從直覺式編碼到情境工程：AI 時代的軟體規格還重要嗎？

截至 2026 年 10 月。如今使用 Claude Code、Copilot、Cursor 或類似工具的開發者都深知其中的矛盾：一方面，模型已變得如此強大，以至於粗略的任務分配往往能帶來驚人的進展。

另一方面，在實際專案中，你很快就會發現，好的結果很少僅憑一句簡短的提示詞就能產生。這正是從直覺式編碼（Vibe Coding）走向情境工程（Context Engineering）的分界線。因此，本文的重點論點是：是的，在某些情況下，嚴格的提示詞規格正變得不那麼重要。但所需付出的努力並未消失，它只是從撰寫單一提示詞轉移到設計專案情境。

「直覺式編碼」一詞源於 Andrej Karpathy。在他 2025 年 2 月 2 日那篇被廣泛引用的 X 貼文中，他描述了一種幾乎「忘記程式碼」、用日常語言請求變更、直接將錯誤丟回模型、甚至經常不仔細閱讀差異就「全部接受」的風格。

這並非一種精確的方法論，而是對一種新實踐的刻意尖銳描述：少打字、多說話、快速迭代、信任模型。這種做法的吸引力顯而易見。對於新創想法、一次性原型、使用者介面草圖或小型輔助工具，這種方法可以非常高效。

任何使用常見技術堆疊來建構表單、小型腳本或簡單服務的人，都能受益於模型已從訓練中學習到許多常見模式的事實。在這種情況下，直覺式編碼不僅是懶惰，更是一種槓桿：減少了想法與第一個可行成果之間的摩擦。

但即使在 Karpathy 的原文中，也包含了警告。他明確提到「一次性週末專案」，以及程式碼如何超出其通常的理解深度。這正是風險開始的地方：模糊的需求、盲目接受變更、難以偵測的安全問題，以及稍後才會顯現的技術債務。

2025 年和 2026 年的獨立研究也證實了這種懷疑：LLM 生成的程式碼可能看起來功能正常，但仍包含安全或品質問題，這些問題在沒有額外審查的情況下很容易被忽略。

「情境工程」一詞隨後確立並非巧合。Anthropic 將情境工程描述為提示詞工程的演進：不僅提示詞中的文字重要，模型在特定情境下看到的所有 token 和訊號都重要，包括系統指令、工具、外部資料、訊息歷史、MCP 情境及其他狀態。

因此，重點從「我該如何 формуulate 請求？」轉移到「模型在何時應該看到哪些資訊？」其原因在於當今編碼和代理工具的運作方式。現代代理不再是單次回合操作，而是在工具、中間狀態和後續決策中循環。潛在的相關情境不斷增長。

此時，僅僅用盡可能多的文字淹沒模型是不夠的。你必須在正確的時間選擇、結構化和重新載入資訊。這正是為什麼 CLAUDE.md 或 AGENTS.md 等專案檔案、儲存的記憶條目、技能和子代理變得如此重要的原因。

Anthropic 公開文件指出，CLAUDE.md 檔案會將永久專案規則、架構筆記和工作慣例載入每個會話，而 Auto Memory 則讓修正和模式可在不同會話間使用。子代理則明確用於在自己的情境視窗中處理子任務，以免主對話被瑣碎事務堵塞。這與「一個大提示詞解決所有問題」的觀點恰恰相反。

因此，情境工程主要不是指更長的提示詞，而是指更好的情境架構。哪些專案規則始終適用？哪些資訊只需要專業代理？哪些是永久儲存的，哪些是即時載入的？以及模型無法從訓練中得知，人類必須明確指定的是什麼？

現在來檢驗實際論點：「今天的模型非常出色，以至於嚴格的情境規格通常不再必要。通常只需幾句話描述專案就足夠了。」公平的結論是：這有時是真的。這也正是該論點如此吸引人的原因。

它特別適用於任務與常見模式接近的情況。在一個使用標準技術堆疊、已知函式庫且目標可控的新專案中，模型可以補充驚人的多數內容。今天，像「建構一個帶有 JWT 登入、PostgreSQL 和測試的小型 FastAPI 服務」這樣的粗略任務，通常就能提供一個令人驚訝的可用起點。

