企业 AI 落地误区之一：用 Codex 或 Claude 搓个软件

你想要的是新软件，还是业务更流畅？

最近半年，不止一位老板问我：我现在的 ERP 和 CRM 不好用，你们能不能用 AI 帮我做个软件替换了？出发点能理解——原来的系统不好用，正好 Codex、Claude Code、Cursor 都能写代码，那就干脆重新做一个。听起来很顺。

我一般会先问一句：你想要的是一个新软件，还是想让业务更流畅？很多老板会停一下。因为这两个答案看起来差不多，其实差很远。做一个软件，只是对原有软件的一次升级；让业务少一点卡顿，重点是这件事每天在哪里发生、谁在处理、资料从哪里来、卡住时谁接手、处理完结果回到哪里——未必要重新开发软件。

很多问题不缺软件，缺的是工作现场里的连续动作：资料在群聊里，确认在会议里，表格在另一个文件夹里，审批人临时换了，老板一句话改变了优先级，员工又忘了更新状态。重新开发一个软件，并不会自动把这些工作搬进去——很多时候，它只是让企业多了一个需要维护的节点。

案例一 · 工程公司的发票审批：一张发票牵着一整条链路

按传统开发思路，这很容易做成一个发票管理系统：上传、识别字段、匹配 PO、走审批、进看板，演示一定不差。可真实问题从发票进入邮箱那一刻才开始：发票上有 PO，系统里没找到项目怎么办？一个 PO 对多张发票，哪种正常哪种重复？供应商名字写法不一致，谁来确认是同一家？金额和 GST 对不上，退回还是人工复核？项目经理换了，审批推给谁？

这些问题不在页面上，也不在识别模型里——它们散在邮箱、项目资料、PO 表、群聊确认、财务复核和审批记录之间。单独做一个发票软件，员工还是要把资料搬进去、把异常搬出来、再到群里问人，最后它很容易变成另一个表格。更有效的做法，是让 AI 直接进入原来的办公环境：发票进来就识别字段、查项目、关联 PO，把异常推给该处理的人，再把结果写回文档、表格或审批记录。发票审批要解决的，是发票进入公司之后，一路怎么往前走。

案例二 · 教育机构的招生转化：CRM 记录状态，机会不会自动往前走

做一个招生 CRM 逻辑很完整：线索池、客户状态、转化漏斗、报表看板。问题是招生工作并不只发生在 CRM 里——沟通在聊天工具里，材料在邮件和文档里，状态在 Excel 里，重点客户在会上讨论，不少判断只存在于顾问脑子里。一个客户卡住了，CRM 只显示“跟进中”，老板看到这三个字，还是不知道这个机会有没有危险。

重新做一个 CRM，最常见的结果是：顾问多填一个系统，老板多看一个看板，真实机会继续漏。更该做的，是让 AI 在顾问每天工作的地方帮一把：读 Excel 里的客户状态，看聊天记录有没有跟进，看邮件和材料缺什么，提醒下一步动作，把风险客户推出来。招生转化最容易漏的，是客户下一步该做什么，没有及时推到人面前。

案例三 · 门店管理：看板能展示异常，不能保证异常被处理

门店项目很容易做成漂亮系统：首页、图表、排名、日销趋势、库存异常，演示效果通常很好。但老板每天想知道的不只是哪个数字变红了，而是：这个异常谁看到了？谁处理？处理了吗？结果是什么？下次还会不会发生？看板最多告诉你问题出现了，它不能替你完成后面的动作。

门店运营更适合在日常办公环境里做闭环：日报生成后 AI 识别异常，异常推给负责人，处理结果写回日报，同类问题反复出现时整理给管理层。门店管理最怕的是：看板很漂亮，动作没人接。

把三个案例放在一起：三层拆解

发票、招生、门店，看起来是三个行业，落到现场都能拆成三层。

• 工具层：解决单点能力——识别一张发票、生成一份日报、写一段代码。AI 编程工具、大模型、OCR 都在这一层。它能让一个动作变快，但不会自动接住整条业务链路。
• 工作流层：企业的问题大多卡在这里——识别完的发票去哪查 PO？异常推给谁？结果写回哪里？这些发生在邮件、群聊、表格、审批、会议之间，工作流层要让 AI 在这些节点之间连续做事。
• 运营闭环层：决定 AI 能不能长期留在企业里——持续识别异常、推动处理、记录过程、形成复盘，让下一次处理更顺。帮你处理一次发票价值有限，进入运营才算数。
• 很多项目走偏的原因：把工具层的能力当成了落地的全部。看到 Codex 会写代码就想重做软件，看到大模型会总结就想做知识库——方向都可以做，但接不上工作流和运营闭环，最后就停在 Demo。

能快速 Demo，不意味着能进生产

AI 编程确实让开发变快了：以前一个小系统要排期，现在一个人几天就能做出像样的版本。但开发速度变快，不代表企业的工作方式自动变好。新系统上线后还有一连串问题：员工愿不愿意用？旧资料要不要搬？群聊里的确认、会议里的决策、审批任务日历还在原来的系统里怎么办？两年以后谁维护？

很多企业最后得到一个尴尬结果：原来的系统还在，新做的软件也在，员工夹在中间来回搬运——这是用更快的方式，增加了一个新的工作地点。个人软件因为 AI 编程多了百倍，企业软件也多了好几倍，但真正被大量用户长期使用而稳定下来的寥寥无几。企业软件要的是稳定、可扩展、好维护，而不是只有你一家在用的 DIY 工具。

企业需要的是办公环境里的 AI

企业每天的工作，本来就发生在办公协同软件里：人、组织、权限、文档、表格、任务、审批、日历、会议纪要和消息记录都在那里。它不只是聊天工具，更像企业日常运转的工作现场。AI 要发挥作用，就该进入这个现场——不是待在一个新系统里等员工打开，而是出现在员工本来就在工作的地方。

员工在群里发来一张发票，它能接住；顾问在表格里更新状态，它能看懂；纪要里出现待办，它能追踪；日报里出现异常，它能提醒负责人；结果出来，它写回原处。这也是我们把 Agent 框架放在办公协同软件之上的原因：办公软件提供工作环境，Agent 框架在里面部署能理解上下文、调用工具、推动任务的 Agent。传统软件让人进入系统；Agent 更应该进入人的工作流。

一个简单的判断标准

未来几年，企业会看到很多快速开发、AI 编程、Agent 应用方案。一个方案如果只讲页面、功能、模块、数据库、上线，却说不清怎么进入企业每天的办公环境、怎么连接人、文档、表格、任务、审批、会议和已有系统，那它大概率只是一个更快的外包开发项目：能产生 Demo，不一定能改变工作方式。

• 问题一：它是不是在企业每天工作的地方运行？
• 问题二：它能不能理解真实上下文？
• 问题三：它能不能调用已有工具？
• 问题四：它能不能推动任务继续往前走？
• 问题五：它能不能把结果沉淀回原来的办公环境？如果回答不上来，它很可能只是一个新软件；能跑通，才开始像企业里的智能体。