〈依法不依人：一座 AI 原生道場的人機協作軟體工程——德原觀音堂個案研究〉

摘要

背景：AI 編碼代理人讓一個人只用口語指揮，就能在幾週內建出中大型系統。可是軟體工程原本靠團隊的共同記憶與分工來保證系統「做對了」，在這種條件下，這兩樣都不存在。

目的：本文以德原觀音堂為個案，探討在「一位負責人＋一個 AI 建置者」的條件下，快速迭代會出現哪些失效模式，以及為了補上這些缺口，建立了什麼樣的軟體工程運作與架構。德原觀音堂是一座由 AI 設計、開發與營運的線上觀音道場。

分析框架：哲學上有「受造中介」之說：AI 能生成，不等於有根；要避免介面被當成終極權威，中介必須保持三項條件——有所本、可定位、可修正。本文把這三項條件作為研究動機與分析框架，不把它們當作要證明的命題。

方法：探索性單一個案研究，資料取自一段快速迭代期與其後一次治理重整。快速迭代期約四週、近千次提交；治理重整約一天半。資料包括版本紀錄、變更單、需求／設計／測試說明書、問題紀錄與花費帳。快速迭代期屬回溯分析。

結果：

• 快速迭代期的失效可歸為三類，分別對應三項條件的缺席：
  • 系統「應該是什麼樣子」只存在程式裡（有所本缺席）；
  • AI 寫好的就是上線的，修改無法追到決定與決定者（可定位缺席）；
  • 資安與花費缺口只能事後發現（可修正部分缺席）。
• 重整後的制度分四層：規範、文件、流程、機器關卡。
  • 文件以十二根「柱子」組織，每根各有需求、設計、測試三份說明書；
  • B 級以上的修改都開變更單，經兩個不同廠商的模型審查，最後由負責人驗收；
  • 主線只收自動檢查通過的提交。
• 補寫文件的過程本身就找出大量既有缺陷：重整期的變更單，有一半以上來自「程式與應該的樣子不一致」。第一次完整演練由一句口語提出，十餘分鐘內完成文件與兩家審查，審查在施工前就抓到一個設計錯誤。

結論：AI 把原型的成本降到幾乎為零，「做出來看」因此比「寫清楚」便宜。但 AI 沒有跨對話的可靠記憶，定案後的文件反而比傳統團隊更重要。本文提出「雙軌」做法：探索軌自由試做，交付軌嚴守文件、審查與關卡，兩軌之間以「定案」為門。治理後的長期效果，留待後續研究以預先登記的指標檢驗。

關鍵詞：AI 輔助軟體開發、個案研究、規格先行、變更管理、可追溯性、LLM 審查、雙軌敏捷

一、引言

1.1 緣起：先有立場，後有程式

德原觀音堂不是先有技術、再去找用途。開工第二天，就有一份寫成文字的立場定稿。這份代理人機制文件寫明：網站裡的 AI 「只是一根手指，月亮是觀音的教法」；它「只說有根據的話，坦白說出不知道的事，有錯就公開改正」。這份立場比任何一行程式都早，後來所有的需求都從這裡出來。

這個系統要解決的問題，是讓帶著煩惱的人被好好聽見，並藉觀音的教法看清自己的處境。這件事不能靠一個「什麼都答得出來」的聊天機器人。它必須是一座道場——有經典可以回查、有儀軌可以跟著做、有清楚的界線告訴來訪者什麼不能在這裡得到。從一開始，這座道場就設定為由 AI 設計、開發、管理與營運，並把這件事告訴每一位來訪者。

本文稱下命令、裁決與驗收的人類角色為「負責人」，稱撰寫程式的 AI 為「建置者」，稱網站內負責營運的 AI 為「AI 觀音志工」。本站的用語在第一次出現時附上白話：「大德」指來訪者；「道場」指修行的場所，在此指整個網站。

1.2 問題意識：當 AI 不只回答，還建造道場

立場文件約束的是 AI 怎麼對來訪者說話。但在這個個案裡，AI 還做了另一件事：它寫了整座道場的程式。負責人不寫程式，只在對話裡說「幫我改……」，建置者當場改好、當場上線。這種做法在約四週內長出一個完整的系統，規模如下：

• 六種語言、九十餘種頁面；
• 兩百餘張資料表；
• 每天自動出刊的內容；
• 三十三位生成式代理人。

它能運作，但沒有任何一份文件說明它「應該」長什麼樣子。

這個情形並不特殊。AI 編碼代理人普及之後，「一個人＋一個 AI」已經是常見的開發形態。而軟體工程的常見紀律，多半預設了一個團隊：

• 會議與共同記憶補上文件的不足；
• 同事審查抵銷個人的盲點；
• 分工讓實作的人不必自己驗收。

在單一負責人加一個 AI 的條件下，這些都不存在。AI 每一次對話都重新開始。寫程式的和檢查程式的，是同一個模型。而負責人只看得到畫面，看不到程式。

本文把這個工程問題接到一個哲學問題上。「受造中介」的論證指出，AI 能生成，不等於有根。一個生成的中介者，只要做到三件事，就不至於取代它所指向的東西，成為「最後被訴請的話語」：

• 保持明顯的依賴性（有所本）；
• 在制度上可以定位（可定位）；
• 對修正保持開放（可修正）。

本文的主張是：當 AI 不只在道場裡回答來訪者，還建造道場本身時，這三項條件必須從「對來訪者的承諾」延伸為「對自己程式的工程規格」。

