AI软件开发,真正难的是什么?

AI 越来越会写代码以后，软件开发真正难的是什么？ ——从"让 AI 写代码"到"让 AI 在规则中持续开发"

最近一段时间接触 AI 编程越来越多，我对这件事的理解也发生了一些变化。

刚开始用 AI 写程序的时候，最容易让人产生兴奋感的其实是"生成速度"。以前不会写的页面，现在描述几句话就能生成；以前需要查文档、找接口、调半天代码的功能，现在把需求交给 AI，它可能十几分钟就能给出一个能跑起来的版本。

对于没有系统编程背景的人来说，这种体验很容易让人觉得：软件开发的门槛，似乎正在迅速消失。

但项目真正做得稍微复杂一点之后，另一面也会很快出现。

页面确实生成得越来越快，功能也越来越容易加，可项目却不一定越来越好控制。前面已经说好的规则，后面可能被忘掉；为了增加一个新功能，AI 顺手改变了原来的数据结构；同一个概念在不同模块里被起了不同的名字；一个功能单独看没有问题，和其他功能放在一起以后却开始互相冲突。

最麻烦的还不是某一段代码写错了，而是做到后面会逐渐说不清楚：现在这个项目，到底应该以什么为准？

这也是我现在越来越明显的一个感受：

🔑

当 AI 把"写代码"这件事变得越来越容易以后，软件开发真正困难的部分，并没有消失，而是在向前移动。

过去很多精力花在"怎么实现"，以后可能越来越多地花在"到底应该实现什么""哪些东西不能随便改""整个系统怎么保持一致""做到什么程度才算真的完成"。

换句话说，AI 软件开发真正需要解决的，并不是怎么让 AI 一次写出更多代码，而是怎么控制一个不断变复杂的项目。

一、AI 的问题往往不是不会写，而是不知道哪些决定已经不能再变

如果只是做一个很小的工具，直接和 AI 对话其实没有什么问题。"帮我加个登录""再增加一个历史记录""这个页面重新设计一下"，需求一个接一个地往下说，AI 一个接一个地做，很多时候确实可以很快得到一个能用的结果。

问题出现在项目开始变长以后。

聊天记录天然是线性的。需求、技术讨论、临时修改、报错信息、产品决策往往全部混在一起。前面几十轮对话里可能已经确认过某个原则，但到了后面处理另一个功能时，这个原则未必还在当前上下文里。

AI 此时并不是故意违反要求，而是它只能根据当前能够看到的信息，重新理解项目。

于是就会出现一种很典型的情况：每一次局部修改看起来都合理，但项目整体却在慢慢漂移。

比如一开始明确说用户的私人数据只保存在本地，后面开发某个功能时，AI 为了实现方便，可能又设计出云端同步；前面规定一个日期只能有一条正式记录，后面另一个模块又按照可以存在多条记录来写；最开始叫 diary_date 的字段，之后某次开发又被重新命名成了 date。

这些问题表面上是代码问题，实际上更接近"项目记忆"出了问题。

所以我觉得 AI 软件开发里非常重要的一个变化，就是不能再把项目主要存在聊天记录里，而要逐渐建立一套稳定、可反复读取、可以作为统一依据的项目文档。

这也是 SDD（Spec-Driven Development，规范驱动开发）真正值得关注的地方。它解决的不是"怎么写提示词更漂亮"，而是一个更基础的问题：

怎样让需求、技术方案、任务执行和最后验收，始终围绕同一套已经确认过的规则运行。

二、真正成熟的做法，是先把"项目的事实"从聊天里拿出来

如果把一套 AI 软件开发流程仔细拆开，会发现项目里其实存在几种完全不同性质的信息。有些是整个项目长期都不能轻易突破的原则；有些是这一版产品具体要实现什么；有些属于技术方案；有些属于数据结构；还有一些只是当前开发阶段需要执行的任务。

如果这些内容全部混在聊天里，AI 每一次都要重新判断哪些信息更重要。项目越复杂，出错的概率越高。所以更清晰的方式，是让不同文档承担不同职责。

最上层是项目的长期原则。比如隐私边界、技术约束、质量要求，这些东西不应该因为今天增加了一个页面、明天换了一个功能就跟着变化。它们更像是项目的"宪法"，负责告诉后面的所有开发：哪些事情即使技术上能做，也不能这样做。

