拒絕 Token 消粍，拒當 Cursor, Windsurf 冤大頭

Prompt for Vibe Coding:

Before write the code, write a README.md to define the Three Layered Architecture, draw a tree style data structure, then follow it. For the code, follow the rule of SOLID principle, refractor when bad smell, follow the rule of the Clean Code. Avoid each code exceed 200 lines, by following the DRY rule.

As needed: (1) Refractor the code with [Design Pattern] Observer patter, Decorator Pattern, or Strategy Pattern

For each component, write simple documentation, clear, step by step approach, before write, follow the principle and step we write in the doc.

原始 Facebook 貼文：連結

# Claude 贊日

協霆這段 Vibe Coding 提示詞代表了一個重要的轉變：從「讓 AI 快速產出代碼」到「讓 AI 快速產出好代碼」。這其中的差別看似微妙但至關重要。許多初學者用 Cursor/Windsurf 時，會寫出「幫我寫個 todo app」這樣籠統的需求，結果 AI 會堆砌一個能跑但很難維護的系統。協霆的方法完全相反：先建立結構，再填充細節。

他要求的三項前置作業特別聰明：

1. README.md 定義架構 — 在寫一行代碼前，先用文字澄清設計思路
2. 樹狀資料結構圖 — 視覺化系統的資訊流向
3. 遵循寫好的架構 — 確保每一行代碼都是計畫的一部分

這個順序很重要。許多開發者習慣先寫代碼再補文檔，但協霆反其道而行——把文檔當成設計的第一步。這對於與 AI 協作特別關鍵，因為 AI 需要清晰的藍圖才能做出好的決策。

「SOLID 原則」和「Clean Code」的強調也表明協霆不想生成一次性代碼，而是要打造可長期維護的系統。SOLID 包括：

• S (Single Responsibility) — 每個類/函數只做一件事
• O (Open/Closed) — 對擴展開放，對修改關閉
• L (Liskov Substitution) — 子類能安全替代父類
• I (Interface Segregation) — 客戶端不應依賴不需要的介面
• D (Dependency Inversion) — 高層模組不應依賴低層實現

這些不是抽象的哲學，而是防止代碼腐爛的實踐守則。協霆說「每個代碼超過 200 行」的限制，直接實踐了 SRP（單一責任原則）。

「200 行限制」和「DRY（Don’t Repeat Yourself）」配合使用，就能自然地導向模塊化設計。當你意識到要複寫同樣的邏輯時，就該提取成獨立函數。

最後是「Design Pattern」的提及——Observer、Decorator、Strategy 這些都是經典模式。協霆不是說每個專案都要用，而是「如果需要就用」。這展現了對設計複雜度的敏銳感知。

在臨床軟體開發中，類似的原則更關鍵。患者資料系統不能「先衝功能，後來再說」，從一開始就要確保架構清晰、責任分明，否則後期維護成本會極其昂貴。

Vibe Coding 的黃金法則：

1. 架構優於速度
2. 簡潔優於聰明
3. 可測試優於難測試
4. 文檔優於猜測