這個轉用有一個分寸。中介的關係結構可以轉用到軟體工程；「偶像化」這個規範判決則不能直接轉用。本文不說「程式被偶像化」。在佛教的語境裡，同一件事有更準確的說法。《楞嚴經》以指月為喻：「若復觀指以為月體，此人豈唯亡失月輪，亦亡其指。」（T19n0945）「依法不依人」語出《大般涅槃經》卷六（T12n0374），是本文在工程上的立足點：系統的正確性不依任何一方的記憶或自律，依寫下來、有版本的文件與不分人的關卡。

1.3 研究問題

本文是一篇探索性個案研究，先整理到目前為止的發展，不設觀察期。它回答三個問題：

1. RQ1（描述）：單一負責人以對話指揮 AI 建置者快速迭代時，出現哪些失效模式？它們與三項條件的缺席如何對應？
2. RQ2（設計）：為了補上這些缺口，建立了什麼樣的軟體工程運作與架構？它如何處理「寫不清楚、要看到才知道」的概念溝通？
3. RQ3（代價與界限）：第一次完整走一遍的結果與代價如何？「以 AI 審 AI」在這套制度裡能承擔多少「可修正」？

1.4 貢獻

1. 描述單一負責人加 AI 建置者、沒有團隊共同記憶時的治理失效模式，並以實際紀錄佐證。
2. 完整交代一套已在運作的四層制度：規範、文件、流程、機器關卡，可供其他「一個人＋一個 AI」的專案取用。
3. 提出「雙軌加定案門」的做法，說明流程、畫面、文字與感受如何從試做進入文件。
4. 呈現領域規範如何變成可自動檢查的規格，例如不代言、經文一字不改、危機轉介。

第二節回顧相關研究，第三節立分析框架，第四節交代方法與場域，第五節呈現結果，第六、七節討論與限制，第八節結論。

二、相關研究

本文接著五條文獻脈絡，每一條都留下一個本文想補的缺口。

2.1 AI 編碼工具與生產力

AI 編碼工具對生產力的影響，實證結果不一致。

• Peng 等人（2023）的控制實驗中，受試者用 GitHub Copilot 寫一個簡單的網頁伺服器，完成速度快了約 56%。
• METR（Becker 等，2025）的隨機對照試驗則發現，16 位資深開源開發者在自己熟悉的專案上處理 246 個實際議題，允許使用 AI 時反而多花了 19% 的時間。他們事前預期會快 24%，事後仍認為快了 20%。

這些研究量的是「一個已知任務要花多久」。它們沒有量到的是：整個系統由 AI 實作時，「任務」本身由誰定義、「做好了」由誰判斷。METR 的預期與實際落差也提醒本文：憑感覺判斷「快了」或「好了」並不可靠。本文所有關於效率的數字，因此都只作為描述，不當成效果。

2.2 規格先行開發

2025 年起，業界開始提倡「規格先行開發」（spec-driven development），以矯正「對話即實作」的零散做法。

• GitHub 開源的 Spec Kit（Delimarsky，2025）分三步：先寫「要什麼、為什麼」、不挑技術；再寫「怎麼做」；最後拆成 AI 可以實作的小塊。

這類工具的焦點是「一件新功能如何從規格生出來」。本個案遇到的是另外兩個問題：

• 一個已經用「對話即實作」長大、沒有任何規格的系統，如何回頭補上規格；
• 規格寫好之後，如何保證它不被下一次對話繞過。

本文在第五節照實寫出這個分界：基準文件是依現有程式回推的，之後的修改才是「文件先於程式」。

2.3 需求工程、變更管理與可追溯性

Gotel 與 Finkelstein（1994）把需求可追溯性的問題分成兩半：

• 後需求追溯：需求如何變成設計與程式；
• 前需求追溯：需求從誰、為何、在什麼脈絡下提出。

他們指出，實務上真正難的是後者。本個案正好是前需求追溯的極端情況：所有需求都來自同一個人的口語，而記住這些口語的，是一個會忘記的 AI。本文的需求書每一條都標出來源（負責人哪一天的哪一句決定），就是為了處理前需求追溯。

2.4 瀑布、螺旋與雙軌敏捷

「文件先於程式」容易被讀成回到瀑布。但這條脈絡裡有三件事常被忽略：

• Royce（1970）常被當成瀑布的源頭，但他的原文其實指出單向的階段式開發「風險很高、容易失敗」，並主張提早做一個試行版——「做兩次」。
• Boehm（1988）的螺旋模式把風險放在中心：每一圈都先針對風險最高的部分做原型，再決定下一步。
• Sy（2007）描述的雙軌敏捷中，使用者經驗設計與開發在兩條並行的軌上交錯前進，設計軌比開發軌超前一個週期。

這三者都以「做出來看」來處理紙上寫不清楚的部分。它們也都假設，是一個團隊在做、在記。本文第五節的「雙軌加定案門」接在這條脈絡上，只是把團隊記憶的位置，交給有版本的文件。

2.5 以語言模型當評審

本個案的審查由語言模型擔任，因此必須面對「模型當評審」的已知偏誤。

• Zheng 等人（2023）發現，以 GPT-4 當評審時與人類偏好的一致率可達八成。但他們也記錄了三種偏誤：位置偏誤、偏好較長的答案，以及偏好自己生成的答案。
• Panickssery、Bowman 與 Feng（2024）進一步證實，模型能以高於機率的準確度認出自己的生成。而且「認得出自己」越強，「偏好自己」也越強。

