为 AI 写回设计可复现的并发冲突测试

AI 给出的修改即使内容正确，也可能在保存时覆盖人工刚改好的数据。原文用一个虚构的共享订单场景，讨论如何测试这类「过期写入」：让 AI 先读取旧版本，再安排人工更新，最后检查系统能否拦住旧提案。

结论很具体：不能只看冲突提示，更要验证数据库保住了什么，以及刷新、审批和重试是否仍然安全。这是一份测试设计指南，没有实际运行结果或性能数据，适合拿来检查 AI 编程项目里的保存流程。

AI 只改备注，为什么也可能出错

场景从 revision 12 开始。订单里有配送日期和内部备注，AI 读取后准备更新备注。提交之前，一位有权限的协调员修正了配送日期，订单变成 revision 13。

如果 AI 提交的是 revision 12 的完整副本，而后端直接保存，旧配送日期就可能覆盖人工修正。

把请求改成只包含备注的局部更新，能减少覆盖范围，却没有解决所有问题。假如备注写着「按原定日期发货」，它仍可能依赖刚被修改的日期。字段没有重叠，业务含义却已经冲突。

因此，测试要主动制造这个顺序：AI 读取完成后暂停，安排人工修改，再放行 AI 写入。作者建议使用同步屏障（barrier）或可暂停的测试替身。随意等待几秒，无法稳定保证两次操作的先后关系，失败也难以复现。

拒绝旧提案，关键在后端如何保存

原文提出一种保守策略：只要记录版本发生变化，就拒绝旧提案，保留当前记录，再由应用提供差异比较或刷新建议。

版本检查和数据写入必须是一次原子决策。

先查询版本、确认没变，再执行无条件保存，中间仍可能插入另一笔修改。正确的存储语义是：仅当有权更新的目标记录仍等于预期版本时，才更新允许的字段，并在成功时递增版本。

这通常称为乐观并发控制：读取时记下版本，提交时让存储层确认这份依据还有效。原文没有给具体数据库、API 或代码，不能据此认定某一种实现已经通过验证。

没有记录匹配更新条件时，也不能统一解释成「版本冲突」。记录可能已不可用，调用者也可能没有访问权限。应用需要给出受控响应，避免泄露调用者无权知道的信息。

版本匹配也不等于允许写入。权限检查、可修改字段校验，都要留在写入路径上。

验证时，冲突横幅只是其中一项证据。测试还应记录提交前的版本和字段值，尝试保存，再通过有权限的测试接口检查持久化结果：

• 人工修正后的配送日期仍然保留。
• 无关字段没有被 AI 的旧副本替换。
• 界面明确表示提案尚未应用，而非更新已经完成。

诊断记录可以包含任务 ID、预期版本、观察到的版本和结果，同时设置访问与保留期限，避免夹带不必要的客户内容。

刷新、审批和重试，也各有一个坑

冲突被拦住后，流程还没有结束。

用户请求刷新建议时，AI 应基于当前记录重新生成。但用户查看比较页面期间，记录还可能再次变化，所以点击应用时仍要执行条件写入。刷新过一次，不能成为后续无条件保存的理由。

审批也要对应到具体提案。重新生成的内容可能与人工审过的版本有明显差异，应用需要规定何时重新审批，并把批准动作绑定到它实际覆盖的内容。

重试则要单独测试。第一次写入可能已经成功，只是响应丢失；再次提交时，版本已经变化，看起来也像旧提案。此时需要借助操作标识和结果核对，识别这次操作是否已经应用，避免把它当成新的动作。

条件写入能阻止一类覆盖问题，但不能独自解决重试与审批。

如果操作涉及多条记录或外部副作用，单条记录的版本号也不足以覆盖整个流程。原文要求明确这些边界，没有给出跨记录事务或外部操作的完整方案。

我的判断

这篇最有用的地方，是把「AI 是否写对了内容」与「应用是否正确保存」分开。即使模型输出完全合理，保存逻辑仍可能造成数据损坏。测试模型质量，替代不了测试并发写入。

整条提案因版本变化而被拒绝，规则清楚，也便于验证；代价是无关字段的修改也可能触发冲突。相比之下，只更新指定字段可以缩小覆盖范围，人工审阅合并则能保留部分有效修改，但两者都需要处理字段之间的业务依赖，不能默认更安全。

作者没有提供这些策略的对照数据。这是一个合理的设计建议，还不能证明整条拒绝最适合所有团队。原文也明确披露内容由自主 AI agent 撰写发布，案例虚构，没有客户结果或基准测量。

一份测试通过，只能支持它覆盖的那条路径。是否可用于生产，还需要其他证据。

能拿来做什么

• 给 AI 辅助编辑表单补一条并发用例：读取 revision 12 后暂停，让人工保存出 revision 13，再提交旧提案，同时检查数据库内容与界面状态。
• 检查 Node 保存接口是否把预期版本纳入更新条件，并在成功时递增版本；不要把前端提交前查询当作并发保护。
• 为刷新后的建议和人工批准建立明确对应关系，并让每次应用都重新经过条件写入。
• 单独测试「保存成功但响应丢失」的重试路径，记录操作标识与最终结果，区分已应用操作和普通版本冲突。