如何把 Claude Code 变成 AI 工程团队
英文原题：How to Make Claude Code Your AI Engineering Team。Garry Tan 用 G Stack 演示一个核心判断：真正限制 Agent 生产力的不是模型智力，而是团队化流程、角色、评审和可见工具。
课程导航
一、问题引入 / 背景
这支视频不是普通的 Claude Code 入门，而是一个创业者兼工程师把自己的工作方式公开拆开。Garry Tan 先说明，他不是从“AI 很酷”开始讲，而是从多年写代码、做产品、做 YC office hours 的经验出发：如果把模型当成一个会写代码的聊天框，它很快会游走、猜测、写出看似正确但暗中损坏系统的代码；如果把模型放进一个有角色、有流程、有评审、有工具的团队系统里，它才开始稳定地产生真正能落地的工程成果。
视频里的主角是 G Stack，它被描述为一种“薄 harness、厚 skills”的实现。所谓薄 harness，是不要让外层框架变成复杂巨兽；所谓厚 skills，是把 YC 式产品拷问、CEO review、工程 review、设计 shotgun、QA 浏览器、ship gate 等经验固化为可调用的专业能力。换句话说，模型不是被要求一次性“把 App 写好”，而是被要求在一个接近真实团队的流程里逐步推进。
Garry 的演示案例很具体：做一个能帮用户找齐 1099 税务文件的产品。这个想法一开始只是“去 Gmail 找文件”，但在 office hours 的追问、竞品辨析、商业模式推演和浏览器自动化方案比较之后，它逐渐变成一个更完整的 wedge strategy：先解决税务文件收集的即时痛点，再把后续的 CPA 匹配和报税协作变成更大的商业机会。
二、核心概念解释
1. Agent 不是一个更长的 prompt，而是一套工作系统
视频最重要的隐含定义是：Agent 工程的关键不是给模型更多自由，而是给它更清楚的上下文边界和决策流程。普通提示词会让模型直接进入执行，但 G Stack 会先让模型扮演产品合伙人、工程负责人、设计 reviewer、QA reviewer 等角色，每一步都要求产物可审查、可回滚、可继续推进。
2. “薄 harness、厚 skills”意味着框架少做魔法
薄 harness 的价值在于降低系统不透明度。Garry 批评了“把所有东西都藏进巨大框架”的倾向，因为那会让调试、治理和迁移变难。厚 skills 则是把实际经验沉淀为明确命令：/officehours 负责先问尖锐问题，/auto-plan 负责压缩多角色审查，/review 负责像 staff engineer 一样找 bug，/browse 和 /qa 则把浏览器测试和视觉检查变成 Agent 可执行的外部能力。
3. Office Hours 是产品判断，不是需求收集表
演示里的 Office Hours 会追问用户痛点、替代方案、商业模式和可行性。它指出 TurboTax、H&R Block、Plaid 等已有方案为什么没有完全解决问题，并引导 Garry 从“文档聚合器”想到“税务服务漏斗”。这一步的价值不是多写功能，而是决定哪些功能值得写。
4. 浏览器自动化把本地上下文变成产品能力
Garry 特别强调，本地可见浏览器和云端托管浏览器不是一回事。对于 Gmail、银行、2FA、税务文件这样的场景，用户在自己机器上登录，AI 在可见浏览器里导航、下载、截图，往往比 OAuth、Plaid 或云端凭证保管更容易建立信任。这也解释了为什么他要围绕 Playwright 和 Chromium 写 CLI 工具。
三、关键论点 / 实操步骤
步骤一：先让 Agent 反驳你的点子
Garry 没有直接让 Claude Code 写税务 App，而是先运行 Office Hours。它会用六个强制问题重构产品：谁痛、为什么现在、现有方案为何不够、用户愿意为哪一步付费、技术可行性在哪里、失败时如何处理。这个顺序能防止团队一开始就把工程能力花在错误问题上。
步骤二：把“需求”改写成可执行设计文档
在 1099 案例里，初始想法被拆成 Gmail 搜索、银行门户导航、PDF 下载、CPA 邮件识别、用户授权和失败处理。模型不仅写需求，还会指出缺少隐私章节、2FA handoff、错误恢复和信任边界。视频中这个 adversarial review 把设计评分从 6/10 推到 8/10，并自动修复了 16 个问题。
步骤三：用设计 shotgun 并行探索多个界面方向
Garry 选择主 checklist dashboard 后，让多个 Agent 并行生成三种视觉方向：command center、friendly progress、split view。重点不是谁画得漂亮，而是让设计空间在一分钟级别展开，再由人类选择更适合用户心理模型的方向。最后他倾向于有进度环和卡片感的 friendly progress，因为税务文件收集是焦虑型任务，需要可见进展。
步骤四：让 coding、review、QA、ship 分离
视频后半段展示的是 G Stack 的完整 sprint：先 Office Hours，再 auto plan 或 CEO/engineering/design/developer-experience review，通过后才让 Claude Code 写代码；写完后运行 review 找 bug，再用浏览器 QA 检查真实界面和 CSS/JS 问题，最后用 ship 工具确认 PR 是否适合进入 main。这个顺序把“一个 Agent 一口气写完”变成“多个专业角色接力”。
步骤五：并行 PR 不是多开窗口，而是多条隔离流水线
Garry 提到自己会同时运行 10 到 15 个 Claude Code session，甚至一天推进 20 到 50 个 PR。这个数字容易误导，真正的关键是每个任务都有 worktree、计划、评审、QA 和落地门禁。没有这些隔离和门禁，多开窗口只会把风险放大；有了这些结构，才可能把“AI 写代码”扩展成“AI 工程团队”。
四、对比表格 / 决策矩阵
| 模式 | 适用场景 | 优点 | 风险 | 决策建议 |
|---|---|---|---|---|
| 直接聊天 / 一次性 prompt | 查资料、写小脚本、生成一次性文本 | 启动成本最低，适合探索 | 模型容易猜测需求，缺少回顾和 QA | 只用于低风险任务；不要让它直接改核心代码 |
| Claude Code 单 Agent | 明确 bug、局部功能、已知代码库内的小改动 | 上下文在代码目录里，执行力强 | 容易边做边改范围，审查压力回到人身上 | 必须搭配计划、diff 检查和测试命令 |
| G Stack skills 团队流 | 新产品、复杂功能、需要产品与工程判断的任务 | 把产品、设计、工程、QA 和发布拆成角色 | 流程更长，需要维护 skills 质量 | 适合高杠杆项目，是视频推荐的主路径 |
| 本地浏览器自动化 | Gmail、银行、后台系统、视觉 QA、下载文件 | 用户可见、凭证不出本机、能处理真实 UI | 站点变化、2FA、下载权限会带来失败模式 | 把它作为 QA 和受控操作工具，不要假装它永不失败 |
| 多 session 并行 PR | 多个相互独立的 issue、开源维护、批量修复 | 吞吐量极高，适合维护者处理大量反馈 | 供应链攻击、冲突、重复工作和审查债务会放大 | 只有在 worktree 隔离、review、QA、ship gate 完整时使用 |
五、引用块
Garry 的核心判断可以转述为：模型已经足够聪明，真正要补的是围绕模型的团队结构、专业角色、审查流程和可见工具。
这句话值得反复看。它把“升级模型”之外的工作重新放到工程师手里：怎样组织任务、怎样提出反对意见、怎样隔离分支、怎样验证浏览器行为、怎样拒绝不成熟的设计，都会直接决定 Agent 的产出质量。
另一个关键点是：当 AI 接管计划、设计和编码后，人类最容易被剩下的 QA 淹没，所以 QA 本身也必须成为自动化的一等公民。
从视频抽出的实践清单
先问难题。 每个新想法先跑产品 office hours，要求模型证明痛点、替代方案和商业模式，而不是直接生成 backlog。
并行出方向。 对复杂 UI 让多个 Agent 给出不同方向，再由人类选择，而不是让一个 Agent 一路微调到审美疲劳。
计划先锁定。 代码前要有可审查计划，计划被 adversarial review 打过一轮之后再进入实现。
浏览器是真相。 对前端、表单、下载、权限、视觉状态，不能只靠静态代码审查，必须让 Agent 操作真实浏览器。