Test Suite Maintainer

<SUBAGENT-STOP> 如果你是作为子代理被派发执行特定任务，跳过此 skill。 </SUBAGENT-STOP>

测试套件维护

这个 skill 的目标不是补写开发阶段的单元测试，也不是用 mock 数据重复验证局部逻辑。它用于功能完成开发、已转测、并部署到可验证环境之后，维护和执行面向上线准入的完整流程测试。

测试通过代表：功能在真实部署环境、真实配置、真实或准真实业务数据、真实服务链路下满足需求和设计约束，可以作为上线判断依据之一。

核心原则

1. 以已转测和已部署为前提

• 默认功能代码已经完成开发并进入测试阶段。
• 默认相关服务、数据库、配置、权限、外部依赖或测试替身环境已经准备好。
• 如果环境未准备好，先输出环境缺口清单，不要退回去设计单元测试。

2. 验证完整业务流程

• 优先覆盖用户真实操作路径、接口链路、数据落库、状态流转、权限边界、异常恢复和跨模块协作。
• 不以函数级断言、mock 数据、孤立 fixture 作为主要验收手段。
• 必要时可以使用脚本自动执行流程，但脚本必须调用真实接口、真实页面或真实服务入口。

3. 每个功能模块独立维护

• 每个功能模块必须有独立目录。
• 测试方案、测试脚本、执行报告和测试数据说明都放在该模块目录下。
• 不使用一个全局 test-plan.md 混放多个功能模块的方案。

4. 先设计方案，确认后再写脚本

• 根据需求文档、设计文档、接口文档、部署说明和用户补充信息，先完成模块级整体测试方案。
• 方案必须先整体说明验收范围、主流程、前后端验证方式、数据准备、通过标准和脚本计划，不要一开始拆成多个脚本片段。
• 方案必须经用户确认后，才创建或修改测试脚本。
• 用户确认方案后，必须先按方案跑通流程，再创建或修改自动化脚本。
• 如果用户修改方案，先按修改后的方案重新跑通流程，脚本必须按确认且已跑通的方案实现。

5. 上线阻断标准清晰

• 核心主流程失败、数据状态错误、权限错误、真实依赖不可用、关键异常流程不符合预期，均视为上线阻断。
• 不能用“单元测试已通过”替代完整流程验收。
• 测试执行的目标是发现问题并给出明确结论，不是把测试结果改到通过。
• 遇到失败必须先判断是测试资产问题、环境/数据问题，还是被测代码问题；未完成归因前不得修改测试脚本。
• 如果归因为被测代码问题，测试应保持失败，报告中明确记录“不通过”和阻断原因。

6. 前端优先真实 Edge

• 涉及真实页面、路由、表单、登录态、网络请求、可见状态或用户路径时，优先使用真实 Microsoft Edge 验证。
• 前端流程跑通时，使用 Playwright CLI 连接远程调试 Edge。
• Vitest 只用于不依赖真实浏览器的纯逻辑、工具函数或轻量组件测试，不作为完整前端流程验收的首选。
• 接口返回正常只证明数据链路正常，不代表页面显示正常。
• 前端验收必须验证真实页面状态：关键内容可见、布局未明显错乱、交互反馈正确、错误提示位置和样式可用。
• 除元素或文本断言外，必要时必须截图查看页面实际显示，并把截图路径写入报告证据。

7. 失败先归因，禁止先改脚本

• 测试失败后，先收集证据：执行命令、输入数据、页面状态、网络请求、后端响应、日志、数据库状态和实际断言差异。
• 只有证明测试方案、测试数据、等待条件、选择器、环境配置或脚本实现本身错误时，才允许修改测试资产。
• 如果产品行为与已确认方案、需求或设计不一致，归因为被测代码问题；该失败必须保留并作为验收失败上报。
• 不得为了让测试通过而放宽断言、删除场景、跳过失败步骤、改用 mock、改预期结果或绕过真实入口。

8. 测试数据是测试方案的一部分

• 设计测试方案时必须同步设计测试数据：数据来源、造数方式、前置状态、账号权限、关联对象、清理方式和风险。
• 正常测试流程中，造测试数据是测试工作的一部分；不能因为“没有现成数据”直接跳过测试。
• 执行前发现数据缺失时，先按 data.md 或方案中的造数步骤创建数据，再执行场景。
• 只有造数入口缺失、权限不足、环境不可写、外部依赖不可用等导致数据无法准备时，才标记为 blocked，并记录环境/数据阻塞原因。

