最近不少朋友在问Cursor 自己写 Skill 到底怎么开始。说实话Cursor 里并没有一个写着“Skill”的按钮大家习惯叫它 Skill 的东西落地下来其实就是一套你自己定义的项目规则和指令模板。我在试过几轮之后最大的感受是不给 Cursor 立规矩它永远只会用那一套通用姿势写代码一旦你给它写清楚边界、流程和偏好它表现出来的“懂你”程度会提升一整个档次。这篇文章就围绕我自己的完整实操流程来写从规则载体、写法结构、测试方法到踩坑排查尽量一次讲透。1. 给 Cursor 立规矩为什么默认能力不够用1.1 Cursor 默认输出和你想要的可能差在哪里我最早用 Cursor 的时候和大多数人一样新项目建好写一句“帮我把登录功能实现一下”代码确实能出来能跑但总感觉哪里别扭。后来我慢慢发现别扭的点特别固定——它默认的代码风格偏“教科书式”变量命名喜欢又长又啰嗦类型能省则省注释时有时无模块拆分也总喜欢堆在一个文件里。这些不是 Bug而是通用模型在缺少约束时的正常表现。它不知道你的项目要兼容什么 Node 版本不知道你们团队约定组件全部用函数式写法不知道你希望每个接口变更都先列影响范围再动手。你可以在每一条对话里反复强调但新开会话之后它又“失忆”了因为聊天上下文不会跨会话保留。我把这个阶段称为“随缘写代码”。代码质量完全取决于当前会话里你重复了多少次约束。今天心情好多写两句要求AI 就像样一点明天偷懒只丢一句需求代码就放飞了。这也是我最开始觉得“AI 写代码只能当辅助”的原因直到我开始认真对待 Skill 这个概念。1.2 Skill 真正解决的问题自己写 Skill本质上就是把那些“你不想每次重复说”的话沉淀成一份 Cursor 每次都会自动参考的规则文件。它做的是三件事把个人编码偏好转成可复用的项目资产不用每次开新对话都重新交待一遍。把团队规范、技术决策、输出格式这类隐性知识显性化新成员协同起来也统一。让 Cursor 的输出从“泛泛的 AI 风格”收敛成“符合你项目语境的专业风格”。打个不太严谨的比方默认 Cursor 像一个能力很强但刚入职的程序员什么都会一点就是不懂你们组里的规矩。Skill 相当于你塞给他一本薄薄的《项目生存手册》告诉他什么能碰、什么不能碰、动手前先做什么。他不一定会全照做但你的合规率会明显上升尤其是硬性规则。1.3 适合的人群和边界我觉得下面几类人是写 Skill 最划算的长期用 Cursor 维护特定项目的人比如自己写了半年的某后台管理系统希望 AI 记住技术栈偏好。团队里带新人的人希望 AI 生成的代码天然符合团队 Review 习惯。对输出格式有强迫症的人比如要求所有修改先列方案、再给代码、最后附自测说明。至于边界也要先说清楚。Skill 不是魔法它不能显著提升模型本身的智能水平。如果你的需求本身描述不清规则写得再好也救不回来它提升的是“可控性”和“一致性”而不是“创造力”。这一点期待要摆正后面写规则的时候你就知道为什么很多细节要靠自己界定。2. Skill 的落点Rules 面板、.cursorrules 文件与全局规则2.1 先弄清三个容易混的入口第一次找“在哪写 Skill”的人大概率会被几个入口搞晕。在我用的版本里至少有三个地方都能放规则一是项目级 Rules。通常通过 Cursor 的设置里的 Rules 面板进入也可以理解为针对当前打开项目生效的规则。这个入口适合放“这个项目特有的技术栈、目录结构、约定俗成的写法”。比如你当前项目是某个跨平台系统里面用了一套特定的状态管理方案就适合写在这里。二是 .cursorrules 文件。早期 Cursor 社区大量使用的方式在项目根目录建一个名为.cursorrules的文本文件Cursor 会在当前项目中把这个文件内容作为额外指令加载。哪怕后来图形界面整合了 Rules 功能旧项目里的.cursorrules通常依然会被识别。它适合放比较长、比较正式的项目规范文档也方便直接用 Git 做版本管理。三是全局 Rules有时显示为 Global Rules。它不绑定具体项目而是对所有项目生效。适合放你个人最底线的编码价值观比如“永远不要删除代码而不留下说明”“提交信息要写清楚改动原因”这类放之四海皆准的规则。2.2 三者的优先级与合并逻辑我自己的理解是这样的以我当时使用的版本实测为准如果你手上的版本行为不同以官方文档为准规则类型作用范围适合内容示例加载时机全局 Rules所有项目通用编码规范、个人底线每次对话默认加载项目 Rules 面板当前项目项目专属技术栈、流程约束打开项目后加载.cursorrules当前项目长文档型规范、团队手册旧项目兼容加载实际使用中这三者不是互斥的Cursor 更倾向把可用规则拼在一起作为上下文供模型参考。项目级规则和全局规则如果出现矛盾我曾经遇到的实测结果是项目级规则优先但我不会依赖这种“默认优先级”来写规则。最稳妥的做法是在同一份 Skill 里不要写互相打架的内容一旦冲突规则的作用力会相互抵消模型会倾向于取一个中庸效果这恰恰是你最不想要的。2.3 Always、Auto 与上下文消耗在 Rules 面板里还有一个容易被忽略的设置Always 与 Auto。Always 很好理解就是无论当前任务是什么这条规则都会占用上下文空间并强制参考。Auto 则更聪明一点它让 Cursor 根据当前任务判断“这条规则是否和本次修改相关”相关才插入。我的建议是硬性红线用 Always比如“禁止使用 any”“禁止直接修改数据库结构而不产生迁移文件”风格类偏好用 Auto比如“组件命名遵循大驼峰”这种让它按需参考就行。这里有一个隐蔽的坑所有规则都会消耗上下文窗口。规则越多、越长留给实际代码的上下文空间越少。所以写 Skill 的精髓不是写多而是写准。3. 从零写第一条 Skill把抱怨转换成指令3.1 第一步列出你最常见的五个“怎么又”我第一次写规则时没有直接去翻官方文档而是干了一件很“土”的事翻自己过去一周的对话记录把所有抱怨 Cursor 的话记录下来。比如“怎么又给我用any我说了多少次类型要写全”“怎么又没写错误处理用户登录失败之后页面直接崩了”“怎么每次都要我提醒先列方案再写代码”“怎么这个项目里还在用 组合式函数我们约好的一律函数式组件呢”“改完一个功能为什么连带把无关文件也改了”这些抱怨看似零散背后其实是极其清晰的需求。写 Skill 的第一性原理就是你越讨厌 AI 反复踩的某个坑越值得把它变成一条显式规则。3.2 第二步把负向抱怨改写成正向指令“不要用 any”这种写法虽然能看懂但对大模型的约束力其实有限。你只告诉它不要什么它可能过度收敛或者换一种同样糟糕的写法。更有效的做法是给它一个替代方案和判断标准。我当时做了一个非常简单的翻译动作把抱怨逐条改为“当某条件出现时必须执行某动作”的句式抱怨正向指令不要用 any当类型无法推断时显式定义 interface 或 type并写明字段含义没写错误处理所有异步请求必须包含失败分支并给出用户可读的错误提示不先列方案就写代码当任务包含多处文件改动时先输出改动清单再开始编码还在用旧写法新代码一律使用函数式组件不得使用 Class Component乱改无关文件未在需求范围内出现的文件如无法绕开必须在回复中单独说明原因这一改之后规则的可执行性立刻不一样了。负面禁令只是悬崖边的栅栏正面指令才是导航路线。Cursor 对“出现 A 情况做 B 动作”这类条件句的遵循率远高于对“不要做 X”的遵守率。3.3 第三步写一条最小可用规则并放进去第一条 Skill 不用追求完整先治最痛的那一个问题。我当时选了“先方案后代码”这条因为它的收益最直观。文本直接写在项目 Rules 面板当用户提出的修改涉及 2 个及以上文件时 1. 先用不超过 10 行的篇幅简述你的修改方案 2. 列出涉及文件清单 3. 等待用户确认后再输出代码 4. 修改完成后用列表说明每个文件为什么被改动这条规则一共不到 80 个字但效果立竿见影。从那之后我对 Cursor 提出跨文件需求时它普遍会先剪短地列方案而不是一声不吭甩出一大段代码。这也是我建议所有入门者做的事不要一上来就写一篇 3000 字的“完美规则”先针对最大的痛点写一条能立刻解决问题的规则跑通流程再说。3.4 第四步用“新会话测试法”验证效果验证规则有没有生效其实有一个笨方法但特别准开一个新对话完全不要重复你的要求直接丢一个会触发该规则的任务给它看它是否自动执行规则。这里有一个很多人不知道的细节普通对话里修改 Rules 之后当前会话不一定会立即重新读取必须新开会话或者点击刷新按钮让规则重新注入上下文。我最初测试时就是在老会话里反复试以为规则写得有问题折腾了半天才发现只是会话没重置。测试时的任务要设计得足够“正常”。比如测试“先方案后代码”就发一句“帮我加一个用户导出功能涉及新建页面、接口封装、菜单配置”不要附加“记得先列方案”这种提示词这样才能验证它是否真的吃进了规则。4. 高质量 Skill 的内部构造指令分层与输出约束4.1 一份 Skill 的四层骨架跑通最小可用规则之后再写正式一点的 Skill我会按四个层次组织内容角色设定层、行为约束层、输出格式层、禁项与替代层。顺序一般固定。角色设定层是给整个规则定调。开头先告诉 Cursor“你是一名什么样的工程师”这会影响它的语气和决策倾向。比如“你是一名注重性能和安全的前端工程师”和“你是一名重视快速迭代的移动端工程师”对同样需求的拆解动作就会有明显区别。行为约束层是核心负责定义具体场景下的动作和顺序。写作重点是把动作拆细。不要说“注意代码质量”因为太抽象要说“抽公共函数时必须让函数名能反映行为且单个函数体不超过 40 行”。输出格式层管的是交付物长什么样。这层非常容易被忽略但它的约束效果极端好。比如规则里写明“代码必须附带运行方式和自测说明”比你在对话里求它“写详细点”稳定得多。禁项与替代层则专门处理那些你不希望发生的行为并且给替代答案。这是我前面提到的“抱怨转指令”的进阶用法但不再逐条对应而是挑高风险行为单独写。4.2 语气词的力量让规则更接近祈使句同一个意思不同的表达方式在模型那里的“力量”完全不同。我对比过两种写法弱写法建议在修改公共函数前先检查一下所有调用方避免造成影响。强写法修改任何公共函数前必须先列出全部调用方清单标注影响范围再开始改动。自己写一遍就能体会出来弱写法是一种谦卑的商量强写法是一个明确的操作流程。Cursor 对祈使句和条件句的遵循度明显比“建议”“可以考虑”这类语气高。这不是玄学因为规则最终会被拼入系统提示词越接近命令格式被采样的概率越高。还有一点尽量不要用双重否定。比如“不修改与需求无关的代码”这句已经算负向指令了如果再叠一句“没有必要时不要进行无关重构”模型可能把两句话含糊合并反而出现反复横跳。一句话只表达一个动作是最安全的结构。4.3 长度管理控制在模型能完整读完的范围内规则不是越长越好。我有一次试图把完整的团队开发规范全部塞进 .cursorrules结果写了大几百行运行起来后发现在最关键的输出格式部分模型反而开始不听话了。原因很简单——过长规则会稀释注意力而且可能挤占上下文空间。我自己现在把一份 Skill 控制在 150 到 300 行 Markdown 内如果团队规范确实很长会拆成多份 Skill 按场景调用而不是一股脑全部常驻。经验法则是常驻规则只放最高频、最硬性的约束低频但重要的约束放在用户跟 AI 交互时主动触发的指令里或者做成一段可以按需粘贴的模板文本。4.4 一个可以直接改用的通用模板下面这个模板是我现在新建中型前端项目时会直接复制的结构你可以往里填自己的内容# 角色 你是一名严谨的全栈工程师擅长在需求不明确时主动提问在动手前优先考虑可维护性。 # 项目背景 当前项目是某跨平台后台管理系统主要技术栈为 TypeScript、React、Node.js。 目录约定页面放在 src/pages公共组件放在 src/components接口封装在 src/api。 # 行为约束 1. 修改任何功能前先识别影响的文件范围并输出一句话影响说明。 2. 涉及接口变更时必须同步说明对现有调用方的影响。 3. 所有新增代码必须带有错误处理分支不允许静默失败。 4. 当用户需求不明确时先列出两种可行方案请用户选择再编码。 # 输出格式 1. 先写“改动概览”不超过 5 行。 2. 再写“文件级改动清单”列出每个文件的作用。 3. 然后输出代码块。 4. 最后附“自测建议”说明如何手动验证改动是否正常。 # 禁止项与替代方案 - 禁止使用 any遇到未知类型时显式定义 interface 或 type。 - 禁止跳过错误边界页面级组件必须包含兜底错误提示。 - 禁止在未说明的情况下删除注释特别是带 TODO 标记的注释。这个模板本身不是重点重点是它体现了我前面说的结构角色、背景、行为、输出、禁止项。你完全可以把技术栈和项目背景替换成自己的然后微调约束项就能得到一个可用的项目级 Skill。5. 实战案例写一个团队级代码审查 Skill5.1 需求从哪来被 Review 逼出来的规则我真正下决心写一个完整 Skill是因为参与模拟项目X的团队协作时后端老哥每次看我提交的代码都要在 Review 里重复同样的话接口变更没标注影响范围、错误处理缺失、测试用例覆盖不完整。后来我发现与其他一条一条在 PR 描述里写不如把团队审查关注的要点变成一个 Skill让 AI 在生成代码时直接按这个清单自我检查。这个场景和前面“个人痛点规则”不太一样它服务的是“AI 生成代码的质量门禁”核心诉求是让 Cursor 生成的代码在产出时就已经满足团队最低审查标准。5.2 我写的审查规则全文以下是我当时在项目规则面板里放的核心内容脱敏后# 代码审查 Skill项目质量标准 ## 目标 当你在当前项目中生成代码或修改代码时必须在交付前按下面的清单进行自我检查并在输出末尾给出检查结果。 ## 审查清单 1. 正确性是否存在明显逻辑漏洞、边界条件未处理、异常分支缺失。 2. 安全性是否直接拼接不可信输入是否缺少鉴权或越权校验敏感信息是否硬编码。 3. 性能是否在循环内发起重复请求是否存在不必要的全表扫描或重复渲染。 4. 可维护性是否抽出了重复逻辑命名是否在当前目录上下文下足够清晰是否遗留调试代码。 5. 兼容性当前改动是否破坏旧的调用方式是否需要同步更新类型声明或文档。 ## 输出要求 每次代码交付时在代码块后追加一栏“自检结果”格式如下 - 正确性通过 / 不通过 一句说明 - 安全性通过 / 不通过 一句说明 - 性能通过 / 不通过 一句说明 - 可维护性通过 / 不通过 一句说明 - 兼容性通过 / 不通过 一句说明 ## 触发方式 当用户要求“生成代码”“修改代码”“重构代码”“修复 Bug”时自动执行本规则。这条规则用了一个月之后团队 Review 里关于低级质量问题的讨论明显变少。原因是它把“模糊的质量要求”变成了“五个固定维度的自检动作”AI 在生成代码时真的会走一遍这个清单并在末尾给你一个形式统一的自检结果。5.3 如何把它变成团队的“活文档”写好规则只是第一步真正让它融入工作流还要做两件额外的事。第一件是把规则放入 Git 仓库管理。.cursorrules这类文件完全适合放进版本管理这样团队里每个人 Clone 之后都能共享同一套规则后续更新也有历史记录。我当时就把规则文件单独建了个cursor-rules/目录里面按用途拆分甚至写过一个小脚本在需要时把多个分片拼装成一个完整文件。这样做的好处是规则本身可以像代码一样被 Review 和迭代。第二件是给规则加“失效日期”或“待办检查”。规则不是写一次就永久有效的。技术栈升级、团队约定变化、或者某条规则长期没有产生正面反馈都需要及时清理。我现在会在每条规则的末尾写一行简短的“最后修订日期和背景”方便三个月后回看时判断它是否还适用。5.4 一个细节区分“主动规则”和“被动触发规则”在上述审查 Skill 里我加了一个“触发方式”字段这很关键。如果你把“每次输出自检结果”设置成 Always 常驻那么哪怕用户只是问一个问题AI 也会在回答后强行附上一大段自检结果非常烦人。加了一个触发范围限定之后规则只在代码生成类任务中生效其余场景不参与。Cursor 的 Auto 模式虽然也能做类似的事但我发现它偶尔会误判相关性。所以对于“只在特定任务中生效”的规则我会在文本里显式写清触发条件这比依赖模式自动判断更可控。6. 写 Skill 最容易翻车的几个场景与排查链路6.1 场景一规则写完了但不生效这是最常见的坑而且原因往往特别蠢。我第一次遇到时把规则写成了.cursorRules大小写不对文件根本没被识别。后来我意识到这类文件对文件名大小写是明确的.cursorrules全小写才是最稳妥的写法。另一个高频原因是改完规则之后没有开新会话。规则是启动会话时注入的已经打开的会话不会动态刷新。所以排查链路固定是确认文件名和路径正确。确认写入的是项目根目录或图形界面里对应的项目 Rules 面板。新开一个对话重新描述需求测试。如果还是不生效在对话里直接问 Cursor“当前项目的规则内容里包含哪几条”看它能否完整复述。第四步是终极验证手段。模型能复述出你的规则说明它已被加载复述不出来那就是加载失败直接检查前面两步。6.2 场景二规则生效了但“大事不听”有时候规则只有 30 行AI 能复述但真到复杂任务时依旧我行我素。我观察下来的原因有两个。一是上下文被任务内容挤占。当任务本身非常长、代码库搜索信息量大时排在后面的规则容易被压缩AI 会选择性地遗忘部分约束。解决思路是把最硬性的 3 条底线放到规则文档的最开头确保它们优先进入注意力区间。二是无效信息稀释了指令强度。比如规则里写了一大段项目历史背景模型可能会把重点理解成“了解背景”而忽略了后面的操作规范。解决办法是精简背景描述只留与编码决策直接相关的技术约束。6.3 场景三全局规则和项目规则打架我见过最典型的案例全局规则里写了“优先使用函数组件”而某个老项目出于历史原因还在用 Class Component项目规则里允许 Class 写法。结果 AI 在生成新代码时犹豫不决一会儿函数式一会儿类式最终输出干脆混着来。这个问题的解法不在“提升规则质量”而在“避免规则对立”。你在写项目级 Skill 时要主动检查全局规则里有没有和自己冲突的条目。官方文档可能定义了优先级但实测中最好的方案是永远不要让两种规则在同一段代码上较劲。如果没法避免就在项目规则里明确写“本项目范围内凡与全局规则冲突时以本规则为准”比不写要好得多。6.4 场景四Auto 模式导致时灵时不灵Auto 模式本来是想省上下文但它偶尔会误判你把“代码审查自检”设为 Auto改一个工具函数时它觉得不相关于是跳过自检可实际上这个函数恰恰是核心逻辑最需要自检。这种时灵时不灵的表现会让团队成员对 Skill 失去信任。我的建议是对重要约束不使用 Auto直接设为 Always对轻微的代码风格偏好才允许 Auto。判断标准很简单——如果这条规则被跳过会让代码质量明显下降就选 Always跳过之后只是风格不统一不影响正确性才选 Auto。6.5 我的最终调试顺序写规则写得越多越觉得它像调试程序只是调试对象是模型行为。我现在遇到“规则没起作用”的情况会按下面这套顺序快速定位先确认规则确实被加载新开对话让 AI 复述规则。再确认任务命中触发条件规则里写了“修改 2 个及以上文件才生效”那测试时就不能只改一个文件。接着检查规则文档长度超过 300 行的高密度规则直接考虑拆分成多个 Skill。然后检查规则是否与其他规则冲突全局和项目分别列出来逐条找语义对立。最后检查上下文当前任务是否包含大量无关历史把规则的有效注意力挤没了。这套流程基本能解决我遇到过的 95% 的“规则不听话”问题。最后再分享一个我自己的习惯我给每个项目的规则文件都开了 Git 历史每次调整都写清楚原因而不是直接覆盖。这样当某个规则导致 AI 行为异常时我可以快速回滚到之前可用的版本再对比差异找出是哪一句话引发了“性格突变”。另外如果你刚开始接触 Skill不要追求一次写全先从“每天都会遇到的小抱怨”开始写一条、测一条、优化一条让规则始终贴近真实需求比刻意追求大而全要重要得多。