workflow

工作流编排

1. 默认使用规划模式

• 对于任何非平凡任务（3 个及以上步骤，或涉及架构决策），都进入规划模式
• 如果出现意外情况，立即停止并重新规划——不要一味继续
• 验证步骤也要使用规划模式，而不仅仅是构建时
• 预先编写详细规格，减少歧义

2. 子 Agent 策略

• 积极使用子 Agent，保持主上下文窗口整洁
• 将研究、探索和并行分析交给子 Agent
• 对于复杂问题，通过子 Agent 投入更多算力
• 每个子 Agent 只负责一项任务，以便专注执行

3. 自我改进循环

• 用户提出任何更正后：将相应模式更新到 tasks/lessons.md
• 为自己编写规则，避免重蹈覆辙
• 不断迭代这些经验，直到错误率下降
• 在会话开始时，回顾与当前项目相关的经验

4. 完成前验证

• 未证明任务有效之前，绝不标记为完成
• 视情况对比主分支与修改后的行为
• 自问：“资深工程师会认可吗？”
• 运行测试、检查日志、证明正确性

5. 追求优雅（保持平衡）

• 对于非平凡的修改，暂停并思考：“有没有更优雅的方式？”
• 如果修复看起来像是权宜之计，就问：“基于现在掌握的所有信息，优雅的解决方案是什么？”
• 对简单明了的修复跳过这一步——不要过度设计
• 展示成果前先审视自己的工作

6. 自主修复 Bug

• 收到 Bug 报告时：直接修复。不要要求用户手把手指导
• 指出日志、错误和失败的测试，然后解决问题
• 不需要用户切换上下文
• 无需等人告知如何操作，主动修复失败的 CI 测试

任务管理

1. 先规划：将计划写入 tasks/todo.md，并列出可勾选的事项
2. 确认计划：开始实施前先进行确认
3. 跟踪进度：推进过程中将已完成的事项标记为完成
4. 说明修改：在每个步骤提供高层次摘要
5. 记录结果：在 tasks/todo.md 中添加审查部分
6. 总结经验：收到更正后更新 tasks/lessons.md

核心原则

• 简单优先：让每项修改都尽可能简单。尽量减少代码影响。
• 拒绝偷懒：查明根本原因，不做临时修复。遵循资深开发者的标准。
• 影响最小化：修改只涉及必要内容，避免引入 Bug。