开源HarnessXP框架：AI Native企业级跨仓多技术栈遗留代码项目迁移到驾驭工程开发，你可以放弃openspec/superpowers了|优普丰助力企业AI落地

admin — Tue, 28 Jul 2026 02:33:09 +0000

开源这个框架的起因

上个月，一个朋友跟我吐槽：他们组 5 个 Claude Code agent 一起干活，后端 agent 把 API 字段改了，前端 agent 完全不知道，联调挂在生产环境。

我问他：”你们不是用 git 协作的吗？”

他说：”用了。但 git merge 退出码是 0，分支 tip 就是没进 main。下次部署就是旧代码。”

这其实是所有跨 2 个以上仓库跑 AI agent 的团队都会撞上的三面墙。今天介绍一个工具 HarnessXP，三面墙一起拆。

项目作者是XP多年实践者，一开始是为了迁移和统一自己的已有的3个项目代码（小程序、后端服务、管理员网站）。后来越搞越大，最后相当于自己弄出来一套openspec commands。一开始确实是想直接用openspec的，后来发现他跨不了仓，然后就在chatGPT和ClaudeCode的帮忙下，自己搞出来一套跨仓的SDD框架。改业务代码过程中，就碰到各种bug，一边儿改代码儿，一边儿修这些命令，就弄出了这么个项目，剥离了业务代码，开源给社区供大家学习和参考。地址：https://github.com/mebusw/HarnessXP

5分钟上手

# 1. 拉框架git clone https://github.com/mebusw/HarnessXP.gitcd HarnessXP# 2. 初始化新项目（在干净父目录）mkdir my-project && cd my-project../HarnessXP/bin/init \  --name my-project \  --repo backend:../backend:service:node \  --repo web:../web:web:react \  --repo mobile:../mobile:app:flutter# 3. 把你的共享契约放进 orchestrator 的 shared/cd orchestrator# （把 openapi.yaml / types.ts / config.schema.json 丢进 .openspec/shared/）# 4. 同步契约到所有业务仓bash .openspec/swarm/sync-shared.sh all# 5. 启动 spec-driven workflowclaude> /spec USER_AUTH> /plan USER_AUTH> /swarm USER_AUTH> /merge USER_AUTH

蓝图

Harness Engineering ← 方法论

HarnessXP ← 开源框架

Specification Gravity ← 核心理论

AI-Native Harness Engineering for Polyrepo & Polyglot Development ← 愿景

跨仓开发的几个典型踩坑

坑一：合约漂移 —— 后端改了字段，前端到生产才挂

想象一下这个场景：

后端 agent 收到指令：”把 /api/users 的 email 字段改成 contact_email。” 它很快把后端代码改了，单元测试通过，提 PR，merge。

前端 agent 同时在另一个仓库登录页面。它不知道 email 改名了，照样发 email。联调在 staging 没跑过（前端的 spec 没同步），部署到生产，挂了。

合约漂移的本质：spec 和代码在不同的仓，改 spec 的 agent 和改代码的 agent 不沟通。

HarnessXP 的解法很直接 —— 把 spec 和共享合约集中到一个 orchestrator 仓。N 个业务仓持有代码，但所有”跨仓接口”必须在 orchestrator 仓里登记。M 个 agent 开工前先读 orchestrator，改完接口必须同步更新 orchestrator 仓。

💡 核心思路： 让”接口是什么”这件事只有一个真理来源。Agent 之间通过共享合约沟通，不通过 git commit 历史沟通。

坑二：状态无人负责 —— “特性 X 做到哪了？”

你问 PM，PM 说：”我以为前端在做。”

你问前端，前端说：”我看 PR 在后端那边挂着。”

你问后端，后端说：”我 merge 了呀。”

规格在仓 1，代码在仓 2，评审在仓 3，状态在某个人的脑子里。这是多仓 AI 协作最常见的死法 —— 状态没有归属，问谁都是”以为在别人那里”。

HarnessXP 用一个 4 态状态机解决：PROPOSED → IN_PROGRESS → REVIEWED → MERGED。每个跃迁由且仅由一个工具负责：

PROPOSED：spec 在 orchestrator 仓登记完毕
IN_PROGRESS：某个 agent 拿到这个 spec，开始改
REVIEWED：CI + 跨仓合约校验通过
MERGED：merge-all.sh 二次校验成功

任何时刻问”特性 X 的状态”，工具直接告诉你。不需要去问 PM、前端、后端。

💡 核心思路： 不要让人去维护状态，让工具去维护。状态机的价值不是机器本身，是”每个跃迁有且只有一个负责人”。

坑三：幽灵合并 —— git merge 退出码 0，但 tip 没进 main

这是最阴险的一个。

CI 全绿。PR 合并按钮显示 “merged”。git log main 也有这条 commit。看起来一切都好。

但下次部署，CI 跑的是旧代码。仔细看 git log main，发现这条 commit 在 main 上的位置比某个 feature 分支还老 —— 它根本不在 main 的 head 链上。

常见原因：rebase 出错、cherry-pick 错乱、force push 覆盖。git merge 的退出码 0 只能告诉你”本地操作没出错”，不能告诉你”这次合并真的进了 main 的 head”。

HarnessXP 的解法是 4 行 bash：

git fetch origin mainif git merge-base --is-ancestor "$BRANCH_TIP" origin/main; then  echo "OK: tip is in main"else  echo "FAIL: phantom merge detected"fi

git merge-base --is-ancestor 做的事就是：检查 $BRANCH_TIP 是不是在 origin/main 的祖先链上。如果不是 —— 合并看起来成功但 tip 没真进 main —— 就是幽灵合并。

每次 merge-all.sh 跑都对每个 PR 做这个二次校验。

💡 核心思路： 不要相信退出码，相信祖先链。CI 验证的是”代码能不能编译”，merge-base 验证的是”代码有没有真的进 main”。

架构：1 orchestrator + N 业务仓 + M agent

HarnessXP 整体架构极薄，由三部分组成：

1 个 orchestrator 仓：所有 spec、共享合约、状态机记录都在这里
N 个业务仓：每个仓独立 git 仓库，代码在这里
M 个 Claude Code agent：每个 agent 有严格的”允许修改的文件”边界，跨边界读写需要走 orchestrator

agent 之间通过共享合约沟通，不通过 git commit 历史沟通。这避免了”我看你昨天改了什么”这种脆弱的协调方式 —— 后者只在单仓有效，跨仓立刻失效。

结语

HarnessXP 是 MIT 协议，bash 3.2 兼容，macOS 开箱即用。仓库：https://github.com/mebusw/HarnessXP

如果你也在跨多仓跑 AI agent，欢迎试用、提 issue、扔 PR。

💬 讨论

你们今天是怎么处理幽灵合并的？是靠 CI 兜底，还是已经有专门的合并校验？评论区聊聊。

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

驾驭工程（Harness Engineering）先行者

优普丰AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

【经验实录】跨3仓遗留代码迁移到AI编码工程，1个月踩坑提炼6条铁律，逼出企业项目驾驭工程智能体的进化方法论|优普丰助理企业AI落地

admin — Tue, 28 Jul 2026 02:29:43 +0000

这不是又一篇”AI 写代码提效 10 倍”的爽文。这是一份真实工程实录：4 个遗留 git 仓、3 套异构技术栈、生产上跑着的服务。我们花了一个月，搭了一套叫 Harness Engineering 的脚手架，让 AI 能在遗留系统上可控地演进，而不是 vibe coding 玩一玩。写给正在评估”AI 编码能不能用在我们这种企业遗留系统上”的技术负责人、架构师、研发管理者。

一、先给你看个画面

如果你的企业里存在这样的场景，这篇文章就是为你写的：

你接手了一个项目。打开 git 一看：3 个仓——一个 Express.js 后端（带一堆历史遗留的 Liberating Structures 内容库），一个微信小程序（视频课程平台是叠在”线下课报名”老小程序上的），一个 AngularJS 管理员网站。

每个仓各自的 main 分支、release tag、CI pipeline、部署节奏都不一样。改 1 个 API 字段要 3 个仓联动，前端先上线、后端 API 还在部署——用户立即看到 500。

新需求：把这套跑了 3 年的老系统，演进成视频课程平台。

这时候你跟 AI 说：”帮我加个视频课程模块。”

AI 会回你一份”理想新系统”的设计稿——跟你手里这套老代码完全对不上。

这就是 vibe coding 的天花板。

它适合从 0 写 demo、做 side project、做学习练手。它不适合企业里”老房子改扩建”这种真实工程。

那么，AI 编码在企业遗留系统上到底能不能用？

我们用一个月的时间，把这件事跑通了。答案不在模型本身，而在我们搭的脚手架——我们叫它 Harness Engineering。

二、Harness Engineering 是什么、不是什么

不是：

不是 prompt 工程（”你应该这样和 AI 说话”）
不是选模型（GPT 还是 Claude 还是 Gemini）
不是装个 IDE 插件（Cursor / Copilot / Claude Code）
不是从 0 开始搞 vibe coding demo

是：

让 AI 在你的工程里”按规矩办事”的一整套脚手架。

类比软件工程发展史——传统软件工程有这些环节：

需求分析 → 系统设计 → 编码规范 → 代码审查 → 自动化测试 → CI/CD → 灰度发布 → 监控告警 → 应急修复

我们没发明新东西，这套流程一个都没丢。只不过执行主体从”人”变成”人 + Agent”——人不再只写代码，人写让 AI 写出来的代码能可控地汇入主干的状态机、目录约定和脚本。

一句话总结我们的元经验：

当 AI Agent 接管了”写代码”这件事之后，工程师的工作不是写更多代码，而是构建”让 AI 写出来的代码能可控地汇入主干”的状态机、目录约定和脚本。这套基建写不好，Agent 跑得越快，烂摊子越大。

我们 2026-06-09 一上午提交了 11 个 commit。没有一个是写业务的——全部都是在补齐 swarm 框架的状态机、文件命名、bash 兼容性、跨仓路径。

如果你看到这里还有共鸣，下面回答你最初关心的 3 个问题。

三、问题 1：怎么让 Agent 生成的代码”满足需求”？

3.1 需求分析：你得先搞清楚，再让 Agent 搞清楚

企业遗留系统的 AI 编码必须先冻结”哪些是基线、哪些要演进”。否则 AI 会把遗留代码当”待清理对象”——你的 LS 内容库、用户中心、线下课报名这些已存在业务，会被 AI 误判为”可以重构的新模块”。

我们的做法是冻结基线：开新会话的第一件事，跑 /release-skills（一个独立 skill，不在 7 个 slash command 之列）给当前 git 状态打一个 release candidate tag（带 release notes），把”哪些是已有事实、哪些是新增需求”钉在 tag 的 release notes 里，类似这样：

以 3 个仓的遗留代码和已实现的功能作为基础，继续开发视频课程平台功能。

公开遗留的 LS 内容库 API（保留不动）

mp-app 视频平台是在”线下课报名”老小程序上叠的

已实现 API / feature 以 shared/openapi.yaml 为准

3 个仓各自的 CLAUDE.md 是遗留代码的总览

💡 Actionable Tip： Agent 不怕你啰嗦，怕你不说。你觉得显然的东西，对它一点都不显然。每次开新会话，第一件事就是把”哪些是基线、哪些是演进”写清楚。

3.2 系统设计：拆 spec 不是”想新系统”，是”扫老代码”

我们第一版用”理想新系统”思路拆出了 7 个 spec（认证、课程目录、订单、支付……），打完 RC tag 回到目录读 release notes，立刻发现两个偏差：

整个缺失”优惠券”（用户当面点出来）
整个集合过于”理想化”，完全没体现 LS 遗留域、用户中心、内容管理、线下课报名这些已存在业务

立刻回炉，最终落地 13 份 spec，按 4 类组织：

平台核心：AUTH / ORDER / PAYMENT
演进型（已存在但需明确）：LIVE_COURSES / VIDEO_COURSES / USER_PROFILE / USER_MANAGEMENT / MEDIA_UPLOADS
遗留 LS 内容域：STRUCTURES_CONTENT / STRINGS_GROUPS / CONTENT_ENGAGEMENT（保留但不再主动改）
新增（gap）：COUPON_PROMOTION / PROTOTYPE_TOOL

