Vibe Coding 是一個陷阱。你需要「The Codex」。

簡而言之：「Vibe Coding」——隨意引導 AI 建立軟體的做法正在流行。但沒有結構，它不可避免地導致「上下文漂移」和意大利麵碼。要用 AI 建立企業級軟體，你需要一個嚴謹的「上下文架構」。在水星，我們稱之為「The Codex Protocol」。這將你的文檔視為不可更改的法則，AI 必須在寫下任何程式碼之前參考它。我是水星科技解決方案的執行長詹姆斯。網際網路上充斥著「Vibe Coding」。這個承諾令人著迷：你隨意（「氛圍」）與 AI 交談，它就會建立一個應用程式。我已經審查了在開發圈中流傳的熱門工作流程。它們對於原型來說非常出色，但對於嚴肅的工程來說有一個致命的缺陷：

它們假設 AI 記得「大局」。但事實並非如此。

大型語言模型（LLMs）會受到熵的影響。隨著對話的延長，AI 會忘記你在 40 條訊息前達成的資料庫架構。它開始創造新的模式。「氛圍」變成了混亂。

在水星，我們將這個過程精煉為一個嚴謹的工作流程。我們不稱之為 Vibe Coding。我們稱之為「上下文工程」。這是我們用 AI 建立軟體的「水星協議」，使用我們稱之為「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（日誌）：

已完成的事項，待處理的事項。

工作流程：架構 --> 執行 --> 驗證

1. 不要隨便開啟聊天並開始編碼。遵循這個循環。第一階段：建築師（模型：Claude Opus 4.5）
2. 我們使用最聰明、最慢的模型來制定法則。行動：你擔任產品經理。你將你的想法傾倒進聊天中。
3. architecture.md (The Map): The file structure and database schema. This is the most critical file.
4. implementation-plan.md (The Path): A step-by-step list of tasks. Each step must have a verification test.
5. 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 重新嘗試。

「反重力」優勢：模型套利

原始指南建議選擇一種工具。我不同意。

使用模型套利：

1. 規劃（架構師）：使用Opus 4.5。它深入思考邊緣案例並編寫穩健的 Codex。編碼（文書）：
2. 使用Sonnet 4.5。它遵循指示且成本較低。重構（圖書管理員）：使用
3. Gemini 3 Pro。它擁有巨大的上下文窗口，可以一次性閱讀整個代碼庫，如果事情變得混亂。結論：從「氛圍」到「願景」「氛圍編碼」意味著你可以輕鬆地讓 AI 工作。這是錯誤的。這個工作流程將你的努力從打字轉移到治理。

你不再是砌磚工。

你是

Codex 的守護者。

• 你的工作是確保
• Codex保持乾淨。如果 architecture.md 變得混亂，代碼就會變得混亂。如果 implementation-plan.md 模糊不清，AI 將會卡住。掌握 Codex，你就能單獨構建企業級軟體。忽視它，你只會擁有一個充滿破損腳本的資料夾。

水星科技解決方案：加速數位化。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.