引導使用者透過結構化工作流程共同撰寫文件。當使用者想要撰寫文件、提案、技術規格、決策文件或類似結構化內容時使用。此工作流程幫助使用者有效傳遞背景脈絡、透過迭代優化內容，並驗證文件對讀者有效。當使用者提到撰寫文件、建立提案、草擬規格或類似文件任務時觸發。
文件共同撰寫工作流程
此技能提供結構化工作流程，引導使用者協作建立文件。扮演主動引導者，帶領使用者經歷三個階段：背景脈絡收集、優化與結構、以及讀者測試。
何時提供此工作流程
觸發條件：
- 使用者提到撰寫文件：「寫一份文件」、「草擬提案」、「建立規格」、「寫下來」
- 使用者提到特定文件類型：「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：見 #channel，3：否因為向後相容」）、連結到更多文件、指向要讀取的頻道，或繼續傾倒資訊。以對他們最有效率的方式進行。
退出條件：
當問題顯示已充分理解——能夠詢問邊界情況和取捨，而無需解釋基礎知識時，表示已收集足夠背景。
過渡：
詢問他們在此階段是否還有更多背景要提供，或者是否該進入草擬文件階段。
如果使用者想補充更多，讓他們補充。準備好後，進入階段 2。
階段 2：優化與結構
**目標：**透過腦力激盪、篩選和迭代優化，逐步建立文件的每個章節。
給使用者的指示：
說明文件將逐章節建立。對於每個章節：
- 會提出釐清問題，詢問應包含哪些內容
- 會腦力激盪 5-20 個選項
- 使用者會指出要保留/移除/合併哪些內容
- 會草擬該章節
- 會透過精確編輯進行優化
從最不確定的章節開始（通常是核心決策/提案），然後處理其餘部分。
章節順序：
如果文件結構明確：
詢問他們想從哪個章節開始。
建議從最不確定的章節開始。對於決策文件，通常是核心提案。對於規格文件，通常是技術方法。摘要章節最好留到最後。
如果使用者不知道需要哪些章節：
根據文件類型和範本，建議 3-5 個適合該文件類型的章節。
詢問這個結構是否可行，或者他們是否想調整。
一旦結構確定：
建立初始文件結構，所有章節都使用佔位文字。
如果可以存取 artifacts：
使用 create_file 建立 artifact。這為 Claude 和使用者提供了可操作的框架。
告知他們將建立包含所有章節佔位文字的初始結構。
建立包含所有章節標題和簡短佔位文字（如「[待撰寫]」或「[內容在此]」）的 artifact。
提供 scaffold 連結，並表示是時候填入每個章節的內容了。
如果無法存取 artifacts：
在工作目錄中建立一個 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 將此章節的佔位文字替換為實際草擬的內容。
宣布現在將根據他們選擇的內容草擬 [章節名稱] 章節。
如果使用 artifacts：
草擬後，提供 artifact 的連結。
請他們閱讀並指出要更改的內容。注意，具體說明有助於後續章節的學習。
如果使用檔案（無 artifacts）：
草擬後，確認完成。
告知他們 [章節名稱] 章節已草擬於 [filename] 中。請他們閱讀並指出要更改的內容。注意，具體說明有助於後續章節的學習。
給使用者的關鍵指示（在草擬第一個章節時包含）：
提供備註：請他們不要直接編輯文件，而是指出要更改的內容。這有助於學習他們的風格，以便後續章節。例如：「移除 X 項目符號——Y 已涵蓋」或「讓第三段更簡潔」。
步驟 6：迭代優化
當使用者提供回饋時：
- 使用
str_replace進行編輯（絕不重新列印整份文件） - **如果使用 artifacts：**每次編輯後提供 artifact 連結
- **如果使用檔案：**僅確認編輯完成
- 如果使用者直接編輯文件並要求讀取：在心裡記下他們所做的更改，並在後續章節中記住（這顯示了他們的偏好）
持續迭代直到使用者對該章節滿意。
品質檢查
在連續 3 次迭代沒有實質性更改後，詢問是否可以移除任何內容而不遺失重要資訊。
當章節完成時，確認 [章節名稱] 已完成。詢問是否準備好進入下一個章節。
對所有章節重複。
接近完成
當接近完成（80% 以上的章節完成）時，宣布將重新閱讀整份文件並檢查：
- 各章節之間的流暢度和一致性
- 冗餘或矛盾
- 任何感覺像是「廢話」或通用填充的內容
- 每個句子是否都有分量
閱讀整份文件並提供回饋。
當所有章節都草擬並優化完成：
宣布所有章節都已草擬。表示將再審查一次完整文件。
審查整體連貫性、流暢度、完整性。
提供任何最終建議。
詢問是否準備好進入讀者測試，或者是否想進一步優化。
階段 3：讀者測試
**目標：**用全新的 Claude（無背景脈絡洩漏）測試文件，以驗證其對讀者有效。
給使用者的指示：
說明現在將進行測試，以確認文件是否真的對讀者有效。這能找出盲點——作者覺得合理但可能讓其他人困惑的內容。
測試方法
如果可以存取子代理（例如在 Claude Code 中）：
直接進行測試，無需使用者參與。
步驟 1：預測讀者問題
宣布將預測讀者在嘗試發現此文件時可能提出的問題。
產生 5-10 個讀者會實際提出的問題。
步驟 2：使用子代理測試
宣布將用全新的 Claude 實例（無此對話的背景）測試這些問題。
對於每個問題，調用一個子代理，僅提供文件內容和該問題。
總結 Reader Claude 對每個問題回答正確/錯誤的部分。
步驟 3：執行額外檢查
宣布將執行額外檢查。
調用子代理檢查模糊性、錯誤假設、矛盾。
總結發現的任何問題。
步驟 4：報告與修正
如果發現問題：
報告 Reader Claude 在特定問題上遇到困難。
列出具體問題。
表示將修正這些缺口。
回到有問題章節的優化階段。
如果無法存取子代理（例如 claude.ai 網頁介面）：
使用者需要手動進行測試。
步驟 1：預測讀者問題
詢問人們在嘗試發現此文件時可能提出的問題。他們會在 Claude.ai 中輸入什麼？
產生 5-10 個讀者會實際提出的問題。
步驟 2：設定測試
提供測試指示：
- 開啟一個全新的 Claude 對話：https://claude.ai
- 貼上或分享文件內容（如果使用已啟用連接器的共享文件平台，提供連結）
- 向 Reader Claude 詢問產生的問題
對於每個問題，指示 Reader Claude 提供：
- 答案
- 是否有任何模糊或不清楚的地方
- 文件假設讀者已經知道哪些知識/背景
檢查 Reader Claude 是否給出正確答案或誤解任何內容。
步驟 3：額外檢查
也詢問 Reader Claude：
- 「這份文件中哪些內容可能對讀者模糊或不清楚？」
- 「這份文件假設讀者已經具備哪些知識或背景？」
- 「是否有任何內部矛盾或不一致？」
步驟 4：根據結果迭代
詢問 Reader Claude 回答錯誤或遇到困難的內容。表示將修正這些缺口。
回到任何有問題章節的優化階段。
退出條件（兩種方法皆適用）
當 Reader Claude consistently 正確回答問題，且不再出現新的缺口或模糊性時，文件就準備好了。
最終審查
當讀者測試通過時：
宣布文件已通過 Reader Claude 測試。在完成之前：
- 建議他們自己進行最終通讀——他們擁有這份文件並對其品質負責
- 建議再次檢查任何事實、連結或技術細節
- 請他們確認文件達到了他們想要的影響
詢問他們是否想要再審查一次，或者工作是否完成。
如果使用者想要最終審查，提供審查。否則：
宣布文件完成。提供一些最終提示：
- 考慮在附錄中連結此對話，以便讀者了解文件的開發過程
- 使用附錄提供深度，而不使主文件臃腫
- 根據真實讀者的回饋更新文件
有效引導的技巧
語氣：
- 直接且程序化
- 在影響使用者行為時簡短說明理由
- 不要試圖「推銷」這個方法——直接執行
處理偏離：
- 如果使用者想跳過某個階段：詢問他們是否想跳過並自由發揮
- 如果使用者感到沮喪：承認這比預期花費更長時間。建議加快速度的方法
- 始終讓使用者有權調整流程
背景管理：
- 在整個過程中，如果缺少關於某個提及事項的背景，主動提問
- 不要讓缺口累積——在出現時就處理
Artifact 管理：
- 使用
create_file草擬完整章節 - 使用
str_replace進行所有編輯 - 每次更改後提供 artifact 連結
- 絕不使用 artifacts 進行腦力激盪列表——那只是對話
品質重於速度：
- 不要急著完成階段
- 每次迭代都應帶來有意義的改進
- 目標是產出一份對讀者真正有效的文件
