“增加一个到期提醒”可以很快转成字段、接口和页面。但如果还没有想清楚提醒发给谁、什么时候发、失败后怎么办，代码写得越快，也可能越早遇到规则冲突。
使用 AI 编程时，值得先做的一件事，是把需求整理成一个能够闭环的问题模型。这并不意味着必须先画出复杂架构图，而是让关键行为可以被解释、实现和检查。
用六个角度检查需求
| 角度 | 要确认的内容 |
|---|---|
| 输入 | 数据来自哪里，是否完整，有没有单位和时间口径 |
| 参与者 | 谁发起、谁处理、谁查看，分别有什么权限 |
| 状态 | 对象经历哪些阶段，什么事件触发变化 |
| 规则 | 允许什么、拒绝什么，冲突时按哪个优先级 |
| 异常 | 超时、重复、缺失、失败时怎样处理 |
| 输出 | 最终交付什么结果，如何判断完成 |
这些问题不必同样详细。一个简单的文本转换工具可能没有复杂权限，但转换失败时保留什么、提示什么，仍然值得说清楚。
把一个提醒需求展开
仍以通用的到期提醒为例，可以继续问：
- “到期”按自然日还是精确时间计算？
- 同一对象能否有多个负责人？
- 提醒成功后，是否仍需要人工确认处理？
- 多次扫描命中同一对象，如何避免重复提醒？
- 对象的到期时间被修改后，旧提醒是否失效？
- 消息发送失败时，是自动重试还是进入待处理列表？
回答这些问题，会自然形成状态、事件和约束。此时再让 AI 设计接口与实现，输入就不再只有一句抽象愿望。
让 AI 辅助找缺口
可以使用这样的任务描述：
请检查下面的需求模型，先不要写实现代码。
按输入、参与者、状态、规则、异常、输出检查缺失项。
把“材料已经明确”“可以提出的方案”“必须进一步确认”分开。
每个重要问题说明：它会影响哪个用户行为或验收结果。
优先列出会导致实现分歧的问题。
AI 的追问只能作为检查线索。最终规则仍需要结合实际业务和负责人的决定，不能因为生成内容看起来完整，就把未知信息当成已知。
从指出问题走到提出可比较的方案
“这里可能重复提醒”指出了风险。更进一步，可以同时提出处理选项：按事件去重、按时间窗口限制，或者由接收者确认后停止。
比较方案时，关注实现成本、误提醒与漏提醒的代价、排查难度和后续变更空间。没有足够信息时，记录假设与重议条件，比过早选择一个复杂方案更有帮助。
用结果校验模型
建模完成后，沿一条正常路径和一条异常路径走一遍，确认输入如何变成结果。然后把这些路径变成验收例子，交给实现与测试共同使用。
建模不能取代编码与验证。它的价值，是提前减少含义不清和约束冲突，让后续代码更接近真正需要解决的问题。