昨天和几位做咨询、报道咨询行业的老师聊天。聊到 AI 的时候，一个问题反复出现：
“能不能给我一条完整学习路径？第一步学什么，第二步学什么，第三步学什么？”
这个问题很自然。
过去学一门技能，大家习惯先拿目录。先概念，后工具。先原理，后实操。最好再配一套课程、一张路线图、一份书单。
但 AI 这件事，偏偏不是这样学会的。
你可以先学什么是大模型，什么是 agent，什么是 workflow，什么是 RAG，什么是 MCP。学完以后，大概率还是不知道明天早上该怎么把它用进自己的工作。
因为 AI 不是一门只靠听课获得的知识。
它更像一种新的工作肌肉。
肌肉不是听懂的。肌肉是练出来的。
一、高手不是在学 AI，是在用 AI
我观察过不少真正用得好的人。
他们有一个共同点：他们很少从“我要系统学习 AI”开始。
他们通常是被一个具体问题逼进去的。
要写一份报告。要拆一个项目。要做一批访谈纪要。要改一个工作流。要给团队搭一个助理。要把一个重复动作变成半自动。
他们带着自己的问题去问 AI，带着自己的材料去试工具，带着自己的工作流去拆任务。
一开始也会失败。
AI 会理解错。会漏条件。会编答案。会写出看似完整、实际不能用的东西。可是这些失败不是坏事。
它们会把边界暴露出来。
你会知道，哪些问题适合交给 AI。哪些必须给例子。哪些要加约束。哪些要拆成步骤。哪些要补知识库。哪些必须做评测。
这才是学习。
公开调研也能解释这种体感。
McKinsey 2025 年关于职场 AI 的报告里有一个很有意思的发现：员工对生成式 AI 的熟悉度很高，但组织真正把 AI 深入工作流的比例仍然有限。另一份全球调研显示，很多企业已经在用 AI，但大多数还处在试验和试点阶段。
这说明一个问题：
大家并不缺“知道 AI 很重要”。真正缺的是把它塞进具体工作的那一下。
二、最难的不是工具，是把自己的工作讲清楚
很多人听到“结合场景”这四个字，会觉得很简单。
其实一点也不简单。
你要先说清楚：你每天到底在处理什么信息？输入是什么？输出是什么？中间判断标准是什么？哪些动作重复？哪些地方容易错？哪些环节只需要起草，哪些必须你亲自判断？
这一步，往往比安装工具更难。
因为一个人要把自己的工作讲明白，本身就需要抽象能力。
很多时候，你不是不会用 AI。你是没有把自己的工作拆到 AI 能接手的粒度。
所以我现在很少建议别人先去上十节概念课。
我更愿意让他拿一个真实任务来。
比如一份客户材料。一次访谈录音。一份流程文件。一个合同审批。一个周报场景。一个投研小需求。然后我们现场拆：
1 这件事原来怎么做？
2 哪一步最耗时间？
3 哪一步有明确标准？
4 哪一步能先让 AI 打底？
拆完以后，再去找工具。
这时候工具才会变得具体。
三、没时间，就买时间
很多人卡在这里，不是因为笨。
是因为他没有时间。
一个咨询顾问、记者、法务、投研、项目经理，本来就被日常任务压着走。你让他自己研究工具、自己拆流程、自己看文档、自己试错，他很容易停在第一步。
这个时候，最现实的选择不是继续收藏资料。
而是花钱买时间。
找一个懂行的人，陪你把工作流梳理一遍。帮你判断哪些值得做，哪些先别做。帮你把工具装好，把权限跑通，把第一个场景做出来。
你买到的不是一套课。
你买到的是少走三个月弯路。
这件事在 AI 上尤其重要。因为很多阻力不是知识阻力，而是操作阻力。
比如你想要一个工作助理。
其实今天像飞书智能伙伴这类企业 AI 工具，已经能在授权范围内连接知识、技能、工作流和任务触发。它不是一个只能聊天的窗口，而是可以进入业务流程的应用。
但问题来了。
很多人看到“部署”“授权”“权限”“发布”，马上就紧张。
明明只差两步，却像隔着一堵墙。
所以我越来越相信，AI 培训不能只讲。
必须让人当场动手。
不动手，他只是听懂了一个道理。动手以后，他才第一次感到：原来这东西真的能替我做事。
等一个场景真的跑通以后，下一步才是沉淀。
也就是把这次有效的做法，变成下次还能复用的规则。
这时候，skill 才有意义。
四、Skill 很好，但它不是许愿纸
现在很多人开始热衷于写 skill。
这个方向是对的。
但我也想泼一点冷水：skill 不好写。
如果只是写一句“请帮我生成高质量报告”，那不叫 skill。那只是一个愿望。
真正可用的 skill，背后一定有清晰的规则、步骤、样例、边界和校验方式。
它本质上像一段被沉淀下来的工作代码。
哪类输入可以处理。输出分成几段。每段标准是什么。遇到信息不足怎么办。什么时候要联网。什么时候要追问。什么时候必须调用脚本。什么时候要拒绝。
这些都要写清楚。
GitHub 的 Copilot skills 文档里，也能看到这种结构：一个 skill 通常包含说明文件，也可以附带脚本、示例和资源。也就是说，skill 不是一句提示词，而是把经验封装成可复用的工作单元。
所以我支持大家学 skill。
但别幻想一次写完。
更好的方式是：
把它当成一个需要不断调试的工作部件，而不是一次写完的文档。
这条路要自己走。
因为你的工作标准，别人不知道。
别人最多给你一个框架。真正有价值的部分，来自你对业务细节的拆解。
五、不要从零开始，先去抄一个能跑的
这里的“抄”，不是偷懒。
是工程里的正常方法。
如果你想做一个 skill，最好不要从空白文档开始。
去找类似的。去看别人怎么写。去看它的目录、说明、脚本、测试样例。先让 AI 帮你读懂，再基于你的场景改。
很多人不知道 GitHub，也没关系。
你不需要先学完 GitHub。
如果你的工具具备联网和本地文件权限，你可以直接在类似 Cursor、Copilot、Codex 这类工具里说：
“我要做一个某某 skill，请到 GitHub 找几个星级高、维护活跃、结构清楚的类似项目，帮我比较，然后下载到本地，基于其中一个改。”
这句话就够了。
GitHub 本身支持按仓库、星标、语言、主题等条件检索。你不必把它当成一门课来学。你只要知道，它是全世界大量开源方案的仓库。
真正重要的是下一步：
让 AI 帮你读。
让 AI 帮你改。
让 AI 帮你解释为什么这么改。
让 AI 帮你做第一版评测。
六、评测，才是 skill 能不能用的分水岭
很多 skill 看起来很漂亮。
一跑，就露馅。
因为它没有评测。
评测不是问一句“你觉得好不好”。
评测至少要回答四个问题：
1 它在典型样例上能不能稳定输出？
2 它在边界样例上会不会乱来？
3 它有没有明确评分标准？
4 每次修改以后，老问题会不会复发？
OpenAI 的评测文档也把这件事讲得很清楚：AI 系统有不确定性，所以不能只靠传统测试。要定义目标、收集样例、设置指标、反复运行，并持续评估。
对 agent 来说，还要看它有没有选对工具、有没有正确交接、有没有违反约束。
这就是为什么我说，写好 skill 很花时间。
真正的难点，不是让 AI 写出第一版。
是让它第十次、第一百次，在不同材料上仍然稳定可用。
七、行动力是第一门槛
最后还是回到那句话：
很多人不是不知道。
他其实知道要用 AI。知道要结合场景。知道要找工具。知道要动手。
但他没有开始。
他会说：“我需要一个工作助理。”
然后停在那里。
他会说：“谁能帮我做一个？”
然后继续停在那里。
真正的变化，通常来自一个很小的动作。
今天装一个工具。今天授权一次。今天拿一份真实材料试一下。今天让 AI 帮你改一版流程。今天把一个重复动作写成 skill 草稿。今天拿三个样例测一下。
AI 的学习，不是等你准备好了才开始。
它是你开始以后，才慢慢准备好。
结尾：别把 AI 学成一门旁观的课
如果你真的想把 AI 用起来，我建议你先别问“完整路径是什么”。
先问一个更小的问题：
我这周最想省掉哪三个小时？
从这三个小时开始拆。
把任务输入找出来，把输出标准写下来，把中间动作列出来。然后找一个 AI 工具，让它参与其中一小段。不要贪大。先让它起草，先让它归纳，先让它检查，先让它把乱材料整理成结构。
跑通以后，再沉淀成提示词。提示词稳定以后，再写成 skill。skill 能跑以后，再做评测。评测通过以后，再交给团队复用。
这就是能力迁移的路径。
你不是从“懂 AI”迁移到“会工作”。你是从“懂自己的工作”迁移到“会让 AI 参与工作”。
这两件事差别很大。
前者容易变成收藏课表。后者会逼你整理流程、定义标准、沉淀经验、修正判断。它会让你重新理解自己的专业。
所以我现在给身边人的建议很简单：
不要再把 AI 当成一门遥远的新学科。
把它当成一个坐在你旁边、需要你训练、也会反过来训练你的工作伙伴。
今天就拿一件真事交给它试一次。
让它先做一版。你看它哪里做不好，再改规则、补样例、加评测。
AI 的学习，就在这一次次真实交手里发生。
参考资料
1. McKinsey: Superagency in the workplace
2. McKinsey: The State of AI 2025
3. GitHub Docs: Adding agent skills for GitHub Copilot
4. OpenAI API Docs: Evaluation best practices
5. 飞书智能伙伴 Aily：应用场景与能力介绍