反模式

这些做法在当下往往显得合理，这正是为什么值得提前把它们一一点名。

背后空无一物的关卡

一个本该由人更新的状态字段，实际上却没有任何东西在监看它，也没有任何东西依据它的变化采取行动。代价： 它在评审时看起来像是有监督，但到了生产环境里却什么监督也没有——东西发出去了，却没有人真正批准过。修复方法： 把这个界面接到真正依赖它的东西上，并在正式宣布完成之前端到端走通整条路径，包括“还没有人做决定”这种情况在内。

填在单元格里的决定

一个人被要求在数据表里编辑一个值来批准。代价： 那个值藏在一张他们没有理由打开的表格里，要保存后才会生效，没有一个业务人员会把它当成在做决定——于是批准来得很晚，或者根本不来。修复方法： 在他们本来工作的地方请他们决定：一封卡片式的邮件，按钮会打开确认页面，文档就在眼前，之后再把决定记录到那一行上。参见人工批准。

问完就挂起的请求

一个构建向人请求做决定，然后就停在那里。决定本身被记录下来了，但后续什么都没有发生：文档没有被发出去，提出请求的人也没有被告知，只能靠自己发现问题、再回来重新问一次。代价： 它能通过评审，却在生产环境里失效——工作被记录下来却没有完成，还得有人手动去追。修复方法： 设计这个请求环节，使其在得到答复后（无论是批准、驳回，还是被搁置）能够自动接着往下走，让流程自己把工作做完，或者自己报告结果。

自信满满的总结

一个由 AI 生成、读起来很顺、但背后什么依据都没有的答案。代价： 正因为它读起来令人信服，才能在评审中蒙混过关，结果决策就建立在一个谁也无法追溯的数字上。修复方法： 要求每一个数字都必须带上它的出处记录；当数据中确实没有答案时，就直接说明，而不是自己编一个来填补空白。

可以绕过的计算器

没有任何机制强制让运算经过一个专门的、可核查的步骤，于是在压力之下，AI 就自己把数算出来了。代价： 它通常是对的，而这恰恰是危险所在——出错的情况很少见、也很安静，不到有人去核查往往不会被发现。修复方法： 每一次都把所有运算路由到同一个专门的计算步骤，并展示所用的输入。

写进提示词里的规则手册

把限额、标准或阈值直接写进 AI 的指令里，而不是作为可编辑的数据来保存。代价： 业务人员没有开发人员协助就没法改动一个数字，也没有人能审计某个案例究竟触发了哪一条规则。修复方法： 把规则作为数据保存在一条记录上，让非开发人员也能直接打开并编辑。

分叉出来的副本

复制一个正常运行的构建的内部逻辑，为新的场景做出一个几乎一模一样的版本，而不是把原来的构建参数化。代价： 变成两样东西要维护，还会在不知不觉中彼此走样，而且下一个接手的人往往根本不知道还存在第二份副本。修复方法： 用参数化代替复制。如果确实需要一个真正独立的第二版本，就给它自己的名字和自己的文档，而不是让它冒充原来那一个。

自建捷径

用自定义代码去做平台本来就已经内置提供的事情，通常是因为事先没有人去核实过。代价： 它通常需要一个原本内置方式根本不需要的凭证，而且构建一旦迁移到另一个账户就会失效。修复方法： 在写任何代码之前，先查一查平台当前的能力清单。参见原生优先。

未经核查的提取

不经核对就直接信任一次提取的结果，而不去对照当初要求提取的内容。代价： 如果没有人拿输出结果去对照字段清单，漏掉的字段很容易被忽略。修复方法： 把每一次提取结果都对照字段清单逐一核查，并把过长的字段清单拆成几轮各有侧重的提取。

用检索来数数

把计数或引证类问题——“有多少个”“哪份文档在第几页提到”——当成搜索问题来处理。代价： 这类问题需要结构化记录才能给出精确答案；单靠检索没法展示它的推导过程。修复方法： 把材料索引成结构化记录，再对其进行查询。把搜索检索留给真正的“我该怎么做”这类问题。

抢跑触发

