admin – 敏捷开发咨询顾问,Scrum认证,敏捷项目管理培训,敏捷教练,Scrum培训,优普丰,UPerform

【全球首发】RSG大会专属培训课程《Creative Agility: AI 原生敏捷工作坊》从 Sprint-driven Delivery 到 Intent-to-Evidence Delivery

admin — Thu, 10 Sep 2026 15:04:58 +0000

欢迎来到优普丰AI敏捷创新咨询承办的2026年中国敏捷嘉年华大会——Regional Scrum Gathering™（#RSGSH26 9月12-13，上海），一天半的会议结束后，9月13日下午，RSG大会特别开设了一期培训课程，Bill老师和王朝成老师联袂授课，全球首发！

购买RSG大会门票者，只需加99元，即可参加。

课程名称：Creative Agility: AI 原生敏捷工作坊–从 Sprint-driven Delivery 到 Intent-to-Evidence Delivery当执行主体从 Human Team 变为 Human-Agent System，团队需要的不是更快的 Sprint，而是一套重新设计的操作模式。

Intent 意图 → Execution 自主执行 → Evidence 证据 → Learning 学习

Human owns meaning & accountability · Agents own bounded execution

课程内容

3.5 小时，你将经历（自带电脑实操 · 动手练习 ≥ 50%）

开场 Opening：AI 时代，敏捷为什么必须重构
主题 + Agent 现场演示 Keynote & Demo：第一性原理 · 双速循环 · Artifact-driven Agent 如何工作
Round 1 · 先失败 Traditional：用传统方式拆解模糊需求，让 Intent / 自主权 / 验证问题当场暴露
Round 2–3 · 再重构 AI-Native：上机实操：用四大核心工作件，重新设计你的人机交付系统
Evidence Gate Take-away：用证据做上线决策，映射你自己的 30-Day Pilot

全程上机实操· 请自带电脑

每组一个 Agent Workspace（5–6 人/组），现场跑通 Intent → Execution → Evidence 完整流程；也可使用自己的千问 / Kimi / DeepSeek / ChatGPT 全程参与。

四大核心工作件

01 Intent Artifacts 意图工作件 · 什么算成功、谁负责

02 Agent Work Package 智能体工作包 · 授权边界与升级条件

03 Verification Contract 验证契约 · 什么证据才算完成

04 Evidence Ledger 证据台账 · 偏差、成本与学习

带走的不只是概念

团队产出：

√ Intent Artifacts + 人机工作编排图

√ Agent 自主等级与 HITL 规则

√ Verification Contract

√ 一个 Evidence Gate 发布决策

个人带走：

My 30-Day AI Native Agile Pilot

一个真实工作· 30 天最小试点——第二天就能拿回团队讨论。

适合谁

研发负责人· 产品经理 · EA / 架构师 · Scrum Master · 敏捷教练 · 交付管理者

授课讲师：Bill li（李国彪）

大中华区敏捷导师第一人

国内敏捷Scrum引进推广先行者之一

优普丰AI敏捷创新咨询创始人、总裁

链接100位创变者，共同探索小而美极简商业模式

服务500+企业客户，10000+个人学员，完整经历移动通讯及互联网发展与创业大周期，深度研究AI落地应用和场景，发布《AI原住民宣言》

长年居住于加拿大，拥有国内外实践经验和双重视角，与Costco等甲方大厂、埃森哲、 OpenAI、加拿大联邦政府首席敏捷教练等多方碰撞与交流，并总结沉淀出行之有效的方法论，专程回国为RSG大会带来专属培训，全球首发。

授课讲师：王朝成

企业 AI 架构师 / FDE 实践者

创羽昀智能创始人兼CEO

浙江大学计算机硕士，前阿里高级技术专家、平安研发总监、饿了么高级架构师

10+ 年软件工程与复杂系统架构经验，8+ 年研发管理经验

曾负责大规模互联网系统及多个从 0 到 1 的技术与产品项目

近年专注企业 AI 与 FDE 实践，推动 AI 从技术验证走向真实业务交付

关注 AI Native Development、现场共创、快速原型、短周期验证与持续迭代

探索如何将 FDE 与敏捷方法结合，让技术团队更快理解业务、验证价值并完成交付闭环

培训时间和价格

9月13日 13:30-17:00

课程时长：3.5小时

课程形式：约45%理念讲解、45%小组练习、10%总结反思

AI-Native Scrum Guides

admin — Sat, 05 Sep 2026 07:46:44 +0000

人类负责、Agent 驱动的产品开发框架

Draft Version 0.2

作者：优普丰敏捷 AI 咨询，申导

目的

人工智能正在改变产品开发工作的基本结构。

过去，产品开发的主要生产能力存在于人类团队之中。知识、经验、专业技能和判断主要由人掌握，工具主要用于辅助人类完成工作。

随着 Agentic AI 的发展，越来越多原本依赖人类专业能力完成的工作，可以被显式地编码为：

Context
Skills
Agents
Evals
Gates
Hooks
Automated Toolchains

因此，团队不再只是由一组人组成。

团队正在成为：

由少量人类领导、由人类和 Agent 共同构成的能力系统。

AI-Native Scrum 为这种新的工作方式提供一个轻量级框架。

它保留 Scrum 的核心思想：

Empiricism
Lean Thinking
Self-Management
Transparency
Inspection
Adaptation

同时重新定义 AI-native 环境中的：

Team
Capability
Collaboration
Artifacts
Sprint
Execution
Human Accountability

AI-Native Scrum 的目的不是让团队：

更快地产生更多 AI Output。

它的目的，是帮助团队：

通过人类判断、共享 Context 和 Agentic Execution，持续创造经过验证的价值。

AI-Native Scrum 的定义

AI-Native Scrum 是一个轻量级框架，用于帮助人类领导的团队利用 Agentic Capability 解决复杂问题并创造价值。

AI-Native Scrum 中：

Human takes accountability.

人工智能可以自主执行工作。

但人工智能不承担最终 Accountability。

人类负责：

Value
Judgment
Trade-offs
Risk Acceptance
Accountability

Agents 可以承担：

Analysis
Exploration
Planning
Execution
Testing
Monitoring
Evaluation
Adaptation

AI-Native Scrum 的核心不是 Human 与 AI 的简单协作。

它是：

Human Accountability over Agentic Production.

AI-Native Scrum 理论

AI-Native Scrum 建立在经验主义之上。

知识来自经验。

决策基于已经观察到的结果。

AI-Native Scrum 使用：

Iteration
Increment
Automation
Agentic Execution

来提高学习速度和创造价值的能力。

经验主义依赖：

