從第一性原則出發的 AI 原生工程方法

摘要

這份文件想先釐清的事

這份文件想講清楚一件事：AI 輔助工程的關鍵，主要不在於能不能接入更強的模型，而在於 workflow 設計、架構清晰度、驗證與治理。真正能累積的收益，來自圍繞這些面向建立組織能力，而不是只靠提示詞技巧。

這對組織意味著什麼

真正的限制通常不是拿不到 LLM，而是組織能否在清楚的 workflow 與驗證邊界內有效使用它。
小型、局部任務可以保持輕量；跨時間或高風險工作則需要顯式控制、可恢復狀態與受治理的停止條件。
架構清晰度很重要，因為歧義不只會增加實作錯誤，也會讓 AI 為了安全工作而必須讀入更多 context。
驗證、審查與證據不是可有可無的額外負擔，而是讓 AI 生成工作在團隊尺度下可信的必要條件。

這需要組織支持什麼

對長任務投資 workflow 控制面，而不是把所有工作都當成直接聊天。
降低架構歧義，讓人和 AI 都能把邏輯、狀態與導航決策穩定地放在對的位置。
把驗證基礎設施、審查回路與證據留存視為真正的能力投資。
把模型路由、預算策略、備援行為與可觀測性集中到共享的模型存取邊界，而不是分散依賴每位工程師各自實作。
將反覆驗證有效的做法沉澱成可重用的內部能力，而不是依賴個人英雄式發揮。

#1 基礎第一性原則

第一性原則

在設計任何 AI workflow 之前，先釐清真正重要的模型現實

在問「該用哪個 AI 工具」之前，更該先問：底層模型有哪些事能可靠做到，又有哪些事做不到。這些限制會直接決定什麼樣的 workflow，才可能同時快速、穩定、成本可控，而且值得信任。

為什麼當代 LLM 會有這些限制。 今天主流的 LLM，大體上仍是以 Transformer 為基礎、在有限 context 視窗內做 next-token prediction 的系統。這讓它們成為非常強的語言機器，但也同時帶來幾個實務上的限制：context 更像工作集，而不是耐久記憶；長任務若沒有顯式狀態就容易漂移；看似合理的文字不等於已驗證的正確；而工具執行、恢復與驗證，仍然是周邊系統的責任。這些 workflow 結論不是風格偏好，而是當前模型運作方式的直接結果。

Next-token prediction 擅長局部連貫，不等於會穩定追蹤長期目標

現代 LLM 被訓練成能把序列延續得很好，因而非常流暢；但這不會自動帶來耐久的目標追蹤、穩定的長程規劃，或可靠的自我修正。

有限 context 更像工作集，不是記憶體

推論只會發生在當前看得見的 token 上。因此，任何需要跨時間保存的狀態，都必須被重新帶回、壓縮整理，或存放在模型之外。

工具與驗證屬於周邊系統

模型可以請求執行某個動作，但權限、參數驗證、重試、失敗處理、測試與回滾，仍然是外部執行環境與 workflow 的責任。

Token 才是模型真正看到的介面

模型不會直接讀懂意圖；它實際處理的是 token 化後的輸入，產生的是 token 化後的輸出。成本、延遲、context 壓力，以及許多優化空間，都從這個介面展開。

Context 是工作集，不是免費記憶體

Context 不是越多越好。過長的提示詞會提高首 token 延遲、成本與噪音；超過某個點之後，常常不是更清楚，而是更分散。

長時間任務自然會漂移

現代 LLM 並不會可靠地在長時程中保留穩定的任務狀態。若沒有系統支撐，目標會模糊、先前決策會淡出，局部行動會開始壓過整體方向。

工具使用本質上是編排問題

模型可以要求使用工具，但工具如何暴露、如何驗證、如何執行、如何重試、如何加上約束，以及失敗後如何恢復，仍然由周邊系統負責。

看起來合理，不等於已被驗證

