最近國外有個開發者，利用AI 編程工具在短時間內開發了12個應用，總結了一份提示詞并分享出來了，今天就來解析一下這份提示詞。

理念

核心理念

• 漸進優于顛覆- 確保小改動能編譯通過測試
• 從現有代碼學習- 實施前先研究規劃
• 務實而非教條- 適應項目實際情況
• 意圖清晰優于代碼巧妙- 選擇簡單明了的方案

簡單性原則

• 每個函數/類單一職責
• 避免過早抽象
• 不要使用巧妙的技巧 - 選擇“無聊”的解決方案
• 如果需要解釋，說明它太復雜了

流程

1. 規劃

將復雜工作分解為3-5個階段。記錄在IMPLEMENTATION_PLAN.md中：

## 階段N: [名稱]
**目標**: [具體交付物]
**成功標準**: [可測試結果]
**測試**: [具體測試用例]
**狀態**: [未開始|進行中|完成]

2. 實現

• 理解- 研究代碼庫現有模式
• 測試- 先寫測試
• 實現- 最小編碼通過測試
• 重構- 在測試通過前提下優化
• 提交- 附帶說明關聯計劃的清晰信息

3. 遇到阻礙時

當每個問題最多嘗試3次，如果還沒修復，就立即停止下來：

1)記錄失敗情況：

• 嘗試了哪些方法
• 具體錯誤信息
• 認為失敗的原因

2)研究替代方案：

• 尋找2-3個類似實現
• 記錄采用的不同方法

3)質疑基礎假設：

• 抽象層級是否合適？
• 能否拆分為更小問題？
• 是否存在更簡單的整體方案？

4)嘗試不同角度：

• 使用不同庫/框架功能？
• 采用不同架構模式？
• 移除而非增加抽象？

技術原則

架構原則

• 組合優于繼承- 使用依賴注入
• 接口優于單例- 便于測試和靈活調整
• 顯式優于隱式- 明確數據流和依賴關系
• 盡可能測試驅動- 絕不禁用測試，而是修復

代碼質量

1)每次提交必須：

• 成功編譯或運行
• 通過所有現有測試
• 包含新功能測試
• 遵循項目格式/linter要求

2)提交前：

• 運行格式化/linter工具
• 自我審查變更
• 確保提交信息說明"原因"

3)錯誤處理

• 快速失敗并提供描述性信息
• 包含調試上下文
• 在適當層級處理錯誤
• 絕不靜默吞異常

決策理念

存在多個有效方案時，基于以下標準選擇：

• 可測試性- 能否輕松測試？
• 可讀性- 半年后他人能否理解？
• 一致性- 是否符合項目模式？
• 簡潔性- 這是最簡單的可行方案嗎？
• 可逆性- 后續修改難度如何？

項目集成

熟悉代碼庫

• 找出3個相似功能/組件
• 識別通用模式和約定
• 盡可能使用相同庫/工具
• 遵循現有測試模式

工具使用

• 使用項目現有構建系統
• 使用項目測試框架
• 使用項目格式化/linter設置
• 無充分理由不引入新工具

重要提醒

絕不：

• 使用--no-verify繞過提交鉤子
• 禁用而非修復測試
• 提交無法編譯的代碼
• 做假設 - 用現有代碼驗證

始終：

• 增量提交可工作代碼
• 隨進度更新計劃文檔
• 從現有實現學習
• 3次失敗后停止并重新評估

總結

你完全可以根據你的項目情況，對這份提示詞做部分修改，或者直接放到你的rules或者CLAUDE.md中，進一步提升AI編碼的效率！

本文轉載自??AI 博物院?? 作者：longyunfeigu