AI搭出来的系统，怎样才算能交付？

用AI搭出一套系统之后，企业接下来该做什么？

要做哪些功能，已经描述清楚，AI也生成了页面、数据表和业务流程。几个主要功能都能操作了，大家自然会关心：现在能交给员工用了吧？

要回答这个问题，还得看看：实际业务中可能遇到的情况，系统有没有考虑进去。

比如，你让AI做一个订单系统，要求“支持订单取消”。系统做好了，点击取消，订单状态也变了。这时，你可能觉得取消功能已经做好了。

可客户下单100件，仓库已经发出60件，客户现在要求取消剩下的40件，系统该怎么处理？

如果这些情况没有讨论过，AI也可能生成一种处理办法，比如直接修改数量，却没保留取消记录。按钮能点，不代表处理方式符合企业要求。

AI能把应用做出来，不代表企业已经把应用里的业务规则确认完了。

应用生成得越快，越要分清：哪些处理是企业确认过的，哪些只是开发时暂时采用的做法。

一、功能做完了，业务规则未必都定好了

假设这张订单只有一种产品，双方已经同意取消剩余40件。为方便讨论，先不考虑退货、预付款和取消赔偿，剩余货物也尚未进入拣货、装车等环节。

这类已审批、已部分履约的订单，需要保留原始订单和变更依据。这里采用一种设计：原订购数量保留100，已发60，取消40，待发数量为0，避免覆盖数量后查不清变化过程。

真正取消前，系统还要重新核对这笔订单剩余多少件未发货。如果审批期间又发出10件，就不能继续取消40件，也不能擅自改成取消30件，而应停止本次修改，请业务人员重新确认。如果已经开始拣货或装车，还要先与仓库确认能否停止发货，再处理取消申请。

数量核对上了，还要看库存。如果这40件已经预留了库存，就要解除对应的占用，否则别的订单仍然用不了这些货。解除占用只是取消预留，不是增加实物库存。

如果销售看到订单取消成功，仓库却发现库存仍被占着，就要查清楚：是已经约定的释放动作没有执行，还是需求里根本没有说明库存该怎么处理？这两种情况，解决办法不同。

规则没有执行到位，和规则本身没有定好，需要区分处理。

已经确认的规则没有正确执行，需要实施或开发人员排查配置、程序和接口；规则本身尚未确定，则需要业务负责人作决定。数量、库存该怎样变化，应先由相关部门确认，再检查系统。结算金额和应收何时确认，则要按合同与财务规则处理，不能仅凭订单状态推断。

在织信的智能体对话开发中，可以先生成数据表、工作流、脚本，再根据反馈调整。企业可以边看应用边澄清需求，但尚未确认的规则要标出来，不能默认业务负责人已经同意。

二、同一条规则，换个入口还管用吗

规则确认后，可以在织信里用订单变更表记录取消数量、原因和客户确认依据，通过关联记录字段指向原订单。如果一张订单包含多种商品，还要明确取消的是哪种商品、多少件。关联记录能说明这次申请对应哪张订单，但不能代替修改权限和业务规则的检查。

接着配置审批和自动化：销售提出申请，负责人审批后，由配置好的自动化执行修改。配置更新步骤时，要明确修改哪张订单、哪条商品明细，以及哪些字段改成什么值。漏掉筛选条件，可能误改整张表的记录。

这条流程跑通，还不能说明所有入口都受到了约束。

假设销售不能直接修改已审批的原订购数量。页面设成只读后改不了了，批量导入、接口或后台任务会不会仍能覆盖这个数字？

再看数据是否合理。销售提交取消申请时，可以配置规则，检查取消数量是否超过剩余待发数量。换成其他方式修改，同样的检查还会不会执行？验收时要按实际开放的入口逐一测试，补上遗漏的控制，或关闭不需要的修改入口。

权限检查也一样。除了检查员工能改什么，还要检查外部系统和后台任务能改什么。销售不能直接取消订单，也不能通过调用一个权限更大的自动任务，绕过审批完成取消。

最后查记录：谁批准，改了什么，修改前后各是多少。织信的变更日志需要相应配置，表单与自动化修改的记录方式也有区别。不能只看到“审批通过”，就以为实际修改都留下了记录。

平台支持某项能力，是选型依据；当前应用已经正确使用这项能力，才是交付依据。

三、AI上线后还做不做判断，验收方法不一样

有些系统只在开发时用AI。搭好以后，订单计算、审批流转都按确定的程序执行，不需要AI每次重新判断。这类系统要检查的是生成的程序和配置是否正确，不能因为代码由AI生成，就认定它每次运行都会变化。

如果系统上线后还要调用AI理解邮件、识别单据、提出处理建议，就得再验一件事：它有没有正确理解业务要求。

把前面的订单换一种情况：发出60件后，客户没有提出取消，而是发来一句话：“剩下的40件先不要发，交期下周再确认。”

验收时可以把这句话作为测试样本。假如系统把“暂缓发货”误判为“取消剩余数量”，后面的计算可能全部正确：取消40，待发0，解除库存占用。但整件事从第一步就理解错了。

