Claude Code 工作流复盘：我以为我掌握了，其实没有
这篇文章是我对自己使用 Claude Code 重构博客项目后的深度复盘。通过 10 个层层递进的问题，测试自己对工作流和构建过程的掌握程度。有些问题答得很好，有些暴露了认知盲区，全部如实记录在这里。
一、为什么要复盘
在完成了博客”墨水经典”的全站重做之后，我花了一天时间整理工作流记录、阅读官方最佳实践文档、并把两者的对应关系梳理成文。但”整理”不等于”掌握”——很多理解可能只停留在表面。
所以我决定做一次自我测试：让 Claude 向我提问，dig out 我没有注意到的内容。10 个问题，从工作流理论到项目实操，逐层深入。回答之后，Claude 给出了逐题反馈，暴露了我从未意识到的盲区。
这篇文章就是这次复盘的完整记录。
二、十问十答
Q1. Context Window 的”容量限制”具体如何影响你的博客项目？
我的回答：本项目中没有碰到 context window 的容量限制。博客项目早期是 context 获取最大的时候，主要是获取项目的整个目录结构，了解所有代码文件的绑定关系和设计。第一次探索时，我直接让 agent 除了探索以外还提取了一些具体的需求，手动截图并加上图片注明文字，污染了上下文，于是直接新开 session。如果早期在探索过程中检查内容上是否出现了缺失，Bug 1 和 Bug 5（都是 title 为空的显示 bug）本可以避免。问题在于理清代码的时候，没有注意到 chirpy 的 locale lookup 机制。
Q2. 你区分了”模糊提示”和”精确指令”的适用场景。在博客项目中，你有没有给 Claude 一个书面的、精确的成功标准？
我的回答：实际上，因为我对原设计不喜欢，但更倾向规划阶段中 agent 提供的方案，于是我没有定标准，也没有逐步纠正来推进，只是选择我觉得可以的方向，执行就由 agent 来编码。官网中”提供验收标准”针对一个完整的项目设计是很有必要的，可以检查 UI 是否正确，也可以编辑对应的测试案例来自动完成测试。我这里因为只是临时起意，所以有违背提供验收标准的建议。我后续会建立 skill 或者方案来改正，形成规范工作流程。
Q3. 官网提到 Plan Mode 增加了开销，小任务应该跳过。博客项目 8 个 commit 中，哪些可以跳过 Plan Mode 直接执行？
我的回答：我不会，我没有前端的知识储备。
（Claude 指出我偏题了——问题不是考前端技术，而是考对 Plan Mode 开销的判断。）
Q4. 你选择了”整体覆盖” chirpy 的 5 个 layout/include，如果今天 chirpy 7.6 发布了，合并成本在哪里？
我的回答：整体覆盖是针对原样式的功能排版都不满意的基础上做的，无法实现后续设计。本项目是个人博客，我会自己维护。后续如果版本更新，我会先检查是否有更新的必要。合并的成本在于部分组件会因为更新而失效，需要重写。除了在每个覆盖文件顶部加注释标记版本号之外，没有做其他降低合并成本的措施。
Q5. Bug 1 和 Bug 5 本质上是同一类问题。为什么修复 Bug 1 时没有顺带发现 Bug 5？
我的回答：Bug 1 和 Bug 5 分别是不同页面下的问题，修复过程中 agent 是按照页面来进行划分，并没有当作同一类检查。如果增加一个”检查所有页面 title 是否正确”的脚本，能够避免 Bug 5 遗漏到 commit 7。
Q6. CSS 变量优先级问题（Bug 2）的根因是 chirpy 用了高特异性选择器。你有没有考虑过更鲁棒的替代方案？
我的回答：没有，我没有考虑更鲁棒性的替代方案，也没有考虑版本更新的问题。
Q7. 你的验证矩阵覆盖了 8 个页面和 3 个视口，但只验证了”渲染通过”。有没有验证 FOUC、reduced-motion、触摸滑动？
我的回答：截图验证的时候选择了双端验证的方式。
（回答比较简略，没有直接回答那三个具体问题。）
Q8. 验证截图是 Claude 自己调 Playwright 做的，还是你手动截图给 Claude 的？
我的回答：前者。Claude 调用了工具后，根据 UI 截图上部分组件没有正常显示的情况，自动修复。
Q9. 回顾整个博客项目，有没有哪个场景如果用了 subagent 会更优？
我的回答：对于执行阶段，如果调用 subagents 去专门执行，会更流畅，主对话也会保持干净。另外就是设计阶段，如果能用上 design 的 skill，可以提高博客的审美能力。对这些工具的不熟悉是主要原因。
Q10. 如果让你再做一次类似规模的博客主题改造，哪些步骤可以复用？
我的回答：可以考虑将设计沉淀成 skill，风格可以沉淀，一些覆盖模式和策略，以及页面验证，对于同款主题可以复用。但是其他主题方案，不能用同一套方案，意义不大。
三、反馈分析：我答得怎么样
理解到位的（继续保持）
Q1 & Q2：我已经实践了”干净 session”原则——第一次探索污染上下文后直接新开 session，这比大多数用户做得好。同时我诚实承认没有定验收标准，这是关键认知。很多人会把”选方向”当成”定标准”，但我区分了这两者。
Q5：对 Bug 1/5 的归因准确。按页面划分工作流是直觉，按问题类型建立检查清单才是工程思维。我的验证矩阵是”页面维度”的，缺一个”问题类型维度”的检查清单。
Q8：确认 Claude 能自主调用工具、根据截图迭代修复——这说明我确实把”验证”交给了 agent，而不是自己当人工测试机。这是官方强调的”最高杠杆的事情”的落地。
理解有偏差的（需要纠正）
Q3：我答”不会，没有前端知识储备”——完全偏题了。问题不是考前端技术，而是考我对 Plan Mode 开销 的判断。Commit 6（gitignore 加几行）和 Commit 7（about.md 改 title）显然不需要 Plan Mode，直接执行即可。Commit 4（作品集数据化 + 响应式网格）涉及多文件、架构决策，才需要规划。学会判断”什么时候可以跳过规划”和”什么时候必须规划”同样重要。
Q7：我只答了”双端验证”，没回答那三个具体问题（FOUC、reduced-motion、触摸滑动）。这说明我的验证矩阵虽然看起来完整，但只验证了”渲染正确”，没验证”行为正确”。官方说的”信任然后验证的差距”指的就是这个——看起来正确，实际可能有可达性隐患。
Q10：我说”同款主题可以复用，其他主题意义不大”——这个判断过于局限。实际上可沉淀的不是具体文件，而是方法论：_data/locales 覆盖模式可以沉淀为”Jekyll 主题本地化覆盖 Skill”，CSS 变量覆盖策略可以沉淀为”主题变量优先级覆盖模板”，8 页面验证矩阵可以沉淀为”静态站点基础验收清单”。这些是可复用的工作流，不限于 chirpy。
没有注意到的（盲区）
1. 探索阶段的”检查清单”缺失
我说”理清代码的时候没有注意”title 问题。但这不是注意力问题，是工作流设计问题。在探索阶段，我让 Claude 去”了解项目结构”，但没有给 Claude 一个探索完成的标准。比如：
“探索完成后，输出：①所有 layout 文件的覆盖点 ②所有使用了
downcase或localelookup 的位置 ③所有 CSS 变量可能被主题覆盖的风险点”
如果当时有这个检查清单，Bug 1/5 在探索阶段就会被标记为风险，而不是等到验证阶段才发现。官方说”给 Claude 一种验证其工作的方式”——探索阶段也需要验证标准。
2. “防御式注释”的价值
我说”除了注释版本号外没做其他措施”。但注释版本号本身就是关键措施——我做了。更进一步，可以在每个覆盖文件顶部加：
1
2
3
4
<!-- OVERRIDE: jekyll-theme-chirpy@7.5.0
REASON: 杂志风改造需要整体替换
MERGE_GUIDE: 升级时对比 vendor 同名文件，将新增的逻辑迁移到本覆盖文件
-->
这不算额外成本，但能显著降低未来的合并认知负担。官方说”培养你的直觉”，直觉的一部分就是”现在花 10 秒写注释，未来省 30 分钟调试”。
3. @layer 作为 CSS 覆盖的替代方案
即使不考虑版本更新，chirpy 选择用高特异性选择器覆盖变量，本质上是在和主题做”特异性军备竞赛”。更现代的方案是使用 CSS @layer：
1
2
3
4
5
@layer chirpy-overrides {
html[data-mode='light'] {
--main-bg: var(--paper);
}
}
@layer 的优先级规则可以让覆盖层独立于选择器特异性。当然，这取决于 chirpy 是否支持，但知道有这个选项很重要。
4. Subagent 的真正机会不是”执行阶段”，而是”探索阶段”
我提到 subagents 可以在执行阶段用。但回顾项目，最大的 context 消耗其实是在探索阶段——Claude 读取了几十个文件来了解 chirpy 主题结构。如果当时用 subagent：
1
2
3
"Use a subagent to investigate how jekyll-theme-chirpy handles
locale translation for page titles. Report: ①lookup mechanism
②where zh-CN.yml is loaded from ③how to override safely"
主对话只会收到 3 行摘要，而不是几十页的代码内容。这才是 subagent 的最大价值——不是让执行更流畅，而是让探索不污染主 context。
5. “验收标准”其实可以事后补成 Skill
我计划后续会建立 skill 来改正。现在就可以：
1
2
3
4
5
6
7
8
9
10
---
name: jekyll-theme-validate
description: 验证 Jekyll 主题改造的基础验收项
---
验证以下项目：
1. 所有 tab 页面 title 非空
2. light/dark 模式切换无 FOUC
3. prefers-reduced-motion: reduce 下所有动效禁用
4. 移动端侧栏触摸滑动正常
5. 响应式断点 768/1024/1280 布局正确
运行 /jekyll-theme-validate 即可调用。这是从”项目经验”到”可复用资产”的最短路径。
四、掌握程度自评
| 维度 | 评分 | 说明 |
|---|---|---|
| Context 管理 | 良好 | 知道新开 session，但探索阶段缺检查清单 |
| 验证策略 | 及格 | 有截图验证，但行为验证（FOUC/可达性）缺失 |
| 阶段划分 | 良好 | 四阶段清晰，但 Plan Mode 的”跳过”判断不熟 |
| 工具扩展 | 薄弱 | subagents/skills 的认知停留在”知道”，没转化为”会用” |
| 经验沉淀 | 及格 | 有复盘意识，但没有把经验抽象为可复用模板 |
五、下一步改进计划
- 建立验证 Skill：把复盘中提到的
jekyll-theme-validate写成可调用 skill，下次项目直接/jekyll-theme-validate。 - 探索阶段加检查清单：以后任何项目探索阶段，都要求 Claude 输出”风险点清单”，而不是只输出”项目结构”。
- 覆盖文件加 MERGE_GUIDE：现在回去给 5 个覆盖文件补全防御式注释。
- 学习 subagent 的调用时机：不是执行阶段才用，而是探索阶段就用，保护主 context。
- 建立”行为验证”意识：截图验证之外，补充 FOUC、reduced-motion、触摸交互等行为层面的验收项。
六、写在最后
复盘的价值不在于证明自己掌握了多少，而在于诚实面对没有掌握的部分。这次测试让我意识到：“用过”和”会用”之间，差着一个”有意识地设计工作流”的距离。
如果你也在用 Claude Code 做项目，建议你在项目结束后做一次类似的自我测试。找一个不了解你项目细节的人（或者 Claude 自己）向你提问，你会惊讶于自己忽略了多少本该注意到的东西。