乘數、倍化，而不是最佳化
AI 寫程式已經熱好一陣子了，而你那些不能/不會寫程式的朋友，現在都在產程式碼、部署新的服務。 對軟體工程師來說這在合理不過了：有神秘小精靈會幫你把繁瑣的工作做掉，讓你能把時間用在更寶貴的事物上。但我觀察到，對於那些寫碼上癮的跟持續抗拒使用的，扔有不小的想法差異。
我自己的經驗是，在成果產出上面有接近 100 倍的速度，但也有人說這幾乎啥也沒變。
這麼確實的差異，讓我想起一段小時候剛學騎腳踏車那時的事情。第一次學會自己騎行的時候，立刻感受到風從我髮際略過，而我正以前所未有的速度「狂奔」。這種近乎自由的感覺貫穿了我全身經脈，我感覺我真能去往任何地方。
「這好偉大喔！」我對我爸說 「是很偉大」他回「但不要因此志滿而止步，而忽略掉了其他偉大的東西。你未來可能還會騎摩托車、開車甚至開飛機、坐火箭。」 他停頓了一下，然後說出了影響我至今的一句話：
「你腳踏車騎得再好，也上不了太空」
但這跟用 AI 寫程式有什麼關係？
一般可能會覺得，這就只是有多會使用這個「新工具」的技巧差異，是術而不是道法、是專業領域的範圍而已。不過其實從我跟許多包含技術與非技術出身的使用者聊過，發現大家在各具體工作事項上的加速，其實都差不多（大約十倍），而且希望維持品質的話，還是需要人為介入審閱。我自己的體感是：以往需要大約三天完成的事項，現在可以壓縮到三小時內完成。雖然已經很可觀了，但跟我前面所說的百倍加速有不小的差異。
所以差異在哪？我在打臉自己嗎？
沒有，而且更極端點的話，我甚至覺得特定工作條件下，進步速度甚至可以達到千倍。其中第一個錯位來自於「速度是怎麼被衡量與觀察的」。單一產品功能與一個完整的服務產出是兩件事情，所以當我只把 AI 當成「程式碼產生器」，那我頂多就是來個十倍的加速而已。
但產出從來就不只是「噴出程式碼」而已。
如果你將大語言模型視為「結構重組的方法」，並將他用到流程中的方方面面，最後衡量整體產出，那你個觀點就有根本性的變化了。你已經不是把你的技能「外包」給一個工具，而是重建整個進步的循環。然而一開始，這其實還蠻讓人失望的：因為你的增幅下降了。你可能得花 6 小時，因為需要處理不同階段間，額外的內容和結構的轉換。但這是短空長多：你犧牲了一點開發速度在生成各類副產出上，而這些輔助了跟人類的來回溝通，最終可能解省數週以上的時間。
然後神奇的事情開始了。雖然對於代碼階段的效率是次佳，他仍是個四到五倍的效率。而這個效率現在可以被同時應用到其他相關的工作上：文件產出、背景知識管理、系統對齊整合、規格確認、測試、安全檢查，所有你想得到的方面。而且更棒的是，很多這類工作因此開始變得可以平行處理，當然你得把工作流程設計設計得好（但這也可以用這新方法做到）。
而當你回頭看，在整個開發週期中，三小時與六小時造成的實質差異其實很小。想想以往有多個關係人的情況，一個兩週的 sprint 搞定一切是大家腦中的美夢，但現實是殘酷的：你還得回頭面對行程表、意見搜集、產報告、等回饋：特別是在高脈絡的溝通環境中。這時花多久把代碼寫出來根本就不是瓶頸了，節奏對齊才是。三天完成工作，抓點摸魚的緩衝其實就是一週，然後另外一週你會拿來估開發點數、排優先級、審閱、會議然後拆解所有人的想法。
但同樣的東西可能塞在一天、最多兩天完成。六小時剛好讓你一天搞定後，趁人下班前拿到最快的回應。同時執行過中所自動捕捉的那些訊息，可以讓你的文件保持實時的更新，隨時轉換成審閱階段或是直接分支開展新工作。你也更容易配合那些相關人士的行程，因為你的工作變得更加碎片單元化了。你可以把各種殘枝片羽拿給他們看，然後叫你的系統在週末前就進行下一階段的預備。
一個可能需要三個 sprint (大約六周) 的工作，現在可能兩天就好了。而你現在可以專心對待現存此地的人們，並同時開展多個事項。
如果你目不窺園的專注在「我到底省了幾個小時」，那以上這些都不會發生了：因為省時間這個動作是最佳化。最佳化適用的是場景與定義完整、熟練度導向的問題。但如今這是一個生產方式上的改變，那麼核心問題就不會只是「你能多快做好」而是「你能怎麼做好」。每一個小進步會複合起來，累積成一個對整體而言巨大的乘數。
這個綜合效果是有根本不同的，因此最終成果是單純的最佳化永遠無法企及的。用 AI 更快的寫出程式碼是在成為偉大的自行車手；而重構你的整個交付流程，進而倍增每一步的收穫，這才是在打造火箭。