LLM 很擅長生成看起來合理的語言；但可靠工程仍需要顯式檢查、證據、結構化輸出，以及明確的驗證路徑。

架構歧義會讓模型錯誤變得更嚴重

當 workflow 的狀態與決策邏輯分散在 UI、router、repository 與 shell code 等多個位置時，AI 更容易把邏輯放錯層、提高耦合，或做出前後不一致的修改。

真正的核心問題，不是怎麼多拿到一個更好的答案。 而是如何在真實限制下，設計一個能持續產出有用答案的開發系統。

#2 推導設計推論

這些現實意味著什麼

一旦看清限制，工程上的回應就會更清楚

以下不是風格偏好，而是從現代 LLM 的實際行為推導出的工程結論。它們會影響 workflow 應如何組織、控制應放在哪裡，以及哪些假設不能再只靠默契維持。

推論

它如何改變工程行為

把 token 與 context 預算當成一級資源

Token 流不是記帳細節。它會影響成本、延遲，以及系統在同一時間能維持多少清楚一致的工作狀態。

Context 塑形應被視為和 CPU、記憶體、網路預算同級的工程資源：需要刻意設計，而不是交給運氣。

偏好 workflow，而不是巨型提示詞

對有意義的軟體工作來說，單一聊天回合很少是正確的控制單位。

顯式階段、檢查點、驗收條件與可重複的工作回路，通常比期待一個長 prompt 把所有事都做好來得可靠。

把一般聊天與受控的長任務 workflow 分開

一般對話很適合用來釐清需求、探索選項，或做小型直接修改；但長時間執行更適合進入具備可恢復狀態與清楚起停邊界的顯式 workflow 模式。

workflow 模式應該是可選而且顯式的：寫入 canonical state 前先確認，啟動輸入太弱就不要啟動，並在不需要完整控制面時保留直接聊天。

對長時程工作，把狀態顯式化

長任務需要控制面。沒有它，workflow 會逐漸塌縮成只追著當前 context 裡最顯眼的局部訊號跑。

任務狀態、slices、恢復機制與 re-grounding 應存在於模型暫時的對話連續性之外。

先開放探索，再有意識地收斂

如果太早把方法鎖死，解空間很快就會縮成起點時已知的那一小塊。

先做較廣的探索，再比較取捨，最後才鎖定實作方向、約束與驗證計畫。

把驗證設計進路徑裡，而不是最後補上

光是聽起來可信還不夠。真正的信任來自證據、檢查，以及能看見系統實際做了什麼。

驗證面、測試回路與可審視的輸出，應該屬於 workflow 本身，而不是最後才補上的東西。

用架構降低歧義

權責邊界越清楚，人和 AI 在修改系統時就越不容易互相踩線或把責任放錯地方。

較穩的做法，是維持一條 canonical workflow seam：把「下一步該發生什麼」留在 core，把副作用留給 adapter 層，並把狀態與導航權責顯式化。

把重複出現的 know-how 沉澱成可重用能力

只要某種模式已經被理解，而且可以穩定重複，就不該只留在人腦裡。

重複的手動技能應轉成命令、workflow、檢查、架構指引，或其他可重複使用的能力形式。

這不是 prompt 魔法

Prompt 當然重要，但它只是其中一個面向。更大的收益通常來自 context 塑形、工具邊界、顯式狀態、架構與驗證。

這不是為自治而自治

重點不是不計代價移除人類，而是讓模型優勢能複利，同時讓責任保持清楚可追。

這不是主張 context 越多越好

「把更多資料塞進去」通常不是好策略。就算 context window 變大，也不代表工作集管理可以省略。

這不是要取代工程判斷

真正的目標是把人類從重複執行中釋放出來，讓更多精力回到問題定義、取捨、最終決策與系統設計。

#3 成本成本治理

成本治理

為什麼 AI 原生工程也需要成本紀律

