把 AI 放在协作链路的什么“位置”

当 AI 进入产研流程，最容易产生的误解是：我们在讨论“用不用 AI”“用哪个模型”“买哪个工具”。但真正决定组织形态的，不是工具清单，而是一个更底层的问题：AI 在交付链路里站在什么位置——它究竟是每个环节的加速器（副驾驶），还是贯穿交付的基础设施（施工队）？

沿着这个问题往下看，现实里会出现两条并行路径：AI-Augmented（AI 增强型） 与 AI-First（AI 原生型）。它们都在“融合 AI”，但融合的方式不同：前者主要改变速度，后者会改变链路结构。选择哪条路，不在于追逐概念，而在于你愿意为“把 AI 往链路下游推”付出多少治理代价，以及你的业务与风险边界是否允许。

1. AI-Augmented：在既定链路上加速

这是目前大多数团队所处的状态。其核心特征是：在维持现有岗位分工和协作流程基本不变的前提下，让 AI 进入每个环节提升单点效率。

在这种形态下，典型链路仍然是：需求（PRD/用户故事）→ 设计（原型/视觉）→ 开发（代码）→ 测试（验收）。产品经理、设计师、前后端研发、测试工程师的职责边界依然清晰，AI 更像一套高级工具（Copilot、各类生成式设计/文档助手），帮助每个角色更快地产出。

这条路的收益直观：重复劳动减少、产出速度提高、试错成本下降。但它的结构性矛盾也很典型：链路并没有缩短，协作摩擦并不会自动消失。当 AI 让“产出”变得更容易，评审（Review）和质检的压力反而可能上升；信息仍然在岗位间传递，损耗仍然存在，只是每段更快了。

2. AI-First：以交付闭环为中心重构

少数处于探索前沿的团队，会尝试另一种路径：不再将 AI 视为工具，而是将其视为组织运作的基础设施。 在这种形态下，传统岗位边界开始变得模糊，团队更倾向于“端到端交付能力”更强的通才或 T-shaped Professionals。

AI-First 的关键不在“生成能力更强”，而在协作方式的改变：从“人对人沟通”转向“人对标准/规则协作”。链路更像这样：Spec（规格说明）→ AI 执行与生成（实现/配置）→ 自动化验证证明符合 Spec → 交付。在这里，人的价值更集中在定义规则、校验逻辑、处理异常；AI 则承担大量构建性工作。

这条路的吸引力在于：当 Spec 足够清晰、验证足够强，交付链路能被显著压缩，想法到落地的速度会发生量级变化。但它也意味着：你把更多“交付责任”交给了机器，必须同时把更多“可控性”通过工程体系补回来。

3. 两种形态的简单对比

位置的代价：AI 越深入交付，治理就越要前置

到这里其实可以看到一个规律：AI 在链路里“站得越靠后”（越接近交付），组织就越必须把不确定性用工程化手段关进笼子。 因为当 AI 只是提升单点效率时，失误更多停留在局部；但当 AI 参与端到端生成与交付时，偏差会直接穿透到线上结果。

AI-Augmented：主要挑战是“协作摩擦不降反升”

在 AI-Augmented 下，问题往往不是“写不出”，而是“生成太多”。代码、文档、素材的产出量变大后，评审与测试的压力会上升。此时组织需要做的不是继续堆工具，而是把质量门禁与规范体系补强，让新增的产出仍然可控。

换句话说，AI-Augmented 的关键治理命题是：如何让 AI 生成的内容尽量沿着既有轨道前进，而不是制造更多‘野生变体’。

AI-First：主要挑战是“可控性差与容错率低”

AI-First 的风险更集中在“偏航成本”。当你让 AI 承担更多实现工作，任何意图不清、边界缺失、验证薄弱，都可能导致“AI 写得越快，Bug 越多，人越忙”的恶性循环。更重要的是：AI 生成的实现往往缺少人类的直觉推演路径，出错时定位与追溯更难，因此需要更强的可观测与审计体系。

因此，AI-First 的关键治理命题是：不是让 AI 生成，而是让 AI 在可证明、可追责、可回滚的体系中交付。

把“位置”落到现实：两种路径下的协作流程与前期基础建设

如果把“AI 在链路里站哪儿”当作第一性问题，那么流程与基建就不再是另一个话题，而是它的直接推论：你选择了哪种位置，就需要相应的流程设计与基础设施去托底。

一、融合 AI 后的协作流程

1. AI-Augmented：在既定轨道上加速

在增强型模式下，传统的“产品—设计—研发—测试”串行链路大体保持不变，AI 作为润滑剂渗透在每个环节。

