三重債務模型：一個幫你想清楚自動化架構的框架
三重債務模型：一個幫你想清楚自動化架構的框架
做 Autopilot 這套系統的時候，手上沒有現成框架——五個問題是逐個撞到才解決，不是一開始就有藍圖。後來在一個 AI 與 Data 的研討會上，聽到一個框架，才發現當初撞到的這五個問題，其實可以用一個更簡單的結構重新講一次：技術債、認知債、意圖債。
Autopilot 是不是做得對，不重要；重要的是這個框架本身，可以幫忙想清楚要自動化的東西落在哪一層，每一層又有哪幾種常見做法。Autopilot 的選擇只是其中一種，不一定是適合你的那一種。
三層的性質，各自不同
自動化跑起來一段時間之後，容易發現一件事：代碼本身通常是最快處理好的部分——重構、補測試、清乾淨，都有明確做法可循。慢慢變成阻力的，反而是另外兩件事：還有沒有人跟得上系統實際在做什麼，以及當初為什麼這樣設計的理由還在不在。
University of Victoria 的 Margaret-Anne Storey 在最近一篇論文裡，把這個現象整理成三層獨立的債務。
技術債住在代碼裡——實作方式令系統之後好不好改。
認知債住在人的腦裡——團隊對系統的共同理解，隨時間流失。這一層最麻煩的地方，是它可以在代碼完全沒壞、測試全部通過的情況下發生：外觀一切正常，但已經沒有人跟得上系統實際在做什麼。
意圖債住的地方，是從來沒有寫下來的東西：支撐系統演化的目標、約束和理據。如果這些東西只存在某個人的腦裡，沒有外部化，之後要嘛難以復原，要嘛完全無法復原。
Storey 強調這三條是獨立的軸：一個系統可以技術債極低，同時意圖債極高——代碼乾淨、測試齊全，但除了寫這套系統的人以外，沒有人知道它為什麼長成這樣。
接下來借用的，不是「債」這個框架本身——Autopilot 並不是在討論欠了什麼債、要怎麼還債。借的是背後那三層的分法：一部分是可以講清楚規則的具體執行，一部分是要跟得上全局在發生什麼的理解，一部分是究竟想做什麼的方向。這三層剛好貼合設計自動化時常常撞到的三種不同問題，跟原本論文要處理的「軟體健康」問題不完全一樣。
每一層底下，怎樣用 Agent 去減輕負擔？如果一件事最後仍然是「請人類回頭去看」，那只是把查核的工作搬了個位置，不算減輕負擔。真正的減輕，應該是 Agent 主動做了一部分原本要人做的理解、篩選或組織工作，人只需要在剩下的地方做判斷。
技術層：選對觸發和執行的方式
Autopilot 用的是 Cursor 的 Automation，但這一層不需要綁定某一個平台。GitHub 事件觸發的 bot、外部 webhook 觸發的 CLI agent，都是類似的做法，選哪一種，看的是這一步能不能講成一組規則，跟平台叫什麼名字關係不大。
用 Cursor 處理，一部分原因是熟悉——連寫書這種非程式碼的任務，也放在同一個平台裡處理，這不代表 Cursor 是唯一或最好的答案，只是目前用得順手的選擇。可以想像不同性質的任務，未來會落在不同平台上。
這一層 Agent 能幫忙減輕的負擔，主要是把規則寫得更完整——例如讀 log 找出規則沒想到的情況、主動指出需要補的測試、提出可以重構的地方；接手做判斷本身，則應該盡量交回確定性代碼。「Agent 幫忙維護自動化」跟「Agent 負責運行自動化」是兩件不同的事。
認知層：彙整一個畫面，還是主動講重點
把狀態彙整成一個畫面，不等於負擔減輕了。如果那個畫面仍然要人自己逐項看、自己判斷有沒有異常，負擔其實只是換了位置——查的成本變低了，理解的工夫還是要人自己做。
要真正減輕，通常要 Agent 多做兩件事。第一，主動摘要：主動整理出這段時間變了什麼、有什麼看起來不對勁、有什麼需要判斷，推給人看，不必等人自己去揭一個 dashboard。第二，轉介：把一段對話或一個想法，拆分成不同 repo 各自需要的具體指令——這其實是一種翻譯工作，不只是整理。
Autopilot 目前這兩件事都做了一部分：跨專案收集器負責把狀態彙整起來；日常跟 Claude 的對話，則負責把一句話拆成不同 repo 的具體任務。
這裡也有其他做法。有人會用 Notion 這類集中式資料庫做總覽儀表板，讓所有狀態集中在一個地方查閱；也可以用 Claude 或 ChatGPT 本身的 connector，甚至市面上其他 agent 工具，去代理這件事。這些做法常見的共同限制，是 chat session 的記憶沒辦法跨 session、跨地方分享——每次開新對話，等於重新從零開始。收集器（用 Orbita 擔任這一層）想解決的正是這個問題：把儲存和檢索分開，狀態統一存放，另外交由一個專門的 agent 負責讀取和呈現，不必依賴單一 session 的記憶。
意圖層：個人和團隊，負擔不一樣
個人意圖
困難通常不是沒有地方寫，而是從零開始寫一份完整的方向文件，這件事本身門檻很高——很多人根本沒有動手，理由通常是太費工夫，不是不重要，於是意圖一直留在腦裡，沒有交給 Agent。
一個常見、也可能是最多人在用的做法，是直接持續跟 Agent 聊——不刻意寫成一份正式文件，讓 Agent 在對話裡慢慢幫忙釐清、記錄下來。這是可行的做法，只是理據會分散在很多次對話裡，不會集中在一份文件。另一個可能的做法，是讓 Agent 從已經發生過的對話和決定裡，主動整理出一份初稿方向文件，人只需要審核和修改，不用從白紙開始寫。哪一種更適合，可能取決於個人習慣，多過取決於哪個更對。
團隊意圖
這是目前還在摸索的方向，還沒有定論。
Autopilot 用 Slack 作為一個入口：團隊討論到有共識，用 emoji 觸發，Agent 把討論整理成提案。Slack 只是眾多可能入口之一。開源專案常見的做法——用 GitHub Issues 收集大眾回饋，再由維護者決定方向——是同一個模式的另一種版本：把意圖誰能貢獻，從一個人的瓶頸，變成任何人都可以參與。
負擔不在收集本身——issue tracker 本身已經做到收集。負擔在於篩選和歸納：如果最後還是要一個人逐條看幾百個 issue 才能決定方向，負擔並沒有減輕，只是換了一種形式的要人看。比較值得探索的做法，是讓 Agent 把大量零散的回饋聚類、歸納成幾個候選方向，人只需要在幾個選項之間判斷，不用逐條看完。
這部分還在嘗試階段，還沒有穩定的做法可以分享。
三層分開看，還有一個管理上的好處
Autopilot 本身也不是三層都處理得一樣完整。技術層和意圖層都有明確的做法，但認知層目前的收集器只彙整技術狀態；判斷方向的那一步，仍然要靠人自己讀懂彙整出來的畫面，還沒有再往下一步系統化。
三條軸確實互相獨立：一個系統可以在某一層做得很好，同時在另一層完全沒有處理。與其籠統問這套自動化做得好不好，不如逐層問：技術層有沒有變成可以檢查的規則？認知層有沒有辦法讓人重新獲得全局理解？意圖層的理由有沒有留下來？
三層可以各自選用不同的工具、各自管理，不需要一個系統包辦全部——技術層可以用 Cursor Automation，也可以換成其他觸發方式；認知層可以用 Orbita，也可以換成 Notion 或其他 agent 工具；意圖層的方向可以用 Slack，團隊回饋可以用 GitHub Issues。三層之間保持鬆散，一層出問題不會拖垮另外兩層，也可以逐層更換做法，不用重寫整套系統。這是自己實際用下來的心得，不是說每個情況都適用；如果要一個系統同時處理全部三層，管理起來大概會困難得多。
引用來源：Margaret-Anne Storey，“From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI”，2026。