對於小型功能、原型或內部工具，簡短指令與可行草稿之間的差距已顯著縮小。這並非因為情境不重要，而是因為部分情境已嵌入模型中：框架慣例、標準專案結構、常見測試模式、熟悉的 API 形式。

但當決定性因素不在於通用訓練知識時，這個論點就會失效。大型、演進的程式碼庫包含著局部真理：內部捷徑、歷史架構決策、團隊慣例、部署中的特殊情況、隱含的安全假設、舊版介面和可維護性規則。這些知識模型根本無法猜測。

任何人若只用兩句話開始，得到的往往不是「更少的規格」，而是更多帶有專業語氣的幻覺。此外還有第二個斷裂點：品質和安全性並非自動從高模型能力中推導出來。2025 年的一項定量分析得出結論，功能正確性並非程式碼品質和安全性的可靠指標；正因如此，靜態分析和額外驗證是必要的。

另一項關於 SWE-bench 上代理式程式修復的研究顯示，代理式工作流程也可能產生新的漏洞，特別是當允許更多自主權且關於問題和程式碼庫的情境不完整時。簡而言之：更好的模型減少了一些摩擦，但它們並不能消除缺少情境資訊的成本。

任何想要親自驗證這個論點的人，不需要大型研究環境。一個小型團隊實驗就足夠了。在一個真實但非關鍵的程式碼庫中，執行一個相同的任務，例如：「在搜尋對話框中添加一個新的篩選選項，包括測試和文件。」

讓模型只使用簡短描述工作一次。在第二次運行中，給予它結構化的情境：相關檔案、架構筆記、驗收標準、專案規則、測試指令和兩個常見陷阱。不僅比較「是否有效」，還要比較：後續問題的數量、後續修正的數量、測試的品質、對慣例的遵守程度、變更的可讀性以及審查工作量。

我的預期是：對於小型、通用任務，差異會比 2024 年小。但一旦專案知識、限制和不明顯的標準變得重要，結構化情境的表現應該會更穩健。

因此，界線運行在任務類型之間，而非「舊」模型與「新」模型之間。類似直覺式編碼的方法在模型可以從已知模式中合理填補缺失細節時運作良好。當缺失的細節是領域特定、架構相關或安全相關時，它們就會變得有風險。

在四種情況下尤其關鍵。首先，在大型舊版專案中：此處，局部知識比通用框架知識更重要。其次，對於隱含的團隊規則：如果命名、錯誤處理或發布實踐沒有明確說明，模型會優化其合理性，而非你的實際情況。

第三，對於安全性和可維護性要求：研究顯示，AI 生成的程式碼仍然可能存在系統性弱點。第四，在較長的代理鏈中：涉及的循環、工具和中間步驟越多，良好的情境管理就越重要，而不是僅僅寄希望於模型的智慧。

那麼，規格工作會消失嗎？不會。它只是轉移了。早期的一些提示詞技巧變得不那麼重要：人為誇大的角色描述、僵化的公式化食譜和過度優化的單次提示。

另一方面，模型無法從世界知識中推導出來的事物變得更加重要：驗收標準、專案規則、架構邊界、決策日誌、相關檔案、測試和安全要求。因此，我的具體建議是：當問題是通用型時，使用簡短的提示詞。

但一旦相同的規則多次適用，就有意識地投入可重複使用的專案情境。撰寫 CLAUDE.md 或 AGENTS.md，保持驗收標準簡潔明確，使用記憶來處理重複的修正，並透過專業代理或子代理更強烈地分離研究、實作和審查。未來不在於選擇直覺式編碼或規格。它在於知道何時幾句話就足夠，以及何時缺少情境將比一開始的任何清晰規格花費更多。

參考資料：

Andrej Karpathy on X, 2. Februar 2025

Effective context engineering for AI agents (Anthropic, 29.09.2025)

How Claude remembers your project (Claude Code Docs)

Create custom subagents (Claude Code Docs)

Vibe coding: programming through conversation with artificial intelligence (Sarkar & Drosos, 29.06.2025)

Security and Quality in LLM-Generated Code: A Multi-Language, Multi-Model Analysis (arXiv/IEEE TDSC)

How Safe Are AI-Generated Patches? A Large-scale Study on Security Risks in LLM and Agentic Automated Program Repair on SWE-bench

Assessing the Quality and Security of AI-Generated Code: A Quantitative Analysis

Want better AI outputs? Try context engineering. (GitHub Blog)