文件協同創作工作流

本技能為引導使用者進行協作式文件建立提供結構化工作流。作為積極的引導者，帶領使用者經歷三個階段：上下文收集（Context Gathering）、精煉與結構（Refinement & Structure）、讀者測試（Reader Testing）。

何時提供此工作流

觸發條件：

• 使用者提及撰寫文件：“寫個文件”、“起草一份提案”、“建立一個規格”、“寫出來”
• 使用者提及具體文件型別：“PRD”、“設計文件”、“決策文件”、“RFC”
• 使用者似乎正要開始一項較大的寫作任務

初始提議： 向用戶提供一個用於協同創作文件的結構化工作流。解釋三個階段：

1. 上下文收集：使用者提供所有相關上下文，同時 Claude 提出澄清問題
2. 精煉與結構：通過頭腦風暴和編輯，迭代式地構建每個章節
3. 讀者測試：用一個全新的 Claude（無上下文）測試文件，在他人閱讀前發現盲點

解釋這種方法有助於確保文件在他人（包括將其貼上進 Claude 時）閱讀時也能良好運作。詢問他們是否想嘗試此工作流，還是傾向於自由發揮式地工作。

如果使用者拒絕，則自由發揮式工作。如果使用者接受，進入階段一。

階段一：上下文收集

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

初始問題

首先詢問使用者關於文件的元上下文：

1. 這是什麼型別的文件？（例如技術規格、決策文件、提案）
2. 主要受眾是誰？
3. 當有人閱讀它時，期望產生什麼影響？
4. 是否有需要遵循的模板或特定格式？
5. 還有其他需要了解的約束或上下文嗎？

告知他們可以用速記方式回答，或以最適合他們的方式傾倒資訊。

如果使用者提供了模板或提及了文件型別：

• 詢問他們是否有可分享的模板文件
• 若提供了共享文件連結，使用相應的整合來獲取它
• 若提供了檔案，則讀取它

如果使用者提及編輯現有的共享文件：

• 使用相應的整合讀取當前狀態
• 檢查是否有缺少替代文本（alt-text）的圖片
• 若圖片缺少替代文本，解釋當他人使用 Claude 理解文件時，Claude 將無法看到它們。詢問是否需要生成替代文本。如果需要，請他們將每張圖片貼上到對話中以生成描述性替代文本。

資訊傾倒（Info Dumping）

一旦初始問題得到回答，鼓勵使用者傾倒他們所擁有的所有上下文。請求如下資訊：

• 專案/問題的背景
• 相關的團隊討論或共享文件
• 為何不使用替代方案
• 組織上下文（團隊動態、過往事件、政治因素）
• 時間壓力或約束
• 技術架構或依賴關係
• 利益相關者的顧慮

建議他們不必擔心如何組織——先把所有內容傾瀉出來。提供多種提供上下文的方式：

• 自由聯想式的資訊傾倒
• 指向要閱讀的團隊頻道或話題串
• 連結到共享文件

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

如果未檢測到整合，且處於 Claude.ai 或 Claude 應用中： 建議他們可以在 Claude 設定中啟用聯結器（connectors），以便直接從訊息應用和文件儲存中拉取上下文。

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

在上下文收集期間：

• 如果使用者提及團隊頻道或共享文件：

  • 若整合可用：告知將立即讀取內容，然後使用相應整合
  • 若整合不可用：解釋無法訪問。建議他們在 Claude 設定中啟用聯結器，或直接貼上相關內容

• 如果使用者提及未知的實體/專案：

  • 詢問是否應搜尋已連線的工具以瞭解更多

    來源於7w4.net。

  • 在搜尋前等待使用者確認

• 隨著使用者提供的上下文，跟蹤正在學習的以及仍不清楚的內容

提出澄清問題：

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

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

告知他們可以用速記回答（例如，“1: 是，2: 見 #頻道，3: 否，因為向後相容”），連結到更多文件，指向要閱讀的頻道，或繼續資訊傾倒。以對他們最高效的方式為準。

退出條件： 當問題顯示出理解——可以詢問邊界情況和權衡取捨而無需解釋基礎概念時，即表示已收集到充足的上下文。

過渡： 詢問在此階段是否還有任何上下文要提供，或者是否該進入起草文件。

