# WorkBuddy 实战：把 AI 当调试搭档，而不是搜索引擎

> 案例背景：一台 ThinkPad C14 Gen 1 Chromebook（板号 **primus**，平台 **brya**，Alder Lake-P），
> CPU 是 `ID 906a1` 的 **Q0 工程样片**。刷 MrChromebox 固件后黑屏，前后排查约三周。
>
> 本文不是救砖教程。救砖的细节我全部压掉了——这里只讲一件事：
> **在这类"现象和原因之间没有直接映射"的问题上，WorkBuddy 具体能帮上什么忙。**
>
> 顺带说一句：这台机器**到现在也没修好**。但三周里最有价值的产出不是修好了什么，
> 而是**排除了一个错误前提**。后面第四节会讲这件事，那是全文最值得带走的部分。

---

## 一、为什么这类问题适合拿来谈协作

这个案子有三层信息源：

- 几百行 coreboot 串口日志
- 一组 port80 POST code 序列
- 一份 32MB 的完整固件二进制

难点在于**现象和原因之间没有直接映射**。黑屏可能是没上电、可能是没过内存训练、可能只是屏线。同样的"刷完黑屏"，背后可能是三种完全不同的故障。

这种问题不适合问搜索引擎——你搜不到"我的机器为什么黑屏"。它适合的是一个能陪你读数据、查源码、写脚本、并且敢质疑你前提的搭档。
![001001.png](https://developer.qcloudimg.com/http-save/yehe-12728962/b8c0ee2e426d2c97d709cdc4a4d42e1d.png)

*图 1 — GSC console 启动现场。SuzyQable 接上后第一个出现的串口是 GSC/Cr50，**不是 AP**。后续所有判断都从这一段开始读。*

下面五个用法，按价值从低到高排。

---

## 二、用法一：让它做日志分诊，不要让它总结日志

**常见但没用的问法**："帮我看看这段日志有什么问题。"

这只会得到一份摘要——而摘要救不了你，你自己也读得懂摘要。

**有用的问法**："这段日志的**最后一行**是什么？它对应源码里哪个函数？下一句本该执行什么？"

实际案例。开了串口的固件刷上去后，日志停在这行：

```text
[DEBUG]  FMAP: area RW_MRC_CACHE found @ 1bb0000 (65536 bytes)
[NOTE ]  MRC: no data in 'RW_MRC_CACHE'
[DEBUG]  SPD index = 2
[INFO ]  SPD: module type is LPDDR4X
[INFO ]  SPD: module size is 2048 MB (per channel)
[DEBUG]  rt_debug: CPU Trace Hub Mode: 0 PCH Trace Hub Mode: 0
        ← 到此为止
```

它的回答：这一行是 `platform_fsp_memory_init_params_cb()`（`alderlake/romstage/fsp_params.c`）的最后一句，紧接着就要进 `fsp_raminit()`。所以卡点在 **FSP-M 的 `MemoryInit()` 内部**。

这就把"日志在这里断了"变成了"卡在哪个函数的哪一步"——信息量完全不同。

它还顺手防了一次误判：coreboot 里有两处会打印 `rt_debug`，另一处属于 CSE 初始化路径。我们遇到的是**第一句**，所以 CSE 那条线可以直接排除。

> **可迁移的做法**：问"最后一行在哪"，别问"有什么问题"。
> 日志的价值集中在**断点**，不在整体。

---

## 三、用法二：同时走两条独立路径，别只信一条

一个结论如果只靠一条证据链支撑，很容易自证。让 AI 分别用**互不依赖的方法**验证同一件事，再比对结果，成本很低但收益很大。

这个案子里，卡点位置走了两条完全不同的路：

**路径 A —— 源码符号**
日志末行 → `platform_fsp_memory_init_params_cb()` → 下一句 `fsp_raminit()` → 卡在 MRC 内部。

**路径 B —— 二进制反查**
EC console 读到的 port80 终值是 `dd28`：

```text
Port 80 writes:
  00 02 b7f d800 de03 de23 d001 ... da51 da52 dd00 d000 dd03 dd02
  dd20 dd21 dd22 dd11 dd15 dd09 dd23 dd12 dd0c dd27 dd26 dd28 <--new
```

让它在 FSP-M 二进制里找写 0x80 端口的 `out dx, ax` 指令，顺着找到一张 163 项的 `0xddXX` 常量分派表，`dd28` 对应函数文件偏移 `0x89ce5`，栈帧 8608 字节。

**两条路一条靠符号表，一条靠二进制特征，完全独立，都指向 MRC 训练。** 这时候才敢下结论。

顺带它还给了一个"别往这边走"的判断：`dd28` 的栈帧深达 8608 字节，而 FSP-M 是 release 精简版——786KB 的二进制里只有 15KB 字符串，压根没有 MRC 调试串；加上 coreboot 在 Alder Lake 上日志等级被钳到 3，`CONFIG_DEBUG_RAM_SETUP` 选不到。**想靠开日志挖 MRC 内部细节，性价比极低。**

省下的时间很可观。

> **可迁移的做法**：让 AI 用 N 种互不依赖的方法验证同一个结论，比对后再信。
> 顺带问一句"哪条路不值得走"——它说"别走"往往比"走这边"更值钱。

---

## 四、用法三：只读取证——让它写脚本挖数据，别让它猜

手上有一份从砖机读出来的 32MB 固件。想知道里面有什么，靠问是问不出来的。

让它**在只读前提下**写解析脚本：按 IFD 切 Descriptor / ME / BIOS 区，按 FMAP 定位各区域，按 CBFS 抽组件并比对 md5，两份 ROM 之间做区域级 diff。

挖出来的东西：

```text
bad.rom @0x1000000 +0x10 : 4d 52 43 64  ("MRCd")
        size = 63176 (0xF6C8)
        区域分析：0xFF 占 4.9%，0x00 占 55.8%（真实数据特征，非随机/非空白）
        payload sha256 = 8d0349869d93ad0841cb8ea2c0770a635dbb05a5d17597dfac2c121f41cd8cb3
```

这件事的意义在于**零风险**：不刷写、不动硬件、随时能推翻重来。而且脚本是可复用的资产，下次拿到新 ROM 直接再跑一遍。

> **可迁移的做法**：需要"看数据"但直接看代价高或有风险时，
> 让它写解析脚本，而不是让它根据文件名和文档猜。

---

## 五、用法四：让它去找**否定你假设**的证据（最值钱的一个）

这是我认为整个案子里最重要的一课。

三周以来，排查都建立在一个假设上：

> **Q0 工程样片 CPU 与零售版 Intel FSP/MRC 不兼容，所以内存训练必挂。**

这个假设看起来非常硬——`dd28` 卡死、CPU 是 ES、日志里 `ucode: 00000000`（Intel 从未发布 `06-9a-01` 微码，这颗 CPU 永远跑出厂内置那一版）。三点互相印证，逻辑闭环。

于是所有实验都围绕"怎么让 MRC 跑过去"展开：换 FSP 版本、降内存频率、关 SaGv……一轮一轮做，一轮一轮卡在原地。

**后来换了个问法。** 不问"怎么让它跑过去"，而是问：

> **现有数据里，有没有能证伪这个假设的证据？**

然后那份 `MRCd` 缓存就浮出来了——它一直躺在 `bad.rom` 里，只是没人往这个方向看。

推理链条：coreboot **只有**在 FSP-M `MemoryInit()` 返回成功、拿到 MRC HOB 之后，才会把训练数据写进 `RW_MRC_CACHE`。训练中途挂死不会有任何写入，而"缓存无效→清掉重试"的流程还会把整块区域抹成 `0xFF`。

对照实测：

| ROM | `RW_MRC_CACHE` 内容 | 推论 |
|---|---|---|
| `bad.rom`（官方 2606.1，从砖机读出） | **有**，63176 字节真实数据 | 这颗 Q0 用 2606.1 的 FSP-M **训练成功过** |
| 所有本地 4.22 重编译 ROM | **全部 100% `0xFF`** | 每次都走全量冷训练，才会撞 `dd28` |

**"Q0 与零售 MRC 不兼容"不成立。** 真正的变量是**本地重编译产物 vs 官方产物**——相隔约三年的 coreboot 源码、UPD 和配置差异。而官方 2606.1 那条分支"训练通过之后停在哪"，**从来没有人测过**。

三周的注意力全在一棵错误的树上。

> **可迁移的做法（全文最该带走的一条）**：
> 当一个问题卡了很久，让 AI 去旧数据里翻**否定当前假设**的证据，
> 比让它再优化一轮方案划算得多。
>
> 优化方案是在假设内部打转，找反例是在检验假设本身。
> 前者再努力也是在错误的方向上跑。

---

## 六、用法五：把你的判断丢给它，让它找反例

前一节是"让它主动找"，这一节是"你主动递过去"。区别在于：你有具体判断时，直接让它攻。

![002002.png](https://developer.qcloudimg.com/http-save/yehe-12728962/ae0e3fe7f608da716882a41b7edc119c.png)
*图 3 — 把 EC 日志（`G3->S5`、`GPIO_RSMRST_L_PGOOD: 1`、约 10 秒后主动 `S5->G3`）扔给它，它直接给出结论：**check.rom 没有进入 AP 启动阶段，不是"已经启动但屏幕没亮"**——这是我之前差点当成"屏坏了"的判断，差点带偏排查方向。*

这次纠掉了三个：

**误区一：「串口没输出 = 卡在早期阶段」**
不成立。MrChromebox 官方固件和 Google 原厂固件**都没开** `CONFIG_CONSOLE_SERIAL`。`bad.rom` 刷上去串口一片空白，不代表它卡在 bootblock——它只是不说话。
→ 改用 EC console 的 `port80`，这条通道官方固件下也能读，是唯一普适的判据。

**误区二：「刷写失败是救砖的主要难点」**
不成立。四次刷写全部 `Verifying flash... VERIFIED.`，零 Transaction error、零校验 mismatch。

![003003.png](https://developer.qcloudimg.com/http-save/yehe-12728962/58074d33e6143c72878c401a8970a3bf.png)
*图 2 — flashrom 整片刷 32MB 的实际输出。每次 3-5 分钟，全程稳定。真正的坑是**不拔内置电池时 flashrom 认不出闪存**——拔掉就好。*

**误区三：「brya 板必须上 `custom_rst=True`」**
官方文档确实提过，部分 brya 板（KANO / BANSHEE / XOL）用标准命令刷写不可靠，需要走 EC console 关 AP + 拉 S5 rails + 改版 flashrom 命令。primus 同属 brya，一开始以为必撞。
**结果一次都没触发。** 它是"按需启用"，不是"brya 必做"。先按标准命令试，失败再上。

第三条尤其值得记：一个技术上正确的知识点，用错了时机也是负担。

> **可迁移的做法**：把你的结论丢给它，明确要求"找反例"而不是"找支持"。
> 默认状态下它会顺着你说，得把任务反向定义清楚。

---

## 七、什么时候别指望它

边界也说清楚，免得用错地方产生落差：

- **物理操作全得自己来**：接线、拆机、拔电池、按电源键、看电源灯亮不亮。
- **需要实时反馈的硬件交互**：它对"这台机器现在什么状态"没有感知，只能读你喂进去的数据。
- **它对你的设备没有先验**：板号、CPU 步进、闪存型号，全得你提供。它不知道你手上是什么机器。

一句话概括边界：

> **它擅长处理你已经拿到的数据，不擅长替你拿数据。**

所以这套协作方式有个前提——**先把观测通道建起来**。这个案子里，如果不先把三路串口接好、不先把砖机固件读出来存档，后面四节全部无从谈起。数据是地基，AI 是上层。

---

## 八、小结：五条可以直接拿去用的做法

| # | 做法 | 一句话 |
|---|---|---|
| 1 | 问"最后一行在哪"，不问"有什么问题" | 日志的价值集中在断点 |
| 2 | 让 AI 用多条独立路径验证同一结论 | 一条证据链容易自证 |
| 3 | 需要看数据时让它写解析脚本，而不是让它猜 | 只读取证零风险、可复用 |
| 4 | **卡住时让它找证伪证据，不是优化方案** | 优化在假设内打转，找反例在检验假设 |
| 5 | 把你的判断丢给它，明确要求找反例 | 默认它会顺着你说，得反向定义任务 |

再加一条元经验：**AI 最适合的不是替你解决问题，是帮你看清你解决问题的姿势对不对。**

这台机器还没修好，但方向已经从"让 MRC 跑过去"换成了"官方固件那条分支根本没测过"——这个转向本身就是三周里最大的进展。


案例背景：一台 ThinkPad C14 Gen 1 Chromebook（板号 primus，平台 brya，Alder Lake-P）， CPU 是 ID 906a1 的 Q0 工程样片。刷 MrChromebox 固件后黑屏，前后排查约三周。

#WorkBuddy# 实战：把 AI 当调试搭档，而不是搜索引擎

一台 Alder Lake Q0 工程样片的 Chromebook 黑屏三周，最大的收获是排除了错误前提。文章不讲救砖，只讲把 WorkBuddy 当调试搭档的五个用法——问日志断点、多路径交叉验证、只读取证、卡住时找证伪证据而非优化方案、主动递判断找反例。外加一条边界：AI 擅长处理你已有的数据，不擅长替你拿数据。

人工智能

开发工具

职业发展

WorkBuddy实战复盘：当AI调试搭档而非搜索引擎，五条高价值做法直击黑屏难题。日志分诊锁定断点函数、双路径交叉验证、只读取证写脚本、翻旧数据找反例、主动要求攻破假设。卡顿三周的最大产出是排除错误前提，方向从"让MRC跑过去"转向"测试官方固件分支"。

代码解释

WorkBuddy 

WorkBuddy企业版限时双倍 Credits 活动

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

#WorkBuddy# 实战：把 AI 当调试搭档，而不是搜索引擎-腾讯云开发者社区-腾讯云

#WorkBuddy# 实战：把 AI 当调试搭档，而不是搜索引擎

#WorkBuddy# 实战：把 AI 当调试搭档，而不是搜索引擎

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