工作流编排思路

类比：工作流像厨房

你走进一个专业厨房。墙上挂着刀，炉子上有炒锅，台面上有搅拌机，水池边有漏勺。你不会用搅拌机煎鸡蛋，也不会用漏勺切菜。每样工具都有它该干的活，也都有它干不了的活。

AI 编程也是一样。你会攒一堆工具：Claude Code 负责对话和代码生成，Skill 负责把重复任务标准化，Memory 负责跨会话记忆，git 负责版本控制，pre-commit hook 负责自动检查。工作流就是把它们按正确的顺序串起来，让你知道每件事该用哪个工具。

更重要的是，工作流帮你解决一个新问题：当你有五六个 AI 工具可用时，每次打开终端会面临一个“决策瘫痪”局面——从哪开始？该先用哪个？工作流就是把“每次都要想一遍怎么走”变成“看流程图直接走”，决策成本趋近于零。

教学模式 vs 实施模式（最核心的一段）

这是 Jason 工作流里最独特的模式——很少有教程单独讲这个环节。它的产生原因很简单：同一个 Claude，面对“教我这个概念”和“帮我修这个 bug”两个完全不同的任务时，如果用一种风格去应答，用户一定会被逼疯。

想象你请了一个家教，他的唯一教学模式是：讲 30 秒，等你消化，问你一个问题，再讲 30 秒。这在讲“因式分解”时很完美。但如果他对你说“冰箱漏水了，我教你修”，你也希望他 30 秒、30 秒地讲吗？不，你希望他直接修好，中间不要停下来问“螺丝刀分一字和十字，你选哪种？”。

反过来也一样：你请了一个很能干的维修工，你跟他说“我想学修水管”，他却二话不说拿起扳手就干完了，你站在旁边什么都没学到。

Claude Code 面对的就是这两种场景的矛盾。 如果没有显式的模式切换，Claude 只会在中间找一个“安全中性”的节奏——教学时讲太快，实施时拖太久。

教学模式

触发信号：用户说“教我这个”“解释一下”“为什么这样写”“带我学”。

行为规则：小段讲解 + 即时一问 + 等用户回答。每轮只讲一个概念，讲完立刻提一个检查理解的小问题，等用户答完再继续。绝对禁止一次性丢多道题——这会像家教一口气讲了三个证明题然后问“都懂了吗”，学生什么都不敢说只能点头。

这个模式的 CLAUDE.md 规则长这样（出自 Jason 的全局 CLAUDE.md）：

教学节奏：学习类任务默认"小段讲解+即时一问+等回答"，禁一次性丢多题

出处是一次真实的用户反馈。Jason 在一次 Hook 功能的学习（在他参与的 OpenClaw 项目中）时对 Claude 说：“用带我学习然后提问的方式，而不是现在这种直接出题目”。这句话变成了全局规则，对所有项目的学习类任务生效。

实施模式

触发信号：用户说“build this”“fix this”“implement this”，或者已经批准了一个 plan / task list。

行为规则：连续推进到完成，每个里程碑不要停下来问“继续吗”。task list 里的任务做完一个自动开始下一个，除非遇到真正的阻塞点（依赖缺失、信息不足、需要用户决策）。

这个模式的 CLAUDE.md 规则长这样（出自 Jason 的全局 CLAUDE.md）：

实施类自驱推进：plan/task list 已批准的实施任务必须连续推进到完成，
不要每个 milestone 停下来问"继续吗"

为什么这两种模式必须分开

因为混淆它们的用户体验极其糟糕：

• 教学模式用于实施：你急着修 bug，Claude 在那“我们先理解一下这段代码的设计思路，你看这里用了什么设计模式？”——你会想砸电脑。
• 实施模式用于教学：你想学一个新概念，Claude 连续写了 200 行代码和 5 段解释一起丢给你——你被淹没了，什么都没学会。

这是一个所有 Claude Code 用户都会踩的坑。大多数人不自觉地学会了“教的时候自己主动停下来问，干的时候让 Claude 别停”，但从来没把这些规则显式写进 CLAUDE.md。显式写进去的好处是：换一个会话、换一个项目，Claude 不需要你重新教它“这次我是学还是做”，CLAUDE.md 里已经有分叉逻辑。

实现上不需要复杂的 if-else

