不少公司的 AI 培训都挺热闹。老师在台上演示 ChatGPT 或 Claude，十几秒写出一封邮件，再生成一张图。中间讲几种提示词结构，大家跟着复制一遍，效果确实不错。培训结束时，每个人都觉得 AI 很厉害。第二天回到工位，该怎么开会还是怎么开会，该怎么整理表格还是怎么整理表格。开发继续自己查日志，销售继续把客户记录留在微信里，培训群慢慢也没人说话了。后来复盘，最容易得到的结论是员工主动性不够。我倒觉得不一定。如果培训里做的是旅行计划、营销文案和通用邮件，员工学会的只是“这个工具能聊天”。他回到真实工作以后，面对公司代码、客户资料、审批流程和一堆历史文件，还是不知道从哪里下手。所以我现在看 AI 培训，验收标准很简单。不是员工听懂了多少概念，也不是现场生成的内容有多惊艳。而是培训结束以后，每个人手里有没有一条明天就能继续使用的工作流程。培训前，先让每个人带一件麻烦事来课程开始前，我会让参加培训的人先交一份很短的作业：我每周重复做的工作： 这件事一次要花多久： 需要找哪些资料： 最后要交付什么结果： 最容易错在哪里： 哪些内容不能交给 AI：开发人员可以带一个真实但范围不大的缺陷，产品经理可以带一段已经脱敏的会议记录，销售可以带一次客户沟通，行政可以带一份入职流程，财务可以带一张去掉敏感信息的对账表。这一步很重要。员工没有真实任务，老师就只能讲通用案例。通用案例越顺，回到公司以后的落差通常越大。部门负责人也要提前看一遍这些任务。有些人带来的工作一个月只做一次，不值得优先改；有些任务涉及付款、合同承诺或生产控制，风险太高；还有些工作连现有流程都说不清楚，暂时也不适合直接自动化。第一批训练任务，最好高频、可验证、做错能撤回。培训不是让大家拿 AI 冒险，而是先找到一块安全的练习场。账号和数据边界，要在上课前准备好培训里经常会出现一种挺尴尬的场面。培训开始了，开发人员还没装 Claude Code，销售没有会议转写权限，行政同事注册不了海外工具。老师演示得很流畅，学员只能看。看懂和会做不是一回事。培训前，公司至少要准备一份批准工具清单。比如：研发允许使用 Claude Code、Codex、Cursor 或 GitHub Copilot 中的哪些工具；通用办公使用 ChatGPT Enterprise、Claude Team/Enterprise、Microsoft 365 Copilot，还是公司统一接入的模型；内部知识问答使用 Dify、FastGPT 或飞书智能伙伴；流程自动化使用 n8n、Power Automate、Make 还是 Zapier；哪些账号由公司统一购买，哪些个人账号禁止处理公司资料。如果公司优先使用国内工具，研发组可以准备通义灵码、百度 Comate 或 Trae，通用办公可以测试 DeepSeek、通义千问、Kimi 或豆包，知识库可以从 FastGPT、Dify、RAGFlow 或 MaxKB 中选择。培训前要统一好版本和账号，不要让每个人临时注册一套完全不同的工具。工具不需要多，但必须能登录、能使用，也知道出了问题找谁。培训材料里最好直接放官方入口，避免学员搜索到名称相似的第三方站点：Claude CodeCodexDifyFastGPTn8n通义灵码百度 Comate飞书妙记这些工具信息核对于 2026 年 7 月 11 日。正式培训前，应再次检查账号、价格、企业数据政策和国内访问情况。数据边界可以先用很直白的红黄绿规则。绿色数据是公开资料、公开代码和已经发布的产品信息，可以进入公司批准的通用 AI 工具。黄色数据是内部制度、项目文档、未发布代码和普通客户资料，只能进入企业账号、批准的 API 或私有部署系统，并且要按权限访问。红色数据包括密码、密钥、未脱敏个人信息、付款账号、核心商业机密和高敏感客户数据，不能直接提交给模型。这个规则不一定一次就很完善。但如果完全不讲，员工要么什么都不敢用，要么把生产密钥和客户资料一起粘进个人聊天账号里。两种结果都不是公司想要的。开场不要先讲模型原理第一节课经常花很多时间介绍大模型发展、参数规模、Token 和提示词公式。这些内容不是完全没用。但员工最先需要学会的，是怎样把一件工作交代清楚。我更愿意先给大家一张任务说明卡：背景：这件事为什么要做，现在是什么情况。 资料：允许使用哪些文档、代码、表格和历史记录。 任务：这一次具体要完成什么。 约束：哪些目录不能改，哪些结论不能猜，哪些规则必须遵守。 输出：结果要用什么格式交付。 检查：怎样判断完成，哪些地方必须由人确认。这比背一套“角色、目标、步骤、格式”的提示词口诀更有用。因为它本质上不是在学习怎么跟 AI 聊天，而是在学习怎么定义工作。一个人如果连自己要什么、有哪些限制、怎么验收都说不清楚，换再强的模型也很难稳定做好。不同岗位，不要坐在一起练同一道题通识部分可以一起上。真正实操时，必须按岗位拆开。技术组使用 Claude Code、Codex、Cursor、GitHub Copilot 和 CodeRabbit，练习代码分析、修改、测试和 Pull Request 审查。产品和运营组使用 Claude Projects、ChatGPT Projects、飞书妙记、Notion AI、Figma Make 或 Gamma，练习把会议记录变成待确认问题、需求和原型。销售和客服组使用 Gong、Fireflies.ai、飞书妙记、HubSpot Breeze、Dify、FastGPT 或 Chatwoot，练习客户信息提取、CRM 回写和建议回复。财务与行政组使用 Excel Copilot、Power Query、Power Automate、UiPath 和 OCR 工具，练习资料提取、表格核对、制度问答和流程提醒。工具并不是每一种都要买。分组的目的是让大家面对自己的工作，而不是让财务跟着开发人员学怎么生成单元测试，也不是让开发人员坐两个小时看市场部生成海报。第一周，只解决一项个人工作第一周不要急着做 Agent，也不要接公司系统。每个人只处理课前带来的那一项任务。技术组可以从一个真实缺陷开始。先让 Claude Code 或 Codex 阅读 Issue 和相关代码，只输出影响范围、修改方案和风险，不允许马上改文件。开发人员确认方向以后，再让 Agent 创建分支、修改代码并执行测试。最后由本人解释每一处修改为什么可以接受。产品组可以把一段飞书妙记交给 Claude Projects，要求区分客户原话、产品判断、待确认问题和任务草稿。产品经理回到原文逐条核对，看看 AI 是在哪里把“可能需要”写成了“确定要做”。销售组可以让 Fireflies.ai 或飞书妙记生成转写，再提取客户角色、需求、异议、承诺和下一步行动。结果先放在草稿区，由销售确认后再录入 CRM。行政组可以拿一份员工手册，用 Dify 或 FastGPT 做一个小型制度问答。先准备二十个员工真的问过的问题，看答案有没有来源、有没有引用过期条款。第一周结束，每个人只需要回答三件事：原来一次要花多久；现在要花多久；AI 最容易在哪一步犯错。能回答清楚，第一周就没有白练。第二周，把个人用法变成部门流程个人用得顺，不代表团队能复用。第二周要做的，是把第一周的成功和失败写下来。比如技术组发现，一张任务单只写“修复登录问题”远远不够，还需要说明影响范围、现有组件、测试命令和不能调整的接口。那就把这些内容放进 Issue 模板和仓库的 AGENTS.md、CLAUDE.md。销售组发现，AI 经常把客户的试探性表达当成正式需求，就在模板里增加一条规则：必须区分客户原话、销售判断和待确认事项，并且保留时间戳。客服组发现，退款问题最容易答错，就把退款、合同和投诉统一列为强制转人工，不再让模型尝试生成最终承诺。这时候形成的东西，可以是一份模板、一张检查清单、一条 SOP，也可以是 Claude Code、Codex 或 Dify 能调用的 Skill。名字不重要。重要的是下一位同事不需要重新摸索一遍。第二周结束时，每个小组至少要交付：一份可以重复使用的任务模板；一组修改前后的真实结果；一份 AI 常见错误清单；一个明确的人工确认节点；一位负责后续更新的人。第三周，再考虑把工具连起来很多培训一开始就演示自动化工作流。屏幕上节点一串，消息一来，AI 自动处理，再发到另一个系统，视觉效果很好。但如果前两周连输入、规则和人工边界都没有跑稳，自动化只会让错误传播得更快。第三周再使用 n8n、Power Automate、Make 或 Zapier，把已经验证过的步骤串起来。销售场景可以这样做：飞书妙记产生会议记录 → n8n 调用 Claude 或企业模型 → 提取客户需求和下一步行动 → 发送给销售确认 → 确认后写入 CRM → 到期发送跟进提醒客服场景可以让 Dify 或 FastGPT 检索知识库，生成带来源的建议回复，再通过 Chatwoot 进入客服工作台。研发场景可以让 Claude Code 或 Codex 完成分支修改和测试，再交给 GitHub Actions 或 GitLab CI 构建测试环境。生产发布仍然等待人工批准。第三周主要练的不是怎么拖节点。而是失败以后怎么办：模型超时是否重试，写入 CRM 失败是否保留草稿，知识库没有答案是否转人工，Agent 执行一半是否有日志可以追。能处理失败的流程，才有资格叫自动化。第四周，不考试，直接做工作演示我不太建议用选择题考核 AI 培训。让学员解释什么是 Prompt、RAG 和 Agent，分数可能很高，跟实际工作仍然没有关系。第四周直接做一次十五分钟的工作演示。每个人展示同一件任务以前怎么做、现在怎么做。现场说明使用了什么工具，输入从哪里来，结果由谁确认，遇到错误怎么退回，以及一个月大概能省多少时间。验收时可以用这张表：验收项要回答的问题时间单次耗时从多少变成多少质量返工、遗漏和错误有没有增加采用AI 结果有多少可以直接使用，有多少要重做风险哪些动作仍然由人确认复用其他同岗位员工能不能照着做维护工具、模板和资料由谁更新如果一条流程只能由培训里最懂 AI 的那个人运行，它还没有真正进入团队。换一位同岗位员工也能照着完成，才算通过。培训结束，要留下一个公司自己的案例库很多培训结束以后，只留下课件和录像。真正有用的内容，反而散落在学员的聊天记录和个人文档里。可以在公司内部建立一个很简单的目录：ai-playbook/ approved-tools.md # 公司批准使用的工具和账号类型 data-rules.md # 数据分级与禁止事项 departments/ engineering/ # 研发任务模板、AGENTS.md 示例 product/ # 会议转需求模板 sales/ # 客户跟进流程 support/ # 知识库与转人工规则 finance/ # 对账和复核流程 failures/ # AI 出错案例与处理办法 metrics/ # 改造前后的效果记录这个目录可以放在 Git、Notion、飞书知识库或公司文档系统里。内容不要只由培训老师维护。每个部门找一位真正每天做这项工作的人负责更新，每两周花半小时整理新问题。AI 工具变化很快，课件很容易过期。但公司自己的任务、错误案例和判断边界，会越来越有价值。培训老师不能成为永久客服培训刚结束的两周，问题通常最多。这个时候如果没人接，员工遇到两次错误就会回到原来的做法。如果所有问题都找外部老师，培训成本又会一直持续。比较现实的办法，是每个部门选一位内部种子用户。他不需要最懂模型，但要熟悉本部门工作，也愿意把问题记录下来。培训期间和外部老师一起跑案例，培训后负责每周一次短时间答疑。遇到工具配置、权限和系统集成问题，再由技术部支持。遇到流程边界和业务判断，仍然由部门负责人拍板。这样责任不会全落在一个“懂 AI 的人”身上。不要把使用次数变成绩效如果公司要求每个人每天必须使用 AI 十次，很快就能得到很好看的数字。但员工也会很快学会完成这个数字。打开聊天窗口、问几个无关紧要的问题，并不会改变工作。真正值得跟踪的是任务层面的结果：一项工作节省了多少时间；AI 结果被人工接受的比例；返工和错误有没有增加；有多少个人做法变成了团队模板；培训结束一个月后，这条流程还在不在运行。有些任务用了 AI 以后没有更快，甚至更麻烦，也很正常。把它停掉就好。培训不是证明 AI 适合所有工作，而是让团队学会判断哪些工作值得使用，怎样使用才不会把风险一起放大。说到底，公司培训员工用 AI，不是多教会一个软件。它是在训练大家把工作讲清楚，把经验留下来，把重复动作交出去，同时知道最后那一步判断仍然属于谁。员工能带走一条真实可用的流程，比记住一百条提示词更有价值。