模糊主題轉文章大綱技能是做什麼的？

將廣泛或半成形的想法轉變為獨特且可研究的文章大綱，而不為用戶撰寫完整文章。從用戶的既有工作和知識庫出發，識別相關社群中反覆出現的問題，選擇一個聚焦的讀者問題，並建立一個逐節的研究框架。

使用時機

當用戶：

提供模糊主題，並希望協助將其轉化為文章時使用；
請求研究問題、大綱或觀點時使用；
想要手動撰寫並稍後由代理改寫時使用；
要求將新主題與現有 wiki 頁面、專案或實作工作連結時使用。

請勿用於：

立即撰寫完成的文章；
沒有研究或來源工作的通用腦力激盪；
編輯既有草稿，且其論點和結構已明確。

核心心智模型

使用以下序列：

模糊主題
  ↓
既有工作與知識
  ↓
外部反覆出現的問題
  ↓
聚焦的讀者問題
  ↓
獨特論點
  ↓
具體機制或設計物件
  ↓
章節主張與研究問題
  ↓
反論點與證據缺口
  ↓
可重複使用的大綱（存於請求的工作空間）

目標不是預測未來或總結領域。目標是找到以下四個面向的最強交集點：

用戶實際建構、觀察或思考過的內容；
特定技術讀者需要理解或決定的內容；
當前行業從業者正在積極辯論的內容；
可由主要來源和具體範例支持的內容。

使用來自 [[outlining-an-article|文章大綱製作]] 的大綱序列：

主題 → 腦力激盪 → 分組 → 塑形 → 每節一句話 → 草稿

對於技術型 Substack 文章，在草稿前加入研究層：

主題 → 既有工作 → 反覆問題 → 聚焦視角
→ 腦力激盪 → 分組 → 故事架構 → 章節主張 → 研究 → 草稿

程序

1. 定義寫作約束

在研究之前，先確定：

目標讀者；
文章類型：技術論文、實戰指南、架構筆記、反對觀點或案例分析；
用戶想要的是大綱還是完成稿；
大綱應儲存的位置；
用戶的現有專案、實作或 wiki 上下文。

預設為：技術讀者、手動研究與草稿、僅限大綱、稍後再修改。

完成檢查：撰寫一句話描述讀者和文章任務。

2. 優先檢視用戶的既有工作

完整閱讀所引用的檔案，以識別：

明確的論點；
具體的過程或範例；
架構邊界；
失敗案例；
評估標準；
權衡取捨；
未解決的問題；
用戶已使用的語言。

如果用戶引用了一個 wiki 或資料夾，在發明新框架之前，先搜尋其中重疊的概念。閱讀最相關的概念、來源、主題、筆記和專案頁面。

偏好植基於用戶自身工作的想法。具體的實作、失敗的評估、設計決策或未解決的權衡，通常比一般的趨勢主張更有價值。

完成檢查：從用戶的材料中列出 3–8 個可重複使用的原則。

3. 研究從業者反覆提出的問題

使用網路搜尋工程社群中的當前討論和主要技術來源。適當地在幾個不同平台上搜尋：

協定儲存庫和 GitHub issue/討論；
官方實作範例；
工程部落格和文件；
Reddit 或其他從業者社群；
技術論壇或會議資料。

搜尋問題，而不只是主題名稱。範例：

[主題] GitHub issue 權威性
[主題] 實作問題
[主題] 工程討論失敗
[主題] 協定限制
[主題] 生產環境教訓

將反覆出現的問題記錄在以下類別下：

身分與權威性；
狀態與交易；
協作；
資料與上下文邊界；
安全性與濫用；
評估與可觀察性；
產品與營運模式。

除非有系統性的資料集支持，否則不要聲稱統計上的普遍性。當研究是定性時，使用「在所取樣的討論中反覆出現的問題」這樣的措辭。

完成檢查：產出 10–25 個按主題分組的反覆出現問題，並附上具代表性的來源。

4. 選擇最佳的文章問題

根據以下標準評分候選問題：

測試	問題
讀者價值	能否幫助特定讀者做出設計或產品決策？
用戶權威性	用戶在此方面是否有第一手工作經驗或已發展的觀點？
證據	主張是否可由主要來源和範例支持？
具體性	是否比整體主題更狹窄？
原創性	是否創造了一個觀點，而非僅是綜述？
持久性	在當前風潮過後是否仍有用？
系列潛力	是否能導向後續文章？

選擇一個主要問題，最多兩個備選。解釋為什麼獲勝者更強。

良好的問題形式：

[特定建構者] 在 [新條件] 下應如何設計 [特定系統]？

應避免：

[大型技術] 將如何改變 [整個產業]？

完成檢查：說明所選的讀者問題及其勝出原因。

5. 從用戶的工作中推導論點

使用以下模板：

普遍觀點是：
用戶的工作顯示：
該觀點不完全是因為：
更有用的模型是：
對建構者的實際影響是：
最強烈的反對意見是：

論點應是一個可辯論的主張，而非一個主題標籤。

有用轉化的範例：

「代理式電子商務」→ 「商家代理是一個有界限的結果解決系統，而非聊天機器人。」
「企業級代理」→ 「被治理的單元是行動系統，而非模型。」
「代理記憶」→ 「記憶是應用層的控制面，而不僅僅是模型功能。」

