2026-05-24-10-09-37 精简工程分析文档

工程分析/经验记录.md

@@ -1639,3 +1639,21 @@ C. 解决问题方案
 D. 后续如何避免问题
 
 清理发布辅助分支前必须先确认对应 Release、tag 和附件均可读，再删除分支而不是删除 tag 或 Release。通过公网域名部署 `npm run serve` 时应使用 `NODE_ENV=production`，否则 Vite 开发中间件可能拦截公网 Host。公网域名验证要同时检查 Web 服务、frpc 登录与代理成功日志、`/api/health`、首页 HTML 和关键业务 API，避免只看本机 4000 端口。
+
+## 2026-05-24-10-09-37 工程分析目录需要长期精简
+
+A. 具体问题
+
+`工程分析/` 中历史 `需求分析-*`、`实现方案-*`、`测试方案-*` 三件套数量过多，后续继续修改程序时，查找真正需要先读的核心约束和长期经验成本变高；部分早期历史文档此前已处于删除状态，也容易在提交时反复干扰状态判断。
+
+B. 产生问题原因
+
+原工作流要求每次修改前创建三件套，但没有规定历史三件套的保留周期。随着需求持续迭代，一次性分析文件不断堆积；真正长期有价值的内容实际已经沉淀在 `工程整体分析.md` 和 `经验记录.md` 中，历史三件套更多用于当次可追溯，适合交给 Git 历史保存。
+
+C. 解决问题方案
+
+保留 `代码编纂工作流.md`、`工程整体分析.md`、`经验记录.md` 和本次 `2026-05-24-10-09-37` 三件套，删除历史三件套与一次性 `系统功能描述-*` 文档。同步更新 `代码编纂工作流.md`，新增工程分析目录精简策略：后续仍必须创建当次三件套，但历史三件套不再默认长期堆积，可通过 Git 历史追溯；长期坑点必须追加进 `经验记录.md`。
+
+D. 后续如何避免问题
+
+后续做程序修改时优先阅读核心三文档和当次三件套，不要在目录中长期堆积几十个历史流水文件。若某次需求产生可复用经验，应写入 `经验记录.md`；若只是一时执行细节，则交由 Git commit 历史保存。文档治理提交前必须确认没有混入源码、医学数据或运行态文件。