写在前面
"我们要用 AI 提效"------这个目标没有问题。
问题在于执行。很多企业的做法是：拿出现有的研发流程，然后把每一个步骤替换成"让 AI 来做"。
表面上看，这很合理。实际上，这是把一个旧瓶装新酒，然后问为什么没有效果。
这篇文章想说清楚一个问题：AI-Native Workflow 和"用 AI 做每一步"的平移 Workflow 之间，本质区别是什么？
问题根源：让错误的人用错误的框架定义 Workflow
在很多企业里，主导 AI Workflow 定义的是有流程专员背景的人，其经验集中在 ASPICE、CMMI 等标准流程体系上。
这类框架能给出高层阶段划分（需求分析、架构设计、详细设计、编码、单元测试......），但无法回答实际操作问题：每个阶段具体由谁、用什么工具、执行哪些步骤来完成，步骤之间真实的信息流和等待点在哪里。
根本原因是能力模型不匹配：ASPICE 框架描述的是 what，而不是 how。用它去设计 AI Workflow，层次对不上。
但更大的问题不是框架选错了，而是发现 Workflow 的方式。
发现 Workflow 的正确方式：别靠访谈
如果执行方式是访谈，得到的是"人认为自己在做什么"，而不是"人实际在做什么"。
认知与行为之间有巨大的鸿沟。最有价值的隐性操作步骤，连研发自己往往也说不清楚：
- "我在分析根因之前会先看一眼日志里的时间戳......"------说不清楚为什么，但每次都会做
- "我会先快速过一遍最近提交的代码改动......"------下意识的动作，访谈里不会提到
- "如果 CI 里有这个报错，我通常会先查 xxx 配置......"------经验积累的捷径，从没有被文档化过
更有效的挖掘方式：
嵌入式观察：跟随研发从接到 ticket 到 merge PR 的完整过程，记录每次工具切换、文档查询、等待反馈的时刻。关键不是听他们说什么，是观察他们做什么。
工具日志分析：Git commit 时间分布、Jira 状态流转时间、PR review 轮次------数据会暴露真实的等待点和摩擦点。
真正的 Workflow 节点藏在转换成本 和等待里，而不在阶段名称里。
什么是真正的 AI-Native Workflow
AI-Native 的本质不是"用 AI 重做人的每一步"，而是重新设计约束条件。
人受限于注意力切换成本、记忆容量和串行处理；AI 受限于上下文窗口、幻觉率和缺乏执行权限。真正的 AI-Native Workflow 以"人负责判断和决策，AI 负责上下文聚合和草稿生成"为基本假设来设计。
下面是四个判断测试，可以用来检验一个 Workflow 是否真正 AI-Native：
测试一：降级测试
把 AI 移除，Workflow 能否退化为效率低一些但逻辑完整的人工流程？
如果可以，AI 只是加速器，不是结构性组件。真正的 AI-Native 流程，移除 AI 后流程形态本身会崩塌------因为 AI 承担了一些人根本无法或不应该手动执行的任务（比如实时聚合 50 个相关 PR 的上下文）。
测试二：信息流方向测试
人工流程：人去各处收集 → 人聚合判断 → 人输出结果。 AI-Native：AI 持续监听和聚合上下文 → 在人需要决策时推送结构化信息 → 人只做判断。
如果重设计后信息流方向没变，只是每一步换成了"让 AI 帮我做"，那还是平移。
关键问题：在这个 Workflow 里，谁主动，谁被动？
测试三：人的角色测试
在这个 Workflow 里，人做的每一个操作，是判断/决策/创造 ，还是信息收集/格式转换/传递？
后者应该被 AI 完全接管。如果人还在做后者，Workflow 没设计完。
测试四：时间结构测试
人工流程是线性同步的（一步完成再做下一步）。AI-Native 可以是异步并行的------AI 在后台持续处理，人的介入是事件驱动而非轮询的。
如果新 Workflow 时间结构还是线性同步的，往往说明还是平移思维。
正反例对比
反例（AI 平移）：AI 代替人逐文件看 PR diff
- 人原来做什么：逐文件看 diff，判断改动是否合理
- AI 平移后：AI 逐文件看 diff，输出评审意见，人再看 AI 的评审意见
- 信息流方向没变，人的角色没变，只是多了一个中间层
正例（AI-Native）：PR 创建时，AI 自动聚合"需求背景 + 架构决策 + 测试覆盖率 + 历史 Bug 模式"，生成结构化 review 上下文，Reviewer 基于这份上下文做高层次判断
- 信息流方向变了：不再是人去各处收集上下文，而是 AI 主动推送
- 人的角色变了：从"信息收集 + 判断"变成"纯粹的判断"
- 时间结构变了：AI 的聚合工作在 PR 创建时就开始，是异步的；人的介入是事件驱动的
做这件事的人才画像
定义 AI-Native Workflow 的角色，需要几种能力的交叉，每种缺失都是真正的瓶颈：
必须有的能力：
- AI 能力的真实认知：不是"知道 AI 很厉害"，而是知道上下文窗口限制、幻觉规律、工具调用开销，能判断哪个步骤 AI 能做好、哪个会出问题
- 软件研发的亲身经历：至少在某个阶段真正写过代码或做过需求/设计，能理解开发者的真实心智模型
- 流程重设计的意识：看到一个流程时，第一反应是"这个流程是为了解决什么问题，有没有更好的方式重新解决"，而不是"怎么用 AI 做这一步"
- 田野调查的能力：能在观察中不打扰，提出让人展开说的问题，区分"他说他做了什么"和"他实际做了什么"
有害的背景（需要主动克服的思维定式）：
- 深度 ASPICE/CMMI 背景：习惯性用"阶段/活动/工件"框架看问题，AI-Native 设计需要打破这个框架
- 只有 AI 产品使用经验但没有开发经历：容易设计出"demo 里好看，实际工作中用不起来"的流程
最可能的人才来源：做过研发、后来深度接触 AI 工具并有系统性思考的高级工程师；或有技术背景的产品经理。
研发与流程定义者的协作模式
两者之间存在天然不对称：研发有信息但缺乏重设计视角，流程定义者有设计能力但缺乏信息。协作的核心是让信息真正流动，而不只是让研发"提需求"或"审方案"。
有效的协作模式：
影子观察（Shadow Session）：流程定义者不带问题观察研发完成真实任务，只记录，不打断。结束后研发标注"哪里感觉费劲"------比访谈得到的信息真实得多。
摩擦地图（Friction Mapping）：让研发记录"今天什么事情让我觉得烦"，不问"你觉得流程哪里可以优化"------前者是真实感受，后者是加工过的答案。
What-If 对话：不问"你觉得 AI 能帮你做什么"，而是问"如果你不需要做 X 这件事，你会把时间用在哪里"------让研发自己说出真正有价值的方向。
原型挑错：流程定义者提出重设计方案，让研发去"挑毛病"而不是"评审通过"------研发在批评时会暴露大量隐性知识。
反模式：
- 整理一套 Workflow 图开会让研发"确认是否符合实际"------研发说"差不多"，但实际细节大量错误
- 让研发"告诉我你需要哪些 AI 能力"------研发无法从空白处想象，这个问法没有有效输出
**关键前提**：研发参与这件事，必须感受到"这是在解决我的问题，不是在标准化我的工作"。第一批落地的 Workflow 必须让参与的研发个人明显感受到工作变轻了------这是后续推广的口碑基础。
实践路径
- 选一个具体任务切入，而非一开始就覆盖全流程（例如"从接到需求到输出技术方案"这一段）
- 跟做而非访谈：坐在研发旁边看他真实完成一个任务，记录每一步
- 识别信息聚合点：哪些步骤需要从多个来源收集信息------这些往往是 AI 最能提效的地方
- 重新设计而非平移：每个步骤问自己，如果 AI 来做这一步，它的输入输出应该是什么，人在这一步的角色是什么
- 从小 Workflow 积累，再考虑端到端串联
总结
判断一个 Workflow 是否真正 AI-Native，可以用四个测试：
- 降级测试：移除 AI 后，流程是否还能运行
- 信息流方向测试：AI 是否改变了信息的流动方向
- 人的角色测试：人是否只做判断和决策
- 时间结构测试：流程是否是事件驱动而非线性同步的
发现真正的 AI-Native Workflow，不能靠访谈，靠的是嵌入式观察和工具日志分析。定义它的人，需要同时具备 AI 认知、研发经历和流程重设计能力------这个组合很稀缺，也很值钱。
欢迎访问 PrimeSkills ------ 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。
更多实用知识和有趣产品，欢迎访问我的个人主页