Back to Details

deep-work

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Deep Work

深度工作

Structured workflow that separates thinking from typing. Never write code until a written plan has been reviewed and approved.
一种将思考与编码分离的结构化工作流。在书面规划文档通过审核并获批前，绝对不要编写代码。

Workflow Overview

工作流概述

Research → Plan → Annotate (repeat 1-6x) → Todo List → Implement → Feedback
All artifacts persist as markdown files in 
.claude/
(not the project root).
研究 → 规划 → 批注（重复1-6次）→ 任务清单 → 实现 → 反馈
所有成果都将作为Markdown文件持久保存在
.claude/
目录下（而非项目根目录）。

Phase 1: Research

第一阶段：研究

Deeply read the relevant codebase before doing anything else. Write findings to 
.claude/research.md
.
How to research:
  1. Read every file in the target area — not just signatures, but implementations, edge cases, error handling
  2. Trace data flows end-to-end
  3. Identify existing patterns, conventions, utilities, and caching layers
  4. Note integration points with other parts of the system
  5. Write a detailed report to 
    .claude/research.md
Research depth signals: Read deeply. Understand intricacies. Go through everything. Surface-level reading is not acceptable. Continue until you have a thorough understanding.
Template: See references/research-template.md for the research document structure.
Critical rule: Stop after writing research.md. Do not proceed to planning until the user has reviewed the research and confirmed it's accurate.
在开展任何其他工作前，深入阅读相关代码库。将研究结果写入
.claude/research.md
。
研究方法：
  1. 阅读目标区域内的所有文件——不仅是签名，还包括实现逻辑、边缘情况和错误处理
  2. 端到端追踪数据流
  3. 识别现有模式、约定、工具函数和缓存层
  4. 记录与系统其他部分的集成点
  5. 将详细报告写入
    .claude/research.md
研究深度要求： 深入阅读，理解细节。全面梳理所有内容。浅层次阅读是不被允许的，直到你完全理解为止。
模板： 研究文档结构可参考references/research-template.md。
关键规则： 完成research.md后暂停。在用户审核并确认研究内容准确前，不要进入规划阶段。

Phase 2: Plan

第二阶段：规划

Write a detailed implementation plan to 
.claude/plan.md
. Base the plan on the actual codebase — read source files before suggesting changes.
Plan contents:
  • Explanation of the approach and rationale
  • Code snippets showing actual changes (not pseudocode)
  • File paths that will be modified or created
  • Considerations and trade-offs
  • Things explicitly not being changed and why
Template: See references/plan-template.md for the plan document structure.
Reference implementations: If the user provides reference code from other projects, study it and adapt the approach to fit the current codebase's patterns.
Critical rule: End the plan with "Ready for your review. Add inline notes directly to 
.claude/plan.md
and tell me when to address them." Do not implement.
编写详细的实现规划文档，保存至
.claude/plan.md
。规划需基于实际代码库——在建议变更前先阅读源码文件。
规划内容：
  • 实现方案说明及理由
  • 展示实际变更的代码片段（而非伪代码）
  • 将要修改或创建的文件路径
  • 考虑因素与权衡方案
  • 明确说明不做变更的内容及原因
模板： 规划文档结构可参考references/plan-template.md。
参考实现： 如果用户提供了其他项目的参考代码，需进行研究并调整方案以适配当前代码库的模式。
关键规则： 规划文档结尾需添加：“等待您的审核。请直接在
.claude/plan.md
中添加行内批注，告知我何时处理这些批注。” 不要开始实现。

Phase 3: Annotation Cycle

第三阶段：批注循环

The user adds inline notes directly into plan.md. When they say "address my notes" or similar:
  1. Read 
    .claude/plan.md
    thoroughly, finding all user annotations
  2. User annotations are any text that wasn't in your original plan — look for corrections, questions, overrides, and constraints
  3. Address every single annotation: update sections, remove rejected approaches, incorporate domain knowledge
  4. Remove the annotation text itself after addressing it (keep the plan clean)
  5. End with: "All notes addressed. Review again or say 'add the todo list' when satisfied."
