把一份业务需求交给AI：从生成初版到验收，需要验证什么？

以前做一套内部系统，需求写得不够细，项目很容易停下来。

开发人员会回来问：审批被退回后，申请人还能改什么？负责人换了，待办交给谁？一笔业务办完了，谁有权把它撤回？

问多了，业务部门嫌慢。可这些问题总得有人回答，系统才能照着办。

现在不一样了。把需求交给AI，表单、流程、列表可能很快就有了。过去会让项目停下来的问题，不一定消失了。它们也可能被AI先填上一个答案，藏在看起来已经做好的应用里。

做系统的速度上来了，企业商量规则的速度却没跟着变。这就是我觉得“AI生成初版”最值得认真对待的地方。页面能打开、按钮能点击，只能说明它做出了一种处理方式。至于企业要不要按这种方式办事，还得往下看。

图1：初版与规则确认（示意）。

一、一个能跑通的流程，可能替你做了好几个决定

拿费用报销举例。需求方说，员工上传票据，主管审批，财务复核，通过后付款。

AI照着做出申请表、审批流和待办列表，业务人员点了一遍：能提交，能审批，财务也能看到。第一眼，很难说它哪里不对。

可一笔报销只要被退回，事情就没那么简单了。

主管认为金额填错，让员工修改。员工改完后，是回到主管重新审批，还是接着走到财务？如果财务发现同一张票据已经用过，这笔申请该退给员工、退给主管，还是直接作废？已经付款的记录，发现录错了金额，又能不能在原单上改？

这些听起来像细节，其实每一个答案都在分配责任。允许员工改已审批金额，主管批准的还是不是当前这笔钱？允许删除已付款记录，财务凭什么回头查这笔账？

最麻烦的情况，不是AI明摆着做错。它可能选了一种很顺的做法：退回后允许修改，修改后继续往下走。大家试用时也觉得省事。直到某天要解释“谁批准了修改后的金额”，才发现系统里找不到这个决定。

所以，别把“流程能走通”当成“规则已经谈妥”。前者AI能帮你很快做到，后者仍是企业自己的事。

二、初版出来，先找那些没人说过却已经存在的规则

这是不是意味着，交给AI之前必须写一本完整的需求说明书？也不用。很多规则，光靠开会想不全，看到初版反而更容易讨论。

比如刚才那张报销单。让主管、财务和经办人一起看，他们未必先争论页面颜色，反倒会指着同一个“退回”按钮说出三种理解。主管觉得退回就是重新审批；财务觉得退回只是补票据，不该再改金额；员工则以为退回后整张单都能重填。

这时候，初版的价值出来了。它让原来藏在各人脑子里的规则，变成了可以指给别人看的字段、状态和动作。讨论也不必停在“这个流程不太对”，而能落到一句具体的话：财务退回补票据时，金额不得修改；金额要改，就重新提交审批。

图2：退回规则分歧（示意）。

还有些问题，AI追问得再仔细也不会自动有答案。如果主管和财务本来就没统一口径，它无法替企业决定谁的做法有效。与其在提示词里反复要求“考虑全面”，不如把分歧留下来，请有权限的人定规则，再让AI或开发人员修改初版。

像织信的智能体对话开发，可以根据描述生成数据表、工作流等应用内容，也支持按后续指令调整。动手构建前，AI还会给出一份执行计划，供人确认。这些能力缩短了从想法到可操作初版的距离。可你确认“先建一张报销表”，并不等于你确认了“退回后可以修改已审批金额”。改起来越快，越要问清这条修改是谁提的、谁同意的。

三、验收时，别只让它处理一笔听话的业务

规则谈清了，接下来怎么验？

还是这套报销应用。拿一笔票据齐全、金额无误的申请，从提交走到付款，只能证明顺路能走通。真正要试的，是它碰到变化之后，能不能继续按商量好的办法办事。

找一笔被主管退回的申请。员工修改金额后，系统有没有重新送给主管？再找一笔财务只要求补票据的申请。员工补了附件，原金额和主管审批结果有没有被悄悄改掉？最后，拿一笔已付款、后来发现录入有误的记录，看系统会让人直接抹掉旧单，还是留下原记录，并由有权限的人按约定处理更正。

图3：业务记录验收（示意）。

我更愿意把这些叫作“拿业务记录问系统”，而不是在验收会上挨个点按钮。每问一次，都把原记录、操作前后的状态和预期结果摆出来。对不上时，也别急着说“AI不行”：有时是规则没人定，有时是规则定了却没配进去，还有时是权限放错了人。原因不一样，返工的地方也不一样。

别忘了换账号再试。员工能否看到同事的票据？主管调岗后，未处理的申请落到谁手上？财务能查看凭证，不代表所有人都能看。界面上看不到某个按钮，也不能证明后台就限制了这项操作。这些都要用实际角色和记录核对，不能凭页面长相猜。

四、验收通过，也要说清“通过到哪一步”

几笔测试申请都对了，“可以用了”这句话很容易说出口。可要是有人追问一句“给谁用”，答案可能就不一样。

在小组里继续试，和让全公司正式报销，是两回事。前者可以让使用者盯着每笔异常，边用边改；后者要面对真实票据从哪里来、员工调岗后权限怎么变、通知失败谁来查。测试数据里从没出现的问题，正式业务会碰到。

下一步可以先让一组实际使用者处理真实业务，把每次退回、修改、更正都留下记录。业务负责人确认规则，财务核对金额与凭证，IT或实施人员查权限和运行结果。发现问题，先修，再用此前通过的记录重测一遍。新规则别把原本正常的流程也改坏了。

图4：使用范围逐步扩大（示意）。

在织信或其他企业级AI开发平台上，初版可以越改越接近业务。可“能试用”“能在一个部门使用”“能正式处理关键业务”，不是同一句话。每往前走一步，都得知道数据从哪里来、谁能改、出了错怎么找回原记录。说清这些，业务部门才知道什么时候能交给更多人用，IT也知道出了问题该从哪里查起。

说到底，AI让人更早看见系统的样子，也让那些没拍板的事更早有了一个看似确定的答案。

下次拿到AI做的初版，不妨先问一句：它替我们决定了什么？确认过的留下，有争议的拿回去商量，再用真实业务记录反复试。

系统可以让AI先搭起来。至于以后公司是不是照这个办法办事，仍得由公司里的人说清楚，并且拿得出记录，证明它经得起下一笔业务。