企业内部 AI 落地方法论：从「发账号」到「建体系」，数字效能经理的实战笔记

过去一年我在一家医疗器械企业做内部 AI 数字效能经理，职责很朴素：把大模型真正塞进同事的日常工作里，而不是停留在「全员发了账号」的阶段。这一年里见过太多失败案例——预算花了、license 买了、培训做了，三个月后登录率跌到个位数。复盘下来，失败的根因几乎从来不是「模型不够强」，而是组织把「买账号」当成了「落地」。这篇文章按我实际走过的四个阶段拆开讲，最后单独写一节数据安全红线。不写营销话术，只写实战。

1 · 第一阶段「发账号」：为什么使用率永远上不来

几乎所有企业的 AI 起点都是同一个动作：IT 统一采购一批大模型账号（或企业版 SaaS），全员开通，发一封邮件「大家可以用了」。这个动作本身没有错，但它制造了一个幻觉——以为工具到位等于能力到位。

我观察到的真实数据：账号开通后第一周使用率很高（新鲜感驱动），第二周开始下滑，第三周跌破 30%，一个月后稳定在 10%–20%。原因不是员工抵触新技术，而是三个结构性问题：

• 不知道什么场景用。「你可以用 AI 写文档」这句话对销售、研发、行政、质控意味着完全不同的事。员工面对一个空白对话框，第一反应是「我该问它什么？」——大多数人想三秒就关掉了；
• 不知道怎么问。Prompt 工程不是员工的本职工作。让一个写检验报告的工程师去学「角色设定 + 思维链 + Few-shot」，学习成本远高于他自己写一遍；
• 不知道能信多少。大模型一本正经地编内容，员工试两次发现答非所问或数据错误，就再也不敢用在正式工作里——这是信任崩塌，比工具不好用更难修复。

所以第一阶段真正的产出不是「账号覆盖率 100%」，而是一组真实使用数据：谁在用、用什么、问什么、卡在哪里。这组数据是第二阶段的输入，没有它，后面全是凭空设计。

2 · 第二阶段「找场景」：蹲下来看真实工作流

第二阶段的核心动作不是「推 AI」，而是找那些已经在发生的、高频重复的人工劳动。我自己的做法是每周花两个半天，跟着不同岗位的同事坐旁边看他们干活——不介入、不指导，只记录：这个动作重复几次、花多少时间、卡在哪。

一轮观察下来，高频重复劳动通常集中在三类：

• 信息搬运类：从 A 系统导出数据 → 复制到 B 系统 → 整理成表格 → 发邮件。这类工作 AI 价值最大，因为它没有创造性判断，纯流程；
• 文档起草类：周报、检验报告初稿、供应商邮件、会议纪要——员工知道要写什么，但每篇都要从头敲；
• 知识检索类：「去年那个客户的投诉是怎么处理的？」「这个型号的注册证号是多少？」——答案就在公司文档库里，但没人记得在哪。

这三类场景对应三种解法。信息搬运类用低代码工作流（飞书多维表格 + 自动化流程、或类似平台），把「导出-整理-发送」串成一条自动跑的链路；文档起草类用 LLM + 提示词模板，把岗位同事的真实范例喂进去做 Few-shot；知识检索类则是下一节要讲的 RAG 知识库的前身——先把分散文档收拢到一个可检索的地方。

这一阶段我反复验证的一个结论：低代码能解决 80% 的场景，代码只解决剩下 20% 的技术难题。销售要的不是一个完美的 Python 脚本，而是「我填一个表单，AI 自动生成跟进邮件草稿」——这件事飞书低代码两小时就能搭出来，写代码反而要两周。不要一上来就建技术中台，先把 80% 的高频场景用最低成本跑通。

3 · 第三阶段「建体系」：知识库 + 工作流 + 安全规范三件套

第二阶段跑通几个单点场景之后，一定会撞上一个问题：每个场景都是孤岛。销售的 AI 助手不知道研发的文档，研发的知识库看不到销售的客户记录，工作流之间数据不通。这时候必须从「点」升到「体系」。

我把体系期的最小闭环拆成三件套：

3.1 知识库（RAG）：让 AI 说公司的话

通用大模型不知道你公司的产品参数、注册证、SOP、历史客户案例。RAG 的本质是把企业内部文档向量化后做检索增强，让 AI 回答时基于你公司的真实语料，而不是它训练时看到的互联网碎片。

