Deliver Report

---
name: deliver-report
description: 把已產好的一批檔案（報告、Excel、原始資料、設定檔）寫成一段口語、務實的交付訊息／回覆信（fulin 慣用格式與語氣）。當使用者說「交付」、「寫交付訊息」、「產出交付信」、「給使用者的交付」、「deliver」、「handoff」、「write a handoff note」、「draft the delivery email」、「交付報告」、「這批檔案要交出去」、「幫我寫給客戶/工程端的說明」、「整理成交付訊息」、「這批要給好幾組人/多個單位」時觸發。**也涵蓋「回覆對方的提問並附報告」這類逐題回覆**：「回覆客戶問的那幾題」、「回覆會議留的待決事項」、「答覆驗收檢核項」、「對方追問的那個疑慮要回他」；以及反方向的「寫信請對方回覆才能繼續」、「這案子卡在對方還沒給資料，寫信催」。前提是**已有一批產出檔案**——還在做分析、檔案未定案、單一檔案隨手一句、或要寫的是技術文件本身，都不該用（工作日報請用 daily-report）。**產出的是一段文字訊息**；若要的是一份測試報告 DOCX 檔案（「測試報告」「驗收報告」「report 要 Word 檔」），改用 test-report-docx skill。內容依當次產出而定，語氣固定。動筆前先定四件事：檔案是主體還是佐證、有沒有對方的問題要回、單一收件人還是多類分眾、內文密度；再套七條寫法規則（第 7 條僅限檔案為主體時），附四個範例。把技術詞翻成人話，非正式官腔。**另含文件易讀性鐵則**（../../references/document-readability.md）：**任何要給別人看的文件**都適用，套十五條鐵則並在交付前跑十一項機械掃描。
---

# deliver-report — 交付訊息產生器

> 使用者常要把一批產出（報告、Excel、log、設定檔…）交付給他的收件人。**語氣固定，形狀依當次情境而定。**
>
> **三個鐵則**：①**稱謂行一律用半形逗號結尾**（`Dear Jen,`／`Hi 佳宣,`），**收件人沒指定就寫 `Hi,`，永遠不留 `<收件人>` 這種佔位符**（忘了改會很難看）。②**預設讀者不懂技術**——寫給主管/客戶/業務看的，用白話，術語只留在給工程端的那一檔。③**這是對外說明，嚴禁任何內部術語/流程字眼**（紅藍對抗、QA、code-review、adopt/bump/publish、skill、plugin、session、AI…）——只講交付物與結論，不講我方怎麼做出來的。

## 這個 skill 產出「訊息」；要「報告檔」請走另一個

判準一句：**對方收到的是「文字」還是「檔案」？**

- **一段訊息／一封信**（把已產好的檔案交出去、回覆對方提問）→ 走本文。
- **一份測試報告 DOCX**（修復／功能的測試證明文件，給 PM 或客戶簽核轉發）→ 改用 **`test-report-docx` skill**，本文不處理。

兩者常前後接續：報告檔產好之後若還要寫一段訊息把它交出去，那一段回到本文走四個決定——報告檔在信中的地位（主體或佐證）由決定一逐案判，不預設。

> 這裡的「訊息」指的是**內容形態**（文字，不是 DOCX），不是**交付管道**。同一段文字可以貼在對話裡給使用者自己送，也可以照第三步之三建成 Gmail 草稿——**建草稿仍然只到草稿為止，寄不寄由使用者按**。

**文件易讀性鐵則：任何要交給別人看的產出都適用**（交付訊息本身、施作說明書、驗收清單、提案、評估報告、交接文件）——一律先讀 `../../references/document-readability.md`：十五條鐵則＋交付前必做的十一項機械掃描。**不要因為「這份只是內部參考」「這份不用照著做」就放寬**（2026-08-25 使用者裁決：「不只吧，所有的文件你都有可能發生這種低級錯誤啊」）。該檔每一條都是使用者當面指出過 2~4 次的實案，**不是理論**。

## 何時用 / 何時不用

**該用**：一批檔案已產好、要寫一段訊息把它們交給收件人（客戶、工程端、主管）。典型是分析報告 + 明細 + 原始資料 + 實作/設定檔的組合交付；或對方來信提問、我方附報告回覆。

**不該用**：還在做分析、檔案還沒定案（先把東西做完）；單一檔案隨手丟一句話就好（不需要正式交付結構）；要寫的是內部技術文件本身而非「交付說明」（那是寫文件，不是交付訊息）；交付物是測試報告檔本身（用 `test-report-docx` skill）。

## 第一步：蒐集這次要交付什麼

在動筆前，先湊齊這些資訊。能從上下文推出來的就自己填，缺的才問使用者——一次把缺的問完，不要逐項來回。

必要素材：

1. **對方到底問了什麼**（若這次是回覆提問）：**以對方最新來信/最新會議紀錄原文為準**核對題號與題目，別沿用先前討論或舊版草稿的框架。題數變了（四題變三題）、或某題前提已變（問「測試環境費用」但環境已由我方建好），整封信的形狀都要跟著改。**先把對方的提問逐條列出來給使用者確認，再動筆。**
2. **收件人**：若使用者這次有講收件人（例如「給 A」），就寫 `Hi A,`。**沒講就直接寫 `Hi,`**——絕不輸出 `Hi <收件人>,`、`Hi ___,` 這類佔位符（忘了改會很難看）。乾淨的 `Hi,` 本身就成立，寧可留白也不留佔位符。
   **稱謂行的逗號一律用半形 `,`**（`Dear Jen,`／`Hi 酩翔,`／`Hi A & B,`），不用全形「，」——這是使用者的固定偏好。對方是外商窗口或英文名時用 `Dear`，內部/熟識同事用 `Hi`。
   **順帶判斷收件人是單類還是多類**：若收件人涵蓋多種角色（業務端＋工程端＋第三方單位…）且各自只需要讀這批檔案的一部分，記下「每類受眾 × 各自關心哪幾份 × 各自的關鍵重點」。
3. **這批是什麼＋幾份檔案**：一句話講清主題與檔案數，例：「這次的 AWS WAF 規則封鎖分析，共五份檔案」。
4. **逐檔清單**：每個交付檔案的 **檔名 + 一句白話說明**。說明要回答：這份是什麼、給誰看、要去這份查什麼。
5. **背景與範圍**：資料從哪來、涵蓋範圍（時間區間 / 筆數 / 樣本數）、以及**帶數字的重點結論**。
6. **跟上次的差異（選填）**：若有前一版，寫數量/結論怎麼變、**為什麼變**（別只報數字，要給原因）。沒有前版就整段省略。
7. **收尾**：一句「有問題再跟我說」＋「謝謝！」類的輕鬆收束。

> 檔名照使用者實際產出的檔名寫（含版本號，如 `_v1.1`）。

### 順手整理交付清單（寫訊息前先做）

寫訊息前，先把這批要交付的檔案整理清楚——這一步是為了讓逐檔清單正確、也順便替使用者把關：

- **列出實際檔案**：從本次產出、或使用者指定的資料夾，把要交付的檔案抓出來（用檔案工具實際看，別憑記憶）。列給使用者確認「這批就是這些、沒有多也沒有漏」。
- **檢查命名/版本一致性**：同一批交付的版本號應一致（例如都是 `v1.1`）。若出現 `v1.1` 混 `v1` 這種不一致，**明講哪幾份不一致**、問使用者是刻意的還是漏更版，別默默照抄。
- **排序**：交付清單依邏輯排——**彙總報告 → 明細 → 原始資料 → 實作/設定檔**（從全貌到細節到可執行），不是照檔名字母序。
- **檔案落點紀律**：最終交付檔集中於**專屬交付資料夾**，除交付檔外的一切過程產物（測試結果、截圖、傾印、中間資料）收進該資料夾內的 **`_work/`** 子資料夾、不散落（詳細結構見 `test-report-docx` skill 的「交付位置與資料夾紀律」，通用於所有產檔交付）。發現散落時指出並建議歸位。
- **不擅自改檔**：整理只做「列清單、指出問題、建議排序」，**不主動改檔名或動檔案**；要改由使用者拍板。

