代理式技術債務

資料來源#

• Claude Opus 5 System Card
• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501
• Do Context Files Help Coding Agents? A Two-Agent Ablation Study on Real Repositories
• From Agent Behaviour to Agent-Friendly Documentation
• From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained
• OpenAI Codex lead on the new shape of product work
• The Founder's Playbook: Building an AI-Native Startup
• Uncle Bob on Software Fundamentals in the Age of AI
• Who Maintains Agent Skills? A Longitudinal Study of Human-Governed, AI-Assisted Skill Maintenance

摘要#

The Founder's Playbook: Building an AI-Native Startup 提出了一種 AI 建構程式碼庫的特定失敗模式：技術債務不是線性累積，而是會複利增長，因為缺乏持續保存的規格或情境檔案時，每次代理式編碼工作階段都會從頭重新推導基礎架構決策。結果是，程式碼庫各個部分都能運作，卻「背後沒有連貫的心智模型；不是因為任何單一部分很糟，而是因為這些部分從未被設計成彼此契合。」問題往往到後期才浮現——程式碼庫原本運作正常，直到反覆迭代或規模成長迫使團隊全面重寫。

這與一般技術債務有何不同#

一般債務逐漸累積，可以在專門安排的衝刺中清償。工程師知道自己在哪裡走了捷徑，也知道走了哪些捷徑；工作範圍有限。

代理式技術債務有三項結構上全新的特性：

1. 漂移，而不只是走捷徑。 每個工作階段依「第一原理」推理，最後都會落在略有不同的位置。程式碼庫裡不只是充滿妥協，還存在妥協彼此之間的不一致。
2. 在問題浮現之前都看不見。 一項可運作的功能，不會揭示它建立時依據的架構前提。只有讀完整個程式碼庫才能觀察到漂移，而創辦人通常正忙著交付產品，並沒有這麼做。
3. 沒有自然的回饋迴路。 傳統工程團隊有共同的設計討論、程式碼審查、ADR——這些都會形成「為什麼要這樣做」的人類記憶。單打獨鬥的創辦人加上代理程式，兩者都沒有，所以每次工作階段都真的從零開始理解意圖。

形成機制#

「如果沒有把規格和架構限制寫在某個 AI 能讀到的地方，每次工作階段都會從頭重新推導基礎決策，而這些決策會逐漸漂移。」

每次代理式工作階段開始時，代理程式都會根據目前的程式碼狀態推斷自己的結構假設。兩個工作階段讀取相同程式碼，可能推斷出兩種不同意圖（這個模式是刻意設計的嗎？那個抽象是限制條件，還是巧合？）。接著代理程式依據自己推斷的意圖建構下一項功能。數月反覆下來，程式碼庫裡便交錯著多套「隱含架構」。

解方：持續保存情境#

Playbook 建議將架構意圖寫入 CLAUDE.md Markdown 檔案，讓 Claude Code 在每次工作階段開始時自動讀取。這些檔案是專案層級的指示，實際上就是專案持續保存的「記憶」。具體做法如下：

1. **開啟 Claude Code 之前，**先開啟 Claude（聊天），定義你要建構的內容：核心問題、使用者、六個月後的規模、架構原則、要避免的相依性，以及有意接受的取捨。儲存為 CLAUDE.md。
2. 開始每次 Claude Code 工作階段時，（1）重新檢視範疇文件，（2）提供模型 CLAUDE.md 情境文件。
3. **結束每次工作階段時，**把工作階段中浮現的決策更新到 CLAUDE.md。

Playbook 的說法是：「每次工作階段花五分鐘寫文件，是防止架構漂移複利成為難以管理的程式碼庫的一筆低成本保險。」（2026-08-05 補充限定——請見下文〈這項解方經測量證明能帶來什麼〉：保險確實能降低成本並改善流程紀律，但尚無證據顯示它提高了每項任務的正確性。）

這項解方經測量證明能帶來什麼（Khatri，2026 年 7 月）#

