鸿蒙应用真机测试 39 个 BUG：我这样搭 AI 修复闭环流水线（回归验证 + 根因合并）

摘要：本文分享作者在鸿蒙 PC 真机（MateBook）上对 MarkPin 应用进行两轮真机测试后，面对 39 个 BUG 如何搭建一套 AI 批量修复的闭环流水线。核心思路是「四件套 + 五步闭环」：用四份文件（测试结果、人设、提示词、修复报告）固定协作契约，让 AI 按「加载人设 → 读测试结果 → 输出计划 → 逐个修复+回归 → 产出报告」五步走完闭环，并强调「模拟器回归通过才算完成」。文中以 [object Object] 家族根因合并修复、任务复选框正则小修复两个真实案例，展示流水线的价值；最后给出能力边界表与三条心得——AI 批量修复的瓶颈是「证明修好了」而非「修」，契约文件化，以及流水线容得下翻车。

MarkPin 第一次真机测试，我拿着测试用例库在鸿蒙 PC 真机（MateBook）上跑了两轮：第一轮 28 个 BUG（BUG-001~028）加 8 个优化项；补测第二轮 33 个用例，21 通过 / 11 失败 / 3 需优化，新增 11 个 BUG（BUG-029~039）。两轮下来，39 个 BUG 排着队等修。

这篇不讲某个具体 bug（那些留给后面几篇），讲的是更重要的东西：面对 39 个待修问题，怎么让 AI 按工程化的方式批量干活，而不是"改一个、崩两个"的救火模式。这套流水线沉淀成了四份文件（人设、提示词、用例库、测试结果模板），一直用到今天——问题日志里现在记满了 46+ 个 BUG，全是这条流水线的产物。

一、问题定义：批量修复的真正瓶颈

第一反应当然是"把 39 个 bug 发给 AI 修"。但之前的教训（第一篇讲过"修一个带出俩"）说明，批量修复的瓶颈不是 AI 的编码能力，而是三件事：

1. 修好了怎么证明？编译通过不等于修好，必须有回归验证；
2. 修一个会不会带崩别人？没有回归保护，修复本身就是风险源；
3. 状态怎么追踪？39 个问题分布在渲染/输入法/文件/导出多个模块，哪个修完了、哪个待真机验证、哪个根因相同可以合并，靠聊天记录记不住。

所以这条流水线的设计目标不是"修得快"，是**“每一单都走完闭环，且全程留痕”**。

二、流水线设计：四件套 + 五步闭环

2.1 四件套（文件化的协作契约）

流水线的基础设施是四个文件，各司其职：

文件	角色	关键规则
TEST_RESULTS_YYYY-MM-DD.md	测试结果（真机实测）	AI 只读不写——测试是人做的，AI 不许代填
MarkPin_修复优化专家人设.md	AI 的角色与纪律	修复前必读，建立稳定角色
MarkPin_修复优化提示词.md	每轮修复的启动指令	五步闭环，任何步骤不得跳过
FIX_REPORT_日期.md	修复报告（AI 产出）	每轮修复后生成，下轮先读避免重复处理

这套设计解决的是"AI 上下文漂移"：每一轮修复从固定的文件状态出发，而不是从上一轮的聊天记忆出发。

2.2 五步闭环（提示词的核心）

每轮修复时段，把提示词投喂给 AI，它必须按序走完五步，输出修复计划后暂停等我确认：

第一步 加载人设 → 确认纪律（回复开头复述 3 条最关键纪律）
第二步 读最新测试结果 → 提取 BUG/OPT 全集 + 读上一轮修复报告避免重复
第三步 输出修复计划（先不改码）→ 按严重度/频率/根因合并排序，标注根因假设
第四步 逐个修复+回归 → 定位根因→改码→编译→模拟器回归→状态更新→影响检查
第五步 产出修复报告 → FIX_REPORT_日期.md

第四步里的回归规则最硬：必须实际在模拟器运行应用、执行该 BUG 关联的用例（用例编号来自测试用例库），观察预期结果——只编译通过不算完成。偶现问题模拟器无法复现时，状态置"已修复待真机验证"，不强行关闭。

2.3 人设里的七条纪律

角色文件里我写死了七条纪律，其中三条最关键：逐个 BUG 走完整闭环（不批量改完一起验）；根因相同的 BUG 合并排查；修复不得破坏既有验收标准，可能影响相邻功能时顺带回归相邻用例。纪律写在文件里而不是写在对话里，是因为对话会被遗忘，文件每次都会被重新加载。

三、解决代码：流水线上的两个真实修复

3.1 一个根因修掉一片：[object Object] 家族

39 个 BUG 里有典型的一类：界面上到处显示 [object Object]——快捷键提示、侧栏按钮、toast 提示，散布在 50+ 处。逐个修是灾难，根因排查后收敛成一句话：鸿蒙资源引用 $r() 返回的是资源对象，直接 String() 化就会变成 [object Object]，必须经资源管理器解析。

