只教 AI 一次，让团队经验开始复利

这两天我一直在想，自己的公众号第一篇到底该写什么。

我手上能聊的东西太多了。怎么设计门禁，让 AI 写出的代码符合我们的要求，怎么同时做到开发快和不出错，怎么把这些实践收拢成一套自研的 AI Coding 工程体系，怎么在项目长期迭代里保证需求不跑偏，让代码和需求始终保持双向追溯。每一个拎出来，好像都能写很久。

但真让我动笔，我反而卡住了。

尤其是那套我们自研的工程体系。它是我沿着一整条实践路径慢慢走出来的结果，一上来就讲终点，读者多半会觉得复杂，我自己也很容易越写越大，最后变成一篇谁都看不完的说明书。

我寻思了很久，最后决定从最小的一块开始。

Skill。

为什么是 Skill？因为我越来越觉得，AI Coding 真正拉开差距的地方，不只是这一轮能不能把东西写出来，而是这轮做完以后，经验有没有留下来。

作为世界上最著名的长期投资者之一，巴菲特把复利的价值验证了一辈子。他特别喜欢用滚雪球来解释这件事，人生就像滚雪球，最重要的是找到足够湿的雪，和一条足够长的坡。

AI Coding 其实也一样。每次解决问题，都是往雪球上加一层雪。经验如果只留在这次对话里，会话一关，雪球就化了。把它写成 Skill，下一次继续滚，前一次解决问题的价值才不会归零。

Skill，就是我给 AI Coding 找到的那条长坡。

我不知道你有没有过这种体验。项目里有些东西，AI 不可能凭空猜出来。目录为什么这么分，部署命令是哪一条，某个字段为什么不能动，测试应该写在哪里。只要这些经验还停留在人的脑子里，每次换会话、换模型、换一个 agent，就可能要重新解释。

但这笔账很容易被忽略。

AI Coding 最开始面对的问题其实很朴素。AI 到底能不能把代码写出来，能不能真的把一个程序做出来。最开始是 Vibe Coding。2025 年 2 月，OpenAI 创始成员、前 Tesla AI 负责人 Andrej Karpathy 提出了这个词。他描述的状态很直接，接受 AI 生成的代码，遇到错误就把报错贴回去，直到东西跑起来，甚至可以先「忘记代码本身的存在」。那时最重要的，就是 AI 能不能把想法变成真正能跑的东西。

后来，Thoughtworks 首席科学家、《重构》作者 Martin Fowler 用 Agentic Programming 把它和 Vibe Coding 区分开来。人不再只是让 AI 写几行代码，而是把完整任务委托给 Agent，由它自己读仓库、修改文件、调用工具和运行测试。再往后，Harness Engineering 和 Loop Engineering 相继出现。工程目标从「能写、能跑」继续往上走，开始追求符合项目规范、自动验证结果、失败后自己返工，以及长期稳定地完成任务。人的位置也从每一步盯着 AI 操作，逐渐转向定义目标、设计规则和处理关键判断。

把几个名字连起来看，这条路其实很简单。AI Coding 正在从「把东西写出来」，走向「用一套可重复、可验证、可治理的方式把事情做对」。

这也是我一直在研究这条路的原因。 AI 已经不是玩具了，它正在成为工业生产里真正有价值的加速器。它已经能把大部分事情做对，欠缺的是稳定、可重复、可验证。我的研究，就是补上这部分，让它真正成为能进入生产环境的可靠工具。

而这条演进路线里，有一块东西从 Harness 一直贯穿到 Loop，就是 Skill。

没有 Skill，Agent 每次进入项目都要重新猜一遍团队的做法，Loop 每转一圈也只是在重复失忆。有了 Skill，前一次任务里形成的项目经验才能进入下一次任务，系统才不只是循环，而是在积累。

这些话你跟人类同事只说一次。他记住了，这事就翻篇了。

跟 AI 呢？每个会话说一遍。换个模型，再说一遍。过两个月项目重构了，再把旧经验纠正一遍。

同一份经验，被重复传授了无数次。聊到这我想说一个我自己的判断，AI Coding 最大的浪费不是代码写错，是经验随对话一起消失。 一次对话只能解决一次问题，教完不留痕，那每一轮 AI Coding 都是从零开始的体力劳动。

那怎么办呢。

我的答案你可能也猜到了，就是 Skill。但我对 Skill 的理解，可能跟很多教程里讲的不太一样。

很多人把 Skill 当成一段更长的提示词。写好一大段话存起来，下次贴给 AI。我觉得这个理解浅了。

Skill 不是提示词，是一套可以被反复调用的工作方法。

还是拿「给项目加新接口」举例。提示词的写法是，帮我写个接口，注意目录规范。Skill 的写法是，路由放哪个目录，服务层怎么分层，错误码用哪套定义，以前在这个任务上踩过什么坑，测试写在哪里，最后跑哪条命令验收。

