需要完整说明和更多案例？ 可继续阅读详细版。
一、提需求
- 写清目标和完成标准：说明要解决什么问题，以及达到什么结果才算完成。
- 给出问题入口和必要上下文：提供相关接口、文件、日志、报错或复现步骤。
- 不明确的业务规则先确认：让Codex复述需求并列出假设和待确认点，不要自行决定。
二、分析与执行
- 简单任务直接执行，复杂任务先分析：跨服务、资金或数据类改动先确认方案和影响范围。
- 按可验收结果拆分任务：一个任务完成一个可以独立验证的业务结果，不要机械地按服务拆分。
- 控制改动范围：只修改与当前需求相关的内容，不混入顺手重构或依赖升级。
三、检查与验证
- 合并前检查diff：确认改动点、Bug、风险和无关修改，必要时新建独立审查任务。
- 检查上下游和异常路径：关注调用方、消费者、兼容性、并发、幂等、事务和重试。
- 用实际结果验证：运行相关测试和命令，高风险改动再做一次独立复查。
四、规则沉淀
- 长期项目规则写进
AGENTS.md：记录项目结构、禁止事项、常用命令和稳定约束。 - 重复且稳定的流程封装成Skill：把固定步骤、模板和专项工作沉淀为可复用能力。
- 必须执行的规则交给自动化：使用测试、脚本或CI强制检查，临时要求留在当前任务中。
