企业做 AI,一号位到底该盯什么?

用哪个模型？选哪个平台？要不要自己部署？是不是也得做几个 Agent？

这些问题当然要回答。但如果一号位的注意力一直停在这里，项目可能已经买了工具、接了系统、做了演示，大家却还没说清楚：这笔投入，究竟要改变什么。

销售响应客户更快了？交付返工更少了？原来卡在几个部门之间的事情，现在有人能接着往下办了？

我觉得，这些问题应该更早出现在桌上。

企业做 AI，一号位最该盯住的，是经营结果。

把这个问题想明白，再去看大厂在做什么，企业自己该做什么，很多事情就容易分清了。

一、名字越来越多，方向却越来越接近

例如，钉钉把企业知识与工作流接进 AI 助理；飞书也在把知识问答、业务应用和工作流里的 Agent 连接起来。各家的具体能力和成熟度有差别，但都在尝试让 AI 进入实际工作。

我把这个方向归纳成四条。

第一，办公入口 AI 化。

员工本来就在钉钉、企微、飞书里聊天、看文档、处理审批。AI 要进入日常工作，就要尽量贴近这些已有入口。少切一次软件，少复制一遍资料，才更容易被持续使用。

第二，企业知识决定实际效果。

通用模型知道很多事。但你们公司这份合同后来补充了什么，这个客户以前被承诺过什么，这个项目为什么延期，它未必知道。

这些知识，才决定它能不能把你们公司的事办对。平台在建设知识接入和检索能力，企业也得把自己的材料整理成可靠、可用的依据。

第三，Agent 进入流程。

AI 开始沿着任务往下做：查资料、拆步骤、调用工具、生成文件，再把结果交给下一个人或下一个系统。能力从回答一个问题，逐步延伸到推进一件事情。

第四，信任成为门槛。

当 AI 只能给建议时，人还可以看一眼再决定。当它能够读取客户资料、修改业务记录、推进工作流程时，身份、权限、溯源、纠错和责任，就必须一起建立。

这四条里，哪一条最难？

不同企业可能有不同答案。但我最想提醒一号位留意的，是第四条。它最容易在演示里被略过，却会直接决定业务负责人敢不敢用。

二、AI 会报价，和公司敢让它报价，是两件事

拿一个假设的场景来说。

客户发来需求，销售希望 AI 帮忙做一份报价。它读取产品资料，整理需求，生成一份格式完整的报价单。演示到这里，效果已经挺好。

真要拿去用，问题才开始出现。

用的是哪一版价格表？这个客户有没有单独谈过折扣？交付日期是谁确认的？销售能看到客户资料，是否就意味着他也能看到内部成本和底价？

如果 AI 把一份过期方案里的价格带了过来，谁能发现？报价发出去以后发现错了，又由谁处理？

这些问题，换一个更聪明的模型，也不会自动消失。

公司得先说清楚：谁在使用 AI，AI 代表谁执行，可以读取什么，可以修改什么。生成结果时，要能找到所依据的资料和版本；发现错误时，要有办法暂停、修正，并交给明确的人处理。

比如，先让 AI 生成报价草稿，标明价格来源，把缺失的信息列出来。超出折扣范围的，交给有权限的人确认。销售审核后再发给客户，系统保留记录。

做到这一步，业务负责人才能知道自己究竟交出去了什么，手里还握着什么。

企业需要的信任，是出了问题能查清、能纠正，也有人负责。

平台可以提供权限和日志功能。飞书的工作流文档就明确涉及执行身份及其权限。可这些功能在你们公司应该怎么配置，依然需要企业自己确定。

三、买到了知识库，还得有人把知识管起来

说到企业知识，很容易想到一个动作：把文件上传。

制度、合同、产品手册、项目方案，全放进去。文件越多，似乎 AI 就会越懂公司。

但还是回到报价这件事。如果知识库里同时有三份价格表，文件名分别叫“最新版”“最新版修改”“最终确认版”，人都得问一圈才知道用哪份，AI 又该相信谁？

它也许能很快找到三份，但公司还得有人确认哪份有效。

哪些资料可以进入知识库，谁有权使用，谁负责更新，什么时候失效，发现回答错误后改哪里。这些事情要有明确安排。

企业真正稀缺的，是能被放心使用的业务知识。

