AI 让原型更容易出现：一段描述可以很快变成页面，表单、列表和按钮也能像成品一样运行。问题是，界面展示了某条操作路径，却未必回答了这条路径背后的全部规则。
如果前端、后端和测试分别把同一个原型交给各自的 AI，缺少的细节就可能被补成不同版本。看起来是实现冲突，根源可能是开发前没有形成共同约定。
原型之外，还有哪些问题
以一个通用的预约表单为例。页面上能选择日期和人数，仍然需要确定：
- 日期采用哪个时区，最早可以预约到什么时候。
- 人数是否允许为零，输入上限是什么。
- 同一时间段名额不足时，界面怎样处理。
- 重复提交是否会生成两条记录。
- 服务暂时不可用时，是否允许重试。
- 取消之后，名额何时恢复。
这些规则很难仅凭截图推断。让 AI 自行补全可以用于探索方案，但补全结果需要被确认，才能成为共同执行的需求。
在开发前安排一次细节对齐
讨论不必追求一次解决所有问题。目标是让当前迭代涉及的关键行为明确，把还没有答案的部分单独列出。
建议按这个顺序推进：
- 展示原型，标出已经确认的行为和仅用于演示的内容。
- 沿一条完整用户路径，讨论输入、状态变化和最终结果。
- 确认字段、接口与异常行为。
- 为关键规则写出可以操作的验收例子。
- 记录未决问题、负责人和下一次确认条件。
会议的产物应当是一份共识文档，而不只是每个人记住了自己的理解。
共识文档至少包含什么
| 部分 | 应回答的问题 |
|---|---|
| 目标与范围 | 本次解决什么，哪些行为留到后续 |
| 字段规则 | 名称、含义、类型、单位、必填条件和边界 |
| 接口约定 | 请求、返回、失败情况、重复请求的处理方式 |
| 状态规则 | 有哪些状态，谁能触发转换，转换后发生什么 |
| 验收例子 | 给定什么条件，执行什么动作，应得到什么结果 |
| 未决项 | 还缺什么信息，由谁确认，是否阻塞开发 |
对不确定的内容直接标明“待确认”，避免 AI 把猜测当成既定事实。
用例比形容词更容易同步
“操作要友好”“接口要稳定”都表达了愿望，但不足以判断实现是否合格。
可以改成更具体的规则：
当预约名额已经用完时，提交不会创建记录；页面保留已经填写的内容，提示选择其他时间段。
这段描述可以同时帮助前端确定提示、后端确定行为、测试确定检查方式，也给 AI 提供了明确的实现边界。
把变更同步到同一个版本
文档需要带版本或修订记录。规则变化时，先更新共同文档，再让各角色与各自的 AI 按新版本调整。已有约定与生成结果冲突时，先核对约定是否仍然有效，再决定改文档还是改实现。
需求共识不能保证没有返工，但它能让分歧有一个共同参照，使问题更早暴露，也更容易定位。