上述建議在這組資料中從未經過測試；Khatri 2026（arXiv 2607.27250，empirical）是首次對此進行受控消融實驗，結果指出一個明確方向。在兩個前沿代理程式和三個真實程式碼庫上進行 288 次由黃金測試評估的執行，完全移除情境檔案並不會降低任務正確性（Claude 沒有情境時為 53.3%，有情境時為 55.6%；Codex 分別為 58.8% 和 56.9%；差異落在 <10–15pp 範圍），而在 36 格探測中，真實的 AGENTS.md 從未把一項差點通過的失敗翻轉為成功。關鍵在形成機制：那些差點成功的案例，失敗原因是實作技巧——在設計正確的最佳化中出現精度錯誤、需要主動更新卻採用了反應式重試模式、代理程式從程式碼讀出一條規則後卻錯誤接線——而非檔案能傳遞的架構意圖。完整分析見 Agent Context Files。

這項結果對本文有三項影響：

• 它沒有觸及漂移主張。 Khatri 衡量的是單一工作階段對隱藏測試預言機的任務正確性。本文討論的是跨工作階段機制——妥協彼此不一致，數月來逐漸累積，最後迫使團隊重寫。單項任務通過率無法觀察這件事；能觀察到的實驗設計（在同一程式碼庫上重複執行工作階段，並在最後衡量一致性）並不存在於這組資料中。
• 它將可宣稱的效益縮限到 Playbook 未提及的面向。 消融實驗中保留下來的是一項有劑量相依機制的流程效果：在唯一一個檔案提醒完整測試套件需花 >20 分鐘的程式碼庫中，隨著情境更有選擇性地提供，代理程式盲目執行完整測試套件的次數從 3.67 降至 2.44，再降至 1.67，實際經過時間減少約 24%。這就是「低成本保險」的前提在token 和延遲成本上得到驗證——恰好是下文從頭重建論證所關注的成本；但正確性方面仍缺乏證據。
• 它更清楚指出檔案應放入哪些內容。 陷阱清單的紀律（Agent Context Files）以及「精簡代理程式能從程式碼推斷的內容」規則都仍然成立；依據這些證據，它們也是唯一有實證回報的內容：唯一發揮作用的檔案，記錄了一項環境資訊（測試套件成本），無論多麼仔細地閱讀程式碼庫都無法得知。Playbook 強調的架構原則和風格慣例，正是消融實驗發現沒有作用的內容。

債務何時到期#

Playbook 指出 AI 建構的一般債務有兩個時點會變成結構性負擔：

• MVP → 上線階段的轉換。 正式環境流量、新功能和複雜度成長會揭露捷徑。「債務開始產生利息，拖得越久才處理，修復成本就越高。」
• 企業客戶稽核之前。 企業合約會帶來原型階段不適用的合規要求（SOC 2、GDPR、HIPAA）。AI 掃描有幫助，但明確不能取代合格的合規審查。

上線階段的解方是系統性架構稽核（Claude Code 找出結構弱點、測試涵蓋率缺口和重構候選項目）→ Claude 進行分類並安排修復順序 → 更新 CLAUDE.md，寫入 MVP 期間只存在於創辦人腦中的架構決策。

「從頭重建」失敗模式#

「放任 Claude Code 在毫無防護的情況下建構，會產生功能正常、結構卻不連貫的程式碼庫；在不連貫的程式碼庫上反覆迭代和擴大規模，終究只是浪費時間和 tokens。遲早，程式碼必然會崩潰，迫使你從頭重建。」

經濟上的論點是：在不連貫的程式碼庫上迭代，所需 tokens（更長的情境、反覆重讀、更多澄清）比一開始就維護連貫的程式碼庫更多。成本主要不是人力時間，而是運算。追求零成本迭代的創辦人，是拿現在的幾分鐘去換未來重寫的成本。

複雜度棘輪：模型會增加，卻很少刪除（Ambrosino）#

創辦人 Playbook 描述的是漂移（每個工作階段以不同方式重新推導意圖）。Andrew Ambrosino（OpenAI Codex）從前沿實驗室一側指出另一個彼此獨立的形成機制：模型預設會增加複雜度，而且不擅長刪除程式碼。

「目前所有模型都有一個共同問題：它們通常會增加複雜度。如果任何公司的研究團隊正在聽，拜託讓模型更擅長刪除程式碼。」