Transparency
Inspection
Adaptation

透明

重要的工作和创造价值的过程必须具有足够的透明度。

在 AI-Native Scrum 中，透明不仅包括工作状态。

还包括：

Intent
Context
Decisions
Constraints
Plans
Agent Actions
Evaluation Results
Evidence

Context 是透明的重要组成部分。

如果 Context 只存在于某个人的脑中，或者只被某一个 Agent 持有，那么团队无法有效检视和适应。

因此：

Context required to create value is a shared asset of the Scrum Team.

检视

工作结果和朝着目标的进展必须被经常检视。

AI-Native Scrum 不要求人类检视所有 Agent Output。

随着 Agent 的执行能力提高，这种方式无法扩展。

检视应重点关注：

Value
Risk
Exceptions
Uncertainty
Evaluation Failures
Important Trade-offs

Automation 和 Evals 应承担大量常规检视工作。

人类将注意力集中在：

需要判断的地方。

适应

当观察到的结果与预期存在偏差时，必须进行适应。

AI-Native Scrum 中，适应可能改变：

Product Direction
Intent
Context
Plans
Skills
Agents
Evals
Gates
Toolchain
Product

AI-Native Scrum Team 不仅适应产品。

它也持续适应：

创造产品的 Team Capability System。

AI-Native Scrum Values

AI-Native Scrum 保持以下 Scrum Values：

Commitment
Focus
Openness
Respect
Courage

这些价值观同样适用于 Agentic Environment。

其中，Openness 的实践范围扩展。

团队不仅对：

Work
Progress
Problems

保持开放。

还对：

Context
Decisions
Constraints
Knowledge

保持开放。

Collective Context Ownership

Context 是团队的共享资产。

它不属于某一个人。

也不属于某一个 Agent。

AI-Native Scrum Team 共同拥有创造价值所需要的 Context。

任何团队成员都可以：

补充 Context；
修正 Context；
改进 Context；
挑战过时的 Context。

这类似于 Extreme Programming 中的：

Collective Code Ownership。

在 AI-Native Scrum 中：

Collective Context Ownership.

避免 Context 成为：

Knowledge Silo；
Personal Dependency；
Agent Dependency。

AI-Native Scrum Team

AI-Native Scrum Team 是一个小型、自管理和跨职能的价值创造系统。

它包括三类 Human Accountabilities：

Product Owner
Developers
Scrum Master

AI-Native Scrum 不增加第四个 Agent Role。

Agents 不承担 Scrum Accountabilities。

Agents 是团队能力的一部分。

因此：

The Scrum Team is human-led. Its capability system may include both humans and agents.

Product Owner

Product Owner 对最大化产品价值负责。

Product Owner 对以下事项负责：

Product Goal；
Value；
Prioritization；
Product Direction；
Value-related Trade-offs。

AI 可以帮助 Product Owner：

分析用户反馈；
综合信息；
发现模式；
生成假设；
形成 Intent。

但是：

AI does not own the Product Goal.

Product Owner 保持最终 Accountability。

Developers

Developers 对创建可用 Increment 负责。

在 AI-Native Scrum 中，Developers 的工作能力来自：

Human Developers；
Agentic Capability；
Skills；
Context；
Toolchains；
Automated Controls。

因此，Developers 不应被理解为：

一组必须亲自完成所有工作的 Human。

Developers 是：

The human-led development capability responsible for creating the Increment.

人类 Developers 对结果保持 Accountability。

Agents 可以作为 Developers 的执行能力。

未来，一个 Developer Group 可能只有少量 Human Developers，同时领导：

Coding Agents；
Test Agents；
Review Agents；
Research Agents；
DevOps Agents；
Monitoring Agents。

因此：

Agents are not equal accountability holders. They are autonomous execution capabilities directed and governed by humans.

Scrum Master

Scrum Master 对 Scrum Team 的有效性负责。

在 AI-Native Scrum 中，Scrum Master 帮助团队：

理解 AI-Native Scrum；
建立有效的 Human Cycle；
建立有效的 Agentic Cycle；
改进 Human–Agent Interaction；
提高 Transparency；
减少 Human Bottlenecks；
改进 Team Capability System。

Scrum Master 不负责管理 Agents。

Scrum Master 帮助团队改善：

人类判断、Agentic Execution 和团队能力系统之间的整体流动。

Team Capability System

传统团队的主要能力依赖：

Human Knowledge；
Human Skills；
Human Collaboration；
Human Judgment。

AI-Native Scrum 中，部分 Human Capability 被显式化、软件化和自动化。

Team Capability System 包括：

Human Capability；
Shared Context；
Skills；
Agents；
Evals；
Gates；
Hooks；
DevOps Toolchain；
LLMOps Toolchain。

这些能力共同支持团队创造价值。

Skills

Skills 是可复用能力的 Artifact。

Skills 可以编码：

Knowledge；
Procedures；
Standards；
Best Practices；
Domain Expertise；
Instructions。

Skills 将原本存在于 Human Experience 中的部分能力，转化为可被 Agent 使用和持续改进的 Capability。

Skills 应当：

Versioned；
Inspectable；
Reusable；
Adaptable。

Agents

Agents 是能够基于 Context 和 Capability 自主执行工作的能力。

Agents 可以：

Reason；
Plan；
Act；
Use Tools；
Produce Artifacts；
Evaluate Results。

Agents 不承担 Accountability。

Evals

Evals 用于判断：

Agent Output；
Product Behavior；
Capability Quality。

Evals 是 Agentic System 的经验主义机制。

它们提供 Evidence。

Gates

Gates 定义：

何时需要进一步的判断或批准。

Gates 可以是：

Human Gate；
Automated Gate；
Risk Gate；
Release Gate。

Hooks

Hooks 是可执行的控制机制。

Hooks 可以：

Trigger Actions；
Enforce Constraints；
Prevent Unsafe Actions；
Require Approval。

Hooks 将部分 Governance 从 Human Process 转化为：

Executable Control.

Toolchain

DevOps 和 LLMOps Toolchain 提供团队的执行基础设施。

包括：

Source Control；
CI/CD；
Deployment；
Observability；
Evaluation Pipeline；
Model Operations；
Runtime Controls。

Toolchain 不是 Scrum Artifact。

它是：

Team Capability Infrastructure。

Three Cycles of AI-Native Scrum

AI-Native Scrum 通过三个相互连接的 Cycle 运行：

Human Cycle
Agentic Cycle
Human–Agent Interaction Cycle

Human Cycle

Human Cycle 是经典 Scrum Cycle 的延续。

它提供：

Collective Human Judgment and Adaptation.

