使用 GPT-5 进行编程的六个技巧

OpenAI出了一个GPT-5编程提示技巧，有6点

1）指令要准确，避免相互冲突

GPT‑5 的遵循指令更强，但副作用是：如果规则含糊或彼此打架（尤其是 .cursor/rules、AgentS.md 这类全局规则），模型会更容易卡住或出现执行摇摆。写清楚、去歧义、消除冲突，能显著减少偏差

2）选对推理力度

GPT‑5 无论如何都会进行一定的推理。经验法则：复杂任务 → 高推理力度；常规任务 → 中/低推理力度。如果你发现它在简单活上想太多，要么把需求写得更具体，要么把推理级别调低（例如 medium 或 low）

3）用类 XML语法把规则结构化

实践表明：用类 XML 标签把项目约定、默认技术栈、风格基线分块写清，模型更容易建立统一上下文，不会反复试探你的偏好。示例：

<code_editing_rules>
  <guiding_principles>
  - Every component should be modular and
    reusable
  - ...
  </guiding_principles>
  <frontend_stack_defaults>
  - Styling: TailwindCSS
  </frontend_stack_defaults>
</code_editing_rules>

提示：你可以按模块继续细化，比如 “错误处理规范”“日志与监控约定”“测试边界”等，让模型有明确的默认答案

4）避免过分强硬的语气

在旧模型里常见的“务必、必须、一定要……”的命令式提示（例如：

Be THOROUGH when gathering information.
Make sure you have the FULL picture before replying.

）在 GPT‑5 上可能适得其反：它会把收集上下文开到过头（例如过度并行使用工具），反而拖慢节奏。更好的做法是轻度引导＋清晰边界：说明什么时候需要更彻底、什么时候到此为止、何时汇报阶段进度

5）零到一任务：先规划＋自省，再动手

从无到有做应用时，让模型先想清楚评判标准，再据此迭代产出，成功率更高。示例：

<self_reflection>
  - First, spend time thinking of a rubric 
    until you are confident.
  - Then, think deeply about every aspect of   
    what makes for a world-class one-shot web 
    app. Use that knowledge to create a rubric 
    that has 5-7 categories. This rubric is 
    critical to get right, but do not show 
    this to the user. This is for your 
    purposes only.
  - Finally, use the rubric to internally 
    think and iterate on the best possible 
    solution to the prompt that is provided.
    Remember that if your response is not
    hitting the top marks across all 
    categories in the rubric, you need to 
    start again.
</self_reflection>

要点：先定 5～7 个维度的打分表→ 按表对方案自评迭代 → 不达标就重来。这能显著降低一次成型任务的偏差

6）可控热情度：给 Agent 设工具预算与查找节奏

GPT‑5 往往会把信息搜集做得很彻底。若你希望它别过度深挖、别盲目并行调用工具，在提示里明确：工具预算、何时详查、何时阶段汇报。示例：

<persistence>
  - Do not ask the human to confirm or 
    clarify 
    assumptions, as you can always adjust 
    later 
  — decide what the most reasonable assumption 
    is, proceed with it, and document it for 
    the user's reference after you finish 
    acting
</persistence>

直白理解：先按最合理的假设把事做完，再把假设、取舍、影响完整记录给用户；别事事打断来回确认。结合并行/串行的明确指示与工具配额，你就能更精细地控制 Agent 的节奏与成本

总结一下

规则要准、无冲突：全局规则文件尤其要避免歧义。
推理档位要对：难题用高档，日常用中低档，避免大炮打蚊子
结构化上下文：用类 XML 把约定、默认、风格写清楚
语气别过火：轻度引导＋清晰边界，避免过度求全
先规划再产出：用自省式打分表驱动零到一任务。
控节奏与预算：设工具预算与检查节点，少走弯路