我的结论很明确：用 AI 生成应用时，我把需求写成“角色、对象、状态、规则、验收”五部分，返工会少很多；只写一句功能愿望，页面出得快，后面的逻辑债也来得快。

我这次以产品经理身份做了一个读书会图书漂流小程序。它要让书友登记闲置书、预约取书、确认借出、归还后重新流转。我用的是一类“中文需求直出多端应用”的零代码 AI 工具：我输入自然语言，它就能生成可用的微信小程序、APP、H5 或鸿蒙应用，生成后还能继续用中文改页面和逻辑。为了看清需求粒度对结果的影响，我保留了三版提示词。

第一版：只讲愿望，十分钟能看，不能验收

我写的是：

做一个读书会图书漂流小程序，大家可以发布书、借书、还书，查看自己的借阅记录，界面简洁温暖。

这一版很快生成了首页、发布、我的借阅和个人中心。演示点击都通，但我一测就发现三个洞：同一本书可以被两个人同时预约；“已借出”和“待归还”含义重叠；发布者删除图书后，借阅记录也找不到对应书名。

我复盘后发现，“可以借书”只有动作，没有说明谁能借、借哪一本实体书、从什么状态变到什么状态。对 AI 来说，这类空白只能靠猜。

第二版：补齐数据对象和状态流

我没有推倒重做，直接用中文要求它沿用现有页面继续修改：

增加书友、图书、实体副本、借阅单四类数据。一本图书允许有多个副本，每个副本有独立编号。副本状态限定为空闲、已预约、已借出、待确认归还。书友只能预约空闲副本；发布者确认交接后，预约才变成已借出；归还需由下一位接收者或管理员确认。历史借阅单保留书名快照，删除图书也不能清掉记录。

改完后，我看到的变化很具体：原来的“借书按钮”变成“预约—确认交接”两步；原来的一个库存数字变成每册副本的状态；原来的借阅列表增加了预约时间、持有人和应还日。这里最值钱的改动，是我把“书”和“手里那一册书”拆开了，否则同名书、多册书迟早把库存弄乱。

第三版：把边界写成可执行规则

第二版流程能跑，我又补了一轮异常和验收条件：

同一副本同一时刻只能存在一张有效预约单；预约保留 24 小时，超时自动释放；借期 14 天，逾期只标记并提醒，不自动扣分；本人不能预约自己当前持有的副本；交接码为 6 位且 10 分钟失效；网络重复提交时只生成一张借阅单。首页显示可借数量，不把已预约副本算进去。

我随后按四个用例验收：两台手机同时抢同一册，只应成功一台；第 24 小时整到期，副本恢复空闲；连续点两次确认，只产生一条记录；删除图书展示页，历史订单仍显示当时的书名。第三版把“看起来能用”推进到了“结果可以判断对错”。

我现在固定这样写提示词

我会先列角色权限，再列数据名词；接着画出状态和触发动作；每条业务规则尽量带数字；然后补重复提交、并发、超时、删除后的处理；末尾给出三到五个验收样例。每一轮我只改一组问题，避免页面、数据和权限一起变化，导致我分不清是哪句描述影响了结果。

这套办法也有边界。我在预览里看不到真实并发锁是否可靠，仍要用两台真机压一次；微信订阅提醒需要书友授权，生成页面无法替我获得长期通知权限。旧表格里还有 ISBN 缺位、同书异名的脏数据，我花了四十分钟合并，AI 没法自动判断哪条才对。

我下次复用这套三版提示词，会在码上飞再跑一遍。