2026和AI一起寫程式 - 實戰篇 - 1 和 AI PM 討論
前篇：2026和AI一起寫程式 - 8. 和 AI 協作的軟體開發流程
( 圖 by Midjourney )
參考前篇, 我開始用 browser 和 Perplexity Pro + GPT 5.2 + Thinking 溝通,
的確令我驚艷！
一開始我先下這段 prompt
===
你是我個人的 AI 軟體工程團隊（模擬多角色分工）。我會明確指定角色，你必須嚴格遵守該角色，並一>直參照之前的文件（requirements.md、architecture.md、tasks.md）。
角色定義：
- Architect：架構設計、圖表
- Coder：寫生產級 Kotlin 程式碼
- Tester：寫測試 + 測試策略
- Reviewer：程式碼審核 + 改善建議
- Project Manager：總結進度、規劃任務
- Technical Writer：文件、README、commit message
當我說「Architect:」就切換角色，以此類推。永遠保持一致性。
===
接著下 "PM: " 開始和 PM 討論,
---
我目前只有一個初步的構想:
專案名稱：CurrencyViewer
Github: https://github.com/neojou/CurrencyViewer (目前可以 clone 但是空的）
環境：MacBook Pro Desktop
開發：使用 Kotlin Component Multiplatform
初期可以在 MacBook Pro 的 Desktop 上執行
同時支援 wasmJS , 可以透過 browser 在 GitHub.io 上看到
想法：執行時, 會主動連到 https://www.google.com/finance/quote/USD-JPY ,
只顯示附圖的畫面, 並按其原本網頁設計幾秒鐘 refresh 相關數字和線圖畫面
請以 PM 的角色, 建議開發計劃, 分配任務給上述的軟體團隊;
你如果需要和團隊成員溝通, 也可以告訴我, 我來作為溝通的橋樑;
我們先來製作相關 md 檔案, 先從 requirements.md 開始,
要建立這份文件, 你這邊還需要什麼資料？還是已經可以直接製作出來？
---
PM 會主動告訴我要怎麼做軟體流程開發
==
原本想簡單地做一個類似看 Google Finance 的 美元/日圓 匯率圖,
直接抓 Google Finance 網頁上的, 但 AI 會主動告訴我這方法有顧慮：
“ Google 的《Terms of Service》明確禁止以自動化方式存取其服務內容，若違反網頁上的 machine‑readable 指示（例如 robots.txt）會構成違規使用，並可能導致你的存取被限制或終止。 另外條款也提到若你「抓取不屬於你的內容」等行為，Google 可能會採取停用/終止存取等措施。”並介紹合法免費的查詢匯率的 API, 最後找到這個非即時, 適合每日一筆的 Frankfurter
=== Grok AI 介紹 ===
Frankfurter 是一個非常受歡迎的免費、開源匯率資料 API，主要提供來自歐洲中央銀行 (ECB) 的官方參考匯率資料。
官方網站與 API 端點
- 官方網站：https://frankfurter.dev/ （以前也用過 frankfurter.app，但目前主要導向 .dev）
- 公開 API 基底網址：https://api.frankfurter.dev
主要特色與功能
- 資料來源：主要來自歐洲央行 (ECB) 的官方參考匯率，每天更新一次（工作日約 CET 16:00 左右更新前一工作日匯率）
- 基準貨幣預設為 EUR（歐元），但可以指定其他貨幣作為 base
- 支援貨幣數量：約 30–35 種（ECB 官方清單為主，例如 USD, JPY, GBP, CNY, TWD, KRW, CAD, AUD 等常見貨幣都有，但不像某些商業 API 涵蓋 170+ 種小眾貨幣）
- 完全支援瀏覽器直接呼叫（CORS 允許），適合前端 / React / Vue / 手機 App 直接使用
- 不需要註冊、不需要 API Key
回傳格式都是標準 JSON，非常乾淨好處理。
是否免費、合法、可用於個人/商業程式開發>？
是的，完全免費且合法可用於個人與商業用途。
官方 FAQ 明確寫道： - Is the API free for commercial use? Yes, absolutely. - Does the API have any call limits? There are no limits.
也就是說： - 沒有每日/每月呼叫次數上限 - 沒有強制加 logo 或 attribution 的要求 - 可以用在商業產品、App、SaaS、網站、小工具等
但有實際使用上的「軟性提醒」
雖然沒有硬性 rate limit，但官方有提到： > 對於非常高流量的應用，建議直接從歐洲央行官方資料源抓取（他們提供 CSV / XML），會比透過 frankfurter.dev 代理更有效率，也能減輕公共 API 伺服器的負擔。
換句話說： - 個人、小型專案、中型商業應用 → 完全沒問題，直接用就好 - 每天幾萬到幾十萬次請求的超高流量服務 → 建議考慮自架 Frankfurter（Docker 一鍵部署很簡單）或直接連 ECB 原始資料
| 需求 | Frankfurter 是否適合？ |
|---|---|
| 完全免費 | 是 |
| 不用註冊 / Key | 是 |
| 前端直接呼叫 | 是（強項） |
| 商業使用合法 | 是 |
| 沒有任何次數限制 | 是（官方說法） |
| 需要超多小眾貨幣 | 不太適合（只有 ECB 支援的約 30+ 種） |
| 需要分秒級即時匯率 | 不適合（每天更新一次） |
| 高流量商業產品 | 可接受，但極高流量建議自架或換其他方案 |
====
完成了 requirements.md 和 tasks.md
看了 tasks.md 真是佩服地五體投地, 果然是 PM , 一般軟體工程師還真寫不出來...
===
什麼是 Sprint
Sprint 是一個「固定時間盒（time-box）」的開發迭代週期：在這段時間內，團隊承諾完成一小批 明確的工作項目，並在結束時交付一個可檢視（最好是可用/可展示）的成果。
放在 tasks.md 裡代表什麼
在 tasks.md 我用 Sprint
來把任務分批，讓你每一批都有清楚的：
- 目標（Sprint Goal）：這一批完成後能看到什麼成果（例如：可在 Desktop 跑起來並畫出 30 天線圖）。
- 範圍（Sprint Backlog）：這一批要做的 tasks 清單，避免同時開太多線導致失焦。
- 驗收（DoD/AC）：到 Sprint 結束時你用什麼標準接受/拒絕這批成果。
Sprint 會多長
常見是 1–4 週固定長度；我們這個小型 MVP（你一人 + AI 團隊協作）通常用 3–7 天一個 Sprint 最好控，能快速迭代並降低風險。
對 CurrencyViewer 的實務建議
- Sprint 0：把「能建置、能部署、能跑起來」這種基礎工程先打通（腳手架/Pages/placeholder）。
- Sprint 1：把 v1.6 的核心價值做完（Frankfurter 抓資料 + 30 天線圖 +
hover tooltip + 錯誤狀態）。
這樣每個 Sprint 結束你都有可工作的增量，而不是最後才一次整合爆炸。
===
什麼是 MVP
MVP 是「最小可行產品」（Minimum Viable Product）：用最少但足以可用的功能做出第一版，目的是盡快驗證核心價值與需求是否成立，再依回饋迭代。
放到 專案CurrencyViewer 的意思
MVP 是「能在 Desktop + Web 跑起來，顯示 USD/JPY latest 數字與匯率日期、最近 30 天線圖、以及 hover 顯示日期+匯率」，其他像自動刷新、多幣別、更多區間切換都先不做，避免把範圍擴太大。===
並且定了三個 Issues 和 Sprint 0 Milestone
https://github.com/neojou/CurrencyViewer/issues/1
https://github.com/neojou/CurrencyViewer/issues/2
https://github.com/neojou/CurrencyViewer/issues/3
感覺這樣開發真的很有流程制度, 下回繼續
留言
張貼留言