[AI 衝擊] AI暗黑工廠：當軟體工程進入極速開發時代

 [AI 衝擊] AI暗黑工廠：當軟體工程進入極速開發時代

摘要 : AI大量接管寫碼後，工程師角色正從工匠轉向工廠經理，生產力暴增同時也帶來失控、重構與基礎設施新挑戰。

內容:

你印象中的程式設計師，或許還停留在那種安靜敲鍵盤、反覆推敲邏輯、謹慎測試的工匠式畫面。但這份材料描繪的，已經不是人類親手逐行寫程式的世界了。取而代之的，是大量高活躍度的 AI 智慧體同時在程式碼庫中高速產出，讓軟體工程從「手工創作」轉變成「規模化生產」的現場。

OpenCloud 的維護者 Vincent Cox，正是這種新模式的縮影。白天，他在大型企業裡遵循嚴格、結構化、安全優先的工程規範；夜晚，他則投入開源世界，依靠對測試框架的強烈信任，驅動大批 AI 在程式碼庫中高速運轉。這種反差不只是工作風格的切換，更像是兩套完全不同的工程哲學並存於同一個人身上。

最令人震撼的是這種模式所帶來的吞吐量。OpenCloud 的核心維護者其實只有約 10 到 15 人，而且大多數人都有全職工作，但專案高峰期卻能做到單日約 800 次程式碼提交。更誇張的是，Vincent 曾在 3 月 15 日創下個人單日將近 3400 次提交的紀錄。這不是透過作弊腳本灌水，而是真實大量驅動 AI 所產生的結果，甚至因此頻繁觸發 GitHub 的 API 保護機制，被平台按小時熔斷，反而成了他少數被迫停下來休息的時間。

這也揭示出所謂「暗黑工廠」模式的核心：當程式碼的主要生產者不再是人類手指，而是大模型的生成能力時，軟體工程比拚的就不再是個人的手速，而是整體生產體系的調度能力。真正的變化，不是寫得更快，而是整個生產方式被重新定義了。

Vincent 用一段早年體驗 VR 的經歷，來形容開發者面對這種 AI 洪流時的感受。2013 年，他曾無視早期 VR 頭顯「每次使用不要超過五分鐘」的警告，連續玩了三小時遊戲，最後不但劇烈暈眩、抱著馬桶狂吐，連視覺都短暫扭曲。他認為，這種生理上的反胃與失衡，和今天開發者面對幾十個 AI 同時輸出、數萬行程式碼瀑布般湧出的認知衝擊非常相似。不是因為內容不能理解，而是因為量級太大，超出了人腦即時消化的極限。

因此，開發者的角色被迫改變。過去那種逐行雕琢程式碼的浪漫工匠形象，正在被「監控整條流水線的工廠經理」所取代。這種轉變甚至可類比英國工業革命：手工織布時代，最熟練的工匠也受限於雙手速度；而進入集中式工廠後，產能的上限來自系統規模與機械協作。AI 時代的軟體工程，也正在經歷類似的結構性躍遷。

在這套模式裡，系統被拆成多個不同風險等級的「湧道」。其中第三與第四號湧道屬於深水區，負責較複雜的功能開發，例如整合與底層訊息通道機制。這部分人類無法缺席，必須與 AI 持續高頻互動、審查架構、修正偏差。AI 更像是高速起草的工程師，人類則是負責把關安全性與方向的經理。

壓力最大的則是第五號湧道，也就是專門處理 P0、P1 級高危 Bug 的急診區。這裡的 AI 會長時間潛伏在社群平台與討論頻道中，持續監聽全球使用者回報。一旦察覺崩潰徵兆，便立即整理出過去幾小時內的重大錯誤、提煉重點並給出修復建議。從這套體系可以看出，真正稀缺的已經不是 Token 成本，而是算力，以及人類注意力、腦容量與多工處理能力。

這種脆弱性，在一次被稱為「凌晨兩點大重構」的事件中徹底暴露。一位位於地球另一端、毫不知情的開源維護者，只是移動了幾個底層檔案路徑，卻瞬間導致整個通訊架構混亂甚至癱瘓。按照傳統工程思維，這種事故應該先回滾、再補丁修復。但當時疲憊不堪的團隊卻做出極度反直覺的決定：不修了，乾脆趁機把整個程式碼庫徹底重構成外掛化架構。

這個決定背後其實有明確邏輯。在 AI 時代，新增功能的成本大幅下降，真正困難的不是答應需求，而是拒絕需求。如果架構沒有物理層面的解耦，專案很快就會因特性膨脹而變成無法維護的泥潭。於是他們放開限制，讓數十個 AI 全面接手重構工作。最終，短時間內產生了約 2700 次提交，修改近千萬行程式碼，觸及核心程式碼庫約 82% 的區域，幾乎等同於把整棟大樓炸掉後原地重建。

過程中當然一度瀕臨失控。測試系統滿屏飄紅，團隊陷入強烈自我懷疑，甚至懷疑自己是否像伊卡洛斯一樣飛得太高、終將墜落。但戲劇性的轉折是，最後救回整個專案的，竟然是那些平常被資深工程師嫌棄、由 AI 過度擬合產生的糟糕單元測試。

