2026年9月16日 星期三

[AI 衝擊] 高度自動化Agent帶來的工程師職涯危機

 [AI 衝擊] 高度自動化Agent帶來的工程師職涯危機

摘要 : 工程師以MCP與Skill打造自動化Agent,也因此直面職涯價值與AI取代焦慮。



內容:


最近一篇帖子,發帖人表示,自己不斷見證AI變強,因而產生了強烈的無力感。


一年前,他還在嘲笑AI不會寫複雜專案的程式碼;如今,AI已經能完成程式開發、測試、問題排查及上線發布。他甚至常常只需要坐在辦公室與同事聊天,實際工作則由AI處理。


過去半年,他主要在為AI搭建MCP與Skill。MCP是由Anthropic率先提出、如今逐漸成為業界通用的標準介面,能讓AI直接呼叫公司的工具與系統;Skill則是將一套操作流程整理成AI可以重複使用的技能包。


完成這些建設後,AI已經能自行取得分配給它的需求。遇到不確定之處時,它會透過機器人帳號主動與工程師討論,接著自行開發、解決程式碼衝突、部署及測試。


AI也可以查看測試與正式環境的日誌,存取資料庫、訊息佇列及大數據平台,進一步排查與驗證問題,甚至直接完成線上發布。


更進一步,AI還會閱讀業務群組中的各種問題。多數情況下,它能自行排查、自行解決並直接回答。


發帖人曾親眼看到AI向業務人員索取具體資訊,再根據取得的資料,跨越五個服務檢查專案程式碼、日誌及資料庫,最後找出問題的根本原因並回覆業務方。整套流程完全由AI獨立完成,前後不到20分鐘。


當然,建成這套系統耗費了他大量時間與精力。目前多數人還達不到這樣的自動化程度,但這已經證明,AI能完成大部分人的工作,甚至可能做得更好。


未來如果有更多公共MCP與Skill開放,達到這種自動化程度的人將愈來愈多,使用AI的門檻也會持續下降。


這讓發帖人開始思考三個問題:


第一,一個每月只需200美元的AI,已能比他和同事做得更好;而他們的年薪接近80萬元,這樣的工作還能維持多久?


第二,他們所做的工作,真的值80萬元年薪嗎?


第三,也是最令人不安的一點:真正可怕的不是現在的AI有多強,而是AI進入Agent時代還不到一年,就已經發展到這種程度。明年、後年乃至更遠的未來,究竟會變成什麼樣子?


這套高度自動化系統,本質上是發帖人花半年時間建立的一條Pipeline,主要包括四件事。


第一是「文件化」。將原本只存在於員工腦中的業務規則、系統關係與問題排查經驗,整理成AI能夠理解的規格,把隱性知識轉化為顯性知識。


第二是「介面化」。將日誌、資料庫、訊息佇列及發布系統,逐一接入AI可以呼叫的MCP與工具,相當於為AI裝上雙手。甚至連聊天工具也能交由AI操作,讓它直接與業務人員溝通。


第三是建立「Skill」。將人類過往解決問題的方法文件化,整理成可以重複使用的操作步驟,相當於為AI裝上經驗。


第四是賦予AI一個可以在組織內活動的身分,例如機器人帳號。它可以加入群組、主動提問、回覆訊息,甚至直接解決問題,因為它已經接通其他工作流程與系統。


許多公司的聊天工具中已經存在AI機器人,只是自動化程度不同。發帖人打造的AI機器人顯然走得更遠:不只是擁抱AI、使用AI,而是進一步讓AI自動運作。


然而,愈是走在前面的人,危機感往往愈強。因為他們比其他人更清楚AI真正具備哪些能力,也更直接地看見自己的工作如何被取代。


以20分鐘內跨五個服務完成問題排查為例,在傳統公司中,五個服務可能分屬五個團隊。這通常需要召集多人開會,各自檢查日誌與系統,經歷跨部門溝通,甚至互相推卸責任,最後再由資深人員判斷。整個過程可能需要數天,甚至數十天。


AI卻能在不到20分鐘內完成。它取代的不只是技術工作,也一併消除了組織協調與跨部門溝通的成本。


不過,這種效率有一項重要前提:建立AI系統的人必須擁有足夠權限,讓AI能夠存取跨部門的程式碼、資料與系統介面。


目前許多大型企業仍受到組織架構與權限限制。一般團隊通常只能查看自己的程式碼,跨組織存取不僅涉及權限問題,也不符合既有工作習慣。但只要為AI提供相應權限及介面,它就可以跨越這些邊界。


這也是AI Agent與一般聊天機器人的本質差異。聊天機器人只能回答問題,Agent則能穿過組織與系統,實際執行任務並解決問題,甚至處理跨組織的問題。


當AI機器人建立起來後,業務人員遇到問題時,可能不再尋找原本的負責人,而是直接聯絡AI Agent。這會導致原有員工在組織中的可見度與重要性下降,而這些因素通常又是績效評估及職涯發展的重要依據。


即使工程師告訴所有人「這個Agent是我做的」,也未必能永久維持自身價值。當所有工作都被自動化後,組織最終仍會回到一個現實問題:這個人現在還能提供什麼價值?


即便如今價值下降,是因為他過去成功建立了自動化系統,管理者通常仍更在意員工當下能提供的價值,而不是過去的功勞。這正是發帖人感到無力的原因之一。


另一個原因,是他與AI發展的距離太近。普通人可能只是從新聞中得知AI正在變強;他卻每天親眼看著自己搭建的系統變得愈來愈能幹,因此感受更為強烈。


當AI接手大部分工作,他坐在辦公室聊天時也會感到心虛。過去,他認為產出必須依靠自己持續工作;如今,工作卻幾乎全部由AI完成。


歷史上也曾出現類似的技術升級。高階程式語言與編譯器出現時,原本手寫組合語言的工程師也曾懷疑,讓編譯器代替自己產生組合語言後,自己是否還算程式設計師。


後來,手寫組合語言的人雖然減少了,軟體開發者的數量卻大幅增加。因此,今天的AI管線會不會成為舊時代的「編譯器」,仍有待觀察。


問題在於,搭建這類管線的門檻可能並不高,因為工程師同樣可以要求AI協助建設。未來隨著公共MCP與Skill逐漸開放,發帖人花半年建立的系統,其他人可能只需要一天就能完成。


換句話說,先行者目前擁有的護城河,可能只是時間差,而不是永久優勢。


至於他是否真的值80萬元年薪,這筆帳並不容易計算。從公司的角度來看,他建立自動化管線後,個人產出可能提升數倍,甚至十倍。過去需要數名乃至十多名員工完成的工作,如今只需要一個人加上一套AI管線,因此公司支付80萬元,或許仍然相當划算。


但問題是,這套系統並非只有他能使用。換成一名初級工程師,也可能透過相同工具驅動整套流程。如果自動化程度與可靠性足夠高,甚至可以讓AI機器人直接與業務方溝通,完全不需要人類參與。


這也讓問題回到最核心之處:當AI不只提升人的效率,而是逐步接手整套工作流程時,人類在組織中的角色、價值與薪資,將如何被重新定義?

[AI 分享] Claude Code 零基礎入門:安裝、權限與常用命令

[AI 分享] Claude Code 零基礎入門:安裝、權限與常用命令

摘要:從安裝、權限模式到專案記憶與常用命令,帶新手安全上手 Claude Code。



內容:


Claude Code 是 Anthropic 官方推出的 AI 程式設計工具,主要透過終端操作。即使沒有程式基礎,也能用自然語言請它查看檔案、修改內容、修正問題、撰寫腳本、處理資料及生成文件。


終端可以簡單理解為一個輸入框,不必因為它看起來像程式設計工具而感到害怕。Claude Code 不只會回答問題,還能圍繞任務查看檔案、拆解步驟、執行命令,並在需要時等待使用者確認。


目前不少人開始改用 Codex,但 Claude Code 仍有其優勢。它的 Agent 架構相對成熟,能妥善處理上下文、權限與工具呼叫;Claude 模型面對複雜任務時,也較擅長先分析、再規劃,最後才執行。強模型搭配工程化完善的 Agent 工具,通常能帶來更穩定的結果。


安裝 Claude Code


Mac、Linux,以及透過 WSL 使用 Windows 的使用者,可以開啟終端,貼上官方提供的安裝命令並執行。若直接使用 Windows 終端,則要先確認目前使用的是 PowerShell 還是 CMD,因為兩者的安裝命令不同。


安裝完成後,在終端輸入:


claude



若能進入 Claude Code 的對話介面,代表安裝成功。也可以輸入:


claude --version



