顯示具有 AI 標籤的文章。 顯示所有文章
顯示具有 AI 標籤的文章。 顯示所有文章

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形容,完成一天工作後,就像剛從賽車裡爬出來一樣疲憊。

2026年9月2日 星期三

[AI 發布] Anthropic推出Claude 5.1雙版本,強化科研、程式設計與安全防護

[AI 發布] Anthropic推出Claude 5.1雙版本,強化科研、程式設計與安全防護

摘要 : Claude 5.1提升程式設計、科研能力,並兼顧企業隱私與安全。



內容:


當地時間9月1日,Anthropic宣布推出兩個Claude 5.1版本,並稱其為全球最先進的程式設計與知識工作模型。兩者採用相同的基礎模型,主要差異在於安全防護等級:一般版本面向所有使用者,較寬鬆版本則僅透過可信訪問計畫,提供給經審核的網路安全及生命科學機構。


根據Anthropic公布的基準測試,Claude 5.1在多項測試中超越前代模型、Opus 5及OpenAI GPT-6。在智慧體科學研究基準TerminalBench Science 0.1中,5.1獲得52.6%,高於前代的24.7%、Opus 5的29%及GPT-6的22.4%。


在智慧體程式設計基準TerminalBench 4.0中,一般版5.1得分55.8%,採用較寬鬆安全防護的版本則達60.9%。知識工作方面,5.1在GDPVal AAV2測試取得1853分,也高於原文所列前代模型的1824分與1723分。


價格方面,5.1的快取讀取費用下調75%,降至每百萬token 0.25美元。典型工作負載的成本約比前代低25%,高度智慧體化工作負載最高可降低40%。基礎定價維持每百萬token輸入10美元、輸出50美元。


企業隱私方面,Anthropic推出Enterprise Frontier Safeguards(EFS),結合零資料保留與先進安全防護。客戶資料將儲存在由企業完全控制的雲端基礎設施,而非Anthropic系統。EFS預計於今年秋季分階段向企業客戶推出;在正式上線前,符合資格的客戶可依零資料保留政策使用5.1。


安全防護方面,Anthropic調整了5.1的防護機制,以降低誤判。網路安全領域的誤攔截數量較過去減少約60%。模型可協助發現軟體漏洞,但不會用來開發針對這些漏洞的利用程式。


生物學領域方面,Anthropic與美國政府合作建立訪問計畫,讓研究人員在受控條件下運用5.1的進階生物學能力,並計畫近期開放科學家註冊。


在分子設計領域,5.1利用開源蛋白質設計與折疊工具,設計出高親和力結合劑。在三個靶點上,其結合親和力比Adaptive Bio蛋白質設計競賽的最佳作品高出10倍;在12個靶點上的命中率接近50%,高於目前蛋白質設計常見的10%至15%。


在計算分析領域,5.1運用NASA麥哲倫任務30多年前取得的雷達影像訓練神經網路,繪製出涵蓋金星約三分之一區域的高解析度高程地圖。解析度由過去的10至20公里提升至2至3公里,高程精度提高25%。


在計算生物學方面,5.1透過編寫自訂GPU核心及快取中間結果,使七個開源深度學習模型的執行速度提升2.5倍,預計可降低30%至60%的GPU成本。


合規方面,Anthropic於2026年7月簽署歐盟《人工智慧法案》有關AI生成內容透明度的實踐準則。依規定,2026年8月2日後發布的模型輸出須加入不可見水印。5.1生成的文字已內建此類水印,不影響內容與輸出品質,也不包含使用者或對話資訊。


Anthropic亦以私人預覽方式推出水印檢測API。符合資格的監管機構、執法部門、媒體及事實查核組織,可依歐盟法律要求申請使用。


Claude 5.1已登上Anthropic各平台,以及Amazon Web Services、Google Cloud與Microsoft Azure,開發者也可透過Claude API使用。較寬鬆安全防護的版本目前僅提供給經審核的美國組織。


此次更新進一步加劇Anthropic與OpenAI之間的競爭。原文並推測,OpenAI執行長Sam Altman可能很快推出代號「Astra」的產品作為回應。


註:原始資料將兩款模型都寫作「Claude 5.1」,且部分前代型號重複或不明,因此本文依其安全防護與開放條件區分為一般版及受限版。

2026年9月1日 星期二

[AI 衝擊] 工具進化,正在淘汰 AI 教學與入門工作

[AI 衝擊] 工具進化,正在淘汰 AI 教學與入門工作

摘要 : AI 功能快速內建,讓工具教學貶值,也壓縮入門職缺與內容創作者的生存空間。



內容:

近期大批 AI 博主停更,表面原因是競爭激烈、廣告與平台補貼減少,更深層的問題卻是教學內容迅速失效。過去需要安裝環境、串接模型或研究提示詞的操作,如今陸續被官方整合成一鍵功能,教程可能還沒剪完就已經過時。


AI 影音生成成本也從每秒數元降至幾毛甚至幾分錢。價格降低雖讓更多人可以創作,卻也抹平了技術門檻,使「熟練操作工具」不再稀缺。像是教人繞過模型無法辨識圖片的限制,功能一旦被官方內建,整套教學便失去價值。


