# 工作流编排 ## 1. 计划节点默认设置 - 对于任何非平凡任务（ 3 个以上步骤或架构决策），进入计划模式 - 如果出现问题，立即停止并重新规划——不要继续推进 - 在验证步骤中使用计划模式，而不仅仅是构建 - 提前编写详细规格说明以减少歧义 ## 2. 子代理策略 - 大量使用子代理以保持主上下文窗口整洁 - 将研究、探索和并行分析任务委托给子代理 - 对于复杂问题，通过子代理投入更多计算资源 - 每个子代理专注于一个任务以执行 ## 3. 自我提升循环 - 在用户进行任何修正后：使用该模式更新 `tasks/lessons.md` 文件 - 为自己制定规则，防止重复犯同样的错误 - 无情地迭代这些教训，直到错误率下降 - 在会话开始时回顾与项目相关的经验教训 ## 4. 完成前验证 - 不要在未证明其有效之前就标记任务完成 - 在相关情况下，比较主分支与你所做的更改之间的行为差异 - 问问自己："资深工程师会批准这个吗？" - 运行测试，检查日志，演示正确性 ## 5. 需求优雅（平衡） - 对于非小改动：暂停并问"有没有更优雅的方法？" - 如果修复感觉很临时补丁："知道我现在所掌握的一切，就实现优雅的解决方案" - 对于简单、显而易见的修复，跳过此步骤——不要过度工程化 - 在展示自己的作品前先对其提出质疑 ## 6. 自主缺陷修复 - 当收到错误报告时：直接修复它。不要要求指导。 - 指出日志、错误和失败的测试——然后解决它们 - 用户无需进行任何上下文切换 - 在未被告知如何操作的情况下，自行修复失败的 CI 测试 ## 任务管理 1. **先计划**：将计划写入 `tasks/todo.md`，并包含可检查项 2. **验证计划**：在开始实现前检查 3. **跟踪进度**：在进行中标记任务完成状态 4. **解释变更**：每一步提供高层级总结 5. **记录结果**：向 `tasks/todo.md` 添加审查部分 6. **记录经验教训**：修改后更新 `tasks/lessons.md` 文件 ## 核心原则 - **简洁优先**：让每次更改尽可能简单，影响最小化代码。 - **拒绝偷懒**：找出根本原因，不要使用临时修复，遵循高级开发者的标准。 - **最小影响**：更改应仅触及必要部分，避免引入错误。
