AI 项目最大的坑: 技术方案很完整,业务上没人用

AI 项目最大的坑：技术方案很完整，业务上没人用

一个 Java 程序员对 AI 落地与经营价值的思考

在四年多 Java 开发经验，参与过采购、库存、订单和供应商门户等系统建设之后，一个值得重新思考的问题是：

一个需求被按时完成，是否就意味着创造了价值？

过去，拿到需求后，常见的做法是迅速进入实现阶段：设计表结构、拆分接口、考虑缓存和消息队列，再完成开发、测试与上线。

这些工作依然重要。可靠的软件，离不开扎实的工程能力。

但在规划一个 AI Agent 项目时，需要在动手之前多问几句：

企业为什么要做这件事？业务真正卡在哪里？老板为什么愿意投入预算？系统上线后，谁会因此改变工作方式？这种改变能带来什么结果？

如果这些问题没有答案，即使技术方案很完整，也可能只是一个没有人持续使用的系统。

以下是正在实践和完善的思路，不是已经验证的企业收益。

01 技术方案之前，先回答“为什么值得做”

假设业务提出一个需求：

做一个库存分析助手，帮助采购人员发现积压风险，并给出处理建议。

从技术角度出发，很容易列出方案：

接入大模型，建立知识库，对接 ERP 和 WMS，再通过多个 Agent 分工完成查询、分析与报告生成。

但这些还不足以支持立项。

站在经营负责人的角度，需要判断：这个项目能改善什么问题？收益是否值得投入？为什么应该现在做？

企业关注的结果，通常落在几个方向：

资金利用率：更早发现积压风险，减少不合理采购，但“识别积压金额”不等于“释放现金”；

人效：减少跨系统导表、查制度、核对数据的时间，但必须把人工核验和纠错也算进去；

成本：减少仓储、紧急运输、重复采购和返工，但前提是问题真实存在且与系统环节有关；

收入：降低缺货风险，改善可售率和履约，但不能只追求降库存而牺牲销售。

原因不同，值得投入的技术方案就不同。

数据口径不一致，需要先治理数据；固定规则没有落实，可能应该完善业务系统；责任不明确，需要调整流程；如果大量时间消耗在跨系统查找、理解和整理信息上，AI 才可能在这一环节发挥作用。

程序员能够参与这些判断，就能更早发现无效需求，也能避免用复杂技术解决错误的问题。

02 把 Agent 放进企业的经营链路

以跨境电商为例，企业关心库存，是因为库存连接着采购支出、销售机会、仓储成本和现金周转。

库存过高，可能占用资金、增加仓储费用；库存过低，又可能导致缺货，损失销售机会，影响履约。

所以，“降低库存”本身并不是完整的经营目标。企业需要在资金占用、供货能力和利润之间作出取舍。

如果采购负责人提出：

欧洲仓有哪些 SKU 存在积压风险？结合在途采购、促销安排和采购规则，应该怎样调整？

回答这个问题，需要的信息可能分散在：

· ERP 中的采购单和在途数据；

· WMS 中的库存数据；

· 销售系统中的近期销量；

· 文档中的预算、审批和补货规则；

· 业务人员掌握的促销计划与特殊情况。

Agent 可以帮助获取和整理这些信息，调用程序计算指标，再形成带依据的风险提示和可选方案。

它的价值由此变得具体：

缩短从发现问题，到核实原因、评估方案和采取行动的时间。

如果随后减少了不合理采购，企业可能避免额外支出；如果积压库存被合理消化，并收到货款，才可能真正改善现金周转。

这里需要保持严谨：识别出的库存金额，不等于已经释放的资金；生成了一份报告，也不等于经营结果已经改善。

技术输出需要通过业务行动，才能影响最终结果。

03 从业务侧驱动开发，意味着改变提问顺序

在这样的项目中，工程师可以先与业务共同回答几个问题：

· 现在的流程是什么？

· 谁在做分析，要查几个系统，最耗时的是取数、核对，还是等待确认？

· 真正需要改善的环节是什么？是信息获得太慢，判断依据不足，还是行动缺少跟进？

· 系统输出由谁使用？谁负责核验建议，谁有权调整采购，谁负责记录后续结果？

· 怎样判断项目有效？是分析时间减少，风险处理更及时，还是采购与库存指标发生了可解释的变化？

这些问题会直接影响开发范围。

如果核心瓶颈是跨系统搜集信息，第一版就应该优先完成可靠的取数与取证；如果建议始终无人处理，则需要建立任务分派和反馈机制，而不只是继续优化报告文字。

从业务驱动开发，并不意味着程序员独自承担经营结果，更不意味着替业务拍板。

它意味着能参与问题定义、说明技术取舍，并在上线后继续关注实际效果。

04 生产级 Agent，需要清晰的职责边界

明确业务目标后，才进入架构设计。

可以这样划分职责：

· 模型理解问题、组织信息、生成解释；

· 检索系统提供相关文档与依据；

· 业务工具获取授权范围内的数据；

· 确定性程序完成公式计算和参数校验；

