當 AI 開始接得回來，我開始思考要怎麼教它工作

當產品開始持續迭代，我發現有些事情不是某一次功能的需求。

而是我希望 AI 在這個專案裡，一直遵守的工作方式。

例如 UI 有一些我希望維持的原則。

版本更新有一些固定要同步處理的事情。

程式修改之後，也有一些我希望它一定要確認的事項。

這些事情每次在對話裡講一次，好像沒有什麼。

但當產品開始一直修改之後，我突然發現：

為什麼這些事情我要一直講？

所以我開始嘗試另外一種做法。

把這些「我希望 AI 記住的工作習慣」，直接寫進專案裡。

我不想每一次都重新提醒 AI

一開始和 AI 一起開發的時候，我常常會在對話裡補充很多事情。

「這裡不要用 Icon。」

「版本號改了之後，記得同步更新其他地方。」

「這個畫面希望保持簡潔。」

這些事情每次講一次，好像沒有什麼。

但當產品開始一直修改之後，我才發現：

這些其實不是某一次功能的需求。

而是我希望 AI 在這個專案裡，一直遵守的工作方式。

如果每次都重新說一次，久了其實很容易漏掉。

所以我開始想：

有沒有什麼方式，可以讓這些規則直接跟著專案走？

我開始使用 Copilot Instructions

我在 Money Snap 裡建立了 copilot-instructions.md。

它不是某一個功能的規格。

也不是告訴 AI：

「這一次要幫我完成什麼。」

比較像是在告訴它： 如果你要繼續和我一起做這個專案，請用這樣的方式工作。

例如 UI 有一些我希望一直維持的原則。

版本更新有一些固定要同步處理的事情。

程式修改之後，也有一些我希望它一定要確認的事項。

這些東西以前散落在不同的對話裡。

現在我把它們放進專案。

於是下一次開始新的功能時，我不用再重新提醒一次。

我不是只在寫程式，而是在慢慢建立一個「和 AI 一起工作的環境」。

Instructions 和規格不一樣

規格是在說： 這一次我們要做什麼。

Instructions 比較像是在說： 我們平常應該怎麼做。

例如今天要做自訂面額。

規格會告訴 AI：

「自訂面額應該有哪些功能。」

但 Instructions 不需要知道這個功能。

它只需要告訴 AI：

「在這個專案裡，UI 應該遵循什麼原則。」

「版本更新時，哪些地方需要一起確認。」

所以我把兩者分開看。

產品需求
    ↓
這一次要做什麼？

開發規格
    ↓
這一次要怎麼完成？

Instructions
    ↓
平常應該怎麼工作？

這樣一來，AI 不只是知道「我要做什麼」。

也開始知道：

「在這個專案裡，我應該怎麼做。」

最有趣的是，我沒有特別感覺到它正在「讀 Instructions」

這可能是我覺得這次最有意思的地方。

我沒有每一次都跟 Copilot 說：

「請先讀 instructions。」

「請記得我們的 UI 規則。」

我只是照原本的方式工作。

但在過程中，我開始看到一些原本需要自己提醒的事情，變成它工作時會一起考慮的事情。

這種感覺和前面「讓 AI 接得回來」很像。

只是上一個階段是在解決： AI 能不能理解現在的專案？

這一次則開始變成： AI 能不能理解我希望它怎麼工作？

這比較像是在「建立團隊規則」

如果今天真的有一個新的工程師加入專案。

我不會希望每一次 Code Review 都重新告訴他：

「這裡有一些固定的版本更新流程。」

「這個專案有一些特別的限制。」

這些東西應該被寫下來。

因為寫下來之後，它就不只是某一個人的記憶。

而是團隊共同遵守的規則。

Instructions 很像是在幫 AI 建立一份「這個專案的工作文化」。

它不是產品需求。

也不是技術文件。

而是： 我們在這個專案裡，習慣怎麼工作。

實際使用之後，我才發現它真正有價值的地方

我覺得 Instructions 最有價值的地方，不是讓 AI 突然變得更聰明。

而是：

減少我一直重複說同一件事情的時間。

以前我可能會在對話裡一直補充：

「這裡不要這樣。」

「那個不要引入。」

「改完記得同步。」

「這個要測試。」

現在這些東西如果已經寫進專案，我就可以把注意力放到真正的產品問題。

例如：

「這個 UI 我用起來不順。」

「這個流程是不是可以再短一點？」

「這個情境是不是還會出錯？」

而不是一直提醒 AI 基本的工作規則。

這個差異看起來很小。

但當開發開始一直迭代，我覺得它會慢慢累積成很大的差別。

我開始發現，AI 協作其實有兩個層次

到了這裡，我開始把前後兩個階段連在一起看。

第一個階段，是讓 AI 理解專案。

所以我需要留下：

讓它可以重新找到目前的位置。

第二個階段，是讓 AI 理解我的工作方式。

所以我開始留下：

前者是在回答： 「我們現在在哪裡？」

後者是在回答： 「我們要怎麼一起工作？」

我覺得這兩件事情開始接起來之後，AI 才比較像是一個可以長期合作的協作者。

我還在觀察，它到底能不能真的做到

我現在還不會說：

「寫了 Instructions 之後，AI 就完全不會犯錯了。」

沒有這麼神奇。

它還是可能理解錯。

還是可能漏掉一些事情。

還是需要我實際操作、Review、測試。

甚至有時候也會發現：

原本寫在 Instructions 裡面的規則，可能根本不適合現在的產品。

那就再修改。

所以 Instructions 本身也變成一個會持續迭代的東西。

這和產品其實很像。

我的 AI Workflow 也會慢慢從一開始的幾個規則，變成越來越適合這個專案的工作方式。

我現在更在意的是怎麼讓 AI 可以一直跟我一起工作？」

它要知道現在的專案在哪裡。

知道下一步要往哪裡走。

知道哪些東西不能被破壞。

也知道我希望它用什麼方式工作。

而我則繼續負責最重要的事情：

實際使用。

觀察。

判斷。

發現問題。

做產品決定。

然後再把這些新的理解，繼續放回專案裡。

AI 協作好像慢慢變成了一個循環：

產品
  ↓
我實際使用
  ↓
發現問題
  ↓
和 AI 一起修改
  ↓
測試
  ↓
留下新的規則與經驗
  ↓
下一次開發
  ↓
再繼續迭代

這可能才是我現在真正想建立的東西。

可以逐漸理解產品、理解工作方式，然後和我一起持續把產品往前推的 AI 協作者。

而我也正在一邊做產品，一邊建立自己的 AI 協作方式。