一位从业者在 300 多次行业交流后发现：过去一年半里见到的 AI 项目全部失败。InfoQ 数据也显示 80% 以上的企业 AI 项目卡在 PoC。问题不在模型能力，而在企业根本没准备好"跑软件项目"。
2026 年 7 月 18 日，一篇题为"AI 狂热正在摧毁全球决策能力"的博文在 Hacker News 登顶。作者 subset 的创始人在过去一年半里与 300 多位企业决策者交流后，得出了一个让人不安的结论：他见到的所有 AI 项目，全部失败——不是大部分，是每一个。
几乎同时，InfoQ 在 AICon 深圳站披露了另一组数字：超过 80% 的企业 AI 项目停留在 PoC 或局部试点阶段，始终无法进入生产环境。这两组数据来自不同渠道、不同观察角度，却指向同一个事实：企业在大模型上砸了钱，但绝大多数还没看到回报。
我们在蓝曜炬辉接触的企业客户中，这些失败的"症状"几乎如出一辙。之前我们系统梳理过 AI Agent 走不出 PoC 的五个工程死结，而这篇文章试图回答一个更根本的问题：如果你的团队正在推一个 AI 项目，怎么避免成为那 80%？
subset 创始人在文章里写了一句很关键的话："失败通常与 AI 本身无关，而是因为公司在有效运行软件项目方面存在致命的缺陷。AI 项目承受着普通项目所有失败模式的影响，而且你即使把所有事情都做对了，仍然可能因为该方法的新颖性而失败。"[1]
他举了一个具体的例子——三菱汽车的语音客服机器人。这个机器人听起来很自然、响应迅速、承诺会快速回电。但六个月过去了，电话从未响起。作者说："我本来打算买一辆车，但最终决定不再买他们的车了。"一个技术层面"成功"的项目，在业务层面制造了一个流失客户。
这种"Demo 好看、上线崩盘"的现象我们见过太多，之前也专门写过 企业 AI 智能体落地的三个典型大坑。InfoQ 报道中，NoDesk AICTO 王仿进一步总结了企业 AI 落地的四大关键问题[2]：
subset 创始人观察到一个反复出现的模式：企业内部聊天机器人几乎无人使用。
原因很直白——公司的文档质量通常很差，而 LLM 不能读心术，它只能知道那些被写下来且可供访问的信息。员工用了一次发现得到的是过时的、不完整的答案，就再也不会打开第二次。我们在 AI Agent 落地企业的三个工程债 里专门讨论过授权、上下文和成本这三个维度，知识治理的欠账正是其中最隐蔽的一个。
面向客户的聊天机器人也好不到哪去。"作为消费者，我很少有愉快的体验。"subset 创始人写道。一个更隐蔽的问题是：项目负责人刻意避免追踪"是否真的有人在用"这类指标，或者追踪的是那些容易被操纵的指标。三菱的案例里，那个没回电话的请求很可能根本没有被标记为错误。
我们的经验是：如果一个 AI 项目没有人敢问"它的用户留存率是多少"，那它几乎注定失败。
2026 年 AICon 深圳站上，一个被反复提及的判断是："企业需要的不是一个会聊天的大模型，而是一套能够持续创造业务价值的 AI 执行系统。"
NoDesk 团队提出的四层架构值得参考[2]：
| 架构层 | 做什么 | 解决什么 |
|---|---|---|
| Business Translation（业务翻译层） | 把"本月报关效率提升 20%"翻译成 Agent 可执行的 Job → Task → Action | 业务语言不可执行 |
| Knowledge Engine（知识引擎） | 企业文档/数据库/外部数据的统一治理，不只是 RAG | 知识孤岛 |
| Skill Framework（技能体系） | Tool → Skill → Workflow 三级抽象，解决工具碎片化 | 系统孤岛 |
| Agent Runtime（执行引擎） | Planning + Reasoning + Memory + 多 Agent 协同 + 失败恢复 | Agent 不可控 |
这套架构在实际项目中已经产生了可量化的结果：进出口报关从 3 小时压缩到 10 分钟（效率提升 70%+），广告投放从半天缩减到 30 分钟。关键在于这不是"模型更强了"，而是"系统能执行了"。
Agent Runtime 中的 Human-in-the-Loop 机制尤其值得注意——在关键决策节点保留人工审批，同时通过 SOP 约束限制 Agent 的自由发挥空间。这解决了企业最担心的"Agent 不可控"问题：不是在 demo 里看起来安全，而是在审计追溯里真的安全。
2026 年 7 月，一篇题为"不会代码也能做产品：Vibe Coding 保姆级教程"的文章在中文互联网获得广泛传播[3]。它提供了一条用国产大模型（Kimi、GLM、Qwen 等）从零开发产品的路径——买 Coding Plan、下载 Agent 编程产品、描述需求、让 AI 自动执行。
Vibe Coding 和企业级 Agent 体系代表了两种完全不同的 AI 应用范式：
| 维度 | Vibe Coding | 企业级 Agent 体系 |
|---|---|---|
| 目标用户 | 非技术人、独立开发者 | 企业 IT 团队、CTO |
| 核心流程 | 描述需求 → AI 写代码 → 部署 | 业务翻译 → 技能编排 → 多系统协同执行 |
| 可控性 | 低（依赖 prompt 质量） | 高（SOP 约束 + 人机审批 + Trace 审计） |
| 适用场景 | 原型、个人工具、小型 SaaS | ERP/CRM/OA 打通、长链路业务流程 |
| 失败成本 | 低（重来即可） | 高（影响业务运营） |
两者并非互斥。Vibe Coding 适合快速验证想法，但当验证通过、需要对接企业核心系统时，就必须转向可控的 Agent 执行体系。那些死在 PoC 阶段的项目，很多正是因为跳过了这个转变——用原型开发的思路去推生产系统，撞墙是必然的。
不同来源的数据有差异。subset 创始人观察到的 100% 失败是针对他本人接触的项目样本（约数十个），InfoQ 引用的"超过 80% 停留在 PoC"来自更广泛的行业调研。两个数据不应理解为绝对的失败率统计，但它们共同指向一个真实趋势：当前企业 AI 项目的生产化成功率确实很低。
Copilot 类工具属于"个体效率提升"，与"业务流程级别的 AI 落地"是两回事。前者可以提升开发者的编码速度，后者要回答的是"AI 有没有改变一个业务环节的成本结构"——比如报关从 3 小时变成 10 分钟。如果你的 AI 投资只能回答"程序员写代码快了一点"但没有改变任何业务指标，那很可能还停在 subset 创始人说的"买了许可证就宣布胜利"的阶段。
可以，但不要试图一步到位。建议路径：先用 Vibe Coding 或低代码工具做一个最小可用的 AI 功能 → 验证有真实用户在用 → 再逐步引入知识引擎和 Skill Framework → 最后打通核心业务系统。关键不是架构多完整，而是每一步都有可量化的使用数据。
我们服务的核心就是把"模型能力"转化为"可执行的系统"——从业务翻译、知识治理到 Agent Runtime 搭建，踩过前面提到的每一个坑。如果你的团队正在做 PoC 但不确定怎么推进到生产，可以直接联系我们做一次技术评估。
基于以上的数据和经验，这里给出四条可操作的建议：
大模型的能力在 2026 年已经足够强了。Qwen3.8 开源了 2.4T 参数，MiniCPM5-2B 在端侧跑出了 4B 以下最优成绩，Cline 这样的开源 coding agent 在 GitHub 上拿了 64.8k stars——模型侧不是瓶颈。瓶颈在企业有没有能力把模型嵌进一个能稳定运行的系统里。这才是接下来几年真正拉开差距的地方。
