锻造Skill，持续优化，让 AI 行为本身，变成可工程化管理的资产

用 AI 写代码也算有些时日了。从最初的新鲜尝试到现在几乎离不开它这个过程让我积累了不少经验。我发现自己在不同项目里反复做着同样的事情调教 AI、设定规则、优化 prompt。每次换一个新项目或者换一个新的 AI 工具一切都要从头开始。就像打游戏每次都从第一关重新开始之前的攻略没法带进新游戏。这种感觉说不上多痛苦但总觉得哪里不对。直到有一天我突然想明白了一个问题为什么代码可以用 Git 管理、可以用 NPM 分发而我的 AI 规范还停留在复制粘贴的阶段问题的本质我们把规则当成了文本回想一下我们平时的做法●在 A 项目里精心调教 Prompt让 AI 学会了某种代码风格●把这个 Prompt 复制到 B 项目●发现 AI 完全不记得之前学到的规矩●重新开始调教……周而复始。这不是工具的问题也不是 AI 的问题。这是我们对待AI 规则的方式本身出了问题——我们一直把规则当作文本而不是代码。代码之所以能成为工程资产是因为它具备三个核心能力可组合Composable → 不同规则可以拆分、复用可分发Distributable → 像 npm 包一样安装可演进Versioned → 有版本、有变更记录如果 AI 规则也具备这三个能力它就能从碎片化经验变成可管理的工程资产。否则一个规范如果不能被 install那它本质上就只是不成体系的经验。Skill 的最小抽象模型那问题来了一个可安装的 AI 规范在工程上到底长什么样我探索出来的最小结构其实非常简单12345my-skill/├── SKILL.md├── rules/├── package.json但真正的关键不是结构而是它解决的问题。1️⃣ rules 目录让 AI分块理解我们传统的做法是把所有规则写在一个巨大的 prompt 里。但这会带来三个问题●上下文污染规则太多AI 记不住重点●规则冲突不同规则之间互相矛盾●记忆漂移AI 在长对话中逐渐忘记规则拆分之后结构就清晰了●behavior rules开发行为约束●optimization rules代码质量优化规则AI 不再理解一坨规则而是按职责加载对应的规则上下文。就像微服务架构一样每个规则模块各司其职。2️⃣ SKILL.md让 AI 知道自己在哪个体系里这是我自己趟过的坑AI 最大的问题不是不会写代码而是不知道当前的约束体系是什么。SKILL.md 本质上是一个运行时契约12345name: project-core-standardsdescription: 项目的核心代码规范、行为准则与架构要求version: 1.0.0author: Admin它定义的不是规则内容而是规则系统的身份边界。就像每个 npm 包都有自己的 name 一样这个文件告诉 AI这个规则的名字是什么它属于哪个体系。3️⃣ package.json从规则文件升级为能力模块一旦进入 npm 体系一切都变了。从文档变成可安装能力——这个描述可能有点抽象但实际效果非常直接同一套规则可以适配所有主流 AI 编程环境。这意味着不再是适配工具而是统一规则源。你定义一次规则然后可以选择要为哪些工具生成对应的配置文件。真实使用方式一行命令安装自定义 skills这套自定义的 skills 最终是这样被使用的12npx project-core-standards init执行后会进入一个交互式初始化流程12345678910111213141516Welcome to Project Core Standards SetupPlease 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 aboveEnter your choices (e.g., 1,3 or A):这一步的意义非常关键——同一套规则可以无缝适配所有主流 AI 编程环境。规则定义一次自动适配多个工具。最终 Skill 的形态最终我把这套系统封装成了一个 npm 包project-core-standards。它的核心结构非常轻量12345name: project-core-standardsdescription: 项目的核心代码规范、行为准则与架构要求。适用于所有需要编写代码、重构或进行代码审查的场景。version: 1.0.0author: Admin两个核心规则Skill 的真正价值不是结构而是规则本身。规则一Agent 行为与全局开发规范涵盖核心开发底线●commit 规范化Conventional Commits●pnpm 作为唯一包管理方式●Vue 项目结构约束●TypeScript 强制类型约束●数据库变更必须可追踪●组件必须可复用、不可重复造轮子这个规则解决的是AI 写代码失控的问题。它就像一道护栏确保 AI 的输出始终在项目允许的范围内。规则二代码简化与优化专家原则核心目标在保持功能不变的前提下优化代码质量。原则包括●优先简化逻辑而不是增加抽象●删除重复代码而不是复制模式●提升可读性优先于设计模式正确性●避免过度工程化●保持结构一致性这个规则解决的是AI 过度设计或复杂化代码的问题。AI 很喜欢炫技这个规则就是给它设一个边界——简洁比花哨更重要。真正的难点无损同步机制分发不是问题问题是如何更新规则而不破坏项目已有的定制这是我自己设计系统时花了最多时间思考的部分。核心设计是 Marker123!-- BEGIN: project-core-standards --!-- END: project-core-standards --同步逻辑●有 marker → 精准替换区块只更新你定义的内容●无 marker → 自动安全注入不影响项目原有配置本质是局部 patch而不是文件 overwrite。工程实现有几个关键点●使用 INIT_CWD 定位真实项目路径●install 阶段自动触发同步●基于 AST regex 做安全替换核心思想是把 Git 的 diff 能力搬进 AI 规则系统。每次更新规则不会覆盖你项目的自定义配置而是像 git merge 一样精准地合并变更。结语当规则变成基础设施引入 project-core-standards 后开发流程变成了以前12新项目 → prompt 调教 → 规则迁移 → 人工同步现在12npx init → 自动生成规则体系当 AI 成为开发流程的一部分一个新的层级出现了●应用代码层——你的业务代码●工程工具层——构建、测试、部署●AI 规则层Skill——AI 行为的配置而 Skill 的意义是这不是在讲概念。这是在解决一个我们每天都在经历的、真实的痛点。如果你也在为 AI 规则无法复用而困扰不妨试试这个思路把规则当代码看给它结构、给它版本、给它分发能力。也许很快调教 AI这件事就会变得和 npm install 一个包一样简单。P