让 AI 直接“做一个会员系统”或“加个导出功能”，通常得到的是一堆看起来完整、实际无法验收的代码。问题不在工具，而在需求没有边界。把需求先写成澄清单，AI 才能生成可审查、可测试、可迭代的实现。
澄清单至少包含六项
谁在什么场景下使用、成功后看见什么、涉及哪些数据、遵守哪些规则、失败时如何处理、如何验收。每一项尽量写成可观察的结果，而不是“体验更好”“页面更快”这种无法判断的描述。
| 问题 | 示例写法 | 验收方法 |
|---|---|---|
| 使用者 | 已登录的运营人员 | 不同角色分别验证权限 |
| 成功结果 | 导出指定日期范围的 CSV | 核对字段、行数和下载文件 |
| 异常分支 | 日期无数据时显示空结果说明 | 构造空数据案例验证 |
把“要做什么”变成测试案例
- 先列三到五个真实使用场景，包括一个失败或边界场景。
- 为每个场景写输入、期望输出和不应发生的事。
- 再让 AI 据此提出接口、数据结构和实施步骤。
- 小步实现后，按场景逐一验证，不通过就回到澄清单更新。
遇到陌生项目时，可以结合 Codex 接手陌生项目的三步法，先建立项目地图和可复现验证，再动代码。
将边界写给未来的自己
常见遗漏包括权限、重复提交、超时、空数据、历史数据迁移和回滚路径。AI 不会自动知道你们的业务约定，所以这些都应明确写入。高质量开发不是一次生成很多代码，而是在每次生成前让“正确”变得可定义。