Critical rule: Do not implement. The phrase "don't implement yet" is a hard constraint. Repeat the annotation cycle until the user explicitly approves.
用户直接在plan.md中添加行内批注。当用户说“处理我的批注”或类似表述时：
  1. 仔细阅读
    .claude/plan.md
    ，找出所有用户批注
  2. 用户批注指所有不属于你原始规划的文本——包括修正内容、问题、覆盖要求和约束条件
  3. 处理每一条批注：更新相关章节、移除被否决的方案、融入领域知识
  4. 处理完成后删除批注文本本身（保持规划文档整洁）
  5. 结尾添加：“所有批注已处理。请再次审核，或在满意后告知我‘添加任务清单’。”
关键规则： 不要开始实现。“先不要实现”是硬性约束。重复批注循环直到用户明确批准。

Phase 4: Todo List

第四阶段：任务清单

When the user approves the plan, add a granular task checklist to 
.claude/plan.md
:
markdown
undefined
当用户批准规划后，在
.claude/plan.md
中添加细化的任务检查清单：
markdown
undefined

Tasks

任务

Phase 1: [Phase Name]

第一阶段：[阶段名称]

  • Task 1 — specific, actionable description
  • Task 2 — specific, actionable description
  • 任务1 — 具体、可执行的描述
  • 任务2 — 具体、可执行的描述

Phase 2: [Phase Name]

第二阶段：[阶段名称]

  • Task 3 — specific, actionable description
  • Task 4 — specific, actionable description

Each task should be small enough to complete in one focused step. Include all phases needed to fully implement the plan.

**Critical rule:** Do not implement yet. Wait for user confirmation to begin.
  • 任务3 — 具体、可执行的描述
  • 任务4 — 具体、可执行的描述

每个任务应足够小，可在一个专注的工作步骤内完成。需包含完整实现规划所需的所有阶段。

**关键规则：** 先不要实现。等待用户确认后再开始。

Phase 5: Implementation

第五阶段：实现

When the user says "implement" or "go":
  1. Execute every task in the plan sequentially
  2. After completing each task, update 
    .claude/plan.md
    — change 
    - [ ]
    to 
    - [x]
  3. Do not stop until all tasks are completed
  4. Run the project's type checker / linter after each phase to catch issues early
  5. Do not add unnecessary comments, docstrings, or type workarounds (
    any
    , 
    unknown
    )
Code quality rules during implementation:
  • No unnecessary comments or jsdocs
  • No 
    any
    or 
    unknown
    types (TypeScript projects)
  • Run typecheck/lint continuously
  • Follow existing codebase patterns exactly
当用户说“实现”或“开始”时：
  1. 按顺序执行规划中的每一项任务
  2. 完成每个任务后，更新
    .claude/plan.md
    ——将
    - [ ]
    改为
    - [x]
  3. 直到所有任务完成后再停止
  4. 完成每个阶段后运行项目的类型检查器/代码检查工具，尽早发现问题
  5. 不要添加不必要的注释、文档字符串或类型变通方案（
    any
    、
    unknown
    ）
实现阶段的代码质量规则：
  • 不添加不必要的注释或jsdocs
  • 不使用
    any
    或
    unknown
    类型（TypeScript项目）
  • 持续运行类型检查/代码检查
  • 严格遵循现有代码库的模式

Phase 6: Feedback

第六阶段：反馈

During implementation, the user may provide terse corrections. These are sufficient because full context exists in the plan and session:
  • "You missed the dedup function" → implement what was missed
  • "Move this to the admin app" → relocate as directed
  • "Wider" / "2px gap" / "still cropped" → adjust and re-check
  • "Make it look like the users table" → read that reference, match it exactly
On reverts: If the user says "I reverted everything" — re-read the current file state, narrow scope to exactly what they specify, and re-implement cleanly.
在实现过程中，用户可能会给出简短的修正意见。由于规划文档和会话中已有完整上下文，这些意见已足够：
  • “你漏掉了去重函数” → 实现遗漏的部分
  • “把这个移到管理应用中” → 按要求迁移
  • “更宽” / “2px间距” / “仍然被截断” → 调整后重新检查
  • “让它看起来和用户表格一样” → 参考该表格，完全匹配其样式
关于回滚： 如果用户说“我回滚了所有内容”——重新读取当前文件状态，将范围缩小到用户指定的内容，然后重新干净地实现。

Prompt Reference

提示词参考

See references/prompts.md for ready-to-use prompts for each phase that the user can copy and adapt.
各阶段的即用型提示词可参考references/prompts.md，用户可直接复制并调整使用。