如果一个团队真的想做 AI-Native 研发组织，第一步是改组织契约：谁可以让 AI 产出代码，谁对代码负责，什么质量底线不能退，什么流程可以砍，什么流程必须更重。

AI 现在太会写代码了，但是这就会导致一个问题：它把「产出代码」这件事的成本做到很低，低到组织里原本那些靠角色边界、流程延迟、评审机制勉强维持的质量平衡，突然失效了。

过去一个 PM 提需求，前端写页面，后端写接口，测试回归，整个链条慢，但慢本身也是一种摩擦力。现在 PM 自己就能把页面跑起来，AI 一下午能写出几十个组件，速度是上去了，但系统开始更脆弱了。

先说 AI-Native 组织不是什么。 AI-Native 组织它不是「让所有人都开始写代码」，也不是「研发岗位会被提示词工程师替代」。

它是把软件组织里的逻辑重排。

以前文档是入口，代码是结果。现在代码变成入口，文档变成派生物。 以前角色按工种切，PM、设计、前端、后端、测试各守一段。现在角色要按责任切： 谁定义业务闭环，谁维护系统护栏，谁提供稳定契约，谁为线上事故买单。

今天我们先聊组织契约，再聊角色重构，然后再把一条研发流水线拆开聊聊。

组织契约

没有组织契约，AI 进团队只会把烂流程放大。

合理预期

在某些 Demo 场景，或者脚本类场景，10 倍是一个合理的预期。 但是对于一个组织来说，10 倍是一个不科学的场景，因为在组织里面，在产品研发过程中，写代码并不是整个生产过程中最耗时的部分。

所以，我们要先摈弃一个幻觉：不要拿 10 倍产出当目标。

AI 在研发组织里的收益区间，我一直认为是 1.5 到 2 倍，高质量前提下的 2 倍。为什么呢？ 因为代码生成速度和有效交付速度不是一回事。AI 能把编码阶段压缩掉一大块时间，但需求澄清、边界判断、异常处理、联调、测试、观测、回滚，这些成本不会自动消失。很多时候还会更高。

如果团队盯着 10 倍，结果一般都一样：PR 数量暴涨，代码体积暴涨，Review 质量下降，线上回归问题增加，半年后开始集中还债。这就是技术债积累速度第一次超过了团队消化速度。

所以合理预期应该写进团队共识里：我们追求的是 2 倍高质量交付，不追求 10 倍低质量代码喷射。

所有权

每个 AI 输出都必须有所有者。

谁发起生成，谁提交 PR，谁 approve merge，这中间可以分层，但最终必须落到一个明确的人身上。这个人要能够面对一句话：如果这段代码挂上你的名字，你愿不愿意负责。要是答案是否定的，这段代码就不该进主干。

这条规则听起来像废话，实际上很多团队做不到。因为 AI 会制造一种错觉：代码好像不是谁写的，是系统吐出来的。人变成了搬运工。只要团队接受这种错觉，质量就开始漂移。一个有所有权的流程大概是这样：

• PR 模板里要求声明 AI 参与范围
• 提交人对业务正确性负责
• Reviewer 对工程质量负责
• 合并人对上线风险负责

责任可以分工，但责任不能悬空。

质量顺序

质量第一，数量第二。

团队如果不显式声明这一点，默认会被 AI 拖向另一个方向：先铺功能，再补治理。这个方向对 demo 团队成立，对正式业务组织通常是灾难。因为 AI 特别擅长快速补齐显性功能，却不擅长主动建立长期维护结构。它会顺着需求走，不会替你守架构。

AI 时代必须把一些以前属于「好习惯」的东西升级为「强制门槛」，也就是我们之前经常强调的规范，流程等等，如测试、监控、CI/CD、单测等等。

• 没有测试，不进主干
• 没有异常处理，不进主干
• 没有监控埋点，不进主干
• 没有 feature flag，不上线
• 不能被 reviewer 解释清楚的代码，不 merge

当代码供给能力暴涨时，质量约束必须同步加码，否则系统会很快从可控变成不可控。

交付代码

传统产品研发里，PRD 是上游，代码是下游。这个模型的问题大家都熟：PRD 经常过期，设计稿和实现偏移，字段定义藏在飞书文档、接口平台、聊天记录和前端代码里，最后没有一个地方是真正可靠的。

