《把软件交给 AI 之前》-序

序

当普通人也可以做软件之后

《把软件交给 AI 之前》

过去，做一个软件通常意味着先跨过一道很高的门槛。你要学会一种编程语言，理解数据库和服务器，知道页面怎样与接口连接，还要花很长时间才能让一个想法出现在屏幕上。很多人并不是没有好想法，只是无法把想法变成一个可以运行的产品。

AI 编程工具改变了这件事。

今天，一个产品经理、设计师、运营人员、创业者，甚至从未系统学习过编程的人，都可以打开 Codex、Cursor、Trae 或类似工具，用自然语言描述一个需求，然后看到 AI 创建页面、编写接口、修改数据结构并运行程序。过去需要几天才能完成的原型，现在可能在一个下午里出现。

这是一种真实的能力扩展。它让更多人拥有了制作软件的机会，也让“我有一个想法”与“我做出了一个东西”之间的距离迅速缩短。

但距离缩短，并不代表风险消失了。

能运行，不等于做对了

第一次使用 AI 编程工具的人，往往会经历一个令人兴奋的时刻：输入一段描述，等待几分钟，一个看起来完整的页面出现了。按钮可以点击，表单可以填写，界面甚至比预想中更漂亮。

接下来，问题才开始显现。

你说“项目负责人可以邀请成员”，AI 可能把“项目负责人”理解成“创建项目的人”；你说“删除任务”，AI 可能真的把数据永久删除，而不是移入回收站；你说“登录成功后保持状态”，页面刷新后却又回到了登录页；你让 AI 修复一个按钮，它顺手重写了整个页面；你看到“测试全部通过”，却不知道测试究竟检查了什么，也不知道最关键的业务行为是否从未被测试。

这些问题并不一定来自 AI 不会写代码。很多时候，AI 完成了它所理解的任务，只是它理解的任务并不是你真正想要的任务。

AI 擅长补全。当信息缺失时，它不会总是停下来等待。它可能根据常见做法、已有代码或语言习惯，替你补上角色、流程、数据和失败行为。补全有时非常方便，有时却会把一个微小的歧义变成产品中的真实规则。

因此，Vibe Coding 最危险的误解，是把“我能用语言让 AI 写代码”理解成“我不再需要判断软件是否正确”。恰恰相反：代码生产变快以后，人的判断变得更加重要。

普通人不必成为程序员，但必须学会判断

这本书不是要把你训练成一名传统意义上的软件工程师。

你不需要先学完一门编程语言，也不需要背诵设计模式、网络协议或数据库理论。本书也不会把 Codex、Cursor、Trae 的每一个按钮逐项介绍，因为工具界面会变化，模型能力会变化，今天有效的入口明天可能出现在另一个位置。

本书关心的是更稳定、也更接近问题本质的能力：

这些能力并不要求你看懂每一行代码。它们要求你看懂“事情是否按预期发生”。

例如，你可能不知道登录状态在代码里怎样保存，但你知道正确密码应该登录成功，错误密码必须被拒绝，退出后不能继续访问受保护页面，刷新页面后状态应该符合产品规则。你可能不知道数据库事务怎样实现，但你知道转移项目所有权时，不能出现新旧两位负责人都失去权限的中间状态。你可能看不懂一份复杂的修改差异，却仍然可以要求 AI 说明改了哪些文件、为什么要改、运行了哪些检查、哪些项目还没有验证。

普通人的优势不是比 AI 更会写代码，而是更清楚软件要为谁解决什么问题，什么结果可以接受，什么错误不能发生。

好的提问，不是更长的提示词

谈到 AI，人们很容易把注意力集中在 Prompt 上，仿佛只要找到一段足够长、足够专业的“万能提示词”，AI 就会稳定地产生正确的软件。

本书不会提供这种承诺。

真正有效的提问，通常并不华丽。它只是把当前目标、已知事实、观察到的现象、允许的操作、禁止的操作和期望输出说清楚。面对故障时，再补充已有证据、需要验证的假设和停止条件。面对实现任务时，再说明修改范围、分步计划、每步验证以及失败后怎样处理。

这些字段不是为了把普通人的话变成官样文章，而是为了减少一种常见损失：AI 在信息空白处替你做决定，而你直到产品出错以后才发现。

好的提问也不意味着把所有事情一次说完。很多复杂需求只有在 AI 阅读项目、复述理解并指出冲突以后，才知道下一步应该问什么。提问不是一次性的命令，而是一段逐步缩小不确定性的对话。

所以，本书不会只给你“复制后直接运行”的提示词。每份提示词都会同时说明：什么时候使用、使用前准备什么、AI 应该回答什么、你必须核对什么，以及出现什么情况应该停止。你不仅要得到一句话，还要知道怎样判断这句话有没有发挥作用。

