课件来了|10月17日南京线下AI沙龙分享

一、四种AI投入，为什么没有自然变成组织效率？

分享开始，我先问了大家一句：单点提效不等于组织提效，这句话对不对？有人说对。我说，要看条件。如果是一人公司呢？如果几个人就能把一件事从头做到尾呢？个人能力提高，完全可能直接带来业务改善。真正要讨论的，是组织有了更多依赖以后，个人省下的时间怎样传递到最后的交付。

现在企业做AI，常见的几种动作是什么？先买工具、发Token；接着要求全员写Skill，A部门几个、B部门几个，最后加起来；再往后，每个部门做Agent，每个人做Agent；觉得还不够，就开始造平台。这些事情都可以做，但我会继续问：你请AI进来，到底是来干什么的？

一个研发同学每天都在写代码，产出很快，可代码还要集成，需求还要澄清，测试还要做，下一个人不一定接得上。还有人今天有个想法，立马干；干出来没用，再干一个。做得越来越快，做的事情却未必更值得做。给工具是起点，接下来要把有效任务、执行能力和流程设计放在一起看。用了多少、做了多少，和最终交付了什么，是两本需要对得上的账。

二、卡住Agent的，常常是周围的工作环境

我讲到这里，想强调的已经不只是模型和上下文了。企业里，AI周围的工作环境，包括人，才是我们要一起准备的东西。你能不能讲清楚需求？逻辑是不是清楚？表达是不是准确？拿到结果能不能判断？同一个AI，交给不同的人使用，结果可能差得很大。人的能力仍然重要，AI也可以帮助人补短板，关键在于具体任务和使用方式。

我举过一个工作场景：AI读材料、按规则判断，单独跑起来效果不错。真正接到企业里，问题来了——要从业务系统取数据，对方愿不愿意开放？取出来的字段是什么意思，几个部门认不认同？你说的“流程”，和业务人员理解的是不是同一件事？这些没有搞清楚，模型再聪明也很难替你补齐。

人、业务上下文、做事方法、系统能力，以及前后的交接，都要给它讲明白、接起来。不必等整个企业都准备完美才开始，但你选出来的这段工作，至少要让执行者有条件做下去。

三、从一整条交付链倒推，重新安排工作

如果要优化一条完整的工作链，你逃不了现状还原。先定义结果、定义需求，再做诊断，看现在到底是怎么跑的：谁在做，等谁答复，什么地方重复了，哪个判断来得太晚，哪个环节交过去又被退回来。

然后才能谈删除冗余、重新分工、补齐条件，再做试点。这里也不是看到审批就删、看到人工就换AI。一个检查为什么存在，它管住了什么问题，删掉以后由什么机制承接，要先看清楚。流程既要支持交付，也要处理资源约束和必要控制。

AI落地是系统性的工作。我希望大家听完以后，能回到自己的主航道流程，找一段真实工作去诊断，而不只是觉得“这个演示真厉害”。试点之后，看看质量、单位交付成本、交期和风险怎样变化，再决定往哪里扩。

四、一个方案为什么迟迟交不出去？

我讲一个做政企客户方案的场景。客户说，我要一个方案。客户经理去拜访、了解需求，回来以后请方案专家设计，产品人员核对产品条件，最后把成稿交给客户。这条链，听起来是不是挺正常？

问题就在实际运行里。专家没有那么多，大需求、小修改都在排；客户经理聊过的细节，回来未必记得完整，转述一次又丢一点；有些产品和交付条件，等整份方案做完才发现不成立。最后拿给客户，对方来一句：这不是我要的。前面做得再快，也要回头改。

所以我没有先问“能不能用AI做个PPT”，而是先看：哪些方案可以复用，哪些一定要专家参与？哪些信息应在最初就保留下来，哪些条件应该提前确认？先把工作过程诊断清楚，再讨论AI在哪里发挥作用。

五、成熟方案小改走快路，新方案先请专家到场

这个方案过程，先做的一件事就是分类和分流。与客户沟通时，在取得相应同意、符合企业要求的条件下，把原始需求尽量完整地记录下来，关联到商机，再分析这是成熟方案的小改，还是要做一套新的东西。

如果是已经验证过的方案，改动也在明确范围内，就让客户经理与AI先澄清、先修改，再把变化点交给专家确认。涉及新的接口、部署条件或对客承诺，就不能当作普通小改继续走快路。全新的方案、拿不准的方案，让产品和交付专家提前到场，把关键条件先讨论明白。

小需求不必和大需求挤在同一个队列里，必要的专业确认也不必全部等到成稿才发生。先梳理流程、做好分类，再安排人和AI做什么。这是这张未来流程图要表达的方向；能省多少等待、减少多少返工，还要拿真实任务跑过、核对过才知道。

六、人、Agent、Skill和系统，在同一条流程里各做什么？