這些測試平常被視為技術債，因為太死板，稍微改動邏輯就會報錯；但在這場毀滅式重構中，它們反而成了最原始、最可靠的生命線。只要這些老派而僵硬的測試重新變綠，就代表最底層的核心邏輯仍然是通的。換句話說，即便新房子蓋得再奇怪，只要地基和主要承重結構還能通過驗證，就還有挽回空間。

然而，真正撐起這種極速並發開發模式的，不只是流程與測試，還有底層基礎設施。Vincent 也坦言自己曾犯下一個代價巨大的判斷錯誤：他原本使用適合傳統開發的工作樹機制來管理多執行緒工作區，因為這樣能共享同一套程式碼庫、節省硬碟空間。但在暗黑工廠模式下，數十個 AI 不斷拉取與提交，導致每天累積 70 到 80 個極度活躍的工作區，最終把高規格機器也拖進記憶體溢位與系統崩潰。

相較之下，他的同事 Peter 採取了極為粗暴但有效的方法：直接把整個龐大程式碼庫完整複製多份，透過物理隔離來徹底避免工作區之間互相爭搶資源。這種看似笨拙的做法，反而更適合高並發 AI 開發的現實需求。

經歷這些慘痛教訓後，Vincent 又進一步打造出一套保命機制：一個常駐守護程序。當系統因為 AI 的瘋狂輸出而卡死、接近崩潰時，他只要按下鍵盤上的 ESC 鍵，守護程序就能立刻介入，強制熔斷失控流程，並指揮 AI 進行環境清理與狀態恢復。這相當於替整座高速運轉的暗黑工廠，加裝最後一道人工緊急煞車。

整體來看，這份內容真正想揭示的，不只是「AI 能把寫程式速度提升多少」，而是軟體工程的本質正在改變。開發者不再只是程式碼作者，而更像是調度者、審查者、熔斷者與系統經理。AI 帶來的不是單純效率提升，而是一種足以讓工程方法論、團隊協作方式、架構設計原則與基礎設施策略全面重寫的衝擊。

[AI 回顧] Token Maxing三月熱潮退場

[AI 回顧] Token Maxing三月熱潮退場

摘要 : Token Maxing從矽谷狂熱蔓延至大廠，卻在三個月內快速降溫，主因是成本失控、ROI不明、能力與組織流程脫節。

內容:

三個月前，矽谷還在流行一場名為「Token Maxing」的熱潮。當時工程師們比拼誰消耗更多 token，彷彿用得越多，就越懂 AI、越代表未來。這股風潮最早出現在 OpenAI、Anthropic 等前沿模型公司內部，後來快速擴散到整個科技圈，甚至連迪士尼、Visa 與國內大廠都加入其中。

所謂 Token Maxing，本意是「最大化使用 token 資源」，但很快被扭曲成一種身份象徵。大家開始把高 token 消耗等同於更高的 AI 掌握度與生產力。當時的氛圍甚至到了「不用 AI 就落後、不多用 AI 就是態度有問題」的程度。

但這場熱潮退得也非常快。到了五月底、六月初，亞馬遜關閉了內部 AI 使用排行榜，因為員工開始為了衝排名而讓 AI 執行沒有價值的任務。Uber 也公開質疑 token 消耗與實際業務成果之間的關聯，微軟則開始削減大量內部 Cloud Code 授權。原本無上限投入的企業，幾乎都陸續踩下煞車。

在這波調整中，各家公司也開始尋找新的衡量標準。百度提出以日活智慧體數（DAA）取代 token；Devin主張用節省的人類工時衡量；Uber希望將 token 與功能交付、ROI 掛鉤；亞馬遜則回到客戶與業務問題解決數量。但問題是，token 消耗與這些最終指標之間並沒有簡單直接的換算關係，試錯成本與效益邊界也難以界定。

微軟 CEO 納德拉後來提出「Token 資本」的概念，認為 token 使用的目的不應只是消耗，而是要沉澱成企業自己的 AI 能力資產，例如工作流、私有評測、組織知識、反饋閉環與可遷移的企業經驗。這個觀點雖然補充了部分方向，但本質上也只是把正在被工具鏈自動化的流程，重新包裝成企業資產來理解。

那麼，Token Maxing 為什麼會這麼快失敗？最直接的原因就是太貴了，企業燒不起。更深層來看，至少有三個原因。

第一，前沿模型公司的成本結構本來就不好看，尤其在 IPO 壓力下，更難維持寬鬆的使用政策。模型本身研發成本極高，商業化後毛利也未必理想，因此企業開始提高價格，或透過調整 tokenizer、計費方式來變相漲價。

第二，訂閱制被重度使用者與 agent 工具打穿了。原本包月訂閱適用於一般聊天式使用，但自動化 agent 能長時間並行工作，token 消耗遠超舊有模型。這讓廠商不得不把高強度推理成本拆出來額外收費，例如 Anthropic 與 Google 都開始調整訂閱方案與計費邏輯。

第三，從技術層面看，agent 的 token 消耗極其驚人，而且效率很低。研究指出，agent 式程式設計任務的 token 消耗大約是普通程式碼問答的 1000 倍，最大開支還不是輸出，而是模型反覆讀取上下文的輸入成本。探索、修正、測試等階段尤其消耗巨大，說明現有工具鏈為了讓模型不跑偏，必須不斷餵入上下文，代價極高。