· 工作流控制执行顺序、状态和异常处理；

· 业务人员确认重要决策与经营操作。

一条完整链路可以是：

核 心 链 路

身份校验 → 意图识别 → 任务规划 → 权限与审批 → 工具执行 → 结果校验 → 回答或业务动作

简单请求直接走固定流程。复杂任务确实需要不同能力协作时，再引入多个 Agent。

例如，库存数据分析和采购制度检索可以并行执行，再汇总证据形成建议。

但金额计算、权限判断和重复操作控制，应该由可靠的程序承担。

让模型参与业务，不代表把所有责任都交给模型。

05 接入 MCP 服务，更要接入企业的权限规则

Agent 连接企业系统后，能否调用接口只是第一步。

批准接入一个 MCP 服务，并不意味着每个用户都有权访问它背后的全部数据。

同一个库存服务里，可能存在不同仓库、不同部门和不同敏感级别的数据：

采购人员可以查看负责仓库的库存数量，但查询采购成本需要额外授权；单次查询可以执行，批量导出需要审批；修改采购单则需要独立的业务确认。

因此，需要区分：

· 服务是否允许接入；

· 用户是否可以调用工具；

· 本次调用是否有权访问具体数据。

权限不足时，系统应该拒绝，或者创建待审批任务并暂停执行。

审批也不能只是一个“已同意”的状态。它需要绑定申请人、工具、操作类型、数据范围、用途和有效期。执行前再次校验，关键参数变化后重新判断。

还有一个边界容易被忽略：

允许读取企业数据，不一定意味着允许把它发送给外部模型。

企业可能允许在内部计算采购成本，却只允许将经过批准的汇总结果发送给指定模型服务。

这些约束需要落实在程序中，不能只写在提示词里。

06 结果可信，依赖可核验的来源

企业资料并不只有纯文本，还包括扫描件、表格、架构图、产品图片和会议录音。

处理这些内容，需要保留它们的结构和来源：

这段文字来自哪一页？图片对应哪段正文？表格数值属于哪一行、哪一列？录音内容位于哪个时间段？回答使用的是哪个版本的制度？

如果文档更新，历史回答仍应能够解释为什么采用当时的规则。

遇到无法完整解析的内容，也应该明确告知，而不是悄悄遗漏后显示“处理成功”。

模型的表达可能很流畅，但业务人员需要的是能够检查的依据。

特别是金额、数量、合同条件和审批规则，不能因为答案语气肯定，就省略核验。

07 生产级能力，体现在失败之后怎么办

真实环境里，接口会超时，模型会限流，文件会解析失败，服务也可能在任务执行中重启。

因此，需要明确记录任务是在排队、执行、等待审批，还是已经失败、取消或完成。

同时回答：

· 哪些错误可以重试？

· 重试是否会重复产生业务影响？

· 服务重启后从哪里恢复？

· 用户取消后如何停止后续任务？

· 超过时间、步数和费用预算后如何结束？

对于写操作尤其如此。

采购单提交超时，并不代表提交失败。业务操作可能已经成功，只是响应没有及时返回。盲目重试就可能造成重复操作。

这需要幂等控制、状态查询和必要的人工确认。

Agent 仍然要遵守业务系统原有的正确性要求。

08 每一次执行，都应该能够追溯

系统进入企业后，需要能从一次请求追溯整个过程：

谁发起了任务，访问了哪些数据，调用了什么模型和工具，执行耗时多久，出现了哪些异常，最终返回了什么结果。

工具调用还需要区分逻辑调用与实际尝试。

一次查询先超时两次，第三次成功，应记录一次逻辑调用、三次执行尝试和两次重试。只保留最终的“成功”，会掩盖下游服务的不稳定。

这些记录既帮助技术团队排障，也帮助企业判断：

哪些功能值得继续投入？哪些工具拖慢了流程？费用消耗在哪里？错误影响了哪些用户？

追溯也需要遵守权限和保留策略。凭证不能进入日志，敏感内容要受控保存，查看与导出记录同样需要授权。

09 用业务结果验收，而不只看系统是否上线

项目上线，是验证价值的开始。

第一轮试点，可以围绕几个维度评估：

经营指标受到市场、促销和人员等多种因素影响，不能把所有同期改善都归功于 AI。

更务实的方式，是先在一个团队、一个仓库或一个高频任务中建立完整闭环，再根据证据扩大投入。

写在最后：程序员的价值，也在这条链路里

AI 让一些能力更容易实现，也更需要判断：什么值得实现。

在继续打磨工程能力的同时，也需要理解企业的收入、成本、资金占用和业务风险，知道一项技术决策会怎样影响使用者。

这并不会削弱技术的重要性。

权限、事务、幂等、任务恢复和数据治理，恰恰决定了一个 AI 想法能否变成企业愿意依赖的系统。

需要逐渐建立这样的工作习惯：

从经营目标出发，和业务一起找到问题；用工程能力完成交付，再用事实验证结果。

企业需要的，从来不是一个会聊天的 AI。

而是一个能进入真实业务、推动行动、创造价值的 Agent。