推荐目录结构

测试套件维护在项目的 workplace/test/ 目录下。每个功能模块一个独立目录：

workplace/test/
├── test-manifest.yaml
├── modules/
│   ├── auth/
│   │   ├── test-plan.md
│   │   ├── scripts/
│   │   │   ├── login_flow.py
│   │   │   └── register_flow.py
│   │   ├── data.md
│   │   └── reports/
│   │       └── 2026-04-20.md
│   ├── payment/
│   │   ├── test-plan.md
│   │   ├── scripts/
│   │   │   ├── checkout_flow.py
│   │   │   └── refund_flow.py
│   │   ├── data.md
│   │   └── reports/
│   │       └── 2026-04-20.md
│   └── ...
└── shared/
    ├── env.example.md
    ├── helpers/
    └── reports/

目录职责：

• modules/<module>/test-plan.md: 模块级完整流程测试方案。脚本生成前必须先有此文件并经确认。
• modules/<module>/scripts/: 根据确认后的方案编写的自动化或半自动化测试脚本。
• modules/<module>/data.md: 真实测试数据准备、账号、订单、配置、清理方式和数据风险说明。
• modules/<module>/reports/: 每次执行后的验收报告。
• shared/: 跨模块共用的环境说明、帮助函数和全量报告。
• test-manifest.yaml: 全量模块清单和上线验收状态索引，不替代模块测试方案。

test-manifest.yaml 格式

test-manifest.yaml 用于索引模块和上线验收状态，不再承载所有测试用例细节。

version: "2.0"
project:
  name: "项目名称"
  test_root: "workplace/test"
  target_environment: "staging"

modules:
  auth:
    description: "用户认证模块"
    priority: high
    requirement_docs:
      - "docs/requirements/auth.md"
    design_docs:
      - "docs/design/auth.md"
    module_dir: "workplace/test/modules/auth"
    plan: "workplace/test/modules/auth/test-plan.md"
    scripts:
      - "workplace/test/modules/auth/scripts/login_flow.py"
      - "workplace/test/modules/auth/scripts/register_flow.py"
    status: active
    plan_status: confirmed
    last_run: "2026-04-20"
    last_result: pass
    blockers: []

  payment:
    description: "支付处理模块"
    priority: high
    requirement_docs:
      - "docs/requirements/payment.md"
    design_docs:
      - "docs/design/payment.md"
    module_dir: "workplace/test/modules/payment"
    plan: "workplace/test/modules/payment/test-plan.md"
    scripts:
      - "workplace/test/modules/payment/scripts/checkout_flow.py"
      - "workplace/test/modules/payment/scripts/refund_flow.py"
    status: active
    plan_status: draft
    last_run: null
    last_result: pending
    blockers:
      - "测试支付网关账号未配置"

字段说明：

• priority: high / medium / low，上线前优先执行高优先级模块。
• status: active / skip / pending，控制是否纳入执行。
• plan_status: draft / confirmed，只有 confirmed 才能生成或修改脚本。
• last_result: pass / fail / blocked / pending。
• blockers: 记录影响上线验收的问题。

模块测试方案格式

每个模块的 test-plan.md 必须以真实流程验收为中心。

# 用户认证模块测试方案

**模块**: auth
**方案状态**: draft
**目标环境**: staging
**设计依据**:
- docs/requirements/auth.md
- docs/design/auth.md
**创建日期**: 2026-04-20

## 验收目标

- 验证用户注册、登录、会话保持、退出登录在真实部署环境下完整可用。
- 验证用户数据正确写入数据库，并能被后续流程读取。
- 验证关键异常路径不会产生错误状态。

## 整体测试方案

| 范围 | 验证目标 | 跑通方式 | 工具 | 通过标准 |
| --- | --- | --- | --- | --- |
| 后端注册/登录接口 | 验证接口、数据库和登录态链路 | 先用脚本调用 staging 真实 API | Python/Node/curl | 响应、数据状态和清理结果符合预期 |
| 前端注册/登录页面 | 验证用户真实页面路径和实际显示 | 先用真实 Edge 跑通页面操作，必要时截图核对 | Playwright CLI attach | 页面跳转、网络请求、关键内容、布局和可见状态符合预期 |