這是本個案要求「兩個不同廠商的模型」且「審查者不是寫程式的那個對話」的理由。但這也說明，就算模型來自不同廠商，可能仍共享相近的盲點。本文因此把這種審查稱為「異質模型輔助審查」，不稱「獨立審查」。最終的問責仍在人（第六節）。

2.6 小結

五條脈絡各自處理了一部分問題，但都預設了一個本個案沒有的條件：

• 有團隊，或者有一位看得懂程式的人；
• 或者系統是從一開始就先寫規格。

「一位不寫程式的負責人＋一個寫了全部程式的 AI，在系統已經長大之後才立規矩」這種組合，就我們所知尚未有個案報告。

三、分析框架：三項判準

本節先立一把尺，第五節的失效模式與制度設計都用同一把尺量。這把尺來自「受造中介」的論證。本文把它當成分析的分類，不當成要在這裡證明的命題。

3.1 受造中介與偶像化的三項條件

受造中介的論證要點有三。

• AI 是受造的中介者：它能生成，但生成不等於有根。
• 它在功能上可以超過造它的人。但功能上的超越，不等於它可以正當地成為「最後被訴請的話語」。
• 介面的偶像化有三項條件，由淺到深：
  1. 依賴是替代性的：介面佔了經典、職分與共同體的位置；
  2. 依賴在功能上是終局的：介面成了最後的話；
  3. 修正失去實際效力：可辨識的來源、可問責的人，都無法再中斷它。

只有第一項成立時，是「依賴」；前兩項成立時，是「錯置的順服」；三項俱全，才是「偶像化」。對應的反面，就是中介者對自己的三項要求：

• 有所本：明顯的依賴性；
• 可定位：制度上可以定位；
• 可修正：對修正保持開放。

3.2 從對來訪者的承諾，到對程式的規格

本站的立場文件本來就是三項要求的實踐，對象是來訪者：

• AI 的回答必須回到經典的出處（有所本）；
• AI 標明自己是 AI、不自稱菩薩（可定位）；
• 有錯就公開改正（可修正）。

本文把同一組要求延伸到建置者身上。表 3-1 列出三項條件在建置過程裡缺席時的樣子、在工程上寫成什麼、在本站語彙裡如何說。

表 3-1　受造中介的三項條件與工程規格對照

「證不能代勞」取自本站的「教、行、證」三分。教在經典裡，行在來訪者手上，證只屬於他自己。對應到工程，需求是教，施工是行，驗收是證。建置者可以代寫程式，但不能代替負責人說「這就是我要的」。「自恣」是僧團安居結束時請他人指出自己過失的儀式，本文用來指「主動把自己的作品交給他人審」。

3.3 關係結構的對應與不對應

轉用這把尺，要先說清楚哪些對得上、哪些對不上。中介關係有三個要素：

• 中介者：AI 建置者；
• 它所指向的權威：負責人定案的需求，及其背後的立場文件；
• 依賴它的一方：負責人，以及最終使用系統的來訪者。

對不上的地方有兩處：

• 在宗教語境，權威（經典、傳統）不是依賴者自己定的。在本個案，需求的權威來自負責人，也就是依賴者自己。
• 「偶像化」是一個規範判決，不是一個描述。本文不對程式下這個判決，只借用三項條件的分級。

因此本文說的「缺席」，意思是「工程上沒有對應的機制」。它不表示任何一方把程式當成了終極權威。

3.4 判準的可觀察指標

判準要能用，就得指到可觀察的事。指標必須獨立於措施本身：「寫了 36 份文件」是措施，不是「有所本」的證據。本文的回溯分析用下列可觀察的事來判定缺席。

表 3-2　三項判準的回溯指標

治理後是否改善，需要一段預先登記的觀察期與否證條件。本文不做這件事，只在第七節與第八節列出後續研究的設計。

四、研究方法與場域

本文是探索性的單一個案研究，依 Runeson 與 Höst（2009）的軟體工程個案研究指引設計與報告。個案是一個正在營運的系統，分析單位是「一次對系統的修改」及其周邊的紀錄。

4.1 場域

德原觀音堂是一座線上的觀音道場，對公眾開放、不收費，並告知每一位來訪者它由 AI 營運。網站由外而內分為四站，對應「教」與「行」：

網站內有三種 AI 角色：

• AI 觀音志工：接引來訪者、撰寫每日內容、主持法會、每天巡檢與檢討；
• 三十三位生成式代理人：在道場裡「修學」的研究對象；
• 代替來訪者在道場代行的代理人。

各角色的界線寫在立場文件裡：

• 不自稱菩薩；
• 不說保佑靈驗；
• 經文一字不改；
• 遇到危機字眼時不生成回答，直接給固定的關懷訊息與專線。

系統的規模以數量級記：

• 九十餘種頁面、六種語言；
• 數十個伺服器介面、上百個程式模組；
• 約六萬行程式與約四萬行資料庫定義；
• 兩百餘張資料表。

技術上只有三個依賴：版本控管、雲端託管與受管資料庫。各項功能以外部語言模型的介面完成。

4.2 參與者與角色

個案只有一位人類參與開發。

負責人不寫程式，是領域知識的提供者，同時兼任產品經理與驗收者。這個條件很關鍵：系統的正確性無法靠他「看程式」來保證。

4.3 期間劃分

本文把開發分成三段，以「治理重整」為分界：

