夜雨聆风
最近，一位朋友问了我一个很典型的问题：她想转向 AI，但并不打算成为算法工程师或 Agent 架构师。她更希望懂得如何使用 AI、与多个 Agent 协作，再把自己的产品、组织与业务经验带进来。
很多准备转型的人都卡在这里：要不要先学编程？要不要把大模型原理学透？Prompt、Agent、Skill、MCP、知识库、工作流，究竟从哪一个开始？工具每天都在变，刚记住一个名字，下一个新概念又出现了。
聊了一个多小时后，我们得到的答案反而很简单：AI 转型不是先把自己变成技术专家，而是先获得一种新的工作能力。你要能判断 AI 能做什么，能把一个真实问题交给它完成，能识别结果为什么不可靠，并逐步把一次成功变成可重复的流程。
你真正要学习的，不是某个工具的按钮，而是如何把一项工作教给 AI，再判断它做得是否值得信任。
一、先确定终点：你不一定要成为 AI 工程师
谈学习路径之前，先把“AI 转型”拆开。不同目标，需要的技术深度完全不同。最常见的路径大致分为三层：
AI 使用者会选择模型与工具，用 Agent 完成研究、写作、分析、编程和日常工作。
AI 方案设计者能把业务流程、专家经验和质量标准整理成 Skill 或 Workflow，并推动团队使用。
AI 应用开发者能接入模型 API，在现有产品里开发稳定、可维护的 AI 功能与智能体。
对大多数产品、运营、咨询、组织发展或业务背景的人来说，第一阶段不必直接冲向第三层。更合适的目标是：先成为熟练的 AI 使用者，再成为能把业务翻译成 AI 方案的人。
这并不是降低要求。恰恰相反，企业真正缺少的，常常不是会调用一个模型接口的人，而是能看懂业务、梳理流程、提炼专家知识，并判断一个问题究竟该用 Prompt、Skill、Workflow，还是需要开发独立应用的人。这种判断本身就是能力。
二、基础要学，但只学“能改变判断”的部分
AI 的基础知识当然重要。只是学习目标不该是背术语，更不是从头啃完机器学习论文。对转型者而言，一套够用的知识地图只需要回答四类问题。
1. 大模型为什么会回答，也为什么会犯错
需要了解预训练、微调与后训练大致在做什么，知道模型是在预测下一个最可能出现的内容，而不是在数据库里检索“标准答案”。一旦理解这一点，你会自然重视上下文、证据、验证和边界条件，也会知道“说得像真的”不等于“事实正确”。
2. Agent 比聊天机器人多做了什么
聊天机器人主要回答问题；Agent 会围绕目标进行规划、执行、调用工具、检查结果，再继续下一轮。理解这条循环，你才能看懂各种 Agent 产品的共同结构，也不容易被界面与营销词汇带偏。
3. Skill、MCP、子 Agent 和上下文分别解决什么问题
这些概念不要孤立地背。Skill 用来沉淀稳定的步骤与专家经验；MCP 让 AI 连接外部工具和数据；子 Agent 适合把垂直任务交给独立角色处理；上下文管理决定 AI 在当前任务里看到了什么、遗漏了什么。记住它们解决的问题，比记住定义更有用。
4. 不同模型的能力边界在哪里
有的模型擅长编码，有的擅长推理，有的更适合图片、音频或视频。学习模型不是追排行榜，而是形成任务与能力的匹配意识：这项工作需要长文本理解、工具调用、视觉生成，还是严格的逻辑检查？
如果一个概念不能帮助你更好地选择工具、设计任务、定位错误或评价结果，暂时不必深挖。先把它放回真实任务里，再决定是否补课。
学习材料也不需要囤太多：一套讲清大模型训练与使用方式的通识内容，例如 Andrej Karpathy 的公开视频；一套能陪你完成个人网站的实操教程；再加一份持续记录失败案例的“AI 错题本”。三类材料分别负责建立地图、完成闭环和形成判断。
三、学习与实操不能排成先后关系
很多人会给自己设计一条看起来很稳妥的路线：先学完大模型原理，再学 Prompt，再学 Agent，最后找项目练习。问题是，AI 的知识更新太快，也太依赖情境。只听课不做事，很容易形成一种“概念都听过，任务仍不会拆”的假熟练。
更有效的方法是让两条线并行：
- 认知线：
用通识课程建立大模型、Agent、上下文和工具调用的基本框架。 - 实践线：
从第一天开始，把手头真实任务交给 AI，要求它产出一个可以使用的结果。
这是一种 “AI First” 的练习方式。不是所有事情都必须让 AI 做，而是遇到任何问题时，先问一次：它能不能承担更多，而不只是给我一点建议？
你可以把练习分成四级。第一级，让 AI 回答；第二级，让它交付完整成果；第三级，把反复成功的做法写成固定 Skill；第四级，让多个角色分别规划、执行和复核。每升级一级，你对 AI 的理解都会比多看十篇工具介绍更扎实。
四、第一个 Hello World：做一个能公开访问的个人网站
朋友问我：“有没有一个像大学第一堂编程课里的 Hello World，让我可以真正开始？”
我的建议是：用 AI 从零完成一个个人网站，并把它发布上线。
这个项目足够小，不需要复杂业务；又足够完整，会迫使你经历需求澄清、内容组织、页面设计、代码生成、错误修复、浏览器验证和上线发布。完成之后，你得到的不只是一个网页，而是第一次完整体验“我提出目标，Agent 负责大量执行，我负责判断与验收”的工作方式。
在这个过程中，刻意练习以下动作：
先说清楚读者、目标、页面结构与验收标准，不要一上来就让 AI “随便做一个网站”。 让 Agent 先给计划，再执行；每一步都要求它说明产出与风险。 真实打开网页检查，而不是看到“代码完成”就算结束。 发现问题时描述现象与标准，让 AI 定位原因，不要只说“不好看”“不对”。 把有效的提示、检查清单和修复方式留下来，作为下一个 Skill 的素材。
如果个人网站与你的工作距离太远，也可以换成同样具备完整闭环的项目：为一组真实产品生成营销材料包，整理一套客户接待话术，或者做一个销售沟通质检助手。关键不是写代码，而是完成一个有输入、有输出、有质量标准的真实交付。
五、不要一上来就建平台，先把一个点做深
谈到企业 AI 转型，人们很容易先想到知识库、数字化平台和完整工作流。于是项目还没开始，就被权限、系统集成、数据治理和预算吓退。
真实落地往往可以轻得多。比如销售团队人员流动大，不同人回复客户的专业程度不一。可以先找到金牌销售，梳理客户接待、需求挖掘、方案、报价、交付与回访各阶段的最佳实践，再把话术原则、禁用表达和检查标准整理成一个 Skill。另一个 Skill 专门复核销售记录，指出遗漏、风险和改进方向。
它不一定需要先开发一整套平台，却已经在一个高频场景里改变了工作方式。等这个点被验证，再考虑连接数据、增加自动流转或嵌入现有系统，成本与阻力都会更可控。
这也解释了企业 AI 转型里最费脑力的工作：不是把一堆 SharePoint 文档扔进知识库，而是把隐性的经验变成 AI 可以执行和人可以验收的结构。至少要说清楚：
任务在什么条件下开始，输入信息是否完整； 专家实际遵循哪些步骤，其中哪些不能省略； 什么情况属于例外，需要人来判断； 输出要满足哪些合规、品牌与业务标准； 如何判断 AI 做对了，错误又怎样回到下一轮改进。
当你能完成这套梳理时，你已经不只是“会用 AI”，而是在设计 AI 可以参与的工作。
六、最有价值的转型角色，是业务与 AI 之间的翻译者
这次交流最后，朋友找到了一个很适合自己的定位：不一定亲自开发复杂的 Agent 框架，但要能站在业务一侧，把模糊需求、组织知识和工作流程翻译成 AI 方案；同时又能与技术人员讨论边界、数据、接口和验收。
这种角色有时被称为 FDE，Forward Deployed Engineer，也可以更朴素地理解为“贴着业务落地 AI 的人”。名称并不重要，能力组合更重要：
会访谈业务，发现真正高频、重复、可评价的工作； 会拆流程，找出知识、规则、工具和人的判断分别在哪里； 会快速做出原型，用真实样本验证，而不是只写方案； 懂得组织变化，知道怎样让一线人员愿意用、持续反馈并承担最终责任； 具备足够的技术理解，能判断何时用现成工具，何时需要工程开发。
如果你过去做过产品、敏捷、咨询、运营、培训或组织发展，这些经历不是需要抹掉的旧标签。它们提供了业务发现、跨团队协作、流程设计与改变行为的基本功。你要补上的，是 AI 的工作机制、工具实践和快速原型能力。这正是新的组合优势。
别再等一条永远不会过时的课程路线。选一个真实问题，让 AI 和你一起把它做完。
做完以后，再问三个问题：哪里最依赖上下文？哪里最适合沉淀成 Skill？哪里必须有人复核？你的下一阶段学习路径，就藏在这三个答案里。
说明：本文根据一次关于 AI 转型与学习路径的真实交流整理，在不改变核心观点的前提下，对口语、案例和结构进行了编辑与补充。
