从会用 AI 到建设自己的 AI 基建

基于一次内部技术分享的音频转写整理。原始分享围绕 skill 的分类、设计、迭代方法，以及如何把同一套方法迁移到 AI coding、团队协作和英语学习中。

过去一年，很多人对 AI coding 的理解还停留在“让 AI 帮我写代码”。但真正拉开差距的地方，可能已经不在于一次提示词写得多漂亮，而在于你能不能把反复发生的工作、隐性的判断经验、验证规则、学习循环攒成可复用的 AI 基建。

这也是我最近越来越强烈的一个感受：AI 时代的个人效率，不只是“会不会问模型”，而是“有没有能力把自己的工作方式工程化”。所谓 skill，本质上就是这种工程化的一个载体。

先区分三个东西：Agent、Skill 和 Tool

现在大家会听到很多概念：agent、skill、tool、function calling。它们之间没有一个绝对统一的行业定义，但如果从实践角度拆开，大概可以这样理解：

• Agent 决定“什么时候做什么”。它更像角色、目标和协作编排。
• Skill 定义“应该怎么做”。它包含流程、边界、规则、验证、失败处理和领域经验。
• Tool 提供“能做什么”。它通常是 API、脚本、MCP、命令行工具或平台能力的封装。

这个区分很重要。因为如果边界不清，skill 很容易变成一个什么都往里塞的大提示词，最后既不好维护，也不好迁移。

真正有价值的 skill，不是把一堆口号写进去，而是把一件事做好的方法固化下来。比如处理 Jira 任务，不只是“读取需求、写代码、提交结果”这么简单，它还包括如何理解任务、如何结合当前仓库拆解、什么时候需要人确认、实现后如何验证、最后如何把处理说明回写到任务里。这些“怎么做”的部分，才是 skill 最值钱的地方。

五类值得沉淀的 Skill

从实践来看，skill 大致可以分成五类。

第一类是流程实现型。也就是把一套固定流程自动化，比如从 Jira 任务 ID 开始，自动拉取任务描述，结合当前代码仓库做方案拆解、实现、验证，再把结果更新回 Jira。它解决的是“这件事每次都差不多，我不想每次从头带 AI 跑一遍”的问题。

第二类是能力接入型。比如让 AI 正确使用 Confluence、Jira、内部知识库、代码平台或本地工具。这类 skill 不一定是长流程，它更像是给 AI 接上一只手，让它能稳定地使用某个外部能力。

第三类是规范约束型。比如 codebase audit、代码门禁、团队工程规范、Review checklist。它解决的是 AI 容易“看起来完成了，但没有按团队标准完成”的问题。规范如果只停留在文档里，AI 不一定会记得；但如果变成 skill，它就能在每一次执行中被调用和检查。

第四类是领域认知型。这类最容易被低估。很多判断不是流程问题，而是经验问题。比如接到一个可视化需求，到底应该用 DDD、微内核、插件体系，还是普通组件分层？AI 未必天然知道你的业务复杂度和演进方向，但有经验的人可以把这些判断模式沉淀成 skill。这样新人或 AI 在面对类似需求时，就不是从零猜架构。

第五类是元工作流型。也就是不直接做某一项业务，而是分析你“怎么工作”。比如分析你过去一段时间的 AI 对话、任务轨迹和项目分布，找出哪些工作重复率高，哪些地方总是翻车，哪些流程应该自动化，哪些能力应该抽成 skill。

这第五类特别关键，因为它相当于给自己装了一个工作方式的反思系统。

AI Coding 之后，我们主要迭代什么？

当 AI 已经能写大量代码后，人还应该把时间花在哪里？

一个越来越明确的答案是：迭代 skill。

比如 codebase audit 这个 skill。一开始它可能只能做一些普通检查，但你把它放到真实代码库里跑，就会暴露出很多问题：有些检查太浅，有些规则不适合当前项目，有些风险没有覆盖，有些建议不可执行。这个时候真正应该迭代的，不只是那一次代码修改，而是 audit skill 本身。

当这个 skill 经过几轮真实项目打磨后，它就会变成一个可迁移的资产。今天可以用来改组件库，明天可以用来改另一个服务，后天可以用来给团队做质量门禁。

这里有一个认知转变：代码库不只是被 AI 修改的对象，也可以是训练和打磨 skill 的场地。一次需求做完了，产出可能只属于当前项目；但一个 skill 变强了，它会影响之后很多项目。

这也是为什么“会用 AI”不够。真正长期复利来自你有没有把一次次经验变成下一次能直接用的东西。

最了解你的，往往是你的工作轨迹

很多人问：skill 的想法从哪里来？