再往下一层，才是具体的产品规格，也就是当前版本到底要给用户什么能力。用户能做什么、什么情况下可以做、做到什么结果才算完成，这些都应该在这里说清楚。

等"要做什么"确定以后，才进入"准备怎么做"：采用什么技术路线，页面之间怎么组织，数据怎么流动，哪些模块需要协作，哪些风险应该提前处理。

再继续往下，是数据模型、原型和任务清单。它们分别负责回答"数据怎么保存""界面怎么组织""下一步具体做什么"。

这样一来，项目就从一堆聊天记录，慢慢变成了一套有层级的开发依据：

项目原则 → 产品规格 → 技术方案 → 数据模型与原型 → 任务清单 → 代码实现

这套结构真正有价值的地方，不是文档数量变多了，而是以后再出现冲突时，终于知道应该回到哪里判断。

AI 不再凭当前对话"猜你想怎么做"，而是可以回到已经确认的文档里找答案。

🔑

三、需求阶段最重要的事情，不是把功能写全，而是把模糊的地方暴露出来

这一套流程里，我觉得最容易被低估的其实不是代码，也不是技术方案，而是需求澄清。

很多时候，我们自己以为一个需求已经说得很清楚了，其实只是脑子里"有个大概"。

比如"支持搜索"，看起来非常明确，但真正进入开发之后马上会遇到一堆问题：搜标题还是正文？能不能按时间筛选？能不能按标签筛选？没有结果怎么显示？删除原始数据以后，搜索结果需不需要同步更新？

再比如"支持历史记录"，也可能继续引出：历史记录能不能修改？修改以后原来的 AI 分析还算不算有效？一个日期能不能补录？补录以后周统计怎么处理？

这些都不是代码问题，而是产品规则没有说清楚。

如果这些问题不提前解决，AI 并不会停在那里等你。它通常会根据当前信息做一个"看起来合理"的决定，然后继续往下实现。

而很多返工，就是这样产生的。

所以在正式进入技术方案之前，非常有价值的一步，是让 AI 先站到开发者的角度，专门去找当前规格里的模糊、矛盾和遗漏。

这个阶段不是让 AI 替我们做决定，而是让它负责"挑刺"。它可以指出前后规则的冲突、没有说明的边界和可能影响验收的问题，然后真正做决定的人仍然是我们。

我觉得这其实体现了 AI 编程里一个非常关键的分工：

AI 擅长穷举问题，人负责确定边界。

需求澄清并不一定要追求"所有问题全部解决"，更现实的标准是：核心行为已经明确、第一版范围已经明确、影响验收的规则已经确定、主要冲突已经解决。

达到这个程度，项目才真正适合往下走。

四、为什么不能跳过技术计划、数据模型和原型

需求明确以后，很多人会很自然地说：那现在可以让 AI 开始写了。

但如果项目稍微复杂，我觉得中间这几层仍然很重要。

首先是技术计划。需求回答的是"用户需要什么"，技术计划回答的才是"系统准备怎么实现"。比如页面如何组织、路由怎么设计、数据怎么存、模块之间怎么通信、外部服务失败时怎么办，这些都属于技术层面的决策。

这一层如果完全跳过，AI 就会在开发过程中边写边决定。今天写 A 模块时选择一种方案，明天开发 B 模块时又可能采用另一种方案。局部实现可能都能运行，但整个项目缺少统一设计。

数据模型尤其如此。页面是最容易看到的，所以 AI 编程很容易让人把注意力都放在 UI 上。但一个软件后面能不能继续扩展，很多时候恰恰取决于数据结构是否稳定。

有哪些数据需要长期保存？每张表有什么字段？字段叫什么？哪些数据是一对多关系？删除主数据以后关联数据怎么办？如果以后软件升级增加字段，原有数据怎么迁移？

这些事情越晚想，代价通常越高。比如今天某个字段叫一个名字，下一次开发又换了另一个名字，短期可能只是修改几行代码，时间一长就会在不同模块之间留下大量不一致。

所以数据模型其实是在给整个项目建立一套共同语言。

原型则解决另一个问题：功能虽然都想清楚了，但用户到底怎么用？首页放什么，一级入口有哪些，哪些东西应该藏到二级页面，用户完成一个操作以后下一步去哪里？

