3.8 KiB
3.8 KiB
代码编纂工作流
更新时间：2026-05-19-22-59-07
本工作流适用于后续所有项目修改相关需求。只要用户提出的是项目修改、修复、重构、部署、文档治理或功能调整，都必须按本流程走；除非用户明确要求跳过其中某一步。
0. 记录开始时间
- 每次执行前先记录问题开始时间，格式为
{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}。 - 时间以当前执行环境为准。
- 同一个时间戳贯穿当次需求分析、实现方案、测试方案、经验记录、commit message 和最终汇报。
1. 阅读或创建工程分析目录
- 每次修改前确认
工程分析/存在，不存在则创建。 - 优先阅读：
工程分析/代码编纂工作流.md工程分析/工程整体分析.md工程分析/经验记录.md- 与当前需求相关的历史
需求分析-*、实现方案-*、测试方案-*
- 如果发现
工程分析/文档在工作区被删除，应先说明风险，只恢复或重建当次必要的核心文档，不把无关删除混入提交。
2. 写入需求分析
- 将用户当次需求整理写入：
工程分析/需求分析-{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}.md
- 文档至少包含：
- 开始时间
- 原始需求摘要
- 业务目标
- 输入与输出
- 影响范围
- 关键约束
- 风险点
- 待确认问题或默认假设
3. 写入实现方案
- 将实现方案写入：
工程分析/实现方案-{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}.md
- 文档至少包含：
- 实现方案文档路径
- 修改目标
- 涉及路径
- 技术路线
- 执行步骤
- 兼容性与回滚方案
- 预计文件变更
- 提交与部署策略
- 2026-05-07-16-35-52 起，用户已确认“都确认，后续直接搞”。因此默认不在实现方案阶段暂停等待二次确认；若用户明确要求人工审核，则必须等待确认后再执行。
4. 写入测试方案
- 将测试方案写入：
工程分析/测试方案-{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}.md
- 文档至少包含：
- 测试方案文档路径
- 静态检查
- 构建检查
- 关键业务场景验证
- 医学影像数据相关边界验证
- 部署验证
- Git/Gitea 备份验证
- 风险与回归关注点
- 默认不在测试方案阶段暂停等待二次确认；若用户明确要求人工审核，则必须等待确认后再执行。
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. 重新部署
- 最终修改完成并通过测试后，重新部署本项目。
- 优先使用当前项目约定：
cd WebSitenpm run buildtmux会话revoxelseg-dicomnpm run serve -- --host 0.0.0.0 --port 4000
- 若端口或会话冲突，先检查并记录实际处理方式。
- 部署后至少验证：
http://127.0.0.1:4000/api/healthhttp://127.0.0.1:4000/
8. 最终汇报
- 汇报本次开始时间、修改文件、测试结果、部署地址和 commit 状态。
- 如果某一步无法完成，必须说明原因、影响范围和建议下一步。