真实工程工作流

Codex 最有价值的地方，不是替你打几个命令，而是把“读代码、改代码、跑验证、解释风险”串成一个循环。

修 bug

推荐流程：

1. 复现问题。
2. 锁定相关测试或日志。
3. 阅读最小相关代码。
4. 做最小修复。
5. 跑相关测试。
6. 总结根因和验证结果。

任务模板：

请修复这个 bug：[描述现象]

已知信息：
- 复现步骤：[步骤]
- 期望结果：[结果]
- 实际结果：[结果]

要求：
1. 先复现或定位失败点。
2. 找到根因后再修改。
3. 保持改动最小。
4. 添加或更新必要测试。
5. 运行相关测试并总结结果。

补测试

让 Codex 补测试时，关键是说明你想覆盖什么行为，而不是只说“提高覆盖率”。

请为 [模块/函数] 补充测试，覆盖：
- 正常路径：[行为]
- 边界情况：[行为]
- 错误输入：[行为]

不要改生产代码，除非发现当前代码无法测试，并先说明原因。

重构

重构任务要先切小。更稳的方式是让 Codex 先做分析：

请阅读 [目录/模块]，找出可以降低复杂度的重构点。先不要修改代码。请按收益、风险和验证成本排序，并推荐第一步最小重构。

确认第一步后再实施：

请只执行你刚才建议的第一步重构。保持行为不变，运行现有测试，并说明如何确认没有改变外部行为。

代码审查

Codex 做代码审查时，要让它像 reviewer，而不是像改代码的人。

请审查当前 diff。重点关注：
- 行为回归
- 安全风险
- 并发或状态问题
- 缺失测试
- 命名和可维护性

请按严重程度列出问题，引用文件和行号。不要直接修改代码。

文档生成

适合让 Codex 生成的文档：

• 新模块 README。
• API 使用示例。
• 迁移指南。
• 排障说明。
• 代码注释补充。

注意：生成文档前最好让它先读真实代码和测试，避免写出“看起来很对”的幻觉文档。