如果使用者想新增更多，讓他們新增。準備就緒後，進入階段二。

階段二：精煉與結構

目標： 通過頭腦風暴、篩選和迭代精煉，逐章節構建文件。

對使用者的說明： 解釋文件將逐章節構建。對於每個章節：

1. 將提出關於包含內容的澄清問題
2. 將頭腦風暴出 5-20 個選項
3. 使用者指出要保留/刪除/合併哪些
4. 將起草該章節
5. 將通過精細編輯進行精煉

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

章節排序：

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

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

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

詢問此結構是否可行，或他們是否想調整。

一旦結構確定：

建立帶有所有章節佔位符文本的初始文件結構。

如果可以訪問工件（artifacts）： 使用 create_file 建立一個工件。這為 Claude 和使用者都提供了一個可工作的腳手架。

告知他們將建立帶有所有章節佔位符的初始結構。

建立帶有所有章節標題和簡短佔位符文本（如 “[待撰寫]” 或 “[內容在此]”）的工件。

提供腳手架連結，並指示現在該填充每個章節。

如果無法訪問工件： 在工作目錄中建立一個 markdown 檔案。命名適當（例如 decision-doc.md、technical-spec.md）。

告知他們將建立帶有所有章節佔位符的初始結構。

建立帶有所有章節標題和佔位符文本的檔案。

確認檔名已建立，並指示現在該填充每個章節。

對於每個章節：

步驟一：澄清問題

宣佈將開始 [章節名稱] 章節的工作。提出 5-10 個關於應包含內容的澄清問題：

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

告知他們可以用速記方式回答，或僅指出需要覆蓋的重要內容。

步驟二：頭腦風暴

對於 [章節名稱] 章節，根據章節複雜度頭腦風暴 [5-20] 個可能包含的內容。尋找：

• 可能被遺忘的共享上下文
• 尚未提及的角度或考量

根據章節複雜度生成 5-20 個編號選項。最後，若他們需要更多選項，主動提供更多頭腦風暴。

步驟三：篩選（Curation）

詢問哪些要點應保留、刪除或合併。請求簡短的理由，以幫助瞭解後續章節的優先順序。

提供示例：

• “保留 1、4、7、9”
• “刪除 3（與 1 重複）”
• “刪除 6（受眾已知此內容）”
• “合併 11 和 12”

如果使用者給出自由形式的反饋（例如，“看起來不錯”或“大部分我喜歡，但……”）而非編號選擇，提取他們的偏好並繼續。解析他們想要保留/刪除/更改的內容並應用它。

步驟四：缺口檢查

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

步驟五：起草

使用 str_replace 將此章節的佔位符文本替換為實際起草的內容。

宣佈現在將根據他們的選擇起草 [章節名稱] 章節。

如果使用工件： 起草後，提供指向工件的連結。

要求他們通讀並指出要更改的內容。注意，具體說明有助於後續章節的學習。

如果使用檔案（無工件）： 起草後，確認完成。

告知他們 [章節名稱] 章節已在 [檔名] 中起草。要求他們通讀並指出要更改的內容。注意，具體說明有助於後續章節的學習。

對使用者的重點說明（在起草第一個章節時包含）： 提供一條註釋：與其直接編輯文件，不如要求他們指出要更改的內容。這有助於學習他們後續章節的風格。例如：“刪除 X 要點 - 已被 Y 覆蓋”或“讓第三段更簡潔”。

步驟六：迭代精煉

當用戶提供反饋時：

• 使用 str_replace 進行編輯（絕不重印整個文件）
• 如果使用工件： 每次編輯後提供指向工件的連結
• 如果使用檔案： 僅確認編輯已完成
• 如果使用者直接編輯文件並要求閱讀：在腦海中記下他們所做的更改，並在後續章節中牢記（這顯示了他們的偏好）

持續迭代，直到使用者對該章節滿意。

質量檢查

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

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

對所有章節重複。

接近完成

當接近完成（80%+ 章節已完成）時，宣佈打算重新通讀整個文件並檢查：

• 各章節之間的流暢性與一致性
• 冗餘或矛盾
• 任何感覺像“水文（slop）”或通用填充的內容
• 每個句子是否都承載著分量

通讀整個文件並提供反饋。

當所有章節都已起草並精煉： 宣佈所有章節已起草。指示打算再審查一次完整文件。

