不少公司的 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 中选择。培训前要统一好版本和账号，不要让每个人临时注册一套完全不同的工具。
工具不需要多，但必须能登录、能使用，也知道出了问题找谁。
培训材料里最好直接放官方入口，避免学员搜索到名称相似的第三方站点：
这些工具信息核对于 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，不是多教会一个软件。
它是在训练大家把工作讲清楚，把经验留下来，把重复动作交出去，同时知道最后那一步判断仍然属于谁。
员工能带走一条真实可用的流程，比记住一百条提示词更有价值。
暂无评论