與攝影的構圖、光影及審美不同,許多 AI 教學傳授的是短期操作步驟。工具愈簡單,這類知識的保值期就愈短。AI 也能大量產出文章、分析資料與整理專業知識,因此單靠資訊量、模板或操作熟練度,愈來愈難建立長期優勢。


真正仍具價值的,是有趣的表達、持續的創意,以及從日常事物中發現異常的能力。模板化的 AI 影片或流行聲音可能迅速爆紅,卻也容易被遺忘;能留下來的,通常不是最會套模板的人,而是持續提出新想法的人。


另一項隱憂是入門職位消失。漫畫新人過去能從描線、上色等助手工作開始學習,程式設計師也能透過初階任務累積經驗;當這些工作被 AI 接手,職涯向上的第一級階梯也可能隨之消失。


學習 AI 並非沒有意義,它仍能協助撰寫週報、製作簡報並節省時間,但不該把單一工具當成長久飯碗。面對快速迭代,與其囤積即將過期的教程,不如累積觀察、敘事、審美與創意——工具會變,自己的想法才是真正能保留的能力。

2026年8月31日 星期一

[AI 衝擊] AI 正在重塑軟體產業的商業地基

[AI 衝擊] AI 正在重塑軟體產業的商業地基

摘要 : AI 大幅降低軟體生產成本,外包、SaaS 與程式設計師都將面臨轉型。



內容:


寫程式碼正在從一項稀缺技能,逐漸變成基礎配置。真正發生的改變,不只是程式設計師是否會失業,而是 AI 編程智慧體正在動搖整個軟體產業的商業基礎。


過去二十年,軟體公司的核心資產是能夠寫程式碼的人。企業透過招募工程師、組建團隊、承接專案並交付程式碼獲利;外包公司依靠人力成本差價生存,SaaS 公司則利用訂閱收入分攤研發成本。這套模式建立在「程式碼與程式設計人才稀缺」的前提上。


如今,Cursor、GitHub Copilot、Replit Agent 等工具,已不只是協助撰寫程式碼,還能生成完整功能模組、修復錯誤及重構架構。即使創業者不懂技術,只要能清楚描述需求,也可能在幾個小時內,以少量訂閱成本完成可運行的產品原型。


過去製作一個網站或小型程式,可能需要委託外包公司,花費數萬元並等待數月;現在則可能透過 AI 工具,在一週內以不到千元的成本完成。這代表軟體的生產成本正在快速下降。


最先受到影響的是外包公司。外包的本質,是將寫程式碼這類勞動密集型工作打包出售。然而,當需求方能使用 AI 以更低成本自行完成開發,原有的報價體系便可能瓦解,訂單減少與利潤縮水也將成為長期趨勢。


SaaS 公司同樣面臨挑戰。傳統 SaaS 透過投入大量成本研發標準化軟體,再銷售給大量客戶以攤薄成本。但在低成本 AI 開發工具普及後,客戶可能選擇自行打造更符合需求的產品,使 SaaS 原有的標準化與規模效應受到定製化軟體衝擊。


軟體公司的組織結構也會隨之改變。過去一個產品團隊需要前端、後端、測試、產品與運維等十多人分工合作;未來,一名理解業務的產品經理,加上少數善用 AI 工具的「配置工程師」,就可能承擔小型團隊的工作。


這不只是程式設計師失業的問題,而是軟體產業生產方式的轉變。如同汽車流水線取代部分手工打鐵工作,同時創造新的汽車工種,AI 也會催生新的軟體職位。不同的是,未來需要的 AI 配置工程師,數量可能少於傳統程式設計師。


對創業者與小公司而言,現在可能是難得的機會。過去有想法卻沒有技術團隊,只能依靠外包、投入資金並承受高昂試錯成本;現在則能利用 AI 快速、低成本地驗證構想,等商業模式跑通後再擴充團隊。


對程式設計師而言,不應只專注於寫程式碼。當編碼成為基礎能力,更重要的是理解業務與需求,並能將 AI 生成的程式碼整合成真正可用的產品;另一條路則是深入底層架構、效能最佳化及安全攻防等 AI 難以完全取代的領域。處於中間層、只負責一般業務程式碼的人,可能面臨最高風險。


對軟體公司、外包公司與 SaaS 公司而言,也必須重新檢視商業模式。如果企業的核心競爭力只是一批能寫程式碼的人,原有壁壘將逐漸消失。


軟體產業正從手工業時代走向流水線時代。過去,會寫程式碼的人最有價值;未來,能運用 AI 生產軟體、理解需求並完成整合的人,將更具競爭力。當產業地基開始移動,身處其中的每個人都必須重新找到自己的位置。

AID06-Knowledge Graph 怎麼讓 AI 把知識連起來-5分鐘學AI

知識圖譜是把人、案子、合約變成點,把關係變成線。 跨好幾份文件的問題,要沿著線走才答得出來。


