从想法到上线：AI 时代，最缺的是把想法讲清楚

前些天我给自己定了一条规矩：在把一个需求讲清楚之前，不许动手写代码，也不许让 AI 写代码。

这条规矩来自一个反复出现的场景。同样一件事，我讲清楚了，AI 一两个小时就能跑起来；我讲得含糊，折腾一整天还在原地打转，最后发现我们俩对「做成什么样」的理解根本不一样。

一开始我以为是自己用 AI 的水平问题，后来想明白了：这跟水平关系不大，是瓶颈换位置了。

这篇就把这件事从头到尾讲一遍——从一个模糊的念头，到最终上线，中间到底要经过哪些阶段，每一个阶段该谁干、怎么干、容易在哪儿翻车。

一、写代码这件事，正在从「能力」变成「资源」

先看几个数字，它们比我讲任何道理都有说服力。

再看一个更能说明问题的指标。在衡量「AI 能不能改对真实项目里的缺陷」的行业基准 SWE-bench Verified 上：

2024 年 6 月，表现最好的模型是 49%。
2026 年 4 月，已经到 87.6%。
22 个月，涨了大约 38 个百分点。

把这些放在一起，结论很清楚：「会不会写代码」这道墙，正在变矮，而且矮得很快。

更值得注意的是一个做低代码工具的公司公布的用户构成——它的用户里有六到七成是设计师、学生和销售人员，而不是程序员。这些人本来是不写代码的，现在他们在做产品。

所以这不是「程序员要被替代了」这种话题。真实情况是：写代码这件事，正在从一种稀缺能力，变成一种随手可得的资源。

二、瓶颈转移：从「写不出来」到「说不清楚」

资源一旦不稀缺，瓶颈就必然会转移到下一个环节。而这个环节，目前看得很清楚。

有一个说法我印象很深，大意是：AI 把「从零到原型」压到了几乎为零，但从「原型」到「可运营」之间，横着一道很宽的沟。很多人卡在这道沟上——演示的时候很好看，一上真环境就各种问题。

为什么会有这道沟？三个数据说得很直白：

• 技术债增加三到四成。有分析机构对比了 AI 大规模介入前后的代码库，发现技术债明显上升。
• 45% 的 AI 生成代码带有已知安全漏洞。这是在做受控测试时统计出来的，覆盖上百个模型和八十多个编码任务。
• 45% 的开发者反馈：调试 AI 写的代码更费时间。因为那段代码不是你写的，你得先读懂它，才能改它。

还有一个数据更值得琢磨。2025 年有一项随机对照试验，让经验丰富的开源开发者分别用 AI 工具和不用 AI 工具做同样的任务，结果用了 AI 的那组反而慢了 19%——但这些人自己觉得变快了。

「感觉变快」和「真的变快」是两件事。这个差值，正是流程要解决的问题。

说到这里，前面那个结论就可以往前推一步了：

真正稀缺的能力，已经从「会不会写」，变成了「会不会判断」。

而判断的前提，是你能不能把要做的事讲清楚。这就是为什么流程变得比技术更重要。

三、完整流程：从想法到上线，七个阶段

下面这套流程不是我发明的。2025 年，GitHub 把这类做法正式命名为「规范驱动开发」（Spec-Driven Development），到 2026 年已经成为主流。亚马逊、微软都有对应的工具，业界还发明了一套专门写验收条件的语法，最早用在航天发动机控制系统上。

但工具是次要的。真正重要的是节奏：每一步之间都要停下来，由人看一眼、改一遍，再往下走。

阶段一：想清楚——把模糊念头逼成清晰需求

这是整件事里最难、也最容易被跳过的一步。

大多数人脑子里的「想法」是这样一句话：「我想做个能管客户的小系统。」这句话对你自己有意义，对 AI 没有任何意义——它不知道客户是谁、有多少、要管什么、谁能用。

把它变清楚，我习惯用四个问题逼自己：

1. 给谁用？不是「给公司用」，而是「给谁、什么场景下、用什么设备」。
2. 解决什么问题？把「提高效率」换成「原来这件事要花多少时间，做完之后是多少」。
3. 什么样算成功？写成一个能验证的条件，而不是形容词。
4. 什么情况不算数？也就是边界：数据只有十条怎么办、网络断了怎么办、有人填错怎么办。

第四个问题是最容易被跳过的，恰恰也是最值钱的——它决定了你会不会在快做完的时候，才发现有个情况没考虑到。

写的时候有个小技巧：把模糊词换掉。「最好能导出」改成「必须能导出」；「不能太慢」改成「三秒内出结果」。凡是 AI 需要猜的地方，就是你将来要返工的地方。

阶段二：让 AI 先提问，别急着写代码

这是全套流程里投入产出比最高的一步，而且只需要十分钟。

做法很简单。当你写完那份一页纸的需求，不要接着说「开始写代码」，而是说：

「这是需求。请列出这份需求里所有的歧义、缺失细节和可能的边界情况。先不要写任何代码，只提问。」

它问出来的东西，往往是你想了半天也没想到的。比如：文件传得太大怎么办？两个人同时改同一条记录怎么办？删除要不要留痕？这些它都能替你想到。

然后你根据它的问题，回头把需求补一遍。这十分钟改需求，能省掉你后面好几天的返工。

很多人跳到这一步就直接说「帮我写」，结果就是前面说的那条沟：它能猜到八成左右，剩下两成怎么都收不了尾——因为那两成它根本不知道你要的是什么。

阶段三：定方案

需求清楚了，接下来定「怎么做」。