這是方向性的偏誤，不只是前後不一致：如果放任代理程式運作，它增加抽象、保護措施和程式碼的速度，會快過移除它們的速度，因此每個工作階段都會讓複雜度棘輪式上升。這是 Ambrosino 所說無法讓開發「完全自動駕駛」的具體障礙（無人監督的迴圈）——他提出「夜間進來替程式碼庫做垃圾回收清理」作為期望能力，正是因為預設漂移方向是增加程式碼，而非減少。Playbook 的解方是持續保存情境（對抗漂移），前沿實驗室面對的則是能力缺口（模型無法可靠簡化）。在自主開發值得信任之前，兩者都必須解決；一家第一方前沿實驗室指出，刪除能力缺口尚未解決。

相同的棘輪也出現在情境層，而且已有測量結果。 From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained（empirical）手動編碼了 5,876 個 GitHub 儲存庫中的 444 個 SKILL.md 差異：排除原地編輯後，整體來看，新增數量是移除數量的 2.7 倍；在本地作者建立後原地演進的技能中則是 6.1 倍（採用時的客製化接近平衡，比例為 1.1:1，因為採用者會刪掉不適用的內容）。開發者不斷附加驗證步驟、禁止事項和最佳實務建議；慣常被刪除的唯一內容，是上游註冊庫的授權條款和作者資訊。因此，原本用來防止重新推導債務的產物（skills），也像程式碼一樣單調增長——同時逐漸過時：53% 被重複使用的技能採用後從未修改，而最大宗的單一演進活動，是追蹤重新命名和工具替換（佔差異的 24.3%），因為周遭專案在技能底下不斷重組。相較於過時文件，這種債務更尖銳，因為代理程式不會略過不一致之處繼續閱讀——它會照著執行。

而在確實有人維護的技能上，棘輪方向也一樣。 Gao 等人抽樣的是整體母體，其中多數技能從未觸碰；Shen & Hruschka（empirical，2026-09）選取五個持續活躍的公開廠商儲存庫，依主要目的為全部 254 次實質 SKILL.md 編輯編碼：60% 為增強、38% 為修正，而整併加棄用僅 254 次中的 11 次（4.3%）——143 個技能在八個月內只退役一個。規模趨勢持平至增加（120 個至少有兩次觀測的技能中，32 個成長 >10%，7 個縮小，81 個維持），編輯間隔中位數為 5 天；每次編輯都由具名人類帳號撰寫或合併，其中 62% 附有 AI 共同作者標記。因此，即使每次合併都有人類參與，方向也沒有改變：持續維護的核心和被棄置的外圍一樣不斷累積，而作者對自動化策展工具提出的第一項設計建議，就是明確設定精簡預算。他們的遷移任務測試又為本文的解方補上令人不安的尾聲——維護六輪以上產生的技能版本並不比第一版好（1 至 5 分量表上為 −0.09，CI [−0.28, +0.10]）——所以對抗漂移的維護工作也尚未證明有回報。完整分析見 Human-Governed Skill Maintenance。

一家沒有既有債務的公司的第一手案例（37signals，2026 年 2 月）#

DHH 表示，本文描述的形成機制發生在 Basecamp；這家公司以架構克制為整體公開形象（Lex Fridman #501，2026-08-26，practitioner-opinion）。在 Basecamp 5 衝刺期間，37signals 認定實作問題已經解決，於是把產品工作交給非程式設計師：

「一開始我們很振奮，覺得『問題解決了。設計師只要寫程式就行。他們知道想要哪些功能，也知道想把功能做成什麼樣子。讓他們隨興發揮吧。』於是我們讓他們自由發揮。結果出現許多 PR，**單獨來看也許在當下情境有其道理，但全部加在一起，卻摧毀了系統架構。**最後我們真的得手動清理，親手、由人來收拾，才能回到感覺凝聚且連貫的架構。」

有三點讓這成為有用的資料，而不只是軼事。這是每個 PR 單獨看都說得通的漂移，不是每個 PR 本身都很糟——正是本文所說「妥協彼此之間的不一致」的明確特徵，由一位有意尋找此現象的人親自觀察到。解方是由人來處理，而且發生在代理式時代好幾個月之後，當時公司有嚴謹慣例、團隊規模也很小。此外，DHH 也獨立重現了該事件之外的堆疊機制：「第一個 PR 品質大概普通，接著在上面再加一個 PR，再往下加五個，品質就不太好了。」

