性能调查：带证据的定向排查

💡 一句话总结：用 Grok Bot 建立你的 AI 性能排查流水线 —— 连上可观测性、分析和事故工具，让 Bot 自己看仪表盘和 traces，定位置信度最高的热点，产出带截图和直达链接、事实与假设分开的短报告，全程不改警报、不动生产设置。

这是路线 B（程序员）的第二课，和Bug 复现出自同一页官方角色、用同一套官方六步法。本课对应官方 use-cases 页 8 个角色里的 Product performance（性能调查专员）。官方给它的定位是：带证据的定向性能调查——不是「帮你猜猜为什么变慢」，而是每次调查都带着可回溯的证据指向一个热点。官方点名的三类连接是可观测性、分析和事故工具。

整课约 12 分钟。官方对这个角色还有一条特别要求：routine 用于周期性健康报告，不做无人监督的生产变更——本课第 6 步专门讲怎么守住这条线。

学完你能做什么

• 建一个「性能调查专员」Bot：连接可观测性、分析和事故工具，把「线上变慢了」变成带证据的定向调查
• 让 Bot 自己看仪表盘和 traces，定位置信度最高的热点，回一份短报告：截图 + 直达链接，事实和假设分开
• 守住官方两条红线：不改警报、不动生产设置——变更建议写进报告，执行留在审批
• 把调查流程存成 skill 按名字复跑；每周健康报告交给 routine（可选）

为什么用 Grok Bot，而不是网页版 AI？

能力	网页版 AI	Grok Bot
看得到你的监控数据	❌ 靠你截图加口述，AI 看不到仪表盘	✅ 连可观测性/分析/事故工具，自己看仪表盘和 traces
证据可回溯	❌ 结论无从验证，只能选择相信	✅ 每个结论带直达链接和截图，你逐条点开核对
事实和假设分开	❌ 一锅粥，「我觉得」和「数据显示」混着写	✅ 官方起步提示词就要求把事实和假设分开
记得住调查口径	❌ 每次事故重新交代一遍看哪些面板	✅ 调查流程存 skill，口径一致，按名字复跑
周期性健康报告	❌ 每周手动导数据、拼周报	✅ 定时 routine 到点自己跑，报告贴在对话里等你审

你现在的困境

• 「昨天上线后 checkout 变慢了」——你在五六个仪表盘之间来回切，半天定位不到热点
• 事故群里人人都在猜：是数据库？是缓存？是新版本？没有证据，只有嗓门
• 调查报告写完就散：截图没存、链接没留、时间戳没有，复盘时对不上数

什么时候用这一招

当你需要：

• 把「XX 变慢了」变成一次带证据的定向 AI 性能排查：看仪表盘和 traces，定位置信度最高的热点
• 让「接事件 → 看面板 → 圈热点 → 写报告」这条流水线跑起来，你只审报告
• 报告里的每个结论都能回溯：直达链接、截图、时间戳，事实和假设分开

而且不想：

• 自己挨个开仪表盘、截截图、拼报告
• 事故群里靠猜定位问题
• AI 一句「可能是数据库慢」却拿不出任何证据

🎒 开始前的准备

• 读完 3.2 Skills 与示教——本课第 5 步要把调查流程存成 skill，这也是多数场景页的通用前置
• 有一个能派活的 Bot：还没有就先去 1.5 创建你的第一个 Bot
• 可观测性工具的访问权（仪表盘和 traces 系统——连接器或网页版都行）
• 分析和事故工具的访问权（官方事件触发源里点名的 Sentry、PagerDuty 这类，或你们自己的事故通道）
• 一次真实的性能事件当练手输入（比如「昨天发布后某接口延迟上升」）
• 大约 12 分钟，外加第一份报告出来后的一次人工反馈

跟我做

第 1 步：把性能调查专员的职责和边界写进 Bot 的描述

为什么：官方六步法的第一步，就是把职责、源系统、输出格式和常设边界写进 Bot 的描述——这个角色的两条红线（不改警报、不动生产设置）也要写死在这里。

怎么做：新建或打开一个 Bot（侧栏 + → Create a Bot），把描述写成下面这样：

你是我的性能调查专员，负责带证据的定向性能调查。
数据源：可观测性工具（仪表盘、traces）、分析工具、事故工具。
输出格式：短报告——置信度最高的热点、支撑证据（截图 + 直达链接）、
建议的下一步；事实和假设分开写，无法核实的单独列出。
常设边界：调查只读——不改警报、不动生产设置；
任何变更只写建议，执行由我审批。