一个销售临时答应客户的条件，如果从来没有记录；一个项目经理处理异常的方法，如果一直只在他脑子里；一条已经变更的制度，如果旧文件还到处流转，接上 AI 以后，这些问题都会继续存在。

所以做企业 AI，也是在逼着企业把原来含糊的地方重新说清楚。

哪些是正式规则，哪些是临时例外。谁能做决定，谁要留下记录。以前靠熟人之间一句话协调的事情，现在要变成系统可以理解、团队可以检查的工作方法。

四、我把这条价值链，分成四层

理解了这些，再来看分工。

企业没有必要从模型到业务全部自己建设。我更愿意把这条价值链拆成四层，看看每一层主要解决什么问题。

第一层，通用模型与算力。

语言、视觉、推理等基础能力，主要由模型厂商和云厂商提供。对大多数企业，重点是选择适合任务、成本和部署要求的能力，再用自己的业务验证效果。

第二层，企业平台与办公入口。

这一层承载知识库、工作流、Agent，以及与原有系统的连接。平台厂商提供基础设施，企业 IT 负责接入、配置和维护，让能力进入已有的工作环境。

第三层，行业与岗位智能体。

销售怎么判断需求，交付人员怎么检查材料，客服遇到哪类问题要转交人工。行业服务商、企业 IT 和业务团队，要一起把这些规则与方法做成能够反复使用的能力。

还拿报价来说，模型会写一份报价单，不代表它已经掌握了某个行业的计价规则、交付限制和例外处理。第三层就在补这些东西。

第四层，经营场景与验收。

这件事最终要降低什么成本，控制什么风险，带来什么增长，改善什么协作？谁对结果负责，做到什么程度才算通过？

这一层，是一号位和业务负责人必须抓住的。

沿着这四层往下看，价值越来越靠近具体业务，也越来越需要企业自己的判断。这不代表底层技术不重要，而是说，技术的价值最终要在真实场景里被验证。

模型和平台可以采购。经营目标、业务规则和验收责任，企业得握在自己手里。

五、一号位要盯的，是第四层

这不意味着一号位完全不用关心技术。

预算怎么花，数据放在哪里，出了问题能不能继续运营，这些都需要了解。但没必要把大部分精力用来比较模型参数，或者追着每一个新名字跑。

更值得追问的是：这个项目现在走到哪一步了？业务结果有没有变化？下一步卡在谁那里？

回到报价场景，团队汇报“已经上线一个报价 Agent”，只是说工具做好了。

接下来还要看，从收到完整需求到发出合格报价，时间有没有缩短。价格和条款错误有没有减少。销售节省的时间，有没有被额外的审核和返工吃掉。

再往后，响应变快了，是否真的带来了更多有效商机？这需要继续观察，不能把报价速度直接当成收入增长。

所以验收前，要先记录原来的情况。尽量用相近类型的业务来比较，把人工复核、异常处理和系统费用一起算进去。

省下来的工时，也要看最后去了哪里。团队能多服务一些客户，或者少加一些班，是结果；如果只是换了一个环节继续忙，也要如实看见。

验收标准，应该在项目开始时就说清楚。

等做完以后再找指标证明成功，很容易挑出几个漂亮数字，却没回答当初为什么要做。

六、先找一件值得做、能验收的事

选一个频繁发生、有明确负责人、结果能检查的场景。把它从头到尾走一遍：需要什么资料，经过哪些步骤，在哪些地方必须由人判断，最后交付什么。

然后用一段约定好的试运行时间，去看真实结果。

知识不准，就补知识。权限不清，就理权限。规则有歧义，就找业务负责人确认。流程跑通以后，再决定下一步扩到哪里。

这也更接近我理解的 OneX 应该做的事：把企业的真实问题，接到已有的 AI 能力上，和企业一起把知识、流程、责任和验收做扎实。

大厂会继续提供更强的模型、更完整的平台。企业可以借助这些能力，把更多精力放在自己的经营现场。

下一次听 AI 项目汇报，一号位不妨先问：

“这件事，最后由谁负责？拿什么结果来验收？”

这两个问题回答清楚了，再谈选哪个模型、接哪个平台，方向会清楚得多。

AI 能办事以后，企业要让这些能力带来可验收的经营结果，并且有人对结果负责。