過去三個月，沒有手寫任何 code 的情況下，我借助 AI 的能力，交付了一套試玩廣告的遊戲製作平台。
流程大概是這樣：
- 累積製作經驗，理解技術原理，發現用戶團隊在大量製作上所面對的問題
- 先透過 AI 進行研究、可行性分析，搭建 POC(proof-of-concept) 系統
- POC 證明了實作可行性，get buy-in from 用戶
- 透過 AI 進行生產環境的 system design，釐清 non-functional requirement，決定系統 tech-stack & architecture，產出 high-level design，訂出上線目標
- 根據目標拆分工作給團隊，大量投入 AI Coding Agent 動工
- 系統正式上線，用戶方開始使用
在我完成了 high-level design 的當下，整個系統的代碼就開始被我們團隊 3 個人，每人一個 AI Agent，快速砌起來。在 AGENTS.md 以及定義好的 high-level design 作為 constraint 的情況下，每次提交(commit)都是經過功能驗收的，沒有壞掉過，單天最高 CI pipeline 可以被觸發 20 多次。
系統 MVP 版本就是在如此快速迭代的情況下被產出。上線第一天，用戶就能順利使用且沒遇到重大 bug。而整個系統 100% 代碼由 AI 撰寫。
系統上線後，要做的事情大致就兩項：
- 監控用戶流量跟業務指標
- 接受用戶需求並迭代系統
今天我想聊的是後者。
反饋不等於需求
上線之後，理想情況是：團隊開始承接用戶在使用上的反饋，繼續使用 AI 快速迭代。
但很快就理解到了一件事：反饋 ≠ 需求。
從用戶的角度做出的「反饋」用語多是「感覺難用 / 希望加上 xxx 功能」。而需求則是要再做一層轉化：沉澱用戶反饋後，先查證釐清他們真正遇到的問題，再從系統的角度出發設計功能，簡單來說就是問一句「系統能提供什麼來解決他們的難題」。
舉個實例。系統有提供一個專門擺放遊戲地圖上元素的畫布編輯器，用戶希望能夠將元素們框選為一組進行移動。起初他們提說要在元素上有「組」的概念，然而這與當時系統的設計上有很多衝突點。
當時元素的管理是存在一個元素列表中(List/Array)，元素間的排序直接代表了它們的渲染層級，展示上也就是把這些元素攤成一個列表讓用戶瀏覽。「組」的設計會把這個渲染層級的設定直接打破。同時，對於「組」的交互也沒有一個好的方式，比如如何選中一個「組」。
後來釐清了他們真正的需求，只是想要在畫布上有個「框選」功能，讓他們能夠一次選中多個元素，一起拖動。框選這個功能對我們的系統也是容易支持上的。後來上線了框選，他們也很滿意。
工作流開始改變，先收集「反饋」，後由較理解系統模塊的人提出初步方案，才成為「需求」。
上線之後，穩定性變成硬指標
在正式上線前，有了「需求」就能丟給 AI 讓他開發。然而，一個系統在上線的那一天「穩定性」就成為硬指標，這使得團隊必須對於迭代上的風險有精準把控。總不能因為上線一個新功能，把原本的功能承諾的能力搞砸了。
於是乎，Tech design / spec 文檔成了開發前的必須文檔，說明一個需求該怎麼被實現，中間牽涉到什麼重要模塊，以及最後功能驗收的標準。經由人工評審之後才能正式開工。
開發過程為了減少一些 bad code smell，也在 MR 上讓 AI 進行 code/unit-test review，開發工作結束後，交由 QA 驗收測試，沒問題後上線，一個需求迭代也到此告一段落。
簡單整理一下流程：
- 收集反饋
- 轉化成需求 -> 人工 review
- 轉化成 TD/spec -> 人工 review
- 轉化成 code
- 測試
AI 能提高工作效率，但從上面的流程來看，根據木桶效應，人工審核成為了這個流程的瓶頸。實際的量級是：AI 開發佔一天，人工審核大概 2~3 天，中間甚至開了幾次組會共同討論。
你說該把人工的部分全部抽掉嗎？AI 是個預測模型，不知道下一秒可能會做出什麼傻事。
這部份也好辦：把上下文全部寫到文檔，提供給 AI 讀就行。
聽起來 Senior 好像快失業了。
Senior 手上的四種上下文
傳統的 Senior 因為理解系統模塊，常常作為需求可行性(Feasibility) 的決策人，也是系統迭代上的發展方向提供者。他們對系統的深刻理解，使他們能夠為系統用最少資源拿到最大價值。
理論上，如果 AI 擁有跟 Senior 一樣的上下文，那就能完全替代 Senior 的位置。
實際上，Senior 所掌握的上下文經過拆解：
- 系統事實：現有系統長什麼樣子，行為是什麼
- 系統約束：架構上，哪些方向不能做
- 取捨判斷：功能是否在 roadmap 上、團隊容量是否足夠
- 不可逆判斷：一旦做下去，未來反悔的成本多高
前兩項確實可以透過落入文檔，讓 AI 有充足上下文，他讀的夠快，這點無庸置疑。而後兩項則無法，也體現在這個時代下 Senior 的價值，應該在槓桿更高的決策上發揮。
最後一項我實際遇過一次。系統因為 schema 改變，連帶要決定某個字段的缺省應該視為 true 還是 false。當時是我擋下來的，因為缺省所填補的值，會大大影響遷移後的系統行為。
回到流程
- 反饋在落入需求後，Senior 能夠對問題做出定義，作為方案基石。
- AI 能產出 TD/Spec，而 Senior 可作為一個關鍵模塊被改動時的審核關卡。
同時，繼續對系統迭代的工作流持續觀察，減少效率瓶頸，我想這就是目前作為一個 Senior 可以做的事。