如果終端顯示版本號,同樣表示安裝完成。


若安裝時出現紅色錯誤訊息、找不到命令或其他問題,不必慌張。可以完整複製錯誤內容,交給其他可用的 AI 工具協助判斷。常見問題多半與網路、權限、終端環境或系統路徑尚未更新有關。


如果安裝後顯示找不到 claude,可以先關閉終端再重新開啟,然後再次執行命令。


用自然語言開始操作


安裝完成後,可以先進入任意資料夾,再啟動 Claude Code,直接用日常語言提問,例如:


這個資料夾是做什麼的?

幫我看看裡面有哪些檔案。

這個專案要怎麼啟動?

幫我整理這個專案目錄的內容。


Claude Code 在修改檔案、執行命令或存取外部資源前,通常會詢問是否批准。這並不是發生錯誤,而是它的安全機制,讓使用者知道它準備執行什麼操作。


選擇適合的工作模式


可以按下 Shift + Tab 切換工作模式。新手最常接觸的模式包括:


Default


預設的手動確認模式,設定較保守。Claude Code 可以直接讀取檔案,但修改檔案或執行命令時,通常會先徵求同意。


Accept Edits


適合已經大致信任執行方向的情況。它會自動批准專案目錄內的檔案編輯,以及建立資料夾、複製或移動檔案等常見操作。遇到複雜命令、敏感操作或專案範圍外的路徑,仍可能要求確認。


Plan


計畫模式非常適合新手。Claude Code 會先檢查專案、查閱檔案並提出方案,但不會立即修改內容。使用者看完計畫並確認後,再讓它繼續執行。


另外還有較積極或特殊的模式,例如 Auto 與 Bypass Permissions。Auto 會透過背景安全檢查減少頻繁確認,但不一定適用於所有帳號、模型及環境。


Bypass Permissions 則會大幅減少權限確認,只適合完全隔離的測試環境、容器或虛擬機器。新手不建議在日常電腦或正式專案中使用。


剛開始使用時,只要記住:不熟悉的任務使用 Default,重要或範圍較大的專案先使用 Plan。


新手安全操作四步驟


第一次使用 Claude Code,可以遵循以下流程:


先開啟 Plan 模式,讓它說明準備做什麼。

看懂並確認方案後,再允許它修改。

修改完成後,使用 /diff 查看實際變更。

如果結果不滿意,使用 /revert 或 /undo 回退。


重要檔案最好事先備份,或納入 Git 版本控制。如此一來,即使結果不理想,也能放心還原與反覆嘗試。


使用 CLAUDE.md 建立專案說明


在專案資料夾中輸入:


/init



Claude Code 會掃描專案並生成 CLAUDE.md。這份檔案就像提供給新同事的入職說明,可以記錄:


專案使用的技術與工具。

專案如何安裝及啟動。

應遵守的開發規範。

哪些檔案或區域不能任意修改。

修改後必須執行哪些測試。

文案應採用何種風格。

腳本應放在哪個目錄。


之後每次在該專案中啟動 Claude Code,它都會先讀取這份說明,省去重複交代背景與規則的時間。


不過,CLAUDE.md 比較像專案囑咐,而不是百分之百強制執行的規則。Claude Code 會參考內容,但不保證絕對服從。相較之下,Hook 更接近強制檢查機制。


若想查看或修改專案記憶,可以使用:


/memory


新手必備命令


在 Claude Code 中輸入 /,就能查看目前可用的命令。新手不需要一次記住所有命令,可以依照使用階段逐步學習。


第一階段建議掌握:


/plan:進入計畫模式,大幅修改前先產生方案。

/diff:查看這次修改了哪些檔案與內容。

/revert 或 /undo:回退至先前的檢查點。

/help:查看命令說明及使用方式。


Claude Code 做錯時不必慌張,確認差異後回退即可。


使用一段時間後再學的命令

/context:查看目前對話使用了多少上下文空間。

/compact:壓縮過長的對話歷史,讓任務繼續進行。

/clear:清空目前會話,適合切換至新任務;專案中的 CLAUDE.md 不會因此消失。

/resume:找回並繼續之前的會話。

/rename:替目前會話命名,方便日後尋找。

/btw:詢問不納入主要對話歷史的題外問題。

進入真實專案後可使用的命令

/model:切換模型。簡單任務可選擇更快或成本較低的模型,複雜任務再使用能力較強的模型。

/code-review:檢查此次變更是否存在明顯錯誤。

/doctor:診斷安裝、登入或設定問題。

/mcp:查看及管理 MCP 連線。

/hooks:查看目前設定的 Hook。

/tasks:查看背景任務的執行進度。


新手不必一次記住所有功能。先掌握安全模式、計畫、差異檢查與回退,再逐步加入專案記憶、模型切換、MCP、Hook 與背景任務,就能把 Claude Code 實際運用在日常工作與真實專案中。

2026年9月15日 星期二

[AI 衝擊] AI 程式設計浪潮下,工程師如何面對「最後一枚銅板」

[AI 衝擊] AI 程式設計浪潮下,工程師如何面對「最後一枚銅板」

摘要 : AI 正加速改變軟體業,但能力提升不等於職位立即消失。



內容:


近期有開發者發文表示,隨著 Claude Code 等程式設計工具快速發展,加上新一代 GPT 模型出現,工程師失業似乎會在一兩年內成為定局。現在上班,就像是在賺職業生涯的「最後一枚銅板」。


我也認為,AI 的能力最終足以取代許多人的工作,只是失業真正大規模發生的時間仍不確定。新模型正逐步具備操作電腦的能力,瞄準白領工作者每天使用的滑鼠與鍵盤;同時,AI 工具的普及率也在快速上升。


根據 JetBrains 的開發者調查,全球專業開發者使用 Claude Code 的比例,從今年初約18%,上升至年中的39%,美國更接近47%。除了 Claude Code,市場上還有 Codex、GitHub Copilot 等工具,意味著 AI 程式設計已迅速進入日常開發流程。


Google 的 DORA 報告指出,軟體開發人員的 AI 使用率已達九成,每天與 AI 協作的中位時間約為兩小時。另一項開發者社群調查顯示,73%的工程團隊每天使用 AI 程式設計工具,一年前則是41%。


有半導體分析機構估計,今年2月由 Claude Code 生成的程式碼,約占全球公開程式碼提交量的4%,年底可能超過20%。無論實際比例為何,AI 可以協助工程師解決問題、撰寫程式碼,已是無法忽視的趨勢。


## 工具普及與裁員同時發生


AI 工具加速普及的另一面,是科技業裁員持續發生。部分企業削減管理職與工程職,甚至連副總裁、新進員工都可能在裁員名單之中。在這種環境下,從業者自然會感覺工作愈來愈不安全,也不敢大幅消費或升級住房。


不過,「正在賺最後一枚銅板」的心態並不是第一次出現。2000年網路泡沫破裂時,工程師圈內就流行過類似說法;2023年初生成式 AI 剛爆發時,也有許多人認為程式設計師即將消失。


幾年過去,程式設計師並未全面消失,但裁員確實發生,入門職位也明顯萎縮。相對而言,資深工程師的職缺沒有同步減少,AI 相關職位還在增加,薪酬甚至出現兩至三成的溢價。


當初認為工程師即將被淘汰的人,如有積極學習 AI 與新工具,如今可能成為企業競相招攬的對象;沒有轉型的人,則可能繼續擔憂被取代,甚至已在裁員中受到影響。


## AI 能力提升,不代表企業能立即裁掉所有人


AI 的能力確實正在跳躍式發展,但從「技術可以完成工作」到「企業真正刪除職位」,中間仍隔著可靠性、組織流程、經濟慣性、法規、預算與責任歸屬等環節。


以 Meta 的內部實驗為例,導入 AI 後,程式碼產出量雖然大幅增加,但真正交付給使用者的功能成長有限,事故數量與救火時間反而增加。這說明更多程式碼不一定等於更多價值,AI 也可能製造新的維護成本。


OpenAI 執行長 Sam Altman 也曾表示,許多人對技術落地的時間表過度樂觀,因為經濟與組織運作的慣性比想像中更大。把模型發布與能力進步的速度,直接當成職位消失的速度,可能會高估一兩年內的衝擊。


## 就業市場正在分裂


目前的招聘市場並非全面惡化,而是出現明顯分化。


史丹佛大學相關研究指出,在最容易受 AI 影響的產業中,入門職位的就業人數下降接近20%,年輕人的求職壓力確實很大。但追蹤大型科技公司的機構也發現,今年在招募的軟體職位數量,可能處於近三年的相對高點。