需求与定义阶段，产品经理仍然主导 PRD 的撰写与需求拆解，但会用 AI 辅助竞品分析、用户故事拆分、初稿润色与风险点提示。设计与构建阶段，设计师利用 AI 生成素材、探索视觉风格；研发在编码过程中依赖 AI 补全代码、解释复杂逻辑、生成单测骨架。验证与交付阶段，测试使用 AI 生成测试用例与边界场景，但验收逻辑仍主要依赖人工点击与人工判断，最终交付的是一个“被人确认过”的版本。

在这里，人与 AI 的关系更像驾驶员与副驾驶：人掌控方向，AI 负责加速。

2. AI-First：以 Spec 为核心的闭环

在原生型模式下，流程不再强调岗位分工，而强调“定义与验证”的短闭环。

规格定义阶段不再产出冗长 PRD 或高保真原型，而是产出结构化的 Spec（规格说明）：它精确描述输入、输出、副作用、异常边界与验收标准，既是给 AI 的指令，也是后续验证的依据。执行与生成阶段，操作者将 Spec 输入 AI Agent，让 AI 端到端生成前端界面、后端逻辑及相关配置；人类更多承担“修偏差、处理报错、补边界”的职责。自动化验证阶段成为流程核心：代码提交后不再主要依赖人工 Code Review，而由 CI 系统自动验证 Spec 的符合度；只有当机器能证明逻辑符合 Spec，才允许进入下一环节；人工抽检更多承担兜底与关键风险点复核。

在这里，人类更像“规则与边界的定义者”，决定做什么、为什么做，AI 更像“可被约束的执行系统”。

二、前期基础建设

1. AI-Augmented 的基础建设：让加速不失控

增强型建设相对温和，重点是工具链引入与现有规范的补强。

首先是工具集成与环境配置：统一采购或部署代码补全、设计生成、文档助手等工具，并确保其能融入既有 IDE、设计软件与协作平台。更关键的是知识库与上下文喂养：把内部的代码规范、组件库、设计系统、交付模板等沉淀为可被 AI 调用的上下文，避免生成“看起来能用、实际上不合规”的内容。

最后是质量门禁加固：当 AI 提升了代码产出量，静态扫描（SAST）、依赖检查、许可证合规、代码风格与测试覆盖等基础能力必须同步加强。人工评审也需要迁移重点：从“语法对错”转向“架构合理性、业务逻辑漏洞、权限与数据安全风险”，否则评审会被产出量拖垮。

2. AI-First 的基础建设：让闭环可证明

原生型建设更颠覆，重点是工程化体系重构，因为它要支撑“可证明的交付”。

第一是 Spec 标准化体系：必须建立一套机器可读、人类可写的 Spec 规范，例如标准化 API 定义（OpenAPI）、数据契约（Schema）、行为描述与验收约束。没有标准，AI 不可能稳定理解意图，验证也无从谈起。

第二是 高可用的自动化验证环境：CI/CD 需要具备强大的自动化测试能力（单测、集成、E2E 至少要形成体系），并能快速、频繁地重建验证环境。因为当你不再依赖人盯每一行代码时，机器验证就是主要可信来源。

第三是 可观测性与审计追踪：由于实现由 AI 生成，出错时难以追溯“人脑逻辑”，必须用全链路日志、Tracing、Metrics 与版本化的决策记录补回可解释性，确保任何异常都能快速定位与回滚。

第四是 权限与沙箱隔离：当 AI 能调用更多工具、执行更多动作，风险边界必须从“流程规范”升级为“基础设施硬隔离”。对敏感数据与危险操作要严格限制访问权限，并将 AI 的执行环境沙箱化，避免误操作穿透到生产系统。

如何选择：因地制宜不是口号，而是对“位置与代价”的匹配

因此，选择的关键不在于追逐流行概念，而在于匹配。

如果你的业务处于探索期，需要快速试错，失败成本可控，并且具备一定的工程纪律，那么可以尝试向 AI-First 靠拢——至少在低风险、可回滚的业务单元中试点“Spec→生成→验证”的闭环，积累可复制的标准与验证资产。

如果你的业务是守成型、合规驱动且容不得半点闪失（例如医疗、金融、核心交易与关键数据系统），那么深耕 AI-Augmented 往往是更现实的最优解：用 AI 提升每个环节的效率，但把关键节点的决策权与验收权留在人类手里，并通过规范、质量门禁与知识沉淀，让加速不以失控为代价。

归根结底：把 AI 放在什么位置，本质上是在决定——你愿意用多少工程化基建，去换多少交付链路的缩短。