Claude Code实战：多Agent编排与闭环自愈提升开发效率

1. 为什么单步聊天会拖垮真实项目：从痛点谈起

第一次把Claude Code用到真实项目里时，我的用法非常蠢：把终端当成一个高级聊天框，问一句答一句。后来随着代码量上来，问题越来越明显——一个重构任务，我要反复粘贴上下文，每次对话都在重复解释项目背景；改完代码没人跑测试；出了错还要我人肉把报错贴回去。那段时间整个流程低效得让人怀疑人生。后来我彻底放弃了“单步聊天”模式，转向多Agent编排、闭环自愈和Routine脚本化，项目的自动化程度才真正提上来。

这篇文章不聊基础操作手册，想拆的是下面这三件事：Claude Code里多Agent编排是怎么运作的，闭环自愈怎么设计才不会翻车，Routine脚本化如何把一天的工作沉淀成随取随用的模板。适合谁读？已经在用Claude Code但觉得效率没有本质提升的人，以及想把AI接入CI/CD和日常开发流程、但不确定怎么设计协作机制的开发者。

1.1 单步聊天模式的核心缺陷

先给单步聊天画个像。你打开终端，输入一段需求，模型开始干活。这个模式本身没错，但它隐含了一个前提：整个任务的复杂度低到可以装进一次对话，而且你对过程没有强校验需求。真实项目里这两个条件几乎都不成立。

第一，上下文断档严重。一次代码重构至少涉及几十个文件，单步聊天里你没法保证模型记住每个文件的角色。换一次会话，前面讨论过的方案就蒸发了；为了弥补，你只能不断把旧的结论重新粘进新对话，提示词越来越长，消耗越来越大，模型反而更容易被淹没在细节里。

第二，任务没有隔离。审查代码的Agent和写代码的Agent如果共用一个上下文，两个职责会互相污染——写代码的Agent被审查意见干扰，审查的Agent又被实现细节带偏。一个会话里所有任务共用一套记忆，这本身就不符合真实工程的分工逻辑。

第三，没有自动校验。单步聊天是人推着模型走，改完代码没有编译、没有测试、没有lint，错误靠人眼去抓，等于把最吃力的部分留给了自己。你会发现，单步聊天不是没有闭环，而是闭环里缺了“自动验证”这一环，所有验证动作都变成了人工操作。

单步聊天还有一个隐藏问题：它天然是串行的。一个人同时只能等一个问题回答完，才能问下一个。而真实项目的任务图是并发的——这边可以跑测试，那边可以审计代码，主流程还能同时做任务调度。单步聊天把这些并发全部拍扁成了排队，时间自然成倍增长。

1.2 多Agent编排的第一性原则

多Agent编排不是一个花哨概念，核心就三句话：把大任务拆成小任务，让不同Agent各司其职，用外部校验决定是否继续。拆任务是为了让每个Agent的上下文都聚焦；各司其职是为了让职责边界清晰；外部校验是为了不信任任何一次生成结果，用测试、编译、lint这类硬性证据来裁决。

我用一个外行人也能懂的例子解释：单步聊天就像你同时充当老板、程序员、测试员和运维，一个人把所有角色演完；多Agent编排则像一个手术室，主刀医生（主Agent）不负责麻醉和护理，他只说“准备麻醉”“递器械”“监测生命体征”，然后由专门的Agent去执行，最后由生命体征数据（测试结果）来判断手术是否成功。每个角色只关心自己那一摊事，效率自然上去。

这也是Claude Code这类工具与普通对话式AI最根本的差异。普通聊天是一个模型、一个上下文、一条线；Claude Code则允许你在一个会话里动态生成子Agent、调用外部工具、用脚本把流程串起来。编排的重点不是“有很多个Agent在跑”，而是“每个Agent的任务边界、上下文、验证方式都被人为设计过”。

2. Claude Code多Agent编排机制深度拆解

2.1 主Agent与子Agent：一个调度中枢加N个专属执行者

Claude Code的Agent模型可以简单分为两层：主Agent和子Agent（Subagent）。主Agent就是你直接在终端里对话的那个角色，它拥有完整的工具调用权限，负责理解大目标、拆解任务、调度资源、汇总结果。子Agent则是被主Agent按需拉起来的临时角色，可以来自项目里自定义的Agent配置文件，也可以由主Agent通过动态方式生成。