这些问题如果等代码全部写完以后再调整，成本已经很高了。

而 AI 让原型生成和修改变得更快以后，反而更应该把这一阶段利用起来：先用低成本的方法暴露产品问题，再进入高成本的正式实现。

🔑

五、真正开始开发以后，最重要的不是"一口气做完"，而是把任务切得足够小

到了任务拆解这一步，前面的需求、方案、数据和界面才真正变成可以执行的开发工作。

这一步看起来很普通，但对 AI 特别重要。

AI 和人一样，面对"把整个系统做完"这种任务时，很容易同时处理太多信息。一旦任务中同时包含导航、数据库、页面、接口、异常处理和 UI，它在实现过程中就不可避免地会做很多隐含决定。

任务越大，隐藏决策越多，最后偏离原始设计的概率也越高。

所以更稳定的方式，是把项目拆成一件一件能够独立完成、独立检查的小任务。先搭基础骨架，让页面和导航跑起来；再建立数据库和迁移机制；然后完成新增、读取、修改、删除等基础数据能力；数据稳定以后再开发具体页面；核心流程跑通以后再接入 AI；最后才处理视觉细节和交互体验。

这里面其实有一个很重要的顺序：

先基础设施，再数据；先核心业务，再 AI；先正确，再好看。

现在很多 AI 产品开发容易倒过来。一上来先接模型，先做一个很炫的 AI 页面，结果后面发现数据没有设计好、页面逻辑没想清楚、错误状态也没处理，最后只能不断返工。

大模型能力当然重要，但一个真正的软件产品，并不是"调用一次模型接口"就完成了。模型只是其中一个模块，软件本身仍然需要一套稳定的结构来承载它。

六、当 AI 真正进入软件以后，Prompt 也不再只是"聊天技巧"

这一部分我觉得也是 AI 软件开发和普通软件很不一样的地方。

我们平时和 ChatGPT 对话时，Prompt 的目标通常是"让回答更符合我的意思"。只要人能够看懂，表达稍微有变化并没有太大关系。

但当大模型成为软件中的一个功能模块时，要求就完全不同了。软件需要稳定。

比如模型要返回"情绪、分析和鼓励"，如果今天返回三个自然段，明天返回一个表格，后天又多加一句解释，人看可能都觉得没问题，但程序很难稳定处理。

所以软件里的 Prompt 需要逐渐结构化。模型扮演什么角色，输入是什么，可以输出哪些字段，每个字段是什么类型，长度有什么要求，哪些话不能说，最终按照什么 JSON 结构返回，这些都需要明确。

到了这一步，Prompt 已经不只是"怎么问 AI"。它实际上开始承担一部分接口契约的作用。

也正因为如此，不同 AI 场景往往需要不同的 Prompt。分析一篇内容和汇总多篇内容，任务目标不同、输入不同、输出结构也不同，很难靠一份万能 Prompt 解决。

这也是为什么 AI 软件开发做到后面，会越来越像传统软件工程，而不是越来越像简单聊天。

只是过去接口的一端是传统服务，现在其中一端变成了一个概率模型。

🔑

七、AI 能力越强，数据边界反而越要提前想清楚

当软件开始调用大模型以后，还有一个问题会变得非常现实：数据到底去了哪里？

这部分在普通 Demo 阶段很容易被忽略。

为了方便调试，把 API Key 直接写进客户端；为了排查问题，把完整用户输入写进日志；为了分析功能使用情况，把一些原本不应该离开设备的内容上传出去。

短期看，这些做法可能让开发更快，但一旦产品真的开始给别人使用，性质就完全变了。

所以 AI 软件设计最好一开始就明确几个问题：哪些数据默认不能离开设备？什么情况下允许发送？是不是只有用户主动触发以后才调用模型？哪些域名允许访问？日志和崩溃报告里能不能出现用户隐私内容？开发阶段使用的 API Key，正式发布以后应该怎样处理？

这些问题表面上属于安全，其实仍然回到了文章前面那个主题——

哪些东西必须先变成明确的项目规则，而不能每次由 AI 临时决定。

AI 可以非常快地帮我们接通一个接口，但能不能接、什么时候接、发送什么内容，本质上还是产品决策。

