🚀 进化之路:从"人教 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) |
每次都要重复解释项目背景 | 知识没有沉淀 |
调教好的提示词,换个项目又要重来 | 经验无法复用 |
今天分享我探索出的两个核心武器:
AI 是纯执行角色,你给的边界越清晰,输出越可控
把 AI 想象成"超级实习生":
一个判断标准:如果人类工程师无法明确说出在给定情况下应该怎么做,AI 智能体也不能做得更好。
与其让人在 review 时逐步想起遗漏告诉 AI,不如建立系统化的上下文管理,让 AI 自动获取精简且高信号的信息。
┌─────────────────────────────────────────────────┐
│ 📄 Context(上下文-项目地图) │ ← 项目是什么
├─────────────────────────────────────────────────┤
│ 📏 Rules(代码规范-自动驾驶辅助线) │ ← 代码怎么写
├─────────────────────────────────────────────────┤
│ 🔄 Workflow(流程规范-标准操作程序) │ ← 需求怎么做
└─────────────────────────────────────────────────┘问题:AI 上下文窗口有限,一次塞太多会产生"记忆丢失"(Context Overflow)
解法:结构化文档,分阶段沉淀
context/
├── 项目概览.md → 技术栈、目录结构
├── 架构设计.md → 模块职责、数据流
├── 当前需求.md → 需求背景、预期目标
└── 代码映射.md → 需求与代码的对应关系进阶玩法:OpenSpec 规范优先
在写代码之前,先让人和 AI 对规范达成一致:
specs/
├── proposal.md → 问题陈述、方案概述、预期收益
├── design.md → 技术设计、架构决策、接口定义
└── tasks.md → 实现清单、任务拆解、验收标准流程:需求输入 → 生成 proposal → 确认后生成 design → 拆解为 tasks → 逐个实现 → 归档
💡 好处:AI 在动手前就理解了"为什么做"和"怎么做",减少返工
制定代码风格规范(如:优先使用 TypeScript、UnoCSS),让输出像你亲手写的一样。
原则 | 实践方法 |
|---|---|
需求理解是基础 | 反复确认:"你懂了吗?不懂就问我" |
代码理解是参考 | 用 md 文档沉淀现有代码的设计意图 |
规范统一是保障 | 制定代码风格规范,保持一致性 |
步骤 | 做什么 | 关键话术 |
|---|---|---|
聊需求 | 确保 AI 理解 | "你懂了吗?不懂哪里?" |
定方案 | 对齐技术方案 | "你打算怎么实现?最佳实践是什么?" |
分步做 | 小步快跑 | "先做 xxx,完成后再做下一步" |
⚠️ 黄金法则:永远不要让 AI 一口气完成大需求 任务越小 → AI 完成度越高 → Review 越轻松
层级 | 作用 | 效果 |
|---|---|---|
Context | 让 AI 了解项目 | 不用每次重复解释 |
Rules | 统一代码风格 | 输出质量稳定 |
Workflow | 规范开发流程 | 小步快跑,可控 |
💡 核心价值:让 AI 输出可控、可预期
Skill = 可复用的能力单元 = 提示词 + 文档 + 脚本
简单说:Skill 就是 .md 格式编写的"技能包"
本质是把专家的"最强状态"打包成 SOP,让经验在 Git 仓库里持续演进。
优势 | 说明 |
|---|---|
按需加载 | 需要时再喂给 AI,不占用宝贵的上下文空间 |
全员外挂 | 让新人的指尖瞬间具备架构师的经验 |
可移植性 | 复制一个文件夹,即可完成团队能力的快速迁移 |
随着开发次数的增加,从最初的"规范化命名"到"提取自定义 Hooks",再到最后的"AI 预设脚手架",开发效率会从"小时级"降至"分钟级"。
阶段 | 你的动作 | 产生的"复利" |
|---|---|---|
第 1 次 | 规范化命名与文档 | 以后不用翻设计稿找尺寸 |
第 2 次 | 提取 useHooks | 业务逻辑与 UI 彻底解耦 |
第 6 次+ | 配置化/脚手架/AI 预设 | 开发效率从"小时级"降至"分钟级" |
💡 我们复用的是思想、模式和最佳实践,而不仅仅是代码实现。
三步搞定:
skills/my-custom-skill/SKILL.md(定义触发条件、执行流程、规范要求)SKILL.md 模板:
---
name: my-custom-skill
description: 这个技能做什么
---
# 技能说明
## 触发条件
当用户需要 xxx 时触发
## 执行流程
1. 第一步做什么
2. 第二步做什么
## 规范要求
- 规范 1
- 规范 2维度 | 无 Skill | 有 Skill |
|---|---|---|
效率 | 每次重复解释 | 一次加载,直接干活 |
质量 | 靠运气 | 靠规范 |
复用 | 经验在脑子里 | 经验在文件里 |
协作 | 口口相传 | 复制粘贴 |
💡 核心价值:让经验可复用、可传承
┌──────────────────────────────────────────────┐
│ 完整工作流 │
├──────────────────────────────────────────────┤
│ 📄 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 高效工作的,是背后那套完整的规范体系:Context 让它了解项目,Rules 让它遵循规范,Skill 让它具备能力,Workflow 让协作顺畅。
我越来越相信一件事:
只要文档落地、规范落地、维护得好,未来人写代码就变得越来越简单了,0门槛。
当规范足够完善,当 Skill 库足够丰富,当 Context 足够清晰——AI 就能自动完成从需求理解到代码生成的全过程。
人的角色会从"代码编写者"变成"规范制定者"和"质量把关者"。
AI Coding 效能 = 需求理解能力 × 技术判断力 × 规范完善度 三者缺一不可,规范是放大器!
工具在进化:
但有些东西永远不会变:
需求理解和技术判断永远是核心竞争力
会写代码,不再是核心能力。会思考、会提炼观点、会审校,才是。
我们正在完成从"代码编写者"到"规范制定者"与"质量把关者"的转型。
从"会写代码"到"会提需求 + 会审代码"——这是我们这一代开发者必须完成的转型。
不是所有工作都值得交给 AI,但所有低价值的重复性工作都应该被 AI 替代。
这样做的核心价值不在于省了多少人力,而在于让我们得以从繁琐的执行中抽身,专注于更高价值的事情:设计流程、优化体验、创造新价值。
我把我的经验都写进了规范里,祝我早日成为一个 Prompt 工程师管理师!
🔗 一个小技巧:如果你在 AI 编程中,同一个错误出现了 2 次以上,或者某个需求反复不符合预期,请务必让 AI 记下来(写入 Rules)。这能显著提高效率,避免重复踩坑。
路漫漫其修远兮,吾将上下而求索。
期待和大家一起探索 AI 辅助开发的更多可能!