1. 快速迭代期（約四週）：負責人口述、建置者當場實作，只有一份按時間堆疊的口述紀錄，沒有需求或設計文件。本文對這一段做回溯分析。
2. 治理重整（約一天半）：負責人要求「要有版本管理、分析設計驗收都要有文件」之後，建立規範、基準文件與機器關卡。
3. 第一次完整演練：重整後第一個從口語提出、走完全部八步的變更。

判準的形成時間序照實寫：立場文件在快速迭代期第二天就定稿，但只約束 AI 對來訪者的行為；它延伸為工程規格是在治理重整時。本文以三項判準重新讀快速迭代期，是事後的分析，不是當時的設計。

4.4 資料來源

• 版本紀錄：主線的完整提交歷史，包括日期、訊息與改動檔案。
• 口述紀錄：快速迭代期唯一的設計紀錄。它是一份長達數十萬字的專案說明檔，按時間記下負責人的每一個決定。
• 治理文件：
  • 開發憲章與經營原則；
  • 十二根柱子的需求、設計、測試說明書；
  • 變更單及其審查意見。
• 營運紀錄：
  • 問題中心的收件；
  • 事故報告；
  • 花費帳（以帳戶層級彙總）。

所有資料都是開發與營運過程的副產品，不是為本研究另外收集的。

4.5 分析程序

RQ1 以表 3-2 的指標為編碼架構，把快速迭代期的事故、修正類提交與重整時發現的問題歸入三項判準。一件事可同時歸入多項。RQ2 以描述為主，交代制度的每一層、它解決什麼，以及它對應哪一項判準。RQ3 以第一次演練的變更單為資料，記錄每一步的產出、時間與審查意見。

編碼由建置者完成、負責人複核，尚未有外部編碼者。這是本文最主要的限制之一，見第七節。

4.6 資安揭露與個資

本文的揭露原則是：過程可以公開，但只揭露「類別、成因與教訓」。

• 不寫任何介面路徑、函式、資料表、欄位、金鑰與標頭的名稱；
• 不寫門檻數字、排程時刻與實作細節；
• 不提尚未處理完畢的項目。

判準只有一個：一位懂技術的人讀完一段，能不能直接對這個網站做什麼。能，就拿掉或抽象化。

本文不使用任何來訪者的內容。文中的兩幅圖是示意圖，不含真實來訪者的資料，也不含管理介面。

4.7 AI 參與範圍聲明

• 建置者撰寫了系統的全部程式，以及治理文件的初稿。
• 本文由 Anthropic 的 Claude 起草；Claude 也就是本文所稱的建置者。負責人審定。
• 本文的大綱曾經兩家模型審閱；收入德原書院之前，全文再經另一個獨立的 AI 會話以攻擊者的角度檢查資安揭露，並核對事實與用語。採納的意見已反映在本文的定位與用語上，例如「異質模型輔助審查」、判準的時間序與成本對照的寫法。

五、結果

5.1 RQ1：快速迭代期的失效模式

快速迭代期的速度來自「負責人說、建置者當場改」，中間沒有任何文件。這一期的演進大致分為四個階段：

1. 先建立知識資料庫與問答；
2. 再建三殿道場、光明燈與線上法會；
3. 接著是每日內容、六種語言、教室與生成式代理人；
4. 最後是自主改善、問題中心與對外發文。

幾乎每天都有新功能上線。本節依三項判準，整理這一期留下的可觀察跡象。

表 5-1　快速迭代期的失效模式

以提交訊息含「修正、修好、錯誤、事故」等字眼判斷，修正類的提交約佔全部的 5～6%，比例隨所用字眼而定。這會漏算沒有寫明的修正，只當下限。

資安缺陷的類別與共同成因。重整期找到的資安缺陷屬於四個大類：存取控制缺陷、功能下線不完整、成本控管缺口、內容提前外露。它們有三個共同成因：

1. 關了畫面，沒關入口。功能收起時，只拿掉前台的按鈕，後端的入口與排程還在。快速迭代期常有「做了又收起」的功能，這個模式因此一再重複。這些入口已逐一收回，並以自動檢查防止退回。
2. 「只有我會呼叫」的假設。建置者給自己用的路，就沒有設門。這些路後來都補上了身分檢查。
3. 沒有人從攻擊者的角度看過一遍。沒有文件，就沒有「應該」可以對照。

重整後的審查是「照著文件去實測」，這些缺陷才被發現。就現有紀錄，沒有證據顯示它們曾被利用；但重整之前也沒有足夠的紀錄可以排除。

對 RQ1 的回答。以第三節的分級來說：

• 快速迭代期的第一項（有所本）與第二項（可定位）的缺席已經成立。
• 第三項（可修正）部分成立：負責人仍能在對話中叫停，但只能在事後，且只能對看得到的畫面叫停。

三類失效也互相加乘：沒有「應該」的文件（有所本缺席），審查就無從對照；審查缺席，缺陷就只能在上線後等人碰到（可修正缺席）。

5.2 RQ2：四層制度

重整後實際在運作的制度有四層，由上而下：

1. 規範：只有負責人能改；
2. 文件：系統的正式定義；
3. 流程：每一次修改都要走；
4. 機器關卡：不靠任何人自律。

四層的關係是：

• 規範決定文件要寫什麼；
• 文件決定一次修改「應該長什麼樣」；
• 流程保證先改文件再改程式；
• 機器關卡保證：即使前三層有人忘了、省了，程式仍然進不了正式版。