## 流程跑通门禁

- 方案确认后，先按本方案跑通流程，再生成或修改脚本。
- 后端流程使用脚本调用真实接口、服务和数据链路。
- 前端流程使用真实 Microsoft Edge，并通过 Playwright CLI 连接远程调试浏览器。
- 前端流程不能只看接口响应；接口成功后还要检查页面真实显示。
- 如果页面包含复杂布局、弹窗、表格、图表、错误提示、状态标签、异步刷新或响应式适配，必须截图核对实际显示。
- 任一目标流程未跑通时，不生成自动化脚本；先修正方案、补齐环境或记录阻塞。

## 环境前提

| 项目 | 要求 | 状态 |
| --- | --- | --- |
| 前端服务 | staging 前端已部署 | 待确认 |
| 后端服务 | staging API 已部署 | 待确认 |
| 数据库 | 可写入测试用户数据 | 待确认 |
| 外部依赖 | 邮件或验证码服务测试通道可用 | 待确认 |

## 测试数据

| 数据项 | 来源 | 造数方式 | 前置状态 | 用途 | 清理方式 |
| --- | --- | --- | --- | --- | --- |
| 测试用户账号 | 测试执行时创建 | 调用真实注册接口或后台测试账号创建入口 | 用户不存在、邮箱未占用 | 注册和登录流程 | 测试后删除或标记 |
| 已存在用户账号 | 测试执行前创建 | 调用后台测试数据接口或 SQL/管理后台创建 | 用户 active、密码已知 | 错误密码登录流程 | 测试后删除或恢复 |

## 造数步骤

1. 检查目标环境是否允许写入测试数据。
2. 为 `auth-flow-001` 生成唯一邮箱和用户名，确保与历史数据不冲突。
3. 通过真实注册入口创建用户，并记录 `user_id`。
4. 为 `auth-flow-002` 创建一个已存在 active 用户，记录账号、用户 ID 和清理方式。
5. 如果造数失败，先判断是数据方案问题、环境/权限问题还是被测代码问题；不能直接跳过场景。
6. 场景执行完成后，按清理策略删除、禁用或标记测试数据。

## 验收场景

| 场景ID | 场景名称 | 优先级 | 类型 | 预期结果 |
| --- | --- | --- | --- | --- |
| auth-flow-001 | 新用户注册后登录 | high | e2e | 用户可注册、登录成功、数据库状态正确 |
| auth-flow-002 | 错误密码登录失败 | high | e2e | 返回明确错误，登录态不创建 |

## 前端显示验收点

| 页面/状态 | 必查显示 | 验证方式 | 截图要求 |
| --- | --- | --- | --- |
| 注册成功后页面 | 成功提示、用户入口、跳转后的目标页面 | 元素断言 + 人工查看 | 页面布局或提示复杂时截图 |
| 登录失败页面 | 错误提示文案、错误位置、表单仍可编辑 | 元素断言 + 截图 | 必须截图 |

接口返回 200、网络请求成功或 DOM 中存在某个元素，都不能单独证明页面正常；必须确认用户实际看到的页面状态符合设计。

## 场景流程

### auth-flow-001 新用户注册后登录

1. 使用真实前端页面或真实注册接口提交新用户信息。
2. 验证响应成功，并记录用户 ID。
3. 查询数据库或后台接口确认用户已创建，状态正确。
4. 使用该用户执行登录。
5. 验证登录态、返回用户信息和页面跳转符合设计。
6. 执行退出登录。
7. 清理测试用户或按数据策略标记。

### auth-flow-002 错误密码登录失败

1. 准备一个已存在测试用户。
2. 使用错误密码调用真实登录入口。
3. 验证登录失败响应符合设计。
4. 验证不会创建有效登录态。
5. 验证用户状态未被错误修改。

## 脚本计划

| 脚本路径 | 覆盖场景 | 执行方式 |
| --- | --- | --- |
| scripts/login_flow.py | auth-flow-001, auth-flow-002 | 调用 staging 真实 API |
| scripts/login_ui_flow.spec.ts | auth-flow-001, auth-flow-002 | Playwright CLI attach 到真实 Edge |

## 上线阻断标准

- 注册或登录主流程失败。
- 用户数据写入错误或状态不一致。
- 错误密码产生有效登录态。
- 测试环境关键依赖不可用且无法替代验证。

