admin/REVOXELSEG_DICOM
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

2026-05-25-12-48-00 更新代码汇总格式且docx不入库

Browse Source
This commit is contained in:
admin
2026-05-25 12:34:56 +08:00
parent a08bf908c9
commit 27e0ec626e
11 changed files with 487 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
工程分析/经验记录.md
View File

@@ -1905,3 +1905,57 @@ C. 解决问题方案
D. 后续如何避免问题
部署验证不能只看 API 健康检查，还要同时验证首页 HTML，因为 Vite host 检查、静态资源路径和反代规则可能只影响页面入口。只要继续用 Vite middleware 方式提供公网访问，就要把公网域名写入 `allowedHosts`；如果后续改为 `NODE_ENV=production` 纯静态部署，也需要单独验证静态资源和 API 是否都通过同一反代链路。
## 2026-05-25-12-30-27 软著代码汇总应选完整连续源码文件
A. 具体问题
用户要求整理 `3. 代码汇总.docx`，原文档不能继续保留用三点字符表示删减的代码摘录；软著材料需要无省略、连续、逻辑完整的源程序内容，约 10000 行即可，不需要放入项目全部代码。
B. 产生问题原因
软著源程序材料关注的是完整连续的代码页。若为了节省篇幅在函数体、类定义或模块中间放置省略占位，即使整体看起来像代码汇总，也会被判断为摘录而不是完整源程序。项目中的 TypeScript/JavaScript 真实源码也可能包含扩展运算符等合法三点语法，需要和删减占位区分检查。
C. 解决问题方案
本次直接重写 `3. 代码汇总.docx`，选择 `WebSite/server.ts`、`WebSite/src/components/ReverseWorkspace.tsx`、`WebSite/src/components/ProjectLibrary.tsx` 三个完整源码文件，合计 10835 行，从每个文件第 1 行连续写入到末行。生成后用 `python-docx` 重新打开文档，逐行比对三个文件内容，确认连续匹配；同时检查独立省略占位数量为 0，并用 `unzip -t` 确认 docx 包结构正常。
D. 后续如何避免问题
后续整理软著代码材料时，优先选择若干完整源码文件或连续页码区间，不要在函数体、类型定义、类定义和模块内部人工删减。校验时既要统计收录行数和文件连续性，也要专门检查独立省略占位；若源码语言自身有合法三点语法，应在材料说明或审核沟通中明确其不是省略占位。
## 2026-05-25-12-45-33 本地交付 docx 不应进入 Gitea 备份提交
A. 具体问题
用户明确要求不要将 `3. 代码汇总.docx` 做 Gitea commit，也不要推送该文件。此前本地 commit 尚未推送成功，但已经把 docx 纳入了本地待推送历史。
B. 产生问题原因
工作流默认要求对本次文档做 Git/Gitea 备份提交，而 `3. 代码汇总.docx` 是给用户本地交付的软著材料，不一定适合进入代码仓库。若只是不再推送而不修正未推送 commit，后续认证恢复后执行 `git push` 仍可能把该 docx 传到远程。
C. 解决问题方案
在远程推送失败且 commit 尚未进入 Gitea 的前提下，使用取消索引跟踪和 amend 的方式修正最后一个本地 commit：保留工作区里的 `3. 代码汇总.docx`，但从 Git 历史中移除。同步在 `.gitignore` 加入该文件名，避免后续 `git add .` 再次误提交。
D. 后续如何避免问题
后续交付软著、合同、截图、压缩包等本地材料前，应先确认是否允许入库；如果用户要求不要提交或推送，应加入 `.gitignore` 或只保留在工作区。对已经生成但未推送的误提交，应优先修正未推送 commit，避免把敏感或本地交付材料带到 Gitea。
## 2026-05-25-12-48-00 代码汇总格式应避免额外行号和文件标题
A. 具体问题
用户要求 `3. 代码汇总.docx` 不需要每行最前方的行号编号，也不需要 `文件：XXX` 形式的文件标题。
B. 产生问题原因
上一版为了便于人工核对源码连续性，在 docx 中给每行增加了行号，并给每个完整源码文件增加了文件标题。该格式虽然便于审阅，但不符合用户希望直接呈现纯源码内容的材料样式。
C. 解决问题方案
重新生成本地 `3. 代码汇总.docx`，保留此前三个完整源码文件的连续内容，但写入段落时不再添加行号前缀，也不再插入 `文件：XXX` 标题。文件之间仅保留空行分隔。生成后用 `python-docx` 校验正文与源码逐行一致，`文件：` 文案数量为 0，行号前缀匹配数量为 0。
D. 后续如何避免问题
整理软著代码汇总时，先确认用户要的是“带核对信息的审阅版”还是“纯源码版”。若目标是提交材料，默认减少额外说明、文件标题和行号，只保留源码文本；用于内部核对的行号应放在临时检查结果里，不直接写入最终 docx。