判断一件事能不能交给 AI，标准不是"AI 会不会做"，而是"它做错了我能不能发现"。按这个标准分三档：错了一眼看得出且代价低（文案、段落结构）放手交给 AI；错了看得出但代价高（Title、URL、内链、Schema）AI 生成加强制校验；错了看不出（参数、认证编号、有效期）绝不让 AI 生成，只允许它从原始资料搬运。人机审核闸门要放在信息最容易被验证的那一步，而不是发布前。

AI 的边界划在哪：以「错了能不能被发现」为唯一标准

先看一个几乎无法察觉的错误

打开 Claude 或 ChatGPT，输入：

帮我写一个 CP-100 不锈钢离心泵的英文产品页，面向欧美工业买家。

你会拿到一份相当漂亮的东西。术语专业，结构完整，参数表格排得整整齐齐：最大流量 120 m³/h，扬程 50 m，效率 78%，NPSH 3.2 m，壳体 SS316，认证 CE / ATEX Zone 2。

这些数字全是编的。

不是“有几个不准”，是每一个都来自模型对“一台叫 CP-100 的不锈钢离心泵大概什么参数”的统计推测。而它们看起来完全合理——量级对、单位对、彼此之间的比例关系也说得通。

这才是真正的危险所在。不是 AI 会编，是它编得像真的。

文案写得烂，你扫一眼就知道；参数编错了，你扫一百眼也看不出来，直到客户拿着这份参数做完工程计算、下了单、进了生产，才发现做不出来。

换一个提问方式

大多数人判断“这活能不能交给 AI”，问的是：

AI 做这件事做得好不好？

这个问题没用。因为 AI 写产品页写得非常好——语言、结构、专业度都好，唯一的问题是数字是假的。按“做得好不好”来判断，你会得出“可以交给它”的结论。

换成这个问题：

它做错了，我能不能发现？多久能发现？发现之前的代价是多少？

同一件事，答案完全反过来。

这个标准的好处是它不依赖你对 AI 能力的判断（那个会随模型升级而变），只依赖你对自己的验证能力的判断（那个基本不变）。模型再强一年，编参数这件事的可发现性也不会提高。

三档分类表

把产品页上的元素按这个标准过一遍，会自然分成三档：

档位	判据	典型元素	处理方式
一档	错了一眼看得出，改起来便宜	产品介绍段落、段落顺序、FAQ 问句、CTA 文案、语气润色	放手交给 AI，人只做取舍
二档	错了看得出，但发现得晚、代价高	Title / URL / H1、内链指向、JSON-LD 结构、hreflang	AI 生成 + 强制机器校验
三档	错了看不出	参数值、工况条件、认证编号、证书有效期、材质牌号、型号规格	绝不让 AI 生成，只允许搬运

一档不用多说。真正需要想清楚的是二档和三档的区别。

二档的错误是可发现的，只是不会立刻发现。 比如 AI 给新产品页起的 Title 和你已有的品类页撞了词，这个错误客观存在、能被查出来，但要么靠工具审计，要么等三个月后看数据才知道。所以对策是：让 AI 生成，但加一道机器校验——查重、查冲突、查结构合法性。校验能查出来的，就不算不可发现。

三档的错误没有可发现性。 一个编出来的流量值，你没有任何自动手段判断它对不对，因为“对”的定义在供应商那份 PDF 里，不在任何可校验的规则里。这一档只有一条路：不让 AI 生成，只让它搬运。

「搬运」和「生成」的区别，是有没有可核对的对象

这一点值得单独说清，因为它是整套做法的支点。

生成：让模型输出“CP-100 的最大流量”。错了没有对照物，你只能凭经验感觉数字合不合理。
搬运：给模型一份供应商 datasheet，让它把最大流量抄进指定字段，并注明抄自第几页。错了你能翻到第 2 页逐字核对。

同一个字段，同一个模型，可发现性天差地别。差别不在模型能力，在你手上有没有一个可以对照的原始来源。

所以三档字段的正确姿势是：先把供应商资料结构化进事实层（这一步是搬运，可核对），页面生成的时候从事实层取值（这一步是机械插值，不经过模型）。模型全程不接触“这个数字应该是多少”这个问题。

人机闸门放在信息最容易被验证的那一步

知道了要留人工，下一个问题是留在哪一步。

大部分人的直觉是“发布前审一遍”。这是最差的位置。

发布前你面对的是一整页成品：一千多词英文、几段介绍、一张参数表、三条 FAQ、一堆链接。你要在这堆东西里找出那个错误的数字。人的注意力在这种场景下会自动漂移到最容易评价的维度上去——文字流畅度、排版好不好看。审了半小时，其实审的是文案。

同一批信息，在刚抽取完的时候审是另一回事：屏幕左边是供应商 PDF 第 2 页，右边是十几个字段，逐个对。这个动作枯燥但明确，五分钟能审完，而且不会审错。

把人工闸门放在信息最容易被验证的那一步，不是放在最后一步。

这条思路可以脱离本文场景使用。任何“AI 干活、人把关”的流程，都该问一句：我把关的那个位置，是这批信息一生中最容易被核对的时刻吗？如果不是，往前挪。

配套的一个小纪律：审核的时候只看数字，不看文风。 想改文案，等审完了另开一轮。两件事混在一起做，一定是数字被文风带走。

三条推论

前面的标准立住之后，下面这三条都不是独立规矩，是它的直接推论。

推论一：数字来自事实层，散文来自模型

这是三档表的执行形态。具体做法是页面模板里放占位符（{{max_flow}}），模型被要求只输出占位符、不输出数值，最后由脚本把事实层的值填进去。回填时如果发现有占位符没匹配上，直接报错——宁可构建失败，不要发布一个来源不明的数字。

推论二：确定性运算交给代码，不交给模型

单位换算（m³/h → GPM）、判断证书是否过期、比较两个参数哪个大、算折扣——这些模型都“会做”，但它算错的时候你同样发现不了。凡是有确定算法的事情，模型的可发现性和参数一样低。

判断很简单：这件事有唯一正确答案且能用代码算出来吗？ 能，就别问模型。

推论三：让模型说「我没找到」比让它给一个合理答案更有价值

模型的默认倾向是补全，不是承认缺失。一份 datasheet 上没写 NPSH，你让它抽取参数，它很可能给你一个“合理”的 NPSH。

对策是把这件事写成硬要求，而不是指望模型自觉：原文没有的字段一律留空，并单独列出缺失清单。缺失清单是有价值的产出——它告诉你还要跟供应商问哪几个数，而一个编出来的值只会让你以为已经问过了。

这套标准怎么用在别的地方

把“错了能不能被发现”套到其它日常任务上，边界都会自己浮现出来：

任务	不可发现的部分（必须留人 / 留原文）	可以放手的部分
英文产品文案	参数、认证、承诺的交期与保修条款	句式、段落结构、语气
报价单	价格、有效期、付款条件	排版、说明文字
客户邮件回复	承诺（能做到什么、什么时候交）	措辞、开头结尾
竞品分析	引用的数据与出处	归纳、对比框架
翻译技术文档	数字、单位、型号、标准编号	句子怎么组织