#一起搞懂AI #AI名詞 #AI入門 #白話AI #企業AI Knowledge Graph 怎麼讓 AI 把知識連起來。 阿哲,我們公司的資料都放進去了,問一段話它也真的找得到。可是我一問這個客戶的案子當初是誰接的,它就開始亂講。因為那個答案不在任何一段裡面。一份文件寫誰負責,一份寫案子叫什麼,後來為什麼砍價又寫在第三份。咦,那它一段一段找,不就永遠拼不起來?對,這就是這一集要解決的事。差別在知識的擺法。文件是一疊一疊放的;換成一張誰跟誰有關係的圖,它就走得過去了。 那第一個名詞就是知識圖譜嗎?圖譜這兩個字,聽起來好學術。名字唬人,東西很單純。它把人、案子、公司、合約,各自當成一個點;再把誰負責哪一案這種關係,畫成一條線。 所以它不是把文件收好,是把關係記下來?對。文件還在,只是多了一層東西記著誰跟誰有關。張經理連到那個案子,案子連到那家公司,公司再連到三份合約。喔,就像家裡那本族譜?上面不寫每個人的生平,只寫誰是誰的爸爸、誰又嫁給了誰。就是這個感覺。族譜的價值不在字多,在於你可以從一個人一路指到另一個人。要提醒一件事,這不是一個更聰明的搜尋,它換掉的是知識的擺法。那這些點跟線,是從哪裡冒出來的?從你本來就有的資料裡整理出來的。一張報價單上有業務的名字,也有案號,這兩格本來就是一條線,只是以前沒有人把它牽起來。 那 Graph RAG 呢?後面那個 RAG 我知道,是回答之前先去查一遍。差別在它怎麼查。一般的做法是各撈各的段落,撈回一堆用字很像、但不見得有關的東西;它是先找到那個點,再沿著線走過去。 那實際問一個問題的時候,差在哪裡?你問這個客戶的案子當初是誰接的。一般做法是拿這句話去比對段落,撈回一堆提到這個客戶的文字。它是先找到這個客戶,再沿著線走到案子、走到那個人。喔,就像提一串粽子?抓住繩頭一提,底下一整串都跟著上來,不用一顆一顆挑。這個比喻很好。差別在帶回來的東西彼此真的有關係,不是剛好用字很像。不過要注意,它走得到的路,只有事先連起來的那些。那沒連起來的那些呢?一樣看不到。這個客戶跟另一個客戶其實是同一個老闆,你沒把那條線牽上去,它就永遠繞不過去,而且它不會告訴你有一條路是斷的。 那 Graph Engineering 呢?工程這兩個字一出現,我就開始緊張。它講的是那些線是誰決定的。哪些東西算一個點、兩個點之間那條線叫什麼名字,都要有人先定義好,圖才長得出來。 所以圖不是自己長出來的?我還以為資料丟進去,它就會自己連。不會。誰算一個點、兩個點之間那條線叫什麼,都要有人先講清楚。負責跟參與是不是同一回事,機器不會幫你決定。喔,就像我幫家裡每一把鑰匙貼標籤?哪一把開哪一道門,是我自己寫上去的。很貼切。而且標籤寫錯的時候最麻煩,你照著標籤一路開下去,會很有條理地開錯一整排。關係定義錯了也一樣,它會很有把握地走到錯的地方。那這件事是一次做完就好了嗎?不是,它要一直養。公司多了一種合約、多了一種角色,就要多一種線。這也是為什麼它叫工程,不叫設定。 最後這個我很常看到。它回答完,旁邊會標一個百分比,說它有幾成把握。那個叫信心分數。它是自己估出來的一個數字,講的是它對這次回答有多確定,不是有人真的去核對過答案。 所以它標九十分,就是九成會對?不是。它算的是自己有多確定,不是這件事有多真。資料裡根本沒寫的東西,它照樣可以給你一個很高的分數。喔,就像考完試自己估分數?我覺得我這題穩了,跟老師改出來是幾分,是兩回事。這個比喻剛剛好。你估的是你當下的感覺,老師改的才是對不對。中間少掉的那一步,就是有人真的去對過答案。那這個分數到底要拿來幹嘛?拿來排先後。分數低的那幾筆先撈出來給人看一眼,這是它最好用的地方。但是分數高的那些,不代表你就可以不看。那它連自己有多確定都會估錯,這個分數還有什麼用?它的用處全在低分那一端。分數低,代表它自己也覺得心虛,那幾筆先撈出來給人看最划算。分數高的那些,只是它不心虛,不是它查過。 那我把這一集重新排一次好不好?好,你來。知識圖譜是把人、案子、公司變成點,把誰跟誰有關變成線。圖譜式檢索是先找到那個點,再沿著線把相關的帶回來,不是各撈各的段落。圖譜工程是那些線都要人先定義,圖不會自己長。信心分數是它自己給自己打的把握,不是有人去查證過。完全正確。以後遇到它答不出一個要串好幾份文件的問題,你先問一句:這兩件事之間,有人幫它牽過線嗎? 企業級智庫引擎。讓公司的知識,答得出來、查得到、帶不走。

