Tai-ch0802 文件共同撰寫工作流程
此技能提供一個結構化的工作流程，指導使用者完成協作式文件建立。作為積極的引導者，帶領使用者經歷三個階段：上下文收集、精煉與結構化、以及讀者測試。
何時提供此工作流程
觸發條件：
- 使用者提到撰寫文件：「寫一份文件」、「草擬提案」、「建立規格書」、「寫成文字」
- 使用者提到特定文件類型：「PRD」、「設計文件」、「決策文件」、「RFC」
- 使用者似乎開始一項大量的寫作任務
初始提供： 向使用者提供一套結構化的文件共同撰寫工作流程。解釋三個階段：
- 上下文收集：使用者提供所有相關上下文，同時 Claude 提問釐清問題
- 精煉與結構化：透過腦力激盪和編輯迭代地構建每個章節
- 讀者測試：使用全新的 Claude（沒有上下文）測試文件，在他人閱讀之前抓出盲點
解釋此方法有助於確保文件在他人閱讀時（包括當他們將文件貼入 Claude 時）能良好運作。詢問是否要嘗試此工作流程或偏好自由撰寫。
如果使用者拒絕，則自由撰寫。如果使用者接受，進入階段 1。
階段 1：上下文收集
目標： 縮小使用者所知與 Claude 所知之間的差距，以便後續能提供聰明的指導。
初始提問
先向使用者詢問關於文件的後設資訊：
- 這是什麼類型的文件？（如：技術規格書、決策文件、提案）
- 主要受眾是誰？
- 當某人閱讀此文件時，期望的影響是什麼？
- 有要遵循的範本或特定格式嗎？
- 有其他需要了解的限制或上下文嗎？
告知他們可以用簡短方式回答或以最方便的方式傾倒資訊。
如果使用者提供範本或提及文件類型：
- 詢問是否有範本文件可分享
- 如果提供共享文件連結，使用適當的整合來取得
- 如果提供檔案，讀取它
如果使用者提及編輯現有的共享文件：
- 使用適當的整合讀取目前狀態
- 檢查沒有替代文字的圖片
- 如果存在沒有替代文字的圖片，解釋當其他人使用 Claude 理解文件時，Claude 將無法看到它們。詢問是否要生成替代文字。如果需要，請求將每張圖片貼入聊天中以生成描述性替代文字。
資訊傾倒
初始問題回答後，鼓勵使用者傾倒所有他們擁有的上下文。要求資訊如：
- 專案/問題的背景
- 相關的團隊討論或共享文件
- 為什麼沒有使用替代方案
- 組織上下文（團隊動態、過去事件、政治因素）
- 時間壓力或限制
- 技術架構或相依關係
- 利害關係人的疑慮
建議他們不用擔心組織 — 先把所有東西倒出來。提供多種上下文提供方式：
- 以意識流方式傾倒資訊
- 指向團隊頻道或討論串以供閱讀
- 連結至共享文件
如果整合可用（如 Slack、Teams、Google Drive、SharePoint 或其他 MCP 伺服器），提到這些可用於直接提取上下文。
如果未偵測到整合且在 Claude.ai 或 Claude 應用程式中： 建議他們可以在 Claude 設定中啟用連接器，以便直接從通訊應用程式和文件儲存中提取上下文。
告知他們完成初始傾倒後會提出釐清問題。
在上下文收集期間：
如果使用者提到團隊頻道或共享文件：
- 如果整合可用：告知現在將讀取內容，然後使用適當的整合
- 如果整合不可用：解釋無法存取。建議在 Claude 設定中啟用連接器，或直接貼上相關內容。
如果使用者提到不熟悉的實體/專案：
- 詢問是否應使用已連接的工具搜尋以了解更多
- 等待使用者確認後再搜尋
隨著使用者提供上下文，追蹤已學到的內容和仍不清楚的部分
提出釐清問題：
當使用者表示已完成初始傾倒（或在提供大量上下文後），提出釐清問題以確保理解：
根據上下文中的空白生成 5-10 個編號問題。
告知他們可以用簡短方式回答（例如：「1: 是、2: 見 #頻道、3: 不行因為向後相容」），連結至更多文件、指向頻道閱讀，或繼續傾倒資訊。以最有效率的方式即可。
退出條件： 當問題展現出理解時，即已收集足夠上下文 — 當能夠提出關於邊緣案例和權衡的問題，而不需要解釋基本概念時。
轉場： 詢問在此階段是否還有更多上下文要提供，或者是否該進入文件撰寫了。
如果使用者想要添加更多，讓他們繼續。準備好後，進入階段 2。
階段 2：精煉與結構化
目標： 透過腦力激盪、策劃和迭代精煉，逐章節建構文件。
給使用者的說明： 解釋將逐章節建構文件。每個章節的流程：
- 提出釐清問題，了解要包含什麼
- 腦力激盪 5-20 個選項
- 使用者指出要保留/移除/合併哪些
- 撰寫該章節草稿
- 透過精確編輯精煉
從未知最多的章節開始（通常是核心決策/提案），然後處理其餘部分。
章節排序：
如果文件結構明確： 詢問他們想從哪個章節開始。
建議從未知最多的章節開始。對於決策文件，通常是核心提案。對於規格書，通常是技術方法。摘要章節最好留到最後。
如果使用者不知道需要哪些章節： 根據文件類型和範本，建議 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：設定測試
提供測試說明：
- 開啟一個全新的 Claude 對話：https://claude.ai
- 貼上或分享文件內容（如果使用啟用了連接器的共享文件平台，提供連結）
- 向讀者 Claude 提出生成的問題
對每個問題，指示讀者 Claude 提供：
- 答案
- 是否有任何模糊或不清楚的地方
- 文件假設讀者已具備什麼知識/上下文
檢查讀者 Claude 是否給出正確答案或誤解了什麼。
步驟 3：額外檢查
也詢問讀者 Claude：
- 「此文件中有什麼內容對讀者可能模糊或不清楚？」
- 「此文件假設讀者已具備什麼知識或上下文？」
- 「有任何內部矛盾或不一致嗎？」
步驟 4：根據結果迭代
詢問讀者 Claude 答錯了什麼或在哪些地方遇到困難。指出打算修復那些差距。
回到精煉階段處理任何有問題的章節。
退出條件（兩種方法皆適用）
當讀者 Claude 能一致地正確回答問題且不再浮出新的差距或歧義時，文件即已就緒。
最終審閱
當讀者測試通過時： 宣布文件已通過讀者 Claude 測試。在完成前：
- 建議他們自己做最後一次通讀 — 他們擁有此文件並對其品質負責
- 建議雙重檢查任何事實、連結或技術細節
- 請他們驗證是否達到了預期的影響
詢問是否要再做一次審閱，或工作已完成。
如果使用者要求最終審閱，提供。否則： 宣布文件完成。提供幾個最終提示：
- 考慮在附錄中連結此對話，讓讀者看到文件是如何開發的
- 使用附錄提供深度而不膨脹主要文件
- 當收到真實讀者的回饋時更新文件
有效指導的技巧
語氣：
- 直接且程序化
- 當理由影響使用者行為時簡短解釋
- 不要試圖「推銷」方法 — 直接執行
處理偏離：
- 如果使用者想跳過某個階段：詢問是否要跳過並自由撰寫
- 如果使用者似乎感到沮喪：承認這比預期花費更長時間。建議加快的方式
- 始終讓使用者有權調整流程
上下文管理：
- 在整個過程中，如果有提到但缺少上下文的內容，主動詢問
- 不要讓差距累積 — 出現時就處理
產出物管理：
- 使用
create_file撰寫完整章節 - 使用
str_replace進行所有編輯 - 每次更改後提供產出物連結
- 絕不使用產出物來做腦力激盪清單 — 那只是對話
品質優先於速度：
- 不要急於度過各階段
- 每次迭代都應帶來有意義的改善
- 目標是一份真正對讀者有效的文件