今日惊闻噩耗，老板将会淘汰两批人：
第一批：现在还不用 AI 写代码，还在手搓的代码信徒
第二批：无法借助 AI 一人完成需求，还在AI拉扯的缝合巨匠
只有能一人完成需求全流程实现的人才能留下来干活。老板说叫 Builder，这玩意和那些自媒体鼓吹的超级个体差不多是一个样。
Builder 看起来很高大上，说白了就是你一个人要干很多人的活。以前你是开发者，老板的要求是一个开发可以干10个开发者的活。
现在又动歪心思，开发者何必是开发者，也可以是产品经理，同时是设计师，同时还是运营，最离谱的是同时还是销售。
反过来，销售又何必是销售，同时可以是上面那几个。
我翻开推特一查，这推文没有强迫，歪歪斜斜的每页上都写着 AI 提效四个字。
我汽销怕横竖睡不着，仔细看了半夜，才从字缝里看出字来，满本都写着两个字是全干！
我认为我辈打人工可以有一个新的title：全干工程师。我老友觉得不够贴切，应该叫：雷锋式全干工程师！
老板的诉求很简单，干的多，还要拿的少。
我勒个豆，最后公司只剩2个人，老板和你。老板负责收钱和鞭策你干整个公司的活，你负责鞭策 AI 干整个公司的活。
你想想是不是有点不对？凭什么你就不能收钱，这不是欺负老实人吗？于是你揭竿而起...，决定开除老板，自己上位...
不好意思，好像扯远了，我们今天的主题是聊聊我是怎么一步步用 AI 来提高开发效率的。本来我想藏着这些东西的，但是现在我的思维发生了一些转变。
貌似开发的模式正在朝着上面那个方向发展，我觉得把我积攒下来的经验发布出来。
其实最主要是的原因是我觉得小龙虾接下来会颠覆整个软件开发的模式，再不把这篇文章发出来，到时候狗都不看了，哈哈哈哈哈哈。
我最开始让 AI 写代码的方式非常的原始啊，就详细描述需求+手动贴代码。
代表的软件就是cursor啦，因为那时候没有其他的方案可选，我15刀开了个Pro就可劲造。
使用的方式基本上就写需求+cursor中@文件写上怎么改。不知道是不是因为我写的是 Java，效果其实不太行。
所以流程就是 cursor AI 写一遍+人工改，有时候还会贴到DeepSeek（当时刚出来说是代码能力贼好）
反正最后干出来的效果，满分 100 分，在我这最多只能给到40分。其实效率没有提高多少，但架不住老板天天问：
今天用cursor没？今天用cursor没？今天用cursor没？
后面出了codex，老板在推特上看到有个哥们一天用codex干了19个pr，就急了。
也给整了一个来玩，codex刚出的时候是云端的。妈蛋，环境配置给我差点整破防了，还好后面 claude code 出来了。
事实证明，claude code 体验上秒杀 codex。这不，后面OpenAI 也整了个codex cli。
cc 出来稍微好点。对于 Javaboy 来说，能在 IDEA 中体验到AI实属不易。我感动得狂写了一堆垃圾代码。
对于直接让大模型一把梭这种事情，大模型是非常擅长的。只是对于开发者来说就是双倍痛苦了，大模型写出来的东西又臭又长，这就导致大部分的开发者需要 cc 先生成一遍代码，能有个40-50%能用。
然后 cursor 微调，cursor的自动补全还是挺智能的，为了这个自动补全我还整了一遍用cursor替代IDEA进行Java开发【链接】。
这个阶段用起来肥肠的痛苦啊，我自己代码没写多少光 review AI 写的了。要知道让程序员改别人的垃圾代码真的是双倍痛苦啊，不止，应该有5倍。
随着模型迭代了几轮，我就探索先 plan 再编码。事实证明方向对了，编码的可用性和一致性提高不少。
好景不常，在快乐的 planing+coding 流程跑起来后，很快又遇到一个问题：如果上下文太长了，plan好的东西模型就忘记了。
不止模型忘记，我也忘记，因为不是我写的，这真不能怪我。
为了解决这个问题我到处找解决方案，最终找到这哥们的一篇文章，说用三个文件存在在本地来持久化一些上下文信息。
这哥们的github 是英文的，我让cc翻译了一遍： github.com/hongweihao/…
主要就这三个文件：
- context.md： 用于记录上下文和一些关键决策，避免大模型死循环
- plan.md：用于记录具体的设计实现
- tasks.md：基于plan 和 context 拆解任务
这个模式一用上，我的效率立马飙升，平时并发干两三个任务都很吃力。用上这个模式，干五六个都还能刷刷手机。
腰不疼了，腿不酸了。好景也又不长了，很快遇到了另一个问题：
- 大的需求规划出来不够详细，很多细节大模型会自由发挥。
- 还有每次改完代码就给我写一个说明文档，一套整下来，文档比代码还多。
就这样我熬了 1 个月，直到亚马逊发布了 Kiro。它带来了一种新的AI编程方式：
spec-drive development，规范驱动编程，简称 SDD。
这个名字不对劲，怎么一读起来就在我的头就开始痛了？原来是有一个货色叫 DDD，相信不少开发都被这东西折磨过。
SDD 和 DDD 很像，他们都有 DD，不过只有DDD是DD，SDD不是DD。
DDD 讲究领域驱动 domain-drive，SDD 讲究规范驱动 spec-drive。
领域驱动说白了就是先设计好领域，再开始编码实现。
规范驱动说白了就是先写好设计文档，实现文档再编码实现。
对了还有一个DD 叫 测试驱动开发，简称 TDD。说白了就是先写好测试再开始编码实现。
反正差不多是这个路子，先写好测试我能懂，设计领域不想懂，那规范怎么说？明明知道程序员不喜欢写文档，你还搞这种事情？
秋的嘛得啊，这不是有 AI 了吗？你不擅长写文档，但是 AI 擅长啊。
甚至连怎么写都有人整好了，我辈javaboy，做一个东西之前都会习惯性先看看github上面是不是已经有了。
不是不想造轮子，而是省点时间摸摸鱼他不香吗？啥都自己干只会害了你。
这不，我找到了2个比较易懂的，实际上我也正在使用OpenSpec。
github.com/github/spec… 是GitHub 家整的，用起来稍微复杂点，功能更全。
对于我这种懒人来说，没有什么比省事更吸引我，于是我毫不犹豫梭哈了 OpenSpec，spec-kit 我只让cc给我分析了一下咋用就丢到一边了。
OpenSpec 用起来也很简单，最简单的流程是三个阶段：提案 -> 实现 -> 归档
使用之前先安装，这是赛博世界的共识。
# 安装openspec 到机器上
npm install -g @fission-ai/openspec@latest
# 初始化项目
# openspec init
✔ Select tools to set up (24 available) Claude Code
▌ OpenSpec structure created
✔ Setup complete for Claude Code
OpenSpec Setup Complete
Created: Claude Code
4 skills and 4 commands in .claude/
Config: openspec/config.yaml (schema: spec-driven)
Getting started:
Start your first change: /opsx:propose "your idea"
Learn more: https://github.com/Fission-AI/OpenSpec
Feedback: https://github.com/Fission-AI/OpenSpec/issues
Restart your IDE for slash commands to take effect.
初始化的过程中会让你选择使用的 agent 工具，我用的是cc，空格选中，然后回车即可。安装完成，会创建一些目录文件
+---.claude
| +---commands
| | ---opsx
| | apply.md
| | archive.md
| | explore.md
| | propose.md
| |
| ---skills
| +---openspec-apply-change
| | SKILL.md
| |
| +---openspec-archive-change
| | SKILL.md
| |
| +---openspec-explore
| | SKILL.md
| |
| ---openspec-propose
| SKILL.md
|
---openspec
| config.yaml
|
+---changes
| ---archive
---specs
安装完成之后，openspec 默认会提供4个斜杠命令。启动 claude 爽用
一般我们干活都差不多是这几个步骤：
- 收到各个渠道反馈的问题，或者是新需求
- 如果是bug就分析原因，如果是需求就分析怎么做
- 基于分析的结果开始实现
- 实现完提交给测试
简单点就是：有活 =》 咋干 =》 开干 =》让测
openspec 对应到这套流程里面怎么运转呢？
第一步 explore：
把活描述给AI，和他讨论咋干。
也有大胸弟不逼逼赖赖的，上来就是干，所以这一步可以也省略
第二步 propose：
可以基于上一步掰头的内容让他规划，但是有时候简单的活就直接让他开始规划。
AI 会自动扫描项目，然后写出一个提案。提案简单来说就是几个文件：
- proposal.md：写为什么做，做什么，边界是什么
- design.md：写上实现方案
- tasks.md：基于上面的两个文件拆解任务
- spec：是一个目录，写了一些规范。什么是要的，什么是不要的。
第三步 apply：
上一步的文件出来之后你可以看看是不是符合你的预期。当前你不看也行，反正干得不对你自己兜着就行。
apply 就是让AI 根据刚刚的提案干活，他干完活会自己把 tasks 里面的任务勾上。
第四步 archive：
干完活，跑完测试没问题。就把提案归档，说白了就是把提案的目录移动到归档目录。
还有就是 spec 的合并，spec 合并就是文档的沉淀。给个案例看一下，其实我也搞不透彻是什么个作用。
接下来就是对这个流程的不断优化以及自动化了，真是一次惊心动魄的变革呀，兄弟们支棱起来。