Human Cycle 通常以 Sprint 为节奏。

它包括：

Sprint Planning；
Sprint Review；
Sprint Retrospective。

Human Cycle 不负责管理 Agent 的每一步工作。

Human Cycle 负责：

Why；
Value；
Priority；
Trade-offs；
Risk；
Learning；
Adaptation。

Sprint 是：

A Human Learning and Judgment Cycle.

Sprint

Sprint 是 Human Cycle 的容器。

Sprint 提供规律的机会，使 Scrum Team：

共同确定方向；
检视结果；
从现实学习；
调整未来方向。

Agentic Execution 可以在 Sprint 中持续进行。

Sprint 不限制 Agent 的执行节奏。

Sprint 提供：

Human Cadence for Collective Inspection and Adaptation.

Sprint Planning

Sprint Planning 启动 Sprint。

整个 Scrum Team 共同明确：

为什么这个 Sprint 有价值；
Sprint Goal 是什么；
当前最重要的 Intent 是什么；
哪些风险和 Trade-offs 需要关注。

Developers 决定如何利用：

Humans；
Agents；
Skills；
Toolchains；

来实现 Sprint Goal。

Sprint Review

Sprint Review 的目的是检视现实。

Scrum Team 与 Stakeholders 共同检视：

Increment；
Evidence；
Product Outcomes；
User Feedback；
Business Signals。

Sprint Review 回答：

What have we learned from reality?

Sprint Retrospective

Sprint Retrospective 的目的是改进团队创造价值的能力。

团队检视：

Human Collaboration；
Context；
Skills；
Agents；
Evals；
Gates；
Toolchains。

Retrospective 不仅改进：

Product Development Process。

它还改进：

The Team Capability System.

Agentic Cycle

Agentic Cycle 是一个持续运行的执行循环。

它不依赖 Sprint Event。

Agentic Cycle 可以由：

Artifact Change；
Trigger；
Hook；
Exception；
Human Request

启动。

一个典型的 Agentic Cycle 是：

Context
   ↓
Interpret
   ↓
Plan
   ↓
Execute
   ↓
Evaluate
   ↓
Adapt
   ↓
Context / Capability Update

Agentic Cycle 的目标是：

Continuous Execution and Learning.

Agentic Cycle 的速度不由 Sprint Length 决定。

它可以运行：

Minutes；
Hours；
Continuously。

Human–Agent Interaction Cycle

Human–Agent Interaction Cycle 连接：

Human Judgment；
Agentic Execution。

Human-in-the-loop 不应该被理解为一个简单的 Workflow Step。

Human 并不是：

在每一个 Agent Action 后进行审批。

Human–Agent Interaction 是一个持续的意义构建过程。

典型循环包括：

Human Intent
      ↓
Agent Interpretation
      ↓
Agent Proposal
      ↓
Human Feedback
      ↓
Agent Adaptation
      ↓
Human Judgment

Human–Agent Interaction 可以通过：

Conversation；
Artifact Review；
Approval；
Exception；
Gate；
Pull Request；
IDE；
Dashboard；

发生。

它的目的不是控制所有 Agent 行为。

而是：

建立 Shared Understanding，并在需要判断时连接 Human Judgment 和 Agentic Execution。

Human-at-the-Gates

随着 Agentic Capability 增强，人类不应成为持续执行中的 Bottleneck。

因此：

Human Attention 应集中在最需要判断的地方。

Human Gates 可以用于：

Intent；
High-risk Decisions；
Architecture；
Exceptions；
Release；
Risk Acceptance。

不是：

Human-in-the-loop everywhere。

而是：

Human judgment where judgment matters.

AI-Native Scrum Artifacts

Artifacts 是工作、知识、意图、决策、证据或能力的持久化表达。

Artifacts 可以被：

Humans 创建；
Agents 创建；
Humans 检视；
Agents 检视；
持续更新；
Version Controlled；
Reused。

AI-Native Scrum 中，Artifacts 是 Human 与 Agents 之间工作的主要媒介。

Core Scrum Artifacts

AI-Native Scrum 保留三个核心 Scrum Artifacts：

Product Backlog；
Sprint Backlog；
Increment。

Product Backlog

Product Backlog 是为了实现 Product Goal 而需要的工作的涌现和有序集合。

AI-Native Scrum 中，Product Backlog 不一定由传统 User Story 或 Ticket 构成。

Product Backlog 可以由一组 Intent 及其相关 Artifacts 表达。

任何 Stakeholder 都可以与 AI 共同形成初始 Intent。

Intent 可以进一步演进为：

Intent
   ↓
Specification
   ↓
Plan
   ↓
Execution
   ↓
Evidence

Product Owner 保持对 Value 和 Priority 的 Accountability。

Sprint Backlog

Sprint Backlog 是 Developers 在当前 Sprint 中为实现 Sprint Goal 而选择和组织的工作范围。

AI-Native Scrum 中：

Sprint Backlog is the scope of an Artifact Graph.

Sprint Backlog 不默认是：

Jira Board；
Kanban Board；
Physical Board。

这些可以作为 Visualization。

但不应被视为唯一 Source of Truth。

Sprint Backlog 可以表现为一个动态的 Artifact Graph：

                Context
                   │
                   ▼
                intent.md
                   │
                   ▼
                 spec.md
                   │
             ┌─────┴─────┐
             ▼           ▼
          research     plan.md
             │           │
             └─────┬─────┘
                   ▼
                execution
                   │
           ┌───────┼───────┐
           ▼       ▼       ▼
         code    tests    infra
           │       │       │
           └───────┼───────┘
                   ▼
                 evals
                   │
                   ▼
                evidence

因此：

The Sprint Backlog is a living, versioned, agent-readable scope of artifacts.

Visual Board 可以存在。

但它是：

Visualization。

Artifact Graph 才是：

Source of Truth。

Increment

Increment 是朝着 Product Goal 前进的可用结果。

Increment 必须符合 Definition of Done。

Agent 产生的 Output 只有符合 Definition of Done 后，才能成为 Increment 的一部分。

Working and Capability Artifacts

除了 Core Scrum Artifacts，AI-Native Scrum 使用更多 Working Artifacts。

例如：

intent.md
spec.md
plan.md
progress.md
decision.md
context.md
eval.md
evidence.md
skill.md

这些 Artifacts 可以共同形成：

Artifact Graph。

Product Artifacts

Product Artifacts 描述：

我们正在创造什么。

包括：

Intent；
Specification；
Plan；
Increment；
Evidence。

Capability Artifacts

Capability Artifacts 描述：

我们如何创造。

包括：

