最初的想法来自微信公众号上的一篇文章 告别AI编程的”分身乏术”！Claude Code Sub Agents让你的代码效率翻20倍 ，再加上平常用AI开发时经常会遇到很多问题，比如同时推进代码审查、测试与调试时，顺序式对话让事情被迫排队，切换主题又容易丢上下文。又读了几篇关于 Sub Agents 的文章与官方文档后，我决定把“并行与分工”变成一个拿来即用的项目骨架：适配个人的日常开发，保留必要的结构化和节奏感，但不把自己绑进复杂流程。
动手之前先做了些功课。文章把方向讲得很清楚：同一会话内的并行、专业化分工、上下文隔离；官方文档明确了子代理的配置与作用域优先级；实践类文章提醒把“工作规矩”写进项目本身，避免反复解释。基于这些，我把结构定在四个支点上： 放职责清晰的项目级子代理， 收纳常用流程的命令模板， 承载可复制的并行剧本， 说明使用方式与上下文约定。
第一轮实现尽量把能想到的都接上：为代码审查、安全审计、性能分析、调试与测试运行配置了子代理，补了微服务架构顾问；剧本里既有一次性拉起多项检查的“代码库体检”，也有微服务分工与 UI 迭代；命令模板覆盖了“探索—计划—编码—提交”和 TDD，并预留了与 Issue/PR 流程结合的入口。为方便跨项目复用，我写了安装与新建脚本：前者把模板复制到现有仓库，后者直接用模板起新工程。这一版覆盖面足够完整，适合团队协作，但对个人开发而言显得偏重。
第二轮尝试把质量门禁闭环补齐：接入 GitHub Actions，让推送/拉取请求自动触发测试与体检；补了一份最小的 OpenAPI 契约示例，在 CI 中做规范与破坏性变更校验。放在团队语境里这很必要，但回到个人项目，它抬高了启动成本。很多时候，我只是想验证一次思路或做个练习，并不需要完整流水线。于是我基于实际使用场景做了减法。
减法的思路很直接：把确实提升效率与稳定性的部分留下来，把维护成本较高或低频的内容下沉为可选。留下来的，是四个职责明确的子代理（代码审查、测试运行、调试与基础安全检查），是一份可以在动手前迅速拉齐风险与优先级的“并行体检”剧本，是两条让开发节奏更稳的命令模板（探索—计划—编码—提交与 TDD）。与此同时，CI、契约校验、分支保护，以及与微服务或特定领域相关的扩展从默认模板中移除，但随时可以按需加回去。
精简后的模板结构清晰直接。项目根目录有一份 作为协作手册，写清 PLAN 模式、TDD、上下文管理与体检门槛； 下的子代理以项目级优先被识别，确保习惯迁移时不走样； 把常用流程固化为可调用命令； 留下一份“并行体检”，面向前端的 UI 迭代按需使用。它的目标很明确：把正确的事情，更稳更快地做完。
当前骨架最核心的目录如下：
把模板装进一个现有项目之后，我通常会先在项目目录启动 Claude Code，执行一次 ，确认项目级子代理处于工作状态。正式改动前，先跑“并行体检”：从 复制提示词，粘贴到对话中执行，让系统在安全、审查与测试三个维度产出一份统一清单，节省来回试错的时间。进入开发环节，用“探索—计划—编码—提交”的命令模板生成可执行的实现计划；能用 TDD 的地方，先写会失败的测试，再逐步让它变绿。遇到异常，就把问题交给“调试”子代理缩小范围并给出最小修复方案，最后回到体检，确认没有引入新的问题。
为了降低记忆负担，我把关键命令和提示词放在了文件里，随用随取。例如安装步骤可以直接照搬：
“并行体检”的提示词写在剧本中，无需现编：
两条常用命令模板也在 中，调用时直接输入命令名：
为了让这篇记录更完整，这里补一段“从体检到修复”的闭环过程。假设我需要给一个 Node 项目做一次快速评估与修补。我先把模板装进去，随后运行“并行体检”。清单里指出某个工具模块的错误处理不充分，且单元测试缺失。我接着调用“探索—计划—编码—提交”的命令，要求先给出最小修复计划与测试范围建议，然后启动 ，先写会失败的测试，再实施修复，最后让测试通过。期间如果遇到报错，我把错误栈和相关上下文交给“调试”子代理，请它帮助定位最小修改面。全部完成后，再回到体检剧本，确认没有新问题被引入。这套闭环的价值在于，不需要我反复在不同任务之间来回切换上下文，把注意力留给取舍本身。
扩展并不复杂。如果未来要增加一个“领域子代理”，只需要在 下新增一个 Markdown 文件，按官方文档格式写清 、 和 ，随后在需要的剧本或命令模板里明确调用；要增加一个“命令”，就在 写一份结构化的步骤说明，让 Claude Code 按步骤执行；要新增一个“剧本”，就在 写下完整提示词与输出要求。这种组织方式的好处在于：把约定落在文件系统上，跨项目迁移时不会失真。
不同项目类型可以做一些微调。前端项目适合保留 UI 迭代相关的命令与剧本，并准备目标截图以获得更直观的对比；纯脚本或命令行工具项目可以删除 UI 相关内容，只保留体检与 TDD；数据类脚本则可以在体检提示中增加“输入输出样例与边界”这类要求。无论是哪一种，保持“先计划再动手、先体检再大改”的节奏，是这套模板背后最重要的建议。
日常维护可以从三个点入手。其一，阶段性地精简：用不到的命令和脚本及时删除或归档，保持仓库干净；其二，必要的固化：当某条实践证明长期有效，就把它写进 ，在新项目也能继承；其三，适度的演进：当协作或质量门槛的需求提升，再把 CI、契约校验与分支保护接回来，让工作流自然升级。
回望整个过程，它经历了从方法论到实现、从求全”到“做减法”的两个转折。第一步证明并行、分工与上下文隔离在个人语境下同样有价值；第二步让这份价值以更低门槛落地。现在留下的，是一份可直接工作的骨架：四个子代理，一份体检剧本，两条命令模板，加上少量脚本与说明。重复性的、可标准化的操作交给“专门的人”，需要判断与取舍的部分留给自己。如果日后需要更严密的流程，可以把 CI、契约与分支保护再接回来；在此之前，这个轻量的起点已经足以支撑个人的日常开发。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/210812.html