Back to Details

deep-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Deep Plan

深度规划（Deep Plan）

Systematic approach for gathering requirements and clarifying decisions before implementation.
系统地收集需求并在实施前明确决策的方法。

When to Activate

激活场景

  • User is in PLANNING mode
  • User explicitly asks to "plan", "discuss", "let's think through", "review approach", "before we start", "what do you think about"
  • Agent identifies choices between 2+ valid approaches
  • Agent lacks context needed for confident decision-making
  • 用户处于PLANNING模式
  • 用户明确提出“规划”“讨论”“我们梳理一下”“评审方案”“开始前”“你对...有什么看法”等需求
  • Agent识别到存在2种及以上有效方案可供选择
  • Agent缺乏做出自信决策所需的上下文信息

When NOT to Activate

非激活场景

  • Fixing obvious bugs/typos (clear single correct solution)
  • User explicitly says "do as you see fit" or similar
  • Trivial changes with single logical approach
  • User already provided specific requirements
  • 修复明显的bug/typos（存在明确的单一正确解决方案）
  • 用户明确表示“按你认为合适的方式做”或类似表述
  • 只有单一逻辑方案的微小变更
  • 用户已提供具体的需求

Clarification Process

澄清流程

1. Context Questions First

1. 先询问上下文相关问题

Before technical decisions, understand the project context:
  • Timeline/deadline constraints?
  • Team size and experience level?
  • Existing tech stack or constraints?
  • Scale expectations?
These answers inform all subsequent recommendations.
在做出技术决策前，先了解项目上下文：
  • 是否有时间线/截止日期限制？
  • 团队规模和成员经验水平如何？
  • 现有技术栈或约束条件有哪些？
  • 预期的业务规模是多少？
这些答案将为后续所有建议提供依据。

2. Identify Decision Points

2. 识别决策点

Scan the task and categorize decisions by priority:
  • 🔴 Blocking — cannot proceed without answer
  • 🟡 Important — affects outcome, but has reasonable default
  • 🟢 Nice-to-know — can decide later
Types of decisions:
  • Technical choices: libraries, tools, patterns, algorithms
  • Architecture decisions: structure, component breakdown, data flow
  • Scope boundaries: what's included vs excluded
  • Priority conflicts: what to implement first
  • Missing context: unclear requirements, ambiguous terminology
梳理任务并按优先级对决策进行分类：
  • 🔴 阻塞性 — 没有答案无法继续推进
  • 🟡 重要性 — 影响结果，但存在合理的默认方案
  • 🟢 锦上添花 — 可稍后再做决定
决策类型：
  • 技术选择：库、工具、模式、算法
  • 架构决策：结构、组件拆分、数据流
  • 范围边界：包含与排除的内容
  • 优先级冲突：优先实现哪些内容
  • 缺失上下文：模糊的需求、歧义术语

3. Progressive Questioning

3. 渐进式提问

Ask questions in phases, starting with most critical:
Phase 1: Context questions + 🔴 Blocking questions (max 5-7 per message) Phase 2: After blocking resolved, ask 🟡 Important questions Phase 3: Ask 🟢 Nice-to-know only when relevant phase begins
Do NOT dump all questions at once. Batch by priority and wait for responses.
分阶段提出问题，从最关键的开始：
阶段1：上下文问题 + 🔴 阻塞性问题（每条消息最多5-7个） 阶段2：阻塞性问题解决后，提出🟡 重要性问题 阶段3：仅在相关阶段开始时提出🟢 锦上添花类问题
请勿一次性抛出所有问题。按优先级分批提问并等待回复。

4. Question Format with Confidence

4. 带置信度的提问格式

Group questions by category, indicate recommendation confidence:
markdown
undefined
按类别分组问题，并标明建议的置信度：
markdown
undefined

[Category] Decisions

[Category] Decisions

  1. [Brief description] 🔴
    • Option A: [description] — strongly recommend because [reason]
    • Option B: [description] — better for [use case]
  2. [Another question] 🟡
    • Option A: [description] — lean towards this
    • Option B: [description] — no strong preference, depends on [factor]

Confidence levels:
- **strongly recommend** — almost always the right choice
- **lean towards** — good option, but context-dependent
- **no strong preference** — both options are equally valid
  1. [Brief description] 🔴
    • Option A: [description] — strongly recommend because [reason]
    • Option B: [description] — better for [use case]
  2. [Another question] 🟡
    • Option A: [description] — lean towards this
    • Option B: [description] — no strong preference, depends on [factor]

置信度等级：
- **strongly recommend** — 几乎总是正确的选择
- **lean towards** — 不错的选项，但取决于上下文
- **no strong preference** — 两个选项同样有效

5. Handle Unanswered Questions

5. 处理未答复的问题

If user does not answer some questions:
  • Do NOT assume defaults silently
  • Explicitly ask: "For questions X and Y, should I proceed with my recommendations, or do you have other preferences?"
  • Wait for explicit confirmation before proceeding
如果用户未答复部分问题：
  • 请勿默默采用默认方案
  • 明确询问：“对于问题X和Y，我是否应该按照我的建议推进，还是你有其他偏好？”
  • 获得明确确认后再继续推进

6. Mid-Execution Re-check

6. 执行中期重新检查

If during implementation agent discovers:
  • New ambiguity not covered by initial planning
  • A decision that has multiple valid approaches
  • Context that contradicts earlier assumptions
→ STOP and return to clarification mode. Do not make assumptions.
如果在实施过程中Agent发现：
  • 初始规划未覆盖的新歧义
  • 存在多种有效方案的决策
  • 与先前假设矛盾的上下文
→ 停止并返回澄清模式。请勿自行假设。

7. Decision Summary (Optional)

7. 决策总结（可选）

After all questions resolved, offer to create a decision log:
  • "Would you like me to save these decisions to the implementation plan for reference?"
  • Only create if user agrees
  • Do NOT create files by default
所有问题解决后，可主动提出创建决策日志：
  • “是否需要我将这些决策保存到实施计划中以供参考？”
  • 仅在用户同意时创建
  • 默认情况下请勿创建文件

Key Principles

核心原则

  1. Context before details — understand the big picture first
  2. Ask first, implement after — when in doubt, ask
  3. Progressive disclosure — blocking → important → nice-to-know
  4. Explicit consent — never assume silence means agreement
  5. Stay focused — max 5-7 questions per message
  6. Re-check when uncertain — new ambiguity = new questions
  1. 先上下文后细节 — 先了解整体情况
  2. 先询问后实施 — 存疑时先提问
  3. 渐进式披露 — 阻塞性→重要性→锦上添花
  4. 明确同意 — 永远不要假设沉默代表同意
  5. 保持聚焦 — 每条消息最多5-7个问题
  6. 不确定时重新检查 — 新歧义=新问题