为 Skill 写好「反模式」：比正面步骤更重要的安全阀

正面步骤不够用

很多 SKILL.md 只写「应该怎么做」。模型在目标压力下会走捷径：跳过测试、硬编码密钥、扩大改动范围。反模式段落就是安全阀——明确告诉 AI 什么不能做，比多写三段励志背景更有用。

反模式要写到什么粒度？

好的反模式同时具备：

• 可观察：审查 diff 时能一眼看出有没有犯
• 可执行：不是「注意安全」这种空话
• 与本仓库相关：绑定你们的目录、命令、合规要求

弱例子：「不要写出不安全的代码。」

强例子：「禁止在客户端组件中读取 process.env 里的密钥类变量；密钥只允许出现在服务端 Route / Server Action。」

推荐分类写

安全类

• 禁止提交 .env、密钥、token
• 禁止信任前端传入的角色字段做鉴权
• 禁止关闭 TLS 校验「仅为了调试」并遗留到提交

范围类

• 禁止顺手重构无关模块
• 禁止删除现有测试让 CI 变绿
• 禁止引入未在讨论中的新依赖

质量类

• 禁止使用 any 掩盖类型错误（除非注释说明原因与拆除计划）
• 禁止复制粘贴重复组件而不抽取
• 禁止留下 console.log 调试输出

流程类

• 禁止在未运行项目指定测试命令前宣称完成
• 禁止修改锁文件除非任务明确要求升级依赖

写法模板

每条反模式建议用同一句式：

「禁止 + 具体行为 +（可选）正确替代。」

示例：「禁止用字符串拼接构建 SQL；必须使用参数化查询或 ORM 查询构建器。」

与 Rules 的关系

全局禁忌放 Cursor Rules；任务特有禁忌放 Skill。Skill 里可写一句：「若与仓库 Rules 冲突，以 Rules 为准。」避免两套文档打架。

从返工中生长反模式

最有效的来源不是想象，而是上周真实翻车：

1. 记录 AI 造成的返工

2. 抽象成一条禁止项

3. 写回对应 Skill

4. 在 团队 Skills 库 评审合入

检查清单

发布 Skill 前问自己：

• 若模型「聪明地偷懒」，最可能偷哪三步？这三步有没有对应禁止项？
• 安全与权限是否单独成组？
• 有没有「完成定义」与反模式互相呼应？

更多结构说明见 SKILL.md 格式指南。

小结

反模式不是消极写作，而是把失败经验编码成约束。没有安全阀的 Skill，只是一篇希望模型发挥好的散文。

下一步：打开你们最常用的一条 Skill，补上至少五条可审查的反模式。