## 失败归因规则

| 归因类型 | 判断标准 | 处理方式 |
| --- | --- | --- |
| 被测代码问题 | 实际行为与已确认方案、需求或设计不一致 | 保持测试失败，记录上线阻断，不改测试脚本 |
| 测试资产问题 | 方案、脚本、选择器、等待条件、测试数据或断言写错 | 修正测试资产，重新执行并记录修正原因 |
| 环境/数据问题 | 服务未部署、配置缺失、账号不可用、外部测试通道不可用 | 标记 blocked，补齐环境后重测 |

测试失败后必须先完成归因，再决定是否修改测试资产。

没有现成测试数据不是跳过理由；先按造数步骤准备数据。只有造数能力缺失或环境不允许造数时，才按环境/数据问题标记 blocked。

方案规则：

1. 每个模块一个 test-plan.md。 2. 每个模块方案必须先给出整体测试方案，再展开验收场景和脚本计划，不能直接按脚本拆散。 3. 方案必须引用需求和设计依据；如果缺少文档，要明确写出依据缺口。 4. 每个验收场景必须包含环境前提、真实数据、造数步骤、执行步骤、预期结果和清理方式。 5. 测试数据必须说明如何添加，不能只写“需要已有数据”。 6. 前端场景必须说明真实 Edge 验证方式，包括页面入口、关键操作、网络请求和可见结果。 7. 前端场景必须包含实际显示验收点；不能只以接口响应、网络请求成功或元素存在作为通过标准。 8. 前端页面复杂、状态容易误判或出现失败时，必须截图作为证据。 9. 方案只写测试逻辑和验收标准，不写代码。 10. 方案状态为 draft 时不能写脚本；用户确认后改为 confirmed。 11. 方案确认为 confirmed 后，仍必须先跑通目标流程；流程未跑通时不能创建或修改自动化脚本。 12. 方案必须包含失败归因规则；测试失败后先归因，不能默认修改脚本。 13. 方案必须包含测试数据准备和清理规则；没有现成数据时先造数，造数不可行才 blocked。

工作流程

场景一：初始化模块测试套件

适用于用户要求为某个功能模块建立上线验收测试。

1. 识别功能模块名称和边界。 2. 查找需求文档、设计文档、接口文档和部署说明。 3. 创建 workplace/test/modules/<module>/ 目录。 4. 编写 test-plan.md，状态为 draft。 5. 编写或更新 data.md，说明真实测试数据准备、造数入口、账号权限、关联对象、清理方式和数据风险。 6. 更新 test-manifest.yaml，登记模块、方案路径和 plan_status: draft。 7. 暂停并要求用户确认测试方案。 8. 用户确认后，将 plan_status 改为 confirmed。 9. 按方案先跑通流程：后端用脚本调用真实入口，前端用真实 Edge + Playwright CLI 执行页面路径。 10. 流程跑通后再创建脚本；流程未跑通时记录阻塞，不生成脚本。

场景二：根据已确认方案创建测试脚本

适用于用户已经确认模块测试方案。

1. 读取 modules/<module>/test-plan.md。 2. 确认方案状态为 confirmed，或用户在当前对话中明确确认。 3. 读取 data.md 和方案中的造数步骤，准备目标流程需要的数据。 4. 按方案先跑通目标流程，不直接生成脚本。 5. 后端流程用 Python/Node/curl 等脚本调用真实接口、服务和数据链路。 6. 前端流程用 Playwright CLI 连接真实 Microsoft Edge 执行页面路径，并检查页面实际显示。 7. 流程跑通后，根据“脚本计划”创建 scripts/ 下的脚本。 8. 脚本必须忠实实现方案中的场景流程和断言。 9. 脚本默认调用真实入口，不 mock 自身业务链路。 10. 脚本必须包含或调用必要的测试数据准备与清理步骤。 11. 更新 test-manifest.yaml 的脚本路径。 12. 如可执行，运行脚本并生成模块报告。

场景三：更新已有模块测试方案

适用于需求或设计变更后更新上线验收测试。

