小应用六轮审查，暴露 AI 开发验收盲区

一个准备交给宠物美容店使用的小应用，第一次独立审查就查出 29 个代码问题，以及 13 项法律或隐私风险。作者亲自开发，AI agents 承担了大部分代码输入，原以为已经接近完工。

SlotSaver 经历了六轮审查，作者最后得到的教训很直接：修复者不能只凭自己的报告宣布完成。对使用 AI 编程的程序员，这篇最有用的是一组具体失败案例：测试全过、函数存在、页面能打开，都可能掩盖尚未解决的问题。

页面能打开，为什么应用仍然不能用

SlotSaver 的流程很简单：宠物美容店出现预约取消后，系统寻找同意接收消息的客户，准备一条 WhatsApp 文本，店主点一下发送。应用运行在 Cloudflare 免费计划上，作者称托管没有费用。

但第一次审查发现，连这条短链路都存在几个断点。

作者配置的安全策略禁止浏览器执行内联脚本，而 SvelteKit 每个页面启动时都需要一个内联脚本。结果是页面看得见，交互却没有启动。安全配置单独看似乎合理，放进实际框架里就发生了冲突。

发送按钮则直接信任表单传来的电话号码和消息正文。问题不在按钮是否响应，而在服务端是否应该接受客户端提交的这两项内容。原文没有展开具体攻击过程，也没有说明最终如何修复。

登录还有平台限制：密码哈希配置要求的迭代次数超过平台允许范围，可能导致服务器错误。作者没有给出具体迭代次数，不能据此推导适用于 Cloudflare 的参数配置。

这几个问题分别落在浏览器、服务端信任边界和运行平台上。只检查组件代码，覆盖不了完整使用过程。

六轮审查，为什么不能合并成一次

作者使用了一个独立于开发 agent 的 AI 审查者。它只有只读权限，可以阅读代码、测试线上站点，不能修改文件或部署。

后续几轮暴露的问题，恰好说明修复本身也会引入新的遗漏：

• 第二轮发现 Exit 按钮没有真正退出登录。作者在第一轮后改了 session cookie 的名称，退出代码仍然删除旧名称，而当时所有测试都通过了。
• 第三轮发现，因隐私原因删除的客户，会在下一次 Excel 导入时重新出现。删除动作成功，不代表后续数据流会尊重这次删除。
• 第四轮发现，10:00 的预约在消息里变成了 09:00。原文没有说明具体原因，不能直接认定是哪一种时区处理错误。

作者给审查者保留了一条固定指令：先读之前的报告，了解哪些问题被宣称已经修复，再亲自检查代码和线上站点。

这条指令抓到了一个很典型的漏洞。修复报告声称 webhook 已验证签名，代码里也确实有验证函数，但没有任何地方调用它。审查者发送未签名请求，依然得到成功响应。

函数存在，只能证明代码写过；请求被正确拒绝，才能证明这条防线实际生效。

各轮之间，作者持续修复问题，自动化测试从 34 个增加到 105 个。第六轮之后，另一个独立会话又使用假数据执行了 61 个验收场景。不过，这篇没有披露验收结果细节，也没有逐项介绍第五、第六轮的发现。

我的判断

这套做法最有价值的地方，是把审查者的任务从「读懂修复说明」推进到「验证修复声明」。先前报告提供检查线索，代码和运行结果提供证据。只读权限则让审查职责更清楚：发现问题、复现问题，再交回开发环节修复。

但它仍然是一个小应用的经验记录。作者没有提供人工审查、同一 agent 自查、独立 AI 审查之间的对照数据，也没有披露模型、提示词全文或审查成本。因此，不能据此断言独立 AI 一定更可靠，更不能把「六轮」当成通用交付标准。

测试从 34 个增至 105 个，也不等于质量按比例提高。退出登录的例子已经说明，关键行为如果没被断言，测试全绿仍会漏掉问题。对一般团队，更值得借鉴的是围绕实际失败补回归检查，而不是追求测试数量。

另外，第一轮报告里的 13 项法律或隐私风险并未展开。它们是待核查的风险清单，原文不足以支持「已经确认违法」或「已经满足合规要求」这样的判断。

能拿来做什么

• 给 AI 编程任务增加独立复核环节，让审查会话读取历史问题和修复声明，再检查当前代码与实际运行结果。
• 为退出登录这类关键操作检查最终状态，例如原来的 session 是否失效，而不只检查接口是否返回成功。
• 把跨流程问题纳入回归检查：删除客户后重新导入 Excel，确认数据不会恢复；生成消息后核对预约时间是否一致。
• 检查 webhook 验签时直接发送未签名请求，验证它是否被拒绝，同时确认验签函数确实接入请求处理路径。