在 AI 輔助工程裡，成本不只是價格問題。token 使用、延遲、驗證回路、模型路由與 workflow 的額外開銷，都會影響一套系統是否能長期實用、保持聚焦，並值得在規模化後持續運行。

token 預算不只影響花費，也決定焦點

過長的 prompt 與過寬的 retrieval 會增加成本，也會稀釋訊號。成本治理的起點，不是一味省錢，而是先保護工作集。

驗證成本會沿著 workflow 持續疊加

生成只是第一筆成本。重跑、測試、審查、稽核與 stop 檢查，都會繼續消耗 token、時間與人類注意力。

不良架構會讓每個任務都更昂貴

只要權責不清楚，系統就得讀更多檔案、帶入更多 context，並驗證更廣的面向。清楚的 seams 能同時降低噪音與成本。

較重的 workflow 控制應選擇性啟用

不是每個任務都值得動用 canonical state、review 階段與受治理的停止條件。較重的控制平面應保留給真正能從中受益的工作。

外部狀態與控制平面本身也有維護成本

canonical state、re-grounding、slice 邊界與 stop 規則能提升可治理性，但它們也需要維護。實務上，團隊往往還需要一個共享的模型存取邊界——例如 gateway 或類似的控制面——來集中處理路由、預算、備援策略與可觀測性。這樣團隊才能建立一套可重用的 workflow 骨架，而不是讓每位工程師各自處理同樣的治理問題。這套機制必須真的值得。

好的治理是分配成本，不只是壓低成本

目標不是把成本壓到最低，而是把成本花在真正能換來清晰度、信心與耐久吞吐量的地方，並避免花在沒有回報的位置。

#4 模型工作模型

工作模型

AI 如何進入日常工程實作

整體回路其實不複雜：先界定問題、擴大選項空間、刻意收斂、讓 AI 吸收重複執行、驗證結果，最後把被證明耐久有效的模式沉澱成可重用能力。

先定義問題，但不要太早把方法定死

先把目標、限制與成功條件說清楚，但不要太早把第一個看似可行的做法變成實作牢籠。

用開放式探索擴大選項空間

在早期階段，目標應該是找出替代方案、比較取捨、看見結構選項，而不是只要求系統服從眼前第一條指令。

收斂成明確的執行計畫

一旦方向看起來可信，就應先對照 repo 的當前狀態重新定錨。接著再把範圍、權責、workflow 形狀、檢查點與驗證收緊成一份明確的執行計畫。

讓 AI 吸收盡可能多的重複工作

修改草稿、測試撰寫、變更摘要、整理與重構等重複性編碼工作，正是 AI 最能提供吞吐量的地方。

當工作跨時間或跨多個面向時，切換到顯式控制

只要工作跨越很多回合、檔案、階段或工具，就不該再假設一般聊天能自行維持整體一致性。

當模式可被穩定重複時，就把它沉澱成能力

如果同類型解法一再出現，就應把它轉成可重用能力，而不是每次重新靠人工演出。

適合啟用受控 workflow 的情境

工作會跨多個工作階段、檔案或審查階段
任務需要明確檢查點、可恢復狀態，或可供 audit 的證據
架構歧義或 workflow 分支會讓直接聊天變得過度脆弱

適合維持輕量流程的情境

任務很小、範圍局部，而且容易驗證
工作仍在探索中、可拋棄，或還不值得進入 canonical state
直接實作比啟動較重的控制平面更有效率

#5 閉環閉環

一個受治理的長任務閉環

真正可用的長任務閉環，在實務上會長成什麼樣子

對長時間的 AI 輔助工程工作來說，真正重要的問題不是眼前是哪個工具，而是：如果系統真的要跨很多回合、檔案、工具與多次工作階段維持一致性，這個閉環裡到底必須有哪些環節。當長任務漂移、薄弱的對話記憶，以及驗證風險都被認真對待時，workflow 通常會收斂成一個更顯式的閉環。

