实测50个真实PR：这4条Prompt技巧让AI写代码准确率飙升22%
大部分教AI写代码的prompt技巧，都是从文本生成那边直接搬过来的——“要具体”、“给例子”、“一步步思考”。这些建议没错，但太粗了。当你让AI帮你写一个200行的函数，编译通过但逻辑全错时，你需要的不是大道理，而是真正能用的方法。
我们花了两周时间，在Claude 4 Opus、GPT-4.1和Gemini 2.5 Pro三个模型上，测试了一套包含50个编程任务的基准——这些任务不是LeetCode题，也不是合成数据，而是从开源项目里扒下来的真实bug修复、代码重构和功能实现。下面是我们发现的真正有用的技巧，以及那些看着对其实没用的坑。
系统提示词：最关键的16个token就能让准确率涨22%
系统提示词（System Prompt）是AI在整段对话中一直会听的指令。大部分开发者从GitHub上复制个模板就再也不管了，这是个大错误。
我们测试了5种系统提示风格，基准是“你是一个有用的编程助手”。结果如下：
- 只设角色（“你是一个有10年经验的资深TypeScript工程师”）：没有任何提升。AI默认就是程序员行为，加个角色标签只是浪费token。
- 加了一大堆指令（400字，包括格式、命名规范、错误处理、日志、注释）：在多文件重构任务上提升了12%，但单函数修复反而变差了。因为AI会过度执行指令——把一个单行修复硬套上日志样板代码。
- 只设约束（精确的行为规则：“不要写你没验证过的代码。如果从上下文看不清楚修复方案，先问我要相关文件”）：调试准确率提升18%。这招管用是因为它直接堵住了AI最致命的毛病——信息不足时自信地瞎编。
- 极简，只给一条硬规则（“不要写代码，先说出你对问题的理解，如果有模糊的地方就问清楚”）：准确率提升了22%，这是所有系统级干预中效果最好的，而且只用了16个token。提升的原因是，AI不再跳过理解环节直接写代码，而是先确认自己没理解错。
结论是：系统提示词应该约束AI最坏的行为，而不是列出它应该怎么做。你每加一条指令，就可能被过度应用。挑一两条能挡住你实际遇到的故障模式的硬规则，其他全删掉。
我们测试过的ROI最高的系统提示词只有一句话：“在写代码之前，先说清楚你理解的任务是什么，还缺什么信息。如果你必须做假设，明确标出来。”就这一句，三个模型都减少了幻觉般的错误导入，也少了很多解决错问题的函数。
少样本示例：格式比内容更重要
给AI看几个输入输出的例子，这是最古老的prompt技巧了。但我们在代码生成上发现了一个反直觉的结果：例子的格式，比例子是否和当前任务相关更重要。
我们对比了四种少样本策略：
- 不相关的例子，但格式正确：让AI看两个SQL查询的例子，然后让它写一个React组件。准确率比零样本提升了14%。例子教会了AI期望的输出结构——包含导入、处理边界情况、加简短说明——尽管领域完全不相关。
- 相关的例子，但格式不一致：给了两个React组件例子，一个用了TypeScript类型，另一个用了PropTypes。准确率反而下降了8%。格式混乱让AI比领域相关性更有帮助。
- 一个“拒绝”例子：包含一个例子，其中要求做不可能的事，理想回答是“这事办不到，因为……”。这个例子让幻觉方案的发生率降低了31%。教会AI什么时候说“不”，比教它怎么说“是”更有价值。
- 例子中体现思考链：当例子显示了中间推理步骤——“首先，我会检查哪些函数被调用了，然后追踪控制流”——然后再给出最终代码，AI会模仿这种推理，产生的逻辑错误减少19%。
实用的建议：每个prompt里至少放一个例子，用来教格式，不只是教内容。如果有多个例子，确保它们在结构上一致。
思考链（Chain-of-thought）：什么时候该用，什么时候别用
“一步步思考”是被引用最多的prompt技巧，它确实有用——但要看场景。我们把50个任务按复杂度分了类：
- 需要跨三个或更多文件推理的任务（多文件重构、跨服务边界的debugging、带破坏性变更的依赖升级）：思考链提升了26%的准确率。好处来自AI显式地走查调用图和数据流，然后才写代码，从而抓住了那些否则会悄无声息写进代码的错误假设。
- 单函数任务（“写一个验证邮箱地址的函数”、“给这个端点加错误处理”）：思考链没有提升，反而在两个案例中引入了错误。AI会“想太多”，给原始需求没要求的边界情况写代码，“思考”变成了需求蔓延。
“一步步思考”不是免费的午餐。对于适合单个函数的任务——特定模型的错误处理、输入验证、字符串操作——多出的推理步骤只会增加延迟而不提升正确性，有时AI还会发明原始prompt没有指定的约束。只在任务跨越文件或服务边界时才用思考链。
不同模型的行为也有差异：Claude 4 Opus用思考链来验证假设是否匹配代码上下文，所以它在debugging中得分最高。GPT-4.1用它来探索不同实现方案，提升了重构质量，但有时会给出多个互相竞争的方案。Gemini 2.5 Pro最死板——它严格按照思考链指令执行，但很少用它来检查自己的错误。
三个必须避免的prompt陷阱
有些prompt模式会导致AI写出更烂的代码，无论用哪个模型：
- “写干净的代码”这条指令：告诉AI写“干净”、“优雅”、“结构良好”的代码，对输出质量没有任何可测量的提升——AI本来就会按你指定的语言写习惯用语。它实际干的事是浪费你本可以用来放具体约束的token。把“写干净、结构良好的Python”换成“在所有函数签名上使用类型提示，并显式处理None返回值”。
- 过度指定解决方案：比如“用二叉搜索树存储用户记录”，这强行绑定了AI可能错误的数据结构。改为描述约束：“用户记录需要支持ID查找，10000条记录内达到亚毫秒级延迟。”AI会自己选合适的数据结构——通常会是哈希表，不是树。
- “加全面测试”这个要求：在第一版代码生成时同时要求写测试，会分散AI的注意力，导致代码和测试都更差。我们测得实现准确率因此下降15%。分成两步：先生成实现，然后单独prompt让它根据刚收到的实现写测试。
共同点是：想一次优化多个目标的prompt，结果每样都做不好。AI每个token的注意力是有限的，每多一条指令就会稀释前面的指令。
这篇文章的原始素材来自pickuma.com，感谢原作者的深度测试。
