40 lines
2.4 KiB
Markdown
40 lines
2.4 KiB
Markdown
# 经验记录
|
|
|
|
本文件作为项目统一知识库。每次最终执行项目修改前必须阅读；每次执行完成后，如遇到关键问题或形成可复用经验，必须按以下四段式追加记录。
|
|
|
|
## 2026-05-03-18-27-21 建立项目修改工作流
|
|
|
|
A. 具体问题
|
|
|
|
项目此前缺少统一的修改前分析、人工审核、测试确认、经验沉淀、Gitea 备份和重新部署流程，后续需求容易直接进入代码修改，导致风险不可追踪。
|
|
|
|
B. 产生问题原因
|
|
|
|
仓库中已有 README 和运行说明，但没有面向后续代码编纂工作的强制流程文件，也没有统一的 `工程分析/` 知识库目录。
|
|
|
|
C. 解决问题方案
|
|
|
|
新增仓库根目录 `AGENTS.md`，明确后续项目修改需求必须记录开始时间、生成需求分析、实现方案、测试方案，并在实现方案和测试方案通过用户二次审核后再修改业务代码。新增 `工程分析/工程整体分析.md`、本经验记录，以及本次需求、实现、测试方案文档。
|
|
|
|
D. 后续如何避免问题
|
|
|
|
后续每次项目修改开始时先阅读 `AGENTS.md`、`工程分析/工程整体分析.md` 和 `工程分析/经验记录.md`，严格使用同一开始时间戳创建三类分析文档，并在用户确认实现方案和测试方案后再执行代码改动。
|
|
|
|
## 2026-05-03-22-02-15 调整硬边界与高斯平滑预览分界线
|
|
|
|
A. 具体问题
|
|
|
|
硬边界和高斯平滑预览图中的黄色分界线出现 Y 字形：一部分随头颈部形变变成斜线，另一部分仍横向延长，视觉上像多出一条不自然的横线。
|
|
|
|
B. 产生问题原因
|
|
|
|
旧逻辑先把黄色分界线画到原始 CT 预览图上，再把整张图传入 `preview_deform_2d` 做快速 2D 形变。硬边界和高斯平滑在分界附近存在不连续或快速变化的运动权重，导致同一条标注线被分裂成不同运动状态。
|
|
|
|
C. 解决问题方案
|
|
|
|
将硬边界和高斯平滑预览改为先对不含黄色线的 CT 图执行形变，再在形变结果上叠加单条黄色分界线。保留原始图的水平分界线，并尽量不改变软过渡原有视觉效果。
|
|
|
|
D. 后续如何避免问题
|
|
|
|
预览标注层、参考线、箭头等非 CT 内容应优先在形变结果上单独叠加，不要和医学影像像素一起参与形变采样。若必须参与形变，应先确认该标注能承受硬边界或快速变化权重造成的撕裂效果。
|