技術團隊與 AI 的合作方式正悄悄發生轉變。
一年前，大家討論的焦點還是 AI 能否寫出有用的 PRD、RFC 或錯誤報告的第一版草稿。
到了今天，這個問題已經有了定論：它確實可以。
而新的問題則困難得多：一旦 AI 產出的文件量大到連任何單一人員都無法獨自審閱時，團隊究竟該在哪裡達成共識？
程式碼審查（Code Review）能捕捉到程式碼的偏差；每日站會（Daily Standup）能掌握時程的偏移。但過去對於「文件偏差（Documentation Drift）」一直沒有明確的解決方案：也就是 AI 助手生成的內容、工程師實際的意圖，以及團隊其他成員的認知之間所產生的落差。
如果中間缺乏一個共享層，AI 生成的文件往往會散落在它們被創建的地方：某人的 Obsidian 保險箱、Claude 的對話紀錄，或是筆記型電腦休眠時就會關閉的 Codex 工作階段中。
我們一直在與各個團隊討論他們如何解決這個問題，其中有一場對話特別引人注目。Mikerah Quintyne-Collins 是 HashCloak 和 Stoffel Labs 的創辦人，這兩個團隊都致力於區塊鏈隱私保護基礎設施的前沿開發。她帶領我們了解了她團隊的工作流程。這是一個清晰且極具見解的範例，展示了 HackMD 在 2026 年對技術團隊而言所扮演的角色：它不只是個編輯器，更是 AI 生成工作與團隊共識之間的治理層 (Governance Layer)。
轉變：從「我在哪裡寫？」到「團隊在哪裡達成共識？」
大多數工程師都已經選定了個人的文件工具。Mikerah 使用 Obsidian 作為本機儲存庫，用來捕捉粗略的想法、在將 Prompt 發送給 Claude 或 Codex 之前進行整理，並存放不需分享的凌亂中間產物。她的團隊每天都與 AI 程式碼工具並肩工作，而她通常會從命令列介面 (CLI) 來驅動這些工作。
個人這部分已經解決了。而那些尚未解決並由 HackMD 最終填補的空白，是當某項工作需要離開個人的腦袋，轉化為團隊可以回應、質疑並據以發展的共享產物的那一刻。
以下是她用自己的話對該流程的描述：
「我現在編寫程式碼的工作流程如下：
先寫下我需要實現的功能需求的粗略 PRD。這是在 Obsidian 中完成的，然後我會將 Prompt 複製到 Claude/Codex。
讓 Claude/Codex 將這個粗略的 PRD 轉化為正式的 PRD。
持續迭代該 PRD，直到它完全符合我的需求。此時，這份文件會發布到 HackMD 作為一篇筆記。
根據 PRD 生成 RFC，這提供了成功落實該 PRD 所需的實作細節。
持續迭代這些 RFC，直到它們符合初步實作的要求。一旦定稿，這就會發布到 HackMD 上，成為一本『HackMD 書本 (Book)』，並在主章節中引用 PRD 筆記。」
這裡有一個微妙但重要的模式。AI 承擔了草擬和迭代的繁重工作，Obsidian 是本機的草稿紙。但在某件事變得 「明確」 的那一刻 (也就是需要被論證、審閱或作為開發依據的那一刻)，它就會移入 HackMD。
這個移動的步驟，就是治理。
為什麼特別選擇移入 HackMD？
當我們詢問 Mikerah 為什麼 HackMD 是最終目的地，而不是直接將 Markdown 推送到 Git、分享 Obsidian 保險箱的連結，或是貼到其他文件工具時，她的回答一再繞回幾個實際的原因。
具體且技術性的細節，同時不需要強迫每個人使用 Git
她的團隊需要理解一項功能的 背後原理，而不僅僅是實作方式。HackMD 讓她不需要發起 Pull Request，就能以工程師易於閱讀、進行評論並做出回應的形式來分享這些原理。正如她所說：「這讓我向團隊分享特定組件的功能與原理變得更容易，不只能提供具體且技術性的細節，幫助他們相應地定位自己的軟體決策，而且他們也能輕鬆地對我的想法提出反對意見。」
長期且持久的知識
PRD 和 RFC 並非免洗文件，它們是團隊當初為何做出這些選擇的紀錄。Mikerah 將這一層描述為「有點像 ADR」——這參考了 Michael Nygard 在 2011 年推廣的架構決策紀錄 (Architecture Decision Record) 模式。透過這種方式，HackMD 的筆記與書本模式成了一種機構記憶，在產出初稿的 AI 工作階段關閉後依然長存。
隨工作規模擴展的結構
單一的 PRD 是一篇 HackMD 筆記。但當你生成從中延伸出來的 RFC 時，你就擁有了一個小型資料庫。HackMD 的書本模式 (Book mode) 讓她能將這些 RFC 組織成章節，並引用最初的 PRD 筆記。團隊能獲得一個權威的入口起點與連貫的設計導覽，而不是面對一整夾互相斷聯的檔案。
超越草擬：利用 HackMD 檢視過去
這場對話最有趣的部分並非關於生成新文件，而是關於如何利用 HackMD 來理解 已經發生 的工作。
Mikerah 分享了她團隊經常使用的兩種模式：
從現有程式碼和對話中逆向工程出設計原理
她會將 AI 模型對準某個程式碼組件，要求它闡明其中蘊含的設計決策。然後將其帶入 HackMD 供團隊審閱。對於來自站會或 Slack 對話、且從未轉化為書面產物的決策原理，她也採取同樣的做法。
It forces [us] to either double down or reconsider past decisions and integrate it into our release schedule.
「這迫使『我們』要嘛加倍堅持、要麼重新審視過去的決策，並將其整合到我們的發布時程中」
找出漏洞
透過這種方式，HackMD 成了浮現「應該存在但實際上不存在的內容」的場所。那些遺失的原理、未經審閱的假設，或是心照不宣卻從未被寫下來的規格。
這正是「治理」這個框架真正落地之處。AI 助手非常擅長製作初稿，包括對已經發生的工作進行草擬。但只有當草稿存在於團隊看得見、能爭辯並能承諾執行的地方，它才會轉變成治理。而那個地方必須比聊天視窗更持久，並且比 Git 儲存庫更容易存取。
實際改變
我們直接了當地詢問 Mikerah，這個工作流程究竟為她的團隊改善了什麼。
她的回答很精簡：
“Less context getting lost and better alignment.”
「減少討論脈絡遺失的情況，並帶來更多的共識」
這句話值得深思。它不是「我們的出貨速度提升了 30%」，這種數據往往是事後編造出來的。
這是一個更誠實的版本：團隊成員清楚知道彼此正在進行什麼工作、為什麼 這麼做，以及做出了什麼決定。AI 負責生成數量，而 HackMD 讓這些數量變得清晰易懂。
為什麼這對目前任何使用 AI 開發的團隊都很重要
Stoffel Labs 是一個特定類型的團隊，「規模小、技術導向，且建構的基礎設施其設計決策具有實際的密碼學與安全性後果」。但 Mikerah 所描述的模式正變得越來越普遍：
- 本機 AI 工作進展飛快： 工程師使用 Obsidian、Cursor、Claude、Codex 或其組合。草稿的成本很低。
- 團隊達成共識卻很慢： 從「我有一個草稿」到「團隊對方向達成共識」之間的鴻溝，正是大多數專案停滯不前的地方。
- 一個共享、持久且易於評論的層級，正是縮短這段差距的關鍵： 不是聊天串，不是 Git 儲儲庫，而是介於兩者之間的存在。
對於 Stoffel Labs 而言，HackMD 就是那個中間層。筆記捕捉了 PRD 的權威版本；書本模式組織了依賴於該 PRD 的 RFC；評論與行內編輯讓團隊得以提出質疑。而且整個成果會持續留存，就算在產出初稿的 AI 工作階段關閉後很久很久依然如此。
如果你每天都在與 AI 工具協作，並發現瓶頸已經從「撰寫」轉移到了「達成共識」，那麼 Mikerah 所描述的工作流程非常值得借鏡。
為你的團隊嘗試看看
感受這種體驗最快的方式，就是挑選一份你們團隊目前正熱烈討論的文件：無論是規格書、錯誤報告還是架構提案，並將其移入 HackMD。
邀請團隊加入、讓他們進行評論，看看會浮現出什麼。
如果你想更深入地融入 AI 輔助的流程，HackMD CLI 和開發者入口網站 (Developer Portal) 讓你能非常直接地從團隊現有的工作環境中（包括自動化代理與 CLI 驅動的工作流程）將 Markdown 推送到 HackMD。
