用子代理团队打造“高级工程师”：在 Claude Code 里复刻一家真实工程组织

作者：AI拉呱（Errol Yan）
定位：AI领域深度内容与实战方法分享

初级工程师和高级工程师的差别从来不在语法，而在 可预测性、风险管理、以及压力下的纪律性。

而 AI agent 最容易在这三点上翻车：

• 跳过 review
• 为走捷径找理由
• 交付“看起来很自信”的产物，但没人真正验证过

单纯加更多 agent 并不会自动变强——没有结构时，只会带来更多混乱与算力浪费。你真正需要的是现实世界里大公司已经验证过的组织形态：

用一个 Staff Engineer（高级工程师）去编排一组职责清晰的子代理（sub-agents），走一条从设计到上线的纪律化流水线。

这套系统如何像“真实工程团队”一样工作

它把工作拆成明确角色，并给每个角色配置“只做自己那一段”的职责边界：

• Discovery & Design（发现与设计）：Architect 一次只问一个问题，给出 2–3 套方案与取舍，写出设计规格（spec）并落盘；未经人类批准不写代码。
• Planning & Review（计划与审查）：Tech Lead 把 spec 拆成 2–5 分钟可执行任务，标注精确文件路径与预期改动；另一个全新的 sub-agent 审核计划，防止漏项与范围膨胀。
• Execution Engine（执行引擎）：Manager 按任务逐个派发“全新上下文”的 sub-agent 执行；卡住则升级；低质量产出直接终止并重派。
• Quality Gates（质量门）：两个顺序评审：先看 spec 是否符合（做对了事？），再看代码质量（事做得好不好？）；完成前必须通过“验证门”，要求提供新鲜的终端输出。
• Engineering Discipline（工程纪律）：TDD 是铁律；调试遵循取证式四阶段流程；根因追踪至少五层；技能本身要经真实 agent 压测后再投入使用。

本文把重点放在：如何把“这些纪律”落到可执行的 hooks / skills / agents 体系里。

1）先搭团队代码库：组织脚手架（Organizational Scaffolding）

真实公司在写第一行业务代码之前，会先搭好：项目结构、开发流程、CI/CD、团队规范。

当你要构建的是“多 agent 团队”而不是“单兵开发者”，结构更关键：十个人的团队需要的组织结构，不是一个自由职业者能凑合的那套。

一个可参考的目录骨架（每个目录都对应组织里的一个职能）：

senior_staff_engineer/
├── agents/                             # 角色与子代理定义（谁做什么）
├── commands/                           # 自定义命令（像团队内部 CLI）
├── hooks/                              # 生命周期 hooks（管理层）
├── skills/                             # 能力与流程模块（员工手册）
│   ├── brainstorming/                  # 头脑风暴与设计
│   ├── dispatching-parallel-agents/    # 并行派发
│   ├── executing-plans/                # 按计划执行
│   ├── receiving-code-review/          # 接收审查并迭代
│   ├── requesting-code-review/         # 发起审查
│   ├── subagent-driven-development/    # 子代理开发
│   ├── systematic-debugging/           # 系统化调试
│   ├── test-driven-development/        # TDD
│   ├── using-git-worktrees/            # worktree 隔离
│   ├── verification-before-completion/ # 完成前验证
│   ├── writing-plans/                  # 写计划
│   └── writing-skills/                 # 写技能

一句话理解：

• agents/ 是团队花名册
• skills/ 是员工手册（流程与标准）
• hooks/ 是管理层（把流程“自动化地强制执行”）

2）Hooks：管理层（The Management Layer）

在真实公司里，很多“管理基础设施”是隐形的：人们开始工作之前，一堆初始化动作已经发生了。

在 agent 团队里，hooks 就是这层管理基础设施：它把“每次会话都当作 Day 1”这件事工程化解决。

一个典型最小 hook 集包括：

hooks/
├── hooks.json     # 主配置
├── run-hook.cmd   # 跨平台脚本执行器
└── session-start  # 会话初始化逻辑

hooks.json：把 SessionStart 固化为“强制入职流程”

核心原则：每次 session 开始（包括 startup / clear / compact），都先跑初始化脚本。

要点包括：

• 通过 matcher 覆盖“新会话 / 上下文清空 / 记忆压缩”
• async: false 确保 hook 完成后 agent 才开始工作（等价于“晨会开完再开工”）