💡 Actionable Tip： 拆 spec 必须用真实代码与真实接口作证据，而不是凭需求文档”自上而下”命名。backend/index.js + backend/models/*.js 是事实之源，需求文档只是输入。

3.3 把”不要碰”写在契约里，不是写在文档里

遗留代码的”存在感”会不断干扰 AI 的判断——”我看到这段代码，是不是要重构它？”

我们的做法是：把 EntryWriteRequest / EntryContent / EntryGroupWriteRequest 这类 schema 显式打上”遗留的 liberating-structures 小程序接口，非当前视频平台核心需求”的 description 备注，并在 info.description 写明项目分层。

用 OpenAPI 的 tags: [Platform Core] / [Legacy LS Content] 给 AI 立边界，比写在 CLAUDE.md 里更难被忽略。

3.4 路由 ≠ 已实现

这条是血泪教训。

我们反推 openapi.yaml 时，backend/index.js 里挂了 30+ 个路由，但实际模型里只实现了 17 个。最终用户会把这个”假实现”当真——上线就崩。

💡 Actionable Tip： 扫 openapi 时必须同时扫 routes/*.js + models/*.js，区分”已实现”vs”只在路由里挂名”。请求 schema 加 additionalProperties: false，从宽松的 type: object 收紧到后端真实读取的字段。

3.5 永远做覆盖率审计

多仓遗留系统的 spec 集不是”写完即完”。我们做完 13 份 spec 后，对照原始需求 v5 文档做需求→spec 覆盖率矩阵，发现：

COUPON_PROMOTION 是用户当面点出来才补的
SCRM_ENGAGEMENT / REFERRAL_TRACKING / COURSE_SCHEDULE 三个 gap 还在

不审计，一定漏。

四、问题 2：怎么减少上线后的不稳定、减少紧急修复？

4.1 拆分细了才好审查

不管多大的功能，都要在 plan 阶段拆成”每次提交做一件事”的粒度。原因很简单：

拆分细了，审查的人（包括你自己）才能看得过来。单仓内 rebase + 跨仓 release gate，三步到位。

可以先让 Agent 审查，但人要兜底。Agent 审查能抓住格式、命名、明显的逻辑错误，但业务逻辑对不对、边界条件有没有漏，这些还是得人来判断。

我们的 reviewer agent 有个硬约束：REQUEST_CHANGES 不是失败，是”拦截越界”。6/23 admin-courses 表格的 task 改到 course-detail / shared forms 已经是 forbidden 路径，reviewer 喊停是职责所在，不是流程摩擦。

4.2 自动化测试覆盖

这是减少线上事故最直接的杠杆。

单元测试：给 Agent 即时反馈的基础——它改了代码跑一下测试就知道有没有破坏已有功能。

集成测试：单个模块测试通过不代表组装在一起也没问题。用模拟数据把主要流程的集成测试覆盖起来。

CI 集成：单元 + 集成测试要跟 CI 集成，提交就自动跑，不要依赖人手动触发。

端到端测试：直接连测试环境或正式环境，通常没那么稳定，但可以代替大部分人工测试。现在有 AI 加持的 browser use 工具，写端到端测试比以前容易很多。

最后一点：自己多测试，不要过于信任 AI，尤其是关键路径和涉及钱的流程。

4.3 灰度发布 + Feature Flag

新功能不要着急全量上线。先给内部人用，测试没问题了再逐步扩大范围。加上 feature flag 开关，有问题随时关闭，不用等发版。

4.4 CI/CD：回滚速度决定事故影响范围

建立自动化部署、发布和回滚机制。修复了问题能以最快速度自动化验证和发布；出了严重问题第一时间回滚到稳定版本。

4.5 “Phantom merge” 必须正向校验

这是我们 2026-06-22 踩的一次大坑：OFFLINE_COURSE_SYNC-007 registry 里标 MERGED，但实际 branch tip没在 admin master 里。

原因：merge-all.sh 的 merge 命令看似成功（exit 0），但实际 push 失败 / merge commit 没真生成 / 后被 force-push 覆盖。

修复：

git merge --no-ff feat/$BRANCH -m "merge: $TID"
# 关键新增：merge 完成后立刻 verify
if ! git merge-base --is-ancestor HEAD origin/$DEFAULT_BRANCH; then
  git reset --hard HEAD~1   # rollback
  exit 1
fi

💡 Actionable Tip：“merge 成功”≠”代码真的进了 main”。 当脚本链条超过 5 步，必须在最后一步做正向校验（ancestor / build / test），不能相信中间步的 exit code。

可选 BUILD_CHECK=1（默认 0）：merge 后跑 ng build / npm test，失败同样 rollback。

五、问题 3：怎么让 AI 自行复现、debug、修复线上 bug 并提交 PR？

5.1 先说现实路径

说实话，让 AI 全自动修线上 bug 听起来很美好，但目前更现实的路径是：AI 辅助定位问题、生成修复方案、人来确认后再提交。

全自动闭环修复，对大多数团队来说还不成熟。建立好的开发、测试、发布流程比追求全自动化更重要。

但即便走”AI 辅助 + 人确认”这条路，前置基建也必须做：

5.2 记日志：没日志一切免谈

补充一点：日志要结构化，要有足够的上下文信息（请求 ID、用户 ID、关键参数、关键状态）。

这样 Agent 拿到日志才能还原现场。否则给它一堆无意义的 print 输出，它也分析不出什么。

5.3 能重现和验证

建立一套和生产环境尽量一致的测试环境，能重现问题、能验证修复。

没有重现环境，Agent 只能靠猜，修出来的东西你也不敢上线。

5.4 CI/CD：不要修一个 bug 搞出三个新问题

修 bug 本身可能很简单，但自动化测试跑通了再合并，这个纪律不能省。

5.5 `/hotfix` 命令：主控在 crisis 时的逃生通道

我们加了一个 /hotfix 命令，追溯式生成 task spec + handoff + review + registry MERGED。

适用条件有 4 个 ✅（全打勾才能走）：

bug 阻断 P0 交易
改动 ≤ 5 个文件
不跨仓
不动 .openspec/shared/ 跨仓契约 + 不动 .openspec/specs/ 业务规格

任一不满足就走正规流程。/hotfix 不是”事后补单据”，是”主控 Claude 在 crisis 时的逃生通道”——4 个 ✅ 是为了避免 /hotfix 命令被滥用为”随便写点东西”。

首个真实案例：PAYMENT-008（mp-app commit 0b8e51f，2026-06-22 retroactive 补登记）。

5.6 Session 中断必须可恢复

P0 bug 在凌晨来的时候，最容易出 session 429 中断。我们 6/19 凌晨 ADMIN_POLISH_V3 就中过一次。

做法：写 SESSION_INTERRUPT_.md 到 handoff//，下次重启时第一件事读这个。内容 5 段：已交付 / 中断（partial）/ 未开始 / Registry 状态 / Resume 指令。partial 段的代码不能 stash / reset，直接让新 agent 读 diff。

💡 Actionable Tip： 与其追求 AI 自己修 bug，不如追求 AI 帮你少写 bug。前面说的需求分析、系统设计、测试覆盖、代码审查做好了，需要紧急修的 bug 自然就少了。

六、swarm-orchestrator 工程解剖

上面回答的是”为什么”和”怎么做”。下面给你看”长什么样”——把我们搭的脚手架原原本本摊开。

6.1 仓库布局：4 个仓的分工

~/work/001 优普丰课程平台多仓AI编码工程/
├── swarm-orchestrator/    ← 4 号仓（Source of Truth，不写业务代码）
├── mp-app/                ← 1 号仓（WeChat 小程序）
├── backend/               ← 2 号仓（Express 后端）
└── admin/                 ← 3 号仓（Angular 管理后台）

业务仓里没有.openspec/。Subagent 写交付物时不会污染业务仓的 main 分支——这是通过 worktree 内的 symlink 桥接实现的（详见后文）。

6.2 swarm-orchestrator 内部结构

swarm-orchestrator/
├── .openspec/
│   ├── specs/             # 13 份 feature spec
│   ├── plans/             # 每个 feature 的实施 plan
│   ├── tasks//   # 每个 task 的详细 spec
│   ├── handoff// # Subagent 的交付物
│   ├── reviews// # 跨仓一致性 review
│   ├── registry/          # agents.yaml + tasks.yaml
│   ├── shared/            # 跨仓契约（openapi / types / config）
│   ├── swarm/             # 5 个核心 bash 脚本
│   └── templates/         # spec / plan / task / handoff / review 模板
├── .claude/
│   ├── agents/            # 6 个 subagent prompt
│   └── commands/          # 7 个 slash command
├── CLAUDE.md              # 跨仓宪法（路径硬规则 + 失败模式速查）
└── README.md              # 仓库布局 + 操作步骤

6.3 6 个 subagent：每个角色都有清晰的边界

.claude/agents/ 下有 6 份 agent prompt，每一份都是这个角色专属的工作环境 + 边界 + 产出模板：

① architect.md — 跨仓契约 owner。

独占权：.openspec/shared/openapi.yaml、.openspec/shared/types.ts、.openspec/shared/config.schema.json、.openspec/plans/**、.openspec/tasks/**
产出：读 spec → 写 plan → 拆 task → 更新 registry/tasks.yaml（每个下游 task 标 app_repo）→ 写 .openspec/shared/openapi.yaml → 写 handoff
铁律：禁止改 ../mp-app/、../backend/、../admin/ 下任何文件；禁止 push main

② backend-agent.md — Express 后端实现者。

工作目录：../backend/wt-/
第一件事：把跨仓契约从 orchestrator 拉到 types/（openapi.yaml + types.ts + config.schema.json）
改 models/utils/index.jstest/，push 到 feat/ 分支

③ miniprogram-agent.md — WeChat 小程序实现者。

工作目录：../mp-app/wt-/
跨仓契约拉下来后，types.ts 会被改成 .d.ts + 注释结构（小程序对 TS 不友好）
改 pages//，push 到 feat/ 分支

④ admin-agent.md — Angular 管理后台实现者。

工作目录：../admin/wt-/
多一步：npx openapi-typescript 自动把 openapi.yaml 转成 TS 客户端（生成 src/app/shared/api-types.ts）
改 src/app/modules/、src/app/store/、push 到 feat/ 分支

⑤ docs-agent.md — API 文档生成者。

不写业务代码，只写 API 文档到 .openspec/docs/**
边界明确：shared / plans / tasks 都是 architect 独占，docs-agent 不碰

⑥ reviewer-agent.md — 跨仓一致性 reviewer。

只读 + 写 review，不写代码
跨仓一致性 checklist：API 字段一致 / Type 一致 / Auth 一致 / 错误码一致 / 跨仓写边界 / 编译测试真跑过
硬约束：1:1 review-per-task 约定——每个被 review 的工作 task 都必须有自己的 review file，缺一个 → 该 task 永远 stuck 在 REVIEWED 不入 main
文件名严格用 .md，不带 -review / -umbrella / -stub 等后缀

6.4 7 个 slash command：从 spec 到 merge 的完整闭环

.claude/commands/ 下有 7 份 slash command prompt，每一份都是一段状态机切片：

① spec.md — 写需求

读用户口述 → 加载 spec-template.md → 跟用户确认 4 件事（涉及哪几个端 / 是否需要 architect 先做跨仓契约 / 是否需要 e2e / Done Definition 是什么）→ 写入 .openspec/specs/.md。

下一步：/plan 。禁止直接 /swarm——没 plan / tasks.yaml 时 swarm 没东西可调度。

② plan.md — 拆 plan + 拆 task

读 spec → 加载 plan-template.md / task-template.md → 起 architect subagent → 校验（plan 文件存在 / 每个 task 列 Allowed/Forbidden / tasks.yaml 有 app_repo 字段 / app_repo 合法 4 选 1）→ 同步 registry status。

关键差异（vs monorepo 版）：多一个字段 app_repo；跨仓契约统一在 .openspec/shared/，plan 必须列哪些 task 是 architect 独占的。

③ swarm.md — 调度

读 registry → 拓扑排序（按 depends_on）→ 跑 create-worktrees.sh（按 app_repo 分组，在各自业务仓里建 worktree）→ 跑 sync-shared.sh all（业务仓拉最新契约）→ 起 Subagent（注入 HANDOFF_DIR / REVIEW_DIR / SHARED_DIR 环境变量）→ 聚合结果。

如果 FEATURE plan 包含 umbrella reviewer task（FEATURE-，owner = reviewer-agent），那么 /swarm 阶段已经一次性完成 review：reviewer 写 1:1 review files + 同步 tasks.yaml status → REVIEWED。不需要单独跑 /review。

④ review.md — 跨仓一致性 Review

只适用于以下场景：

老式 plan 风格（plan 里没有 umbrella reviewer task）
hotfix 后重审（REQUEST_CHANGES → APPROVED 后需要刷新 review file）
手动 review 路径

⑤ merge.md — 跨仓 merge

按 tasks.yaml 拓扑顺序 + app_repo 分组，把 APPROVED 的任务分别 merge 到 3 个业务仓的 main。

关键纪律：

不带参数：处理所有 APPROVED 的 task
带 FEATURE：只处理该 Feature
前置校验：每个 task 必须 status: REVIEWED，否则跳过并打 ↷ X: status=IN_PROGRESS，not yet REVIEWED，跳过 merge
跨仓 release 协调：backend → 等部署 OK → mp / admin
脚本默认不暂停（RELEASE_GATE=0），要开 gate 跑 RELEASE_GATE=1 bash merge-all.sh

⑥ status.md — 一张表看全

读 tasks.yaml registry status → 列跨仓 worktree → 列 handoff 落地 → 列 review 状态 → 跑契约一致性检查。

输出示例：每个 task 按 ✓ / ⏳ / ✗ 三个状态色展示，按 app_repo 分组——主控一眼能看出哪些 task 卡在哪。

⑦ hotfix.md — P0 hotfix 追溯式补全

⚠️ 专为”来不及走正规流程”的 P0 hotfix 设计。 严禁把 normal-flow 任务伪装成 hotfix 走本命令——会绕过 reviewer-agent 的质量门。

适用条件 4 个 ✅（全打勾才能走）：bug 阻断 P0 交易 / 改动 ≤ 5 个文件 / 不跨仓 / 不动 .openspec/shared/ + .openspec/specs/。

追溯式生成：task spec + handoff + review（强制 APPROVED retroactive）+ 追加 registry MERGED。

6.5 跨仓 symlink 桥：handoff 不污染业务仓

这是企业遗留系统能放心让 AI 写代码的关键设计：

业务仓里没有.openspec/。Subagent 写交付物时如果用相对路径（.openspec/handoff/...），要么落到业务仓 main 分支（污染），要么报错。

解决：create-worktrees.sh 给每个业务仓的 worktree 自动建一个 .openspec symlink：

ln -s ../../swarm-orchestrator/.openspec  backend/wt-auth-002/.openspec
ln -s ../../swarm-orchestrator/.openspec  mp-app/wt-auth-003/.openspec
ln -s ../../swarm-orchestrator/.openspec  admin/wt-auth-004/.openspec

Subagent 在 wt- 里写 .openspec/handoff/AUTH/AUTH-002.md → 实际写到 orchestrator 仓。handoff / reviews 永远在 orchestrator 落地，不污染业务仓 main。

orchestrator 自己的 worktree（wt-auth-001-arch、wt-auth-005-doc）不走 symlink，因为 .openspec/ 本来就在仓里。

6.6 跨仓契约”单一真相源”

.openspec/shared/ 是唯一的接口事实之源：

openapi.yaml — API 字段 + 路径 + 类型
types.ts — TS 类型定义
config.schema.json — 跨仓配置 schema

权限表：

architect agent → 唯一能写的人
其他任何人 → 只读
业务仓需要时 → 走 bash $ORCHESTRATOR_ROOT/.openspec/swarm/sync-shared.sh 拉取

Subagent prompt 里明确写：

禁止在 mp-app/types/ 或 backend/types/ 直接写跨仓类型，只能跑 sync 脚本。

这是 3 仓版本能 work 的核心机制。没有这层”单一真相源 + sync 拉取”，3 仓独立就退化成”3 份维护负担”。

七、4 个 commands 的演进（这一个月发生了什么）

脚手架不是一天搭好的。下面是 7 个 slash command 一个月里的演进路径，每一步都有具体 commit 和真实教训。

7.1 第 1 周：spec / plan / swarm / review / merge / status 6 件套打地基

最初的 monorepo 模板只有 /spec /plan /swarm /review /merge 5 个。6/6 拆 4 仓时加了 2 个字段（app_repo + handoff 路径硬规则）。

最关键的设计是主控永远在 orchestrator。README.md「Where to run claude」表里写：

写需求 / 拆 plan / 启动 swarm：swarm-orchestrator/ → claude → /spec /plan /swarm /review /merge /status改业务代码（不通过 swarm）：mp-app/ 或 backend/ 或 admin/ → cd <业务仓> && claude改 agent prompt：直接编辑 swarm-orchestrator/.claude/agents/改 slash command：直接编辑 swarm-orchestrator/.claude/commands/

核心规则：主控永远在 orchestrator。不要在业务仓直接 claude 跑 /swarm 之类的主控命令。

7.2 第 2 周：status 字段 + handoff 命名严格化

最初 tasks.yaml 里没有 status 字段，”哪个 task 已合并”靠人脑或 grep handoff 文件。结果 /swarm 把已合并的 task 又起了一遍 worktree，/merge 在已删除的分支上 rebase 报错。

修法：先把状态机写死：

# status 枚举：
#   PROPOSED      —— 已建任务，未起 agent
#   IN_PROGRESS   —— launch-agents.sh 起 agent 时改写
#   REVIEWED      —— /review 写完且 APPROVED 后改写
#   MERGED        —— merge-all.sh 成功合并后改写

然后把”谁改哪个状态”分摊给 4 个 slash command 的 prompt：

/plan 创建 task = PROPOSED
/swarm 起 agent = PROPOSED → IN_PROGRESS（脚本里 python 原子改 yaml）
/review 写完 = APPROVED → REVIEWED / REQUEST_CHANGES → IN_PROGRESS（review skill prompt 内嵌 python 多行脚本）
/merge 合并成功 = REVIEWED → MERGED（merge-all.sh 改 yaml）

元经验：状态机不要交给主控 Claude 维护，要切片分给每个负责执行的 skill。主控不可能记住 4 个状态转换发生在何处，但每个 skill prompt 都能在自己那一格做”原子的状态推进”。

同时把 handoff 文件命名严格化：.md，不带 owner 后缀（-arch / -api / -mp / -admin / -doc / -review / -umbrella 一律不用）。owner 信息落文件正文 ## Owner 段。脚本里删了 owner-suffix fallback——约定不够，必须代码强制。

7.3 第 3 周：umbrella reviewer + `/swarm` 一体化 `/review`

老 reviewer 写 1 个 umbrella 算完 → merge 阶段 skip 了 3 个 task。修法：

新规则——1 个 umbrella reviewer 任务 = 写 1 个详细 umbrella + N 个 per-task stub。每个 stub 必须含 **APPROVED**（或 REQUEST_CHANGES）in ## Decision 段。缺一个 stub → 该 task 永远 stuck 在 REVIEWED 不入 main。

自检脚本（每个 reviewer 任务完成前必跑）：

for f in .openspec/tasks/FEATURE/*.md; do
  tid=$(basename "$f" .md)
  rf=".openspec/reviews/FEATURE/$tid.md"
  if ! awk '/^## Decision/{flag=1; next} /^## /{flag=0} flag && /\*\*APPROVED\*\*/{found=1; exit} END{exit !found}'"$rf"; then
    echo"✗ NO '**APPROVED**' in Decision section: $rf"
  fi