Context；
Skills；
Agent Definitions；
Evals。

Capability Artifacts 是 Team Capability System 的组成部分。

它们也持续被：

Inspect；
Adapt；
Improve。

Artifact-Driven Work

AI-Native Scrum 中，工作主要通过 Artifacts 流动。

而不是依赖：

Transient Conversation；
Manual Status Update；
Human Memory；
Isolated Knowledge。

典型的 Artifact Flow：

Reality
   ↓
Intent
   ↓
Specification
   ↓
Plan
   ↓
Execution
   ↓
Increment
   ↓
Evidence
   ↓
Learning
   ↓
Context / Capability Update

因此：

Artifacts are the primary medium through which work and context flow between humans and agents.

Continuous Intent Refinement

AI-Native Scrum 不要求提前多个 Sprint 准备大量详细 Backlog。

AI 可以帮助任何 Stakeholder：

Clarify Problems；
Identify Constraints；
Generate Intent；
Explore Alternatives。

因此 Refinement 更适合作为：

A continuous Intent Refinement System。

而不是必须提前安排的会议。

一个 Intent 可以从：

Stakeholder
     ↓
Conversation with AI
     ↓
intent.md
     ↓
Human Judgment
     ↓
Artifact Graph

逐步成熟。

Product Owner 决定：

是否值得进一步投入团队能力。

Commitments

AI-Native Scrum 保持：

Product Goal；
Sprint Goal；
Definition of Done。

Product Goal

Product Goal 描述 Scrum Team 希望实现的未来产品状态。

它提供长期方向。

Sprint Goal

Sprint Goal 描述当前 Sprint 的共同目标。

它帮助团队在复杂环境中保持 Focus。

Sprint Goal 不要求固定的工作路径。

Developers 可以调整：

Artifact Graph；
Plan；
Agent Allocation；
Execution Method。

只要 Sprint Goal 保持有效。

Definition of Done

Definition of Done 描述 Increment 达到可用状态所需要满足的质量标准。

在 AI-Native Scrum 中，Definition of Done 可以由：

Human Judgment；
Automated Tests；
Evals；
Hooks；
Gates；

共同支持。

部分过去依赖人工协作完成的质量能力，可以被转化为：

Executable Quality Controls。

例如：

Definition of Done
        │
        ├── Automated Tests
        ├── Evals
        ├── Security Checks
        ├── Hooks
        └── Required Human Gates

Definition of Done 不因为 AI 能够快速产生 Output 而降低标准。

The AI-Native Scrum System

AI-Native Scrum 可以概括为：

╔══════════════════════════════════════╗
║            HUMAN CYCLE               ║
║                                      ║
║  PLAN → REVIEW → RETROSPECTIVE       ║
║       Human Judgment & Learning      ║
╚══════════════════╤═══════════════════╝
                   │
                   │
        ┌──────────▼──────────┐
        │ HUMAN–AGENT         │
        │ INTERACTION         │
        │                     │
        │ Intent              │
        │ Proposal            │
        │ Feedback            │
        │ Judgment            │
        │ Gates               │
        └──────────┬──────────┘
                   │
                   ▼
╔══════════════════════════════════════╗
║           AGENTIC CYCLE              ║
║                                      ║
║ Context → Plan → Execute → Eval      ║
║              → Adapt                 ║
║                                      ║
║ Continuous Agentic Execution         ║
╚══════════════════╤═══════════════════╝
                   │
                   ▼
        ┌─────────────────────┐
        │ TEAM CAPABILITY     │
        │ SYSTEM              │
        │                     │
        │ Humans              │
        │ Shared Context      │
        │ Skills              │
        │ Agents              │
        │ Evals               │
        │ Gates / Hooks       │
        │ DevOps              │
        │ LLMOps              │
        └─────────────────────┘

End Note

AI-Native Scrum 不试图将人工智能加入传统 Scrum。

它重新理解：

在人工智能成为生产能力之后，一个 Team 是什么。

过去：

Team Capability 主要存在于 Humans。

现在：

Team Capability 可以存在于 Humans、Context、Skills、Agents、Evals 和 Toolchains。

因此：

The Team becomes a human-led capability system.

过去，Scrum 主要协调：

Human Collaboration。

AI-Native Scrum 同时协调：

Human Judgment、Human–Agent Interaction 和 Agentic Execution。

过去，Sprint Backlog 主要承载：

Human Work。

AI-Native Scrum 中：

Sprint Backlog defines the current scope of an evolving Artifact Graph.

过去，人的经验主要存在于人的头脑和团队协作之中。

AI-Native Scrum 将越来越多的能力：

显式化、Artifact 化、Skill 化和可执行化。

但是，无论 Agentic Capability 如何发展：

Human remains accountable for the value created.

AI-Native Scrum 的目的不是：

Replacing humans with agents.

而是：

Enabling fewer humans to responsibly direct increasingly powerful systems of agentic capability.

这就是 AI-Native Scrum。

Human Accountability.
Collective Context.
Artifact-Driven Work.
Agentic Execution.
Continuous Learning.

大多数企业的数字化转型，从一开始就做错了|优普丰助力企业数字化/敏捷转型

admin — Sun, 30 Aug 2026 09:59:37 +0000

经常和各行各业的企业创始人、高管交流，我听过最多的一句话就是：“我们公司数字化做完了，系统全都上线了，但业务一点起色都没有。”

这几乎是所有企业转型的通病：花钱、上系统、搞项目、做汇报，流程走得滴水不漏，看起来轰轰烈烈，落地之后却彻底沉寂。

很多企业陷入了一个致命误区：把“买工具、上系统”当成了数字化转型。

真正的数字化，从来不是一场技术采购，而是一场深刻的组织进化。工具可以花钱买到，但能适配数字时代的团队能力、业务模式、决策思维，只能靠企业自己打磨生长。

今天我跳出枯燥的理论框架，结合多年企业辅导的实战经验，拆解清楚：什么是真数字化、什么是伪转型、为什么绝大多数企业越转越累，以及普通企业可直接落地的转型路径。

一、先避坑：认清4种最常见的“伪数字化转型”

很多企业转型失败，根源不是执行力不够，而是从定义上就彻底跑偏了。如果你还在把以下这4件事当成数字化转型，做得再多也是无用功。

1. 把系统上线，等同于转型成功

上线ERP、CRM、各类办公系统，只是单纯的工具采购，和数字化转型毫无关系。就像买了一堆高端厨具，不代表能做好一桌好菜。工具摆在那里没人用、用不好、和业务脱节，最后只会沦为摆设，白白消耗企业成本。

2. 把渠道升级，等同于模式升级