不是要你写一个复杂的模式检测规则引擎。只需要两条互斥的规则同时存在于 CLAUDE.md 里，每条带上触发条件。Claude 读到时会自己判断当前对话属于哪种模式。

关键是：两条规则都要写，缺一条就有一类场景会翻车。只写了教学模式，Claude 会在所有任务里停下来提问；只写了实施模式，Claude 会在学习时变成信息轰炸机。

Explore → Plan → Implement → Verify → Learn 循环

很多新手对 AI 编程的想象是：说需求 → 得代码 → 完成。三个步骤，一步到底。这个想象的问题在于：你省略了最关键的两步——检查代码对不对、记下学到了什么。

完整的工作流应该是五步循环：

1. Explore（探索，理解现状）

写代码之前，先理解现在有什么。如果是在已有项目中加功能，这一步需要：

• 读相关文件的结构（目录、关键函数、数据流）
• 理解为什么代码写成现在这样（已有的设计决策）
• 确认改动范围和影响面

跳过这一步直接写代码，常见结果是：改了一个文件发现牵连了另外三个文件，推倒重来。探索的时间几乎永远值得——10 分钟的阅读能省 1 小时的返工。

2. Plan（出计划，拿到批准）

对于多文件修改或架构级改动，先写一个简短的执行计划：

• 改哪些文件
• 每个文件改什么
• 分几步执行

然后停下来等用户确认。这一步的好处不是“表现乖巧”，而是防止迷失方向。当 Claude 用几分钟写完计划呈给你，你可以一眼看出“这个方向不对”然后纠正，而不是等几小时后发现全废了。

Jason 的 CLAUDE.md 里对应的规则：

多文件改动 / 架构级重构 -> 必须先 EnterPlanMode

对于简单任务（单文件小改动），这一步可以跳过——不需要为修一个 typo 写计划。判断标准：如果改动在 3 个文件以内且你脑子里的方案已经很清晰，可以直接实施。

3. Implement（按计划执行）

有了批准的计划后，一个 task 一个 task 地执行。task list 的好处是：

• 每一步做完都有明确的“完成”标志（任务状态改为 completed）
• 中间被打断（接电话、下班、吃饭），回来只要看 task list 就知道做到哪了
• 做错了不需要全部推倒，只需要把当前 task 和后续受影响的 task 重做

实施阶段遵循“实施模式”：不每步停下来问，自动推进到完成。

4. Verify（验证，不止是看代码）

拿到代码后，验证才是真正的“做完”。新手常犯的错误是：代码写出来了，看了几眼觉得对，就算 done 了。验证需要跑实际的东西：

• 跑测试（如果有的话）
• 跑 npm run build（确认能编译）
• 用 diff 看实际改了什么（和你的计划一致吗？）
• 在浏览器里实际操作一遍（别只看代码）

验证的核心原则：让计算机验证，不要用眼睛验证。眼睛会漏东西，计算机会老老实实告诉你编译不过、测试失败、拼写错误。更多验证方法论见 验证方法论。

5. Learn（提炼，让这次不再白做）

这是最容易被跳过但回报最高的一步。做完一个任务后问自己：

• 这次学到了什么新概念/技术/模式？（写进 learnings/）
• 犯了一个什么错误？怎么防止下次再犯？（加一条 CLAUDE.md 规则）
• 这个过程对下次做类似任务有什么借鉴？（写进 Memory）

如果做完任务直接跳到下一个任务，你只是交付了一个结果。如果你提炼了一条经验写进系统，你是在为未来所有类似任务提速。一次提炼投资 5 分钟，后续每次省 30 分钟，复利惊人。实际项目案例见实习日志项目。

五步循环的实际例子

假设你要在一个项目中加一个“批量删除”功能：

1. Explore：读现有删除逻辑，发现它是单条删除，没有确认弹窗，直接在 API 层处理。
2. Plan：方案——前端加多选 checkbox + 确认弹窗，后端改 API 接受 id 数组。分 3 个 task：前端 UI、API 改造、集成测试。
3. Implement：按 task list 逐个执行，做完一个标记 completed。
4. Verify：跑 npm run build 确认编译通过，手动在浏览器里勾选 3 个项目点删除，确认弹窗出现，确认删除后列表刷新。
5. Learn：学到了批量操作的前后端协作模式。在 CLAUDE.md 加一条规则：“批量操作必须先弹确认，不能直接执行”。在 learnings/ 写一篇笔记记录这个 pattern。