此外，agent 真正的能力也還遠未成熟。研究顯示，在大量真實專業任務中，即使是最好的系統，最難任務的完整通過率也只有 8.6%，平均甚至只有 2.6%。而且 75% 的失敗並不是執行層面的手腳問題，而是理解與策略問題，也就是說，agent 最大的短板是缺乏真正的行業知識與專業判斷。

這意味著，AI 並不是不能做事，而是越接近真實企業場景，越依賴隱性知識、本地規則、專業流程與可驗證輸出。一個通用 skill 到企業內部往往還要二次開發，法務、財務、研發、銷售各有自己的規範與系統，越貼近業務，越難通用。

組織層面也是一大瓶頸。即使 AI 在某個上游環節真的有效，比如寫程式碼，它也未必能轉化成最終成果。因為程式碼之後還有審查、測試、整合、發布與採用等一連串流程。上游加速了，但下游沒有同步加速，最後就只會堆出更多半成品。

MIT 的研究就指出，AI 工具確實讓程式碼提交大幅增加，但這種增幅傳導到專案數與實際發布版本時，效果會明顯縮水。也就是說，「寫出更多程式碼」和「交付更多產品」完全不是一回事。更麻煩的是，AI 產生的程式碼還可能讓人類後續審查負擔更重，理解難度更高，進一步卡住人的頻寬。

除了這些大問題，還有兩種常被忽略的浪費。第一是簡單任務上的虛耗。研究顯示，像簡單算數、拼寫檢查、同義詞查詢這類小任務，很多人明明自己做更快，卻還是習慣打開 AI。結果反而花更多時間在寫提示詞、等待答案、閱讀與確認上，形成一種「效率幻覺」。

第二是重複造輪子。隨著 agent 生成內容的成本越來越低，開發者與 AI 都更傾向直接重新生成一份，而不是搜尋、理解、複用既有成果。研究發現，大量 skill 高度相似，許多 agent 提交的程式碼修復請求最終未被合併，其中相當一部分原因就是同樣的問題早已被別人解決。這說明在缺乏全局協調時，AI 很容易放大重複建設與資源浪費。

總結來看，Token Maxing 的失敗，不只是一次短期泡沫破裂，更像是 AI 產業從狂熱走向現實的過程。它暴露了兩件事：第一，現階段 agent 的能力還不足以在所有任務上穩定提效；第二，企業也還沒有建立出一套成熟的 AI 使用方法，能真正避免浪費並轉化為業務成果。

更深一層說，這其實是經濟學中「生產率悖論」的再次上演。像電力、電腦、網際網路這些通用技術，在剛出現時都曾經歷過「技術進步很快，但整體產出沒有立刻提升」的階段。因為真正的瓶頸，往往不在單一技術本身，而在與之互補的流程、制度、組織與人類能力。

所以，Token Maxing 的退潮不一定代表 AI 沒有未來。相反地，它可能只是提醒大家：AI 要真正產生價值，不能只看 token 花了多少、程式碼寫了多少，而要看它是否穿透整條價值鏈，最終轉化成可交付、可使用、可驗證的成果。

[AI 分享] AI三巨頭分道競爭，產業進入下半場

 [AI 分享] AI三巨頭分道競爭，產業進入下半場

摘要：Google拚生態、Anthropic拚深度、OpenAI拚商業化，AI競爭重心正從模型能力轉向產品與服務。

內容:

AI產業正在進入一個新的競爭階段。5月19日，Google、Anthropic、OpenAI幾乎在同一時間做出重大動作，但三家公司選擇了完全不同的方向，也象徵AI競爭正式走入下半場。

Google在當天一口氣發布28項產品與功能，企圖全面擴張AI在日常生活中的滲透率。重點包括可長時間在背景運作的AI管家「Gemini Spark」，即使手機螢幕關閉，仍可協助處理郵件、追蹤任務與安排日曆；新一代旗艦模型「Gemini 3.5 Flash」，主打更快的速度；以及可24小時監控新聞、部落格與社群媒體動態，並主動推送資訊的AI資訊代理。除此之外，還涵蓋影片生成、程式設計平台升級與智慧眼鏡等。

Google的核心戰略很明確，不只是推出單一強產品，而是藉由Gmail、地圖、搜尋、YouTube等既有生態系，打造更難被取代的AI入口。它比的不是單點模型最強，而是誰能讓使用者更離不開自己的整體服務體系。

另一方面，Anthropic則走向更聚焦、更深度的路線。當天，知名深度學習專家加入Anthropic，引發AI圈高度關注。這類頂尖人物的轉換，不只是職涯選擇，更像是在替某種技術路線投票。

Anthropic從一開始就強調兩件事：打造最好的模型，以及確保模型對人類安全。這種堅持並非口號。此前美國國防部曾要求AI供應商移除部分安全限制，允許軍方將AI應用於所有合法用途，Google與OpenAI選擇接受，但Anthropic拒絕放寬自主武器與大規模監控相關紅線，甚至因此失去高額合作機會。

Anthropic的特別之處，不只是有原則，而是把這種高標準落實到產品上。其模型與工具在長推理、深度分析與程式設計領域被不少人視為頂尖選擇。它不追求產品數量，也不急著鋪滿生態，而是專注在做出夠強、夠硬的產品，並吸引最優秀的人才。

至於OpenAI，則走出第三條路：商業化與速度。Sam Altman在同一天宣布推出1到3年的算力承諾合約，提供折扣價格，並強調市場對算力確定性的需求正在上升，未來一段時間算力緊缺可能仍會持續。同時，OpenAI也對特定創業圈提供token資源支持。