搭建官网、开发小程序、上线APP，只是多了一个触达用户的渠道，只是表层的形式更新。没有重构服务逻辑、没有优化用户体验、没有迭代业务流程，再多的线上渠道，也只是空有外壳，无法带来真正的业务增长。

3. 把IT项目，当成企业转型

不少公司的数字化，全权交给IT部门负责，业务部门全程旁观、被动配合。但数字化的核心是业务变革，不是技术升级。技术只能实现功能，只有业务才能创造价值。IT自嗨式建设、业务落地脱节，是转型最常见的翻车原因。

4. 把一次性项目，当成长期进化

很多企业抱着“一劳永逸”的心态做转型：定一套完整方案、做完一次落地、验收一次项目，就觉得万事大吉。但数字时代的市场、用户、竞品永远在变，静态的完美规划，根本扛不住动态的市场变化。用工业时代的静态思维，做数字时代的动态转型，注定只会被时代淘汰。

二、读懂本质：真正的数字化，到底转的是什么？

拨开所有概念和噱头，数字化转型的核心本质只有一句话：用数字技术重构价值创造的方式，完成企业组织能力的迭代升级。

它的核心从来不是技术，而是思维、流程、组织的全方位变革。

技术只是手段，业务价值才是目的；

工具只是载体，模式升级才是核心；

项目只是起点，持续进化才是终点。

这里分享一个简单好用的自检标准，帮你快速区分真假转型：

如果你的关注点只有「系统有没有上线、项目有没有做完」，这是项目思维，伪转型；

如果你的关注点是「效率有没有提升、体验有没有优化、有没有新的增长机会」，这是价值思维，真转型。

数字化从来不是为了“看起来先进”，而是为了“跑得更快、活得更好、长得更强”。

三、深度拆解：绝大多数企业转型失败的3个核心根源

见过无数企业的转型案例，抛开表面的资金、团队问题，所有失败的底层逻辑，都逃不开三个核心错位。

1. 战略悬空：高层画蓝图，基层原地踏步

很多企业的数字化，只停留在高层的会议和PPT里。管理层喊着转型口号，却没有把宏大战略拆解为可落地、可执行、可验证的具体动作；中层看不懂方向、接不住任务；基层依旧沿用旧流程、旧思维工作。

没有落地路径的战略，终究只是空谈。转型不是一场宣讲，而是日复一日的价值交付，只有层层落地、逐步推进，才能真正见效。

2. 业务和技术两张皮：技术自嗨，业务无用

这是企业转型最普遍的内耗。IT团队专注技术迭代，追求功能完善、系统先进，却从不深入一线了解业务痛点；业务团队深陷日常工作，觉得数字化是额外负担，消极应付、不愿配合。

最终打造出来的数字化系统，看似功能齐全、十分专业，却解决不了任何实际业务问题，反而增加员工的操作成本，最后被全员闲置，彻底沦为摆设。

3. 规划僵化：用静态方案，应对动态市场

传统企业习惯做长线、全量、完美化的规划，试图一次性把所有问题解决。但当下的市场最大的特点就是不确定性：用户需求随时迭代、行业规则持续更新、竞品打法不断升级。

我曾辅导过一家制造企业，耗费大量时间和成本打造标准化智能工厂，落地完成后才发现，市场早已从大批量标准化生产，转向小批量定制化需求。一套完美的静态方案，彻底跟不上动态的市场变化，所有投入全部付诸东流。

在不确定的时代，完美的规划，远不如灵活的迭代靠谱。

四、转型核心：数字化的终极目标，是打造业务敏捷能力

很多企业本末倒置，一味深耕技术、搭建系统，却忽略了数字化的终极目标：通过数字化，让业务更敏捷、组织更灵活、增长更可持续。真正的转型，核心是三件事。

1. 重构客户价值：从“我有什么”到“用户要什么”

传统企业的经营逻辑是供给驱动：企业有什么产品、什么服务，就卖给用户什么。数字化转型，要求企业彻底切换为需求驱动。

依托数据洞察用户真实痛点，挖掘未被满足的潜在需求，通过数字化手段优化全流程客户体验，跳出同质化竞争，创造独属于自己的用户价值，这才是数字化的核心意义。

2. 再造业务流程：从“线上搬家”到“流程重构”

很多企业的流程数字化，只是把线下填表、审批、流转的工作，简单搬到线上，看似高效，实则冗余繁琐的问题依然存在。

真正的流程再造，是彻底打破旧有桎梏：砍掉无价值的审批环节、自动化重复机械的基础工作、打通各部门的流程壁垒，从“以部门为中心”转为“以价值流为中心”，让业务流转更顺畅、资源利用更高效、整体内耗更低。

3. 进化组织能力：从“经验决策”到“数据驱动”

技术可以采购、系统可以复制，但敏捷的组织能力，是企业独一无二的核心壁垒。

数字化转型，本质是组织思维的升级：告别老板拍脑袋、经验做决策的传统模式，用数据支撑判断；打破部门墙，建立跨部门协同机制；培养快速试错、持续优化的团队文化，让整个组织能够快速响应市场变化。

五、为什么做数字化，一定要结合敏捷思维？

很多人疑惑：数字化转型，为什么离不开敏捷？因为二者底层逻辑完全契合，是天然的共生关系。

1. 同样拒绝无效自嗨，坚持价值优先

数字化以客户价值为核心，敏捷以业务价值为导向。二者都摒弃“为了做而做”的形式主义，所有迭代、所有优化、所有投入，都只为落地真实价值，拒绝无用功能、无效投入。

2. 同样拥抱变化，拒绝僵化固守

市场永远在变，没有一成不变的转型方案。敏捷的短迭代、快试错模式，刚好适配数字化的不确定性，把宏大的转型目标拆解为小周期可落地、可验证的任务，有效规避一次性投入的巨大风险。

3. 同样强调协同，打破组织内耗

数字化转型需要全员联动，绝非单一部门的工作。敏捷的跨职能团队模式，能够打通业务、技术、运营的壁垒，让各岗位协同作战、目标统一，共同对转型结果负责，彻底解决“两张皮”问题。

4. 同样坚持持续进化，拒绝一劳永逸

数字化没有终点，只有连续不断的新起点。敏捷的持续复盘、迭代优化机制，能够让企业在转型过程中不断修正方向、补齐短板，让组织能力持续进化，适配市场长期变化。

六、落地指南：企业通用的四步数字化转型框架

数字化不用追求大而全，盲目全面铺开只会漏洞百出。这套轻量化落地框架，适配大中小各类企业，小步快跑、稳步见效。