done

收益：从”3 步等用户”变”2 步等用户”，省一次 slash command 调用 + 一次 subagent 启动。/swarm 命令的”下一步”从 /review 改为 /merge。

7.4 第 4 周：`/hotfix` 命令 + P0-P2 hardening

P0 bug 阻断交易时，来不及走 /plan→/swarm→/review→/merge 全流程。业务仓已经直接 commit 了，事后需要补 audit trail。

解法：新 /hotfix 命令，追溯式生成 task spec + handoff + review + registry MERGED。首个真实案例：PAYMENT-008（mp-app commit 0b8e51f，2026-06-22 retroactive 补登记）。

同步落地的 P0-P2 hardening 6 项：

P0-1：phantom merge guard — merge-all.sh merge 后 verify git merge-base --is-ancestor HEAD origin/main，否则 rollback
P0-2：可选 BUILD_CHECK=1 — merge 后跑 ng build / npm test，失败 rollback
P1-3：worktree 路径校验 — create-worktrees.sh 拒绝 ../admin（应是 ../admin/wt-）
P1-4：枚举统一 — handoff Status 段 4 态，review Decision 段 3 verdict，模板与 schema 用同一组枚举
P2-5：APPROVED 检测精确化 — 9 种历史格式兼容，避免”previous APPROVED inside REJECTED”误判
P2-6：last_verification 字段 — merge 成功后写 {merged_at, method} 到 registry

核心教训：“看着 exit 0″是工程里最深的坑。任何链条长过 3 步的脚本，最后一步必须做正向校验（ancestor / build / test），不能相信中间步。

八、我们这一周的真实数据（6/18-6/24）

维度 → 数字 → 说明：

Git commits → 53 → 6/18 上午到 6/23 下午
业务 feature 收尾 → 4 个 → ADMIN_POLISH_V3 / OFFLINE_COURSE_SYNC / ENROLLMENT_PIPELINE_HARDENING / ADMIN_UI_TABLE_FIX 等
框架代码 commit → 3 个 → P0-P2 hardening / /hotfix 模板 / umbrella reviewer 一体化
写新业务代码 → 0 → 全部在 swarming + hardening

关键判断：6/18-6/24 是「从建设期 → 运维期」的转折点。前两周几乎都在建流程（spec / plan / tasks / handoff / review / merge）；从这周开始，流程基本就位，进入”边跑边补”阶段。

九、6 条铁律（带走版）

1. 先冻结”基线”，再谈演进。 跑 /release-skills 给当前 git 状态打一个 release candidate tag（带 release notes），把”哪些是已有事实、哪些是新增需求”钉在 release notes 里，否则 AI 会把遗留代码当”待清理对象”。

2. 以真实代码反推契约，不要用需求文档正推。backend/index.js + backend/models/*.js 是事实之源，需求文档只是输入。架构师 agent 用 shared/openapi.yaml 重新反推——5 个阶段：扫路由 → 扫模型 → 写 schema → 区分已实现 / 挂名 → 按范围打 tag。

3. 共享契约文件要”独占维护”。shared/openapi.yaml 由 architect agent 独占维护，业务仓 agent 只读 + 同步拉取。这是为数不多必须”中心化”的设计——分散写一定会出三仓字段对不上的问题。

4. 状态机不要交给主控维护，要切片分给每个负责执行的 skill。tasks.yaml 里只允许 4 个状态枚举（PROPOSED / IN_PROGRESS / REVIEWED / MERGED），状态注释写在 yaml 顶部；每个 slash command 的 prompt 内嵌 Python 脚本做”原子的状态推进”。派生状态（ready / blocked）必须脚本入口现算，不要人手维护。

5. 任何”看着 exit 0″的脚本步骤都要加正向校验。 ancestor / build / test / 业务码 grep，缺一不可。脚本 fallback 短期友好、长期反模式——删 fallback 让 strict 路径生效。”Phantom merge guard”不是 nice-to-have，是脚本链条超过 5 步时的必填项。

6. CLAUDE.md 不是文档，是法律。 凡是踩过两次以上的坑、凡是 AI 容易猜错的目录约定、凡是涉及跨仓边界的硬规则——都要写进 CLAUDE.md，而且要写得像法条一样可执行（”做什么 → 在哪做 → 用什么命令”）。CLAUDE.md 是稳态规则；SESSION_INTERRUPT_*.md 是动态状态——两者分工明确，不要混。

十、这套脚手架不是模板，是要贴着企业实际搭的

最后说点不太中听的。

这套 harness 之所以能在我们这个项目跑起来，是因为它贴着我们的实际：

3 仓不同的技术栈（Express + 小程序 + AngularJS）→ 决定 SoT 必须独立仓
跨仓改动 < 5% → 决定走 3 仓独立而非 monorepo
团队职责边界要清晰 → 决定 architect 独占契约
业务仓 release 节奏独立 → 决定跨仓 release 必须有 gate

直接抄模板到你企业里，大概率跑不起来。每个企业的遗留系统长得不一样：

你的仓可能是 5 个、10 个，技术栈可能是 Java + Go + Python + Vue 的组合
你的 CI 可能是 GitLab 不是 GitHub Actions
你的跨仓 release 节奏可能比我们的更松散
你的 reviewer agent 可能不需要我这种 1:1 per-task stub 的硬约束

但 harness engineering 的核心思想是不变的：

把”AI 写代码”这件事工程化对待，套上状态机、目录约定、脚本校验
让传统软件工程的所有纪律（需求 → 设计 → 编码 → 审查 → 测试 → 发布 → 监控）一个都没丢，只是执行主体变了
把”状态外部化到脚本”，因为 Agent 没有持久记忆，每次会话起来都从零开始
把”规则”从 CLAUDE.md 升级到”代码强制”，否则就是空话

十一、如果你想搭一套自己的 Harness Engineering 脚手架

我们提供 企业级 AI 编码转型咨询顾问服务，覆盖：

现状评估：你企业的遗留系统 + 团队结构 + 现有 CI/CD 适配 AI 编码的程度
脚手架定制：基于你的多仓结构、技术栈、release 节奏，定制 harness engineering 脚手架（不是套模板）
Pilot 落地：选 1-2 个 feature 做端到端验证，把流程跑通
团队赋能：把你团队的研发骨干培训成”AI 工程的脚手架搭建者”，而不是”AI 操作的执行者”

我们已经在 4 仓异构技术栈上把 13 份 spec、20+ 个 subagent、3 仓并发 merge 的完整流程跑通，这周又迭代了一轮 P0-P2 hardening。

如果你正在评估”AI 编码能不能用在我们这种企业遗留系统上”，欢迎把这篇文章转发给你的同事、架构师、技术总监——它就是我们能力的真实证明。

联系方式：jackyshen@uperform.cn

项目实践：基于真实生产系统的 4 仓异构技术栈 AI 编码工程

💬 讨论

如果让你给自己企业的遗留系统搭一套 AI 编码脚手架，你会先做哪一步——先写 spec，还是先把跨仓契约的反推做对？

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

驾驭工程（Harness Engineering）先行者

优普丰AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

一次遗留架构推翻重来：从 monorepo 拆 3 仓，OpenSpec × Claude Code 跨仓架构演进AI 编码驾驭工程完整复盘

admin — Wed, 22 Jul 2026 13:20:14 +0000

起点：1 个 monorepo 仓的 OpenSpec × Claude Code 模板。终点：4 个独立 git 仓 + swarm-orchestrator 编排 + 跨仓 symlink 桥。触发原因：WeChat 小程序 / Express.js 后端 / Angular.js 管理员网站，三个工程上是 3 个独立的遗留 repo，monorepo 装不下，也不可能合并到一起。

TL;DR（30 秒版）

如果你只有 30 秒，看这一段就够了。

一、仓数变了。从 1 个装一切的 monorepo，拆成 4 个独立 git 仓：orchestrator + mp + backend + admin。

二、编排层搬出来了。OpenSpec 的 Source of Truth（.openspec/、.claude/、CLAUDE.md、registry）从业务仓里抽出来，变成了第 4 个仓，叫 swarm-orchestrator。这个仓不写任何业务代码，只做编排。

三、跨仓契约的落地方式换了。monorepo 时代直接在仓内的 openapi/types/config 里改。现在这些共享契约放在 orchestrator 的 .openspec/shared/ 下，业务仓通过 sync 脚本拉只读副本，architect 是唯一能写的人。

四、handoff 和 reviews 的物理路径变了。以前在 monorepo 仓内，现在永远在 orchestrator。业务仓里没有 .openspec/ 目录，靠 symlink 桥接。

五、merge 行为从 1 次变成 3 次。还要按 backend → mp → admin 顺序 release，因为 backend API 没部署之前，前端调不到新接口。

六、tasks.yaml 多了一个必填字段：app_repo，可选 4 个值：mp-app / backend / admin / swarm-orchestrator。4 个 shell 脚本都靠这个字段路由。

七、worktree 位置也变了。从 project/wt-/（都在 monorepo 仓内），变成各自业务仓的 wt-/。

结论：3 仓独立版适合”仓内任务清晰、跨仓改动少”的场景。跨仓改动超过 30% 仍然选 monorepo。

1. 起点：单仓 monorepo 工程目录长啥样

先看初始版本的目录结构。

根目录是 ~/work/openspec_claudecode_monorepo/。下面是 project/ 这个单一 git 仓：

project/.openspec/ 下分 specs/、plans/、tasks/、handoff/、reviews/、registry/、prompts/、templates/、swarm/ 这几个子目录。

project/.claude/commands/ 下有 4 个 slash command。

project/ 下面直接挂 backend/、frontend/、tests/、docs/ 这些业务目录，全在一个仓里。

还有一份 CLAUDE.md 当作项目宪法。

这个模板的工作流是：5 个 Subagent 跑在 project/wt-*/ 5 个 worktree 里（worktree 都在 monorepo 仓内），分别改 backend/、frontend/、tests/、docs/ 各自的目录。

架构干净，工作流也跑通。这个模板我用了一段时间，没问题。

直到我接了一个真实项目。

2. 痛点：真实项目是 3 仓，硬塞 monorepo 反而别扭

接的活是三个独立的技术栈：

WeChat 小程序：用微信开发者工具打开，目录是 app.json + pages/ + utils/
Express.js 后端：独立 Node 项目，src/routes/ + src/models/
Angular.js 管理员网站：独立 Angular 项目，ng new 出来的，src/app/ + angular.json/

这 3 个本来就是 3 个独立 git 仓库：

各自的 main 分支、release tag、CI pipeline
各自的部署节奏：后端上线 ≠ 小程序发版 ≠ admin 发版
各自的开发团队：小程序组 / 后端组 / 前端组
各自的依赖管理：mp 用微信工具链，backend 用 npm，admin 用 ng

但为了用 OpenSpec 模板，我把它们塞进了 1 个 monorepo。具体做法是 frontend/ 放 mp+admin，backend/ 放 Express。

改起来才发现一堆问题：

🔴 部署粒度错位：monorepo 一次 release，3 端一起发版。本来后端先上线、前端第二天跟，硬塞成同一天。

🔴 团队职责边界糊：后端组 PR 改了 frontend/utils/api.ts 没人审。reviewer 看到的是”全仓 diff”，没人聚焦到自己的领域。

🟡 Git 体积爆炸：3 仓的 node_modules 互相污染，.gitignore 难写。

🟡 worktree 互相打架：5 个 Subagent 在同一个仓里 git worktree add 5 个分支，目录互相看不到，路径还容易搞混。

🟡 跨仓”改一处三处 pull”：改 types/user.ts 要 mp/backend/admin 三边手动同步。

🟡 装不下微信工具链：project.config.json 是 mp 专属，放 monorepo 仓怪怪的。

最致命的是”团队职责边界糊”。AI 给我们做的 Review 应该是按仓切分的，不是看一个混合 diff。monorepo 把这件事搞反了。

一句话总结这个阶段的教训：monorepo 是为了”原子化跨仓改动”设计的模板，真实项目压根不需要这么频繁地跨仓改。我们需要的不是更紧的耦合，而是更清晰的边界。

3. 转折：把编排层从 monorepo 抽出来

意识到”3 仓各自独立”才是真实需求后，问题变成一个 meta-level 的问题：OpenSpec 的 Source of Truth 放在哪？

我列了 3 个方案：

方案 A：塞 mp-app 仓。 简单，但后端组 / admin 组改 OpenSpec 都要 PR 进 mp-app，跨仓权限尴尬，乱。

方案 B：新建第 4 仓 swarm-orchestrator/。 编排 = 独立仓 = 单一真相源。代价是多一个仓，但跟获得的清晰度比，值。

方案 C：散落各仓。 每个仓带一份 .openspec/。看似解耦，实际上失去 single source of truth，编排乱套。

选 B。

最终的目录结构是这样的：

~/work/
├── swarm-orchestrator/            ← 第 4 仓，源真相
│   ├── .openspec/                 规约、计划、任务、契约
│   ├── .claude/                   agent prompt + slash command
│   └── CLAUDE.md                  跨仓宪法
│
├── mp-app/                        ← 1 号业务仓
├── backend/                       ← 2 号业务仓
└── admin/                         ← 3 号业务仓

关键认知：Source of Truth 必须是独立仓。如果它寄生在某个业务仓里，那个业务仓就自动成了”主仓”，其他仓的”从属感”会让团队边界再次糊掉。

这条认知后来被我升级成了 SoT 设计的一条新规则：

凡是”X 仓和 Y 仓都要参考的东西”，就不该放在 X 仓或 Y 仓里。

CI/CD 的 release-coordinator.yml 也得独立。跨仓 schema registry 独立。跨仓 e2e 测试仓库独立。

4. 4 个核心改动

从 monorepo 版本到 3 仓独立版，4 个地方必须改。4 个改完就能跑，其他都是 nice-to-have。

4.1 tasks.yaml 加 app_repo 字段

- id: AUTH-002
  owner: backend-agent
  app_repo: backend                # ← 新字段，4 选 1
  worktree: ../backend/wt-auth-002
  branch: feat/auth-002-api
  task_file: .openspec/tasks/AUTH/AUTH-002-api.md
  depends_on: [AUTH-001]

作用：4 个 shell 脚本都靠这个字段决定 cd 到哪个仓。脚本不用猜。

4.2 4 个 shell 脚本都按 app_repo 路由

create-worktrees.sh：以前全在 monorepo 仓内 git worktree add。现在读 app_repo，先 cd 进对应仓，再 git worktree add ../<业务仓>/wt-。

launch-agents.sh：以前默认在 monorepo/wt-/ 启动。现在 cd $app_repo/wt-/ 启动，注入绝对路径环境变量（HANDOFF_DIR / SHARED_DIR）。

collect-handoff.sh：以前巡查 monorepo 内的 handoff。现在永远读 swarm-orchestrator/.openspec/handoff/，不去 worktree 里找。

merge-all.sh：以前是 1 个 PR 进 monorepo main 收尾。现在按 app_repo 分组，每个 repo 独立 rebase + merge。

最大的差异在 merge 阶段。以前是 1 次进 main，现在变成 3 个仓各 merge 一次，还要按 backend → mp → admin 顺序 release。原因是 backend api 部署 OK 后 mp/admin 才能发版，否则前端会调不到新接口。

4.3 Handoff 路径：永远在 orchestrator

这是最容易踩坑的地方。

业务仓里没有 .openspec/（业务仓只关心自己的业务代码，OpenSpec 的目录跟它无关）。但 Subagent 写 handoff 的时候，直觉上会写到自己 worktree 里的 .openspec/handoff/… 这个路径在业务仓里根本不存在，要么落进业务仓的 main 分支（污染），要么报错。