你应该看到：描述保存在这个 Bot 的详情页里。边界写在这里，意味着以后每一次调查都遵守同一条红线。

第 2 步：连接可观测性、分析和事故工具

为什么：调查里的事实只能来自你连接的系统——官方给这个角色点名的三类连接就是：可观测性、分析、事故工具。

怎么做：三类工具分别处理，5 步连接法的细节见 2.5 连接应用：

1. 有连接器的工具：先在 Connect apps 里搜；想让 Bot 代装就直接说「Add the Linear app」这类话（官方文档的例子是 Linear，Bot 会搜索目录、装好应用、需要登录时给你一张 Connect 卡）
2. 没有连接器的工具：让 Bot 用云电脑浏览器打开网页版，登录凭据存进 Vault，Bot 代填但看不到值
3. 提供 MCP server 的工具：让 Bot 按 URL 添加
4. 只有公司内网才能打开的仪表盘：打开 Settings → Computer → Route traffic through this computer，让 Bot 浏览器走你桌面的网络和 IP（细节见 5.3 流量路由与本地执行）
5. 授权中断就点 Reconnect（应用上）或 Reopen（聊天里的连接卡上）找回登录页

你应该看到：三类工具 Bot 都能打开。注意 Added ≠ 已登录——显示 Needs auth 或 Disconnected 时要点 Authenticate 重新授权；内网路由生效后，内部仪表盘在 Bot 的浏览器里能正常加载（解析到私有/VPN 地址的站点默认封，需要组织放行——被拦时这个设置会显示本次拦截数）。

第 3 步：用官方 starter prompt 跑第一次 AI 性能排查

为什么：官方 starter prompt 刻意停在只读调查的 review point——先验证报告质量，再谈自动化。

怎么做：把事件背景（什么指标、从什么时候开始、期间有过什么变更）随消息发给 Bot，再发送这段官方 Product performance starter prompt 的中文化版本：

调查昨天发布后 checkout 延迟上升的问题。
查看仪表盘和 traces，定位置信度最高的热点，
回一份简短的调查报告，带截图和直达链接。
事实和假设分开写。不要改警报，不要动生产设置。

你应该看到：Bot 在右侧 computer preview 里逐个打开仪表盘、翻 traces——点开预览能看它的点击和导航。最后回你一份短报告，截图以卡片形式附在回复里，点开可预览。一份合格的报告包含：

• 置信度最高的热点（一句话说清「慢在哪」）
• 支撑证据：截图 + 直达链接（点开能回到源面板）
• 事实和假设分开（「数据显示」和「我推断」不混写）
• 建议的下一步（只是建议，不执行）
• 无法核实的内容（官方留证据清单的要求：明确列出，不硬编）

💡 这就是 Grok Bot 的独有价值

网页版 AI 只能靠你截图口述，结论无从验证。Grok Bot 自己登录监控工具看仪表盘和 traces，证据是它亲眼看的、带直达链接可回溯——你逐条点开就能核对，事故群里再也不用靠嗓门定位问题。

第 4 步：把报告改到可审——证据逐条核

为什么：官方六步法要求把结果改到「不用你盯也能审」；官方留证据清单还特别提醒：快速变化的数据不能只靠截图。

怎么做：逐条核对 Bot 的报告——

1. 每条直达链接点开，能回到源面板、对上报告里的数字
2. 截图带相关状态（时间范围、服务名、异常段可见）
3. 时间戳和时区写清了（复盘对不上数，多半栽在这）
4. 快变的指标（延迟曲线、QPS 这类）有源链接或导出，不只一张截图——官方原话：「Do not rely on a screenshot alone for rapidly changing data」
5. 事实和假设分开了吗？不合格就打回，让 Bot 修订现有报告，而不是另写一份

你应该看到：改过几轮后，报告扫一眼就能审——每个结论都挂着证据，事实和假设分得清。

第 5 步：存成「性能调查」skill，换一次事件测一遍

为什么：官方六步法第四步：把跑通的流程存成 skill，并用第二份输入测一遍。

怎么做：发送下面这段：

把刚才性能调查的完整流程存成 skill，名字叫「性能调查」。
包括：源系统（仪表盘、traces、事故工具）、调查步骤、
输出格式（热点 + 证据 + 事实假设分离 + 建议下一步），
以及「不改警报、不动生产设置、变更只写建议」这三条规则。

