「有人開啟了 Miro 白板。」

這就是我知道我們遇上麻煩的時刻。

不是因為我不喜歡圖表。

我其實很喜歡圖表。

我不喜歡的是有人開啟 Miro 白板之後通常會發生什麼事。

方框開始出現。

接著是箭頭。

然後更多方框。

接著有人說：

「如果我們有一個需求代理怎麼樣？」

另一個人點頭同意。

「如果那個需求代理再接給架構代理呢？」

「然後再跟程式碼代理對話。」

「再交給測試代理。」

「喔！還有文件代理。」

「別忘了 PR 審核代理。」

此時我們已經不小心聘請了一整個 AI 工程部門。

有趣的是？

我們還是沒解決原本的問題。

我們在建立記憶之前，就先建立了中層管理

目前 AI 工具生態最讓我感到有趣的一點，就是大家都熱衷於設計專門的角色。

每個提示都有職稱。

每個工作流都多了一個代理。

每項新功能似乎都值得在圖表上多畫一個方框。

與此同時，可憐的模型在每次對話一開始就問：

「程式碼規範在哪裡？」

又問一次。

一般的後端工作其實沒那麼刺激

老實說。

我們大多數人都不會在午餐前發明新的共識演算法。

我們的工作通常看起來像這樣：

  • 閱讀 Jira 工單。
  • 搞清楚業務真正想要什麼。
  • 找到相關程式碼。
  • 確認你不會破壞三年前某人做出的架構決定。
  • 實作功能。
  • 撰寫測試。
  • 開 PR。
  • 因為有人覺得某個變數「讀起來比較順」，而把它重新命名。

困難的部分不是在打 Java（或 Python、C#、TypeScript、Rust……或老天保佑，Visual Basic）。而是每次都要重建上下文。

每一次。都是。

恭喜，你重新造了一個新手開發者

每次新的對話都以相同的方式開始。

「可以幫我抓 Confluence 嗎？」

「可以幫我開 Jira 嗎？」

「規範在哪裡？」

「我們有 ADR 嗎？」

最後你的 AI 花在跟 MCP 伺服器對話的時間，遠多於幫你寫軟體。

恭喜。

你重新造了一個入職第一週的新手開發者。

只是跟新手開發者不同的是……

……你每天早上都會把它的記憶抹掉。

文件不應該是執行期依賴

這大概是我最大的心態轉變。

Jira……還好。

Confluence……也還在。

給人類使用是沒問題。

但如果每次實作都需要 AI 不斷去抓 Jira 工單、Confluence 頁面和隨機文件……

……那你的文件就變成了執行期依賴。

任何 AI 會重複需要的東西，都應該直接存在你的知識庫裡。

程式碼標準。

架構決策。

業務術語。

審核期望。

常見實作模式。

「請不要在週五下午四點後碰這段查詢」的備註。

Markdown。

Markdown。

更多 Markdown。

如果 Confluence 仍然是單一事實來源，很好。

同步它。

匯出它。

嵌入它。

我不在乎它是用什麼方式到那裡。

我只在乎 AI 打開本地 Markdown 文件，而不是發出當天第十五次 MCP 請求。

少抓取。

多建立。

Obsidian 不是筆記本。它是記憶。

人們問我為什麼喜歡把 Obsidian 跟 AI 一起使用。

不是因為我喜歡收集 Markdown 檔案。

是因為 Obsidian 變成了第二大腦。

每一個架構決策。

每一個命名慣例。

每一個學到的教訓。

每一個業務上的怪癖。

每一個「我們 2024 年試過，結果上線燒掉」的經驗。

一旦寫下來，AI 就不用每次對話都重新發現它。

無聊的部分才是贏家

這就是 Superpowers 這類工具真正打動我的地方。

老實說，把「Superpowers」換成 SpecKit、Matt Pocock 的工作流，或任何你偏好的編排框架都行。

名字不重要，編排才重要。

想像一下流程。

一個技能負責蒐集上下文。

它讀取 Jira 工單。

找到相關 Markdown。

載入業務規格。

拉取架構決策。

找出類似的實作。

完成。

下一個技能接手。

載入專案指南。

檢查架構限制。

提醒模型命名慣例。

強調大家都會忘記的業務規則。

完成。

實作結束。

另一個技能接手。

產生 PR 說明。

檢查文件更新。

建議發行說明。

找出缺陷。

在適當的地方提出技術債，而不是再加一個永生的 TODO。

產生真正聽起來像你團隊的審核意見。

注意到什麼沒發生嗎？

我們從來沒有建立 PR 代理。

也沒有建立架構代理。

或文件代理。

它們只是小型、可重複使用的技能，互相傳遞上下文。

厲害的地方不在於個別技能。

而在於編排。

請不要再給提示 LinkedIn 履歷了

有些提示一開始是這樣寫的：

你是擁有二十五年企業經驗的傑出首席資深軟體架構師……

兄弟。你只是在寫 commit message 而已。
放輕鬆。

現代模型已經非常強大了。

差異很少在於智慧。

而在於上下文。

一個好大腦勝過二十個聰明員工

我對 AI 輔助開發實驗得越多，就越相信我們一直在優化錯誤的東西。

我們不需要另一個專家。

我們需要更好的記憶。

我們需要更好的編排。

我們需要讓專案知識在第一行程式碼寫出來之前就已經準備好。

諷刺的是，這也是讓人類開發者有生產力的原因。

知識。

上下文。

共享慣例。

而不是職稱。

在你新增另一個代理之前……

下次有人打開 Miro 白板，得意地展示二十個用彩色箭頭連接的 AI 代理時……

問一個問題。

「你們的程式碼規範在哪裡？」

如果答案是：

「嗯……它們大多散落在 Confluence……」

關掉 Miro 白板。

打開 Obsidian。

從這裡開始。

因為大多數後端團隊不需要另一個 AI 員工。

他們需要一個第二大腦，以及少數編排良好的技能。

其他一切都只是中層管理。