從不同位置看交付
在金融服務科技領域的十五年多裡，我曾從事 UI 開發、軟體工程、量化工程、系統可靠性、架構與技術教育。這些角色雖然不同，卻讓我一次又一次從不同位置看見同一套交付系統。
軟體變更能否成功，往往不只取決於實作技巧。產品意圖、領域判斷、架構、營運知識與驗收，都必須完整傳遞，最終成為可運作的軟體。在這些職責之間轉換，讓我格外留意交接過程中流失了什麼。
規格優先交付的緣起
規格優先交付源於我多年參與軟體交付時反覆看見的一種模式，而 AI 加快實作後，這個模式變得更清楚。一個大型 AI 輔助軟體專案不斷印證同一件事：程式碼生成能力再強，也無法彌補沒有帶入實作工作的專業判斷。我曾在交付系統的不同環節工作，因此能辨認這個模式，並試行另一種做法。
從經驗到提案
我從不同位置看見同一個交付難題
AI 讓隱藏的限制浮現
我從 Codex 一推出就開始使用了。真正值得注意的改變是不只是程式碼生成變快，而是實作上再也不能掩蓋許多協調上的問題。
過去工程師通常要在數天或數週的實作期間，才會逐漸釐清的問題，如今更早就浮現：脈絡不足、決策未定、權限不清，以及驗收邏輯薄弱。程式碼生成尚未成為限制因素之前，這些問題就可能已經限制交付。
一個專案成了實驗場
在金融服務工作之外，我參與了一個大型軟體專案。起初，我著眼於讓 AI 輔助開發更可靠，做法是提供更完整的脈絡、更清晰的指示與更明確的規格。
每一次改進，都讓另一項更上游的依賴關係浮現。再好的提示詞，也有賴先前已做出的決策；再清楚的規格，仍要以分散在不同人員與各類產出物中的知識為本；再快的實作，也需要明確的權限與可信的驗收。這個問題已經超出實作本身。
問題的焦點改變了
關鍵轉折在於，我發現自己一直問錯了問題。
我從一開始思考工程師該如何指示 AI，轉變成思考組織要如何讓專業判斷確實用於軟體交付。規格優先交付的概念就是從這個問題的轉變中發展而來，及後在反覆實作下衍生出軟體工程框架。
一個特別的視角
我為什麼會這樣看待問題
我的職涯經驗橫跨多個範疇，這讓我能沿著同一項決策，一路看見軟體交付中通常分別處理的責任如何彼此相連。
貫穿交付各層
我曾參與實作、架構與管理工作，也處理過高度仰賴領域知識的系統，並從事技術教育。因此，我習慣追問一項決策如何穿過不同層次，不把每次交接都當成別人的事。
專業之間的接點
我處理過最棘手的問題，許多都出現在專業交會處：業務與工程、架構與實作、平台團隊與使用者，或領域專家與必須依據其知識採取行動的人之間。我會尋找意義在哪個環節斷開或流失。
透過實作與教學
實作能驗證一個想法是否行得通；教學則檢驗背後的推理能否傳遞給別人。這兩種經驗讓我不只關心系統今天能否運作，也關心另一位有能力的人能否在明天理解並延續它。
起源與作者
規格優先交付由 Marcus Peck 從事 AI 輔助軟體交付的獨立研究與實作工作中創立。其公開且可追溯的發展脈絡，始於 Marcus 在 2025 年 7 月發表的 Context Engineering 系列文章。
以「規格優先交付」為名的出版系列始於 2026 年 6 月，之後並透過規格優先資源中心持續完成更完整的體系化。這套框架持續從公開研究、實作經驗，以及與相鄰領域工作的比較中發展。
相鄰領域也可能獨立發展出相關想法。本項作者歸屬所指的是這一具體工作體系、其術語、規格架構與有紀錄可循的發展脈絡。較廣泛的想法及獨立發展的工作，各自都有其發展歷程。
從實務走向公開框架
一個有待檢驗的提案
規格優先交付是我將這些觀察整理為一套連貫工程框架的嘗試，目的是讓它跳出單一專案、組織或個人的範圍，接受檢驗。
我選擇公開發表，因為產品、工程、架構、品質、營運與研究領域的工作者，都應能從不同角度檢視這些想法。當實務與證據指出需要調整之處，這套框架也應隨之改變。
它的起點仍然很簡單：把實作工作委派出去愈來愈容易，圍繞實作的知識與專業判斷是否充分，也就再也無法忽略。
Marcus Peck
規格優先交付的創立者暨維護者