介紹 Tenex 的公民開發者 SDLC，這是一個六階段生命週期，能將非技術員工使用 AI 打造的內容，從個人原型轉化為整個公司都能信賴的正式生產環境。
作者：Alex Lieberman（[@businessbarista](https://x.com/@businessbarista)）、Arman Hezarkhani（[@ArmanHezarkhani](https://x.com/@ArmanHezarkhani)）、Suchi Patel 與 Ashwin Kadaru（[@AshwinKadaru](https://x.com/@AshwinKadaru)）
一個 Tenex.co 的框架。
重點摘要
公民 SDLC 是一個六階段生命週期（構想、前門、分流、佈建、建置、執行與變更），能將非技術員工使用 AI 打造的軟體，從個人原型轉化為受控管的正式生產環境。每個階段都遵循同一項原則：AI 負責勞動，確定性程式碼設定護欄，而人類負責處理例外狀況。之所以需要這個框架，是因為 AI 已將撰寫程式碼的成本壓低到近乎為零，並將瓶頸推向後端，也就是確保所建置的內容是健全的，並在軟體上線後，管理好持續增長的一套應用程式。
我們有一位客戶是一家投資公司。該公司投資組合營運團隊的一名成員，從未寫過任何程式碼，卻打造了她的團隊現在每天使用的儀表板。這個儀表板用來追蹤數十家被投資公司的價值創造工作。她是透過提示 Claude，反覆迭代約兩個月才完成的。每一行程式碼都由 AI 撰寫。
而且它很棒。檢視畫面正確，工作流程符合團隊實際運作方式，採用率也立即上升。她在任何工程師介入之前，就已經勾勒出正確的產品。
這不是運氣。數十年來，了解業務問題的人，幾乎從不是能夠打造軟體來解決問題的人。要縮小這個差距，需要耗費極大的心力：產品經理將她的問題轉化為規格，工程師將規格轉化為程式碼，然後還得排隊等待開發路線圖上的其他項目。從構想到工具，需要耗費數月時間，而最終交付的成果，也是別人對她意圖的詮釋。
這個差距現在已經消失了。打造能力已經轉移到那些真正了解流程、知道數據含義、並且每天實際參與工作流程的人身上。她一次就打造出正確的東西，因為她就是源頭。沒有人站在中間替她翻譯，也沒有人會稍微搞錯。這就是公民開發的承諾，而她實現了這個承諾。
然後我們檢視了內部結構。
整個應用程式就是一個 HTML 檔案。540 KB。大約 5,300 行。主資料集以 80 KB 的資料塊形式，塞在單一行內。當檔案需要更新時，AI 會附加修補函式，每次應用程式載入時就重寫數值。要儲存工作，就意味著應用程式會重寫自己的 HTML，下載到你的筆電，然後你以新版本的形式重新上傳到共享磁碟機。如果兩個人同時編輯，最後儲存的人獲勝，另一個人的編輯就會消失。
有一天，一個儲存函式在檔案中尋找某個標記，但沒找到，於是它還是將現有內容寫回去。整個 540 KB 的應用程式被截斷成 7 個位元組。在一次無聲無息的寫入中，她團隊每天依賴的儀表板就此消失，而當初建置它的方式，完全沒有任何機制能捕捉、阻止或還原這個錯誤。
大多數領導者聽到這個故事後，會認為公民開發是個應該被關閉的負債。我們認為這是錯誤的教訓，而那些據此行動的公司將會失敗。正確的教訓是：她出色地完成了自己的工作。只是沒有人為這套軟體鋪好通往正式生產環境的道路。
瓶頸轉移了
數十年來，建置軟體是成本最高的部分。它既緩慢又稀缺且昂貴，整個軟體開發生命週期都是為了保護它而發展出來的。規格、票證、衝刺、程式碼審查：傳統 SDLC 中的每一項儀式，都是因為撰寫程式碼是瓶頸而存在。
AI 將這個階段壓縮到近乎為零，於是瓶頸轉移了。當任何人都可以在一個下午建置出一個可運作的應用程式時，昂貴的工作不再是建置本身。而是之後的事情：確保所建置的內容是健全且安全的，並在應用程式上線後，管理好持續增長的一套應用程式。
GIF
而且建置速度並沒有放緩，這帶來了兩個需要解決的問題：
第一，內在品質。 非工程師從空白頁面開始提示一個 Agent，最終會收斂成今天能運作、但永遠無法維護的拼湊軟體。那個 540 KB 的檔案並非特例；它是沒有軌道限制下進行建置的預設產出。
第二，擴散問題。 每個團隊都想要自己的應用程式，而沒有任何中央 IT 團隊能夠手動建置並營運數十個應用程式。如果沒有護欄，每個應用程式都會根據建置者或模型所選擇的技術堆疊來建置：不同的資料庫、不同的驗證方案、秘密憑證隨處丟放。反之，如果封鎖這些請求，他們也不會停止，只是轉為地下化。無論哪種方式，你繼承的不僅是一套應用程式，還有它們底下的基礎設施亂象，而 IT 部門無法合理地保護、支援或解釋這些東西。
因此，每家企業即將面臨的真正問題是：如何讓非技術員工交付真正的內部軟體，卻又不會繼承那套應用程式亂象？
三個預設答案都行不通：
1) 封鎖它。 請求排隊，耐心耗盡，影子應用程式終究會被建置出來。現在你完全看不到它們。你無法管理你看不到的內容。
2) 放任不管。 讓非工程師在沒有結構的情況下使用 AI 工具，並慶祝他們展示的成果。這就是你得到 540 KB 檔案的方式。而且你事後也無法透過審查來解決問題。當一個龐大檔案出現在程式碼審查中時，它已經是個龐大檔案了。必須從起點就加以預防。
3) 審查所有內容。 對每個變更都加上人為核准。你的 IT 團隊規模精簡，但建置量卻爆炸性成長，現在每個部署都得等待審查者的行事曆。審查要不是扼殺採用率，就是變成橡皮圖章。兩種結果都違背了目的。
因此，答案不是另一份政策文件，而是一個生命週期：一個真正的 SDLC，專為那些永遠不會稱自己為開發者的人設計，並將護欄內建於平台之中，而非寫在備忘錄裡。一條道路，能將建置內容從最初的平實語言構想，一路引導到受控管的正式生產環境，且從不要求建置者成為工程師。人員提供意圖，平台提供紀律。
每個階段都遵循同一項原則：AI 負責勞動，確定性程式碼設定護欄，而人類負責處理例外狀況。 AI 負責起草、分類和撰寫。程式碼決定什麼是允許的。只有在真正需要判斷力的地方，才會投入人力。記住這個分工，這是讓整個系統能規模化的關鍵。
我們稱之為公民 SDLC。六個階段，每個階段都受控管。
第一階段
構想
人員在 AI 的協助下，用平實的語言描述應用程式：它的功能、使用者、會接觸哪些數據、由誰擁有。只需幾分鐘，讀起來就像一份備忘錄。它同時也是後續所有流程的簡報。這是營運模式的第一步：AI 負責將雜亂的敘述轉化為結構化的文件。
實際運作情況如下。基金財務部門的某人輸入：「我想要一個追蹤資本催繳通知的工具。目前它是一個我手動更新並每週五用電子郵件寄出的試算表。」AI 會問一個受理分析師會問的問題：還有誰需要看到它？基金財務與投資人關係部門的十二個人。數據目前住在哪裡？Box 裡的一個試算表，唯讀即可。當你不在時誰擁有它？她的主管。雜亂的敘述變成了一份簡報：目的、使用者、數據來源、存取層級、擁有者，甚至對應用程式形態的初步猜測。一份 PRD，實際上，由一個從未聽過 PRD 這個詞的人所撰寫。
GIF
目前什麼都還不存在。沒有程式碼，沒有存取權限，沒有基礎設施。這是刻意為之：公司在應用程式存在之前就先形成對它的意見，而不是在它已經承擔負載六個月之後。
第二階段
前門
每個請求都通過一個結構化的單一前門，而提交請求的同一動作會直接將其送入分流階段。那份簡報就是請求、IT 看到的票證、永久記錄，以及所有人都能搜尋的目錄中的一個條目，全部一次完成。沒有走廊上的請託，沒有私下拜託，沒有影子管道。你無法管理你看不到的內容，也無法分享你找不到的內容。前門從第一天起就讓這兩件事成為可能。
這個階段消滅了影子管道。一個跳過前門的建置，仍然可以作為原型存在於筆電上，但它也只能停留在那裡。任何能將原型轉化為團隊可以信賴的軟體的東西，都存在於這個階段之後：真實的儲存空間、公司登入、部署管道、實際運行的場所。這些東西都不會流向一個從未通過前門的建置。你可以繞過前門；但如果你這麼做，就永遠無法超越原型階段。
第三階段
分流
AI 沿著兩個軸向對請求進行分類。形態： 這是哪種應用程式？對員工實際建置的內容進行反向審計，幾乎總是會歸結到一個簡短的清單：文件產生器、工作流程自動化、CRUD 應用程式和互動式儀表板。命名形態會告訴你它所需的架構，並將鋪好的道路交給下一個階段來蓋章。影響範圍： 這個建置如果出錯，可能造成多大的損害？我們從四個維度來評分：
- 範圍與能力： 它能接觸到什麼，它能寫入還是只能讀取？
- 可逆性與自主性： 是否有有人為介入，而且這個動作可以復原嗎？
- 暴露程度： 誰能看到輸出，它在公司外部傳播多遠？
- 數據敏感性： 它互動的數據有多機密？
但讓這個機制值得信賴的規則是：AI 提供建議。程式碼做決定。 模型讀取簡報並進行分類；然後 IT 撰寫的政策程式碼會檢查每個分類是否符合規則。看看它在資本催繳通知追蹤器上如何運作。形態：互動式儀表板。影響範圍：內部基金數據，十二個內部使用者，唯讀，有人為介入，與現有應用程式無重疊。每個維度都落在核准門檻內，因此核准，沒有人為此爭論。
現在改變一個事實。假設這個追蹤器還需要 LP 出資承諾數據。簡報再怎麼有說服力都沒用；這一個變更就會讓數據敏感性維度超過 IT 設定的門檻，於是請求就會轉給人處理。中間沒有任何判斷發生。規則要不是符合，就是不符合。
三條出路：
- 核准。 影響範圍在所有門檻內，簡報完整，信心度高。在我們客戶那裡，大約有十分之九的請求以此方式自動解決。
- 重複使用。 它與已存在的應用程式重疊，因此請求者會被導向該應用程式的擁有者，而不是建置重複的東西。重複的應用程式會被合併，而非倍增。
- 升級。 某個維度超過其門檻，或信心度低。IT 與安全部門的人員會收到完整的請求作為背景資訊。
GIF
那第十個請求，也就是特例，仍然會帶著完整的簡報出現在人員的桌上。其他九個則從不需要。
第四階段
佈建
這裡是讓 IT 能夠大規模說「好」的關鍵：佈建不是 IT 失去對交付內容的控制，而是 IT 的控制向前端移動。IT 不再事後審查每個應用程式，而是預先鋪好一次道路，每個應用程式都在這條路上誕生。一個人核准，平台就會根據應用程式的形態，從道路中蓋印出應用程式：一個儲存庫、公司登入、一個部署身份、一個私有環境，以及它自己的資料庫，全部以 IT 擁有並進行版本控制的基礎設施即程式碼來定義。幾分鐘內即可佈建完成。
這是唯一一個需要高權限運行的時刻，而且有人為介入。每個應用程式從誕生起就是隔離、受控管且可稽核的：各自封閉的環境，沒有公開位址，沒有儲存的雲端秘密，從第零天起就有只能附加的稽核軌跡。安全工作在道路中一次完成。沒有應用程式需要重複它。
因為道路是根據形態來撰寫的，所以人為核准是預設姿態，而非永久性的稅賦。新穎的形態和高影響範圍的建置會永久保留人為把關。但是，一旦某個形態的道路在足夠多的建置中證明了自己，該道路上低影響範圍的請求就可以自動佈建。這是將「把人類判斷力留給特例」的邏輯提前一個階段應用：早期你將更多請求導向人員，而隨著模式成立，界線會轉向自動化。
而這條道路還承載著另一項與基礎設施同等重要的事：AI 規則手冊。繼承的儲存庫會在每次會話中，為編碼 Agent 提供一組指令，其中編碼了從真實失敗中學到的反模式。不要內嵌超過 1 KB 的資料塊。不要添加在應用程式載入時重寫數據的函式。這就是如何在不需要建置者知道任何最佳實務的情況下，解決內在品質問題：道路讓 Agent 遵循這些規則。每一條規則背後都有一個疤痕與故事（你已經讀過其中一個）。
第五階段
建置
建置者在受控的雲端工作區內提示他們的編碼 Agent（例如 Claude Code、Codex 等），永遠不在自己的筆電上進行。筆電上的終端 Agent 會繼承那裡的任何東西：郵件、同步的磁碟機、瀏覽器 Cookie、快取的憑證。在工作區中，Agent 只看到專案。沒有其他東西。
工程師通常會攜帶的一切，改由軌道來承載：在我們客戶那裡，有四個層級的 35 個護欄，建置者無法關閉。
合併層包含專門為 AI 生成程式碼而設計的漂移檢查：檔案大小預算、無過大的內嵌數據、稽核日誌一致性。通過才能合併。當檢查失敗時，建置者要求 Agent 修復它，然後再次推送。
人類不審查例行變更。檢查本身就是審查。例行變更以 CI 的速度進行，而不是審查者行事曆的速度。送到人類面前的是重要的特例，由機械化方式偵測出來：破壞性的資料庫結構變更、新的依賴項、對 Agent 自身限制的變更、任何觸及基礎設施的東西。這些需要等待人類處理。其他都不需要。而當新的問題還是逃脫了，解決方案是新增一個自動化檢查，而不是增加更多人類審查。系統透過編碼教訓來變得更嚴格，而不是透過增加會議。
回想一下開頭的儀表板。其中兩個漂移檢查在第一週就會對它觸發。那個 80 KB 的單行資料塊，在它第一次提交時就會讓 CI 失敗，遠在任何失敗模式固化之前的數月。
第六階段
執行與變更
六個月後，資本催繳通知追蹤器仍在運行，而這就是生命週期展現其價值的地方。投資人關係部門的某人對三月份通知的電匯截止日期提出質疑。稽核軌跡在三十秒內給出答案：誰更改了這個欄位，什麼時候改的，以及它之前的內容，這些都與編輯本身記錄在同一個交易中。沒有人需要從電子郵件串中重建真相。當建置者轉換團隊時，所有權會轉移給指定的繼任者，而不是化為烏有。如果她完全離開公司，她的登入憑證會失效，而她曾經開啟的所有門都會同時關閉。包括那個追蹤器。下個季度的功能請求，會遵循與第一次提交相同的軌道。
控管依賴訊號，而非年度稽核。追蹤器的使用指標顯示另外兩個團隊也開始依賴它，因此它獲得升級與投資。那個自四月起就沒人打開過的貨幣儀表板，會被歸檔，而不是留在選單中任其腐朽。沒有人會懷念它。所有權在第一天就指派好，因此沒有東西會在建置者離開後變成無人認領的孤兒。隨著應用程式演進，文件會自動重新產生，因此永遠不會過時。一個未使用的應用程式是失敗，而不是獎盃。目標從來不是應用程式的數量：它是一個你團隊真正信賴的活躍目錄，而不是被遺忘軟體的墳場。
當目錄從十個應用程式成長到兩百個時，中央團隊無法再同時監控所有內容，監督責任必須向外推展到擁有這些應用程式的團隊。何時以及多大程度地聯邦化，這是一種判斷，並且會隨著目錄組合的成長而變化。此處的控管是一種你持續調整的姿態，而不是你設定一次就永不變動的控制。
維繫一切的規則
我們教導每個客戶一個觸發條件，因為它能回答 90% 的「這個需要完整流程嗎？」問題：第二位消費者規則。它之所以有效，是因為那是風險狀況改變的時刻。
某人為自己、在自己的筆電上、使用受限的數據存取權限來建置分析？影響範圍小，控管輕鬆。圖表、備忘錄和他們為自己執行的腳本，不需要部署管道。但是，一旦有第二個人想要直接使用輸出，而不是要求作者重新整理？影響範圍立刻跳升：更多接觸範圍，數據傳播更遠，其他人信任它是正確的。現在它已經是軟體了，並且有意識地、明確地升級到完整的生命週期。相同的數據來源，相同的身份，新的道路。
這一條規則就是為什麼這個流程不會讓人們淹沒的理由。大多數建置從未跨越這條線。而那些跨越的，正是完全值得這套儀式的東西。
我們坦然面對的事
沒有任何平台能讓首次建置者寫出完美的程式碼。我們不這麼聲稱。這些層級的存在，是為了讓一個錯誤只是一個小邊界內的不便，而不是整個公司的事件。每一層正好涵蓋了上一層無法處理的內容：
而稽核無法預防任何事，但它能讓每個事件變得簡短、可解釋且可歸責。這就是一個糟糕的下午和一個糟糕的季度之間的差別。
公民開發的目的不是要取代專業工程。受控管流程中的記錄系統、任何面向客戶或投資人的東西、為外部使用者建置的應用程式、任何停機時間會帶來財務懲罰的東西：這些仍然屬於工程部門，而前門在第一天就會將它們導向那裡。它取代的是瓶頸。它讓長期以來不值得正式工程專案的內部工具長尾得以民主化，並以開發路線圖佇列永遠無法提供的速度交付它們。一個沒有邊界的框架只是口號；這個框架知道它不適用於哪些地方。
實際改變的是什麼
在該投資公司，第一個通過平台的應用程式正是催生這個框架的應用程式：開頭故事中的儀表板，在軌道上重建。相同的畫面。相同的建置者。現在有了真實的儲存空間、公司登入，以及每次編輯的歷史記錄。它再也不可能將自己截斷成 7 個位元組，因為導致那個問題的程式碼類別無法合併。
大約十分之九的請求已經自動解決，而且這個比例只會持續成長。非技術建置者所做的大多數東西，本質上影響範圍都很小。內部、以讀取為主、小眾受眾的工具。隨著每個形態的道路證明自己，這些建置中有更多變得可以安全地佈建和部署，完全不需要人為介入。人類的注意力持續集中在重要的特例上，並從其他地方淡出。
今天說「好」只需要幾分鐘，而且正趨向即時，因為「不行」已經內建其中。
每家公司都即將擁有數百名建置者。大多數公司仍在決定是要對此感到害怕還是興奮。贏家不會是擁有最多建置者的公司。而是擁有最好道路的公司。