Indeed 的資料則顯示,資深軟體職位約占整體軟體招聘的70%,AI 相關技能可帶來約30%的薪酬溢價。也就是說,在同一個產業與同一段時間裡,有人的工作正在被取代,也有人因為掌握新工具而變得更加搶手。


## 效率提高之後,工作會更多還是更少?


一項大規模工程效率調查發現,每天使用 AI 的開發者,每週可以合併兩至三個 PR;沒有使用 AI 的開發者,每週平均約為1.3個,效率差距可達六成。


JetBrains 的調查也指出,89%的開發者每週至少能利用 AI 節省一小時,約20%的人每週可以省下八小時以上。


然而,生產工具提高效率後,通常會同時帶來兩種可能:一是企業用更少的人完成原有工作;二是成本下降後,市場產生更多軟體需求,反而需要更多人。最後的就業結果,取決於需求成長與人力縮減哪一方更快。


## 可靠性是阻止全面替代的一道牆


使用 AI 與信任 AI 是兩回事。Stack Overflow 近年的調查顯示,使用 AI 程式設計工具的人愈來愈多,但信任其產出的人反而減少。許多開發者用得愈多,愈不敢完全放手。


只要 AI 生成的結果仍需人工檢查,企業就需要工程師負責審查、修復事故、處理例外情況,並在出問題時承擔責任。這也是許多職缺仍要求傳統工程能力的原因:企業可以大量使用 AI,但最終仍需要有人看著它。


有創業者分享,新產品約八成程式碼由 Claude Code 生成,相關 Token 費用僅三百多美元。生成成本雖然很低,但程式碼是否正確、產品能否上線、事故如何處理,仍不能只看生成程式碼的價格。


## 悲觀不能成為停止行動的理由


如果把努力視為一種品質不高的燃料,那麼「反正只是在賺最後一枚銅板」的心態,等於連燃料都不再添加,直接讓自己熄火。


即使未來可能悲觀,職場仍是一場人與人之間的競賽。重要的不是證明自己永遠不會被淘汰,而是比別人更早適應、更晚被淘汰,替自己爭取更多轉型時間。


公司此刻仍願意支付薪資,並不是因為仁慈,而是因為員工仍擁有企業暫時買不到的能力,包括檢驗 AI 產出的眼睛、修復 AI 事故的腦與手,以及在出現問題時承擔責任的能力。每一筆到帳的薪資,都是尚未被 AI 完全取代的證明。


如果目前真是某種產業形態的末期,那麼薪資也不只是「最後的銅板」,更可以視為一種轉型補貼。穩定收入、公司提供的 AI 工具,以及真實的專案環境,組合起來就是練習下一種技能成本最低的窗口。


## 技術換代時,消失的通常是拒絕轉型的人


從膠片相機轉向數位相機、從傳統報業走向自媒體,每次技術換代都出現過末班車心態。舊產業的從業者並未全部消失,許多人只是轉往新工具與新產業,並把原有的經驗、審美和判斷力帶過去。


AI 的不同之處,在於它可能同時影響程式設計、文案、客服、分析、會計、設計、法律與醫療等大量白領工作。它不只是替代單一工具,而可能逐漸接近對人類智力工作的全面替代。


但在現階段,人仍需學習如何指揮 AI、驗證 AI,並將它的能力轉化為真正可用的成果。


## 如何使用「最後一枚銅板」


第一,把薪資當成訓練預算。每週固定安排數小時學習與實作,利用 AI 開發產品,找出它無法處理的部分,並學習如何改善整個流程。除了提升正職能力,也可建立自己的副業或作品。


第二,準備足夠的現金緩衝。失業恐慌很大一部分來自每月帳單,因此應評估自己在沒有收入時可以生活多久。資金愈充足,面對技術變化與裁員時就愈有選擇權。


第三,把職務往 AI 難以獨立完成的方向移動,例如判斷結果、審查品質、處理事故、跨部門協調,以及承擔最終責任。既然每個人都在爭取更多時間,就應往較難被自動化的位置靠近。


第四,不要為了躲避 AI 而衝動裸辭。AI 最終可能滲透每一個產業,逃離的成本通常高於適應的成本。轉到新產業後,一切都要重新開始,而等到適應完成,AI 也可能已經進入該領域。


第五,看清楚自己所在公司的狀態,包括公司是否獲利、是否正在裁員、商業模式是否健康,以及自己的團隊是否屬於核心業務。不同公司的風險差距,可能比不同職稱之間更大。


第六,建立多種收入來源。副業收入即使不高,也能降低對單一工作的依賴,並提供測試新技能與商業模式的機會。


## 能力爆發與職位消失是兩張時間表


部分研究員與企業領袖認為,AI 可能在未來一至五年內大幅超越人類能力。這些預測未必毫無根據,因為模型能力確實可能在一兩年內再次爆發。


但能力提升與職位替換之間,仍隔著可靠性、組織慣性、經濟週期、合規要求、企業預算與責任制度。公司即使知道 AI 能提高效率,也未必會立刻重建所有流程並裁掉全部員工。


未來一兩年內,IT 產業未必立即出現全面失業潮,但職位結構很可能持續變形:部分職缺減少,入門門檻提高,資深人才與一般人才的收入差距擴大,能熟練使用並監督 AI 的人則獲得更高價值。


AI 最終也許真的會取代大量工作,但至少在目前,最危險的不是 AI 已經無所不能,而是人在它尚未完全成熟之前,就先因悲觀而放棄學習與行動。

2026年9月13日 星期日

 [AI 洞察] 當百個AI Agent加入專案:軟體工程如何重新分工

摘要 : AI Agent加速開發與維護,也迫使團隊重思架構、文件及工程師角色。


內容:


如果一個週末內,就有100個AI Agent加入你的軟體專案,最先跟不上節奏的會是什麼?


在9月9日釋出的《The Pragmatic Engineer》播客訪談中,Codex早期建立者之一、負責OpenAI核心產品與平台組織的Dibble Sodiol提出一個對比:過去,一個小團隊可能要發展一年,才會有50至100名工程師參與;現在,100個Agent同時貢獻程式碼,一個週末就可能發生。


當程式碼產出突然加速,專案的複雜度也會更快到來。原本還有時間逐步補上的文件、模組邊界與協作方式,可能很快就要接受考驗。這也帶出一個更長遠的問題:當AI開始接手軟體維護、審查與重構,人類工程師應該把注意力放在哪裡?一個會寫程式碼的模型,又需要經歷哪些變化,才能真正承擔這些工作?


Dibble將軟體維護比喻為一筆持續繳納的稅。功能完成後,為了讓它繼續正常運作,團隊仍要升級第三方依賴、跟進安全補丁,並讓舊程式碼適應新需求。這些工作未必會增加可展示的新功能,卻決定了專案能否健康地延續。


以依賴升級為例,如果變更日誌清楚、文件完善,模型便能理解新版帶來的影響,並在程式碼庫中完成大範圍調整。這類過去因枯燥、麻煩而不斷延後的工作,現在可能在幾小時內推進。


Agent做的也不只是修改版本號,而是讀懂新版變更、找出專案中受影響的位置、調整程式碼並驗證結果。當模型能將這些分散步驟串連起來,維護工作便有了自動化的可能。文件也因此產生新的價值:變更條件交代得越明確,Agent越容易判斷哪些呼叫需要修改,專案留下的知識將直接影響自動化品質。


當維護成本下降,團隊評估新功能的方式也會改變。工程師仍須提出證據,說明改動會受到使用者歡迎、值得加入產品,也值得長期維護;但如果後續照顧功能的負擔降低,一些過去不划算的嘗試,就有了重新討論的空間。


不過,團隊仍要回答:這個功能究竟幫助了誰?它是否與整體產品協調?


Dibble曾在Google參與一項改善網頁、尤其是行動版網頁速度的專案。技術問題很有挑戰性,他也很享受這份工作,但大約兩年後,專案因只有幾百名使用者、未達Google期待的規模而被取消。


這段經歷讓他持續追問:正在做的事情有什麼影響?專案為何重要?技術上的興奮,必須與真實使用者的回饋一起衡量。


後來,他在DeepMind與OpenAI從事研究基礎設施及工具開發,關注如何讓其他人更有效率。Codex的一部分前身也源自這項需求:讓模型協助研究人員與工程師,更快建構內部系統。


團隊最初訓練內部模型,讓它熟悉OpenAI的Python程式碼庫,使其產出的程式碼風格與架構選擇更符合內部需要。這項工作之後與「自主軟體工程師」方向合併,逐漸形成面向外部使用者的產品。