## 第二步：動筆前先定四件事

**四件事每封信都要走過一遍，不要去找自己屬於哪一型——沒有型，只有這四個決定。** 決定完了，信的形狀自然就出來了。

> **依這個順序定，因為後面的會被前面的影響**（它們不是四個互不相干的變數）：**決定一（檔案地位）→ 決定二（有無提問）→ 決定三（收件人結構）→ 決定四（密度）**。密度是前三個的結果，不是先挑好的偏好——例如決定一選「主體」就不可能同時是「高壓縮」（主體要求每檔寫得清楚）。**先定密度再回頭套地位，會得到兩個互斥的取值。**

### 決定一：檔案在信中的地位

| 地位 | 何時 | 寫法 |
|------|------|------|
| **主體** | 對方要的是「這批成果本身」——他委託你產出一批東西，想知道有什麼、該讀哪份 | 逐檔清單放開頭，每檔可寫兩三句、可展開子項 |
| **佐證** | 對方要的是「答案」，檔案只是答案的依據 | 附件區退到結尾，每檔一句話定位，不展開 |

判準一句：**對方打開信，想先看到的是檔案清單，還是結論？**

> **兩種都成立時（交付物本身就是那個答案，例如「按你上次七項意見改完的 v2 規格書」）算主體**——逐檔說明要留，因為對方要拿它去簽核；同時把「七項改好了沒」當結論寫在前面。
>
> **進度型交付**（有半成品、還沒有最終答案）也算主體，但檔名後要**標狀態**：`（已完成）`／`（進行中，約 N 成）`／`（待您確認）`。對方想先看到的是「到哪、卡在哪、要我做什麼」，所以結論段改寫成這三件事。「不該用」那條講的是「還沒做完就別急著發交付信」，不是禁止中期進度信。

### 決定二：有沒有「對方的問題」要回

若對方心裡已有一組待解問題，**信的骨架就長成那組問題的形狀**，不是長成我方產出物的形狀。那組問題的來源不限於來信編號提問——也可能是會議留下的待決事項、對方反覆追問的同一個疑慮、驗收檢核項、等你拍板的決策點。

有問題要回時，三條配套：

- **題目標籤照抄對方的用詞與編號**：對方寫「Nginx HTTPS Reverse Proxy」就別改寫成「前置伺服器方案」，讓對方能把你的回覆跟自己的信逐條對齊。**照抄只用於題目標籤**，內文其他地方仍照術語密度規則翻成人話。
- **核對題數與題目**（見第一步第 1 項）：以對方最新原文為準，別沿用舊框架。
- **前提已失效的題目，先校正再答，不要照題硬答**：例如對方問「測試環境費用為何」，但測試站已由我方建好、不需對方出資——先一句校正前提（「已建置完成，不需你方提供資源」），再答校正後真正該答的（「但要把工作天收斂成定量，需要另一批資料」）。硬答一個已失效的題目，會讓整封信答非所問。**前提校正也是誠實原則的一種**：對方問了不存在的東西，校正比照答有用。
  > **⚠ 校正的邊界——這條授權很窄，越界就變成擅自改寫對方的問題**：
  > **判準：你能不能指出一個具體、可驗證的事實，證明他問的東西已經不存在或已改變？** 指得出來才是校正；指不出來就是你的觀點。
  > **可以校正**（客觀失效）：問已建好環境的費用、問已移除功能的設定、題數與最新來信不符。
  > **不可校正**（我方觀點，即使你很確定自己對）：他問 A 方案的工時、你認為不該做 A；他的問題基於你認為錯誤的架構理解；他問的東西存在但你認為不必要。
  > **不可校正時的正確寫法是「先答再建議」，不是改題**：照實答他問的（他可能要拿去報預算、對上級交代），再把你的看法接在後面當建議，讓他自己拍板——
  > 「全清約 N 天（明細在報告第 3 章）。不過我們評估後認為多數資料其實不需要清理，若只清 A、B 兩類約 M 天，效果差異不大——要走哪個方向請您拍板。」
  > **拿不準是失效還是觀點時，一律照答再建議。** 把「我方的建議」寫成「你的前提失效了」，等於在教客戶怎麼提問；而且題目標籤照抄了他的原字，他會以為這題答過了，比直接改標籤更難察覺。

沒有問題要回時（單純託付一批工作），骨架由決定一與決定三決定；密度（決定四）仍要定——**四個決定每封信都要走過，沒有例外**。

> **反方向也算一種「題」：你有問題要問對方、且他不回你就沒法繼續。** 這種**阻塞型待回覆**不要塞進「需別人配合確認」的附屬區——它是整封信最重要的東西，要**獨立一區、放在結論之後、逐條編號，並寫明「回覆後預計 N 天內完成」**，讓對方一眼看出案子卡在他身上。（若只是一小塊要對方確認、不影響主線，才用附屬區。）

### 決定三：收件人結構（單一／多類分眾）

判準是**不同人是否只讀不同子集**，不是檔案數量。就算檔案很多，只要所有人都該從頭讀到尾，仍走單受眾；反之只要「不同人只讀不同子集」，哪怕才四五份檔，分眾都讓每類人 30 秒找到自己該讀的。

分眾時的四個要領：

- **每區自帶動線**：受眾區塊本身就是導讀（該讀哪幾份、什麼順序），**結尾不必再寫一段整體導讀動線**；有明確閱讀依賴時給「可按以下順序：A → B → C」。
- **「重點：」行**：一行塞進該受眾的關鍵事實——欄位數、規則代號、時程日期、行為鐵則（例：「Excel 上傳一律進暫存、按送出才正式提交」）。數字與日期必帶。目的是讓對方**不開檔案就先有正確預期**。
- **範圍邊界聲明**：每區講完「有什麼」，若有容易誤解的邊界，補一句「沒有什麼」（例：「綠色採購資料不提供於此 API」），別讓對方開了檔案才發現沒有。
- **視覺慣例**：受眾區塊用 `▌` 開頭、檔案指路用 `→`、縮排對齊——掃一眼就能跳到自己的區塊。

> **跨受眾的共通項要有自己的位置。** 分眾信幾乎一定有「所有人都得知道」的事（停用日、上線日、共同行為鐵則）——形狀 B 的受眾區塊裝不了它。**寫在開場之後、第一個 `▌` 之前，獨立一行帶日期**（例：「先講一件三邊都會碰到的事：舊版金鑰 8/31 停用，之後呼叫一律要換新金鑰。」）。**不要只寫在某一區**——其他受眾會漏掉。
>
> **這個決定與決定二可疊加**：同一封信可以既按題回覆、又要分眾。疊加時：**題號當外層、受眾標記塞在題內**（因為對方是按題來對齊你的回覆），只在「該題只有某類人要看」時掛一個 `▌` 標記，並替不需讀的人補一句免讀結論（例：「業務端這題不用細看，結論是不影響上線時程」）——沒有這句，看不懂的人會硬讀。疊加時不要每題都寫「重點：」行，那會跟每題最多三句打架。
>
> **同一份檔案可出現在多個受眾區塊**（同一份設計文件同時給使用者與 IT），各區塊用各自角度定位它，不必去重。「不必去重」指**檔案**可重複出現，不是說共通的**事實**只能講一次。

### 決定四：內文密度

### ⛔ 先立總長上限（這條贏過所有「必寫」規則）

**基準上限 550 個中文字，寫到七成就該停下來檢查**（四個使用者滿意的範例實測是 189／473／526／539 字，上限照這個訂）。

> **怎麼數**：只數**中文字**——檔名、網址、英文與數字都不計（範例一含檔名共 774 個字元，但中文只有 473，上限對的是後者）。分眾信是**三個區塊合計**，不是各自算。
>
> 精確計數不是重點，**你要的是「這封信是不是明顯比範例長」的感覺**：範例一那封五份檔的信約 470 字，你的信如果看起來比它長一半以上，就該停下來砍。真的難判時用行數當代理——**範例一 12 行、範例二 16 行、範例四 14 行**，超過 20 行就太長了。**下面所有「必寫」「一律進信」「要留」的規則，全部在這個上限之內競爭，不是各自加一段。**

