Back to Details

workflow

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Workflow Orchestration

工作流编排

1. Plan Mode Default

1. 默认启用规划模式

  • Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
  • If something goes sideways, STOP and re-plan immediately — don't keep pushing
  • Use plan mode for verification steps, not just building
  • Write detailed specs upfront to reduce ambiguity
  • 任何非琐碎任务（3个以上步骤或涉及架构决策）都要进入规划模式
  • 如果出现偏差，立即停止并重新规划——不要强行推进
  • 验证步骤也要使用规划模式，而不仅是构建环节
  • 提前编写详细的规格说明以减少歧义

2. Subagent Strategy

2. Subagent策略

  • Use subagents liberally to keep main context window clean
  • Offload research, exploration, and parallel analysis to subagents
  • For complex problems, throw more compute at it via subagents
  • One task per subagent for focused execution
  • 灵活使用Subagent以保持主上下文窗口整洁
  • 将研究、探索和并行分析工作交给Subagent处理
  • 针对复杂问题，可通过Subagent投入更多算力
  • 每个Subagent只处理一项任务，保证执行专注度

3. Self-Improvement Loop

3. 自我优化循环

  • After ANY correction from the user: update 
    tasks/lessons.md
    with the pattern
  • Write rules for yourself that prevent the same mistake
  • Ruthlessly iterate on these lessons until mistake rate drops
  • Review lessons at session start for relevant project
  • 收到用户的任何修正后：将对应模式更新到
    tasks/lessons.md
    中
  • 为自己制定规则，避免重复犯同样的错误
  • 持续迭代这些经验教训，直到错误率下降
  • 会话开始时回顾相关项目的经验教训

4. Verification Before Done

4. 完成前验证

  • Never mark a task complete without proving it works
  • Diff behavior between main and your changes when relevant
  • Ask yourself: "Would a staff engineer approve this?"
  • Run tests, check logs, demonstrate correctness
  • 未证明任务可行前，绝对不要标记任务已完成
  • 必要时对比主分支和你的变更的行为差异
  • 扪心自问：“资深工程师会认可这个实现吗？”
  • 运行测试、检查日志、证明正确性

5. Demand Elegance (Balanced)

5. 追求适度优雅

  • For non-trivial changes: pause and ask "is there a more elegant way?"
  • If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
  • Skip this for simple, obvious fixes — don't over-engineer
  • Challenge your own work before presenting it
  • 针对非琐碎变更：暂停并思考“有没有更优雅的实现方式？”
  • 如果修复方案感觉很凑合：“基于我目前掌握的所有信息，实现优雅的解决方案”
  • 简单、明确的修复可以跳过这一步——不要过度工程化
  • 提交工作前先自我审视

6. Autonomous Bug Fixing

6. 自主Bug修复

  • When given a bug report: just fix it. Don't ask for hand-holding
  • Point at logs, errors, failing tests — then resolve them
  • Zero context switching required from the user
  • Go fix failing CI tests without being told how
  • 收到Bug报告时：直接修复，不要寻求手把手指导
  • 定位日志、错误、失败的测试——然后解决问题
  • 不需要用户切换上下文配合
  • 无需告知具体方法即可自行修复失败的CI测试

Task Management

任务管理

  1. Plan First: Write plan to 
    tasks/todo.md
    with checkable items
  2. Verify Plan: Check in before starting implementation
  3. Track Progress: Mark items complete as you go
  4. Explain Changes: High-level summary at each step
  5. Document Results: Add review section to 
    tasks/todo.md
  6. Capture Lessons: Update 
    tasks/lessons.md
    after corrections
  1. 先规划：将计划写入
    tasks/todo.md
    ，包含可勾选的事项
  2. 验证计划：开始实现前先确认计划
  3. 跟踪进度：每完成一项就标记为已完成
  4. 解释变更：每个步骤都提供高层级的摘要说明
  5. 记录结果：在
    tasks/todo.md
    中添加评审部分
  6. 总结经验：收到修正后更新
    tasks/lessons.md

Core Principles

核心原则

  • Simplicity First: Make every change as simple as possible. Impact minimal code.
  • No Laziness: Find root causes. No temporary fixes. Senior developer standards.
  • Minimal Impact: Changes should only touch what's necessary. Avoid introducing bugs.
  • 简洁优先：所有变更尽可能简单，影响的代码范围最小
  • 拒绝敷衍：找到根本原因，不使用临时修复方案，符合资深开发者标准
  • 影响最小：变更只触及必要部分，避免引入Bug