但這條路也經歷過調整。Dibble表示,早期的雲端Codex使用阻力較大,尚未找到良好的產品市場契合點。團隊持續推出CLI並反覆迭代,才逐步將模型能力轉化為使用者願意採用的工具。


這也引出訪談中的關鍵概念:harness。它可以被理解為包在模型外面的執行系統。模型負責理解任務、推理並決定下一步;執行系統則負責組織工具、指令、執行環境與安全限制,讓模型能讀取檔案、執行命令、查看結果,再根據結果繼續行動。


當使用者說「幫我把這個功能改好」,模型接收到的是一個目標,但真正完成目標,還需要把需求理解、程式碼修改與驗證串成完整流程。只要中間遺漏一步,最終交付就可能不完整。


主持人提到,早期使用Codex時,模型修改完程式碼後,有時不會主動執行既有測試;後來產品開始自行完成這一步。這究竟是模型變強,還是外部程式與指令改變?


Dibble的回答是:兩者都在變化。早期模型無法穩定完成的事情,可以由執行系統先行提醒,例如要求模型修改後執行測試。等到下一代模型更能理解使用者真正想要的結果,這類提醒便可能不再必要。


因此,harness總會比模型領先一點。它先以額外支撐,讓當前模型更可靠、更有效率,也更容易被使用者控制;當下一代模型吸收部分能力後,這些外部支撐便能逐漸縮減。


對開發團隊而言,這也產生一項特殊取捨:發現模型弱點後,應投入多少工程資源彌補?研究團隊可能在一個月後改善模型,也可能需要三個月或半年。產品團隊必須綜合判斷,是立即修改執行系統,還是等待模型層面的解決方案。


Dibble特別不鼓勵為了繞過模型缺陷,建立上萬行複雜程式碼。因為模型一旦更新,這套龐大的結構可能很快失去存在的必要。Agent產品團隊因此必須持續理解模型邊界,判斷哪些部分值得長期建設,哪些只是現階段的臨時輔助。


不過,有些底層設計仍值得從一開始就重視,例如Codex核心選擇Rust。當時模型對Rust的熟練程度不如Python等語言,但團隊更看重正確性、效率、穩健性與安全性,同時也擁有能力很強的Rust開發者。


Rust能在編譯階段提供大量檢查,這些明確回饋對Agent也有幫助。程式碼發生問題時,Agent可以更早取得提示,再據此修改。Dibble認為,只要投入足夠的訓練與工程資源,Rust也能成為適合Agent使用的語言。


更深一層的考量,是將Agent本身與產品介面分開。Agent可以在不同環境中執行,介面則負責讓人使用它。如果兩者過早綁在一起,未來發展新的產品形態時,就容易受到既有結構限制。即使AI讓重寫程式碼變得更容易,良好的初始架構仍能減少後續阻力。


這一點在多個Agent同時工作時更加重要。Dibble以「盒子」比喻模組:團隊先約定盒子要完成的功能、資源使用方式、資料存取與安全要求,以及哪些條件必須始終成立。只要符合這些約定,盒子內部的實作便可以更靈活地變化。


放回軟體工程中,這就是清楚的模組邊界。一個模組修改內部邏輯時,其他部分仍可依賴既有約定運作,讓變更被限制在可理解的範圍內。


過去,系統重構可能耗費數年。即使團隊發現原本架構已經限制新功能,或對工作負載有了新的認識,也未必有能力立即調整。Dibble認為,Agent正在大幅加速這類工作,降低修正錯誤選擇的成本;但這種速度更需要清楚的結構承接。


盒子的邊界劃分得越好,內部就越能快速修改,同時減少對其他服務的影響。程式碼越容易變動,團隊就越需要知道:哪些東西可以改,哪些約定必須保持穩定。


這正是100個Agent在短時間內加入專案所帶來的問題。人類團隊逐步擴張時,大家還有機會觀察協作困難、補充文件並整理結構;Agent加入的速度快得多,軟體會在短時間內走過原本漫長的生命週期。


模型本身也持續進步,開始更能考慮長期維護與架構問題。關注點正從單一檔案是否整潔,延伸到整個系統能否支援未來的功能變化。人與Agent討論的內容,也會逐漸從「這一段程式碼怎麼寫」,轉向「整個系統應該如何組織」。


程式碼審查則提供了另一個觀察視角。Dibble早期曾參與程式碼審查模型的開發。他提到,有些錯誤極難發現:開發者依照文件理解第三方程式庫的行為,但程式庫的實際實作與文件描述並不完全一致。


要找出這類問題,可能需要沿著依賴關係向下追查三、四層。人工審查往往得花數小時,甚至需要熟悉相關依賴的實作細節。這類需要大量閱讀、追蹤與交叉驗證的工作,正是AI Agent未來可能協助工程師處理的方向。


當AI開始大量產出、維護、審查與重構程式碼,人類工程師的價值不會只剩下「寫得比模型更快」,而是更集中於定義問題、理解使用者、設計邊界、建立約束,並判斷哪些結果真正值得交付。


AI讓程式碼變得更容易產生,也讓好的文件、清楚的架構與穩定的協作規則變得更加重要。真正跟不上100個Agent速度的,可能不是打字與寫程式碼的能力,而是團隊理解系統、管理複雜度,以及決定產品方向的能力。

2026年9月10日 星期四

AID09-Agent 上工之前,你要先給它一間房間-5分鐘學AI

 AID09-Agent 上工之前,你要先給它一間房間-5分鐘學AI



同一個 Agent,換一個工作環境,做得出來的事差很多。 它做不出來,常常不是它不會,是沒有人先幫它擺好。 #一起搞懂AI #AI名詞 #AI入門 #白話AI #企業AI Agent 上工之前,你要先給它一間房間。 阿哲,上一集你教我問,這件事的下一步是誰決定的。我拿去問了,兩邊都說是它自己決定,可是一邊做得出東西,一邊什麼都做不了。你問對了,只是那句話只問到一半。誰決定下一步是一回事,做不做得成是另一回事。差在哪裡?模型不一樣嗎?常常是同一個。差在它待的地方。你想想自己第一天到職:公司先給你座位、帳號、一本規矩,你才做得了事。這一集講的就是,有人得先幫它把這一整套擺好。 那第一樣要幫它準備什麼?一張規矩紙。放在案子的資料夾裡,寫上東西怎麼稱呼、哪些不能動、做完要交什麼。它一進來就先讀這張。 那 Agent Skill 呢?聽起來像它學會了什麼技能。不是它學會,是你先寫好。把某件事的做法整包寫下來收著,平常它不看,碰到那件事才翻出來讀。 這兩張我分不出來,不都是寫給它看的嗎?差在什麼時候看。一張是它每次進來都會讀的,所以只能寫最重要的幾條;另一包收在旁邊,碰到才拿出來。喔,就像我家牆上貼的那張紙?垃圾幾點丟、鞋子放哪裡,誰進門都看得到。可是洗衣機怎麼用寫在說明書裡,我要洗才會去翻。非常準。要小心的是,很多人把整本說明書抄到門口那張紙上。還記得那張桌子嗎?門口這張每次都要先攤上去,它越長,桌上留給正事的位置就越少。 紙讀完了,它就可以開始動手了嗎?動手之前還有一件事:它在哪裡動手。做法是給它一間關起門的房間,裡面隨便它改,弄壞了也波及不到外面。 這個我要問。前幾集你留了伏筆,說單子開出來以後,誰去執行、有沒有權限執行是另一件事。是在講這個嗎?先還你一半:它在哪裡動手。所有動作都關在房間裡發生,外面的東西它碰不到。至於有沒有權限拿到什麼,還有一集要專門講。喔,就像我小時候玩顏料,我媽在地上鋪一大張塑膠布,說你要潑要灑都在布上面。玩完整張捲起來丟掉,地板還是乾淨的。就是這個畫面。最容易誤會的是,關起門不是為了防它學壞,是為了讓你敢放手。弄壞了沒關係,是因為壞掉的範圍你事先就畫好了。 那房間裡的工具怎麼進來?你說過要先接上去,它才有單可以開。麻煩就出在那個接。以前每接一樣東西就要重寫一次,十樣就寫十次。後來大家講好一種共通的接法,這份規格就叫 MCP。 可是這名字我完全看不懂。模型脈絡協定,這六個字在講什麼?名字很糟,意思很單純。它是一份大家講好的規格,規定工具怎麼自我介紹、AI 怎麼呼叫它。照這份規格做的工具,接上去就能用。喔,就像充電線!以前每支手機一種孔,出門要帶一大包;現在都同一種頭,一條線走到哪都插得上。這個比喻最準。要小心的是,插得上不代表你該全部插上去。工具接越多,它每次要挑的東西就越多,反而更容易挑錯那一個。 那這些事是誰在做?我以為就是同一個 AI 從頭做到尾。不一定。模型有貴有便宜、有快有慢。所以有人會在前面加一段分派:簡單的問題交給便宜的做,難的才叫貴的出來。 為什麼不乾脆全部都用最好的那一個?反正比較準。因為貴,而且慢。大部分問題其實非常簡單,用最好的那個去回一句幾點下班,錢跟時間都花在不需要的地方。喔,就像打客服電話?一般的問題第一線就處理掉了,真的難的他才幫我轉給後面的專員。就是這個。要注意的是,分派那一關自己也會分錯。它把難題判成簡單的,你就會拿到一個又快又便宜、可是不夠好的答案,而且看起來跟平常一模一樣。 講了這麼多,有沒有一個我真的看得到的東西?有。有一個開源的 Agent,中文圈叫它小龍蝦,因為它英文名字裡有 claw,就是蝦鉗那個字。它不是一個你去登入的網站,是你可以自己裝起來跑的。 開源是什麼意思?跟我平常用的那些差在哪?開源就是它的做法整個攤開給你看,你可以自己拿去裝、自己改,養在你自己機器上。所以它剛好就是我們前面講的那一整套?規矩紙、房間、插座、哪一題叫誰做,全部都要我自己給它。對,這就是它有意思的地方,前面五樣不再是概念,你會一樣一樣自己擺出來。最容易誤會的是,裝起來不等於它就會做事,房間沒畫、工具沒接,它一樣什麼都做不了。 那我們最後重新排一次好不好?好,你來。AGENTS.md 是放在案子裡的一張規矩紙,它進來就先讀。Agent Skill 是一包寫好的做法,需要才翻出來。Sandbox 是一間關起門的房間,讓它在裡面動手,弄壞了不會流到外面。MCP 是接工具的共通插座,不用一個一個接。Model Routing 是簡單的派便宜的做,難的才叫貴的。小龍蝦是一個開源的 Agent,你可以自己裝起來跑。完全正確。所以下次它什麼都做不了,先看看它的房間:紙有沒有寫、門有沒有關、插座接了沒。它站在一間空房間裡,再厲害也只能站著。 企業級智庫引擎。讓公司的知識,答得出來、查得到、帶不走。

