Agentic Banking 讓 AI 習慣變範圍

我把 Anchorage Digital 的 agentic banking 職缺拆成一套可直接套用的 AI 輔助產品工作法。

我盯這類職缺文很多年了，大多數都像一群人把「想要一個很會做事的人」硬塞成一頁字，結果每句都很空。這份來自 web3.career 的 Anchorage Digital 職缺不一樣。它沒在跟你喊口號，反而一直重複同一件事：你要把產品面、後端行為、文件、客戶溝通一起扛起來，還不能等 PM 幫你翻譯。我看完第一反應不是「哇好強」，而是「這根本是在找能自己收爛攤子的人」。

更刺的是 AI 那段。它沒在講什麼 AI-native 神話，也沒叫你把決策丟給模型。它要的是 AI 輔助執行的習慣，但判斷力還是你自己的。這才是多數團隊真正卡住的地方：不是太慢，就是太迷信模型。這份職缺其實是在押一條中間路線，而且我覺得這條路才真的能做事。

我先講清楚，這篇不是新聞整理。我是拿這份職缺當樣本，拆它背後的工作方法，最後給你一份可以直接抄去改的模板。原始貼文沒有公開提供我能核實的觀看數、書籤數或星數，所以我不亂編。

這不是 full-stack，這是產品 owner 長出來的工程位

“Own the customer-facing product surface, backend business logic, docs, and developer experience.”

翻譯一下就是：他們不是要你只會寫前端，也不是只要你會接 API。它要的是一個人從使用者看得到的東西，一路管到後端邏輯、文件、整合體驗，全部自己收。這種職缺我看過太多次，表面寫工程，骨子裡其實是產品 owner 加工程執行，外加一點 customer engineer 的味道。

我以前待過一個支付功能團隊，最常見的爛事就是這樣：工程寫完了，PM 覺得需求有交代，文件交給別人補，support 最後才知道有問題。那種分工一開始看起來很專業，實際上就是把上下文切碎，然後大家一起假裝沒事。金融產品最怕這個，因為每個 handoff 都可能變成錯誤來源。

這份職缺真正要你做的，是把整條鏈收回來。UI 的文案怎麼寫、API 回傳什麼狀態、後端怎麼轉移、異常怎麼顯示、文件怎麼讓客戶自己上手，這些不是附屬品，是同一個產品的一部分。你如果做過一次「功能本體已上線，但每週還在答同一個 onboarding 問題」就知道，產品沒做完不是因為 code 沒合，而是因為使用者還是卡在你沒想清楚的地方。

實操寫法很簡單：以後不要只說自己是 full-stack。你要能講的是「我能把一個產品流程從需求、狀態、API、UI 到文件全串起來」。履歷上至少放一個例子，證明你真的做過端到端，而不是只碰過其中一段。

• 先寫產品行為，不要先寫畫面。
• 每個使用者動作都對應一個後端狀態。
• 文件先寫失敗情境，再寫成功流程。

AI 不是幫你做決定，是幫你把瑣事做快

“Apply strong AI-assisted execution habits while maintaining judgment over critical product decisions.”

這句我很喜歡，因為它把 AI 的邊界劃得很清楚。它要你用模型加速，但不是叫你把腦袋外包。模型很會幫你把事情鋪平：草擬 spec、整理條件、產生測試骨架、把文件改順。但它不會替你判斷一個付款流程該不該可逆，也不會替你決定風險邊界要畫在哪裡。

也就是說，AI 可以幫你把「怎麼做」變快，但不能替你決定「該不該做」。這在一般 SaaS 可能還好，在金融、支付、穩定幣、合規敏感系統裡就很要命。你一旦把決策也交出去，速度看起來變快，實際上只是把風險延後，最後一次炸更大。

我自己用 AI 最有感的地方，是寫那些我本來就知道答案、只是很煩的東西。像是 state machine 初稿、測試案例列表、docs 的第一版、把客戶回饋整理成條列。最沒用的地方，是叫它幫我「想想這個流程該怎麼設計」。如果我自己都還沒想清楚，模型只會給我一段看起來很像答案的廢話。

實操寫法：你可以把 AI 分成四種用途，只有前兩種常態使用。第一種是草擬，第二種是整理，第三種是比較，第四種是決策。前兩種交給它，第三種要你看，第四種永遠留在人腦。這樣你才不會把「我有用 AI」誤認成「我有判斷力」。

