问题

在使用claude code的时候，我发现，我提供了一系列的操作规范，比如代码编译，容器创建，资源初始化等标准化的操作规范，我让它按照规范执行操作。会话前期，它会严格执行，但是会话长了以后，它会忽略掉我的标准规范，导致编写代码报错，执行报错等问题，然后逐渐失控。我的方案是提供docs目录，放置大量操作规范，是不是采用skills技术，会跟家稳定呢？

解决方案

你遇到的情况，本质上是长会话上下文的注意力衰减和指令稀释问题，这在所有大语言模型中都存在。

你现在的方案是把规范写成 Markdown 放在 docs/ 里，然后让 Claude 去读。这种“被动引用”的方式，在短会话里还好，一旦上下文变长，模型很容易忘记去查，或者只记住前几条规范，后面的就会被忽略。这就是你观察到的“会话长了就逐渐失控”。

而 skills（技能）技术，就是为了解决这个问题而设计的。它的核心思路是把规范从“被动文档”变成“主动调用的执行单元”。具体来说，比单纯放 docs 更稳定的原因有这几个：

1. 强制重载指令，刷新注意力

Skills 相当于一套打包好的系统指令 + 执行流程，每次被触发时，都会把完整的规范重新“塞进”模型的注意力窗口。

比如你定义了一个 compile-and-deploy skill，每次执行编译部署前，模型会强制调用它，相当于在那一刻完整执行一套标准化 SOP，不会被前面几千行的闲聊冲淡。而 docs 里的规范只在第一次加载时被完整阅读，之后模型只是“隐约记得有规范”，但细节全忘了。

2. 结构化的执行边界，防止自由发挥

Skills 一般有明确的输入、输出、步骤限制，甚至可以包括断言和校验。

比如你可以在 skill 里写：“第 3 步执行 docker build 后，必须检查返回码，并提取镜像 ID；若失败，必须终止并反馈错误，不得尝试自行修复。” 这种严格的流程控制，比“请参考 docs/compile.md” 更不容易被模型在长会话中“创造性发挥”所破坏。

3. 上下文隔离与工具化

Skills 在很多实现里是工具调用（tool use）级别的，比如 Claude Code 的 custom slash commands 或者通过 MCP 注册的 skill。这意味着它可以在独立的上下文片段中执行，甚至在极端场景下，部分状态不污染主对话上下文，进一步保证规范的执行纯度。

你现在的 docs 方案是“带小抄”，skill 方案更像是“按下一个写死的自动化按钮”。

4. 更好的版本与调试

Skills 可以独立测试、独立维护。当你发现某个规范总是被忽略时，你可以直接去检查这个 skill 的触发条件和流程，而不是在大段对话记录里猜模型为什么不看 docs。

具体怎么做？

如果你在用 Claude Code，可以有几种落地方式：

• Custom slash commands（内置）：在项目根目录创建 .claude/commands/，把每个规范写成一个 Markdown 文件，里面用 <instructions> 等标签定义严格执行流程。执行时通过 /command-name 强制触发。这其实就是一种轻量级 skill。
• MCP Skills（高级）：如果你的平台支持 MCP（如 Claude Desktop 或支持 MCP 的 Claude Code），可以把规范封装成 MCP 工具，模型必须通过工具调用来执行，这样规范是硬约束。
• 明确设计原则：每个 skill 只做一件事，内部包含：
  • 前置检查（状态、环境）
  • 严格步骤（每一步附带 expected output）
  • 异常终止条件（不允许自行绕过）
  • 事后验证（如运行测试、检查日志关键词）

结论：相比继续往 docs/ 里堆文档，把高频、容易出错的规范抽象成 skills/commands，会让稳定性有质的提升。它是从“希望 AI 记得查文档”变成“AI 必须按这个按钮才能继续”，从根本上规避了长上下文遗忘的问题。