用 AI 寫 code，前期真的很爽。 很多東西丟進去，很快就有東西跑出來。 UI、CRUD、測試、refactor，體感都比以前快很多。 但我自己用一陣子之後，慢慢發現一個問題： AI 很會讓你在前兩週覺得自己效率翻倍。 但如果專案稍微變大，後面很可能就開始失控。 --- 我自己最常遇到的大概是這幾種： 原本正常的頁面，被改一輪之後反而壞掉 UI 理解一直有落差，你以為講清楚了，它其實理解成別的東西 前面講過的規則，過幾輪就忘 context 很快塞滿，品質開始往下掉 換個 session 之後，像失憶一樣，很多東西都要重講 所以我後來慢慢有個感覺： 我後來慢慢有個感覺：AI coding 不穩，很多時候不一定是模型本身不行。 我自己看身邊同事在用 AI，很多時候還是這種模式： 開個 chat、丟需求、等它吐東西，不對就再重講一次。 這樣不是不能用， 但很難長期穩定產出。 --- 我自己真正意識到這件事，是去年 Amazon 兩次 re-org 之後。 我原本做的是 Payment 系統， 每天處理上百萬筆交易，這塊我做了三年，算是很熟。 但某次 re-org 之後，我被拉去做一個新任務： 在既有的廣告 backend 裡， 接一條新的交易流程。 我第一次打開 codebase 的時候，心裡只冒出一句話： What the hell did I just get myself into. 主專案很大，很多團隊共用，service 之間互相依賴， 很多邏輯不是你看一兩個檔案就能懂的。 更現實的是，時程也不長。 第一個月要有 beta。 第二個月要完整上線。 那時候我就很清楚， 如果我還是用以前那種方式慢慢看、慢慢接、慢慢查， 風險會很高。 不是那種「辛苦一點還是做得完」的高， 而是你根本很難在有限時間裡，建立足夠的全局理解。 所以我那時候做了一個決定： 先不要急著叫 AI 幫我生 feature。 先把自己的 AI 使用方式整理起來。 --- 我後來給自己定了一條原則： 任何需要手動重複做，而且超過兩三步的事情， 都要想辦法系統化。 所以我開始做的事情，大概像是： 把常用操作整理成固定 command 把環境資訊、測試方式、規則整理成可重用的 context 可以平行驗證的事情就拆出去跑 比較明確地管理 session、規則和回饋 讓 AI 不只是回答問題，而是進入我的開發流程裡 這些東西聽起來都不炫， 但真正讓我後面速度差很多的，反而是這些。 --- 老實講，第一週這樣做的時候壓力很大。 因為表面上看起來，你沒有立刻產 feature。 我還記得那時候 manager 問我一句話： "You haven't worked on any feature?" 那時候的壓力，其實真的很大。 因為在別人眼裡，你像是在花時間整理工具， 不是在推進事情。 --- 但我那時候心裡很清楚， 如果這套東西沒有先立起來， 後面只會一直卡在： context 爆掉 規則忘記 改一處壞三處 測試一直重跑 每次都從頭解釋 這種狀況短期看起來還能撐， 但在大 codebase 裡，很容易越做越亂。 所以我後來回頭看，那一週反而是最值得投資的一週。 --- 我現在對 AI coding 最大的感想，不是它能多快幫你生出 code。 而是專案一旦變複雜， 真正影響效率的，往往已經不是模型會不會寫， 而是你有沒有一套穩定的方法，讓它持續在對的軌道上工作。 我現在不太相信 「只要模型夠強，一切自然會變順」這件事。 我自己的經驗比較像是： 模型變強當然有幫助， 但如果 workflow 沒跟上， 最後只是更快把專案搞亂。 --- 回頭看，去年那次 re-org 留給我最大的收穫， 不是我用了什麼模型。 而是我終於搞懂： 真正的門檻， 不是你會不會下 prompt。 而是你有沒有能力，把 AI 變成一套能長期運作的工作方式。 -- --- 寫工程師在 AI 時代的轉變 也分享 AI 工作流、創業思維與矽谷職場 矽谷叔叔 Uncle Sam -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 99.185.46.190 (美國) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1773816611.A.F38.html