公司内部应用AI大模型的几点思考内心澎湃，觉得这玩意儿这么聪明，怎么着也能帮我把日常那些繁琐的内部流程给收拾了吧。我就开始老想着用它来操作内部应用，比如审批OA已阅公文，收发邮件，审批工单。我心想，这些东西不都是文字吗，让大模型读懂了规则，帮我点点鼠标，不过分吧。结果呢，效果很差，经常弄不清楚我的要求，也不能帮我点击。让它帮我查一下某个工单的处理状态，它一本正经地编了一个根本不存在的工单编号出来。我当时就愣住了，这不是越帮越忙吗。然后我就开始反思了，说真的是不是我的方法有问题，是不是提示词写得不对，是不是系统API没有预留好接口。我就去翻文档，去问厂家技术支持，去翻各种技术博客，发现了一个让人有点沮丧的事实——不是我的方法有问题，而是这个方向本身就是错的。
为什么要重新理解大模型的「技能树」
有人让它帮忙自动填报销单，它把发票金额给加错了；有人让它帮忙查CRM系统里的客户信息，它一本正经地告诉你这个客户去年贡献了800万营收，实际上这个客户去年压根就没有合作了。还有人让它去发邮件，结果它把邮件发给了错误的收件人，差点造成一次严重的数据泄露。你发现没有，这些问题的共同点是——大模型并没有真正「操控」我们的系统，它只是在「想象」它操控了系统之后应该返回什么结果。现在的大模型本质上是一个语言模型，它的强项是理解、生成和推理文本，它并不具备真正的工具操控能力。你让它「点」一个按钮，它其实并没有真的去点，它只是在预测一个「点了之后最可能出现的文字」是什么。这个区别听起来有点绕，但搞清楚了之后你就会明白，为什么让它操作内部系统这件事，目前来看就是强人所难。系统改造和大模型智商，是一枚硬币的两面
我又深思了一下企业内部使用大模型的场景，感觉是不是我们对他有什么误解。其实大模型现在很弱很弱的点，恰恰就是「操控外部系统」这一块。不是说它蠢，而是它的能力边界就不在这个方向上。一个厨师你让他去修空调，他再有天赋，没有相应的工具和培训，也是干不了的。大模型现在就是那个有天赋但还没学过空调维修的厨师。我们现阶段在企业内部遇到的各种AI操控系统的问题，根本上有两个原因：第一个，大模型不具备结构化的工具调用能力。 虽然现在的模型厂商都在推Function Calling / Tool Use这个概念，但说实话，用起来还是相当的脆弱。你给一个工具写好schema，它确实能调用对，但是一旦业务流程稍微复杂一点，需要多步判断、异常处理、状态回滚的时候，它就容易乱了套。工单审批里一个很常见的场景是：审批人被退回了一个申请，需要重新提交，但是退回的原因是系统里多个条件同时触发的，大模型就彻底蒙了，不知道该怎么处理。第二个，我们的IT系统压根就没有为大模型改造过。 大家想想，我们的OA系统、审批系统、工单系统，有多少是十几年前的老系统，接口文档残缺，字段命名混乱，返回格式不标准，这种系统让人类IT人员去对接都头疼，更别说让大模型去自动化操控了。所以我说，这是一枚硬币的两面。一面是AI-Agent的操控性能和智商需要再提升一个台阶，另一面是我们的IT系统需要做相应的改造，为大模型预留好清晰的API接口，让它能真正意义上「行动」，而不是「猜测」。真正好用的场景，其实一直就在手边
我又重新想了几个方面，再让大模型尝试，感觉好多了。让它来给我整理云电脑文件，这个效果貌似好一些。 说出来你可能觉得这个需求很 low，但真的，太好用了。我每天工作产生大量的文档、截图、报告，分布在不同的文件夹里，我只要跟大模型说，把这个月跟某项目相关的所有文件给我整理到一个目录里，并生成一个文件清单，它真的就能帮你做好，而且经常能找出那些我自己都忘了放在哪里的参考资料。这种事情它干起来特别自然，因为它本质上就是在处理文本和文件路径，这些东西它太熟了。让它帮我总结写文章，那更是如鱼得水。 我经常需要写各种汇报材料、技术文档、邮件草稿，跟大模型一说，它就能给我一个相当不错的初稿。我再根据自己的风格修改，效率提升非常明显。以前写一份月度总结要憋一下午，现在可能一个小时就搞定了初稿，剩下的就是润色和核实数据。这两个场景和第一个场景的本质区别在哪里？在于有没有「系统操控」。整理文件本质上是对磁盘内容的读取和组织，大模型通过文件系统API可以很好地完成这个任务，它不需要去点击一个图形界面上的按钮，它不需要模拟鼠标键盘，它只是在处理结构化的数据。而操作OA审批流，需要它去理解一个复杂的业务流程，去模拟人类的点击和输入，去处理各种异常分支，这远远超出了它目前的能力边界。同样的道理，让它帮我写一份报告，它处理的是纯文本，它就是在它的主场上工作，当然得心应手。所以我现在总结出一个特别简单粗暴的判断标准：如果你让大模型做的事本质上是在处理文字、语音、代码这类符号信息，那大概率是靠谱的；如果你让它做的事需要操控一个图形界面、需要模拟人的肢体动作、需要和现实世界产生物理交互，那现在还不行。审批流自动化的关键：分级分类与规则判断
说完了个人效率层面的事情，我们再往大一点的方向聊。我所在的公司内部有大量的审批流程和工单，每天流转的数量是惊人的。以前我们总觉得，这些东西如果能让大模型自动处理就好了，能省多少人工啊。但前面说了，直接让它来审批是搞不定的，不过这不代表这条路走不通。我最近在想一个方向，觉得可能是有价值的，就是对流程进行分级分类，低级别的，审批通过的规则是什么，符合规则的经过校验可以授权自动审批通过；风险高的，才需要你亲自仔细审核。 相信绝大多数都可以自动审批。我举个例子。比如员工提交一个设备领用申请，领取的是键盘鼠标这种低值易耗品，单价不超过200块，库存有货，部门预算没用完，这种申请其实有非常明确的通过条件，如果系统能够判断这些条件全部满足，自动通过就好了，根本不需要人工审批。反过来，如果有人申请一笔大额采购，或者一个敏感权限的开通，那风险就高得多，确实需要仔细人工审核。分级分类的核心逻辑就是：让机器处理有明确规则的低风险事务，把人的精力留给真正需要判断力和专业经验的高风险决策。审计的真正价值：发现异常，而不是制造繁琐
关于规则判断，我想再往深了聊一句，因为这个和我的本职工作网络安全太相关了。很多公司做内部审计，做着做着就做成了一个「防员工」的系统。规则越设越多，审批层级越来越深，每个员工每天大量的正常操作都要经过额外的人工审核。打个比方，某个人在同一个部门工作三年了，一直勤勤恳恳，突然有一天他想申请一个VPN权限，需要三个层级的主管签字，还要安全部门审核，这个流程走下来要三天。你说这是不是在防员工？这当然是在防员工，但这种防法，其实是在用一种粗放的方式把所有人都当成潜在的坏人，然后再靠人工审核去弥补这种不信任。审计应当发现异常，而不是制定一个粗放的规则，把每天大量的正常操作都要纳入人工审核。 审计应该做的事，是发现真正存在的问题，而不是制造大量的低价值人工劳动。我举个例子。某个人天天只做A类事情，突然有一天他做了B类事情，而且B类事情的数量或者金额跟他的日常行为画像差异巨大，这种时候才应该触发审核，才应该让人类去看看是不是合规。这里面的分析才是应该给大模型来做的。 大模型特别擅长处理大量的行为数据，发现偏离正常模式的异常点，而人类的审计人员应该把精力放在更高层次的判断上：这个异常是不是真的有问题？是业务正常变化还是有人在搞事？换句话说，审计的智能化方向，不是把所有东西都交给AI审批，而是让AI来做海量数据里的异常发现，把人的精力解放出来去做真正的判断。国网江苏省电力就有一个基于大模型做工程审计的项目，他们把大模型用来做跨系统的数据关联分析，把ERP数据和OA数据以及银行流水放在一起做一致性校验，这种事情如果靠人工去做，要审到猴年马月，但交给大模型处理效率就高得多。而且大模型会生成审计三元组，告诉你这个数据异常对应的审计疑点是什么，需要重点关注。这就是大模型在审计领域真正该干的事：不是在流程节点上替人签字，而是在海量数据里把真正的异常抓出来。企业内部部署最大的好处：数据不出门
聊了这么多使用场景，我想换一个角度来聊，就是为什么企业内部部署大模型这件事本身是值得做的。我们先把功能放一边，有一个最朴素的理由：它确保了公司数据的内部处理。这个价值在当前的监管环境和企业竞争环境下，是被严重低估的。你用公有的大模型API，你把内部文件、代码、业务数据往里传，那个数据到底去了哪里，被怎么存储和使用了，你是很难完全掌控的。但如果你在内部私有化部署了大模型，所有数据都在你自己的服务器上流转，没有出境风险，没有第三方访问的可能，这对于很多企业来说本身就是一条硬性的合规要求。金融行业、医疗行业、政府机关，这几个领域对数据安全的要求是极高的，它们天然就是私有化部署大模型的主要需求方。而且还有一个很实际的考虑，就是响应速度。内部部署的大模型走的是内网，没有公网延迟，在高峰期也不会因为API限流而影响业务。你要是做过大规模的生产系统接入，就会知道公网API的不确定性有多让人头疼了。24小时挖洞这件事，大模型是真的能干好
接下来说一个我特别期待的方向，我觉得这个方向现在就可以开始做了，不需要等系统改造，不需要等AI-Agent再升级，就是现在就可以部署起来产生价值的。大模型完全应该来给我24小时挖洞，找系统问题，日夜不休。网络安全，漏洞扫描这件事一直在做，但传统扫描工具本质上是一个规则库，它需要安全研究人员先发现某种漏洞模式，然后把它写成规则，再让扫描器去匹配这些规则。这个模式有一个天然的瓶颈，就是规则永远滞后于新的漏洞。你想，一个新的漏洞被发现了，到它的扫描规则被写出来、被测试好、再推送到生产系统上，这个时间差就是风险窗口。但大模型不一样。大模型可以做代码审计，它能理解代码的语义，能发现那些传统的规则引擎发现不了的漏洞类型。GitHub上已经有不少基于大模型的代码审计工具在生产环境里跑了，像Devin这些AI程序员，它们的代码审计能力已经超过了大多数初级安全工程师。更关键的是，大模型可以做持续性的监控。只要你把代码仓库接进去，每一次代码提交大模型都可以自动去做一次审计，不需要人工触发，不需要排队等扫描窗口，发现问题直接生成工单推送给相关开发人员。这个效率是传统安全工具没法比的。而且大模型挖洞这件事，它不需要系统改造，它不需要跟任何内部应用做API对接，它处理的是代码本身，它就在它的主场上工作。 代码审计这件事，和我前面说的文档整理、写文章，本质上是一样的，都是在处理符号信息，大模型干这些事情是得心应手的。现在已经有公司在做APT攻击预警平台的产品，里面有一个AI安服数字员工的功能，基于大模型做渗透测试和代码审计，覆盖渗透测试、应急响应、代码审计等5大核心场景。据他们自己说，整个过程不需要人工干预，可以自主规划任务，调用工具链。这代表了一种方向，就是安全服务本身也可以被大模型自动化。海量日志丢给大模型分析，这才是它该干的事
说完了挖洞，我们再说一个我觉得想象空间更大的场景。把海量的操作日志丢给大模型，规则给它，让它来分析谁干了坏事，能不能一抓一个准。这个方向我在各种安全运营的场景里越想越兴奋。企业内部每天产生的日志数据量是巨大的，传统SIEM系统能做的事情是把这些日志收集起来存好，然后用规则匹配的方式去发现一些已知类型的异常行为。但已知类型的异常毕竟是有限的，而攻击者的手法是在不断进化的，你永远无法写出足够完善的规则来覆盖所有的攻击场景。大模型可以做上下文理解，可以把分散在多个系统里的日志关联起来看，可以从一段看似正常的操作序列里发现不寻常的意图。一个很典型的场景是：一个员工账号平时都是在北京登录的，有一天突然在广州登录了，而且还访问了他平时从来不会去碰的那些敏感数据。这种行为模式靠简单的规则其实不好定义，但如果把这个员工的日常行为画像交给大模型，让它来分析这个异常登录背后的意图，它就有可能发现这是一个账号被盗用的信号。不少安全运营中心产品里就集成了大模型能力，每天处理超过200GB的安全日志，他们说AI测试工具能在24小时内完成过去需要两周的手动测试，漏洞检出率提升了47%。这个数字听起来很夸张，但仔细想想其实不意外，因为大模型可以7×24小时不间断工作，而且它不会疲劳，不会因为看了太多数据就漏掉细节。当然这个场景也有一个前置条件，就是你得先把日志规范好，得让大模型能看懂日志的内容。很多老系统的日志格式混乱得很，时间戳不统一，字段命名不规范，这种数据质量大模型来了也是白搭。所以数据治理是所有这些智能化场景的基础，这一步没有做好，上层的大模型应用就是空中楼阁。互联网大厂们在怎么用：一些已知的实践
聊了这么多我自己的想法，也来看看互联网厂商们现在都在怎么用企业内部的大模型，这些实践不一定完美，但至少代表了一种方向。字节跳动从今年开始，要求所有部门在绩效考核里加入AI应用贡献这一项，各业务线都在探索怎么用大模型提升工作效率。豆包大模型部门的负责人朱文佳说过，未来的模型不仅要回答问题，更要通过清晰易懂的语言展现其情感智能，任务管理应聚焦问答、创作、解题和编程这些领域。说实话这个判断我觉得是靠谱的，这些领域大模型确实强，你非让它去操控一个图形界面点按钮，就有点强人所难了。腾讯的做法是「双引擎」模式，自己的混元大模型配合DeepSeek一起用，在内部形成了一套模型选型的体系，不同的业务场景用不同的模型。腾讯元宝的日活跃用户增长很快，他们也在用DeepSeek来提升广告业务的效率。这是一个很务实的思路，不追求一个模型解决所有问题，而是让合适的模型做合适的事。阿里巴巴的力度更大，CEO吴泳铭明确说了未来三年投3800亿做AI基础设施建设，而且要求所有部门都得用AI促进增长的方式来评估绩效。他们内部用通义大模型接入了很多业务场景，我听说在一些客服和文案生成的场景里效果已经非常显著了。百度和信通院联合发了一个《大模型平台落地实践研究报告》，里面提到了「建、用、管」三步走的路线图，这个思路挺实在的：先建好模型服务平台，再把模型用到具体的业务场景里，最后管好模型的运营和合规。这个报告里还特别提到了一个观点，我觉得说得特别好——大模型平台的核心价值不是替代人，而是把人从低价值的重复劳动里解放出来，让人有更多精力去做需要判断力和创意的事情。在中国企业内部部署大模型的实践里，有一个特别值得关注的案例，就是辽宁移动基于中国移动的「九天」人工智能平台做的AI审计。他们构建了覆盖「知识通问、代码通译、案例通汇、问题通查、文稿通拟、建审千询」六大核心能力的审计专业智能体，实现了审计工作的自动、全量、深入的精准化风险管控。这个案例特别能说明我前面说的观点——大模型在审计领域最适合做的事，是全量数据的异常发现，而不是在审批节点上替人签字。为什么说「号召大家都用起来内部的百亿token」
百亿token这个活动我相信不会每个公司员工都会用，很多人还是把它当成了一个新鲜玩意儿，试了两下觉得不太会用，就丢在一边了。更多的人是在用公有的大模型API处理工作上的事，数据出去了没有，心里其实也没太当回事。我想说的是，企业内部部署的大模型，目前确实还有各种各样的不完善，工具调用能力弱、系统适配差、用户体验不够流畅，这些都是事实。但这不是我们观望的理由，而是我们参与进来的理由。一个系统好不好用，最终还是要靠真实用户在真实场景里用起来才能验证。你不用，我不用，厂家没有真实反馈，改进就慢。你用了，发现了问题，报给厂家，厂家才有动力去修。这才是一个正常的迭代循环。而且大模型的进化速度是非常快的，现在觉得不好用的地方，可能过三个月就完全不一样了。就拿工具调用这件事来说，我记得半年前各大模型厂商的Function Calling能力还相当的粗糙，但现在再看，很多场景下已经可以很好地工作了，这个进步速度是惊人的。至于百亿token这个说法，我是认真的。现在很多企业私有化部署的大模型，算力已经不是问题了，问题是这些算力没有被真正地运转起来。大量的token被闲置，而另一边大家还是在用公有API处理工作数据。还是那句话，数据安全这件事，你不上心，没人替你上心。行动起来，从小场景开始
如果你是一个企业的IT负责人或者安全负责人，想要在企业内部推广大模型应用，我的建议是从小场景开始，不要一开始就想着颠覆什么核心业务流程，那个阻力太大，而且风险也高。从哪里开始呢？我列几个我自己验证过或者看到别人验证过的、目前阶段靠谱的场景：第一个，内部知识库的智能问答。把公司的制度文档、操作手册、技术规范扔给大模型，让员工可以自然语言查询这些内容，这个场景效果立竿见影，而且几乎没有什么风险。第二个，会议纪要自动整理。接入了日历和会议系统之后，大模型可以自动把会议录音转成文字再整理成纪要，这个功能在各种大厂内部已经是标配了，用过的都说好。第三个，代码review辅助。开发团队每天都有代码提交，把这些提交交给大模型做一次自动review，让它发现潜在的bug和安全问题，这个效率提升是非常明显的。第四个，安全日志异常检测。把SIEM系统里的日志数据接入大模型，让它做7×24小时的异常行为发现，这个我在前面已经详细说过了，这是大模型在安全领域最能发挥价值的地方之一。第五个，内部文档写作辅助。技术文档、汇报材料、培训教材，大模型都能帮你起一个像样的初稿，你再修改润色，比自己从头憋快得多。这些场景有一个共同特点，就是大模型处理的是公司内部的数据，但没有在关键的决策节点上替代人工，风险是可控的，价值是明显的，推进阻力也是相对较小的。从这些场景入手，让大家慢慢感受到大模型的价值，等大家用习惯了，再往更复杂的场景推进，这个节奏可能是最合理的。说真的，这波大模型浪潮来得比我想象的快多了。两年前我还在想这个东西什么时候才能真正用到生产环境里，现在再看，很多场景其实已经可以跑起来了。数据安全问题、模型能力问题、系统适配问题，这些确实还存在，但这些问题不是停滞不前的理由，而是边干边解决的动力。企业内部部署的大模型，它确保了数据不出门，它有巨大的提效空间，它现在唯一缺的就是被真正地用起来。
夜雨聆风