當產品開始持續迭代，我發現有些事情不是某一次功能的需求。
而是我希望 AI 在這個專案裡，一直遵守的工作方式。
例如 UI 有一些我希望維持的原則。
版本更新有一些固定要同步處理的事情。
程式修改之後，也有一些我希望它一定要確認的事項。
這些事情每次在對話裡講一次，好像沒有什麼。
但當產品開始一直修改之後，我突然發現：
為什麼這些事情我要一直講？
所以我開始嘗試另外一種做法。
把這些「我希望 AI 記住的工作習慣」，直接寫進專案裡。
一開始和 AI 一起開發的時候，我常常會在對話裡補充很多事情。
「這裡不要用 Icon。」
「版本號改了之後，記得同步更新其他地方。」
「這個畫面希望保持簡潔。」
這些事情每次講一次，好像沒有什麼。
但當產品開始一直修改之後，我才發現：
這些其實不是某一次功能的需求。
而是我希望 AI 在這個專案裡，一直遵守的工作方式。
如果每次都重新說一次，久了其實很容易漏掉。
所以我開始想：
有沒有什麼方式，可以讓這些規則直接跟著專案走？
我在 Money Snap 裡建立了 copilot-instructions.md。
它不是某一個功能的規格。
也不是告訴 AI：
「這一次要幫我完成什麼。」
比較像是在告訴它： 如果你要繼續和我一起做這個專案，請用這樣的方式工作。
例如 UI 有一些我希望一直維持的原則。
版本更新有一些固定要同步處理的事情。
程式修改之後，也有一些我希望它一定要確認的事項。
這些東西以前散落在不同的對話裡。
現在我把它們放進專案。
於是下一次開始新的功能時，我不用再重新提醒一次。
我不是只在寫程式，而是在慢慢建立一個「和 AI 一起工作的環境」。
規格是在說： 這一次我們要做什麼。
Instructions 比較像是在說： 我們平常應該怎麼做。
例如今天要做自訂面額。
規格會告訴 AI：
「自訂面額應該有哪些功能。」
但 Instructions 不需要知道這個功能。
它只需要告訴 AI：
「在這個專案裡，UI 應該遵循什麼原則。」
「版本更新時，哪些地方需要一起確認。」
所以我把兩者分開看。
產品需求
↓
這一次要做什麼？
開發規格
↓
這一次要怎麼完成？
Instructions
↓
平常應該怎麼工作？
這樣一來，AI 不只是知道「我要做什麼」。
也開始知道：
「在這個專案裡，我應該怎麼做。」
這可能是我覺得這次最有意思的地方。
我沒有每一次都跟 Copilot 說：
「請先讀 instructions。」
「請記得我們的 UI 規則。」
我只是照原本的方式工作。
但在過程中，我開始看到一些原本需要自己提醒的事情，變成它工作時會一起考慮的事情。
這種感覺和前面「讓 AI 接得回來」很像。
只是上一個階段是在解決： AI 能不能理解現在的專案？
這一次則開始變成： AI 能不能理解我希望它怎麼工作？
如果今天真的有一個新的工程師加入專案。
我不會希望每一次 Code Review 都重新告訴他：
「這裡有一些固定的版本更新流程。」
「這個專案有一些特別的限制。」
這些東西應該被寫下來。
因為寫下來之後，它就不只是某一個人的記憶。
而是團隊共同遵守的規則。
Instructions 很像是在幫 AI 建立一份「這個專案的工作文化」。
它不是產品需求。
也不是技術文件。
而是： 我們在這個專案裡，習慣怎麼工作。
我覺得 Instructions 最有價值的地方，不是讓 AI 突然變得更聰明。
而是：
減少我一直重複說同一件事情的時間。
以前我可能會在對話裡一直補充：
「這裡不要這樣。」
「那個不要引入。」
「改完記得同步。」
「這個要測試。」
現在這些東西如果已經寫進專案，我就可以把注意力放到真正的產品問題。
例如：
「這個 UI 我用起來不順。」
「這個流程是不是可以再短一點？」
「這個情境是不是還會出錯？」
而不是一直提醒 AI 基本的工作規則。
這個差異看起來很小。
但當開發開始一直迭代，我覺得它會慢慢累積成很大的差別。
到了這裡，我開始把前後兩個階段連在一起看。
第一個階段，是讓 AI 理解專案。
所以我需要留下：
讓它可以重新找到目前的位置。
第二個階段，是讓 AI 理解我的工作方式。
所以我開始留下：
前者是在回答： 「我們現在在哪裡？」
後者是在回答： 「我們要怎麼一起工作？」
我覺得這兩件事情開始接起來之後，AI 才比較像是一個可以長期合作的協作者。
我現在還不會說：
「寫了 Instructions 之後，AI 就完全不會犯錯了。」
沒有這麼神奇。
它還是可能理解錯。
還是可能漏掉一些事情。
還是需要我實際操作、Review、測試。
甚至有時候也會發現：
原本寫在 Instructions 裡面的規則，可能根本不適合現在的產品。
那就再修改。
所以 Instructions 本身也變成一個會持續迭代的東西。
這和產品其實很像。
我的 AI Workflow 也會慢慢從一開始的幾個規則，變成越來越適合這個專案的工作方式。
它要知道現在的專案在哪裡。
知道下一步要往哪裡走。
知道哪些東西不能被破壞。
也知道我希望它用什麼方式工作。
而我則繼續負責最重要的事情：
實際使用。
觀察。
判斷。
發現問題。
做產品決定。
然後再把這些新的理解，繼續放回專案裡。
AI 協作好像慢慢變成了一個循環：
產品 ↓ 我實際使用 ↓ 發現問題 ↓ 和 AI 一起修改 ↓ 測試 ↓ 留下新的規則與經驗 ↓ 下一次開發 ↓ 再繼續迭代
這可能才是我現在真正想建立的東西。
可以逐漸理解產品、理解工作方式，然後和我一起持續把產品往前推的 AI 協作者。
而我也正在一邊做產品，一邊建立自己的 AI 協作方式。
]]>做 Money Snap 的時候，我已經慢慢建立了 PRD、開發規格、工作計畫、測試與版本文件。 一開始只是覺得這樣比較有條理。
但當產品開始迭代，版本越來越多，我才發現這些文件真正的價值： 它們讓 AI 可以重新理解現在的專案。
這和記住上一段對話不太一樣。
今天可能在電腦前面開發，明天換一台電腦。 這一次對話已經很長，下一次可能重新開一個 Copilot Session。 版本也會一直往前走。
如果每一次都要重新跟 AI 解釋「我們現在做到哪裡」，那 AI 協作其實很難真正持續下去。
只要產品目前的狀態有被留下來，AI 就有機會從現在繼續往下走。 AI 不一定要記得我們昨天聊了什麼，但它必須看得懂我們今天留下了什麼。 這可能才是跨裝置、跨對話還能繼續工作的關鍵。 而且不只是接著寫程式，而是接著往「正確的方向」開發。
以前像是在「聊天」，現在比較像是在「交接」， 我現在在意的是「上下文能不能被接續」。
我會讓專案裡留下：
這些東西看起來很像文件管理，其實也是 AI 協作的「上下文」。 讓 AI 回到專案本身，而不是只依賴上一段對話。
當然，這不代表 AI 每次重新讀專案，就一定會做對。 所以我現在比較在意的是，不要讓它急著動手。
先理解，再開始動手。
哪些東西已經有了？ 哪些地方需要修改？ 哪些功能彼此有關？ 哪些地方可能會影響原本的行為？ 然後再開始整理工作。
這樣做的好處是： 我不需要自己把整個專案重新講一次。 AI 也不需要猜，它可以直接從現在的程式和文件裡找答案。
實際開發最有趣的地方，往往不是完全照著規格完成。 而是：我打開畫面之後，突然發現這裡怪怪的。
例如 CSV 匯入。 一開始看規格，好像就是把 CSV 匯進來。 但真的拿檔案測試之後，才會發現，有些實際使用情境，和原本想像的不太一樣。
這些事情很難在第一次寫規格的時候全部想到。
所以後來我的工作方式變成： 發現問題。 把問題描述給 AI。 讓 AI 回頭去找是哪一段程式造成的。 修改。 再測。 然後我再用一次。
規格已經寫好 UI 了，那照著做應該就差不多。 但真的開始使用之後，UI 很難一次定案。
一個按鈕的位置。 一段提示文字。 一個設定要不要預設展開。 手機上是不是太擠。 桌機上是不是又太空。
這些事情，很少能在第一次規格裡就全部想清楚。 而且有些問題不是「不好看」。 而是「用起來不順」。 這兩件事情差很多。
例如後來做自訂面額時，原本的操作方式比較像一個設定面板。 實際使用之後，我希望它改成主開關，讓使用者一眼就知道現在到底有沒有啟用自訂面額。 所以我把需求告訴 AI。
它不是只把 UI 換一個樣式而已。 而是重新把 UI 的操作方式、設定狀態，以及背後的計算邏輯一起調整。 主開關關閉，就使用預設面額。 主開關開啟，才使用自訂設定。 使用者的偏好也要能被記住。
所以 UI 的改動，最後還是回到了產品邏輯。
這也是我越來越在意的地方：好的 UI 調整，不只是把畫面改漂亮，而是畫面、互動、程式邏輯和驗收標準一起改。
持續修改有一個很大的風險。 就是：「這次修好了，但上次好的東西被弄壞了。」 測試就像是一條安全線。 讓我們可以一直往前修改，而不是每改一次，就害怕整個產品不知道壞在哪裡。
如果要讓 AI 跨對話、跨裝置持續工作，測試其實也是很重要的一條線。
因為對話可以不見。 Session 可以換。 甚至 AI 模型都可以換。 但：
規格 → 程式 → 測試 → 驗收
這條線可以留下來。
產品需求 ↓ 版本規格 ↓ AI 讀取目前專案 ↓ 確認「現在在哪裡」與「要往哪裡走」 ↓ 建立工作計畫 / 待辦項目 ↓ 依照依賴關係實作 ↓ 測試 ↓ 我實際操作 ↓ 發現問題 ↓ 把「現象」告訴 AI ↓ AI 回頭檢查程式 ↓ 修改 ↓ 再測試 ↓ 更新文件 ↓ 下一個版本
這個循環可以一直繼續。
當我隔了一天、換了一台電腦、開了一個新的對話，我還能不能持續和 AI 一起工作？
這件事情最後不是靠 AI 的記憶解決的，而是靠我們一起留下來的東西。 不管下一次從哪裡開始，我們都還能繼續往正確的方向走。 這可能才是我目前最想建立的 AI Workflow。
]]>我花了 12 個小時，和 AI 一起完成了一個產品── Money Snap。
它是一個協助現金拆鈔、兌幣與統計的小工具。
回頭整理整個開發過程，我發現比起工具本身，更有趣的是這次和 AI 協作的方式。
老實說，我一開始沒有想過什麼 AI Workflow，也沒有刻意設計 Multi-Agent。就只是剛好手邊有 Gemini、ChatGPT 和 Copilot CLI，於是很自然地在不同階段用了最順手的工具。等到產品做完、回頭整理時，我才發現，原來這一路留下了一條很完整的人機協作軌跡。
每個月初，總有一個人必須提早開始工作。 她打開 Excel、整理薪資、計算每個人的金額，再開始思考： 「銀行到底要換多少張一千？」 「這個人全部給五百可以嗎？」 「如果今天銀行沒有那麼多百元怎麼辦？」 我發現，這些工作沒有任何創造性，卻不能出任何差錯。
一開始我其實也想過：「是不是用 Excel 就好了？」
但真正困擾我的並不是公式，而是每次來源資料都不太一樣。有人貼的是 Excel、有人給 CSV、有人直接從薪資系統複製文字，整理格式往往比真正計算還花時間。
於是我開始思考，如果把這整個流程重新設計，而不是只是把 Excel 做得更複雜，會不會更有意義？
這就是 Money Snap 想解決的事情。
過去做 Side Project，很容易一想到功能就直接開始寫。
但這次我刻意讓自己冷靜下來多學一點。
我先和 Gemini 討論產品到底要解決什麼問題，而不是先討論技術。很多時候，它不是在回答我，而是在反問我。
「真正的使用者是誰？」
「哪些功能是 MVP？」
產品方向慢慢清楚之後，我再把需求交由 Gemini 整理成 PRD 和 Technical Specification，讓整個產品有一份可以被閱讀、可以被討論、也可以交付開發的文件。
幾乎所有的開發工作，都建立在這份規格之上。
現在回頭看，多花了這一個小時 CP 值很高。
有了規格之後，我把整個專案交給 Copilot CLI。
它沒有一開始就直接產生程式，而是先閱讀規格、整理計畫、拆解待辦項目，再開始一步一步完成功能。
我面對的不是一個「自動補程式碼的工具」，而是一個會依照規格工作的協作者。
第一次把薪資資料貼進去，看著每個人的面額、統計一起算出來，我反而沒有太大的興奮。 我的第一個念頭是：「真的可以。」 那一刻我知道，後面的工作不再是「做不做得到」，而是「怎麼把它做好」。
我不再一直思考「這段程式怎麼寫」，而是一直在做另外幾件事情：
需求有沒有被理解？
功能是不是符合使用情境？
介面是否真的好操作？
哪些地方需要再調整？
如果發現問題，就重新描述需求，再交回 Copilot 修改。
這樣的循環，重複了很多次。
慢慢地，我發現自己花最多時間的，不再是寫程式，而是一直確認： 「這是不是我要的？」 「使用者真的會這樣操作嗎？」 「這樣算完成了嗎？」 我開始覺得，我比較像產品的把關者，而不是一直埋頭寫程式的人。
整個 MVP 大約花了 8 個小時。
需求探索 (1H - 12%)
開發＋QA (2.5H - 31%)
Review / Prompt / 版控 / 文件 / 發布 (4.5H - 57%)
其中大概可以拆成三個階段：
這個比例其實和我原本想的不太一樣。
我一直以為寫程式會花最多時間。
結果真正花時間的，是讓產品達到「可以發布」的品質。
AI 可以很快產生第一版，但第一版通常不是最後一版。
真正耗時的是那些很細微的事情：
一個按鈕的位置。
一句提示文字。
一個流程是不是順。
一個命名是不是容易理解。
這些都不是 AI 能自己決定的。
MVP 發布完成之後，我又陸續加入了 PWA 和 Google Analytics。
PWA 和 Google Analytics，其實都是我以前沒有做過的東西。 過去遇到這種情況，我可能會先去找教學、看文件，再慢慢開始寫。 但這次，我先把需求講清楚，再和 AI 一起把它完成。
有趣的是，第二次開發幾乎完全沿用了第一次建立的流程。
先討論需求。
更新規格。
交給 Copilot 開發。
驗收。
修正。
發布。
這次大約又花了四個小時。
我開始發現，真正留下來的不是某一個功能，而是一套可以一直重複使用的協作方式。
我在寫這篇文章才想到這個問題。
也許在我有資源的情況下，下個產品我會試試看一個具備 Subagent 能力的平台，讓需求分析、規格整理、程式開發都在同一個工作流完成。
但回頭看這次的過程，我不是刻意的把不同 AI 分配成固定角色。
不是因為 Gemini 不會寫程式，也不是因為 ChatGPT 不會規劃，更不是 Copilot 不能討論需求。
只是當下，我用了自己最順手的工具。
要整理規格時，就切到 ChatGPT。 要真的改程式，又回到 Copilot CLI。 我不是先設計工作流，而是在產品做完之後，才發現工作流已經形成了。
也許未來，一個 Agent 就能完成所有事情。
但我相信，人仍然需要決定產品方向、定義完成的標準，以及負責最後的驗收。
如果要說這個專案最大的收穫，我覺得不是完成了一個工具。
而是重新理解了自己的工作方式。
以前，我把 AI 當成一個回答問題的工具。
現在，我更傾向把它看成團隊中的協作者。
真正重要的，也不再是哪一個模型比較厲害，而是如何建立一套自己可以持續使用的人機協作流程。
因為模型會一直更新，工具也會一直改變。
但產品開發的節奏不會變。
從發現問題、定義需求、建立規格、實作、驗收，到持續迭代，這套流程未來仍然可以套用在之後的產品。
Money Snap 是第一個產品，我不知道下一個產品會是什麼。 但我知道，我大概還是會用同樣的方法開始：先把問題想清楚，再找 AI 一起把它做出來。
]]>