官方说一个有用的 skill 要说清六件事：何时用、需要什么输入和权限、工作顺序、怎么校验结果、返回什么、什么需要审批。存好之后在任何对话里按名字要它——直接说「运行性能调查 skill」就能调用（@ 是给 Bots、群组、routines 和应用的，不出技能）。

你应该看到：Bot 确认 skill 已保存。官方要求用第二份输入测一遍：换一次性能事件（另一次延迟上升、一个报错率飙升）再跑，核对报告还稳不稳。私有 skill 库全 Bot 共享，保存细节见 3.2 Skills 与示教。

第 6 步：routine 只做周期性健康报告，不做生产变更

为什么：官方对这个角色的特别要求原话是「Use a routine for a recurring health report, not for unsupervised production changes」——routine 的正确用途是到点出报告，不是趁你睡觉改生产。

怎么做：发送下面这段：

每周一早上 9 点运行「性能调查」skill，产出一份健康报告：
核心指标过去一周的趋势、异常段、值得关注的早期信号。
报告贴在这个对话里等我审。数据缺失就说明缺什么，不要猜。

发出后，跟 Bot 把官方确认清单的六项过一遍：归属哪个 Bot、时间和时区、输入源、期望结果、审批边界、数据缺失怎么办——对不上就纠正它。

你应该看到：routine 出现在这个 Bot 的 routines 里。新 routine 不立即跑，要等下一个时间点——想马上验证就用 Test。routine 在云端执行，合上电脑也跑；每次 run 都消耗用量，健康报告一周一跑用量可控。

审批线在这步一起守住：就算哪天你想让 routine 响应事故自动跑，产出也只能是报告——改警报、动生产设置是外部动作，永远留在审批后面。routine 触发的审批卡 30 分钟没人处理会过期，所以 routine 别配需要审批的动作。审批规则细节见 3.1 审批与 Auto Review。

📋 魔法 Prompt

📝 定向性能调查（官方 starter prompt 结构版）

预期效果：Bot 回一份短报告——热点是它看仪表盘和 traces 定位出来的，证据带直达链接，事实和假设分开，你可以逐条核对。

## 角色
你是我的性能调查专员，负责带证据的定向性能调查。
## 任务
调查这次性能事件，定位置信度最高的热点，产出短报告。
## 输入信息
### 必填项
- 事件描述：【什么指标、什么现象、从什么时候开始】
- 时间范围：【调查覆盖的时间段】
- 期间变更：【这段时间内上过什么版本、改过什么配置】
### 选填项
- 重点怀疑服务：【优先查看的服务或面板?】
- 异常口径：【判定异常的标准，如 P95 超过多少毫秒?】
## 输出规范
短报告：置信度最高的热点（一句话）、支撑证据（截图 + 直达链接）、
事实和假设分段、建议的下一步、无法核实的内容清单。
## 约束条件
- ✅ 每个结论挂直达链接，点开能回到源面板
- ✅ 事实和假设分开写，无法核实的明确列出
- ❌ 不改警报、不动生产设置
- ❌ 快变数据不只给截图，留源链接或导出

📝 每周健康报告（routine 版）

预期效果：每周一自动出现在对话里的健康报告——趋势、异常段、早期信号，你扫一眼就知道这周有没有要盯的。

## 角色
你是我的性能调查专员，每周例行产出健康报告。
## 任务
汇总过去一周核心指标，产出健康报告贴在对话里。
## 输入信息
### 必填项
- 核心面板清单：【每周必看的仪表盘和 traces 列表】
- 时间范围：【过去一周，注意时区】
### 选填项
- 上周遗留项：【上周报告里标了继续观察的条目?】
## 输出规范
健康报告：核心指标周趋势、异常时间段（带直达链接）、
值得关注的早期信号、与上周报告的对比。
## 约束条件
- ✅ 数据缺失就写明缺什么，不猜
- ✅ 只产报告，所有变更留给我审批
- ❌ 不改警报
- ❌ 不动生产设置

🔧 调查报告质量反馈（把口径写进 skill）

预期效果：你指出这份报告缺什么，Bot 把要求写进「性能调查」skill，下一份明显更稳。

## 角色
你是我的性能调查专员，刚交出一份调查报告。
## 任务
对照我的反馈，更新「性能调查」skill 的报告口径。
## 输入信息
### 必填项
- 这份报告的问题：【链接打不开 / 截图没带时间范围 / 事实假设混写……】
- 正确的口径：【你希望以后每份报告都做到的】
### 选填项
- 特定指标的额外要求：【比如延迟类必须带 P95 数值和时区?】
## 输出规范
先复述你总结出的新口径，我确认后再更新 skill。
## 约束条件
- ✅ 口径写进 skill，下次调查开始生效
- ✅ 只补口径，不改审批边界
- ❌ 不为了省事砍掉证据项