這背後代表的是，OpenAI正在把算力當成一種可預售的資源，近似「算力期貨」。邏輯很直接：趁AI需求持續暴增、算力仍然稀缺時，用長約換取客戶承諾、穩定現金流與可預期收入。

OpenAI目前的處境相對微妙。它仍然是全球最具知名度的AI品牌之一，但在模型前沿能力上，未必始終全面領先；在產品生態鋪設上，也面臨Google這類巨頭的壓力。因此它選擇更務實地把品牌、用戶規模與商業模式轉化為護城河。與其只比誰模型更聰明，不如先比誰能更快鎖定客戶、把算力變現。

這三條路之所以在此刻明顯分叉，根本原因在於AI競賽的重心變了。從2023年到2025年上半，市場比的是誰先做出GPT-4等級的模型，模型能力幾乎代表一切。但到了下一階段，頂尖模型之間的差距逐漸縮小，多模態、長推理、程式設計、日常任務與工具整合能力，各家都開始形成自己的強項，已經很難再出現一家全面碾壓所有對手的情況。

於是，Google選擇了廣度，靠生態綁定使用者；Anthropic選擇了深度，專注做最強的細分產品；OpenAI則選擇了速度與商業化，搶先鎖定資源與現金流。

對一般AI使用者來說，這其實是好事。因為市場不再只有單一強者，而是三家各自擅長不同場景。未來關鍵不再是找「最強AI」，而是找「最適合自己需求的AI」。

如果偏向搜尋研究、多模態內容製作，可優先考慮Gemini；如果需要深度分析、長文撰寫、程式設計，Anthropic系統可能更合適；如果重視日常對話、快速原型與成熟工具體驗，OpenAI仍然具有明顯優勢。理解各家定位、依需求組合使用，往往才是最實際的策略。

總結來看，這一天三家公司同時亮牌，不只是新聞事件，更是一個訊號：AI模型本身的絕對差距正在縮小，未來競爭將更集中在產品、服務、商業模式與使用者體驗。對大公司而言，這是新一輪戰略分化的開始；對創業團隊而言，則意味著更需要找到差異化定位；而對普通使用者而言，真正重要的是建立屬於自己的AI工作流，讓工具為自己提升效率與產出。

AI下半場，才正要開始。

[AI 分享] 用對AI的方法

 [AI 分享] 用對AI的方法

摘要 : 多數人用不好AI，不是提示詞不夠長，而是把自己的有限理解硬套給AI。真正有效的方法，是提供優質樣本，讓AI自行拆解規律。

內容:

大部分人用不好AI的核心原因，在於他們常常把AI變成「另一個維度的自己」。換句話說，很多時候提示詞寫得越詳細，反而越容易把AI的表現限制在自己的理解範圍內，導致結果看起來很假、很僵硬，缺少真正的味道。

以AI寫爆款文案為例，很多人會先告訴AI「你是一位資深文案專家」，再補充一大堆風格、原則與技巧，甚至寫上數千字提示詞。但最後產出的內容，往往只是表面像，實際上沒有神韻。也有人研究某些博主的影片後，整理出短句、犀利語言、反問等特徵，再把這些規則餵給AI，結果依然只是「形似神不似」。

問題的本質在於，這些做法都是把自己腦中對某種風格的理解，翻譯成一套規則，然後要求AI照著執行。這在某些場景可以成立，但在更多創造性工作裡，往往註定失敗。

使用AI大致可以分成兩種類型。第一種是流程明確、步驟清楚的任務，例如翻譯、資料整理、格式轉換，或將A平台內容搬到B平台並做固定調整。這類工作輸入、輸出和中間流程都能清楚定義，使用詳細提示詞或智慧體處理，通常效果很好。

第二種則是創造性任務，例如希望AI模仿某位博主，寫出相似風格的爆款內容。這時候，單靠自己總結幾條特徵，再轉成提示詞讓AI模仿，通常不夠。因為你以為自己抓住的是對方成功的秘密，但實際上往往只抓到表層。

這就像學做菜。你去餐廳吃到一道很好吃的菜，或許能分辨出用了醬油、蠔油，火候比較大，於是把這些寫成菜譜讓別人照做。但成品通常還是差很遠。原因是廚師真正的能力，不只是材料和步驟，而是火力、翻鍋節奏、下料時機，甚至是一種說不清楚的手感與經驗。你從外部觀察後得到的，只是你理解中的那道菜，而不是廚師真正做出的那道菜。

因此，正確做法不是先替AI總結規則，而是直接把作品本身交給AI。讓AI看到真正的大量樣本，例如把某位高手的十篇、幾十篇，甚至上百篇作品直接提供給它，然後只問一句：「幫我分析這些內容有什麼共性？」

大語言模型最強的能力，本來就不是乖乖執行你主觀整理出的規則，而是進行大規模模式識別。它是從海量文本中訓練出來的系統，只要給它足夠多的樣本，它就能提取出連創作者自己都未必意識到的規律。

實際上，當把一個人表現最好的幾十條影片文案都交給AI分析，而且不先預設風格、不限定維度時，AI拆解出來的結果，往往比人自己反覆觀看後總結得更完整。它可能分析出平均句長、短句比例、反問句常出現的位置、正文結構偏遞進還是分點、開頭啟動了什麼樣的心理機制等。很多細節，往往是人看到AI分析後，才恍然大悟原來一直存在，只是自己過去根本不會想到去觀察。

