最近跟几个做AI项目落地的朋友聊天，发现一个特别有意思的现象：
几乎每个人都跟我说——"流程梳理嘛，我们做过的，之前公司搞流程变革的时候就梳理过一轮了。"
然后呢？项目一旦进入实施阶段，全卡住了。
不是技术搞不定，不是模型选错了，而是 业务流程根本没梳理到位。拿着一张粗颗粒度的泳道图就去开发了，结果每个节点的输入输出是什么、谁触发谁、走到哪里该分支——全是模糊的。
我想很认真地讲一件事： AI项目里的流程梳理，和你过去做业务变革时的流程梳理，压根不是一回事。
为什么AI项目的流程梳理必须更细？
传统业务流程梳理，你画个泳道图，标清楚谁干什么事、大致的先后顺序，业务部门看得懂就行了。
但AI项目不一样。
你想想，你要让一个Agent去帮你处理某段流程。那它起码得知道：
——我从哪里被唤起？
——我的输入数据是什么结构？
——我处理完了把结果给谁、以什么格式给？
——中间需要等人确认吗？走代办还是走消息推送？
——如果出了分支条件，往哪边走？
这些东西，传统流程梳理根本不会覆盖到。
说白了，传统梳理给人看的，AI项目的梳理是给系统和Agent看的—— 它必须精确到能直接写成代码逻辑的程度。
两层梳理：业务节点建模 + 交互编排
实际操作下来，我发现AI项目的流程梳理分成两层。缺一不可。
第一层：业务节点建模
首先你还是按正常的方式来——价值流梳理，自上而下，从左到右，把每一个业务活动说清楚。
但这里有几个关键区别：
角色不只是"人"了。 你的泳道里必须同时涵盖三类角色：人、系统、Agent。因为在AI流程里，这三者之间的交互逻辑完全不同。人跟系统交互靠界面，人跟Agent交互靠对话，Agent跟系统交互靠接口——你得分清楚。
每个节点的输入输出必须是"系统事件"。 不是那种"收到需求后开始处理"这种抽象描述，而是真正能落到系统中的事件。比如"收到飞书审批单状态变更webhook回调"，比如"多维表格新增一行记录触发自动化"。
业务节点≠AI节点。 这一点很多人搞不清楚。你可能梳理出100个业务活动节点，但最终建模的时候，可能三五个业务节点聚合成一个AI节点。因为Agent可以一次性处理多个步骤，你得判断哪些节点可以合并、哪些必须拆开。
梳理完业务节点后，还远远不够。你接下来得出一张 "流程说明表"。
这张表比泳道图重要得多——它才是真正能指导开发的东西。每个节点必须标注清楚：
没有这张表，开发团队拿到一张泳道图根本无从下手。你说"用户提交需求"——提交到哪里？什么格式？触发什么动作？后面怎么流转？全是问号。
第二层：交互编排
第一层解决的是"流程怎么跑"，第二层解决的是"用户怎么用"。
不是所有节点都需要交互编排——有些节点纯粹是后台工程逻辑，跑完就完了。但 凡是涉及到人参与的节点，必须做交互编排。
你得搞清楚：
进入方式是什么？ 用户是通过一条IM消息进来的？还是通过待办列表点进来的？还是在一个中心化的对话窗口里被引导过来的？这三种方式，对应的产品形态完全不同。
首屏内容是什么？ 用户进来第一眼看到什么？需要给他展示哪些上下文信息？他才能做出判断和操作。
用户要做什么动作？ 是填表？是上传文件？是点一个"同意"按钮？还是跟Agent对话来输入信息？
操作完了之后呢？ 流程往哪走？需要通知谁？状态变成什么？
还有一个很容易忽略的问题—— 用户是否能通过连续对话改变工作流？
这是AI时代特有的交互模式。传统系统里，用户只能按照固定表单填写；但在Agent场景下，用户可能通过一轮对话就改变了整条流程的走向。这一点你不提前设计好，后面一定会出问题。
图形和表格必须结合
有人喜欢只画图，有人喜欢只填表。
我的建议是： 两个都要。
图是用来看全局的——让所有人快速理解整条流程的走向、分支、交互关系。
表是用来理细节的——每个节点的入参出参、触发条件、通知规则、字段字典，全部靠表格来承载。
光看图你会觉得"好像挺清楚的"，但一旦进入开发，全是漏洞。光填表你会觉得"都写了"，但缺了全局视角，容易顾此失彼。
谁来做这件事？
这里有个很现实的分工问题。
梳理业务流程本身——业务经理或者产品经理来做。他们最懂业务场景、最了解实际操作逻辑。
但是，做实现层的编排—— 一定要有技术背景的经理来牵头。
为什么？因为编排涉及的不只是"业务上应该怎么走"，而是"系统上能怎么实现"。事件怎么触发？接口怎么回调？数据结构什么格式？这些不是纯业务人员能判断的。
最好的方式是：业务经理先梳理出完整的业务流程和节点，技术经理在此基础上做实现编排，编排过程中发现不清楚的地方，再拉业务经理来澄清。
最终交付的东西应该包括：
——节点编排的所有细项
——交互规则（进入方式、首屏内容、操作动作）
——接口回调设计
——通知规则设计
——字段字典
没有这些东西，你根本编不好一条AI流程。
"AI能编排"——但你得有输入啊
最近经常听到有人说：现在AI这么强了，让AI去编排流程不就行了？
对，AI可以帮你编排。但关键问题是—— 你得先有输入。
AI不是你的业务经理，它不知道你的审批线怎么走，不知道你的ERP数据结构长什么样，不知道你的用户是从飞书进来还是从企微进来。
这些东西必须由人来梳理清楚，变成一份足够精确的输入文档，AI才能帮你做编排、做代码生成。
不是用了AI你就不用做前期工作了。恰恰相反， 用AI做流程开发的前期工作要求比传统开发更高 ——因为AI对输入的准确性和完整性要求极高。你给它模糊的输入，它只会给你模糊的输出。
选AI项目的四个维度
既然AI项目的流程梳理这么费劲，那怎么选项目就很关键了。不是所有流程都值得第一时间AI化。
我自己筛项目有几个核心维度：
满足这四个条件的项目，优先做。
注意第一点—— 必须在主价值链上。不是搞个智能办公助手、搞个会议纪要总结就叫AI项目了。真正有价值的AI项目，是切入到你公司的核心业务流程里，实实在在地替代或增强某段业务能力。
争取做一个"小的端到端"——从一个明确的起点到一个明确的终点，跑通一段完整的流程。别一上来就想做大而全的东西，先跑通一个小循环，积累经验。
写在最后
回过头来看，AI项目流程梳理的核心矛盾其实很简单：
传统流程梳理是给人看的，AI项目的流程梳理是给系统执行的。
给人看，模糊一点没关系，人脑会自动补全上下文。但给系统和Agent执行，每一个模糊点都会变成bug，每一个没定义清楚的分支都会变成故障。
所以我的建议是：
第一，承认AI项目的流程梳理比你过去做的要复杂得多，不要拿过去的经验套用。
第二，坚持两层梳理——业务节点建模先行，交互编排紧随其后。图形看全局、表格理细节，两个都不能少。
第三，分工要清晰——业务/产品经理负责梳理业务流程，技术经理负责实现编排，两个角色缺一不可。
第四，选对项目——在主价值链上、高频、规则清晰、实施难度中低。先做成功一个，再复制推广。
第五，别指望AI替你省掉前期工作——AI能加速实现，但 精确的输入只能靠人来做。你梳理得越清楚，AI帮你实现的质量就越高。
这不是一件容易的事。但它是AI项目能不能真正跑起来的分水岭。
做好了这一步，后面的开发、测试、上线都会顺畅很多。
做不好这一步，后面就是无尽的返工、扯皮、和"这个需求当时没说清楚"。
与其后面痛苦，不如前面多花点时间。