八、一个能运行的软件，和一个真正能使用的产品，中间还隔着"最后一公里"

AI 很擅长帮我们快速做到"能跑"。但能跑和好用之间，其实还有很长一段距离。

按钮按下以后有没有反馈，页面切换是否自然，加载的时候用户能不能知道系统在做什么，失败以后有没有明确提示，数据还没保存时用户离开页面怎么办，浅色模式和深色模式是不是都清楚，页面内容会不会被系统区域遮挡……

这些问题很少是产品的核心卖点，但它们叠加起来，就是用户对"这到底是一个 Demo 还是一个真正软件"的判断。

所以开发到了最后，不能只检查"功能有没有"。还需要专门去处理异常状态、操作反馈、安全区域、主题适配、页面过渡这些细节。

这一阶段的重点已经不再是增加功能，而是减少那些让用户觉得"不顺"的地方。

很多时候，软件的完成度并不是靠最后再加几个功能提高的，而是靠把已经存在的功能真正打磨完整。

🔑

九、我现在最认同的一点：不要让写代码的 AI 自己宣布"验收通过"

整个流程到了最后，还有一个很值得保留的做法：生成和验收分离。

如果一个 AI 刚刚完成了一项功能，然后马上让它自己检查"有没有问题"，它很容易继续沿用刚才开发过程中形成的判断。如果一开始需求就理解偏了，它后面的检查也可能沿着同一个方向继续证明自己是对的。

所以更有效的方式，是重新开一个独立上下文，让另一个 AI 不参与前面的实现过程，只看原始需求、验收标准和最终结果。

它的任务不是评价代码写得漂不漂亮，而是重新回答几个问题：这个实现有没有偏离原始需求？有没有漏掉应该存在的功能？异常情况和边界条件有没有处理？有没有为了实现方便偷偷改变原来的产品规则？

然后再把这些问题反馈给原来的开发上下文。

但这里还有一个细节我很认同：验收者也不是绝对正确的。第二个 AI 找到的问题，同样应该逐条核对。成立的就修，不成立的就说明为什么不成立。最终判断标准不是"谁是第二个 AI"，而仍然是需求、验收标准和实际运行结果。

所以完整的闭环其实是：

生成 → 独立验收 → 反馈 → 核对 → 修改 → 再验收

这一步看起来只是换了一个对话，本质上是在给 AI 软件开发增加一个"第二视角"。

而随着 AI 以后承担越来越多的代码实现，这种独立审查的重要性只会越来越高。

十、AI 软件开发真正变化的，其实是人的位置

把这一整套过程串起来以后，我反而觉得，AI 编程并没有让人从软件开发里消失。它只是改变了人的工作位置。

过去一个没有编程能力的人，最大的障碍可能是"我不知道这段代码怎么写"。以后这个障碍会越来越小。

但新的问题变成了：你是否真的知道自己想做什么？能不能把模糊想法变成清晰规则？遇到多个可行方案时知道怎么取舍吗？你能不能判断 AI 给出的技术方案有没有违反最初的产品原则？功能做出来以后，你有没有能力判断它究竟算不算完成？

这些问题，AI 可以参与，可以辅助，但很难完全替人回答。

所以如果重新看 AI 软件开发的全过程，我觉得真正重要的并不是某一套框架，也不是记住多少命令，而是建立这样一条稳定的逻辑：

先确定项目原则，再定义需求；先把模糊问题澄清，再做技术方案；再把数据、界面和任务设计清楚；然后让 AI 按小任务逐步实现；核心业务稳定以后再接入大模型；功能完成以后处理体验；最后再通过独立视角反复验收。

从这个角度看，所谓 AI 编程真正成熟的标志，可能并不是"我已经可以一句话生成一个软件"。

恰恰相反，是我们开始意识到：

越是能够快速生成，就越需要知道什么不能随便生成；越是能够快速修改，就越需要一套稳定的依据，来判断什么该改、什么不该改。

🔑

代码正在变得越来越便宜，但需求、判断、取舍和验收并没有因此贬值，甚至可能变得更重要。

以前我们最担心的是"我不会写"。

以后真正需要担心的，也许是：AI 什么都会写，但我们自己还没有想清楚，到底应该让它写成什么样。

好的软件，从来不是从代码开始的，而是从清晰的思考开始的。