旁听过一场内部评审，屏幕上是一段客服回复草稿，语气稳，措辞也顺。有人问了一句：这条是模型改的还是人改的？房间里安静了两秒，没人答得上来。这不是技术问题，是流程问题。
类似的空白其实很多。系统上线前，大家盯的是准确率、响应时间、调用成本；上线之后，真正天天被追问的是另一批东西：这条草稿谁签发，改过一版之后原始版本还在不在，出了错能追到哪一步为止。这些问题在立项文档里通常没有位置。
模型不会报错，它只会给一个像样的答案
传统软件出错会抛异常，日志里留一行红字，运维看一眼就知道去哪修。模型不这样。输入稍微变一下，输出就换了个说法，读起来依然通顺合理。工程师私下管这叫静默失败——它不喊，你也就不知道。
所以监控指标得换一套。以前看接口有没有报错，现在得看输出的分布有没有漂：同一个问题问十遍，答案的一致程度如何；不同批次的数据通过率有没有突变；被人工退回去重写的比例是不是在往上走。这些数字不好看，也不适合放进汇报首页，但它们是少数能让人提前看见问题的信号。
评估集是最容易被糊弄的一环
做评估集这件事听起来很工程，实际上很人事。谁来挑样本、挑多少、边界案例放不放进去，直接决定了后面所有结论的成色。见过一种常见做法：拿过去三个月最典型的请求建一个集，跑出来的分数很整齐。可真实环境里让人头疼的，恰恰是那百分之几的怪请求。
- 评估集是谁写的，写的人有没有在一线待过
- 边界样本占多大比例，多久换一次
- 分数掉了，是模型变了，还是进来的数据变了
第三个问题尤其容易被跳过。很多所谓的效果波动，追下去发现是上游业务改了字段含义，模型只是诚实地反映了这个变化。
责任要写在纸上，不能写进模型里
有团队试过一种笨办法：每条产出都带一个「建议」标签，人工确认后才进入正式记录，确认这个动作本身留痕。麻烦是麻烦，但它把责任放回了具体的人身上。另一头也有相反的诉求，希望把人工智能直接接到下游系统，省掉确认那一步——省掉的其实不只是人力，还有可追溯性。
边界大概在这里：越是可逆、风险低、事后能核对的环节，越适合放手；越是一锤定音、对外可见、难以回滚的环节，越应该卡一道人工。这个判断跟模型有多强关系不大，跟业务本身的可逆性关系很大。
提示词不是文档
不少团队把提示词存在某个人的电脑里，或者某个共享文档里，版本靠文件名区分。过两个月，没人说得清线上跑的是哪一版。这不是玄学，就是配置管理没跟上。把它当代码对待——有版本、有评审、能回滚——琐碎，但省心。
回到开头那个问题。那条草稿是谁改的？真正需要的不是一个答案，而是一个随时查得到答案的记录。人工智能进流程，难的从来不是让它跑起来，是跑起来之后每一步都留得下痕迹。