为什么对软件来说,＂AI友好＂比＂AI原生＂更重要

昨天在《我的新角色：AI时代的信息搬运工》中，我们讨论过一个极其荒诞却又无比真实的职场现象：每天有无数高薪的知识工作者，把业务信息从陈旧的软件里一点点拷出来，送给AI进行分析，再把AI得出的结论一条条拷回软件里。人，硬生生地把自己活成了AI和传统软件之间的一座数据搬运桥梁。

文章发出去后，很多同行业的朋友跑来问我，既然发现了这个痛点，那解决办法到底是什么？难道是指望未来的大模型变得更聪明，聪明到能自动看懂我们那复杂的ERP系统吗？

其实，真正的问题根本不出在AI的智商上，而是我们的软件从第一天起就不是给AI设计的。

针对这个问题，现在行业里最热闹、被投资人和大厂疯狂追捧的一个词叫"AI原生"（AI Native）。大家都觉得，只要我们把系统推翻，用AI原生的理念重写一遍，问题就迎刃而解了。但是咱们接下来聊聊，为什么对于99%的企业来说，现在去盲目追求软件的"AI原生"，是一个极其危险且昂贵的陷阱。

AI原生与AI友好的本质错位

什么是AI原生？如果去翻看各类权威机构的研报，定义大概是这样的：软件从设计的第一天起，就是围绕AI能力来构建的，底层架构是AI优先，功能逻辑是AI驱动，用户交互是自然语言先行。

听起来非常完美，极具未来感，这也是很多创业公司最喜欢讲的故事。

在这里我不得不泼一盆冷水。现实情况是，真正能从零开始、完全按照AI原生理念构建的软件，在整个商业世界里屈指可数。我们绝大多数企业面临的是什么？是跑了十年的核心业务系统，是庞大臃肿的存量代码，是几十个盘根错节的上下游系统接口，以及成千上万已经形成肌肉记忆的存量用户。

让这些背负着沉重历史包袱的软件在一夜之间实现"AI原生"，无异于给一架正在太平洋上空飞行的波音747换发动机，根本不现实。

更致命的是，AI原生回答的核心问题是"这个软件怎么用AI技术来构建"，它并没有真正回答"这个软件怎么让AI进来操作"。这是完全不同的两码事。

所以，我今天想抛出一个可能有些反常识的观点：对于当下的企业数字化转型来说，"AI友好"（AI Friendly）比"AI原生"重要得多，也务实得多。

市场说的"AI友好"，不是我们说的"AI友好"

遇到这种新的复合概念，咱们得一层一层剥洋葱。在展开讨论之前，必须先澄清一个巨大的行业误会：当我们今天在这里讨论"AI友好"时，市场上主流技术圈所说的，和我们真正需要的，完全不是一回事。

首先，你去技术社区（比如以Thoughtworks为代表的工程派）看，他们口中的"AI友好"指的是什么？指的是代码可读性。他们认为，只要变量命名清晰、模块划分合理、上下文逻辑连贯，让AI编程工具（比如Cursor）能更好地读懂代码、写出高质量的修改建议，这就是AI友好的软件。

个人比较认可这种工程视角的价值，它对于程序员提升开发效率确实有极大的帮助。但话说回来，这个定义的局限性太明显了。它仅仅解决了"程序员怎么用AI写代码"的问题，丝毫没有触及"普通业务人员怎么用AI操作软件"的核心痛点。

上篇文章里那个苦哈哈的数据搬运工不是程序员，他是一个业务经理。代码写得再优雅、再AI友好，也解决不了他每天在CRM和AI对话框之间来回复制粘贴的噩梦。

所以，我给"AI友好"下了一个回归业务本质的定义：AI友好，关注的是这个软件能不能对外暴露足够清晰的机器语义，让AI能够直接接管并操作它。

不管你的软件是用老旧的Java写的，还是有多少年的技术债，只要它愿意对外敞开大门，让AI能读懂它的功能菜单、理解它的数据结构、并按照它的业务逻辑自动执行点击和录入操作，那它就是AI友好的。