最核心的一步，是不要再把長任務當成一段被拉長的聊天，而要把它當成受治理的閉環。 這個閉環通常從顯式 workflow 入口與確認過的 startup intent 開始。接著，任務描述、canonical plan、active slice、驗證證據與停止紀錄，會被放進 repo-local、機器可讀的外部狀態裡，而不是留在模型本身。之後系統才能持續 re-ground、執行、評估、再對齊，並只在當前證據允許時才停止。

workflow 入口是顯式的

受治理的長任務模式是選擇性啟用，而不是把每個任務都強迫套進重型流程。一般聊天仍可處理輕量工作；只有在可恢復性、啟動前確認與顯式控制真的值得時，才切進 workflow mode。

repo truth 會反覆覆蓋過時摘要

re-ground 的過程會持續根據當前 codebase 校準 workflow 狀態，而不是信任舊計畫或對話延續感。這讓系統在 context 被壓縮、中斷、review 發現問題，或單純長時間漂移之後，仍有機會回到真實狀態。

執行一次只推進一個可驗證 slice

實作透過單一明確 slice 前進，附帶鎖定的驗收條件、聚焦驗證，並以 commit 作為邊界。目標不是在大片修改面上看起來很忙，而是用之後仍可重新校驗的可審查單位穩定前進。

評估與再對齊是閉環的一部分

嚴肅的閉環不會從這一輪實作直接跳到下一輪實作。審查、稽核與正式再對齊必須夾在中間，讓系統決定這個 slice 應該被接受、重開、更新待辦項目，或交出下一個邊界清楚的步驟。

收束是受治理的，而不是靠對話感覺

完成並不是因為模型講得很有自信，或因為對話看起來差不多結束了。只有當前證據、驗證結果與明確停止條件都支持時，這個閉環才應該真正停下來。

這種閉環不是為了流程而流程。 它回應的是模型的真實限制：有限 context、任務漂移、薄弱的隱式記憶，以及「看起來合理」與「已被驗證」之間的落差。當這些限制被認真對待時，外部狀態、反覆 re-ground、邊界清楚的 slices、把評估納入閉環，以及受治理的收束，看起來就不再像額外儀式，而更像基本的 workflow 基礎設施。

#6 能力系統能力

必要能力

真正認真的 AI 原生工程，需要哪些能力

這更該被理解成一個能力堆疊，而不是單一工具選型。若目標是真實工程工作，而不是短距離輔助，下面這些能力幾乎避不開。

對模型行為的現實心智模型

一套認真的 workflow，首先需要清楚理解 LLM 擅長什麼、會在哪裡漂移，以及結果應該如何被判定。

context 塑形與工作集控制

系統應決定哪些資訊此刻進入 context、哪些留在外部，以及狀態如何隨時間被壓縮、取回或重新帶回。

顯式狀態分類與長任務控制

任務狀態、slices、檢查點、恢復機制，以及持久狀態、workflow 暫態與介面本地狀態之間的區分，都不該依賴對話運氣。

執行環境邊界、語義化副作用與編排

工具使用與副作用需要清楚的邊界、執行規則、參數驗證、失敗處理，以及可在事後檢視的結果。

單一 canonical seam 與清楚權責

一個功能應收斂到一條 canonical workflow seam，讓人和 AI 都知道「下一步該發生什麼」應該放在哪裡。

驗證面與證據回路

好的 workflow 會讓證據容易被檢視：有哪些檢查、跑了哪些測試、留下哪些可審查輸出，以及系統實際做了什麼。

交付衛生與可審查打包

工作應收斂成乾淨、可審查的單位——理想上一次只完成一個邊界清楚的 slice——而不是最後堆成一團零散修改、分散權責與倉促收尾。

學習與蒸餾

只要某種模式反覆證明有效，就應把它沉澱成可重用能力，而不是每次重新靠人工重演。

canonical 外部狀態與可恢復性

