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

基于一次内部技术分享的音频转写整理。

过去一年，很多人对 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 变强了，之后很多项目都受益。

从工作轨迹里找 Skill

很多人问，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 为什么这么做、做到什么程度算对、什么时候必须停下来确认。

英语学习的例子

这个方法也可以用在学习上。

我之前准备托福，第一次模拟考大概只有 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 按这个流程跑一次真实任务，不用追求完美，只记录哪里做错、哪里需要确认、哪里缺工具。

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

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