run-hook.cmd：跨平台兼容

真实团队不可能只跑同一种 OS：有人用 macOS，有人用 Linux，还有 Windows。

因此需要一个“网关脚本”把平台差异屏蔽掉：

• Windows：尝试找到 bash（常见 Git 安装路径）并执行
• Unix：直接 bash 执行

这样 agent 不必关心运行环境，脚本会决定怎么跑。

3）员工手册：文化与纪律从第一秒开始（The 1% Rule）

团队要稳定输出，靠的不是聪明，而是纪律。

这类系统往往会把第一条铁律写进 skills/using-senior-staff-engineer/SKILL.md，并在每次 session-start 注入到上下文里。

其中一个非常关键的规则是 1% 规则：

如果你觉得某个 skill 有哪怕 1% 的可能适用，你就必须调用它。

因为 agent（和人）最常见的退化路径就是：

• “这事太简单了，不用走流程”
• “就改两行，不用测”
• “不用 review 了，很明显”

每一个高级工程师都见过团队是如何被这些“合理化”慢慢掏空质量的。

子代理的“豁免条款”

当主 agent 派发一个非常聚焦的 sub-agent 做具体任务时，sub-agent 不必重复完整的 skill discovery 流程；它应该专注于执行被派发的工作。

组织类比就是：承包商不必参加 all-hands，只要把交付做完。

4）技能发现流程：先走流程，再动手（Skill Discovery Flow）

这类体系通常会明确规定：

• 收到消息后，先判断是否有 skill 适用
• 只要有 1% 可能性就调用
• 明确宣布正在使用哪个 skill
• 按 skill 的清单/步骤执行
• 最后才对用户输出

并配一张“红旗表（red flags）”来打断常见的偷懒合理化，例如：

• “这只是个简单问题” → 问题也是任务，先查 skill
• “我先看代码再说” → skill 会告诉你怎么探索，先用 skill
• “我记得这个 skill” → skill 会演化，必须读最新版本

5）设计优先：写代码前必须先有设计（Brainstorming & Design）

在真实公司里，最重要的工作往往发生在“代码还不存在”的那一刻。

无论是 press release 先行、pitch document、还是多层级 design doc review，核心共性都是：

先思考，后构建。

因此 brainstorming skill 往往会设一个硬门（hard gate）：

• 没有设计
• 没有人类批准

就禁止进入实现阶段。

最危险的反模式：“太简单，不用设计”

“简单项目”是最容易浪费时间的地方，因为假设没人去检查。

• 一行配置改动可能影响三个服务
• 一个“快速工具函数”可能需要处理七个边界条件
• 一个“简单 todo app”可能暗含离线、冲突解决、多用户

设计可以很短：真正简单的改动两三句话就够。

但关键是：必须停下来做设计，并得到批准。

设计检查清单（9 步）

一个非常实用的 checklist（映射真实产品团队的节奏）：

1. 探索项目上下文（文件、文档、近期提交）
2. 必要时提供视觉辅助（白板/图）
3. 一次只问一个澄清问题（目的/约束/成功标准）
4. 提出 2–3 个方案 + 取舍 + 推荐
5. 分段呈现设计并逐段确认
6. 把设计文档落盘并提交
7. 自审 spec（占位符/矛盾/歧义）
8. 用户审阅书面 spec
9. 进入实现（调用 writing-plans skill）

这里真正“高级”的点不在清单本身，而在执行方式：

• 一次只问一个问题
• 尽量用多选题
• 每条消息只包含一个问题

这是典型的资深工程师式沟通：把对齐做扎实，再开始写。

6）从设计到交付：计划→派发→评审→验证

当 spec 得到批准后，系统进入“交付流水线”：

• Tech Lead 把工作拆成短任务，并写清文件路径与验收标准
• Manager 按任务派发 sub-agent，并用状态追踪推进进度
• Reviewers 先看 spec 合规，再看代码质量
• Verification gate 要求新鲜的终端输出（测试、构建、脚本结果）

这样做的价值是：把 AI agent 从“会写代码”升级为“可控、可验证的工程系统”。

---

关注 AI拉呱

如果这篇内容对你有启发，欢迎关注「AI拉呱」，获取更多 AI 前沿洞察、实战教程与趋势解读。

下期在看

下期将继续带来该主题的进阶拆解与实操案例，建议先收藏本文，避免错过更新。