Superpowers的3條鐵律+1套流程，搭建“守規矩”的 AI工作流
整理版優先睇
提供一套名為「7-14-3」嘅 AI 編程工作流：7步流程、14個技能、3條鐵律，將 AI 編程從隨機生成變成可控、可預測、可維護嘅工程化過程。
呢篇文章係關於點樣系統化噉用AI編程，避免「一跑就崩」嘅情況。作者提出咗一套名為「7-14-3」嘅工作流，包括7步流程、14個技能同3條鐵律。文章嘅背景係好多開發者將AI當成黑盒生成器，導致代碼容易出錯。作者嘅結論係：AI編程唔係魔法，而係工程，需要系統化嘅流程約束同人工審查。
7步流程從精準定義需求開始，經過架構拆分、生成代碼、人工審查、沙箱測試、集成迴歸到持續優化，每一步都係關鍵關卡。14個技能分為精準輸入、高效協作同工程化落地三個層面，幫助開發者由「寫提示詞」進化到「駕馭AI」。最後3條鐵律——永遠唔好信AI第一版、唔好直接改生產環境、AI係工具你係設計師——係守住底線嘅關鍵。
總括而言，呢篇文章提供咗一套實用嘅方法論，適合任何用AI輔助編程嘅開發團隊。最直接嘅行動係：下次叫AI寫代碼前，先寫一個結構化需求模板，咁已經可以減少一半嘅翻車機會。
- AI編程容易崩潰嘅根源在於將AI當成黑盒生成器，缺乏系統化工作流。
- 「7-14-3」工作流包含7步流程：精準定義、架構先行、生成代碼、人工審查、沙箱測試、集成迴歸、持續優化。
- 14個核心技能涵蓋精準輸入（結構化模板、示例驅動等）、高效協作（CoT推理、迭代修正等）、工程化落地（依賴管理、安全審查等）。
- 3條鐵律：永遠唔好信第一版、唔好直接改生產環境、AI係工具你係設計師。
- 可行動點：下次用AI寫代碼前先寫結構化需求模板，可減少50%翻車。
結構化需求模板
功能：{功能名} 輸入：{參數名}（{類型}，{約束}） 輸出：{成功返回}；{失敗返回} 邊界條件：{特殊情況} 錯誤處理：{錯誤場景與處理}
AI 編程「一跑就崩」嘅根源
你讓 AI 寫代碼有幾爽，佢就能讓你修 bug 有幾崩潰。呢個唔係AI嘅錯，係你缺一套令佢「守規矩」嘅工作流。
「黑盒生成器」
「7-14-3」
呢套工作流包括7步流程、14個技能同3條鐵律。
7步流程：從需求到上線嘅防崩流水線
7步流程從精準定義到持續優化，每一步都係關鍵。
Chain-of-Thought推理、人工審查同沙箱測試
- 1 精準定義：用結構化模板描述需求，減少AI跑偏。
- 2 架構先行：將大需求拆成小任務，一次只處理一個函數。
- 3 生成代碼：先讓AI解釋思路（Chain-of-Thought），再生成。
- 4 人工審查：檢查邏輯、安全、命名、註釋，別信第一版。
- 5 沙箱測試：讓AI生成測試用例，喺隔離環境運行。
- 6 集成迴歸：通過CI/CD、Code Review、性能基準先合併。
- 7 持續優化：記錄成敗案例，形成團隊知識庫。
功能：用戶登錄
輸入：用戶名（字符串，1-20字符）、密碼（字符串，8-32字符，含大小寫字母和數字）
輸出：成功時返回JWT token；失敗時返回錯誤信息
邊界條件：連續5次失敗，鎖定賬號30分鐘；密碼明文傳輸需加密
錯誤處理：數據庫連接失敗時，返回「服務暫時不可用」結構化模板
14個技能：成為AI編程駕馭者
14個技能分為三個層面：
精準輸入
高效協作
工程化落地
- 1. 結構化需求模板：用模板描述功能、輸入、輸出、邊界、錯誤。
- 2. 示例驅動（Few-shot）：畀AI 2-3個示例理解風格。
- 3. 角色與約束設定：指定語言、框架、規範。
- 4. 代碼風格與命名約定：camelCase、UPPER_CASE等。
- 5. 上下文管理：總結成果後重置對話。
- 6. 分步推理（CoT）：先解釋思路再生成代碼。
- 7. 迭代修正：指出問題要求重寫。
- 8. 代碼審查與追問：檢查安全、性能、可讀性。
駕馭AI
3條鐵律：守住AI編程嘅底線
守唔住呢3條鐵律，前面都係白搭。
3條鐵律
總結：AI編程係工程，唔係魔法
AI編程係工程，唔係魔法。你有幾系統化噉用，佢就有幾穩定噉回報你。
結構化需求模板
就呢一步，已經可以減少一半嘅翻車機會。
❝你等 AI 寫 code 有幾爽，佢就可以令你修 bug 有幾崩潰。
❞
呢個唔係 AI 嘅錯，而係「你欠佢一套令佢「守規矩」嘅工作流程」。
第一部分：點解你嘅 AI 寫 code 成日「一開就死」？
由「爽」到「死」嘅 AI 寫 code 幻覺
AI 寫 code 的確快。你描述一個功能，佢 10 秒就可以生成一段睇嚟冇問題嘅 code。你複製、貼上、執行——然後出錯。或者更慘：「睇嚟行得通，但三個月後生產環境死咗」。
呢個唔係笑話，而係好多開發團隊嘅日常。
根本原因其實好簡單：「你當咗 AI 係「黑箱生成器」，而唔係「協作夥伴」」。你冇一套系統化嘅流程去約束佢、審查佢、驗證佢。
「解決方法」：一套我叫做 「「7-14-3」」 嘅工作流程——「7 步流程、14 個技能、3 條鐵律」。佢可以將 AI 寫 code 由「隨機生成」變成「可控、可預測、可維護」嘅工程化過程。
第二部分：7 步流程 —— 由需求到上線嘅 AI 寫 code「防死流水線」
一套流程，令 AI 唔再係「失控野馬」
步驟 1：精準定義（需求輸入）
「別」咁樣問 AI：
❝「幫我寫一個用戶登入功能。」
❞
「要」用結構化模板：
功能：用戶登錄
輸入：用戶名（字符串，1-20 字符）、密碼（字符串，8-32 字符，含大小寫字母和數字）
輸出：成功時返回 JWT token；失敗時返回錯誤信息
邊界條件：連續 5 次失敗，鎖定賬號 30 分鐘；密碼明文傳輸需加密
錯誤處理：數據庫連接失敗時，返回“服務暫時不可用”
「點解有效」：AI 擅長處理結構化資訊。你畀得越清楚，佢行差踏錯嘅機會越低。
步驟 2：架構先行（拆分任務）
大需求一次過餵畀 AI？呢個係炒車嘅捷徑。
正確做法：「將大需求拆成細任務」。
例如「電商系統」拆成：
用戶註冊模組 商品列表模組 購物車模組 訂單生成模組
每個模組再拆成更細嘅 function。一次只餵一個 function，「令 AI 專註解決一個具體問題」。
步驟 3：生成 code（多輪對話）
「別」直接講「生成 code」。「先叫 AI 解釋思路」：
❝「請先解釋你打算點樣實現呢個 function，包括數據結構、算法選擇同邊界條件。確認之後再生成 code。」
❞
這叫 「Chain-of-Thought 推理」。AI 喺解釋嘅過程中，會自己發現邏輯漏洞。
步驟 4：人工審查（關鍵把關）
「審查啲咩」：
邏輯正確性（AI 可能會作啲邏輯出嚟） 安全性（SQL injection、XSS 攻擊） 命名規範（有冇跟團隊約定） 註釋質量（係咪過多或者太少）
「唔使審查啲咩」：
語法錯誤（交畀 Linter） code 風格（交畀 Prettier）
❝「鐵律」：唔好信 AI 嘅第一版 code。「你對眼係最後一道防線」。
❞
步驟 5：沙箱測試（單元／整合）
叫 AI 「同時生成測試用例」：
❝「為呢個 function 寫全面嘅單元測試，覆蓋正常路徑、邊界條件同異常路徑。」
❞
然後喺隔離環境執行。「唔好喺生產環境直接試 AI code」。
步驟 6：整合回歸（code 合併）
AI code 合併到主分支之前，一定要通過：
自動化測試（CI/CD） code 審查（Code Review） 效能基準測試（避免 AI 生成低效 code）
「冇通過流水線？絕對唔合併。」
步驟 7：持續優化（回饋閉環）
記錄 AI 生成嘅成功同失敗案例。建立團隊知識庫：
邊啲 prompt 效果好？ 邊啲場景 AI 容易炒車？ 點樣修正？
「每次失敗，都係優化 prompt 嘅材料。」
第三部分：14 個核心技能 —— 令你成為「AI 寫 code 駕馭者」
唔止係「寫 prompt」，而係「寫 code 藝術」
技能 1-5：精準輸入（需求層）
「1. 結構化需求模板」
頭先已經示範過。呢個係最基本、最有效嘅技能。
「2. 示例驅動（Few-shot Prompting）」
畀 AI 2-3 個示例，等佢明你嘅「風格」：
示例 1：
輸入：用戶註冊
輸出：registerUser(username， password， email)
功能：創建新用戶，密碼加密存儲
示例 2：
輸入：用戶登錄
輸出：loginUser(username， password)
功能：驗證密碼，返回 token
現在，為“重置密碼”功能生成代碼：
「3. 角色同約束設定」
❝「你係一位資深 Java 工程師，跟 Google 編碼規範。code 一定要用 Lombok，log 就用 SLF4J。」
❞
「4. code 風格同命名約定」
❝「變數名用 camelCase，常數用 UPPER_CASE，方法名用動詞開頭。」
❞
「5. 上下文管理」
AI 對話窗口有限。當對話太長嘅時候，「總結當前成果並重置上下文」：
❝「我哋已經完成咗用戶模組。而家總結一下：用戶註冊、登入、重設密碼三個功能已經實現。接下來開始商品模組。」
❞
技能 6-10：高效協作（對話層）
「6. 分步推理（Chain-of-Thought）」
❝「請一步步解釋：你打算點樣實現呢個排序算法？先寫 pseudocode，再生成 code。」
❞
「7. 疊代修正」
唔好諗住一次就完美。「指出問題，叫 AI 重寫」：
❝「呢個 function 嘅時間複雜度係 O(n²)，請最佳化到 O(n log n)。」
❞
「8. code 審查同追問」
❝「審查呢段 code：有咩安全漏洞？效能瓶頸喺邊？可讀性點樣改善？」
❞
「9. 單元測試編寫」
❝「為呢個 function 寫全面嘅單元測試，覆蓋正常路徑、空輸入、非法輸入。」
❞
「10. code 重構同最佳化」
❝「重構呢段 code，令佢更簡潔、更易讀。跟單一職責原則。」
❞
技能 11-14：工程化落地（輸出層）
「11. 依賴管理同版本控制」
❝「明確列出呢段 code 需要嘅所有依賴同版本。用 Maven 格式。」
❞
「12. 錯誤處理同日誌記錄」
❝「加入健壯嘅錯誤處理同日誌。錯誤信息要包含上下文，日誌級別要合理。」
❞
「13. 安全性審查」
❝「檢查呢段 code 有冇 SQL injection、XSS、CSRF 風險。有嘅話，修復。」
❞
「14. 文檔生成」
❝「為呢個模組生成 API 文檔，包括參數說明、回傳值說明、使用示例。」
❞
第四部分：3 條鐵律 —— 守住 AI 寫 code 嘅底線
唔遵守呢 3 條，頭先講嘅全部都係白廢
「鐵律 1：永遠唔好信 AI 嘅第一版 code。」
AI 生成嘅 code 就好似第一稿——可能睇落唔錯，但一定有隱藏問題。「人工審查係最後一道防線」。冇審查嘅 AI code，就係一個計時炸彈。
「鐵律 2：絕對唔好將生產環境嘅 code 直接交畀 AI 改。」
AI 可能會「污染」你嘅 code base——引入唔兼容嘅依賴、改咗唔應該改嘅邏輯。「一定要喺隔離環境（沙箱、分支）入面操作」，審查之後再合併。
「鐵律 3：AI 係工具，你係設計師。」
AI 唔明業務上下文、做唔到架構決策、冇辦法幫你對 code 質量負責。「你係設計師，AI 係執行者」。將 AI 當成高級實習生——佢需要你嘅指導同監督。
寫喺最後
❝「AI 寫 code 唔係魔法，係工程。」
❞
你有幾系統化咁用佢，佢就有幾穩定咁回報你。
「第一件要做嘅事」：下次叫 AI 寫 code 之前，先寫一個結構化需求模板。就係呢一步，已經可以減少 50% 炒車嘅機會。
❝你讓 AI 寫代碼有多爽，它就能讓你修 bug 有多崩潰。
❞
這不是 AI 的鍋，是「你缺一套讓它“守規矩”的工作流」。
第一部分：為什麼你的 AI 編程總是“一跑就崩”？
從“爽”到“崩”的 AI 編程幻覺
AI 寫代碼確實快。你描述一個功能，它 10 秒就能生成一段看起來沒毛病的代碼。你複製、粘貼、運行——然後報錯。或者更糟：「看起來跑通了，但三個月後生產環境炸了」。
這不是段子，是很多開發團隊的日常。
根本原因其實很簡單：「你把 AI 當成了“黑盒生成器”，而不是“協作夥伴”」。你缺少一套系統化的流程來約束它、審查它、驗證它。
「解決方案」：一套我稱之為 「“7-14-3”」 的工作流——「7 步流程、14 個技能、3 條鐵律」。它能把 AI 編程從“隨機生成”變成“可控、可預測、可維護”的工程化過程。
第二部分：7 步流程 —— 從需求到上線的 AI 編程“防崩流水線”
一套流程，讓 AI 不再是“脱繮野馬”
步驟 1：精準定義（需求輸入）
「別」這樣問 AI：
❝“幫我寫一個用戶登錄功能。”
❞
「要」用結構化模板：
功能：用戶登錄
輸入：用戶名（字符串，1-20 字符）、密碼（字符串，8-32 字符，含大小寫字母和數字）
輸出：成功時返回 JWT token；失敗時返回錯誤信息
邊界條件：連續 5 次失敗，鎖定賬號 30 分鐘；密碼明文傳輸需加密
錯誤處理：數據庫連接失敗時，返回“服務暫時不可用”
「為什麼有效」：AI 擅長處理結構化信息。你給得越清楚，它跑偏的幾率越低。
步驟 2：架構先行（拆分任務）
大需求一次性餵給 AI？這是翻車的捷徑。
正確做法：「把大需求拆成小任務」。
比如“電商系統”拆成：
用戶註冊模塊 商品列表模塊 購物車模塊 訂單生成模塊
每個模塊再拆成更小的函數。一次只投餵一個函數，「讓 AI 專注解決一個具體問題」。
步驟 3：生成代碼（多輪對話）
「別」直接說“生成代碼”。「先讓 AI 解釋思路」：
❝“請先解釋你打算如何實現這個函數，包括數據結構、算法選擇和邊界條件。確認後再生成代碼。”
❞
這叫 「Chain-of-Thought 推理」。AI 在解釋的過程中，會自己發現邏輯漏洞。
步驟 4：人工審查（關鍵把關）
「審查什麼」：
邏輯正確性（AI 可能會編造邏輯） 安全性（SQL 注入、XSS 攻擊） 命名規範（是否遵循團隊約定） 註釋質量（是否過度或缺失）
「不審查什麼」：
語法錯誤（交給 Linter） 代碼風格（交給 Prettier）
❝「鐵律」：別信 AI 的第一版代碼。「你的眼睛是最後一道防線」。
❞
步驟 5：沙箱測試（單元/集成）
讓 AI 「同時生成測試用例」：
❝“為這個函數編寫全面的單元測試，覆蓋正常路徑、邊界條件和異常路徑。”
❞
然後在隔離環境中運行。「別在生產環境直接測 AI 代碼」。
步驟 6：集成迴歸（代碼合併）
AI 代碼合併到主分支前，必須通過：
自動化測試（CI/CD） 代碼審查（Code Review） 性能基準測試（避免 AI 生成低效代碼）
「沒通過流水線？絕不合並。」
步驟 7：持續優化（反饋閉環）
記錄 AI 生成的成功和失敗案例。形成團隊知識庫：
哪些提示詞效果好？ 哪些場景 AI 容易翻車？ 怎麼修正？
「每次失敗，都是優化提示詞的素材。」
第三部分：14 個核心技能 —— 讓你成為“AI 編程駕馭者”
不只是“寫提示詞”，而是“編程藝術”
技能 1-5：精準輸入（需求層）
「1. 結構化需求模板」
前面已經演示過。這是最基礎、最有效的技能。
「2. 示例驅動（Few-shot Prompting）」
給 AI 2-3 個示例，讓它理解你的“風格”：
示例 1：
輸入：用戶註冊
輸出：registerUser(username， password， email)
功能：創建新用戶，密碼加密存儲
示例 2：
輸入：用戶登錄
輸出：loginUser(username， password)
功能：驗證密碼，返回 token
現在，為“重置密碼”功能生成代碼：
「3. 角色與約束設定」
❝“你是一位資深 Java 工程師，遵循 Google 編碼規範。代碼必須使用 Lombok，日誌使用 SLF4J。”
❞
「4. 代碼風格與命名約定」
❝“變量名用 camelCase，常量用 UPPER_CASE，方法名用動詞開頭。”
❞
「5. 上下文管理」
AI 對話窗口有限。當對話過長時，「總結當前成果並重置上下文」：
❝“我們已經完成了用戶模塊。現在總結一下：用戶註冊、登錄、重置密碼三個功能已實現。接下來開始商品模塊。”
❞
技能 6-10：高效協作（對話層）
「6. 分步推理（Chain-of-Thought）」
❝“請一步步解釋：你打算怎麼實現這個排序算法？先寫偽代碼，再生成代碼。”
❞
「7. 迭代修正」
別指望一次就完美。「指出問題，讓 AI 重寫」：
❝“這個函數的時間複雜度是 O(n²)，請優化到 O(n log n)。”
❞
「8. 代碼審查與追問」
❝“審查這段代碼：有什麼安全漏洞？性能瓶頸在哪裏？可讀性怎麼改進？”
❞
「9. 單元測試編寫」
❝“為這個函數編寫全面的單元測試，覆蓋正常路徑、空輸入、非法輸入。”
❞
「10. 代碼重構與優化」
❝“重構這段代碼，讓它更簡潔、更易讀。遵循單一職責原則。”
❞
技能 11-14：工程化落地（輸出層）
「11. 依賴管理與版本控制」
❝“明確列出這段代碼需要的所有依賴和版本。用 Maven 格式。”
❞
「12. 錯誤處理與日誌記錄」
❝“添加健壯的錯誤處理和日誌。錯誤信息要包含上下文，日誌級別要合理。”
❞
「13. 安全性審查」
❝“檢查這段代碼有沒有 SQL 注入、XSS、CSRF 風險。有的話，修復。”
❞
「14. 文檔生成」
❝“為這個模塊生成 API 文檔，包括參數說明、返回值說明、使用示例。”
❞
第四部分：3 條鐵律 —— 守住 AI 編程的底線
不遵守這 3 條，前面都是白搭
「鐵律 1：永遠別信 AI 的第一版代碼。」
AI 生成的代碼就像第一稿——可能看起來不錯，但一定有隱藏問題。「人工審查是最後一道防線」。沒有審查的 AI 代碼，就是一顆定時炸彈。
「鐵律 2：絕不把生產環境代碼直接交給 AI 改。」
AI 可能會“污染”你的代碼庫——引入不兼容的依賴、修改不該改的邏輯。「始終在隔離環境（沙箱、分支）中操作」，審查後再合併。
「鐵律 3：AI 是工具，你是設計師。」
AI 搞不懂業務上下文、做不了架構決策、沒辦法替你對代碼質量負責。「你是設計師，AI 是執行者」。把 AI 當成高級實習生——它需要你的指導和監督。
寫在最後
❝「AI 編程不是魔法，是工程。」
❞
你有多系統化地用，它就有多穩定地回報你。
「第一件要做的事」：下次讓 AI 寫代碼前，先寫一個結構化需求模板。就這一步，就能減少 50% 的翻車概率。