diff --git a/docs/测试开发标准流程.md b/docs/测试开发标准流程.md
deleted file mode 100644
index 42904012..00000000
--- a/docs/测试开发标准流程.md
+++ /dev/null
@@ -1,244 +0,0 @@
-# 嵌入式测试开发标准流程（基于 STM32F4 + CH395F 经验）
-
-> 适用范围：STM32 裸机/FreeRTOS 项目，Keil MDK-ARM v5 (ARMCC)，串口日志输出测试结果。
-
----
-
-## 1. 测试规划（文档先行）
-
-在 `docs/` 下创建测试规范文档，定义以下结构：
-
-### 1.1 阶段概览表
-
-| 阶段 ID | 类型 | 耗时 | 入口 | 出口 |
-|---------|------|------|------|------|
-| TM-PHY-01 | 独立运行 | ~1s | 宏启用 | 串口汇总 |
-
-### 1.2 每个测试用例
-
-| 字段 | 说明 |
-|------|------|
-| **ID** | `TC-NET-NNN`，唯一编号 |
-| **优先级** | P0（核心）/ P1（重要） |
-| **类型** | 功能测试 / 边界测试 / 负向测试 / 压力测试 / 恢复测试 |
-| **标题** | 一句话描述 |
-| **前置条件** | 硬件状态、PC 端命令、依赖的其他用例 |
-| **测试步骤** | 编号操作序列 |
-| **成功标准** | 精确到"返回值 == 0x00"、"延迟 >= 60000ms" |
-| **失败标准** | 每种失败对应的现象 |
-| **覆盖原则** | 对应哪个设计原则 |
-
-关键原则：**先写判定标准，再写测试代码**，避免"测了但不知道算不算过"。
-
----
-
-## 2. 测试框架搭建
-
-### 2.1 目录结构
-
-```
-test/
-  ch395f_test.h           # 宏定义 + TEST_CHECK/TEST_REPORT + test_stats_t
-  ch395f_test_task.h      # 仅导出 StartCh395fTestTask
-  ch395f_test_task.c      # 全 Phase 实现
-```
-
-### 2.2 模板文件
-
-#### `ch395f_test.h` — 宏+类型
-
-```c
-// 阶段使能开关（取消注释即启用）
-#define ENABLE_PHASE1_TESTS
-
-// 测试统计
-typedef struct {
-    uint16_t total;
-    uint16_t passed;
-    uint16_t failed;
-} test_stats_t;
-
-extern test_stats_t g_test_stats;
-
-#define TEST_CHECK(cond, fmt, ...) do { \
-    g_test_stats.total++; \
-    if (cond) { \
-        g_test_stats.passed++; \
-        DBG_INFO("[PASS] " fmt, ##__VA_ARGS__); \
-    } else { \
-        g_test_stats.failed++; \
-        DBG_ERROR("[FAIL] " fmt, ##__VA_ARGS__); \
-    } \
-} while (0)
-
-#define TEST_REPORT(name) do { \
-    DBG_INFO("=== %s: %d/%d PASSED (failed=%d) ===", \
-             name, g_test_stats.passed, g_test_stats.total, g_test_stats.failed); \
-} while (0)
-```
-
-#### `ch395f_test_task.c` — 每个 Phase 的模板
-
-```c
-#ifdef ENABLE_PHASEX_TESTS
-/*
- * Phase X — 功能说明
- *
- * 测试目的：（概括）
- * 前置条件：（硬件/软件/PC 端）
- * 通过：（整体判定条件）
- * 失败：（整体判定条件）
- */
-static void phaseX_run(void) {
-    DBG_INFO("=== CH395F Phase X Tests ===");
-
-    /* ---- TC-NET-NNN: 用例标题 ---- */
-    {
-        // 原理说明
-        // 通过：精确条件
-        // 失败：精确条件
-        ret = some_api();
-        DBG_INFO("          expect: ...");
-        DBG_INFO("          actual: ...");
-        TEST_CHECK(ret == EXPECTED, "description");
-    }
-
-    TEST_REPORT("Phase X");
-}
-#endif
-```
-
----
-
-## 3. 编码规范
-
-### 3.1 DBG_INFO 三行输出
-
-每个判定点输出三行，一眼看出"期望什么、拿了什么、过没过"：
-
-```
-  [P1-01] ch395f_check_exist()
-          expect: 0x00 (~0x57 = 0xA8)
-          actual: 0x00
-  [PASS] P1-01 check_exist = 0x00 (expect 0x00)
-```
-
-### 3.2 硬编码值加注释
-
-```c
-// 好：
-ch395f_status_t ret = ch395f_check_exist();
-// SPI 写入 0x06 (CMD_CHECK_EXIST) + 0x57 (测试字节)
-// 成功：回复 == ~0x57 == 0xA8（CH395F_ERR_SUCCESS = 0x00）
-// 失败：回复 != 0xA8（CH395F_STATUS_NOT_DETECTED = 0xFF）
-
-// 不好：
-ch395f_status_t ret = ch395f_check_exist();
-TEST_CHECK(ret == 0, "check_exist OK");
-```
-
-### 3.3 无中文字符串
-
-ARMCC v5 不识别 UTF-8 多字节字符。`DBG_INFO`/`DBG_ERROR` 中只写 ASCII。注释可以写中文。
-
-### 3.4 栈安全
-
-大缓冲区（如 64KB）用 `static` 全局，不放任务栈：
-
-```c
-#define TEST_BUF_SIZE       65536
-static uint8_t s_rx_buf[TEST_BUF_SIZE];
-```
-
-### 3.5 条件编译消除未使用变量警告
-
-```c
-static uint8_t s_rx_buf[TEST_BUF_SIZE];
-#if defined(ENABLE_PHASE5_TESTS) || defined(ENABLE_PHASE8_TESTS)
-static uint8_t s_tx_buf[TEST_BUF_SIZE];
-#endif
-```
-
----
-
-## 4. 统一入口
-
-### 4.1 所有测试在 FreeRTOS 任务中串行执行
-
-```
-ch395fTestTask:
-  1. 等待 SYS_EVT_NET_READY（netTask 初始化完成，通过 Event Flags 广播）
-  2. 阻塞执行 Phase 1/2/3/6/9（内部循环，无需外部连接）
-  3. 创建 TCP 监听 Socket（端口 8080，单连接模式）
-  4. 事件驱动循环 Phase 4/5/7/8/10（等待 PC 连接）
-```
-
-### 4.2 不要在 main.c 中直接调用测试
-
-main.c 只做硬件初始化和启动 OS，不包含任何测试逻辑。
-
-### 4.3 测试文件的手动注册
-
-新测试文件需：
-1. 添加到 `test/` 目录
-2. 修改 `MDK-ARM/STM32F407-Demo.uvprojx` 添加文件引用和 IncludePath
-
----
-
-## 5. 文档与代码同步
-
-- 文档中的入口函数名、宏名、流程描述必须与代码一致
-- 代码变更后立即更新文档，否则文档两天内就会失效
-- 测试用例的通过/失败标准在**文档和代码注释中都写清楚**
-- 文档使用标准 Markdown 表格，避免复杂嵌套导致渲染异常
-
----
-
-## 6. 编译验证
-
-### 6.1 底线
-
-**`0 Error(s), 0 Warning(s)`**，不可妥协。
-
-### 6.2 常见警告处理
-
-| 警告 | 原因 | 解决 |
-|------|------|------|
-| `#177-D: variable was declared but never referenced` | 条件编译导致 | 加 `#ifdef` 包裹变量声明 |
-| `#870-D: invalid multibyte character sequence` | DBG_INFO 中有中文 | 改为纯 ASCII |
-| 隐式类型转换 | 参数类型不匹配 | 加显式 `(uint8_t)` 等 cast |
-
-### 6.3 构建命令
-
-```bat
-MDK-ARM\build.bat
-:: 或项目根目录执行 @build
-```
-
-退出码：0 = 成功 | 1 = 有警告（不通过）| 2+ = 错误
-
----
-
-## 7. 迭代节奏
-
-```
-文档（规划 + 判定标准）
-  → 代码（添加 Phase 实现）
-  → @build（0 Error(s), 0 Warning(s)）
-  → 烧录验证（串口观察 PASS/FAIL）
-  → 根据实际结果修正判定标准
-  → 更新文档（保持同步）
-  → 下一阶段
-```
-
----
-
-## 附录：本项目的测试文件清单
-
-| 文件 | 作用 |
-|------|------|
-| `test/ch395f_test.h` | 测试宏、类型定义、Phase 使能开关 |
-| `test/ch395f_test_task.h` | 导出 `StartCh395fTestTask` |
-| `test/ch395f_test_task.c` | 全 10 个 Phase 实现 |
-| `docs/CH395F_Test_Guide.md` | 测试规范、用例表格、通过/失败标准 |
-| `docs/CH395F_Trap_Records.md` | 已知硬件/软件陷阱及修复 |
diff --git a/docs/测试文档模板规范.md b/docs/测试文档模板规范.md
deleted file mode 100644
index 86bc33a8..00000000
--- a/docs/测试文档模板规范.md
+++ /dev/null
@@ -1,221 +0,0 @@
-# 测试文档模板规范
-
-本文档定义本项目中测试文档的统一模板和编写规范，确保各模块（CH395F、GD5F2GQ5UE、TPAFE5160 等）的测试文档格式一致、可追溯。
-
----
-
-## 1. 文档结构
-
-每份测试文档包含以下章节：
-
-```
-# [模块名] 测试规范
-
-## 1. 概述
-- 测试范围
-- 设计原则覆盖表（DP-xx → 描述 → 验证用例）
-- 测试环境（拓扑、工具链、硬件版本）
-- 启用测试的方法
-
-## 2~N. 阶段 x：[阶段名]
-- 阶段元信息表：阶段 ID、类型、耗时、入口、出口
-- TC-NET-xxx: 测试用例（完整表格）
-
-## N+1. 脚本参考（如有 PC 端工具）
-## N+2. 已知陷阱与故障模式（引用 Traps 文档）
-## 附录 A：通过/失败汇总矩阵
-## 附录 B：测试覆盖 vs 设计原则
-```
-
----
-
-## 2. 阶段元信息表
-
-每个阶段以表格开头，描述阶段的整体属性：
-
-| 字段名 | 填写说明 |
-|--------|----------|
-| **阶段 ID** | `TM-模块缩写-两位数序号`，如 TM-PHY-01、TM-NAND-01 |
-| **类型** | 独立运行 / 需 PC 配合 / 需物理操作 / 在 xxTask 中运行 |
-| **耗时** | 预估执行时间 |
-| **入口** | 代码入口函数或宏定义 |
-| **出口** | 阶段结束标志（如串口输出内容） |
-
----
-
-## 3. 测试用例表格模板
-
-每个测试用例使用统一表格格式：
-
-```
-### TC-模块缩写-序号: 用例标题
-
-| 字段 | 值 |
-|------|-----|
-| **ID** | TC-XXX-NNN（全局唯一） |
-| **优先级** | P0 / P1 |
-| **类型** | 见下文 3.1 |
-| **标题** | 一句话描述测试什么 |
-| **前置条件** | 测试执行前必须满足的条件（编号列表） |
-| **测试步骤** | 操作步骤（编号列表，动作具体到 API 或操作） |
-| **预期结果** | 系统应表现的行为 |
-| **通过标准** | 可量化的判定条件 |
-| **覆盖原则** | DP-xx（可选，关联设计原则） |
-```
-
-### 3.1 类型枚举
-
-| 类型 | 说明 | 适用场景 |
-|------|------|----------|
-| 功能测试 | 验证某项功能是否符合预期 | 正常的收发、初始化、配置等 |
-| 负向测试 | 验证系统对非法/异常输入的处理 | 超时、断开、无效参数等 |
-| 边界测试 | 验证系统在边界条件的表现 | 最大包长、最小超时、满队列等 |
-| 压力测试 | 验证系统在高负载下的稳定性 | 多客户端、高频请求、长时运行等 |
-| 恢复测试 | 验证系统从故障中恢复的能力 | 断线重连、PHY 重连、复位恢复等 |
-| 合规测试 | 验证实现是否符合特定约束 | 中断处理位置、等待顺序、字节序等 |
-| 稳定性测试 | 验证系统长时间运行的可靠性 | 长时间压力、反复循环等 |
-
-### 3.2 优先级定义
-
-| 优先级 | 定义 |
-|--------|------|
-| **P0** | 核心功能，必须通过。阻塞后续测试或影响系统基本可用性 |
-| **P1** | 重要功能，建议通过。失败表明潜在缺陷但不阻塞基本功能 |
-
----
-
-## 4. 命名规则
-
-### 4.1 阶段 ID
-
-```
-TM-{MOD}-{NN}
-```
-
-- `TM` — Test Module
-- `{MOD}` — 模块缩写（大写）
-  - `PHY` — CH395F 网络
-  - `NAND` — GD5F2GQ5UE NAND Flash
-  - `ADC` — TPAFE5160 ADC
-  - `RTC` — SD2506 RTC
-  - `RS485` — RS-485 通信
-- `{NN}` — 两位序号，从 01 开始
-
-示例：`TM-PHY-01`, `TM-NAND-03`
-
-### 4.2 测试用例 ID
-
-```
-TC-{MOD}-{NNN}
-```
-
-- `TC` — Test Case
-- `{MOD}` — 模块缩写（同上）
-- `{NNN}` — 三位序号，从 001 开始
-
-示例：`TC-PHY-101`, `TC-NAND-201`
-
-### 4.3 设计原则 ID
-
-```
-DP-{NN}
-```
-
-- `DP` — Design Principle
-- `{NN}` — 两位序号，从 01 开始
-
-示例：`DP-01`, `DP-02`
-
----
-
-## 5. 编写规范
-
-### 5.1 表格格式
-
-- 使用 GFM (GitHub Flavored Markdown) 表格
-- 首列为字段名，加粗（`**字段**`）
-- 第二列为值，左对齐
-- 多行内容使用 `<br>` 换行（保持表格可读性）
-
-### 5.2 测试步骤与前置条件
-
-- 使用有序列表（`1. 2. 3.`）
-- 每个步骤是一个完整的可执行动作
-- 包含具体 API 名或操作名（如 `net_recv()`、`ch395f_open_socket()`）
-- 前置条件写明硬件状态、PC 端命令、代码配置等
-
-### 5.3 语言
-
-- 中文书写（技术标识保留英文）
-- 保持客观、精确、可验证
-- 避免模糊表述（如 "应该能正常工作" → "回显内容与发送完全一致"）
-
-### 5.4 通过标准
-
-- 必须可量化验证
-- 好的示例：`70/70 成功率（100%）`、`串口显示 "PHY_CHANGE: 0x01"`、`10/10 回显匹配`
-- 差的示例：`功能正常`、`系统稳定`
-
-### 5.5 引用
-
-- 引用函数、宏、文件名使用反引号（`` `net_poll()` ``）
-- 引用其他文档使用相对路径：`docs/CH395F_Trap_Records.md`
-
----
-
-## 6. 快速参考
-
-### 6.1 新模块测试文档模板
-
-```markdown
-# [模块名] 测试规范
-
-## 1. 概述
-
-### 设计原则覆盖
-
-| 原则 | 描述 | 验证用例 |
-|------|------|----------|
-| DP-01 | ... | TC-XXX-xxx |
-
-### 测试环境
-
-```
-[硬件拓扑]
-```
-
-## 2. 阶段 1：[阶段名]
-
-| 阶段 ID | TM-XXX-01 |
-|---------|------------|
-| **类型** | ... |
-| **耗时** | ... |
-| **入口** | ... |
-
-### TC-XXX-001: 用例标题
-
-| 字段 | 值 |
-|------|-----|
-| **ID** | TC-XXX-001 |
-| **优先级** | P0 |
-| **类型** | 功能测试 |
-| **标题** | ... |
-| **前置条件** | 1. ...<br>2. ... |
-| **测试步骤** | 1. ... |
-| **预期结果** | ... |
-| **通过标准** | ... |
-```
-
-### 6.2 附录模板
-
-```markdown
-## 附录 A：通过/失败汇总矩阵
-
-| 阶段 | TC ID | 优先级 | 类型 | 状态 |
-|------|-------|--------|------|------|
-
-## 附录 B：测试覆盖 vs 设计原则
-
-| 原则 | 覆盖用例 |
-|------|----------|
-```
diff --git a/docs/测试说明/测试开发标准流程.md b/docs/测试说明/测试开发标准流程.md
new file mode 100644
index 00000000..b656c1bd
--- /dev/null
+++ b/docs/测试说明/测试开发标准流程.md
@@ -0,0 +1,361 @@
+# 测试开发标准流程（STM32F4-Base）
+
+> **定位**：本项目测试开发的总流程，覆盖"规划 → 板端套件 → 主机侧工具 → 验证门禁 → 提交沉淀"全链路，并给出未来测试设计的约束。
+> 各环节的具体操作见下表对应文档，本文只讲流程、门禁与约定，不重复其内容。
+
+**关联文档**
+
+| 文档 | 内容 |
+|---|---|
+| `docs/测试说明/自动化测试流程.md` | @test 闭环细节（命令 / 标记 / 失败模式） |
+| `docs/测试说明/测试文档模板规范.md` | 测试文档模板、命名规则（TM / TC / DP） |
+| `docs/测试说明/serial-mcp-server_串口调试.md` | 串口调试 / 采集工具与陷阱 |
+| `docs/UI 设计/UI_自动化测试流程.md` | UI 模拟器回归（ui-verify）细节 |
+| `docs/代码规范/pre-commit使用说明.md` | pre-commit 门禁配置与范围 |
+| `docs/项目部署环境要求.md` | 构建 / 测试工具链环境 |
+| `docs/测试说明/<模块>_Test_Guide.md` | 各模块测试规范（CH395F / GD5F / SD2506 / FTP） |
+
+---
+
+## 1. 测试分层与门禁总览
+
+测试体系分四层，门禁由便宜到昂贵依次布防，改动须过对应门禁方可提交：
+
+| 层 | 名称 | 载体 | 抓住什么 |
+|---|---|---|---|
+| L0 | 静态门禁 | pre-commit 钩子（cppcheck / 代码规范 / 乱码 / 空白 / gitlint）+ `@build` | 编码规范、静态缺陷、任何编译警告 |
+| L1 | 板端测试套件 | testTask + `test/test_config.h` 套件 | 驱动 / 协议功能（串口 `[PASS]/[FAIL]` + `=== ... PASSED` 汇总） |
+| L2 | 主机侧回归 | `@test` 串口日志标记 + LVGL 模拟器像素 / 池水位回归 | 启动序列、UI 渲染、LVGL 内存池水位 |
+| L3 | 人工目检 | 上机屏幕、PC 端交互工具 | 视觉内容、自动化无法覆盖的场景 |
+
+### 1.1 门禁决策表（改动类型 → 必跑门禁）
+
+| 改动类型 | 必跑门禁 |
+|---|---|
+| 任何源码提交 | G0 pre-commit（提交时自动触发）+ G1 `@build` |
+| App / Drivers 功能代码（板端行为可观测） | G0 + G1 + G2 `@test`（模块标记） |
+| UI（菜单 / 内容页 / 字体 / 样式 / 几何） | G0 + G1 + G2 + G3 ui-verify 五步 |
+| UI 新增中文文案 | 另需 font-regen（字体重生成 + 回归），**先于提交** |
+| `test/` 套件或 PC 端工具代码 | G1 + G2（套件标题标记 / 工具自测） |
+| 仅文档 | G0 |
+
+G0~G3 命令详见 §6 / §7；ui-verify 完整命令见 `UI_自动化测试流程.md`。
+
+---
+
+## 2. 测试规划（文档先行）
+
+### 2.1 何时必须写测试文档
+
+新驱动 / 新模块 / 新功能 / 新协议 / 新接口：动手写代码前先立 `docs/测试说明/<模块>_Test_Guide.md`，结构遵循 `测试文档模板规范.md`（概述含设计原则覆盖表 → 阶段元信息表 → 测试用例表 → 脚本参考 → 已知陷阱 → 附录矩阵）。
+
+### 2.2 命名（与模板规范一致）
+
+| 对象 | 格式 | 现用示例 |
+|---|---|---|
+| 阶段 | `TM-{MOD}-{NN}` | TM-PHY-01 |
+| 测试用例 | `TC-{MOD}-{NNN}` | `TC-NET-601`（CH395F）、`TC-GD5F-205`、`TC-STO-03`、`TC-RTC-002` |
+| 设计原则 | `DP-{NN}` | DP-01（单连接 socket） |
+
+模块缩写 `{MOD}` 在新模块测试文档立文档时确定（2~4 个大写字母）；现有：`NET`=CH395F 网络、`GD5F`、`STO`=存储、`RTC`、`ADC`、`RS485`。
+
+### 2.3 三条铁律
+
+1. **先写判定标准，再写测试代码** —— 文档里先写"什么算过 / 什么算失败"（精确到返回值 / 日志字符串 / 像素参考），再实现，避免"测了但不知道算不算过"。
+2. **判定标准必须可机器判定** —— 必须能落到：串口日志标记（→ `@test -Required`）、返回值 / 寄存器值（→ `TEST_CHECK`）、像素参考（→ 模拟器回归）、池水位（→ 基线常量）之一。无法机器判定的标准只能放 L3 人工层。
+3. **每条设计原则必须有对应用例** —— 覆盖表中每个 DP-xx 至少一个 TC；新功能设计时先定 DP，再设计 TC。
+
+---
+
+## 3. 板端测试套件（test/）
+
+### 3.1 统一入口与套件互斥
+
+所有测试套件经唯一入口调度：**testTask**（`test/test_config.c` 的 `start_test_task()`），按 `test/test_config.h` 选中的 `TEST_SUITE_*` 分发到套件运行函数：
+
+```mermaid
+flowchart TD
+    T["testTask: start_test_task()（test/test_config.c）"] -->|TEST_SUITE_CH395F| A["ch395f_test_run()<br/>硬件层 1~5 / NET 层 6~11"]
+    T -->|TEST_SUITE_STORAGE| B["storage_test_run()<br/>FTL + FatFS"]
+    T -->|TEST_SUITE_GD5F| C["gd5f_test_run()<br/>10 阶段"]
+    T -->|TEST_SUITE_RTC| D["sd2506_test_run()<br/>2 个阶段组"]
+    T -->|全部注释=产品构建| E["空闲（仅打印 suite=NONE）"]
+```
+
+- **套件互斥**：一次构建最多启用一个 `TEST_SUITE_*`，否则 `#error`（编译期门禁）；全部注释 = 正常产品构建。
+- **main.c / freertos.c 不含任何测试逻辑** —— 测试代码只能出现在 `test/`。
+
+| 套件 | 宏 | 文件 | 阶段组织 | 备注 |
+|---|---|---|---|---|
+| CH395F | `TEST_SUITE_CH395F` | `ch395f_test.h/.c` + `net_test_task.c` | 硬件层 1~5 / NET 层 6~11 | 两层互斥（`#error`）；阶段 2/3/4/5 与 6/7/8/10/11 需 PC 端配合 |
+| STORAGE | `TEST_SUITE_STORAGE` | `storage_test.h` + `storage_test_task.c` | FTL + FatFS 集成（TC-STO-01~04） | 恢复测试（重建 BBT）默认关闭 |
+| GD5F | `TEST_SUITE_GD5F` | `gd5f_test.h` + `gd5f_test_task.c` | 10 阶段（选中时自动全开） | NAND 驱动全覆盖 |
+| RTC | `TEST_SUITE_RTC` | `sd2506_test.h` + `sd2506_test_task.c` | 阶段 1 基本 / 阶段 2 API（默认全开） | SD2506 RTC |
+
+### 3.2 套件文件模式
+
+每个套件两个文件，模式一致（参照 `ch395f_test.h` / `storage_test.h`）：
+
+- `xxx_test.h` —— 阶段使能开关（取消注释启用）+ 本套件**独立统计**结构体 + `XXX_TEST_CHECK` / `XXX_TEST_REPORT` 宏 + `xxx_test_run()` 声明；
+- `xxx_test_task.c` —— `xxx_test_run()` 入口 + 每阶段一个 `static phaseN_run()`。
+
+断言宏（语义统一，统计变量按套件独立，防跨套件串数）：
+
+```c
+typedef struct { uint16_t total, passed, failed; } xxx_test_stats_t;
+
+#define XXX_TEST_CHECK(cond, fmt, ...) do { \
+    g_xxx_stats.total++; \
+    if (cond) { g_xxx_stats.passed++;  DBG_INFO("  [PASS] " fmt, ##__VA_ARGS__); } \
+    else      { g_xxx_stats.failed++;  DBG_ERROR("  [FAIL] " fmt, ##__VA_ARGS__); } \
+} while (0)
+
+#define XXX_TEST_REPORT(name) do { \
+    DBG_INFO("=== %s: %d/%d PASSED (failed=%d) ===", name, ...); \
+} while (0)
+```
+
+每 Phase 用标准注释头（与文档用例一一对应）：
+
+```c
+/*
+ * Phase N — 功能说明
+ * 测试目的 / 前置条件 / 通过 / 失败（四行，与 Test_Guide 文档一致）
+ */
+static void phaseN_run(void) {
+    DBG_INFO("=== XXX Phase N Tests ===");
+    /* ---- TC-XXX-NNN: 用例标题 ---- */
+    {
+        // 原理说明；通过：精确条件；失败：精确条件
+        ret = some_api();
+        DBG_INFO("          expect: ...");
+        DBG_INFO("          actual: ...");
+        XXX_TEST_CHECK(ret == EXPECTED, "description");
+    }
+    XXX_TEST_REPORT("Phase N");
+}
+```
+
+**套件运行结束行的 `=== <名称> Tests: N/N PASSED (failed=0) ===` 即该套件 `@test` 回归的默认标记**（各套件确切字符串见对应模块 Test_Guide，如 `=== Storage Tests:` / `=== GD5F2GQ5UE Tests:`）。
+
+### 3.3 编码约定
+
+| # | 约定 | 说明 |
+|---|---|---|
+| 1 | 判定点三行输出 | `expect:` / `actual:` / `[PASS]/[FAIL]`，一眼看出"期望什么、拿了什么、过没过" |
+| 2 | 硬编码值加注释 | 协议字节 / 寄存器 / 阈值必须注释含义与来源（手册页 / 协议条款） |
+| 3 | 日志字符串纯 ASCII | ARMCC v5 不识别 UTF-8 多字节字符（`#870-D` 警告）；注释可中文，`DBG_*` 字符串不可 |
+| 4 | 大缓冲用 static | 大缓冲（64KB 级）`static uint8_t s_rx_buf[N]`，不放任务栈 |
+| 5 | 条件编译包裹变量 | 仅特定阶段使用的变量 / 函数用 `#if` 包裹，消除 `#177-D` 未使用变量警告 |
+| 6 | 就绪等待用就绪屏障 | 任务间时序依赖 `SYS_EVT_*`（`osEventFlagsWait`），**禁止魔法延时** |
+
+> 注意：`test/` 在 pre-commit 检查范围之外（工具代码豁免）——上表约定属**自律**要求，但 0 错 0 警的构建红线对测试代码同样生效。
+
+### 3.4 已知问题：测试构建下的 netTask（未来测试设计必读）
+
+代码事实（截至 2026-09）：
+
+1. `netTask` 定义于 `.ioc`（RTOS 任务列表）→ `Src/freertos.c` 的 **CubeMX 生成区无条件创建**，其函数体 `net_task_func()` **在所有构建模式下一样运行**：等存储就绪（≤10s）→ `net_stack_bring_up()`（CH395F 初始化）→ 置 `SYS_EVT_NET_READY` → `net_poll()` 轮询循环。
+2. USER CODE 区在 `ENABLE_NET_LAYER_TESTS` 下**另建一个** netTask → NET 层测试构建下**双 netTask 并存**（双重初始化；靠重初始化幂等 + 失败方永久挂起在实践中被掩盖）。
+3. 硬件层 CH395F 模式下，testTask 还自行做一次 `net_stack_bring_up()` 后阻塞跑各阶段；生成版 netTask 的第二次初始化把芯片重初始化为相同状态，且 PC 配合阶段要等 PC 端就绪才启动（时延远大于初始化窗口），**实测不影响测试结果**。
+
+由此产生的设计约束：
+
+- 旧文档"硬件层模式 netTask 不创建、testTask 独占 CH395F、无 net_poll 并发"的说法**与代码不符**：任何构建下生成版 netTask 都存在且运行 `net_poll()`（全局中断由它消费清除）。
+- **新增测试套件必须按"netTask 恒存在且在轮询"设计**：不得假设"无人动芯片 / 中断"。
+- 若未来需要严格"测试独占外设"，须先完成以下重构（尚未实施）：
+  1. 删除 `freertos.c` USER CODE 区冗余的 netTask 创建；
+  2. `net_task_func()` 增加编译期守卫：`ENABLE_HW_LAYER_TESTS` 下挂起（不 bring_up、不 poll）；
+  3. （彻底方案）netTask 从 `.ioc` 移除、全部创建移入 USER CODE 区按构建模式控制——需同步验证 CubeMX 再生成流程。
+- 重构完成前：**不要**新增断言"中断状态寄存器全程 0x0000"之类的用例（net_poll 会清除标志，必现竞态误报）。
+
+### 3.5 新测试文件 / 新套件 checklist
+
+1. `test/` 下新建 `xxx_test.h` / `xxx_test_task.c`（按 §3.2 模式）；
+2. `test/test_config.h`：补 `TEST_SUITE_XXX` 注释开关 + 互斥 `#error` 加项 + 分发分支（include + `TEST_SUITE_NAME`）；
+3. `test/test_config.c`：`start_test_task()` 加分发分支；
+4. **双端注册核查**（`new-source-file` skill）：新 `.c` 必须加入 `MDK-ARM/STM32F407-Demo.uvprojx`；test/ 代码仅 MCU 端编译，**不**登记模拟器 CMakeLists（UI / App 共用代码才需双端）；
+5. `@build` → 0 错 0 警；
+6. 立 `docs/测试说明/<模块>_Test_Guide.md`（§2 模板）；
+7. `@test` 以套件标题行为 `-Required` 标记跑通回归。
+
+---
+
+## 4. 主机侧测试工具
+
+### 4.1 工具清单
+
+| 工具 | 位置 | 作用 |
+|---|---|---|
+| serial-mcp-server v0.3.0 | `%LOCALAPPDATA%\serial-mcp-server\serial-mcp-server.exe` | 串口 CLI / MCP：列端口、采集、读写 |
+| `test/serial_capture.ps1` | `test/` | 底层采集编排（稳定启动 → 烧录 → 收集；内置 EOF 自动重试） |
+| `test/run_boot_test.ps1` | `test/` | 一键闭环：采集 → 烧录 → 提取日志 → 校验 |
+| `test/verify_log.ps1` | `test/` | 日志标记校验（Required / Forbidden → PASS / FAIL） |
+| `.opencode/serial_config.json` | 仓库 | **串口端口单一配置源**（当前 COM6 / 115200）；换端口只改这个文件 |
+| `test/ftp_*.py`（4 个）/ `ch395f_socket_test.py` / `time_sync_server.py` | `test/` | PC 端交互测试工具（FTP 客户端 / socket 回显 / 对时推送） |
+| `simulator/tests/*.py`（4 个） | `simulator/tests/` | LVGL 模拟器回归脚本（见 §5） |
+
+### 4.2 新工具约定
+
+- **PowerShell 脚本必须纯 ASCII**（编码铁律：会读写中文源码的脚本不得含非 ASCII，见 `run_boot_test.ps1` 头注）；
+- **Python 统一用仓库 `.venv`**；第三方依赖必须进 `requirements.txt`（纯 ASCII）；
+- 落位：板端交互工具 → `test/`；模拟器回归 → `simulator/tests/`；
+- 新工具引入新的"通过标记"时，必须登记到 §6.2 标记表，供 `@test` 闭环复用。
+
+---
+
+## 5. UI 测试门禁（ui-verify）
+
+**触发条件**：任何 `Drivers/BSP/UI/` 下改动、字体（`ui_font_cn_12.c` / `ui_cn_chars.txt`）、菜单 / 内容页。
+
+### 5.1 五步门禁（顺序执行，全过）
+
+```powershell
+cmake --build simulator/build --config Debug   # 0) 构建模拟器（须 0 警告）
+.venv\Scripts\python.exe simulator/tests/check_menu_rows.py      # 1) 菜单 8 状态像素回归 + 池基线
+.venv\Scripts\python.exe simulator/tests/check_content_pages.py  # 2) 内容页黄金参考 + 往返池水位
+& "MDK-ARM\build.bat"                          # 3) Keil 构建（UI 源码双端共用，改一端必过另一端）
+.venv\Scripts\python.exe scripts/check_coding_standard.py        # 4) 代码规范机械检查
+```
+
+远显推流通道另按需跑 `simulator/tests/check_remo_sink.py`。
+
+### 5.2 三层断言（两个回归脚本内置）
+
+| 层 | 载体 | 抓住什么 |
+|---|---|---|
+| 文本层 | `check_content_pages.py` 字形模板匹配（50 条，解析字体 cmap / glyph_dsc / bitmap） | 缺字显示空白 / 标签写错等**静默失败**（不依赖 `ref/`，先于像素比对运行、失败即中止防误刷参考） |
+| 像素层 | 11 内容页 + 菜单 8 状态，与黄金参考逐字节比对 | 几何 / 样式 / 光标反显 / 整体外观 |
+| 池水位层 | `MENU_POOL_BASELINE=4784 B` / `POOL_AFTER_ROUNDTRIP=4864 B` | LVGL 内存池泄漏 / 结构性漂移 |
+
+### 5.3 黄金参考与字体纪律
+
+- `simulator/tests/ref/`（`.bin` 参考 + `.png` 目检图）**不入库**：首次 / 换机先 `check_content_pages.py --update` 生成；
+- `--update` 有**误刷保护**（先跑文本层断言，失败即中止）——**未有意改视觉而 FAIL = bug，修代码，禁止刷参考掩盖**；
+- 刷新参考后必须重跑 `regen_ref_png.py` 重生成目检 PNG（否则旧 PNG 看似乱码）；
+- 门禁常量漂移：先确认新值合理（残留分解见 `菜单页面设计.md` §9.5）→ 更新常量 + 在 `UI_自动化测试流程.md` 变更记录登记；
+- **UI 新增中文文案提交前必须先跑 font-regen**（extract_cn → make_font → diff 检查）：字符集 `ui_cn_chars.txt` 缺字则上机显示空白。
+
+---
+
+## 6. 自动化闭环（@test）
+
+### 6.1 流程
+
+```mermaid
+flowchart TD
+    A[代码改完] --> B["G1 @build（0 错 0 警，否则修复重编）"]
+    B --> C["run_boot_test.ps1：烧录前武装采集（等 first-byte）"]
+    C --> D["@download 烧录（Reset & Run 触发重启）"]
+    D --> E[提取日志 + verify_log 标记校验]
+    E -->|exit 0| F["PASS → G3（UI 改动）→ L3 上机目检 → 提交"]
+    E -->|exit 1 FAIL| G["[MISS]/[HIT] + 日志尾部定位 → 修代码"]
+    G --> B
+    E -->|exit 2/3 环境错误| H["按 自动化测试流程.md 失败模式表处理 → 重试"]
+```
+
+### 6.2 判定标记
+
+默认：`-Required "App init OK;Network Init;net init: OK"` / `-Forbidden "FAIL;ERROR;HardFault;assert"`。
+
+| 回归场景 | `-Required` 定制 |
+|---|---|
+| 网络 | `App init OK;Network Init;net init: OK;PHY: 100M FULL` |
+| UI 初始化 | `UI port init: OK;UI menu init: OK;UI net sink: started` |
+| 开机全量（存储 / RTC / RS485 / ADC） | 默认 + `RS485 init: OK;NAND init:;ADC init:;SD2506 ID:` |
+| 测试套件构建 | 套件结尾汇总行（`=== Storage Tests:` / `=== GD5F2GQ5UE Tests:` 等，确切字符串见各模块 Test_Guide） |
+
+### 6.3 三条铁律
+
+1. **采集必须先于烧录武装** —— serial-mcp-server 无历史缓冲（只能读调用后字节）；开机日志必须"先采集、后烧录"（`run_boot_test.ps1` 已保证顺序）；
+2. **端口以 `.opencode/serial_config.json` 为准** —— 每次连接前先读它；
+3. **参数覆盖时间窗** —— `InitialTimeoutMs=90000`（覆盖编译 + 烧录）、`IdleTimeoutMs=8000`（覆盖 boot ~3-4s 自然静默间隙）；`UnexpectedEof` 陷阱由 `serial_capture.ps1` 内置自动重试，勿裸跑 CLI。
+
+---
+
+## 7. 提交门禁与沉淀
+
+### 7.1 提交门禁（G0，pre-commit）
+
+提交被钩子门禁，任一失败即拦截：
+
+| 钩子 | 内容 |
+|---|---|
+| trailing-whitespace / end-of-file-fixer / check-added-large-files / check-merge-conflict / check-yaml | 官方空白 / 文件尾 / 大文件 / 冲突 / YAML 检查 |
+| gitlint | commit message 标题 ≤100 字符 |
+| cppcheck | 静态分析（warning / performance / portability / style，含 suppress 清单） |
+| no-mojibake | 禁止 U+FFFD 乱码字节（保护中文注释） |
+| coding-standard | 代码规范 V1.0 机械检查（S1~S19） |
+
+范围：仅项目自有代码受检；第三方与生成物（`Lib/`、`Middlewares/`、CMSIS/HAL、`lftpd`、`dhara`、`MDK-ARM/`、`test/`、CubeMX 生成的 `Src/` `Inc/` 等）被排除（详见 `pre-commit使用说明.md`）。
+
+### 7.2 提交纪律
+
+- **逻辑提交**：一笔提交只做一件事（代码 / 文档 / 工具分开）；
+- **编码铁律**（最高优先级）：含中文文件只用 Edit 工具精确替换修改；**禁止** PowerShell / cmd 整文件重写（U+FFFD 乱码不可逆）；BOM 状态按原样保持（UI 相关源 / `lv_conf.h` 带 BOM，其余无 BOM）；
+- **内存预算**：新增任务 / 缓冲 / 栈前必须先对照 RAM 红线（当前 SRAM 占用 95.4%、仅余 ~5.8KB，见 `docs/内存管理/`）。
+
+### 7.3 沉淀（必须）
+
+| 事件 | 动作 |
+|---|---|
+| 测试发现陷阱（硬件 / 协议 / 工具链 / 时序） | 写入 `docs/问题记录/<模块>_Trap_Records.md`：现象 / 根因 / 修复 / 规避 |
+| 代码变更影响判定标准 | 立即同步更新模块 Test_Guide，并登记该文档变更记录 |
+| 有意改视觉 | 刷黄金参考 + 重生成目检 PNG + `UI_自动化测试流程.md` 变更记录登记 |
+| 新增测试工具 / 新标记 | `自动化测试流程.md` 命令清单登记（§4.2） |
+
+> 文档与代码一体两面：**代码改了文档没同步 = 未完成**。
+
+---
+
+## 8. 迭代节奏（完整闭环）
+
+```mermaid
+flowchart LR
+    A["文档：规划 + 判定标准<br/>（Test_Guide）"] --> B["代码：套件 / 工具实现<br/>+ 双端注册核查"]
+    B --> C["G1 @build<br/>0 错 0 警"]
+    C --> D["G2 @test<br/>采集→烧录→校验"]
+    D -->|PASS| E["G3 ui-verify<br/>（UI 改动时）"]
+    E --> F["L3 上机目检"]
+    F --> G["提交<br/>G0 门禁 + 逻辑提交"]
+    G --> H["沉淀：陷阱记录 /<br/>文档同步 / 变更记录"]
+    D -->|FAIL| I["[MISS]/[HIT] 定位"]
+    I --> B
+```
+
+各模块测试迭代都走这个闭环：文档先行、门禁验收、沉淀回灌。
+
+---
+
+## 附录 A：test/ 文件清单（现状）
+
+| 文件 | 作用 |
+|---|---|
+| `test_config.h` / `test_config.c` | 套件选择（互斥 `#error`）+ 统一调度入口 `start_test_task()` |
+| `ch395f_test.h` / `ch395f_test_task.c` | CH395F 套件：阶段开关、断言宏、Phase 1~5 实现 |
+| `net_test_task.h` / `net_test_task.c` | CH395F 套件 NET 层（6~11）：TCP 监听循环 / Client 主动连接测试 |
+| `storage_test.h` / `storage_test_task.c` | STORAGE 套件：FTL + FatFS 集成（TC-STO-01~04）+ 恢复测试 |
+| `gd5f_test.h` / `gd5f_test_task.c` | GD5F 套件：NAND 驱动 10 阶段 |
+| `sd2506_test.h` / `sd2506_test_task.c` | RTC 套件：SD2506 RTC 2 阶段组 |
+| `run_boot_test.ps1` / `serial_capture.ps1` / `verify_log.ps1` | 自动化闭环三件套（纯 ASCII） |
+| `ftp_test.py` / `ftp_capture.py` / `ftp_up_dl_test.py` / `ftp_speed_test.py` | FTP PC 端测试工具 |
+| `ch395f_socket_test.py` | CH395F PC 端 socket 回显 / 大文件传输工具 |
+| `time_sync_server.py` | 对时推送 PC 端服务器 |
+
+## 附录 B：模块测试文档
+
+| 文档 | 模块 / 套件 |
+|---|---|
+| `docs/测试说明/CH395F_Test_Guide.md` | CH395F（11 阶段，TC-NET-xxx） |
+| `docs/测试说明/GD5F2GQ5UE_Test_Guide.md` | GD5F + 存储集成（TC-GD5F / TC-STO） |
+| `docs/测试说明/SD2506_Test_Guide.md` | RTC（TC-RTC-xxx） |
+| `docs/测试说明/FTP_Test_Guide.md` | FTP 服务（手动 + 阶段 8 自动化） |
+| `docs/测试说明/serial-mcp-server_串口调试.md` | 串口调试工具 |
+| `docs/测试说明/自动化测试流程.md` | @test 闭环细节 |
+| `docs/测试说明/测试文档模板规范.md` | 测试文档模板与命名 |
+
+## 变更记录
+
+| 日期 | 变更 |
+|---|---|
+| 2026-09-13 | 重写：对齐现测试架构——统一 `test_config.h` 套件（旧版仅描述 CH395F 单套件与 `ch395fTestTask` 旧入口）；新增 @test 自动化闭环、pre-commit 门禁、UI 模拟器五步门禁、主机侧工具约定；新增"测试构建下 netTask"已知问题（旧版"硬件层模式 netTask 不创建"表述与代码不符，改为设计约束并给出重构路径）；修正附录路径（旧版 `docs/CH395F_Test_Guide.md` 等已移入 `docs/测试说明/`）；新增双端注册、内存预算、陷阱沉淀要求 |
diff --git a/docs/测试说明/测试文档模板规范.md b/docs/测试说明/测试文档模板规范.md
new file mode 100644
index 00000000..46d5d17c
--- /dev/null
+++ b/docs/测试说明/测试文档模板规范.md
@@ -0,0 +1,338 @@
+# 测试文档模板规范
+
+本文档定义本项目测试文档的统一模板与编写规范，确保各模块（CH395F、GD5F2GQ5UE、SD2506 RTC、存储等）测试文档格式一致、可追溯，并能直接接入 `@test` 自动化闭环与门禁体系。
+
+---
+
+## 1. 定位与关联文档
+
+| 文档 | 关系 |
+|---|---|
+| `测试开发标准流程.md` | 测试开发总流程（规划 → 实现 → 门禁 → 沉淀）；本文是其"测试规划（文档先行）"环节的可执行模板 |
+| `自动化测试流程.md` | `@test` 闭环命令、参数与失败模式；本文"回归接入"章节引用它 |
+| `docs/UI 设计/UI_自动化测试流程.md` | UI 类改动的模拟器回归门禁（L2 层） |
+| `docs/问题记录/<模块>_Trap_Records.md` | 陷阱记录；测试文档"已知陷阱"章节引用它 |
+
+---
+
+## 2. 文档结构
+
+每份测试文档包含以下章节：
+
+```
+# [模块名] 测试规范
+
+## 1. 概述
+### 1.1 套件与入口（TEST_SUITE_* 宏 / 入口函数 / 阶段宏 / 运行方式）
+### 1.2 设计原则覆盖表（DP-xx → 描述 → 验证用例）
+### 1.3 测试环境（拓扑、工具链、硬件版本、PC 端依赖）
+### 1.4 启用方法（编译开关 + 运行命令）
+### 1.5 回归接入（@test 标记 / PC 端脚本 / 门禁层级）
+
+## 2~N. 阶段 x：[阶段名]
+- 阶段元信息表（含阶段宏）
+- TC-XXX-xxx: 测试用例（完整表格）
+
+## N+1. 脚本参考（如有 PC 端工具）
+## N+2. 已知陷阱与故障模式（引用 Trap 文档）
+## 附录 A：通过/失败汇总矩阵
+## 附录 B：测试覆盖 vs 设计原则
+## 附录 C：API 覆盖（驱动类模块建议）
+## 变更记录
+```
+
+---
+
+## 3. 概述章节要求
+
+### 3.1 套件与入口（必填）
+
+| 项 | 说明 |
+|---|---|
+| 套件宏 | `TEST_SUITE_XXX`（`test/test_config.h` 选择，套件互斥，见 `测试开发标准流程.md` §3.1） |
+| 入口函数 | `xxx_test_run()`（由 `start_test_task()` 统一调度） |
+| 阶段宏 | `ENABLE_XXX_PHASEN_TESTS`（各阶段使能开关，取消注释启用） |
+| 运行方式 | 独立运行 / 需 PC 配合（逐阶段标注所需 PC 端工具） |
+
+### 3.2 回归接入（必填）
+
+| 项 | 说明 |
+|---|---|
+| `@test` 标记 | 套件结尾汇总行（如 `=== Storage Tests:`）或阶段标题行；**必须与串口实际输出逐字一致**（`verify_log.ps1` 子串匹配） |
+| 禁止模式 | 默认 `FAIL;ERROR;HardFault;assert`，可按模块增补 |
+| PC 端脚本 | `test/*.py` 工具清单与调用方式 |
+| 门禁层级 | L1（板端套件）/ L2（串口标记 + 模拟器回归）/ L3（人工目检），见 `测试开发标准流程.md` §1 |
+
+> 标记字符串一律**从代码 `DBG_*` 实际输出复制**（含大小写 / 冒号 / 空格）；代码改了输出文案必须同步改文档（§7.6）。
+
+---
+
+## 4. 阶段元信息表
+
+每个阶段以表格开头，描述阶段的整体属性：
+
+| 字段名 | 填写说明 |
+|--------|----------|
+| **阶段 ID** | `TM-模块缩写-两位数序号`，如 TM-PHY-01、TM-NAND-01 |
+| **类型** | 独立运行 / 需 PC 配合 / 需物理操作 / 在 xxTask 中运行 |
+| **耗时** | 预估执行时间 |
+| **入口** | 代码入口函数或宏定义 |
+| **出口** | 阶段结束标志（如串口输出内容，即 `@test` 可校验的标记） |
+| **阶段宏** | 对应使能宏（如 `ENABLE_PHASE1_TESTS`） |
+
+---
+
+## 5. 测试用例表格模板
+
+每个测试用例使用统一表格格式：
+
+```
+### TC-模块缩写-序号: 用例标题
+
+| 字段 | 值 |
+|------|-----|
+| **ID** | TC-XXX-NNN（全局唯一，不复用） |
+| **优先级** | P0 / P1 |
+| **类型** | 见下文 5.1 |
+| **标题** | 一句话描述测试什么 |
+| **前置条件** | 测试执行前必须满足的条件（编号列表） |
+| **测试步骤** | 操作步骤（编号列表，动作具体到 API 或操作） |
+| **预期结果** | 系统应表现的行为 |
+| **通过标准** | 可量化的判定条件 |
+| **机器可判** | 串口标记 / TEST_CHECK / 像素参考 / 池水位 / L3 人工（见 §7.4） |
+| **覆盖原则** | DP-xx（可选，关联设计原则） |
+```
+
+### 5.1 类型枚举
+
+| 类型 | 说明 | 适用场景 |
+|------|------|----------|
+| 功能测试 | 验证某项功能是否符合预期 | 正常的收发、初始化、配置等 |
+| 负向测试 | 验证系统对非法/异常输入的处理 | 超时、断开、无效参数等 |
+| 边界测试 | 验证系统在边界条件的表现 | 最大包长、最小超时、满队列等 |
+| 压力测试 | 验证系统在高负载下的稳定性 | 多客户端、高频请求、长时运行等 |
+| 恢复测试 | 验证系统从故障中恢复的能力 | 断线重连、PHY 重连、复位恢复、掉电恢复等 |
+| 合规测试 | 验证实现是否符合特定约束 | 中断处理位置、等待顺序、字节序等 |
+| 稳定性测试 | 验证系统长时间运行的可靠性 | 长时间压力、反复循环等 |
+| 集成测试 | 验证跨模块组合场景下的行为 | FTL+FatFS 联合、FTP+存储、网络+存储等 |
+
+### 5.2 优先级定义
+
+| 优先级 | 定义 |
+|--------|------|
+| **P0** | 核心功能，必须通过。阻塞后续测试或影响系统基本可用性 |
+| **P1** | 重要功能，建议通过。失败表明潜在缺陷但不阻塞基本功能 |
+
+---
+
+## 6. 命名规则
+
+### 6.1 阶段 ID
+
+```
+TM-{MOD}-{NN}
+```
+
+- `TM` — Test Module
+- `{NN}` — 两位序号，从 01 开始
+
+### 6.2 模块缩写（以项目现用为准）
+
+| 缩写 | 模块 | 现用文档 |
+|---|---|---|
+| `NET` | CH395F 网络（驱动 + 协议栈 + FTP 自动化用例） | `CH395F_Test_Guide.md`（`FTP_Test_Guide.md` 的自动化部分复用其 TC-NET-8xx 编号） |
+| `GD5F` | GD5F2GQ5UE NAND Flash 驱动 | `GD5F2GQ5UE_Test_Guide.md` |
+| `STO` | 存储（FTL + FatFS 集成） | `GD5F2GQ5UE_Test_Guide.md`（TC-STO 章节） |
+| `RTC` | SD2506 RTC | `SD2506_Test_Guide.md` |
+| `ADC` | TPAFE5160 ADC | （待立） |
+| `RS485` | RS-485 通信 | （待立） |
+
+> 新模块立测试文档时先定缩写（2~4 个大写字母），并同步更新本表与 `测试开发标准流程.md` §2.2 的缩写表。
+> 注：旧版缩写 `PHY` / `NAND` 已被实际用法 `NET` / `GD5F` 取代（历史文档不回改，新文档按本表）。
+
+### 6.3 测试用例 ID
+
+```
+TC-{MOD}-{NNN}
+```
+
+- **分阶段套件**：序号**百位放阶段号**，编号即自文档化——`TC-NET-101` = CH395F Phase 1 第 1 项、`TC-NET-601` = Phase 6 第 1 项、`TC-NET-1101` = Phase 11 第 1 项；
+- **无阶段划分套件**：全局顺序编号（如 `TC-STO-03`、`TC-RTC-001`）；
+- 编号不复用：废弃用例保留编号并注明"已废弃"。
+
+### 6.4 设计原则 ID
+
+```
+DP-{NN}
+```
+
+- `DP` — Design Principle
+- `{NN}` — 两位序号，从 01 开始
+
+示例：`DP-01`（CH395F 单连接 socket）、`DP-02`（中断集中处理）
+
+---
+
+## 7. 编写规范
+
+### 7.1 表格格式
+
+- 使用 GFM (GitHub Flavored Markdown) 表格
+- 首列为字段名，加粗（`**字段**`）
+- 第二列为值，左对齐
+- 多行内容使用 `<br>` 换行（保持表格可读性）
+
+### 7.2 测试步骤与前置条件
+
+- 使用有序列表（`1. 2. 3.`）
+- 每个步骤是一个完整的可执行动作
+- 包含具体 API 名或操作名（如 `net_recv()`、`ch395f_open_socket()`）
+- 前置条件写明硬件状态、PC 端命令（含完整命令行）、代码配置（宏 / 编译开关）
+
+### 7.3 语言
+
+- 中文书写（技术标识保留英文）
+- 保持客观、精确、可验证
+- 避免模糊表述（如 "应该能正常工作" → "回显内容与发送完全一致"）
+
+### 7.4 通过标准（必须可机器判定，或显式人工层）
+
+通过标准必须落到以下通道之一，并在用例表"机器可判"字段标明：
+
+| 通道 | 判定方 | 适用 |
+|---|---|---|
+| 串口日志标记 | `@test` / `verify_log.ps1` 子串匹配 | 启动序列、阶段标题行、关键事件 |
+| 返回值 / 寄存器 / 数据 | 板端 `XXX_TEST_CHECK` 断言 | 驱动命令、协议交互、数据完整性 |
+| 像素参考 | LVGL 模拟器回归（`simulator/tests/`） | UI 渲染、字体、样式 |
+| 内存池水位 | 模拟器池基线 / 往返常量 | LVGL 对象泄漏、结构漂移 |
+| L3 人工 | 人工目检 / 交互 | 屏幕观感等无法机器判定的项（必须写目检步骤） |
+
+- 好的示例：`70/70 成功率（100%）`、`串口显示 "PHY_CHANGE: 0x01"`、`10/10 回显匹配`、`=== Storage Tests: 11/11 PASSED (failed=0) ===`
+- 差的示例：`功能正常`、`系统稳定`
+
+### 7.5 引用
+
+- 引用函数、宏、文件名使用反引号（`` `net_poll()` ``）
+- 引用其他文档使用仓库相对路径：`docs/问题记录/CH395F_Trap_Records.md`、`docs/测试说明/自动化测试流程.md`
+- 代码位置引用：`文件路径:行号` 或函数名
+
+### 7.6 文档维护（与代码同步）
+
+- 代码变更影响用例 / 判定标准 / 日志文案 → **当天**更新本文档，并在变更记录登记（与 `测试开发标准流程.md` §7.3 同标准）；
+- 测试发现陷阱 → 写入 `docs/问题记录/<模块>_Trap_Records.md`（现象 / 根因 / 修复 / 规避），并在本文档"已知陷阱与故障模式"章节留链接；
+- 判定标准经实测修正 → 更新用例表并在变更记录注明修正原因。
+
+---
+
+## 8. 快速参考
+
+### 8.1 新模块测试文档模板
+
+```markdown
+# [模块名] 测试规范
+
+## 1. 概述
+
+### 1.1 套件与入口
+
+| 项 | 值 |
+|---|---|
+| 套件宏 | `TEST_SUITE_XXX` |
+| 入口函数 | `xxx_test_run()` |
+| 阶段宏 | `ENABLE_XXX_PHASE1_TESTS` … |
+| 运行方式 | 独立运行 / 需 PC 配合（列明哪些阶段、用什么 PC 工具） |
+
+### 1.2 设计原则覆盖
+
+| 原则 | 描述 | 验证用例 |
+|------|------|----------|
+| DP-01 | ... | TC-XXX-xxx |
+
+### 1.3 测试环境
+
+（硬件拓扑 / 工具链 / PC 端依赖）
+
+### 1.4 启用方法
+
+（test_config.h 开关 + 构建 / 运行命令）
+
+### 1.5 回归接入
+
+| 项 | 值 |
+|---|---|
+| `@test` 标记 | `=== XXX Tests:`（套件结尾汇总行的确切字符串） |
+| PC 端脚本 | `test/xxx_test.py` |
+| 门禁层级 | L1 + L2 |
+
+## 2. 阶段 1：[阶段名]
+
+| 项 | 值 |
+|---|---|
+| 阶段 ID | TM-XXX-01 |
+| 类型 | ... |
+| 耗时 | ... |
+| 入口 | ... |
+| 出口 | ... |
+| 阶段宏 | `ENABLE_XXX_PHASE1_TESTS` |
+
+### TC-XXX-001: 用例标题
+
+| 字段 | 值 |
+|------|-----|
+| **ID** | TC-XXX-001 |
+| **优先级** | P0 |
+| **类型** | 功能测试 |
+| **标题** | ... |
+| **前置条件** | 1. ...<br>2. ... |
+| **测试步骤** | 1. ... |
+| **预期结果** | ... |
+| **通过标准** | ...（可量化） |
+| **机器可判** | 串口标记 / TEST_CHECK / 像素参考 / 池水位 / L3 人工 |
+
+## 附录 A：通过/失败汇总矩阵
+
+| 阶段 | TC ID | 优先级 | 类型 | 状态 |
+|------|-------|--------|------|------|
+
+## 附录 B：测试覆盖 vs 设计原则
+
+| 原则 | 覆盖用例 |
+|------|----------|
+
+## 附录 C：API 覆盖（驱动类模块建议）
+
+| API | 已覆盖 | 用例 |
+|-----|--------|------|
+
+## 变更记录
+
+| 日期 | 变更 |
+|---|---|
+```
+
+### 8.2 附录模板
+
+```markdown
+## 附录 A：通过/失败汇总矩阵
+
+| 阶段 | TC ID | 优先级 | 类型 | 状态 |
+|------|-------|--------|------|------|
+
+## 附录 B：测试覆盖 vs 设计原则
+
+| 原则 | 覆盖用例 |
+|------|----------|
+
+## 附录 C：API 覆盖
+
+| API | 已覆盖 | 用例 |
+|-----|--------|------|
+```
+
+---
+
+## 变更记录
+
+| 日期 | 变更 |
+|---|---|
+| 2026-09-13 | 补充完善：模块缩写表更新为项目实际用法（`NET`/`GD5F`/`STO`/`RTC`/`FTP`，取代旧版 `PHY`/`NAND`，历史文档不回改）；概述新增"套件与入口"与"回归接入"章节（衔接 `test_config.h` 套件互斥与 `@test` 闭环，标记须与串口实际输出逐字一致）；用例表新增"机器可判"字段（四通道 + L3 人工层）；类型枚举新增"集成测试"；TC 序号约定"分阶段套件百位放阶段号"（TC-NET-601 = Phase 6）；新增附录 C API 覆盖；陷阱引用路径修正为 `docs/问题记录/`；新增 §7.6 文档维护规范与文末变更记录章节 |
diff --git a/docs/测试说明/自动化测试流程.md b/docs/测试说明/自动化测试流程.md
index 59e9bd0b..fb03ed6a 100644
--- a/docs/测试说明/自动化测试流程.md
+++ b/docs/测试说明/自动化测试流程.md
@@ -59,16 +59,12 @@
 | 端口被占用 | 先 `serial_close` / 结束残留 `serial-mcp-server` 进程；Keil ST-Link 不占 COM |
 | 日志中无 UI 相关输出 | 见下节「UI 自动化」 |
 