看出区别了吗。前者是叮嘱，后者是流程。叮嘱会被遗忘，流程可以被检查。

所以一个合格的 Skill 里通常有这么几样东西。适用场景，触发条件，操作步骤，项目专用的命令和脚本，常见错误，以及我认为最重要的一样，验证方式。做完了怎么确认做对了，跑什么命令，看什么输出。这一条要是没有，Skill 就是个许愿池，许完愿灵不灵全看运气。

接下来这个点，是我自己最想讲的，也是这篇文章真正的核心。

不是 Skill 应该怎么分类。

是积累。

很多人一听到 Skill，脑子里会冒出一套很大的东西。完整的方法论，几十页的操作手册，或者某种看起来非常厉害的自动化流程。

但我自己的感受刚好相反。项目里真正值得留下来的经验，很多都不大，关键是它们足够专属，专属到模型不可能自己猜出来。

这也正好对应 Anthropic 在讨论新一代模型时提出的判断。模型能力越强，越不需要我们反复教它那些大众化的内容。怎么写常规代码，怎么理解目录，怎么完成通用操作，它读一遍项目大多就能自己判断。

真正值得写进上下文的，是团队或产品特定的观点、知识和最佳实践。这个项目为什么放弃某个方案，新增一种业务类型时必须同步修改哪些地方，一条需求怎样跟代码保持双向追溯，某类改动要经过哪些项目专属的验证。这些才是模型读代码也推断不出来的东西。

判断标准也很简单。对每一条内容都问一遍，模型读代码能不能自己推断出来。能，就别写。真正该留进 Skill 的，是模型不可能自己知道的那部分。

所以我说项目经验可以很小，不是说每一条命令都要单独做成 Skill。如果只是「改完这个配置后跑某条命令」这样一句话就能讲清的规则，直接写在 AGENTS.md 里就够了。但只要它开始包含适用条件、多个操作步骤、项目背景或者验收方式，哪怕全文只有几行，也值得独立成一份 Skill。

写成 Skill 只是第一步。它放在哪里，AI 又怎么找到它，这两件事同样重要。

第一，项目里的 Skill 要放进 Agent 能自动发现的位置，并跟代码待在同一个仓库里。

像 TDD、代码审查和 Git 提交流程这类跨项目都能复用的经验，可以放在全局。但只要一份 Skill 记录的是当前项目的目录约定、业务判断、开发流程或验收方式，它就不再只是某个人的使用习惯，而是项目资产。

在支持 Agent Skills 自动发现的工具里，项目根目录下的 .agents/skills/ 就是这样的入口。Agent 进入项目后，运行环境会自动扫描其中的 Skill，先看到它们的名称和描述，遇到匹配的任务时再读取完整内容。不需要再为每一份 Skill 手工建立一条索引。

这不是一个简单的目录选择。它决定的是，这段经验究竟只属于某个人，还是能够留在团队里继续产生价值。

对一个开发团队来说，真正值钱的不只是眼前这份代码，还有代码背后积累下来的判断。为什么当初选这个方案，什么地方最容易出错，哪类改动必须经过哪些验证。这些东西如果只在人的脑子里，人一走、会话一关、模型一换，团队就得重新交一遍学费。

经验只有在离开某个人以后还能继续工作，才真正属于团队。

把 Skill 放进项目的自动发现目录，就是把个人经验变成团队资产。完成一次任务，不只留下一次交付，还留下一套下次可以直接复用的做法。同类问题再出现时，后来的人和 AI 不需要从零摸索，而是站在上一次实践的结果上继续往前走。

这就是复利。项目做得越久，留下的 Skill 越多，团队不是背着越来越重的历史包袱，而是在拥有越来越厚的经验底座。

所以项目 Skill 应该和代码一起提交，一起分支，一起进入 PR，一起接受 review。代码改了，相关 Skill 也要跟着改。每一次评审不只是在保证这一轮代码没问题，也是在校准团队以后处理同类问题的方法。

新人 clone 下来，拿到的不只是能运行的代码，还有这个团队一路走过来积累的做事方式。人可以换，模型可以换，经验不需要跟着归零。

代码记录的是项目现在长什么样，Skill 记录的是这个项目应该怎么继续往前走。

第二，让 Skill 的描述负责被发现，让 AGENTS.md 守住关键门禁。

自动发现不等于自动执行。Agent 进入项目后先看到的是 Skill 的名称和描述，不是所有 Skill 的完整正文。它会根据当前任务判断哪一份值得加载，所以描述不是普通简介，而是 Skill 的路由规则。

一份 Skill 什么时候使用，适合处理什么任务，哪些场景必须触发，都应该在描述里说清楚。描述写得含糊，Skill 即使放对了位置，也可能在真正需要时被错过。