小 diff 纪律：一次只改 200 行

无论多复杂的任务，每次变更控制在 200 行以内。这不是硬性技术限制——是 Claude Code 的工作特性决定的：

• Claude 理解小变更的准确度远高于大变更（经验上显著更高）
• 超过 200 行的 diff 很难逐行审计（你会跳过细节）
• 如果任务需要 >200 行改动，拆成多个子任务——每个子任务独立验证

Jason 的 commit skill 强制了“原子化提交”：一个 commit 只做一件事。这不是洁癖——这是验证的前提。如果一次提交改了 5 个不相关的文件，你根本说不清哪里改错了。

类比：搬家时一次打包一个房间。而不是把所有东西扔进一个箱子——等到了新家打开，你找不到任何东西。

Skill + Hook + Memory 三角

三个机制单独看都很有用，但它们的真正力量来自协同——缺一角的三角形站不稳。

Skill：重复任务自动化

Skill 是 Claude Code 的工作流模板。它的本质是：把“每次都要手动一步步告诉 Claude 怎么做”的重复任务，变成一个可复用的、一句话触发的流程。

Jason 的 intern-journal 里有十余个 Skill，下面列出常用的 7 个（完整列表见 CLAUDE.md 或 AGENTS.md）：

Skill	一句话作用
/commit	分析 git 变更，按主题分组，原子化提交
/daily-learn	读今日对话记录，补 daily 文件的“今日学到”段
/wiki	检查知识库健康、消化新来源、发现矛盾
/learn	学习导航——根据现状推荐下一步学什么
/source-learn	从开源项目源码中系统学习
/sync-all	一键刷新所有派生文件和 HTML 渲染
/dotfiles	备份/恢复/同步 Claude Code 配置

Skill 解决的问题是“决策成本”。没有 Skill 时，每次要做上述事情，你都要在脑子里回忆步骤、打出具体指令、确认参数。有 Skill 后，说一句 /commit，Claude 就知道整个流程。决策成本从“想 30 秒+打 50 字”降到“打 7 个字符”。

Hook：自动防止错误

Hook 是 “不许做的事情” 的自动执行。它在 Claude 的某些行为发生前/后自动插入检查，拦截已知错误模式。

Jason 的项目里有多个 pre-commit hook：