这一步要定的是三件事：用什么技术、数据存在哪里、跟哪些系统对接。

我的做法是让 AI 同时给两三个方案，并说清各自的代价。比如「用现成的开源组件」和「自己写一套」，它会把开发速度、后期维护难度、依赖风险分别列出来，我再拍板。

这一步的关键是别让它替你决定。它可以分析，但选择权在你——因为承担后果的是你。

如果这一步偷懒直接开始写，风险是：技术选型和你们单位现有的环境对不上，写到一半发现部署不上去，那就得推倒重来。

阶段四：拆任务

把方案拆成一个个小块，每一块都能独立完成、独立验证。

拆的原则是：每一块控制在几分钟到半小时能做完，并且带一句明确的验收标准。

举个例子，一个「用户注册」功能应该拆成：建数据表、写注册接口、接入短信服务、写校验规则、跑一遍完整流程。每一块做完，你都能看一眼对不对。

为什么不一次性让它全做完？因为一次性做完，出了问题你不知道是哪一块出的。一个小小的错误，会藏在几百行代码里，找起来比重新写还慢。

阶段五：AI 实现

到这一步，才真正让它写代码。一次只做一个任务，做完立刻跑一遍验收，通过了下一条，不通过就当场修。

这里有一条纪律必须守住：拒绝范围扩张。

AI 很爱「顺手」多做点事——「我顺便帮你把日志也加上了」「我一并把配置抽出来了」。听起来是好事，实际上这是工期翻三倍的真正原因：你以为只做了原计划的事，实际上多出来一堆你没检查过的改动。

做法很简单：回头看你的需求单。里面没写的，就是不做。真觉得有用，记到下一版里，别混进这一版。

阶段六：人来测——这一步不能省

AI 写完会自己跑一遍测试，但它测的是「能不能跑」，不是「对不对」。

举个真实感受：它写一个统计功能，跑通了、没报错、数字也出来了。但那个数字把一类不该算进去的记录也算进去了。程序不会报错，因为它确实「正确执行」了——只是按一个错的理解执行。

所以有三类东西必须人来看：

• 算出来的数对不对。金额、数量、占比这类，拿手算或者拿旧数据对一遍。
• 边界情况扛不扛得住。空的、特别大的、重复的、乱填的，挨个试一遍。
• 看起来是不是那么回事。名称对不对、顺序合不合理、给外人看的东西得体不得体。

这一步很枯燥，但它决定了你交付的是「能用的东西」还是「能演示的东西」。

阶段七：发布上线

测试过了，就可以发了。发布这件事本身不复杂，但有两件小事值得养成习惯：

• 打版本号，写一句变更说明。不用长篇大论，一两句话说明「这一版多做了什么、修了什么」。将来出问题，这是你唯一的回溯线索。
• 保留上一版，能一键退回去。新版上线出问题，先退回去恢复可用，再慢慢查原因——不要在用户正用着的时候现场改。

上线之后还要盯几天：有没有异常报错、用量正常不正常、有没有人反馈奇怪的现象。上线不是终点，是观察期的起点。

四、这套流程里，人和 AI 各干什么

把七个阶段串起来看，人和 AI 的分工其实非常清楚：

一句话概括：

AI 负责「把东西做出来」，人负责「决定做什么」和「判断对不对」。

这两件事最容易搞反——要么让 AI 替你做决定，要么自己抢着去写代码。搞反了，流程就白设计了。

如果只能记一条判断依据，就记这个：

凡是「错了可以重来」的，交给它自动跑；凡是「错了要出大事」的，人一定盯。

五、三个最容易踩的坑

坑一：跳过设计，直接让它写。

这是最普遍的。它会一路猜你的意思，猜到八成左右就走不动了。剩下那两成，你要花几倍的时间去收尾——因为你要先读懂它写的几百行代码，才知道问题出在哪。

坑二：它说做完了，你就当做好了。

「做完了」是它自己的说法，不是事实。前面那个数据摆在那里：45% 的开发者反馈，调试 AI 写的代码更费时间。所以每一个任务做完，验收这一关不能省。

坑三：范围悄悄扩大。

它「顺手」多做的那些事，累积起来就是你工期翻倍的原因。发现它做了需求单以外的东西，先回头看方案，不要默认「多做总比少做好」。

六、怎么练「想清楚」这个能力

流程可以照搬，但「想清楚」这件事得练。三个我一直在用的方法：

一、把想法说给一个不懂技术的人听

如果你需要用到「就是那个……你懂的」这种词，说明你自己也还没想清楚。找一个完全不懂这行的同事，用大白话讲一遍，讲到他能在纸上画出来，那基本就清楚了。

二、每次返工都记一笔：到底哪句话没说清

返工不丢人，但同一个原因返工两次就亏了。我习惯在返工之后问自己一句：是我哪句话没讲明白？记下来，下次动笔前先看一眼。

三、先写「不做什么」

需求单里最容易漏、但最值钱的部分，是「这一版不做什么」。写清楚不做的东西，AI 就不会乱发挥，你也不会在收尾阶段被一堆「顺便」绊住。

写在最后

回到开头那句话。

写代码这道墙确实在变矮，这是好事，它意味着一个人能做出以前一个团队才能做的量。但墙矮了之后，你会看到墙后面还有一道墙——那道墙上写的是「你得先知道你要什么」。

所以流程不是束缚，恰恰是给想法让路。把阶段切开、每步停下来看一眼，看起来变慢了，实际上是把返工的钱提前花掉了。

AI 不缺写代码的能力，缺的是你告诉它写什么。
你能把想法讲得多清楚，它就能把东西做得多准。