高质量任务说明与提示词

Codex 的输出质量很大程度取决于任务边界。好的任务说明不是长，而是清楚。

基础结构

一个稳定的任务说明通常包含：

• 背景：这个项目、模块或 bug 是什么。
• 目标：希望完成的具体结果。
• 范围：哪些文件或行为可以改，哪些不要动。
• 约束：风格、兼容性、性能、安全、依赖限制。
• 验证：要运行哪些测试、命令或手动检查。
• 交付：最后需要总结哪些信息。

通用模板

请处理：[一句话目标]

背景：
- [项目或模块背景]
- [当前问题或期望行为]

范围：
- 可以修改：[文件/目录/模块]
- 不要修改：[明确排除项]

要求：
1. 先阅读相关代码再动手。
2. 保持现有代码风格。
3. 不做无关重构。
4. 修改后运行：[验证命令]
5. 最后说明改动、验证结果和剩余风险。

让 Codex 更可靠的说法

优先说：

• “修改最少必要文件。”
• “先给我确认你找到的入口点，再实现。”
• “如果测试失败，继续定位并修复，直到相关测试通过或明确说明阻塞原因。”
• “不要引入新依赖，除非现有实现无法满足，并说明理由。”
• “保持公开 API 兼容。”

少说：

• “帮我优化一下。”
• “把项目做得更好。”
• “顺便重构。”
• “你看着办。”

“你看着办”很省字，也很容易把范围交给命运。

大任务拆法

把大任务拆成三层：

• 探索：让 Codex 只读代码、画出影响面。
• 计划：让它提出分步方案和验证方式。
• 实施：一次只做一个可验证切片。

示例：

请先不要改代码。阅读认证模块、路由和测试，找出把登录页改成双因素登录会影响哪些文件。请输出实施步骤、风险和建议的第一步最小改动。