那到底哪个地方需要AI？你把需求给它以后，它应该去查商机记录，查方案库，查以前的评审，看看有没有类似方案、哪些条件已经确认。需要澄清就追问，需要生成就调用做方案的方法，完成之后还要检查，把结果交给后面的人。

企业自己的战略和产品条件也要进来。这个方案值不值得做，哪一类客户优先，哪些承诺不能做，这些不能指望AI凭空知道。客户经理负责目标和对客确认，产品、交付专家负责关键专业判断，Agent在已经明确的范围内推进任务。

AI要发挥这种作用，需要真实进入业务过程，取得必要事实，并能调用获准的系统能力。问答本身有价值；希望它接住更完整的工作，就还要准备方法、动作和回执。这张图讲的是各方如何配合，具体系统接入要逐项落实。

七、系统CLI化、流程Skill化、岗位Agent化

这就是我一直讲的三个“化”：系统CLI化、流程Skill化、岗位Agent化。先问一句，今天AI已经进入工作环境，原来的业务系统对这个新执行者友不友好？拿不到数据，干不了活，动不了手，怎么让它接住业务？不只是查询，还要能在授权范围里执行动作。

第二个是企业的方法。流程不只讲一套理想做法，还承载资源有限时的安排和取舍。我在现场说“流程是妥协”，想表达的是，各方要在现实约束下共同完成工作。有时质量优先，有时交期更紧，这些取舍和变化由谁决定、怎样告诉执行者，需要说明白。只有目标、没有条件和优先级，AI就可能围绕局部指标做事。

再往下，要落到岗位和职责：产品运营能不能让AI接一段？稳定性运营能不能接一段？整个岗位做不到，先拆出其中边界清楚的工作。说它能提效，就要说清它能独立闭环哪一部分，哪一步由人判断，遇到例外找谁。员工也随之改变工作方式，更多负责目标、授权、监督和关键取舍。

八、系统改造，从一条关键流程所需的操作开始

我讲“系统CLI化”，核心是在强调系统应当有AI可以稳定操作的入口。这里把几个概念讲准确：API提供程序调用接口；CLI提供命令行操作方式；MCP提供AI应用连接外部数据和工具的一套协议。它们可以组合，MCP可以接API，也可以接其他已有能力，并不一定经过CLI。

我偏好在适合的场景提供清楚的命令、参数和结构化结果，方便Agent组合使用，但不能由此推出所有系统都必须先造CLI，或者CLI在所有任务上都比MCP好。真正要打通的，是这条流程需要的事实、动作、错误状态和结果回执。身份和业务权限仍然要由可信系统校验，接上一个工具不代表获得全部权限。

也不要因此发起一个全面改造所有系统的大工程。当前哪个业务域最重要，哪条流程最需要改善，就先从那里做。重点是业务能不能得到改善。流程管理平台里的文件、规则和方法，也应该逐步成为人和AI能在工作中使用的东西。

九、Skill，就是给AI的SOP

今天请AI进企业是干什么？执行任务。任务在哪里？在流程上。所以Skill要回到业务任务里去建。你请一个人来干活，需要告诉他怎么做；请AI来干活，为什么反而不交代方法、检查要求和例外处理？

我把它概括成一句话：Skill，就是给AI的SOP。这里说的是企业工作方法的类比。技术上的Skill可以包含指令、参考资料、模板和脚本，不只是贴一份SOP文件。把一段工作的触发条件、输入、步骤、输出检查和失败处理整理出来，AI才有可复用的方法；当前业务事实和系统权限还要另外提供。

如果只是全员交作业，最后很容易得到一大堆周报、月报、作图、作表的Skill。一件值多少，谁在用，维护到什么时候，都说不清楚。要回到流程问：哪一个节点需要什么能力？怎样才算做对？业务变了，谁来更新？有了这些，数量才开始有实际意义。

十、我的数字员工实践：在微信中接住咨询与需求

现场我没有只讲概念，也请大家和小詹聊一聊。已经用过的朋友谈了自己的体验，有人把它当作一个能交流工作困惑的对象。对话自然，确实容易让人先感受到它；但单独看聊天能力，还看不到数字员工后面的工作。

它需要记忆，也需要人物关系，需要知道这次是谁来找、以前谈过什么、什么资料可以在这个场景用。再往后，还要能进入获准的工作系统，取得事实、承接任务，把结果带回来。

课件保留的是10月10日的一份快照：526位人物留下了记忆，40个群会话留下了经历，2612条入站事件，以及700条带平台发送回执的出站记录。它们分别反映接触与消息流转，不能直接当作当前好友数、当前在群数或700件业务办结。看运行规模之后，还要追问：什么事情真的做完了，什么地方还需要人。

十一、从入站消息，到任务、行动和真实回执

