我自己写的第一个skills--project-core-standards

背景

用 AI 写代码一段时间后，我发现一个很反直觉的问题：我们其实已经有一些"最佳实践"，但它们无法复用：

A 项目调教好的 AI，在 B 项目完全失忆
规则散落在 prompt / 文档 / IDE 配置中，无法版本化
每次新项目，都在重复"驯化 AI"

既然代码可以用 Git 管理、用 NPM 分发，为什么 AI 规范还停留在"复制粘贴"？

本质问题是：我一直把规则当"文本"，而不是"代码"。

把规则当代码看

如果把 AI 规则当作代码，它应该具备三个能力：

可组合（Composable） → 不同规则可以拆分、复用
可分发（Distributable） → 像 npm 包一样安装
可演进（Versioned） → 有版本、有变更记录

否则它就不是工程资产，而只是碎片化经验沉淀。一个规范，如果不能被 install，那它本质上只是不成体系的经验。

Skill 的最小抽象模型

那问题来了：一个"可安装的 AI 规范"，在工程上到底长什么样？

最小结构其实非常简单：

go 复制代码

my-skill/
├── SKILL.md
├── rules/
├── package.json

但真正的关键不是结构，而是它解决的问题。

1️⃣ rules目录让 AI "分块理解"，而不是"整体吞咽"

传统方式是把所有规则写在一个 prompt 里，但这会导致：

上下文污染 + 规则冲突 + AI 记忆漂移

拆分之后：

behavior rules：开发行为约束
optimization rules：代码质量优化规则

AI 不再"理解一坨规则"，而是按职责加载规则上下文

2️⃣ SKILL.md 让 AI 知道"自己在哪个体系里"

AI 最大的问题不是不会写代码，而是：

不知道当前约束体系是什么

SKILL.md 本质是一个"运行时契约"：

makefile 复制代码

name: project-core-standards
description: 项目的核心代码规范、行为准则与架构要求
version: 1.0.0
author: Admin

它定义的不是规则内容，而是：规则系统的身份边界

3️⃣ package.json 从"规则文件"升级为"能力模块"

一旦进入 npm 体系，规则就发生了本质变化：从"文档"变成"可安装能力"

真实使用方式：一行命令安装自定义skills

这套自定义的skills最终是这样被使用的：

csharp 复制代码

npx project-core-standards init

执行后，会进入一个交互式初始化流程：

less 复制代码

Welcome to Project Core Standards Setup

Please select the IDEs you want to generate rules for:
[1] Cursor (.cursorrules)
[2] Windsurf (.windsurfrules)
[3] Antigravity / Gemini (GEMINI.md)
[4] GitHub Copilot (.github/copilot-instructions.md)
[5] Cline / Roo Code (.clinerules)
[6] Codex (.codexrules)
[A] All of the above

Enter your choices (e.g., 1,3 or A):

这一步的意义非常关键：同一套规则，可以适配所有主流 AI 编程环境**

也就是说：不再是"适配工具"，而是"统一规则源"

最终 Skill 的形态（project-core-standards）

最终，我把这套系统封装成了一个 npm 包： project-core-standards

它的核心结构如下：

yaml 复制代码

---
name: project-core-standards
description: 项目的核心代码规范、行为准则与架构要求。适用于所有需要编写代码、重构或进行代码审查的场景。
version: "1.0.0"
author: "Admin"
---

两个核心规则（真正落地的部分），Skill 的真正价值，不是结构，而是规则本身。

1. Agent 行为与全局开发规范

diff 复制代码

涵盖核心开发底线：

- commit 规范化（Conventional Commits）
- pnpm 作为唯一包管理方式
- Vue 项目结构约束
- TypeScript 强制类型约束
- 数据库变更必须可追踪
- 组件必须可复用、不可重复造轮子

这个规则解决的是：AI 写代码"失控"的问题

2. 代码简化与优化专家原则

diff 复制代码

核心目标：保持功能不变的前提下优化代码质量

原则包括：

- 优先简化逻辑，而不是增加抽象
- 删除重复代码，而不是复制模式
- 提升可读性优先于"设计模式正确性"
- 避免过度工程化
- 保持结构一致性

这个规则解决的是： AI 过度设计 / 复杂化代码的问题

真正的难点：无损同步机制

分发不是问题，问题是： 如何更新规则，而不破坏项目已有定制？ 这里的设计核心是 Marker：

xml 复制代码

<!-- BEGIN: project-core-standards -->
<!-- END: project-core-standards -->

同步逻辑：

检测 marker → 精准替换区块
无 marker → 自动安全注入

本质是： 局部 patch，而不是文件 overwrite

工程实现关键点，在 CLI 层：

使用 INIT_CWD 定位真实项目路径
install 阶段自动触发同步
基于 AST + regex 做安全替换

核心思想是：把 Git 的 diff 能力，搬进 AI 规则系统**

结语：当规则变成基础设施

引入 project-core-standards 后，开发流程变成：

以前：

新项目 → prompt 调教 → 规则迁移 → 人工同步

现在：

npx init → 自动生成规则体系

当 AI 成为开发流程的一部分，一个新的层级出现了：

应用代码层
工程工具层
AI 规则层（Skill）

而 Skill 的意义是： 让 AI 行为本身，变成可工程化管理的资产

未来可能会变成这样：不再"调教 AI"，而是"安装开发规范"。想了解详细的规则内容可以点击这里查看。