您的第二大腦不應該需要您親自去撰寫它

每個 wiki 和知識庫都需要人類來撰寫與維護。但如果它能自己撰寫呢？能根據您的實際工作進行更新的自撰寫文件，是我們構建過最徹底、最創新的產品。

知識管理的歷史，就是一段手動撰寫專案宣告失敗的歷史。某人花了一週時間填寫、但第一個月後就無人維護的 wiki。產生了五十頁、但其中四十七頁在一個季度內就過時的文檔衝刺。團隊「太忙而無法更新」的知識庫——這只是維護成本超過其感知價值的另一種說法。

這些系統無一例外都因為同一個原因而失敗：它們要求人類將撰寫和維護文件視為一項獨立於文件所描述工作之外的任務。工作發生在 Slack、會議、程式碼審查和 電子郵件中。關於工作的文檔必須由停下工作來描述它的人單獨撰寫。文檔總是落後於現實，因為它是由有其他優先事項的人類撰寫的。

問題不在於「我們如何讓大家寫出更好的文件？」而在於「如果文件能從已經發生的工作中自己撰寫呢？」

自撰寫文件的真正含義

自撰寫文件能根據您連接工具中的活動，生成結構化、有引用來源且可編輯的文件。文件不是摘要或逐字稿，它是從原始活動中提取出來的結構化知識，並隨著活動的演變而持續維護。

來自 Slack：您的團隊爭論是否使用微服務或單體架構的對話串，會變成一份包含問題、考慮過的選項、推理和結論的決策記錄。您不需要撰寫決策記錄，它會根據討論內容自己撰寫。

來自 會議：衝刺計劃會議會變成一份包含決策、行動項目和背景資訊的專案狀態文件。與客戶的通話會變成包含反饋、需求和承諾的客戶帳戶記錄。您不需要撰寫會議記錄，系統會自動轉錄、提取並結構化。

來自 GitHub：PR、程式碼審查評論和問題討論會變成描述系統如何運作以及為什麼這樣構建的工程文件。文件會隨著程式碼的更改而更新，因為它是從程式碼活動中衍生出來的。

來自 銷售活動：與客戶的通話、CRM 記錄和交易討論會變成競爭情報檔案、客戶歷史記錄和流程文件，並隨着團隊活動的持續進行而保持最新狀態。

每項主張皆有出處：

文件中的每項主張都會引用其來源：特定的 Slack 訊息、會議時間戳記、PR 描述。文件並非 AI 產生的虛構內容。它是從真實活動中進行的結構化提取，可透過引用進行驗證。已經學會不信任過時 wiki的工程師可以透過點擊鏈接至來源來驗證任何主張。

為什麼這改變了第二大腦的方程式

傳統的第二大腦要求您做兩份工作：工作，以及工作的文檔記錄。大多數人只做第一份工作而跳過第二份，因為第一份是評估他們的標準，而第二份是額外的負擔。

自撰寫的第二大腦消除了第二份工作。您只需做您的工作（在 Slack 中討論、參加會議、審查程式碼、給客戶發電子郵件）。文件會作為副產品自動生成。第二大腦會從您的活動中自動填滿，而不是要求您去填滿它。

這將知識管理的經濟學從「花時間創建文件」改變為「文件是您已經在做的工作的免費副產品」。時間投入降至零。知識擷取變得全面。維護工作降至定期審查，而非持續撰寫。

對於個人而言，這意味著一個不會在一個月內失效的第二大腦，因為它不再依賴您的自律來填滿它。對於團隊而言，這意味著一個能保持最新的企業大腦，因為文件會即時追蹤團隊的活動。對於組織而言，這意味著一個能作為日常營運副產品累積機構知識的背景知識庫。

您還需要寫些什麼

自撰寫文件可處理營運知識：決策、流程、系統文件、會議產出、專案狀態。它們無法取代的是：

戰略思考。 您對市場為何朝特定方向發展的分析。您對公司下一步該做些什麼的假設。原創思考需要人類作者。

創意工作。 部落格文章、簡報提案敘事、設計原理。創意產出是撰寫出來的，而不是提取出來的。

個人反思。 您關於學到了什麼、在想什麼、想如何處理某事的筆記。您可以與處理營運背景資訊的自撰寫文件並排，在筆記和文件編輯器中進行此類撰寫。

自撰寫系統處理了沒人想寫但大家都希望存在的文檔。您只需撰寫只有您能寫的東西，系統會撰寫其他所有內容。

常見問題

這與 AI 會議記錄工具有何不同？ AI 會議記錄工具（如 Otter、Fireflies）主要轉錄和總結會議。自撰寫文件則能將會議與 Slack 討論、GitHub 活動以及電子郵件一起擷取，並跨所有來源合成結構化文件。會議記錄只是其中一項輸入，自撰寫 wiki 才是全面的輸出結果。

我可以編輯自撰寫的文件嗎？ 可以。文件是完全可編輯的。AI 產生初始版本並進行維護，您可以根據需要進行精簡、糾正或擴展。AI 產生與人類審查的結合，能產生既全面又準確的文件。

我如何知道 AI 擷取的內容是否準確？ 每項主張都有引用其來源。點擊引用連結即可查看原始的 Slack 訊息、會議時間戳記或 PR 描述。如果 AI 誤解了某些內容，來源就在那裡，便於驗證和修正。

這適用於非技術團隊嗎？ 適用。自撰寫文件可從任何連接的來源生成：銷售頻道、產品討論、客戶會議和一般的 Slack 活動。來自 GitHub 的工程文件只是其中一種應用。該系統適用於任何工作涉及討論和溝通的團隊。

如果我們在 Slack 中討論不應記錄的敏感話題怎麼辦？ 您可以控制哪些頻道和來源饋入自撰寫系統。排除敏感頻道即可。文件僅會從您已連接並授權的來源生成。

這與 Notion 或 Confluence 相比如何？ Notion 和 Confluence 需要手動撰寫和維護。自撰寫文件則會自動生成和維護文件。手動 wiki 的失敗模式（內容過時、放棄維護）在此並不適用，因為維護工作已由系統處理。

文件累積的速度有多快？ 在連接來源的第一週內，系統就會根據當前的活動生成文件。在一個月內，累積的文件就足以回答有關近期決策和流程的大多數問題。隨著活動的持續，文件將繼續增長和完善。

「有引用來源的」文件實際上看起來是什麼樣子的？ 文件中的每條聲明都包含一個小小的引用連結。點擊它即可帶您前往來源：該聲明所源自的確切 Slack 訊息、特定會議時間戳記或特別的 PR 描述。這些引用提供了手動撰寫的文件通常缺乏的可驗證性。

文件可以對外分享嗎？ 可以。文件可以發佈為可共享的頁面，並在需要時提供密碼保護。面向客戶的文件、入職指南和流程文件都可以與外部利益相關者共享。

相關閱讀：自撰寫文件解析、為什麼大多數第二大腦會失敗、沒人看 wiki、您的第二大腦應該思考。相關頁面：自撰寫文件、Fabric 對比 Notion、Fabric 對比 Confluence。