Codex 提示词怎么写？任务说明、约束与验收标准模板

一份任务说明需要回答六个问题

先写最终要达到的结果，再补充为什么要做、相关代码在哪里、允许修改什么、不能破坏什么，以及如何判断完成。信息不必很长，但应该让另一个没有参与讨论的开发者也能照着执行。

• 目标：用户或系统最终获得什么能力
• 背景：当前行为、错误和业务原因
• 范围：相关目录、模块与接口
• 约束：兼容性、安全和禁止修改项
• 验收：可以逐条检查的结果
• 验证：测试、构建与人工检查命令

功能开发任务模板

功能任务应避免只列页面元素。先说明核心用户流程，再写异常状态、移动端表现和兼容要求。验收标准使用勾选项表达，例如‘未登录用户会跳转到登录页’、‘重复提交不会产生两条订单’。

让 Codex 在开始前先定位已有实现和可复用组件，完成后报告修改文件、运行命令与测试结果。这样输出更适合进入团队代码审查。

Bug 修复任务模板

修复任务最重要的是复现路径和期望结果。给出最短复现步骤、关键日志、影响环境和首次出现版本，并要求先定位根因，再进行最小修复。不要用吞掉异常、删除校验或扩大重试次数来掩盖根因。

• 先写一个能稳定失败的回归测试
• 区分根因、触发条件和表面症状
• 限制修改范围，避免顺手重构
• 修复后重复原步骤并运行相邻流程测试

代码审查任务模板

代码审查要写清比较基线，例如未提交改动、指定提交或当前分支相对 main 的差异。要求按正确性、安全、数据一致性、性能和测试覆盖排序，每个问题包含文件位置、触发条件、影响和修复建议。

在线任务说明生成器可以快速生成 Markdown 初稿，再按仓库实际路径和命令补充细节。模板负责避免遗漏，真实项目上下文仍需要开发者提供。