企业IT需求排队，哪些内部应用适合先用AI开发？

企业的IT需求表里，有三个字挺容易让人误会：待开发。

业务部门看到它，会觉得是IT没空。现在AI都能做应用了，那些排了很久的需求，能不能先让AI做？

我觉得，当然可以试。但先别把“待开发”都当成一回事。

比如，有人想做个项目问题跟进工具，省得天天在群里问“这件事谁处理了”。有人想把采购订单、到货情况放在同一个页面看。还有人说，出库时库存扣减的规则也该改一改。

听着都像“做个系统”，可让AI接手以后，遇到的麻烦完全不一样。前两件事，可能缺的是一个好用的入口；最后一件事，改错一次，账就可能对不上。

要是真想让AI帮IT减轻排期压力，就得先想清楚：这三件事，该先做哪一件？

一、先做那些“大家知道怎么干，只是天天靠人催”的事

拿项目问题跟进来说。

客户提了一个问题，销售在群里转给项目经理。项目经理安排人处理，处理完再请销售回复客户。这套做法，大家其实都懂。麻烦在于，问题散在不同的群里：哪条还没回复，哪条已经处理却没告诉客户，往往要靠人翻记录。

这种需求，就比较适合先用AI辅助做一版。让提问题的人填清项目、问题内容和期望回复时间；处理人接到任务后更新进度；项目经理能看到还有哪些事没结。先在一个团队里试，发现字段不够、提醒发错人，还能对着原来的客户消息核查和修改。

织信的智能体对话开发可以按描述先生成数据表、工作流和看板。这里省下来的，主要是从“我们想要一个工具”走到“大家能点开看、能指出哪里不对”的时间。比如页面出来以后，销售才发现需要区分“内部处理完了”和“客户已经收到回复”。这两个状态以前靠人记着，做成应用就不能混为一谈。

图1：问题跟进流程示意。

类似的事还有普通办公设备报修、项目资料催交、售后问题分派、内部需求受理。你会发现，它们未必只有一张表，但有个共同点：谁提出、谁接手、怎样算办完，业务人员说得清楚。IT暂时排不过来，AI就能先帮忙把这段工作接起来。

不过，别光看名字。普通办公设备坏了，和生产设备故障导致停机，都可以叫“报修”。后者涉及停机、检修、复机等控制要求，就不能照前者的办法随手上线。

二、另有一批需求，不缺流程，缺的是把消息放在一起看

采购想知道哪些订单还没到货，通常得先查订单，再查收货记录，有时还要问供应商有没有改交期。数据可能都在，只是不在一个地方。于是每天导出、复制、对表。

这时能不能先做一个应用？能。但我建议先让它看见问题、提醒人处理，不要一开始就让它替人修改采购订单。

比如把订单号、约定交期、已收数量和未到数量放在同一个视图里。采购看见某笔订单快到期还没收货，可以去联系供应商，再由有权限的人在原系统里确认交期变更。新页面负责把线索找出来，正式订单仍由原系统管理。

为什么要分这一步？因为“我看到了异常”和“我已经把业务改了”，是两件事。前者可以先从一批订单试起；后者要考虑重复修改、接口失败、仓库已经收货却没及时同步等情况。

用织信做这页时，可以把查询、提醒和角色权限放在一套应用里考虑：采购看自己负责的订单，主管看整体进度。但数据从哪里来、多久更新一次，企业得先弄清楚。否则，采购只是从每天对Excel，变成每天看一张过时的看板。

图2：织信采购订单视图。

所以，报表、待办、异常提醒这类需求也值得排在前面，尤其适合那些“数据已有、员工还在到处找”的场景。前提是能找到可信的数据来源，并且有人负责处理看板上冒出来的问题。

三、有些需求，先拿AI做个样稿，比急着上线有用

比方说，销售想加一个折扣审批。这个需求听上去也不大：填折扣，主管点同意，不就完了吗？

可往下问两句，意见可能就不一样了。折扣按客户等级算，还是按订单金额算？老客户临时补单，沿用原报价吗？主管批准后，谁把价格写进正式订单？

如果销售、财务和管理层还没谈拢，AI可以先做个可操作的样稿，让大家看到不同规则会怎样影响审批。讨论时有个东西能点，比围着一句“优化报价流程”开会有用得多。

但样稿就是样稿。谁有权给折扣、最后价格以哪里为准，这些决定不能交给AI猜。规则还没定，就别把样稿接上正式订单，更别因为按钮已经能点，就告诉销售“系统做好了”。

这一类需求不是要从排期表里删掉。只是它眼下最该排的工作，不是开发，而是让业务负责人把分歧定下来。AI先把问题摊在桌面上，决定仍由人来做。

四、最容易看走眼的，反而是“只改一个按钮”

再看库存。有人提需求：出库时自动扣减库存。

页面上也许真就一个按钮。可同一张出库单点了两次，扣一次还是两次？货已经拣出来，单据却被撤回，库存怎样恢复？退回的货没检验，能不能直接算成可用库存？

图3：出库扣减时需要核对的例外情形。

这些问题不处理，按钮点通了也没用。仓库拿着单据说货已经出去了，财务看系统却是另一笔数，最后还得有人一张张核对。出库时省下几步操作，月底可能都得补回来。

这并不是说AI做不了复杂系统。织信也可以用数据模型、流程、脚本和接口来开发ERP、MES等复杂业务应用。只是这种需求要按正式系统项目做：拿真实的正常单据、撤销单据和重复提交记录测试，确认库存、业务单据和相关系统能对得上。AI能帮忙搭建，出了错账，还是企业自己得查。

人员薪酬、应收应付、生产报工也是同样的道理。它们不一定非要排到最后，业务急的时候甚至应该尽快立项；但不能因为生成页面变快了，就把核对规则、权限和异常处理的时间从计划里拿掉。

五、那下次排期会，怎么挑？

其实不用先给所有需求打一个复杂的分数。请申请部门找一笔最近发生的业务，把它从头讲到尾，IT跟着问三件事。

第一，今天这件事是谁在做？如果大家只是苦于反复登记、转发、催办，处理办法本身没什么争议，就先做一版，让小范围的使用者试。

第二，大家有没有在哪一步说法不一样？如果一问到退回、改价、代审，各部门答案就变了，先做样稿供讨论。这个阶段的交付物，是定下来的规则，不是上线通知。

第三，做错了会改动什么？如果会动库存、金额、工资，或者把敏感资料开放给原本看不到的人，按正式项目安排验证。它可以用AI开发，但不能用“先试试”的标准放行。

我会把项目问题跟进、普通内部报修、资料催交放进第一批；把已有数据上的查询和提醒作为另一批候选；业务规则还没谈妥的先做原型；涉及正式账和敏感权限的单独立项。名单不是固定的。同一个“报修”需求，换了设备和使用场景，就可能换一条路。

最后

AI让企业更早看到一套能用的应用，这是好事。业务不用等到几个月后才发现“原来我想要的不是这个”，IT也能把时间用在更值得认真检查的地方。

可排队的需求，并不是每一项都在等程序员。有的在等一个入口，有的在等部门把话说到一处，还有的在等一轮不能省的业务验证。

下次再看到“待开发”，先别急着问AI几天能做完。问问申请人：这件事该怎么办，大家商量好了吗？做错了，会不会改掉正式的账？只是缺一个记录和协作入口，可以先让AI做一版。规则还在争，或者会动到正式交易，就别把“生成得快”当成“可以直接上线”。