这张产品大图，大家可以顺着工作来看。消息从实际渠道进来，先留存事件，再判断这是马上回答的问题，还是要持续跟进的一件事。人物关系是什么样，发起者有没有权限，这次请求有没有得到授权，这些都要先处理。像查询学员数据，同一个问题，也不能对所有人都给同样的答案。

带着这些条件，再进入Agent的工作循环：理解当前任务，取得可见的事实和记忆，选择方法和工具，行动，再观察结果。缺材料去追问，需要别人判断就找对应的人，等补充回来以后继续原来的事。模型、运行环境、Skill、系统入口、记忆和关系，需要配合起来。

最后不是“模型说做完了”就结束。系统操作有没有成功，文件有没有交出去，消息有没有发送回执，任务当前停在哪一步，要分别核对并保存。任务记录、唤醒和恢复由运行系统支持，不是靠模型自己记住。图是产品的工作安排；多渠道和各项业务能力，按实际接入与验收分别判断。

十二、替人找负责人之后，还要确认事情走到了哪一步

现场我讲了一个很具体的故事：有一项工作流能力要开通，对方说，这件事请找另外一位负责人。正常情况下，我是不是又要把前面聊过的背景重新讲一遍，再去找人、解释、等答复？

那次我直接把这件事委托给数字助理。它带着前面的上下文找负责人、说明来意。对方反馈已经开通，还给了技术文档。它没有只把这句话转回来，而是读文档、继续尝试。发现还需要管理员重启，就回来告诉我：对方已经处理，但这里还差一步，我没有权限，你需要继续完成。

我当时就问：如果雇一个助理，你希望他只替你转句话，还是替你把事情确认好？你不是转手人。别人说开通了，你有没有试过、有没有验证？做不了的部分说明白，把下一步带回来。这是另一个数字助理的协同样例，不计入小詹的运行数据；负责人反馈开通，也还要等用户最终验证可用。

十三、需求发出去，研发怎样自己往前走？

以前做研发，需求提出来，进入双周迭代，指定开发，开发完了再测试、交给业务验收。产品经理得跟着整段过程走，不断解释、确认和催进度。这也是我一直想改变的事情。

在自己的实践里，需求先进来，由数字员工追问场景和目标，结合已有材料判断哪里还不清楚。决定继续以后，原始对话、已经澄清的结论、当前版本和验收条件进入同一个事项；再按负责人和接入规则，把工作送到开发同学的本地Agent。它沿用已有环境和权限，遇到业务问题找需求方，遇到工程判断找开发方，确认以后继续。

开发完了，结果还要回到需求上验证。能打开页面，只说明页面能打开；还要看原来那条业务动线、那些规则是否满足。测试、审查和必要的人工确认都要接在链路里。

我当时的感受甚至有点复杂：过去很多协同工作，它已经能往前推进，那我做什么？我应该锁定高优先级的需求，好好设计，把精力放到更重要的产品判断上。这条链的价值，也要回到具体需求的交付质量、周期和完整投入来核对，不能只凭某次做得快就说所有研发都翻了多少倍。

问：给员工配AI工具有价值吗？不看用量，又怎样评价成果？

答：可以配。我在现场反复澄清过，我没有说不应该给员工买工具、发Token。就配置生产工具这件事来说，和给员工买电脑有相通之处：你得看他做什么工作，适合什么配置。不能所有人都配同一种，也不能因为暂时算不出精确收益，就否认工具的价值。

有人继续问，老板让我拿出效率提升怎么办？还是拿结果来说话。选一类真实任务，看看以前怎么完成，现在怎么完成；同样范围、质量和风险要求下，周期、人时和返工发生了什么变化。别只看代码多了多少行、材料多了多少份。

还有一个问题：省下来的时间，后来用在哪里？业务有增长，能不能接住更多需求；没有增量，是不是改善了质量或减少了积压？释放工时、避免未来投入和费用真的下降，是不同的事情。评价要把审核、返工、管理维护和AI投入一起算，不能拿一笔调用费直接和一份工资比较。

问：个人能力提高以后，怎样把能力留在组织里？

答：这个追问在现场很有代表性。有人说，我们做组织、做流程，想把能力沉淀到组织上。但现在给员工发工具，A做得更快了，交到B那里却不认、接不住。统一语言、标准和方法，本来就是组织的责任，不能把这个责任全交给员工。

该梳理的流程要梳理，该明确的方法要明确。员工在共同的规则和空间里发挥能力，做出来的方法、资料和经验，再整理成别人可以用的东西。Skill建设、流程建设，本身就承担这件事；但文件进入目录之后，还得有人维护，有有效版本，也要经过别人接手使用的检验。

我在现场提过，人离开以后，沉淀下来的方法和数字员工还可以继续服务组织。这里留下的是企业获准保留的方法、资料和岗位能力，不是让离职人员的个人账号和权限继续有效。方法能够复用，接手的人和系统身份也要重新安排。

