# Doc Coauthoring

> 引導使用者完成結構化文件共同撰寫的工作流程。當使用者想撰寫文件、提案、技術規格書、決策文件或類似的結構化內容時使用。此工作流程幫助使用者有效傳遞上下文、透過迭代精煉內容，並驗證文件對讀者是否有效。當使用者提到撰寫文件、建立提案、草擬規格書或類似文件任務時觸發。

- Skill: `tai-ch0802/doc-coauthoring` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tai-ch0802/doc-coauthoring`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tai-ch0802/doc-coauthoring/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Tai-ch0802 (https://skillmd.com/u/tai-ch0802)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/tai-ch0802/doc-coauthoring

---


# 文件共同撰寫工作流程

此技能提供一個結構化的工作流程，指導使用者完成協作式文件建立。作為積極的引導者，帶領使用者經歷三個階段：上下文收集、精煉與結構化、以及讀者測試。

## 何時提供此工作流程

**觸發條件：**
- 使用者提到撰寫文件：「寫一份文件」、「草擬提案」、「建立規格書」、「寫成文字」
- 使用者提到特定文件類型：「PRD」、「設計文件」、「決策文件」、「RFC」
- 使用者似乎開始一項大量的寫作任務

**初始提供：**
向使用者提供一套結構化的文件共同撰寫工作流程。解釋三個階段：

1. **上下文收集**：使用者提供所有相關上下文，同時 Claude 提問釐清問題
2. **精煉與結構化**：透過腦力激盪和編輯迭代地構建每個章節
3. **讀者測試**：使用全新的 Claude（沒有上下文）測試文件，在他人閱讀之前抓出盲點

解釋此方法有助於確保文件在他人閱讀時（包括當他們將文件貼入 Claude 時）能良好運作。詢問是否要嘗試此工作流程或偏好自由撰寫。

如果使用者拒絕，則自由撰寫。如果使用者接受，進入階段 1。

## 階段 1：上下文收集

**目標：** 縮小使用者所知與 Claude 所知之間的差距，以便後續能提供聰明的指導。

### 初始提問

先向使用者詢問關於文件的後設資訊：

1. 這是什麼類型的文件？（如：技術規格書、決策文件、提案）
2. 主要受眾是誰？
3. 當某人閱讀此文件時，期望的影響是什麼？
4. 有要遵循的範本或特定格式嗎？
5. 有其他需要了解的限制或上下文嗎？

告知他們可以用簡短方式回答或以最方便的方式傾倒資訊。

**如果使用者提供範本或提及文件類型：**
- 詢問是否有範本文件可分享
- 如果提供共享文件連結，使用適當的整合來取得
- 如果提供檔案，讀取它

**如果使用者提及編輯現有的共享文件：**
- 使用適當的整合讀取目前狀態
- 檢查沒有替代文字的圖片
- 如果存在沒有替代文字的圖片，解釋當其他人使用 Claude 理解文件時，Claude 將無法看到它們。詢問是否要生成替代文字。如果需要，請求將每張圖片貼入聊天中以生成描述性替代文字。

### 資訊傾倒

初始問題回答後，鼓勵使用者傾倒所有他們擁有的上下文。要求資訊如：
- 專案/問題的背景
- 相關的團隊討論或共享文件
- 為什麼沒有使用替代方案
- 組織上下文（團隊動態、過去事件、政治因素）
- 時間壓力或限制
- 技術架構或相依關係
- 利害關係人的疑慮

建議他們不用擔心組織 — 先把所有東西倒出來。提供多種上下文提供方式：
- 以意識流方式傾倒資訊
- 指向團隊頻道或討論串以供閱讀
- 連結至共享文件

**如果整合可用**（如 Slack、Teams、Google Drive、SharePoint 或其他 MCP 伺服器），提到這些可用於直接提取上下文。

**如果未偵測到整合且在 Claude.ai 或 Claude 應用程式中：** 建議他們可以在 Claude 設定中啟用連接器，以便直接從通訊應用程式和文件儲存中提取上下文。

告知他們完成初始傾倒後會提出釐清問題。

**在上下文收集期間：**

- 如果使用者提到團隊頻道或共享文件：
  - 如果整合可用：告知現在將讀取內容，然後使用適當的整合
  - 如果整合不可用：解釋無法存取。建議在 Claude 設定中啟用連接器，或直接貼上相關內容。

- 如果使用者提到不熟悉的實體/專案：
  - 詢問是否應使用已連接的工具搜尋以了解更多
  - 等待使用者確認後再搜尋

- 隨著使用者提供上下文，追蹤已學到的內容和仍不清楚的部分

**提出釐清問題：**

當使用者表示已完成初始傾倒（或在提供大量上下文後），提出釐清問題以確保理解：

根據上下文中的空白生成 5-10 個編號問題。

告知他們可以用簡短方式回答（例如：「1: 是、2: 見 #頻道、3: 不行因為向後相容」），連結至更多文件、指向頻道閱讀，或繼續傾倒資訊。以最有效率的方式即可。

**退出條件：**
當問題展現出理解時，即已收集足夠上下文 — 當能夠提出關於邊緣案例和權衡的問題，而不需要解釋基本概念時。

**轉場：**
詢問在此階段是否還有更多上下文要提供，或者是否該進入文件撰寫了。

如果使用者想要添加更多，讓他們繼續。準備好後，進入階段 2。

## 階段 2：精煉與結構化

**目標：** 透過腦力激盪、策劃和迭代精煉，逐章節建構文件。

**給使用者的說明：**
解釋將逐章節建構文件。每個章節的流程：
1. 提出釐清問題，了解要包含什麼
2. 腦力激盪 5-20 個選項
3. 使用者指出要保留/移除/合併哪些
4. 撰寫該章節草稿
5. 透過精確編輯精煉

從未知最多的章節開始（通常是核心決策/提案），然後處理其餘部分。

**章節排序：**

如果文件結構明確：
詢問他們想從哪個章節開始。

建議從未知最多的章節開始。對於決策文件，通常是核心提案。對於規格書，通常是技術方法。摘要章節最好留到最後。

如果使用者不知道需要哪些章節：
根據文件類型和範本，建議 3-5 個適合的章節。

詢問此結構是否可行，或是否要調整。

**結構確定後：**

以佔位文字建立所有章節的初始文件結構。

**如果可使用產出物：**
使用 `create_file` 建立產出物。這為 Claude 和使用者提供了一個可依循的架構。

告知將建立包含所有章節佔位符的初始結構。

建立產出物，包含所有章節標題和簡短佔位文字如「[待撰寫]」或「[內容放這裡]」。

提供架構連結並指示該開始填寫每個章節了。

**如果無法使用產出物：**
在工作目錄中建立一個 markdown 檔案。適當命名（例如：`decision-doc.md`、`technical-spec.md`）。

告知將建立包含所有章節佔位符的初始結構。

建立檔案，包含所有章節標題和佔位文字。

確認檔名已建立並指示該開始填寫每個章節了。

**每個章節的流程：**

### 步驟 1：釐清問題

宣布將開始撰寫 [章節名稱] 章節。詢問 5-10 個關於應包含什麼的釐清問題：

根據上下文和章節目的生成 5-10 個特定問題。

告知他們可以用簡短方式回答或僅指出重要的涵蓋內容。

### 步驟 2：腦力激盪

對於 [章節名稱] 章節，腦力激盪 [5-20] 個可能包含的內容，取決於章節的複雜度。尋找：
- 分享過但可能被遺忘的上下文
- 尚未提及的角度或考量

根據章節複雜度生成 5-20 個編號選項。結尾時提供如果需要更多選項可繼續腦力激盪。

### 步驟 3：策劃

詢問哪些要點要保留、移除或合併。要求簡短理由以幫助學習後續章節的優先順序。

提供範例：
- 「保留 1,4,7,9」
- 「移除 3（重複 1）」
- 「移除 6（受眾已知道這個）」
- 「合併 11 和 12」

**如果使用者給出自由形式的回饋**（例如：「看起來不錯」或「我喜歡大部分但是...」）而非編號選擇，提取他們的偏好並繼續。解析他們想保留/移除/更改的內容並套用。

### 步驟 4：空白檢查

根據他們所選的，詢問 [章節名稱] 章節是否有遺漏重要內容。

### 步驟 5：草稿撰寫

使用 `str_replace` 將此章節的佔位文字替換為實際撰寫的內容。

宣布將根據他們的選擇撰寫 [章節名稱] 章節的草稿。

**如果使用產出物：**
撰寫後，提供產出物連結。

請他們閱讀並指出要更改的地方。說明越具體越有助於後續章節的學習。

**如果使用檔案（無產出物）：**
撰寫後，確認完成。

告知 [章節名稱] 章節已撰寫於 [檔名]。請他們閱讀並指出要更改的地方。說明越具體越有助於後續章節的學習。

**給使用者的關鍵說明（在撰寫第一個章節時包含）：**
提供注意：不要直接編輯文件，而是指出要更改的地方。這有助於學習他們的風格以用於後續章節。例如：「移除 X 項目符號 — 已被 Y 涵蓋」或「讓第三段更簡潔」。

### 步驟 6：迭代精煉

隨著使用者提供回饋：
- 使用 `str_replace` 進行編輯（永不重新列印整份文件）
- **如果使用產出物：** 每次編輯後提供產出物連結
- **如果使用檔案：** 只需確認編輯完成
- 如果使用者直接編輯文件並要求閱讀：在心中記下他們所做的更改，並在後續章節中留意（這展示了他們的偏好）

**繼續迭代**直到使用者對章節感到滿意。

### 品質檢查

連續 3 次迭代沒有實質性更改後，詢問是否有任何可以在不遺失重要資訊的情況下移除的內容。

當章節完成時，確認 [章節名稱] 已完成。詢問是否準備好進入下一章節。

**對所有章節重複此流程。**

### 接近完成

接近完成時（80%+ 的章節已完成），宣布打算重新閱讀整份文件並檢查：
- 跨章節的流暢度和一致性
- 冗餘或矛盾
- 任何感覺像「廉價」或泛用填充的內容
- 每個句子是否都有分量

閱讀整份文件並提供回饋。

**當所有章節都已撰寫和精煉：**
宣布所有章節已撰寫完畢。指出打算再次審閱完整文件。

審閱整體連貫性、流暢度、完整性。

提供任何最終建議。

詢問是否準備好進入讀者測試，或是否還要精煉任何內容。

## 階段 3：讀者測試

**目標：** 使用全新的 Claude（無上下文洩漏）測試文件，以驗證它對讀者有效。

**給使用者的說明：**
解釋現在要測試文件是否真的對讀者有效。這能抓出盲點 — 對作者來說有意義但可能讓他人困惑的內容。

### 測試方法

**如果可使用子代理（例如在 Claude Code 中）：**

直接執行測試，無需使用者參與。

### 步驟 1：預測讀者問題

宣布打算預測讀者在試圖發現此文件時可能會提出什麼問題。

生成 5-10 個讀者實際會提出的問題。

### 步驟 2：使用子代理測試

宣布將使用全新的 Claude 實例（沒有此對話的上下文）測試這些問題。

對每個問題，使用僅包含文件內容和問題的子代理。

摘要讀者 Claude 對每個問題的正確/錯誤之處。

### 步驟 3：執行額外檢查

宣布將執行額外檢查。

使用子代理檢查歧義、錯誤假設、矛盾。

摘要發現的任何問題。

### 步驟 4：報告與修復

如果發現問題：
報告讀者 Claude 在特定問題上遇到困難。

列出具體問題。

指出打算修復這些差距。

回到精煉階段處理有問題的章節。

---

**如果無法使用子代理（例如 claude.ai 網頁介面）：**

使用者需要手動測試。

### 步驟 1：預測讀者問題

詢問人們在試圖發現此文件時可能會問什麼問題。他們會在 Claude.ai 中輸入什麼？

生成 5-10 個讀者實際會提出的問題。

### 步驟 2：設定測試

提供測試說明：
1. 開啟一個全新的 Claude 對話：https://claude.ai
2. 貼上或分享文件內容（如果使用啟用了連接器的共享文件平台，提供連結）
3. 向讀者 Claude 提出生成的問題

對每個問題，指示讀者 Claude 提供：
- 答案
- 是否有任何模糊或不清楚的地方
- 文件假設讀者已具備什麼知識/上下文

檢查讀者 Claude 是否給出正確答案或誤解了什麼。

### 步驟 3：額外檢查

也詢問讀者 Claude：
- 「此文件中有什麼內容對讀者可能模糊或不清楚？」
- 「此文件假設讀者已具備什麼知識或上下文？」
- 「有任何內部矛盾或不一致嗎？」

### 步驟 4：根據結果迭代

詢問讀者 Claude 答錯了什麼或在哪些地方遇到困難。指出打算修復那些差距。

回到精煉階段處理任何有問題的章節。

---

### 退出條件（兩種方法皆適用）

當讀者 Claude 能一致地正確回答問題且不再浮出新的差距或歧義時，文件即已就緒。

## 最終審閱

當讀者測試通過時：
宣布文件已通過讀者 Claude 測試。在完成前：

1. 建議他們自己做最後一次通讀 — 他們擁有此文件並對其品質負責
2. 建議雙重檢查任何事實、連結或技術細節
3. 請他們驗證是否達到了預期的影響

詢問是否要再做一次審閱，或工作已完成。

**如果使用者要求最終審閱，提供。否則：**
宣布文件完成。提供幾個最終提示：
- 考慮在附錄中連結此對話，讓讀者看到文件是如何開發的
- 使用附錄提供深度而不膨脹主要文件
- 當收到真實讀者的回饋時更新文件

## 有效指導的技巧

**語氣：**
- 直接且程序化
- 當理由影響使用者行為時簡短解釋
- 不要試圖「推銷」方法 — 直接執行

**處理偏離：**
- 如果使用者想跳過某個階段：詢問是否要跳過並自由撰寫
- 如果使用者似乎感到沮喪：承認這比預期花費更長時間。建議加快的方式
- 始終讓使用者有權調整流程

**上下文管理：**
- 在整個過程中，如果有提到但缺少上下文的內容，主動詢問
- 不要讓差距累積 — 出現時就處理

**產出物管理：**
- 使用 `create_file` 撰寫完整章節
- 使用 `str_replace` 進行所有編輯
- 每次更改後提供產出物連結
- 絕不使用產出物來做腦力激盪清單 — 那只是對話

**品質優先於速度：**
- 不要急於度過各階段
- 每次迭代都應帶來有意義的改善
- 目標是一份真正對讀者有效的文件