Salesforce 豪擲 3 億美元買 AI Token,讓我看到企業用人邏輯正在改變

Salesforce 豪擲 3 億美元買 AI Token,讓我看到企業用人邏輯正在改變



最近看到一則消息,Salesforce 預計投入接近 3 億美元購買 Anthropic 的 AI Token,同時延續軟體工程師的招募凍結政策。

乍看之下,這似乎只是一則大型科技公司增加 AI 預算的新聞,但仔細思考後,我認為它反映的其實是一個更重要的變化:企業正在重新定義「產能」是什麼。

過去公司想加快產品開發,最直接的做法通常是增加工程師、擴大團隊,讓更多人投入開發工作。但現在,企業開始思考的可能不再是「還要再聘多少人」,而是「現有團隊搭配 AI 之後,還能增加多少產出」。

這兩種思考方式看起來相似,背後的資源配置邏輯卻完全不同。

AI 預算正在逐漸取代部分人力預算

Salesforce 表示,工程團隊導入 AI 工具後,生產力提升超過 30%。因此,公司選擇維持現有約 1.5 萬名工程師的規模,透過 Claude、Codex、Cursor 等工具提升產能,而不是繼續增加工程師人數。

這讓我感受到,企業在做預算規畫時,AI Token、模型費用與 Agent 執行能力,已經逐漸成為一種新的生產資源。

以前企業的產能主要來自人,現在則變成「人加上 AI」。

公司不一定會直接解僱現有員工,但當 AI 能讓原本的團隊完成更多工作時,企業自然就沒有那麼強烈的理由繼續擴大招募。

因此,AI 對就業市場的影響,可能不一定會以大規模裁員的方式發生。另一種更安靜、也更容易被忽略的形式,就是職缺減少、招募凍結,以及新人進入產業的機會逐漸變少。

工程師沒有立刻消失,但工作內容一定會改變

我並不認為 AI 短期內會完全取代軟體工程師。

軟體開發不只是產生程式碼,還包含需求釐清、架構設計、系統整合、資安、測試、維運,以及對最終結果負責。這些事情目前仍然需要有經驗的人來判斷。

但可以確定的是,工程師的工作內容正在發生改變。

未來工程師可能不再花大部分時間逐行撰寫程式,而是將需求拆解成任務,交由不同 AI Agent 執行,再負責檢查程式碼、驗證結果、處理例外,以及確認整體系統是否符合需求。

過去企業重視的是「誰寫程式寫得快」,未來可能更重視「誰能正確定義問題、指揮 AI、審查結果,並對系統品質負責」。

換句話說,工程師不只是開發者,也會逐漸成為 AI 開發流程的管理者與品質把關者。

真正令人擔心的,可能是初階職位的減少

這則消息讓我最在意的,其實不是資深工程師會不會被 AI 取代,而是初階工程師未來還有多少機會可以進入產業。

一位資深工程師搭配 AI,可能可以完成過去需要數位初階工程師共同完成的工作。站在企業角度來看,這確實能降低成本並提高效率;但站在人才培養的角度來看,卻可能產生新的問題。

因為每一位資深工程師,都是從初階工程師一路累積經驗而來。

如果企業為了效率而大量減少初階職缺,未來可能會出現人才斷層。公司短期內可以依靠現有的資深人員與 AI 提高產能,但幾年之後,市場上是否還有足夠的人才可以接替資深工程師,將成為另一個問題。

因此,企業不能只把 AI 當成減少人力的工具,也必須重新思考在 AI 時代中,該如何培養新人、傳承經驗,以及設計新的職涯成長路徑。

AI 不只改變技術,也正在改變組織結構

另一個值得注意的地方是,Salesforce 並不是全面停止招募。

公司一方面凍結工程師招募,另一方面卻計畫增加業務人員,協助客戶導入 AI 產品。這代表企業不是單純縮減人力,而是在重新調整不同職位的重要性。

未來有些工作會因為 AI 而減少,有些工作則會因為 AI 而增加。

例如,單純執行、整理、撰寫與重複操作的職位,可能面臨較大的壓力;但負責客戶溝通、流程設計、AI 導入、結果驗證、治理與風險管理的人才,反而可能變得更加重要。

所以,AI 帶來的並不只是「人會不會被取代」的問題,而是整個企業組織會如何重新分工。

中小企業也應該開始思考同樣的問題

雖然 Salesforce 是大型科技公司,但我認為這種改變並不只會發生在大型企業。

中小企業的資源有限,反而更有動機利用 AI 提升效率。當企業需要增加客服、行銷、文件整理、研究、行政或程式開發能力時,未來不一定會先想到增加人力,而可能先評估能否使用 AI 工具完成。

這不代表企業應該立刻用 AI 取代員工,而是應該重新設計工作流程。

哪些工作適合交給 AI?

哪些工作仍然必須由人判斷?

哪些結果需要經過人工審查?

如果 AI 發生錯誤,最後應該由誰負責?

我認為,這些問題會比單純購買哪一個模型或工具更重要。

最大的風險,不是沒有使用 AI,而是不知道如何管理 AI