AID08-你只給目標,AI Agent 自己決定步驟-5分鐘學AI

 AID08-你只給目標,AI Agent 自己決定步驟-5分鐘學AI



Agent 不是更聰明的模型,是誰決定下一步換人了。 會自己繞圈找路的東西,繞得很順也可能繞錯方向。 #一起搞懂AI #AI名詞 #AI入門 #白話AI #企業AI 你只給目標,AI Agent 自己決定步驟。 阿哲,上一集你說 AI 會開一張單子,請外面的程式做事。那大家在講的 Agent,又是什麼?算是同一條路再往前一步。我先問你,那張單子什麼時候該開、開完接著做什麼,是誰決定的?呃⋯⋯是我吧?流程是我排的,它只負責中間那幾格。對,差別就從這裡開始。這一集講完你會發現,整件事只有一句話:以前是你排步驟、它做事;現在是你講結果,步驟換它想。 那我們從最中間那個字開始。Agent 到底是什麼?它是一個你交代目標、自己想辦法完成的東西。你不用告訴它先做什麼再做什麼,只要把你要的結果講清楚。 那 Agentic AI 呢?多了幾個字母,是另外一個嗎?不是另外一個產品。Agentic 是形容詞,講的是一件事自主到什麼程度。有人說某個功能比較 Agentic,那是在講程度。 所以 Agent 就是比較聰明的那一種自動化?差別不在聰不聰明,在誰決定順序。以前是你把每一步排好,它照著跑;現在你只講你要什麼,中間怎麼走它自己安排。喔,就像找路!我可以自己一路問人,也可以印一張地圖照著走,或者上車輸入一個地址,讓導航帶我去。就是這三種。要小心的是,Agentic 不是一個開關,是一條光譜。同一個產品裡,有的功能你按一下動一步,有的自己跑二十分鐘。那我怎麼知道手上那一個是哪一種?看你要不要盯著。每一步都要你按確認的,你還是那個排流程的人;你講完就去忙別的,方向盤才算交出去了。 可是它拿到一個目標,第一步要做什麼,怎麼知道?它會先把你交代的那件事,拆成一條一條要做的事,排出先後。這一段就叫 Planner,中文是規劃器。 拆完之後照著做完,就結束了嗎?沒有。它做一步就停下來看結果,看完再決定下一步,一直繞。繞到事情做完,或者繞到它放棄為止。 繞來繞去不是很浪費時間嗎?拆好了一路做完,不是比較快?快,但只在你一開始就猜對的時候。計畫是它還沒動手之前想的,做了第一步才發現名字對不上,硬照原計畫走只會把錯的做完。喔,就像我出門辦事,本來排好先去銀行再去郵局。到了銀行才發現印章沒帶,我就當場改成先去郵局。關鍵就是那三個字,當場改。排好的流程走到卡住那一格就停在那裡。但要提醒你,會繞圈不等於會成功,它也可能繞錯方向繞得很有效率。那它會不會就這樣一直繞下去?通常會設一個上限,繞幾次就停。所以看到它跑很久都沒交東西出來,不一定是在深思,也可能是在原地打轉。 繞了這麼多圈,前面做過的事它還記得嗎?這要接回我們講過的那張桌子。它每繞一圈,桌上就被塞進更多東西:剛查到的、剛失敗的、剛拿到的結果。所以要有人決定什麼留在桌上。 那全部留著不就好了?留著它就什麼都看得到。桌子的大小是固定的。留太多,重要的那一條就攤不上去了;而且桌上越亂,它越容易被不相干的東西帶走。喔,所以不是它記性好不好,是桌面要有人整理。就像我桌上堆到滿出來,反而找不到今天要用的那一張。就是這樣。所以做得好的 Agent,會把前面幾圈整理成幾行結論,過程收起來。要注意的是,收起來的就真的不見了,除非有人放回桌上。那我可以自己幫它整理嗎?可以,而且是最有效的一招。你在中間停下來跟它說,現在的結論是這三條,前面的別管了,它接下來會穩很多。 最後一個。有人說要開一整組來做事,那是什麼意思?就是把一件大事拆給幾個角色。一個找資料,一個負責寫,一個負責挑錯,各做各的那一段,做完再交給下一個。 那是不是開越多越快?多幾個角色一定比較強吧。不一定。多一個角色,就多一個交接的地方。前一個做完的要講給下一個聽,講的時候一定會少講一點,下一個就照著少掉的版本做下去。喔,就像接力賽?跑得再快,掉了棒還是全部重來,真正會出事的都在交棒那幾公尺。非常準。所以要問的不是可以拆成幾個,是交出去的東西講不講得清楚。多一個角色不等於多一分力,是多一個掉棒的機會。那什麼時候才該拆?一個角色要顧的事太多、開始顧此失彼的時候。簡單的事別拆,兩個人做一件小事通常比一個人慢。 那我們最後重新排一次好不好?好,你來。AI Agent 是你只給目標,步驟由它自己決定。Agentic AI 講的是自主到什麼程度,是一條光譜,不是一個產品。Planner 是出發前先把事情拆成一步一步。Agent Loop 是做一步、看結果、再決定下一步,它會因為看到結果改計畫。Agent Memory 是決定桌上留什麼、什麼收起來。Multi-Agent 是拆成幾個角色分工,交接的地方最容易掉東西。完全正確。以後有人跟你說這是 Agent,你只要問一句:這件事的下一步,是誰決定的? 企業級智庫引擎。讓公司的知識,答得出來、查得到、帶不走。

AID07-Function Calling 是 AI 開的一張單子-5分鐘學AI

 AID07-Function Calling 是 AI 開的一張單子-5分鐘學AI



