ai-first-engineering

ai-first-engineering 技能總覽

ai-first-engineering 是做什麼用的

ai-first-engineering 技能是一套精簡的營運模型，適合那些由 AI agent 承擔相當比例實作工作的團隊。它不是程式開發框架，也不是自動化套件。它的目的，是協助你調整工程流程、架構、審查標準與測試預期，讓生成的程式碼更安全、也更容易上線。

最適合的使用者與要完成的工作

這個 ai-first-engineering 技能適合工程主管、Staff Engineer、平台團隊，以及以 agent 為主的產品團隊，去回答一個很實際的問題：「當程式碼生成變得很便宜時，會發生什麼改變？」 其核心任務，是為規劃、架構、審查與驗證建立標準，避免速度提升最後變成品質漂移。

這個技能的差異在哪裡

不同於一般「把 prompt 寫得更好」的建議，ai-first-engineering 聚焦的是團隊的營運規則：重視規劃品質勝過打字速度、重視 eval 覆蓋勝過主觀信心、重視行為導向的 code review 勝過樣式評論。它最強的差異化在於對 agent 友善的架構：明確邊界、穩定合約、型別化介面，以及可決定性的測試。

什麼情況下這個技能還不夠用

如果你期待 ai-first-engineering 直接提供可執行工具、按語言分類的清單，或深入的實作範例，就不適合安裝它。來源內容本來就是一份精簡的政策型指南。當你已經在使用 coding agents，並且需要制定 Agent Standards、code review 與測試決策標準時，它才最有價值。

如何使用 ai-first-engineering 技能

安裝情境與閱讀起點

請照你平常的 skills 工作流程，從 affaan-m/everything-claude-code 加入 ai-first-engineering 技能，然後先閱讀 skills/ai-first-engineering/SKILL.md。這個技能沒有 helper scripts、參考文件或規則檔，所以幾乎所有價值都集中在那一份文件裡。請把它當成決策視角來讀，不是逐步安裝教學。

ai-first-engineering 技能需要哪些輸入

這個技能在你提供以下資訊時效果最好：

• 團隊設定：repo 規模、語言、部署風險
• agent 的使用方式：autocomplete、PR 生成、完整任務執行
• 目前痛點：測試薄弱、review 雜訊太多、回歸、責任歸屬不清
• 期望成果：review rubric、架構標準、測試門檻、招募訊號

弱 prompt：Apply ai-first-engineering to our team.

較強的 prompt：Use the ai-first-engineering skill to draft Agent Standards for a TypeScript service team using PR-generating agents. We need architecture rules, code review criteria, and minimum test requirements for medium-risk backend changes.

把模糊目標轉成可用的 prompt

ai-first-engineering 的一個好用方式是：

1. 先講清楚範圍：團隊、repo，或工作流程。
2. 說明 AI 會在哪裡帶來風險。
3. 要求的是標準，不是口號。
4. 指定輸出格式要能直接採用。

prompt 結構範例：

• Use the ai-first-engineering skill.
• Context: 12 engineers, Python/TypeScript monorepo, agents create first-draft PRs.
• Problems: hidden coupling, weak regression tests, review time spent on style.
• Deliver: architecture principles, review checklist, testing standard, and rollout guardrails.

這樣得到的輸出，會比泛泛地問 AI engineering best practices 好得多。

實務工作流程與決策建議

建議在撰寫詳細流程文件之前，就先使用 ai-first-engineering。實際上可以這樣做：

1. 先讀 SKILL.md。
2. 從中擷取最符合你瓶頸的段落：流程、架構、review、招募、測試。
3. 把內容轉成符合你 repo 的政策語言。
4. 先在一個團隊或一個服務上試行。
5. 再根據真實的 PR 失敗案例與漏網缺陷調整。

多數使用者應該先從 Architecture Requirements、Code Review in AI-First Teams 和 Testing Standard 開始。這些章節最能快速提升輸出品質，因為它們直接影響 agent 能安全產生什麼，以及 reviewer 必須驗證什麼。

ai-first-engineering 技能 FAQ

如果來源很短，ai-first-engineering 值得安裝嗎？

如果你想要的是一個精簡、可用來建立標準的視角，而不是一本厚手冊，那答案是肯定的。ai-first-engineering 技能把重點集中在最有槓桿的轉變：架構清晰度、可量化驗證，以及以行為為中心的 review，因此能省下時間。如果你需要的是模板或自動化，它就會顯得太輕量。

這和一般關於 AI coding 的 prompt 有什麼不同？

一般 prompt 常會回傳很通用的生產力建議。ai-first-engineering 技能則提供更有立場的框架：提高規劃品質、以明確介面為設計目標、review 系統行為、並提高生成程式碼的測試嚴謹度。這讓它在政策、流程與 Agent Standards 工作上更實用。

ai-first-engineering 技能適合新手嗎？

部分適合。概念本身清楚，但最佳使用者通常已經理解軟體交付中的取捨。新手仍然可以用，但不要把它當成完整教條。它最適合能把原則轉成具體 repo 規則的主管或資深工程師。

什麼情況下不該使用 ai-first-engineering？

如果你主要需要的是寫程式協助、特定框架的實作指引，或安裝自動化，就先不要用它。若你的團隊幾乎還沒開始使用 AI，也不建議先用；這個技能假設 agents 已經明顯影響交付，因此流程與架構需要跟著調整。

如何改進 ai-first-engineering 技能

提供具體的營運限制

最大的品質提升，來自你補上來源文字不知道的限制：受監管產品還是低風險產品、monolith 還是 services、型別化 stack 還是動態語言、測試成熟度、以及發布風險。當模型能把大原則轉成具體標準時，ai-first-engineering 會更可執行。

要求團隊能直接採用的輸出

不要只問 thoughts。請直接要求：

• pull request review rubric
• 新模組的架構要求
• 依變更類型區分的最低測試期待
• AI-first 工程師的招募或面試訊號

這樣就能把 ai-first-engineering 從概念型指南，變成可以直接貼進 AGENTS.md、CONTRIBUTING.md 或內部工程文件的內容。

注意常見失敗模式

最常見的壞輸出，是像 ensure quality 或 use good tests 這類模糊政策語言。你要逼它更具體：什麼算穩定合約、哪些 edge cases 必須明確斷言、哪些項目 review 時可以忽略因為自動化已經覆蓋、以及哪些變更需要 integration checks 或 rollout safeguards。

第一次輸出後要迭代

拿到第一版後，請用真實案例去修正 ai-first-engineering 的輸出：

• 一個最近表現良好的 PR
• 一次失敗的發布或回歸
• 一個有隱性耦合的架構區域

請模型根據這些案例修訂標準。這樣可以看出你目前流程在哪裡太抽象，也能幫助把 ai-first-engineering 技能變成真正可落地的 Agent Standards，而不只是泛用原則。