第一步：价值发现，单点突破

摒弃全面转型的执念，优先梳理业务核心痛点，筛选出投入低、见效快、价值高的转型切入点。通过业务流程梳理、价值流分析，明确转型目标和价值标准，先做单点试点，不盲目铺大盘。

第二步：能力搭建，夯实基础

组建跨职能专项团队，整合业务、技术、运营核心人员，打破部门壁垒。导入敏捷工作方法和数字化工具，搭建基础的数据决策体系，培养团队数字化、敏捷化的工作思维，筑牢转型根基。

第三步：迭代落地，持续验证

以短周期迭代推进落地，每一轮迭代都聚焦具体业务问题，落地后及时验证价值、收集反馈。根据市场和业务变化灵活调整方案，不纠结完美方案，只求持续优化、逐步见效。

第四步：复制推广，全面进化

沉淀试点过程中的成功经验、落地方法和避坑逻辑，形成可复制的标准化模式。逐步推广到全业务线，同步搭建转型文化和治理体系，让数字化从项目工作，变成企业常态化的进化能力。

七、转型成功的5个核心关键，缺一不可

纵观各类企业的转型结果，能真正跑通数字化、拿到结果的企业，无一例外都做到了这五点。

1. 一把手深度认知，亲自推动

数字化是顶层变革，绝非中层或基层能够推动。企业负责人必须真正理解转型本质，亲自参与规划、协调资源、破除阻力，而非简单授权、甩手不管。高层的认知高度，直接决定转型的最终成效。

2. 从价值切入，用小成功建立信心

优先从业务痛点最突出、价值最直观的环节落地，用看得见的效率提升、体验优化、成本降低，让团队真切感受到转型的价值，打消抵触心理，积累转型信心。

3. 业务技术深度融合，协同共生

业务主导方向，技术负责落地，二者深度绑定、共同复盘、共同优化。彻底杜绝技术自嗨、业务旁观的问题，让每一次技术迭代，都精准服务于业务增长。

4. 建立数据驱动的决策文化

把数据贯穿业务全流程，用数据发现问题、验证效果、制定决策。逐步替代经验主义、拍脑袋决策的模式，让企业经营更科学、更精准、更可控。

5. 包容试错，坚持长期迭代

数字化没有完美路径，过程中必然会有试错和调整。企业要摒弃急于求成的心态，包容不完美，坚持持续复盘、持续优化，在迭代中不断完善转型体系。

八、即刻落地：普通人也能启动的3个转型动作

不用等待完备方案，企业想要启动数字化转型，从当下就能落地三个核心动作。

1. 召开全员共识会

拉通高层、中层、一线骨干，统一对数字化转型的认知，厘清误区、明确目标、对齐方向，解决“大家各有理解、各做各事”的内耗问题。

2. 锁定一个核心痛点

从效率低下、客户投诉多、成本浪费严重的核心业务环节中，锁定一个痛点作为首个转型切入点，聚焦发力、单点突破。

3. 组建专项落地小组

抽调业务、技术核心人员组成专项团队，明确目标、职责和落地周期，快速推进试点工作，尽快拿到首个转型成果。

结语

最后再重申一遍：数字化转型，从来不是买系统、做项目，而是一场企业组织的全面进化。

它淘汰的不是老旧工具，而是老旧的思维、僵化的流程、割裂的组织。在日新月异的数字时代，技术永远可以迭代，但能够快速适应变化、持续创造价值的敏捷组织能力，才是企业真正的核心竞争力。

转型没有捷径，但找对方向、用对方法，就能少走弯路、少花冤枉钱，让数字化真正成为企业增长的助推器，而非流于表面的面子工程。

如果你在企业数字化、敏捷转型的过程中，遇到认知困惑、落地卡点、团队协同难题，欢迎在评论区留言交流。

别被忽悠了！大多数企业，根本不懂什么是真正的数字化转型

admin — Sun, 30 Aug 2026 09:57:38 +0000

上周，一位CEO兴奋地告诉我：“我们数字化转型成功了！花大价钱上了全套的管理系统和客户管理工具。”我平静地问：“然后呢？业务有什么变化？客户体验变好了吗？”他瞬间愣住了，支支吾吾说不出话来。

这个场景，我在从业多年里见过太多次，太多企业把“技术采购”当成了“数字化转型”，盲目跟风砸钱买系统、上工具，以为只要搞定了技术，就完成了转型。可到最后，钱花了不少，系统成了摆设，业务毫无起色，员工怨声载道，转型彻底沦为“面子工程”。

其实，绝大多数企业对数字化转型都存在根本性的误解，把手段当成了目的，把工具当成了核心。今天，我就从敏捷教练的视角，帮你拨开迷雾，揭开数字化转型的真正面目，避开那些让你白花钱、走弯路的坑。

一、本质澄清：先搞懂，数字化转型不是什么，是什么？

想要做好数字化转型，第一步必须破除那些根深蒂固的迷思，先分清“伪转型”和“真转型”的边界，否则从一开始就会跑偏。

数字化转型，绝对不是这些事

❌ 不是买一套ERP、CRM或各类SaaS系统。这只是单纯的技术采购，就像买了一台先进的机器，不懂得怎么用、用在什么地方，它永远只是一个摆设，带不来任何业务价值；

❌ 不是建一个App或网站。这只是渠道建设，顶多是多了一个触达客户的途径，和“转型”无关，很多企业建了App，下载量寥寥，反而浪费了大量人力物力；

❌ 不是让IT部门主导一个项目。这只是技术升级，把线下的工作搬到线上，没有改变业务逻辑，没有优化组织模式，本质上还是换汤不换药；

❌ 不是一次性就能完成的工程。这是典型的瀑布思维，以为制定一个完美的规划，按部就班执行，就能一劳永逸。可数字时代变化太快，等你按规划完成，市场早就变了。

数字化转型的本质，到底是什么？

核心一句话：利用数字技术，重塑企业的价值创造方式，实现组织能力的根本性进化。

它从来不是关于“技术”，而是关于“业务”。技术只是工具，最终目的是解决业务痛点、提升业务效率、创造业务价值；

它从来不是关于“工具”，而是关于“模式”。不是简单地用数字工具替代人工，而是重构业务模式、盈利模式，找到新的增长路径；

它从来不是关于“项目”，而是关于“能力”。不是做完一个项目就结束，而是打造企业应对变化、持续创新的核心能力。

这里有一个最简单的判断标准，帮你快速自检：

如果你开口就问“系统上线了吗”“项目完成了吗”，那你还是停留在“项目思维”，做的只是伪转型；
如果你开口问“业务效率提升了吗”“客户体验改善了吗”“新的收入模式出现了吗”，那你才真正理解了转型的本质，走在正确的路上。