API 是兩套系統講好的窗口,流程是你排好的順序。 模型只負責開單子,真正動手做事的,從來不是它。 #一起搞懂AI #AI名詞 #AI入門 #白話AI #企業AI Function Calling 是 AI 開的一張單子。 阿哲,我問一件很實際的事。我叫 AI 幫我查這個料號還有沒有庫存,或是開一張發票,它做得到嗎?這個問題很好。它回你的那一段話,跟它真的去查了一次,是兩件完全不同的事。咦,可是它回我的時候講得很肯定啊。講得肯定不代表它去查過。這一集講完你就知道,它從頭到尾沒有動手,它只是開了一張單子,真正去做的是別人。 那我們從第一個名詞開始。API 這個字我天天看到,可是不知道它是什麼。它是兩套軟體之間講好的一個窗口。你照它規定的格式把要求送進去,它照規定的格式把結果送回來。 所以我要用別人家的功能,就是走這個窗口?對。雙方要先講好:你送什麼進來、我回你什麼。格式對不上,窗口就不理你。喔,就像去店裡點餐?我不會自己走進廚房炒一盤,我填一張單子交出去,廚房照單做,做好再端出來給我。這個比喻很準。你不需要知道廚房裡面怎麼運作,只要知道單子上有哪幾格可以填。那 API 是最近才有的嗎?感覺是跟著 AI 一起冒出來的。這是最常見的誤會。API 比 AI 老得多,它本來就不是 AI 的東西,是所有軟體之間互相講話的方式。那我平常有用到嗎?天天在用。你在網站上刷卡,網站自己沒有在算錢,是把資料送到銀行那個窗口,等一句成功或失敗。 第二個名詞叫 Workflow,中文就是工作流程。這個我好像懂,可是講不出來。它是一串固定順序的步驟,一步做完換下一步。誰來跑都同一條路,它不會自己改順序。 那它跟我平常做事有什麼不一樣?我也是一步一步做啊。差在它被寫死了。這一步做完一定接下一步,中間不會有人臨時改主意。喔,就像公司的報帳流程?我把單據交出去,先給主管簽,簽完才到會計,會計核完才付款。就是這個。今天換一個新同事來跑,他也是走同一條,因為順序不是他決定的。那遇到一張怪怪的單據呢?它不替你判斷,只會照寫好的往下送。所以它其實一點都不聰明?對,但這正是它值錢的地方。它不聰明,所以每一次都一樣。要出貨、要對帳,你要的就是每一次都一樣。 那 AI 工作流程呢?是不是讓 AI 自己去跑流程?不是。路線還是你排好的,只是中間某幾格本來要人來判斷,現在換成讓 AI 判斷。 那我還是不太懂,哪幾格會換成它?舉一個具體的。一封客戶來信進來,先收信,再判斷這封是不是客訴,最後分給對的窗口。中間那一步以前要人讀完才知道,現在交給它讀。喔,就像工廠的生產線?整條線的順序沒有變,只是其中一站本來是人在挑,現在換成機器在挑。非常準。線怎麼走沒有動,動的是站在那一格的人。它做得好不好,還是看你那條線排得對不對。那我常聽到有人說,這樣就等於有一個 AI 在幫我做事?這裡要很小心。這條路線是誰排的?是你排的。它拿到的是一格寫好的工作,不是一整件事情。所以它不會自己說,這一步應該先做別的?不會,那不在它的權限裡。要能自己決定先做哪一步,那是另一種東西,我們下一集專門講。 最後一組。Function Calling 這個字我看過好幾次,每次都跳過。它講的是模型自己開一張單子出來,上面寫著請幫我查這個料號的庫存。單子開好,交給外面的程式執行。 那 Tool Calling 呢?看起來很像。是同一件事的另外一面。你先把查庫存、開發票這些工具接上來,告訴它有哪幾種單可以開,它才開得出來。 等一下,所以是它自己跑進我的系統查資料嗎?不是。它從頭到尾沒有碰到你的系統,只是寫出一張單子,說我需要這個料號的庫存數字。喔,那就像我在櫃檯寫一張申請單?我不會走進倉庫自己翻,我把單子交出去,倉庫的人查完,把數字寫回來給我。就是這個畫面。結果送回它手上,它才拿那個數字寫成一句話回你。它講的庫存是真的,因為那個數字不是它自己想出來的。那如果沒有接這些工具呢?那它就只能用讀過的東西回你,聽起來一樣肯定,可是那不是你倉庫裡的數字。同一句話,有接跟沒接差非常多。所以它開得出單子,就代表這件事做得到囉?這裡先留一個伏筆。單子開出來以後,誰去執行、有沒有權限執行,是另一件事,後面幾集會好好講。 那我們最後重新排一次好不好?好,你來。API 是兩套系統之間講好的窗口,照格式送進去,照格式回來。Workflow 是固定順序的步驟,誰來跑都走同一條。AI Workflow 是路線還是你排的,只有其中幾格換成它來做。Function Calling 是它開一張單子,請外面的程式去執行。Tool Calling 是你先把工具接上來,它才有單可以開。完全正確。以後聽到有人說 AI 幫我做了什麼,你只要問一句:那件事,是誰真的動手做的? 企業級智庫引擎。讓公司的知識,答得出來、查得到、帶不走。

2026年9月9日 星期三

[AI 警示] 馬斯克的AI失控論與無法停止的競賽

[AI 警示] 馬斯克的AI失控論與無法停止的競賽

摘要 : 馬斯克一面警告AI失控,一面加速入局,揭示產業難以踩下煞車的囚徒困境。



內容:


據科技媒體《The Information》爆料,SpaceX 以600億美元收購AI程式設計工具公司Cursor。馬斯克隨後在全員會議中表示,AI模型終有一天會先進到人類無法控制,既然失控難以避免,SpaceX就必須趕在其他公司之前造出來。


這套說法引發一個矛盾:如果AI失控意味著它可能控制甚至毀滅人類,那麼搶先創造它的意義是什麼?相較於OpenAI、Anthropic等公司強調「AI有風險,因此必須謹慎、安全地開發」,馬斯克的說法更接近競賽邏輯——既然無法阻止,就要由自己率先抵達終點、取得規則制定權。


回顧馬斯克過去對AI的態度,這種矛盾長期存在。2014年,他將研發AI形容為「召喚惡魔」,並稱其為人類最大的生存威脅。2015年,他參與創辦OpenAI,希望避免最強AI被Google等單一企業壟斷;2018年,他退出OpenAI。


2023年3月,馬斯克簽署公開信,呼籲全球實驗室暫停訓練更強大的AI模型六個月。然而僅四個月後,他便成立xAI。公開信雖有三萬多人簽署,卻沒有主要實驗室真正停下研發,呈現出典型的囚徒困境:所有人都認為AI有危險,卻沒有人敢率先停止,因為先停下來的一方幾乎確定會在競爭中出局。


馬斯克曾估計,AI造成災難性後果的風險約為10%至20%;五年內,AI智慧可能超過全人類的總和,十年內人類或將失去控制權。但他同時認為,AI是實現物質極大豐富、釋放龐大生產力的必經之路。即使存在風險,其潛在收益仍值得投入。


國際競爭也讓AI更難停下。算力高度依賴電力,而各國在能源、晶片及模型能力上持續角力。若美國停止研發、其他國家卻繼續前進,結果可能不是更加安全,而是由另一個國家率先取得優勢。因此,AI競賽的煞車不斷被安全、經濟與國家競爭等理由拆除。


馬斯克的公開說法也曾出現前後不一。在與OpenAI執行長奧特曼相關的訴訟中,他宣誓作證時表示,特斯拉沒有追求通用人工智慧的具體計畫;但在此之前,他又曾發文稱,特斯拉可能成為率先創造通用人工智慧,甚至人形版本AGI的公司之一。這可能反映立場矛盾,也可能是其規畫快速變化。


對馬斯克而言,「警告AI」與「親自投入AI」或許並不衝突。他可能相信,既然競賽無法停止,誰先創造出強大AI,誰就能制定規則;即使AI終將失控,由自己主導也可能建立較好的規範,或至少延緩失控。


這並非馬斯克一人的邏輯。OpenAI、Anthropic、Google及各國政府,都傾向相信自己才是更安全、更負責任的開發者。因為不信任競爭者,卻對自身能力過度有信心,各方反而全力加速,最終使AI競賽本身走向失控。


馬斯克也經常提出非常激進的時間預測。他將2026年形容為AI的「奇點之年」,並預測通用人工智慧可能在近期實現、2030年前後超越全人類。然而,這類預測未必適合直接當作個人決策的時間表。


例如,若學生因相信白領工作即將全面消失而放棄升學,外科醫生因聽信短期內會被機器人取代而轉行,或投資者因AI前景而過度集中投資,都可能承擔重大損失。AI的發展方向值得參考,但預測中的「三年、五年、十年」往往可能延後,甚至出現數倍誤差。


尤其外科手術涉及極高精度、複雜判斷與責任問題,機器人的模式識別能力最終或許能超過人類,但從技術成熟到大規模臨床應用,仍可能需要很長時間。對普通人而言,更合理的做法是重視趨勢,而不是把科技領袖給出的日期視為確定日程。


