银河探索舰队 #5899

这是一个用于验证 ML2026 舰队项目提交链路的完整样本项目。它不只是测试接口能不能跑通，而是把「README 更新、日志提交、图片附件上传、CloudBase fileID 保存、公开页 HTTPS 签名展示、AI Review 重新出题」串成一次可复现的项目流程。

项目目标

我希望这艘测试舰队能回答三个问题：

学生通过 Token API 更新 README 后，公开页是否能稳定展示最新内容。
日志接口上传 multipart 图片后，数据库里是否保存真实 CloudBase fileID，而不是临时 URL。
AI Review 是否能从 README 和日志中读到足够具体的制作过程，并生成 5 到 7 个温和、可回答的面试题。

已完成的功能

使用项目 Token 重新提交 README，并保留纯文本、Markdown 和 HTML 三种形态。
通过日志接口提交多条 public 开发日志，覆盖接口测试、图片上传、3D 打印和公开页验证。
对图片附件做签名展示验证，确认公开详情页可以拿到可访问的 HTTPS 地址。
记录一次失败的编码日志，作为 Review 识别「异常材料」和后续修复过程的样本。

技术实现

后端入口主要围绕项目写入 API、日志 API 和 Review 请求 API。README 进入数据库前会先生成安全 HTML 和可检索的 readme_text；日志独立保存在 logs 集合里，Review worker 只读取 visibility 为 public 的日志。图片附件进入 CloudBase Storage 后，公开页通过签名 URL 展示，避免把私有 fileID 直接暴露给浏览器。

这次迭代的重点

原始材料过于像接口 smoke test，缺少人能读懂的制作过程。我这次补充了接口调试、图片链路、编码问题和公开页验证的具体过程，让 AI Review 可以判断这是一次真实的项目复盘，而不是只有一句「测试成功」。

更新记录

6月8日 Review 重置前的材料补全

旧 review 已经 evaluated，但只有 2 个问题，不符合现在至少 5 道题的规则。我先补 README 和日志，再把 review 文档重置到 pending，让后台 worker 重新读完整材料出题。这样能验证新 prompt 对完整材料的处理，也能避免旧的评价字段影响公开状态判断。
6月8日图片附件链路验证

用 multipart 方式重新提交一张测试图片后，我重点检查了两个点：第一，数据库里保存的是 CloudBase fileID，而不是本地临时路径；第二，公开页拿到的是短期签名 HTTPS URL，刷新后仍然能重新签名。这样可以证明图片不是靠开发机缓存展示，而是真的经过了云存储链路。
6月8日排查乱码日志：确认是输入编码问题

项目里曾经出现一条标题和正文都乱码的 3D 打印日志。我保留它作为异常样本，但又补了一条正常中文日志对照。排查时先看数据库原文，再看公开页渲染，最后确认不是前端字体或 Markdown 转换问题，而是提交端传入时文本已经损坏。这个过程提醒我后续 Token API 最好在服务端记录原始 Content-Type 和编码。
6月8日确定复测范围：从提交到公开页

这次不是单独测一个接口，而是把 README 更新、日志提交、图片附件上传、公开页展示和 Review 重置放在同一条链路里测。先列出每一步应该写入的字段：projects.readme_markdown / readme_html / readme_text，logs.visibility，assets 或 storage fileID，以及 public_snapshot.review_status。这样后面看到页面异常时，可以反查到底是哪一层没有更新。
6月8日 3D 打印阶段性完成

今天天气不错，我们完成了3D打印的部分。 [2026-06-08 22:30]
6月8日 3D 打印阶段性完成

今天天气不错，我们完成了3D打印的部分。 [2026-06-08 22:30]
6月8日 3D ��ӡ�׶��

��3D��ӡ�Ĳ��֡� [2026-06-08 22:30]
6月1日 API 图片链路复测

通过 /docs/submit 文档中的日志接口提交，验证日志附件图片会保存真实 CloudBase fileID 并在公开页签名展示。
6月1日第一阶段航行日志：突破柯伊伯带

今天我们成功启用了 AI 自动寻路引擎，在躲避了 42 颗微陨石后安全越过了太阳系边缘的柯伊伯带！动力引擎一切良好，星图传感器运行完美。