一个流程对一连串相关活动中的第一项就立刻做出反应，而不是等这一连串活动告一段落。代价： 结果在其余相关项目到达之前就已经生成，一旦其余项目到达，它当场就变得错误或不完整。修复方法： 等这一连串活动平静下来之后，再针对完整情况一次性采取行动。

轻信的关卡

一个审批环节直接读取 AI 刚刚给出的数字，而不是根据底层记录独立算一遍。代价： 一个错误的数字可以自己批准自己，因为从来没有人拿它去对照过原始来源核实。修复方法： 这个关卡必须每次都自己重新推导出答案。

自我汇报

一个构建自己汇报自己的成功——一段看起来煞有介事的粘贴结果，一个“已完成”或“已上线”的状态，而实际上从来没有人真正看着它运行过。代价： 对一个从未被真正观察到的世界状态抱有信心。修复方法： 亲自运行一遍，亲眼看着它发生，只有在真正有人看到它成功运行之后，才能把它标记为可用。

绕开隐私保护的捷径

为了回答一个棘手的问题，临时把一处存放原始敏感数据的存储直接连接给 AI。代价： 敏感数据与 AI 之间的隔离，本来就是整个隐私保障的全部内容，而这一刻，它已经在悄无声息中不再成立了——哪怕只是短短一瞬间。修复方法： 绝不连接，哪怕只是暂时的也不行。如果一个问题确实需要用到原始数据，那这个问题本就不该由那个 AI 来回答。

写进提示词里的标准答案

把预期答案——也就是演示应该展示出来的那些数字——直接写进智能体自己的指令里。代价： 演示能通过，但背后的工具其实是错的，而且要等到真正有人提出问题时才会被发现。修复方法： 预期数值只应存在于测试集中，绝不能出现在指令里；在智能体上线之前进行一次检查，一旦指令中包含这些数值就予以拒绝。

把记忆当成数据来源

一个智能体靠自己记得的内容、或者靠此前某个时间点附加给它的文档来回答一个实时数据问题，而不是去读取眼前的原始来源。代价： 一个语气自信、却装着过时数字的答案。修复方法： 不要给任何依据实时数据作答的智能体附加文档，给它定一条常设规则——绝不把数字存进记忆，也绝不凭记忆作答，并且保留一道能够识破过时答案的测试问题。对于任何需要维持一段对话的智能体，要保留它自己的对话历史——它需要靠这段历史，才能对自己先前说过的话保持一致。

在有争议的数字上让步

某个人提出自己的一个数字，智能体就放弃了自己原本用工具算出来的正确数字，转而附和对方。代价： 答案变成了对话中语气最自信的那个人说了算。修复方法： 给智能体定一条质询规则——重新跑一遍工具、尝试用工具复现对方给出的数字，并清楚说明每个数字各自代表什么。

透视表快照

把一份转换过格式的表格里的数据透视表当成仍在实时计算来读取。当一个 Excel 工作簿被转换成 Google 表格时，其中的数据透视表会保留转换那一刻显示的数值，之后就不再更新。代价： 从透视表里取出的每一个数字，都被冻结在转换发生的那一天，无论底下的原始行数据有多新。修复方法： 从原始行数据重新计算，并且无论在哪里展示这份透视表，都要注明这一点。

整张表甩进一轮对话

在一轮对话里，把一整张大型表格或数据表原封不动地丢给智能体。代价： 这超出了智能体一次能消化的量，之后的一切都建立在一次看似完整、实则只读了一部分的基础上。修复方法： 用平台自带的读取步骤来读取它，用一个计算步骤汇总它，只把算好的最终数字交给智能体，并附上这些数字所依据的行、筛选条件和日期。参见原生优先。

从未被复用的共享部件

因为看起来“应该会有用”而构建出来的东西，实际上却从来没有被真正复用过，却还要一直维护下去。代价： 持续投入维护成本却换不回任何价值，还会让人误以为这个构建比实际情况更模块化。修复方法： 在至少有两个真实、独立、且叫得出名字的需求出现之前，不要把某样东西标注为“可复用”。