至於SpaceX收購Cursor的價值,主要可能來自兩項資產。第一是入口:大量程式設計師將Cursor作為日常工作工具,掌握入口就能影響整個開發流程。第二是資料:使用者如何修改、刪除程式碼,在哪裡受阻,以及哪些提示詞最終被採用,都是訓練下一代程式設計AI的重要資料。


不過,Cursor本身並未掌握基礎大模型,其競爭力主要來自使用者規模、產品體驗、工作流程及模型整合能力。若其他程式設計工具能完整取代其功能,導致使用者快速流失,那麼600億美元的收購價格便可能過高;反之,若它能持續掌握大量使用者與程式設計入口,其戰略價值仍然可觀。相關交易與金額仍應以公司公告及可靠資料為準。


對普通人來說,我們既是AI競賽的旁觀者,也是競賽結果的承受者。科技巨頭押注的是歷史地位與企業市值,一家公司失敗後還可能有下一家公司;普通人押上的卻是工作、家庭、孩子的前途與自己的人生。


因此,不應盲目相信任何一位競賽參與者的預言,也不要完全依照他們給出的時間線安排人生。更實際的做法,是假設AI競賽不會有人主動踩下煞車,在此前提下持續學習新工具、提升判斷能力、保留職涯彈性,並做好財務與生活上的風險準備。


AI帶來的未來可能非常黑暗,也可能極度繁榮,但可以確定的是,轉變過程很可能充滿動盪。看清競賽規則、避免迷信預言並提前準備,並不是悲觀,而是清醒。

2026年9月7日 星期一

[AI 衝擊] AI時代,程式設計的意義還剩什麼?


摘要:當AI讓實作變得廉價,程式設計師該如何重新尋找成就感與自身價值?


內容:


8月18日凌晨,Hacker News出現一篇令人扎心的文章:「還有沒有人覺得一切都沒有意義了?」發文者是一名程式設計師。他對新軟體發布失去感覺,也懷疑學習新的電腦科學概念、準備面試及開發個人專案是否還有價值,因為AI一天就能生成大量作品,而眼前的職位明年甚至可能消失。


文章很快獲得297個讚與175則留言。有人深感共鳴,有人反駁,也有人從中談起哲學。發文者用「遊戲開了作弊碼」形容這種感受:當什麼都能輕易做到,一切也就失去了樂趣,彷彿人的意義與快樂都被奪走了。


一名網友以遊戲《Factorio》為例。玩家之所以投入,是因為資源有限,必須不斷規劃與最佳化;但輸入作弊碼、一路輾壓到結局後,很快就會對遊戲失去興趣。人類長久以來都在為生存與資源奮鬥,如今許多事情都被安排妥當,每天只需面對螢幕工作,感覺就像遊戲突然進入終局。


這個比喻揭露了AI帶來的一項心理衝擊:能力快速通膨,成就感也隨之縮水。AI貶值的不只是程式碼,更是「困難」本身。


過去,程式設計師的成就感來自「這件事很難,而我做得到」。無論是學習一門語言、理解編譯原理、處理分散式系統,或解決詭異的錯誤,都需要投入大量時間、經驗與智力。如今,AI代理可能在數小時內完成過去數週的工作,於是人們開始懷疑:既然誰都能做到,那麼我做到又代表什麼?


有位網友形容,程式設計就像下棋,而AI則是象棋引擎。贏棋固然重要,就像交付產品一樣;但開著引擎贏棋,無法帶來真正的快樂。他更尖銳地指出,許多程式設計師未必喜歡下棋,只是喜歡「贏」。以前能贏,是因為別人做不到;現在任何人都可能在AI協助下完成,那麼原有的價值感也會受到挑戰。


這也迫使每個人回答一個問題:自己真正熱愛的是程式設計,還是勝過別人的感覺?


另一種失落與失業無關,而是來自工作體驗的改變。以前的開發流程是理解問題、思考、撰寫程式碼、除錯並完成作品;現在則逐漸變成描述需求、讓AI代理撰寫、審查結果、調整提示詞,再進行驗證。人從創造者轉變為管理者。


即使系統架構仍由自己決定,只要大量實作並非親手完成,就很難真正內化整個系統。對真正喜歡寫程式的人而言,審查本身並不好玩,無論審查對象是人還是AI。雖然AI輔助開發在短期內能快速帶來成果,但時間久了,一些人會開始覺得:「這不是我的專案。」


因此,有人刻意保留幾個只用傳統方式撰寫的個人專案,完全不使用大型語言模型。一名網友凌晨三點半仍在開發命令列工具,把地圖資料轉換成向量圖磚。沒有人要求他這麼做,也沒有產出壓力,他只是單純想寫。


這就像有人堅持使用底片攝影、機械錶或手沖咖啡。它們的價值不一定來自效率,而是來自手感、過程,以及「這是我親手做的」所帶來的滿足。


第三種衝擊則落在知識上。過去,資料庫、編譯器、網路與分散式系統都需要多年學習。知識稀缺,專家自然稀缺,專業能力也因此具有價值。大型語言模型大幅降低了取得知識的成本,也讓原本的門檻逐漸消失。


同時,AI議題也排擠了其他技術討論。過去人們會談語言、協定、演算法與架構,如今這些話題受到冷落,因為沒人確定它們未來是否仍然重要。個人發表的內容甚至可能迅速被納入訓練資料,最終與作者姓名完全脫鉤,形成一種徹底的商品化。


然而,取得資料與真正理解資料是兩回事。


一名網友曾要求大型語言模型為他設計完整的電池產業課程。AI提供的資料非常豐富,課程架構也很漂亮,但真正開始學習後,他才發現最大的問題是:自己根本不知道有哪些事情是自己不知道的。


AI可以讓知識取得近乎免費,卻無法讓理解也同步免費。判斷力、心智模型、經驗脈絡,以及辨識問題可能出在哪裡的能力,仍需要人親自累積。正如該名網友所說:「理解事物依然重要。」


這場討論也並非完全悲觀。另一派人認為,AI出現後,程式設計才真正開始變得有趣。


過去,大量時間耗費在樣板程式碼、CRUD、環境設定、查詢API與機械式除錯上。如今,這些工作可以交給AI代理,人終於能把注意力放回真正的問題:「我到底想做什麼?」


有人表示,自己過去執行力不佳,專案總被無聊的部分拖垮;有了AI之後,反而能把專案完成。一名40歲的前端開發者說,過去他的個人專案大多停留在30%,現在卻能真正完成作品,第一次讓想法成為完整且經過打磨的產品。


但他也強調,如果沒有過去累積的前端與使用者體驗知識,最後做出來的東西仍可能只是「AI slop」——一眼就能看出是批量生成、缺乏品味與細節的產物。真正能區分廉價生成內容與成熟作品的,恰恰是人過去累積的經驗、判斷與品味。


這一派的核心觀點是:AI沒有讓創造失去意義,只是讓實作變得更便宜。


當然,也有人認為AI生成內容並沒有想像中強大。AI製作的傳單可能直接被忽略,AI撰寫的文字讀幾行就能察覺,套版生成的介面也未必有人想用。類似的技術浪潮過去已出現多次,最終往往會在熱潮後回歸現實。


兩派真正的分歧,或許不在AI本身,而在於人們原本從程式設計中獲得什麼。


一部分人依賴的是稀缺性所帶來的回報,包括職業優勢、高薪、履歷、GitHub星數、他人認可,以及掌握別人不會的技能。當AI降低技能門檻,這些外在回報自然會被削弱。


另一部分人追求的則是創造本身的快樂。他們的動機是:「我就是想讓這個東西存在。」對這些人而言,AI不是威脅,而是放大創造力的槓桿。


真正成熟的產品仍需處理大量邊界情況、效能、記憶體與使用者體驗,也要讓使用者少走彎路。能把這些細節做好的人,從來都不多。甚至有人表示,即使自己設計的新程式語言最終沒有任何使用者,他仍然會寫,因為那是他想親手創造的東西。


整場討論指向一條價值鏈的遷移:過去,程式設計師的核心價值是會寫程式碼,而且比別人寫得更好;在AI代理時代,單純實作逐漸變得便宜,而理解問題、建立心智模型、做出判斷、掌握細節,以及賦予作品方向與品味,正變得更加重要。

2026年9月4日 星期五

[AI 衝擊] DHH從拒絕AI到全面採用Agent開發

[AI 衝擊] DHH從拒絕AI到全面採用Agent開發

摘要:DHH以Omarchy實證AI Agent如何重塑程式開發、開源協作與工程師角色。



內容:


13個月前,Ruby on Rails創始人、37Signals技術長大衛・海涅邁爾・漢森(David Heinemeier Hansson,DHH),還在播客上公開表示對AI寫程式碼不太感興趣。13個月後,他坐在同一個位置,告訴主持人自己已經連續兩個月沒有親手寫過任何一行程式碼。