因此，验收这类功能，要把“理解客户意思”和“执行系统操作”分开检查。测试时，既要有要求明确的客户消息，也要有说得含糊、信息不全，或客户随后改变要求的情况，看系统会作出什么判断。

涉及取消、金额或重要交期变更，可以先把AI建议写入织信的待确认申请，由指定人员审核后再修改正式订单。审核人要能看到客户原文、原订单和建议修改值，不能只有一个“同意”按钮。哪些操作可以进一步自动执行，应根据场景测试和使用结果决定。

AI也可以帮忙编写测试，但正确答案要由熟悉业务的人确认。如果写系统和编测试都沿用“先不要发就是取消”的错误理解，测试通过也证明不了业务处理正确。

四、测试通过，为什么正式使用还会出问题

前面检查的是业务处理得对不对。接下来还要看：员工多了、订单多了、其他系统接进来了，它还能不能正常运行？这也是传统企业软件实施中经常需要面对的问题，已有的实施经验值得参考。

微软的实施指南记录过一个制造企业案例：早期用少量数据、部分接口测试，表现正常；接近实际规模后出现性能问题，团队却寄希望于正式环境更高的配置。上线第二天，服务系统频繁通过接口查询库存、创建销售订单和开票，影响了正常交易、发货和车间物料流转，最终仍要调整两套系统交换数据的方式。

这个案例与AI生成无关，但它解释了一个普遍问题：测试通过，只能证明系统在被测试的条件下表现符合要求。

除了按实际业务量测试，还要检查同时操作会不会改错数据。例如仓库发货与销售取消同时发生，不能一边发出了货，另一边仍把原先剩余的40件全部取消。

网络超时同样值得测试。仓储系统已经接收了发货请求，回复却没传回来。操作人员看到失败提示，再点一次，系统会查询原请求的结果，还是又创建一张出库单？

页面提示失败，不等于业务没有执行。要核对实际生成了几张单据；同一取消申请重试，也不能重复累加取消数量、重复释放占用。

还要测试只成功了一部分的情况。如果库存预留由另一套仓储系统（WMS）管理，订单系统就需要通过接口通知它，解除这笔订单对应的库存占用。订单修改成功，库存释放却失败时，应留下待处理状态和失败记录，安排重试或人工处理；无法确认上次结果时，先查清状态，不能盲目重发。审批通过、订单修改成功，都不能单独证明整笔取消业务已经完成。

测试范围应结合使用规模和错误后果确定，内部登记应用不必照搬集团订单系统的测试要求。但可能造成损失的情况要测到。出错后由谁核对单据、哪些操作需要补做、错误数据怎样纠正，也要提前安排好。恢复数据库，不会让已经发出的货自动回到仓库。

五、能交付，还要能继续修改

说到这里，可能有人担心：确认规则、检查入口、准备样本，AI省下的时间是不是又花回去了？

这些检查本来就是企业系统交付的一部分，无论用AI还是人工开发，都需要做。AI缩短了搭建时间，业务确认和验收仍然要完成。

为了避免每次修改都从头检查，可以保留确认过的规则和测试样本，例如正常发货、取消剩余数量、暂缓发货、重复提交。每个样本写明输入、预期结果和适用条件，供后续使用；业务规则调整后，相应的预期结果也要更新。

以后增加折扣功能，除了检查新价格，还要重新核对相关的审批金额、结算与统计结果。这就是回归测试：确认新改动没有破坏原来已通过的功能。

在织信上完成开发后，接手的人应该找得到：取消数量在哪里检查，谁负责审批，库存释放失败后在哪里查原因。这些配置为什么这样做，也要有说明。以后规则变了，他才能知道该改哪里、改完要测哪些业务，不必从头翻聊天记录、重新问一遍。

交付前，不妨让接手的同事在测试环境做一次约定范围内的小调整，再验证相关样本。这比一句“后续支持维护”更能说明交接是否完成。

最后，把本次可以投入使用的范围写清楚：哪个版本、哪些角色、哪些业务、什么数据规模，尚有哪些限制，由谁维护。

内部试用通过，不等于可以全面上线。新增业务、接口或重大变更，还要补充验证。错账、重复发货、越权修改等关键问题，也不能拿其他功能通过的数量来抵消。

交付可以分阶段，但每一阶段允许企业拿它做什么，必须明确。

最后

从织信的角度看，AI让企业更早拿到应用，也让业务人员能更早验证自己的需求。开发速度的价值，要在员工真正使用之后体现出来。

那么，AI搭出来的系统，怎样才算能交付？

在约定的使用范围内，业务规则已经确认，系统按这些规则通过了验收，异常有人处理，后续有人接手维护，企业才有依据批准它投入使用。

交到企业手里的，应当包括可运行的应用，以及确认过的业务规则、验收结果、已知限制和维护安排。具体交付物与验收手续按项目约定落实。这样，接手的人才知道系统可以用来做什么，哪些情况需要人工确认，出了问题该找谁。

点击文末“阅读原文”，申请体验织信。从一项需要改进的业务开始，试试用AI搭建应用，再按文中的方法验证它是否满足实际使用要求。