[討論] 亞麻工作談：兩次 re-org 後，我對 AI coding 最大體會

看板Soft_Job (軟體人)作者uopsdod (pcman)時間1小時前 (2026/03/18 14:50)推噓8(8推 0噓 18→)

留言26則, 7人參與討論串2/2 (看更多)

用 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

推

whitecolor

03/18 14:51, 1小時前 , 1^F

03/18 14:51, 1^F

推

aspirev3

03/18 15:03, 1小時前 , 2^F

03/18 15:03, 2^F

推

yamakazi

03/18 15:22, 1小時前 , 3^F

03/18 15:22, 3^F