他提出的普遍原則值得記住：你必須已經是程式設計師，才能在既有的大型程式碼庫上進行氛圍編碼，即使它們只是 CRUD，若想保留讓系統發展到目前規模的架構元素更是如此。同樣三個月裡的全新專案——他的 Omarchy 發行版——達到 100% 由代理程式撰寫程式碼，沒有遇上這種失敗；Basecamp 和 Hey「證明要完全以代理程式加速開發，出乎意料地棘手」。目前沒有人釐清造成差異的是哪個變數（程式碼庫年齡、使用者數量或連貫性）。

觀察到的門檻，而非推論出的門檻（Martin，2025 年 12 月）#

本文的形成機制通常是從結果推論而來——被迫重寫、善後清理、PR 漂移。Robert C. Martin 描述了在單一工作階段內親眼看著它發生的經驗，當債務開始讓代理程式而非團隊付出代價時就是那個門檻（Uncle Bob on Software Fundamentals in the Age of AI，2026-08-19，practitioner-opinion）。大約從 2025 年 12 月初期的 Grok 代理程式開始，他刻意不在任務之間清理：

「它會留下這一堆亂七八糟的東西，我不去清理，而是叫它接著做下一件事，然後它又留下更多亂七八糟的東西……我注意到它開始變慢。它改動一處，卻不小心弄壞另一處；修好那裡，又不小心弄壞別處。最後開始原地打轉。」

他描述的終點狀態是代理程式直接放棄——用他的轉述來說，代理程式表示「我真的沒辦法再處理下去了。」

對本文有兩項貢獻：

• 這是門檻模型，不是線性累積模型。「人類會受亂碼的程式碼影響，代理程式也是。也許影響沒那麼大，也許門檻不同，但門檻仍然存在。程式碼可能變得太亂，讓代理程式再也無法應付，接著就會開始打轉，讓情況變得更糟。」如果債務有一道懸崖，而非一條斜坡，可觀察到的訊號就不是輸出逐漸惡化，而是代理程式自身的行為突然改變——無效反覆、修復來回震盪、放棄。這是比任何架構審查都便宜的早期指標，也是 Martin 說他實際使用的指標。
• **這就是他不讀程式碼的原因。**有人問他 12 月時怎麼知道代理程式犯了錯，他清楚區分兩種訊號：「早期我只是看程式碼，看到一堆狗屎。**那不是重點。**重點是接下來我看到它們打轉。」接著他指出這對未曾親身經歷的人造成的遷移問題：「問題之一是新手進來時，認不出這種掙扎」（代理式編碼中的專業知識回報）。

他的解方不是持續保存情境，而是一套必須通過的閘門，從一開始就讓混亂維持在門檻以下（重啟不切實際的品質工具）——針對相同形成機制，提出不同於本文 CLAUDE.md 計畫的答案。兩者尚未經過直接比較。

延伸閱讀#

• Agent Documentation Behavior — **本文解方所預設的共同演進測量。**代理程式確實會維護文件——33,097 個代理式 PR 中有 41.5% 修改文件，高於人類留言維護文獻所見——但債務形狀的部分在於先後順序：在 4,386 個能觀察提交順序的多次提交 PR 中，程式碼先被觸及的頻率是文件的 4.7 倍，而兩者分別在不同提交中併入時，有 82.5% 是程式碼先行。因此，下文的持續情境解方，天生就落後於它應該描述的程式碼，而非因疏忽才落後

• Spec-Driven Development as the New Waterfall — 如果採納低成本修改的論點，卻沒有配上讓它安全的閘門堆疊，會累積哪些問題

• Community Smells Under AI Adoption — 這項債務在團隊層面的影子：五種結構模型中，唯一指向傷害的路徑是資訊治理（採用 AI → 文件和非正式資訊流變差，β = −.194，p =.069，邊緣顯著）

• Unproductive Self-Verification — 債務如何被寫入：未經要求的重構、額外測試和推測性的驗證管線，看起來像生產力，並在 Opus 5 的訓練逐字稿中觀察到

• AI-Native Startup Lifecycle — MVP 和上線階段的主要風險

• Deep Modules for Agents — Ousterhout 式深層模組加上持續情境紀律，是抵抗這股趨勢的架構力量；Matt Pocock 的 Sandcastle 模式是具體案例

• Agent Context Files — 本文解方所屬的跨廠商模式，也是 Khatri 消融實驗完整分析之處：一般慣例內容對正確性的回報接近零，實測回報在成本和流程上

