前言¶
技術文檔、提案和決策說明往往不是「一次 prompt 出全文」就能交稿。背景散落在頻道和會議紀要裏，作者腦子裏清楚、讀者卻看不懂，定稿前也很少有人用「陌生讀者」視角做驗證。直接在對話裏讓模型自由發揮，容易漏約束、章節失衡，或寫出對作者有意義、對他人卻含糊的段落。
下面介紹 SkillHub 上的 文檔協作撰寫工作流（@org-02qudk26/doc-coauthoring）。它把協作寫作拆成可重複的步驟：先對齊上下文，再按章節迭代起草與打磨，最後用讀者測試檢查盲點。適合在 Cursor、Claude Code 等支持 Agent Skills 的環境裏啓用。
這是什麼¶
文檔協作撰寫工作流 是一條面向 Agent 的結構化指引（通用 SKILL.md 格式），由 智雨科技 發佈，版本 1.0.0，分類爲 content-creation，來源標註爲 enterprise。座標爲 @org-02qudk26/doc-coauthoring；SkillHub 頁面顯示評分 100000，下載約 1592 次，標籤 requires_api_key=false（無需額外 API Key）。
官方簡介：引導用戶走完結構化的文檔協作撰寫工作流；當用戶想撰寫文檔、提案、技術規格、決策文檔或類似結構化內容時使用；幫助高效傳遞上下文、通過迭代打磨內容，並驗證文檔對讀者是否有效。
與「單次生成長文」相比，該 Skill 要求 Agent 充當引導者，按階段推進，並在用戶拒絕流程時退回自由撰寫。
核心功能¶
以下能力均來自技能包內的 SKILL.md 說明。
觸發與入口¶
當用戶提到寫文檔、起草提案、創建規格，或出現 PRD、設計文檔、決策文檔、RFC 等類型時，Agent 應說明三階段流程並詢問是否採用；用戶拒絕則按自由形式寫作。
階段 1：上下文收集¶
- 先問文檔類型、受衆、期望影響、模板或格式、其他約束。
- 鼓勵用戶傾倒背景（項目背景、備選方案、組織上下文、依賴、干係人等）；若有 Slack、Drive 等集成則嘗試拉取，否則提示粘貼或配置連接器。
- 在用戶完成初步傾倒後，提出約 5–10 條澄清問題；理解足夠深入後，再進入起草。
階段 2：打磨與結構¶
- 按文檔類型建議章節，或讓用戶選定順序（通常從「未知數最多」的章節開始，摘要可後置）。
- 建立帶佔位符的全文腳手架（支持製品時用
create_file；否則在工作目錄寫 Markdown，如technical-spec.md）。 - 對每個章節循環：澄清問題 → 頭腦風暴 5–20 條要點 → 用戶篩選保留/刪除/合併 → 空白檢查 → 用
str_replace起草並迭代修改（避免整篇重印）。 - 多數章節完成後，通讀全文檢查流暢性、冗餘與矛盾；全部章節滿意後，可進入讀者測試。
階段 3：讀者測試¶
目標是用「無本對話上下文」的讀者視角檢驗文檔。
- 有子 Agent 的環境（如 Claude Code）：由 Agent 生成讀者可能問的問題，用子 Agent 僅依據文檔作答，並檢查歧義與矛盾；發現問題則回到階段 2 修訂。
- 無子 Agent 的環境：指導用戶在新對話中粘貼文檔並提問；根據 Reader 是否答對、是否誤解來迭代。
讀者測試穩定通過且無明顯新盲點時，流程結束；Skill 建議作者自行覈對事實、鏈接與技術細節，並對文檔質量負責。
安裝與啓用¶
先確認本機已安裝 SkillHub CLI（參見 SkillHub 安裝說明）：
command -v skillhub && skillhub --version
未安裝時可執行官方推薦的一鍵安裝（需聯網）：
curl -fsSL https://skillhub-1388575217.cos.ap-guangzhou.myqcloud.com/install/install.sh | bash
安裝技能時，必須用 --dir 指向當前 Agent 的 skills 目錄，否則默認落在 ./skills/ 可能不會被識別。本 Skill 的安裝命令爲：
skillhub install doc-coauthoring --namespace org-02qudk26 --dir <你的 skills 目錄>
常用客戶端路徑（來自 SkillHub 安裝文檔）：
- Cursor：
~/.cursor/skills/ - Claude Code：
~/.claude/skills/ - Codex：
~/.codex/skills/或項目下的.agents/skills/
也可將安裝提示直接發給 Agent：「請根據 https://skillhub.cn/install/skillhub.md，安裝 @org-02qudk26/doc-coauthoring。」安裝後按各客戶端要求刷新或重啓 Agent，使技能生效。
典型用法¶
1. 用自然語言觸發¶
在已啓用該 Skill 的對話中，說明文檔類型與目標即可，例如：
- 「幫我寫一份技術規格，受衆是後端團隊。」
- 「起草一個是否引入某中間件的決策文檔。」
- 「按 RFC 形式整理這次 API 變更。」
Agent 應主動介紹三階段流程並徵求是否採用。
2. 配合章節迭代¶
接受工作流後，按 Skill 要求用簡寫回答元問題與澄清列表（如「1: 是，2: 見 #channel，3: 否」）。進入階段 2 後，對頭腦風暴列表用「保留 1,4,7 / 刪除 3 / 合併 11 和 12」等方式篩選，比直接改全文更利於 Agent 學習你的取捨。
3. 讀者測試¶
在 Cursor 等若無內置「子 Agent 讀者」，按 Skill 指引新開對話，僅粘貼成稿並提問；把答錯或含糊之處反饋給原對話，回到對應章節打磨。
技能包 README.md 中給出的示意場景包括：複雜遷移提案需先收集約束再排章節、產品規格需補足術語後做讀者測試、投資決策需整理目標、證據、選項與風險等——可作爲選題參考，實際內容仍以你的業務材料爲準。
適用場景與注意¶
適合誰
- 需要寫提案、技術規格、決策文檔、PRD、設計文檔、RFC 等結構化文稿的工程師、架構師、產品與技術負責人。
- 希望把「背景收集 → 分節起草 → 讀者可讀性驗證」固化到 Agent 行爲裏，而不是每次重新描述流程的團隊。
限制與注意
- 流程偏長，Skill 本身允許用戶跳過階段或改用自由撰寫；時間緊時要主動說清期望。
- 文中部分步驟針對 Claude 製品（artifact）與子 Agent；在 Cursor 中通常落爲工作區 Markdown 文件與
str_replace編輯，讀者測試需手動或藉助其他 Agent 能力完成。 - 外部文檔、頻道內容依賴 MCP/連接器；無集成時需自行粘貼上下文。
- SkillHub 統計的下載量會變動，以 SkillHub 技能頁 爲準。
結尾¶
文檔協作撰寫工作流 把結構化寫作拆成上下文收集、按章打磨與讀者測試三步，減少「作者默認讀者已知」帶來的誤解，並強調用增量編輯而非整篇重寫。若你經常在 Agent 裏寫規格或決策類文檔，可以按上文命令安裝到對應 skills 目錄後試用。
官方入口：
- SkillHub 頁面：https://www.skillhub.cn/skills/org-02qudk26/doc-coauthoring
- API 座標頁：https://api.skillhub.cn/org-02qudk26/doc-coauthoring
