程式碼即真相來源

資料來源#

• How the Open Knowledge Format can improve data sharing
• Running an AI-native engineering org
• The State of Agent Wikis

摘要#

Fiona Fung 為 AI 原生組織重寫知識共享方式：**當編碼產能很高，文件過時的速度就會快過任何人維護它的速度——因此程式碼庫成為真相來源，而任何希望持續有效的內容，都要簽入程式碼庫。**規格成為提交至儲存庫的技能；新人上手時，透過請 Claude 教你熟悉系統範圍，而不是拉工程師來做技術深度講解。「我們的程式碼就是真相來源。」

為什麼文件在 AI 原生組織中會腐朽#

這個機制直接源自驗證成為新的瓶頸：編碼產能提高代表程式碼變動更快，因此任何不在更新迴圈內的文件幾乎立刻就會過時。Fung 的建議是：「無論你的真相來源是什麼——即使是規格——都把它改成簽入程式碼庫的技能，這樣你才能持續更新。」儲存庫是唯一能保持最新的產物，因為它本身就是正在被修改的對象。

儲存庫中的規格讓規格漂移得以驗證#

把規格簽入程式碼庫，不只是維持新鮮度的整潔做法——這也讓機械化驗證成為可能：「Claude 很擅長檢查規格漂移。」已提交的規格既是人類可讀的意圖，也是機器可檢查的參照，審查代理程式會拿它來比對差異。（這和 Symphony 的 WORKFLOW.md 及 Claude Code 的 CLAUDE.md 是同一種做法——以儲存庫版本管理的純文字作為控制平面；見 Symphony、Claude Code Best Practices。）

將文件視為建置產物：重新產生，而非持續維護（Factory AutoWiki）#

Fung 透過把真相簽入儲存庫來確保文件正確；Factory 的 AutoWiki（透過 mem0 於 2026 年 7 月進行的代理程式 wiki 調查，practitioner-opinion）則從另一端解決同樣的過時問題——讓文件成為儲存庫的衍生函式：每次推送至預設分支時，由 CI 重新產生的建置產物（/install-wiki 會寫入工作流程），而非任何人必須維護的獨立專案。調查如此描述：Factory「靠基礎設施維持 wiki 正確，而不是靠紀律」，並稱四套代理程式 wiki 系統之間「透過 CI 或手動指令產生的差異」是「成熟度指標」——所有非 CI wiki「都只能和上次有人執行指令時一樣新」。

這兩項建議可以組合使用，並不互相競爭：能從程式碼推導的內容就重新產生（AutoWiki）；無法推導的內容——意圖、規格、慣例——則提交入庫，讓變更迴圈維持其時效（Fung）。無論採哪種方式，承載關鍵資訊的內容都不會留在更新迴圈之外的產物中。LLM-as-Compiler Knowledge Base 提供完整概覽。

同一規則寫入格式規格（2026 年 6 月）#

Fung 把簽入儲存庫說成工作流程建議。Google Cloud 的 Open Knowledge Format（2026-06-12，vendor-claim）則將它列為格式要求：它所列知識表徵必備的五項特性之一，是「與其描述的程式碼一同存在於版本控制中」——因此這種格式是「純檔案」，而不是帶有 API 的服務。理由正是本文所述，只是從互通性角度推導而來：若知識儲存庫只能透過供應商的目錄 API 存取，依其設計就位於變更迴圈之外，不論內容有多新都一樣。這項規格沒有納入 Fung 論點的後半段——已提交的規格可以用機器檢查是否漂移，而 OKF 沒有標準化任何可供檢查器依據的欄位。想了解此格式還有哪些部分交由內容提供者決定，請見 LLM-as-Compiler Knowledge Base。

本文未明說的遷移規則：每項產物只指定一個真相來源（2026 年 8 月）#

以上兩種說法都假設從零開始選擇。Anthropic 的 Applied AI AI-Native SDLC playbook（vendor-claim，2026-08-21）是語料中第一個處理實際阻礙採用情況的來源——紀錄已經存在於稽核人員接受的地方。其側欄直接指出 Jira、ServiceNow、受監管的需求工具或 Figma 為何不能直接刪除：「稽核人員與監管機關已經接受它們，而且其他團隊也仰賴它們，因此很難取代。」

這條規則以單項產物為單位，而非以組織為單位：**為每項產物明確指定一個系統作為真相來源，其他地方只保留副本或連結。**以下三種配置，依整潔程度由高至低排列：

• 儲存庫為權威來源——Markdown 就是紀錄，舊系統則參照提交中的檔案。這被稱為最適合工程主導組織的方式，原因也正是本文所述：單一工具，單一時間戳權威來源。
• 舊系統為權威來源——需求工具保存紀錄；Claude 在工作階段開始時讀取，並透過 MCP 連接器在產生規格或計畫的同一個工作階段內寫回結果，而 Markdown 則降為工作副本。這保留了本文論點中代理程式可讀的部分，但讓步於版本控制的部分。
• 僅建立連結——每項產物註明紀錄 ID，每筆舊系統紀錄附上提交 SHA。建議以此作為起點，同時也清楚指出其代價：存在兩個真相來源。

這套分類針對的失敗情況，是未被選定的中間狀態——兩套系統都存在，卻沒有一套被指定為權威來源，於是彼此漂移。這條規則所管轄的產物鏈，請見已提交產物鏈。

透過 Claude 上手，而不是透過同事#

