Codex Prompt 中“目标 + 约束”写法详解与操作指南

1. 文档目标

这份文档专门解决下面几个问题：

• 为什么 Prompt 里必须写清目标和约束
• 目标和约束分别应该怎么写
• 什么样的写法最容易让 Codex 理解并执行
• 不同任务场景下，目标和约束该怎么变化
• 有哪些常见误区会导致 Codex 输出跑偏

读完后，你应该能够：

• 写出更容易让 Codex 准确执行的 Prompt
• 明确区分"目标"和"约束"
• 为开发、排错、测试、文档场景写出更高质量的请求
• 把这套方法沉淀为团队共用模板

2. 为什么 Prompt 里一定要写"目标 + 约束"

很多人问 Codex 时，只写了"想做什么"，却没有写"不能做什么""应该怎么做""做到什么程度算完成"。

这就会导致几个典型问题：

• 方向对了，但范围太大
• 功能实现了，但破坏了旧逻辑
• 答案很完整，但不符合项目风格
• 它顺手做了很多你没要求的事

一句话理解：

目标决定 Codex 要往哪里去，约束决定它不能怎么走。

3. 什么是"目标"

目标就是你希望 Codex 最终达成的结果。

一个好目标通常要回答三个问题：

• 最终要完成什么
• 当前这一步先完成什么
• 什么情况下算完成

差的写法

帮我改一下这个接口。

问题：

• 改什么不清楚
• 为什么改不清楚
• 改到什么程度不清楚

好的写法

目标：修复订单分页接口手机号筛选失效问题。
当前这一步：先判断根因，不要直接改代码。
成功标准：明确是参数、Java 逻辑还是 SQL 条件导致的问题。

4. 什么是"约束"

约束就是你要求 Codex 在执行过程中必须遵守的边界和规则。

常见约束包括：

• 不能改什么
• 必须兼容什么
• 不做什么
• 优先采用什么方式
• 输出必须包含什么

差的写法

帮我修好就行。

问题：

• 它可能会大改
• 可能会顺手重构
• 可能会改到你不想动的部分

好的写法

约束：
1. 不修改接口路径
2. 不改变入参结构
3. 不做无关重构
4. 不影响其他筛选条件
5. 优先最小改动

5. 为什么很多 Prompt 会失败

很多失败，不是因为内容太少，而是因为结构不清。

常见失败原因：

• 只有目标，没有约束
• 只有约束，没有明确目标
• 目标过大，但当前步没有收缩
• 约束写得太空泛
• 输出要求不明确

6. 目标和约束在 Prompt 里的正确位置

最推荐的写法是把它们单独列出来，而不是埋在大段描述里。

推荐结构

目标
当前这一步
项目背景
相关文件/模块
约束
风险提示
输出要求
验证标准

7. 最推荐的 Prompt 结构模板

请帮我处理一个任务。

目标：
[最终要达成什么]

当前这一步：
[当前先只完成什么]

项目背景：
[项目类型 / 技术栈 / 相关模块]

相关文件或模块：
[关键位置]

约束：
[不能改什么 / 必须兼容什么 / 不做什么 / 优先怎么做]

风险提示：
[高风险点]

输出要求：
1. [先做什么]
2. [再做什么]
3. [最后做什么]

验证标准：
[怎样算完成]

8. 怎么写"目标"更清楚

目标写法建议满足这 4 条：

8.1 用一句话说清最终结果

例如：

• 修复什么问题
• 增加什么能力
• 输出什么文档

8.2 当前步要收缩

不要每次都要求"一步到位"，而要说清当前只做哪一步。

8.3 尽量有成功标准

告诉 Codex 什么情况算完成。

8.4 避免抽象词

像"优化一下""改好一点""处理一下"这类词都太模糊。

9. 怎么写"约束"更有效

约束不是越多越好，而是越具体越有价值。

推荐写法

• 不修改什么
• 不影响什么
• 必须兼容什么
• 不做什么
• 优先采用什么策略

示例

约束：
1. 不修改数据库表结构
2. 不改变接口返回格式
3. 不影响现有权限逻辑
4. 不做无关重构
5. 优先最小修改

10. 哪些约束最值得优先写

下面这些约束最常用、也最有价值：

10.1 范围约束

例如：

• 只改指定模块
• 只改后端，不改前端

10.2 兼容约束

例如：

• 保持接口兼容
• 保持旧数据兼容

10.3 风险约束

例如：

• 不改事务边界
• 不改数据库结构
• 不动权限逻辑

10.4 方法约束

例如：

• 优先最小改动
• 先分析再执行
• 先给计划再改

10.5 输出约束

例如：

• 先输出根因分析
• 最后给验证步骤

11. 标准操作流程

1. 明确最终目标
2. 收缩当前步目标
3. 写清关键约束
4. 补项目背景和相关文件
5. 明确输出要求
6. 明确验证标准
7. 再交给 Codex 执行

12. 第一步：先写最终目标，再写当前这一步

这个顺序非常重要。

推荐写法

目标：给会员资料管理新增 customerLevel 字段。
当前这一步：先只分析影响范围，不直接改代码。

为什么这样写

因为：

• 最终目标给方向
• 当前步目标给节奏

13. 第二步：优先写关键约束，而不是想到什么写什么

不是所有约束都要写，优先写最会影响结果的那些。

优先级通常是

1. 不能改什么
2. 不能破坏什么
3. 不做什么
4. 优先采用什么策略

