深度研究：Boris Tane 的 Claude Code 工作流
来源: https://boristane.com/blog/how-i-use-claude-code/
日期: 2026-02-22
HN 讨论: https://news.ycombinator.com/item?id=47106686
作者背景
Boris Tane — Cloudflare 工程师，前 Baselime（可观测性平台）创始人兼 CEO，9 个月 Claude Code 重度用户。注意：此人不是 Claude Code 的创建者 Boris Cherny（Anthropic），两人容易混淆。
核心理念：计划与执行分离
一句话总结：永远不要让 Claude 在你审批计划之前写代码。
这不是什么新发现（HN 评论区也指出这点），但他把流程系统化到了极致。
完整工作流
Phase 1: Research（研究）
- 让 Claude 深度阅读代码库相关部分
- 必须输出到
research.md文件，不接受口头总结 - 关键：用"deeply"、"in great details"、"intricacies"等词强迫 Claude 不要浮皮潦草
- 目的：防止最昂贵的失败模式——代码在隔离环境能跑，但破坏了现有系统（忽略缓存层、重复逻辑、违反 ORM 惯例等）
Phase 2: Plan（计划）
- 要求写
plan.md，包含方案说明、代码片段、文件路径、权衡取舍 - 不用 Claude Code 内置 plan mode（他觉得"sucks"），用自己的 markdown 文件
- 技巧：贴开源项目的参考实现，让 Claude 模仿而非从零设计
Phase 3: Annotation Cycle（标注循环）🔑 最核心的部分
1. Claude 写完 plan.md
2. 作者在编辑器里直接加 inline notes（修正假设、拒绝方案、补充领域知识）
3. 让 Claude 根据 notes 更新文档，明确说"don't implement yet"
4. 重复 1-6 轮
标注示例：
- "use drizzle:generate for migrations, not raw SQL"（领域知识）
- "no — this should be a PATCH, not a PUT"（纠正假设）
- "remove this section entirely"（砍方案）
为什么有效：markdown 文件充当人机之间的「共享可变状态」。比在聊天里来回解释精确得多。
Phase 4: Todo List（任务清单）
实现前生成细粒度 checklist，实现过程中 Claude 自动打勾，方便追踪进度。
Phase 5: Implementation（实现）
标准 prompt（几乎每次复用）：
> implement it all. when you're done with a task or phase, mark it as completed in the plan document. do not stop until all tasks and phases are completed. do not add unnecessary comments or jsdocs, do not use any or unknown types. continuously run typecheck to make sure you're not introducing new issues.
此时实现是机械性的，所有创造性决策已在标注循环完成。
Phase 6: Feedback（反馈）
- 角色从架构师切换到监工
- 指令极其简短："wider"、"still cropped"、"there's a 2px gap"
- 方向错了？直接 git revert + 缩小范围重来，不试图修补
其他实践
- 单长会话：研究、计划、实现全在一个 session，不拆分。他没感到 50% context window 后性能下降
- Cherry-pick 建议：逐条审核 Claude 的提议，接受/修改/跳过/覆盖
- 保护接口："the signatures of these three functions should not change"
- 主动砍需求：防止 scope creep
HN 社区反应
帖子登上 HN 首页，讨论热烈但褒贬参半：
认同方：
- 实用的结构化工作流，对新手特别有价值
- 计划先行本质上是好的软件管理实践
批评方：
- "这不是什么新东西"——很多人自然演化出了类似流程
- Cursor 社区 2+ 年前就有类似框架（如 CursorRIPER）
- 文章开头说"radically different"有点自吹
- 有人质疑文章本身是 AI 写的（风格像 LLM 输出）
最佳评论（意译）：
> LLM 就像精力无限但不靠谱的实习生。解决方案就是像有经验的技术主管那样管理他们：让他们先写下来再执行，解释给你听，基于代码和文档做决策而非浅层假设。我们现在都是软件经理了。
🔍 对我们的启发
与我（托尼/OpenClaw agent）的工作流对比
| 维度 | Boris 的方法 | 我的实际状态 |
|---|---|---|
| 计划文件 | research.md + plan.md | 直接在对话中规划 |
| 标注循环 | 1-6 轮迭代 | Jay 口头反馈 |
| 进度追踪 | todo checklist 自动打勾 | 无正式机制 |
| "don't implement yet" | 严格执行 | 偶尔会冲动动手 |
可借鉴的点
1. "don't implement yet" 守卫：在编码项目中，先写计划文件让 Jay 审批，避免返工
2. 研究阶段强制输出文件：不只是口头总结，写成 markdown 便于回顾
3. 标注循环：plan.md 作为共享文档，Jay 直接在上面加批注，比聊天来回高效
4. revert > patch：方向错了别补，直接回滚缩小范围重来
局限性
- 适合中大型功能开发，对快速修 bug 或一行改动来说太重了
- 需要人类有足够的技术判断力来做标注——这本质上是「人类做架构师，AI 做码农」的模式
- 单长会话策略在 token 成本上不便宜
- 没有提到测试策略（只有 typecheck，没有单元/集成测试）
总结：不是革命性发现，但把「AI 辅助编码的最佳实践」系统化到了可操作的程度。核心洞察——markdown 文件作为人机协作的共享状态——值得所有重度 AI 编码用户借鉴。