2026-05-21-10-05-51 更新软著材料工程记录

This commit is contained in:
2026-05-21 10:28:40 +08:00
parent d7eeedd9b3
commit e4a403f015
4 changed files with 186 additions and 0 deletions

View File

@@ -0,0 +1,57 @@
# 实现方案-2026-05-21-10-05-51
实现方案文档路径:`工程分析/实现方案-2026-05-21-10-05-51.md`
## 修改目标
- 根据当前系统功能更新软著说明书、登记表、代码汇总与素材清单。
- 重新拍摄说明书章节图片,确保每个主要功能说明有对应真实界面图。
- 重新生成可编辑 Word 文档。
- 完成文档引用、图片存在性、Word 文件有效性和服务验证。
## 涉及路径
- `新撰写软著文档/1. 软著说明书.md`
- `新撰写软著文档/2. 软著登记表.md`
- `新撰写软著文档/3. 代码汇总.md`
- `新撰写软著文档/images/`
- `新撰写软著文档/功能验证与素材清单.md`
- `新撰写软著文档/*.docx`
- `工程分析/经验记录.md`
## 技术路线
1. 学习 `※撰写Agent.md` 与参考模板要求。
2. 读取现有软著说明书、登记表、代码汇总和素材清单,找出与当前功能不一致之处。
3. 使用当前运行系统重新拍摄登录、概况、项目库、导入、三维模型、逆向分割结果、逆向工作区、导出、系统管理等图片。
4. 重写或增补说明书章节,保证功能说明更细化、图片引用更新且无重复引用。
5. 更新登记表中的功能概述、技术特点、运行环境和源程序量。
6. 更新代码汇总,确保核心代码摘抄覆盖当前导入、导出、分割映射、用户管理和位姿逻辑。
7. 生成 docx并校验图片引用、docx 压缩包结构与行数。
## 执行步骤
- 检查当前服务状态并确认可访问。
- 准备或更新截图自动化脚本,输出到 `新撰写软著文档/images/`
- 更新 Markdown 正文和素材清单。
- 使用 Pandoc 或 `python-docx` 生成 Word。
- 校验所有图片引用存在、说明书每个章节都有图片、代码汇总行数满足要求。
- 按工作流追加经验记录、提交工程分析文档并重新部署验证。
## 兼容性与回滚方案
- 本次不修改系统业务代码,回滚时只需恢复 `新撰写软著文档/` 的文档和图片。
- 软著材料不入 Gitea避免影响项目代码版本。
- 若自动截图失败,可保留已有图片并记录失败原因,但优先重拍成功截图。
## 预计文件变更
- 更新 `新撰写软著文档/` 下 Markdown、Word、图片和素材清单。
- 新增当次工程分析三件套。
- 追加 `工程分析/经验记录.md`
## 提交与部署策略
- Gitea 提交只包含本次工程分析记录,不包含软著材料。
- Commit message 包含 `2026-05-21-10-05-51` 与简要描述。
- 按工作流重新部署并验证服务。

View File

@@ -0,0 +1,57 @@
# 测试方案-2026-05-21-10-05-51
测试方案文档路径:`工程分析/测试方案-2026-05-21-10-05-51.md`
## 静态检查
- 检查 Markdown 图片引用是否全部存在。
- 检查说明书是否保留面向用户的操作语言,避免接口、组件、状态字段等开发黑话。
## 构建检查
- 本次不修改业务代码,但仍按工作流执行 `cd WebSite && npm run build`
- 校验 `.docx` 文件可作为 zip 打开。
## 关键业务场景验证
- 登录页截图。
- 总体概况截图。
- 项目库 DICOM 影像、3D 模型、逆向分割结果截图。
- 项目导入和导出项目及结果相关说明。
- 逆向工作区三维融合视图、可视化工具栏、逆向分割映射视图、保存至项目库截图。
- 系统管理、用户编辑、密码修改、演示环境恢复等说明。
## 医学影像数据相关边界验证
- 文档中说明 DICOM、STL、NIfTI、位姿 JSON、labels JSON 等格式用途。
- 不在说明书中写入真实患者敏感信息。
- 截图避免错误状态、半加载状态或遮挡严重界面。
## 部署验证
- `http://127.0.0.1:4000/api/health`
- `http://127.0.0.1:4000/`
## Git/Gitea 备份验证
- 只提交工程分析三件套和经验记录。
- 不提交 `新撰写软著文档/`、截图、视频、压缩包和软著 Word。
## 风险与回归关注点
- 软著说明书图片要与当前界面一致,不能继续引用旧 UI。
- Word 文档必须嵌入图片并保持可编辑。
- 代码汇总至少保持用户此前要求的 1600 行以上。
## 实际验证记录
- Markdown 图片引用检查:说明书 23 个章节、23 个图片引用,缺失图片 0 个。
- 图片尺寸检查23 张 `chapter-*.png` 均为 1680x1050且均为非空截图。
- Word 校验:
- `1. 软著说明书.docx` 可解压,包含 23 张嵌入图片。
- `2. 软著登记表.docx` 可解压,包含 5 个可编辑表格。
- `3. 代码汇总.docx` 可解压,代码文本可编辑。
- 代码汇总行数:`3. 代码汇总.md` 为 10839 行,满足至少 1600 行要求。
- 系统使用视频:`系统使用视频.mp4` 为 H.2641280x800时长约 46 秒。
- `npm run lint`:通过。
- `npm run build`:通过,仅保留既有 Vite 大 chunk 提示。