-## UI 屏幕自动化（当前缺口）
+## UI 屏幕自动化
 
-`App/task/ui_task.c` 目前没有 DBG 打印，串口无法确认 UI 是否成功初始化。建议在固件中补充：
-
-```c
-if (ui_port_init() != 0) { DBG_ERROR("UI port init: FAIL"); } else { DBG_INFO("UI port init: OK"); }
-if (ui_menu_init() != 0) { DBG_ERROR("UI menu init: FAIL"); } else { DBG_INFO("UI menu init: OK"); }
-```
-
-加完后把 `UI port init: OK` / `UI menu init: OK` 加入 `@test` 的 `-Required` 标记，即可自动回归 UI 初始化。屏幕上的**内容**仍需人工目检或后续接入截屏/控制类方案。
+- **初始化回归**：`App/task/ui_task.c` 已有 `UI port init: OK` / `UI menu init: OK` / `UI net sink: started`
+  打印（见 `@test` 命令示例）；将其加入 `-Required` 即可经串口自动回归 UI 初始化。
+- **屏幕内容回归**：由 LVGL 模拟器像素回归覆盖（文本级断言 + 11 页黄金参考 + 池水位门禁，
+  见 `docs/UI 设计/UI_自动化测试流程.md`）；上机屏幕仍需人工目检（L3 层，见 `测试开发标准流程.md` §1）。
 
 ## 扩展用法
 
@@ -77,3 +73,9 @@ if (ui_menu_init() != 0) { DBG_ERROR("UI menu init: FAIL"); } else { DBG_INFO("U
 - **测试套件构建**：`test/test_config.h` 开启某个 `TEST_SUITE_*` 后，把套件打印的
   `=== ... Test:` 标题作为 Required 标记，配合 `test/` 下各用例输出判断。
 - **长时间采集**：serial-mcp-server 支持 `--duration-ms` 长窗口采集（MCP `read` 传 `duration_ms` 即进入 capture 模式）。
+
+## 变更记录
+
+| 日期 | 变更 |
+|---|---|
+| 2026-09-13 | 「UI 屏幕自动化（当前缺口）」更新：UI 初始化 DBG 打印已实现（`ui_task.c`），屏幕内容已纳入模拟器像素回归；测试分层与门禁见 `测试开发标准流程.md` |