子Agent最有价值的地方是上下文隔离。每个子Agent可以带一套独立的System Prompt、专属的工具白名单和输出格式约束。比如我需要一个“数据库专家”，它可以只看schema文件、只允许执行只读SQL；我需要一个“安全审查员”，它可以只读diff和依赖清单，不允许写任何文件。这样一来，每个Agent的上下文窗口都花在刀刃上，不会把无关的闲聊、背景故事和重复解释也塞进去。

我在项目里习惯把子Agent定义在.claude/agents/目录下，一个Agent一个Markdown文件，里面写上职责描述、适用场景、工具限制和输出格式。主Agent在需要时通过内部机制调用这些子Agent，子Agent返回结构化结果后，主Agent再决定下一步动作。这个模式非常接近一个真实团队：项目经理不亲自写代码，他只负责把需求传达给合适的人，再把结果拼成整体方案。

2.2 编排引擎与工具调用链：任务拆解、结果汇聚如何落地

编排的核心是一个可预测的工具调用链。以一次“修复历史遗留Bug”为例，典型链路是：

1. 主Agent接收任务，先通过Read工具读取相关文件，理解代码结构。
2. 主Agent识别出需要专项分析的部分，调用子Agent去深挖（比如一个Agent专门排查数据流，另一个负责检查日志逻辑）。
3. 子Agent返回结论后，主Agent自己动手修改代码，或者再派一个“实现Agent”去落盘改动。
4. 主Agent调用Bash执行测试命令，拿到失败或成功的结果。
5. 若失败，主Agent读取报错，把反馈作为新的输入，重复步骤3和4。

这条链路里，主Agent相当于一个带有限状态机的调度器。它不会一股脑把所有代码改完，而是每一步都基于上一步的硬性输出做决策。我实测下来，这种“拆一步、验证一步、再前进一步”的节奏，比让单个Agent一口气改完几十个文件的成功率高出非常多。

另外一个容易忽略的点是并行调度。虽然Claude Code在单会话内不一定真能像分布式系统那样多线程并行，但你可以通过设计，让主Agent在等待一个子Agent结果时，不重复做无用功。实战中我是把“读代码、理清结构”这类耗时任务拆给子Agent，主Agent只保留决策逻辑，整个任务的响应速度会明显改善。这也是编排和“提示词堆砌”的本质区别：编排关心任务之间的依赖关系，而不是堆多少字。

2.3 权限模型与Hooks：把编排半自动化的关键

编排要落地，离不开权限控制和自动化钩子（Hooks）。

权限模型决定了Agent能做什么、不能做什么。Claude Code启动时可以带--allowedTools参数指定允许调用的工具清单，也可以使用--permission-mode切换模式：acceptEdits模式允许直接修改文件，plan模式只允许规划不许改动，bypassPermissions则跳过所有确认。我个人的建议是：日常开发用--allowedTools "Read Edit Write Bash"这类白名单方式，不要直接用bypassPermissions。白名单看起来麻烦，但它能保证出了问题你还能看到Agent执行了什么操作；全程免确认听起来爽，真遇到Agent拿rm -rf级别的命令乱跑时，你连后悔的机会都没有。

Hooks则是把“人肉触发”变成“自动触发”的关键。Claude Code支持在特定事件后执行外部命令，常见的有PreToolUse（工具调用前）、PostToolUse（工具调用后）、Stop（Agent停止时）、Notification（需要通知时）。我在项目里用PostToolUse绑定Edit和Write事件，每次Agent改完文件，自动触发一次lint或类型检查，结果直接返回给Agent，让它在下次修改前自动修正。这套机制让编排从“人盯着Agent干活”变成了“代码管着Agent干活”。

这里放一个简单的hooks配置示例，实际项目里可以按需扩展：

