一个功能上线三个月，用得还算顺。某天业务提了个小改动，工程师打开配置文件，发现那段提示词没人敢动——写它的人已经调去别的组，注释只有一行：别改，改了会乱。功能就这么停着。
这类情况在人工智能落地的过程中出现得比想象中频繁。模型没坏，接口也稳定，卡住的是它周围那些没被写下来的东西：为什么这样切分输入，为什么这条规则要放在最前面，出错时由谁来判断。
那些留在个人手里的判断
传统软件里，业务规则最终会落成代码里的条件分支，读起来难看，但能读。模型做的事情不太一样：它把一部分判断从代码挪到了数据分布和措辞上。同一层意思换个说法，输出可能就变了。这部分没法用一行注释交代清楚，只能靠人反复去试、去记。
于是团队里往往需要一个知道边界在哪的人。他未必懂模型结构，但他清楚哪种输入容易出岔子。问题在于，这种知识大多停留在个人经验里，既没进文档，也没变成测试用例。
它擅长的是“看起来对”
另一个容易被忽略的地方是反馈方式。传统系统的错误通常很显眼：报错、空白、数字对不上。而人工智能的输出往往语法通顺、格式合规，错误藏在细节里。审的人得逐条去看，有时比自己重做一遍还慢。所以在不少场景中，它省下的时间被复核环节吃掉了大半。
这不是说它没用。重复度高、错误代价低、有人愿意抽查的环节，收益确实是实在的。真正要警惕的是把“看起来对”当成“对”，尤其是在没人复核的那条链路上。
先问那几个不上汇报材料的问题
判断一个环节能不能交出去，我倾向于看两件事：错了以后多久能被发现，发现以后能不能回退。这两点比平均准确率更能决定实际体验。准确率是平均数，而业务感受到的是那几次意外。
还有一件事常被跳过：谁来维护。模型会更新，输入会漂移，业务口径也会变。上线时大家关心效果，半年后关心的是还有没有人愿意接手。人工智能系统的维护成本并不只落在算力和调用上，更多落在这种交接的缝隙里。前面那个不敢改的配置文件，说到底是一个没人认领的位置。
所以现在看一个方案，我会先问：这段逻辑三个月后谁来改，改完怎么验证，出了问题找谁。答案清楚，技术选型反而没那么要紧。答案含糊，效果演示再顺，也只是把问题往后推了几个月。