2026年8月,DHH第二次做客Lex Fridman的播客,進行了一場超過5小時的長談。他帶著一台預裝自研Omarchy作業系統的戴爾筆記型電腦,現場展示不到一分鐘便能從開機完成安裝並進入桌面的過程。


節目錄製後,他還宣布成立OmaCom基金會。Shopify、Stripe、Dell、Block等科技業領袖共同出資,總額達1,000萬美元,目標是推動Linux桌面真正普及。


九個月內,發生數十年的進步


DHH引用列寧的一句話作為開場:「有些十年什麼都沒發生,有些幾週卻發生了數十年的事情。」在他看來,過去九個月,AI領域就經歷了數十年的進步。


最初,AI對他而言只是查詢資料與補全程式碼的工具,並沒有從根本上改變工作方式。真正的轉折點是2025年11月24日,Anthropic發布Opus 4.5。


DHH安排了幾項任務後發現,AI輸出的品質已經不可思議地接近自己的水準。他認為變化分成兩層:第一層是模型變得更聰明;第二層,也是更關鍵的變化,是AI取得了使用工具的能力,能操作電腦、執行任務並檢查自己的成果。


他甚至表示,即使Opus 4.5是最後一個模型,自己也已經心滿意足,足夠再使用20年。


然而,進步並未停止。2026年初春,Subagent出現,一項任務可以拆成八個子任務同步執行,速度提升5至10倍。到了夏天,Opus 5、Fable、GPT-So等模型陸續出現,使用者只需要描述問題,Agent便能自行規劃解決路線。


DHH將這項轉變總結為:以前是告訴Agent該往哪裡走,現在只需要告訴Agent自己遇到了什麼問題。


Omarchy:沒有手寫發布程式碼的系統


DHH用來證明這種轉變的核心案例,就是基於Arch Linux打造的桌面發行版Omarchy。


Omarchy Bootstrap版本的開發週期為三個月。在此期間,DHH沒有親手撰寫任何一行正式發布的程式碼,所有程式碼均由Agent生成,他主要負責審查整體品質與方向。


例如,他想要一款極簡的Markdown編輯器,便要求Agent使用C++和Qt開發。20分鐘後,AI完成第一個版本;兩天內,他就拋棄原本使用的Taper。此後,他的文章都改用這款名為Oma Write的編輯器撰寫,但他從未閱讀過其中任何一行C++原始碼。


另一個案例是,某個Python函式庫的資源占用過高。DHH要求Fable製作Rust版本,45分鐘後便完成,啟動時間從86毫秒降至2毫秒,執行檔大小僅約3MB。


整個過程中,他沒有查看任何一行Rust程式碼,而是直接讓Agent建立儲存庫、發布套件、提交程式碼與合併請求。


DHH也藉此進行模型橫向測試。Fable最快,約45分鐘完成,但成本約550美元;GPT-So約需1.5小時,成本約46美元;Grok 4.6約55美元;DeepSeek V3 Pro約23美元;Kimi K3也成功完成任務。


GPT Luna則未能完成,甚至試圖抄襲既有實作;DeepSeek V3 Flash也無法自主循環完成工作。雖然Fable最快,但其他模型只花約十分之一的成本也能交付成果。經過後續兩輪最佳化,最終Rust版本的速度比原本Python版本快了46倍。


大型軟體為何還沒有明顯加速?


Lex Fridman觀察到,大型軟體似乎尚未因AI而顯著加速迭代。DHH從三個層面回應這個問題。


第一是「人」。大型組織的主要阻力往往不是實作,而是人員怠慢、溝通與協調。若要取得10倍、100倍甚至1,000倍的生產力提升,就必須直接與Agent互動,不能在中間再加入另一個人,因為人類的溝通速度太慢。


第二是「想法」。多數組織真正缺乏的是願景與品味,而不是編碼能力。微軟擁有近乎無限的程式設計資源,卻不代表一定能產出令人心動的軟體。


第三是「時間」。這種程度的AI能力才出現約半年,人類歷史上幾乎沒有任何技術進展得比AI更快,因此現在就嫌它改變得太慢,並不合理。


Vibe Coding仍可能破壞架構


DHH也坦承,37Signals曾讓設計師直接使用Agent撰寫程式碼。單獨檢視每個PR時似乎都沒有問題,但合併後卻破壞了整體系統架構,最後不得不由工程師手動清理。


因此,他認為在既有的大型程式碼庫中進行Vibe Coding,若要維持架構完整性,目前仍然需要程式設計師參與。


不過他也反問:「如果有人批評Vibe Coding產出的都是垃圾,那麼你看過普通程式設計師的產出嗎?其實很多也同樣是垃圾。」


AI正在引發開源世界的宗教改革


DHH將AI對開源社群的衝擊,比喻為馬丁・路德發起的宗教改革。


過去,開源軟體宣稱所有人都能貢獻程式碼,但實際上只有少數具備高技術能力、宛如「祭司階層」的人能真正參與。現在,AI Agent正在拆除這道門檻。


在Omarchy約三個月的開發期間,DHH合併了超過1,000個PR,其中許多來自非傳統程式設計師。


對於維護者抱怨AI產生大量低品質PR,他並不認同。經營開源專案25年來,他看過成千上萬名程式設計師的成果,發現多數人提交的PR原本就不理想:不寫測試、不提供關鍵資訊,也不檢查自己的工作。相較之下,Agent反而更常完成這些基本要求。


他甚至表示,自己現在更願意收到Agent撰寫的PR,不僅品質可能更好,拒絕時也沒有太大的心理負擔。


如今,他不再親自審查每一個PR。Agent會先進行審查、淘汰品質不佳的內容,再把真正值得由人類判斷的「珍珠」呈現出來。在他看來,開源工作中的大量苦差事正以驚人的速度消失,留下最精華的創造與決策部分。


好想法不一定只來自人類


當Lex追問「真正的好想法是否最終仍然來自人類」時,DHH表示自己過去也這麼認為,但現在已不再確定。


他已經看過模型提出好到令自己自愧不如的想法。那些仍堅持Agent只是「鸚鵡」的人,很可能忽略了過去六至九個月的巨大進展。


至於這種工作方式究竟該叫什麼,DHH非常討厭「Agent Engineering」這個詞,認為它已經成為行銷用語。他對「Vibe Coding」也有所保留,覺得它聽起來像2000年代初期下載現成PHP腳本直接使用的「腳本小子」。


在他的定義中,如果完全不查看實作,確實可稱為Vibe Coding;若仍會審查實作、架構與品質,那就是另一種工作模式。


程式設計知識有時反而成為限制


Lex認為,擁有程式設計經驗的人應該更擅長使用Agent。DHH只同意一半。


他認為,在某個階段,知道太多程式設計知識反而可能成為劣勢,因為程式設計師會要求Agent按照自己的既定方法工作。當模型已經進步到只需描述問題、不必規定解決路徑時,Agent反而可能提出比程式設計師預想更好的方案。


他也提到CLAUDE.md等指令檔案。過去,人們會撰寫很長的指令來微調Agent,但Claude Code團隊後來將Opus 5的系統提示詞縮減約80%,因為過度規定反而可能損害表現。


這就像不懂程式設計的主管不斷指手畫腳,最終只會讓程式碼變得更差。DHH認為,好的軟體是在實際使用過程中逐步被發現的,而不是在規格書中一次設計完成。


從單執行緒轉向多機、多Agent並行


DHH自己的工作環境,也已經從單執行緒轉變為多台機器、多個Agent同步執行。


他最初使用Tmux,後來轉向名為Heather的工具,由系統通知哪個Agent已經完成任務。之後,他購買GL.iNet Comet設備,將閒置的Mini PC全部連線,並透過Tailscale建立虛擬區域網路,讓自己能隨時從手機連接馬里布與哥本哈根辦公室的電腦。


目前,他大約可以同時執行16個工作執行緒。相較一年前每小時約20行程式碼的產出,現在已能達到每小時數百行。


他的日常流程,是在Heather中執行Claude Code、Codex與OpenCode,再以Opus或Fable撰寫程式碼,並交由其他高階模型交叉審查。最近他也開始使用Grok進行審查;推送至GitHub後,再由Copilot檢查一次。


他表示,Copilot現在確實有所進步。過去標記出的問題多半沒有價值,如今已經能找到真正的缺陷。


不過,這種多執行緒、多Agent並行的工作方式也非常消耗腦力。DHH形容,完成一天工作後,就像剛從賽車裡爬出來一樣疲憊。