验收，是普通人不能交给 AI 的最后一步

AI 可以编写测试，也可以运行测试；可以整理日志，也可以解释错误；可以列出修改文件，也可以生成一份看起来完整的完成报告。但 AI 不能替你决定产品事实。

“访客是否可以看到内部评论”“删除后是否允许恢复”“负责人离开团队后项目归谁”“导出的文件包含哪些字段”，这些都不是代码自动产生的答案。它们是产品选择。只有理解实际使用场景的人，才能确认这些选择是否正确。

因此，本书把验收放在与提问同样重要的位置。

页面出现了，不等于功能完成；没有报错，不等于结果正确；测试通过，不等于测试覆盖了你在意的行为；AI 说“已修复”，不等于问题已经被复现并证明消失；本地可以运行，也不等于发布后的真实环境可用。

你需要学习从五个方向观察产品：页面是否正确，业务规则是否成立，权限是否被正确限制，数据是否真正保存，失败时系统是否给出安全且可理解的结果。对于重要变化，还要重新检查以前已经能用的关键功能，并明确记录哪些事情仍然“未验证”。

“未验证”不是失败，也不是丢脸。它是一种诚实的状态。它比没有证据却写下“全部完成”更可靠。

我们会一起做出一个越来越复杂的产品

全书会沿着一个名为 TeamFlow 的小型团队协作产品前进。

一开始，它只是一个模糊的“任务管理系统”。随后，它会拥有用户、Workspace、Project、Task、成员、角色、评论、活动记录、搜索、通知、访客成员、所有权转移、数据导出和部署环境。每加入一个功能，产品都不只是多一个页面，也会多一些需要说清楚的规则、多一些可能被破坏的旧行为，以及更多需要验证的失败情况。

你会看到同一个需求怎样从一句含糊的话，逐渐变成 AI 可以执行、你也可以验收的任务；看到 AI 怎样误解“负责人”，怎样在修复一个问题时引出另一个问题，怎样声称完成却遗漏权限或数据；也会看到普通用户怎样用事实、截图、日志、测试账号和实际操作，把讨论从猜测带回证据。

书中还会出现 QuickCRM——一个已经被 AI 修改过数百次的旧项目。它展示另一种常见结局：规则散落、文档过期、补丁叠加，谁也说不清当前状态。通过它，你会学习何时停止继续修补，怎样判断一个项目是否还值得抢救，以及什么时候重建比继续修改更负责任。

这些案例不是为了展示完美流程，而是为了展示真实的不完美：信息缺失、第一次提问不完整、AI 理解错误、测试失败、环境不同、修复无效，以及用户不知道下一步该看哪里。每一章最终都要回答三个朴素的问题：你现在做什么？你应该看到什么？如果没有看到，接下来怎么办？

四个动作，贯穿全书

当工具、模型和项目不断变化时，你可以抓住四个动作：

说清楚 → 看影响 → 小步做 → 用证据验收

说清楚，不是把提示词写得很长，而是区分目标、事实、假设和不能接受的结果。

看影响，是在修改前问一句：这件事除了页面，还会不会影响数据、业务规则、权限、接口、测试和部署？

小步做，是不让 AI 一次改变太多。每一步都应有明确范围和验证方法，失败时先保存现场，不继续把更多修改叠上去。

用证据验收，是把“看起来没问题”换成可复查的事实：执行了什么操作，得到什么结果，哪些测试通过，哪些路径由真人操作，哪些环境尚未检查。

如果出现问题，则进入另一条同样重要的路径：

保存现场 → 提供证据 → 一次验证一个原因 → 修复 → 重新验收

这两条路径不是大型公司的繁重制度，而是普通人在 AI 快速行动时保护自己判断力的简单方法。

在把软件交给 AI 之前

这本书的书名强调“之前”，并不是要你害怕 AI，也不是劝你放慢所有事情。

它提醒你，在 AI 开始写代码以前，有一些决定仍然属于你：为什么要做这个功能，谁会使用它，什么结果算成功，什么东西不能被破坏，哪些操作需要先确认，出现什么信号必须停止。

AI 越强，这些问题越不会自动消失。相反，AI 执行得越快，一个模糊决定被放大的速度也越快。

你不必因为不懂编程而放弃制作软件，也不必因为 AI 能写代码而放弃思考。你可以把搜索文件、生成方案、修改代码、运行检查和整理证据交给 AI，把产品目标、风险选择和最终验收保留在自己手中。

当你翻开下一章，我们会从最常见的一句话开始：“帮我做一个任务管理系统。”然后一起看看，为什么 AI 可以成功生成一个页面，却仍然不知道你真正想要什么。

在那之前，请先记住这句话：

AI 可以替你写代码，但在把软件交给 AI 之前，你必须知道自己要什么、什么不能被破坏，以及怎样证明它真的完成了。