展开本页目录
开始前准备什么
- 下载独立练习包，保留 starter、reference 和原始输入。
- Python 3标准库SQLite与两个隔离浏览器会话。
- Replit原生功能需账号/额度；App Testing当前需Power/Max付费模式，本地参考不调用该能力。
- 两名编辑者读取同一revision
- 向Replit Agent提交条件写入合同
- 审查服务端原子条件更新
- 先让A保存到revision2
- B的旧版保存触发409并留草稿
- 审阅合并后按新版重试
- 并发API验收恰一成功
starter、任务提示、具体输入、作者人工可运行参考与独立验证；不含账号/密钥/运行时数据库。
按本文环境运行，再对照原始输入和正反例。
1. 两名编辑者读取同一revision
从 revision=1 的同一公告开始。打开两个隔离浏览器会话，分别保留A和B的未提交文字，不共享前端状态。
2. 向Replit Agent提交条件写入合同
在 Replit Plan 先提出条件更新与草稿合同，再生成 Full Stack JavaScript 应用；本地包是作者用SQLite适配的相同业务合同，不是托管数据库导出。
交给目标 AI 工具的任务提示
构建 Full Stack JavaScript 编辑板。每次保存提交 id/revision/text，后端用单条带 revision 条件的原子 UPDATE，失败返回 409 与当前版本。前端保留旧草稿并可对照重试。不要先读后无条件写，不把客户端 disable 按钮当并发控制。
3. 审查服务端原子条件更新
审查服务端使用单条 UPDATE ... WHERE id=? AND revision=?，检查 rowcount 后提交。先读再无条件写无法防并发覆盖。
4. 先让A保存到revision2
本地运行 server.py，让A先保存，版本应由1到2；B仍基于1，不能在后台悄悄替换它的草稿。
5. B的旧版保存触发409并留草稿
B保存得到409和服务器新版本，自己的文字仍保留。检查 Network/响应，不把客户端按钮禁用当并发安全。
6. 审阅合并后按新版重试
审阅差异后点“保留草稿并采用最新revision”，手工合并再保存，版本到3。原生 App Testing 需Power/Max付费模式，本文没有启用。
7. 并发API验收恰一成功
运行 python3 reference/verify.py；两个真正并发请求争用同一revision，应恰一个200、一个409，最终版本只加1。临时SQLite运行文件不进入下载包。
怎样确认已经完成
- 同一旧 revision 的两个更新恰有一个成功、一个冲突，持久数据不会无条件最后写覆盖。
- 409 后 B 的草稿仍在，显示服务器新版本；用户选择/合并后才按新 revision 提交。
- 并发 API 负例与两个隔离浏览器都通过；原生 App Testing 未执行时不得冒称其回放通过。
常见问题
Replit Agent 做的多人应用会互相覆盖修改吗？
审查服务端使用单条 UPDATE ... WHERE id=? AND revision=?，检查 rowcount 后提交。先读再无条件写无法防并发覆盖。
AI 写的后台怎么提示内容已被别人更新？
B保存得到409和服务器新版本，自己的文字仍保留。检查 Network/响应，不把客户端按钮禁用当并发安全。
哪些结果已执行，哪些仍需原生账号验证？
真实双浏览器409草稿保留/合并到revision3，独立并发HTTP恰一200一409已在本地SQLite适配验证；Replit托管数据库/Agent/App Testing未执行。