這裡有一個很核心的差別。若你先研究高手，再把自己的研究成果寫成提示詞，那AI產出的上限，其實就是你的認知上限。你不知道的東西，就無法寫進提示詞裡。反過來，如果你把高手的作品直接交給AI，讓它自己拆解規律，那你用到的就是AI最強的模式識別能力，這才是真正發揮它價值的方式。

所以，與其在提示詞裡憑空塑造一個你想像中的高手，不如去現實中找到真正的高手與真實作品，然後大量提供給AI，讓它自己分析、自己總結。你的任務不是教AI怎麼做，而是選對樣本、問對問題。

說到底，AI時代真正重要的分水嶺，是你是否願意承認：在許多創造性領域裡，自己的理解其實不足以直接定義想要的結果。一旦承認這一點，你就不會再執著於把有限認知硬塞給AI，而會把自己的角色，從「教AI做事的人」，轉變成「為AI選素材、提問題的人」。這種策展式的能力，才是更值得修煉的方向。

[AI 分享] 大腦啟動規則

 [AI 分享] 大腦啟動規則

摘要 : 靈感常在放空時出現，關鍵不在意志力，而在降低啟動摩擦、設定貼邊難度，並用簡單流程快速進入深度工作。

內容:

你可能常有這種經驗：洗澡、走路、搭地鐵，甚至上廁所時，突然想通卡了一整天的問題；但真正坐到桌前準備工作時，反而發呆、分心、遲遲進不了狀態。這種差距背後，其實藏著一套大腦啟動工作的規則。只要理解它，不一定要有安靜房間或整段空檔，在零碎時間裡也能更快進入深度工作。

很多人以為自己做不下去，是因為不夠自律，但研究指出，真正的問題常是「注意力殘留」。當你從一件事切到另一件事，前一件事留下的思緒碎片還會佔據工作記憶，讓你雖然人坐在書桌前，大腦卻還停留在剛剛的訊息、影片或聊天內容上。於是你一天下來覺得很累，但真正專注工作的時間可能很少，最耗能的往往不是工作本身，而是開始前的反覆空轉。

除了注意力殘留，還有一個更隱蔽的因素是「啟動摩擦」。同樣的人、同樣的工作，若檔案早已開好、資料就放在手邊、手機也被收起來，往往幾分鐘就能開始；反過來，如果還要找檔案、開軟體、想怎麼起頭，大腦就會判定這件事太麻煩。BJ福格的模型指出，行為要發生，需要動機、能力與提示同時具備；很多時候不是你不想做，而是環境把開始的門檻抬高了。若能提前用「什麼時間、在哪裡、做什麼」的執行意圖鎖定行動，啟動就會容易得多。

但能開始，不代表能持續。想進入像玩遊戲那樣的投入狀態，還需要符合「心流」條件：目標清楚、反饋即時、挑戰與能力匹配。其中最重要也最容易忽略的是任務難度要剛剛好，也就是所謂的「貼邊難度」——不能太簡單讓人無聊，也不能太難讓人想逃。只有當任務比你當前能力高一點點，剛好需要專注、又不至於崩潰時，大腦才最容易咬住不放。

因此，實作上的關鍵是把任務切小，切到15分鐘內能看到一個結果。像寫文章先寫300字開頭，做方案先列出第一頁框架，練琴先單獨練最難的幾個小節。這種可見的小交付物，既能降低壓力，也能快速提供回饋，幫助大腦逐步進入更深的專注狀態。對創造性工作來說，過高壓力反而有害，適中的喚醒程度通常表現更好。

如果環境不理想，也可以靠一套隨時可用的啟動流程：第一，只要求自己先做15分鐘，不追求一次做完；第二，把入口縮小到30秒內能完成的第一步，直接開始；第三，為每個小進展設計可見回饋，例如打勾或劃線；第四，減少干擾，把手機翻面、關掉無關頁面、移開雜物。走神、拖延、遲遲無法開始，很多時候並不是你意志力差，而是你還沒用對大腦啟動的方式。

[AI 觀點] 程式設計師在AI時代真正值錢的能力，是「寫得慢」

 [AI 觀點] 程式設計師在AI時代真正值錢的能力，是「寫得慢」

摘要 : AI讓寫程式碼速度不再稀缺，程式設計師真正值錢的，是能慢下來做架構、決策與品質把關。

內容:

在AI時代，程式設計師最稀缺、最值錢的能力，可能不是寫程式碼快，反而是「寫得慢」。這裡的慢，不是摸魚或拖延，而是先思考、先設計、先判斷，再動手實作的能力。

過去初級與高級工程師的重要差距，常常來自熟練度與輸出速度。老手熟框架、熟API、熟業務，寫起來自然比新手快很多。但現在AI已經能在極短時間內生成大量看似合格的程式碼，單純比拚敲鍵盤速度，人的優勢幾乎被抹平。當所有人都能快速產出程式碼時，「快」就不再是核心競爭力，而成了廉價能力。

AI普及後，程式設計師的分層會更明顯。初級工程師容易沉迷於速度，拿到需求就直接交給AI生成，快速接受建議、快速拼出頁面與介面，誤以為是自己效率提高了，實際上只是模型在幫忙加速。中級工程師開始處理較複雜的功能，能利用AI做模組整合，讓系統跑起來。但真正高級的工程師，核心能力不在產碼，而在決策。

