大厂这套重构 Skill，自动化测试必看

哈喽，测试宝子们！你经历过服务重构吗？如果没有的话，相信随着 AI 浪潮的持续冲击，服务重构也迟早会落到咱们头上。

前两天刷到腾讯云开发者社区的一篇文章，它们针对服务重构沉淀了一套 Skill，从链路分析到测试自动化，用 流程拆分、分层知识库和 Harness Engineering 三板斧把重构流程彻底标准化了。

今天咱们就来一起盘一盘：这个 Skill 到底是啥？每个阶段怎么执行？它凭什么这么靠谱？以及—— 测试能从中薅到什么羊毛？

一、这个 Skill 是什么？

简单说，这是一套" AI 驱动的重构 SOP "。它的目标是解决服务重构中最大的痛点—— 业务逻辑梳理 ，把原本依赖个人经验、容易翻车的重构工作，变成标准化、可复现、质量可控的流程。

下面我们从 核心思想（为何做） 、 文件结构（放在哪） 和 知识库与阶段的映射（何时用） 三个维度来拆解这套机制。

1. 核心思想：渐进式披露（Progressive Disclosure）

AI 的上下文窗口有限，不可能一次性塞进所有重构知识。所以这个 Skill 采用 三层渐进式加载 ，让 AI 只加载当前需要的知识：

• 第 1 层（自动加载） ：核心规则速查（< 100 行），编辑 service/logic/repo/entity 目录时自动注入 DDD 分层、命名规范等。
• 第 2 层（按阶段加载） ：Skill 主控文件（< 200 行），描述 5 阶段流程，AI 根据当前阶段跳转到对应章节。
• 第 3 层（按需加载） ：Reference 知识库（不限行数），阶段 1 加载链路分析指引，阶段 3 加载设计模式，阶段 5 加载部署与排障。

2. 文件结构

   
   
   
   
/skills/trpc-go-refactor/
├── SKILL.md                          ← 主控文件（5 阶段流程 + Harness 机制）
├── assets/
│   ├── document-template.md          ← 重构方案 11 章节模板
├── references/
│   ├── architecture-patterns.md      ← DDD 分层 + 四件套设计模式 + 编码规范
│   ├── code-analysis-guide.md        ← 老代码链路分析方法论
│   ├── domain-knowledge.md           ← 业务领域知识（状态机 / 分表 / MQ / 枚举）
│   ├── project-config.md             ← 项目 Git 地址 + 文件查找规则
│   └── testing-guide.md              ← 测试与部署指引（编译部署 + 排障）
├── rules/
│   ├── refactor-command.mdc          ← 重构命令与项目定位规则
│   └── trpc-go-refactor.mdc          ← 自动加载的编码规则
└── bundled-skills/
    └── observe/                      ← 生产监控、日志查询、告警分析

3. 知识库与阶段的映射

有了三层加载机制和文件骨架，还要明确每份知识在哪个阶段使用，确保按需加载、精准投放。

二、每个阶段都执行什么？

知识库解决的是"AI 该知道什么"，接下来是"AI 该怎么一步步做"。

整个重构按 5 个阶段线性推进 ，每个阶段都是人发起命令 → AI 执行 → 人审查后再推进，阶段之间支持回退。

阶段 1：链路分析 & 生成方案

链路分析是决定重构质量的关键一步。

• Step 1 · 拉取依赖代码 ：AI 读取 project-config.md ，将老项目和参考项目克隆到 ../_refactor_deps/ ，与当前工作目录隔离。
• Step 2 · 全量链路分析 ：AI 按四层顺序追踪完整调用链，关键是要 深入方法内部 ，逐层展开到最终 DB 操作、缓存读写、RPC 调用和 MQ 发送。只看调用关系会漏掉两类信息：

   
   
   
   入口层 (回调处理)
  1. 参数解析 — 深入内部：
     → 外层报文解析 → 解密 → 内层报文解析 → 产出完整字段列表（= 新接口 Proto Req 的来源）
  2. 限流校验 — 深入内部：必传校验、时间格式校验、限流阈值
  3. 单号反查 — 深入内部：特定场景按业务单号反查，常规场景直接复用
  4. 调用下游 — 深入内部看参数组装
      ▼
核心业务层 (状态处理)
  1. 加锁读取 — SELECT FOR UPDATE，读取 20+ 字段
  2. 状态处理 — 10+ switch 分支逐一展开，每个分支的转换规则和前置条件
  3. 写回更新 — UPDATE / INSERT 各字段

• Step 3 · Proto GAP 分析 ：将老链路所需下游能力与现有 Proto 接口逐一比对，标记状态并列出待补充字段。这张表决定 Proto 改动范围和 BO 实现排期。

  