View File

@@ -1477,3 +1477,21 @@ C. 解决问题方案
D. 后续如何避免问题
凡是涉及 STL 与 DICOM 尺度自动匹配的逻辑,都必须明确使用“全局包围盒”还是“可见构件包围盒”,并与实际渲染组件保持一致。单轴等比例贴合要考虑其他轴的视场约束,短轴贴合不能无限放大长轴;位姿数值控件的步长、显示精度、内部取整和导出数据要同步设计,避免 UI 看起来精细但实际状态漂移。
## 2026-05-21-10-05-51 软著材料更新要同步源码、截图、Word 与素材清单
A. 具体问题
用户要求继续更新 `新撰写软著文档/` 中的所有软著材料,并重新拍摄说明书图片。此前说明书、登记表、代码汇总和视频素材已经存在,但最新功能变更包括自动拉伸 DICOM 体范围约束、缩放三位小数、0.005 级微调等内容,若只更新文字或只更新截图,软著材料会与当前系统不一致。
B. 产生问题原因
软著材料由 Markdown、Word、图片、视频、代码汇总和素材清单组成属于多文件联动交付。截图需要真实页面状态代码汇总需要从当前源码重新生成Word 又依赖 Markdown 和图片引用任何一个环节未同步都会出现说明书图片旧、代码摘录旧、Word 未嵌图或素材清单时间不一致的问题。
C. 解决问题方案
`※撰写Agent.md` 流程复查说明书、登记表、代码汇总和素材清单。使用 Chrome Headless + SwiftShader + DevTools 视口强制 1680x1050 重拍 23 张章节截图,避免 WebGL 截图为空。说明书补充自动拉伸、DICOM 体范围约束、三位小数缩放和 0.005 微调说明;登记表同步最新功能;代码汇总从当前核心源码重新生成;视频用最新章节截图重新生成 MP4再用图片引用检查、docx 解压、Word 图片数量、代码行数、视频参数和项目构建做验证。
D. 后续如何避免问题
后续只要系统功能发生变化并要求更新软著材料,应同时更新 Markdown 正文、截图、Word、代码汇总、视频脚本和素材清单不能只改其中一项。截图自动化必须固定视口并校验图片尺寸、非空像素和引用数量代码汇总应从当前源码机械生成或明确摘录范围软著目录按用户要求不提交 Gitea只提交工程分析记录。

View File

@@ -0,0 +1,54 @@
# 需求分析-2026-05-21-10-05-51
开始时间2026-05-21-10-05-51
## 原始需求摘要
用户要求继续更新 `新撰写软著文档/` 中的所有材料,细致同步当前系统功能,并重新拍摄或更新软著说明书中引用的界面图片。
## 业务目标
- 让软著说明书反映当前系统最新功能,包括项目库导入、压缩包上传、逆向分割结果、导出项目及结果、三维融合、模型位姿、自动拉伸、分割映射、系统管理等。
- 重新拍摄说明书图片,避免旧截图和当前界面不一致。
- 同步更新登记表、代码汇总、功能验证与素材清单,并生成可编辑 Word 文档。
- 遵守此前约束:软著撰写相关材料不纳入 Gitea只在本地 `新撰写软著文档/` 更新。
## 输入与输出
- 输入:
- 当前项目源码与运行中的系统界面。
- `参考软著构建模板/``※撰写Agent.md`
- 已有 `新撰写软著文档/` 内容和图片。
- 输出:
- 更新后的 `1. 软著说明书.md/.docx`
- 更新后的 `2. 软著登记表.md/.docx`
- 更新后的 `3. 代码汇总.md/.docx`
- 更新后的说明书截图和素材清单。
## 影响范围
- `新撰写软著文档/`
- `工程分析/需求分析-2026-05-21-10-05-51.md`
- `工程分析/实现方案-2026-05-21-10-05-51.md`
- `工程分析/测试方案-2026-05-21-10-05-51.md`
- `工程分析/经验记录.md`
## 关键约束
- 不修改业务代码。
- 软著材料本身不提交到 Gitea。
- 截图必须来自当前运行界面,不能使用错误态、半加载态或严重遮挡画面。
- 说明书面向用户与审查人员,避免开发黑话。
- 代码汇总保持可编辑文本,并覆盖当前核心代码。
## 风险点
- Headless 截图可能因 WebGL 限制、加载慢或会话未登录导致图片为空或停留在登录页。
- Word 转换若缺少 Pandoc需要使用 `python-docx` 或其他方式生成。
- 软著目录较大,必须避免误提交。
## 默认假设
- 当前本机服务 `http://127.0.0.1:4000/` 可用于拍摄。
- 软著材料字段中未确认的著作权人、联系人等继续保留“待确认”。
- 本次只提交工程分析记录,不提交 `新撰写软著文档/`