高級工程師拿到需求時，第一步不是立刻生成程式碼，而是先分析需求、拆解系統、釐清業務邊界、設計資料表與架構，甚至思考未來幾年的擴展性。他們關注的不只是「這個功能能不能做出來」，而是「這樣設計未來會不會崩」、「下次需求變更時需不需要整個重構」。這種看起來比較慢的過程，才是真正有價值的地方。

所謂真正的慢，是一種「謀定而後動」的能力。AI可以當油門，但方向盤一定要握在人手上。你必須給AI清楚的上下文、明確的業務邊界與技術限制，才能讓它產出真正有用的結果。如果自己都沒想清楚，就只是丟一堆模糊需求給AI，那它雖然能很快生成程式碼，卻很可能產出一堆難維護、易出錯、與需求偏離的內容。

因此，比起快速生成程式碼，更重要的是仔細審視AI的輸出。包括review程式碼品質、檢查邏輯漏洞、確認併發安全、記憶體問題，以及判斷設計是否合理。這些工作看起來慢，但這正是工程師不可替代的價值。真正要負責上線品質與系統安全的人，不能只追求速度，否則程式碼寫得越快，翻車也可能越快。

AI讓寫程式碼的成本不斷下降，但讓系統做出正確決策的能力，價值卻變得越來越高。真正厲害的技術人，不一定天天親手敲很多程式碼，但他們知道系統該往哪裡走，也能判斷AI提出的方案到底是好解法還是陷阱。

所以，與其和AI比誰寫得快，不如把節奏放慢，把腦力放回需求理解、架構設計、邏輯判斷與品質控制上。在AI時代，能穩定思考、清楚決策、正確駕馭AI的人，才是最不容易被取代的那一群。

[AI 分享] 長專案中如何讓AI回到受控狀態

 [AI 分享] 長專案中如何讓AI回到受控狀態

摘要 : 長視窗易讓AI飄移，關鍵是分階段拆解、適時換視窗，並在每次開工前重新校準任務邊界。

內容:

很多人在用AI處理稍微長一點的專案時，都會遇到同樣的問題。前面對話看起來很正常，但隨著聊天視窗越來越長，AI開始偏離原本任務。你讓它修一個小問題，它卻順手改了其他地方；你讓它做驗收，它一邊檢查一邊直接修改，最後驗收又變成開發。即使你事先寫了規則或文件，AI口頭上說會遵守，實際執行時還是很容易被上下文帶偏。

這篇內容的核心重點，是當視窗變長後，如何把AI重新拉回可控狀態。第一個方法是「勤換視窗」，但換視窗真正困難的地方，不是開新聊天，而是如何把舊視窗的重要工作狀態正確交接到新視窗。很多人會重新講背景，卻漏掉最重要的執行資訊，例如目前處於哪個階段、已完成哪些工作、下一步只做什麼、依據哪些文件、驗收標準是什麼。只有把這些內容整理清楚放到新視窗最前面，AI才有機會從舊的混亂上下文中被拉回來。

至於什麼時候該換新視窗，可以看兩個訊號。第一是階段切換，例如需求整理完成後要進入開發，或一輪修復完成後準備驗收，只要工作階段改變，就很適合開新視窗。第二是AI已經出現明顯飄移，例如回覆變慢、答非所問、重複內容，或你叫它做A，它總是順手去碰B。這時候不要硬聊，應該先做交接，再換到新視窗繼續。

換視窗也分兩種情況。如果目前視窗還能正常工作，就在舊視窗直接要求AI整理一份「新視窗工作交接提示詞」，內容要包含專案目標、已完成階段、當前進度、正在處理的檔案或模組、下一步任務、必須遵守的文件、驗收標準與已知風險，而且要明確要求它「不要繼續開發，只做交接」。這句話很重要，因為此時你的目標不是讓它往前做，而是把真正有用的資訊整理出來。

如果目前視窗已經無法正常工作，例如內容混亂、一直轉圈、總結品質也變差，那就不要再依賴它原地整理，而是讓新視窗回頭讀取舊對話，再先做交接整理。重點依然是不要直接開發，而是先確認已完成與未完成內容、目前階段、關鍵限制、風險點與下一步計畫，同時再次確認規則文件是否真的被遵守。

第二個方法，是每次開工前都先補一次「階段邊界」。除了換視窗以外，還要養成一個習慣：每次開始工作前，先明確告訴AI現在是什麼階段，例如需求、開發、測試或驗收，並要求它先複述自己理解的階段目標、當前任務、禁止事項與驗收標準，等確認無誤後再開始。這樣做的目的，是讓AI在每次開工前重新校準邊界，不要帶著上一階段殘留的脈絡一路衝下去。

不過這種方法也有前提，那就是目前視窗還不能太長。如果上下文已經嚴重失控，只靠補一句提示詞效果有限，這時還是應該先換視窗、完成交接，再在新視窗重新建立規則與範圍。

最穩定的做法，其實是從一開始就不要把所有事情混在一起。需求、前端、後端、修Bug、測試、驗收如果全部塞進同一個長視窗，專案本身就容易變糊，AI自然更容易飄。比較好的方式，是把工作拆細，分成一個個階段文件來推進。每個階段只處理一件主要事情，並清楚定義目標、依據文件與驗收標準。這樣即使AI偏了，你也有文件可以把它拉回來；即使要換視窗，也有明確的交接依據，不會因為上下文丟失而重來。

