半年多来，我把 Cursor 当主力编辑器，但一碰到 Infra 方向的活儿就头疼：让它写内核模块，它一上来就是几百行代码，API 全是老版本；丢给它一篇论文，它三句话总结完，连实验基准都没提。后来我干脆整理了一个 AI Infra Skills 仓库，给 Cursor 装上边界和流程——核心诉求就一句话：别一上来就乱写 kernel，也别乱总结论文。这篇东西适合所有用 AI 编程助手做系统编程、内核开发、技术调研的人参考，思路和坑都记录在下面。
先说背景。Cursor 在生成 CRUD 接口、写单元测试这些常规任务上确实顺手，但底层开发完全是另一回事。基础设施领域的代码高度依赖上下文：内核版本、硬件平台、并发模型、编译环境，任何一项没对齐，生成结果就是纸面废物。论文阅读也是重灾区，模型对长文本摘要的能力很强，但它不做信息筛选，也不知道一篇系统方向论文里什么信息才是真正重要的。与其反复骂模型蠢，不如把问题拆成：不是模型能力不够，而是任务缺少约束。Skills 仓库就是为了补上这一层约束，它的核心价值不是让 AI 变得更聪明，而是让 AI 在特定任务里不犯低级错误，并且把不可信的部分显式暴露出来。这个仓库我已在几个项目里跑了一段时间，下面的内容会从设计思路、目录结构、核心 skill 写法、效果评估到常见排查，一步步说明白。
1. 为什么需要“约束型”的 Skills 仓库
1.1 Infra 场景下 AI 编程工具的三个典型翻车点
先说第一个翻车点：乱写内核代码。你让 Cursor “写一个简单的内核模块”，它大概率直接给你完整代码。表面上看结构齐全，include 也对，module_init 也有，但细看全是过时 API。我见过它用create_proc_entry生成 proc 文件，这个函数在 Linux 3.10 之后就被移除了，现在的内核里根本没有这个符号。它也分不清init_MUTEX和semaphore到底该用哪个，更不用说处理wait_event_interruptible的返回值检查。
第二个翻车点是论文总结。把一篇系统方向的论文丢给 Cursor，让它 “总结一下”，它输出的是 Abstract 和 Conclusion 的拼接，核心方法一笔带过，实验设置完全没提。比如一篇讲分布式共识优化的论文，它总结成“提出了一种新算法，提高了吞吐量”，这等于没读。真正有价值的信息是：它在什么网络模型下做的实验、对比了哪些协议、故障场景怎么模拟、有没有消融实验。这些信息缺失之后，总结就变成流水账。
第三个翻车点更隐蔽：AI 会在代码里明目张胆地“模拟成功”。一个内核模块需要编译验证，但 AI 没法真的编译，于是它会在代码注释里写“测试通过”。实际上它根本没有测试环境。这种自信式幻觉在普通业务代码里可能只是逻辑 bug，在内核场景下直接就是系统崩溃或者数据损坏。
1.2 根因分析：为什么模型在 Infra 领域特别容易错
很多人以为原因是大模型“不懂内核”，我认为这不准确。它懂很多知识，问题是它不知道什么时候该用哪些知识，以及哪些知识已经过时。内核 API 的变化频率很高，网上流传的教程和博客大量基于旧版本，模型从这些语料里学到的“最常见路径”往往是过时路径。
可以这么理解：大模型像一个跨部门新来的实习生，能力很强，但不懂规矩。你不知道它会引用哪个版本的文档，也不知道它会把“权威文档”和“论坛乱写”放在同一个权重上。在 Web 开发里这种问题不明显，因为框架 API 相对稳定，代码跑不起来马上就能发现；在内核开发里，一条过时的 API 调用可能导致模块加载失败，甚至 panic，而且排查成本远高于业务代码。
论文阅读则是另一类问题。模型的文本摘要能力其实很强，但它没有“领域价值观”——它不知道在一篇系统论文里，实验设置和研究动机比相关工作总结更重要。没有明确任务框架时，它会按照语言模型的本能，输出一个语法正确、读起来通顺但信息密度极低的内容。这不是智力问题，是目标函数问题。
1.3 Skills 仓库的本质：给 AI 划边界，而不是让它更聪明
我最初的想法也简单，就是在项目里加一个 global prompt，告诉 Cursor “你是内核专家”。实测下来，这种身份式提示对行为改变非常有限。AI 听完以后依然是原样输出，顶多语气更专业一点。真正有效的是给它一套可执行的行为规范：什么不能做、什么必须做、按什么顺序做、做完怎么检查。
AI Infra Skills 仓库做的是这件事。它是一组可复用的行为规则、任务模板和检查清单，通过 Cursor 的自定义规则机制加载。核心设计原则是“约束优先于生成”：先告诉模型不允许做什么，再告诉它必须做什么，最后才是可以怎么做。
这个思路和敏捷开发里的 Definition of Done 很像。你不告诉开发人员“要专业”，而是告诉他们“哪些情况算完成，哪些情况算没完成”。模型也一样，给它一个明确的 Done 定义，它输出的质量会稳定很多。
2. 仓库设计与工作流
2.1 设计目标与目录结构
仓库叫 infra-skills，设计目标很直接：在不同 Infra 相关项目里复用同一套 AI 行为约束。它不是一个代码库，也不是一个插件，它只是一堆 Markdown 文件，被 Cursor 读取后变成模型的上下文约束。
初始目录结构是这样的：
infra-skills/ ├── skills/ │ ├── kernel-dev/ │ │ ├── SKILL.md │ │ ├── examples/ │ │ │ └── bad-practice.c │ │ └── checklist.md │ ├── paper-reader/ │ │ ├── SKILL.md │ │ └── templates/ │ │ └── paper-review-template.md │ ├── perf-analyzer/ │ │ └── SKILL.md │ └── crash-debug/ │ └── SKILL.md ├── prompts/ │ └── common-rules.md └── README.md每个 skill 都由三部分组成。SKILL.md 是主文件，定义触发条件、行为约束、执行流程；examples 目录放正反面案例，用于 few-shot 引导；checklist.md 是提交前要逐项核对的问题列表。之所以把 checklist 单独拆出来，是因为它会被频繁引用，放在 SKILL.md 里会让模型分不清主次。
2.2 为什么按任务类型而不是按代码库拆分
一开始我按项目拆分，一个项目一套规则。用了两周发现维护成本太高：内核模块项目和驱动移植项目有大量共同约束，但各自的 SKILL.md 里都是复制粘贴。而且 Cursor 按对话加载规则，项目 A 的规则放在项目 B 里完全不生效，复用很差。
后来改成按任务类型拆分。内核开发一个 skill，论文精读一个 skill，性能分析一个 skill。每个 skill 对应一类高频任务，而不是一个具体仓库。这样内核模块项目和驱动移植项目都可以加载 kernel-dev，行为约束统一维护，改一处全局生效。
这个决策带来一个额外好处：skill 的命名变清楚了。用户看到 kernel-dev 就知道它管什么，看到 paper-reader 就知道它管什么。如果是按项目命名，比如 project-x-rules，你根本不知道它约束的是什么行为。
2.3 任务触发条件与优先级
每个 SKILL.md 都有一个 frontmatter 区域，声明 name 和 description，以及触发关键词。Cursor 机制会读取这些信息，在对话中自动匹配。我的触发条件设计如下：
- kernel-dev：关键词包括“内核模块”“驱动”“/proc”“kernel panic”“dmesg”“syscall”等。
- paper-reader：关键词包括“论文”“paper”“阅读笔记”“总结这篇”“相关工作”等。
- perf-analyzer：关键词包括“性能”“perf”“火焰图”“CPU 占用”“延迟分析”等。
- crash-debug：关键词包括“crash”“panic”“死锁”“OOM”等。
优先级也很重要。比如用户说“分析一个内核模块的性能瓶颈”，这时候 kernel-dev 和 perf-analyzer 都会触发。我的规则是：用户手动指定 > 具体场景任务 > 通用任务。perf-analyzer 的触发条件里明确声明“如果任务是性能分析，kernel-dev 只提供背景知识，不要主导执行流程”。这种显式的优先级声明避免了两个 skill 同时输出互相矛盾的要求。
还有一点要注意：规则文件不要写太长。模型对上下文的注意力会稀释，一堆规则堆在一起，真正关键的约束反而会被忽略。每个 SKILL.md 控制在 200 行以内，核心红线放在最前面，详细模板放后面作为可展开内容。
3. 核心实现解析：如何编写约束型 skill
3.1 kernel-dev skill 的行为约束设计
这个 skill 是所有 skill 里最重要的，也是我踩坑最多的。它的核心是一份“禁止清单”和一份“必须清单”。
禁止清单：
- 禁止在未确认目标内核版本、硬件架构、内核配置选项之前生成完整模块代码。
- 禁止使用不确定是否存在的内核 API，除非在代码中标注“此 API 需核实”。
- 禁止模拟编译通过、加载成功或运行结果。
- 禁止在未说明锁策略和并发模型的情况下写出涉及共享数据结构的代码。
必须清单：
- 必须先输出“环境假设”，包括内核版本、架构、模块功能描述。
- 必须先输出“设计思路”，包括模块的初始化流程、数据结构、内存生命周期、错误处理路径。
- 涉及核心 API 时，必须指出该 API 所在的内核子系统或头文件位置，不确定则明确写“不确定”。
- 输出代码后必须附上“自检清单”，逐项验证。
为什么这么设计？核心原因是把“思维过程”显式化。模型在生成代码前先写环境假设和设计思路，相当于强制它做一次推理预热。很多幻觉代码的产生，是因为模型直接从“问题”跳到了“代码”，中间的逻辑链条缺失。一旦强制性要求它先输出思路，它就会被迫重新组织信息，错误率显著下降。
这是 kernel-dev SKILL.md 的开头部分，可以直观感受约束的写法：
--- name: kernel-dev description: 内核模块、驱动程序、内核补丁开发的强制行为约束 triggers: - 内核模块 - 驱动 - kernel panic - /proc - syscall --- # 核心规则 ## 禁止 1. 没有确认环境假设之前，禁止生成完整代码。 2. 禁止使用不确定的 API 而不标注。 3. 禁止模拟验证结果。 ## 必须 1. 先输出环境假设，再输出设计方案，最后才输出代码。 2. 每个关键 API 都需要标注可能的位置，如 include/linux/xxx.h。 3. 输出结束后，用 checklist.md 逐项自检。3.2 paper-reader skill 的深度阅读流程
paper-reader 的目标是消灭“表面摘要式总结”。我定义了一个五维拆解框架，强制模型按这个框架输出：
- 研究问题与动机：这篇论文解决的具体问题是什么？为什么重要？
- 核心方法设计：方法的关键组件、数据结构、算法流程。
- 实验设置与基线对比：环境配置、数据集、对比方法、评估指标。
- 结果与消融：主要结论、各模块的消融实验、异常现象。
- 局限性与可复现要点：作者承认的局限、复现时需要的数据和实现细节。
对应的 SKILL.md 里有一条硬性规则：禁止仅基于 Abstract 和 Conclusion 进行总结。模型必须从正文中寻找方法设计和实验信息。另外，输出内容必须区分三类信息：原文结论、作者推测、读者推断。原文结论标注“原文提出”，作者推测标注“作者推测”，读者推断标注“我推断”。这个设计是为了避免模型把推理过程包装成原文观点，导致读者误读论文。
还有一个实用的模板，放在 templates/ 目录下，方便对话中引用：
## 论文阅读笔记 - 论文标题： - 核心问题： - 方法概览： - 实验设置： - 环境： - 基线： - 指标： - 关键结果： - 消融结论： - 局限性： - 复现注意点：实际体验下来，加了这套约束后，模型输出的论文笔记从“150 字自然段”变成了“结构化的调研材料”。虽然还是不能完全替代人类阅读，但信息密度和准确性提升非常明显。
3.3 用正反案例做 few-shot 约束
光有规则还不够。规则解决的是“方向”问题，案例解决的是“质感”问题。我在 examples/ 目录下放了一对案例：bad-practice.c 和 good-practice.c。
bad-practice.c 模拟的是 Cursor 默认输出：一段看似完整、实际上使用旧 API 且没有错误处理的内核代码。good-practice.c 是加了约束后的输出：先注释环境假设，再列出设计思路，代码里每个关键 API 都标注了头文件位置，最后附上自检清单。
这两个案例不只是一堆文本，而是模型在生成新代码时的参考锚点。few-shot 的作用机制是：模型在生成时会模仿案例的结构和风格。你给它看一段结构严谨、带注释的代码，它就更有可能生成类似结构的代码，而不是默认那种“只要语法看起来对就行”的输出。
我强烈建议每个 skill 都配置至少一组正反案例，让模型知道“好的输出长什么样”。这个技巧对任务型 skill 的效果立竿见影，比多写十条规则都管用。
3.4 轻量评估：如何判断 skill 是否有效
搞了个仓库总得知道它有没有用。我设计了四个评估指标：
- API 幻觉率：生成代码中真实存在的内核符号数 / 全部符号数。
- 未确认假设数：生成代码中出现但未显式标注的假设数量（如未确认的内核版本、锁策略、架构假设）。
- 论文总结覆盖率：输出内容是否正确覆盖研究问题、方法、实验、局限五个维度的比例。
- 直接可用率：生成代码在不修改情况下通过编译和基本运行的比例。
实测中，加载 kernel-dev 后，API 幻觉率明显下降，未确认假设数也大幅减少。模型不再生成一眼假的旧 API 代码，而是先问“目标内核版本是多少”或直接注明“此 API 需根据你的内核版本核实”。这正是我要的效果。
一个容易踩的坑是：不要只依赖模型自己生成的“测试报告”来评估。开发者很容易陷入自我欺骗——让 AI 用同一套约束去检查自己生成的代码，然后得出结论“完美通过”。这不靠谱。评估必须落到真实环境：实际编译、实际安装到虚拟机、实际跑一遍 test case。论文总结类任务则要找懂行的同事人工打分，或者逐段对原文检查。
4. 常见问题与排查实录
4.1 Cursor 不加载 skill 或规则不生效
最常见的报障就是“我的 SKILL.md 写了，但模型完全不理我”。排查路径基本是按优先级来的。
先看文件放在哪。Cursor 的规则加载有目录要求，如果仓库放在~/infra-skills/而当前项目在~/work/foo/，它不会自动读取外部目录。需要把规则文件放进项目根目录（比如.cursor/rules/），或者通过 Cursor 的规则配置手动引入。
再看 frontmatter 是否完整。SKILL.md 顶部的 name 和 description 字段是必须的，这是 Cursor 识别 skill 的依据。如果缺了，文件就会变成普通文档，不会被加载。
最后看对话上下文。Cursor 对新规则的加载通常需要开一个新对话才生效。如果你在同一个会话里修改了规则文件，模型可能还是沿用旧上下文。改完规则，记得新开对话测试。
4.2 规则生效后 AI 变“怂”
这个问题很有意思。加了一堆禁止规则后，模型确实不乱写内核代码了，但也不会写任何代码了。它变成了一个“问题复读机”，永远在追问，不给方案。
原因很简单：规则写得太多，模型感知到风险，干脆不做动作。解决办法是给约束分级。我的做法是把所有约束分成三层：
- 红线：会导致严重错误的禁止项，比如未确认环境就生成完整代码、模拟验证结果、使用确定不存在的 API。这几条必须禁止。
- 建议：希望模型倾向性做到的，比如涉及共享数据时先说明锁策略。
- 可选：有更好，没有也行，比如输出附加参考资料。
只对红线使用“禁止”字眼，建议层用“应”，可选层用“可”。这样模型既不会闯大祸，也不会畏手畏脚。
还要给它一个安全的出口：当不确定信息时，明确说“不确定”，并且给出下一步验证方案。比起什么都不做，让模型先输出一个“带标记的猜测”并附上验证路径，推进效率反而更高。
4.3 Token 消耗变大
加上设计思路输出和自检清单之后，单轮对话 token 开销明显增加。原本一段代码 200 token，现在前面多了几百 token 的思路分析，后面又多了检查清单。整体下来每个任务多花不少 token。
我试过直接把 SKILL.md 里的模板全删掉，效果不好，质量回落。后来折中处理：在规则里加一个“快速模式”指令。用户可以主动要求“快速模式”，这种情况下模型只输出核心风险点，不做完整设计思路展开。对于简单的任务，比如“写一个 hello world 内核模块”，快速模式足够了；对复杂任务，比如“写一个字符设备驱动并处理并发”，则需要完整流程。
还有一个技巧：把长模板放到单独的 reference 文件里，SKILL.md 里只写“如需完整模板，引用参考文档”，而不是把整段模板内联进去。这样默认情况下模型不会展开全部内容，只有需要时才会读取。
4.4 skill 之间互相打架
多个 skill 触发后，规则可能冲突。比如 kernel-dev 要求先确认环境再生成代码，perf-analyzer 要求先抓取性能数据再做分析，用户说“写个内核模块然后分析性能”，两个规则同时生效，模型会无所适从。
我的解决方式是在触发条件和规则声明里增加优先级。perf-analyzer 的 SKILL.md 里明确写：“如果对话同时涉及内核模块开发和性能分析，先按 kernel-dev 流程完成模块设计，再切换到 perf-analyzer 进行性能分析。”这样模型就知道执行顺序，不用自己在多个指令里做模糊决策。
另外，每个 skill 独立命名空间，规则不要共享全局变量。如果两个 skill 都定义了“必须 xxx”，内容可能互相矛盾。我的做法是在 common-rules.md 里只放通用规则，具体任务的规则都放在各自的 SKILL.md，尽量互不引用。
4.5 评估结果虚高，实际表现不稳
最后想分享一个心态上的坑。开发这套仓库的时候，我很想看到一个“完美结果”，于是下意识用模型自己生成的代码和注释去评估效果。结果自然是“看起来一切正常”。
后来我在真实环境里做了一个最小编译实验，把模型生成的内核模块放到编译容器里跑，发现一堆问题：头文件路径写错、结构体字段版本差异、错误处理路径缺失。这些问题在模型输出的“自检清单”里完全没有出现，因为它检查的是规则，不是真实的编译错误。
从那以后，我对所有 AI 生成的内核代码都默认不信任，必须过编译和冒烟测试。规则能降低幻觉率，但不能消灭幻觉，AI 生成的代码永远需要人工把关。
我个人在实际使用中的体会是：这个仓库给我带来的最大收益不是代码的正确率，而是把 AI 的思考过程变成了可见的东西。它不再闷头写一大堆代码然后让我去排错，而是先告诉我环境假设和设计风险。这样一来，即使最后它生成的代码有问题，我也能很快定位是哪个假设错了，而不是面对一堆代码无从下手。
最后再分享一个小技巧：如果团队里多个人都在用这类工具，可以把各自的排查经验补充到对应 skill 的 checklist 里。内核开发者补内核相关的坑，搞性能的同学习惯记录 perf 的常用命令，几个迭代下来，这个仓库会越来越像团队的“AI 行为规范手册”。我就打算后面把它扩展一下，把网络栈分析和文件系统调试也加进去，不过那是下一次聊的话题了。
