---
name: defend-my-work
description: >-
  当使用者要对外交付一项（多由 agent 写成的）工作、即将被人追问或质疑，说「给我一份
  FAQ」「帮我准备答辩」「我要能扛住提问」时使用：产出一份给使用者本人深入理解、自测的问答资料，不是给团队看的文档。
---
# 答辩 FAQ：让我真懂自己交付的东西

读者是使用者本人，不是同事。目标：使用者在对外交付、被追问和挑战时，每个问题都能凭真实理解答上来，而不是复述 agent 的结论。重度依赖 agent 后，使用者对细节失控，这份资料要把失控的部分找出来并补上。

## 1. 圈定范围
- 范围是使用者点名的工作（仓库、分支、MR、功能）。没点名时，用当前分支相对基线分支的 diff，加上相关的提交说明、MR 描述和对话记录。
- 用一两句话复述这项工作「对外承诺了什么」和「交给谁」。拿不准就问一次，不要猜。
- 识别听众：评审人、产品、测试、上级、客户。不同听众问的问题不同，出题时按听众分组。

## 2. 先摸清事实，再出题
- 读真实代码和提交，弄清机制（参考 pstack `how` 的做法）和动机（参考 `why`：提交、MR 讨论、issue、文档）。
- 每条事实标来源：文件和行号、提交、测试、命令输出。分清「已证实」「从代码推断」「不知道」。不编原因，找不到动机就写「没有记录」。

## 3. 以挑战者身份出题
站在最难缠的对方立场，专挑使用者最可能答不上来的问题。至少覆盖：
- 是什么：一句话说清它做了什么、改了哪里、没改哪里。
- 为什么这样做：每个关键决策的理由。
- 为什么不那样做：被放弃或没考虑的替代方案，各自输在哪。
- 边界和风险：哪些输入、环境、并发、权限、数据量下会出问题；影响到哪些别的模块（参考 `blast-radius`）。
- 怎么证明是对的：跑过哪些测试，没跑哪些，覆盖不到什么。
- 坏了怎么办：怎么发现、怎么回滚、谁受影响。
- 成本：性能、维护、迁移、对后续工作的约束。
- 尖锐质疑：「这是不是 AI 写的你自己懂吗」「这段为什么这么复杂」「为什么拖了这么久」「还剩哪些尾巴」这类带情绪的问题，也要给出诚实、站得住的回答方式。

能跑就跑：对拿不准的说法，用命令、测试或小脚本当场验证（参考 `interrogate`：只有跑出来的结论才算数），把结果写进答案。

## 4. 每题写一个使用者讲得出口的答案
- 先给一两句口头能说的短答，再给展开：机制和原因，用人话讲，不堆函数名。
- 附可以指给对方看的证据位置。
- 不确定的明说：「目前不知道，需要查 X」，不要替使用者编一个听起来对的答案。

## 5. 单独列出「我没掌握的部分」
- 把 agent 做了、但使用者大概率不清楚的细节单独成节：隐含的假设、顺手改的地方、绕过的问题、临时方案、TODO、没测的路径。
- 每条说明为什么值得补课，以及最快弄懂它的办法（读哪段代码、跑哪个命令）。
- 这一节是这份资料最重要的产出。

## 6. 自测
- 末尾给一组只有问题、没有答案的自测题，按难度排列，供使用者先自己回答再对照。
- 不做表演式提问，不催促；使用者想深入哪题，再按 `teach` 的方式展开讲。

## 输出
一份 Markdown（或使用者指定的格式），结构：
1. 这项工作一句话 + 对外承诺
2. 按听众分组的问答（短答、展开、证据）
3. 我没掌握的部分
4. 自测题
5. 未证实和需要补查的清单

写作用使用者的语言，直白、短句、先结论；去掉 AI 腔（参考 `unslop`）。不改代码，不对外发送，只交给使用者本人。

交付时用一句话提醒使用者：这份资料最有效的用法是亲自读懂第 3 节「我没掌握的部分」，而不是只看问答。