> **檔案多的信另加額度**：逐檔說明的體積跟檔案數成正比，不該跟警示搶同一份預算。**基準 550 字含前五份檔；第六份起每份加額度**——**一行帶過的加 40 字，要展開子項的加 90 字**（實測範例一「一行一檔」是 38 字/檔，範例二「展開子項」是 88 字/檔，照這兩個數訂）。
>
> 例：8 份檔、其中 3 份要展開 → 550＋（3 份展開超出的算 90、其餘算 40）。**先決定哪幾份要展開再算額度**：只有「對方要拿去審、簽核、照著做」的才展開，其餘一行帶過。
>
> 這條的用意：上限要咬住「規則堆疊出的贅句」，不是咬住「對方要的檔案清單」——後者正是決定一選「主體」時對方唯一想要的東西。**別為了守上限把該展開的檔案壓成一行**，那是把決定一「主體／佐證」的差別抹平。

超過上限時**不是**放寬上限，而是照這個順序砍：

1. 同類項合併成一句（三個安全性項寫成「另有三項設定要調，都列在報告第 N 章」）
2. 只留「是什麼＋在哪一章」，理由全部拿掉
3. **逐檔說明分級**：只展開「對方要拿去用的」那幾份（要審、要簽核、要照著做的），其餘一行一檔帶過。**這一步比砍警示優先**——警示砍掉是實害，檔案說明壓短只是少點方便
   > 這一步與上面的分級額度**不衝突**：兩邊用同一個判準挑同一批檔案，額度是「先算你可以展開幾份」，這一步是「額度還是不夠時，把展開的份數再收一點」。不是一邊要你擴張、一邊要你壓縮。
4. 仍超過 → **順位 4、5 的內容全部只留指路**（「明細與風險清單在報告第 N 章」一句帶完）
5. 到這裡還超過，代表順位 1、2 的項目本身就很多（例如八項安全性失效）。**這時不要再砍，改寫成「一句總述＋逐項半句」**：「上線前有八項設定必須調整，其中三項不調會讓登入狀態外洩（第 3 章）、其餘五項列在第 4 章。」——**把最嚴重的幾項點名，其餘計數＋指路，但不能讓任何一項『完全沒被提到』**

> **「最嚴重」怎麼判**：照下面的保留順位表，順位數字小的就是嚴重。**同順位內比「出事後多久會發現」**——越晚發現的越嚴重（靜默失效排最前）。
> **「同類項」的定義**：同一個順位、且對方會採取同一個動作處理的，才算同類（三項都要改設定＝同類；一項改設定＋一項要給資料≠同類，不可合併）。

**跨類要砍時，照這個優先序保留**（上面三步是同類項內部壓縮，這裡是不同類之間的取捨）：

| 保留順位 | 內容 | 為什麼排這裡 |
|---|---|---|
| 1（絕不砍） | **對方不知道就會受損**的事——安全性失效、沿用現狀會出事 | 砍掉是實害，且出事後歸因是「你們沒講」 |
| 2 | **卡住對方下一步**的事——要他給資料/授權/拍板、阻塞型待回覆 | 砍掉整件事就停擺 |
| 3 | 分眾的**共通項**（純告知性質的，如上線日、版本號） | 砍掉會讓某類受眾漏掉關鍵事實 |
| 4 | 帶數字的重點結論、逐檔說明 | 重要但附件裡有，可壓成指路 |
| 5（先砍這個） | 範圍邊界、負面結論、版本差異原因 | 該寫，但壓成半句＋指路的損失最小 |

> **一件事同時符合多個順位時，取數字最小的那個。** 例：「舊版金鑰 8/31 停用」既是分眾共通項（順位 3）、也是「不換就連不上」（順位 1）→ **算順位 1，絕不砍**。順位 3 只涵蓋純告知性質的共通項（上線日、版本號這種知不知道都不會出事的）。
>
> **順位 1、2 不會因為上限而完全消失**——項目少時每項壓成「半句＋指路」；項目多到連半句都放不下時，用上面第 5 步的「總述＋點名最嚴重的幾項＋其餘計數指路」。**底線是對方讀完信知道「有這類問題、有幾項、在哪一章」，不會以為不存在。**

> **判準是「這封信讀起來像不像一封信」**——不是「有沒有漏掉檢核項」。塞滿 12 個必寫項的信，對方一項都不會讀；壓到 5 行、指清楚哪章有細節的信，對方會翻。**漏警示與寫太長都是失敗，而寫太長是舊版被連退三次的那一種。**

### 逐句判準

**寫下每一句前先問「這句不寫，對方會不會做錯事、或對現況產生錯誤認知」**——都不會就刪。

> **「錯誤認知」不等於「認知不完整」。** 少寫一項事實一定讓對方知道得少一點，那不算錯誤認知——要到「他會據此形成一個**具體而錯誤的結論**」才算（例：不寫資料只到 6/28，他會以為涵蓋整個 6 月）。**用這個門檻擋掉「補充說明性質」的句子**，否則這條判準會退化成「所有真實資訊都要寫」。

> **問「會不會做錯事」而不只是「會不會做錯決定」**，因為有三類內容對方明明沒有決定要做、卻必須寫：
> ①**他不必動作但沿用現狀就會受害**的（見寫法規則 2）；②**等他回覆才能繼續**的（他不會做錯，他會什麼都不做，然後案子停擺）；③**「這塊沒有結論」的負面結果**（例：「9 條判不出來」——作用是防止他誤以為已無殘留風險）。
> 還有一類與決定無關但必寫：**範圍邊界**（「這批資料只涵蓋 6/11–6/18」「排除了維護期間的工單」）——他不會因此做錯決定，但沒寫，他日後會拿這份數字去對別的帳然後質疑整份分析。

這條自然產生不同長度，不需要為不同情境訂兩套上限：

- 檔案為主體的信，通得過的句子比較多——帶數字的結論、逐項的判斷、版本差異的原因，這些確實影響對方決定。
- 檔案退為佐證的信，通得過的很少——對方要的是結論，理由與佐證在附件裡。所以自然就短。

> **兩者同時成立時（檔案是主體、對方又有提問）的排版**：**題目當骨架放前面**（他心裡有問題，先給答案），**逐檔說明合併成結尾一區、不拆進各題**（同一份檔案常回答多題，拆了會重複、也看不出這批有哪些檔）。每檔仍寫得清楚（不壓成一句），但**只寫一次**。
>
> 順序：開場 → 逐題回答 → 附件區（逐檔說明，可兩三句）→ 導讀動線。**這個組合沒有範例可抄，照這個順序自己長。**
>
> ⚠ **這個組合最容易超長**（逐題回答＋不壓縮的逐檔說明，兩者單獨都用掉大半額度）。上限仍是 550 字，但**這裡的省法不是壓縮逐檔說明**（那是這個組合的重點），而是：**逐題回答只留結論＋指路**（理由全部推到附件）、**檔案超過四份時只展開對方要拿去用的那幾份、其餘一行帶過**。

配套一條：**要寫第三句時，改成指路**（「細節在盤點報告第 N 章」）。

## 第三步：常見形狀參考

> **以下是四個決定組合下長出來的常見形狀，是產物不是規範。** 你的組合若跟哪個都不同，就照四個決定自己長出形狀，別硬套。
>
> 形狀裡尖括號 `<…>` 只是給你看的填空提示，**最終輸出絕不能留任何尖括號佔位符**。收件人沒指定就只寫 `Hi,`（半形逗號）。

### 形狀 A：逐檔導讀

> 常見於「檔案是主體、沒有提問要回、單一受眾」，但**不要拿這個括號當索引照抄**——你的組合就算完全命中，這封信該有的重點也未必在骨架的格子裡（例：哪兩份是對方要簽核的，骨架沒有那一格）。