1. 读取模块当前 test-plan.md 和相关文档变更。 2. 标出新增、修改、删除的验收场景。 3. 更新模块 test-plan.md，状态改为 draft。 4. 同步更新 data.md 中的数据准备、造数入口、账号权限、关联对象和清理策略。 5. 更新 test-manifest.yaml 的 plan_status: draft。 6. 暂停并要求用户确认方案。 7. 用户确认后，先按更新后的方案跑通受影响流程。 8. 流程跑通后再更新脚本；流程未跑通时停止脚本更新并记录阻塞。

场景四：执行上线前完整流程验收

适用于“上线前测试”“跑全量验收”“真实流程验证”。

1. 读取 test-manifest.yaml。 2. 筛选 status: active 且 plan_status: confirmed 的模块。 3. 按 priority: high > medium > low 排序。 4. 检查每个模块的环境前提和测试数据是否就绪。 5. 如果测试数据不存在，先按 data.md 和方案中的造数步骤创建数据；不得因为没有现成数据跳过测试。 6. 只有造数入口缺失、权限不足、环境不可写或外部依赖不可用时，才标记 blocked。 7. 后端场景执行模块 scripts/ 下的脚本，或用临时脚本按方案调用真实接口/服务。 8. 前端场景优先用真实 Edge + Playwright CLI 执行页面路径；已有自动化脚本也必须连接真实浏览器或真实页面入口。 9. 前端场景必须在接口响应之外验证页面实际显示；必要时截图并记录截图路径。 10. 记录每个场景的实际结果、证据、数据记录和问题。 11. 对失败场景先做归因：测试资产问题、环境/数据问题、被测代码问题。 12. 只有归因为测试资产问题时才修改脚本；归因为被测代码问题时保持失败并记录上线阻断。 13. 生成模块报告到 modules/<module>/reports/<date>.md。 14. 生成全量报告到 shared/reports/<date>-full.md。 15. 更新 test-manifest.yaml 的 last_run、last_result 和 blockers。

验收结论：

• 所有 high 模块通过，且无上线阻断问题：可以进入上线评审。
• 任一 high 模块失败：不建议上线。
• 任一 high 模块 blocked：必须先补齐环境、数据或依赖后重测。

场景五：查看覆盖和上线风险

1. 汇总 test-manifest.yaml 中所有模块状态。 2. 列出没有测试方案的模块。 3. 列出 plan_status != confirmed 的模块。 4. 列出 last_result 为 fail 或 blocked 的模块。 5. 列出只有脚本但缺少方案确认的模块。 6. 给出上线风险判断。

测试脚本编写要求

脚本可以使用 Python、Playwright、pytest、Vitest、curl 或项目已有工具链。选择依据是能否稳定执行真实流程，而不是框架偏好。前端完整流程优先使用真实 Microsoft Edge；Vitest 只用于不依赖真实浏览器的逻辑测试。

脚本生成前必须满足：

• 模块 test-plan.md 已确认。
• 测试数据准备方式已在 data.md 和方案中明确。
• 目标流程需要的数据已按方案创建，或确认造数能力存在且可由脚本创建。
• 后端目标流程已用脚本调用真实入口跑通。
• 前端目标流程已用真实 Edge + Playwright CLI 跑通。
• 跑通过程的入口、命令、关键结果和阻塞处理已记录。

前端真实 Edge 连接命令：

& "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --remote-debugging-port=9222
npx playwright-cli attach --cdp=http://127.0.0.1:9222

脚本必须满足：

• 从环境变量或配置文件读取目标环境地址、账号和密钥，不硬编码敏感信息。
• 调用真实页面、真实接口或真实服务入口。
• 对业务结果、数据状态和关键副作用做断言。
• 记录足够的失败信息，方便定位问题。
• 包含测试数据清理或隔离策略。
• 不使用 mock 数据替代真实业务链路。
• 前端脚本应连接真实浏览器或真实页面入口，不用 jsdom/Vitest 替代完整用户流程。
• 断言必须来自已确认方案、需求或设计，不得为了通过而降低断言强度或改写预期。
• 失败时输出可归因证据，不自动吞掉错误、不自动重写测试、不把代码问题转成 skip。
• 需要前置数据时，脚本必须显式创建、查询或校验测试数据；不能假设环境中已经有某条隐含数据。
• 数据缺失时，脚本应执行造数步骤；造数失败时输出 blocked 原因，不应静默跳过场景。
• 前端脚本不能只断言接口响应正常；必须检查用户实际看到的页面状态。
• 前端脚本除元素断言外，应在关键页面状态、失败场景、复杂布局或疑似显示异常时截图。
• 截图文件应保存到模块报告或证据目录，并在报告中引用路径。

