2026-05-04-02-38-48 建立代码编纂工作流文档

工程分析/代码编纂工作流.md

@@ -0,0 +1,96 @@
+# 代码编纂工作流
+
+本工作流适用于后续所有项目修改相关需求。除非用户明确说明跳过流程，否则每次修改都按以下步骤执行。
+
+## 0. 记录开始时间
+
+- 每次执行前先记录问题开始时间，格式为 `{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}`。
+- 本时间戳用于贯穿需求分析、实现方案、测试方案、经验记录和 Git 提交信息。
+
+## 1. 阅读工程分析
+
+- 每次修改前阅读或创建 `工程分析/` 文件夹。
+- 优先阅读：
+  - `工程分析/工程整体分析.md`
+  - `工程分析/经验记录.md`
+  - 与当前需求相关的历史 `需求分析-*`、`实现方案-*`、`测试方案-*` 文档
+
+## 2. 写入需求分析
+
+- 将用户当次需求整理写入：
+  - `工程分析/需求分析-{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}.md`
+- 内容至少包括：
+  - 原始需求摘要
+  - 业务目标
+  - 输入与输出
+  - 影响范围
+  - 风险点
+  - 待确认问题
+
+## 3. 写入实现方案并等待人工审核
+
+- 将实现方案写入：
+  - `工程分析/实现方案-{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}.md`
+- 文档必须包含：
+  - 修改目标
+  - 涉及路径
+  - 技术路线
+  - 数据流或交互流程
+  - 兼容性与回滚方案
+  - 预计文件变更
+  - 人工审核状态
+- 实现方案写完后必须等待用户二次人工审核确认。
+- 未收到明确确认前，不执行项目业务代码修改。
+
+## 4. 写入测试方案并等待人工审核
+
+- 将测试方案写入：
+  - `工程分析/测试方案-{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}.md`
+- 文档必须包含：
+  - 静态检查
+  - 单元或集成测试
+  - 关键业务场景验证
+  - 医学影像数据相关边界验证
+  - 回归风险
+  - 人工审核状态
+- 测试方案写完后必须等待用户二次人工审核确认。
+- 未收到明确确认前，不执行最终修改方案。
+
+## 5. 执行前后维护经验记录
+
+- 最终执行整个修改方案前，必须阅读：
+  - `工程分析/经验记录.md`
+- 修改完成后，将关键问题与解决方案追加到 `工程分析/经验记录.md`。
+- 每条经验使用四段式结构：
+  - A. 具体问题
+  - B. 产生问题原因
+  - C. 解决问题方案
+  - D. 后续如何避免问题
+
+## 6. 文档备份提交
+
+- 最终执行后，使用 Git/Gitea 对文档进行备份提交。
+- Commit message 必须同时包含：
+  - `{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}` 时间戳
+  - 本次修改简要描述
+- 备份完成后提醒用户：文档备份 commit 已完成。
+- 默认远程仓库：
+  - `http://192.168.31.5:5002/admin/REVOXELSEG_DICOM.git`
+
+## 7. 重新部署
+
+- 最终修改完成并通过测试后，重新部署本项目。
+- 若项目只有前端开发环境，默认使用 `WebSite/` 下的脚本：
+  - `npm run build`
+  - `npm run dev`
+- 若已有服务进程或部署脚本，优先沿用现有部署方式。
+
+## 人工确认口令
+
+后续当我完成实现方案和测试方案文档后，需要用户明确回复类似以下内容才继续：
+
+- `确认实现方案`
+- `确认测试方案`
+- `确认执行`
+
+如果用户对方案提出修改意见，则先更新对应文档，再等待新的确认。