AI-Native 组织里：代码作为唯一源，文档从代码反向提取。

从代码出发

现在 PM 借助 Codex、Claude Code（最近又有同事被封号了）、Cursor 这类工具，已经可以生成带交互的页面、Mock 数据、状态流转，很多场景下甚至能直接把核心业务路径跑通。既然这样，就不要再让 PM 先写一份长 PRD，再让研发去猜什么叫「列表为空时的引导态」。让页面先跑起来，再从页面反推需求定义，效率和准确率都更高。

这里有个好处：讨论变得具体了。

以前评审会上大家讨论一句文档描述，脑子里各自渲染不同 UI。现在把页面摆出来，点击路径、字段结构、交互反馈、错误提示都变成可观察对象。对齐成本直线下降。后端也不需要看十页文字说明，只要看这个页面最终需要什么数据结构，就知道接口该怎么供给。

文档反向生成

代码是唯一真相源，不等于不要文档。让文档变成派生物，而且是自动派生物。

流程大概如下：

1. PM 先生成并跑通前端页面，带 Mock 数据
2. AI 从页面代码、组件 props、Mock schema 中逆向提取字段说明、交互流程、状态机描述
3. PM 对这份自动生成的文档做人审
4. 后端按确认后的 JSON Schema 或 TypeScript Interface 实现接口
5. 联调时再根据真实契约让 AI 回写文档

这样处理后，文档不再是一个独立维护成本很高的系统，而是代码的视图层。它可以读给人看，但它的源头来自真实实现，而不是空想。

建议把接口契约标准化为 JSON Schema 或 TypeScript Interface

角色重构

AI-Native 组织可能会有一些角色的变更，但是也可能会裁掉一些角色，因为我们是重写角色边界。如果当前人不合适，或者适应不了，就需要换，否则就会变成打造新组织过程中的阻碍。

很多人讨论这件事喜欢走两个极端。一个极端是「以后人人都是全栈」。另一个极端是「AI 只会替代初级岗位，核心角色不变」。这两个判断都不够准确。

真正发生的变化是：低门槛生产能力下放，专业门槛上移。简单说，更多人能做出东西，但真正有价值的岗位，会向规范制定、质量兜底、系统抽象和复杂问题处理集中。

PM 变成产品工程师

在这个新组织中，变化最大的角色是 PM。

过去 PM 的主要输出物是 PRD、流程图、原型图和口头解释。现在这些东西很多都可以收敛成一个交互可运行的页面。于是 PM 的角色自然往「产品工程师」移动：他不再只描述需求，他直接构造需求的运行形态。

但这里一定要说清楚，PM 写了前端代码，不等于 PM 变成前端工程师。PM 的责任边界还是业务逻辑，不是工程治理。

PM 需要对什么负责：

• 用户路径是否闭环
• 页面状态是否完整
• 文案、条件、分支、空态是否符合业务预期
• Mock 数据结构是否表达真实业务语义
• 生成代码是否遵守团队规定的基础组件和样式约束

PM 不需要对什么负责：

• 全局状态架构是否优雅
• 包体积是否最优
• 路由切换是否引入副作用
• 渲染性能是否达标
• 工程抽象是否可复用

这些后者还是需要专业前端要接住。

问题不是让 PM 承担更多，而是让 PM 把过去停留在文档层的业务表达，直接推进到代码层。这样整个团队拿到的是可执行的业务定义，不是抽象说明书。

设计师变成立法者

设计角色也会变。

当 PM 可以直接借助 AI 生成页面时，设计师如果还把大量时间耗在单页面高保真稿上，投入产出比会快速下降。更有价值的位置，是维护设计系统和机器可消费的样式规范。

设计师的工作重心会变成：

• Design System
• 样式 token
• Visual QA

也就是把颜色、间距、字体、圆角、阴影、组件状态、可访问性规范，从设计稿资产转化成代码和配置资产。比如 Tailwind config、CSS variables、组件规范、图标集、交互动效约束。这些东西一旦进入 AI 生成上下文，PM 或其他角色在生成页面时就不容易跑偏。

说白了，设计师从「画每一张图」转向「制定法律」。立法做得越完整，AI 和 PM 生成的页面越像一个系统，而不是一堆拼起来的截图。

前端变成守门员和重构者

前端是最容易被误读的角色。很多人看到 PM 可以生成页面，就开始下结论：前端会被干掉。实际情况通常相反。前端从体力活里解放出来之后，工程价值反而被放大了。