14. 第三步：把目标和约束与项目上下文绑在一起

如果你只写目标和约束，但没有项目背景，Codex 仍然可能给泛化答案。

所以更好的方式是：

• 目标 + 当前步
• 相关模块 / 文件
• 约束
• 输出要求

15. Java / Spring Boot 项目实战实例

场景

订单分页接口在带手机号筛选时返回空数据。

不推荐写法

帮我修一下订单接口。

问题：

• 目标不明确
• 约束没有
• 很容易发散

推荐写法

请帮我处理一个 bug。

目标：
修复订单分页接口手机号筛选失效问题。

当前这一步：
先判断根因，不要直接改代码。

项目背景：
这是一个 Spring Boot + MyBatis 项目。

相关文件：
1. OrderController
2. OrderServiceImpl
3. OrderMapper
4. OrderMapper.xml

约束：
1. 不修改接口路径
2. 不改变入参结构
3. 不做无关重构
4. 不影响其他筛选条件

输出要求：
1. 先判断更可能是参数、Java 逻辑还是 SQL 条件问题
2. 再给最小修复建议
3. 最后给验证步骤

验证标准：
1. 手机号筛选恢复正常
2. 其他筛选条件不受影响

16. 功能开发实战实例

场景

要给会员资料管理新增 customerLevel 字段。

推荐写法

请帮我处理一个功能开发任务。

目标：
给会员资料管理新增 customerLevel 字段，并最终支持新增、编辑、分页筛选和列表展示。

当前这一步：
先只分析影响范围并列出应修改模块，不直接改代码。

项目背景：
这是一个 Java / Spring Boot + MyBatis 项目。

相关模块：
1. MemberController
2. MemberServiceImpl
3. MemberMapper / MemberMapper.xml
4. ReqVO / RespVO / SaveVO
5. 前端列表和表单页面

约束：
1. 优先最小改动
2. 不做无关重构
3. 保持现有接口风格
4. 兼容现有列表和筛选逻辑

输出要求：
1. 输出影响范围
2. 输出建议修改文件
3. 输出风险点
4. 输出建议执行顺序

17. 测试任务实战实例

场景

一个需求已经做完，现在要补测试。

推荐写法

请帮我补充测试方案。

目标：
为本次 customerLevel 字段扩展补充测试范围和回归清单。

当前这一步：
只输出测试点和验证清单，不修改代码。

项目背景：
Spring Boot + MyBatis，涉及会员列表、编辑表单和分页筛选。

已完成改动：
1. 后端字段流转已完成
2. SQL 筛选已支持
3. 前端展示已完成

约束：
1. 不改代码
2. 覆盖正常、异常、边界和回归场景

输出要求：
1. 功能测试点
2. 异常测试点
3. 边界测试点
4. 联调清单
5. 回归清单

18. 文档生成实战实例

场景

你想让 Codex 帮你整理一份模块说明文档。

推荐写法

请帮我生成一份模块说明文档。

目标：
输出会员模块的结构说明、调用链说明和开发注意事项。

当前这一步：
先读取相关模块并生成文档大纲，不直接写最终完整文档。

项目背景：
这是一个 Spring Boot 项目，会员模块与订单模块有关联。

约束：
1. 文档要贴近真实代码结构
2. 不写空泛描述
3. 先出结构化大纲

输出要求：
1. 模块职责
2. 核心目录说明
3. 典型链路
4. 风险点
5. 开发注意事项

19. 常见误区

19.1 误区一：只写目标，不写约束

问题：

• 很容易超范围执行

19.2 误区二：只写约束，不写清目标

问题：

• Codex 不知道要达成什么结果

19.3 误区三：目标太大，当前步不收缩

问题：

• 一步到位很容易失控

19.4 误区四：约束写得太空

例如：

• "注意风险"
• "尽量别出错"

这类话几乎没有执行价值。

19.5 误区五：没有验证标准

问题：

• 很难判断结果是否真正完成

20. 注意事项

• 目标一定要具体
• 当前这一步尽量收缩
• 约束优先写最影响结果的部分
• 约束尽量可执行，不要空泛
• 高风险任务一定要显式写风险和边界
• 最后补上输出要求和验证标准

21. 高质量提示词模板

21.1 通用模板

请帮我处理一个任务。

目标：

当前这一步：

项目背景：

相关文件或模块：

约束：

风险提示：

输出要求：

验证标准：

21.2 Bug 模板

请帮我处理一个 bug。

目标：

当前这一步：

项目背景：

相关文件：

约束：

输出要求：
1. 先判断根因
2. 再给最小修复建议
3. 最后给验证步骤

验证标准：

21.3 功能开发模板

请帮我处理一个功能开发任务。

目标：

当前这一步：

项目背景：

相关模块：

约束：

输出要求：

验证标准：

22. 团队落地建议

如果你想把这套方法推广到团队里，建议这样做：

1. 固化一份"目标 + 约束"模板
2. 沉淀几个典型高质量示例
3. 把"先写目标、再写约束、再写验证标准"写进团队 AI 规范
4. 在 AGENTS.md 中加入 Prompt 书写要求

23. 一句话总结

Codex 的高质量 Prompt，不只是"说想做什么"，而是把目标、当前步、约束、风险、输出要求和验证标准一起说清楚。

24. 快速上手清单

• 先写最终目标
• 再写当前这一步
• 再补项目背景和相关文件
• 再写关键约束
• 再写输出要求
• 最后写验证标准