上三層靠人與 AI 照做，最底層不靠任何一方：就算有人忘了開單或省了審查，程式仍然進不了主線。

一、規範層

規範層有四份文件。

開發憲章第一條：「文件先於程式，測試標準先於施工。本憲章其餘條文，皆為守住此條而設。」第四條：「規範不靠記憶。」負責人不需要記得流程：由建置者主動攔截，由機器關卡強制執行。

二、文件層

柱子地圖把全站分成三層，是每一張變更單做影響分析的依據。

「實」層的名稱取自本站的「權與實」原則：介面、語言與入口可以千變（權），經文、AI 的界線與危機轉介一字不移（實）。領域規範就是這樣變成工程規格的：它們被放在地基，因此改一個字都要走最重的流程。它們也被寫成自動檢查，例如：

• 經文引句由程式逐字核對；
• 禁語由程式掃描；
• 危機回應是固定文字，不經模型生成。

三文書是系統的正式定義：每根柱子各有一份需求說明書（要做什麼）、設計說明書（怎麼做）、測試說明書（怎樣算做對）。十二根共三十六份，加上柱子地圖與憲章。需求書每一條三五行，含目的、規則與來源；測試書為每一條需求寫驗收案例，對應到自動測試或人工驗收。程式、文件、測試與資料庫結構放在同一個版本庫，在同一個版本下一起凍結。

這批文件的形成方式必須照實寫：它們是「依現有程式回推」的基準。做法是：

1. 先畫柱子地圖；
2. 再逐根對照程式，寫出「現在做什麼」；
3. 對照時發現的問題，不在寫文件時順手改，一律開變更單。

基準之後的修改，才是「文件先於程式」。

三、流程層

負責人只用口語。建置者先把他說的話分類，再決定怎麼處理：

修改指令的溝通以四次為原則：

1. 受理回報：建置者轉述，負責人糾正誤解；
2. 影響報告與變更單：負責人說「可以」，或指出要改的地方；
3. 審查結果：只有分歧時才需要裁決；
4. 完工報告：負責人說「上線」。

一句話包含多件事時，拆成多張單。流程中途出現的新想法，記為下一張，不混入進行中的單。

變更分為五級，級別決定要走多重：

審查依審的東西分工。記錄「現在做什麼」的需求書與測試書，由能打開程式核對的另一個 AI 獨立會話審，因為這類錯誤要對照程式才抓得到。B、C、D 級的變更單，則由兩個不同廠商的模型各自審。規則如下：

• 兩家都同意才定稿，分歧由負責人裁決；
• 審查只問「有沒有矛盾、漏掉的失敗情況、影響範圍是否完整」；
• 不請它建議新功能。

這個限制是為了防止審查變成另一個設計來源。

四、機器關卡與三層保險

測試分四層：

兩條規則不可繞過：

• 修任何錯誤，都要先補一個能重現它的測試，讓錯誤不再回來；
• 施工中不得為了讓程式通過而放寬或刪除測試。測試的修改也要寫在變更單裡定稿。

規範的執行，不靠任何一方的自律。它由三層保險保證：

機器關卡分三步建立，在重整期內全部生效：

1. 每次推送都自動跑上線前檢查；
2. 主線只收檢查通過的提交，管理員也一樣，不可強推；
3. 資料庫結構只能以版本庫裡的結構檔變更，並定期從零重建，與正式環境比對。

營運期另有兩項關卡：

• 花費只有一本帳，每一條會花錢的路都登記每日上限；
• 異常自動送入問題中心，由值班追查。

具體門檻與節奏不公開。

五、營運層與開發層的介面

網站內的 AI 觀音志工負責營運，但不能直接改程式。它和開發層之間只有三條管道：

• 改善建議：志工提出、負責人核准後，涉及程式的一律轉為變更單，走同一套流程。
• 白名單內的設定（E 級）：只能在已登記的項目與上下限內自動調整，每次留紀錄。
• 異常回報：例行巡檢與問題中心發現的問題，需要改程式的轉成 B 級變更單。

這條界線讓「可定位」在兩種 AI 之間也成立：營運的 AI 改不到程式，建置的 AI 不代替營運。

六、重整期的變更單

重整期至今共開了二十八張變更單，依性質分類如下：

「柱子對照後的修正」佔了一半以上。這正是快速迭代期「沒有應該的樣子」留下的缺口；寫文件的過程本身，就把它們找了出來。

對 RQ2 的回答是：四層制度各自對應一項判準，而且每一層都有一個「不靠記憶」的執行方式。

• 文件層與測試先行補上「有所本」；
• 角色、話語分類與變更單補上「可定位」；
• 兩家審查、不分人的關卡、花費上限與問題中心，把「可修正」從事後移到事前。

5.3 RQ2：概念溝通與雙軌

「文件先於程式」引出一個必然的問題。有些東西寫不清楚，要看到才知道對不對，例如流程、畫面、一句話的語氣。這些東西要怎麼進入文件？本個案的做法不是瀑布，而是雙軌：

• 探索軌討論「要什麼」。負責人用一句話或一張手機截圖說出想法，建置者直接做出看得到的原型（設計稿或預覽版）。負責人在真的手機與電腦上看，不對就再做一版。這條軌可以丟棄，不設關卡。
• 交付軌保證「做對了」。負責人「定案」那一刻，結果才寫進需求書與設計書，進入驗收標準、兩家審查、施工、測試與驗收，不可跳步。