```
Hi <對方稱呼，沒有就 Hi>,

<開場一句：收到／回應對方的委託，講你完成了什麼（若對方有先來信託付，扣回他講的）。例：「收到，已完成 XX 盤點，依您提供的格式彙整，這次附上 N 份檔案：」>

1. <檔名1> — <這份是什麼、去哪查什麼；需要的話往下展開子項>：
   <子項A：…>
   <子項B：…（可順帶解釋「為什麼這樣設計」，例：避免一整排 N/A 造成誤判）>
2. <檔名2> — <…>

這次的重點結論：
<挑重點項目逐一講清楚，每項帶上你的判斷與建議>：
<重點項1：這是什麼、影響範圍、（若有）這是對方信中所指的核心>
<重點項2：標出風險最高/建議優先評估的>
<重點項3：標出可簡化/可移除的（例：零流量可直接移除）>
<（有的話）需要別人配合確認的事項；以及你自己做不到、要誠實講的>
<（選填）跟上次的差異＋原因>

<導讀動線：先看哪份抓全貌 → 要查細節翻哪份>，有任何問題再跟我說~
```

### 形狀 B：分眾

> 常見於「收件人分多類、各讀不同子集」。同上：骨架是對照用的，不是填空表。

```
Hi <稱呼們>,

<開場一句：什麼東西出爐了＋檔案眾多，以下按對象稍作說明~>

<（有的話）共通項：所有人都得知道的一件事，獨立一行帶日期。例：「先講一件三邊都會碰到的事：舊版金鑰 8/31 停用，之後呼叫一律要換新金鑰。」沒有共通項就整行省略——但別把它塞進某一區。>

▌ <受眾 A（角色白話註記，例：使用者（物管 / 採購 / 需求單位））>
   → <檔名>：<一句定位：這份是什麼、去查什麼>
   → <檔名>：<一句定位>
   重點：<這類人最需要知道的關鍵事實，名詞化壓縮、帶數字/日期/行為鐵則，一到兩行>

▌ <受眾 B（例：IT（內部開發））>
   可按以下順序：<檔1> → <檔2> → <檔3> → <檔4>
   - <檔名>：<定位>
   - <檔名>：<定位>

▌ <受眾 C（例：外部串接方）>
   → 只看 <檔名>，<裡面有什麼一句講完>、<範圍邊界：什麼「不」包含在內>。

有問題直接 reply 或 Teams 我，謝謝~
```

### 形狀 C：逐題回覆

> 常見於「對方有提問、檔案退為佐證」。同上：骨架是對照用的，不是填空表。

```
Hi <稱呼>,

<開場一句：主題＋「來信的 N 個問題我們評估完了」＋（若有）我方已完成的關鍵動作一句，收在「請詳以下 N 題回覆：」>

第 1 題（<照抄對方的題目關鍵詞>）

<結論句打頭，再一到兩句補「為什麼」或「範圍」，然後指路（＝常態三句；遇前提校正或對方要拿去報預算的數字可到五句）>

第 2 題（<對方題目關鍵詞>）

<同上。前提已變的先一句校正再答>

附件 N 份：

<檔名> — <一句定位：這份是什麼、哪一題的完整答案在裡面>

<導讀動線>。有任何問題，或需要就其中某一項再展開說明，隨時告知，謝謝！
```

> 收尾用 `謝謝！` 或直接以「有問題再跟我說~」收束皆可，看整封語氣自然收。

## 寫法規則

> 規則 1–6 不分形狀都適用；**規則 7 有適用邊界**（只在決定一選「主體」時），標在該節。

### 1. 術語密度

**獨立於決定四**：一句話可以很短但全是術語，也可以很長但全白話。這裡管的是用詞，不是長度。

- **預設讀者不懂技術**（最重要）：交付對象通常是**看不懂技術術語的人**（主管、客戶、業務端）。整段訊息要讓一個不懂的人也能看懂在講什麼、結論是什麼、要他做什麼。寫之前先自問「我媽看得懂這句嗎」，看不懂就換白話。
- **技術詞翻成人話**：寫「加個條件再攔」不是「加 scope-down rule」；寫「攻擊藏在被遮掉的參數裡、暫時判不出來」不是「payload 位於 redacted query string 無法判定」。**專業名詞（label、scope-down、IPSet ARN、SQL injection、payload…）只在「給工程端的那一檔」的說明裡保留**，其餘一律白話；真的非提不可時，後面用括號補一句白話解釋。
- **分眾時的術語分級按「區塊」不按「檔」**：給使用者/業務的區塊全白話；給 IT/工程受眾的區塊**可以保留架構與實作詞**（Aggregate、Repository、DB Schema、API spec…），因為那個區塊就是寫給懂的人，硬翻白話反而失真。同一封信裡兩種密度並存是正常的。
- **少用縮寫與英文術語**：能講中文就別丟英文縮寫。必要的產品/系統名稱（AWS、WAF 這種）可留，但別堆疊一串術語讓外行看不下去。
- **稱呼對方一律用「您們」（單人用「您」），禁止公文式敬稱**：不寫「貴司」「貴公司」「貴中心」「貴單位」「貴部門」「貴部」「貴院」「貴局」「貴處」「貴校」「貴廠」「貴組」「貴方」「您司」，也不自稱「敝司」「敝公司」「敝中心」「本司」「本中心」。理由：這類敬稱是公文腔，讀起來有距離感；交付訊息要像人講話，「您們」既禮貌又親近。需要指單位時就直接寫單位名稱（「資訊室」「桃園廠」），不加「貴」字。
- **繁體中文**，半形數字與英文檔名/系統名照原樣。

### 2. 誠實邊界（含與密度規則的仲裁）

- **誠實講出做不到 / 要別人配合的事**：自己權限不足或查不到的，直說（「我這邊沒有 DB 權限無法代為確認~」）；需要 DBA/infra 等他人協助確認的，列成一區讓對方知道還缺哪塊。不假裝全包。
- **範圍邊界要先講**：容易誤解的「沒有什麼」，寧可先講明，別讓對方開了檔案才發現。

**與「內文密度」衝突時，依「對方不知道會不會出事」分流**：

**判準只有一個：對方不知道這件事，之後會不會有人受損？** 會 → 進信。不會 → 只留指路。

**注意判準不是「他要不要動作」。** 最容易漏的正是「他什麼都不用做、維持現狀就會出事」這類——它不卡任何動作，卻等著對方照原樣走然後受害。

| 情形 | 寫法 |
|------|------|
| **會受損**（進信留一句 + 章節指路）：①需對方提供資料、授權、拍板 ②**他不知道就會受害**——含「不必動作、沿用現狀就出事」 ③**任何安全性失效**，尤其「靜默失效」（沒有錯誤訊息、沒人會發現） | 信裡留一句 + 章節指路 |
| **不會受損**（只留指路）：純我方作業流程、不影響對方系統行為的內部風險、附件已寫清楚**且不涉及安全性或資料正確性**的技術細節 | 只留指路，不重述內容 |