總結來說，AI在長視窗中飄移是很正常的現象，不能只靠一句「請嚴格遵守規則」來硬壓。真正有效的方法有三個：第一，先把工作拆成清楚的階段，建立文件化底座；第二，當階段結束或AI明顯飄移時，就及時換視窗並做好交接；第三，每次開工前都重新確認階段目標、任務邊界與驗收標準。只要這三件事做好，即使AI有飄移傾向，也比較容易重新回到可控狀態。

[AI 分享] 打造好用的 Skill 方法

 [AI 分享] 打造好用的 Skill 方法

摘要 : 重點不在規則多，而是寫清觸發場景、任務邊界、輸出格式與示例，才能做出真正好用的 Skill。

內容:

cloud 官方文件指出很多人寫 Skill 效果不好，不是因為不夠努力，而是沒有抓到設計重點。真正好用的 Skill，不是靠堆疊大量規則，而是要讓系統清楚知道「什麼時候該被呼叫」、「被呼叫後要完成什麼」、「最後要如何輸出」。

先介紹 Skill 的基本結構。標準的 skill.md 分成兩部分：上方是 YAML 配置區，包含名稱、觸發時機與是否需要額外權限；下方是 Markdown 內容區，負責描述 Skill 被調用後的具體執行方式。示範案例是一個名為「meeting to action」的 Skill，功能是把會議記錄轉換成結構化的行動項清單。

其中，配置區最重要的欄位是 description。這一段文字會被系統拿來做語意匹配，判斷目前對話是否需要自動載入這個 Skill。若 description 只寫「會議記錄整理工具」這種模糊描述，系統無法理解具體用途與觸發時機；但若寫成「把會議記錄或會議內容整理成結構化的行動項清單，當使用者提供會議逐字稿、錄音轉文字，或要求整理會議與提取行動項時觸發」，就能明確提供場景、關鍵詞與觸發條件。作者也提醒，description 有字數顯示限制，因此最重要的觸發詞要盡量放在前面。

接著內容區的寫法。第一步不是急著列規則，而是先定義任務本身，也就是一句話講清楚這個 Skill 的核心工作。這樣系統才知道執行的終點與邊界，例如這個案例的重點不是做全面摘要，而是只聚焦在行動項、決策與待澄清問題。

第二步是定義輸出格式，而且越具體越好。作者示範的輸出包含三部分：第一是行動項清單，每一條都要有負責人、任務、截止時間與優先順序；第二是本次會議的核心決策，列出兩到四條；第三是待澄清問題，用來標記責任不清或尚未解決的事項，若沒有則可省略。明確的格式設計，能讓每次輸出維持穩定一致，不會忽長忽短、忽散忽亂。

在規則設計上，作者特別強調「少而有力」。很多人習慣寫出一長串像是「保持客觀」、「語言簡潔」、「注意格式」這類看似專業、實際卻缺乏約束力的規則。真正有效的規則，應該要能落地執行，例如：只提取明確任務、負責人不清楚就標示待定、截止時間未說明就寫未定、不要自行猜測內容、行動項要用動詞開頭等。這些規則能直接限制模型最容易出錯的地方。

示例是最常被忽略、卻極其重要的一部分。相較單純描述，完整的輸入輸出示例更能讓系統理解你想要的格式、資訊密度與判斷方式。像是如何區分行動項與決策、如何標記待定、如何處理未解決問題，透過一個涵蓋多種情況的示例，往往比十條抽象規則更有效。

最後，整理出三條 Skill 寫作原則。第一，先寫 description，再寫內容，因為先釐清觸發場景，後續設計才有方向。第二，一個 Skill 只解決一件事，不要同時想讓它整理會議、寫週報又寄信，否則容易失焦。第三，Skill 與 cloud.md 不能混用，cloud.md 適合放每次對話都要載入的固定規則與背景，而 Skill 則適合做按需載入的場景化指引。

整體來說，核心觀點很明確：Skill 不是越長越好，也不是提示詞的堆砌，而是一份精準的操作手冊。只要把觸發條件、任務邊界與示範方式設計清楚，就能寫出真正實用、穩定又高效的 Skill。

[AI 觀點] AI工具下的程式設計師內耗危機

 [AI 觀點] AI工具下的程式設計師內耗危機

摘要 : AI雖提升寫碼速度，卻可能壓縮思考、削弱除錯與架構能力，讓工程師陷入表面高效、實則退化的困境。

內容:

最近不少程式設計師都強烈感受到，真正變捲的不是找工作，而是日常開發工作本身。自從團隊導入 AI 工具後，管理者對開發效率的期待明顯提高，原本需要三天完成的任務，現在可能被認為一天就該做完。因為在許多人眼中，既然程式碼可以由 AI 產出，那工程師只要「按幾個鍵」就能交付成果。

這樣的變化不只來自上層壓力，團隊內部也開始出現一種比拼速度的氛圍。大家互相比誰更會用 AI、誰產出更快，再加上網路上大量渲染「幾秒生成系統」、「一天完成複雜專案」的內容，讓整個開發現場變得越來越焦躁，也越來越失真。

