银河探索舰队 #7179
这个项目用于验证「同一个账号下多个项目同时补材料并重置 Review」的流程。它和 #5899 的区别是：#7179 更关注批量场景，比如多个项目都已经提交过 review，现在需要补充内容后重新排队。
项目目标
- 验证 owner_user_id 相同的项目能被准确筛选，不误伤其他用户项目。
- 验证多个项目的 README 和日志补充后，public_snapshot 可以分别重新计算。
- 验证 review 从 evaluated 回到 pending 后，后台 worker 能重新生成问题。
- 验证 Review prompt 在面对「接口测试型项目」时，能根据具体日志提出过程类问题，而不是只问泛泛的真假判断。
当前实现
项目保留了最初的 Token API README 更新记录，并补充了更多开发过程说明：如何选择测试字段、如何确认数据库写入、如何检查公开页图片、如何处理多个项目 review 状态不一致的问题。
我遇到的主要问题
最开始这份材料太薄，README 只说明了图片链路复测，日志也只有两条。AI 虽然能生成 5 个问题，但很多问题会偏泛。为了让 Review 更有价值，我把自己实际排查的路径写出来：先定位用户，再列项目，再看每个项目的 README 长度、日志数量和 review 状态，最后决定统一补材料并重置。
下一步
如果这次 worker 能重新生成质量更高的问题，我会把这个流程整理成一个管理员工具：输入邮箱，列出项目，勾选要补材料或重置的对象，最后显示变更摘要。
更新记录
-
重置成功后，每个 review 应该是 pending，questions 为空，evaluation 为空，project.public_snapshot.review_status 应该折叠成 pending。后台 worker 看到 pending 后会进入 checking，然后根据补充后的 README 和日志重新生成 questions_ready 或 needs_more。
-
我没有把 README 写成宣传文案，而是补充 Review 真正需要的信息：项目目标、实现方式、排查过程、遇到的问题和下一步。这样 AI 出题时可以围绕具体行为追问，比如为什么要查 email_normalized、为什么要重算 public_snapshot，而不是只问“你是不是自己做的”。
-
查到三个项目状态不一致：#5899 是 evaluated 但只有 2 个问题，#7179 是 evaluated 且有 5 个问题，#4831 是 needs_more。这个差异正好适合作为批量重置测试：同一个脚本要能把不同旧状态都归一成 pending，同时清掉旧问题和旧评价。
-
先用 email_normalized 找到用户，再用 owner_user_id 查 projects。这里特意同时查了 gamil 和 gmail 两种拼写，确认 gamil 没有记录，真实用户是 mr.guo.lin@gmail.com。这个步骤很重要，因为后面的 reset 会修改 review 文档，不能靠猜 slug。
-
通过 /docs/submit 文档中的日志接口提交，验证日志附件图片会保存真实 CloudBase fileID 并在公开页签名展示。
-
今天我们成功启用了 AI 自动寻路引擎，在躲避了 42 颗微陨石后安全越过了太阳系边缘的柯伊伯带！动力引擎一切良好，星图传感器运行完美。
