用子代理团队打造“高级工程师”在 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/是管理层把流程“自动化地强制执行”2Hooks管理层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映射真实产品团队的节奏探索项目上下文文件、文档、近期提交必要时提供视觉辅助白板/图一次只问一个澄清问题目的/约束/成功标准提出 2–3 个方案 取舍 推荐分段呈现设计并逐段确认把设计文档落盘并提交自审 spec占位符/矛盾/歧义用户审阅书面 spec进入实现调用 writing-plans skill这里真正“高级”的点不在清单本身而在执行方式一次只问一个问题尽量用多选题每条消息只包含一个问题这是典型的资深工程师式沟通把对齐做扎实再开始写。6从设计到交付计划→派发→评审→验证当 spec 得到批准后系统进入“交付流水线”Tech Lead 把工作拆成短任务并写清文件路径与验收标准Manager 按任务派发 sub-agent并用状态追踪推进进度Reviewers 先看 spec 合规再看代码质量Verification gate 要求新鲜的终端输出测试、构建、脚本结果这样做的价值是把 AI agent 从“会写代码”升级为“可控、可验证的工程系统”。关注 AI拉呱如果这篇内容对你有启发欢迎关注「AI拉呱」获取更多 AI 前沿洞察、实战教程与趋势解读。下期在看下期将继续带来该主题的进阶拆解与实操案例建议先收藏本文避免错过更新。