> 反例一：「需對方提供伺服器設定檔才能把工作天收斂成定量」——卡住他的下一步，進信。
> 反例二：「若沿用現有排程，月底批次會撞到新作業導致報表少算」——他現在不必做任何決定，但不知道就會受害，進信。
> 反例三：「後端調整若只套用一半，登入憑證安全屬性會靜默失效」——**即使該調整由我方執行，也要進信**。理由：交付之後改設定的人可能是對方、代管商或下一任工程師；「靜默」意味著出事時沒有任何訊息會提醒任何人。
>
> **安全性項目的處理（別把交付信寫成安全稽核報告）**：一份技術盤點常會順手撞到三到十項安全性問題，**不是每項都進信**。只有**這次交付的東西會讓它被觸發或被放大**的才進信（例：這次要上線 HTTPS，而 cookie 屬性沒跟著調）；**盤點過程順手看到、與本次交付無因果關係的**（連線字串明碼、既有 SQL 拼接、備份沒加密…）**歸為「另案建議」，在信裡合併成一句＋指路**（「另外看到 N 項既有的設定風險，不影響這次上線，但建議另外找時間處理，列在報告附錄」）。**別寫「跟這次交付無關」這種話**——那是在勸對方別看，而你並不知道他的環境裡那項會不會出事。
>
> ⚠ **「無因果關係」不是你說了算，判錯的方向只有一邊會出事**，所以門檻要這樣設：
> **只有「你能說出這項問題在本次交付前後完全一樣、且對方照這次的交付內容操作不會碰到它」時，才算無因果關係。** 說不出來就算有關係、進信。
> **這三種一律算有關係，不得歸另案**：①本次交付的文件或設定檔**教對方去動到**那個地方 ②本次上線/切換會**改變那項風險的觸發條件**（例：上線 HTTPS 後 cookie 沒調，風險比上線前更高）③**靜默型**——出事時沒有錯誤訊息、沒人會發現。
> **歸另案時要在信裡留下計數**（「另有 N 項既有設定風險列在附錄」），不能只寫「另有一些」——對方要知道有幾項才能決定要不要看。
>
> 進信時**用白話講後果、不用術語講手法**——寫「登入狀態可能被別人取得」不是「session cookie 缺 Secure 導致可被 MITM 竊取」（術語留給工程端那一檔，見寫法規則 1）。
>
> **有疑慮時進信，但受總長上限管制**（見決定四）：進信的形式可以只是**半句＋指路**（「另有兩項設定要調，列在報告第 5 章」），不必每項都解釋清楚。理由：警示被靜默丟掉是對方受損後才發現，歸因會是「你們交付時沒講」；但十二個各自合理的疑慮加起來就是一封沒人讀的信，**那等於全部都沒講**。
>
> **判準要落在「受損」而不是「我不確定」**：說得出「誰、在什麼情況下、損失什麼」才算；說不出來就只是資訊不完整，不進信。

### 3. 可行動的判斷

- **有優先建議就講**：標出「建議優先評估」「可直接移除以簡化」這種可行動的判斷，別只陳述事實。
- **能帶判斷就別只陳述事實**：哪個是核心、哪個風險最高、哪個零用量可移除。

### 4. 與前一版的差異（有前版才適用）

- **變動要給原因，不只報數字**：數量變了要解釋為什麼，並點出方向（「往判斷更精準的方向調整」）。

### 5. 導讀動線

- 把每份檔案對應到「什麼時候翻它」，收件人不必自己猜。
- 分眾時每區自帶動線，結尾不必再寫整體動線。

### 6. 語域與收尾

- **口語、白話、務實**。像同事之間交接，不是官方公文。
- **開場先回應對方**：若對方是先來信託付（有委託脈絡），開頭先一句「收到，已完成 XX…」回應他，別劈頭就列檔案。呼應對方講過的話（「您信中範例所指的核心」「依您提供的格式」）會讓對方覺得你有聽進去。
- **輕鬆收尾**：用 `~`、「有問題再跟我說」、「謝謝！」收束，不要生硬結尾。

### 7. 檔案為主體時的補充

> **適用邊界（唯一判準）：決定一選「主體」時適用，選「佐證」時不適用。** 與有沒有提問要回無關。
>
> 下面前兩條會把信寫長。檔案退為佐證的信要的是壓縮，誤用就會寫太長（這是舊版把交付信寫得沒人要看的主因）。
>
> **但第 2 條（結論要有敘事、不是數字串）有一個例外**：佐證信裡若某一題的答案是「幾個因素互相牽動」，硬寫成數字串（「建議 6 週；風險 3 項；成本增 12%」）對方看不懂為什麼，會回信再問一次。**那一題可以用敘事寫，仍守三句上限**——把因果講清楚比省一句重要。（範例四第 3 題就是這樣寫的。）

- **別填格子、要有機補充**：該補的細節就補、有層次就展開（一個檔案底下可再分子項）、沒有的就省。寧可為這次多寫兩句有用的，也不要為了對齊形狀寫得乾巴巴。讀起來要像「為這次量身寫的一封信」，不是套版。
- **結論是有敘事的，不是數字串**：不要寫成「A 類 N 個；B 類 M 個」的分號串（那太制式）。改成挑重點項目逐一講，每項講清楚「是什麼、影響範圍」並帶上判斷。有數字就帶數字，但數字是佐證不是主體。
- **檔案內設計上的取捨可以順帶解釋**（「改用適配欄位，避免一整排 N/A 造成誤判」）——讓對方懂你為什麼這樣排。

## 第三步之二：交付前自檢（凡有文件產出即必做）

**眼睛掃會漏**——實測：人工掃過一輪後仍漏掉一個符號的說明在精簡時被刪掉，是寫腳本全掃才撿回來。
**下列各項用程式跑，不要用讀的**。哪些會自動跑、哪些要自己跑：

- **自動跑（不用手動）**：本 skill 一被調用（Skill 工具或斜線指令都算），Stop hook 就會在回合結束時用同一套判準掃，有硬缺陷就擋。掃的範圍：
  - **本回合提到或寫過的交付檔**：交付訊息裡寫到的檔名／路徑（用反引號包起來最穩，中文檔名含空白也抓得到）、本回合 Write 寫出的檔。任何位置、docx／md／txt／pdf／pptx／xlsx 都算，最多 6 份。所以**交付訊息裡一定要寫出每個交付檔的檔名**。
    只在文字裡提到的檔，要 6 小時內改過才算（讀過的客戶原稿通常是舊檔，不算交付檔）；已經擋過一次、而剩下的缺陷都不在「本回合寫出的檔」上（只被提到的檔、固定目錄裡剛好近期改過的檔）時，第二次改為提醒，免得客戶給的原稿把收尾卡住。本回合 Write／Edit 寫出的檔每次都擋。
  - 目前目錄、`_work/`、`docs/`、`output/` 裡 6 小時內改過、至少 20 段的 docx（最多 4 份）與 `checklist-*.md`。
  - docx 有目錄時另檢查目錄頁碼（要開 Word，每次最多 2 份）。
  - 不算交付物、不掃：CLAUDE.md、SKILL.md、README、CHANGELOG、MEMORY，以及 `.claude／memory／node_modules` 底下的檔。
- **要自己跑**：本回合沒提到、也沒寫過的交付檔（例如前一回合就產好、這回合只口頭交代的），或想在寫交付訊息之前先檢查。跑同 plugin 的自檢腳本：

```
node "${CLAUDE_PLUGIN_ROOT}/skills/check-before/scripts/check_doc.js" <檔案路徑或檔名>
```

exit 1＝有硬缺陷要改；exit 0 仍要逐條判斷「提醒」；exit 2＝讀不到，不可當通過。樣式一致性與表格欄寬只有 docx 能機械判定。完整流程（含五條人工判斷）見同 plugin 的 check-before skill。
（test-report-docx 的報告、to-checklist 的清單、daily-report 的日報，各自的產檔／寄送腳本已內建這道檢查，不用在這裡重跑。）

| # | 掃什麼 | 通過標準 |
|---|---|---|
| 1 | 符號與代號 `§` `#N` `字母-數字` `S/V 編號` | 每種都有定義句，或已改成白話 |
| 2 | 編號連續性 | 列出完整序列，無缺號、無小數點式（四之二） |
| 3 | 交叉引用 | 每個「見第N節」「見步驟X」「見第N項」都指得到 |
| 4 | 重複偵測 | >25 字且出現 ≥2 次的行，逐一判斷是真重複還是巧合 |
| 5 | 異動紀錄用語 | 「本次查核／本文件初版／原文件／改版／第 N 輪」為 0 |
| 6 | 樣式一致性 | 同級標題字級／顏色相同、主標大於子標；⚠※◆ 各自樣式統一；括號符號單一用途 |
| 7 | 表格欄寬 | 窄欄（<1500 dxa）不塞長文字，否則擠成直排 |
| 8 | 內部推導痕跡 | 原價／折／優惠／成本／buffer／緩衝／本來／比照，逐一判斷是結論還是推導（搜到不等於要刪） |
| 9 | 公文式敬稱（只提醒，不擋） | 貴司／貴公司／本中心…逐一判斷是敬稱還是正常詞，是敬稱就改「您們」 |
| 10 | 目錄頁碼 | docx 有目錄時，目錄與正文的頁碼、標題一致 |

