夜雨聆风如果一个团队真的想做 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。现在把页面摆出来，点击路径、字段结构、交互反馈、错误提示都变成可观察对象。对齐成本直线下降。后端也不需要看十页文字说明，只要看这个页面最终需要什么数据结构，就知道接口该怎么供给。
文档反向生成
代码是唯一真相源，不等于不要文档。让文档变成派生物，而且是自动派生物。
流程大概如下：
PM 先生成并跑通前端页面，带 Mock 数据 AI 从页面代码、组件 props、Mock schema 中逆向提取字段说明、交互流程、状态机描述 PM 对这份自动生成的文档做人审 后端按确认后的 JSON Schema 或 TypeScript Interface 实现接口 联调时再根据真实契约让 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。
以上。