AI友好的三个关键阶梯

这事儿听起来玄乎，其实我们在IT发展史上不是没干过类似的事。十几年前我们搞SOA（面向服务的架构）或者搞企业API网关的时候，核心逻辑不也是不动底层的老系统，而是在上面封装一层标准化的服务接口让其他系统调用吗？

只不过，面对大模型，我们需要的接口不再是冷冰冰的RESTful API，而是带有业务语义的"智能接口"。要实现真正的AI友好，我将其拆解为三个递进的层次：

第一层：AI能发现。 现在的系统，如果AI想进去操作，往往需要人把厚厚的接口文档找出来，提炼成提示词一条条喂给AI，AI进去之后依然两眼一抹黑，全程需要人肉导航。而达到第一层AI友好的软件，会主动向大模型暴露自己的结构信息。它会用机器能读懂的语言告诉AI：我这里有哪些功能模块，核心数据存在哪个对象里，权限的边界在哪里，执行某个操作后会引起什么连锁反应。AI一旦接入，自己就能绘制出系统的全貌地图，不需要人去当向导。

第二层：AI能优化。 传统的软件是你输入一个极度明确的指令，它就刻板地执行一步。而在第二层的AI友好软件中，系统不仅接受指令，还能配合AI主动判断更优的路径。比如你告诉AI"帮我推进一下张总的那个项目"，AI会自己去系统中判断该走哪个特殊审批流，该用什么格式自动生成报告，并抄送给哪些相关人。系统不再是死板的菜单集合，而是能与AI共鸣的业务通道，你说出目的，AI自己在系统里找最优路径。

第三层：意图驱动。 这是AI友好演进的最高形态。在这个阶段，软件能够完全承接人类的意图，一口气执行到底，不需要人全程在屏幕前盯着、每步点确认。你只需要丢下一个宏观的业务目标，AI结合系统自身的友好反馈，自己去判断风险、自己去调用模块、自己去修正执行中的偏差。

这三层叠加起来，其实就指向了一个终极目标：人再也不需要去痛苦地学习和适应那个反人类的复杂软件了，AI彻底替人消化了它。

清醒的务实主义，今年就能迈出的一小步

这么拆解下来，可能有的朋友要问了，这不就是一种技术妥协吗？

没错，任何能包治百病的药都是假药。我始终认为，在这个技术狂飙的年代，保持清醒的技术务实主义比什么都重要。

AI原生当然是灯塔，是我们构建下一代全新系统的终极理想。但对于今天手里端着存量系统、面临真金白银业务压力的绝大多数CIO和产品经理来说，不顾一切地去搞AI原生，是一场代价极其高昂且成功率极低的冒险。

而AI友好，是一条我们随时可以上路的渐进演化路线。它不需要你推翻重来，不需要你把原来的数据库砸了重建。你只需要在对外接口这个层面换一种设计思路：以前设计系统，我们思考的是"人怎么点击这个页面"；现在我们只需要多想一步，思考"AI怎么能看懂并调取这个功能"。

这种改变，不需要等什么五年规划，今年就可以做，甚至下个月你们团队的第一个MVP（最小可行性产品）就可以跑起来。说白了，第一步可能仅仅是由研发团队把现有的API接口文档，用大模型能够理解的System Prompt格式重新改写和封装一遍而已。

两者从来不是对立的。对于全新的创新业务，我们大胆去拥抱AI原生；对于扛着公司营收大头的存量系统，我们脚踏实地先做AI友好，让AI先能进得来、跑得动、把人从搬运工的位置上解放出来，再去谈更深度的架构重构。没办法，谁让现实世界的数字化就是背着这么多包袱在负重前行呢。

最后，既然方向明确了，那我们到底应该从哪里下手？怎样才能诊断出我们现在的业务系统在AI眼里到底是瞎子还是朋友？下一篇，具体怎么去判断和落地这套AI友好的改造方案。

数智进化，关注AI时代的组织能力升级。