我的结论很明确用 AI 生成应用时我把需求写成“角色、对象、状态、规则、验收”五部分返工会少很多只写一句功能愿望页面出得快后面的逻辑债也来得快。我这次以产品经理身份做了一个读书会图书漂流小程序。它要让书友登记闲置书、预约取书、确认借出、归还后重新流转。我用的是一类“中文需求直出多端应用”的零代码 AI 工具我输入自然语言它就能生成可用的微信小程序、APP、H5 或鸿蒙应用生成后还能继续用中文改页面和逻辑。为了看清需求粒度对结果的影响我保留了三版提示词。第一版只讲愿望十分钟能看不能验收我写的是做一个读书会图书漂流小程序大家可以发布书、借书、还书查看自己的借阅记录界面简洁温暖。这一版很快生成了首页、发布、我的借阅和个人中心。演示点击都通但我一测就发现三个洞同一本书可以被两个人同时预约“已借出”和“待归还”含义重叠发布者删除图书后借阅记录也找不到对应书名。我复盘后发现“可以借书”只有动作没有说明谁能借、借哪一本实体书、从什么状态变到什么状态。对 AI 来说这类空白只能靠猜。第二版补齐数据对象和状态流我没有推倒重做直接用中文要求它沿用现有页面继续修改增加书友、图书、实体副本、借阅单四类数据。一本图书允许有多个副本每个副本有独立编号。副本状态限定为空闲、已预约、已借出、待确认归还。书友只能预约空闲副本发布者确认交接后预约才变成已借出归还需由下一位接收者或管理员确认。历史借阅单保留书名快照删除图书也不能清掉记录。改完后我看到的变化很具体原来的“借书按钮”变成“预约—确认交接”两步原来的一个库存数字变成每册副本的状态原来的借阅列表增加了预约时间、持有人和应还日。这里最值钱的改动是我把“书”和“手里那一册书”拆开了否则同名书、多册书迟早把库存弄乱。第三版把边界写成可执行规则第二版流程能跑我又补了一轮异常和验收条件同一副本同一时刻只能存在一张有效预约单预约保留 24 小时超时自动释放借期 14 天逾期只标记并提醒不自动扣分本人不能预约自己当前持有的副本交接码为 6 位且 10 分钟失效网络重复提交时只生成一张借阅单。首页显示可借数量不把已预约副本算进去。我随后按四个用例验收两台手机同时抢同一册只应成功一台第 24 小时整到期副本恢复空闲连续点两次确认只产生一条记录删除图书展示页历史订单仍显示当时的书名。第三版把“看起来能用”推进到了“结果可以判断对错”。我现在固定这样写提示词我会先列角色权限再列数据名词接着画出状态和触发动作每条业务规则尽量带数字然后补重复提交、并发、超时、删除后的处理末尾给出三到五个验收样例。每一轮我只改一组问题避免页面、数据和权限一起变化导致我分不清是哪句描述影响了结果。这套办法也有边界。我在预览里看不到真实并发锁是否可靠仍要用两台真机压一次微信订阅提醒需要书友授权生成页面无法替我获得长期通知权限。旧表格里还有 ISBN 缺位、同书异名的脏数据我花了四十分钟合并AI 没法自动判断哪条才对。我下次复用这套三版提示词会在码上飞再跑一遍。