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 進行所有編輯
• 每次更改後提供產出物連結
• 絕不使用產出物來做腦力激盪清單 — 那只是對話

品質優先於速度：

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