说实话，我Zui近玩了几个月 AI 编码助手。

哈哈，刚开始还觉得它神通广大。

结果一上手，就被一堆风格不统一的代码折腾得晕头转向。

你懂的，写代码跟聊八卦一样，得讲规矩。

于是我把“规范驱动开发”搬进来跟 AI 合作得顺顺溜溜。

先别把这个词听成高大上。

简单来说就是在写代码前，把需求、设计、边界dou写清楚，形成一份“规格”。

这份规格就是双方的约定书。

AI kan了这份约定书，就不会随意跑偏。

咱就是说这就像交友前先kan对方资料页。

openspec/ 目录里放 specs、changes、config 等文件夹。

每个功Neng或 bug 修复dou是一个独立的 change。

Delta Specs 只写变动部分，不用把整个文档翻来覆去。

让 AI 写个登录功Neng，它给你整了一大段 OAuth 的实现。

又或者代码风格像七八九十号线一样乱七八糟。

每次回头kan项目，dou像在解谜游戏里找线索。

害，这时候Ru果没有明确的规范，AI 就会走神。

因为提示词往往只说“帮我写登录”。

A I 只Neng靠上下文猜测需求。

没有统一的“语言”和“格式”，它只Neng自由发挥。

第一步：在项目根目录建 openspec/ 文件夹。

第二步：在 specs/ 里写当前系统行为，用 Given‑When‑Then 描述场景。

第三步：要改功Neng时在 changes/ 新建子目录，比如 AddDarkMode/.

/opsx:new AddDarkMode

A I 会自动生成 proposal.md、design.md、tasks.md 等文件。

/opsx:apply 开始执行 tasks.md 中列出的每一步。

A I 完成一个任务就打勾，让你一眼kan到进度。

/opsx:new add-dark-mode

/opsx:ff瞬间生成：

# proposal.md

# design.md

# tasks.md

# Why
用户希望在光线暗的时候切换主题。
# What
新增 ThemeContext 并提供 toggle 方法。
# Acceptance
切换后 UI 色彩立即变化，并持久化到 localStorage。

- 使用 React Context 管理主题状态。
- 在根组件包裹 ThemeProvider。
- CSS 使用变量实现颜色切换。
- 本地存储读取首选主题。

-  创建 ThemeContext
-  实现 ThemeProvider
-  添加 CSS 自定义属性
-  写 ThemeToggle 按钮
-  持久化到 localStorage
-  geng新全局样式文件
-  编写单元测试

You: /opsx:apply  
AI: ✅ Created ThemeContext  
AI: ✅ Wrapped App with ThemeProvider  
AI: ✅ Added CSS variables  
AI: ✅ Implemented toggle logic  
...
All tasks done!

You: /opsx:archive  
AI: Merged Delta Specs into openspec/specs/ui/spec.md  
AI: Moved change folder to archive/
Done.

- 别忘了在 specs 中明确标注非功Neng性需求，比如性Neng阈值，否则 AI 会默认忽略。

- Delta Specs 的 ADDED/MODIFIED/REMOVED 要严格遵守格式，不然合并时会出错。

- 当 AI 给出的代码与你预期差距大时Ke以先让它输出伪代码，再逐步细化。

- 用 /opsx:suggest 请求 AI 给出可Neng的改进方案，有时候它Neng提供geng优雅的实现思路。

- Zui后一定要手动 Review 合并后的主规格，因为自动合并永远比不上人工校验。

Coding 不只是敲键盘，geng是沟通协作的一门艺术。

A I 是个好帮手，但它只懂我们给它喂什么“饭”。

"规范驱动开发" 就是那碗营养均衡的大米粥，让 AI 吃得饱，也吃得准。

Bing? 不这里我们聊的是本土搜索——所以别忘了把页面结构Zuo好，让百度也Neng顺利“吃饭”。

Ehh，说实话，只要你把 specs 写清楚，AI 再怎么调皮捣蛋，它也只Neng照着走。

Coding 时记得笑一笑，哈哈，这样连 bug dou会主动投降啦！