• Claude Code Best Practices — Anthropic 關於 CLAUDE.md 的官方指引；Playbook 將相同紀律定位為創辦人的生存之道，而非最佳實務

• Claude Code — 這項債務累積的工具

• Zero-Friction Scope Creep — 相關失敗模式；範疇蔓延會讓債務累積得更快

• Harness Shrinkage as Models Improve — 抵抗力量：如果 harness（包括工作階段情境管線）縮小，CLAUDE.md 也可能需要演進

• Context Window Smart Zone — CLAUDE.md 必須符合智慧區；過長的情境檔案本身也會造成問題

• Design Concept Grilling — Matt Pocock 的 grill-me 模式會在寫程式碼前先形成 Brooks 所說的「設計概念」，與 CLAUDE.md 作為架構情境互補

• Founder as Agent Orchestrator — 非技術創辦人的管線讓風險更高：最能辨認問題的創辦人，最不具備撰寫架構情境的能力，而這正是防止此債務所需的

• Problem-Solution Fit Discipline — MVP 階段的另一項風險；認知紀律（先驗證再建構）和架構紀律（先持續保存情境再建構）都不可或缺

• Agentic Work Systematization — 未系統化的代理程式使用方式，就是從零重新推導／意圖債務的失敗模式；skills 是持續保存情境的解藥，但逐漸腐壞、無人維護的 skills 本身也會形成債務，因為慣例會變動

• Unknowns as the Agentic Bottleneck — 帶有 Deviations 日誌的 implementation-notes.md，是在執行期間逐步償還的意圖債務：代理程式記錄迫使它偏離計畫的邊界案例，讓下一次工作階段不必重新推導

• Code as Source of Truth — Fiona Fung 提出對抗這項債務的正向做法：把規格／skills 納入儲存庫，讓情境保持最新，並讓 Claude 驗證規格漂移，不必每次工作階段都重新推導

• Harness Shrinkage as Models Improve — CLAUDE.md 是一項最終或許能被推斷出來的 harness 資產；在那之前，持續保存情境就是對抗債務複利的解藥

• Founder as Agent Orchestrator — 遞迴問題：非技術創辦人可能缺乏撰寫有效 CLAUDE.md 的詞彙

• Loop Engineering — Osmani 所說的意圖債務，是從迴圈角度看同一種複利漂移機制：沒有 skills 時，迴圈會「每個週期都從零重新推導整個專案」，每次工作階段都用一個信心十足的猜測填補意圖缺口；skills（將意圖寫在外部）就是解藥，和此處的 CLAUDE.md 完全相同

• Outsource Your Thinking, Not Your Understanding — 認知層面的孿生問題：理解債務（存在的程式碼和你理解的內容之間的落差），是以理解為衡量標準的架構債務；兩者都會以代理式編碼的速度複利增長

• Acceleration Whiplash — 同一複利機制在產業規模上的測量；Faros AI 的「情境引擎」（從程式碼庫的演進過程推導意圖，而非只看當前狀態），是組織規模版的 CLAUDE.md 解方

• AI as Primary Author — 沒有持續保存意圖的 AI 作者，每次工作階段都會重新推導架構；這項債務就是此種作者身分／問責落差造成的結構成本

• Andrew Ambrosino — 前沿實驗室對複雜度棘輪的報告：模型會增加程式碼，不擅長刪除，並阻礙無人監督的開發

• Vibe Coding vs. Agentic Engineering — 刪除能力缺口解釋了為何「迴圈已經過時」還沒發展到完全無人監督的自主開發

• Harness Build-vs-Buy — 寫程式代理程式帶來的另一種債務，形成機制完全不同：不是你自己的程式碼內部出現意圖漂移，而是別人的廠商分支發生分歧，以他人的開發速度每天累積約 13 個上游 PR。成熟曲線相同（直到被迫重新套用變更或被迫重寫前都看不見），成因無關——不要把它的 PR 數量當成代理程式撰寫程式碼品質的證據

• Security Debt of Agent-Generated Code — 同一債務在安全面向的實測：它累積於 CI／容器管線（87.6% 的異味出現在 GitHub Actions 工作流程和 Dockerfile），這些都不在任何工作階段的架構情境涵蓋範圍內；而且只有在憑證遭利用時才會浮現，不會等到被迫重寫才出現