因为 PM 生成的页面，最常见的问题不是「长得不对」，而是「能跑但脆」。

可能会有大量这类代码：

• 一个组件里塞满请求、状态、渲染、事件处理
• loading、error、empty 三种状态缺两种
• useEffect 依赖写错
• 切页面回来状态丢失
• 没有 abort controller，快速切换导致竞态更新
• 表单校验只校 happy path
• 直接把 mock 字段名写死在视图层，后续接口一改全炸

这些问题不是 PM 能解决的，也不是 AI 自己会主动解决的。前端真正的工作变成三块：

第一块，Review。
不是审美式 review，也不是找缩进。重点看稳定性、边界条件、状态管理、组件职责、可维护性。

第二块，Refactor。
把单文件逻辑拆成组件、hooks、domain service，把团队组件库接上，把状态流收敛，把重复逻辑抽掉。这个过程需要持续迭代，做到团队规范中，给到 PM 生成的上下文中。

第三块，Integration。
把 Mock 替换成真实 API，处理鉴权、缓存、错误回退、重试、并发、路由守卫、埋点、监控。

这个阶段的前端，更像体验架构师和质量守门员。

后端变成能力供应商

后端角色也会收缩：提供稳定、安全、确定性的能力边界。

如果前端页面能更快被构造出来，后端的价值就不在于「接收一份文档然后写 CRUD」，而在于把系统能力以 API 或 Tools 的形式稳定暴露出来。尤其是 AI Agent 场景下，后端实际上在扮演工具供应商。

后端重点关注四类问题：

• 契约稳定性
• 权限与安全
• 幂等性与确定性
• 可观测性与审计

前端、PM、Agent 都可能直接消费这些能力。一旦接口设计漂、错误码混乱、鉴权模型含糊，整个上层生成式开发就会持续返工。AI 会把不稳定接口的问题放大得很明显，因为它极度依赖上下文中的确定性。

流程重构

只讲角色变化不够，需要把研发流程改成适合 AI 的形状。下面是一版比较能落地。

需求具象

第一阶段，需求不再先写成长文档，而是先具象成可运行页面。

PM 独立生成前端

PM 拿着明确业务目标，直接在受控环境里生成页面代码。这个页面至少要包含：

• UI 布局
• 基本交互
• 主要状态流转
• Mock 数据
• 核心校验逻辑
• 空态、错误态、加载态

特别强调最后三项。很多团队让 PM 生成页面，只盯着主流程，结果页面演示时很漂亮，一联调全是坑。空态、错误态、加载态必须在这个阶段一起生成，否则后面每一轮都要补票。

禁止黑盒交付

PM 生成页面这件事，最怕黑盒。也就是只看效果图对不对，不管代码是否落在团队跑道上。

所以团队必须先准备好脚手架和护栏。比如：

• 必须使用指定组件库
• 必须使用既定样式 token
• 必须遵守目录结构
• 必须使用指定的数据获取模式
• 必须输出可运行测试脚本
• 必须带 feature flag 接入点

否则 PM 生成的代码看似完成任务，实际是给前端制造二次工程。

不要让 PM 从空白页面开始提示 AI，而是给一个完整的基础模板，再让 AI 在模板内填充。这个模板的价值极高，它决定了团队是让 AI 在高速公路上开车，还是在野地里乱冲。

契约握手

第二阶段，前端页面和后端能力正式握手。

前端反定义接口

以前是后端先定义接口，前端去适配。现在很多场景可以反过来：前端页面里需要什么数据结构，先自然长出来，再把这份结构抽取成契约。

这里的关键点是「自然长出来」之后，必须立刻标准化。不能停留在 JS 对象字面量和口头描述。最好直接生成：

• JSON Schema
• TypeScript Interface
• 字段说明
• 校验规则
• 错误码预期
• 状态迁移说明

做到这一步，后端看到的就不是「我要一个用户列表接口」，而是一个明确的数据契约：字段、类型、可空性、分页、排序、过滤、异常响应、鉴权要求，全都摆明。

这一步会明显减少沟通损耗。后端可以少看很多无效文档，直接围绕契约开发。

后端提供确定性能力

后端接手后，不建议只机械实现接口。要借这个机会把系统能力做成稳定工具层。

