白話解釋(Plain Explain)
SkillFiles & storageUse when the user asks for a plain-language explanation ("白話", "講重點", "所以呢", "太長"), or when answering a decision question (does this affect me / should I act) whose honest answer would otherwise be buried in file paths, IDs and grep counts. Translates a verified finding to the reader's decision layer without dropping honesty, proportion or traceability.
Available today. Use it from your connected AI after setup.
No other account needed.
Add ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.
Then ask your AI: use the 白話解釋(Plain Explain) skill
What this skill tells your AI
The instructions your AI receives, as published by zenobia000/claude-godzilla-z in .claude/skills/sunnydata-plain-explain/SKILL.md and read by ahel’s review.
何時用
觸發條件與禁用場合是 Rule 管的,見 ../../rules/plain-language-answers.md。
本 Skill 只回答一件事:確定要白話之後,怎麼寫。
前提:白話是最後一步,不是第一步
先查證,再翻譯。 白話會讓結論聽起來更確定——所以底下的證據必須比平常更硬,不是更軟。
順序不可顛倒:
查證(讀碼 / 讀需求與驗收文件 / 實跑)→ 得到有把握的結論 → 翻譯到決策層 → 寫成白話
跳過查證直接白話 = 用流暢的語氣包裝猜測。這是本 Skill 最嚴重的誤用。
五步
1. 先問「他要拿這個答案做什麼」
不是「他問了什麼」,是「他問完之後要決定什麼」。
| 問句 | 表面在問 | 真正要決定的 |
|---|---|---|
| 「需求都有追到測試嗎」 | 追溯狀態 | 我這批能不能過 Gate |
| 「這份 PRD 可以用了嗎」 | 文件狀態 | 我今天能不能開始實作 |
| 「要多久」 | 工期 | 我要不要等,還是先做別的 |
答案要停在「要決定的」那一層。
2. 先給形狀
開頭一句話說明有幾件事、或結論是什麼。讀者知道形狀才讀得下去。
「就是三件事。」 · 「結論:目前不影響你,但有一個未來的地雷。」
3. 用動作講機制,不用元件名
問「它怎麼運作」,答案是一連串動作,不是一串名詞。
- ❌ 需求清單的 REQ 欄 join 驗收對照表的 ACPT 欄,命中 19/23
- ✅ 把需求清單裡每條編號拿出來,去驗收對照表找它對應的驗收條件,再看那條驗收條件有沒有一個真的跑得出結果的測試——三段接得起來才算追到
判準:唸出來像不像在跟人講話。唸起來像在報檔名就是還沒翻譯完。
4. 一個比喻,只用一個
好比喻對應讀者已經有的經驗,而且不撐超過它能撐的範圍。
驗收條件寫了但沒人寫測試 vs 連驗收條件都還沒填 → 「前者是作業寫了一半,後者是題目還沒出。」
用完就停。同一段塞兩個比喻,讀者會開始比對比喻本身而不是事實。
5. 把風險放回正確比例,然後給決策
最容易犯的錯是把每個發現都講得很嚴重。 假警報跟漏報一樣有害——它會讓真警報失去可信度。
收尾三件事:
- 現在影響我嗎 —— 直說會或不會,不要用「可能」逃避。
- 什麼時候會影響 —— 給具體條件,不給時間。
- 要不要做什麼 —— 給選項+推薦,或明說「不必動作」。
檢查表(送出前唸一遍)
- 底下的結論查證過,不是推測?(沒查證就先去查,不要先寫)
- 停在讀者的決策層,不是實作層?
- 開頭就給了形狀(幾件事/結論)?
- 機制用動作描述,不是元件名?
- 比喻最多一個,而且沒有撐過頭?
- 有沒有把小事講成災難? 也有沒有把真風險講輕?
- 明確講了「現在影響不影響」?
- 結尾有決策或「不必動作」?
- 被追問時,我拿得出路徑/證據?(白話換的是表層,不是證據)
反模式
| 反模式 | 為什麼壞 | 改成 |
|---|---|---|
| 白話=省略證據 | 結論變成沒有底的斷言 | 證據不寫出來,但要拿得出來 |
| 白話=語氣變輕 | 真風險被講成小事 | 語氣可以口語,判斷不可以打折 |
| 每個發現都很嚴重 | 假警報淹沒真警報 | 一定要說「這個目前不影響你」 |
| 比喻堆疊 | 讀者開始檢查比喻而非事實 | 一個,然後停 |
| 先白話再查證 | 用流暢包裝猜測 | 順序反過來 |
| 講完不給決策 | 讀者知道了,但不知道要幹嘛 | 收尾給選項或「不必動作」 |
| 對著要改 code 的人白話 | 他需要的是行號 | 看 Rule 的禁用場合 |
完整範例
問:「我們的需求都有追到測試嗎?」
先做的事(不寫給使用者看):查專案的需求清單、驗收條件對照、測試檔與最近一次驗證留下的證據,逐條核對 REQ→ACPT→測試三段接不接得起來。
寫出來的:
白話講就是三件事。
一、追溯實際上是怎麼跑的? 沒有自動掃描。就是把需求清單裡每一條編號拿出來,去驗收對照表找它對應的驗收條件,再看那條驗收條件有沒有一個真的跑得出結果的測試。三段接得起來才算追到。
二、23 條裡 19 條接得起來,斷掉的 4 條不是同一種斷法。 3 條是驗收條件寫了但沒人寫測試;1 條是連驗收條件都還沒填。後面這種比較麻煩,因為它會讓前面所有的估算都不準。打個比方:前三條是作業寫了一半,第四條是題目還沒出。
三、但現在不影響你。 這 4 條都在下個階段的範圍,這週要交的那批(REQ-001 到 REQ-008)全部接得起來。
唯一的地雷:那條沒填驗收條件的(REQ-021)是 owner 要拍板的,不是工程補得掉的。如果拖到下個階段開工還沒定案,那一批就沒有驗收依據,做完也沒人能簽收。
我建議現在只做一件事:把 REQ-021 丟回給 owner 要驗收條件,另外 3 條等排到再補測試。要我把那條的現況整理成一句話給 owner 嗎?
為什麼這樣寫:①開頭給形狀(三件事)②機制用動作講(「拿出來、去找、再看」)③一個比喻用完就停 ④明講「現在不影響你」把比例放對 ⑤地雷給了具體觸發條件而非時間 ⑥收尾給選項+推薦+問要不要做。所有數字都來自查證,被追問時每一項都拿得出路徑。
Signals
- GitHub stars
- 20
- Forks
- 2
- Last commit
- Aug 2026
Advanced
- Item type
- skill
- Key
sunnydata-plain-explain- Source
- github.com/zenobia000/claude-godzilla-z