**交付兩份以上文件時加驗**：步驟數／步驟名／項數／數字宣稱值，兩份必須一致。

**三個實作陷阱**（都踩過）：
- **改 .docx 後 `zipfile` 驗證不夠**，必須加 XML parse 與表格標籤平衡檢查；
  最終仍要**實際用 Word 開一次**——曾發生 zipfile 全綠但 Word 打不開。
- **編號替換要防英數字前綴咬字**：`TLS1.0` 會被 `S1` 咬中變成 `TL步驟一.0`。
  用 `(?<![A-Za-z0-9])` 擋，且替換前先列出所有命中處人工掃一遍。
- **檢查腳本自己會過時**：改了標題格式後，腳本把 6 個正常步驟誤報成「缺步驟」。
  機械檢查報出來的問題，**先確認是文件錯還是檢查器錯**。

**修完任何一類問題後，必須全文重掃同一類**——不是只確認被指出的那一個。
這是易讀性問題被反覆指出 2~4 次的唯一原因。

**另外**：機械性、判準明確的變更該寫成腳本交付，不要叫對方照著文件手動改（鐵則 10）；腳本必須在未施作的原始副本上實跑過完整循環才算完成——實跑會抓到 dry-run 抓不到的 bug。

## 第三步之三：能建草稿就別叫使用者複製貼上

**判準：這封信有明確的收件人與信件管道（Gmail），就直接用 Gmail 工具建成草稿，不要只把文字丟在對話裡叫使用者自己貼。**

最常見的觸發是**使用者請你去看信**（「你看一下這兩封信」「他們來信要議價」「幫我回這封」）——**看完信就順手把回覆建成草稿**，讓使用者只需按送出，省去複製、貼上、重排格式、補收件人這四道工。使用者沒說「建草稿」也照做；他叫你看信，通常就是要回信。

**建草稿的五個要點**：

1. **掛回原信串**：回覆既有信件時帶 `replyToMessageId`（用該封信的 message id，不是 thread id），Gmail 才會把草稿接在原討論串下、主旨自動帶 `RE:`。新信才不帶。
2. **收件人照原信的回覆規則**：原信寫「回覆請使用本封郵件進行回覆」就回原寄件位址；原信 To／Cc 裡的內部關係人（採購承辦、需求端窗口）判斷是否保留，**多帶一個需求端窗口通常對使用者有利**（讓他知道採購在動作），但要在對話裡告訴使用者你帶了誰、讓他決定要不要拿掉。
3. **一次只建一封、一案一封**：兩個案子（不同案號、不同公司）就建兩封各自掛在自己的信串，不要合併成一封群發。
   **每封動筆前重新核對「這封信是哪個案子、對方問的是哪幾件事」**，只用那個案子的事實——同一輪對話裡處理過的另一案資訊不得沿用。兩案的報價、時程、對方窗口在腦中很容易串，而寄錯案的資訊給對方是收不回來的。
4. **建完在對話裡摘要**：列出「收件人／副本／立場」一小張表，並點出兩封信之間**刻意的差異**（例如同一句話對 A 客戶能寫、對 B 客戶不能寫的理由）。使用者要能不開 Gmail 就知道你寫了什麼。
5. **附件**（2026-10-06 實案：reply 草稿被帶入對方原信的 9 張截圖，使用者自己打開才發現）：
   - **用 `replyToMessageId` 掛原信串時，原信的附件會被整批複製進草稿附件區**——寄回去給對方沒有意義。建完的 `get_draft` 讀回檢查（要點 4 之後、交付前必做）**附件區也要看**；有帶入就 `update_draft` **不帶 attachments 欄位**一次清空（附件不做合併、未重附即全清，內文與收件人不受影響）。
   - **要主動附檔時由工具直接帶，不要叫使用者自己拖**：合計 ≤25MB 用 `attachments`（base64）附上；**超過 25MB API 必失敗**（PreToolUse 閘會先擋），改走①縮檔到 25MB 內、②瀏覽器自動化代拖進 Gmail 網頁草稿（網頁版對 >25MB 會自動轉雲端硬碟連結）、③使用者慣用的檔案交換管道——選了③要把信裡「請詳附件」改成實際取檔方式。

**格式：用 Gmail 原生純文字，非必要不要送 HTML。**

- **預設只給 `body`（純文字），不要給 `htmlBody`**。Gmail 會用它原生的富文本編輯器呈現，字體、行距、簽名檔都跟使用者平常寄的信一致；塞 HTML 進去反而會出現字體不一致、行距怪異、與簽名檔衝突。
- **排版靠空行與破折號，不要靠標籤**：條列用「項目：值」一行一條（前面不加 `-`／`*` 符號也可以，Gmail 純文字看起來更乾淨）；段落之間空一行。**不要用 Markdown 語法**（`**粗體**`、`##`、`|表格|`）——那在 Gmail 裡會原樣顯示成星號與井號，很難看。
- **兩個例外要用 `htmlBody`**：①使用者明講要表格、或內容確實需要表格才能讀懂；②**信裡有要對方複製貼上的網址或指令**（見下一段，純文字會被 Gmail 改寫成轉址連結）。

> **用 `htmlBody` 時只准用這組標籤**（白名單，其餘一律不准）：
> `<br>`　`<hr>`　`<b>`　`<i>`　`<u>`　`<ul>` `<ol>` `<li>`　`<a>`　`<pre>`　`<table>` `<tr>` `<td>` `<th>`
>
> （`<strong>`／`<em>`／`<code>`／`<thead>`／`<tbody>` 是上面幾個的等價寫法，hook 一併放行，但寫的時候用上面那組就好。）
>
> **換行一律用 `<br>`，禁止用 `<p>`。** 段落之間空一行就是 `<br><br>`。
> 外層可以包一個 `<div dir="ltr">`，那是 Gmail 自己的結構。
>
> **為什麼禁 `<p>`**（兩個理由，第二個才是主因）：
> 1. `<p>` 本身有段落間距，原始碼裡再留空行會疊成雙倍行距。
> 2. **更重要：草稿是要讓使用者在 Gmail 富文本編輯器裡微調的。** 塞 `<p class=…>`
>    這種結構進去，使用者改一個字就可能整段跑版——而寄不寄、怎麼微調本來就是他的事。
>    `<div dir="ltr">` ＋ `<br>` **正是 Gmail 編輯器自己產生的結構**，所以草稿在編輯器裡的
>    行為會跟他手打的信完全一致。
>
> **禁止**：`class=`、`style=`、`<span>`、`<div>`（外層那一個除外）、任何 CSS。
>
> 實測（2026-09-16 建草稿讀回比對位元組）：`<br>`／`<b>`／`<i>`／`<ul>`／`<li>`／`<table>`
> 送進去讀回來**一個位元組都沒變**；而 `<p>` 之間留空行會讀回 `</p>\r\n\r\n<p>`，
> 也就是收件者看到的雙倍行距。

**寫法範例**（含指令、清單、表格的完整一封）：

```html
<div dir="ltr">Hi 暉東,<br><br>正式站的 HTTPS 已經上線，18 項裡 17 項通過。<br><br>請把步驟 7 這三行的 <b>308 改成 307</b>，其餘不動：<br><pre>location = /api.php     { return 307 https://www.example.com$request_uri; }
location = /connect.php { return 307 https://www.example.com$request_uri; }</pre><br>改完確認：<br><ul><li>回應要有 Location 這一行</li><li>而且指向加密版網址</li></ul><br>Best Regards,<br>甫軒</div>
```

重點：**標籤之間不留空行**（要空一行就寫 `<br><br>`），但 **`<pre>` 裡面的換行照舊保留**——
多行設定就是靠它才貼得出來，實測兩種寫法下 `<pre>` 內的換行都不會被動。
- **不要在草稿裡加簽名檔**——Gmail 會自動附上使用者設定的簽名，重複加會出現兩份。結尾寫到「Best Regards,」加名字即可，或連名字都不寫讓簽名檔接手（看使用者習慣）。