修复方案是一个统一的解析函数，然后全项目替换反模式：

// entry/src/main/ets/pages/Index.ets（真实代码，节选）
private resStr(id: number): string {
  const ctx: common.UIAbilityContext | undefined =
    AppStorage.get<common.UIAbilityContext>('abilityContext');
  if (ctx) {
    try {
      return ctx.resourceManager.getStringSync(id);
    } catch (_err) {
      // 降级
    }
  }
  // ...兜底路径
}

对应 R1/R2 批次记录：BUG-019/020（快捷键/侧栏）与 BUG-033（toast）三个编号、50+ 处替换，一次根因修复全部闭环。这正是"根因合并排查"纪律的价值：39 个 BUG 里有不少家族，家族要一起修。

3.2 小修复也要走闭环：任务复选框正则

流水线的另一端是"小到不值一提"的修复，也要走完闭环。例：任务列表语法 - [ ] 没空格时（- []）无法识别为任务项。根因是原正则要求 [x] 带尾空格，放宽为容忍任意空格组合：

// editor-build/src/render/mdParser.ts（真实代码，节选）
// 判断是否为任务列表项：括号内容 `[ xX]*` —— `[]`/`[ ]` 未勾选、
// `[x]`/`[X]`/`[ x]`/`[x ]`/`[ x ]` 勾选、`[y]` 等非任务行（OPT-003）
const taskLineMatch = contentText.match(/^(\s*)([-*+])\s+\[[ xX]*\]/);
const isTaskItem = taskLineMatch !== null;

改一行正则，但闭环一步不少：编译 → 模拟器回归任务列表用例 → 确认 [ ]/[]/[x] 全语义正确 → 状态更新。流水线的意义就在这：修复的质量不取决于改动大小，取决于流程是否完整。

3.3 流水线的"配置文件"：提示词原文节选

流水线本身最重要的"代码"其实是那段启动提示词（qa/MarkPin_修复优化提示词.md），节选硬约束部分：

> 硬约束（再次强调）：
> - 模拟器回归通过才算完成。只编译通过不算。
> - 偶现问题模拟器无法复现时标"待真机验证"不强行关闭。
> - 一次会话处理 2-4 个相关项，不要贪多。
> - 不修改规格书 FR 定义，只改实现。
> - 不关闭"待真机验证"状态的 BUG。

"一次只处理 2-4 个相关项"是吃过亏之后加的：一次喂太多，AI 的注意力摊薄，修复质量明显下降——和第一篇"拆开喂"的心得完全一致。

四、验证与效果

两轮真机测试、39 个 BUG + 11 个 OPT 的消化情况：

• R1 批次：渲染类（公式/表格/列表/代码块 17 个）输入法类（4 个）文件标签类（11 个）+ 优化项 8 个，走完闭环；
• R2 批次：11 个新 BUG 全部进流水线（TOC 渲染、PDF 边距与书签、深色主题跟随、行宽失效等），其中"根因合并"典型案例：BUG-001/002/003/016 四个公式渲染问题实为同一个数学规则边界缺陷，一次重写全部闭环；
• 之后流水线持续运转：紧急批次（白屏、渲染全坏两个致命问题当天修复）、遗留清理批次……到今天问题日志累计 46+ 个 BUG 全程可追溯。

值得一提的是流水线也抓出过 AI 的翻车：早期一次修复中，改动被直接打进构建产物而没有回到源码（手动补丁累积偏差），导致后续预览渲染全部异常——最终以"从源码重建产物 + 清理调试代码"收场，并把"改动必须落在源码、产物只从源码构建"写进了纪律。流水线不保证不翻车，但保证翻车能被追溯。

五、能力边界表

事项	AI 表现	我的结论
单个 BUG 根因定位	稳定，具体到文件/接口/库层	给足上下文（测试结果+用例库）时表现最好
根因合并（一因多果）	表现亮眼	家族式 bug 合并修复是 AI 的强项
批量修复节奏	必须限制在 2-4 个/轮	贪多必散，注意力是稀缺资源
回归验证自觉性	依赖纪律约束	"模拟器回归通过才算完成"必须写进文件反复强调
状态管理（待真机/已关闭）	可靠	文件化状态比对话记忆可靠得多

六、三条心得

1. AI 批量修复的瓶颈是"证明修好了"，不是"修"。把回归验证和状态追踪做成硬性流程，编码能力才能兑现成交付质量；
2. 契约文件化：人设、提示词、用例库、测试结果全是文件——对话会漂移，文件每次都在；
3. 流水线容得下翻车：产物补丁、贪多嚼不烂这些坑都被流水线抓住并沉淀成新纪律，机制的价值在于让错误变成规则。

---

如果你也在用 AI 做批量修复，或者想看 MarkPin 后续，关注专栏。