2026-04-18-16-45-02 - 建立代码编纂工作流规范（含需求分析、实现方案、测试方案）

工程分析/实现方案-2026-04-18-16-45-02.md

@@ -0,0 +1,83 @@
+# 实现方案 —— 2026-04-18-16-45-02
+
+## 方案目标
+建立一套标准化、可复用的代码编纂工作流，确保后续所有项目修改需求都能按统一流程执行，减少遗漏和错误。
+
+## 方案内容
+
+### 阶段一：工程分析文件夹确认（步骤 1）
+1. 检查 `.\工程分析` 文件夹是否存在。
+2. 若不存在则创建；若存在则确认其包含以下文件类型：
+   - `需求分析-*.md`
+   - `实现方案-*.md`
+   - `测试方案-*.md`
+   - `经验记录.md`
+
+### 阶段二：需求分析文档生成（步骤 2）
+每次用户提出修改需求时：
+1. 记录开始时间 `{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}`。
+2. 创建 `.\工程分析\需求分析-{时间}.md`。
+3. 文档内容包含：
+   - 需求来源
+   - 需求概述（一句话描述）
+   - 功能详细描述
+   - 涉及文件/模块清单
+   - 需求影响范围
+
+### 阶段三：实现方案文档生成与用户审核（步骤 3）
+1. 基于需求分析，编写 `.\工程分析\实现方案-{时间}.md`。
+2. 文档内容包含：
+   - 方案目标
+   - 具体实现步骤（分阶段）
+   - 涉及文件及修改点
+   - 风险与注意事项
+3. **此处为强制审核节点**：文档生成后停止执行，等待用户确认"方案无误，继续执行"。
+4. 用户确认后方可进入下一阶段。
+
+### 阶段四：测试方案文档生成与用户审核（步骤 4）
+1. 基于实现方案，编写 `.\工程分析\测试方案-{时间}.md`。
+2. 文档内容包含：
+   - 测试目标
+   - 测试用例清单（编号、操作步骤、预期结果）
+   - 回归测试范围
+3. **此处为强制审核节点**：文档生成后停止执行，等待用户确认"方案无误，继续执行"。
+4. 用户确认后方可进入下一阶段。
+
+### 阶段五：经验记录阅读与执行（步骤 5）
+1. **执行前**：读取 `.\工程分析\经验记录.md`，提取与本次修改相关的经验条目。
+2. **执行中**：按照已审核的实现方案修改代码。
+3. **执行后**：若过程中遇到新的关键问题，按四段式追加到 `.\工程分析\经验记录.md`：
+   - A. 具体问题
+   - B. 产生问题原因
+   - C. 解决问题方案
+   - D. 后续如何避免问题
+
+### 阶段六：Gitea 备份（步骤 6）
+1. 执行以下 Git 操作：
+   ```bash
+   git add .
+   git commit -m "{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec} - {简要描述}"
+   git push origin main
+   git tag -a v{版本号} -m "{版本描述}"
+   git push origin v{版本号}
+   ```
+2. 向用户汇报备份完成。
+
+### 阶段七：重新部署（步骤 7）
+1. 执行 `npm run build` 构建生产版本。
+2. 验证构建产物 `dist/` 已生成。
+3. 启动预览服务 `npm run preview`（或用户指定的部署方式）。
+
+## 工作流强制审核点
+| 审核点 | 触发条件 | 用户操作 |
+|--------|----------|----------|
+| 实现方案审核 | 实现方案文档生成完毕 | 用户阅读并回复"确认" |
+| 测试方案审核 | 测试方案文档生成完毕 | 用户阅读并回复"确认" |
+
+## 本次（建立工作流）的执行差异
+由于本次需求不涉及业务代码修改，阶段五（代码执行）、阶段六（备份）、阶段七（部署）均跳过或简化处理。重点在于将工作流规范文档化并确认用户理解。
+
+## 风险与注意事项
+1. 用户必须理解两个强制审核节点（实现方案、测试方案），不可跳过。
+2. 若用户在审核阶段提出修改意见，需重新生成对应文档并再次等待确认。
+3. 经验记录文档需持续维护，成为项目知识库的核心资产。

工程分析/测试方案-2026-04-18-16-45-02.md