Fung 自己透過 Claude Code 上手：她沒有（只）和工程師做技術深度講解，而是第一次深入了解時和 Claude 一起進行——「在我開始處理這個錯誤修正之前，你可以先教我這個錯誤涉及的範圍，以及周邊相關部分嗎？」她回報的效果是：新人上手時間縮短，其他團隊成員付出的成本也降低——新加入的同事不再占用資深工程師的時間來補足背景資訊。對身為主管的她而言，這也讓她能毫無愧疚地重新熟悉程式碼庫（「我不覺得自己在浪費任何人的時間」）。程式碼庫加上 Claude，就是新人上手文件。（見身為 IC 的主管。）

與 CLAUDE.md 和代理式債務的關係#

程式碼即真相來源，是正向的實踐方案；代理式技術債則是它要防範的失敗模式。持續存在並已提交的脈絡（CLAUDE.md、簽入的技能／規格）能避免每次代理式工作階段都重新推導架構決策。wiki 自己的 LLM-as-Compiler Knowledge Base 則是更高階的例子：它是已編譯且持續更新的產物，而非重新推導的知識。

延伸閱讀#

• Building Is Cheap, Arguing Is Expensive — 若程式碼勝過辯論，儲存庫（而非文件）就是真相來源
• Fiona Fung —「我們的程式碼就是真相來源」
• Verification as the New Bottleneck — 成因：高產能使文件過時；將規格放進儲存庫便能檢查規格漂移
• Agentic Technical Debt — 脈絡未保存在儲存庫時會累積的債務；本文做法就是解方
• Claude Code Best Practices — CLAUDE.md 是以儲存庫版本管理脈絡的典型做法
• Symphony — WORKFLOW.md / SPEC.md 是編排層中由儲存庫版本管理的控制平面
• Managers as ICs — 把 Claude 當作新人上手文件，讓主管重新投入程式碼庫的成本降低
• LLM-as-Compiler Knowledge Base — 編譯並持續更新與重新推導之間的差異；更高一層的知識管理原則
• Claude's Constitution / Model Spec — 對齊層中作為關鍵文件的規格
• Prototype Over PRD — 從另一端處理同一個理由記錄缺口：本文因程式碼是真相而刪除文件，Carey 因原型就是規格而刪除文件；兩者都讓「為什麼」無處安放
• The Committed-Artifact Chain — 本文向上游延伸兩個階段：Anthropic 的手冊將 intent.md 和 spec.md 加入提交清單，讓產品負責人擁有的產物也加入工程師既有的提交內容，並補上上述舊系統遷移規則。這也是第一個替「為什麼」指定明確位置的來源——intent.md 記錄「想要什麼、為什麼，以及有哪些限制」——以處方而非證據回答了本文第一個開放問題
• Dynamic Workflows: An Algebra for Agents — 將同樣做法應用於失敗，而非規格：把編譯器錯誤、堆疊追蹤和失敗測試序列化至檔案，再讓代理程式以該檔案作為工作佇列，分頭處理
• The Code-Quality Payoff Is Token-Indexed — 將相同資訊放在另一處的做法：把規格保存在儲存庫，或編碼於架構中；兩者都是為了避免代理程式重新推導脈絡，而 DHH 以 token 計算這項成本
• Spec-Driven Development as the New Waterfall — 直接拒絕本文將規格放入儲存庫的規則：Martin 不在儲存庫中保留規格，因為完成的產物本身就是規格；他將持久的意圖陳述放進檢查器（CRAP 分數、變異測試、依賴規則），而非文件。雙方都尚未量化；本文提出的規格漂移檢查，正是可以裁定兩方觀點的工具

開放問題#

• 有哪些知識確實無法存在於程式碼庫中（組織策略、「為什麼」、跨團隊脈絡），因此仍需要持久文件——又要如何讓這小部分維持最新？部分解答：「為什麼」應該放在哪裡？——「為什麼」是最明確的此類內容，而每個候選位置都會失敗或只能部分奏效；在不斷過時的程式碼之外保留一份已編譯的知識庫，是最不差的選項。「如何保持最新」這部分仍未處理。
• 如果上手方式是「問 Claude」，過去在深入講解中透過社交互動傳遞的隱性知識會怎麼樣——它有被記錄下來嗎？還是悄悄流失？

衍生文章#

• Where Does the Why Live? — 延續本文第一個開放問題；本文排除於程式碼庫之外的「為什麼」沒有理想位置，只有更完整產物與已編譯知識庫這兩種不完整的補救方式
• When Knowledge Layers Disagree: Context Files vs Memory, and Conflicting Sources at Compile Time — 以本文作為事實層的裁定依據：脈絡檔案與記憶對現況的描述不一致時，以儲存庫／即時狀態為準，並修復兩份快取
• Is Persistence the Line Between Prompting and Spec-Driven Development? — 將本文兩條規則解讀為權威性界線的強式版本：提交規格的價值在於漂移檢查，而不是儲存；「每項產物只指定一個真相來源」規範的是哪一份持久副本具有約束力，若只從持久性角度理解便難以說通

資料來源#

• Running an AI-native engineering org
• How the Open Knowledge Format can improve data sharing — Sam McVeety 與 Amir Hormati，Google Cloud，2026-06-12（vendor-claim）：「缺少的是一種格式，而不是另一項服務」——五項格式要求之一，是與所描述的程式碼一同存在於版本控制中。沒有量化；Google 以外沒有內容提供者或使用者。完整來源說明見 LLM-as-Compiler Knowledge Base