看到 Salesforce 投入 3 億美元購買 AI Token,很容易讓人產生一種感覺:只要投入更多 AI 預算,企業就能自然獲得更高的效率。

但我認為事情沒有這麼簡單。

AI 可以快速產生程式碼、文件與分析結果,但如果企業缺乏清楚的需求、流程、資料治理與品質審查,AI 也可能快速製造更多錯誤與技術債。

尤其在軟體開發領域,程式碼寫得更快,不代表專案就能更快完成。大量由 AI 產生的程式碼,仍然需要被審查、測試、整合與維護。

如果企業只追求產出速度,卻沒有同步強化審查與治理能力,最後可能只是把開發瓶頸從「寫程式」移到「驗證與維護」。

因此,企業真正需要建立的,不只是 AI 使用能力,而是 AI 管理能力。

我的感想

Salesforce 的案例讓我更加確定,AI 已經不再只是員工手中的輔助工具,而是企業正式計算產能與配置預算的一部分。

未來企業在規畫資源時,可能會同時衡量人力成本、模型費用、Token 用量、Agent 數量與自動化程度。

對個人而言,也不能只停留在「會不會使用 AI 工具」的階段,而是要進一步學習如何將工作拆解、如何驗證 AI 的結果、如何建立完整流程,以及如何對最後的成果負責。

我認為,AI 時代真正有競爭力的人,不一定是最會操作某一套工具的人,而是能夠理解業務、定義問題、設計流程,並讓人與 AI 有效合作的人。

同樣地,真正有競爭力的企業,也不一定是購買最多 AI Token 的公司,而是最早建立正確人機分工、治理制度與人才培養模式的公司。

Salesforce 的 3 億美元 AI 投資,表面上是一筆技術採購,實際上更像是一個訊號:企業成長與擴大產能,未來不一定會同步帶來更多職缺。

AI 不只是讓工作做得更快,也正在重新決定哪些工作需要人、需要多少人,以及人的價值應該放在哪裡。

[AI 警示] 比爾・蓋茨:AI轉型恐引發失業與社會動盪

[AI 警示] 比爾・蓋茨:

摘要 : AI將超越人類認知,但社會尚未建立足夠的應對制度。


內容:

比爾・蓋茨近期撰文警告,即使在最樂觀的情況下,AI時代的過渡仍可能成為人類史上最動盪的時期之一。然而,各國領導人、專家與社群尚未提出完整計畫,以因應失業、教育、稅制及社會保障等挑戰。


過去他多半強調AI對醫療、教育與農業的正面影響,也反對單方面暫停研發。但在親自使用Claude Code後,他認為AI的程式設計能力已實質超越自己,並意識到AI正首次具備取代、甚至超越人類認知工作的能力。


他最擔心工作永久消失,而且替代速度可能快於新職位的產生。客服、程式設計、法律文書等工作首當其衝,未來建築與旅宿業也可能大量導入機器人。尤其入門職位一旦被AI取代,年輕人將失去累積經驗、技能與人脈的職涯階梯;企業即使沒有惡意,也會因競爭壓力持續自動化。


AI也可能削弱教育及人格成長。若學生把思考、查找資料與完成作業全交給機器,學習過程便可能被掏空;若人們過度依賴永遠迎合、即時回應的AI伴侶,也會減少從衝突、拒絕、道歉與等待中培養同理心及心理韌性的機會。


比爾・蓋茨提出四項對策:依AI使用量課徵Token稅,補助失業保障與再培訓;向替代人力的機器或機器人徵稅,補充因工資稅萎縮而不足的社會安全網;保留護理等高度依賴人際接觸的工作;建立國家及國際層級的AI治理與協調機構。不過,Token稅可能促使運算轉向本地,機器人稅也面臨定義與執行難題。


儘管各界對危機發生的時間、路徑與嚴重程度看法不同,共識仍是AI轉型確實正在發生,而人類準備不足。一般人可降低負債與大型消費、增加現金儲備,評估自身工作被取代的程度,善用AI提升競爭力並培養副業或多元收入,以提高面對失業潮與社會動盪的韌性。

[AI 趨勢] AI顛覆為何比預期更慢

[AI 趨勢] AI顛覆為何比預期更慢

摘要 : AI能力快速進步,但企業慣性、責任風險與導入成本延緩全面取代。


內容:

AI雖已普及,北美卻尚未出現全行業的大規模裁員。OpenAI執行長奧特曼坦言,自己高估了AI落地速度:GPT-4發布時,他曾以為軟體業會迅速洗牌,但經濟與社會慣性遠比預期強,人們仍習慣向原供應商採購,沿用既有工具與工作方式。


企業導入AI並非只看技術能力,還要遷移資料、整合系統、設定權限、培訓員工、調整預算,並通過法務與合規。更關鍵的是,AI即使有99.9%的可靠度,剩下0.1%的錯誤若出現在合約、報稅、醫療或大型系統中,仍可能釀成重大事故;責任歸屬未明前,人工審核便無法取消,也因此成為效率瓶頸。