我比较了两种处理方式：

方式 A：任务文件里给绝对路径。 在任务文件末尾写明”写 handoff 到 /abs/path/.openspec/handoff/…”。可行但每个任务都要手动写一遍。

方式 B：worktree 内 symlink。 在 create-worktrees.sh 里加一步 ln -s ../../swarm-orchestrator/.openspec $WT/.openspec。一次性给所有业务仓的 wt- 建好 symlink，Subagent 用相对路径写就自动落到 orchestrator 仓。Prompt 模板几乎不用改。

选 B。

# create-worktrees.sh 末尾
if [ $APP_REPO" != "swarm-orchestrator" ]; then
  ln -s $ORCH_ROOT/.openspec" $ABS_WT/.openspec"
  echo $ABS_WT/.openspec → $ORCH_ROOT/.openspec"
fi

效果是这样的：

backend/wt-auth-002/.openspec   →  ../../swarm-orchestrator/.openspec
mp-app/wt-auth-003/.openspec    →  ../../swarm-orchestrator/.openspec
admin/wt-auth-004/.openspec     →  ../../swarm-orchestrator/.openspec

Subagent 在 wt- 里写 .openspec/handoff/AUTH/AUTH-002-api.md，实际写到 orchestrator 仓。handoff/reviews 永远在 orchestrator 落地，不污染业务仓 main。

小细节：orchestrator 自己的 wt-（architect 任务、docs 任务）不走 symlink，因为 .openspec/ 本来就在仓里。

4.4 Architect 角色扩成”跨仓契约 owner”

Architect 这个角色在 monorepo 版只管 openapi/ + types/ 几个目录。3 仓版下，它是唯一能写跨仓契约的角色。

新加的”跨仓契约统一源”：

swarm-orchestrator/.openspec/shared/openapi.yaml → architect only
swarm-orchestrator/.openspec/shared/types.ts → architect only
swarm-orchestrator/.openspec/shared/config.schema.json → architect only

业务仓需要这些文件时只能走 sync-shared.sh：

# 业务仓里
cd backend && bash ../swarm-orchestrator/.openspec/swarm/sync-shared.sh
# 或
cd admin && npm run sync:shared     # admin 还会自动跑 openapi-typescript

这是 3 仓版本能 work 的核心机制。没有这层”单一真相源 + sync 拉取”，3 仓独立就退化成”3 份维护负担”。

5. 4 个配套改动

4 个核心改完，已经能跑通。但要让 5 个 Subagent 真的不踩坑，还要 4 个配套：

5.1 Agent prompt 顶部加 WORKTREE_BASE 提示

# .claude/agents/backend-agent.md 顶部
APP_REPO=backend
WORKTREE_BASE=$PWD                          # ../backend/wt-/
ORCHESTRATOR_ROOT=$WORKTREE_BASE/../..      # swarm-orchestrator/
HANDOFF_DIR=$ORCHESTRATOR_ROOT/.openspec/handoff
REVIEW_DIR=$ORCHESTRATOR_ROOT/.openspec/reviews
SHARED_DIR=$ORCHESTRATOR_ROOT/.openspec/shared

launch-agents.sh 已经在 spawn Subagent 时 env 注入了这些变量，但 prompt 里写明让 agent 自己也知道，不会去 env | grep 查。

5.2 4 个仓的 .gitignore 各自维护

orchestrator：极简，不忽略业务代码（业务代码压根不在这里）
mp-app / backend / admin：各自的 types/ 全部 gitignored（同步副本不 commit）
业务仓统一 wt-*/ gitignore（worktree 不入仓）

5.3 CI/CD：每个业务仓独立 pipeline + 1 个 release coordinator

3 个业务仓各自跑 CI（mp 用微信工具链，backend 用 npm test，admin 用 ng test）
orchestrator 加一个 release-coordinator.yml：watch 3 仓的 release tag，按 backend → mp → admin 顺序触发部署

这一步可选。如果业务仓 release 节奏本来就是人工协调的，可以先不做。脚本里 merge-all.sh 也带了”backend 段结束后停一下”的 gate，让主控人工 confirm deploy。

5.4 README “Where to run claude” 表变成 4 行

写需求 / 拆 plan  →  swarm-orchestrator/  →  claude → /spec /plan /swarm /review /merge
改业务代码 (直跑)  →  <业务仓>/  →  cd <业务仓> && claude

主控在 orchestrator，3 个业务仓是 Subagent 的工作区。不要在业务仓直接 claude 跑主控命令（虽然技术上能跑，但 /swarm 这类命令会找不到 registry）。

6. worktree 实际位置（最容易晕的地方）

跑完 /swarm AUTH 后，5 个 worktree 不在同一个地方。它们分别落在 4 个仓里：

~/work/openspec_claudecode_seperepo/
│
├── swarm-orchestrator/
│   ├── wt-auth-001-arch/         ← architect 任务（本仓内）
│   │    .openspec → ../../.openspec   (仓内 symlink)
│   │
│   └── wt-auth-005-doc/          ← docs-agent 任务（本仓内）
│
├── backend/
│   └── wt-auth-002/              ← backend-agent 任务（backend 仓内）
│        .openspec → ../../swarm-orchestrator/.openspec   ★ 跨仓 symlink
│        src/  tests/  types/
│
├── mp-app/
│   └── wt-auth-003/              ← mp-agent 任务（mp-app 仓内）
│        .openspec → ../../swarm-orchestrator/.openspec   ★ 跨仓 symlink
│        pages/  utils/  types/
│
└── admin/
    └── wt-auth-004/              ← admin-agent 任务（admin 仓内）
         .openspec → ../../swarm-orchestrator/.openspec   ★ 跨仓 symlink
         src/app/  types/

5 个 worktree 分别在 4 个仓里（orchestrator 自己有 2 个：architect + docs-agent；其他 3 仓各 1 个）。互不打架。

FAQ：为什么仓本体不放进 main/ 子目录和 wt- 平级？

不要。git init 创出来的 repo 默认根目录就是 main checkout，CI、IDE、部署脚本全假设这个。挪到 main/ 子目录是重发明一个本来就有的轮子。

7. 什么时候该 monorepo，什么时候该 3 仓独立

今天最大的收获是画清楚这个判定线。

改 1 处契约要 3 端联动：✅ 选 monorepo（1 个 PR 改完）；❌ 3 仓独立要做 orchestrator + 3 仓 sync + 3 次 PR。

3 端都是同一个团队，节奏一致：✅ monorepo 更顺手；⚠️ 3 仓独立嫌麻烦。

3 端不同团队，独立 release 节奏：❌ monorepo 一发全发；✅ 3 仓独立各自节奏。

团队职责边界要清晰：⚠️ monorepo 看 PR 评审；✅ 3 仓独立仓级 reviewer。

Agent Swarm 编排：monorepo 简单（1 仓）；3 仓独立复杂（4 仓）。

跨仓 refactor：✅ monorepo 1 个 PR；❌ 3 仓独立几乎做不了。

适合 Agent Swarm 的 task 切分：monorepo 任意；3 仓独立仓内任务清晰、跨仓改动少。

判定公式：

跨仓改动 > 30% → monorepo
跨仓改动 < 10% → 3 仓独立
10% ~ 30% → 看你团队结构

我们今天这个项目（mp + backend + admin，3 端完全是不同技术栈、不同团队、不同 release 节奏）属于”跨仓改动 < 5%”，3 仓独立赢麻了。

8. 一个新认知：Source of Truth 不能寄生

今天还有个隐性收获：Source of Truth（SoT）必须独立存在，不能寄生。

monorepo 时代，SoT 就是 monorepo 自己。但 3 仓独立的时候，”OpenSpec 放哪”这个问题是个 meta-level 的 SoT 问题：

寄生在 mp-app → 后端组 / admin 组改 OpenSpec 要 PR 进 mp-app，跨仓权限尴尬
寄生在 backend → 类似问题，反过来
寄生在任意一个业务仓 → 该仓自动变成”主仓”，其他仓的”从属感”再次让边界糊掉
独立成第 4 仓 → 编排 = 独立仓，所有业务仓都是平级

CI/CD 的 release-coordinator.yml 也得独立
跨仓 schema registry 独立
跨仓 e2e 测试仓库独立

凡是”X 仓和 Y 仓都要参考的东西”，就不该放在 X 仓或 Y 仓里。这是我对 SoT 设计的一条新规则。

9. 验证：现在 seperepo 跑得通吗

我跑了一遍 sanity check。

5 个脚本全部通过 bash 3.2 语法检查（macOS 默认 bash）：

$ for f in .openspec/swarm/*.sh; do bash -n "$f" && echo "✓ $f"; done
✓ .openspec/swarm/collect-handoff.sh
✓ .openspec/swarm/create-worktrees.sh
✓ .openspec/swarm/launch-agents.sh
✓ .openspec/swarm/merge-all.sh
✓ .openspec/swarm/sync-shared.sh

5 个 task 全部带 app_repo，4 选 1 合法：

$ python3 parse tasks.yaml
  AUTH-001    app_repo=swarm-orchestrator      owner=architect
  AUTH-002    app_repo=backend                 owner=backend-agent
  AUTH-003    app_repo=mp-app                  owner=miniprogram-agent
  AUTH-004    app_repo=admin                   owner=admin-agent
  AUTH-005    app_repo=swarm-orchestrator      owner=docs-agent

未跑的部分（要等业务仓 git init 后才能真跑）：

create-worktrees.sh 实际创建 5 个 worktree
launch-agents.sh 实际启 5 个 Subagent
merge-all.sh 实际 merge 3 个仓的 main

但脚本逻辑都验证过了，跑起来应该没坑。

10. 留给以后的自己

3 条带走：

monorepo 不是银弹。当”跨仓改动 < 10%”，3 仓独立 + 1 个 SoT 仓 = 更清晰。判定公式见 §7。SoT 必须独立成仓，不能寄生。否则业务仓边界再次糊掉。这是 SoT 设计的一条新规则。
worktree 跟着业务仓走，别堆在 SoT 仓里。handoff 路径永远在 SoT 仓，业务仓用 symlink 桥接。
app_repo 的设计，使得 Registry 会慢慢长成：Jira Issue + GitHub Project + Agent Runtime。

3 条防踩：

改业务代码路径：”<业务仓>/wt-/ 里改”（不是 SoT 仓的 wt-）
改契约路径：”SoT 仓的 .openspec/shared/，然后业务仓 npm run sync:shared”
merge 顺序：”backend → 等 deploy OK → mp → admin”

1 个下次要先问的问题：

接新项目时，先问”3 端是不是独立 release 节奏”。是 → 3 仓独立；否 → monorepo。别急着抄模板。今天的最大教训是：模板不是越多越好，是贴合实际场景的才好。

11. 下一阶段：从跨仓编排到 Agent Platform

这次从 monorepo 演进到 3 仓独立版，本质上解决的是：代码仓如何解耦。

但在搭建过程中，也逐渐看到了下一阶段可能出现的新问题。

今天的架构已经足够支撑：1 个项目 + 5 个 Subagent + 4 个 Git 仓。

但如果未来变成：多个项目 + 20~50 个 Agent + 更多跨仓协作，有些设计可能会继续演进。

11.1 Runtime State 可能从文件演进成状态系统

当前版本 .openspec/ 下的 handoff/、reviews/、registry/ 全部以文件形式存在。

这在 5 个 Agent 规模下非常简单且透明。

但未来如果出现 20+ Agent 同时更新 tasks.yaml + handoff/reviews/，可能会开始出现状态冲突。

因此未来有一种可能：把 handoff、reviews、status 统一视为 Runtime State，从文件演进到 Runtime State，再往后甚至演进为 SQLite / Redis 轻量状态服务，统一管理 Agent 生命周期。

这并不意味着文件方案不好。相反，文件 → Runtime State → Agent State Service 是一条非常自然的演进路径。当前阶段文件依然是最简单、最透明、最容易调试的方案。

11.2 Architect 可能拆分为 Contract Agent

当前版本中 Architect 同时负责：架构设计、OpenAPI、共享 Types、共享 Config。因此 .openspec/shared/ 实际上由 Architect 统一维护。

这种方式非常适合项目初期。但随着 Feature 数量增加到 10+、20+、30+，Architect 可能逐渐成为跨仓协作的瓶颈。

未来一种可能的演进方向：把 Architect 拆分成两个角色——Architect 负责系统设计，Contract Agent 负责共享契约。共享契约治理将成为独立能力。

11.3 SoT 仓可能继续演进为 AI PMO

当前 swarm-orchestrator 保存：Spec、Plan、Task、Review、Workflow。虽然它仍然是 Git 仓库，但从职责来看，它已经越来越接近项目管理系统，而不是传统代码仓库。

从这个角度看，swarm-orchestrator 其实已经承担了 Architecture Repository、Task Registry、Agent Registry、Workflow Engine 的角色。

未来它可能进一步演化成 AI PMO（Project Management Office），成为整个 Agent Swarm 的控制中心。

11.4 从项目级 Orchestrator 到组织级 Control Tower

当前架构：backend、mp-app、admin 三个业务仓被一个 swarm-orchestrator 管。对于单项目非常合适。

但如果未来同时管理 Project-A、Project-B、Project-C，就会出现新的问题：Prompt、Agent、Workflow、Skill 开始在多个项目之间重复。

因此未来可能出现更高一层：Workspace 下面挂多个 Project，每个 Project 有自己的 swarm-orchestrator，最顶层有一个 AI-Control-Tower。

AI-Control-Tower 统一管理 Agent Registry、Prompt Registry、Skill Registry、Workflow Registry。而项目级 orchestrator 只负责 Spec、Plan、Task。

这种结构与企业中的 Team → Program → Portfolio 层级非常相似。

11.5 Agent Engineering 的真正问题

这次演进还有一个重要体会。

最开始以为问题是：如何让 Claude 写代码。

后来发现问题变成：如何让多个 Claude 协同写代码。

再往后发现：如何让多个 Agent 在真实组织结构中协同工作。

这已经不再是代码生成问题，而是：组织结构、仓库结构、Agent 结构三者如何保持一致的问题。

从这个角度看，OpenSpec、Claude Code、Worktree、Subagent 都只是工具。真正的挑战始终是：如何建立一个能够持续演化的 Agent Operating System。

而这次从 monorepo 到 3 仓独立版，只是这条演进路线上的第一步。

附：项目地址速查

monorepo 模板：~/work/openspec_claudecode_monorepo/project/ 历史（保留作对比）

3 仓独立样例：~/work/openspec_claudecode_seperepo/ 当前主用

顶层 README：openspec_claudecode_seperepo/README.md 操作步骤 + worktree 位置

跨仓宪法：openspec_claudecode_seperepo/swarm-orchestrator/CLAUDE.md “where to run claude” 表

跨仓脚本：openspec_claudecode_seperepo/swarm-orchestrator/.openspec/swarm/*.sh 4 + 1 = 5 个

5 个 agent prompt：openspec_claudecode_seperepo/swarm-orchestrator/.claude/agents/*.md 顶部都带 WORKTREE_BASE 提示

6 个 slash command：openspec_claudecode_seperepo/swarm-orchestrator/.claude/commands/*.md /spec /plan /swarm /review /merge /status

日期：2026-06-06 状态：seperepo 骨架完成，脚本验证通过，等真实业务仓 git init 后跑通端到端

💬 讨论

你最近一次”架构推翻重来”是因为什么原因？是项目规模变了，团队变了，还是部署节奏变了？

如果接新项目，你会先问”3 端是不是独立 release 节奏”吗？

欢迎在评论区聊聊你的踩坑经历 👇

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

驾驭工程（Harness Engineering）先行者

优普丰AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

在AI时代，每个程序员都活成了自己最讨厌的那种Team Leader|优普丰赋能企业AI落地

admin — Mon, 13 Jul 2026 15:03:31 +0000

一、那个发誓”绝不变成他”的人

前两天刷到一条帖子，看完我坐在椅子上愣了三分钟。

帖子很朴素，列了 7 条”程序员变成自己最讨厌的那种 team leader”的标准症状。我一条一条读，越读越不对劲——

不是因为陌生。

是因为每一条都像在照镜子。

我们这代程序员，从入行第一天起就被各种”领导力糟粕”耳濡目染过：

“那个 leader 半年不写代码，凭什么指手画脚？”
“PRD 写得稀烂还天天催进度，出了问题就甩锅”
“PR 看都不看就 Approve，连 diff 都懒得滚一下”
“新人被他骂哭三次了，他自己连 git rebase 都不会”

我们曾经在工位上、午饭时、复盘会后，立下过多少铮铮誓言：

“我以后要是当了 manager，绝不这样。”

然后呢？

2023 年，ChatGPT 来了。 2024 年，Cursor 来了。 2025 年，Claude Code 来了。 2026 年，连 PRD 都不用人写了。

我们没有等到当 manager 的那天——AI 直接替我们提前完成了转型。

那条帖子总结得精辟，我把它转写一遍，并附上一点”我亲眼见过 / 我自己干过”的注解。

如果你读着读着也像我一样”坐立不安”——恭喜你，这篇不是写给 manager 的，是写给你的。

二、7 张”AI 时代病”的精准 CT

① 半年不写一行代码，编程能力严重退化，还自诩”我也是搞技术的”

“搞技术的”——这四个字现在基本等于”搞过技术的”。

打开你最近一个月的 git log，git log –author=”你自己”，是不是有几次作者名出现次数 < 5？再看看 commit message，是不是清一色的”wip”、”fix”、”feat: 优化一下”？

上周我让一个三年经验的后端同事，徒手写一个 LRU Cache。他憋了 15 分钟，最后说：

“我让 Claude 写一个吧，半分钟。”

我问他：”你还能闭着眼睛写出单例模式吗？” 他沉默了三秒，说：”我可以让 AI 给我写出 5 种实现，挑一个。”

这不叫”搞技术的”，这叫”搞 AI 技术的”。

更扎心的是——我问他 LRU 的 Get 时间复杂度，他想了想说”应该是 O(n) 吧”。错了。是 O(1)。然后他用 AI 验证了一下，确认”哦，对的，O(1) 哈希 + 双向链表”。

我们这一代，正在变成”AI 的肉喇叭”——AI 说什么，我们就转述什么。

② 开会的时候把一线开发干的活全说成是自己的，连自己的汇报材料都是让别人总结的

这个病最隐蔽，而且是 AI 时代独有的。

以前老板要 PUA 你好歹还得先认识你，现在：

周一 Scrum站立会，你负责的部分是 ChatGPT 帮你写的；
周三技术分享会，你的方案是 Claude 帮你 review 的；
月底部门 OKR review，你的 PPT 是让实习生帮你排的版；
季度战略会，你”展示”的那套架构是下属设计的，你连”为什么用 Postgres 不用 MySQL”都答不上来。

最有意思的是——你还自我感觉良好。

因为在 AI 帮你写的报告里，你是一个”技术深度扎实、推动力强、沟通高效”的工程师。在 AI 帮你润色的述职里，你是一个”具有系统思维、能带兵打仗”的技术 leader。 你照着念，念得还挺像那么回事。

直到有一天，老板现场追问一个细节。

空气突然安静。

你脸上的表情，被全组 17 个人看得清清楚楚。

“AI 帮我们写 PPT 的时候，从来不会提醒我们：这个人其实没参与过这个项目。”

③ 瞎 JB 指挥，出了问题就甩锅说是下面没执行好

这一条，是 AI 给所有人的”权力幻觉”。

AI 让一个人看起来像一个 leader。它不让他真正成为一个 leader。

所以你就出现这种症状：

需求没想清楚就催进度：”我让 AI 评估过，这个两周能做完。”
方案评审时只会说”AI 建议这么做”——AI 是你的 leader，你是 AI 的传话筒。
出了线上事故，凌晨 3 点的复盘邮件第一句是”经过排查，根因是 SRE 同学未按预案执行”。
老板问”这个架构你当时 review 过吗”，你立刻甩锅”我 prompt 写得可能不够细，回头我优化一下 prompt 模板”。

最经典的甩锅话术已经进化到 2.0 版本了：

1.0 版：”他执行不到位。” 2.0 版：”我 prompt 写得不够精确。”

1.0 甩的是下属，2.0 甩的是 AI。 本质上，都是甩的别人。

④ 不了解项目具体情况，只会提”单测加了没”、”性能还要优化”、”文档要沉淀一下”这类空洞的要求

这条我太熟了。AI 时代最伟大的一项发明，不是 Transformer，是”一键三连金句”：

“单测、性能、文档。

“任何 review 会上，你只要把这三件套甩出来，永远不会错：

加了单测 = 你重视质量
性能要优化 = 你关注用户体验
文档要沉淀 = 你在乎团队成长

至于具体加哪些单测、哪个接口要优化到多少 QPS、文档要沉淀到哪个 wiki 路径——

这是细节。细节是要命的。细节不是 leader 该关心的。

哦对了，这种话术还特别防 PUA。 因为下属如果反驳，他会显得”格局不够”。如果照做，你可以随时补一句”我是从方向上把关的，你执行的时候要带脑子”。

AI 时代最讽刺的是：这三件套连 AI 自己都听得耳朵起茧。

你问它”我的代码有什么问题？” 它说：”建议加单元测试覆盖边界条件、性能可进一步优化、文档需补充示例。”

你问它”项目该怎么管理？” 它说：”建议完善单测体系、建立性能基线、沉淀团队知识库。”

我们用 AI 写出来的废话，又喂回 AI 让它自己消化。

⑤ PR 基本上看不懂，只会让别人先 review 了自己跟着点赞

这条最黑色幽默。

以前 PR review 是程序员的基本尊严——你至少要证明”我看过这段代码，我才点 Approve”。

现在？

PR review 已经是 AI 的事了。

同事 A 把 Cursor 生成的代码 commit 上来了；同事 B 让 Claude review，给了 12 条建议；同事 C 让 GPT 提了 8 条改进；团队 leader 点 Approve，留言：”👍 看着没问题，辛苦！”

leader 那条留言的意义是什么？是告诉老板”我也参与了”，是 KPI 上的”团队 review 参与度 100%”，是周报里”持续推动 code review 文化”的素材。

更黑色幽默的是——

这段代码的 review，是 AI 写的；你点 Approve 的依据，是”别人都 Approve 了所以我也 Approve 了”；这段代码的作者，是 AI；这段代码的 Reviewer，也是 AI。

这中间那个”leader”，是干嘛的？

是来给 AI 之间的对话，加一个 “+1” 表情的。

⑥ 遇到 bug 了只知道无脑转发让别人查一下，自己负责来来回回转发消息

这条是当代职场最大的表演艺术——bug 转发学。

9:00 客户发截图：这里报错了。 9:02 你把截图转给后端 A：@A 麻烦看一下。 9:05 后端 A 问你：是测试环境还是线上？ 9:06 你把客户原话复制给后端 A：他说”线上”。 9:08 后端 A 说：线上哪个账号？ 9:10 你把客户截图再转一次：他要账号吗？你给他一下。 9:15 客户回了一个 UUID。 9:16 你把 UUID 转给后端 A：客户说用这个账号复现的。 9:30 后端 A：找到原因了，是 X 服务在 Y 场景下的 Z 问题。 9:31 你把后端 A 的话转给客户：已经定位到问题了，开发同学正在修复。 9:45 修好了。 9:46 你把”修好了”转给老板：客户反馈的问题已修复。

全程 0 行代码。0 次 debug。0 个判断。唯一产出是 12 条转发消息。这是 AI 时代最完美的岗位描述：消息中间件 (Message Middleware)。

更绝的是——你还会用 AI 让自己的转发显得更专业：

让 ChatGPT 把后端 A 的话润色成”经过技术团队的快速响应和深度排查，已经定位到根因并完成修复”。

你把别人的话，喂给 AI 加工一遍，再发出去——你的核心能力就完整闭环了。

⑦ 还经常吐槽”今年的应届生水平越来越不行了”

这条是”AI 病”最严重的并发症。

你自己写不出的代码，AI 写出来你签字。你自己 review 不出的 PR，AI review 完你点赞。你自己调不出的 bug，AI 帮你定位你转发。

然后你转身跟 HR 说：

“今年秋招这批简历，看不出潜力啊。算法题让 AI 一做都满分，聊聊工程能力就露馅。”

你有没有想过——你招的”工程能力”，可能还不如这届应届生？

应届生至少能徒手写个快排。
你连单例模式都得 AI 写。
应届生至少 debug 时还会用 print。
你 debug 只会用”截图转发”。
应届生至少知道”git rebase”是什么。
你 rebase 出冲突了，直接 revert 然后让 AI 重新生成一份。

最讽刺的是，你一边用 AI 把自己的活干完，一边骂”应届生被 AI 惯坏了”——请问，你是被谁惯坏的？

这一条没有 AI 治得了。因为这不是技术问题，是病。

三、AI 没让我们变强，让我们变懒

写到这里，我得停下来。

因为这篇文章的讽刺如果只停留在”骂人”，那我也成了那种只会写”程序员堕落”爽文的烂账号。

我想真正戳一下自己——

为什么我们会集体滑向这种状态？

不是 AI 让我们变强，是 AI 让我们可以”看起来很强”地变懒。

写代码难，但你让 AI 写 → 容易。
理解架构难，但你让 AI 解释 → 听起来容易。
解决问题难，但你让 AI 诊断 → 像是容易。
团队协作难，但你让 AI 写话术 → 显得容易。

这 4 个”容易”，合起来就是 1 个——

“逃避真难的”容易”。

而那些”真难”的部分——

真正理解业务；
真正打过一场生产事故；
真正和一个难缠的客户聊一下午需求；
真正在 deadline 前熬 36 小时交付过；
真正为一个技术决策承担过后果——

AI 帮不了你。

AI 只能帮你”看起来像做过”。

但”看起来像”和”真的做过”，是两件事。前者让你 KPI 好看，后者让你半夜睡得着。

四、最后问一个得罪人的问题

你看完了。

笑完了。

转发了。

然后呢？

明天上班，你是准备继续让 AI 帮你写代码、自己继续转发 bug、自己继续 +1 别人的 PR——

还是打开 IDE，从一行真正的代码开始，重新做回一个”搞技术的”？

我选了后者。你呢？

💬 今日互动话题：

上面 7 条里，你中了几条？

A. 0 条（请受我一拜）

B. 1-2 条（人之常情）

C. 3-4 条（开始警觉了）

D. 5-6 条（要不咱俩抱头痛哭一下）

E. 7 条全中（兄弟，你就是那个 leader 本 lead）

评论区等你🐶

关于作者

申导（Jacky），一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

如果这篇文章对你有帮助,点个在看,让更多人看到AI时代真正的工作方式。

Anthropic设计主管Meaghan Choi 谈 ClaudeCode 的敏捷开发故事：团队管理者都在一线构建产品，看 Token 用量不如看最原始的产

admin — Mon, 29 Jun 2026 10:14:08 +0000

从 12 人的业余项目到 25 亿美金：Claude Code 用的根本不是什么新方法他们用的，叫敏捷开发。

你上一次听到有人认真说”我们用的是敏捷”是什么时候？

开个站会，贴几张 Jira 卡，喊一声 Sprint，然后 deadline 一到全部乱套——这大概是大多数人对”敏捷”的真实记忆。

然而就在 2026 年纽约 ProductCon 的舞台上，Anthropic Claude Code & Cowork 的设计主管 Meaghan Choi 坐下来，用 40 分钟告诉你：

那个从 12 个人的内部工具，长到年营收 25 亿美金、拿下编程工具 51% 市场份额的产品，走的就是最正统的敏捷路子。

没有什么秘法，就是【构建 → 测量 → 学习】的循环。

第一章：故事从一个粗糙的原型开始

2024 年，AI 编程工具的主流范式是这样的：

把代码复制进聊天窗口，等回答，再复制回编辑器。少数人在用自动补全，仅此而已。

然后，一位 Anthropic 的工程师做了一个大胆实验：让 Claude 直接在你的电脑上执行操作，而不是给建议。

他用 CLI 做了个原型，给 Claude 开放了本地文件系统权限，录了一段演示视频，发到内部 Slack。

Meaghan 看到的那一刻，只有一个念头：

“Holy crap, this is it.”

但这个原型跑起来要将近一小时，体验粗糙，模型能力也没跟上。用她的话说——“至少提前了 6 个月。”

很多团队在这里会做什么？可能急着找时间表，可能开始写 PRD，可能先做竞品分析。

Anthropic 的团队做的事情是：在公司内部推广，让尽可能多的人用起来。

接下来 3 个月，他们跟着用户走，看别人怎么用，现场修 bug。

💡敏捷视角：这就是最标准的 Sprint 0——不求对外发布，只求内部验证。”先让我们自己信，再让用户信。”

第二章：发布标准只有一条——真实采纳，不是功能完成

Claude Code 的发布流程非常清晰，分三步：

① 敏捷小队内部的人觉得够好、愿意用

② 推给公司其他团队

③ 追踪内部日活用户数，看到真实采纳增长，才考虑对外发布

注意——不是”功能做完了就发”，而是“有人真的在用了才发”。

这两者的差距，Meaghan 形容为建立 conviction（信念）：

“你对产品的信心，来自亲手用过、看到别人也在用。”

有多少团队的发布节点，是”需求评审通过了”？

有多少团队验收标准，是”测试用例全部通过”？

Claude Code 的验收标准是：自己用了、同事用了、停不下来了。

这套”先内后外”的机制，贯穿 Claude Code 至今。

第三章：头衔是你的专长标签，不是你的边界

Anthropic 怎么组队？

Meaghan 用了一个词：fluid（流动的）。

“头衔只是你带给团队的专业背景标签，它不划定你能做什么。”

她本人是设计主管，日常往生产环境推代码。她的工程师会做设计决策。她不参与每一个功能的设计。

一个敏捷小队，可以是：

5 个工程师
4 个工程师 + 1 个设计师
2 个设计师 + 3 个工程师
2 个 PM + 3 个工程师

只要人在 3-5 人之间，只要所有人一起冲刺，把东西做到在代码里跑起来。

她还强调了一点，听起来刺耳，但很重要：

“任何人都应该能往生产环境发布。”

她承认作为设计师，起初很难接受没经过自己手的功能上线。但她也承认：这种不适感，是进入快速迭代模式的必要代价。

要让这个模式跑起来，后面要有安全网：好的代码评审流程、CI 自动化测试、完善的测试覆盖。安全网在后面撑着，前面才能放开让所有人跑。

💡 敏捷视角：这是跨职能团队的最佳状态——不是”前端等后端等设计等 PM”的串行，而是所有人围着同一个目标并行。

第四章：质量关卡，从纸面移进了运行中的代码

这可能是 Meaghan 整场分享里最”颠覆常识”的一点。

传统流程的质量决策发生在哪里？

讨论阶段。看 PRD、看设计稿、在 Figma 里确认方向，然后才动手开发。

Anthropic 把这个决策点往后推了一步——推到了可运行代码的阶段：

“你得自己用，在真实工作流里体验产品，这时候做出的质量判断才最接近用户的真实感受。”

她用了一个词：“a flip on the head”（翻了个个儿）。

这对设计师尤其是职业本能上的挑战——放手让没打磨到 100% 的东西上线，是很难受的事。

但她也说：

“快速迭代和带着不完美上线不是 AI 时代的发明——AR、VR、空间计算一路走过来都是这样。这是新兴技术开发的天然节奏。”

先做出来，再迭代质量——而不是在动手前把所有迭代做完。

这句话，Scrum 从第一天起就在讲。只是现在 Anthropic 用一款年营收 25 亿的产品，把它演示了出来。

第五章：开发者先用，带动整个企业买单

Claude Code 的企业扩张走的是 PLG（产品驱动增长） 路线：

开发者在个人项目中使用，觉得好用
在公司内部推动采纳
企业工具团队被驱动去做定制化连接器
内部数据库、基础设施被接通
每个人效率提升更大 → 循环继续

更有意思的是：当工具延伸到非工程职能——财务团队用 Claude Code，设计师用 Claude Code——使用者不仅完成了工作，还在过程中学到了新技能。

Meaghan 管这叫：

“Multiply your ability to learn those skills as well.”

这和敏捷对”跨职能能力成长”的期待完全一致：团队因共同工作而互相渗透，每个人的能力边界在悄悄扩大。

第六章：Token 用量不代表 ROI

这是 Meaghan 给整个行业的一个警告。

如果一个人的 token 用量是零，应该引起关注。

但不要让团队比拼谁用的 token 最多——消耗大量 token 却什么都没做到，太容易了。

她拿了一个精准的类比：

以前工程团队用代码行数衡量工程师贡献，后来发现这不是最好的方式。AI 时代的 token 用量，处在类似的阶段。

那应该看什么指标？

采纳率、留存率、收入。

无论你用不用 AI，这些指标都成立。

行业不应该因为工具变了，就发明一套全新的衡量体系。敏捷从一开始就说：关注可工作的软件，关注客户满意度。AI 工具改变的是效率，不是这些原则的有效性。

💡 给管理者的提醒：你的 KPI 体系不需要推倒重来。先问问：用了这些工具之后，留存率提升了吗？交付速度提升了吗？用户满意度呢？

第七章：每个 IC 都成了”迷你管理者”

这是 Meaghan 最后抛出的一颗炸弹：

“Everyone’s kind of managing a fleet of Claudes that are also working.”团队里每个人，现在都在管理一群 Claude 实例同时工作。

分配任务、检查产出、协调节奏——这像是所有人都沿着管理链往上挪了一格。

一线执行者变成了”迷你管理者”。而 Anthropic 所有带团队的管理者，都同时在一线构建产品——Meaghan 自己做设计、推代码。

她的逻辑是：只有亲身经历工作流程的变化，才能判断应该在什么工具和培训上投入。

这其实是 Scrum 对 Scrum Master 角色的期待——不是一个会议主持人，而是一个深度理解团队工作方式的人。

写在最后

如果用一句话总结 Meaghan Choi 的整场分享：

构建 → 测量 → 学习。先让小队内部的人信，再让用户信，最后让市场信。

Claude Code 从 12 人的副项目到 51% 市场份额，用的不是更重的流程，而是更快的反馈环。

头衔不设边界、质量关卡后移、Token 用量不替代用户指标——这些不是 Anthropic 独有的方法论，它们有一个共同的名字：

敏捷开发。

不是墙上贴的敏捷，不是会议室里说的敏捷。

是真正跑起来的那种。

💬 你觉得，你们团队现在最难做到的，是哪一条？

是”任何人都可以发布”，还是”先做出来再迭代质量”？

欢迎留言，我来和你聊聊。

本文基于 Meaghan Choi 在 2026 ProductCon 纽约大会的访谈整理

原始来源：ProductCon NY 2026 · Product School 官方访谈

本文作者：申健 Jacky Shen

关于作者

申导（Jacky），一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

如果这篇文章对你有帮助,点个在看,让更多人看到AI时代真正的工作方式。

知名战略咨询顾问G总破防了？维护咨询行业不被AI颠覆为何反被群嘲？

admin — Fri, 26 Jun 2026 03:54:14 +0000

最近，一位在 MBB、SAP 等多家头部咨询公司辗转多年的战略顾问 G 总，在公众号上发文高调宣称：管理咨询是最不会被 AI 颠覆的行业之一，咨询顾问的薪酬将会大幅增长。原文论点扎实、引经据典，看上去胸有成竹。

然而戏剧性的一幕发生了——文章评论区直接被打成”案发现场”，点赞最高的几乎全是”打脸”评论，而 G 总本人在评论区里与读者频频过招，几次”反击”反而成为全场笑点。于是我们决定把这场精彩交锋原汁原味地搬运过来，让各位读者自己判断：原文到底站不站得住脚？

需要说明的是，本文不做立场判断，纯吃瓜，欢迎读者自行服用。

一、G 总的三大核心论点（精华版）

先帮没看过原文的读者快速过一下 G 总的论据——他把咨询工作拆成”生产”和”信任接口”两块，再援引《可信赖的顾问》里的”信任公式”，最后拿美国执业护士（NP）做类比，得出三个核心判断：

咨询的本质是”高触感服务业”：客户买的不是 PPT，而是决策的信心、权威的体面；
AI 只能替代”生产工人”，替代不了”咨询顾问”：前者是流水线，后者是合伙人级别的”信任接口”；
真正的咨询顾问会像 NP 一样迎来薪酬大爆发：AI 把杂活干完，资深顾问反而更值钱。

单看论点，不能说没有道理。但评论区显然不打算放过 G 总。

二、第一回合：核心论战——”70-80% 的咨询工作 5-8 年内会消亡”

一位坐标加拿大的读者 Rainier 留言被顶到置顶：

“讲真，70-80% 的顾问的工作已经很容易被 AI 取代了。真正能为企业提供价值的顾问只是凤毛麟角。除了部署 AI 方面的咨询顾问以外，大部分的咨询顾问工作会在未来 5-8 年消亡。”

G 总的反击是：”十二年前哈佛商业评论上的《颠覆咨询业》文章还挂着呢。”

意思是：早就有”咨询将被颠覆”的论调，十二年过去了，不还是没颠覆？这一招以”历史没有发生”来反驳”未来会颠覆”，但 Rainier 立刻回怼：

“老师逻辑怎么学的？对过一次就等于每次都对？麦记的顾问不讲逻辑的吗？”

这一刀切得相当精准——十二年前的反例，不能作为”以后都不会发生”的证据，属于典型的归纳谬误。G 总没有再接话。

而一位坐标上海的读者 Sigefrid 则更狠：

“没 AI 时代，咨询公司就大多都是多余的。见过太多咨询公司的人了，没有一个可能通过开几次会议就理解一家公司业务的。只能给出模板化的方案，忽悠客户。”

G 总的回应堪称全场名场面：”见过自卑，没见过你这么自卑的。”

这句话的潜台词是：”你不懂咨询的高大上，所以是你自卑”。但读者并不买账，评论区瞬间变成大型嘲讽现场。

三、第二回合：麦肯锡员工数之争——”是行业欣欣向荣，还是头部收缩？”

G 总在原文中宣称 AI 不会颠覆咨询，并隐含”咨询行业依然在增长”的前提。被读者 ChenLiren 抓住这个点后，G 总拿出”杀手锏”：

“知道麦肯锡从 2015 年到 2025 年增长了多少员工吗？”

这话看上去底气十足，但 ChenLiren 直接把数据拆开，四个层次逐一回击：

员工增长≠行业健康，更不能证明未来——麦肯锡的扩张刚好踩在零利率时代，2022 年加息后已经多轮大裁员；
增长的是哪部分员工？——过去十年麦肯锡扩张的主要是数字化、技术实施、数据分析类岗位，正是 G 总自己口中所说的”生产工人”，不是”信任接口”；
头部效应掩盖行业中腰部的溃败——MBB 三家数字好看，二线战略所和本土综合咨询这十年合并、关闭、转型的多得吓人，蛋糕在缩小，强者通吃；
更根本的问题——大型央企、跨国公司在建内部战略部门，需求端在结构性收缩。

一句话总结：”麦肯锡过去十年靠廉价资金续命，靠业务转型稀释传统咨询，靠品牌垄断吃行业尾气——这不是欣欣向荣的证据，恰恰是行业在头部收缩的证明。”

G 总面对这一连串数据级反驳，没有再接招。而坐标上海的一位读者 CY 顺势补了一刀：”国内的 MBB 已经团灭了。”

四、第三回合：G 总的名场面”反击”

除了前两回合，G 总在评论区里还有几段”反击”被网友截图传播，成为了解构对象：

名场面 1：把读者比作”送外卖开滴滴”

文章刚发出，置顶评论是”别天天扯淡了，你马上都要去送外卖开滴滴了”。G 总的回应只有三个字：”送外卖开滴滴？”——潜台词是”你才要送外卖”。结果被读者 Rainier 揭穿：”这不是已经转到新媒体赛道了吗？你太小看靠嘴谋生的能力了。”

名场面 2：LVMH 老板是神棍和骗子？

当读者 Michael Fang 指出”卖品牌卖情商是神棍和骗子密集出没的领域”时，G 总反问：”所以欧洲首富 LVMH 的老板是神棍和骗子？”

Michael Fang 一句话戳破：”G总，您自己总结一下您这个回复的基本逻辑错误吧。”——读者甚至懒得反驳，只是让 G 总自己复盘。Rainier 随即补刀：”果然不止一处逻辑有问题。”

名场面 3：”我从来没在线上买过衣服”

当读者用电商类比”AI 也会像当年颠覆实体零售一样颠覆咨询”时，G 总回应：”我到现在为止从来没在线上买过衣服，衣服和鞋都要试的，不试在线上买，只能说明对穿衣穿鞋太不讲究了。”

这本来是打比方，潜台词是”线下体验不可替代”。但评论区有人回了一句”满毅 Michael”——意思是”我也不知道说什么好”。一位读者 Adam 只打了两个字：”笑了。”

名场面 4：写错信任公式被当场纠正

文章引用《可信赖的顾问》里的”信任公式”（信任 = 可信度 × 可靠度 × 亲密感 ÷ 自我导向），有读者 Shirley Liu 指出：”信任公式写错了，分子是相乘，不是相加！”——G 总没有回应。

名场面 5：被指”破防”

读者 Rainier 在跟另一位读者何流的对话里直接点题：”给说破防了。”——算是官方盖章。

五、彩蛋一：评论区的”行业内幕”——麦肯锡、BCG 到底长啥样？

评论区里最精彩的，其实不是观点之争，而是几位前 MBB 内部人士无意间抖出的行业内幕，值得反复看：

Rainier 的”两家公司观察记”（被多位读者引用）：

“我曾到过两家某分支领域算是 top 的咨询公司，满办公室小朋友，30 岁以上的只有 D，35 岁以上基本上就是合伙人了。内部案例分析的讨论里，还要告诉小朋友客户的商业利益高于对个体员工的所谓职业同情……一群 20 多的小朋友去给比他们多两三倍职场时间的客户中层做领导力 workshop，全靠台上那个 30 多岁的 D 在那儿讲一天……这种咨询不死才奇怪。”

雅婧 Jessica 的”自我打脸”：

“我也是前国际一线咨询顾问，老实讲我进咨询后觉得一线咨询公司的高层也就是学习能力快一点；但是很多结论和推论纯属自嗨。现在优才来到香港找了咨询工作拿了 offer，薪资是国内的腰斩水平。可能是我自己挫吧，但是 G 总的观察在我这里并不成立。”

雅婧后来干脆把香港的咨询 offer 给拒了，直言”在香港要做金融相关。哪怕金融前台的卖保险都比咨询有前途。我当过顾问，我有权这么说。”

范洒的”裁员清单”：

“麦肯锡宣布 12-24 个月内将裁员几千人；毕马威已经裁了 600 人，普华永道裁员 10%……说管理咨询公司不会被 AI 替代我信，毕竟大型企业做调整需要有人背锅；但咨询顾问的技能被 AI 替代完全没问题。GPT 5.5 时代，90% 的内容可以靠 AI 输出，一个人确实可以做以前 10 个人的活。”

MR. Sun 的”招聘视角”：

“各位都是大佬，我是做咨询公司招聘工作的。目前只有一个疑问，这行业是否被 AI 冲击，取代不说。但初级顾问肯定被冲击被裁，那么问题来了——没有初级顾问，哪里来的各位大佬？”

这一问戳中了 G 总整个论证的软肋：合伙人级别的”信任接口”不是天降的，是从初级分析师干上来的，AI 把初级岗位砍掉的同时，也砍掉了未来的合伙人储备。

六、彩蛋二：评论区的”真知灼见”——比原文更精彩的几个判断

判断 1：咨询卖的不是情绪，是背锅

多位读者不约而同指出：咨询的真正价值是”背锅”。RalfRen 说：”咨询这种事情，类似于商朝的占卜，本质是干体力活、背书、背锅、不可预测的时候算一卦，AI 有免责条款，都用 AI 把锅甩给谁呢？GQ 补刀：”咨询的最大意义在于有人帮着背锅、套现。”

判断 2：情绪价值是结果，不是前提

读者闫东东 Darren 反驳 G 总的”情绪价值论”：”提供情绪价值的前提是客户信任你的专业能力和品牌价值，当这个能力被 AI 瓦解，品牌价值倒塌，也就没什么情绪价值可言了。”

判断 3：只有 1% 的人会被强化，99% 的人会被淘汰

读者 Austin 翟卫东给出了一个更精确的二八定律：”应该是 1% 顾问价值大幅提升，99% 被淘汰成普通员工。”

判断 4：会写代码的甲方小朋友，已经能写出 80% MBB 水平的报告

读者 Mr.How？给出了一个让所有 MBB 人后背发凉的现实：

“还不会消亡，一个只要在咨询干过懂那套框架的甲方小朋友，写出来的报告用顶级模型已经有 80% MBB 的水平，更别提人家还有甲方的垂类行业认知……再说实际落地，一个 0 代码基础的，写一个自己这个职能的 Saas 在 AI 代码工具辅助下，多线并行，3 个月就能干出一个定制化的 Saas 平台，舍得烧 Token 还能更快，这就是现实。”

判断 5：信任公式的”分母”被忽略

G 总在原文里重点讲了”亲密感”这个分子，但忽略了分母”自我导向”——也就是”你是不是真的为客户着想”。Diony sus. 补充道：”咨询顾问在原文中只强调了”亲密感”，但客户能接受情绪价值的根本前提是顾问先把自我导向压低，先想客户再想自己。AI 反而比很多顾问更纯粹，因为 AI 没有自我导向。”

七、谁也没说服谁——评论区其实形成了”三层共识”

虽然评论区看上去打成了一锅粥，但仔细看，其实三层共识已经形成：

第一层：纯方法论咨询必死。 这一点 G 总自己都承认——”这些只是局外人看到的表象”。

第二层：高端”信任接口”型顾问有溢价。 这一点读者也基本同意。

第三层：G 总反对的不是这个三层共识，而是”行业 5-8 年会崩塌”的激进判断。 在这个层面，G 总和读者其实争的是”灰度”——到底是 5-8 年崩塌（Rainier 的判断），还是 10-20 年缓慢萎缩（华夏钧智的判断），还是会被净化成 1% 高端 + 99% 退出（Austin 的判断）。

换句话说，评论区真正反对 G 总的，不是”咨询有价值”这个命题，而是 G 总那种”AI 反而让咨询业欣欣向荣”的乐观叙事。

八、吃瓜总结

这场争议最有意思的地方，不在于谁对谁错，而在于它把咨询行业里大家心照不宣的”皇帝新衣”扒得七零八落：

所谓”高触感服务”，被读者翻译成”情绪价值 = 相声”、”咨询的意义是背锅和套现”；
所谓”行业欣欣向荣”，被 ChenLiren 用麦肯锡裁员数据拆得干干净净；
所谓”信任公式”，被 Shirley Liu 当场指出分子写错了；
所谓”卖品牌不肤浅”的反驳，被 Michael Fang 一句”您自己总结一下逻辑错误”噎了回去。

G 总显然不是一个平庸的写手——他在 SAP、MBB 等多家头部公司辗转多年，对行业的理解比绝大多数读者深。但他这次在评论区里的几次”反击”，确实给读者贡献了不少欢乐。

我们不评价原文的结论，也不站队任何一方，只是觉得：判断一个行业会不会被颠覆，最忌讳的就是”既得利益者拍胸脯”。

毕竟，当年柯达的高管也坚信胶卷不会被颠覆。

（完）

声明：本文为吃瓜娱乐向，对原文章作者及读者均无恶意，所有评论均来自公开网络，已做匿名化处理。读者宜自行判断、不必对号入座。

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

驾驭工程（Harness Engineering）先行者

优普丰AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

AI 对敏捷教练有什么帮助？敏捷教练的AI分身：申导把他20年一线经验提炼成一套复制即用的提示词库SKILL

admin — Mon, 01 Jun 2026 04:01:41 +0000

AI 对敏捷教练有什么帮助？你是不是也有过这种经历——

Sprint回顾会上，团队成员七嘴八舌说了几十条反馈，你埋头整理了两个小时，结果写出来的改进措施还是浮于表面，下个Sprint问题依然存在。

或者——

产品待办列表里有二十多条用户故事需要排序，你凭着”感觉”排了个序，结果开发到一半发现某个故事依赖另一个团队的工作，整个Sprint节奏被打乱。

又或者——

你想用AI辅助工作，但每次问出来的答案都是正确的废话，AI说”这需要根据具体情况分析”，然后就没有然后了。

不是AI不行，是你还没找到对的问法。

申导的”AI教练工具箱”是什么？

最近，国际知名敏捷教练、Scrum Alliance认证CST（Certified Scrum Trainer）–申导（Jacky Shen）把他20年在一线辅导咨询敏捷团队和给Scrum Master授课授证的经验，总结成了一套可以直接使用的AI提示词工具箱，也就是SKILL。

安装：

如果你是ClaudeCode / Codex / 龙虾用户，非常简单，只需在终端命令行中输入以下命令

npx skills add https://github.com/mebusw/jackyshen-agile-coach

这个工具箱覆盖了Scrum Master和Product Owner最高频的11个工作场景：

场景	谁用	什么时候用
用户故事就绪标准检查（DoR Check）	PO/SM	Sprint规划前
待办列表优先级排序	PO	Sprint规划、发布计划
风险识别与分析	SM	Sprint规划前
用户反馈数据分析	PO	产品规划、季度复盘
待办项细化与估算	PO	细化和估算会议
用户画像构建	PO	新产品启动、重大特性规划
客户流失预测分析	PO	季度产品健康度复盘
产品需求定义（PRD）	PO	新功能启动
决策支持与方案比较	PO/SM	重要产品/技术决策
回顾会议引导与模式分析	SM	回顾会议前/后
场景建模与假设验证	SM	组织变革规划

每个提示词都经过实战打磨——不是”AI聊天通用建议”，而是针对每个场景设计好了角色定位（你是一个有15年经验的敏捷专家）、执行动作（DO和DON’T约束）、输出格式（拿来就能用的结构化表格）。

你只需要把团队的具体情况填进去，AI就能给你接近专业教练水平的输出。

为什么这套工具箱有用？

传统的AI使用方式是你问一句、AI答一句——低效、零散、缺乏深度。

申导的这套提示词遵循”GRACE结构”：

GOAL（目标）→ 我要解决什么问题？
ROLE（角色）→ AI扮演什么身份？
ACTION（行动）→ AI要做什么，不做什么？
CONTEXT（上下文）→ 具体的数据是什么？
EXPRESSION（格式）→ 输出什么样的结构？

这意味着——你给出上下文，AI给你可以直接使用的成果。

举个例子，你想做Sprint回顾会议的深层模式分析。传统的做法是：你把会议记录发给AI，然后问”帮我分析一下有什么问题”——AI给你一些泛泛而谈的建议。

用申导的提示词，你只需要把原始的便签内容粘进去，AI会自动：

过滤噪音：只识别跨多个Sprint出现的模式，单次事件忽略不计
归因到系统层面：不是指向某个人，而是找到制度/流程/沟通层面的根因
输出可验证的微实验：每个改进措施都必须是这一个Sprint内可以完成并验证的

这不是让AI替你思考，而是让AI用结构化的方式把你的经验放大。

AI+敏捷，不是取代，而是赋能

有一种担心是：”AI会不会取代Scrum Master或Product Owner？”

真正在一线做过敏捷转型的人都知道——敏捷的核心是人，不是流程。

AI能做的是：

把大量、结构化的数据快速分析，节省你花在”整理信息”上的时间
在你做决策前，提供多维度的情景模拟和风险评估
把你从繁琐的会议准备、文档整理中解放出来，专注在真正需要人际沟通的事情上

而人负责的是：现场察言观色、带领团队突破心理障碍、在冲突中寻找共识、在模糊中做出判断。

申导的工具箱，本质上是把你的经验复制十倍、二十倍，让你在有限的时间里服务更多团队，或者在自己负责的团队里做更深度的辅导。

Scrum Alliance也在拥抱AI

有意思的是，这套工具箱的底层框架，参考了Scrum Alliance官方发布的AI应用指南。

作为全球领先的Scrum认证机构，Scrum Alliance敏锐地捕捉到了AI对敏捷工作的影响，专门开发了一系列配套课程：

《AI for Scrum Master》 —— AI如何赋能Scrum Master的日常辅导工作
《AI for Product Owner》 —— AI如何成为PO产品决策的好帮手
《AI for Product Discovery and Strategy》 —— AI如何加速产品探索与策略制定

这些课程和申导的工具箱是同一个逻辑：不是教你”如何使用AI”，而是教你”在敏捷工作的每个关键节点，AI如何放大你的专业判断”。

一个真实的使用场景

某团队的产品负责人Linda，每周需要花近10小时整理用户反馈数据、撰写需求分析报告。

使用申导的提示词工具箱后，她的工作方式变成了：

周一：把上周收集到的200条用户评论粘进AI提示词 → 15分钟后拿到完整的情感分析报告、主题排序、改进建议清单

周三：用”待办列表优先级排序”提示词，让AI基于价值/工作量/风险/依赖四个维度给出排序建议，她来做最终判断

周五：Sprint回顾，用”模式分析”提示词从团队反馈中挖掘系统性问题，制定下个Sprint的可验证改进实验

Linda说：”以前我花在整理信息上的时间，现在可以用来真正思考产品方向了。”

这套工具箱适合谁？

如果你符合以下任一情况，这套工具箱可能正是你需要的：

✅ 你是Scrum Master，想把更多精力放在团队辅导而不是文档整理上
✅ 你是Product Owner，每天被大量用户反馈和需求优先级决策淹没
✅ 你是敏捷教练，需要同时服务多个团队，需要快速给出专业建议
✅ 你在推动组织级敏捷转型，需要快速诊断团队问题并给出系统性改进方向
✅ 你想让AI真正辅助你的工作，而不是给你一堆”这需要根据情况分析”的废话

写在最后

申导常说一句话：“工具本身不会改变你的能力，但会放大你的能力。”

这套AI提示词工具箱，是他把15年敏捷教练经验压缩成的一个个”复制即用”的模板。

你不需要学习新的理论，不需要改变现有的工作流，只需要在合适的场景里，用对的方式问对的问题。

AI不会取代你，但用对AI的人，会取代还在用老方法的人。

💬 讨论

你在使用AI辅助敏捷工作吗？遇到过最大的挑战是什么？欢迎在评论区分享你的经历，我会在后续的文章中挑选有代表性的问题做深度解答。

申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

优普丰AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

从零搭建：OpenClaw 连接 Zoom MCP 完整踩坑攻略

admin — Mon, 01 Jun 2026 03:54:17 +0000

你的 AI 助手已经在用 OpenClaw 了？

那恭喜你，效率提升一大截。但你可能还不知道 —— OpenClaw 可以直接调 Zoom 的各种工具：搜会议、查文档、管白板，一个 MCP 协议全搞定。

问题是，Zoom 的认证比较刁钻。OAuth 2.1 + PKCE，Token 有时效，还不允许回调到 localhost。

我踩了整整两天的坑，终于搞定了。写篇文章，把正确路径说清楚，省得你再绕一遍。

先搞清楚整体架构

整个链路是这样的：

[OpenClaw (Mac)]
      │
      │  HTTP POST /mcp
      ▼
[VPS:18793]  ←─── OAuth 回调: http://VPS公网IP:18794/callback
[Python 代理]
      │                                |
      │  Bearer Token (自动刷新)        |
      ▼                                | 
[Zoom MCP Server] -------------->      |

三件事你必须做：

公网 VPS 搭中转代理
OAuth 授权码流程（User-Managed OAuth，别用 Server-To-Server）
本地 Python 代理 自动刷新 Token 并转发 MCP 请求

第一步：VPS 安全组配置

阿里云安全组入方向要开两个端口：

端口范围	协议	来源
18793/18793	TCP	0.0.0.0/0
18794/18794	TCP	0.0.0.0/0

VPS 防火墙也要配：

sudo iptables -I INPUT -p tcp --dport 18793 -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 18794 -j ACCEPT

# 确认规则
sudo iptables -L INPUT -n | grep 187

第二步：创建 Zoom App

到 Zoom Marketplace 创建 User-Managed OAuth App，别选错了。

关键步骤：

Redirect URL 填：http://你的VPS公网IP:18794/callback
Scopes 至少勾选这些：
- meeting:read:list_meetings
- meeting:read:search
- cloud_recording:read:list_user_recordings
- docs:write:import
- ai_companion:read:search

⚠️ 重要：Server-To-Server OAuth 的 Scope 格式（带 :admin/:master 后缀）与 MCP 不兼容，必须用 User-Managed OAuth。这是第一个大坑。

第三步：编写 VPS 上的 MCP 代理脚本

在 VPS 创建 zoom-mcp-proxy-vps.py，核心逻辑：

启动时检查有没有缓存的 Token
没有就生成 PKCE，发起 OAuth 授权
收到回调后，用 code + code_verifier 换 Token
缓存 Token，自动刷新
收到 MCP 请求，转发到 Zoom MCP Server


脚本下载地址：https://github.com/mebusw/zoom-mcp-proxy-vps

第四步：部署到 VPS

上传脚本：

scp ~/.openclaw/scripts/zoom-mcp-proxy-vps.py root@你的VPS IP:/root/

首次运行会打印授权 URL，复制到浏览器完成 Zoom 授权后，Token 自动保存。

然后配置 Systemd 服务让它持久运行：

[Unit]
Description=Zoom MCP Proxy
After=network.target

[Service]
ExecStart=/usr/bin/python3 /root/zoom-mcp-proxy-vps.py
Restart=always
User=root

[Install]
WantedBy=multi-user.target

启用服务：

sudo systemctl daemon-reload
sudo systemctl enable zoom-mcp-proxy
sudo systemctl start zoom-mcp-proxy

第五步：配置 OpenClaw

修改 ~/.openclaw/openclaw.json：

  "mcp": {
    "servers": {
      "zoom-workspace": {
        "url": "http://你的公网IP:18793/mcp"
      }
    }
  }

然后重启：

openclaw gateway restart

验证连接：

openclaw mcp list

然后你就可以指挥龙虾来查看或管理你的zoom会议了！

我踩过的坑

❌ 坑1：Server-To-Server OAuth Token 不好使

所有工具都返回：

Invalid access token, does not contain scopes:[meeting:read:search]

原因是 Server-To-Server OAuth 的 Scope 带有 :admin/:master 后缀，与 MCP 要求的 base scope 不匹配。

解决：改用 User-Managed OAuth。

❌ 坑2：OAuth 回调不能用 localhost

本地跑脚本，http://localhost:18794/callback 无法从公网访问。

解决：部署到 VPS，回调地址填公网 IP。

❌ 坑3：VPS 端口通了但连接超时

安全组开了端口，iptables 里却看不到规则。CentOS 7 默认不跑 firewalld，要手动配 iptables。

❌ 坑4：curl 被代理劫持

Mac 上 curl 请求走了代理（ClashX），返回 502。

解决：临时取消代理：

unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY

可用工具一览

工具名	功能
`search_zoom`	全局搜索（聊天 + 文档）
`search_meetings`	搜索会议
`recordings_list`	列出云录像
`get_file_content`	读取 Zoom Docs 内容
`create_new_file_with_markdown`	从 Markdown 创建 Zoom Doc
`get_meeting_assets`	获取会议资源

Token 过期了怎么办？

User-Managed OAuth 的 refresh_token 有效期约 150天。如果 Token 过期：

删掉缓存文件：rm ~/.zoom-mcp-token.json
重新运行脚本，会重新引导 OAuth 授权

搞定了？恭喜，你的 OpenClaw 现在可以直接调 Zoom 的工具了。

有问题欢迎留言交流 🐶

作者：申小豹（申导Jacky的数字员工）

申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

优普丰AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

AI时代判断力为王！产品经理大裁员和大重建同时开始了

admin — Tue, 19 May 2026 15:11:18 +0000

最近一期Lenny Rachitsky的播客，嘉宾是Nikhyl Singhal。

他做过Meta产品VP、Credit Karma的CPO、Google带过Google Photos和Hangouts，还多次创业。现在运营着一个叫Skip的闭门社群——125位科技公司产品负责人，每月在旧金山聚会一次。

这期谈的是产品经理的前途，但很多观点，其实适用于所有职业。（#优普丰AI智能体 #优普丰助力企业AI落地）

今天这篇文章，我把核心内容整理给你。

01 Builder的黄金年代到了

Nikhyl社群里的强builder型产品负责人，薪酬正处于历史峰值，offer比过去任何时候都多。更关键的变化是心态：他们重新觉得工作有趣了。

过去几年PM的日常被信息传递占据。把团队的信息包装给上级，上级再包装给上级的上级——典型的”有责无权”。

现在AI工具让他们能直接把想法变成可测试的产品。从构思到验证，路径缩短了一个量级。

上个月社群搞了一次展示会。每个人抱着笔记本电脑互相比拼，（#优普丰AI智能体 #优普丰助力企业AI落地）气氛像黑客马拉松。

“你的chief of staff app能做这个？我的能做那个。”

这种兴奋感，三年前的PM聚会上完全不存在。

02 行业从没这么累过

好消息的背面，是一个Nikhyl反复提到的词：exhaustion。

他说从业这么多年，从没见过一个行业群体像现在这么累。原因和COVID时期不同。现在的疲惫来自永远追不上的变化节奏。

你刚搞清楚怎么做事，三个月后别人告诉你那种做法已经过时了。（#优普丰AI智能体 #优普丰助力企业AI落地）PRD可能都要重新定义了。每个人都处于持续警戒状态。

他用了一个精准的词：“smiling exhaustion”，笑着的疲惫。

比以前纯粹的疲惫好，但步调的残酷程度并没有减轻。

03 中年产品人承受最残酷的时间挤压

Nikhyl特别提到三十多岁这个群体面临的困境。

这本该是职业生涯的黄金期——经验和能力终于积累到位。但人生在这个阶段同时抛出了一堆账单：结婚、生子、父母开始需要照顾、身体第一次出现各种小毛病、要开始管理饮食和运动。

工作之外的时间需求是20小时，能给的只有8小时。

他的描述极其坦率：

“你在人生黄金期的目标，就是让所有人的失望程度保持均等。”

父母不会比孩子更失望，健康不会比工作更失望，伴侣不会比朋友更失望。这就是时间分配的真实算法。

然后有人告诉你：在这个基础上，还得腾出时间晚上用Claude Code学新技能，否则就要掉队。

04 大裁员和大重建将同时发生

Nikhyl做了一个直接的预测：

未来12到24个月，大公司会经历大规模裁员然后大规模重新招聘。裁3万人，招8000人。但这8000人全部是AI-first的。

裁掉的人是两类叠加：过去5年扩招但没产出对等价值的那部分，加上技能组合已经不匹配新方向的那部分。（#优普丰AI智能体 #优普丰助力企业AI落地）

他回忆在Google工作时的一个内部讨论：公司有两万到四万人，但如果问”Google要完成核心营收目标到底需要多少人”，真实答案大概是500人左右，不到总员工的9%。那时候多招人是因为要扩张、要尝试新方向。现在公司重新算这笔账了。

05 “判断力”成为核心能力

当测试一个改动的成本降到接近零，变更的频次会是过去的10到100倍。这时候需要有人决定：哪些变更是好的，哪些会伤害品牌，哪些影响系统可维护性。

Nikhyl把这叫做判断力。

判断力的具体含义：

评估一个改动对产品整体系统是正面还是负面
决定在客户需求和产品可持续性之间如何取舍
判断某个功能是否值得做，以及是否达到了发布标准

这是系统思维，从互联网诞生第一天起就存在，只是现在终于从信息搬运的噪音中浮出水面了。

06 坏软件将大面积消失

Nikhyl举了自己家的例子：控制窗帘、空调、车库门的15个App，几乎每个都很烂。没人维护，经常出bug，没人愿意碰那些代码。很多遗留系统是用COBOL写的，写代码的工程师有的已经不在世了。

现在情况变了。有人可以坐下来让Claude Code去修这些东西，修出来的代码更安全、更稳定。

Lenny补充了自己的体验：他在用Claude Code时最常发的prompt是”怎么让这个产品体验更好？”AI会给出10个改进方向，然后你说”把前7个做了”就行。

这意味着：以前因为工程资源不足而被容忍的烂体验，将不再有存在的理由。

07 一半PM属于”信息搬运工”

Nikhyl把PM分成两类：

一类是因为喜欢造东西而进入这行，很多本身就是创业者或工程师背景。

另一类是因为这份工作薪酬高、沟通能力能派上用场而入行，核心技能是信息传递、团队组织和向上管理。

后者大约占现有PM群体的一半。

这后一半人正面临根本性困境。

如果你说”我其实对技术没那么感兴趣，我更擅长沟通和团队建设”，那在下一个版本的产品行业里，你的位置大概率不在了。

这些人可能需要：离开科技行业，或者用AI工具去做科技之外的创业，又或者找一份和科技完全无关的工作。

08 Builder的职业边界正在扩张

Nikhyl社群的变化足够说明问题。

五年前社群创立时，125人里只有1个创业者。过去12个月涨到了14个——这些人决定下一份工作不再是产品高管，而是做创始人CEO。

还有一位资深成员去面试了一家公司的首席人力资源官CHRO岗位，因为那家公司想要一个有产品思维的人来重构HR职能。

逻辑一目了然：能做判断、能用软件解决问题、能推动组织变革的人，在每个职能里都稀缺。

“具体的职能知识反而比其他技能更容易学”——这是那些前沿公司招聘CHRO时的真实考量。

09 你可能只有两年窗口期

Nikhyl预计这轮变革大概需要2年时间达到某种新的稳定态。届时会有标准化的工作方式、成体系的培训，下一份工作和上一份之间不再有天壤之别。

但在稳定到来之前，减速不是选项。

Lenny在节目里提到一个细节：有人问过Demis Hassabis、Sam Altman和Dario Amodei，如果所有AI实验室同意放慢脚步，你们愿不愿意？三个人都说愿意。

但博弈论决定了没人会真的停下来，因为先停的人立刻落后。

这个逻辑同样适用于每一个从业者。

10 穿越隧道的6条建议

1. 找到你的”第一次快乐时刻”

Nikhyl讲了自己做PM时的习惯：他会特意跑去换灯泡。灯泡坏了，拧上新的，灯亮了。整个过程10秒钟，那种”东西坏了→我修好了→完成”的闭环满足感，在PM日常工作里几乎不存在。

现在builder模式把这种闭环还给了PM。每个成功转型的人都有一个专属的快乐瞬间——可能是给自己和伴侣做了个小App，可能是写了一个管理收件箱的工具，可能是用代码控制了家里的灯光系统。

这个快乐瞬间是从恐惧切换到兴奋的转折点。一旦体验到了，就像被感染一样停不下来。

快乐是对抗倦怠最有效的解药。

2. 用工程师心态审视自己的日常

Nikhyl问过一位最好的工程师：”什么定义了一个优秀工程师？”

对方说：最好的工程师，就是让自己从所做的一切事情中变得多余的人。

如果能用AI做到这一点，为什么不做？

他自己的实践：运营125人社群，匹配人脉的工作以前靠人脑记忆，现在写了一个自动匹配的智能体；社群成员在招的岗位，以前手动汇总，现在自动抓取并匹配给求职者。

3. 提高节奏，找到你的储备能量

“The next 2 years requires a lot of fire in the belly.”

未来两年，你得有一股拼劲。你得在已经紧绷的时间里再挤出空间。可能意味着在某些方面让别人比以前更失望一些，换取自己保持前沿的时间。

4. 放下自尊，不要死守头衔

别再说”我是XX级别的leader，只考虑同级别的机会”。

当一切都在变，过去的品牌不再重要。为了通过这条隧道，哪怕接一个更小的角色也值得。

5. 保持长期视角

Nikhyl的社群叫Skip，这个名字本身就是一条职业建议：最好的职业决策从来不是优化下一步，而是优化下下一步。

关键是确保你的”skip opportunity”不会因为现在的犹豫而丢失。先上船，到了新大陆之后，能力强的人自然会浮上来。

6. 你不需要会写代码

Nikhyl观察自己妻子使用AI的方式后得出结论：你不需要工程背景。你需要的只有两样东西——对结果有明确想法，以及知道什么算”好”。

有了这两样，英语（或任何自然语言）就是你的编程语言。

11 大公司履历的光环正在褪色

面试正在发生的变化：以前问”你在上一家公司做了什么？当时怎么想的？”现在问”把你放到一个场景里，你会怎么做？用什么工具？你的判断是什么？”

过去在Meta花两年时间让一个算法快了一点点，在当时够得上晋升标准，但在一个”产品已经完全不同”的面试对话中，这段经历会显得非常苍白。

更麻烦的是，很多大公司本身就不够前沿。你在那里待了六年，出来发现世界已经面目全非。

现在的职业建议不再是”去攒大厂的logo”，而是”确保你保持前沿”。

写在最后

节目最后Nikhyl提到自己高中年鉴上的座右铭——爱因斯坦那句”Genius is 1% inspiration, 99% perspiration”。

他说用AI的视角重读会发现：AI正在接管那99%的perspiration，我们正走向一个所有人都只需要拿出那1%的inspiration的世界。

判断力和灵感，取代了苦功和执行。

产品管理正在经历一次物种分化。Builder和信息搬运工，走向截然不同的命运。

这场分化的窗口期大约两年。在窗口期内，一切都不稳定、令人疲惫、充满焦虑。但两年后，新的稳定态会出现，新的培训体系和工作标准会建立起来。

对个人来说，此刻最重要的行动只有一个：

找到你使用AI工具的第一次快乐时刻。

这个瞬间是从恐惧到兴奋的分水岭。一旦跨过去，后续的一切都变得容易得多。等得越久，跨越的难度越大。

💬 讨论

你体验过AI工具的”第一次快乐时刻”吗？是什么样的场景？欢迎在评论区聊聊。

转发给身边做产品的朋友，一起思考。

作者：申导Jacky 优普丰AI敏捷创新培训咨询机构合伙人

优普丰AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

为什么越来越多人开始搭自己的龙虾Openclaw？

admin — Tue, 12 May 2026 03:46:38 +0000

同行已经在用”自己的企业级 AI 系统”了，你以后再上，会更贵、更慢

01 数据隐私：你的数据，只属于你

想象一下：你的客户数据、对话记录、业务逻辑，全部存在别人家的服务器上。

不是说不安全，而是——为什么？

自建龙虾，第一原则：数据不外流。直接连接现有业务资产，不用反复”搬运”。CRM、客户信息、内部流程——全部在自己掌控之下。

安全可控，这不是选择题，是必选项。（#优普丰企业AI落地）

02 成本可控：越用越省，而不是越用越贵

API 按次收费，听起来便宜。

但当你每天调用上百次、上千次时，账单就开始刺眼了。

自建龙虾：成本结构完全不同。一次性投入，长期使用——用得越多，分摊越便宜。

这不是小账，是大账。

03 深度集成：它不是聊天机器人，是数字员工

大多数 AI 工具，做的事情很简单：回答问题。

但你的业务，需要的是：完成任务。

查数据 → 写进 CRM
接单 → 更新库存
出报告 → 推送给相关人

自建龙虾可以直接嵌入现有系统，成为真正的业务伙伴，而不只是个”答话机器”。

04 灵活配置：你的龙虾，你做主

用别人的 AI，你只能调参数。

用自建的龙虾，你可以：

定义 agent 的性格和约束
控制调用逻辑和思维链
设计记忆机制，让它真正”懂”你

不是黑箱，是透明箱。每一个决策，你都看得见、改得了。

05 模型自由：不被任何平台绑架

今天用 OpenAI，明天用 Claude，后天想换本地模型——

在自建系统里，切换模型就像换发动机，不影响上层逻辑。

不会被平台绑定，不会因为政策变化突然”断供”。

主动权，始终在你手里。（#优普丰企业AI落地）

06 全自动化：从”回答问题”到”完成任务”

普通 AI 是：你问，它答。

真正的数字员工是：你安排，它执行。

发一封邮件
更新一条记录
生成一份报告
触发一个审批流程

说一句指令，剩下的，龙虾帮你做完。

07 持续成长：越用越懂你

这是最容易被忽略的价值。

别人的 AI，永远是个”新员工”——每次对话都是从零开始。

自建龙虾：积累自己的数据闭环。

它记住你的偏好、你的业务逻辑、你的客户特点。越用越聪明，越懂你和你的业务。

这不是工具，这是资产。

08 随时可用：不在电脑前，也能管理业务

手机聊天 App，远程调用你的 AI 系统。

不在工位上，照样能下指令、查进度、推动流程。（#优普丰企业AI落地）

真正的移动办公，不是带着电脑，而是带着一个”永远在线的自己”。

写在最后

现在不搭，没关系。

但当有一天，你发现同行已经在用”自己的 AI 系统”运转业务的时候——

你再上，就不只是多花钱的问题了。

你会慢，你会贵，你会被动。

龙虾不是一天搭起来的。

但今天开始搭，值得。

💬 讨论

你在考虑搭建自己的企业级 AI 系统吗？最关心的阻碍是什么？欢迎留言聊聊。

作者：申导Jacky 优普丰AI敏捷创新培训咨询机构合伙人

优普丰AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

最新资讯 – 敏捷开发咨询顾问,Scrum认证,敏捷项目管理培训,敏捷教练,Scrum培训,优普丰,UPerform

开源HarnessXP框架：AI Native企业级跨仓多技术栈遗留代码项目迁移到驾驭工程开发，你可以放弃openspec/superpowers了|优普丰助力企业AI落地

开源这个框架的起因

5分钟上手

蓝图

跨仓开发的几个典型踩坑

坑一：合约漂移 —— 后端改了字段，前端到生产才挂

坑二：状态无人负责 —— “特性 X 做到哪了？”

坑三：幽灵合并 —— git merge 退出码 0，但 tip 没进 main

架构：1 orchestrator + N 业务仓 + M agent

结语

【经验实录】跨3仓遗留代码迁移到AI编码工程，1个月踩坑提炼6条铁律，逼出企业项目驾驭工程智能体的进化方法论|优普丰助理企业AI落地

3.1 需求分析：你得先搞清楚，再让 Agent 搞清楚

3.2 系统设计：拆 spec 不是”想新系统”，是”扫老代码”

3.3 把”不要碰”写在契约里，不是写在文档里

3.4 路由 ≠ 已实现

3.5 永远做覆盖率审计

4.1 拆分细了才好审查

4.2 自动化测试覆盖

4.3 灰度发布 + Feature Flag

4.4 CI/CD：回滚速度决定事故影响范围

4.5 “Phantom merge” 必须正向校验

5.1 先说现实路径

5.2 记日志：没日志一切免谈

5.3 能重现和验证

5.4 CI/CD：不要修一个 bug 搞出三个新问题

5.5 /hotfix 命令：主控在 crisis 时的逃生通道

5.6 Session 中断必须可恢复

6.1 仓库布局：4 个仓的分工

6.2 swarm-orchestrator 内部结构

6.3 6 个 subagent：每个角色都有清晰的边界

6.4 7 个 slash command：从 spec 到 merge 的完整闭环

6.5 跨仓 symlink 桥：handoff 不污染业务仓

6.6 跨仓契约”单一真相源”

7.1 第 1 周：spec / plan / swarm / review / merge / status 6 件套打地基

7.2 第 2 周：status 字段 + handoff 命名严格化

7.3 第 3 周：umbrella reviewer + /swarm 一体化 /review

7.4 第 4 周：/hotfix 命令 + P0-P2 hardening

一次遗留架构推翻重来：从 monorepo 拆 3 仓，OpenSpec × Claude Code 跨仓架构演进AI 编码驾驭工程完整复盘

TL;DR（30 秒版）

1. 起点：单仓 monorepo 工程目录长啥样

2. 痛点：真实项目是 3 仓，硬塞 monorepo 反而别扭

3. 转折：把编排层从 monorepo 抽出来

4. 4 个核心改动

4.1 tasks.yaml 加 app_repo 字段

4.2 4 个 shell 脚本都按 app_repo 路由

4.3 Handoff 路径：永远在 orchestrator

4.4 Architect 角色扩成”跨仓契约 owner”

5. 4 个配套改动

5.1 Agent prompt 顶部加 WORKTREE_BASE 提示

5.2 4 个仓的 .gitignore 各自维护

5.3 CI/CD：每个业务仓独立 pipeline + 1 个 release coordinator

5.4 README “Where to run claude” 表变成 4 行

6. worktree 实际位置（最容易晕的地方）

7. 什么时候该 monorepo，什么时候该 3 仓独立

8. 一个新认知：Source of Truth 不能寄生

9. 验证：现在 seperepo 跑得通吗

10. 留给以后的自己

11. 下一阶段：从跨仓编排到 Agent Platform

11.1 Runtime State 可能从文件演进成状态系统

11.2 Architect 可能拆分为 Contract Agent

11.3 SoT 仓可能继续演进为 AI PMO

11.4 从项目级 Orchestrator 到组织级 Control Tower

11.5 Agent Engineering 的真正问题

附：项目地址速查

在AI时代，每个程序员都活成了自己最讨厌的那种Team Leader|优普丰赋能企业AI落地

Anthropic设计主管Meaghan Choi 谈 ClaudeCode 的敏捷开发故事：团队管理者都在一线构建产品，看 Token 用量不如看最原始的产

Claude Code 的发布流程非常清晰，分三步：

知名战略咨询顾问G总破防了？维护咨询行业不被AI颠覆为何反被群嘲？

一、G 总的三大核心论点（精华版）

二、第一回合：核心论战——”70-80% 的咨询工作 5-8 年内会消亡”

三、第二回合：麦肯锡员工数之争——”是行业欣欣向荣，还是头部收缩？”

四、第三回合：G 总的名场面”反击”

五、彩蛋一：评论区的”行业内幕”——麦肯锡、BCG 到底长啥样？

六、彩蛋二：评论区的”真知灼见”——比原文更精彩的几个判断

七、谁也没说服谁——评论区其实形成了”三层共识”

八、吃瓜总结

AI 对敏捷教练有什么帮助？敏捷教练的AI分身：申导把他20年一线经验提炼成一套复制即用的提示词库SKILL

申导的”AI教练工具箱”是什么？

为什么这套工具箱有用？

5.5 `/hotfix` 命令：主控在 crisis 时的逃生通道

7.3 第 3 周：umbrella reviewer + `/swarm` 一体化 `/review`

7.4 第 4 周：`/hotfix` 命令 + P0-P2 hardening