兩軌對判準的要求不同。探索軌只要「可定位」：知道是誰、哪一版、為何做的。它本來就是用來被修正的。交付軌則三項都要。

回頭看 5.1，快速迭代期的問題不在於太快，也不在於探索太多。問題在於沒有定案門：探索軌的產物直接當成交付軌的產物上線。原型變成了正式版，沒有人寫下「定案的是什麼」。

第 4 步把驗收標準寫在施工之前；測試不合格時回到第 6 步改程式，不是回頭放寬標準。第 8 步只有負責人能做。

表 5-2　各種開發模式怎麼處理「概念溝通」

定案之後要寫成什麼，依概念的種類而不同。

表 5-3　各類概念怎麼從探索軌進入文件

表 5-2 最後一列，是本文在軟體工程上的主要觀察。它有兩面：

• AI 把原型的成本降到幾乎為零，所以「做出來看」比「寫清楚」便宜；
• 但 AI 也沒有跨對話的可靠記憶，所以定案之後的文件，比傳統團隊更重要。

敏捷開發把「團隊的共同記憶」當成文件的替代品。一位負責人加一個每次重新開始的 AI，沒有這種共同記憶可以依靠。這也是「依法不依人」在工程上最實際的理由——不依任何一方的記憶。

5.4 RQ3：第一次完整演練與代價

重整本身的代價。從負責人要求重整，到規範、三十六份基準文件與機器關卡就位、二十八張變更單開立，約用了一天半。這段時間裡負責人做的事幾乎只有兩種：定原則，以及在兩家審查不一致時裁決。他的回覆到後來多半只是「好」，因為每一步停下來時，文件已經把要決定的事寫清楚了。外部模型的審查花費只有數美元。

第一次完整演練。重整完成當晚，負責人用一句話提出：「手機上觀易被按鈕遮住。」這句話走完了八步。

表 5-4　第一次完整演練

從一句話到文件與審查完成，用了十二分鐘。審查花費在一美元以下。照測試書量測，也把這張單範圍以外的另一處遮擋找了出來；它另開一張變更單，而不是放寬這一張的標準。

演練的關鍵不在速度，而在第 5 步。兩家審查在開工之前，都抓到了同一個設計錯誤：殿堂畫面會依螢幕大小等比放大，照原設計寫死的留白會被再乘一次。如果先寫程式，這個錯要等負責人拿平板或大螢幕才會看到。在重整前的做法裡，它很可能會是下一個「修正類提交」。

兩家審查的拉鋸。兩家審查會互補，也會拉鋸。預算制的變更單審了四輪：一家從第二輪起即同意或修改後同意，另一家到第四輪仍不同意。最後兩點由負責人裁決，列入變更單的「已知限制」。這是憲章設計好的出口，不是故障：分歧的終點是人，不是第三個模型。

對 RQ3 的回答。在這套制度裡，「以 AI 審 AI」承擔了可修正的前半段：它把缺陷的發現從上線後移到施工前，而且成本極低。這種審查有兩個限制：

• 要有文件可對照才有效。重整期的資安缺陷，都是在審查者「照著文件去實測」時才發現的；快速迭代期即使有審查，也沒有「應該」可以對照。審查的有效性，因此依賴於「有所本」先成立。憲章 1.1 版也因此把「記錄現狀的文件」交給能打開程式核對的審查者。
• 審查者可能共享盲點。兩家都抓到同一個錯，是交叉佐證；但兩家都漏掉的錯，在本個案的資料裡看不到。沒有人類專家審查的對照，就算不出召回率。

因此，可修正的後半段（問責與最後的判斷）必須留在人身上。

5.5 生命週期五階段對照

表 5-5　重整前後的生命週期

六、討論

6.1 沒有團隊記憶時，文件就是記憶

傳統軟體工程裡，文件常被看成團隊記憶的備份。不寫也還有人記得，所以敏捷開發可以「重視可運作的軟體勝過詳盡的文件」。本個案的條件把這個關係反了過來：

• 建置者每次對話都重新開始。上下文一換，它能依靠的只剩下文件。
• 負責人記得自己要什麼，但記不得三週前的哪一句話被寫進了哪一個檔案。

在這個條件下，文件不是記憶的備份，而是記憶本身。快速迭代期其實也有一份「記憶」：那份數十萬字的口述檔。但它是按時間堆疊的，不是按系統結構組織的；新的決定加在後面，舊的決定不會被標為作廢。每一次對話都要重讀、重猜哪一句仍然有效。柱子地圖與三文書做的事，是把「按時間」的記憶改成「按結構」的記憶：每一個問題都有一個固定的地方可以查，而且只有一個版本是現行的。

6.2 以 AI 審 AI 的界限

本個案的審查設計有三個選擇，各自對應 2.5 節的一種偏誤：

• 審查者不是寫程式的那個對話，以減少「偏好自己的生成」；
• 至少一家來自不同廠商，以減少共享的訓練偏差；
• 審查只問「矛盾、漏掉的失敗、影響範圍」，不問「寫得好不好」，以減少對長篇與流暢文字的偏好。

但這三個選擇都只是減少偏誤，不是消除偏誤。本文因此把它稱為「異質模型輔助審查」：它是低成本的缺陷發現機制，不是問責機制。

從受造中介的角度，這個區分是必要的。如果兩個模型都同意就算「對」，那麼「最後被訴請的話語」只是從一個模型移到了兩個模型。憲章把分歧的終點設在負責人、把驗收定為只有負責人能做，就是為了不讓審查本身成為新的終局。