二、为什么大多数转型都失败了？敏捷视角的深度剖析

见过太多企业，雄心勃勃地启动数字化转型，最后却不了了之，要么不了了之，要么半途而废，要么投入巨大却颗粒无收。结合我辅导过的众多企业案例，发现这些失败的背后，都藏着三个根本错位，也是最容易被忽视的坑。

错位一：战略与执行脱节，口号喊得响，落地没方向

最典型的表现就是：高层在会议上高喊“数字化转型”的口号，描绘了宏伟的蓝图，可中层管理者一头雾水，不知道该怎么落地，基层员工更是照旧按老路子工作，转型只是停留在PPT上、会议里，从来没有真正渗透到日常工作中。

根源问题在于，企业缺乏将战略转化为可执行行动的机制，把“转型”当成了一句口号，而不是需要一步步落地的具体动作。

从敏捷视角来看，真正的转型战略，从来不是靠一次宣讲、一份规划就能落地的，必须通过持续的价值交付，把宏大目标拆解成一个个可落地、可验证的小目标，一步步推进，才能让战略真正落地生根。

错位二：技术与业务割裂，IT自嗨，业务脱节

很多企业的转型，都是由IT部门主导，业务部门被动配合。IT部门埋头研究技术、搭建系统，却从来不去了解业务部门的真实需求，不知道一线员工每天面临的痛点是什么；业务部门则觉得“转型是IT的事”，消极应付，不主动参与。

最后的结果就是，IT部门辛辛苦苦搭建的系统，和业务需求严重脱节，员工用起来不方便，甚至还要额外增加工作量，最后只能弃之不用，形成“系统与业务两张皮”的尴尬局面。

敏捷视角下，转型从来不是技术部门单方面的事，必须是业务与技术深度融合的过程。技术要服务于业务，业务要引导技术，两者协同发力，才能避免“自嗨式转型”。

错位三：规划与执行断裂，用旧思维应对新变化

很多企业做转型，还是沿用工业时代的“预测式思维”，花大量时间制定完美的规划，试图把所有细节都考虑到，然后按部就班执行。可数字时代的核心特征就是“不确定性”，市场在变、用户需求在变、竞争对手在变，等你按规划完成系统上线，当初的需求可能早就过时了，用户也根本不买账。

我曾辅导过一家制造业企业，他们耗时许久、投入巨资打造了“智能工厂”，一心想实现大规模标准化生产，结果系统上线后才发现，市场需求已经转向了小批量定制，他们的系统根本无法适配，之前的所有投入，都打了水漂。这就是预测式规划的典型悲剧，用静止的思维，应对动态的市场。

敏捷视角下，转型必须是迭代演进、持续验证的过程，不是一次性的工程。与其追求完美规划，不如小步快跑，快速试错，根据市场反馈及时调整方向，才能跟上变化的节奏。

三、数字化转型的核心：从“技术系统”到“业务敏捷”

很多企业之所以转型失败，核心是搞错了重点，把精力都放在了技术架构、系统搭建上，却忽略了最核心的东西：组织能力的重塑。

真正的数字化转型，核心不是技术，而是组织能力的根本性进化。基于多年的实战经验，我认为数字化转型的三大核心，缺一不可，其中组织能力是最关键的一环。

核心一：客户价值的数字化重构，以客户为中心，而非以产品为中心

传统企业的思维是“我们有什么能力，就卖给客户什么产品”，而数字化转型，需要彻底扭转这种思维，变成“客户需要什么价值，我们就创造什么价值”。

通过数据洞察，找到用户未被满足的需求，发现客户旅程中的痛点；用数字化手段，创造全新的客户体验，让客户更便捷、更高效地获得价值。

这里有两个关键问题，值得每一位企业负责人深思：你的客户旅程中，有哪些环节可以通过数字化优化，提升客户体验？你能为客户创造哪些前所未有的价值，形成自己的核心竞争力？

核心二：业务流程的数字化再造，不是“搬家”，而是“重构”

很多企业的数字化，只是简单地把线下流程搬到线上，以为这样就是转型了。但实际上，这只是“换了个地方干活”，没有消除冗余环节，没有优化工作效率，反而可能因为操作繁琐，增加员工的工作量。

真正的业务流程数字化，是“重新设计数字时代的业务流程”——消除那些不创造价值的冗余环节，自动化那些重复、繁琐的工作，让员工从机械劳动中解放出来，专注于更有价值的事情；同时，打破“部门为中心”的思维，转向“价值流为中心”，让业务流程更顺畅、更高效。

关键问题：你的核心业务价值流是什么？数字化如何让这些价值流流动得更快、质量更高，减少内耗？

核心三：组织能力的数字化进化，打造敏捷的“组织肌肉”

这是最核心、最难复制的竞争优势。技术可以买，系统可以建，但敏捷的组织能力，只能靠企业自己慢慢生长。

所谓组织能力的数字化进化，就是建立基于数据的决策机制，告别“老板拍脑袋”“凭经验做事”；培养快速实验、持续学习的文化，让员工敢于试错、乐于创新；构建跨职能协作的组织结构，打破部门墙，让团队能够快速响应市场变化。

关键问题：你的团队能否快速响应市场变化，不被旧思维束缚？你的组织是否有能力持续学习、持续改进，跟上数字时代的节奏？

四、敏捷与数字化：天然的孪生兄弟，缺一不可

很多企业问我：“做数字化转型，为什么一定要用敏捷？”答案很简单：敏捷和数字化，有着完全相同的基因，是天生的孪生兄弟，只有深度融合，转型才能成功。

1. 价值驱动 vs 技术驱动。两者都聚焦“有用”，而非“有技术”

数字化转型的核心要求是“以客户为中心”，一切动作都要围绕客户价值展开；敏捷的核心原则是“价值优先”，拒绝做无用功。两者的结合点的是：每个迭代都必须交付可衡量的业务价值，不搞“自嗨式开发”，不做“无用的功能”。

2. 迭代演进 vs 一次性工程。两者都拥抱变化，拒绝僵化

数字化转型面对的是充满不确定性的市场，没有固定的路径可循；敏捷通过短周期迭代，快速试错、快速调整，恰好能应对这种不确定性。两者的结合点是：将宏大的转型目标，拆解成一个个可快速验证的小目标，小步快跑，逐步推进，避免一次性投入过大、风险过高。

3. 跨职能协作 vs 部门割裂。两者都强调“协同”，拒绝内耗

