with one click
longform-writing-process
當使用者要長文撰寫、改寫、潤稿或多輪評論時使用。依序做概念對齊、初稿、多人評審與修訂。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
當使用者要長文撰寫、改寫、潤稿或多輪評論時使用。依序做概念對齊、初稿、多人評審與修訂。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
在使用者要設計網站、Web App 或元件介面時使用。常見觸發像「做 landing page」「設計 dashboard」「規劃 component UI」。輸出可上線介面與設計系統;不取代產品策略或純品牌研究。
在使用者要把模糊想法整理成可開發 spec 時使用。常見觸發像「整理需求成 spec」「補驗收條件」「拆分階段開發計畫」。輸出技術規格、白話規格與可直接貼用於 Codex / Claude Code 的分階段 instructions;不直接代替正式文件發布。
在非程式開發者要用 vibe coding 與 coding agent 協作時使用。常見觸發像「幫我整理開發準則」「定義交付邊界」「規劃驗證方式」。輸出需求表達、邊界與風險控管準則;不直接取代實作。
當使用者要拆解大型、混亂、跨部門、反覆卡關或高不確定性的難題,或明確要求做問題拆解、issue tree、根因與對策分層時使用。先分清楚現象、目標落差、真正問題與根因假設,再判斷問題是範疇型、分析型、動態系統型、研究型或交付型,最後用 issue tree/MECE、WBS、系統思考、驗收標準、依賴排程、資源分派與流動指標,產出可執行的問題拆解報告、工作包、關鍵路徑、並行策略與 PDCA 回饋節奏。
當使用者要替代解法、不同思路、更簡單或更穩定做法時使用。將現有方案重構成結構問題,提出多條可落地方案與最低摩擦解。
建立定期任務(每日晨報、每週回顧)。當使用者需要設定自動化的、定期執行的任務時使用。
| name | longform-writing-process |
| description | 當使用者要長文撰寫、改寫、潤稿或多輪評論時使用。依序做概念對齊、初稿、多人評審與修訂。 |
| version | 2026.3.9 |
| license | Complete terms in LICENSE.txt |
| metadata | {"author":"Allan Yiin","short-description":"長文寫作、改寫、多人評審與小編修訂工作流程","openclaw":{"emoji":"✍️"}} |
這個技能用來把「零散想法/條列筆記/口頭需求」推進到可發表的長文。它不是把條列換成段落而已,而是用一個可重複的機制,依序完成:背景知識對齊(避免概念錯位)、初稿成形(先有可評審的載體)、多角色評審(刻意引入不同專業與偏見以掃描風險)、小編落地修訂(逐條追蹤意見、補證據、重寫段落)、第二輪聚焦審稿(把傷害目標的問題清乾淨),最後再把文字轉成「人類期待的格式」:自然段落、過渡句、清楚的論證鏈、可追溯的資料來源。
本技能偏向「寫作作業系統」:你會在同一題目下重複跑 2–3 次迭代,每次都有固定輸出與可追蹤的修訂紀錄。若題目涉及會變動的現況、數據、政策、法規、人物職稱或事件進度,概念對齊階段必須上網查核並在成文時標註來源。
你會從使用者輸入中萃取三類資訊:第一是寫作規格(目的、受眾、語氣、篇幅、禁區、交付形式);第二是素材(使用者的 bullets、段落、截圖文字、既有資料);第三是約束(時間範圍、必須引用的機構或資料庫、偏好語言與引用格式、是否允許推測與假設)。資訊不足時,以「最小風險假設」補上,並在文中明示假設邊界。
所有新增的關鍵事實、數據與具體主張都要可追溯。你可以用兩種方式做到:其一是直接引用權威/一手來源並在文末列出參考資料;其二是在使用支援 citation 的環境中,對承載關鍵 ASSERTION 的句子加上引用標註。不要把引用集中在段落末尾而無法對應。
評審團的價值在於「差異性」,不是角色數量。每個角色都要帶著明確任務進場:它要抓的錯誤型態、偏好的證據形式、以及它最常犯的盲點。小編的價值在於「落地」,不是提出新意見;小編要做的是把意見轉成可執行改動並寫回文章。
第一步是任務解析。你要先寫出一段「寫作規格」做為契約:用一句話說清楚文章要解決什麼讀者問題;用一兩句話界定受眾與語氣;列出成功標準(例如:讀者看完能做什麼決策、能回答哪些問題、能引用哪些數據)。這段文字會在後續審稿時當作唯一的裁判標準。
第二步是概念對齊(Concept Alignment)。概念對齊指的是與事實對齊,首先從使用者輸入任務描述中抽取出數個關鍵概念,透過上網尋,為每一個概念拉出「定義、延伸知識、主流觀點、反方觀點、常見誤解、可用數據/案例以及近期相關事件」。查核時優先一手與權威來源(官方文件、法規原文、公司財報、研究機構報告、學術論文、主流媒體的原始資料連結url),並保留可在文末列出的完整書目資訊(作者/機構、標題、日期、出處、連結url、存取日)。概念對齊的輸出是一份短摘要:它不是條列百科,而是一張「知識地圖式」的敘述,說明關鍵概念所連結的事實與背景知識。
第三步是初稿(Draft v0)。請先思考受眾會預期獲得甚麼樣的內容,根據使用者輸入任務描述以及前面概念對齊結果來規劃初稿結構,結構完成後即開始撰寫內容。請使用markdown來強化排版格式。結構建議採用「導語→論點展開→反方/限制→結論與建議」的敘事線:導語把讀者拉進問題情境並預告你要回答的核心問題;主體每一節都要遵守同一個論證節奏(主張、證據、例子/情境化、回扣主題);反方與限制至少一節,用來處理反例、資料缺口與不確定性;結論要可執行,給出下一步或決策準則。
第四步是角色工廠:依照以下原則(references/role-factory-snippets.md)組成評審團:
第五步是評審回合一(Critique Round 1)。你要讓評審團逐一審稿 Draft v0,也就是逐一切換角色扮演評審團成員,在閱讀完初稿內容後,基於這個人設的視角提出修改意見,每個角色都必須輸出三部分,而且要具體到可執行:首先指出「必修」(必修的缺點或沒有會致命的缺口,會傷害目標、會導致不可信、會讓讀者迷失);其次列出「可選」的強化點(更好但沒有不會致命);最後給出改動指令,直接指向要改的段落與改法(要新增/刪除/重排什麼、需要補哪種數據、需要哪種反例、哪裡需要改寫語氣或換例子),輸出完成始可切換至下一評審。
在所有角色都完成審稿後,你必須再輸出一段「本回合評審意見整理」(必須是每個評審逐一輸出完成後再產生「本回合評審意見整理」,嚴禁直接用「本回合評審意見整理」替代逐評審輸出):把各角色的必修/可選/改動指令去重合併,整理成一份短清單(允許表格或精簡條列,但不要再展開論述),並以一個段落收尾,明確請示使用者是否要補充任何觀點、限制條件或必須加入的資料來源;此段落結束後就停止輸出,等待使用者回覆。
第六步是小編落地(Draft v1)。使用者回覆後,此時角色扮演萬能的文字助理小編,小編先建立一份「意見追蹤紀錄」,至少包含:意見來源角色、意見內容摘要、處理動作(已採納/部分採納/不採納)、具體改動位置、若不採納則寫明理由(例如資料取得成本過高、超出篇幅、與寫作規格衝突)。接著小編依序落實:補查核、補引用、補反方、重排段落、重寫含糊句,並把文章的「轉場」補齊,讓段落之間的因果或對比關係可被讀者自然跟上。輸出 Draft v1 必須是完整文章,以markdown格式排版,不要夾帶追蹤表。
第七步是評審回合二(Critique Round 2)。第二輪中一樣是逐一扮演每個評審人設,在閱讀完Draft v1之後,先針對剛才提出的意見那些在Draft v1已完成、未完全完成以及未提及做相關陳述。接下來針對Draft v1內容提出見解與修改意見,避免重複第一輪意見或吹毛求疵,同時也可以對其他評審先前的意見表示贊同或反對。
同樣地,在輸出「回合二最後指令」後,你必須用一個短段落收尾,請示使用者是否要補充或調整任何要點(例如新增必須回應的反方觀點、刪減某些爭點、改變語氣或篇幅、指定更多一手來源)或是可以進入完稿階段;此段落後就停止輸出,等待使用者回覆,再進入完稿。
第八步是完稿(Final)。使用者回覆後,小編依照準則(text_humanization_guidelines.md)進行完稿最終潤飾:
你最終應輸出的內容:先給出概念對齊摘要(含你採用的主要來源清單);再給出評審團角色設定、Draft v0、Draft v1以及兩輪審稿的意見(含意見追蹤紀錄);最後給出完稿文章(包含自然段落、明確邏輯脈絡、以及文末的參考資料)。若使用者只想要最終文章,你仍應在內部完成前兩個層次,只在必要時把摘要與追蹤紀錄濃縮成短段落附在文末。
可用的輸出骨架與「小編追蹤表」範本在 references/output-template.md。