流程梳理不是开工前的杂事：写不下来的流程，自动化不了

写不下来的流程，自动化不了

我接手自动化项目时，第一份要的东西不是系统账号，是流程的文字版本（我交付这类项目的方式），而多数时候它并不存在。这不是文书问题：一份写不出来的流程，本质上是一个还没被做出的决定，而机器执行不了一个没人做过的决定。

写不下来的流程，自动化不了；把它写下来的那一遍梳理不是开工前的准备成本，它本身就是项目的第一份交付物——后面每一步能不能验收，都挂在这份东西上。

同一套剧本我看过五遍：到第三周，工程师总会问那个没人答得一致的问题——发票进来但没有采购订单，算不算例外。

模型能不能自己把模糊的流程吸收掉

最常见的反驳是：模型能像新来的同事一样，从日常行为里学会这套流程。它能学会语言，学不会共识。

请两位老手各自独立判断同一个决策点上的三十条历史案例：有明文规则的地方判断一致，靠默契的地方就会分叉，分叉恰好出现在要紧的那几种——涉及指定客户的例外、刚越过阈值的金额。模型能给出一个合理的判断，但那是“一个”合理判断，不是“你们公司”的判断。

代价更贵的地方在后面：没有写下来的规则就没有“正确”的定义，没有正确的定义就做不出评测集，只能靠盯着它跑，于是组织说不清一套 AI 工作流究竟准确还是只是流畅——演示里这两者长得一模一样。

写下来，具体写到什么程度算够

不是六十页的流程地图，是每个步骤一页纸、八个字段填满，再加一张例外清单，每条例外旁边写频率估计。

我用的门槛是：判断规则如果写不成三句话、且让两个不同的人读成同一个意思，这个步骤就该先跟握着这份判断的人聊一次，而这次聊天属于第一周，不是测试阶段。

写下来的流程，是评测集的前身

要测一套 AI 工作流，你需要一批带正确结果的历史案例，而正确结果由规则定义。规则写出来，才有人能翻上个季度的案例，在每个决策点上标三十条，并故意把那几条大家记得很别扭的塞进去；规则没写出来，标注就退化成两个评审人互相不同意——而那个不同意本身就是结论。

两个人各自独立标注、对上了二十一条：花了几天、没花软件钱，却暴露出试点要三个月才会暴露的事实——这个流程没有稳定答案，任何自动化都没法拿它做验收基准，而分歧集中的那几类例外，就是接下来要先写清楚的。完整推理我写在流程文档为什么是 AI 项目可评测的前置条件里。

一次梳理要花多少时间，折成钱是多少

数字是我在深圳做项目的口径，换成你自己的薪资表，不要照抄。

• 流程负责人（十到十四个步骤）：三到四次九十分钟的会加会后复核，三十五到五十小时。
• 分析师取历史案例并整理成表：十五到二十五小时。
• 两个评审人各标三十条案例：合计约八小时。

按运营负责人全成本四万元一个月、分析师三万元一个月、每月一百七十四工作小时算，约合每小时二百三十元和一百七十元：四十小时、二十小时、八小时分别是九千二百、三千四百、一千三百六十，合计约一万四千元，还没聊到软件。同一个项目按两名工程师做六周算，这笔梳理不到总成本的十分之一，却决定了剩下十分之九里装的是什么。梳理做三个月只会得到一份没人照着建的文档，做三天写下的则是最顺的那条路径——会议排紧、开工日期先定，让文档有一个等着用它的消费者。

哪些流程要写全，哪些只写边界

不是每个步骤都值得走完这一遍。判断依据只有一条：变化在这件事上是缺陷，还是价值。

这套说法在哪些地方不成立

写下来的过程会改变流程本身：有人记录时，人会顺手整理自己的活，我有两个项目的周期时间在软件上线前就明显下降，这让后续收益的归因变得不干净——两种原因各占多少，我给不出拆分。

文档还会过期：没有具名的所有者和复核日期，一个季度后它描述的就是一个不存在的流程，而过期的文档比没有文档更危险，因为建设团队会信它。还有些流程不该被完整写下来：价值在资深的人对少数几个案例的判断上时，自动化准备工作、把结论留给人更诚实。

周一可以做的三件事

挑量最大、对判断方差容忍度最低的那条流程，约上真正做这份工作的人开两次九十分钟的会，把每个步骤的判断规则写成三句话。再找两个人各自独立标注每个决策点的三十条历史案例，数他们一致多少条：几乎全一致，你就有了规格、评测集和一条能拿去批预算的理由；三分之一不一致，你找到的才是真正的项目，而它从来不是技术问题。把这份写下来的东西当成自动化项目的第一个交付物，并给它一个日期。如果有人管这叫开销，问他一句：机器到底要做哪个决定。