Prompt 是新的接口设计，不是新的搜索词
用 LLM 写代码这件事最大的认知陷阱是把 prompt 当成"搜索框"——你输入一个想法，它返回一段实现，看上去工作流就该是这样。
但搜索框的契约是模糊的：你打几个关键词，搜索引擎用启发式凑出最相关的几条结果，你再人肉筛选。它不会按你想的方式去执行某种"流程"。
LLM 不一样。LLM 会把你写下来的每一句话**当作一份执行 spec**。你说"加个错误处理"，它会就近找一处 try/except 包起来；你说"加个有用的错误处理"，它会开始想"我应该捕获什么、log 什么、什么情况降级"。两个 prompt，两份完全不同的实现。区别不在搜索质量，而在你写的 spec 完不完整。
从"问"到"约定"
我现在写 prompt 的时候不再想"我要问什么"，而是想"我要和一个会逐字执行的同事约定什么"。约定大概包含几层：
- 目标：要做完什么——但不是"实现 X"，而是"实现 X，使得 Y 这件事变得可能 / Z 这种回归不会发生"。
- 边界：哪些文件不能动、哪些缩写不要展开、哪些"看起来更整洁的重写"不要做。
- 验收：跑哪条命令算过、哪个 case 算过、什么样的输出说明完成了。
没写边界的时候我经常会得到"顺手把那个老方法重构了一下"——它技术上没错，但完全不是我要的那次提交。
边界比目标更重要
这是反直觉的一点。一开始我以为只要把"目标"写得越细越好，结果就会越准。后来发现真正影响产出质量的是负面边界——明确告诉它不要做什么。
因为模型默认是有"上进心"的：你给它一个待修的 bug，它会顺便清理它觉得丑的代码、补几个它觉得缺的测试、改几个它觉得不专业的命名。每一处单独看都"更好"，合在一起就是一个不能 review 的 PR。
"修这个 bug，不要碰任何其他文件"——这句话的价值常常超过整个目标描述。
verify, don't trust the summary
第二个反直觉的事：模型告诉你"已完成"的时候，你别信它的总结，要看 diff。
这不是说模型在撒谎，而是它的总结是基于"我打算做什么"而不是"我实际写到文件里的是什么"。中间任何一步——文件没写成功、edit 应用错位置、改了之后又被覆盖——它的总结都不会更新。
这条规矩我吃过太多次亏才学会。现在 review AI 改的代码时，我先看 git diff，再读它的解释。
结果
把 prompt 当 spec 写之后，我的 PR 数量没变，但每个 PR 改回的次数明显少了。AI 不再是"快速地干各种你没想清楚的事"，而是"严格按照你想清楚的事干"。后者更慢，但慢得有意义。