08｜让 AI 一次做一小段，做完马上试

本章任务：这次先做一小段能从头试到尾的功能，试对了，再接着做。
准备材料：甲方确认过的要求、页面样图、开发方案，以及哪些地方能改、哪些不能动的约定。
本章产出：一张分步任务表、一份能运行的代码、实际试过的记录，还有下次接着做需要知道的事。

页面都有了，为什么还是没法用？

图解：页面上说成功，不代表真的存进去了。 查看大图

你让 AI 一口气把报名系统做完。它做出了活动列表、报名表、审核页，看起来每个地方都齐了。

你点报名，页面提示成功；刷新一下，记录没了。你在后台点通过，报名端却还显示待审核。

页面齐了，只能说明画面做出来了，不能说明这些画面背后的事情真的接上了。

为什么不能等全做完再试？因为前面猜错一条规则，后面可能全跟着错。比如 AI 按“提交就占名额”写了保存、审核、取消和剩余人数，你最后才发现应该“审核通过才占”，这几个地方都得重做。

所以这一章换个做法：这次只做“点提交，到刷新后还能查到记录”这一小段。 先看它是不是真的保存了，再做下一段。

第一步：先选一小段能从头试到尾的功能

先拿一个已经发布的测试活动。你能打开详情、填必要信息、点提交，再打开自己的报名记录，看到刚才那条申请。

这一轮先不做审核和取消。但要明说：它们还没做，不能把这个版本介绍成“报名系统已经完成”。

这次做什么	做完马上怎么试	暂时不做什么
第一次：提交并查到记录	提交后刷新，记录还在，而且属于当前账号	审核、取消
第二次：后台审核	有权审核的账号能通过，报名端能看到变化，名额正确	通知
第三次：取消报名	允许取消时能取消，只有原来占了名额的记录才释放名额	候补
最后：多试几种情况	试截止、快速连点、两个账号同时操作，再试以前好用的地方	没答应本期做的新功能

别把保护数据的判断拖到最后。第一次做提交，就要检查是否登录、是否已截止、是否已经报过名；第二次做审核，就要检查当前账号能不能审这个活动。

否则，你可能先做出了一个“谁都能改”的功能，等后面补限制时，又要拆开重写。

第二步：先写清楚，这一小段做到什么样算合格

这就是“验收条件”：一句话说清楚做到什么样算合格。比如“提交后刷新，仍能看到自己的那条报名”，就是一条。

不要只给 AI 写“完成报名功能”。你和它可能说的不是同一件事：你想要真保存，它可能只让页面弹出“成功”。

这次可以先写下几条：

• 用测试账号提交一次，得到一条“待审核”的报名，刷新后还在。
• 按本指南的示例规则，提交申请不占名额，审核通过才占。
• 截止前，即使通过人数已满，也仍能提交申请；只是不能继续审核通过。
• 必填内容没填，页面说明缺什么，也不能偷偷存一条空记录。
• 同一账号已有有效报名时，再点一次，不能多出第二条。

这些只是本例已经说好的规则。你的项目如果还没问清楚，就先问甲方，不能拿这里的答案替甲方决定。

第三步：让 AI 先说清这次准备改哪里，再动手

把现在的代码、做好的部分和这次目标交代清楚。已有的东西先看一遍，别让 AI 每次都从零再造一个项目。

仅作为示例，不建议作为实际项目中的提示词使用。

这次只做报名提交：从填写并提交，到刷新后还能查到自己的记录。先看当前资料和代码，说清准备改哪些地方、做完怎样试。暂时不加审核、取消或通知。若要修改数据保存格式、让多个功能共用的地方，或者安装新的东西，先解释原因和影响，再按已经约好的权限处理。做完请列出真正试过的结果、没试的地方和还不能用的功能。

AI 如果说“得改数据库”，别急着点同意。数据库就是保存报名等记录的地方，比如你昨天报过名，今天打开还能查到，通常靠它记着。