如果团队本身就在做 Agent 或工作流系统，这里更应该统一成 Tools 注册机制，而不是散落一地的临时 API。因为未来调用这些能力的，未必只有前端页面，还有内部 Agent、自动化流程、运营工具、甚至外部合作系统。

后端在这一阶段最常踩的坑有几个：

第一，返回结构不稳定。
今天 success 返回 data，明天又套一层 payload。前端 AI 生成代码时非常怕这个，会反复产生错误适配。

第二，错误码语义不清。
鉴权失败、参数错误、资源不存在、限流、业务冲突全都混成一种 message，联调体验很差。

第三，幂等性缺失。
AI 驱动的调用链经常会重试，如果创建类接口没有幂等控制，很容易重复写入。

第四，缺少审计。
AI 或 PM 直接驱动系统能力时，操作路径更分散，审计日志不能省。

联调瓶颈

真正的瓶颈通常出现在第三阶段：联调、测试、排雷。

到这一步，很多团队会发现：AI 把前半段提速提得很猛，但最后这段并没有自动消失，甚至更重。因为前面生成得越快，后面积累的隐患越多。

Review 的重点

前端 reviewer 在这一阶段要非常克制。不要把 review 做成审美比赛，也不要上来就要求所有代码重写一遍。真正该看的，是那些会直接影响稳定性和维护成本的问题。

我会把检查项固定成一张表，至少覆盖这些内容：

• 异步请求是否有取消机制
• Loading、Empty、Error 状态是否完整
• 表单提交是否防重入
• 路由切换是否会遗留脏状态
• 全局状态有没有被随意污染
• 组件职责是否过载
• 是否接入统一埋点与异常上报
• 是否存在明显重复逻辑
• 是否绕过设计系统直接手写样式
• 是否引入不必要依赖

这样做的好处是，review 从个人经验驱动变成组织标准驱动。AI 时代 PR 量会明显增加，没有标准化检查单，review 质量一定掉。

测试和验收左移

如果团队已经允许 PM 直接交付前端页面，那测试必须同步左移。否则生成速度越快，测试越像消防队。

谁生成页面，谁至少生成对应的 E2E 测试脚本。这个要求不算过分。因为页面交互路径是 PM 最熟的，AI 根据这些路径生成 Playwright 或 Cypress 脚本，命中率通常不低。

在生成代码时，PM 已经完成了第一次的验收。

测试左移不是为了把测试岗位干掉，而是为了把最贴近业务逻辑的验证提前到需求具象阶段。后面的 QA 才能把精力放在组合场景和系统回归上。

发布保险

第四阶段是发布与可观测性。这在 AI-Native 组织里是核心流程。

因为一旦允许更广泛的人群借助 AI 产出代码，线上报错率几乎一定会上升。组织必须提前接受这个现实，然后把监控和发布控制建好。

前端监控

前端监控一定要上，而且要够细。

至少需要这些能力：

• 错误堆栈捕获
• Source map 还原
• 用户会话回放
• 性能指标采集
• 接口失败聚合
• 版本维度对比

像 Sentry、LogRocket 这类工具的价值，在 AI 场景下会更高。因为当报错出现时，你可以把错误堆栈、用户操作轨迹、接口上下文直接喂给 AI，让它先生成修复建议，再由责任人确认。这种协作模式对定位简单问题很有效，尤其是 UI 状态错乱、边界遗漏、类型不匹配这类故障。

但不要误解成「有了 AI 修 bug 就轻松」。线上修复的难点从来不只是生成 patch，而是确认根因、评估影响面、决定是否回滚、验证是否引入新问题。这些仍然要靠工程纪律。

灰度发布

Feature Flag 在这个模式里几乎是必需品。

原因不复杂：当业务页面大量由 PM + AI 参与生成时，组织需要一个足够便宜的试错阀门。否则每次上线都把全量用户暴露在新逻辑下，风险太高。

把 Feature Flag 从「重要功能才加」提升为默认机制。尤其是下面这些场景必须强制：

• 新页面替换旧页面
• 新流程替换旧流程
• 高价值转化路径
• 涉及支付、权限、数据修改的动作
• 首次由非传统研发角色主导产出的功能

灰度期间要明确看哪些指标，不要只看有没有报错。还要看：

• 转化率变化
• 页面停留时长
• 关键按钮点击率
• 表单提交成功率
• 接口失败率
• 用户退出路径