一个很朴素但有效的答案是：从自己的工作日志里来。

不管你用 Codex、Claude Code、Cursor 还是其他 AI coding 工具，本地通常都会留下很多 session 信息。这些记录里有你真实解决过的问题、反复卡住的地方、项目切换的轨迹、经常使用的提示方式、经常失败的场景。

这些东西比“我觉得我需要什么”更可靠。因为人对自己的工作习惯经常有错觉，但轨迹不会骗人。

如果周期性分析这些 AI 使用记录，可以得到几个很有价值的问题：

• 我最近主要时间花在哪些项目和任务上？
• 哪些工作已经重复出现三次以上？
• 哪些地方 AI 总是做不好，需要补规则或验证？
• 哪些任务本质上是一个固定工作流，可以抽成 skill？
• 我使用 AI 的方式有没有明显盲区，比如一直在许愿式编程，而不是给标准、给反馈、做验证？

这件事的价值不只是自动化，更重要的是让自己进入一个持续改进的飞轮：工作留下轨迹，分析轨迹能暴露盲区，盲区补进 skill，下一轮工作就顺一点。

我自己非常明显的体感是，在没有做这类分析之前，AI coding 很容易变成“许愿式编程”：把需求丢给模型，希望它一次做对。后来开始分析工作轨迹、反向调整自己的使用方式以后，效率和质量才有明显跃迁。

Skill 设计需要“第一性原则 + 对抗式审查”

很多 skill 效果不好，不是因为模型不行，而是因为设计时没有真正挖到问题本质。

一个常见错误是：把当前流程原封不动写成提示词。这样最多只是把低效流程自动化。如果原来的流程就有问题，AI 只会更快地执行错误。

更好的方式是先问第一性问题：

• 这件事真正要交付的结果是什么？
• 判断结果好坏的标准是什么？
• 哪些步骤是必要的，哪些只是历史习惯？
• 哪些信息必须来自当前仓库、当前任务或当前用户，而不能凭经验猜？
• 哪些环节一旦出错，会造成不可接受的后果？

然后再做对抗式审查：

• 如果这个 skill 失败，最可能失败在哪里？
• 它会不会让 AI 更自信地犯错？
• 它依赖的外部信息会不会过期？
• 它有没有把一次性偏好误写成长期规则？
• 它有没有缺少验证，只是把输出包装得更像真的？

这个动作看起来很小，但会极大改变 skill 的深度。浅层 skill 只告诉 AI “照这个流程做”；深层 skill 会告诉 AI “为什么这么做、做到什么程度算对、什么时候必须停下来确认”。

英语学习的例子：Skill 不是工具，而是训练系统

这套方法不只适用于写代码，也适用于学习。

我之前准备托福时，第一次模拟考大概只有 53 分，基本属于低分段。后来没有报很贵的培训班，而是尝试用 AI 和 skill 构建一个训练闭环。真正有用的不是某个单点工具，而是一整个系统。

这个系统里至少有几个要素。

首先是标准。托福写作、口语都有评分规则，这就像代码质量里的 rubric。没有标准，AI 的反馈就容易变成泛泛而谈。

其次是方法。我把一些老师的讲解、视频内容、经验材料转成文本，再让 AI 做蒸馏，提取出可执行的训练方法。但只有名师方法还不够，因为高手讲的东西未必适合低分段，所以还需要补充普通学习者的提分经验，用来校准当前水平。

第三是长期记忆。每天练完之后，内容会沉淀为文档，记录当天写了什么、错在哪里、反馈是什么、下一步该练什么。这样 AI 不是每天从零认识我，而是能沿着历史轨迹发现弱项。

第四是迁移训练。考试不会只考练过的原题，真正要练的是把有限题目中的表达、逻辑和方法迁移到新题上。这个和开发很像：做 A 项目时学到的东西，要能迁移到 B 项目，而不是只会修当前这个 bug。

第五是复习机制。我会把每天总结出的表达、错误和关键点拆成 Anki 卡片，进入间隔复习。练习负责产生材料，复习负责防止它们流失。

最后还要有阶段性检测。不是一直练，而是每隔一段时间检查训练是否真的带来了提升。

这个闭环跑起来以后，写作小分从 3.5 提升到 5.5，整体也达到了 C1/托福 100 分左右的水平。这里面当然有应试技巧的成分，但更重要的启发是：学习也可以像工程系统一样设计。

标准、方法、记忆、迁移、反馈、复习、检测，这七个东西组合起来，才是一个训练系统。skill 只是把这个系统稳定执行下去的载体。

不要掉进“做工具”的幻觉