• 讓 AI 幫你寫，不要讓 AI 幫你定義政策。
• 讓 AI 幫你找 edge case，不要讓它決定 edge case 的處理原則。
• 凡是牽涉資金、合規、可逆性，最後都要人簽字。

這份工作其實在考 state machine，不是在考 UI 美感

“Design and implement backend state machines and customer-facing status models for payment and stablecoin flows.”

翻譯一下就是：他們最在乎的不是畫面漂不漂亮，而是狀態轉換有沒有講清楚。金融系統裡，狀態就是產品。你如果把 initiated、pending、settled、failed、reversed、under review 混成一團，客戶只會覺得你不可靠，support 也會被打爆。

我以前接手過一個付款流程，最白癡的地方就是 UI 顯示 success，但後端其實只是 queued。功能看似能跑，實際上客戶以為錢已經過了，結果後面補帳、對帳、客服全都要陪葬。那種 bug 不只是技術問題，是信任問題。你一旦把狀態設錯，後面每個說明都會變成補洞。

這就是為什麼這種職缺會一直提 state machine。它要你先想「系統現在在哪個狀態、能不能轉、誰能觸發、客戶看到什麼」，再去寫 endpoint。不要反過來。很多工程師很會做 happy path，但一碰到 partial failure 就開始閃爍，因為腦中根本沒有完整的狀態圖。

實操寫法：你做任何跟錢有關的流程，先把 state machine 寫在紙上。每個 state 都要有名字，每個 transition 都要有觸發條件，每個 terminal state 都要有明確定義。然後拿給 support 或 ops 看，問他們：「如果客戶卡在這裡，你要怎麼解釋？」如果他們講不出來，你的模型還沒完成。

文件不是收尾，它是客戶能不能自己活下去的關鍵

“Create integration docs and onboarding examples that allow customers to self-serve without requiring support intervention.”

這句很直接，也很殘酷。很多團隊都把文件當成最後再補的東西，好像只要 API 寫得夠漂亮，客戶自然會懂。屁啦。客戶不懂你的內部假設，他只知道自己能不能在第一天接通、第二天不出包、第三天不用來找你哭。

這份職缺把 docs 拉到跟產品一樣重要，是因為它知道文件其實在幫你省 support 成本，也在幫你縮短導入時間。你如果做的是 agentic banking，文件不是「教人怎麼呼叫 endpoint」而已，而是要教人什麼叫正常、什麼叫異常、什麼狀態代表要等、什麼狀態代表要重試、什麼狀態代表要找人。

我看過太多「API 很直覺」的自嗨說法。那通常是寫文件的人自己太熟了，根本不知道外部第一次看會多痛。真正好的 docs，會把 onboarding、範例、錯誤碼、失敗情境、下一步都講清楚，而且最好能讓客戶不需要先開一個 support ticket 才知道自己卡在哪。

實操寫法很簡單：每個重要流程都至少寫一個真實情境範例，不要用太理想化的 demo。再補一段「如果卡住怎麼辦」。如果你的文件不能降低客服壓力，那它只是裝飾品，不是產品的一部分。

• 文件先寫客戶第一天要做什麼。
• 把錯誤碼翻成白話，而不是只丟代碼。
• 每個狀態都要對應一個可執行的下一步。

能不能直接跟客戶講話，決定你是不是只會轉述

“Comfort talking directly to customers and using that signal to shape the product.”

這種要求看起來普通，實際上很挑人。很多工程師不是不能跟客戶講話，是一講就想立刻承諾功能，或者只會把問題轉回 PM。那樣不叫收訊號，那叫把噪音再包裝一次。

翻譯一下就是：你要能從客戶抱怨裡抓出真正的產品訊號。不是每個 complaint 都是需求，有些只是訓練問題，有些是 edge case，有些是真的流程有洞。你要做的是把它拆開，判斷哪個值得改 API、哪個要補文件、哪個要改狀態顯示、哪個其實是客戶操作方式錯了。

我自己最常在客戶 call 裡問的一句話是：「你當時想完成什麼？」這句超有用，因為它會把抽象抱怨拉回真實工作流。很多時候客戶不是要一個新功能，他只是想在某個節點得到更清楚的回饋。你一旦聽懂這個，很多產品調整會變得很準。