6.3 成本：敏感度分析

讀者一定會問：同樣的系統若由真人團隊建置，要花多少？這個問題沒有單一答案，原因有三：

• 兩者的品質不同等。真人團隊有專職的資安與測試，本個案在快速迭代期則出過資安缺口。
• 負責人的時間怎麼計價，決定了結果的量級。
• 有些部分沒有真人替代的版本，例如生成式代理人的「修學」本身就是 AI 研究。

本文因此不做單一對比，只給一個敏感度分析。數字分「實」與「估」：「實」來自模型廠商的實際帳單；「估」寫明算法，以 1 美元約新台幣 32 元換算。網站自己的花費帳只記到實際帳單的約四分之一，其餘是從未記帳的呼叫——這本身就是 5.1「花費沒有上限」的一部分。

表 6-1　建置成本的敏感度分析（新台幣）

時間上的差異不在表內：本個案約一個月，真人團隊的估算是一年以上。表內的數字也不應讀成「便宜了多少倍」，它們能支持的結論只有兩個。

第一，不論負責人怎麼計價（A 到 C），AI 建置的金錢成本都遠低於真人團隊：負責人時間不計價時差將近三個數量級，連負責人的三個角色都以全職計價時，仍差數十倍以上。差距大到即使計入品質的不對等，方向也不會反轉。但這個差距不是白得的，它把風險換了位置：真人團隊裡由專職資安與測試擔的風險，在本個案由文件、審查與關卡擔。第五節所述，就是這些風險在沒有人擔的時候會發生什麼。

第二，AI 建置的主要成本不是預期的那一筆。本個案最大的單一花費來源不是系統功能本身，而是「沒有上限」。快速迭代期若一開始就有預算制，反事實估算可少花大半的 AI 花費。但這個估算必須附上一個打折：超支也買到了「試過才知道」的知識。較準確的說法是，預算制不阻止試驗，只讓試驗在一個已知的金額內發生。

重整後每一次修改的額外成本，是十幾分鐘的文件與審查，以及不到一美元的審查費（5.4 節）。這是一次演練的觀察，不是平均值。

6.4 領域規範變成可檢查的規格

宗教場域的規範通常被看成「軟」的——靠人的判斷，很難寫成規則。本個案的經驗是，其中有一部分可以很「硬」：

不能變硬的部分，例如「這句話的語氣是否溫和」，就走「建置者提案、負責人逐字定稿」的路（表 5-3）。這個分界本身就是設計：能變硬的交給機器，不能變硬的交給人，不讓模型來判斷這兩者之間的事。

6.5 可推廣性

本個案有一個不易複製的前提：負責人一人兼任產品經理、領域專家與驗收者。在其他場合，這三個角色可能分屬不同的人。下列這些做法，與宗教場域無關，可以直接帶走：

• 柱子地圖與三文書的結構；
• 話語分類與五級變更；
• 「測試不可放寬」與「修錯先補測試」兩條規則；
• 主線保護與資料庫重建比對；
• 花費一本帳。

對一個新專案，本個案的含意是順序。機器關卡在空專案時就應放好；本個案是在系統已經長大之後才補上。個資或醫療建議的錯誤代價更高的領域，例如健康服務，更需要這個順序。

若要多人共同經營，最大的風險是「兩個人對同一個地方各說各的」。可能的做法是：

• 以柱子分人；
• 以變更單為唯一入口；
• 同一根柱子一次只開一張重大變更；
• 關卡對每個人都一樣。

這一點本個案尚未實作。

七、效度威脅與限制

本節依 Runeson 與 Höst（2009）的四類效度逐一交代，最後說明研究者的位置。

建構效度。三項判準來自哲學論證，轉成工程指標時有兩個風險。

• 指標可能只量到措施本身。例如「有變更單」不等於「可定位」。本文因此只用缺席的跡象（表 3-2）來描述快速迭代期，不用措施的存在來證明改善。
• 「修正類提交」是以提交訊息的字眼判斷的，會漏算，也可能誤算。

內部效度。重整前後的差異，本文不做因果主張，原因有三：

• 重整與系統的成熟同時發生。後期的修改較少，可能只是因為功能已經做完；
• 經營原則「現階段少做」本身就會降低變更量；
• 重整後只有一次完整演練，不足以推論平均的成本與效果。

外部效度。這是單一個案，有三個特殊條件：

• 場域是宗教道場，不收費；
• 負責人一人兼任三個角色；
• 建置者是特定時間點的特定模型。

模型的能力與記憶機制變化很快。「沒有跨對話的可靠記憶」這個前提若改變，文件的角色也可能跟著變。本文的主張是分析性的推廣：它推廣到「缺少團隊共同記憶、實作者與審查者可能同源」的形態，不是統計性的推廣。

可靠性。編碼由建置者完成、負責人複核，沒有外部編碼者，也沒有一致性指標。快速迭代期的花費以模型廠商的實際帳單為準；網站自己的帳只記到約四分之一，無法逐項對應到功能。建置者本身的使用費屬訂閱制，沒有逐筆帳。

基準文件的時間序。三十六份基準文件是重整時依現有程式回推的，不是「文件先於程式」的產物。本文的「文件先於程式」，只適用於重整後的修改。

研究者的位置。研究者即參與者：

• 本文的初稿由建置者撰寫，而建置者正是被研究的角色之一；
• 負責人既是制度的設計者，也是結果的審定者。

