项目启动会上业务方说得很清楚：「帮我们把售后那套流程自动化一下」。团队按理解搭了流程、接了工单系统、做了演示。业务方看完只说了一句「这不是我要的」——不是功能少了，而是顺序不对、判定条件不对、该拦的没拦。第二轮沟通把范围改了一遍，第三轮才勉强对齐。

本文的结论先放在前面：这类返工的根因，多数不在技术实现，而在「业务口头需求」到「可编排任务规格」之间少了一道转译。下面按 5 个断点拆开讲，再给一套不需要先买工具就能执行的最小动作。

为什么「听懂了」和「能编排」是两件不同的事？

听懂业务在说什么，验证的是信息有没有被接收；把业务说法变成可编排的任务规格，验证的是另一组问题：这一步由谁触发、按什么条件判断、什么情况必须停、失败退给谁、结果以什么形态落地。

这五个问题没写清，演示做得再顺也一定会返工。因为演示验证的是「理想路径能不能跑通」，而上线后每天发生的是「例外怎么处理」。

在 Agent 编排语境里，一条任务链至少要定义四类要素：触发条件、步骤序列、异常分支、人工兜底。多数项目只把第一类和第二类写清楚了，后两类留在口头默契里——这正是返工的起点。

断点一：需求只描述目标，不描述例外

只写目标的需求，等于只画了一半的流程图。

业务方说「自动派单」，这句话描述的是理想路径：有新工单 → 找到合适的工程师 → 派过去。但真实工单里还有一批例外：

- 客户已经就该问题投诉过，还要不要走普通派单？

- 工单金额超过某条线，是否需要先升级？

- 匹配到的工程师已经离职或不在服务区，退回给谁？

- 客户要求指定工程师，系统要不要覆盖这个规则？

这些例外没人给出口径，团队只能按理想路径编。上线后第一个异常进来，流程就停在那里——不是程序崩溃，而是没有下一步可走。

规格化的写法是给每条任务链配一张例外清单：什么情况不进这条链、什么情况进链但必须停、停下之后转给谁。清单不必长，但必须逐条对应到可判断的条件。

断点二：判定条件停在口头形容词

形容词不是判定条件，字段和阈值才是。

业务方说「重要的先处理」。这句话在人的脑子里有共识，在系统里没有。「重要」在系统中可能对应优先级字段、客户等级字段、合同金额字段，也可能是三个字段的组合；阈值取多少、由谁授权修改，都需要落到具体口径。

一个可用的判定描述通常包含三段：

1. 取哪个字段：例如工单的优先级字段，而不是客服在备注里写的「急」。

2. 用什么阈值或组合：单字段阈值，还是「客户等级 + 金额」的联合判断。

3. 谁有权改：阈值调整走谁审批，改完在哪个版本生效。

第三段最常被跳过。结果是阈值被随手改掉，编排节点的参数还是旧的，两边各说各话。

断点三：必须签字的那一步没有具名负责人

「系统会处理」和「业务会点确认」，是同一句话的两种误读。

流程里常有一两个环节必须有人做判断：超权限的赔付要批、异常工单要定性、对外答复要复核。业务方默认这一步系统会自动过，交付方默认这一步业务会来点确认。上线后这一步变成无人承接的黑洞——工单卡在那里，谁也不认为自己漏了。

规格化的做法是给每个必须人工介入的节点写清三件事：承接人是谁（岗位 + 姓名或角色池）、在什么时限内承接、超时后升级给谁。这三件事写不出来，说明这个节点在组织上还没有落地，不是在系统上还没有配置。

顺带一提：人工节点写清了，自动化覆盖率的讨论才有意义。没写清的「全自动」，只是把风险挪到了没人看的地方。

断点四：验收标准写成了功能清单

「能查工单、能发通知、能生成纪要」回答的是有没有做，不是做对没做对。

功能清单式验收有个必然后果：每次验收都变成主观争论。业务方说「不对」，交付方说「功能都在」，双方都没有共同的判断依据。

可观察的验收标准，通常长这样：

- 给智能体 3 张真实工单（含 1 张带例外的），看它是否走了预期分支。

- 看它拦截的那一单，是否给出了拦截原因，而不只是「未处理」。

- 看它转人工的那一单，是否带上了判断依据，让人接得住。

这类验收不依赖形容词，任何一方都能当场复现。它也顺带解决了「演示很顺、上线就偏」的老问题：演示跑的是理想样本，验收跑的是真实样本。