• Step 4 · 生成方案 + 拆分任务 ：按模板生成完整方案，覆盖链路概述、数据依赖、DDD 归属映射、Proto 定义、实现方案、优先级与风险等 11 章节。其中 DDD 归属映射 最核心——将老链路每个步骤明确归到新架构的 Gateway/AO/BO 层。方案生成后自动跑完整性检查，确认章节齐全、旧步骤有归属、状态机分支无遗漏，再交人审查。

阶段 2：审查方案

方案再完整也需人工把关，这是 人机协作最密集 的阶段。审查聚焦：归属映射是否准确、Proto 字段是否完整、状态机分支有无遗漏、GAP 如何处理（新增接口还是扩展已有接口）。

有些判断只能靠业务经验——分支是否废弃、字段能否安全去掉、灰度维度如何切分——代码里读不出来。AI 的职责是把这些取舍整理成清晰的选择题， 决策权在人 。

审查中 AI 会主动提问关键决策点，例如：“下游是否需要返回明细记录用于构建 MQ 消息？”" channel_type 影响多个状态机分支，老 Proto 没有此字段，是否补充？"

每轮最多提 5 个问题以控制成本。所有澄清与决定记录在 clarifications.md ，确保换人接手或切换会话时，决策过程可追溯。

阶段 3：实施编码

方案审查通过、Proto 已提交并生成桩代码后，进入编码阶段。AI 按项目维度逐个落地，遵循方案中的 DDD 分层设计。

分层架构 ：调用方向为 Gateway → Service → Logic → Repo ，领域层 Entity 不依赖 tRPC 等框架，Logic 通过接口使用 Repo 能力，确保业务逻辑不被协议和基础设施污染。CR 阶段会专门检查分层边界。

Logic 层设计模式 （以 AO 服务为例）：采用 Builder 链式编排，每个 WithXxx 是一个独立、可插拔的步骤：

   
   
   
   flowData, err := builder.
    WithParamValidation().        // ① 参数校验
    WithResolveOrderNo().         // ② 确定业务单号（特定场景反查）
    WithQueryOrderDetail().       // ③ 查详情
    WithCheckOrderState().        // ④ 状态校验（幂等）
    WithVerifyTicket().           // ⑤ 票据验证（非关键，失败不终止）
    WithDetermineTargetStates().  // ⑥ 确定目标状态
    Build()

收益：非关键步骤失败不阻塞主流程；新增/删除步骤只需增删一行 WithXxx ； FlowData 私有字段配合 Getter/Setter，步骤间只能按约定接口传参，中间状态不被随意改写。

验证循环 ：每完成一个逻辑单元（一个 WithXxx 或 repo 方法），立即执行 go build → go vet → 结构验证 ，通过后继续。同一错误连续修复 3 次仍未通过则停下交人，避免空转。

阶段 4：代码 CR

代码写完不等于写对。CR 阶段回答两个核心问题： 写得规不规范？方案有没有落全？

AI 按 60+ 检查点从三个维度自查：

• 设计层 ：DDD 分层是否合理、依赖方向是否单向、repo 是否通过接口隔离实现细节
• 实现层 ：错误处理是否规范包装、日志是否携带 traceID、Context 是否全链路透传
• 规范层 ：缩写大小写、导出方法 GoDoc、import 分组

此外还需做 重构完整性评估 ：方案 11 章节是否全部实现、归属映射中每个旧步骤是否有对应新代码、状态机分支是否全覆盖、Proto 是否与方案一致。

这些检查通过后，代码才具备进入测试阶段的基础。

阶段 5：自动化测试闭环

静态检查过了，还得用真实运行验证行为是否和老服务一致。这是 自动化程度最高 的阶段，AI 从构造数据到排查问题一条龙做完：

1. 编译部署 ：用部署 CLI 执行 build → deploy
2. 编写 client ：用正确的协议和端口，靠命令行参数切换不同业务场景
3. 构造测试数据 ：复用 DB 里已有记录并重置状态，关键字段用真实值
4. 自动修复循环 ：运行 client → 报错 → 查日志 → 改代码 → 重新部署 → 重测，最多 5 轮，超限就暂停并汇总给人决策
5. 排障 ：用可观测平台搜索日志、追踪调用链、查看错误码

这几步里最容易被低估的是 构造测试数据 。交易类接口对数据真实性很敏感，状态字段要落在能触发目标分支的取值上，单号要和下游系统里的真实记录对得上，编码、金额、笔数之间还有一致性约束。更稳妥的办法是 复用库里已有的真实记录，只把状态字段重置到起点 ，而不是凭空造一条。

