三年前,我总结了一套BEST系统选型法:
B = 业务需求 Business Requirements
E = 企业环境 Enterprise Environment
S = 服务交付 Service Delivery
T = 技术融合 Technology Fusion
三年间,AI的爆发不仅改变了科技环境,也改变了社会和经济环境。利用AI提升组织能力和效率、建立竞争优势,几乎成为所有企业新的需求。
因此在现在的AI Agent时代,系统选型时自然要把AI考虑在内,但只看系统自带了哪些AI功能还远远不够。
背景:工作范式的改变
我常看的博主“第四种黑猩猩”最近总结了企业落地AI的实操公式:
Agent + Skill + Data
这个公式也代表着白领员工工作范式正在经历的转变。
这里说的Agent,就是我们之前介绍过的Work Agent或者Coding Agent,比如WorkBuddy、Trae、Claude Code、Codex。这类软件给大模型装上“harness”、配上工具,让AI不再只是会思考,而是能完成几乎所有在电脑上的操作。
现在有多少人每天上班开电脑第一件事 就是打开这类Agent?
正如飞书/钉钉/企微是我们和人类同事交流的主要渠道,这类Agent是我们现在和AI交流的主要入口、和AI协作的主要工作台,它们不但能执行我们的指令,还能读懂我们的想法、记住我们的习惯、帮我们分析问题、给我提出建议。
这里说的Skill,泛指被AI重塑的业务流程。我们过去做系统实施,都会画业务流程图,告诉大家在哪个节点,谁要用系统做什么操作。现在,流程、方法、规范、资料、经验都被固化在了Skill里,不过这份“流程指引”的读者不是人,而是AI Agent。
这里说的Data,指的并不仅是系统数据库里的数据和Excel台账中的数据,还包括过去不好管理、不好应用的非结构化数据,比如录音、图片、PPT、制度文件、邮件、消息记录等等。现在的AI Agent能以极高的效率,将这些文件转换成能被大模型AI读懂和利用的形式,并让AI整理、提炼其中的内容要点。
通过WorkBuddy、Codex之类的Agent,我们和AI一起分析业务问题和需求,让AI按我们的想法和业务流程执行操作,这个过程中让AI读取和修改业务数据,这就是新的工作范式。
有了Agent还需要系统吗?
系统用合规、科学、可靠的方法,管理着业务流程和数据。新的工作范式并不会改变这一点。
已经将Agent、Skill用于实际工作的你,一定不会对此怀疑。
我们聊过大模型AI的各种先天不足:幻觉、黑盒、上下文限制、注意力衰减,这些都还需要我们用各种工具、技巧来尽量克服。而且无论从时间、费用,还是合规风险、数据质量的角度来看,Agent,或者Agent编写的“日抛软件”都不会完全替代系统。
不过既然说Agent无所不能,编程更是拿手好戏,那直接用AI编程开发系统可以吗?还需要做外购选型吗?
如果你有这个疑问,我的建议是:去搓一个试试,你就会有答案。
一定有人泼冷水:我不信AI能理解什么什么什么,我不信AI能考虑到什么什么什么,我不信AI能做到什么什么什么。人信不信,并不影响AI行不行,试过才知道。
已经有人成功了,王岩总最近分享了一篇《花268块用WorkBuddy手搓了一套生产系统,交付了,钱到账了》。
我也已经试过了,以我开发微信小程序为例子,我花了几个小时和AI交流:目标是什么、决定做哪些功能、页面应该长什么样子,最终让AI整理汇总成了一份功能说明书。我把这份功能说明书传给WorkBuddy,它读完觉得没什么问题,一言不合就直接开干了,一个多小时愣是没停过。“YES”都没让我点一下,一定参与感都没有。而它这一把写出来的程序,运行居然没有任何报错,而且主体功能框架也都已经具备了。
现在要搓出一个能用的系统,技术门槛真的已经几乎为0了。
当然,能用和好用不是一回事,能用和能用很久不是一回事,能用和能给全公司用也不是一回事。
我的小程序,在第一版的基础上,又花了至少5倍的时间和Token才最终上线。
王岩总能用268块搓出来一套企业能用的系统,背后是他20多年做数字化的经验。
试一试,如果在可接受的时间和费用内,就把系统搓满意了、搓上线了,那就太好了,确实暂时就不用外购了。
如果搓出来的不行,那也是好事呀,咱也知道外购选型的重点是什么了、也就能理解专业和经验值钱在哪里了,钱花得更明白了。
需要提醒一点:搓企业办公用的软件,安全和合规都是第一位的。
胡彦斌搓出来的APP,第一天就被人发现几乎是在“裸奔”,哪怕他跟AI讨论过数据安全、内容审核这些话题,都不会是这样的结果。
系统如何接入Agent?
系统应用在业务流程里。
过去,企业为了让流程更顺畅,经常要做很多系统之间得集成,比如把所有系统审批都汇总到OA、让所有通知消息都发送到IM、HR系统中的组织人员变化要及时同步给各个系统。
即使所有系统都开放了自己的API,开发系统之间的集成接口一直还是高投入、高风险的。所以厂商会强调自己的“生态”:我们已经和其他哪些系统做好了集成,你们不用单独开发了,我们也会一直负责维护和更新。
而业务流程和工作范式正在被AI和Agent重塑。
系统中的功能是否容易被Agent调用、数据是否容易被Agent接入,已经成为了我们选型要考虑的重要因素。
Agent可以通过不同的方法接入和操作系统。比如之前介绍过的CLI(Command-Line Interface,命令行界面)和MCP(Model Context Protocol,模型上下文协议),是目前对于大模型来说是非常高效且省Token的方法。

(图:Claude Code通过飞书CLI创建飞书多维表格)

(图:Claude Code通过SupaBase MCP读取、分析数据库中的数据)
如果系统没推出CLI或MCP,再不济API也是得齐全得,可以让AI去写程序调用,也比以前人手开发效率高得多。现在不少系统厂商会把调用API的程序固化成Skill。
无论是CLI、MCP还是Skill,对于不同Agent、不同大模型都是通用的。
AI时代,系统的“生态”不再是壁垒,心态开放的厂商才会有未来!
开放、健全的文档越来越重要
在过去,有些厂商对系统文档、知识库是不够重视的,客户有问题,微信群里都有专人一对一贴心服务。
让随着客户工作习惯和厂商交付成本的变化,AI客服肯定会越来越多被应用,这对系统厂商的文档、知识库管理提出了更高的要求。
相比去找厂商的AI客服,更好的体验可能是:客户在自己的Agent里问AI,就能直接得到答案。
比如我这次上线微信小程序,在AI开发好之后,还需要我亲手在微信开发者工具和微信公共平台做很多配置工作。但我并没有去读文档,而是直接在CodeBuddy里让AI带我一步一步做。AI直接能告诉我点哪个按钮、填什么参数,遇到报错也能告诉我要怎么处理。
大模型并不能看到系统的页面,它是从公开的文档中学习到的这些操作方法。而且我发现,在微信小程序配置这个场景中,腾讯自家的混元大模型比GLM和DeepSeek都懂得多太多。
如何让系统文档、截图成为大模型的训练数据,也许是系统厂商的新课题。同时系统的页面布局和操作方法的更新可能也需要更加谨慎,因为大模型的训练数据并不是最新的。
开放、健全的文档变得越来越重要。有AI,这件事可能并不会增加太多负担。
我在Vibe Coding的时候,都会在CLAUDE.md/AGENTS.md/CODEBUDDY.md里写上一句,功能变更先更新PRD.md,确认无误后再改代码,保证PRD与代码一致。
相关阅读:
夜雨聆风