1. 从技能仓库到能力装配线awesome-claude-skills 到底在解决什么问题第一次看到awesome-claude-skills这个仓库名很多人会下意识把它归类成又一个资源清单——就像 GitHub 上那些awesome-xxx系列无非是把链接堆在一起收藏夹吃灰。但真正把 Claude Code 用进日常开发流的人会发现这个仓库的价值根本不在清单本身而在于它把散落各处的技能定义、提示词模板、工具调用约定收敛成了一套可复用、可组合、可版本管理的能力装配线。先说清楚背景。Claude Code 这类终端里的编码代理核心能力来自两件事一是模型本身的推理与代码理解二是它能调用的工具与技能。工具是底层动作比如读写文件、执行命令、搜索代码技能则是更高一层的行为封装——它告诉代理在特定场景下应该按什么流程、用什么工具、遵循什么约束去完成任务。awesome-claude-skills收集的就是后者一批已经被人踩过坑、调过参、验证过效果的技能定义。为什么这件事重要因为裸用 Claude Code 的人几乎都会遇到同一个问题同一个任务今天跑得好明天跑得烂。你让它重构一个模块它有时规规矩矩先读测试再改代码有时上来就大改一通把测试全弄挂。这种不稳定性不是模型随机性那么简单而是缺少稳定的行为契约。技能就是这份契约——它把遇到这类任务该怎么做从模型的即兴发挥变成一份可检查、可迭代的说明书。这个仓库适合谁三类人最该看。第一类是刚装上 Claude Code、还在摸索怎么让它稳定干活的新手直接抄现成技能比自己瞎试快得多。第二类是团队里负责搭建 AI 编码规范的人需要一套可共享、可评审的技能库作为基线。第三类是做技能开发的人想看看别人怎么组织一个高质量技能的结构、边界和测试。至于只想让 AI 帮忙写个正则的人说实话用不太上杀鸡不用牛刀。关键词里出现的mcp、codex、superpower skills、agent skills这些词其实都指向同一个趋势代理的能力正在从模型内置走向外部可插拔。MCP 负责把外部工具接进来skills 负责把行为流程固化下来两者一个管能碰到什么一个管该怎么碰。awesome-claude-skills 站在后者的位置上是这个生态里最接地气的一环。2. 拆开一个技能看内部它凭什么能让代理听话2.1 技能不是提示词是带约束的流程说明书很多人第一次接触 skills会把它理解成一段更长的提示词。这个理解会让你写出很烂的技能。提示词是一次性指令技能是可复用的行为规范两者的差别在于约束密度。一个能用的技能通常包含这几层信息触发条件什么情况下该用这个技能、前置检查动手前必须确认什么、执行步骤按什么顺序调用哪些工具、验证标准怎么判断做完了、失败回退出问题怎么办。你把这五层写清楚代理的行为才会稳定少写任何一层它就会在那一步开始自由发挥。举个具体例子。假设你写一个安全重构技能只写重构代码时保持功能不变那基本等于没写。但如果你写成先运行测试确认当前全绿再定位待重构函数的所有调用点改完后必须重新运行同一批测试任何测试变红立即回滚并报告——这就成了一个有牙齿的技能。代理拿到这份说明书行为空间被大幅收窄稳定性自然上来。2.2 触发条件写不好技能就是摆设我见过太多技能死在触发条件上。写得太宽任何编码任务都适用结果代理在每个任务上都加载它上下文被塞满反而变笨。写得太窄仅当文件名包含 refactor_ 且是 Python 3.11 时适用那基本永远不会触发。好的触发条件应该描述任务意图而不是表面特征。比如当用户要求修改现有代码的行为但保持接口不变时就比当用户说重构时更可靠因为用户可能说整理一下这个函数把这段逻辑拆开字面没有重构二字但意图完全一致。awesome-claude-skills 里那些被反复使用的技能触发条件几乎都是按意图写的这是它比随手写的提示词耐用的关键原因之一。2.3 工具调用顺序里藏着大量隐性知识技能真正值钱的地方是它固化了工具调用的顺序和依赖关系。这些顺序不是随便定的每一条背后都有踩坑经验。比如先读测试再改代码这条新手会觉得多此一举——我改完再跑测试不就行了但实际经验是如果你不先读测试代理很可能改出一个测试能过但语义已经变了的版本因为测试覆盖不全。先读测试代理才能知道哪些行为是被锁定的、哪些是自由的。再比如改多个文件前先建立依赖图这是为了防止改到一半发现某个调用点没考虑到导致中间状态不可编译。这些顺序知识文档里通常不会写因为它们来自改崩过几次之后总结出来的。awesome-claude-skills 把这些隐性知识显性化是它最大的实用价值。2.4 验证标准决定了技能能不能自我纠错一个没有验证标准的技能等于把质量判断完全交给模型。而模型的自我评估能力说实话不太可靠——它经常觉得自己改得挺好实际跑起来一堆问题。验证标准要尽量可执行、可观测。能跑测试就跑测试能跑类型检查就跑类型检查能跑 lint 就跑 lint。如果这些都没有至少要求代理输出一份改动前后行为对比的说明让人来复核。我在实际项目里给技能加的最有用的一条验证标准是改动后必须能通过原有的 CI 流程。这一条直接把看起来对和真的对区分开了。3. 把技能装进真实工作流几个能直接抄的落地场景3.1 场景一接手陌生代码库时的侦察技能刚进一个项目代码库几万行你不知道从哪看起。这时候一个代码库侦察技能能省掉大量时间。它的流程大致是先读 README 和构建配置搞清楚项目类型和入口再扫描目录结构识别核心模块然后定位测试目录了解覆盖情况最后输出一份项目地图——包含主要模块职责、关键依赖、测试入口、潜在风险点。这个技能的价值在于把探索过程标准化。没有它代理可能随机翻几个文件就给你一个片面的印象有了它每次探索都覆盖同样的维度输出可比、可积累。我自己的做法是把这个技能的输出存成PROJECT_MAP.md后续所有任务都先读它代理的上下文质量立刻上一个台阶。3.2 场景二改 bug 时的最小复现优先技能修 bug 最常见的失败模式是代理没搞清楚 bug 到底怎么触发就开始改代码改完说应该好了实际根本没修对。对应的技能应该强制一个顺序先写一个能稳定复现 bug 的测试或脚本确认它现在失败再改代码改到测试通过最后确认没有引入回归。这条流程的关键是先让失败可见。很多 bug 之所以难修是因为触发条件模糊。把复现步骤固化成可执行的东西bug 就从玄学变成了工程问题。我在实际使用中发现光是强制先写复现这一步就能把修 bug 的一次成功率提高一大截。3.3 场景三批量重构时的分批提交技能大规模重构最怕的是一次改太多出了问题不知道是哪一步引入的。对应的技能应该要求把重构拆成多个逻辑独立的小步每步改完立即验证并提交任何一步失败就停在那里而不是继续往下改。这个技能背后是版本控制的经典智慧——小步快跑随时可回退。代理天然倾向于一口气改完因为它觉得这样效率高。但工程上可回退性比速度重要得多。技能的作用就是把这个工程直觉强加给代理。3.4 场景四写新功能时的接口先行技能写新功能时代理容易一头扎进实现细节写着写着发现接口设计有问题返工。对应的技能要求先定义接口函数签名、数据结构、错误类型确认接口合理后再填实现。接口先行的好处是把设计决策和实现细节解耦。接口定下来之后实现可以慢慢调甚至可以并行。这个技能特别适合多人协作或者需要评审的场景因为接口是最容易评审的部分实现细节反而次要。4. 技能开发中的真实坑我踩过的和看别人踩过的4.1 坑一技能写太长代理反而抓不住重点新手写技能有个通病怕说不清楚于是把所有能想到的情况都写进去一个技能写两千字。结果代理加载后注意力被稀释关键约束反而被忽略。我的经验是一个技能只解决一类任务正文控制在能一屏读完的长度。复杂任务拆成多个技能用组合的方式解决而不是写一个巨型技能。这跟写函数是一个道理——单一职责短小精悍。4.2 坑二把建议写成必须导致技能僵化技能里的措辞很讲究。必须禁止这类硬约束要慎用因为现实情况千变万化硬约束在边界情况下会变成障碍。更好的做法是写默认这样做除非有明确理由——既给了代理稳定行为又保留了合理偏离的空间。我见过一个技能把每次改动后必须运行全部测试写成硬约束结果在一个测试要跑二十分钟的项目里代理每次小改都卡二十分钟效率极低。后来改成改动核心逻辑后运行相关测试改动接口后运行全部测试才合理起来。4.3 坑三技能之间互相冲突代理无所适从当你装了十几个技能冲突就来了。比如一个技能说改动前先备份另一个说直接原地修改代理同时加载两个就懵了。解决办法是给技能分层基础层技能如代码风格、提交规范全局生效任务层技能如重构、修 bug按需加载两者职责不重叠。awesome-claude-skills 里很多技能在设计时就考虑了兼容性会明确写本技能假设已加载 X 技能这种显式声明能避免大量冲突。4.4 坑四技能不写什么时候不该用大部分技能只写什么时候用不写什么时候别用。这导致代理在不适用的场景也硬套技能效果适得其反。比如一个激进重构技能如果不写当代码即将上线、稳定性优先时不要用代理可能在发布前一天给你来个大规模重构。加上不适用场景这一节技能才算完整。这一节往往比适用场景更重要因为它防止的是最坏情况。4.5 坑五技能写完不测试等于没写技能也是代码也需要测试。但很多人写完技能就直接用从不验证它在各种输入下的行为。我的做法是给每个技能准备一组测试用例几个典型任务、几个边界任务、几个不该触发的任务。每次修改技能后跑一遍确认行为符合预期。这个习惯听起来麻烦但能避免技能在关键时刻掉链子。agent skills 测试这个词能上热搜说明大家已经意识到技能测试的重要性了。5. 从 awesome-claude-skills 看技能生态的演进方向5.1 技能正在从个人收藏走向团队资产早期大家写技能都是自己用存在本地。现在越来越多团队把技能库纳入版本管理像管理代码一样管理技能——有评审、有测试、有版本号、有变更日志。awesome-claude-skills 这类仓库的流行本质上是技能从个人经验变成团队资产的信号。这个转变的意义在于技能开始有了复用和积累的价值。一个团队踩过的坑通过技能固化下来新成员直接继承不用重新踩一遍。这是知识管理在 AI 时代的一种新形态。5.2 MCP 管连接skills 管行为两者正在分工明确热词里mcp和skills经常一起出现这不是巧合。MCP 解决的是代理能调用哪些外部能力skills 解决的是代理该怎么组织这些调用。一个管广度一个管深度。理解这个分工很重要因为它决定了你该往哪投入。如果你缺的是代理访问不到某个系统那是 MCP 的问题如果你缺的是代理访问得到但用得不对那是 skills 的问题。搞混了方向投入就白费。5.3 技能的可组合性会成为核心竞争力单个技能的价值有限技能之间能像积木一样组合价值才指数级上升。未来的技能库比拼的不是数量而是组合的顺畅度——能不能把侦察 重构 测试 提交串成一条流水线中间不用人工干预。这要求技能在设计时就考虑接口输入输出格式统一、状态传递清晰、失败处理一致。awesome-claude-skills 里那些被高频引用的技能往往就是组合友好度高的。这个方向值得每个做技能开发的人认真对待。5.4 技能质量会逐渐出现事实标准现在技能写法五花八门但趋势是收敛的。哪些字段必须有、触发条件怎么写、验证标准怎么定慢慢会形成事实标准。跟着这些标准走技能的可移植性和可维护性都会好很多。我个人的判断是未来一两年内技能会像今天的 ESLint 配置一样有一套被广泛接受的 schema。到那时候awesome-claude-skills 这类仓库的角色可能就从收集变成规范制定了。6. 我自己的技能库是怎么组织的说说我自己的实践可能对你有参考价值。我的技能库分三层目录base/放全局生效的基础技能比如代码风格、提交信息规范、错误处理约定task/放按需加载的任务技能比如重构、修 bug、写测试、写文档project/放项目专属技能比如这个项目的数据库迁移流程这个项目的发布检查清单。加载策略上base/永远加载task/根据当前任务意图匹配加载project/只在对应项目目录下加载。这样既保证了基础行为一致又避免了上下文被无关技能塞满。每个技能我都配一个test.md记录几个测试用例和预期行为。改技能前先跑测试改完再跑一遍。这个习惯是从踩坑里逼出来的——有次改了一个重构技能没测试就上线结果它在处理异步代码时把await全删了差点酿成事故。最后分享一个小心得技能库要定期清理。用不上的技能、被更好技能替代的技能、触发条件已经过时的技能该删就删。技能库不是越大越好是越精准越好。我每季度会过一遍自己的技能库删掉大概两成剩下的都是真正在用的。这个清理过程本身也是对我到底怎么用 AI 干活的一次复盘。 
长河君 · 2026/10/31 5:50:32 · 阅读 1.2k awesome-claude-skills：从技能仓库到能力装配线的工程实践
1. 从技能仓库到能力装配线awesome-claude-skills 到底在解决什么问题第一次看到awesome-claude-skills这个仓库名很多人会下意识把它归类成又一个资源清单——就像 GitHub 上那些awesome-xxx系列无非是把链接堆在一起收藏夹吃灰。但真正把 Claude Code 用进日常开发流的人会发现这个仓库的价值根本不在清单本身而在于它把散落各处的技能定义、提示词模板、工具调用约定收敛成了一套可复用、可组合、可版本管理的能力装配线。先说清楚背景。Claude Code 这类终端里的编码代理核心能力来自两件事一是模型本身的推理与代码理解二是它能调用的工具与技能。工具是底层动作比如读写文件、执行命令、搜索代码技能则是更高一层的行为封装——它告诉代理在特定场景下应该按什么流程、用什么工具、遵循什么约束去完成任务。awesome-claude-skills收集的就是后者一批已经被人踩过坑、调过参、验证过效果的技能定义。为什么这件事重要因为裸用 Claude Code 的人几乎都会遇到同一个问题同一个任务今天跑得好明天跑得烂。你让它重构一个模块它有时规规矩矩先读测试再改代码有时上来就大改一通把测试全弄挂。这种不稳定性不是模型随机性那么简单而是缺少稳定的行为契约。技能就是这份契约——它把遇到这类任务该怎么做从模型的即兴发挥变成一份可检查、可迭代的说明书。这个仓库适合谁三类人最该看。第一类是刚装上 Claude Code、还在摸索怎么让它稳定干活的新手直接抄现成技能比自己瞎试快得多。第二类是团队里负责搭建 AI 编码规范的人需要一套可共享、可评审的技能库作为基线。第三类是做技能开发的人想看看别人怎么组织一个高质量技能的结构、边界和测试。至于只想让 AI 帮忙写个正则的人说实话用不太上杀鸡不用牛刀。关键词里出现的mcp、codex、superpower skills、agent skills这些词其实都指向同一个趋势代理的能力正在从模型内置走向外部可插拔。MCP 负责把外部工具接进来skills 负责把行为流程固化下来两者一个管能碰到什么一个管该怎么碰。awesome-claude-skills 站在后者的位置上是这个生态里最接地气的一环。2. 拆开一个技能看内部它凭什么能让代理听话2.1 技能不是提示词是带约束的流程说明书很多人第一次接触 skills会把它理解成一段更长的提示词。这个理解会让你写出很烂的技能。提示词是一次性指令技能是可复用的行为规范两者的差别在于约束密度。一个能用的技能通常包含这几层信息触发条件什么情况下该用这个技能、前置检查动手前必须确认什么、执行步骤按什么顺序调用哪些工具、验证标准怎么判断做完了、失败回退出问题怎么办。你把这五层写清楚代理的行为才会稳定少写任何一层它就会在那一步开始自由发挥。举个具体例子。假设你写一个安全重构技能只写重构代码时保持功能不变那基本等于没写。但如果你写成先运行测试确认当前全绿再定位待重构函数的所有调用点改完后必须重新运行同一批测试任何测试变红立即回滚并报告——这就成了一个有牙齿的技能。代理拿到这份说明书行为空间被大幅收窄稳定性自然上来。2.2 触发条件写不好技能就是摆设我见过太多技能死在触发条件上。写得太宽任何编码任务都适用结果代理在每个任务上都加载它上下文被塞满反而变笨。写得太窄仅当文件名包含 refactor_ 且是 Python 3.11 时适用那基本永远不会触发。好的触发条件应该描述任务意图而不是表面特征。比如当用户要求修改现有代码的行为但保持接口不变时就比当用户说重构时更可靠因为用户可能说整理一下这个函数把这段逻辑拆开字面没有重构二字但意图完全一致。awesome-claude-skills 里那些被反复使用的技能触发条件几乎都是按意图写的这是它比随手写的提示词耐用的关键原因之一。2.3 工具调用顺序里藏着大量隐性知识技能真正值钱的地方是它固化了工具调用的顺序和依赖关系。这些顺序不是随便定的每一条背后都有踩坑经验。比如先读测试再改代码这条新手会觉得多此一举——我改完再跑测试不就行了但实际经验是如果你不先读测试代理很可能改出一个测试能过但语义已经变了的版本因为测试覆盖不全。先读测试代理才能知道哪些行为是被锁定的、哪些是自由的。再比如改多个文件前先建立依赖图这是为了防止改到一半发现某个调用点没考虑到导致中间状态不可编译。这些顺序知识文档里通常不会写因为它们来自改崩过几次之后总结出来的。awesome-claude-skills 把这些隐性知识显性化是它最大的实用价值。2.4 验证标准决定了技能能不能自我纠错一个没有验证标准的技能等于把质量判断完全交给模型。而模型的自我评估能力说实话不太可靠——它经常觉得自己改得挺好实际跑起来一堆问题。验证标准要尽量可执行、可观测。能跑测试就跑测试能跑类型检查就跑类型检查能跑 lint 就跑 lint。如果这些都没有至少要求代理输出一份改动前后行为对比的说明让人来复核。我在实际项目里给技能加的最有用的一条验证标准是改动后必须能通过原有的 CI 流程。这一条直接把看起来对和真的对区分开了。3. 把技能装进真实工作流几个能直接抄的落地场景3.1 场景一接手陌生代码库时的侦察技能刚进一个项目代码库几万行你不知道从哪看起。这时候一个代码库侦察技能能省掉大量时间。它的流程大致是先读 README 和构建配置搞清楚项目类型和入口再扫描目录结构识别核心模块然后定位测试目录了解覆盖情况最后输出一份项目地图——包含主要模块职责、关键依赖、测试入口、潜在风险点。这个技能的价值在于把探索过程标准化。没有它代理可能随机翻几个文件就给你一个片面的印象有了它每次探索都覆盖同样的维度输出可比、可积累。我自己的做法是把这个技能的输出存成PROJECT_MAP.md后续所有任务都先读它代理的上下文质量立刻上一个台阶。3.2 场景二改 bug 时的最小复现优先技能修 bug 最常见的失败模式是代理没搞清楚 bug 到底怎么触发就开始改代码改完说应该好了实际根本没修对。对应的技能应该强制一个顺序先写一个能稳定复现 bug 的测试或脚本确认它现在失败再改代码改到测试通过最后确认没有引入回归。这条流程的关键是先让失败可见。很多 bug 之所以难修是因为触发条件模糊。把复现步骤固化成可执行的东西bug 就从玄学变成了工程问题。我在实际使用中发现光是强制先写复现这一步就能把修 bug 的一次成功率提高一大截。3.3 场景三批量重构时的分批提交技能大规模重构最怕的是一次改太多出了问题不知道是哪一步引入的。对应的技能应该要求把重构拆成多个逻辑独立的小步每步改完立即验证并提交任何一步失败就停在那里而不是继续往下改。这个技能背后是版本控制的经典智慧——小步快跑随时可回退。代理天然倾向于一口气改完因为它觉得这样效率高。但工程上可回退性比速度重要得多。技能的作用就是把这个工程直觉强加给代理。3.4 场景四写新功能时的接口先行技能写新功能时代理容易一头扎进实现细节写着写着发现接口设计有问题返工。对应的技能要求先定义接口函数签名、数据结构、错误类型确认接口合理后再填实现。接口先行的好处是把设计决策和实现细节解耦。接口定下来之后实现可以慢慢调甚至可以并行。这个技能特别适合多人协作或者需要评审的场景因为接口是最容易评审的部分实现细节反而次要。4. 技能开发中的真实坑我踩过的和看别人踩过的4.1 坑一技能写太长代理反而抓不住重点新手写技能有个通病怕说不清楚于是把所有能想到的情况都写进去一个技能写两千字。结果代理加载后注意力被稀释关键约束反而被忽略。我的经验是一个技能只解决一类任务正文控制在能一屏读完的长度。复杂任务拆成多个技能用组合的方式解决而不是写一个巨型技能。这跟写函数是一个道理——单一职责短小精悍。4.2 坑二把建议写成必须导致技能僵化技能里的措辞很讲究。必须禁止这类硬约束要慎用因为现实情况千变万化硬约束在边界情况下会变成障碍。更好的做法是写默认这样做除非有明确理由——既给了代理稳定行为又保留了合理偏离的空间。我见过一个技能把每次改动后必须运行全部测试写成硬约束结果在一个测试要跑二十分钟的项目里代理每次小改都卡二十分钟效率极低。后来改成改动核心逻辑后运行相关测试改动接口后运行全部测试才合理起来。4.3 坑三技能之间互相冲突代理无所适从当你装了十几个技能冲突就来了。比如一个技能说改动前先备份另一个说直接原地修改代理同时加载两个就懵了。解决办法是给技能分层基础层技能如代码风格、提交规范全局生效任务层技能如重构、修 bug按需加载两者职责不重叠。awesome-claude-skills 里很多技能在设计时就考虑了兼容性会明确写本技能假设已加载 X 技能这种显式声明能避免大量冲突。4.4 坑四技能不写什么时候不该用大部分技能只写什么时候用不写什么时候别用。这导致代理在不适用的场景也硬套技能效果适得其反。比如一个激进重构技能如果不写当代码即将上线、稳定性优先时不要用代理可能在发布前一天给你来个大规模重构。加上不适用场景这一节技能才算完整。这一节往往比适用场景更重要因为它防止的是最坏情况。4.5 坑五技能写完不测试等于没写技能也是代码也需要测试。但很多人写完技能就直接用从不验证它在各种输入下的行为。我的做法是给每个技能准备一组测试用例几个典型任务、几个边界任务、几个不该触发的任务。每次修改技能后跑一遍确认行为符合预期。这个习惯听起来麻烦但能避免技能在关键时刻掉链子。agent skills 测试这个词能上热搜说明大家已经意识到技能测试的重要性了。5. 从 awesome-claude-skills 看技能生态的演进方向5.1 技能正在从个人收藏走向团队资产早期大家写技能都是自己用存在本地。现在越来越多团队把技能库纳入版本管理像管理代码一样管理技能——有评审、有测试、有版本号、有变更日志。awesome-claude-skills 这类仓库的流行本质上是技能从个人经验变成团队资产的信号。这个转变的意义在于技能开始有了复用和积累的价值。一个团队踩过的坑通过技能固化下来新成员直接继承不用重新踩一遍。这是知识管理在 AI 时代的一种新形态。5.2 MCP 管连接skills 管行为两者正在分工明确热词里mcp和skills经常一起出现这不是巧合。MCP 解决的是代理能调用哪些外部能力skills 解决的是代理该怎么组织这些调用。一个管广度一个管深度。理解这个分工很重要因为它决定了你该往哪投入。如果你缺的是代理访问不到某个系统那是 MCP 的问题如果你缺的是代理访问得到但用得不对那是 skills 的问题。搞混了方向投入就白费。5.3 技能的可组合性会成为核心竞争力单个技能的价值有限技能之间能像积木一样组合价值才指数级上升。未来的技能库比拼的不是数量而是组合的顺畅度——能不能把侦察 重构 测试 提交串成一条流水线中间不用人工干预。这要求技能在设计时就考虑接口输入输出格式统一、状态传递清晰、失败处理一致。awesome-claude-skills 里那些被高频引用的技能往往就是组合友好度高的。这个方向值得每个做技能开发的人认真对待。5.4 技能质量会逐渐出现事实标准现在技能写法五花八门但趋势是收敛的。哪些字段必须有、触发条件怎么写、验证标准怎么定慢慢会形成事实标准。跟着这些标准走技能的可移植性和可维护性都会好很多。我个人的判断是未来一两年内技能会像今天的 ESLint 配置一样有一套被广泛接受的 schema。到那时候awesome-claude-skills 这类仓库的角色可能就从收集变成规范制定了。6. 我自己的技能库是怎么组织的说说我自己的实践可能对你有参考价值。我的技能库分三层目录base/放全局生效的基础技能比如代码风格、提交信息规范、错误处理约定task/放按需加载的任务技能比如重构、修 bug、写测试、写文档project/放项目专属技能比如这个项目的数据库迁移流程这个项目的发布检查清单。加载策略上base/永远加载task/根据当前任务意图匹配加载project/只在对应项目目录下加载。这样既保证了基础行为一致又避免了上下文被无关技能塞满。每个技能我都配一个test.md记录几个测试用例和预期行为。改技能前先跑测试改完再跑一遍。这个习惯是从踩坑里逼出来的——有次改了一个重构技能没测试就上线结果它在处理异步代码时把await全删了差点酿成事故。最后分享一个小心得技能库要定期清理。用不上的技能、被更好技能替代的技能、触发条件已经过时的技能该删就删。技能库不是越大越好是越精准越好。我每季度会过一遍自己的技能库删掉大概两成剩下的都是真正在用的。这个清理过程本身也是对我到底怎么用 AI 干活的一次复盘。