• Agent-Generated Test Quality — 測試套件中的「隱形技術債務」：代理程式測試觸及磁碟和非確定性 API 的比例約為人類的 1.4 倍，因此測試套件今天能通過，未來卻會降低 CI 的可靠性——這與可運作功能掩蓋其架構前提一樣，都是不會自行揭示問題的特性；債務累積在環境而非架構。該文的涵蓋率結果，是來源在測試領域對本文形成機制的直接描述：「未測試的程式碼路徑會形成悄然累積的技術債務，直到正式環境發生回歸失敗才浮現」，而且已有測量結果：50.4% 修改程式碼的代理式 PR 沒有測試變更，Python 中既有測試僅觸及 27.0% 的變更行數。可運作的功能不會揭示其架構前提；測試全綠也不會揭示它是否涵蓋了差異內容

• Review as the Control Point — 理解債務是 CMU 程式碼審查理論中此架構債務的認知孿生問題：審查深度不足加上程式碼不透明會累積債務，接著形成強化迴圈，侵蝕可維護性、所有權和未來的審查技巧——即使審查深度維持很高，也仍會累積（「品嚐料理，而非閱讀食譜」）

• Efficiency Debt of AI-Generated Code — 同一種情境缺失機制以運算量計價：AI 生成的 C++ 會寫出約 2 倍的明確迴圈，以及少 30–40% 的標準函式庫呼叫，導致正式環境的相對運算開銷約 5%、記憶體開銷約 8%。有兩點讓它成為本文的同類議題，而非獨立主題。論文本身對成因的假設是「通用型 LLM 缺乏高度特定的內部企業 monorepo 結構情境」，提出的修正方式是在提示時注入這些情境的知識庫——這與 CLAUDE.md 解方殊途同歸，都是從效能剖析資料中得到的結果，而且不像 Khatri 消融實驗，已有實測回報（目標發現數減少 11.1%）。它也指出了債務成熟時點：這種債務永遠不會迫使團隊重寫，只會讓每個月的帳單更高

• Prototype Fidelity After Cheap Polish — Boehm 1988 年提出的「義大利麵式程式碼困境」，就是本文論點的原始形式，也是演進式原型製作從未成功的原因；GenAI 能否解決問題，還是自動化重複同樣錯誤，是本文證據要回答的分岔點

• The Code-Quality Payoff Is Token-Indexed — DHH 對同一現象的經濟觀點：架構一致性的價值在於代理程式不必反覆重新推導情境，因此這項債務的成本取決於 token 預算，而非人類理解能力

• Open Source Under Agent Contributions — 同一種漂移從團隊之外進入：無上限供應、各自都能通過的外部 PR，由代理程式分流

• Robert C. Martin (Uncle Bob) — 親眼看著門檻在工作階段中被跨越的實務者，並據此重新建構工作流程，避免再次逼近門檻

• Reviving Impractical Quality Tools — 閘門堆疊解方：以機制把混亂壓在代理程式門檻以下，而非記錄架構

• Human-Governed Skill Maintenance — 棘輪在有人維護的核心，而非被棄置的外圍上的測量：254 次由人類發布的 SKILL.md 編輯、一次棄用、十次整併、60/38 的增強／修正比例；維護工作也沒有實測回報

尚待解答的問題#

• 隨著程式碼庫演進，CLAUDE.md 能維持準確多久？Playbook 只提到每個工作階段都更新；沒有資料測量腐化速度。（Khatri 2026 只回答了一部分——並未真正解答：腐化速度仍未測量，但問題的重要性有所改變。如果評為良好／優秀的檔案並未比完全沒有檔案帶來更多正確性，那麼過時檔案造成的正確性損失也相對有限；真正重要的腐化，是環境事實內容（測試成本、部署不變條件）——唯一實測有效果的內容。仍待完成的是縱向研究：檔案準確度的下降，是否與代理程式行為中可觀察的變化有關？） （2026-09-22 測量了維護頻率，而非腐化速度：研究 Who Maintains Agent Skills? A Longitudinal Study of Human-Governed, AI-Assisted Skill Maintenance 探討相近產物；積極維護的公開 SKILL.md 檔案中位數每 5 天就會修改一次，實質編輯有 38% 是修正——包括事實更正和根據已觀察失敗所做的修復；主要編碼階段中 24% 的編輯有具體失敗證據，跨研究族群重新編碼後則為 63%。這顯示受維護的 skills 多常被修補，而非未維護的 skills 衰退多快；同一篇論文的遷移任務未顯示差異（最新版相較最早版為 −0.09，CI [−0.28, +0.10]），表示這些修補沒有帶來可測量的效益——正好從另一面印證 Khatri 對問題利害程度的弱化。）
• 這項解方假設創辦人有能力用白話說明架構。非技術創辦人（Playbook 主要面向的受益群體）可能既缺乏詞彙，也缺乏直覺，無法做好這件事——這是 Playbook 沒有處理的遞迴失敗。（Khatri 2026 弱化了這項假設，但沒有解決問題——如果檔案不影響正確性，創辦人寫不好檔案的代價就比本項所假設的小；請見 Founder as Agent Orchestrator。）
• Anthropic 的 harness 縮減論點指出，CLAUDE.md 最終或許能由模型自行推斷。在那之前，這項紀律仍不可或缺。