完成檢查：撰寫一句話的論點和一個 30 秒的解釋。

6. 命名或定義一個具體機制

為文章提供一個使論點有用的設計物件。範例：

過程合約；
權威邊界；
評估框架；
上下文預算；
能力表面；
決策追蹤；
結果分類帳；
干預迴圈。

不要為了聽起來原創而發明行話。搜尋該術語是否已存在，識別鄰近的術語，必要時將其標記為工作術語。

完成檢查：用 1–3 句話定義該機制，並展示一個小範例。

7. 將文章塑形為一個故事

不要建立一個主題目錄。給讀者一個從一個章節繼續到下一個章節的理由。

使用以下預設故事流程：

開場問題或情境 — 在解釋主題前展示具體情況。
張力 — 揭示為何明顯的解決方案失敗或不完整。
論點 — 清楚陳述主要主張。
機制 — 介紹解釋問題的模型、架構或設計物件。
應用 — 逐步說明機制如何改變實務。
護欄或權衡 — 展示可能出錯的地方以及界限應設在哪裡。
證據與評估 — 解釋建構者如何知道該方法有效。
影響 — 展示對讀者工作或產業的改變。
開放式結尾 — 以問題或未解決的張力作結，而非總結。

對於每個章節，在撰寫段落之前先寫一句話：

章節：
本章節的主張：
範例或證據：
讀者現在有的問題：
下一個章節如何回答它：

下一個章節通常應回答前一個章節所創造的問題。移除不推進故事發展的章節。

完成檢查：大綱應能從頭到尾作為一個問題與答案的鏈條來閱讀，而不只是一個主題列表。

8. 腦力激盪、分組與精簡

在最終確定大綱之前：

腦力激盪 所有相關的想法、範例、來源、反對意見和個人觀察。
搜尋既有資料 在 wiki、筆記、重點 highlight 和專案檔案中搜尋。
分組相關想法，並移除不支持所選視角的資料。
選擇一個形狀 從上述故事流程或其他合適結構中選取。
每個章節寫一句話 並檢查過渡。
將未解決的想法保留在「待辦清單」中，而不是強加入文章。

不要直接從主題跳到散文。大綱是原始思維與草稿之間的橋樑。

完成檢查：每個保留的想法都屬於一個章節，且每個章節只有一個主要主張。

9. 添加研究問題與證據缺口

對於每個保留的章節，提供：

用戶必須回答的研究問題；
需要尋找的證據；
可能的反論點；
什麼會改變論點；
具體的範例、圖表或案例。

不要撰寫僅僅有趣的問題。每個問題都必須有助於建立、挑戰或限定該章節的主張。

完成檢查：每個章節都有 2–5 個可回答的研究問題和至少一個證據目標。

10. 添加反論點與證據缺口

不要產生單方面的趨勢敘述。添加 4–8 個嚴肅的反對意見。對於每個反對意見，建立：

主張：
支持的證據：
反對的證據：
什麼會改變我的想法：
對論點的影響：

將主張標記為事實、預測、解釋或意見。確定哪些主張在發布前需要主要證據。

完成檢查：列出文章中最弱的未經支持的主張，以及測試它所需的來源。

11. 建立大綱產出物

如果用戶要求一個檔案，請將其建立在請求的位置。對於 Substack 草稿，使用：

substack/drafts/<描述性標題>.md

使用前註：

---
type: substack-draft
created: YYYY-MM-DD
updated: YYYY-MM-DD
status: outline
working_title: "..."
---

該檔案應包含工作論點、讀者、所選問題、研究紀律、章節大綱、問題、反論點和來源清單。除非明確要求，否則不要撰寫完成文章的文字。

除非用戶明確要求，否則不要為 Substack 草稿更新 wiki/index.md 或 wiki/log.md。不要修改 raw/。

完成檢查：檔案存在，包含完整的大綱，並清楚告知用戶下一步應研究什麼。

12. 報告結果

提供一個簡短報告，包含：

所選的框架；
為何選擇它；
與用戶既有工作的最強重疊點；
大綱儲存的位置；
用戶應研究和撰寫的下一步；
研究的任何限制，特別是如果「最常見」是從定性樣本推斷而來。

研究與來源紀律

對協定和實作主張使用主要技術文件。
使用社群討論來發現問題和失敗模式，而不是將其作為市場範圍行為的無疑問證據。
區分協定能力、實作行為、用戶信任和市場採用。
偏好具體範例、追蹤記錄、評估案例和失敗報告，而非一般性預測。
當使用網路搜尋時，在最終回應中引用源自網際網路的事實性主張。
不要將定性的搜尋結果呈現為統計上的代表性。

常見失敗模式

從行業主題開始，而不是從用戶最強的證據開始。
產出一個協定綜述，而沒有論證。
將代理視為分析單位，而實際單位是過程、工作流程或行動系統。
在定義讀者問題之前就開始撰寫文章。
將模型能力與生產保證混淆。
將 API 或協定視為安全協作的證據。
提出無法改變文章結論的研究問題。
使用「市場正朝著」等短語隱藏不確定性。
在未檢查鄰近文獻的情況下創造聽起來很厲害的術語。
在用戶要求研究和手動撰寫時，起草潤飾過的散文。

驗證檢查清單

在完成前：

模糊主題轉文章大綱技能