實操寫法：每次跟客戶聊完，自己寫一則三行筆記。第一行寫客戶目標，第二行寫卡點，第三行寫你認為應該改哪裡。這樣你不是在記錄情緒，而是在累積產品訊號。久了你會發現，最有價值的不是客戶說了什麼，而是你有沒有把它翻成可執行的改動。

這種系統不能只追快，還要能被審、被救、被解釋

“Balance shipping velocity with the correctness and reliability required for financial systems handling real customer funds.”

這句是整份職缺最誠實的地方。很多團隊嘴上說要快，其實是把測試、觀測、rollback、責任邊界都外包給未來的自己。金融系統不能這樣玩。你可以快，但不能亂；你可以用 AI 提速，但不能讓它幫你把責任模糊掉。

也就是說，你做的每個變更都要能被審、能被回溯、能被救回來。這裡沒有什麼神奇捷徑。你需要測試，你需要 observability，你需要清楚的 failure mode，你需要 rollback 路徑，你還需要 support 看得懂的說明。說白一點，這種系統最值錢的不是 clever，而是可預期。

我現在反而比較怕那種很會秀技巧的人。金融基礎設施裡，太聰明常常等於太難維護。清楚、穩、可解釋，才是真的省錢。這也是為什麼這份職缺一直繞回 docs、state、customer signal、AI judgment，因為它們其實都在服務同一件事：讓系統不只會跑，還要能長期活著。

實操寫法：你每次 review 自己的功能，問三個問題。第一，客戶看得懂嗎？第二，半夜出事我能不能查？第三，這個改動會不會讓錢的流向變得不確定？如果三題有一題答不出來，就先別急著上線。

可抄的模板

# AI 輔助金融產品工作法：把「會用 AI」變成「做得出東西」

## 1. 決策邊界
AI 可以做：
- 草擬 spec
- 整理客戶回饋
- 產生測試骨架
- 改寫文件
- 列出 edge cases

人要保留：
- 資金流向決策
- 合規判斷
- 狀態定義
- 可逆性規則
- 上線門檻
- 客戶承諾

## 2. Feature 流程
1. 用一句話寫出客戶想完成的事
2. 定義系統目標
3. 列出所有 backend state
4. 把每個 state 對應到客戶看得懂的名稱
5. 寫出 allowed / blocked transitions
6. 定義 API、webhook、error state
7. 補一個真實 onboarding 範例
8. 寫 happy path、partial failure、recovery tests
9. 跟 engineering、ops、support 一起 review
10. 只有在 failure mode 可解釋時才上線

## 3. 客戶訊號筆記
- 客戶目標：
- 卡點：
- 可能原因：
- 建議修改：
- 負責人：
- 下一步：

## 4. State machine checklist
- 每個 state 都有名字
- 每個 transition 都有觸發條件
- 每個 terminal state 都明確
- 每個 error state 都有白話說明
- 每個 support 問題都能對回某個 state
- 每個 state 都能在 log 或 metric 找到

## 5. 文件 checklist
- 這個產品是做什麼的
- 客戶先準備什麼
- 怎麼完成第一筆成功流程
- 每個 status 代表什麼
- 失敗時會長什麼樣
- 卡住時下一步做什麼
- 一個可直接複製的範例
- 一段 troubleshooting

## 6. AI review prompt
你正在協助我交付一個金融敏感的付款流程。

請幫我：
- 草擬 feature spec
- 列出 edge cases
- 建議測試
- 改善文件

規則：
- 不要替我決定政策
- 不要捏造合規規則
- 不要改變資金流動行為
- 不確定就明講
- 優先選擇保守、正確、可解釋的行為

輸出格式：
1. Spec draft
2. Edge cases
3. Test ideas
4. Doc improvements
5. 需要人決定的問題

## 7. Release gate
我不會上線，除非：
- state machine 已 review
- 文件新客戶看得懂
- error states 已測過
- rollback 路徑已知
- support 團隊能解釋行為
- 我能說清楚每個接受的 AI 建議

這份模板不是從天上掉下來的，是我把這份職缺的要求翻成可執行的版本。核心就一句：AI 幫你提速，但範圍、狀態、文件、決策邊界都還是你要扛。你如果想套用，先挑你自己產品裡最麻煩的那條流程，照這份模板重寫一次。

原始來源是 web3.career 的 Anchorage Digital 職缺頁，公司背景可參考 Anchorage Digital。我這篇是根據原文做的方法論拆解，模板與白話翻譯是我的原創整理，不是原文照抄。