@@ -0,0 +1,96 @@
+# 测试方案 —— 2026-04-18-16-45-02
+
+## 测试目标
+验证代码编纂工作流是否能够正确运行，确保后续所有项目修改需求都能按规范流程执行，无步骤遗漏。
+
+## 测试用例
+
+### TC-01：工作流文档完整性验证
+**前置条件**：用户已提出建立工作流的需求
+**操作步骤**：
+1. 检查 `.\工程分析` 文件夹是否存在
+2. 检查 `需求分析-2026-04-18-16-45-02.md` 是否生成
+3. 检查 `实现方案-2026-04-18-16-45-02.md` 是否生成
+4. 检查 `测试方案-2026-04-18-16-45-02.md` 是否生成
+5. 检查 `经验记录.md` 是否存在
+
+**预期结果**：
+- `.\工程分析` 文件夹存在
+- 需求分析、实现方案、测试方案文档均已生成，内容完整
+- `经验记录.md` 存在且格式正确
+
+---
+
+### TC-02：实现方案审核节点验证
+**前置条件**：实现方案文档已生成
+**操作步骤**：
+1. AI 展示实现方案文档内容
+2. 用户阅读文档
+3. 用户回复"确认"或提出修改意见
+
+**预期结果**：
+- AI 在实现方案生成后主动停止，等待用户输入
+- 用户未确认前，AI 不进入下一阶段
+
+---
+
+### TC-03：测试方案审核节点验证
+**前置条件**：测试方案文档已生成，且实现方案已通过用户审核
+**操作步骤**：
+1. AI 展示测试方案文档内容
+2. 用户阅读文档
+3. 用户回复"确认"或提出修改意见
+
+**预期结果**：
+- AI 在测试方案生成后主动停止，等待用户输入
+- 用户未确认前，AI 不进入下一阶段
+
+---
+
+### TC-04：经验记录读取验证
+**前置条件**：存在历史经验记录文档
+**操作步骤**：
+1. AI 读取 `.\工程分析\经验记录.md`
+2. 检查是否能正确解析四段式格式
+
+**预期结果**：
+- AI 能正确读取并理解经验记录内容
+- 执行代码修改前能引用相关经验防止重复犯错
+
+---
+
+### TC-05：Gitea 备份验证（后续真实需求执行时）
+**前置条件**：代码修改已完成
+**操作步骤**：
+1. AI 执行 `git add .`
+2. AI 执行 `git commit -m "{时间戳} - {描述}"`
+3. AI 执行 `git push origin main`
+4. AI 执行 `git tag` 并推送
+
+**预期结果**：
+- Commit 成功推送到远程 main 分支
+- 标签成功推送到远程
+- AI 向用户汇报备份完成
+
+---
+
+### TC-06：重新部署验证（后续真实需求执行时）
+**前置条件**：代码修改已提交
+**操作步骤**：
+1. AI 执行 `npm run build`
+2. 检查 `dist/` 目录是否存在且包含构建产物
+3. AI 执行 `npm run preview` 或等效部署命令
+
+**预期结果**：
+- 构建成功，无报错
+- `dist/` 目录包含 `index.html` 和 `assets/`
+- 预览服务正常运行
+
+---
+
+## 回归测试范围
+- 无业务代码变更，不涉及回归测试
+- 需确认 `.\工程分析` 目录下的新文档不会影响项目构建（即 `.gitignore` 或构建配置不会误处理 `.md` 文件）
+
+## 测试结论
+本次测试的核心是验证"工作流机制本身是否成立"。由于不涉及业务代码修改，TC-05 和 TC-06 将在后续真实需求中实际执行并验证。

工程分析/需求分析-2026-04-18-16-45-02.md

@@ -0,0 +1,55 @@
+# 需求分析 —— 2026-04-18-16-45-02
+
+## 需求来源
+用户明确要求建立一套标准化的代码编纂工作流，用于规范后续所有项目修改需求的处理流程。
+
+## 需求概述
+新建一个完整的代码编纂工作流。后续用户提出的任何项目修改相关需求，都必须严格按照该工作流执行。
+
+## 工作流步骤定义
+
+### 0. 时间记录
+每次执行前，记录问题开始的时间，格式为 `{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}`。
+
+### 1. 工程分析文件夹
+阅读或创建 `.\工程分析` 文件夹，用于存放对整个工程的整体分析文档。
+
+### 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. Gitea 备份
+最终执行完成后，使用 Gitea 对文档进行备份。Commit 信息需包含：
+- `{Year}-{Mon}-{Day}-{Hour}-{Min}-{Sec}` 时间戳
+- 对本次修改的简要描述
+完成后提醒用户已完成文档备份。
+
+### 7. 重新部署
+最终执行完成后，重新执行 `npm` 部署本项目。
+
+## 本次需求的特殊性
+本次需求本身即为"建立工作流规范"，不涉及具体业务代码的增删改。因此实现内容主要是：
+1. 确认 `.\工程分析` 目录结构已就绪
+2. 将工作流规范固化为可重复执行的流程文档
+3. 确保用户理解每个步骤的审核节点
+
+## 需求影响范围
+- 工程分析文档体系
+- 后续所有项目修改需求的执行方式
+- Gitea 备份流程
+- 无业务代码变更