workflow 的連續性應透過機器可讀的外部狀態穿越 context 壓縮、中斷與重啟，而不是只依賴對話本身的連續感。

受治理的停止與收束

完成不應由模型自信或對話動能決定，而應建立在當前證據、審查、稽核與明確停止條件之上。

#7 所有權人類角色

人類應該留在流程中的哪些地方

人類判斷不會消失，而是被集中到真正重要的地方

AI 應吸收大量重複執行，但不該悄悄接手那些仍取決於意義、風險與可追責判斷的工程部分。

定義問題執行前

人類定義問題與真正的限制

即使 workflow 設計得很好，仍需要人類說清楚意圖、成功條件、邊界，以及那些決定「什麼才算正確」的不明顯脈絡。

取捨探索期間

人類決定哪些取捨值得做

速度與整潔、局部修補與較大重構、短期修正與長期一致性，這些都是工程判斷，不是純統計選擇。

收斂實作前

人類決定何時從探索轉入執行

開放探索很有價值，但最後仍需要有人判斷：選項空間是否已經足夠，以及工作是否該收斂到單一路徑。

意義審查期間

人類驗證的是產品意義，不只是檢查有沒有過

測試可以全綠，但使用者感受到的產品意義、架構意圖或操作後果仍可能是錯的。這些地方仍需要人類審查。

風險上線前

人類承擔風險與不可逆後果

部署、遷移、安全敏感修改、資料寫入，以及其他高影響動作，都應維持清楚的人類責任歸屬。

學習任務之後

人類決定哪些模式值得沉澱成可重用能力

蒸餾本身也是判斷：什麼該變成作業手冊、命令、約束或 workflow，什麼則應維持一次性決策？

#8 限制取捨

取捨與失敗模式

這種做法的代價，以及仍可能出錯的地方

從第一性原則出發的 workflow，不會因為原則清楚就自然變簡單。它會帶來槓桿，但也同時引入額外結構、維護負擔，以及新的出錯方式。

顯式控制越多，系統機械也越多

檢查點、workflow 狀態與驗證面能提升可靠性，但也會讓系統本身更難建置、操作與維護。

不是每個任務都值得啟動完整系統

有些工作小到用簡短 prompt 或輕量編輯回路就夠了。把每件事都系統化，反而會增加阻力。

客製 workflow 邏輯本身有維護成本

這套 workflow 邏輯越客製，就越需要持續和真實實踐對齊；否則它很容易從有用流程變成僵化儀式。

控制平面本身也有維護負擔

canonical state、re-grounding、slice 邊界與 stop 規則能提升長任務的可治理性，但也會帶來持續的流程成本與維護負擔。

蒸餾可能把當前偏好過早固化

把重複驗證有效的做法轉成可重用能力很有力量，但也可能太早把當下偏好的做法寫死。

AI 友善結構仍必須同時服務人類與產品

架構應該變得更清楚，而不是更教條。為 AI 最適化只有在同時保留人類可維護性，並服務真實產品需求時才有意義。

指標有用，但永遠不會取代判斷

Token 數、成本與測試結果都很重要，但它們仍只是部分訊號。Workflow 可以看起來高效，卻仍然在解錯問題。

為什麼這仍然值得做

目標不是追求最高自治，而是建立一套讓模型優勢能持續複利、同時刻意約束模型弱點的開發系統。

當 workflow 設計得夠好時，AI 就不再只是更快的自動補全。它會成為更大工程工作模型的一部分：提升吞吐量、保留判斷，並把反覆驗證有效的做法轉成可重用能力。

團隊最低運作標準

對於非瑣碎的 AI 輔助工程工作，我們的預設基線是：

在放大 workflow 之前，先把任務說清楚。
把 workflow 的狀態與決策邏輯維持在單一位置。
不要把業務分支邏輯藏進 UI 層或 adapter 層。
對非瑣碎的 AI 生成修改，留下可審查的驗證證據。
只有在較重的 workflow 控制確實值得時，才啟用它。