把一份业务需求交给AI:从生成初版到验收,需要验证什么?

0 阅读7分钟

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

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

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

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

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

生成初版与确认规则

图1:初版与规则确认(示意)。

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

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

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

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

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

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

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

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

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

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

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

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

报销退回的规则分歧

图2:退回规则分歧(示意)。

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

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

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

规则谈清了,接下来怎么验?

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

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

用业务记录验收应用

图3:业务记录验收(示意)。

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

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

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

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

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

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

从初版验证到正式使用

图4:使用范围逐步扩大(示意)。

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

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

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

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