从原图到交付文档：巡检影像证据链
不止收下照片，
更要把证据交付出去。
一句话现场照片经 AI 预标注、人工确认，一键生成可以交付的检验报告；一个 714 张照片的大项目，84 秒出报告。
HEIC 上传 → OSS 三级图 → 视觉大模型预标注 → 画布标注与人工复核 → 模板填充出 Word。幕墙与基坑两个领域共用这一条链；报告只画已确认的框。
桌面复核
桌面复核：让照片和判断在同一处。
保留真实墙面照片、八个标注框和逐项确认操作。截图中的 QA 项目用于交互验收。
手机标注
手机标注：给现场操作留出画布。
这是本轮同步后保存的手机界面。画面直接使用基坑原图，保留选图、切图、画框和保存的工作入口。
- 我的工作
- 产品范围与关键取舍、交互迭代、AI 辅助实现、交付验证；报告链路生产事故的根因分析与热修。
- 当前进展
- v0.6 已验收并同步正式环境；报告链路 9 月 22 日热修后 714 张项目实测通过；正常样本混入报告等留账。
- 本页展示
- 桌面复核、正式版手机标注，以及出图链路的工程记录。
真正难的，不是把照片放上云，是让每张照片走到报告里时还带着它的证据。
照片从不同设备进入，判断需要人工参与，结果要进入一份有法律与工程责任的文档。图片存储、AI 推理、标注状态与文档排版必须在同一条链上设计，任何一段丢了状态，报告就成了"看起来对"的东西。
三项产品取舍
上传先成立，AI 按需进入。
资料接入与 AI 处理分开。没有 AI 结果，也不应堵住人工工作。
手机是现场入口，不是缩小版桌面。
围绕有限画布安排拍照、上传、触摸标注；保留源文件、兼容显示。
"已有标注"和"已经确认"分开。
看过、标过、AI 给过建议，都不等于复核通过。状态与原图、记录一起传到下游。
链路上的四处硬功夫
这些不是功能点，是让这条链在生产里站得住的地方。
- SEMANTICS
- 把"标注状态"翻译成"交付文档语义"。
报告只画已确认的框，且自己重绘；病害号按立面重编，照片号全报告连续，一张图可挂多条病害。排序改按 image_id，为的是可追溯。
- ROOT CAUSE
- 一次 OOM 的根因与 58 行修复。
旧路径把全部原图解码、画框、装进内存再排版，714 张项目单进程冲到 4.3 G 被内核杀掉。修复：OSS 服务端缩图、框坐标按长边缩放、8 路并发取图、原图回退——4 个文件 58 行，实测 83.6 s / 821 MB，新旧框重叠度均值 0.824。
- TWO DOMAINS
- 幕墙与基坑共用一条链。
幕墙填客户模板的 A–E 块；基坑是 13 类监测规则、逐日配置快照冻结、首测 / 复测分离、并发锁返回 409。同一条影像 → 文档链，两套领域规则。
- AI, HONESTLY
- "误报要治、漏识免费"，不作识别率声明。
视觉大模型只做预标注。发现改一类病害的定义会牵动其他类的输出（同一 prompt 内竞争）；新模型对照 10/10 vs 7/10 通过、1.89 s vs 3.94 s，没证明更好就不换。
数字来自 2026-09-13 → 09-22 的验证记录与热修记录；端到端 8–9 分钟的瓶颈在公网出口，不在计算。不出现客户与项目名。
做到哪里，就讲到哪里。
截至 2026.09.22
影像管理与现场操作
移动端交互、兼容上传、状态说明与指南已进入正式版；升级保留历史数据与既有入口。
规模与出图
批量导入与完整性校验、大图预览、大项目出图热修均有实测记录。它不等于所有批量操作都已验收。
报告模式与设备覆盖
正常样本混入报告、用户端超大批量上传、批量质检与导出、更多真实设备验证仍在账上；报告平台的业务验收单独判断。
报告是这条链的一个出口。
原图、人工记录和复核状态，才是能继续用于报告或训练数据的基础。本案例因此先展示完整工作流程，再用出图链路的工程记录说明其中一段交付。
责任、协作与依据
我的责任与已有基础
我在既有团队平台和行业材料的基础上推进本轮产品范围、交互与验收，借助编程 Agent 完成实现、集成和维护。报告链路还涉及既有模板与协作实现；不把整条历史代码或所有贡献归为个人从零完成。
证据与展示范围
界面截图的版本标在图注；性能数字来自带日期的验证与热修记录。不把测试记录写成客户使用规模或商业成效；不出现客户名、项目编号与内部地址。