可以接受的测试替身：

• 第三方支付、短信、邮件等外部服务可使用官方 sandbox 或测试通道。
• 法规、费用或生产风险较高的外部动作可使用预发专用替身。
• 替身必须在 data.md 和报告中明确说明。

不应使用：

• 只调用内部函数的单元测试作为上线验收。
• 与真实部署环境无关的纯 fixture 测试。
• 大量 mock 自身业务模块后仍宣称完整流程通过。
• 未归因就修改测试脚本。
• 因产品行为失败而修改预期结果、删除断言或跳过场景。
• 因“没有数据”直接 skip 测试。
• 依赖未声明的历史脏数据或人工临时数据。
• 前端只看接口 200、网络请求成功或元素存在，就判定页面正常。
• 页面显示异常时不截图、不人工查看实际渲染结果。

报告格式

模块报告示例：

# 用户认证模块验收报告

**模块**: auth
**执行时间**: 2026-04-20 14:30
**目标环境**: staging
**结论**: pass

## 执行统计

| 指标 | 数值 |
| --- | --- |
| 场景总数 | 2 |
| 通过 | 2 |
| 失败 | 0 |
| 阻塞 | 0 |

## 场景结果

| 场景ID | 场景名称 | 结果 | 归因 | 证据 | 页面证据 |
| --- | --- | --- | --- | --- | --- |
| auth-flow-001 | 新用户注册后登录 | pass | 不适用 | user_id=12345 | reports/screenshots/auth-flow-001-success.png |
| auth-flow-002 | 错误密码登录失败 | pass | 不适用 | response=401 | reports/screenshots/auth-flow-002-error.png |

## 失败归因

| 场景ID | 归因类型 | 结论 | 处理 |
| --- | --- | --- | --- |
| 无 | 不适用 | 无失败 | 不适用 |

## 数据处理

| 数据项 | 创建方式 | 结果 | 清理结果 |
| --- | --- | --- | --- |
| 测试用户账号 | 真实注册接口创建 | user_id=12345 | 已删除 |
| 登录会话 | 登录流程创建 | session_id=abc | 已失效 |

## 问题和风险

- 无。

全量报告必须包含：

• 各模块结论。
• high 优先级模块是否全部通过。
• 失败和阻塞项。
• 每个失败项的归因：被测代码问题、测试资产问题、环境/数据问题。
• 测试数据准备结果和清理结果。
• 前端场景的页面显示证据，必要时包含截图路径。
• 上线建议。

最佳实践

1. 先方案后脚本：任何新增或变更都先更新模块 test-plan.md，确认后再改脚本。 2. 模块隔离：不要把多个功能的方案堆在一个全局文件里。 3. 真实链路优先：上线验收关注真实环境端到端结果。 4. 测试数据先设计：方案阶段就要写清数据怎么添加、怎么隔离、怎么清理，不能执行时临时找数据。 5. 缺数据先造数：没有现成数据不是 skip 理由；先按方案造数，造数不可行才 blocked。 6. 数据可追踪：测试数据来源、用途、创建结果和清理方式必须写清楚。 7. 阻断项明确：失败、阻塞、可接受风险要分开记录。 8. 确认后先跑流程：方案确认不等于可以直接写脚本，必须先证明后端和前端目标流程真实跑通。 9. 前端真实 Edge 优先：涉及页面和用户路径时，优先用 Edge + Playwright CLI；Vitest 不替代完整流程验收。 10. 前端看实际显示：接口正常不等于页面正常，必须验证用户看到的真实页面状态。 11. 必要时截图：复杂页面、失败场景、视觉状态或布局风险必须截图，截图路径进入报告。 12. 失败先归因：测试失败时先判断是测试资产问题、环境/数据问题还是被测代码问题，不能先改脚本。 13. 代码问题保持失败：如果归因为被测代码问题，明确报告不通过和上线阻断，不通过放宽断言或修改预期让测试变绿。 14. 脚本忠实于方案：脚本逻辑变更前先更新方案，并重新跑通受影响流程。 15. 不要倒退到开发测试：单元测试和 mock 测试属于开发阶段质量保障，不是此 skill 的主要产出。