奧特曼以百視達為例:Netflix早期郵寄DVD明明更方便,消費者仍因習慣持續前往門市。慣性讓百視達多維持了數年,卻未能阻止流媒體最終取代實體租片。這說明更好的技術往往需要多年才能普及,但一旦習慣與基礎設施被突破,變化也可能在短期內急遽加速。


對一般工作者而言,AI變革仍會發生,只是更可能以年、而非月為單位展開。裁員未必一次爆發,而可能呈現持續縮編的「溫水煮青蛙」模式。嵌入複雜系統、仰賴客戶關係,或受到高度監管與責任約束的職位,受慣性保護較深,轉型速度也會較慢,但不代表永遠不受影響。


落地放緩也可能擴大AI投資與實際回報之間的時間差。科技公司依照高速成長預期投入巨額資本,若收入遲遲無法跟上,市場信心可能轉弱,甚至引發企業財務與產業連鎖風險。不過,這仍取決於時間差有多大,以及企業能否承受長期投入。


判斷自身行業是否接近加速轉型,可觀察三項訊號:AI是否進入公司正式流程並建立規範與審核機制;職缺是否開始要求AI能力或負責建置AI流程;AI支出是否由試點預算轉為固定營運成本。若三項中已有兩項出現,代表組織、制度與預算逐漸到位,產業變化可能隨時加速。

2026年8月29日 星期六

[AI 正能量] 面對AI焦慮,持續改變就有機會

[AI 正能量] 面對AI焦慮,持續改變就有機會

摘要 : AI重塑工作卻不會消滅需求;放下追趕恐慌,持續學習與調整,人人都能重新入局。



內容:

面對AI工具與資訊快速更新,許多人擔心自己跟不上,甚至認為職業終將被取代。這種焦慮並非個人問題,就連身處科技前沿的人也會感到變化太快、難以掌握,因此不必過度責怪自己。


AI可能改變或取代某些職業任務,卻不等於相關需求會消失。婚禮攝影師即使能用AI快速修圖,新人仍可能需要專業人士處理影像與流程;老闆即使懂得寫程式或收發快遞,也不代表會親自完成所有工作。過去秘書從打字轉向行程規劃與商務協調,也是相同的職能轉型。


真正容易被淘汰的,是效率提高後仍維持舊有工作方式與價值的人。如果AI把三天的修圖縮短為幾分鐘,服務者便可利用其餘時間增加影片、活動企劃、文案、造型建議與婚禮陪伴,讓客戶得到更多價值。AI取代的是低效率流程,而非所有人的服務需求。


AI時代像一波又一波的浪潮,每次技術更迭都提供重新上岸的機會。這不像需要長期累積才能追上老手的遊戲,而更像每個賽季都會重置的競賽;這一次沒有跟上,不代表下一次必然落後。企業也未必搶先就能建立永久優勢,等待成熟時機再布局,同樣可能後來居上。


焦慮可以成為學習動力,但若恐懼使行動變形、無法專注學習,傷害人的便不只是AI,而是失控的焦慮。工業革命時,部分工人因害怕機器而陷入絕望;今天更重要的選擇,是接受變化、學習工具,並依照新的商業需求調整自己。


這場洗牌不只讓打工人焦慮,企業主與投資人承受的壓力可能更大。講者以學生獲得高薪AI職位為例,指出企業願意投入大量時間與成本爭取人才,背後正反映老闆害怕錯失浪潮。知識與技術逐漸平權,雖會帶來動盪,卻也讓資歷較淺的人有機會打破舊有門檻;只要願意開始學習,就不算被時代淘汰。

2026年8月27日 星期四

[AI 分享] 用 Herder 管理多個 Coding Agent

[AI 分享] 用 Herder 管理多個 Coding Agent


摘要 : Herder 以狀態感知、終端持久化與 CLI,降低多 Agent 開發的切換成本。


內容:


現在寫程式時,最廉價的擴充資源就是 Agent:開一個 Codex 修改頁面,再啟動另一個做 Code Review,旁邊同時掛著開發與測試服務。帳面上的吞吐量看似拉滿了,人的注意力卻先爆了顯示記憶體。


你得在不同終端之間輪流查看:誰還在執行、誰卡在授權、誰早已完成?視窗一多,名稱很快就失去辨識作用。傳統終端只能顯示字元與日誌,無法理解其中的 Agent 究竟處於什麼狀態,因此大家只能手動巡查。


每次切換可能只花幾秒,累積起來卻會消耗大量心力,真正被破壞的是思考的連續性。Herder 想消除的,正是這筆隱形的排程成本。


為 Coding Agent 重新設計的 tmux


你可以把 Herder 理解成一套為 Coding Agent 重新設計的 tmux。它保留真正的偽終端窗格與持久化工作畫面,同時能辨識窗格裡執行的 Agent。


接入之後,Codex、Claude Code 等工具仍維持原生介面,測試腳本也能照常執行。若說 tmux、Zellij 擅長管理終端與版面,圖形化平台適合處理審批流程及環境隔離,那麼 Herder 剛好位於兩者之間,替終端補上 Agent 狀態感知、CLI 控制及本地 API。