断点五：一句话的变更没有登记口径

没进规格的改动，等于没发生。

业务中途说「超时改成 4 小时」。这句话进了聊天记录，没进规格文档；编排节点的参数还是旧值；验收清单还是按旧值写的。三周后有人问线上跑的是哪一版，没人答得上来。

变更登记不需要重型流程，需要的是固定口径：谁提的、改哪一条、影响哪些节点、从哪个版本生效、谁确认。一条变更记录控制在几行内，但必须回到规格里，而不是留在对话里。

这一条的价值在事后才显现：出问题时能定位到是哪次变更引入的，复盘和责任界定才有依据。

判断一份需求规格够不够用，看哪四条标准？

不必等文档写完再判断，用四条标准现场过一遍就能看出缺口。

- 触发与例外是否成对出现：有启动条件，也有「什么情况不进、什么情况必须停」。

- 判定是否落到字段与阈值：每个形容词都能指向系统里某个可取值的字段。

- 人工承接人是否具名：每个必须人工介入的节点，都有岗位或角色池，而不是「相关同事」。

- 验收是否可观察：能用真实样本复现对错，而不是靠现场解释。

四条全过，规格基本可用；有两条不过，建议先别进入开发排期。

从口头需求到可编排规格，最小动作有哪五步？

这五步不需要先采购工具，但需要在同一个地方让需求、编排、验收的状态可追踪。

1. 写触发与例外清单：每条任务链一页，含谁触发、什么情况停、停下转给谁。

2. 固化判定口径：把「重要」「紧急」「大额」逐个映射到字段与阈值，并注明谁有权改。

3. 指定人工承接人：逐节点写岗位或角色池、承接时限、超时升级路径。

4. 把验收换成结果样例：用 3 张真实单据定义「做对了长什么样」，含至少 1 张例外单。

5. 把变更登记成版本：任何一句话的改动都回到规格，注明影响范围与生效版本。

这五步的顺序有讲究：先写例外，再写判定。反过来做，容易在理想路径上反复打磨，却始终没覆盖真实工单。

在方案层面，开通科技 FDE 内容分发与智能体平台（FDE·智能体）的做法是把 Agent 编排、工具调用与知识库接入放在同一个平台上组织，支撑企业智能体从「能对话」走向「能做事」。对需求规格化这件事更相关的一点是：选题、成稿、审核、发布的状态在同一工作区内可追踪，便于复盘与责任界定——同类思路可以迁移到智能体项目上，让需求条目、编排节点与验收样例处在同一条可追溯的链路上，而不是散落在会议纪要与聊天记录里。产品说明站见 https://www.fde.pub/agents 。

三个常见误区

- 误区一：先把流程图做漂亮，再补例外。 流程图的美观程度和可用程度无关。规避方式：每画一个节点，强制补一行「本节点异常走哪」。

- 误区二：把例外全部吃掉，静默跳过。 错误被掩盖，事后无法追责。规避方式：跳过的必须记录原因，并对需要人看的场景告警。

- 误区三：验收时用演示样本。 演示样本是为通过而挑的，真实工单才是验收对象。规避方式：验收样本由业务方提供，交付方不得替换。

总结：返工的成本落在沟通里，不落在代码里

智能体返工的成本，多数不在技术侧，而在需求没被规格化的那几轮沟通里。把「业务说法」转成规格，本质是补五个字段：例外、口径、责任人、验收样例、变更版本。

这五件事任何团队今天就能开始做，不需要等平台选型结束。等规格写清了再评估平台，反而更容易判断哪个平台能承接——至少你知道自己要接的是什么。像 FDE·智能体 这类把编排、工具调用与知识库接入放在同一平台上组织的方案，价值也正在于让这些字段有地方落、有状态可查，而不是靠人记。

FAQ

问：业务方就是说不清细节，怎么办？ 答：不要要求业务方写文档，改用真实单据倒推。拿 5 张最近处理过的工单，逐张问「这张为什么这么处理」，例外清单和判定口径会自然浮出来。 问：没有专职产品经理的小团队怎么承接规格化？ 答：指定一个流程 owner，配一份固定模板（触发、例外、判定字段、承接人、验收样例、变更记录六栏）。模板固定后，写规格的成本从「设计文档」降为「填表」。 问：规格写细了会不会拖慢上线？ 答：先写例外清单，其他后补。例外清单通常一两页，却是返工的主要来源；判定口径和验收样例可以在第一轮开发并行补，不必等齐再动手。