问：数据敏感，又担心本地模型跟不上，怎样选择？

答：先回答你做什么业务、处理什么数据、客户提出什么要求，再讨论部署。任务性质、企业阶段和资源条件不同，选择就可能不同。不能看见本地部署就默认安全，也不能看见云服务就默认一定会把数据拿去训练。要核对实际服务条款、数据流向和控制措施。

如果客户或企业要求某些信息不能进入外部服务，就在这个条件下找可行方案，连同模型效果、更新和维护成本一起看；允许进入获准云服务的任务，也可以单独评估。企业把合适的工具和入口配置好，让员工能继续工作。涉及具体敏感业务的合规要求，要在项目里另外核对，不能在沙龙里用一句话替所有企业作结论。

问：受限环境里，AI写代码效果不好，怎么办？

答：这类情况我遇到过。企业限定了设备、模型和工作环境，效果不够理想，先接受这是当前的实际条件，再看还能改善什么。模型是一个要素，运行环境也是一个要素，人的工作方法同样重要。

需求、架构、接口、代码背景要尽量说清楚。任务太大，就拆到能够检查的范围；一步做完，看看是不是满足要求，再往下走。写代码不是只生成一段文本，后面还要能运行、能测试、能审查。

把这些做好，可能改善结果，也有助于定位问题，但不能承诺靠拆任务就能消除所有模型差距。要看失败是缺资料、理解错误、工具不可用，还是能力确实到不了，再作选择。

问：我的工作很复杂，想“蒸馏自己”，从哪里开始？

答：现场有朋友说，我的工作层次很多，既有重要判断，也有大量琐事。我把资料都接进去，让AI分，结果有点乱。我的第一反应是：先把最核心的岗位和职责找出来。你有目标吗？你最关心哪一层？这些要由你和AI一起讨论。

然后再看你的真实工作。过去一天、一个月，你在做哪些事？哪些事情反复发生？哪些判断有标准，哪些是你凭经验在做？在获准范围内，让它接触与任务相关的记录和资料，再帮你刻画工作画像。AI整理出来的画像，还需要你逐项确认。

琐碎、高频、规则清楚的，可以逐步交给AI；价值高、规则不稳定的，要先梳理做法，判断AI干到哪里、你干到哪里。比如周报，AI先按约定把进度、风险和待决定事项读出来，你仍然负责核对重要问题、作评价和沟通。

“蒸馏自己”，是把自己的判断与工作方法提炼清楚。这里不是把一个人训练成模型，也不等同于机器学习里的知识蒸馏。很多时候，把经验摆到面前，才会发现自己原来并没有把标准想得那么清楚。

问：AI越来越强，个人怎样发挥更大的价值？

答：我想稍微多讲一点“蒸馏自己”这件事。很多时候我们其实不了解自己，做判断也有随性的一面。只有把那些判断摆到面前，才会继续问：我为什么这样做？做得对吗？如果换个条件，我还会这样选吗？这个过程会把相对模糊的判断，慢慢变得更清楚。

你也会看到自己的标准：哪些地方有依据，哪些只是习惯；哪些已经能够交给别人，哪些还需要自己继续想。把自己梳理明白，可能很费力，也可能迎来一个“啊，原来是这样”的时刻。我自己很喜欢做这件事，帮别人刻画工作画像，也回过头来梳理自己：哪些事自己做，哪些交给AI或别人，怎样更好地协同。

还有一个更实际的问题：你有没有给自己的学习建立一个有效闭环？听了很多课，知道很多概念，最后能不能对别人讲清楚一个问题，能不能给别人一份真正有用的东西？如果一直停在输入，别人也很难知道你的能力在哪里，你自己也得不到足够的反馈。

可以从自己熟悉、有真实需求的一件事开始。尝试做一次讲解、一份方案、一个工具，或者围绕一个有把握的问题做一段咨询。交出去以后，听对方说哪里有用、哪里不清楚，再回来改。不会表达，就练表达；方法还不完整，就补方法；别人不知道你能做什么，就把已有成果讲明白。不是每个人一开始都有成熟服务，但可以这样逐步找到自己的价值。

我也在用这样的方式持续做：有机会去交流、去分享，回来写文章，得到别人的认可和反馈，再继续往前走。有人更擅长行业判断，有人擅长把复杂问题讲清楚，也有人善于把事情协调起来。每个人可以找到不同的发挥空间，不需要都走同一条路。

为什么我喜欢AI？因为它让每个人有机会发现自己的闪光点，再借助AI不断强化，做出属于自己的结果。这个结果可以是在企业里承担更重要的工作，也可以是在有真实能力和需求的前提下，对外提供咨询、培训或产品。把学习、实践和反馈连起来，让自己创造的价值被真正看见。