先想清楚，再让 AI 写：谈谈 CodeArts 的"规格驱动开发"

一、AI 写代码，最容易掉的坑不是"写不出"

用 AI 编程助手久了，你会发现最麻烦的从来不是"它写不出代码"，而是"它写出来的不是我想要的"。

你随手丢一句"帮我做个用户中心"，它几秒钟就还你一个功能齐全、结构完整的模块——但和你脑子里的那个版本，往往差了十万八千里。于是你开始一句句纠正，反复拉扯，最后得出的结论是"这东西不太行"。

问题真的在模型吗？多数时候不在。真正的原因是：需求根本没想清楚，就急着让 AI 动手了。

二、把"想清楚"这件事，前置并固化下来

CodeArts 里让我印象很深的一个理念，叫规格驱动开发（Spec-Driven Development）。

它的思路其实很朴素：别一上来就写代码，先老老实实把需求、设计、任务一层层写清楚，让每一份文档都成为下一环节的输入。CodeArts 中配套的几个协作角色，大致对应这条链路：

• 先把口述需求整理成结构化的需求规格；
• 再基于需求产出技术设计（模块划分、接口、数据流）；
• 然后把设计拆成可独立实现、可验证的任务清单；
• 最后才进入编码。

听起来像是又给开发加了一层"流程负担"，但和 AI 协作时，这套前置动作的价值反而被放大了。

三、为什么它和 AI 特别搭

第一，它给了 AI 一个稳定的"锚"。
多轮对话里最怕的就是意图漂移——聊着聊着，AI 已经偏离了你最初的目标。而一份明确写下来的规格，是双方共享的上下文，随时可以拉回来对照。

第二，它把"想清楚"的责任交还给人。
AI 很擅长一件小事：把模糊的话逼问清楚。你说"优化一下性能"，它会追着你把它变成"首屏加载 < 1s，查询接口 P95 < 200ms"这种可验收的条目。这个"逼问"的过程，往往比写代码本身更有价值。

第三，它让改动可追溯。
每个任务都挂在某条需求上。哪天需求变了，你能顺着链路定位到哪些设计、哪些任务会受影响，而不是凭记忆去猜。

四、我的实际流程

我现在的习惯大致是三步：

1. 整理需求：把脑子里的想法口述出来，让 AI 归成结构化条目（做什么、边界在哪、验收标准是什么），我逐条确认；
2. 敲定设计：基于需求生成技术方案，我重点看模块边界和接口设计是否合理；
3. 拆解任务：把设计切成一个个小任务，每个任务都能单独完成、单独验证。

走完这三步再开始编码，最直观的变化是：AI 写出来的东西，明显更贴近我想要的，返工的次数少了很多。

五、几个我踩过的坑

• 规格别写太细，也别太粗。 细到每行代码都规定，等于让 AI 抄写；粗到只有一句话，又回到了拍脑袋。分寸在于"把不确定的地方问清楚"，而不是"把所有细节都写死"。
• 规格是活文档。 需求变了就要同步更新，否则文档和代码会悄悄分叉，最后谁都不信那份文档。
• 别让 AI 替你拍板。 它擅长整理、补全、查漏，但"这个功能到底要不要做、做成什么样"是产品判断，得人来定。
• 小项目别硬套流程。 一句话能说清的需求，不必非要走完三份文档。工具是为效率服务的，别反过来被流程绑住。

六、结语

规格驱动开发并不是什么新鲜发明，它只是把"想清楚再动手"这条老规矩，变成了 AI 时代可执行、可协作的工作方式。

当写代码这件事被 AI 变得越来越快时，"定义问题"反而成了整个链路里最稀缺、最值钱的一环。先想清楚，再让 AI 写——这大概是我和它协作以来，最受用的一条心得。