数字化转型需要业务、技术、运营等多个部门深度融合，缺一不可；敏捷通过组建跨职能团队，实现端到端交付，打破部门墙，避免推诿扯皮。两者的结合点是：组建包含业务、技术、运营等角色的转型突击队，让大家目标一致、协同作战，共同对转型结果负责。

4. 持续改进 vs 静态目标。两者都追求“进化”，拒绝停滞

数字化转型不是一次性的，而是一场持续的组织进化；敏捷通过迭代回顾会，持续反思、持续优化，不断提升团队能力。两者的结合点是：建立转型过程的定期检视和调整机制，及时发现问题、解决问题，让转型之路越走越顺。

我辅导过的很多企业，正是因为将敏捷与数字化深度融合，摆脱了“伪转型”的困境，真正实现了业务的提升和组织的进化。

五、数字化转型的四步实战框架，不用复杂，直接落地

结合多年辅导企业转型的成功经验，我总结出一套简单易落地的四步实战框架，不管是中小企业，还是中大型企业，都能直接套用，避开弯路、少花冤枉钱。

第一步：价值发现，找准切入点，不盲目铺开

转型不是“全面开花”，而是“单点突破”。先识别1-2个高价值的数字化切入点，不用追求“大而全”，重点找那些痛点最突出、最能快速产生业务价值的环节。

通过价值流分析，梳理核心业务流程，找到其中的瓶颈和痛点；明确转型的初步价值假设和成功标准，知道“我们要达到什么效果”，再制定清晰的转型路线图和第一个小目标。

第二步：能力建设，搭建团队，夯实基础

转型的核心是人，没有合适的团队，再好的规划也无法落地。组建第一个跨职能转型团队，成员要包含业务、技术、运营等多个角色，确保团队能覆盖转型的全流程。

导入敏捷实践和数字化工具，让团队掌握转型所需的方法和工具；建立数据驱动的决策机制，让团队养成“用数据说话”的习惯，夯实转型的基础能力。

第三步：迭代突破，小步快跑，持续验证

通过短周期迭代，交付数字化成果，不用追求“一步到位”，每个迭代都聚焦一个小目标，完成后及时验证价值假设——看看这个成果是否解决了痛点、是否创造了价值。

根据验证结果，及时调整方向，持续优化，把小的成功积累起来，慢慢建立团队的信心，也让转型成果逐步显现。

第四步：规模化推广，复制经验，全面进化

当第一个试点团队取得成功，形成可复制的经验后，再将这些经验推广到更多业务领域，扩大转型的覆盖面。

建立转型文化的传播机制，让更多员工理解转型、认同转型、参与转型；完善数字化治理体系，确保转型能够持续推进，最终打造出持续进化的组织能力。

六、企业数字化转型的五个关键成功要素，缺一不可

很多企业转型失败，不是因为方法不对，而是忽略了一些关键要素。结合实战经验，这五个要素，是转型成功的核心保障，缺一不可。

1. 一把手的认知升级，转型的核心推动力

数字化转型不是“IT部门的事”，而是“一把手工程”。一把手不能只授权给技术负责人就万事大吉，而是要亲自参与转型设计，理解数字化转型的本质，明确转型的方向和目标，不做“甩手掌柜”。只有一把手重视，才能打破部门墙，协调各类资源，推动转型落地。

2. 以价值为纲的切入点选择，用小成功积累大信心

转型不能急于求成，要从最能产生业务价值的环节开始，比如解决客户投诉最多的痛点、优化效率最低的流程。用早期的小成功，建立团队和企业的转型信心，让大家看到转型的价值，才能更好地推动后续的转型工作。

3. 业务与技术深度融合，拒绝“两张皮”

打破部门墙，组建跨职能团队，让业务人员和技术人员并肩作战，共同参与需求分析、方案设计、落地执行的全过程。业务人员提供需求和方向，技术人员提供实现方法，两者协同发力，才能避免系统与业务脱节，让转型真正服务于业务。

4. 数据驱动的决策文化，告别“拍脑袋”

建立数据采集、分析、应用的闭环，让数据贯穿转型的全过程。无论是需求判断、方案设计，还是效果验证，都要用数据说话，而非凭经验拍板。培养团队“用数据决策”的习惯，让转型更科学、更高效。

5. 持续学习与迭代改进，接受不完美，拥抱变化

数字化转型没有标准答案，也没有完美的路径，必然会遇到挫折和失败。要接受“小步快跑、快速试错”的转型节奏，不追求“一步到位”，从失败中快速学习，持续调整方向和方法，让转型在迭代中不断完善、不断进化。

七、立即行动：明天就可以开始的三个动作

很多企业负责人总说“转型太难，不知道从哪里开始”，其实转型不用等“完美方案”，从明天开始，这三个小动作，就能让你迈出转型的第一步，快速启动转型之路。

1. 组织一次转型共识会

召集核心团队，包括高层、中层和一线骨干，一起讨论“我们理解的数字化转型是什么”，澄清大家的认知差异，明确转型的核心目标，让所有人都达成共识，避免“各自为战”。

2. 选择一个痛点开始

不用追求“全面转型”，找出当前业务中最痛的一个环节，可能是客户投诉多、可能是流程效率低、可能是成本居高不下，思考“数字化能否优化这个环节”，把这个环节作为转型的第一个切入点。

3. 组建一个转型小组

从业务部门和技术部门各抽调1-2名核心骨干，成立临时转型突击队，明确小组的目标和职责，让他们专门负责第一个切入点的转型落地，快速拿到第一个小成果。

结语：数字化转型，是一场组织进化，而非技术采购

回到开篇的问题：什么才是真正的数字化转型？

它不是一个项目、一套系统、一次投入，而是一场组织能力的根本性进化；它不是让企业变得更“技术”，而是让企业变得更“敏捷”、更“高效”、更“懂客户”。

它要求企业从工业时代的“稳定可控”模式，进化为数字时代的“敏捷适应”模式——不再害怕变化，而是主动拥抱变化；不再依赖经验，而是依赖数据；不再各自为战，而是协同作战。

在陪伴企业转型的这些年里，我看到一个清晰的规律：那些把转型当作技术项目的企业，最终都失败了；那些把转型当作组织进化的企业，最终都成功了。

数字时代，最大的不变就是变化本身。真正的数字化转型，不是让你拥有多少先进的技术和系统，而是让你拥有应对变化、持续创新的组织能力。而敏捷，正是帮你打造这种能力的最佳路径。

如果你在数字化转型中，遇到了认知困惑、落地难题、团队协同等具体问题，欢迎在评论区留言，我们一起探讨解决方案～

开源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倍。