表面上看，AI 的確讓寫程式變快了，但真正令人擔心的是，工程師主動思考的空間正在被嚴重壓縮。過去接到需求後，會先理解問題、設計系統、規劃資料表，再一步一步親手完成程式碼，過程中不斷除錯與重構。雖然慢，但每一段程式碼都經過自己的思考，系統脈絡也更清楚。

現在在時程壓力下，許多人逐漸變成把需求丟給 AI、等 AI 生出程式碼、再把錯誤訊息丟回去修正的工作模式。人腦不再主導開發，而是淪為 AI 與需求之間的傳話工具。這種流程看似高效，實際上卻讓思考能力慢慢退化，長期下來會讓工程師失去最核心的價值。

其中最明顯被削弱的能力之一，就是除錯能力。以前自己寫的程式出錯時，必須看日誌、打斷點、追原始碼、理解底層機制，雖然痛苦，卻能一步步累積真正的技術內功。現在很多人一遇到錯誤，第一反應就是交給 AI 處理。AI 若修好了，自己未必真的知道原因；AI 若修不好，就只能反覆貼錯誤訊息碰運氣。一旦遇到複雜問題，例如分散式鎖、高併發異常或記憶體溢位，若基礎功不夠，往往連問題方向都抓不到。

另一個正在被侵蝕的，是架構與系統拆解能力。AI 擅長提供片段式答案，但企業級專案需要的是全局思維，包括模組拆分、邊界定義、解耦設計與整體架構判斷。當工程師長期習慣讓 AI 幫忙「切碎」問題、提供局部解法，就可能逐漸失去獨立拆解大型系統的能力。一旦系統規模變大、服務開始拆分、邏輯變複雜，AI 很容易因上下文不足而產出錯誤建議，這時若工程師自己也缺乏判斷能力，就很難有效修正。

這種現象帶來的，不只是效率提升，而是技術圈潛在的全面平庸化。問題不在於 AI 會不會寫程式，而在於工程師是否把最有價值的思考與決策也一併外包了。軟體開發中最不值錢的從來不是敲鍵盤，而是鍵盤背後的理解、判斷與取捨。

因此，真正值得警惕的不是 AI 讓人寫更少程式，而是它讓人少想程式。如果工作環境只追求速度，把 AI 當成思考替代品，那麼工程師的核心競爭力就會被一點一滴掏空。面對這個趨勢，最重要的不是拒絕 AI，而是重新思考：在 AI 時代，真正稀缺的能力，依然是獨立思考、深度理解與做出正確技術決策的能力。

[AI 分享] Codex AGENTS.md 實戰寫法

 [AI 分享] Codex AGENTS.md 實戰寫法

摘要 : 善用精簡的 AGENTS.md，可大幅提升 Codex 輸出品質與專案協作效率。

內容:

AGENTS.md 是一份提供給 Codex 的專案使用說明。每次 Codex 啟動時，都會自動讀取這個檔案，因此不需要手動貼上內容，也不需要每次重新說明專案規則。只要在終端輸入指定初始化指令，就能依照當前專案自動生成模板，再依需求進行修改即可。

可以把 AGENTS.md 理解成 Codex 的專案入門指南。若沒有這份檔案，Codex 每次都像剛加入專案的新手，無法快速掌握規則；有了它，Codex 一開始就知道專案怎麼執行、有哪些限制，以及提交前應遵守哪些流程，整體使用體驗會明顯提升。

撰寫 AGENTS.md 時，不建議把整份專案文件全部貼進去。因為它有 32KB 的長度限制，內容太多不但可能被截斷，還可能讓重要規則被忽略。最理想的做法，是把內容控制在十幾行內，只保留最關鍵、最具操作性的資訊。

建議優先寫五類內容。第一是專案執行方式，例如怎麼安裝依賴、怎麼跑測試、使用什麼包管理器與工具。第二是提交前必須完成的動作，例如 lint 與 test 必須全部通過。第三是禁止變更的內容，例如不要修改 ENV 檔案或既有 migration。第四是專案特殊約定，例如 commit message 格式、變數命名規則。第五是新增依賴的規矩，例如加入新的正式環境依賴前需要先確認。

撰寫時也要避開幾個常見問題。第一，不要只寫空泛態度，例如「請重視程式碼品質」，這類描述對 Codex 幾乎沒有實際幫助，應改成具體可執行的命令與步驟。第二，不要把它本來就能從專案中直接判斷的資訊重複寫進去，否則只會製造噪音。第三，不要寫完後就放著不管，因為專案規則會隨時間變動，應定期回頭檢查並刪除已經不必要的內容。

進階用法是分層管理。若專案屬於單一倉庫但包含多個服務，例如前端與後端採用不同技術棧，建議在根目錄放通用規則，再於各服務子目錄內建立各自的 AGENTS.md，分別定義專屬的測試命令與開發規範。Codex 會依所在目錄自動套用對應規則，而且越接近當前目錄的設定優先度越高。

另外，如果只是想暫時調整規則，又不想修改原本的 AGENTS.md，可以在同目錄新增 Agents Override MD。這樣就能臨時覆蓋原設定，刪除後即可恢復，使用上相當彈性方便。

總結來說，AGENTS.md 的重點不是寫得多，而是寫得準。只要內容精簡、明確、可執行，就能讓 Codex 更理解你的專案脈絡，進一步提升輸出品質與工作效率。