这些数据能帮助团队判断问题究竟出在代码稳定性，还是业务交互本身。

基建先行

前面这些流程能否跑起来，核心在于基建。没有基建，AI-Native 组织会迅速退化成提示词手工作坊。

可以先建三类基础设施。

护栏脚手架

这是第一优先级。

它包括：

• 项目模板
• 目录规范
• 统一组件库
• 设计 token
• 数据获取封装
• 表单与校验约定
• 埋点和监控 SDK
• 测试模板
• CI 预设规则

这套东西是整个组织 Harness 的部分。

Prompt 资产

很多团队低估了 Prompt Library 的价值。实际上，当非工程角色也开始产出代码时，提示词模板本身就是组织资产。

可以把高频场景沉淀成标准模板，比如：

• 列表页生成模板
• 表单页生成模板
• 详情页生成模板
• 多步骤流程模板
• 异常状态模板
• E2E 测试生成模板
• 文档反向提取模板
• 重构任务模板

这些模板不是为了追求文风统一，而是为了把团队积累的工程约束嵌进去。你希望 PM 每次生成页面都自动包含 loading、error、empty、feature flag、埋点、测试入口，那就别靠口头提醒，直接写进模板。

CI/CD 闸门

AI 时代，CI/CD 不能只是跑个 lint。它必须承担质量闸门职责。

最低限度我会要求：

• Lint
• Type check
• Unit test
• E2E smoke test
• Bundle size 检查
• 安全扫描
• 依赖合规检查
• 自动化预览环境
• 灰度发布流水线
• 一键回滚

如果团队现在连这些都没有，先别急着搞 PM 交付前端代码。真把口子放开了，组织会先被事故教育一遍。

常见误区

这是几个最常见的误区。

把 AI 当外包

这是第一类坑。很多团队使用 AI 的方式，本质上和用廉价外包没区别：把需求甩出去，拿回代码，自己不理解也不维护。

这个模式短期可能看起来很省，长期一定出问题。因为系统复杂度没有消失，只是被包进了你看不懂的代码里。等线上出事，你会发现团队没有形成任何新的内生能力。

只提速前半段

第二类坑是，只提速需求到页面这一段，不提速后面的治理、测试、发布、观测。结果就是项目看板前面一片绿，最后两列全堵死。

AI 会把组织瓶颈照得更亮。以前慢慢暴露的问题，现在两周就能堆出来。你不改后半段流程，前半段越快，堵得越严重。

容忍脏代码，也容忍脆弱代码

我能接受 PM 生成的代码不够优雅。变量命名一般、文件拆分普通、抽象层次一般，这些问题都能后续治理。真正不能接受的是脆弱代码：没异常处理、没监控、没测试、状态流断裂、提交会重复、接口失败直接白屏。

脏和脆是两回事。组织必须把这条线划清楚。

用 AI 替代判断

第四类坑最隐蔽。团队开始迷信 AI 给出的架构建议、重构建议、性能建议，仿佛它给出了答案，工程判断就可以省掉。

这是错的。AI 非常适合提供候选方案、加快实现、缩短试错周期，但它不拥有系统上下文，不承担线上责任，也不会为半年后的维护成本买单。架构判断、边界判断、风险判断，最终还是人做。

最后

如果一定要用一句话概括我对 AI-Native 软件研发组织的理解，那就是：把代码生产普遍化，把工程责任集中化。

前者意味着更多角色可以直接参与构造软件。PM 可以交付可运行页面，设计可以把规范直接编码，后端可以把能力做成工具供全组织消费。后者意味着系统质量不能民主化。责任必须更清晰，护栏必须更强，发布必须更克制，观测必须更细。

「PM 交付前端代码」这件事很容易被包装成一个新故事。真落地时，它首先是工程纪律问题，然后才是工具问题。团队如果没有建立所有权，没有把代码当唯一真相源，没有把契约、测试、监控、灰度这些基础设施补齐，这条路大概率会走成一场持续返工。

反过来，如果这些条件具备了，AI 确实会把组织推到一个新阶段。PRD 不再是那份总会过期的文档，代码本身就是需求表达。角色不再围着工种转，而是围着责任和系统边界重组。研发流程不再把大量时间浪费在翻译需求上，而是更早进入真实问题：契约、质量、异常、性能、发布。

这才是我理解的 AI-Native。

以上。