Appearance
把“帮我修一下”写成能验收的任务
同样是修 Bug，“帮我优化一下”与“修复优惠后金额为负的问题，不改测试，修完重新运行测试”给出的方向很不一样。
不必堆角色设定。把目标、相关文件、修改范围和完成条件说清楚，Codex 才有依据开展工作，你也更容易检查结果。
先看同一个任务的两种写法
原始请求：
text
帮我优化一下购物车，修复里面的问题。问题在于“优化”和“问题”没有定义。模型不知道你在意速度、界面还是计算规则。对本站负金额练习，可以改为：
text
请读取 TASK.md 和购物车源码，先运行 node --test cart.test.mjs 复现问题。
解释失败原因，仅修改 cart.mjs 修复优惠导致负金额的问题，不修改测试。
重新运行全部测试，输出实际测试结果、修复 diff 和没有覆盖的边界。第一句给依据和复现方法；第二句限制修改面；第三句要求交付可检查的结果。你不必照搬措辞，但不要漏掉真实文件和完成条件。
为什么第二种更容易检查
不是因为它更长，而是补上了四个关键空白。官方 Best practices 推荐 Goal、Context、Constraints、Done when，对应到这里就是：
| 要素 | 模糊请求漏掉的事 | 改写后说清了什么 |
|---|---|---|
| 目标 | “优化”到底改变什么？ | 修复优惠造成的负金额 |
| 上下文 | 到哪里找问题？ | 读 TASK.md 与源码，运行给定测试 |
| 约束 | 能不能改测试凑答案？ | 只修改 cart.mjs，不改测试 |
| 完成条件 | 什么叫修好了？ | 实际测试结果、修复 diff、未覆盖边界 |
小任务一句话说清也可以；不需要为了凑四栏写成长文。重要的是，这些信息必须来自你的真实任务。
不知道原因，也能提出好任务
不要先把猜测写成事实。例如“肯定是缓存坏了，重写缓存”会过早限制排查方向。可以改成：
text
现象：点击保存后显示成功，刷新页面却恢复旧值。
复现步骤和相关文件如下……
请先定位原因，区分已验证事实与假设，再提出最小修改方案。
未确认原因前不要替换存储方案，也不要发布到生产环境。把示例中的现象换成自己的复现步骤和文件路径。暂时不知道的条件可以留给 Codex 调查，不必先猜一个原因。
复杂任务先定方案，小任务别过度管理
涉及数据库迁移、多模块重构或外部系统写入时，先要求调查与计划，等确认范围再实施。单个拼写修改不必强迫它先写长篇规划。
你也不需要提前规定每一个搜索命令。给目标和边界，保留执行者发现相关文件的空间；对必须按顺序执行的验收步骤则明确要求。
如何追问，才不会越改越乱
- 范围太大：“只保留与负金额有关的修改，其余改动先说明，不要继续扩展。”
- 没有运行：“列出实际执行过的命令和结果；没执行的请标为未验证。”
- 偷改本题测试：“恢复题目提供的固定测试，在不修改测试的条件下修复源码。”真实项目需要补充或更新测试时，应先说明业务依据，不是永远禁止改测试。
- 解释与代码不一致：“指出结论对应的具体文件；找不到依据就更正。”
复制这份模板，换成你的任务
text
目标：我希望完成……
上下文：请先阅读……；目前的现象是……
范围：允许修改……；不要改动……
完成条件：运行……；检查……；最后说明修改文件和结果。例如，写给网站表单的任务可以是：
text
目标：空表单提交时，在必填项旁显示错误，不进入成功页。
上下文：先查找报名页、提交处理逻辑与相关测试。
范围：只处理必填校验，不改页面布局，不发送真实报名数据。
完成条件：检查空提交、合法输入两条路径；运行相关测试。
最后给出改动文件、实际检查结果和仍需人工检查的部分。这里不知道文件名，就让 Codex 先找；但“什么不能发生”和“怎么检查”仍然明确。把模糊的“更专业”改成可观察的行为，你才有办法判断结果。
跨任务重复的测试命令和代码约定可以放进 AGENTS.md；本次要解决的业务问题留在对话里。