法則一：Be Claude’s PM——為它提供完整上下文

四大黃金法則 (Vibe Coding) 第一條。

核心類比

想像一位新員工第一天上班，你直接丟給他「實作這個功能」——他不可能成功。Claude 也一樣。

規範要求

✅ 動工前至少花 15–20 分鐘蒐集上下文，整理成單一 prompt 或計畫文件
✅ 建議做法：先在另一個對話裡與 Claude 探索 codebase、共同產出計畫，再開新對話請它執行（Plan-then-Execute SOP step 2-4）
❌ 禁止做法：對著一個複雜功能直接打「幫我做 XXX」就按 Enter

Context 必須包含 5 元素

商業需求與「Done」的定義
受影響檔案與模組
應遵循的程式碼模式 (pattern)
限制條件（效能、相容性、API 規格、Lint rules）
不希望被改動的範圍

詳細展開見 Prompt 必備六元素。

為什麼這條最先

四法則中，這條是 prerequisite——其他三法則都假設「AI 拿到完整上下文後做出合理產出」才成立。沒有這條，後面三條再嚴也救不回來「garbage in, garbage out」。

違反時的常見症狀

症狀	根因
AI 產出跟 codebase 風格完全不像	沒給 pattern 說明
AI 動到不該動的檔	沒劃 scope
AI 重新發明已有的 utility	沒 codebase 探索
AI 寫出能跑但不符商業邏輯的東西	沒寫「Done」定義
AI 違反公司既定 conventions	沒把 lint rules / style guide 帶進 context

落地工具

工具	角色
CLAUDE.md 4 層機制	把 codebase context 讓 Claude 自動 load
Skills 九種類型	把可重用 expertise 包成 skill
MCP 三層架構	把外部資源（DB / API / Docs）餵給 Claude
Sub-agent	Phase 1 codebase 探索可派 sub-agent 做
Plan-then-Execute SOP	整個流程的 SOP

跟其他法則的銜接

法則一 (給 context)  ──→  法則二 (限制範圍 = leaf node)
                      ──→  法則三 (core 由人 review)
                      ──→  法則四 (可驗證檢查點)

法則一是輸入端——後面三條是處理 / 驗證端。

相關