文件協同創作
📖 技能介紹
name: doc-coauthoring slug: doc-coauthoring displayName: 文件協同創作 description: 引導使用者通過結構化工作流進行文件協同創作。用於使用者想要撰寫文件、提案、技術規格、決策文件或類似結構化內容時。該工作流幫助使用者高效傳遞上下文、通過迭代精煉內容，並驗證文件對讀者是否有效。當用戶提及撰寫文件、建立提案、起草規格或類似文件任務時觸發。 summary: 引導使用者通過上下文收集、精煉結構與讀者測試三階段創作文件。 version: 1.0.0
文件協同創作工作流
本技能為引導使用者進行協作式文件建立提供結構化工作流。作為積極的引導者，帶領使用者經歷三個階段：上下文收集（Context Gathering）、精煉與結構（Refinement & Structure）、讀者測試（Reader Testing）。
何時提供此工作流
觸發條件： - 使用者提及撰寫文件：“寫個文件”、“起草一份提案”、“建立一個規格”、“寫出來” - 使用者提及具體文件型別：“PRD”、“設計文件”、“決策文件”、“RFC” - 使用者似乎正要開始一項較大的寫作任務
初始提議： 向用戶提供一個用於協同創作文件的結構化工作流。解釋三個階段：
- 上下文收集：使用者提供所有相關上下文，同時 Claude 提出澄清問題
- 精煉與結構：通過頭腦風暴和編輯，迭代式地構建每個章節
- 讀者測試：用一個全新的 Claude（無上下文）測試文件，在他人閱讀前發現盲點
解釋這種方法有助於確保文件在他人（包括將其貼上進 Claude 時）閱讀時也能良好運作。詢問他們是否想嘗試此工作流，還是傾向於自由發揮式地工作。
如果使用者拒絕，則自由發揮式工作。如果使用者接受，進入階段一。
階段一：上下文收集
目標： 縮小使用者已知與 Claude 已知之間的差距，以便後續提供明智的指導。
初始問題
首先詢問使用者關於文件的元上下文：
- 這是什麼型別的文件？（例如技術規格、決策文件、提案）
- 主要受眾是誰？
- 當有人閱讀它時，期望產生什麼影響？
- 是否有需要遵循的模板或特定格式？
- 還有其他需要了解的約束或上下文嗎？
告知他們可以用速記方式回答，或以最適合他們的方式傾倒資訊。
如果使用者提供了模板或提及了文件型別： - 詢問他們是否有可分享的模板文件 - 若提供了共享文件連結，使用相應的整合來獲取它 - 若提供了檔案，則讀取它
如果使用者提及編輯現有的共享文件： - 使用相應的整合讀取當前狀態 - 檢查是否有缺少替代文本（alt-text）的圖片 - 若圖片缺少替代文本，解釋當他人使用 Claude 理解文件時，Claude 將無法看到它們。詢問是否需要生成替代文本。如果需要，請他們將每張圖片貼上到對話中以生成描述性替代文本。
資訊傾倒（Info Dumping）
一旦初始問題得到回答，鼓勵使用者傾倒他們所擁有的所有上下文。請求如下資訊： - 專案/問題的背景 - 相關的團隊討論或共享文件 - 為何不使用替代方案 - 組織上下文（團隊動態、過往事件、政治因素） - 時間壓力或約束 - 技術架構或依賴關係 - 利益相關者的顧慮
建議他們不必擔心如何組織——先把所有內容傾瀉出來。提供多種提供上下文的方式： - 自由聯想式的資訊傾倒 - 指向要閱讀的團隊頻道或話題串 - 連結到共享文件
如果可用整合（例如 Slack、Teams、Google Drive、SharePoint 或其他 MCP 伺服器），提及可以利用這些直接拉取上下文。
如果未檢測到整合，且處於 Claude.ai 或 Claude 應用中： 建議他們可以在 Claude 設定中啟用聯結器（connectors），以便直接從訊息應用和文件儲存中拉取上下文。
告知他們，完成初始傾倒後會提出澄清問題。
在上下文收集期間：
- 如果使用者提及團隊頻道或共享文件：
- 若整合可用：告知將立即讀取內容，然後使用相應整合
-
若整合不可用：解釋無法訪問。建議他們在 Claude 設定中啟用聯結器，或直接貼上相關內容
-
如果使用者提及未知的實體/專案：
- 詢問是否應搜尋已連線的工具以瞭解更多
-
在搜尋前等待使用者確認
-
隨著使用者提供的上下文，跟蹤正在學習的以及仍不清楚的內容
提出澄清問題：
當用戶表示已完成初始傾倒（或在提供了大量上下文之後），提出澄清問題以確保理解：
根據上下文中的空白，生成 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 將此章節的佔位符文本替換為實際起草的內容。
宣佈現在將根據他們的選擇起草 [章節名稱] 章節。
如果使用工件： 起草後，提供指向工件的連結。
要求他們通讀並指出要更改的內容。注意，具體說明有助於後續章節的學習。
如果使用檔案（無工件）： 起草後，確認完成。
告知他們 [章節名稱] 章節已在 [檔名] 中起草。要求他們通讀並指出要更改的內容。注意，具體說明有助於後續章節的學習。
7w4.net小蔥技能。
對使用者的重點說明（在起草第一個章節時包含）： 提供一條註釋：與其直接編輯文件，不如要求他們指出要更改的內容。這有助於學習他們後續章節的風格。例如：“刪除 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”測試。在完成之前：
- 建議他們自己進行最後一次通讀——他們擁有此文件並對其質量負責
- 建議複核任何事實、連結或技術細節
- 要求他們驗證它是否實現了期望的影響
詢問他們是否需要再審查一次，或者工作是否已完成。
如果使用者想要最終審查，則提供。否則： 宣佈文件完成。提供幾個最終提示： - 考慮在附錄中連結此對話，以便讀者看到文件是如何開發的 - 使用附錄提供深度，而不使主文件臃腫 - 隨著來自真實讀者的反饋持續更新文件
有效引導的提示
語氣： - 直接且按流程化 - 在影響使用者行為時簡要解釋理由 - 不要試圖“推銷”該方法——只需執行它
處理偏差： - 如果使用者想跳過某個階段：詢問是否想跳過它並自由發揮式地寫 - 如果使用者似乎感到沮喪：承認這比預期的耗時。建議加快速度的方法 - 始終讓使用者有調整流程的自主權
上下文管理： - 始終，如果提及的內容缺少上下文，主動詢問 - 不要讓缺口累積——出現時就解決它們
工件管理：
- 使用 create_file 起草完整章節
- 對所有編輯使用 str_replace
- 每次更改後提供工件連結
- 絕不將頭腦風暴列表用於工件——那只是對話
質量優先於速度： - 不要匆忙走過各階段 - 每次迭代都應帶來有意義的改進 - 目標是產出一份真正對讀者有效的文件
🤖 AI 評測
這是一款專業且實用的文件協作工具。質量很好，工作流程設計清晰完整，能有效引導使用者從零開始產出高質量文件。優勢在於步驟細緻、考慮周全，支援迭代最佳化和讀者驗證，文件產出有保障。主要不足是配置檔案中存在小瑕疵需要修復。總體而言值得使用。
