银河探索舰队 #4831
#4831 是这组三个项目里最适合复盘的一个，因为它之前被 AI Review 判为 needs_more。旧材料只有「API 图片链路复测」和一段偏故事化的航行日志，缺少真实制作过程，所以这次我把它补成一个专门验证 needs_more 恢复流程的样本。
为什么之前没有通过
旧 Review 指出的问题是准确的：项目核心功能不清楚、实现方式不清楚、缺少真实排查步骤，所谓 AI 自动寻路也只有概念描述。换句话说，它像一条接口测试记录，不像一个孩子或开发者真正做出来的项目。
这次补了什么
- 明确项目目标：验证旧项目重新提交后，图片展示和 Review 状态能恢复。
- 补充实现细节：README 写入、日志写入、图片 fileID、签名 URL、public_snapshot 重算。
- 补充失败过程：为什么会 needs_more，哪些材料被 AI 判定太薄。
- 补充修复动作：增加具体日志、重置 review、等待 worker 重新评审。
技术链路
- 通过用户邮箱定位 user_id。
- 通过 owner_user_id 找到项目。
- 更新项目 README 的 Markdown、HTML 和 text 字段。
- 新增 public 日志，让 worker 有足够材料读取。
- 把 review 文档重置为 pending，清空旧 completeness 和问题。
- 重新计算项目 public_snapshot，让公开页先显示评审中。
我希望验证的结果
如果材料补充有效，后台 worker 应该不再给出 needs_more，而是生成 5 到 7 道针对具体过程的问题。例如它可以追问：为什么先查 email 拼写、如何判断 fileID 和签名 URL 是否正确、为什么要保留乱码日志作为异常样本、重置 review 时哪些字段必须清空。
更新记录
-
补完材料后，下一步是把 review 从 needs_more 重置为 pending。重置时不能只改 status，还要清空 questions、completeness、evaluation、error_summary 等旧字段，否则公开页和后台可能混用旧结果。重置后再观察 worker 是否重新生成 questions_ready。
-
项目里原来有一些材料偏测试或偏故事化，这些不删掉，因为它们能说明早期提交为什么不够。真正的修复是新增更清楚的日志，说明我如何识别问题、如何验证图片签名 URL、如何判断 review 状态是否会重新进入队列。
-
我把这次恢复流程拆成六步：定位用户、定位项目、更新 README、补 public logs、重置 review、重算 public_snapshot。每一步都对应数据库中的具体字段，这样 AI Review 能看到真实操作，而不是只看到“已经修好了”。
-
旧评审说材料像接口复测，不像完整项目。重新读了一遍旧 README 后，我同意这个判断：它没有解释项目要解决什么问题，也没有写清楚怎么做、哪里失败、怎么修复。于是这次先把失败原因写进 README，避免只是机械增加字数。
-
通过 /docs/submit 文档中的日志接口提交，验证日志附件图片会保存真实 CloudBase fileID 并在公开页签名展示。
-
今天我们成功启用了 AI 自动寻路引擎，在躲避了 42 颗微陨石后安全越过了太阳系边缘的柯伊伯带！动力引擎一切良好，星图传感器运行完美。