实战里最容易踩的坑是「什么都往里灌」。我的经验是语料必须分桶：制度类文档重结构化（条款、编号、生效日期要保留）、技术文档重解析质量（PDF 表格、插图是丢分重灾区）、项目笔记重清洗（去会议纪要里的闲聊段落）。用同一条 pipeline 硬吃所有格式，检索质量一定崩。待验证 万份文档级别的向量检索性能与召回率衰减曲线。

3.2 工作流（自动化）：把 AI 嵌进业务，而不是让业务找 AI

员工最省力的方式不是「打开一个 AI 对话框」，而是AI 出现在他本来就要用的系统里。飞书低代码、多维表格、审批流这些员工每天已经在用的工具，是嵌入 AI 的最佳载体——填完表单自动生成邮件、审批通过自动同步到 CRM、会议结束自动生成纪要并归档。

工作流和 RAG 的区别在于：RAG 是「人找答案」，工作流是「事情自动发生」。前者解决检索效率，后者解决重复劳动。两者要同时建，单建一个都会回到孤岛。

3.3 安全规范：合规不是事后补丁

安全规范必须和知识库、工作流同步设计，不能等合规来查才补。具体到医疗器械行业，敏感数据（患者信息、临床数据、注册证核心参数）一旦进入 LLM 的上下文，就存在外传风险。这一节我会在第 5 节单独展开。

4 · 第四阶段「团队赋能」：把 AI 能力还给员工

体系建完之后，最危险的状态是「AI 团队变成少数专家的玩具」。三个工程师搭了所有工作流、调了所有 prompt，其他同事只是被动使用者——一旦这三个人离职，整个体系就塌了。

第四阶段的目标是把使用率从「专家依赖」拉到「全员可用」。我的做法有三件事：

• 场景化培训，不是工具培训。不讲「什么是 prompt」，讲「销售每周写跟进邮件这个动作，怎么用 AI 十分钟搞定」。按岗位分组，用真实案例练，而不是通用大课；
• 内部分享机制。每月一次「AI 实战 30 分钟」，让用得好的同事上来讲他省了多少时间、怎么调的。peer 讲 peer，比我们这些「AI 团队」讲一百遍都管用；
• 代码辅助下沉。对有技术基础的同事（研发、质控、数据），开放代码辅助工具，让他们能自己写简单的脚本和查询，而不是所有需求都排队等 IT。降低门槛比提升能力更快见效。

这一阶段最核心的优势是快速迭代。内部用户就在隔壁工位，同事用完第二天就拉你说「这个回答不对」，你当场改 prompt、当天重新发布。这种反馈-调整的闭环可以做到分钟级——这是任何外部 SaaS 厂商永远做不到的，因为他们离用户太远。推断 这套闭环速度是内部数字效能岗的最大护城河，而非技术本身。

5 · 数据安全红线：医疗器械行业的三条硬约束

最后单独写安全，因为这件事在医疗/合规行业是一票否决。系统再好用，一次数据泄露就全停。我把实战中沉淀的三条红线列出来：

5.1 敏感数据脱敏 / 编码替代

患者姓名、住院号、身份证号、临床数据，绝对不能以明文形式进入 LLM 的 prompt 或知识库。我的做法是在工作流入口做一层编码替代：真实患者信息映射成「患者 A / P-1024」这种内部代号，AI 只接触代号，业务系统保留对照表。这样 AI 能辅助写病历摘要、做质控分析，但它永远不知道「A 是谁」。这一层必须做在数据进入模型之前，不能指望员工自觉。

5.2 单人单 Agent 不混用

不同岗位、不同数据权限的员工，不能共用同一个知识库或同一个 Agent。销售的提问不应该能召回研发的注册文档，质控的检索不应该能看到销售的客户信息。技术上通过分库 + 分权限实现：每个岗位群一个独立的 RAG 命名空间，Agent 的检索范围按角色硬隔离。混用一次，权限模型就漏一次。

5.3 最小权限原则

每个员工、每个 Agent 拿到的数据范围，只覆盖他本职工作必须的那部分。开放权限之前先问一句：这个人真的需要看到全部 200 份文档吗，还是只需要他所在项目的 20 份？默认收紧、按需开放——这不是不信任员工，而是合规审计的基本盘。一旦审计追溯，你能说清「谁在什么时间、基于什么权限、访问了什么」，这比「我们觉得没问题」重要一百倍。

这三条红线写起来只有三行，但每一条背后都是一次差点出事的教训。安全规范不是文档里的一段话，是要嵌进工作流入口、权限配置、检索逻辑里的硬代码——靠自觉的安全，等于没有安全。

FAQ

边界声明

参考来源