🚀 进化之路：从"人教 AI"到"AI 带人"
AI 可以写代码，但它不知道该做什么；AI 可以替我写，但不能替我想。
会写代码不再是核心能力，会思考、会定规范、会审代码，才是。
写在前面：一个"工具人"的自白
最近我陷入了一种奇怪的状态——
我感觉自己成了一个工具人。
每天都在尝试各种 AI 工具，各种工具筐筐一顿往项目里造。今天是提示词工程，明天是 MCP，后天又是 Skill、Rules……
从前是向 ChatGPT 提问代码，再把回答粘贴到 IDE；到如今是各路 AI 辅助编程工具轮番上阵。
一路走来，我学会了什么？
Prompt 工程、项目规划、规范约束的能力。 好像都不是，我什么也不会
各种概念满天飞：MCP、Skill、Agent……项目里疯狂一顿 AI 炫。
但说实话，AI 能力的扩展也确实让我的专业能力得以延伸——我可以不知道，AI 知道就够了。
但我真正的目标，不是被工具牵着走。
我的终极目标：成为那个驾驭它们的老板。
开篇：一个真实的"翻车"现场
"帮我实现一个 XX 功能"
AI 秒出代码，看起来还不错，简单体验了一下功能，好像是那么回事...
但仔细一看：class 组件？我们用的是函数组件；全局 CSS？我们用的是 UnoCSS；命名风格也不对...
改完这些，时间都花在"纠错"上了。最后花在"纠错"上的时间，比自己写还长。
这种"AI 写完人来收拾残局"的经历，是不是很熟悉？
😫 常见痛点与根因分析
| 😫 痛点 | 🔍 根因 |
|---|---|
| 代码风格和项目不一致 | AI 不了解项目规范 |
| 同一问题，换个上下文答案完全不同 | AI 没有"记忆" |
| 大需求一次生成，质量惨不忍睹 | 上下文超载（Context Overflow） |
| 每次都要重复解释项目背景 | 知识没有沉淀 |
| 调教好的提示词，换个项目又要重来 | 经验无法复用 |
今天分享我探索出的两个核心武器：
- OpenSpec —— 规范驱动，让 AI 输出可控
- OpenSkills —— 能力增强，让经验可复用
一、OpenSpec：建立 AI 的"数字围栏"
核心理念
AI 是纯执行角色，你给的边界越清晰，输出越可控
把 AI 想象成"超级实习生"：
- ✅ 执行力强、不知疲倦、知识面广
- ❌ 但需要明确的指令和规范，否则容易"自由发挥"
一个判断标准：如果人类工程师无法明确说出在给定情况下应该怎么做，AI 智能体也不能做得更好。
与其让人在 review 时逐步想起遗漏告诉 AI，不如建立系统化的上下文管理，让 AI 自动获取精简且高信号的信息。
三层规范体系
┌─────────────────────────────────────────────────┐
│ 📄 Context（上下文-项目地图） │ ← 项目是什么
├─────────────────────────────────────────────────┤
│ 📏 Rules（代码规范-自动驾驶辅助线） │ ← 代码怎么写
├─────────────────────────────────────────────────┤
│ 🔄 Workflow（流程规范-标准操作程序） │ ← 需求怎么做
└─────────────────────────────────────────────────┘
1️⃣ Context：让 AI "认识"你的项目
问题：AI 上下文窗口有限，一次塞太多会产生"记忆丢失"（Context Overflow）
解法：结构化文档，分阶段沉淀
context/
├── 项目概览.md → 技术栈、目录结构
├── 架构设计.md → 模块职责、数据流
├── 当前需求.md → 需求背景、预期目标
└── 代码映射.md → 需求与代码的对应关系
进阶玩法：OpenSpec 规范优先
在写代码之前，先让人和 AI 对规范达成一致：
specs/
├── proposal.md → 问题陈述、方案概述、预期收益
├── design.md → 技术设计、架构决策、接口定义
└── tasks.md → 实现清单、任务拆解、验收标准
流程：需求输入 → 生成 proposal → 确认后生成 design → 拆解为 tasks → 逐个实现 → 归档
💡 好处：AI 在动手前就理解了"为什么做"和"怎么做"，减少返工
2️⃣ Rules：让 AI 输出"像你写的"
制定代码风格规范（如：优先使用 TypeScript、UnoCSS），让输出像你亲手写的一样。
| 原则 | 实践方法 |
|---|---|
| 需求理解是基础 | 反复确认："你懂了吗？不懂就问我" |
| 代码理解是参考 | 用 md 文档沉淀现有代码的设计意图 |
| 规范统一是保障 | 制定代码风格规范，保持一致性 |
3️⃣ Workflow：需求实现三步走
| 步骤 | 做什么 | 关键话术 |
|---|---|---|
| 聊需求 | 确保 AI 理解 | "你懂了吗？不懂哪里？" |
| 定方案 | 对齐技术方案 | "你打算怎么实现？最佳实践是什么？" |
| 分步做 | 小步快跑 | "先做 xxx，完成后再做下一步" |
⚠️ 黄金法则：永远不要让 AI 一口气完成大需求
任务越小 → AI 完成度越高 → Review 越轻松
OpenSpec 小结
| 层级 | 作用 | 效果 |
|---|---|---|
| Context | 让 AI 了解项目 | 不用每次重复解释 |
| Rules | 统一代码风格 | 输出质量稳定 |
| Workflow | 规范开发流程 | 小步快跑，可控 |
💡 核心价值：让 AI 输出可控、可预期
二、OpenSkills：让经验"原子化"与资产化
什么是 Skill？
Skill = 可复用的能力单元 = 提示词 + 文档 + 脚本
简单说：Skill 就是 .md 格式编写的"技能包"
本质是把专家的"最强状态"打包成 SOP，让经验在 Git 仓库里持续演进。
💡 为什么需要 Skill？
| 优势 | 说明 |
|---|---|
| 按需加载 | 需要时再喂给 AI，不占用宝贵的上下文空间 |
| 全员外挂 | 让新人的指尖瞬间具备架构师的经验 |
| 可移植性 | 复制一个文件夹，即可完成团队能力的快速迁移 |
知识复利的演进路径
随着开发次数的增加，从最初的"规范化命名"到"提取自定义 Hooks"，再到最后的"AI 预设脚手架"，开发效率会从"小时级"降至"分钟级"。
| 阶段 | 你的动作 | 产生的"复利" |
|---|---|---|
| 第 1 次 | 规范化命名与文档 | 以后不用翻设计稿找尺寸 |
| 第 2 次 | 提取 useHooks | 业务逻辑与 UI 彻底解耦 |
| 第 6 次+ | 配置化/脚手架/AI 预设 | 开发效率从"小时级"降至"分钟级" |
💡 我们复用的是思想、模式和最佳实践，而不仅仅是代码实现。
如何自己制作 Skill？
三步搞定：
- 新建文件夹
skills/my-custom-skill/ - 编写
SKILL.md（定义触发条件、执行流程、规范要求） - 添加配套资源（docs/、scripts/，可选）
SKILL.md 模板：
---
name: my-custom-skill
description: 这个技能做什么
---
# 技能说明
## 触发条件
当用户需要 xxx 时触发
## 执行流程
1. 第一步做什么
2. 第二步做什么
## 规范要求
- 规范 1
- 规范 2
OpenSkills 小结
| 维度 | 无 Skill | 有 Skill |
|---|---|---|
| 效率 | 每次重复解释 | 一次加载，直接干活 |
| 质量 | 靠运气 | 靠规范 |
| 复用 | 经验在脑子里 | 经验在文件里 |
| 协作 | 口口相传 | 复制粘贴 |
💡 核心价值：让经验可复用、可传承
三、1 + 2 = 最大化效能
完整工作流
┌──────────────────────────────────────────────┐
│ 完整工作流 │
├──────────────────────────────────────────────┤
│ 📄 Context → AI 了解项目背景 │
│ 📏 Rules → AI 遵循代码规范 │
│ ⚡ Skill → AI 具备专业能力 │
│ 🔄 Workflow → 人机高效协作 │
└──────────────────────────────────────────────┘
知识的复利效应
需求 #1 ───→ 建立 context/（从0到1，投入）
需求 #2 ───→ 复用 context/（边际成本开始下降）
需求 #3-5 ──→ 沉淀 rules/（规范逐渐完善）
需求 #6+ ───→ 封装为 Skill（能力产品化）
团队共享 ───→ 全员复用（知识复利爆发）
效果对比
| 阶段 | 传统模式 | OpenSpec + OpenSkills |
|---|---|---|
| 新人入职 | 老人讲解 4-7 小时 | 加载文档 20 分钟 |
| 首次质量 | 不稳定，靠运气 | 稳定，有规范保障 |
| 知识传承 | 口口相传，易丢失 | 文件化，可追溯 |
| 边际成本 | 固定不变 | 持续递减 |
四、核心理念转变：从代码复用到规范复用
AI 时代最大的变化是代码生成成本的急剧下降。
当编写一个新组件的边际成本接近于零时，我们为什么还要承受复杂组件带来的维护负担？
新的解决思路：
与其构建一个极其复杂的"万能组件"来适配所有场景，不如为每个具体场景定制专门的实现：
- 为每个具体场景定制专门的组件实现
- 通过 AI 按需生成，而不是试图构建万能组件
- 让每个组件专注于特定场景，逻辑更简洁清晰
我们通过规范约束 AI 快速生成，保持逻辑的简洁与纯粹。
规范驱动开发的价值：
| 维度 | 传统方式 | 规范驱动 |
|---|---|---|
| 复用方式 | 复杂的万能组件 | 简洁的专用组件 |
| 质量保障 | 依赖个人经验 | 规范约束 AI 生成 |
| 开发效率 | 小时级 | 分钟级 |
| 真正复用的是 | 具体代码实现 | 思想、模式和最佳实践 |
💡 这就是基于规范的复用——我们复用的是设计理念、接口规范和最佳实践，而不是具体的代码实现。
五、我的思考与展望
只要提示词写得够好？
有段时间我沉迷于打磨提示词，觉得"只要我的提示词写得够好，AI 就能完美执行"。
但后来我发现，提示词只是冰山一角。
真正让 AI 高效工作的，是背后那套完整的规范体系：Context 让它了解项目，Rules 让它遵循规范，Skill 让它具备能力，Workflow 让协作顺畅。
未来的畅想
我越来越相信一件事：
只要文档落地、规范落地、维护得好，未来人写代码就变得越来越简单了，0门槛。
当规范足够完善，当 Skill 库足够丰富，当 Context 足够清晰——AI 就能自动完成从需求理解到代码生成的全过程。
人的角色会从"代码编写者"变成"规范制定者"和"质量把关者"。
核心公式
AI Coding 效能 = 需求理解能力 × 技术判断力 × 规范完善度
三者缺一不可，规范是放大器！
不变的核心
工具在进化：
- 2024：Agent 爆发
- 2025：MCP / OpenSpec / Skill ...
- 未来：更多可能
但有些东西永远不会变：
需求理解和技术判断永远是核心竞争力
会写代码，不再是核心能力。会思考、会提炼观点、会审校，才是。
我们正在完成从"代码编写者"到"规范制定者"与"质量把关者"的转型。
从"会写代码"到"会提需求 + 会审代码"——这是我们这一代开发者必须完成的转型。
写在最后
不是所有工作都值得交给 AI，但所有低价值的重复性工作都应该被 AI 替代。
这样做的核心价值不在于省了多少人力，而在于让我们得以从繁琐的执行中抽身，专注于更高价值的事情：设计流程、优化体验、创造新价值。
我把我的经验都写进了规范里，祝我早日成为一个 Prompt 工程师管理师！
🔗 一个小技巧：如果你在 AI 编程中，同一个错误出现了 2 次以上，或者某个需求反复不符合预期，请务必让 AI 记下来（写入 Rules）。这能显著提高效率，避免重复踩坑。
路漫漫其修远兮，吾将上下而求索。
期待和大家一起探索 AI 辅助开发的更多可能！
📢 关注我，共享我知，我思，我学，我想