一个真正有经验的老员工，不会把公司所有 SOP 一字不差地背下来。他厉害的地方，是遇到一件事，知道去哪里找资料，读哪份流程，最后用什么方式确认自己做对了。 自动发现机制给了 Agent 这份能力，Skill 的描述则告诉它什么时候应该拿起哪份流程。

AGENTS.md 不再需要承担完整目录的索引工作。它更适合保存每个任务都必须知道的短规则，以及绝对不能绕过的关键门禁。普通开发 Skill 交给自动发现，高风险流程则可以额外写一条强约束，要求生产部署、生产数据修改或关键发布前必须读取指定 Skill。

Skill 的描述负责让经验被发现，AGENTS.md 负责保证关键流程不会被绕过。

Skill 多起来并不可怕。真正要控制的是混乱。不要把所有经验都塞进 AGENTS.md，不要让 Skill 的描述含糊到无法匹配，也不要让过期流程继续躺在项目里骗人。自动发现和关键门禁一起工作，这个资产才会越用越值钱。

Skill 最有价值的地方，不是它有多大，而是它让经验留了下来。

这才是我理解的积累。

一个 Skill 留下一段经验，十个 Skill 留下一套做事方式。项目继续往前走，新的坑、新的判断、新的流程一点点加进去，后面每一个新会话都能站在前面所有实践的基础上开始工作。

那是不是只有很大、很复杂的流程才值得写成 Skill？

恰恰相反。

越小的项目经验，越容易因为没人专门记录而消失。判断它值不值得积累，不看它有多少行，先看这个操作以后还会不会再做。

同一个问题已经出现两次，当然应该写。但不用非得等到第二次踩坑。只要你现在就知道，这个操作未来肯定还会再执行一次，第一次做完就值得把它沉淀成 Skill。

能预见第二次，就应该在第一次留下来。

再看几个问题。它是不是这个项目特有的，新会话能不能自己推断出来，做错之后有没有成本。只要答案指向应该留下，那就写。十行也可以，五行也可以。先让经验有地方落下来，再通过使用不断修正它。

这里我必须坦诚一下学习成本，不然这篇就成画饼了，我很烦那种只讲收益不讲代价的方法论文章。

一开始写 Skill 绝对比直接干活慢。你明明十分钟能改完的东西，提炼成 Skill 可能要半小时。刚开始你会怀疑，这么小的流程也要写吗？

要写。

因为你付出的不是这一次多出来的二十分钟，你买回来的是后面每一个新会话都不用重新解释。

写坏的 Skill 当然也比没有 Skill 更可怕。AI 对明确规则的执行可能非常坚定，你写错一步，它就可能错得理直气壮。所以 Skill 不能只写操作，还得写验收。缺少验证方式的流程，看起来完整，实际上根本不知道有没有跑对。

这也是为什么 Skill 不能写完就不管。

Skill 还是活的项目资产。项目变了它就得跟着变，发现新问题就继续补，原来的做法失效了就及时改。

不用等一套完美体系设计好再开始。

今天遇到一个值得留下的小流程，就积累一个。

说到这，一个完整的闭环其实就清楚了。AI 犯错，你定位原因，把正确流程提炼成 Skill 写进项目的自动发现目录，再把触发场景写进 Skill 描述。下次遇到同类任务，Agent 根据描述发现并加载它，最后用测试或者门禁验证结果。高风险流程再由 AGENTS.md 加一道强制门禁，发现没拦住就回头改 Skill。

这个闭环需要不断跑。Skill 不是写完就供起来的规范文档，它更像一个一起干活的同事，错了就教，教完还得考。

写到这，我想聊点更大的。

我们做技术的人，特别喜欢聊资产。代码是资产，数据是资产，文档是资产。但很少有人意识到，「你怎么把一件事做对的经验」，才是团队里最值钱又最容易蒸发的那种资产。以前它存在老师傅的脑子里，老师傅一走，全公司交一遍学费重新踩坑。

现在其实多了一个选择。把它写成 Skill，留在项目仓库里，AI 每次干活都带着它，人换了一茬又一茬，模型换了一代又一代，经验还在原地，越用越准。

这是我觉得 Skill 这件事真正迷人的地方。它不是什么提示词技巧，它是第一次让「经验」这种东西，有了一个可以被版本管理、被审查、被执行的载体。

回到我准备这篇文章的那个晚上。

我一开始想从那套自研体系讲起，想把代码级门禁、开发流程、项目约束一次讲完。现在再看，这样写一定会失控。因为那些看起来很大的体系，往下拆，都是从一条条被保存下来的经验开始的。

先让经验留下来，才谈得上让系统替你执行经验。

一次对话只能解决一次问题。但一个被项目持续维护的 Skill，可以让同类问题以后都少走一遍弯路。

AI Coding 真正的长期价值，不是只把这一轮任务做完，而是这一轮结束后，项目留下了什么。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。