用阶段验收约束 AI 编程交付

AI 写完代码后说「已经充分测试」，和它拿出测试命令、实际输出、通过结果，是两回事。ParkEase 的作者发现，比起不断加长提示词，把开发拆成固定阶段，并要求每个关卡提交证据，更能稳定改善交付质量。

作者用 Claude Code 独立开发这个面向印度的个人间停车位交易平台。他列出的三个漏网问题，分别涉及配色、支付脚本注入和未接入的安全控制。代码看起来完整，不代表检查已经发生。

为什么长提示词管不住最后的交付

作者最初也尝试过常见套路：指定资深工程师身份、列步骤、给示例，再用大写警告强调要求。这些提示词有帮助，但效果往往只维持一个会话。

他的解释是，提示词只是上下文中的一项请求。会话接近结束时，「记得做安全审查」会和即将完成的功能、模型报告成功的倾向竞争。尤其当要求出现在 40,000 tokens 之前，检查未必能在交付时落实。

作者改用固定阶段、具名关卡，并要求明确说出跳过了哪个关卡。具体有三点：

• 构建阶段固定采用「测试先行」，不用每次重新提醒。
• 验证指令在 agent 准备宣布完成时加载，让要求出现在需要执行的时刻。
• 交付阶段提交表格，逐项列出命令、输出和是否通过。

工作流的价值，在于把「我检查过了」变成可以核对的记录。

这里的「关卡」可以理解为交付条件：到这一步，必须拿出相应证据。文章没有展示具体如何阻止跳过，所以不能仅凭作者的描述，就认定它具备程序层面的强制约束。

三个关卡，分别发现了什么

第一个问题出在设计阶段。AI 先生成三个视觉方向，作者选中名为 Wayfinder 的方案，其中有鲜亮的钴蓝和绿色。

随后，设计 token 测试计算颜色与白色的对比度：钴蓝为 4.10:1，绿色为 3.77:1，都低于普通文本要求的 4.5:1。用于 14 像素按钮文字时，这套配色就不合格。

修复办法是分成两层：承载文字的区域使用更深的色调；鲜亮颜色只用于地图标记，以及另有标签说明的大面积填充。更关键的是，对比度要求被保留成测试，后续改色也会触发检查。

第二个问题位于支付路径。ParkEase 在 WebView 中打开 Razorpay checkout，初版把预订详情直接拼进页面的 script 块，其中包含车位所有者填写的标题。

测试输入了包含 </script><script>… 的恶意标题，成功跳出了原来的脚本块。一个用户填写的内容，因而可能在另一个用户的支付页面执行。

作者没有继续叠加转义规则，而是取消向自建文档中插入其他用户文本，改用 WebView 的类型化通道传递这些值。原文没有给出通道 API 或实现代码，无法据此照搬具体方案。

第三个问题更隐蔽。同一个 checkout 文件曾导出来源白名单，测试也证明列表里全是 Razorpay 来源，但它根本没有接到 WebView 上。安全审查才发现这处断点。

白名单内容正确，只证明配置正确；是否参与运行时决策，是另一件需要验证的事。

一个被定义、被测试却没有被使用的安全控制，会制造虚假的安全感。

我的判断

作者最有说服力的地方，是把检查放在容易遗漏的位置：配色确定后验证对比度，支付页面测试恶意输入，安全审查追踪控制是否真正生效。这三个案例都有明确问题和修复方向，比泛泛要求 AI「认真一点」更容易执行。

但「工作流胜过所有聪明提示词」仍是作者的经验判断。文章没有提供对照实验、缺陷率变化或不同模型的比较，也没有给出完整工作流配置。三个案例能说明关卡抓到了问题，不能证明所有团队采用同样流程都会得到同等收益。

提示词与工作流也有配合空间。阶段指令仍需要写清楚，而命令退出码、CI 检查和实际输出，可以为这些指令提供更可靠的验证依据。

成本同样真实：每个关卡都消耗 tokens，派发独立 reviewer agent 会更贵；即使只是两行修改，也要经过验证，增加等待时间。作者提到自己在系列第 14 篇中记录过昂贵的教训，但本文没有公布具体开销。

我的取舍是优先覆盖失败代价高、又容易自动检查的环节。支付与跨用户输入值得严格审查；低风险改动是否需要完整流程，要结合团队成本决定。作者关于 1,550 行 learnings.md 的内容只是下一篇预告，本文尚未证明这套「记忆」机制的效果。

能拿来做什么

• 给日常 AI 编程增加明确的完成条件：交付时列出实际执行的命令、关键输出和通过结果；没有运行的检查必须直接注明。
• 在前端设计 token 测试中加入文本与背景的对比度检查，让配色调整也能接受自动验证，尤其关注小字号按钮文字。
• 审查 WebView 支付页面时，追踪用户输入如何进入页面，并用恶意字符串测试边界；涉及类型化通道的改造，要继续核对具体实现。
• 检查来源白名单等安全配置时，沿着调用路径确认它确实参与运行时判断，避免测试只验证了一个无人使用的常量。