自动修复循环是这个阶段的核心。一次典型循环：运行 client 报错 → 到可观测平台按 traceID 拉完整日志和调用链 → 判断是代码 bug、配置问题还是数据问题 → 改完重新部署再跑一遍。整个过程 AI 自己闭环，人只在超过 5 轮仍未解决时介入。

三、它凭什么这么可靠？

—— Harness Engineering 五机制

这五个机制合在一起，让 AI 做到了：知识加载精准、流程不中断、结果有校验、成本不失控、过程可追溯。前面各个阶段的例子其实都能对上号——分析阶段的"文件最多读 2 次"是成本控制，编码阶段的"错误修 3 次不过就交人"是验证循环加成本控制，测试阶段的"按 traceID 拉全链路日志"是可观测性。这些约束不是额外加的，而是直接写进了每个阶段的操作里。

四、测试能学到些什么？

前面聊了这么多，可能有宝子要问了： 这好像是开发的重构工具，跟咱测试有啥关系？

别急，这套 Skill 从头到尾都在透露一个信号—— 重构时代，测试的角色正在被重新定义 。咱们至少能从中带走 5 个实打实的收获。

🗺️ 收获 1：测试设计有了"精确地图"

以前做重构项目的测试，我们最怕 不知道里面有多少个状态机分支、多少种隐式校验 ，拿着接口文档就开始盲测，漏测是常态。

这套 Skill 的阶段 1 会产出 DDD 归属映射表 和 全量分支清单 ——老链路的每一步都拆得清清楚楚。

我们可以拿来干嘛？ 直接当测试用例设计的底图，做 覆盖矩阵 ：每一行老步骤对应一条 / 多条用例，确保新代码没漏掉任何分支。审查方案时还能指着表问：“这个 default 分支怎么触发？有对应的测试数据吗？”

💾 收获 2：测试数据的"黄金法则"

阶段 5 里提到一个关键策略： 复用 DB 里已有的真实记录，只重置状态字段到起点，而不是凭空造一条。

太实在了。交易类接口对数据真实性极其敏感——金额、渠道、编码、笔数之间都有一致性约束，随便造的数据根本进不了目标分支。

我们可以怎么做？ 建立一套"基线数据集"，从生产脱敏数据里挑几条典型记录，标注当前状态，执行用例前用脚本重置到起始状态，跑完再校验终态。省时省力还准确。

🔍 收获 3：测试左移有了具体抓手

阶段 2 明确说"方案再完整也需人工把关"“决策权在人”。

这意味着什么？ 测试不用等到提测才介入 。方案审查阶段，咱们就可以带着三个问题杀进去：

1. 日志带 traceID 吗？ （不然出问题怎么查？）
2. 错误码细分了吗？ （自动化断言靠它）
3. 非关键步骤挂了怎么降级？ （异常场景怎么设计？）

这些问题不涉及业务深度，但直接决定了"这代码好不好测"。 测试左移不是口号，是具体动作。

🔄 收获 4：测试执行有了"闭环方法论"

阶段 5 的自动修复循环特别值得细品：跑 client → 报错 → 按 traceID 拉全链路日志 → 定位是代码 / 配置 / 数据问题 → 改完重测，最多 5 轮。

这套流程给咱们的启发是： 发现问题别急着提单，先利用可观测平台做初步归因 。环境配置问题、数据问题，很多时候我们自己就能判断，不用等开发来回拉扯。

同时，"最多 5 轮自动修复，超限暂停交人"也是个很好的 止损策略 ——别在同一个坑里无限空转，该停就停。

🏗️ 收获 5：可测试性设计是可以前置的

阶段 3 的 Builder 链式编排，每个 WithXxx 都是独立、可插拔的步骤。这意味着 每个步骤都可以单独测试 ，不用跑完整条链路。

还有"非关键步骤失败不终止主流程"——这类降级逻辑极容易被忽略，但影响面可能很大。

我们的关注点可以前置到设计阶段 ：代码还没写，就能判断它是不是"好测"的。这在评审时就是话语权。

以前测试在重构项目里，角色普遍比较被动——代码提测了才介入，发现问题了返工成本已经大了。

但这篇文章让人看到另一种可能性：测试可以提前进场，用方案做地图，用数据做武器，用可观测性做闭环。 重构不光是开发的事，测试越早介入，踩坑越少。

五、话题讨论

讨论1：你参与过的重构项目中，最大的测试难题是什么？

讨论2：你在测试过程中有用过 测试用生产脱敏数据吗，有没有过翻车事件？

以上话题，任选其一，欢迎评论区留言，小编会在下下周一（2026年9月7日）下午，选取1位“关注+点赞+留言”的幸运用户，送出《 Claude Code实战–Harness工程至道 》1本，快来评论区互动吧~