前几天，同事把一段需求贴进对话框，AI大模型很快回了三屏代码，跑起来却直接报错。他改了两个小时提示词，最后发现问题出在需求文档里：「兼容旧接口」这句话被写在附录第三页。
提示词不是咒语
讨论大模型落地时，提示词常被当成一个开关，好像措辞换得足够巧，输出就会听话。实际情况更朴素一些：模型看不到你的项目结构、历史决策，也看不到那些没写进文档的口头约定。它只能基于你递过去的那点上下文做推断。
有个简单的判断方法：同一个问题，换个人来问，答案就明显不同，那多半是上下文缺失，而不是提示词写得不够花哨。
整理输入，比挑选模型更花时间
现在团队做 AI 功能，写代码的时间在减少，整理输入的时间在增加。把散落在文档、工单、代码注释里的信息拼成一段模型能读懂的输入，这件事没有捷径。检索增强这类做法之所以流行，动机也在这里：模型不知道的事，总得有人递过去。
- 只给结论，不给约束条件，模型只能猜
- 同一个术语在不同团队里含义不同，输入里没有统一
- 示例写得太干净，和真实数据的分布差得远
评估别只看它答得像不像
判断一次回答的好坏，很容易停留在语言流畅度上。但流畅和正确是两回事，一段读起来顺理成章的文字，可能把某个字段名编错了。更实际的做法是留一小批有标准答案的任务，每次改动后跑一遍，样本不用多，能覆盖常见分支就够。
也要接受边界。AI大模型在开放问题上的自信程度，和它在事实性任务上的可靠性并不成正比。需要精确数字、需要最新状态、需要有人为结论负责的场合，还是得回到人这里。
慢一点的用法，反而省事
我不太相信「一句话让模型替你干完一个项目」这类说法。真正省时间的用法，是把模型放在那些重复、输入输出明确、错了也能被快速发现的环节：生成样板代码、整理日志、把一段描述改写成几种说法。这些场景里，人的复核成本低，模型的失误也就没那么贵。
回到开头那位同事。他后来没再纠结提示词，而是把需求文档重写了一遍，把隐含条件提到前面。回答的质量立刻不一样。模型没换，换的是它看到的东西。