整套程式只是一個 Rust 二進位檔,不強制建立帳號,沒有雲端控制面板,也不收集惱人的遙測資料。它沒有試圖吞下整套開發流程,而是專注於管理終端與 Agent。


Herder 的五層核心模型


Herder 的核心模型可分為五個物件:


Session

管理整套執行環境。日常使用一個預設 Session 通常就足夠,需要隔離時再建立具名 Session。


Workspace

通常對應一個程式碼倉庫,用來組織不同專案。


Tab

類似瀏覽器分頁,代表專案裡的特定工作視角。可以將 Agent、開發服務及測試工作分開。


Pane

真正的偽終端,可以執行任意命令。


Agent

在 Pane 中被 Herder 辨識出的 Coding Agent 程序。


測試腳本只算 Pane;Codex 則同時是 Pane 與 Agent。Pane 負責字元流,Agent 負責生命週期。底層狀態會一路向上彙整至 Tab 與 Workspace,因此即使同時開啟許多專案,也能快速找到卡住的節點。


程序、版面與對話是三種持久化


從架構來看,Herder 採用典型的 Client-Server 模式。伺服器掌握 PTY 程序與視窗版面,客戶端則負責顯示畫面及傳遞輸入。


正常 Detach 時,關閉的只有客戶端,背景中的 Agent、測試與開發服務都會繼續執行,也能讓多個客戶端連入同一個工作畫面。


但必須注意,伺服器才是狀態的唯一來源。Herder 伺服器一旦停止,其管理的程序也會終止。再次啟動時,雖然可以恢復目錄、版面與焦點,原本的程序卻無法復活。


官方整合可以保存 Agent 原生的 Session ID,協助接回對話,但無法讓已終止的建置程序重新執行。實驗性的 Pane History 也只是保存螢幕文字的緩衝區。


因此,不能把「持續執行」理解成所有狀態都會永久保存。程序、版面與對話的持久化是三件不同的事。


真正節省時間的是狀態追蹤


Herder 側邊欄會追蹤幾種主要狀態:


Working:Agent 正在執行工作。

Blocked:Agent 卡住,正在等待授權或使用者輸入。

Done:Agent 已在背景完成,但使用者還沒切過去查看,類似未讀訊息。

Idle:Agent 目前閒置,或完成結果已被查看。

Unknown:系統無法確定狀態,不能視為成功或失敗。


這些狀態會向上聚合。即使某個 Workspace 被放在背景,只要裡面出現 Blocked 狀態,Workspace 層級也會亮起提醒。


這才是關鍵:讓人的注意力跟著事件移動,而不是每隔幾分鐘手動巡查一次。


Herder 如何偵測 Agent 狀態


Herder 會先取得 Pane 的前景程序。遇到支援的 Agent 時,還會掃描終端底部畫面,透過 Screen Manifest 比對已知的 UI 特徵。


這種方式不要求每項工具都主動提供整合介面,因此 Codex、Claude Code 與 OpenCode 等工具可以低成本接入。不過,這種做法也有代價:如果 Agent 修改了提示介面,舊規則可能立即失效;若在 Herder 裡再套一層 tmux,也可能干擾前景程序的判斷。


官方整合則能利用原生 Session ID 補強辨識。遇到誤判時,可以執行:


herder agent explain



藉此查看究竟是哪一條規則命中。面對 Unknown 狀態時,不應盲信自動化,直接切到現場確認通常最可靠。


本機與遠端開發


安裝 Herder 後,在專案根目錄執行 herder,即可啟動預設工作畫面。使用者可以用滑鼠切換窗格及調整大小;習慣鍵盤操作的人,也能使用類似 tmux 的前綴鍵,不需要重新背誦大量快捷鍵。


遠端開發可直接使用原生 SSH。程式碼與 Herder 伺服器都留在遠端,即使 SSH 中斷,背景任務仍會繼續。網路恢復並重新連線後,原本的 Pane 仍會留在原位。


Herder 也針對窄螢幕做了調整,臨時使用手機終端查看部署結果或點選確認相當方便。若需要桌面端能力,也能在本機執行 Herder 客戶端連至遠端,甚至可將本機剪貼簿中的圖片傳入遠端工作畫面。


建議的 Workspace 配置


實務上,可以讓每個活躍倉庫使用獨立 Workspace,再依職責劃分 Tab:


Agent:程式碼生成與 Code Review。

Dev:執行熱更新開發伺服器。

Checks:編譯、靜態檢查與單元測試。

Deploy:監看發布流程。


切換 Workspace 時,目錄、Pane 與 Agent 狀態會一起切換,才能做到接近無損的上下文切換。


不要把所有程序都硬塞給 Agent 管理。基礎服務、測試與日誌最好獨立執行。Agent 完成後可以關閉,但開發環境仍要保留以便除錯;程式碼出錯時,到 Checks 查看錯誤,再到 Dev 重新整理頁面,各項工作互不干擾。


穩定的基礎目錄與版面配置,通常比背下大量快捷鍵更有價值。


雙 Agent 的高效陣型


一種典型配置是在同一個工作環境裡放兩個 Agent:


Builder:負責修改程式碼。

Reviewer:使用唯讀模式檢查 Diff。

旁邊另外執行開發伺服器與測試輸出。


Builder 完成修改後,Reviewer 直接接手檢查差異。如果 Reviewer 進入 Blocked,通常代表工作已到達需要人類判斷的系統邊界,此時再由人介入。


審查任務必須嚴格限制檔案範圍、測試腳本及寫入權限,否則一旦出問題,很難釐清責任。


Herder 不負責檔案隔離


必須注意,Workspace 只負責邏輯組織,不提供檔案隔離。兩個 Pane 如果指向同一目錄,仍然可能同時讀寫並產生衝突。


遇到大型需求時,應使用不同 Git 分支或 git worktree。Agent 之間的交接也應透過 Commit 或 Patch 完成。


Herder 提供的是執行容器與工作視角,Git 管理的是變更記錄,而最終驗收仍然必須由人負責。


CLI 才是真正的控制介面


不要只注意圖形介面,CLI 才是 Herder 控制面的真正入口:


layout:一次建立 Workspace、Tab 與 Pane。

pane:管理測試、服務與一般終端程序。

agent:啟動 Agent、傳遞 Prompt 並等待生命週期狀態。


透過腳本建立物件時,CLI 會回傳 JSON。應保存並使用其中穩定的 ID 操作,不要猜測新 Pane 的編號,也不要對目前焦點盲目發送命令。


利用這套能力,可以建立外部協調器:動態啟動 Reviewer、分派受限任務,再等待 Idle、Done 或 Blocked 等語義狀態。普通腳本若沒有 Agent 狀態,也能使用 Pane 的輸出等待功能捕捉關鍵字。


只要能等待語義狀態,就不要在腳本裡寫死 sleep 30。依靠固定時間猜測工作是否完成的流程非常脆弱,只要執行速度稍有變化,整條自動化管線就可能失效。

[AI 轉折] AI人才逆向流動:從技術競賽走向產業兌現

[AI 轉折] AI人才逆向流動:從技術競賽走向產業兌現

摘要 : AI核心人才轉向產品與傳統產業,反映競爭焦點已從技術上限轉向場景落地與交付。



內容:


在AI最熱門、融資與估值屢創新高之際,一批最接近技術前線的人卻開始主動離開。他們並非遭到裁員,而是轉往產品營運、傳統製造業,甚至回學校教書,或投入農業、連鎖餐飲等領域。


這些人的答案相當一致:看不到落地。


外界關注的是模型的能力上限,看它又能完成哪些新任務;業內人士面對的卻是交付下限,也就是模型在真實業務中能否穩定運作。實驗室裡效果驚人,到了客戶現場卻漏洞百出,兩者之間的差距就是「最後一公里」。


一名在大廠工作三年的模型工程師,曾參與化工廠設備故障預警專案。團隊投入半年,模型準確率超過九成,但正式落地時,現場師傅問:「如果誤報一次,停機一天損失六十萬,你們敢擔保嗎?」團隊無法承諾。


這名工程師後來轉往規模較小的工業質檢公司,薪資沒有增加,但能直接接觸真實資料、產線與工人。他認為技術已經足夠,真正不足的是對場景的理解,因此選擇深入產業補足能力。


從研究轉向產品的人,是在補商業化能力,因為再強的模型若不能解決具體問題,就無法產生收入。從大廠前往傳統產業的人,是在補場景縱深,因為通用能力已成紅海,真正的護城河藏在產業內部。至於徹底離開的人,則是在評估後認為投入產出比不再划算。


這些選擇雖然方向不同,卻指向同一件事:AI產業已經進入兌現期,開始從講故事轉為交答卷。


前兩年,AI職缺是明顯的賣方市場,只要具備模型調校能力便有人爭搶。如今,企業的招聘條件逐漸加入「熟悉特定行業流程」與「具備交付經驗」。單一技術能力的議價空間正在下降,結合技術、產業與交付經驗的複合能力則更加重要。


第一個提醒是,不要只學工具。AI工具的替代週期可能只有幾個月,今天花錢學習的技巧,明年或許就會內建成一個按鈕。真正有價值的是對行業的理解,包括哪個環節最痛、誰願意付費,以及驗收標準是什麼。


更可靠的路徑,不是從AI裡尋找問題,而是先從自己熟悉的領域找到真實問題,再運用AI解決。順序一旦顛倒,方向也可能隨之偏離。


第二個提醒是,警惕只談能力上限、卻不談交付下限的人。許多課程只展示模型能做什麼,卻很少說明它在真實業務中如何出錯。真正參與一線交付的人,更關心資料從哪裡來、錯誤由誰承擔,以及系統上線後如何維護。


判斷一個人是否真正投入實務,可以觀察他是否願意談風險、成本與代價。


最懂AI的人選擇離開,並不代表這個產業失去前景,而是容易完成的部分已逐漸結束。真正的機會才正要開始,只是它不一定存在於最熱門的地方,而是藏在那些艱苦、緩慢,卻又必須有人完成的產業現場。