**信裡有網址／指令／設定內容時，一律改走 `htmlBody`——純文字 `body` 會被 Gmail 竄改。**

Gmail 建草稿時會把內文裡的網址**自動改寫成自家轉址連結**，長這樣：

```
原本寫的：  return 307 https://www.nuvoton-mcu.com$request_uri;
對方看到的：return 307 https://www.google.com/url?q=https://www.nuvoton-mcu.com&source=gmail&ust=1789569257762000&sa=E$request_uri
```

**後果是對方照貼就貼到錯的位址**——設定檔的轉址目標變成 Google、curl 指令打到 Google。信裡只要有「請照這段貼上去」的內容（nginx／Apache 設定、curl／wget 指令、API endpoint、資料庫連線字串、檔案下載連結），就會中。

**實測結論**（2026-09-15 對 Gmail 建草稿實打驗證，非推論）：

| 寫法 | 結果 |
|------|------|
| `body` 純文字，網址直接寫 | ❌ 被改寫 |
| `body` 純文字，去掉 `https://` 只留 `www.x.com` | ❌ 照樣被改寫（還自動補上 `http://`） |
| `body` 純文字，網址包 `[ ]` 或 `< >` | ❌ 被改寫 |
| `body` 純文字，整段縮排四格當程式碼區塊 | ❌ 被改寫 |
| `body` 純文字，塞零寬空格斷開 | ❌ 被改寫，而且把零寬字元一起吃進網址裡 |
| **`htmlBody`，網址直接寫**（含 `<pre>`、`<code>`、`<a>`） | ✅ **顯示文字原封不動**，只有 `href` 被改寫 |

**所以做法是**：

1. **這封信只要含一個以上「要對方複製貼上」的網址或指令，就給 `htmlBody`**——這是前面「預設只給純文字」那條規則的明確例外，不必再找使用者確認。
2. **可貼的內容包在 `<pre>` 裡**，其餘照上面的白名單用 `<br>`、`<b>`，一樣不要塞 CSS。`<pre>` 除了保住網址，也順便保住換行與縮排——純文字路徑另一個坑是**多行設定會被擠成同一行**（`}location = /connect.php`），對方根本貼不了。
3. **`body` 還是要給**（同一份內容的純文字版），當作不支援 HTML 的信箱的退路；那一份裡的網址會被改寫，所以**純文字版把可貼內容換成一句「完整內容見報告第 N 節」**，不要留半殘的指令。
4. **建完一定要 `get_draft` 讀回來看**，用 `messageFormat: FULL_CONTENT` 檢查 `htmlBody` 裡**標籤之間的顯示文字**是不是原本寫的網址（`href` 被改寫是正常的、不用管）。**掃到 `google.com/url?q=` 出現在顯示文字裡就是壞了**，重建。

**沒辦法用 HTML、或內容太長的時候**（例如整份設定檔），才退成「信裡不貼、指到報告第 N 節」，並且**在信裡明講為什麼**（「信件系統會自動改寫網址，貼在信裡反而會貼到錯的位址，完整內容放在報告第五節」）——讓對方知道要去翻報告，而不是以為你漏給了。**不要默默把網址整個拿掉、也不要代換成 `[站台網址]` 這種佔位符**：對方看不懂那要填什麼（2026-09-15 使用者當面退過這個做法）。

**建完務必說明「已建草稿、未寄出」**——寄信是對外動作，一律讓使用者自己按送出。

## 第四步：交出草稿，讓使用者微調

把整段訊息**直接輸出成一塊可整段複製的文字**（不要拆段落夾註解）。輸出後可補一句「收件人/檔名/版本要調再跟我說」。

**已依第三步之三建成 Gmail 草稿時**，對話裡就不必再貼一次全文——改成給那張「收件人／副本／立場」摘要表，加上要使用者拍板的幾點（副本帶了誰、有沒有沒開的附件、兩封信的刻意差異）。全文已經在草稿裡，重貼一次只是洗版。

**若這封信有任何項目被降級處理，在訊息之外（不在信裡）告知使用者一行**，讓他有覆核機會：

- 歸為「另案建議」的安全性項目有哪幾項（他可能知道某項其實會出事）
- 因為超過長度上限而被壓成指路的順位 1、2 項目
- 你判斷「前提失效」而改寫過的題目

格式例：「另外提醒：報告裡的三項既有設定風險我判斷跟這次上線無關、在信裡合併成一句了，若其中哪項你覺得該講明就跟我說。」**這是給使用者看的，不要寫進信裡。**

---

## 參考範例（few-shot，照這個語氣與密度寫）

> 四個使用者滿意的範本。**範例是用來抄「語氣與用詞密度」的，不是用來抄結構的**——結構一律由你自己的四個決定導出。
>
> ⚠ **不要拿自己的決定組合去比對範例標籤挑最接近的那個照抄**（那就是換一張皮的選型表）。四個範例只覆蓋 8 種組合裡的 3 種，**「主體＋有提問」「佐證＋無提問」「有提問＋分眾」這些常見組合都沒有範例**；差一個維度就照抄，密度就會錯——這正是舊版連退三次的病。
>
> 正確用法：先定四件事、長出自己的形狀，**再回來看範例的句子怎麼寫**（怎麼一句話定位一份檔、怎麼把判斷放進結論、怎麼收尾）。

### 範例一：逐檔導讀（WAF）——檔案主體 + 無提問 + 單受眾 + 中密度

```
Hi A & B,

附上這次 AWS WAF 的規則封鎖分析，這次共五份檔案：
waf_白話決策報告_v1.1.pdf — 分析彙總文件，紅橘綠灰四色分類，可直接看出哪些規則可以改攔截、哪些先別動。
waf_防火牆規則封鎖分析_v1.1.xlsx — 完整 AWS WAF 規則明細，每條規則的命中數、來源國家、Top IP、打的路徑都在「規則命中彙總」分頁。
waf_raw_suspicious_v1.1.csv — 高風險 Log 明細，從 85 萬筆原始 log 裡篩出的 22,023 筆「高可疑請求」明細（打敏感路徑、命中攻擊規則、風險分高的⋯）。
AWS加條件再攔截_實作文件_v1.pdf — 給工程端的實作文件，列出「加條件再攔」那幾條規則的 label、scope-down 條件與上線注意事項。
AWS_WAF_攔截設定_v1.json — 上一份文件確認無誤後，可直接提供 NextLink 匯入 AWS 的 scope-down 設定檔（上線前填入放行名單 IPSet ARN）。
這次是把 06/11 - 06/18 總共 85 萬筆的 WAF log 拉出來看，裡面實際被打到的有 30 條規則，重點結論：
30 條裡，10 條可以直接改成攔截（命中幾乎全是攻擊，誤擋風險很低，建議優先做）；8 條建議加個條件再攔（有攻擊但也混到正常流量）；3 條先觀察；9 條因為攻擊藏在被遮掉的參數裡、暫時判不出來。
數量跟上次（8/13/5/4）有變動，主要是兩個原因：一是這批 log 開始看得到部分查詢參數的內容（多數仍被遮蔽）；二是這次經過其他工程師 Review，修正了先前的幾條誤判（例如原本誤把合法爬蟲當攻擊、有些規則的攻擊內容其實藏在 log 看不到的地方），整體是往「判斷更精準」的方向調整。
細節都在報告裡了，先看 PDF 抓全貌，要查單條規則再翻 Excel，規則對應的 Log 則在 csv，要看要卡攔截的設定就看實作文件跟 json，有問題再跟我說~

謝謝！
```

### 範例二：逐檔導讀＋子項展開（OppTrack）——檔案主體 + 無提問 + 單受眾 + 中密度