資料來源#

• From Agent Behaviour to Agent-Friendly Documentation — Gao & Chen（Peking University），arXiv 2608.20195，2026-08-20，empirical。本文引用 §4.3（33,097 個 AIDev PR 中有 41.5% 修改文件，依儲存庫分群的 CI 為 35.8–45.4%；4,386 個可辨識提交順序的多次提交 PR 中，47.3% 先碰觸程式碼，相較之下文件優先的比例為 10.0%；兩者落在不同提交時，程式碼先行的比例為 82.5%），以及 §2.3 與人類共同變更文獻的比較。本文不引用合併率數據——儲存庫分群的區間重疊，作者也沒有下結論。完整分析見 Agent Documentation Behavior

• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501 — DHH，Lex Fridman #501（2026-08-26，practitioner-opinion）：Basecamp 5 設計師氛圍編碼造成的架構失敗，以及人工善後清理；37signals 程式碼庫中重現 PR 疊加漂移

• The Founder's Playbook: Building an AI-Native Startup — MVP 階段及上線階段章節

• OpenAI Codex lead on the new shape of product work — Ambrosino：「模型通常會增加複雜度……拜託讓模型更擅長刪除程式碼」

• From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained — Gao 等人，arXiv 2607.00911（empirical）：§VII-A 增量維護的不對稱性（整體 2.7:1，演進中的技能為 6.1:1）；§VI-A 有 53% 的重複使用技能採用後從未修改

• Who Maintains Agent Skills? A Longitudinal Study of Human-Governed, AI-Assisted Skill Maintenance — Shen & Hruschka（Megagon Labs），arXiv 2609.05677，2026-09-04，empirical：§4 加上附錄 C 的操作分布（254 次中整併 10 次、棄用 1 次）、§5 加上圖 4 的規模趨勢和維護頻率、§6 的治理、§7 的遷移任務未顯示差異。完整分析見 Human-Governed Skill Maintenance

• Do Context Files Help Coding Agents? A Two-Agent Ablation Study on Real Repositories — Prakhar Khatri，arXiv 2607.27250，2026-07-28（empirical，唯一作者，未經同儕審查）：首次對 CLAUDE.md／AGENTS.md 解方做受控消融——表 1 中兩種代理程式的 NONE／ALWAYS ON／SELECTIVE 通過率持平，§5.1 將失敗歸因於實作技巧而非知識，§5.2 操弄探測（真實檔案從未翻轉一項差點通過的失敗），表 2 呈現完整測試套件執行的劑量效果。這是有界的無差異結果，不是具足夠檢定力的等效性主張（n=17 時 MDE >30pp）；範圍限於單一工作階段的任務正確性，因此沒有測試本文的跨工作階段漂移機制。論文五個表格中有兩個在原始資料裡格子合併；本文數據引自內文*（原始資料於 2026-09-05 以 docling 2.126 重新解析：表 3 的任務列焊接問題已修復；剩餘的 table-collapse 命中是重複通過次數組合，不是列合併——請見 Agent Context Files 的說明。）*

• Uncle Bob on Software Fundamentals in the Age of AI — Robert C. Martin 與 Matt Pocock，2026-08-19（practitioner-opinion；自動字幕逐字稿）：工作階段內門檻案例——無效反覆、修復震盪和代理程式放棄任務；另主張可用的早期訊號是觀察代理程式掙扎，而非閱讀輸出