加载中...
GPT-5 在指令遵循和推理能力上比前代更强，但也因此更“敏感”：如果规则里有冲突或表述过度强硬，模型往往会卡壳或输出异常。为此，OpenAI 发布了面向开发者的 《GPT-5 for Coding》技巧小抄，其中总结了使用 GPT-5 进行编程与代码生成时最实用的六条经验。这些技巧与普通的“写作提示工程”不同，它们专门针对软件开发场景：如何写规则、怎样控制推理强度、如何避免模型“想太多”，以及怎样利用 GPT-5 的新特性把它真正驯化成可靠的结对编程伙伴。本文对这六条技巧逐条进行解释总结。
欢迎关注 DataLearner 官方微信，获得最新 AI 技术推送
GPT-5 对指令很敏感、遵从度高，连细枝末节也会当真。如果你的规范里前后矛盾（“要详细注释” vs “尽量少注释”），模型会纠结：到底哪条更优先？结果常常是输出摇摆、质量不稳。 所以要么统一成一种规则，要么明确边界：在哪些情况“该注释”、哪些情况“不该注释”。
建议如下：
小例子 “要写大量注释”和“尽量少注释”二选一；若要折中，就改成：“仅在复杂算法与关键边界条件处写行内注释，模块头 3 行概述”。
GPT-5 不管怎样都会“想一想”。复杂任务需要更强的推理才能稳；但简单小修若也用高强度，模型容易“想太多”，把小问题演成大改动。 因此，按任务难度与范围选 Low/Medium/High，并在请求里点名范围和禁区。
怎么落地：
如果输出开始变啰嗦、偏题或“自发优化”，通常是推理强度过高或边界不清，此时就应该让模型少推理了。
自由叙述的文字，人读得懂，但模型未必抓得准重点。把规则模块化并用“类 XML”包裹，等于给模型提供“坐标系”——哪里是原则、哪里是默认栈、哪里是禁区、最后要什么交付物。
怎么落地：
小例子（模板）
<code_editing_rules>
<principles>
- 组件化与最小变更
- 先通过测试再优化
</principles>
<stack_defaults>
- Frontend: React + Tailwind
- Server: Spring MVC
</stack_defaults>
<forbidden>
- 在 UI 组件写业务逻辑
- 引入非必要第三方依赖
</forbidden>
<delivery>
- 产物：git diff + 新/改测试 + 变更说明
</delivery>
</code_editing_rules>
上面就是把编程原则、技术栈分组后在不同的xml节点上说明，这个经验OpenAI说来自Cursor，实测发现GPT-5对于XML格式的指令遵从更优秀，非常建议使用~
像“务必/必须/全面收集”这类一刀切表述，会驱动 GPT-5 去过度收集上下文、过度调用工具，响应变慢、跑题概率升高。 更好的写法是告诉它：什么情况下要全面收集，什么情况下直接产出。
怎么落地：
小例子（改写） 下面这个务必就会让模型必然触发收集的操作，其实应该是按照不同情况来判断。
- 务必在回复前收集全部相关信息。
+ 若缺失关键参数或涉及外部依赖，再补充收集；否则直接产出。
<communication>
strategy: proceed_then_report <!-- 或 confirm_before_action -->
assumptions: 允许合理默认值；在变更说明中逐条列出
</communication>
如果让GPT-5从零搭一个模块/页面/流程，直接开写容易遗漏边界。让模型先拟一套 5–7 条内部评价维度（rubric），再据此自检一次，首稿质量会明显更稳。 注意：这套自检是内部过程，对读者只给最终结果和变更说明，避免暴露冗长思考。
怎么落地：
小例子（模板）
<self_reflection>
- 拟定 5–7 条评价维度（仅内部使用，不展示）
- 产出前按维度自检；不达标则迭代 1 次
- 对用户仅输出：最终代码、测试与变更说明
</self_reflection>
GPT-5 倾向“面面俱到”：读很多文件、并行探索多个路径。没有限制时，速度慢、确定性差。 给它预算（最多读多少文件、访问几次依赖图）、并行门槛（什么条件下才并发搜索）、沟通策略（先做后报 or 先问再做），能把它的“热心”引导到正轨。
怎么落地：
files_max、dep_graph_access 等上限。把规则单点生效、任务强度分档、输入结构化、约束可执行，GPT-5 才能稳定按你的工程习惯写代码，主要包括：
.prompt/rules.xml 或 .cursor/rules），把硬规则与非目标集中在此。OpenAI的GPT-5 for Coding原文：https://cdn.openai.com/API/docs/gpt-5-for-coding-cheatsheet.pdf