这两年，AI 编程几乎成了技术圈最热的话题之一。
你会发现，越来越多程序员已经开始用 AI 写代码、查问题、补逻辑、改 bug，效率提升也非常明显。很多人第一次认真用起来之后，都会冒出同一个感受：
AI 这东西，是真的能干活。
但有意思的是，很多人对 AI 的使用，一直停留在“边角料阶段”。
写个函数，可以。 改个 bug，可以。 补个接口，可以。
可一旦说到：
“要不要把 AI 真正引入项目开发流程？”
很多程序员就开始犹豫了。
不是不相信 AI，而是不敢。
尤其是老项目，大家心里都会有同一种顾虑：
AI 写点具体实现没问题，但你让我把一个真实项目交给它，我真怕它乱来。
这种担心其实特别正常。
因为项目不是 Demo，老项目更不是白纸。 它往往意味着：
- 代码历史包袱重
- 业务规则复杂
- 隐性约束很多
- 很多逻辑“能跑但说不清为什么能跑”
- 改一处，可能牵出三处联动
很多人刚开始用 AI 编程时，都会掉进一个很典型的“甜蜜陷阱”。
第一下特别爽。 一句提示词扔过去，几秒钟就是一大段代码，速度快得像开了挂。
但问题也恰恰藏在这里。
当需求只存在于聊天记录里时，AI 往往会变得非常不可预测。
你说“帮我加个登录功能”，它可能默认给你上邮箱登录； 你心里想的是手机号，它却顺手把第三方登录也配上了； 你本来只想补前端交互，它却连数据库结构都想一起改。
它不是故意乱来，而是在替你补全那些你没说清楚的部分。
所以很多人觉得 AI 又强又危险，根子并不矛盾。强，是真的强；容易跑偏，也是真的。
问题其实不在于：AI 能不能写代码。
真正的问题是：
怎么让 AI 在项目里参与进来，但又不至于把项目带偏。
这也是我最近关注 OpenSpec 的原因。
一、发现一个开源项目：OpenSpec
最近在 GitHub 上翻 AI 编程相关项目时，我注意到了一个开源项目：
OpenSpec
项目地址：https://github.com/Fission-AI/OpenSpec
它现在已经有 30.7k stars，热度不低。GitHub 首页对它的定位很直接：
Spec-driven development (SDD) for AI coding assistants。
翻成人话就是：
给 AI 编程加一层规格驱动的护栏。
它不是单纯让 AI 帮你“写代码更快”，而是先解决另一个更本质的问题：
在真正开始写代码之前，先把“到底要做什么”对齐清楚。
这一点一下就戳中了我前面对老项目的担心。
因为很多 AI 编程翻车，不是模型不够强，而是需求和边界全漂在聊天里。 AI 只能一边猜你想干嘛，一边开始动手。
这就像让一个刚入职的新同事，没看文档、没搞清业务、没理解边界，就直接去改线上系统。
抽奖味儿太重了。
而 OpenSpec 的核心思路恰恰相反：
先对齐，再实现。
二、OpenSpec 为什么值得看？
我觉得 OpenSpec 最有价值的，不是它多新奇，而是它刚好击中了 AI 进入真实项目时最痛的几个点。
1. 它解决的是“AI 不可控”问题
GitHub README 里有一句话讲得很准：
AI coding assistants are powerful but unpredictable when requirements live only in chat history.
意思很简单。
AI 很强，但如果需求只存在聊天记录里，它就会很不稳定。
OpenSpec 做的事情，就是给 AI 开发补上一层轻量的 spec layer，让人和 AI 在代码动手之前，先对“要做什么”达成一致。
这和很多人现在“想到哪问到哪”的用法，本质上不是一个路子。
前者是在协作。 后者更像是在碰运气。
2. 它适合老项目，不只是适合从零开始
这点我挺喜欢。
OpenSpec 在项目首页明确写了一个理念：
built for brownfield not just greenfield
也就是说，它不是只适合新项目、Demo 项目、从 0 到 1 的快速搭建； 它同样考虑了已有项目、老系统、历史包袱一大堆的 brownfield 场景。
这对于大多数程序员来说，比“我能 10 分钟生成一个 Todo App”有意义得多。
因为现实工作里，我们面对的更多是：
- 一个已经跑了几年的后台
- 一个逻辑复杂的前端项目
- 一个迭代了很多版的支付流程
- 一个没人敢轻易动的订单系统
而不是一个空目录。
3. 它不是重流程，而是轻量护栏
很多人一听“规格驱动”“proposal”“design”“tasks”，第一反应会是：
这是不是又一套很重的流程？
但 OpenSpec 给我的感觉不是“瀑布式管理工具”，而更像是：
给 AI 协作加一副刚刚好的骨架。
它首页的理念写得也很明确：
- fluid not rigid
- iterative not waterfall
- easy not complex
也就是说，它追求的是流动、迭代、轻量，而不是把开发过程锁死成层层审批。
这点很关键。
因为大多数程序员排斥流程，不是排斥清晰，而是排斥低效。 而 OpenSpec 比较聪明的一点，是它试图用尽量轻的方式，换来尽量高的可控性。
4. 它把“人的经验”变成 AI 能遵守的规则
老项目里最值钱的，很多时候不是代码本身，而是团队知道哪些地方能改、哪些地方不能碰。
比如：
- 某个字段不能随便动
- 某个回调要兼容历史数据
- 某个页面虽然很旧，但每天都有用户在用
- 某段代码很丑，但背后绑着真实业务
这些经验如果只存在人脑子里，AI 就永远只能当临时工。
而 OpenSpec 的 proposal、spec、design、tasks，本质上就是在做一件事：
把这些原本口口相传的经验，整理成 AI 可以消费的上下文。
这样 AI 才不是每次都从零猜需求，而是开始真正按规则协作。
三、OpenSpec 是怎么工作的？
你可以把它理解成一套很清晰的四步工作流。
第一步：起草提案
不是上来就写代码，而是先把“这次到底要改什么”说清楚。
AI 会帮你把一个模糊想法，整理成 proposal，明确这次变更的目标、范围，以及会影响哪些内容。
第二步：审查对齐
提案不是生成完就结束，而是要继续看：
- 有没有漏需求
- 边界清不清楚
- 设计方向对不对
- 哪些地方还需要补充说明
这个阶段最值钱的，不是文档，而是澄清问题。
很多时候，提案阶段多问清一个问题，后面能少返工好几个小时。
第三步：按任务实现
等 proposal、spec、design、tasks 都比较清楚之后，再让 AI 去执行。
这时候它不是在“猜需求”，而是在“按已经对齐过的任务做实现”。
这个差别非常大。
前者是概率游戏。 后者才更像正式开发。
第四步：归档更新
功能完成后，不是聊天记录一关就算结束，而是把这次变更沉淀回项目里。
这样后续再迭代时，团队和 AI 都能站在同一份上下文上继续工作，而不是每次重新回忆“上次到底改了什么”。
这套流程表面上看比“直接开聊写代码”多了几步，但本质上是在把风险前移。
先把错的方向挡住，再追求快。
对于老项目来说，这种效率往往比首轮生成速度更值钱。
四、如果要用 OpenSpec，怎么改造现在的项目？
我觉得最重要的一点是：
不要一上来就想把整个项目交给 AI。
更现实的做法，是把它当成一套让 AI 渐进式进入项目主流程的方法。
1. 先从一个小功能开始试
第一个提案，不要上来就重构会员中心、支付链路、订单系统。
更适合的起点是：
- 增加一个字段
- 补一个筛选条件
- 修一个边界明确的小 bug
- 加一个空状态
- 调整一个页面交互
这样你可以先走通一遍 OpenSpec 的节奏，看它是怎么提问、怎么拆分、怎么落档的。
2. 先让 AI 理解项目，再让它修改项目
很多人一上来就说“帮我实现”。
但对老项目来说，更好的方式是先让 AI 做理解型工作：
- 帮我梳理这个模块结构
- 帮我总结这段业务逻辑
- 帮我列出这次改动会影响哪些文件
- 帮我拆成几个更可控的小任务
先理解，再动手，AI 的偏差会小很多。
3. 把“这次做什么，不做什么”写清楚
很多项目翻车，不是因为没能力，而是因为范围失控。
所以用 OpenSpec 时，一定要把边界说清楚：
- 这次是改前端还是联动后端
- 是新增流程还是修改旧流程
- 哪些旧逻辑不能碰
- 哪些状态必须兼容
- 哪些字段只是展示，不改数据结构
这些内容越清楚，AI 越不容易自由发挥。
4. 认真回答 AI 的澄清问题
这一点特别重要。
很多人嫌 AI 反问麻烦，想让它直接写。但在正式项目里，澄清问题不是阻碍效率，而是在提前省返工成本。
真正浪费时间的，从来不是“多回答两个问题”，而是“写错了以后整段推翻重来”。
5. 从“写小活”慢慢过渡到“参与主流程”
当你连续几次都能稳定跑通一个小变更之后，再逐步放大范围：
- 从改一个交互，到完成一个页面
- 从改一个页面，到交付一个模块
- 从实现任务，到参与需求拆解和设计对齐
你不是在赌 AI 会不会写，而是在训练一套更可控的协作方式。
五、总结
很多程序员不是不想把 AI 引入项目，而是担心它一旦真的进入主流程，就不是帮忙，而是添乱。
尤其是老项目，越复杂，越怕 AI 在错误方向上高速狂奔。
而 OpenSpec 让我觉得有意思的地方，就在于它没有试图把这个问题简单粗暴地解决成“换个更强模型就好了”。
它给出的思路更现实：
先把需求、边界、设计和任务说清楚，再让 AI 进入实现。
说白了，它不是让 AI 变得更聪明，而是让 AI 在真实项目里变得更可控。
对于那些只想快速生成 Demo 的人来说，这套方式可能显得慢了一点。
但对于真正要长期维护、持续迭代、多人协作的项目，尤其是 1→n 的老项目演进，这种“慢一点但不容易跑偏”的方式，反而更接近生产环境真正需要的效率。
所以如果你之前对 AI 的态度一直是：
“我知道它好用，但我不敢把它放进项目里。”
那 OpenSpec 这种思路，确实值得看看。
互动话题
你现在在项目里，敢让 AI 参与到哪一步？
是只让它写点小功能、改改 bug，还是已经开始让它参与需求拆解、页面开发，甚至模块级交付了？
欢迎在留言区聊聊：你最想让 AI 帮你做什么，又最担心它把哪里搞乱？
如果你对 AI 编程实战、老项目怎么接入 AI、各种高效 AI 使用技巧 感兴趣，欢迎关注我。 带你实战 AI 编程，也分享更多真正能落地的 AI 使用技巧。
