每一次效率革命，都先经历一段比以前更慢的时期
背景
最近在推一件事：让 AI Agent 接管整个研发链路。所谓 AI Agent，就是给 AI 配上工具调用能力，让它能主动操作系统、读写文件、调接口------不只是回答问题，而是真的去干活。产品写需求、设计出 Figma、前后端写代码、测试出报告，每个角色都配一个 AI Agent，跑完整个流程。
听起来很爽，实际干起来，有点不对劲------效率反而变低了。
Agent 写代码的时候忘了去读接口文档，设计 Agent 改完稿子忘了通知前端，测试 Agent 截图文件太大直接把 AI 的记忆撑爆......一堆小问题叠在一起，有时候人工确认的时间比直接写代码还长。
这让我想到一件事，这种感觉我好像在哪里经历过。
2013～2015 年，前后端分离也是这样开始的
其实前后端分离的念头在 2010 年前后就有了。移动端爆发、SPA 需求增加、REST API 开始普及，大家慢慢意识到前端不该再是后端模板的附属品，应该独立出来。
但真正让这件事规模化落地的，是工具跟上来了------2013 年 React 发布，2014 年 Vue 和 Spring Boot 相继出来，前后端各自有了成熟的开发框架，分离才真正变成行业共识。
于是开始拆。拆完发现，麻烦事反而变多了：
- 接口文档靠口头约定，联调一次吵一次
- 前端本地跑不起来，需要连后端环境
- 部署两套工程，运维头大
- CORS 问题从来没配对过
- 没有 Swagger 之前，接口变了没人知道
从 2013 到大概 2018 年，这段时间前后端分离的链路是混乱的。每个团队自己摸索一套，效率可能比以前的 JSP 时代还低。
但大家没有放弃，而是开始逐模块提效，一个卡点一个卡点地拔掉：
前后端分离
混沌期"] --> B["接口靠口头约定
联调靠吵架"] A --> C["本地环境跑不起来
必须连后端"] A --> D["部署两套工程
运维头大"] B --> B1["Swagger / Apifox
接口契约化"] C --> C1["Webpack dev-server
本地 Mock Server"] D --> D1["CI/CD
自动化部署"] B1 --> E["2018~2022
工程化成熟期"] C1 --> E D1 --> E E --> F["2023
效率天花板
1人/天 = 2014年1周"] F --> G["ChatGPT 出现
下一个 10 倍机会"] style A fill:#f9e4e4,stroke:#e88 style E fill:#e4f4e4,stroke:#8c8 style F fill:#e4f4e4,stroke:#8c8 style G fill:#fff3cd,stroke:#f0a
一个模块一个模块地打通，到了 2022、2023 年，前后端分离的效率已经到了一个新的天花板------一个熟练的前端工程师配上完善的脚手架，一天能干的事情比 2014 年一个礼拜还多。
然后 ChatGPT 出来了，大家一下子意识到，下一个 10 倍增长的机会来了。
AI 全链路的现状：我们现在在 2014 年
现在 AI 全链路的状态，和 2014 年的前后端分离太像了。
技术上没问题，能力都有了：AI 能写代码、能读设计稿、能分析测试日志、能拆解需求。
但链路没打通，模块没提效，协作方式没建立。
先看整条链路的数据流长什么样：
口述需求"] UI_D["UI 设计师
Figma 出稿"] end subgraph CONTRACT["契约层（基础设施）"] REQ["需求契约
结构化需求单 TAPD"] DESIGN["设计契约
Design Token + 命名规范"] API["接口契约
Apifox Contract"] MEM["规则契约
项目上下文 + 编码规范"] end subgraph AGENT["Agent 执行层"] AGT_PM["产品 Agent
需求拆解 + Wiki"] AGT_UI["设计 Agent
读 Figma 节点"] AGT_FE["前端 Agent
读 Contract 写代码"] AGT_BE["后端 Agent
写 Contract + 写代码"] AGT_QA["测试 Agent
从 PRD 出发写用例"] end subgraph OUTPUT["产出层"] WIKI["技术方案 Wiki"] CODE_FE["前端代码 MR"] CODE_BE["后端代码 MR"] REPORT["测试报告"] end PM -->|"结构化输入"| REQ UI_D -->|"规范出稿"| DESIGN REQ --> AGT_PM DESIGN --> AGT_UI API --> AGT_FE API --> AGT_QA MEM --> AGT_FE MEM --> AGT_BE AGT_PM --> WIKI AGT_PM -->|"广播通知"| AGT_UI AGT_PM -->|"广播通知"| AGT_BE AGT_UI -->|"节点数据"| AGT_FE AGT_BE -->|"写入"| API API -->|"读取"| AGT_FE AGT_FE --> CODE_FE AGT_BE --> CODE_BE AGT_QA --> REPORT style INPUT fill:#e8f4fd,stroke:#5b9bd5 style CONTRACT fill:#fff3cd,stroke:#f0ad4e style AGENT fill:#e8f6e8,stroke:#5cb85c style OUTPUT fill:#fde8e8,stroke:#d9534f
契约层是整条链路的关键------Agent 执行得再快，如果没有契约层兜底，上下游之间的信息就会断，断一次就要人工介入修一次。
但还有一个更深的问题，各个模块的痛点都还没触及它：需求变更。
变更是项目流转中永远不变的主题。前后端分离时代，需求改了，会有一个人感知到，然后一个个通知：接口要改、前端要改、测试用例要更新。流程低效，但信息是靠人扛着传递的，扛到了就没事，扛不到就出bug。
AI 全链路的问题是，链路越自动化，变更的破坏半径越大、越隐蔽。
需求改了一行，但下游的五个 Agent 已经按旧需求跑完了------代码写好了、测试用例生成了、MR 提了。这时候没有任何一个 Agent 知道自己的产出物已经过期。没有人拍桌子说"需求变了"，只有一堆静静等着被合并的错误产物。
前后端分离并没有真正解决变更问题，它只是把变更的沟通成本从"口头"变成了"接口文档版本号"------换了个载体，本质还是靠人盯。
AI 全链路要面对的是同一个问题，只是规模更大：当整条链路都在自动跑的时候，变更信号从哪里进来，怎么传递到每一个受影响的 Agent，怎么让已完成的产出物知道自己需要重跑？
这个问题目前没有成熟答案，但它是 AI 全链路走向真正高效前必须解决的那道坎。
我把整条链路拆开看了一下，每个模块都有自己的痛点。
格式不统一每次重新理解"] R_FIX["提效方向：标准化需求模板
用户故事 + 边界条件表 + Mermaid 流程图"] R_PAIN --> R_FIX end subgraph DESIGN_MOD["设计模块"] D_PAIN["痛点：设计与开发缺少共同规范
AI 读出来的节点无法映射到代码组件"] D_FIX["提效方向：制定设计开发共同命名规范
组件分组对齐 → AI 读节点直接生成代码"] D_PAIN --> D_FIX end subgraph API_MOD["接口契约模块"] A_PAIN["痛点：前后端 Agent 各写各的
联调字段名 / 类型 / 分页全对不上"] A_FIX["提效方向：后端先写 Apifox Contract
前端 Agent 和测试 Agent 都以它为准
顺序不能反"] A_PAIN --> A_FIX end subgraph CODE_MOD["代码生成模块"] C_PAIN["痛点：上下文一长就断片
忘规范 忘 Contract 忘已有工具函数"] C_FIX["提效方向：持久化项目规则注入
子任务拆细 每个任务独立生成独立验证"] C_PAIN --> C_FIX end subgraph TEST_MOD["测试模块"] T_PAIN["痛点：覆盖率好看但测自己写的代码
边界条件 / 异常流程 / UI 还原度覆盖不到"] T_FIX["提效方向：从 PRD 边界条件表出发设计用例
模拟器截图 + uiautomator dump 让 AI 真正看到页面"] T_PAIN --> T_FIX end style R_PAIN fill:#fde8e8,stroke:#d9534f style D_PAIN fill:#fde8e8,stroke:#d9534f style A_PAIN fill:#fde8e8,stroke:#d9534f style C_PAIN fill:#fde8e8,stroke:#d9534f style T_PAIN fill:#fde8e8,stroke:#d9534f style R_FIX fill:#e8f6e8,stroke:#5cb85c style D_FIX fill:#e8f6e8,stroke:#5cb85c style A_FIX fill:#e8f6e8,stroke:#5cb85c style C_FIX fill:#e8f6e8,stroke:#5cb85c style T_FIX fill:#e8f6e8,stroke:#5cb85c
下面展开说每个模块。
需求模块
痛点：产品经理写需求的方式和 AI 能理解的方式之间有一道鸿沟。
口头描述的需求太模糊，AI 会乱猜；结构化的需求（用户故事、边界条件、流程图）产品经理不一定会写；就算写了，格式不统一，AI 每次都要重新"理解"一遍。
现在能提效的方向：建立一套标准化的需求模板，用户故事 + 低保真原型 + 边界条件表 + Mermaid 流程图，让每一份需求单都是 AI 可以直接消费的结构化输入。这一步不是 AI 的问题，是人需要先养成结构化思维的习惯。
设计模块
痛点：Figma MCP（Model Context Protocol，让 AI 调用外部系统的标准协议，可以理解成给 AI 装的插件）已经能让 AI 直接读取设计稿的节点信息，这个技术问题基本解决了。但读出来能不能用，是另一回事。
真正的问题是设计和开发之间缺少共同规范 。设计师按自己的习惯命名组件和分组------矩形 23、frame-copy-2、按钮备用版------AI 读出来是一堆没有语义的节点，根本无法映射到代码里的 Button、Card、Modal。这不是工具的问题，是设计和开发两端从来没有对齐过命名和组件边界。
现在能提效的方向：设计和开发共同制定一套组件命名规范和分组约定，Figma 里的组件名和代码里的组件名一一对应。这件事不需要等工具，现在就可以做，做完之后 AI 读 Figma 节点生成代码的准确率会有明显提升。
接口契约模块
痛点：这是整条链路里最容易出问题的地方。
前端 Agent 和后端 Agent 各写各的，没有一个"合同"约束，最后联调的时候字段名对不上、类型对不上、分页参数对不上。这和 2014 年前后端分离初期的接口联调问题是同一个问题，只不过现在踩坑的变成了两个 AI。
现在能提效的方向：Apifox Contract 是目前最可行的方案，先有接口契约，后有代码实现。后端先在 Apifox 里录入完整的接口定义，前端 Agent 读 Contract 写代码，测试 Agent 读 Contract 写用例。这个顺序不能反。
代码生成模块
痛点：AI 生成代码的单次质量还不错，但上下文一长就开始"断片"，忘了之前定好的规范，忘了读 Contract，忘了项目已有的工具函数。
现在能提效的方向：给 Agent 配置持久化的项目规则------技术栈、编码规范、目录结构、常用工具函数的位置，在每次会话启动时作为基础约束注入进上下文。Claude Code 就是这个思路的具体实现，它在每次启动时自动加载项目级的规则配置，让 Agent 始终在正确的框架下工作。另外，不要让 AI 一次生成太多，按功能模块拆分，每个子任务独立生成、独立验证。
测试模块
痛点：AI 写的单元测试覆盖率好看，但测的都是"自己写的代码"，边界情况、异常流程、UI 还原度这些反而覆盖不到。
现在能提效的方向：测试 Agent 需要有"人的视角"------从 PRD 的边界条件表出发设计用例，而不是从代码反推。模拟器截图 + uiautomator dump 这条路在 Android 开发里已经跑通了，可以让 AI 真正"看到"页面，而不是只看代码。
现在最大的效率瓶颈不在 AI，在协作契约
把上面这些痛点放在一起看，会发现一个共同点：问题不是 AI 不够强，而是 AI 和 AI 之间、AI 和人之间，缺少协作契约。
前后端分离解决效率问题的核心武器，就是各种契约：接口契约（Swagger/Apifox）、代码规范契约（ESLint）、部署契约（CI/CD 配置）、组件契约（Storybook）。
AI 全链路需要的是同一类东西：
TAPD 标准化需求单"] C2["设计契约
Figma Design Token + 命名规范"] C3["接口契约
Apifox Contract"] C4["角色契约
Agent 职责边界定义"] C5["规则契约
项目上下文 + 编码规范注入"] end subgraph PROBLEMS["没有契约时的症状"] P1["AI 乱猜需求 反复确认"] P2["前端靠眼睛还原 还原度差"] P3["前后端 Agent 联调字段对不上"] P4["Agent 越权 产出物互相覆盖"] P5["上下文断片 忘规范忘工具函数"] end P1 -- "解决" --> C1 P2 -- "解决" --> C2 P3 -- "解决" --> C3 P4 -- "解决" --> C4 P5 -- "解决" --> C5 style CONTRACTS fill:#e8f6e8,stroke:#5cb85c style PROBLEMS fill:#fde8e8,stroke:#d9534f
这些契约不是 AI 能自动建立的，需要人先把它搭好。这也是为什么现在推 AI 全链路反而更慢的原因------我们在用 AI 干活，但还没建好让 AI 高效干活的基础设施。
但光有契约还不够。契约只是定义了"规则"，真正让效率飞起来的，是把这些规则沉进工具------让工具自动执行契约，而不是靠人每次手动对照。
下一跳：模板 + CLI 的思路能复用吗
说到这里，我脑子里又冒出了另一个类比。
前端工程化那一轮效率爆炸，有一个关键的跃迁点不是"工具变多了"，而是编程模型变了。
手写 HTML+JS+CSS 的时代，开发者要写的是所有细节------DOM 操作、事件绑定、样式层叠，全部手工。React 和 Vue 出来之后，开发者只需要写模板，声明"我要什么"，框架和 CLI 负责把模板编译成浏览器能跑的代码，细节全部收进工具层。
这一跳的本质是：人只表达意图，工具负责展开。
今年（2026年）3月，尤雨溪在 VoidZero 发布了 Vite+ Alpha，把这个理念推向了极致------一个 vp 命令 + 一个 vite.config.ts，把 runtime 管理、包管理器、构建、测试、lint、格式化全部收进一个统一入口，过去要维护十几个配置文件的复杂度，现在一个文件搞定。他们的原话是 "simplify the web development process"，本质就是：配置和决策全部沉进工具，开发者只表达意图。这个方向我觉得说到点子上了。
那现在 AI 全链路，有没有同样的机会？
有。而且这个"编译层"已经有雏形了，只是还没系统化。
所有细节全部手工"] end subgraph FRAME["框架时代（高效）"] F1["写模板 + 声明组件"] F2["CLI 编译 + 框架运行时"] F1 --> F2 F2 --> F3["浏览器可运行的代码"] end subgraph NOW["AI 链路现状（低效）"] N1["手动配置 Agent
手动接 MCP
手动写 prompt
手动管理 skill"] end subgraph FUTURE["AI 工具化时代（目标）"] T1["描述意图
一句话需求 / 模板配置"] T2["AI 工具链编译层
Skill 管理 / MCP 编排 / Agent 调度"] T1 --> T2 T2 --> T3["可执行的全链路 Agent 流程"] end OLD -- "框架革命" --> FRAME NOW -- "工具化革命" --> FUTURE style OLD fill:#fde8e8,stroke:#d9534f style NOW fill:#fde8e8,stroke:#d9534f style FRAME fill:#e8f6e8,stroke:#5cb85c style FUTURE fill:#fff3cd,stroke:#f0ad4e
我们现在做的事------手动配置 Claude Code、手动写 CLAUDE.md、手动接 MCP、手动定义 Skill------本质上还是在"手写 HTML"。繁琐、容易出错、换个项目就得重来。
真正的跃迁，是把这一层工具化。
AI + 需求：模板驱动的需求拆解
现在的做法是产品经理口述，AI 自由发挥理解，每次理解深度不一样。
工具化之后应该是：一套需求模板（用户故事 + 边界条件 + 流程图格式）内置到工具里，产品经理输入一句话，工具自动展开成结构化需求单，AI 拿到的永远是格式一致、字段完整的输入。就像 Vue 的 <template> 语法，写的时候很自然，编译出来是标准的 render function。
这个方向现在已经有人在做了，比如部分 PM 工具开始内置 AI 需求拆解，把"一句话需求"自动展开成 Epic → Story → Task 的层级结构。
AI + 设计：让设计稿天然可被机器读取
Figma MCP 已经打通了 AI 读取设计稿的技术路径，现在缺的不是工具，是设计侧和开发侧共同遵守的一套规范。
工具化之后应该是：设计系统里的组件命名、分组结构、变量命名与代码组件严格对应，AI 读出节点就知道该生成什么组件、用什么属性。更进一步，组件的交互状态（hover、disabled、loading）在 Figma 里有对应的 variant 定义，AI 可以直接生成带状态的完整组件，而不是只还原静态样式。
Figma 的 Variables 体系和 Component Properties 已经提供了这个能力，现在缺的是设计和开发团队坐下来把规范对齐------这是一次性的沉淀，做完之后每个后续需求都能受益。
AI + Coding：Skill 和 MCP 的工程化管理
这是目前最混乱的一块。每个团队自己攒一套 Skill，自己接一套 MCP，没有复用，换个项目全部重写。
先解释一下 Skill 的概念：Skill 是把一段常用的 AI 操作封装成可复用的指令（类似函数）；MCP 前面设计模块提到过，接上哪个 MCP，AI 就能操作哪个系统。
工具化之后应该是：一个 Skill 注册表 + MCP 市场，类似 npm 生态。常用的 Skill（需求拆解、代码生成、自测报告）可以发布和复用，MCP 工具（TAPD、GitLab、Apifox）有标准化的接入配置，项目级的 CLAUDE.md 只需要声明"我用哪些 Skill、接哪些 MCP"，工具链自动装配好运行环境。
Claude Code 的 Skill 机制现在其实已经是这个方向的雏形了------把常用操作封装成 /skill，在任何项目里都可以调用。但还缺团队级的共享和版本管理，也缺和 MCP 的联动编排。
AI + CI/CD：流水线从"执行者"变成"诊断者"
CI/CD 目前是全链路里 AI 介入最少的一块，基本上还是纯机械执行：跑测试、跑构建、报失败。失败了，开发者自己打开日志慢慢看。
痛点：构建失败的日志动辄几百行，真正有用的报错往往藏在中间，开发者花在"看日志找原因"上的时间经常超过"修问题"本身。更麻烦的是，同一类错误在不同项目里反复出现，但每次都要重新排查，经验没有沉淀。
工具化之后应该是什么样：流水线里内置 AI 分析节点，测试或构建失败时自动提取关键报错、定位根因、给出修复建议，直接附在 MR 评论里。更进一步的方向是：对于有明确修复模式的失败（比如 lint 报错、类型错误），直接触发 Agent 修复并重新推送------开发者收到的不是"构建失败"的通知，而是"已自动修复，请 review"。
这个方向已经在发生了。GitHub Copilot 在 Actions 里的错误分析、GitLab Duo 的 CI 根因建议，都是这个思路的早期实现。工具化程度还不高，但方向是确定的。
AI + Test：从"验代码"到"验意图"
现在 AI 写测试的问题是视角错了------它从代码出发写用例，等于是在验证自己写的东西。
工具化之后应该是：测试 Agent 的输入不是代码，而是 PRD 的边界条件表。工具从需求单里自动提取边界场景，生成测试矩阵，再去跑代码验证。这样测的是"产品意图有没有实现"，而不是"代码有没有语法错误"。
那我们现在应该积累什么
这个问题让我想起 2016 年前端工程师该学什么：不是学最新的框架，而是先把工程化搞清楚，搞清楚 webpack 是干什么的，搞清楚为什么要有模块化，等基础打牢了，框架换再多也不慌。
AI 全链路时代也一样，应该积累的不是"会用哪个 AI 工具"，而是这几个更底层的能力：
1. 结构化表达能力
AI 最擅长处理的是结构清晰的输入。需求、方案、用例，越结构化越好。这不是会不会用 AI 的问题，是能不能把想法清晰表达出来的问题。现在就可以开始练：写需求时写边界条件，写方案时画流程图，拆任务时拆到可以独立交付的粒度。
2. 契约设计能力
每个模块之间的交界面要怎么定义------接口怎么设计，Figma 组件怎么命名，需求单格式怎么统一。掌握这个的人，在 AI 时代是链路的"设计者"，而不只是执行者。
3. 工具化思维
遇到重复的手工操作，先想"能不能封装成 Skill"；遇到跨系统的数据流动，先想"能不能用 MCP 打通"；遇到团队协作的摩擦，先想"能不能沉淀成模板"。不是每次都靠人工盯着，而是把规律沉进工具里。
4. 对 AI 输出的验证习惯
AI 出错的方式和人不一样。代码逻辑通顺，但可能悄悄漏掉边界条件；需求方案结构完整，但可能把两个相互矛盾的点都写进去了。建立"AI 输出 → 人工快速验证"的节奏，比"跑完发现跑错了再返工"高效得多。
5. 变更管理意识------这是 AI 全链路独有的新挑战
前面说的四点，人工开发时代也需要。但这一点是 AI 全链路特有的：你需要知道，当需求发生变更时，哪些 Agent 的产出物失效了。
前后端分离时代，变更靠人传递，低效但有感知。AI 全链路时代，链路跑得越快，变更造成的"静默失效"就越多------没有报错，没有提示，只有一堆基于旧需求生成的产出物安静地躺在那里。
现在能做的，是在设计链路的时候就把变更入口想清楚：需求单是唯一的变更入口，所有 Agent 的产出物都能追溯到对应的需求版本，变更发生时能快速判断影响范围。这不是工具的问题，是链路设计者的责任。
至于"变更自动触发 Agent 重跑受影响的模块"------这个方向是确定的，但现在还没有成熟的实现。这是留给这条路上下一批人去解决的问题。
结语
前后端分离从 2013 年到 2025 年走了 10 年多，中间有混乱、有反复，但每次有人解决了一个模块的痛点，整条链路就往前走一步。
AI 全链路现在就在这个起点。现阶段低效是正常的，就像 2014 年你联调一个接口能吵一下午一样正常。问题不是 AI 不行，而是那一层"编译器"------把人的意图翻译成 Agent 可执行动作的工具层------还没建好。
尤雨溪在 Vite+ 里把"极致工具化"这件事做到了 JS 工具链层面，AI 全链路也需要同样的那一层。AI + 工具才能真正提效，工具化不是终点，是那个能让效率跳台阶的杠杆支点。
契约搭好，工具化跟上，那个台阶就在前面。
我们正在往上爬。