用 AI 学习时还有一个坑：太容易沉迷于做工具。

因为现在让 AI 写一个小页面、小 App、小脚本太方便了，于是你可能不断优化练习系统、播放器、记忆页面、统计面板，但真正练习的时间反而少了。

这其实是一种很隐蔽的逃避。你感觉自己很忙，也确实产出了很多东西，但核心能力没有被训练。

所以 skill 和工具的目标应该是降低训练摩擦，而不是替代训练本身。判断一个工具有没有价值，最终要看它有没有让你更稳定地完成高质量练习，而不是看它功能多不多。

听力训练也是同理。精听软件、原题抓取、Whisper 转写、错句标注、影子跟读功能都可以做，但真正有效的仍然是那些基础动作：反复听、听不懂就拆句、标注听错原因、复习弱点、必要时跟读。

工具是脚手架，不是肌肉本身。

什么时候该做成 Skill？

不是所有东西都应该做成 skill。一个实用判断是：第三次出现时再认真考虑。

如果一件事第一次出现，可能只是偶发问题；第二次出现，先观察；第三次出现，就说明它可能是一个模式，值得沉淀。

下面几类尤其适合做成 skill：

• 一个流程你已经手动跑过很多次，比如日报、周报、Jira 任务处理、Anki 同步。
• AI 总是在同一个地方翻车，比如漏验证、误读架构、忽略团队规范。
• 团队总要反复解释同一件事，比如新人入职、环境配置、代码结构、发布流程。
• 某个判断依赖专家经验，比如架构选型、技术方案评审、代码质量审查。
• 外部出现了新方法、新技巧，你希望把它吸收到自己的工作流中。
• 你看不清自己的 AI 使用盲区，需要通过历史轨迹反向分析。

反过来，如果一件事高度一次性、标准不稳定、缺少验证方式，或者必须依赖强人工判断，就不要急着塞进 skill。否则它只会让系统变重。

信息输入之后，必须有下一步动作

AI 领域的信息密度很高。每天都有文章、公众号、官方博客、论文、工具更新、实践技巧。如果只是看完觉得“不错”，很快就会过去。

真正有效的信息输入，后面一定要有动作。

我自己的做法是把信息源大致分成两类。

国内公众号、大 V、设计类创作者，经常会提供一些很灵活的技巧、提示词、交互方式、视觉方法。这类内容适合沉淀成小 prompt、小 skill，或者补充到已有 skill 的某个局部环节。

国外官方博客、工程团队文章、OpenAI、Anthropic 这类源头材料，往往更偏工程原则和系统方法。它们适合被蒸馏成更底层的方法论，进入 code review、方案设计、评估框架、harness/loop engineering 这类能力中。

关键不在于看了多少，而在于看完后有没有进入自己的系统。信息只有被分析、改写、验证、存下来，才会变成能力。

个人 AI 基建，才是长期护城河

最后回到最核心的判断：AI 时代，个人竞争力的一部分会从“我会不会做某件事”，转移到“我有没有把做这件事的方法沉淀成可复用系统”。

当你不断把重复流程变成 skill，把失败记录变成验证规则，学习过程本身也变成每天练、每天改的循环，你的工作方式就会开始复利增长。

这带来的结果不只是更快完成任务。更重要的是，你会从疲于奔命的执行里抽出时间，重新获得思考、总结和改进的空间。

如果每天都在赶 bug、补需求、追进度，很难真正变强。因为没有余量的人，很少有机会审视自己的方法。但当一部分工作被 workflow 和 skill 稳定接住，人就能把精力放到更高层的问题上：我现在的判断标准对吗？我有哪些盲区？这套方法能不能迁移？下一轮系统应该怎么进化？

所以，skill 不是一个提示词文件，也不是一个炫技的小工具。它更像是个人和团队的操作系统插件。

谁能更快把经验沉淀进去，谁就能更快地把 AI 从“临时助手”变成“长期资产”。

一个最小落地路径

如果要从明天开始做，可以不用想太复杂。

先选一个你最近第三次遇到的重复工作，写下当前手动流程。然后补四件事：输入是什么，输出是什么，做到什么程度算合格，失败时怎么发现。接着让 AI 按这个流程跑一次真实任务，不要急着追求完美，只记录它哪里做错、哪里需要确认、哪里缺少工具。

第二次迭代时，把这些失败点写回 skill。

第三次迭代时，再问一个更狠的问题：这套流程是不是本身就错了？有没有更小、更直接、更可验证的做法？

如果能坚持这样做几轮，你会发现自己积累的不是一堆零散提示词，而是一套越来越懂你、越来越贴近真实工作的 AI 基建。