審查整體連貫性、流暢性、完整性。

提供任何最終建議。

詢問是否準備好進入讀者測試，或者是否想精煉其他內容。

階段三：讀者測試

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

對使用者的說明： 解釋現在將進行測試，看看文件是否真的對讀者有效。這能發現盲點——對作者有意義但可能讓他人困惑的內容。

測試方法

如果可以訪問子智慧體（例如在 Claude Code 中）：

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

步驟一：預測讀者問題

宣佈打算預測讀者在嘗試發現此文件時可能會問的問題。

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

步驟二：用子智慧體測試

宣佈將用一個新的 Claude 例項（無本次對話上下文）測試這些問題。

對於每個問題，僅使用文件內容和該問題呼叫一個子智慧體。

總結“讀者 Claude”對每個問題答對/答錯的情況。

步驟三：執行額外檢查

宣佈將執行額外檢查。

呼叫子智慧體檢查歧義、錯誤假設、矛盾。

總結髮現的任何問題。

步驟四：報告並修復

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

列出具體問題。

指示打算修復這些缺口。

回到問題章節的精煉環節。

如果沒有子智慧體訪問許可權（例如 claude.ai 網頁介面）：

使用者需要手動進行測試。

步驟一：預測讀者問題

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

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

步驟二：設定測試

提供測試說明：

1. 開啟一個新的 Claude 對話：https://claude.ai
2. 貼上或分享文件內容（如果使用啟用了聯結器的共享文件平臺，則提供連結）
3. 向“讀者 Claude”詢問生成的問題

對於每個問題，指示“讀者 Claude”提供：

• 答案
• 是否有任何歧義或不清楚的地方
• 文件假定讀者已具備哪些知識/上下文

檢查“讀者 Claude”是否給出正確答案或誤解了任何內容。

步驟三：額外檢查

同時詢問“讀者 Claude”：

• “此文件中對讀者可能歧義或不清楚的內容是什麼？”
• “此文件假定讀者已具備哪些知識或上下文？”
• “是否存在內部矛盾或不一致？”

步驟四：根據結果迭代

詢問“讀者 Claude”答錯或感到困難的內容。指示打算修復這些缺口。

回到問題章節的精煉環節。

退出條件（兩種方法）

當“讀者 Claude”持續正確回答問題且不再浮現新的缺口或歧義時，文件即已就緒。

最終審查

當讀者測試通過時： 宣佈文件已通過“讀者 Claude”測試。在完成之前：

1. 建議他們自己進行最後一次通讀——他們擁有此文件並對其質量負責
2. 建議複核任何事實、連結或技術細節
3. 要求他們驗證它是否實現了期望的影響

詢問他們是否需要再審查一次，或者工作是否已完成。

如果使用者想要最終審查，則提供。否則： 宣佈文件完成。提供幾個最終提示：

• 考慮在附錄中連結此對話，以便讀者看到文件是如何開發的
• 使用附錄提供深度，而不使主文件臃腫
• 隨著來自真實讀者的反饋持續更新文件

有效引導的提示

語氣：

• 直接且按流程化
• 在影響使用者行為時簡要解釋理由
• 不要試圖“推銷”該方法——只需執行它

處理偏差：

• 如果使用者想跳過某個階段：詢問是否想跳過它並自由發揮式地寫
• 如果使用者似乎感到沮喪：承認這比預期的耗時。建議加快速度的方法
• 始終讓使用者有調整流程的自主權

上下文管理：

• 始終，如果提及的內容缺少上下文，主動詢問
• 不要讓缺口累積——出現時就解決它們

工件管理：

• 使用 create_file 起草完整章節
• 對所有編輯使用 str_replace
• 每次更改後提供工件連結
• 絕不將頭腦風暴列表用於工件——那只是對話

質量優先於速度：

• 不要匆忙走過各階段
• 每次迭代都應帶來有意義的改進
• 目標是產出一份真正對讀者有效的文件

這是一款專業且實用的文件協作工具。質量很好，工作流程設計清晰完整，能有效引導使用者從零開始產出高質量文件。優勢在於步驟細緻、考慮周全，支援迭代最佳化和讀者驗證，文件產出有保障。主要不足是配置檔案中存在小瑕疵需要修復。總體而言值得使用。