🎯 学如何用 gstack 构建 AI 原生的工程团队：不是"用 AI 辅助开发"，而是以 AI Agent 为工程团队的正式成员——从 Think→Plan→Build→Review→Test→Ship→Reflect 的完整闭环由人 + 40+ AI Agent 协作完成。理解 AI 如何改变团队结构、开发速度和工程质量的关系。 ⏱️ 预计时间：35 分钟
[!tip] 💡 白话小课堂 AI原生工程团队不是"用AI写代码"，而是把AI当作团队的正式成员。传统团队10个人的活（写码+审查+测试+部署+安全），3个人+AI就能干完——人负责"想清楚做什么"，AI负责"把事做完做对"。记住一个公式：3人+40个AI Agent ≈ 传统10人团队产出。
[!warning] ⚠️ 避坑指南 别指望AI自动做出好架构决策。AI能审查代码、跑测试、扫描漏洞，但不能替代你做"为什么这么做"的判断。人永远是最关键的决策者——把精力花在定义问题和做关键权衡上，而不是审查代码格式。
[!info] 🔑 核心秘诀 AI负责广度（检查所有代码行、所有测试场景），人负责深度（关键架构决策、业务权衡）。这就是"3个人+AI > 10个人"的数学原理——AI永远不会累，不会被风格争论消耗精力。
[!quote]- 📖 课程来源 本课为系统设计大师课，内容综合自真实电商工程实践经验，而非单一 Skill 文件。涵盖架构设计、分布式系统、团队管理等高级工程主题。
1. 传统工程团队 vs AI 原生工程团队
传统团队结构
一个典型的产品工程团队： → 1 个 Tech Lead（技术决策 + 架构） → 3-5 个 Senior Engineers（功能开发 + 代码审查） → 1 个 QA Engineer（测试 + 质量保证） → 1 个 DevOps（部署 + 运维） → 1 个 EM（人员管理 + 流程）
瓶颈在哪里？ → 代码审查：1 个 TL 审查 5 个人的代码 → 瓶颈 → 测试：QA 远远不够——永远在追赶开发速度 → 部署：DevOps 是单点——请假 = 无法部署 → 知识传承：Senior 离职 → 大量隐性知识丢失
AI 原生团队结构
一个 AI 原生产品工程团队： → 1 个 Tech Lead + gstack AI 工程团队（40+ Skills） → 1-2 个 Product Engineers（定义需求 + 验收） → gstack 自动处理： - 架构评审（/plan-eng-review） - 代码审查（/review + 7 个专家 Agent） - QA 测试（/qa 三层测试深度） - 部署验证（/land-and-deploy + /canary） - 安全审计（/cso OWASP + STRIDE） → 人专注于：定义正确的问题、做出高杠杆决策、理解用户
关键变化
→ 从"人做所有事"到"人决定方向，AI 做执行" → 从"瓶颈在人"到"瓶颈在想清楚要什么" → 从"隐性知识在人的脑子里"到"显性知识在 learnings 和 CLAUDE.md 中" → 从"速度牺牲质量"到"速度和质量同时提升"
2. gstack 的角色分工
人 + AI 的职责矩阵
| 活动 | 人类 | gstack AI | 协作模式 |
|---|---|---|---|
| 定义需求 | 主导 | /office-hours 辅助思考 | 人决策 |
| 架构设计 | 决策 | /plan-eng-review 评审 | AI 建议，人批准 |
| 代码实现 | 指导 | /autoplan 生成实现计划 | 人定义 scope |
| 代码审查 | 最终批准 | /review 7 专家审查 | AI 发现，人确认 |
| 测试 | 验收 | /qa 自动测试+修复 | AI 执行，人验证 |
| 部署 | 确认 | /land-and-deploy 自动部署 | AI 操作，人监督 |
| 安全审计 | 审查 | /cso 全量审计 | AI 扫描，人评估 |
| 回顾 | 决策 | /retro 数据汇总 | AI 提供数据，人决策 |
关键原则
→ AI 负责广度（检查所有东西）——人负责深度（关键决策） → AI 做重复性工作（100% 覆盖）——人做创造性工作（第一性原则思考） → AI 提供建议（带数据和置信度）——人做最终决定
3. 电商案例：3人AI团队支撑5000万GMV独立站
🛒 实战案例：某DTC品牌独立站（Shopify竞品）由一支3人AI原生团队运营——Tech Lead张明 + 2名全栈工程师 + gstack 40+ Skills。平台年GMV 5000万，日订单峰值3000单，覆盖商品管理、订单履约、支付对接、会员营销全链路。
用 gstack 驱动日常运营：
- 早晨Standup（10分钟）：张明用 /landing-report 查看昨夜15次自动部署的状态 → 发现凌晨2点支付模块hotfix成功上线，P0 bug修复确认 ✓
- 全栈工程师A接手"会员等级权益重构"需求 → /autoplan 生成4阶段实施计划（数据迁移→权益引擎→前端展示→AB验证）→ /pair-agent 结对完成核心权益引擎代码 → /review 发现2个CRITICAL（等级升级阈值边界条件错误、SQL查询缺少租户隔离）→ AUTO-FIX修复后人工确认
- 全栈工程师B处理"库存同步延迟"线上问题 → /investigate 根因分析 → 发现ERP Webhook回调在峰值期排队超时 → Kafka消费线程池从默认16扩到64 → P99延迟从12s降到800ms
- 每次PR自动触发 /review（7专家并行）+ /qa exhaustive + /cso 安全扫描 → 人工审查仅关注3个CRITICAL标记点 → 人均日审查时间从3小时降至15分钟
效果：
3人团队月均交付功能点42个（传统8-10人团队基准为35-40个）
代码审查覆盖率100%（7专家并行，2分钟完成），人工审查仅关注架构和业务逻辑关键点
部署频率：日均15次，变更失败率0.7%（行业基准5-8%）
/health 代码健康度从初始54分持续攀升至86分（6个月趋势）
P0线上故障：6个月内仅1次（支付签名证书过期），MTTR 8分钟
人力成本对比：3人+AI的产效等价于传统8-10人团队（年节省人力成本约150-200万）
🔑 启示：AI原生团队的核心不是"用AI写代码"，而是重新定义人的工作——张明不再逐行审查PR或手动跑回归测试，而是把80%精力投入架构决策和业务方向（会员体系设计、定价策略、供应链整合）。AI负责广度（检查所有代码行、所有测试场景、所有安全漏洞），人负责深度（为什么选择这个定价模型、会员等级如何影响留存、双11扩容方案选型）。3个人+AI不是因为AI有多聪明，而是因为重复性的质量保障工作不再消耗人的注意力——人的时间变成了真正做决策的时间。
4. 动手实践
- 盘点你当前的工程流程：列出你的团队从"想法"到"上线"经历了哪些步骤，每个步骤目前由谁（人还是工具）完成。标出人力瓶颈最大的 3 个环节。
- 设计你的 gstack 最简可行集：从 40+ Skills 中选出 5 个对你团队最有价值的 Skill，写出每个 Skill 解决你什么具体问题。
- 跑一次 mini gstack 演练：用 /review 审查你最近的一个 PR，用 /qa 跑一次测试，比较"人做"和"AI 做"在时间和覆盖度上的差异。
[!tip] 提示：不需要一次引入全部 40+ Skills。从 /review + /qa 开始，让团队体验 AI 带来的质量提升，再逐步引入其他 Skill。
5. 掌握检验
Q1：AI 原生工程团队中，传统团队的代码审查瓶颈在 AI 原生模式下如何被消除？
- A) TL 不再审查任何代码，完全信任 AI
- B) AI 负责广度（所有代码行、所有规则），人负责深度（关键架构决策），审查覆盖率从约 60% 提升到 100%
- C) 通过招聘更多 TL 来分摊审查负担
- D) 放弃代码审查，改为上线后监控
Q2：在 AI 原生团队中，人的职责从"做所有事"转变为"决定方向和做关键权衡"。请举出一个具体场景（如支付安全、双11扩容等），说明哪些事由 AI 完成，哪些由人决策，并解释为什么这种分工能让 3 人团队达到传统 10 人的产出。
Q3：AI 原生团队的日常工作中，一个 PR 从提交到上线经历了哪些 gstack 自动化步骤？请按顺序列出至少 5 个步骤，并说明每个步骤替代了传统团队中什么角色。
Q4：为什么说"知识传承从隐性知识变为显性知识"是 AI 原生团队最大的长期优势？如果一个 Senior Engineer 离职，传统团队和 AI 原生团队分别面临什么局面？
- A) 两者没有区别，都是文档交接
- B) 传统团队：隐性知识随人离开，代码库变黑盒；AI 原生团队：learnings、CLAUDE.md、ADR（ADR：架构决策记录）中已沉淀显性知识，新成员可快速接手
- C) AI 原生团队更脆弱，因为过度依赖 AI
- D) 传统团队更好，因为 Senior 离职前可以把所有人培训一遍
Q5：gstack 的 40+ Skills 覆盖了软件工程全生命周期。假设你现在领导一个 3 人团队建设电商平台，请设计你的 gstack Skill 采用优先级——列出最先引入的 5 个 Skill，并为每个 Skill 说明选择理由和预期效果。
Q6：在 AI 原生团队中，技术债务（Technical Debt）的管理方式和传统团队有何本质区别？
- A) AI 原生团队不会产生技术债，因为 AI 写的代码都是完美的
- B) 没有区别，技术债都靠人工 Code Review 发现
- C) gstack /review 和 /health 在每次 PR 时自动检测技术债信号（死代码、低测试覆盖率、高圈复杂度），实现预防性管理而非事后偿还
- D) AI 原生团队技术债积累更快，因为 AI 代码难以理解
6. 答案
点击查看答案
Q1：B — AI 负责所有代码行和规则的广度检查（7 个专家 Agent 并行审查），人只关注关键架构决策。审查覆盖率从人工瓶颈的约 60% 提升到 AI 的 100%，审查时间从数小时缩短到数分钟。TL 不是不审查，而是从"逐行读代码"变成"确认 AI 标注的关键决策点"。
Q2：以支付安全为例——AI 完成：/cso 全量 OWASP+STRIDE 安全扫描、/review 检查签名验证逻辑和金额单位转换、/qa 跑支付 E2E 测试；人决策：选择支付网关、定义退款策略（部分退款还是全额退款）、评估安全扫描结果中的 HIGH 级别发现是否接受风险。这种分工让 3 人做到传统 10 人的产出，因为 AI 承担了传统团队需要 6-8 个 QA/DevOps/安全工程师才能完成的重复性质量保障工作，把人释放出来做只有人能做的事——定义问题和做关键权衡。
Q3：PR 提交后 → /review（7 专家并行审查，替代人工 Code Reviewer）→ /qa standard（自动化测试，替代 QA 工程师）→ /cso（安全审计，替代安全工程师）→ /ship（创建 PR 和 CHANGELOG）→ /land-and-deploy（自动部署，替代 DevOps 工程师）→ /canary（金丝雀验证，替代运维监控）。全过程人工耗时约 15 分钟，gstack 耗时约 12 分钟。
Q4：B — 传统团队：Senior Engineer 离职带走隐性知识（为什么订单表这样设计、为什么选 Kafka 不选 RabbitMQ、哪些边界条件曾导致线上故障），新成员需要数月口述传承，且永远丢失部分知识。AI 原生团队：每次决策写 ADR（架构决策记录），每次 bug 修复写 /learn（沉淀根因和教训），团队标准记录在 CLAUDE.md 中，新成员读这些显性知识可在数天内上手。
Q5：优先引入的 5 个 Skill 示例：1) /review — 替代人工 Code Review 瓶颈，7 专家并行审查使覆盖率从 60%→100%；2) /qa — 替代 QA 工程师，每次 PR 自动跑集成+E2E 测试；3) /land-and-deploy — 替代 DevOps，自动化部署管线；4) /cso — 替代安全工程师，每次 PR 自动 OWASP（OWASP：开放Web应用安全项目）+STRIDE（STRIDE：微软威胁建模框架）扫描；5) /learn — 建立知识沉淀习惯，将隐性经验转化为团队显性资产。
Q6：C — gstack 的 /review 在每次 PR 时自动检测死代码、测试覆盖率不足、圈复杂度过高等技术债信号，/health 提供 6 维度健康度仪表盘（Tests、Typecheck、Lint、Dead Code 等），使技术债从"积累很久才发现"变成"每次 PR 实时度量"。这是预防性管理而非事后式偿还，与传统团队依赖 TL 经验和定期大扫除有本质区别。
（5/6 通过）
延伸阅读
- [[L6-50-创业深度诊断|上一课：创业办公时间]]
- [[L7-02-事件驱动架构|下一课：事件驱动架构 —— 用"发生的事情"而不是"调用链"来设计系统]]
- [[L6-15-PR代码审查|相关：代码审查系统——AI 审查的深度]]
评论区
共 0 条评论