AI 编码代理大幅缩短了从想法到可用软件的距离，但并未消除判断力。一个好看的界面不能证明数据能在重载后存活，通过的单元测试不能证明键盘用户能完成核心任务，成功部署不能证明预期提交已到达生产环境。因此需要“证明门”——必须满足的可观测条件，才可使产品声明更可靠。以下是区分有说服力的 AI demo 与小规模可交付 MVP 的五道门。
第一道门：证明一个有价值的用户循环
AI 让功能生成变得廉价，但无控制的范围扩张尤其危险。在请求代码前，先定义一个特定情境下的主要用户，描述其可观测的初始状态、能执行的最小有用操作、直接结果以及他们可能返回的原因。这就是产品的核心循环。例如“构建一个生产力平台”过于宽泛，更可测试的循环可以是：自由职业者记住一个有用的客户成果 → 记录成果和支持证据 → 记录出现在可搜索库中 → 能稍后用于提案或回顾。此门通过的条件不是存在表单，而是新用户无需指导即可完成整个循环并说明变化。
第二道门：证明数据与恢复契约
许多 demo 将持久化视为实现细节，但对真实用户而言，持久化是产品承诺的一部分。在允许生成代码散布存储假设之前，先定义数据契约：对每个持久化字段明确名称、类型、是否必填、长度/计数限制、规范化规则和面向用户的含义。持久化数据应携带足够的版本信息以便安全解释。要区分通常被错误归为“空”的各种状态：无数据、当前数据有效、旧数据已迁移成功、数据损坏/不支持、存储不可用、写入因配额或访问限制失败。一个危险模式是捕获解析错误并返回空数组，然后用空状态覆盖用户的最后有效数据。恢复行为必须预先设计。最强实际测试是真实往返：创建代表记录 → 导出备份 → 通过正常控制删除应用数据 → 导入备份 → 重新加载应用 → 验证预期记录和字段存在。
第三道门：用有边界的提示证明 AI 变更
“构建剩余应用”给了代理过多自由度，也给审查者过少证据。有边界的实现提示应包含五部分：目标、边界、验收标准、验证、报告。目标指明一个用户可见结果；边界说明哪些不可更改；验收标准描述可观察的通过/失败行为；验证列出必须运行的测试和命令；报告要求确切结果、已更改文件、剩余风险和未验证行为。对于 Bug，应将诊断与编辑分离：提供预期行为、实际行为、重现步骤和首个相关错误，要求代理追踪代码路径并识别确认怀疑原因的最小实验，然后再请求有针对性的修复和回归测试。
第四道门：证明行为、失败状态和可访问性
如果测试只断言实现细节而非用户可见行为，那么绿色测试套件也可能与故障产品共存。测试领域规则，也要测试用户依赖的完整操作：必填字段拒绝无效输入，有效记录重载后存活，编辑保留身份和创建元数据，取消操作不改变任何内容，删除需确认，搜索和组合过滤器返回确定结果，失败的导入不改变当前数据，选择的导出仅包含预期记录。然后检查超越愉快路径的界面：键盘顺序应遵循任务，焦点应保持可见且在对话框后合理返回，错误应与相关控件关联，基本操作在 320px 宽度和 200% 缩放时应保持可用。自动化可访问性工具有价值，但无法证明完整交互。结果按三组报告：通过、失败、未验证。“未发现自动违规”不等于“工作流可访问”。
第五道门：证明用户实际收到的发布
本地构建成功证明的是构建本身，而非部署。发布前，核对文档与实现行为，运行完整相关测试套件、类型检查、配置的 lint 检查和生产构建，检查凭据、调试输出、失效占位符和无法解释的控制台错误。记录发布提交和已知回滚目标。部署后，在干净会话中验证线上产品：HTTPS 加载正确，主机服务预期发布，静态资源和元数据加载，核心循环工作，持久化数据重载后存活，错误和恢复状态可用，键盘和窄屏行为正常，浏览器控制台和网络面板无未解释的故障。如果高影响线上检查失败，诚实的结果是诊断出发布问题，而非成功启动公告。
保持小证据记录
对每道门记录：正在评估的声明、重现步骤、运行的测试或命令、手动观察、通过/失败/未验证项、回滚点。这份记录无需详尽，其目的是阻止信心脱离证据。AI 能帮助我们更快构建，相应的专业技能是学会何时可用证据证明“这已就绪”。
#开发者 #工具 #MVP #ProofGate #AIAgent #测试 #可访问性 #WebDev #工程效率
@DevToolboxHub