{ "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "npx tsc --noEmit" } ] } ] } }

这个配置表达的含义是：每当Agent修改了代码，立刻跑一次TypeScript编译检查，如果编译失败，这个失败信息会成为Agent下一步操作的输入，逼它修复类型错误再继续。这就是最基础的自动闭环。

3. 闭环自愈：让Agent像工程师一样自己发现并修复问题

3.1 自愈循环的构成要素

闭环自愈是“多Agent编排”最有价值的延伸。它的本质是把一个开发者的日常工作流抽象成一个循环：做出改动，验证改动，发现失败，读取失败原因，再次修改，直到通过。这个循环不需要人肉介入，所以才叫“自愈”。

我拆解下来，一个可靠的自愈循环必须有三个要素：失败信号、修复指令、验证闸门。

失败信号就是测试失败、编译报错、lint告警这类明确的结果。它必须能被程序捕获，不能是模糊的“好像不对劲”。在Shell脚本里就是退出码，在测试框架里是失败用例列表。修复指令则是把失败信号转化为Agent能理解的修正任务，比如把报错日志和上下文一起作为Prompt的一部分传给Agent。验证闸门是循环的终止条件，也是防止Agent“假装修好了”的关键——它必须重新运行一次完整的测试或编译，用硬性结果说话。

这三个要素缺一个都会出问题。没有失败信号，Agent不知道什么时候该停；没有修复指令，Agent不知道该做什么；没有验证闸门，Agent可能改完代码就宣布成功，结果测试根本不过。很多人在项目里抱怨“AI不可靠”，仔细排查下来，大半是因为验证闸门做得太松，甚至压根没做。

3.2 基于CLI与Hooks的自动化闭环示例

最直接的自愈闭环实现方式，是用一段Shell脚本把“测试-修复-再测试”串起来。下面这个脚本是我在一个Node.js项目里实际跑过的简化版，逻辑很朴素：先跑测试，失败就把错误日志交给claude -p去修复，最多循环5次，超过次数就中止并保留现场。

#!/usr/bin/env bash set -e MAX_ATTEMPTS=5 attempt=1 while [ $attempt -le $MAX_ATTEMPTS ]; do echo "[attempt $attempt] running tests..." if npx jest --silent 2>test-error.log; then echo "all tests pass" exit 0 fi echo "tests failed, asking claude to fix..." claude -p "请根据 test-error.log 中的失败信息修复代码。要求： 1. 只修改导致测试失败的代码，不要重构无关模块 2. 修改后必须先自查，再提交 3. 最终输出修改了哪些文件、为什么这样改" \ --allowedTools "Read Edit Write Bash" attempt=$((attempt+1)) done echo "max attempts reached, check test-error.log manually" exit 1

这套脚本看起来简单，但已经具备了一个自愈系统的基本骨架。npx jest --silent 2>test-error.log负责生成失败信号；claude -p负责任务理解和修复；循环条件attempt -le $MAX_ATTEMPTS负责防止死循环。你可以在此基础上扩展，比如失败后先让Agent阅读历史提交记录再决定改法，或者先把失败的测试用例单独抽出来跑，让Agent聚焦于最小失败集。

我在真实项目里用下来，最深刻的体会是：不要把整个测试套件一次性丢给Agent修复。测试失败可能是几十个原因混在一起，Agent很容易陷入选择困难。更好的做法是先让脚本自动按模块归类失败用例，一次只让Agent处理一到两个强相关的失败项，小步快跑，每个循环的修复成本都低，成功率反而高。

3.3 自愈设计的边界与防抖

闭环自愈不是越猛越好，设计时一定要考虑“防抖”和“止损”。我把常见的坑列一下：

• 死循环风险：如果测试失败原因多年不变，Agent会反复尝试相同的修法。必须设置最大尝试次数，并在每次循环之间加入冷却或变化策略（比如第二次循环时，明确告诉Agent“你上次的方案没有解决，请换一个思路”）。
• 改动扩散风险：Agent修一个Bug时顺手重构了三处无关代码，这是我在项目里最怕的事。修复指令里必须强约束改动范围，最好在Prompt里直接写“只允许修改与失败用例直接相关的文件”。
• 测试本身不可靠：如果测试套件有flaky用例，自愈循环会被带偏，Agent为了讨好测试可能去找各种trick绕过失败。这时候应该先修测试，再谈自愈。
• 回归保护：修复完当前失败后，要跑全量测试而不是只跑刚才失败的用例。很多“修复”是按下葫芦浮起瓢，只验局部大概率埋雷。

止损策略我建议这样定：尝试3次后自动停止，发通知给人，并保留所有中间产物（错误日志、Agent的修改记录、测试快照）。不要追求“百分百自愈”，自愈的目标是把人从重复劳动里解放出来，而不是让机器完全替代人的判断。

4. Routine脚本化：把可复用的工作流沉淀成模板

4.1 Routine的本质：流程、约束与校验的组合

Routine脚本化是“效率升级”的最后一环。你会发现，多Agent编排和闭环自愈解决了“单个项目怎么跑”的问题，但如果你每次新开一个项目都要重新配置、重新设计流程，那沉淀就是零。Routine就是把这个设计过程固化下来，让它一次设计、处处复用。

一个Routine不是简单的一段Prompt，它是流程说明 + 行为约束 + 工具白名单 + 校验步骤的组合。比如“代码审查Routine”包含：审查哪里（流程）、用什么标准（约束）、允许读哪些文件（工具白名单）、提交前必须跑什么检查（校验）。这跟写一个函数很像：输入是需求，输出是符合要求的交付物，内部逻辑是稳定的，每次执行的质量不会因为换了个模型版本就大幅波动。

我在团队里推广Routine时发现一个现象：新手和老手最大的差距不在编码能力，而在于有没有把“怎么做一件事”的方法论沉淀下来。Claude Code给你提供了一个绝佳的载体——你不需要写一堆文档，只需要把Routine配置进项目，AI就能按你的方法论执行。

4.2 Slash Command与项目记忆：两个最轻量的落地载体

Claude Code里最常用的两种Routine载体是斜杠命令（Slash Command）和项目记忆文件。

斜杠命令放在.claude/commands/目录下，每个Markdown文件对应一个命令。例如我建了.claude/commands/review.md，内容是代码审查的标准流程：

你是一名高级代码审查员。收到 /review 请求后，请执行以下步骤： 1. 先运行 `git diff --stat` 和 `git diff` 获取本次变更范围 2. 按以下维度审查：逻辑正确性、边界条件、安全隐患、可读性、测试覆盖 3. 对每个问题输出：严重级别（高/中/低）、涉及文件行号、具体修改建议 4. 最后汇总一个优先修复清单，若存在高危问题则直接说明“不通过”

配置好之后，在Claude Code交互面板里输入/review，就会触发这个Routine，而不是依靠模型临场发挥。项目记忆文件则是CLAUDE.md或claude.md，放在项目根目录，相当于给Agent的一份“项目说明书”。里面可以写技术栈、目录结构、编码规范、常用命令，Agent每次启动会话都会自动读取，相当于给Routine提供了稳定的上下文底座。

我的经验是：斜杠命令管“动作”，项目记忆管“背景”。两者配合使用，效果远好于只配一个。项目记忆告诉Agent“这是什么项目，有哪些约定”，斜杠命令告诉Agent“遇到这个场景，按什么流程做”。没有项目记忆，Routine执行时会频繁猜错背景；没有斜杠命令，项目记忆也只是一个静态文档，不会主动转换成行动。

4.3 一个可复用的Bug修复Routine完整模板

下面这个Bug修复Routine模板是我未来新项目都会默认带上的一份配置，分享出来供参考。

## 定位阶段 1. 先复现：运行最小复现命令，确认Bug确实存在 2. 阅读相关模块的最近改动，判断是否回归引入 ## 诊断阶段 3. 检查日志与错误堆栈，缩小到具体函数或代码路径 4. 分析数据流，确认是逻辑错误、边界条件还是外部依赖异常 ## 修复阶段 5. 给出最小改动方案，只修改与Bug直接相关的代码 6. 补充或调整测试用例，确保能覆盖该Bug场景 7. 运行相关模块测试，再跑全量测试，确认无回归 ## 总结阶段 8. 输出修复说明：根因、改动文件、测试结果、影响范围 9. 若复现/定位耗时超过10分钟，及时停下并汇报当前进展

这个模板最大的特点是把“怎么做”拆成了带明确动作的步骤，并且设置了“超时汇报”机制。很多Routine失败是因为没有终止条件，Agent在一个方向走死；加入“超时汇报”后，Agent会在卡住时主动停下来，把现状交给人类决策，而不是硬编硬造一个答案。

4.4 Routine库的维护建议

Routine不是写一次就永远正确的，它需要持续迭代。我建议在团队层面做三件事：版本化、复盘、按场景分库。

版本化：把Routine文件放进Git仓库，每次改动都有提交记录，出了问题可以回溯到上一个可用版本。复盘：每隔一段时间回顾一下哪些Routine经常被跳过、哪些Agent执行结果不佳，花30分钟调整一次，收益通常很可观。按场景分库：不要把审查、重构、文档生成、上线检查全部塞进一个命令，场景之间差别太大时，Agent需要在多个不相关流程之间跳转，反而容易混乱。

5. 完整实操：从安装配置到一套多Agent闭环工作流

5.1 安装、登录与模型接入

这部分讲一下从零开始的实操路径。安装Claude Code最常用的方式是通过npm全局安装，或者使用官方提供的安装脚本。安装完成后直接运行claude，首次启动会引导你完成认证，方式一般是登录Anthropic账号或配置API Key。这里要注意，账号直接登录和API Key计费是两种不同形态，订阅用户可以在订阅额度内使用，API Key则按实际调用量计费，团队使用可以把Key放在中心化的密钥管理里。

如果不使用Anthropic官方账号，Claude Code也支持通过环境变量接入兼容端点。常见做法是设置ANTHROPIC_BASE_URL指向第三方兼容服务，同时设置ANTHROPIC_AUTH_TOKEN作为认证凭证。这个模式在接入DeepSeek、千问、GLM等模型的兼容接口时非常实用，社区里也有像cc-switch这类工具专门做多供应商配置管理，本质上是帮你维护不同Base URL和Key的组合，切换时自动重写环境变量。我个人的建议是：如果主力使用Anthropic模型，直接官方登录最省心；如果需要在多个国产模型之间做对比测试，再用环境变量的方式接入。

本地模型接入是另一个常见需求。用LM Studio这类工具启动本地模型后，会暴露一个OpenAI兼容的本地服务地址（通常形如http://localhost:1234/v1）。Claude Code是Anthropic协议，直接接OpenAI地址通常需要一层转换代理，社区有多个兼容层项目可以实现格式互转。这里不推荐具体哪个，只给两条实操经验：一是本地模型的上下文长度别开太大，显存不够时性能下降非常明显；二是本地模型更适合做子Agent的专项任务（比如格式修正、分类提取），让主Agent继续用云侧强模型，性价比和效果都更好。

VS Code用户还可以安装Claude Code扩展插件，在IDE里直接启动会话。配置上无非是选择终端、设置工作目录、确认权限模式。插件和CLI底层共享一套配置，所以你在命令行里配好的settings.json、命令文件、Hooks，在IDE里同样生效。

5.2 实战案例：用多Agent编排改造一个遗留服务

我把一个真实的实操案例简化后放在这里。假设有一个老旧的Node.js服务，代码风格混乱、没有类型定义、测试覆盖率只有20%，需求是“加一个限流功能，同时不破坏现有接口”。

用多Agent编排的思路，我会让主Agent先派一个“审计Agent”去通读代码，整理出路由注册、中间件链路、数据库访问三个关键路径，输出一份简洁的结构报告。这个Agent只允许Read和Bash（用于跑只读命令），不允许改文件。结构报告回来之后，主Agent再派一个“方案Agent”，根据审计结果设计限流方案，明确要修改哪些文件、是否需要引入中间件、如何保证向后兼容。

方案确定后，主Agent才会亲自（或派实现Agent）动手改代码。改完之后，核心动作来了：主Agent调用Bash跑一遍现有测试集，再补一组针对限流功能的用例。测试失败，就把失败日志回填给实现Agent去修；测试通过，再让主Agent做一次diff级自查，确认没有无关改动。

这个流程看起来“多绕了几步”，但它每一步都有明确产出物：审计报告、技术方案、代码改动、测试结果。相比“你直接帮我加个限流”，产出质量是数量级上的差距。我算过一笔账，前期多花10分钟做审计和方案设计，后期减少的人肉review和返工时间通常远超10分钟。

5.3 项目级配置与团队协作建议

项目级配置的核心文件是settings.json，建议在版本库里保留一份公共配置，包含Hooks、允许的工具列表、默认权限模式。团队成员clone下来，跑一次认证即可开工，不用各自凭记忆敲参数。

我认为团队协作方面最值得做的三件事是：统一Routine库、统一项目记忆、约定阶段门禁。统一Routine库是指所有人在同一个斜杠命令集上工作，避免每个人自己发明一套流程；统一项目记忆是指CLAUDE.md由维护者统一更新，保证Agent收到的背景一致；约定阶段门禁是指什么情况下必须人工介入——我建议在“影响线上的配置变更”“数据库结构变更”“涉及支付和权限的改动”这三类场景强制关闭AI自动直改，改为先生成方案给人审。这是安全底线，不是效率问题。

6. 常见问题与排查技巧实录

6.1 上下文被污染与子Agent结果失真

第一个高频问题是Agent用着用着突然“忘事”，或者子Agent返回的结果牛头不对马嘴。这通常不是模型傻，而是上下文被无关信息挤爆了。排查时先看会话日志里是否有大量重复内容、是否混入了其他任务的输出。解决办法是：拆子Agent时把提示词写得更窄，明确告诉它“你只需要看这几个文件”；主Agent收到子Agent结果后，立刻把结果消化成简报，而不是继续保留子Agent的完整原始输出。

还有一个细节：子Agent返回“没问题”“已完成”这样的模糊结论时，一定要让主Agent补问“证据是什么”。我在Routine模板里强制要求子Agent输出“验证方式+实际结果”，比如“已运行npm test，3个用例全部通过”。模糊结论是自愈系统最大的敌人。

6.2 死循环与重试风暴

自愈脚本跑着跑着不结束，这是第二个高频问题。前文提过最大尝试次数，但实际还有一个坑：Agent每次修复完，自认为成功了，但它跑的验证命令写错路径或命令本身静默失败，导致信号没传递出来。排查方法是先人工执行一遍验证命令，确认它真的有效、退出码正确。我踩过一次最离谱的坑：脚本里写的是npx jest，Agent为了“修复”，直接把jest换成了npm test，然后又说测试通过——实际上npm test里的脚本根本没写，等于绕过了验证闸门。所以验证命令必须写绝对路径或者写校验脚本，防止Agent“优化”掉验证环节。

6.3 权限卡死与工具拒绝执行

第三个问题是Agent想执行某个命令，但权限配置没放开，任务直接卡住。我见过很多人遇到Tool requires permission就不知所措，其实只要在启动参数或settings里给对应工具授权即可。这里想提醒的是：权限卡死不是Bug，它是安全机制在起作用。如果AI经常卡在合理操作上，说明你的白名单太窄，适当放开Read和Bash即可；如果它频繁想执行危险操作，说明你的Routine写得太开放，应该收紧而不是祈祷它别乱来。

6.4 模型接入与更新问题

模型接入的典型报错包括鉴权失败、Base URL不对、模型名不匹配。鉴权失败时，先检查ANTHROPIC_AUTH_TOKEN是否带上了过期空格；Base URL问题可以先用curl测试端点连通性，再排查Claude Code侧环境变量；模型名不匹配则是因为不同供应商给的模型标识符不同，需要在配置层做映射。另外，企业环境里如果遇到组织策略阻止了Claude订阅访问，常见解决办法是改用API Key计费，或者联系管理员调整组织策略，不要试图用旁门左道绕过，那只会给自己埋雷。

升级与兼容性方面也有几个常见问题。老版本Claude Code更新不及时，可能会导致Hooks配置格式不兼容、新命令不可用，建议保持自动升级习惯，同时留意release notes。Windows用户如果遇到安装后无法启动的兼容性问题，优先检查Node版本和PowerShell执行策略，必要时在WSL环境中运行。社区讨论的“在线升级最新版本”也就是执行一次更新命令的事，真正需要注意的反而是升级后重新验证一遍现有Routine和Hooks，避免新版本行为变化影响你的自动化流程。

我按这几个维度整理了一张速查表，供日常排查时对照：

结语：别追求“全自动”，把半自动做到极致才靠谱

我个人在整套体系里最大的体会是：多Agent编排、闭环自愈和Routine脚本化从来不是为了“完全取代人”，而是把人在整个流程里的角色从“执行者”调整成了“设计者”和“裁决者”。你用Routine定义了流程，用编排分配了任务，用自愈循环处理了重复劳动，然后你只需要在最关键的节点做判断：方向对不对、风险能不能接受、要不要继续投入。

另一个很实用的建议是：不要一上来就想搞一个庞大完美的编排系统，先从一个小任务开始。挑一个你每周都要做、重复度最高的场景，把它固化成一条Routine，加上一个最小测试闭环，跑通之后再复制到其他场景。我自己的第一套Routine只花了一个下午搭建，后来每天省下的时间远远不止一个下午。这套东西的真正威力，是在日复一日的小迭代里慢慢发酵出来的。