簡而言之：「Vibe Coding」——隨意引導 AI 建立軟體的做法正在流行。但沒有結構，它不可避免地導致「上下文漂移」和意大利麵碼。要用 AI 建立企業級軟體，你需要一個嚴謹的「上下文架構」。在Mercury，我們稱之為「The Codex Protocol」。這將你的文檔視為不可更改的法則，AI 必須在寫下任何程式碼之前參考它。我是Mercury Technology Solutions的執行長詹姆斯。網際網路上充斥著「Vibe Coding」。這個承諾令人著迷：你隨意（「氛圍」）與 AI 交談，它就會建立一個應用程式。我已經審查了在開發圈中流傳的熱門工作流程。它們對於原型來說非常出色，但對於嚴肅的工程來說有一個致命的缺陷：
它們假設 AI 記得「大局」。但事實並非如此。
大型語言模型（LLMs）會受到熵的影響。隨著對話的延長，AI 會忘記你在 40 條訊息前達成的資料庫架構。它開始創造新的模式。「氛圍」變成了混亂。
在Mercury，我們將這個過程精煉為一個嚴謹的工作流程。我們不稱之為 Vibe Coding。我們稱之為「上下文工程」。這是我們用 AI 建立軟體的「Mercury協議」，使用我們稱之為「The Codex」的單一真相來源。
核心理念：「The Codex」
秘密不在於模型（Claude 與 GPT-5）。秘密在於「外部記憶」。你必須將你的專案資料夾視為不僅僅是程式碼的地方，而是 AI 的「大腦」。我們強制執行一個嚴格的資料夾結構，稱為「/codex」。
為什麼叫「Codex」？因為它暗示著權威。這些不是筆記；它們是「法則」。在 AI 寫下任何程式碼之前，它必須參考 The Codex。結構在你的根目錄中創建一個名為 /codex 的資料夾。它包含五個不可更改的檔案：
product-vision.md（為什麼）：
高層次的目標。（例如，「使用 ThreeJS 的 3D 多人狗鬥遊戲」）。tech-stack.md（如何）：
具體的工具。（例如，「用於網路的 WebSockets，物理的 Rapier。不要使用 React，僅限於原生 JS」）。architecture.md（地圖）： 檔案結構和資料庫架構。這是最關鍵的檔案。
implementation-plan.md（路徑）： 一個逐步的任務列表。每一步「必須」有一個驗證測試。progress.md（日誌）：
已完成的事項，待處理的事項。
工作流程：架構 --> 執行 --> 驗證
- 不要隨便開啟聊天並開始編碼。遵循這個循環。第一階段：建築師（模型：Claude Opus 4.5）
- 我們使用最聰明、最慢的模型來制定法則。行動：你擔任產品經理。你將你的想法傾倒進聊天中。
- architecture.md (The Map): The file structure and database schema. This is the most critical file.
- implementation-plan.md (The Path): A step-by-step list of tasks. Each step must have a verification test.
- progress.md (The Log): What is done, what is pending.
The Workflow: Architecture --> Execution --> Verification
Do not just open a chat and start coding. Follow this loop.
Phase 1: The Architect (Model: Claude Opus 4.5)
We use the smartest, slowest model to write the law.
Action: You act as the Product Manager. You dump your brain into the chat.
提示："擔任系統架構師。根據我的想法創建 product-vision.md 和 tech-stack.md 的條目。然後，提出 architecture.md。暫時不要寫代碼。這些文件將放入 The Codex。"
結果：你鎖定設計。你明確禁止 AI 之後做出架構決策。
第二階段：文書 (模型：Claude Sonnet 4.5 / Codex)
我們使用快速的「代理」模型來執行法律。
黃金法則：每個新的聊天會話必須以 AI 諮詢 The Codex 開始。
提示："諮詢 /codex/@architecture.md 和 /codex/@implementation-plan.md。我們目前在第三步。嚴格遵循 The Codex 中定義的架構來實施第三步。不要進入第四步。"
通過強迫 AI 每次都閱讀 /codex，你消除了「上下文漂移」。無論你是在提示 #1 還是提示 #100，AI 都是基於相同的真相。
第三階段：驗證者 (模型：人類 + 瀏覽器工具)
這是你的工作。
流行的指南建議使用自動化，但我堅持人類驗證。
行動：AI 說「第三步完成。」
你：運行代碼。檢查日誌。3D 平面真的能飛嗎？
關鍵步驟：如果它有效，你指揮 AI："更新 /codex/@progress.md 標記第三步完成。如果你添加了新文件，更新 /codex/@architecture.md。"
只有在那之後你才會提交到 Git。Git 是你的保存點。如果 AI 在第四步中出現幻覺，你可以 git reset --hard 重新嘗試。
「反重力」優勢：模型套利
原始指南建議選擇一種工具。我不同意。
使用模型套利：
- 規劃（架構師）：使用Opus 4.5。它深入思考邊緣案例並編寫穩健的 Codex。編碼（文書）：
- 使用Sonnet 4.5。它遵循指示且成本較低。重構（圖書管理員）：使用
- Gemini 3 Pro。它擁有巨大的上下文窗口，可以一次性閱讀整個代碼庫，如果事情變得混亂。結論：從「氛圍」到「願景」「氛圍編碼」意味著你可以輕鬆地讓 AI 工作。這是錯誤的。這個工作流程將你的努力從打字轉移到治理。
你不再是砌磚工。
你是
Codex 的守護者。
- 你的工作是確保
- Codex保持乾淨。如果 architecture.md 變得混亂，代碼就會變得混亂。如果 implementation-plan.md 模糊不清，AI 將會卡住。掌握 Codex，你就能單獨構建企業級軟體。忽視它，你只會擁有一個充滿破損腳本的資料夾。
Mercury Technology Solutions：加速數位化。Codex stays clean. If the architecture.md gets messy, the code gets messy. If the implementation-plan.md is vague, the AI will get stuck.
Master the Codex, and you can build enterprise-grade software alone. Ignore it, and you’ll just have a folder full of broken scripts.
Mercury Technology Solutions: Accelerate Digitality.