```
Hi C,

收到，已完成 OppTrack System 的跨資料庫存取盤點，依您提供的表格格式彙整，這次附上兩份檔案：

1. OppTrack_跨資料庫存取盤點表.xlsx — 盤點主表，分兩個工作表，每個工作表頂端都有「跨庫定義」說明，可單獨開啟閱讀：
工作表 A（跨資料庫存取）：採用您提供的 7 欄格式，列出存取非主庫之資料庫來源。
工作表 B（跨系統非 DB 存取）：SMTP、網路芳鄰檔案分享、外部 Web 連結。這類沒有 DB Server / DB Name 概念，改用適配欄位呈現，避免一整排「N/A」造成誤判。
2. OppTrack_跨資料庫存取盤點報告.pdf — 詳細說明文件，逐一說明每個存取點的用途、連線方式與注意事項，並附主庫存取對照、需 DBA 確認事項，以及改寫規劃重點摘要。

這次盤點的重點結論：
跨資料庫（DB）存取實際只有 NuIDB（dbsrv-01）這一個庫，共 4 個存取點：
BTP 報價查詢（GetBTP）：您信中範例所指的核心。查 ERPDB_SD.vwBTP 取 BTP 價格，供 File Upload 價格檢查（UnitPrice 不得超過 5×BTP）。ERPDB_SD 是 NuIDB 庫內的 View，存取止於這個庫，不會再跨到第三方系統，影響範圍相對單純。
新增客戶公司編號：這是唯一一個對非主庫的寫入操作，改寫風險最高，建議優先評估。
取 D365 案件 GUID：寄報價通知信時查 OppTrack_System 串接 D365 網址。
WAPDB：程式雖已設定此連線並提供給約 15 個功能模組使用，但目前完全沒有實際查詢，實務上零流量，改寫時可直接移除以簡化程式。
跨系統（非 DB）存取：另有 SMTP 寄信、網路芳鄰檔案分享（\\10.x.x.x，下載/上傳檔案）、外部參考設計連結，細節在工作表 B。
* 需請 DBA/infra同仁 協助確認的事項（已列在盤點報告第四節）：主庫 Stored Procedure（spGetReport / spGetParts 等）內部是否再跨庫、網路芳鄰 PRD/DEV 路徑，以及 SMTP 端點來源。
=> Stored Procedure 我這邊沒有資料庫權限無法代為確認~

建議先看 Excel 工作表 A 抓全貌，要看每個存取點的細節再翻說明文件。有任何問題再跟我說~
```

### 範例三：分眾（碳排模組設計文件）——檔案主體 + 無提問 + 多類分眾

```
Hi D & E,
入庫品碳排資料模組的第一版設計文件出爐，請詳信件附檔，檔案眾多，以下稍作說明~

▌ 使用者（物管 / 採購 / 需求單位）
   → design-screens.pdf：UX 決策 + POC 畫面連結
   → sa.pdf（業務分析：流程、規則、stakeholders）
   重點：51 欄業務定義、防呆 A/B/C 規則、年度調查時程（6/1、6/15、12/1、12/15 共 4 個發信日）、Excel 上傳一律進暫存、廠商補完佐證按送出才正式提交。

▌ IT（內部開發）
   可按以下順序：sa.pdf → sd.pdf → impl.pdf → design-screens.pdf
   - sa.pdf：業務背景
   - sd.pdf：架構決策（Aggregate / Repository / 4 態雙軸 / Workflow）
   - impl.pdf：實作細節（DB Schema / SQL Migration /
     EntityConfig / Handler 偽碼）
   - design-screens.pdf：UX 決策 + POC 畫面連結

▌ 碳會計 IT
   → 只看 public-api.pdf，2 隻 API 完整 spec、範例 JSON、
     增量同步流程都在裡面，對外只開放基本資料+碳排資料，綠色採購資料不提供於此API。

有問題直接 reply 或 Teams 我，謝謝~
```

### 範例四：逐題回覆（B 論壇 HTTPS）——檔案佐證 + 有提問 + 單受眾 + 高壓縮

> 示範重點：組織軸是**對方的題號**（檔案退到結尾）、**題目標籤照抄對方用詞**（「Nginx HTTPS Reverse Proxy」沒改寫）、**第 2 題前提校正**（對方問測試環境建置與需要什麼協助，我方先講「已建好、不需你給資料」再講「但需要另一批資料才能收斂工作天」）。
>
> **密度上的注意**：第 1、3 題各 2–3 句，第 2 題 5 句——**它是刻意的例外**：那題含「前提校正＋要對方給四項資料（阻塞型）＋工作天與曆時數字」三件對方要拿去用的事。**三句是常態上限，遇到「校正前提」或「對方要拿去報預算的數字」可以放寬到五句，但整封仍守總長上限。**

```
Hi B,

關於 B 論壇（b-forum.example.com/forum.php）啟用 HTTPS，來信的三個問題我們評估完了。我們已在自己這邊用同版本的論壇軟體（Discuz! X3.2 繁中 UTF8）建好一座對等測試站，把整套架構實際跑過一遍，請詳以下三題回覆：

第 1 題（Nginx HTTPS Reverse Proxy 方案的可行性）

可行，我們認同以此架構作為執行方向，也已實際部署驗證通過。分階段導入的作法我們同意，建議切成三階段，細節在盤點報告。

第 2 題（測試環境建置進度與需要代管商協助提供的資料）

測試站已建置完成，架構層與後端調整層的驗證都已通過——這部分不需要代管商提供任何資料。

但還是需要請代管商協助提供資料，才能把工作天收斂成定量。建議先行提供伺服器設定檔、已裝外掛清單、站台設定值與主機掌控權歸屬這四項，完整清單列在盤點報告第 7 章。

完整評估報告（技術可行性、建議架構與執行方式、預估時程、所需人力、風險與限制事項）都在附件的盤點報告裡。全案約 21~42 個工作天，曆時約 6~11 週。

第 3 題（B 論壇重建方案評估）

建議先做 HTTPS 化，Rebuild 列為長期規劃議題。兩者不互斥，而且先做 HTTPS 化不會造成重複投資——前置伺服器在 Rebuild 後可直接沿用，新平台放在它後面即可。方向性簡評放在盤點報告附錄，若您們對 Rebuild 有實質興趣，建議另立評估案。

附件兩份：

B 論壇HTTPS_盤點報告.pdf — 完整評估內容，包含結論、建議架構與三階段執行方式、時程與人力、風險清單，以及需要代管商提供的資料清單。Rebuild 評估在附錄。

B 論壇HTTPS_技術架構細節.pdf — 給工程端看的實作層文件。

建議先看盤點報告第 1 章抓全貌，要看實作細節再翻技術架構細節。有任何問題，或需要就其中某一項再展開說明，隨時告知，謝謝！
```

### 從四個範例提煉的可複用要點

- **密度差異來自決定組合，不是來自「選了不同的型」**：範例一、二每檔寫兩三句並展開子項；範例四每題二三句（第 2 題因含前提校正與要對方拿去報預算的數字放寬到五句）、附件一句話帶過。同一個 skill 兩種密度是正常的。
- 逐檔說明用 `檔名 — 說明`；**內容多時可編號 1./2. 並往下展開子項**（工作表 A/B），少時一行一檔即可。
- 檔案排序有邏輯：**彙總/主表 → 明細/說明 → 原始資料 → 實作/設定檔**（從全貌到細節到可執行）。
- **結論兩種寫法都行**：分類少而清楚 → 像 WAF 用一段串（帶數字）；存取點/項目各有故事 → 像 OppTrack 逐項講、每項帶判斷。**能帶判斷就別只陳述事實。**
- **開場回應委託、呼應對方原信**（「收到，已完成…」「您信中範例所指的核心」「依您提供的格式」）。
- **誠實區塊**：需別人配合確認的獨立列一區；自己權限不足做不到的直說（「我沒有 DB 權限無法代為確認~」）。
- **（逐題回覆）題目標籤照抄、內文翻白話**：兩者不衝突——標籤是為了讓對方對齊自己的信，內文是為了讓看不懂技術的人也讀得懂。
- **（逐題回覆）前提校正比照答有用**：對方問了不存在的東西（已建好的環境要多少錢），校正前提再答校正後的問題。
- **（分眾）同一份檔案可出現在多個受眾區塊**，各區塊用各自角度定位它，不必去重；「重點：」行是該受眾的濃縮先修，讓對方不開檔就有正確預期。