检查点 ✅

• 三类工具 Bot 都能打开：连接器显示 Installed（不是 Needs auth / Disconnected），内网仪表盘路由生效
• 第一份报告齐全：热点、截图、直达链接、事实假设分开、建议下一步、无法核实清单
• 直达链接逐条点开能回溯；快变指标有源链接或导出，不只截图
• 全程只读：没改警报、没动生产设置；变更只出现在「建议」里
• 调查流程存成 skill，换一次事件按名字能复跑；routine 只出健康报告

踩坑提醒

❌ 让 Bot「顺手」调一下警报阈值

官方 starter prompt 的边界原话：「Do not change alerts or production settings」；官方对 routine 的定位原话：「not for unsupervised production changes」。正确做法：变更建议写进报告，执行留在审批——你审过再动，出事有据可查。

❌ 一张仪表盘截图当全部证据

官方留证据清单明确说：「Do not rely on a screenshot alone for rapidly changing data」。性能数据变化快，截图只是某一秒的快照。正确做法：每个结论挂直达链接，快变指标让 Bot 附源系统的链接或导出。

❌ 事实和假设混在一起写

官方 starter prompt 专门要求「Separate facts from hypotheses」。「数据显示 P95 上升 300ms」是事实，「多半是新版本的数据库查询」是假设——混在一起，读者会把假设当结论。正确做法：按官方五分离让 Bot 分段写——事实、假设、已完成、待审批、未解决。

❌ 内部监控工具打不开就放弃

Bot 的云电脑在云上，只有公司内网才能打开的仪表盘默认看不到。官方解法：Settings → Computer → Route traffic through this computer，让 Bot 浏览器走你桌面的网络和 IP。注意两点：解析到私有/VPN 地址的站点默认封，需要组织放行；同一时间只有一台电脑能路由。细节见 5.3 流量路由与本地执行。

进阶技巧（可选）

• 事故自动出调查草稿：官方支持的事件触发源包括 Sentry、PagerDuty——给「性能调查」skill 配一个事件 routine，事故一进来就自动产出调查报告贴在对话里。边界不变：报告可以自动出，变更永远留审批。见 3.3 Routines。
• 健康报告归档成 Pages：让 Bot 把每周健康报告整理成 Pages 页面（官方定位：报告这类可读页面），存进 Bot 的 Library——对比上周趋势，比翻聊天记录快。见 2.2 文件与可审阅结果。
• 和 Bug 复现接力：调查定位到具体版本或功能后，把报告连同证据交给 B1 Bug 复现——那边的流程会把它变成开发能直接定位的复现包。
• 要证据变成对话习惯：官方高效对话清单里就有「要证据」这一条——平时和 Bot 对话也坚持每个结论带链接，报告质量会稳很多。

本课小结

• ✅ 一个「性能调查专员」Bot + 三类数据源（可观测性、分析、事故工具），把性能事件变成带证据的定向 AI 性能排查
• ✅ 用官方 starter prompt 起步：看仪表盘和 traces、定位最高置信度热点、短报告带截图和直达链接、事实假设分开
• ✅ 守住两条官方红线：不改警报、不动生产设置；变更只写建议，执行留审批
• ✅ 改到可审存 skill，换一次事件测一遍；routine 只做周期性健康报告

关键项	本课的值
Bot 角色	Product performance（性能调查专员）——带证据的定向性能调查
连接的应用	可观测性（仪表盘/traces）、分析、事故工具；内网工具走本地路由
起步 prompt	官方 Product performance starter prompt（中文化版）
skill	「性能调查」（官方六要素，按名字调用，全 Bot 共享）
routine	每周健康报告（可选）；事件触发只出报告，不做生产变更
审批线	不改警报、不动生产设置；变更执行永远留在审批

下一课预告

下一课 B3 云电脑当开发环境：调查和复现都跑顺之后，认识 Bot 干活的这台机器本身。你会学到：

• /workspace 持久工作区：文件放哪、跨 Bot 怎么共享
• 让 Bot 在云电脑上跑脚本、装依赖、验证环境
• node_modules、venv 这类目录不在同步范围，更新后要重装
• 磁盘将满时 Bot 会怎么处理（先报告最大文件，征得同意才删）