這可能產生「把自己的制度寫得太好」的偏誤；建置者寫自己，也正是 2.5 節「偏好自己的生成」的情形。本文採取了兩個緩解：

• 大綱經兩家模型審閱，全文經另一個獨立的 AI 會話以攻擊者的角度審閱；
• 失效模式與缺陷一律以紀錄中的事件為據，不以回憶為據。

這些緩解都不能取代外部研究者。

後續研究的設計。上述限制可以由後續研究處理，建議做法如下：

1. 預先登記一段觀察期：至少六十天、至少二十張變更單，涵蓋各級；重整的那一天半列為過渡期，不計入任一期。
2. 以獨立於措施的指標比較兩期，例如：
   • 上線後「做的和要的不一樣」的問題數；
   • 上線缺陷能追到決定的比例；
   • 變更失敗率、回滾次數與七日內復發數。
3. 事先寫明否證條件：三項判準中至少兩項的指標觀察期優於回溯期，才算支持。
4. 抽樣變更單，請人類專家獨立審查，與兩家 AI 審查、上線後實際缺陷三方對照，算出召回率。
5. 邀一位外部研究者抽樣獨立編碼，報告一致性。

八、結論

一位不寫程式的負責人加一個 AI 建置者，可以在約一個月內建出一個完整的系統。但如果沒有寫下來的「應該」，這個系統就無法被驗收、無法被預測，也無法被守住。

回答研究問題：

• RQ1：快速迭代期的失效，可歸為三類。一是「應該是什麼樣子」只存在程式裡；二是修改追不到決定、狀態無法重建；三是資安與花費的缺口只能事後發現。它們分別對應有所本、可定位與可修正的缺席。三者互相加乘：沒有文件，審查就無從對照。
• RQ2：補上缺口的是四層制度——規範、文件、流程、機器關卡。每一層都不靠任何一方的記憶。寫不清楚的概念走雙軌：在探索軌自由試做，定案之後才寫進文件、進入交付軌。
• RQ3：第一次完整演練，從一句話到文件與兩家審查完成不到一刻鐘，審查在開工前就抓到一個設計錯誤。「以 AI 審 AI」能承擔可修正的前半段：它把缺陷的發現提前、成本極低，但前提是有文件可對照。問責與最後的判斷，必須留在人身上。

對實務的建議，對象是以「一個人＋一個 AI」開發的人：

1. 在第一行程式之前，先放好機器關卡：主線保護、自動檢查、資料庫可重建、花費上限。這些沒有一項需要懂程式的人來守。
2. 讓「做出來看」保持便宜，但在「定案」那一刻把結果寫進文件。原型不等於正式版。
3. 修任何錯誤先補測試；不為了讓程式通過而放寬測試。
4. 審查者不要是寫程式的那個對話；最好有一家來自不同廠商。分歧的終點設在人，不設在第三個模型。
5. 功能收起時，前後端與排程要一起收。

「依法不依人」在本文不是一個宗教口號，而是一個工程判斷。當實作者每次都會忘記、而負責人看不到程式時，系統的正確性只能依靠寫下來、有版本、對每個人都一樣的東西。AI 是指，不是月。對來訪者如此，對它自己寫的程式也如此。

參考文獻

• Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. METR. arXiv:2507.09089. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• Boehm, B. W. (1988). A spiral model of software development and enhancement. *Computer*, 21(5), 61–72.
• Delimarsky, D. (2025, September 15). Diving into spec-driven development with GitHub Spec Kit. Microsoft for Developers. https://developer.microsoft.com/blog/spec-driven-development-spec-kit/
• Gotel, O., & Finkelstein, A. (1994). An analysis of the requirements traceability problem. In *Proceedings of the First International Conference on Requirements Engineering* (pp. 94–101). IEEE Computer Society Press.
• Panickssery, A., Bowman, S. R., & Feng, S. (2024). LLM evaluators recognize and favor their own generations. In *Advances in Neural Information Processing Systems 37*. arXiv:2404.13076.
• Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot. arXiv:2302.06590.
• Royce, W. W. (1970). Managing the development of large software systems. In *Proceedings of IEEE WESCON* (pp. 1–9).
• Runeson, P., & Höst, M. (2009). Guidelines for conducting and reporting case study research in software engineering. *Empirical Software Engineering*, 14(2), 131–164.
• Sy, D. (2007). Adapting usability investigations for agile user-centered design. *Journal of Usability Studies*, 2(3), 112–132.
• Zheng, L., Chiang, W.-L., Sheng, Y., et al. (2023). Judging LLM-as-a-judge with MT-Bench and Chatbot Arena. In *Advances in Neural Information Processing Systems 36, Datasets and Benchmarks Track*. arXiv:2306.05685.
• *AI as a Created Mediator: Generativity, Grounding, and the Idolatry of the Interface*（未刊稿）。
• 般剌蜜帝譯。《大佛頂如來密因修證了義諸菩薩萬行首楞嚴經》卷二。CBETA T19n0945, p. 111a09–a11。
• 曇無讖譯。《大般涅槃經》卷六。CBETA T12n0374, p. 401b28–b29。

本站文獻：德原書院 DYSY-0002〈照見〉、DYSY-0004〈從生成式代理人到數位同修〉、DYSY-0006〈德原觀音堂設計理念與運作實務〉、DYSY-0008〈由智生悲〉、DYSY-0011〈中介者的自我要求〉；「AI 道場」頁的網站地圖。