先问清楚：改哪张表、已有记录怎么办、有没有不用推倒重来的办法。它说“必须改”，也要给理由，不能因为赶着做完就省掉这一步。

第四步：亲自从提交到查询走一遍，别只看成功提示

图解：身份、截止、重复这些检查，要和功能一起做。 查看大图

现在打开项目，真的填一次、点一次、刷新一次。不要只读 AI 最后那句“功能已完成”。

点提交以后，页面通常会发出“请求”，也就是向处理程序传话。比如把“哪个活动、当前账号、填写内容”送过去，请它保存。

接收请求、检查规则、保存数据的程序，通常叫“后端”。你看到的页面则常叫“前端”。比如页面上点提交，后端判断是否截止，再决定能不能保存。

你可以让 AI 带着你看下面四处，不需要一开始全会：

看哪里	这次具体看什么	别误以为
页面	点完有没有反馈，刷新后记录在不在	弹出成功，就一定保存了
请求	是否真的发出去，对方实际回答了什么	页面没报错，对方就答应了
程序记录	检查和保存到底走到了哪一步	程序没出错，就符合甲方规则
保存的数据	账号、活动、状态和数量是否正确	成功一次，所有情况都没问题

练习要在专门拿来试的环境里，用编造的账号和记录。别为了验证，把真实报名清空再来一次。

发现问题就记下“点了什么、看到了什么”，按第 10 章查原因。不要连发几遍“彻底重写”，把原本能用的地方也改乱。

第五步：把现在能用的样子存好，再做下一段

图解：没做完的地方写清楚，别藏在“以后优化”里。 查看大图

这一小段试对之后，用前面学过的版本保存办法，把当前代码留住。顺手写清楚：这次做了什么、试过哪些操作、还有什么没好。

只试对一半，就写“一半”。比如“正常提交能用，快速连点还会重复保存”，这不是已完成，也不能改名叫“后续优化”。

下次继续前，留下几句交接说明：怎么启动、现在能用哪些功能、有什么问题、下一次准备做什么。密钥这类能打开服务或账号的秘密值不能写进去，比如真实数据库密码。

否则换一个会话，AI 可能把你没做的功能当成已经做好，又在错误的起点上继续写。

改动越来越多时，先停下来检查

本来只修报名按钮，AI 却又要升级工具、重排文件夹、重写登录。先停一下，问：这些改动分别在解决什么问题？不改行不行？原来好用的地方要重试多少？

不是说一次只能改一个文件。有时一个小功能确实需要改好几处。关键是你能说出每处为什么改，改完知道该试哪里，出问题也有能退回去的版本。

常见误区

先把所有页面画完再管保存。 如果只是演示页面，可以这么做，但要标明是假数据。真正开发时，尽早把一次提交和保存跑通，否则可能最后才发现前后两边说的话根本接不上。

改一点就重写整套方案。 先找被影响的那几条改。整份反复生成，容易留出几份互相矛盾的版本，下次又不知道听哪份。

AI 写了测试命令，就算测过。 命令只是做法。要看它有没有真的执行、执行结果是什么；没做的就写没做。

练习：把取消报名拆成这次能做完的一小段

先写明哪些报名允许取消、取消之后是否释放名额。再写：这次从哪里开始，到哪里算做完；有哪些暂时不做。

然后想两个会失败的例子：比如已经截止还点取消，或者连续点两次。每个例子都写清你希望发生什么。

如果报名端说已取消，后台却没变，你准备先看什么？怎样确认名额没有多减一次，也没有多加一次？

完成检查

• [ ] 这次做什么、不做什么，已经写清楚。
• [ ] 能从点提交讲到数据保存，再讲到查出结果。
• [ ] 自己试过正常操作，也试过几种不该成功的操作。
• [ ] 已经试的和还没试的分开记录。
• [ ] 当前能用的代码存好了，下次怎么继续也写下来了。

本章带走： 一小段真的能用、你自己试过的功能，以及能退回去的代码。下一章继续讲：还要怎样检查，才能发现只点一次看不到的问题。