• learnings/*.md 必须有 来源: 字段
• sources/*.md 必须有 状态: 字段
• 所有 .md 内部链接必须能解析（无死链）

这三条规则如果靠人检查，每 10 次 commit 至少漏 1 次。Hook 让它们变成自动门禁——不满足条件就拒绝 commit。人不用担心忘记检查，Claude 不用担心漏掉规则。

Memory：跨会话持久化

Memory 解决“新会话 Claude 失忆”的问题。它的设计原则和三层稀疏结构详见 记忆系统设计原则，这里不重复。从工作流角度看，Memory 的角色是：让错误只需要犯一次。

每次踩坑 → 写一条 Memory → 未来所有会话都能读到 → 永远不会再踩同一个坑。

三角形的协作

单独看：

• Skill 省打字，但不会阻止你做错事
• Hook 阻止做错事，但不管教你该做什么
• Memory 帮你记住教训，但没有执行机制

三者组合后：

1. 你第一次做错了某件事（比如忘记在 learning 笔记里写 来源:）
2. Hook 挡住你（pre-commit 拒绝），迫使你修正
3. 你把这条规则写成 Memory（“learning 缺来源字段会被 hook 拦截，写完第一时间检查”）
4. 下次用 /commit Skill 提交时，Skill 自己会在提交前检查前置条件

Skill 做正事，Hook 挡住错事，Memory 记住教训。 一套完整的自动化闭环。

错误恢复循环：持续优化的飞轮

工作流不是建好后一劳永逸的。最好的工作流在运行中自我改进。改进的燃料是什么？错误。

每一次 Claude 犯的错误、每一次你操作失误、每一次流程走不下去，都是优化工作流的信号。处理模式只有三步，但每一步都很关键：

1. 错误发生 → 加 CLAUDE.md 规则（防止复发）

这是 CLAUDE.md 编写哲学的核心：每犯一次错，加一条规则。具体方法见 CLAUDE.md 编写哲学。

从工作流角度看这一步的意义：把一次性的痛转化为永久性的防护。就像打了疫苗之后不会再得同样的病。

2. 能自动拦截的 → 加 Hook（防线前移）

有些错误加 CLAUDE.md 规则就够了。但如果这个错误的后果严重（比如提交了含敏感信息的文件），或者复发率很高（比如忘记加 frontmatter 字段），单靠 Claude 读规则还不够——需要 Hook 做自动拦截。

判断标准：这个错误是“Claude 行为不当”还是“文件格式/内容不合格”？

• 行为问题（讲太快、没出计划就动手）→ 加 CLAUDE.md 规则，因为需要 Claude 的判断力
• 格式问题（缺少字段、死链、敏感文件）→ 加 Hook，因为可以机械检查，不需要判断力

3. 记下 Why → Memory（不让教训丢失）

规则写了，Hook 加了，最后一步：记下为什么这样做。这是防止未来某天你（或接手的人）看到规则觉得“这没道理啊”然后删掉它。

Memory 里的 Why 段就是告诉你：这条规则不是凭空来的，背后有一次真实的翻车。删掉它，那次翻车就会回来。

一个完整案例

2026 年 5 月，Jason 遇到一个问题：

1. 错误：daily-learn Skill 运行时用 cat manifest.json | python3 -m json.tool | head -40 这个命令，在 pipefail（shell 的一个设置，让管道中任何命令失败都算整体失败）模式下 head 早退导致 SIGPIPE（操作系统发给进程的一种信号，当读端关闭时触发），命令报“失败”。实际上 JSON 完全正常。

2. CLAUDE.md 规则：全局 CLAUDE.md 加了一条“读本地文件用 Read，不用 Bash cat/head/tail”。

3. Hook：不需要 Hook——这是 Claude 的行为问题，不是文件格式问题。

4. Memory：feedback_bash_sigpipe.md 记录了完整的 Why——pipefail 下 head 早退会向上游发 SIGPIPE，导致误报。还记录了 originSessionId，可以追溯到原始对话。

从问题发生到全系统防护完成，总时间约 15 分钟。此后所有项目、所有会话都不会再被 SIGPIPE 误导。这就是错误恢复循环的价值——一次投资，永久免疫。

Skill 链：确定性知识管线

单个 Skill 解决单个任务。但真正的效率来自把多个 Skill 串成确定性管线——每个环节的输出是下一个环节的输入，整条链的完成标准清晰无歧义。

Jason 的学习管线是最典型的例子。当一个概念出现在对话中且值得记录，走这条链：

/source-learn -> /learn -> /wiki index -> /sync-all

拆开看每一步：

第一步：/source-learn（从源码中提炼）

输入：一段想学习的源码、一个不知怎么理解的设计决策 输出：一段结构化的解释（日常类比 → 技术定义 → 代码示例 → 和你已学知识的关联）

完成标准：你能用自己的话解释这个 pattern 是什么、为什么这样设计、什么时候用。

第二步：/learn（自测理解）

输入：/source-learn 的输出 输出：自测问题 + 你的回答 + 结果（通过/需再学）

这一步是“你以为你懂了 vs 你真的懂了”的校验。/learn 会出题让你把理解说出来，说不清楚的地方就是真正没懂的地方。

完成标准：所有自测通过，或未通过的部分标记为后续深入。

第三步：/wiki index（注册到知识库）

输入：通过 /learn 验证的理解 输出：一篇新的 learnings/ 笔记，已写入 frontmatter（含 来源: 字段），已注册到分类索引，已检查无死链

这一步把“对话中的理解”变成“知识库中的资产”。下次遇到类似问题，Claude 可以直接引用这篇笔记，不需要重新学。

完成标准：笔记通过 pre-commit hook（来源: 字段、无死链），已出现在知识库索引中。

第四步：/sync-all（刷新制品）

输入：新的 learnings/ 笔记 输出：sidecar HTML（给人读的视图）、更新的 index.html（仪表盘）、更新的 wiki overview

这一步是纯粹机械操作——重新渲染所有 HTML、重新生成综合页。它本身不做任何决策，只是把前面三个智力步骤的结果变成“好看”的展示。

完成标准：npm run build 无错误，打开 index.html 能看到新笔记的链接。

为什么整条链比单独用每个 Skill 强

• 方向感：你知道现在在哪一步、下一步是什么、终点在哪。不需要每步做完再想“接下来干嘛”。
• 质量门禁：每步有明确的“通过标准”。/source-learn 没理解透？/learn 自测会拦住，不会带着错误理解进 /wiki index。
• 可中断可恢复：如果在第三步被打断下班了，明天打开 index.html 看到管线停了，从第三步继续就行。不需要回忆“昨天我学到哪了”。

另一条常见的链：反馈管线

当 mentor 给反馈时：

写入 feedback/inbound/ -> 拆出 feedback/action/ -> /learn 学习 -> /wiki index

这条链把“别人提的意见”转化为“你自己的知识和行动”，不会出现“听到了但没消化，一个月后又说要改”的情况。

常见坑

1. 只用一种模式应对所有场景

这是最常见的错误。用户没意识到 Claude 需要模式切换，结果教学太慢或实施太赶。解决方法：把教学模式和实施模式两条规则同时写入 CLAUDE.md。

2. 工作流中断了不知道从哪恢复

做了一个复杂的 multi-step 操作，中间去吃饭/开会/下班了，回来面对终端不知道刚才做到哪了。

解决方法：用 task list（对于实施类任务）或管线（对于学习类任务）做“书签”。每条管线有明确的前后步骤，中断后看“上一步的输出”就知道当前该做什么。

3. 工具太多，决策瘫痪

攒了 10 个 Skill、5 个 Hook、20 条 Memory、3 个 pipeline，每次打开终端不知道该用哪个。

解决方法：两条黄金规则就够了。

• 不知道做什么 → /learn（学习导航会自动导向合适的 Skill）
• 知道自己该干什么 → 直接打那条 Skill 的名字

不需要记住所有 Skill。/learn 是统一入口。

4. Plan 跳过 Explore

这是实施类任务最常见的失败模式。拿到需求就直接写代码，不先读现有的代码和结构。结果写出来的东西跟已有代码打架，推倒重来。

解决方法：把“Explore”当成 Plan 的第一步，不是可选的。“理解现状 → 出计划 → 实施”这个顺序不能打乱。

5. 跳过 Learn，直接进下一个任务

任务做完了，交付了，马上跳去下一个。一个月后遇到完全一样的问题，又要从头学一遍。这就是“没提炼”的代价。

解决方法：每次完成任务后花 3 分钟问自己“我学到了什么”。如果有答案，写成 learning 笔记或 Memory。3 分钟 vs 未来每次 30 分钟，这笔账很好算。

6. 规则加了但不加 Why

CLAUDE.md 里积了一堆“不要做 X”“永远做 Y”的规则，但三个月后你自己都忘了这些规则是怎么来的。某天你觉得一条规则好像没道理了，删了它——然后当初的 bug 卷土重来。

解决方法：每条规则对应的 Memory 文件里写 Why 段。不用长，两句话讲清楚当时发生了什么就行。写 Why 多花 1 分钟，省的是未来 30 分钟的排查时间。

Checkpoint 练习

从你最近重复做了 3 次以上的事情中挑一件。在纸上画一个流程图，包含四个部分：

1. 触发（什么信号告诉我们该做这件事了？比如“下班了”、“新概念懂了”、“收到 mentor 反馈”）
2. 执行（用什么 Skill？分几步？每步的输出是什么？）
3. 验证（怎么确认做对了？什么结果才算完成？）
4. 记录（做完后记什么？写在哪里？）

画出来之后，这就是你的第一个工作流原型。下次做这件事时按图走，看看有几步是多余的、有几步是需要补的。迭代两次，它就会变成一条成熟的管线。

如果你已经在用 Claude Code，试着把这张图变成一条 Skill 链。不需要一步到位写出完美的 Skill——先从最简单的开始（比如：“收工”触发写 daily），之后每次发现缺失步骤就加一个 Skill。

下一步

• 记忆系统设计原则——工作流里的 Memory 怎么设计三层稀疏结构
• CLAUDE.md 编写哲学——错误恢复循环的第一步（加规则）的具体方法
• Claude Code Skill 系统——怎么写一个可复用的 Skill
• 学习方法论总览——回到方法论索引