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