GPT-5 在指令遵循和推理能力上比前代更强，但也因此更“敏感”：如果规则里有冲突或表述过度强硬，模型往往会卡壳或输出异常。为此，OpenAI 发布了面向开发者的 《GPT-5 for Coding》实践技巧，其中总结了使用 GPT-5 进行编程与代码生成时最实用的六条经验。这些技巧与普通的“写作提示工程”不同，它们专门针对软件开发场景：如何写规则、怎样控制推理强度、如何避免模型“想太多”，以及怎样利用 GPT-5 的新特性把它真正驯化成可靠的结对编程伙伴。本文对这六条技巧逐条进行解释总结。
1) 避免在 prompt 中包含有冲突的指令（单一事实来源）
GPT-5 对指令很敏感、遵从度高，连细枝末节也会当真。如果你的规范里前后矛盾（“要详细注释” vs “尽量少注释”），模型会纠结：到底哪条更优先？结果常常是输出摇摆、质量不稳。
所以要么统一成一种规则，要么明确边界：在哪些情况“该注释”、哪些情况“不该注释”。
建议如下：
- 所有硬规则只写一处（SSOT）：把强约束集中到一个块或一个文件里，其他地方只“引用它”。
- 同类规则只保留一份，并且写清“非目标”（不做什么），告诉模型不要做什么能显著减少越界。
小例子
“要写大量注释”和“尽量少注释”二选一；若要折中，就改成：“仅在复杂算法与关键边界条件处写行内注释，模块头 3 行概述”。
2) 给任务选对“推理强度”（Reasoning Effort）
GPT-5 不管怎样都会“想一想”。复杂任务需要更强的推理才能稳；但简单小修若也用高强度，模型容易“想太多”，把小问题演成大改动。
因此，按任务难度与范围选 Low/Medium/High，并在请求里点名范围和禁区。
怎么落地：
- Low：语法/类型小修、小范围重命名 → 要求“最小改动，不重排结构”。
- Medium：新增小功能（≤1 文件）、需考虑边界和测试 → 先列依赖与边界，再实现。
- High：涉及架构/性能/多约束权衡 → 系统性分析、权衡与一次自检。
如果输出开始变啰嗦、偏题或“自发优化”，通常是推理强度过高或边界不清，此时就应该让模型少推理了。
3) 用“类 XML”结构组织规则（让模型更好“定位”）
自由叙述的文字，人读得懂，但模型未必抓得准重点。把规则模块化并用“类 XML”包裹，等于给模型提供“坐标系”——哪里是原则、哪里是默认栈、哪里是禁区、最后要什么交付物。
怎么落地：
按原则 / 默认技术栈 / 禁用项 / 交付物格式分区；块名要语义明确。 这不是要求真 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格式的指令遵从更优秀，非常建议使用~
4) 把“强硬命令”改成“条件化约束”（避免过度探索）
像“务必/必须/全面收集”这类一刀切表述，会驱动 GPT-5 去过度收集上下文、过度调用工具，响应变慢、跑题概率升高。
更好的写法是告诉它：什么情况下要全面收集，什么情况下直接产出。
怎么落地：
定义触发条件（如缺关键参数/涉及外部依赖）才扩展收集；否则“直接交付”。 指明沟通习惯：先做后报告，还是先问再做。
小例子（改写）
下面这个务必就会让模型必然触发收集的操作，其实应该是按照不同情况来判断。
- 务必在回复前收集全部相关信息。
+ 若缺失关键参数或涉及外部依赖，再补充收集；否则直接产出。
<communication>
strategy: proceed_then_report <!-- 或 confirm_before_action -->
assumptions: 允许合理默认值；在变更说明中逐条列出
</communication>
5) 0→1 任务先“内部规划与自检”，再给终稿（更稳的一次成型）
如果让GPT-5从零搭一个模块/页面/流程，直接开写容易遗漏边界。让模型先拟一套 5–7 条内部评价维度（rubric），再据此自检一次，首稿质量会明显更稳。
注意：这套自检是内部过程，对读者只给最终结果和变更说明，避免暴露冗长思考。
怎么落地：
维度建议：可维护性、边界处理、可测试性、无副作用、性能基线、与既有栈一致性、可读性（从中挑 5–7 条即可）。 自检不过关 → 允许模型内部再迭代一次。
小例子（模板）
<self_reflection>
- 拟定 5–7 条评价维度（仅内部使用，不展示）
- 产出前按维度自检；不达标则迭代 1 次
- 对用户仅输出：最终代码、测试与变更说明
</self_reflection>
6) 驯服代理“过度积极”：工具预算 / 并行门槛 / 沟通策略
GPT-5 倾向“面面俱到”：读很多文件、并行探索多个路径。没有限制时，速度慢、确定性差。
给它预算（最多读多少文件、访问几次依赖图）、并行门槛（什么条件下才并发搜索）、沟通策略（先做后报 or 先问再做），能把它的“热心”引导到正轨。
怎么落地：
- 预算：
files_max、dep_graph_access等上限。 - 并行门槛：只有在测试失败且无法定位时才并发检索。
- 沟通策略：默认先做后报告；遇关键风险再切换为先问再做。
GPT-5编程提示词优化总结：快速落地清单（把它写进你的工程）
把规则单点生效、任务强度分档、输入结构化、约束可执行，GPT-5 才能稳定按你的工程习惯写代码，主要包括：
新建或整合一个 SSOT（如 .prompt/rules.xml或.cursor/rules），把硬规则与非目标集中在此。给常见任务绑定推理强度模板（Low/Medium/High），并在脚本或 Bot 命令中一键套用。 用“类 XML”把原则/默认栈/禁用项/交付物分块；请求中点名强度与边界。 0→1 任务启用内部自检；交付只给最终结果 + 变更说明。 设置工具预算/并行门槛/沟通策略，避免“过度积极”带来的拖沓。
