一个不算罕见的场景：团队把人工智能接进工单系统，让它根据用户描述生成处理建议。前两周大家觉得新鲜，第三周开始有人默默绕过它——建议读起来通顺，却常常漏掉关键约束，修改成本很高。
这时候讨论“模型够不够强”很容易跑偏。真正卡住流程的，是另一个问题：谁来判断这条建议可以用。
“看起来对”为什么最难验收
传统软件出问题，通常有明确的报错。生成式系统的输出很少报错，它更像一份语气自信的草稿。草稿能不能用，取决于业务上下文里那些没写进文档的默契：这个客户上次投诉过什么，这条规则上个月为什么临时放宽。
把这些默契全部塞进提示词并不现实。一种可行的做法，是把验收动作前置：先定义几条必须满足的硬条件，再谈语言是否自然。比如建议里必须包含责任归属、必须引用对应的条款编号、遇到模糊描述必须反问。硬条件不满足，输出再漂亮也退回。
- 把“好”拆成可检查的几条，而不是凭感觉打分；
- 给每次提示词改动留版本记录，方便回看哪次调整带来了偏差；
- 保留一小批固定样本，改动后先跑一遍，别只看眼前这一条。
权限比效果更值得先谈
另一个常被忽略的细节是位置。人工智能放在“起草”位置和放在“执行”位置，风险完全不同。起草错了，人还能拦一下；执行错了，回滚成本可能高得多。很多团队一开始就想着端到端自动化，结果在异常分支上反复打补丁。
一种常见的路径是先给它只读权限和草稿权限，涉及写操作时留一个人工确认点。确认点不是形式主义，它是收集反例的地方。反例积累到一定数量，才知道该收紧哪条规则、放宽哪条限制。
把它当成需要交接的同事，而不是插件
我倾向于一个朴素的判断：生成式系统更像一个刚入职、记忆力很好但不懂本地规矩的同事。你会给他背景资料，会告诉他哪些事必须问，也会在他交付前抽查。插件坏了可以重装，同事交接不清楚，问题会一直留在流程里。
所以落地时真正要写的文档，不只是接口说明，还有一份“什么情况下不要用它”的清单。这份清单直接影响返工次数，也决定了团队敢不敢把更多环节交出去。流程里多一个明确的停手信号，和一份漂亮的演示同样值得写进文档。
回到开头那个团队，后来他们做的第一件事不是换模型，而是把验收条件写成三行字贴在工单模板旁边。效果谈不上惊艳，但绕过它的人少了。人工智能要进入日常，大概都要经过这种不起眼的修补。