跳到主要內容

精選文章

標籤

2026和AI一起寫程式 - 8. 和 AI 協作的軟體開發流程

前篇：2026和AI一起寫程式 - 7. Steve Yegge 的 AI 協作程式的八個階段



( 圖 by Midjourney )


最近在想如何一人用單一AI 透過 browser 方式溝通, 來完成專案, 

先記錄一下草擬的問題, 和 Grok AI 的回答, 之後找個小題目來實作看看^^

==

問題：

請參考 Steve Yegge 和 Thomas Dohmke 的想法, 幫忙設計一套個人搭配軟體專案的開發流程：


語言：kotlin

環境：

   在 MacBook Pro 上

   Github : 用來存取專案

   IntelliJ IDEA  社群免費版 ：當編輯器

   AI 交流 : 透過 chrome browser 和 AI 如 Perplexity Pro 選 ChatGPT 5.2 + Thinking

                 (但有檔案上傳限制)

   Local AI : ollama + GLM-4.7


第ㄧ：一開始需求怎麼提給ＡＩ

  如何定義 intent(意圖）, constraints(限制）, outcomes(結果）

第二：Github 上開專案, Local 端 git clone

          是否可以請 AI 產生 README.md, 人要先想好哪些資料提供給 AI ? 

第三： 請 AI 先當架構師, 定義架構: 如 MVVM 架構, 有哪些物件, 物件如何溝通, 

            有哪些現成 package 套件可以提供給 AI使用?

            是否可以請 AI 先產生UML / mermaid 圖?

第四：各物件實作

第五： 驗證, 請 AI 寫各物件的測試

           有問題是否開 PR 解決？

第六：專案執行測試反饋

…


參考 Claude 16 AI agent 寫 C compiler 的實例, 各AI 角色要如何定義分工?

因為是個人, 一次只有對一個 AI 手動下指令, 整理溝通, 請依此設計一套個人對單一 AI agent 的協作方案流程


===

Grok AI 的回答：


是的，這是一套非常實用的個人 Kotlin 開發流程設計。 我已參考 Steve Yegge 的「Vibe Coding」（高層次對話式指導、把 AI 當團隊帶、小塊迭代 + 驗證迴圈、從 coder 轉為 orchestrator）和 Thomas Dohmke 的 agentic 想法（GitHub 作為協作中樞、AI 產生可審核的 PR/變更、追蹤 reasoning），同時借鏡 Claude 多代理建 C compiler 的分工概念。

因為你是個人單一 AI 操作（手動切換 Chrome 的 Perplexity/ChatGPT 或本地 Ollama GLM-4），我設計成單一 AI Agent 模擬團隊的方案：透過明確的角色 prompt + 持續上下文參照，模擬 Architect、Developer、Tester、Reviewer、Project Manager 等角色分工。這樣不用同時開多個 AI，就能維持一致性。

核心原則（Yegge + Dohmke 精神）

  • Vibe Coding：給高層次「vibe」（感覺）而非細部指令，例如「像資深工程師一樣做出 production-grade、可維護、易測試的程式碼」。
  • 小步 + 反饋迴圈：一次只做一個小任務（模組/功能），馬上驗證、測試、review。
  • GitHub 為中心：用 Issues 或簡單 tasks.md 追蹤任務（可模擬 Yegge 的 Beads），分支開發，PR 自審。
  • 單一 AI 團隊模式：一個主要聊天視窗（建議用 Perplexity 或 ChatGPT 做長上下文，本地 Ollama 做快速迭代）。每次 prompt 開頭指定角色，並附上關鍵 artifact（architecture.md、tasks.md）。
  • 工具搭配：IntelliJ Community 編輯 + 除錯；GitHub 版控；檔案大時用本地 Ollama（無上傳限制）。

完整個人開發流程

第 1 步：需求定義（Intent / Constraints / Outcomes）

這是最重要的一步，避免 AI 亂猜。

你先準備的資料（手寫或打字）： 

- Intent（意圖）：專案要解決什麼問題？目標用戶？核心價值。 

- Constraints（限制）：Kotlin + MVVM、平台（Android / JVM / KMP？）、效能、依賴限制、不想用的技術等。 

- Outcomes（結果）：成功標準（e.g. 通過所有單元測試、UI 流暢）、可交付物、non-functional（可測試性、可維護性、安全性）。


Prompt 範例（給 ChatGPT / Perplexity）：

你現在是我的 AI 軟體團隊（Product Owner + Architect）。專案是 Kotlin [簡述類型，例如 Android App]。

Intent: [貼上]
Constraints: [貼上，包括必須用 MVVM]
Outcomes: [貼上]

請先幫我：
1. 細化成 User Stories + Acceptance Criteria
2. 建議整體開發計劃，分成 8-12 個小任務（適合一人開發）
3. 列出風險與假設

把輸出存成 requirements.md，commit 到 repo。這會成為後續所有 prompt 的參考文件。

第 2 步：GitHub 開專案 + Local Clone + README

  • 手動在 GitHub 建立 repo（建議用 Kotlin Gradle template）。
  • Local：git clone → 開 IntelliJ 匯入。
  • 請 AI 產生 README.md

你提供給 AI 的資料： 

- 專案名稱、簡短描述 

- Tech stack（Kotlin、Gradle、MVVM、IntelliJ） 

- 從第 1 步的 Intent/Outcomes 

- 任何已知的架構方向

Prompt 範例：

Act as Technical Writer + Senior Engineer。
根據以下資訊，產生專業的 README.md（使用 Markdown，最好有 badge、目錄、安裝步驟、架構簡述）：

[貼上專案描述 + tech stack + requirements.md 摘要]

複製輸出成 README.md，commit & push。

小建議：可以再請 AI 產生 .gitignore 和基本 build.gradle.kts（包含 Kotlin 版本、plugin）。

第 3 步：請 AI 當架構師（Architecture）

Prompt 範例：

Act as Principal Software Architect（專精 Kotlin MVVM / Clean Architecture）。

專案需求見 requirements.md。
請定義：
- 整體架構（建議 MVVM + Domain Layer + Repository Pattern）
- 主要物件與職責（ViewModel、UseCase、Repository、Model、DataSource 等）
- 物件間溝通方式（StateFlow / SharedFlow、Events、Coroutines）
- 推薦現成套件（2026 年主流）：
  - DI：Koin（輕量）或 Hilt
  - Async：Kotlin Coroutines + Flow
  - Network：Ktor Client 或 Retrofit
  - DB：Room（Android）或 SQLDelight（KMP）
  - Testing：Kotest + Turbine + MockK
  - 其他：Kotlinx Serialization、Coil 等
- 生成 Mermaid 圖：Class Diagram、Component Diagram、關鍵 Sequence Diagram

輸出全部用 Markdown 格式，方便直接存成 architecture.md。

把輸出存成 architecture.md（含 Mermaid 圖），commit。GitHub 會自動 render Mermaid。

第 4 步：各物件實作（Incremental Development）

用分支開發：

git checkout -b feature/xxx

每次只做一個小任務（e.g. 一個 Repository、一個 UseCase、一個 ViewModel）。

Prompt 範例（Coder 角色）：

Act as Senior Kotlin Developer。

參考 architecture.md 和 requirements.md。
請實作 [具體物件名稱，例如 AuthRepository]。

要求：
- 遵循 MVVM + Clean Architecture
- 使用推薦套件
- 寫乾淨、可讀的程式碼 + KDoc
- 輸出完整可複製的程式碼檔案內容

如果需要新增 dependency，請同時給 build.gradle.kts 片段。

貼到 IntelliJ → 修正 import / 小錯誤 → 手動測試 → commit（可請 AI 幫寫 commit message）→ push → 開 PR 自審。

第 5 步：驗證與測試（Tester + Reviewer）

寫測試 Prompt：

Act as QA Engineer。
為 [class 名稱] 寫完整單元測試。
使用 Kotest + Turbine（Flow testing）+ MockK。
涵蓋 happy path、error cases、edge cases。

Code Review Prompt：

Act as Senior Code Reviewer。
審核以下程式碼（或 PR diff）：
[貼程式碼或描述變更]

請指出：
- 架構符合度
- 潛在 bug、安全問題、效能問題
- 可讀性與最佳實踐建議
- 重構建議

有問題 → 開新 branch 或直接 fix → 再次 review。

模擬 PR：在 GitHub 開 PR（即使 solo），把 AI review 意見貼到 PR comment，當作記錄。

第 6 步：執行、測試、反饋與迭代

  • 在 IntelliJ 執行專案（Run / Debug）。

  • 手動驗證功能。

  • 發現問題 → 截圖 / log / 描述 → 貼給 AI：「Fix this issue: [描述]，參考 architecture.md」

  • 定期請 AI 當 Project Manager：

    Act as Project Manager。
參考所有文件和目前進度，總結：
- 已完成項目
- 剩餘任務優先序
- 風險與建議

單一 AI Agent 的角色分工方案（模擬 Claude 16 代理）

在主要聊天視窗建立「系統 prompt」或每次開頭寫：

推薦的統一 Team Prompt 開頭：

你是我個人的 AI 軟體工程團隊（模擬多角色分工）。我會明確指定角色，你必須嚴格遵守該角色，並一>直參照之前的文件（requirements.md、architecture.md、tasks.md）。

角色定義：
- Architect：架構設計、圖表
- Coder：寫生產級 Kotlin 程式碼
- Tester：寫測試 + 測試策略
- Reviewer：程式碼審核 + 改善建議
- Project Manager：總結進度、規劃任務
- Technical Writer：文件、README、commit message

當我說「Architect:」就切換角色，以此類推。永遠保持一致性。

這樣你一次只對一個 AI 下指令，但它能「記得」自己是團隊。

任務追蹤（模擬 Beads）： 

- 簡單做法：維護一個 tasks.md（用 Markdown checklist + 依賴關係）。 

- 進階：安裝 Yegge 的 Beads（Mac 很容易，git clone 後 build），讓 AI 自己「file a bead」來追蹤長期任務。 

- 或直接用 GitHub Issues + Projects。

額外實用Tips

  • AI 切換策略：複雜設計 / review 用 ChatGPT 或 Perplexity（推理強）；大量程式碼生成 / 快速 debug 用本地 Ollama GLM-4（無限制、快）。
  • 檔案上傳限制：大專案時，先 commit 後讓 AI 讀 GitHub 連結（如果支援），或只貼關鍵片段 + 描述。
  • IntelliJ 發揮：善用 refactoring、debugger、Gradle tool window。AI 產生的程式碼貼進去後，讓 IDE 幫忙優化。
  • 頻率：每天小 commit（5-10 次），保持 momentum。
  • 生產力加成：遵循 Yegge 的「vibe」——當 AI 卡住時，告訴它「用更 production-grade 的方式重寫」或「像 Google 資深工程師一樣處理」。

這套流程已經很接近「一人團隊」的最高效率。你可以從一個小專案開始試跑一輪，然後告訴我哪一步不順，我再>幫你微調 prompt 或加入新角色。

準備好開始哪個步驟了嗎？或你有特定專案類型（Android / Backend / KMP）想更細化？

標籤：

留言

張貼留言

熱門文章