讀書心得
|

畢業生選城市指南：別再盲目往北上廣深衝了

你的「45度角人生」選錯城市，努力全白費

畢業生比較北上廣深與新一線城市的求職選擇

我跟你們說一件很殘酷的事—— 你以為拼命擠進北上廣深就是正確選擇？錯了。 胡鞍鋼教授有個概念叫「45度角人生」：橫軸是你的個人目標，縱軸是國家發展方向。兩者夾角45度，才是最佳人生。 聽起來很高大上？我直接跟你說結論：2026年了，對大多數普通家庭的畢業生來說，那個45度角已經不在北上廣深了。

數據不會騙人，但會被誤解

先看一線城市的薪資數字：

  • 上海应届生月薪中位值 7,681 元
  • 北京 7,576 元
  • 深圳 7,568 元
  • 廣州 6,845 元

看起來不錯是吧？但你算過房租嗎？ 深圳一套普通單間，月租 2,500-4,000 元。北京更誇張。扣掉房租、交通、吃飯，你每月能存下多少？我跟你講，很多一線城市的年輕人，月薪八千，月光還倒貼家裡。 再看新一線：

  • 杭州 6,671 元
  • 南京 6,385 元

薪資差了一千多塊，但房租差了多少？杭州單間 1,500-2,500，南京 1,000-2,000。 關鍵問題來了：你到底是想「賺最多的錢」，還是想「存最多的錢」？ 這兩個答案完全不一樣。

中國經濟地理已經變天了

胡鞍鋼把中國發展分成四個版本：

  • 1.0：沿海 vs 內地
  • 2.0：沿海先富
  • 3.0：西部大開發、中部崛起
  • 4.0：四大板塊 + 一帶一路 + 京津冀 + 長江經濟帶

你聽不懂沒關係，我翻譯成大白話：過去十年，國家的錢和機會，早就不是只往東南沿海流了。 2025年的數據更說明問題：

  • 安徽新能源汽車產量激增 1.4 倍，成為「汽車產量第一大省」
  • 湖北、河南、安徽出口同比增速領跑中部地區
  • 四川、湖北、山東、浙江GDP增速均達 5.5%，跑贏全國平均
  • 廣東實際增長只有 3.9%，連續五年低於全國平均

你猜怎麼回事？廣東——也就是深圳、廣州所在地——增速連續五年墊底經濟大省。你還覺得那裡機會最多？

2026屆畢業生的真實選擇

2026年全国高校毕业生超過 1,200 萬人。他們怎麼選？ 數據說話：

  • 34.7% 的畢業生主動選擇二線及以下城市（比去年增加了 4.6 個百分點）
  • 25.1% 準備考公考編（碩士更高達 35.6%）
  • 新一線城市求職者增速，連續三年高於一線

什麼概念？越來越多人清醒了。 深圳雖然還是「95後人才吸引力」第一名，但你知不知道，清華大學近5年有 2,800 多名畢業生去廣東就業，簽約最多的兩家單位——華為和比亞迪，這兩家公司的總部就在深圳。 所以問題不是你該不該去一線，而是：你的目標企業在哪裡？ 華為不在北京，比亞迪不在上海。它們在深圳、東莞、合肥。選城市之前，先看你將來要給誰打工。

我給你三個判斷標準

1️⃣

看產業，不看城市名號 一座城市的產業結構，決定了你的職業天花板。 想做 AI？北京、上海、深圳、杭州有優勢。 想做新能源？安徽、四川、湖北機會更多。 想做物聯網？無錫連續三年人才吸引力排名第9，因為產業聚集。

2️⃣

看「留存率」，不看「吸引率」 很多城市會搶人——給補貼、免房租、送戶口。深圳免費住宿15天、成都30天、長沙本科補1.2萬。 但這些是「引鳳入巢」，不是「固巢養鳳」。 你要看的是：待三年之後，你的人值不值得漲薪？你的技能有沒有增值？

3️⃣

看你的家庭條件 這一點我最想強調。 家裡有礦的孩子，去一線城市試試錯，不行就回家繼承家業。 普通家庭的孩子，錯一次的成本你可能承受不起。 所以你更要算一筆賬：在哪个城市，你用最低的生存成本，換取最大的技能成長？

最後一句話

胡鞍鋼說，個人目標越接近國家發展方向，發展越快。 2026年，國家的方向是什麼？區域協調發展、產業轉移升級、中西部崛起來了。 這不是什麼宏大敘事，這是你找工作時的實際選項。 別再用2018年的思維，打2026年的仗了。 選對城市，比選對公司還重要。因為公司可以換，但一座城市的產業紅利期，過了就沒了。

畢業生選城市常見問題

畢業生一定要先去北上廣深嗎？

不一定。先看目標產業與公司集中在哪裡，再比較房租、通勤、生活成本及三年後的技能成長，城市名氣不能取代職涯判斷。

薪資和生活成本該怎麼比較？

不要只比較月薪，應該比較扣除房租、交通與必要支出後的可支配收入，同時評估該城市能否提供下一份工作的選擇。

新一線城市適合哪些求職者？

如果目標產業已形成聚落、家庭無法長期補貼高房租，或希望用較低生存成本換取技能成長，新一線城市通常更值得納入比較。

延伸閱讀

更多求職與城市選擇內容，可查看 生涯規劃文章。

讀書心得
|

Kimi K3 評測：開源權重已發布，效能、授權與部署成本一次看

2.8 兆總參數、100 萬 Token 上下文、原生視覺能力，以及針對長時間程式開發、知識工作與複雜 Agent 任務所做的強化——單看規格，K3 已經足以成為今年最受矚目的模型之一。Moonshot 預計在 2026 年 7 月 27 日釋出完整權重；在那之前，更精確的稱呼應該是「即將開放權重」，而不是已經完全開源，因為授權條款與實際可下載檔案仍是判斷它是否真正開放的關鍵。

但 K3 真正引發震動的地方，不是「又出現一個更大的模型」，而是它把一個延續多年的產業共識推到了失效邊緣：

開源模型落後閉源旗艦半年，這句話可能已經不再成立。

過去開源模型追趕 GPT、Claude，常常像是在追逐一條移動中的終點線。當開源陣營終於摸到上一代旗艦，閉源公司又已經推出下一代產品。

K3 改變的，是這種時間差。

它或許仍然沒有全面擊敗最強的閉源模型，卻已經從「追趕者」變成必須被放進同一張比較表的競爭者。

而這兩者之間，差別很大。

K3 在牌桌上的位置：跟 Opus、GPT 怎麼排

Kimi K3 與 Claude Opus、GPT-5.6、GLM 5.2 效能比較

根據 Artificial Analysis Intelligence Index v4.1，Kimi K3 Max 的分數約為 57.1。若以每個模型家族的最佳設定計算，它排在 Claude Fable 5 Max 的 59.9 與 GPT-5.6 Sol Max 的 58.9 之後，進入全球前三名的討論範圍。Artificial Analysis 官方頁面目前以四捨五入後的 57 分呈現，因此不同頁面可能會看到 57 或 57.1 的寫法。

這個排名當然不能直接解讀成「K3 是全球第三強」。

模型評測會受到提示詞、推理強度、工具框架、測試版本與 Agent Harness 影響。尤其 K3 的官方成績混用了 Kimi Code、Claude Code 與其他執行框架，目前也不是所有結果都已由第三方完整重現。

不過，K3 的成績仍透露出一個明確訊號：它不是靠單一數學或程式基準刷出漂亮數字，而是在多步驟工具使用、長時間任務和知識工作上，出現了相對一致的進步。

例如在模擬 44 種職業知識工作的 GDPval-AA v2 中，Artificial Analysis 公布的 K3 Elo 為 1668，超過 Claude Opus 4.8 的 1600、GPT-5.5 的 1494 與 GLM-5.2 的 1514，但仍落後 Claude Fable 5。K3 在 AutomationBench-AA 也取得領先成績，顯示它的強項不只是「回答問題」，而是串接工具、處理中間狀態並完成多步工作。 

這是理解 K3 最重要的角度。

如果上一個時代的大模型是在比「誰知道得多」，現在的競爭已經轉向：

  • 誰能維持更長的任務狀態；
  • 誰能在失敗後修正路徑；
  • 誰能正確使用終端、瀏覽器和各種工具；
  • 誰能真正把工作交付出來。

K3 的價值，不只在於智能分數接近 GPT 或 Claude，而是它開始展現出一種過去多半只有頂級閉源模型才有的「工作感」。

為什麼這次發布引爆全網討論

Kimi K3 與 Claude Opus、GPT-5.6、GLM 5.2 效能比較

K3 發布後，開發者社群的反應大致可以分成四派。

它們看似互相矛盾，但其實剛好反映了 K3 的四種不同身分：旗艦模型、開放權重模型、昂貴的基礎設施，以及尚未完全成熟的新產品。

第一派：開源終於有了「旗艦級體感」

最樂觀的聲音認為，K3 的突破不只是排行榜上的幾分，而是實際使用時開始接近頂級 Claude 的工作方式。

部分早期使用者把它形容為具有「Fable 級體感」：模型在長任務中比較不容易失去方向，能持續呼叫工具，也更願意自行檢查結果，而不是做完第一步就停下來等人類指示。社群對它在前端開發、視覺理解和長流程 Agent 任務上的初步反應尤其積極；Arena.ai 的前端開發相關評測也將 K3 排在非常前面。 

這種「體感」往往比 Benchmark 更難量化，卻可能更重要。

因為真正讓使用者依賴一個模型的，不是它在選擇題上多答對三題，而是它能不能在你離開螢幕之後，繼續做對的事。

一個模型如果智力很高，卻每十分鐘就需要人類介入，那它仍然只是一個高級助理；如果它能在數小時的任務中維持目標、管理上下文並修復錯誤，它才開始接近真正的代理人。

從這個角度看，K3 的突破不是「更會回答」，而是「比較能被交付工作」。

第二派：2.8 兆參數是超跑海報，不是家用汽車

另一派的反應則務實得多。

2.8 兆總參數確實驚人，但它也讓「開放權重」與「人人可用」之間的距離變得非常明顯。

K3 採用高度稀疏的 MoE 架構，據公開資料是在 896 個專家中，每次選擇 16 個專家參與運算。這能控制每個 Token 的實際計算量，但部署時仍然要處理完整模型權重、專家路由、記憶體通訊與分散式推理等問題。Moonshot 建議使用 64 張以上加速卡的 Supernode 進行推理，這顯然不是一般個人玩家能負擔的規模。

社群有人用了一個很傳神的比喻：

1990 年代的年輕人會在房間貼超跑海報，夢想有一天能買一台；今天的 AI 玩家則在螢幕上收藏 Kimi、DeepSeek 等模型，夢想有一天自己的機器跑得動。

這個比喻點出了當代開放模型的一個尷尬：

權重可以下載，不代表能力可以民主化。

對一般使用者而言，K3 的權重即使公開，實際使用方式很可能還是透過 Moonshot API、第三方雲端供應商或量化後的衍生版本。真正有能力完整部署的，仍然是雲端平台、研究機構與大型企業。

所以 K3 是開放權重的里程碑，但還不是個人 AI 的里程碑。

第三派：Benchmark 很漂亮，但先別急著刪掉 Claude

第三種聲音是典型的工程師懷疑論。

社群對 K3 的跑分感到興奮，但不少人仍想知道：它在真實專案裡能不能穩定地重現這些表現？

目前首批實測對 K3 的視覺理解與前端頁面復刻能力評價不錯，但也有人反映 Agent 集群會自動中止、排程卡住，以及部分客戶端尚未完整支援新 API 參數。這些回饋還不足以形成全面結論，但提醒我們：模型能力與產品可靠性不是同一件事。

這也是為什麼我不建議因為 K3 發布，就立刻把現有的 GPT、Claude 或其他編程模型全部替換掉。

Benchmark 測的是在特定環境中「最高可以做到什麼」；企業真正關心的，則是在大量、重複、混亂的任務中「穩定能做到什麼」。

兩者之間隔著：

  • API 穩定性；
  • 工具呼叫成功率；
  • 長任務的失敗恢復；
  • 延遲與併發；
  • 內容安全規則；
  • 上下文快取；
  • 成本預測；
  • 版本是否會突然改變。

對開發者而言，一款模型最昂貴的地方，往往不是 Token，而是不知道它會在哪個步驟突然失敗。

第四派：這是中國模型正式進入前沿競爭的訊號

還有一種討論，已經超出模型本身。

Reuters 將 K3 放在中國 AI 實驗室加速開放模型的脈絡中觀察；包括 Moonshot、Z.ai、DeepSeek 等團隊，都正在用更快的發布週期、較低的使用成本與開放權重策略，挑戰「中國模型長期落後美國數個月」的既有判斷。 

這並不只是技術競賽，也是生態競賽。

美國頂級實驗室的核心商業模式，是把最強能力封裝在 API 與訂閱服務裡；中國模型廠商則愈來愈常透過權重開放，換取全球開發者採用。

前者要的是收入與控制權，後者要的是擴散速度與生態位置。

對 Moonshot 來說，開放 K3 的真正目的，未必是讓每個人都在家裡架一套模型，而是讓未來的 AI 工具、研究專案、企業平台和模型衍生版本，都有機會建立在 Kimi 的技術路線上。

權重是入口，生態才是終點。

2.8 兆參數很大，但「大」不是重點

Kimi K3 與 Claude Opus、GPT-5.6、GLM 5.2 效能比較

K3 的 2.8 兆參數很容易成為標題，但只看總參數其實會誤判它的技術意義。

由於它採用 Mixture of Experts 架構，並不是每生成一個 Token，就同時啟用全部 2.8 兆參數。公開資料顯示，K3 以 Stable LatentMoE 搭配 896 個專家、每次選用其中 16 個；然而完整的有效參數量、記憶體需求與不同硬體下的推理效率，仍有待正式技術報告與權重發布後驗證。 

我認為 K3 真正值得看的，不是「模型有多大」，而是 Moonshot 試圖解決三項限制：

  1. 超長上下文怎麼跑得動；
  2. 超深網路中的資訊怎麼保留下來；
  3. 巨大 MoE 的專家怎麼穩定分工。

K3 採用 Kimi Delta Attention 與 Attention Residuals 等技術，目標是改善長序列處理和深層資訊傳遞。換句話說，2.8 兆是結果，不是核心；核心在於 Moonshot 是否找到一種方法，讓龐大的模型容量真正轉化成長任務能力。 

如果只是參數更大、成本更高，K3 很快就會成為一座昂貴的技術紀念碑。

如果它能證明長上下文、工具使用與專家路由可以穩定結合，那它就可能成為下一代 Agent 模型的架構範本。

100 萬 Token，不等於模型真的記得一切

100 萬 Token 上下文是 K3 的另一個賣點。

它可以一次容納大型程式碼倉庫、數百份報告、長時間 Agent 紀錄，或跨文件的研究材料。對需要讀取完整專案、追蹤大量規格與處理複雜文件的使用者來說，這顯然比 128K 或 256K 更有彈性。 

但這裡必須區分三件事：

  • 模型能不能「放進」100 萬 Token；
  • 模型能不能在其中「找到」正確資訊；
  • 模型能不能在數十輪任務後，仍然知道哪些資訊最重要。

上下文窗口比較像倉庫容量，而不是記憶力。

倉庫可以放進一百萬件物品，不代表管理員能在需要時立刻找到正確的一件。對 Agent 來說，更關鍵的是資訊檢索、優先順序、狀態壓縮與錯誤恢復能力。

因此，K3 的 100 萬 Token 真正價值不在「可以塞更多」，而在 Moonshot 聲稱它可以不依賴大量外部上下文壓縮，直接處理長時間工作的完整狀態。K3 在 BrowseComp 等長流程檢索測試上取得亮眼成績，說明這個方向值得期待，但仍需要更多獨立的真實任務驗證。 

K3 的官方 Demo 很精彩，但要看懂它證明了什麼

Moonshot 展示了幾個極具話題性的案例，包括長時間 GPU Kernel 最佳化、48 小時完成小型晶片設計，以及在約兩小時內進行天體物理研究重現。相關案例涉及閱讀多篇論文、評估數百項狀態方程、產生數千行 Python 程式，或透過開源 EDA 工具完成晶片設計與驗證。

這些 Demo 最容易產生兩種極端解讀。

一種是：「AI 已經可以取代晶片工程師和科學家。」

另一種是：「這都是精心挑選的展示，沒有參考價值。」

我認為兩種說法都太快。

這些案例真正證明的，不是 K3 已經能獨立承擔完整專業職位，而是模型開始能在具備明確目標、可操作工具和可驗證回饋的環境中，持續完成數十小時的工作。

這個能力對產業非常重要。

因為許多知識工作並不要求模型第一次就答對，而是要求它能：

  1. 提出假設；
  2. 執行工具；
  3. 看結果；
  4. 找出錯誤；
  5. 修正方法；
  6. 重新執行；
  7. 最後交付成果。

這種迴圈，才是 Agent 從展示品走向生產力工具的關鍵。

Kimi K3 與 Claude Opus、GPT-5.6、GLM 5.2 效能比較

價格：比 Opus 便宜，但絕對不算廉價

K3 API 定價為每百萬 Token：

  • 快取命中輸入：0.30 美元；
  • 一般輸入：3 美元；
  • 輸出：15 美元。

Artificial Analysis 估算，K3 在其測試中的單任務成本約為 0.94 美元，接近 GPT-5.6 Sol 的 1.04 美元，低於 Claude Opus 4.8 的 1.80 美元；不過，它仍明顯高於 GLM-5.2 與 DeepSeek V4 Pro 等開放權重競品。

因此，「K3 很便宜」並不是一個準確的說法。

比較合理的說法是：

K3 用接近中高階閉源模型的價格，提供接近頂級閉源模型的能力。

這是一種旗艦定價，而不是開源福利價。

而且 K3 目前只有 Max 推理強度，推理模式長時間開啟，輸出 Token 又比輸入昂貴五倍。如果沒有良好的快取設計、上下文管理與模型分流策略，帳單很可能迅速上升。

企業真正合理的做法，不會是把所有請求都丟給 K3。

比較務實的架構是：

  • 簡單問答交給小模型；
  • 日常程式修改交給編程專用模型；
  • 長文件與跨領域任務交給 K3；
  • 只有最複雜、最需要長時間規劃的任務，才使用最高推理設定。

K3 更像是 AI 團隊中的資深架構師，不是每封郵件都要出席的執行長。

K3 和 GLM 5.2，誰是中國開放模型第一？

只看能力評測，K3 目前明顯領先。

Artificial Analysis 的資料顯示，K3 約為 57 分，GLM-5.2 約為 51 分；GDPval-AA v2 則是 K3 的 1668 對 GLM-5.2 的 1514。K3 權重已如期釋出，目前是能力最強的開放權重模型之一。

但企業選模型時，能力不是唯一問題。

還需要考慮：

  • 授權是否允許商業使用；
  • 是否有地域限制；
  • 能不能修改與再散布；
  • 是否容易在現有硬體部署；
  • 社群工具是否成熟；
  • 推理成本是否可控；
  • 供應商是否提供長期維護。

完整權重與正式授權已於 7 月 27 日公開。Kimi K3 License 允許使用、修改、部署與衍生開發，但 Model-as-a-Service 業務連續 12 個月總收入超過 2,000 萬美元時，商業使用前需另行與 Moonshot AI 簽約；超過 1 億月活或每月收入 2,000 萬美元的商業產品也有介面標示要求。

我的判斷是：

K3 贏在能力上限，GLM 5.2 暫時贏在部署現實。

對追求最強 Agent 能力的團隊，K3 很有吸引力；對需要立即私有化部署、法律條款清楚、成本可預測的企業，GLM 或其他較小模型可能更實際。

最強模型與最好用的模型，從來不是同一件事。

我對 K3 的五個看法

一、K3 是開放模型的里程碑，但不是開放模型的勝利

K3 證明開放權重模型可以進入前沿能力區間。

但閉源陣營沒有停止移動。Claude Fable 5 與 GPT-5.6 Sol 目前仍在部分綜合測試、輸出品質和完整產品體驗上領先；K3 比較接近「站到旁邊」，而不是「完成超車」。

真正的勝利，要看半年後是否有大量開發者基於 K3 做出微調、量化、工具鏈和企業產品。

開放權重只是發布行為，開放生態才是長期結果。

二、K3 的真正對手不是 GPT，而是整套 Claude 工作流

模型公司喜歡比較 Benchmark，但使用者不是在購買分數。

使用者購買的是一套可以工作的系統：模型、CLI、IDE、工具呼叫、檔案處理、記憶、權限、安全、除錯與團隊協作。

Moonshot 同步推動 Kimi Code，顯示它也理解：只賣一個模型 API 已經不夠。下一階段的競爭，不是 K3 能不能在某個程式測試贏 Claude，而是開發者願不願意把每天的工作環境搬到 Kimi 生態。

三、模型變強之後，稀缺資源會從「答案」轉向「驗收」

當模型可以連續工作 48 小時，人類真正缺少的可能不再是產出能力，而是驗證能力。

誰來確認晶片設計真的可製造？

誰來確認研究結果不是模型在錯誤假設上建立出一座漂亮建築？

誰來確認幾千行自動生成的程式，沒有埋下安全漏洞？

Agent 能力愈強，人類的角色愈不會消失，而是從「親手完成」轉向「定義標準、設計驗證與承擔責任」。

K3 如果真的讓長任務 Agent 普及，最先升值的能力，可能不是提示工程，而是測試、審核和風險管理。

四、100 萬 Token 會讓企業更容易犯下一個錯：以為資料塞進去就等於知識管理

企業看到長上下文，容易認為可以把所有文件都丟進模型。

但沒有整理過的制度、過期版本、互相矛盾的規範與缺乏權限標記的文件，放進 100 萬 Token 之後仍然是混亂，只是規模更大。

K3 可能降低資訊載入的技術門檻，卻不會替企業解決資料治理。

未來企業 AI 專案的差距，不只來自用了哪個模型，而來自誰擁有更乾淨的資料、更清楚的權限，以及更可靠的驗收流程。

五、K3 最大的風險不是模型不夠強，而是它太難被廣泛部署

2.8 兆參數讓 K3 取得了能力與行銷上的雙重優勢，也帶來龐大的部署難題。

如果一般企業最終仍只能透過 Moonshot API 使用，而無法有效私有化部署，那麼它的「開放權重」價值就會比較偏向雲端供應商、國家級研究機構與大型科技公司，而不是普遍的開發者民主化。

因此，7 月 27 日之後真正值得看的，不只是誰成功下載模型，而是：

  • 社群能否做出可用的量化版本；
  • vLLM 等框架多久能完整支援；
  • 部署需要多少張 GPU；
  • 稀疏 MoE 的跨卡通訊效率如何；
  • 精度下降能否控制；
  • 授權是否真的允許廣泛商用。

這些答案，會決定 K3 是一場產業革命，還是一座只有少數人能進入的技術地標。

結論：K3 沒有終結閉源模型，但終結了一種想像

Kimi K3 尚未全面擊敗 Claude，也沒有讓 GPT 失去競爭力。

它的 API 不便宜，完整權重雖已釋出，但 2.8 兆參數的部署門檻、Kimi K3 License 的商業條件，以及產品穩定性仍需要納入評估。

但它已經完成了一件很重要的事：

K3 終結了「頂級 AI 能力必然只存在於封閉平台」的想像。

過去，閉源模型的優勢建立在明顯的能力差距上。當這個差距縮小到幾分，競爭規則就會改變。

企業會開始問：

  • 為什麼要支付更高的閉源溢價？
  • 為什麼不能保留自己的資料與模型控制權？
  • 為什麼不能同時使用多家供應商？
  • 為什麼模型不能像資料庫一樣被替換？

而閉源廠商也必須拿出比「模型比較聰明」更完整的答案。

我的最終判斷是：

K3 不是開源擊敗閉源的那一刻，而是開源取得上桌資格的那一刻。

它最大的成就不是排行榜第三，也不是 2.8 兆參數，而是讓整個產業第一次認真思考：如果最強模型不再只能由少數美國公司控制，那麼下一個 AI 平台的主導權，究竟會落在誰手上？

答案還沒有出現。

但從 K3 開始，這已經不再是一場只有 OpenAI、Anthropic 和 Google 能參加的比賽。

FAQ

Q：K3 跟 Opus 4.8 誰強？

整體智力 Opus 4.8 在 AA 榜上靠 Fable 5 兜底排更前，但 GDPval 實戰 Elo K3（1668）贏 Opus 4.8（1600）。結論：K3 在 agentic 知識工作壓過 Opus 4.8，整體略輸閉源頂尖。

Q：K3 跟 GLM 5.2 差在哪？

智力 K3 贏（AA 57 vs 51），但 GLM 5.2 是純 MIT 授權、無地域限制，拿到手更無顧慮。兩個是中國開源雙雄，打不同位置。

Q：個人電腦跑得動嗎？

基本不行，2.8 兆要大規模 GPU 叢集。先用 API 是現實路徑。

Kimi K3 權重已經發布了嗎？

已發布。Moonshot AI 已於 2026 年 7 月 27 日釋出完整模型權重，並同步公布 Kimi K3 License。權重可從官方 GitHub 與 Hugging Face 取得，但 2.8 兆參數模型的儲存及推論需求極高，不適合一般個人電腦部署。

 

Kimi K3 官方資料與延伸閱讀

讀書心得
|

職場聚會的警惕心：越熱鬧，越要記得自己為什麼在場

你有沒有那種時候，自己一個人待在某個地方，忽然覺得怪怪的，說不上來哪裡不對，就是渾身不自在？

最近聽到一段老話，挺有意思的。

郭德綱講的：「一人不逛廟，二人不看井，三人不抱樹。」

一個人別去廟裡閒晃，因為宗教場合會把你心裡那種很超越的情緒叫醒，但旁邊沒人可以幫你消化，越逛越慌。

兩個人別一起湊到井邊，萬一對方起歹念，你連跑都跑不掉。

三個人別一起抱樹玩兒，兩個外人要聯手欺負一個，那可太容易了。

聽起來像江湖故事對吧？老一輩的怪談。

但你再琢磨一下，這三件事有一個共通點：都在「玩」。

人只要進入玩的狀態，警覺心就掉下來。掉下來的那一刻，最容易被趁虛而入。

職場上也一樣。

所謂警惕心，不是對人不信任，是認清「玩」與「被玩」的界線。

開會聊到一半氣氛很鬆，主管突然丟出一句「你覺得呢」——這時候你的腦袋可能正想著中午吃什麼。

團隊出去玩，喝酒唱歌很開心，有人在這個時候聊你明年的績效——你以為他在開玩笑，他其實在試探。

跟客戶吃飯，對方笑著講了一句「你們的報價比 A 家貴兩成」——你以為是閒聊，他其實在等你讓步。

每一個讓你卸下防備的場景，都藏著別人丟出來的訊號。

那怎麼辦？

老話給的答案簡單到不行：別在「玩」的時候做重要決定。

一句話判斷：當下氣氛越鬆，你越要記得，這是別人選的時間點。

鬆，是刻意的。

你以為的閒聊，可能是一場精心挑過時間的試探。

警惕心不是冷漠，是把腦袋留在「玩」之前，別讓它跟著身體一起放假。

今天開始，提醒自己一件事：

越熱鬧的場合，越要記得自己為什麼在場。

職場聚會為什麼容易失去警覺？

人在喝酒、聊天或團隊出遊時，會自然降低防備，但職場角色並不會因為氣氛輕鬆就消失。主管的隨口一問、同事的八卦與客戶的玩笑，都可能是在確認你的立場與底線。

遇到試探時怎麼判斷？

  • 主管提問：先確認他要的是想法、承諾，還是責任歸屬，不要在放鬆狀態下隨口接下工作。
  • 同事八卦：不評論不在場的人，也不要把未確認資訊當成交換信任的籌碼。
  • 客戶議價：先問比較基準與範圍，不要因為一句「別家比較便宜」就立即讓價。

職場警惕心常見問題

保持警惕是不是代表不信任同事？

不是。警惕心是分辨場合、角色與資訊邊界，不是預設每個人都有惡意。

主管在聚會中問工作，應該怎麼回答？

可以先給方向，不要在資訊不足時承諾時程、預算或責任；隔天再用正式訊息確認彼此理解。

客戶用玩笑方式砍價怎麼辦？

先把玩笑轉回條件討論，確認規格、交付與比較基準，再決定是否調整方案。

延伸閱讀

團隊在壓力下如何維持信任，可延伸閱讀 危機管理與共享柔軟。

讀書心得
|

AI Agent 實戰：你的專案真的需要 Multi-Agent 嗎？從 Hermes Agent 經驗看生產級部署

當你打開 Hacker News 或 GitHub Trending，幾乎每個討論串的熱點都是一個新的 Agent 框架。大家都在討論 Multi-Agent、Agent Orchestration，彷彿這已經成為 AI 應用開發的黃金標準。

市場上充斥著大量「Agent 框架」的介紹，從 LangGraph 到 AutoGen，每個框架都宣稱能解決「複雜問題」。但如果你是一位真正負責生產級部署（Production-Grade）的工程師，你一定會意識到一個事實：大部分的討論和 Demo，都停留在「看起來很複雜」的層面，而不是「真正能穩定運行」的層面。

這篇文章不是來比較哪個框架最好，更不是另一篇充滿過度工程（Over-Engineering）的理論文章。

我會從我在 Hermes Agent 實戰的經驗出發，帶你走過一個從「懷疑 Multi-Agent 的存在價值」到「理解其精準應用場景」的決策過程。

核心問題是：你的 Use Case，真的需要 Multi-Agent 這種複雜架構嗎？

在閱讀之前，請先記住我的觀點：Multi-Agent 是一個極度強大的工具箱，但它絕對不是萬靈丹。盲目導入，只會讓你的專案複雜度指數（Complexity Score）飆升，但實際價值卻為零。

Multi-Agent 的迷思與現實：何時是解方，何時是陷阱？

在深入技術細節之前，我們必須先釐清一個概念：什麼是 Multi-Agent，以及它在實際生產環境中，到底能帶來什麼。

🤖 什麼是 Multi-Agent 系統？

從定義上來說，Multi-Agent System (MAS) 就是讓多個具有特定角色（Role）和目標（Goal）的獨立 AI 實體，互相溝通、協作，共同完成一個單一的複雜任務。

它的潛在優勢非常明顯：

  1. 任務分解 (Task Decomposition)： 將一個大問題拆解成多個可管理的子任務。
  2. 角色分工 (Role Specialization)： 每個 Agent 專精於一個領域（例如：一個負責資料擷取，一個負責語義分析，一個負責最終報告生成）。
  3. 魯棒性提升 (Robustness)： 即使某個子任務失敗，整個系統也不會崩潰，可以進行重試或降級處理。

⚠️ 陷阱警訊：過度工程的誘惑

然而，業界的 hype 往往會讓我們忽略一個關鍵的工程原則：Keep It Simple, Stupid (KISS)。

我觀察到許多團隊在 Demo 階段，會傾向於「為了讓架構看起來很酷」，而將 Multi-Agent 導入，即使單一 Agent 已經能達到 80% 的業務目標。這就是典型的「過度工程」。

生產環境與 Demo 環境的巨大鴻溝：

  • Demo 環境： 只需要一個「流程圖」能跑通，即使背後邏輯是硬編碼的。
  • 生產環境： 必須考慮到延遲、成本、錯誤邊界、上下文同步，以及最難的——可維護性 (Maintainability)。

如果你的 Use Case 只是「根據用戶輸入，生成一篇標準化的產品介紹文」，你真的需要讓它由「研究 Agent」、「寫作 Agent」和「審核 Agent」三方協作嗎？

我的經驗判斷是：如果單一 Agent 已經能達到 80% 的準確度，那麼 Multi-Agent 引入的 20% 複雜度，很可能導致整體系統的準確度反而下降。

Hermes Agent 的實戰經驗：Multi-Agent 何時真正發光？

既然 Multi-Agent 這麼容易被誤用，那它在什麼場景下，才是真正能發揮「生產級」價值的呢？

我必須分享我在 Hermes Agent 系統架構中的實戰經驗。我們沒有用 Multi-Agent 來做簡單的問答，而是用它來處理高度複雜、多步驟、需要平行資源調度的任務。

這讓我體會到 Multi-Agent 真正發光的，是「協調」和「擴展性」。

🚀 模式一：Dispatching-Parallel（平行任務調度）

這是 Multi-Agent 最直接的應用，核心是「同時處理多個獨立的子任務」。

想像一個複雜的市場分析報告，它不能線性生成。它需要同時完成以下幾件事：

  1. 數據擷取 (Data Fetching Agent)： 從 API A 抓取最新的銷售數據。
  2. 情緒分析 (Sentiment Agent)： 從 API B 抓取社交媒體的輿情報告。
  3. 競爭者分析 (Competitor Agent)： 從 API C 抓取競品的新產品發布資訊。

如果用單一 Agent，它必須依序執行：抓取 $\rightarrow$ 分析 $\rightarrow$ 抓取 $\rightarrow$ 分析… 整個過程會被最慢的步驟拖垮。

Multi-Agent 的優勢：

  • 效率提升： 系統可以同時發出三個並行的 API Call，等待所有結果集齊後，再交由一個中央 Orchestrator Agent 進行彙整和總結。
  • 資源利用率： 確保系統的 I/O 資源是飽和利用的，而不是等待單一步驟的完成。

實戰價值： 任何需要「多源異質數據」並「時間敏感」的報告生成流程，都是這個模式的理想場景。

🛠️ 模式二：Subagent-Driven-Development（子智能體驅動開發）

這模式的重點已經從「執行任務」轉移到了「構建系統」。

當你的產品功能越來越複雜，單一 Agent 的 Prompt 和邏輯就會變得極度龐大，難以維護。Subagent-Driven 模式的思路是：將產品的每一個核心功能，都獨立成一個可插拔的子 Agent。

例如，一個企業級的內容生成平台：

  • [Agent A] 負責「SEO 關鍵字優化」： 接收主題，輸出 5 個高潛力關鍵字清單。
  • [Agent B] 負責「Tone & Voice 調整」： 接收文稿和目標受眾，調整語氣（例如：從學術轉為口語化）。
  • [Agent C] 負責「格式化與排版」： 接收純文字，輸出 Markdown 或 HTML 格式。

Multi-Agent 的價值體現：

  1. 模組化與可維護性： 當 SEO 規則改變時，你只需要更新 Agent A 的 Prompt，而不用碰 Agent B 或 C 的邏輯。這極大地降低了開發和維護的門檻。
  2. 可擴展性： 想要增加一個「圖片生成」功能？你只需要新增一個 Image Agent，並在中央 Orchestrator 中增加一個調度步驟，整個系統的擴展成本極低。

總結來說，當你的專案從「一個一次性的腳本」進化成「一個需要長期迭代、功能不斷增加的產品線」時，Multi-Agent 才是真正能帶來生產級價值的地方。

單一 Agent 反而更好？Multi-Agent 的隱藏成本與痛點

如果 Multi-Agent 這麼好，為什麼我會強調它有陷阱？因為從工程師的角度看，它帶來的複雜度，往往是「隱形的成本」。

這部分是我們必須用批判性思維來審視的。

📉 成本一：協調與通訊的複雜性（The Orchestration Overhead）

Multi-Agent 的核心難點不在於讓 Agent 跑起來，而在於「如何讓它們協調得像一個真正的團隊」。

你必須設計一套複雜的通訊協定（Communication Protocol）：

  • Agent A 輸出的格式，是否能被 Agent B 準確地解析？
  • 如果 Agent B 失敗了，是讓 Agent C 嘗試修復，還是直接回報給用戶？
  • 誰是最終的決策者？（Orchestrator 的權限邊界在哪裡？）

這些協調邏輯，往往需要大量手動的狀態機（State Machine）編寫，這才是開發者心智負擔的來源。

🧠 成本二：上下文管理與膨脹（Context Bloat）

這是目前所有 LLM 應用最普遍的痛點，Multi-Agent 只是讓它更糟。

當多個 Agent 輪流處理一個任務時，它們的上下文（Context）必須不斷地被傳遞、合併、修剪。

  • 上下文共享的難點： 每個 Agent 只能看到它需要的資訊，但如果資訊是分散的，誰來負責將這些分散的「知識點」彙整成一個完整的、不重複的上下文？
  • 上下文膨脹 (Context Bloat)： 每次協作都會增加輸入 Token。如果沒有精準的 Context Management 機制，輸入的 Token 會不斷膨脹，導致：
    1. 成本暴增： API 費用直接跟著 Token 數掛鉤。
    2. 效能下降： LLM 處理過長上下文時，容易出現「迷失在中間」（Lost in the Middle）的現象，導致模型忽略關鍵資訊。

🐛 成本三：調試與監控的噩夢（Debugging Nightmare）

當單一 Agent 報錯時，你只需要看一個 Stack Trace。

當 Multi-Agent 報錯時，你必須追蹤一個「跨越多個服務、多個 API Call、多個 Agent 決策點」的流程。

你必須問：

  • 是 Agent A 的 Prompt 寫錯了？
  • 還是 Agent B 接收到的資料格式有誤？
  • 還是中央 Orchestrator 在判斷流程時，誤判了任務順序？

這極大地提高了開發和維護的複雜度，讓原本應該是「快速迭代」的開發週期，變成了「複雜的跨元件整合測試」。

💡 決策樹：判斷你的專案是否需要 Multi-Agent

在閱讀了這些陷阱和實戰經驗之後，我為你整理了一個實用的決策流程。請用這套問題清單，來評估你的 Use Case。

這不是一個「是/否」的答案，而是一個「程度」的評估。

📋 步驟一：任務分解度評估（Task Decomposition）

  • 問題： 你的任務是否可以自然地、邏輯性地拆解成 3 個以上，且彼此獨立的子步驟？
    • ✅ 是： 進入步驟二。
    • ❌ 否（例如：簡單的分類、摘要）： 停留在單一 Agent 即可。

📋 步驟二：資源依賴性評估（Resource Dependency）

  • 問題： 這些子步驟是否需要依賴不同類型的外部資源或知識庫？
    • 例如：需要同時調用「即時 API 數據」+「內部知識庫」+「用戶歷史行為數據」。
    • ✅ 是： 進入步驟三。
    • ❌ 否（例如：只依賴一個大型知識庫）： 單一 Agent 搭配 RAG (Retrieval-Augmented Generation) 即可。

📋 步驟三：處理模式評估（Execution Mode）

  • 問題： 這些子步驟是否必須平行、同時進行，以達到效率最大化？
    • 例如：同時分析 A 產品和 B 產品的市場反應。
    • ✅ 是： 強烈建議考慮 Multi-Agent (Dispatching-Parallel)。
    • ❌ 否（必須按順序執行）： 考慮單一 Agent 搭配複雜的 State Machine 邏輯。

🎯 結論總結：

判斷結果 建議架構 適用場景範例 關鍵提醒
簡單單一流程 單一 Agent (Single Agent) 內容摘要、問答機器人、單一格式轉換。 專注於優化 Prompt 和 RAG 檢索。
複雜流程，順序性 單一 Agent + State Machine 複雜的表單填寫、多步驟工作流（如：先驗證 $\rightarrow$ 後提交）。 核心邏輯應由程式碼（Code）控制，而非 LLM 決策。
多源異質，平行處理 Multi-Agent (Orchestration) 市場報告生成、跨系統數據分析、複雜決策模擬。 必須從「協調機制」入手，而非「Agent 數量」。

從框架選擇到生產部署：哪些真的 Ship 了？

當你決定了需要 Multi-Agent 之後，下一步就是選擇工具。市場上充斥著 LangGraph、CrewAI、AutoGen 等框架，這很容易讓人陷入「框架選擇焦慮」。

但請記住，我們不是在比較哪個框架的 API 最漂亮，我們是在尋找「最能穩定運行、最容易維護」的生產級工具。

🏗️ 框架選擇的黃金準則：穩定性 > 功能豐富度

在選擇框架時，請將注意力從「它支援多少種 Agent 類型」轉移到以下三個維度：

  1. 狀態管理 (State Management)： 框架是否提供一個清晰、可追蹤的中央狀態（Global State）？這決定了你在 Debug 時能否知道「現在系統處於哪一步，擁有哪些資訊」。
  2. 可擴展性 (Extensibility)： 它是否允許你在核心流程外，輕鬆地插入自定義的、非 LLM 的程式碼邏輯（例如：一個外部的資料庫查詢函數）？
  3. 部署成熟度 (Deployment Maturity)： 框架是否已經有成熟的容器化、監控和服務化部署的範例？

🔮 未來的趨勢：沙盒式編排平台 (Sandboxed Orchestration)

我觀察到一個更宏觀的趨勢，那就是從「程式碼定義流程」轉向「低代碼/無代碼的沙盒式編排平台」。

這類平台（例如 Hacker News 討論的 SuperHQ 概念）的價值，在於它將「流程定義」從 Python 程式碼，提升到了更接近「流程圖」的視覺化層面。它讓非 AI 工程師的 PM 或業務分析師，也能夠參與到流程的定義和調整中。

這代表著 Multi-Agent 的未來，會越來越傾向於「流程的視覺化定義」，而不是「程式碼的硬編碼」。

💡 我們的 Builder 視角：工具是為問題服務的

無論市場上出現什麼新的框架，我們作為 Builder 的心態必須是：永遠不要為了解決不存在的問題而增加複雜度。

先用最簡單的單一 Agent 跑通核心業務流程 $\rightarrow$ 遇到性能或模組化瓶頸 $\rightarrow$ 評估是否需要 Multi-Agent。

這個「問題驅動 (Problem-Driven)」的開發思維，才是決定專案成敗的關鍵。

總結：從複雜到精準，才是生產級的體現

回顧整個流程，我們可以得出一個非常明確的結論：

Multi-Agent 系統的強大，在於它模擬了「專業團隊」的協作模式。但這份強大，是以極高的「協調成本」和「維護複雜度」為代價的。

記住這三點：

  1. 先懷疑，再導入： 每次遇到複雜問題，都先用單一 Agent 跑一遍，如果能達到 80% 的準確度，先用它。
  2. 關注邊界，而非數量： Multi-Agent 的價值不在於 Agent 的數量，而在於你定義的「Agent 之間的邊界和協作協議 (Protocol)」是否精準。
  3. 從流程圖開始思考： 永遠從「這個任務的流程圖是什麼？」開始，而不是「我該用哪個 Agent 框架？」

生產級的 AI 應用，不是堆砌最先進的技術，而是用最精準的架構，解決最核心的業務痛點。

 

Multi-Agent 常見問題

什麼情況適合使用 Multi-Agent？

任務可以切成彼此獨立、輸入輸出清楚、能單獨驗收的工作時，Multi-Agent 才能真正換到平行效率。

為什麼 Multi-Agent 比較難除錯？

問題可能發生在任務切割、上下文傳遞、工具權限、執行順序或結果整合；如果沒有完整紀錄，很難判斷錯誤由哪一個 Agent 造成。

單一 Agent 何時更好？

任務高度依賴同一份上下文、步驟必須連續推進，或協調成本高於平行收益時，單一 Agent 通常更穩定。

延伸閱讀

讀書心得
|

OpenClaw 自動發文測試

這是一篇由 OpenClaw 透過 SSH + wp-cli 自動發布的測試文章。如果看到這行代表發文通道已暢通。

讀書心得
|

AI 長任務時代來了：真正該升級的不是工具，而是你的工作流

一句話結論

AI 長任務時代的核心不是工具變強，而是任務邊界變長；真正需要升級的是拆任務、驗證、交接與回收結果的工作流。

AI 長任務工作流的拆解、驗證、交接與結果回收

我現在看到新的 AI 新聞，第一反應已經不是「這模型多強」。

這句話放在兩年前，我自己大概也不相信。那時候每次模型升級，大家都在比誰回答更順、誰寫程式更快、誰的 benchmark 又往上爬了幾分。那當然重要，但看久了會有一種疲勞感：demo 都很漂亮，真的接進工作裡，常常又回到一個老問題。

它到底能不能交付？

不是回答一段，不是幫你整理一張表，也不是在會議上看起來很聰明。我的意思是，你晚上把一件麻煩事交給它，隔天早上回來，它能不能把做了什麼、改了什麼、哪裡失敗、哪裡需要你拍板，整整齊齊放在桌上。這個門檻比「會聊天」高太多了。

這幾天剛好有三個訊號撞在一起。Anthropic 推 Claude Fable 5，Stripe 測了 5,000 萬行 Ruby codebase 的遷移案例；Anthropic 也在強化 Services Track 和 Partner Hub，把 AI 服務商往「真的部署過」這條線上拉；另一邊，Search Engine Land 開始更認真談 GEO，因為 AI 搜尋正在改變內容被看見的方式。

表面上是三條新聞。我看到的是同一條線：AI 正在離開「單次回答」的階段，開始逼我們面對工作流本身。

長任務的重點，不是模型終於變勤勞了

Stripe 那個 5,000 萬行代碼遷移案例很容易讓人興奮。一天完成原本可能要整個團隊兩個多月手工處理的事，這種對比太好傳播了，也太容易被拿去做簡報。

但我不太想把焦點放在「一天 vs 兩個月」。那是結果，不是本質。

真正有趣的是，這類模型如果開始能承受長上下文、長時間執行、跨檔案推理，它就不再只是回答問題的工具。它開始像一個可以被委派一段責任的人。這裡的差別很大。以前你問 AI 一段，它答一段；你叫它改一個檔案，它幫你改；你給它一個稍微複雜的任務，它可能前面看起來都懂，後面突然忘記約束，順手把不該動的地方也動了。

那種感覺很熟悉。像把任務交給一個很熱情、很會講話、但沒有交付紀律的實習生。你以為自己省了時間，結果更多時間都花在檢查、補洞、回滾。

長任務模型真正改變的地方，是我們終於可以開始問比較嚴肅的問題：它能不能維持任務邊界？遇到錯誤會不會停下來？交付物能不能讓下一個人接手？它有沒有留下足夠的驗證紀錄？

這些問題聽起來一點都不性感，卻比 benchmark 更接近真實工作。

長任務的價值，不是 AI 終於可以多做一點，而是它開始能承擔一段完整責任。

麻煩也在這裡。當 AI 真的開始能跑長任務，你就不能再用一句模糊指令把責任丟出去。你要先講清楚什麼叫完成，什麼叫不能碰，什麼情況要停，什麼結果算失敗。你如果自己都沒有這套標準，AI 只會把你的混亂放大，然後用更漂亮的語氣包起來。

這也是為什麼我現在越來越不迷信「神 prompt」。

prompt 可以讓你得到一個好回答，但工作流才會讓你得到一個可交付的結果。

AI 顧問市場會被重新切開

第二個訊號是 Anthropic 的 Services Track 和 Partner Hub。

這件事我覺得很合理，甚至有點晚了。過去一年，市場上太多人把「會用 AI」包裝成「會導入 AI」。這兩件事差太遠了。

會用 AI，是知道怎麼問、怎麼調 prompt、怎麼接 API。這本身沒問題，也確實有價值。

可是會導入 AI，是另一個層級。你要知道資料從哪裡來，權限怎麼切，流程卡住時誰接手，輸出錯了怎麼發現，出事怎麼回滾，半年後模型換了又怎麼維護。

中間隔著一整條工程和營運的溝。

很多包裝型顧問最怕的不是客戶問「你們模型多強」，而是問幾個很無聊的問題：上線案例在哪？失敗怎麼處理？交付後誰維護？如果原本負責的人離職，這套系統還能不能跑？

通常問到這裡，簡報就開始變安靜。

這不是刻薄。這是 AI 走進長任務之後，市場自然會發生的分層。以前大家買的是新鮮感，覺得有一個聊天機器人接在公司資料庫上就很厲害。接下來大家會買的是上線能力。誰能把資料、權限、流程、驗證、維運接起來，誰才是真的服務商。

包裝會越來越便宜，能把流程接起來的人會越來越貴。

這件事對個人也一樣。你不一定要把自己包裝成 AI 專家。比較值得做的，是把你已經熟的工作拆成可交付流程。你知道輸入是什麼，輸出長什麼樣，怎麼驗證，出了錯先看哪裡。這種能力不花俏，但它會變得越來越值錢。

因為模型變強之後，真正稀缺的反而不是「誰比較會問 AI」，而是誰能把一件混亂的工作，整理成 AI 接得住的形狀。

GEO 其實是在提醒我們：內容也要能被交付

第三個訊號是 GEO。Generative Engine Optimization，生成式引擎優化。

老實說，這名字聽起來很像行銷圈又發明了一個新縮寫。以前我看到這種詞，通常會先皺眉。SEO 已經夠多人講得很玄了，現在又多一個 GEO，很容易讓人以為只是換個包裝繼續賣課。

但這次我不太敢直接忽略。

因為搜尋行為真的變了。以前你寫文章，是希望使用者在 Google 搜尋結果看到你，點進來，慢慢讀。現在越來越多情境是，使用者在 Perplexity、ChatGPT 或 Google AI Overviews 看完摘要就走了。你辛苦寫的內容，可能不再以「被點擊」的形式出現在讀者面前，而是被 AI 摘成幾句話，再塞進答案裡。

這裡的問題很刺耳：你的內容有沒有資格被引用？

排名和引用不是同一件事。排名是在搜尋結果裡搶位置，引用是在答案裡搶信任。SEO 很在意標題、關鍵字、內鏈、頁面權重；GEO 更在意你的內容能不能被機器理解、抽取、重組，而且不要被講歪。

所以我現在看一篇技術文章或產品頁，會多一層檢查。標題下面有沒有直接回答問題？重要數字是不是藏在一大段情緒文字裡？規格、限制、適用情境有沒有講清楚？如果 AI 只抓其中三句，會不會抓到最容易誤解的部分？

這對寫作者不舒服。因為它代表文章不只要讓人讀起來順，還要讓機器讀得懂。人類可以靠上下文補意思，機器常常只會抓最明顯、最結構化、最像答案的那幾句。

但換個角度看，這也是機會。

大多數人還在用舊 SEO 的方式堆字，拼命拉長篇幅、塞關鍵字、做一堆看起來很完整但其實很難抽取的段落。願意把答案前置、限制講清楚、資料放在可引用位置的人，反而更容易在 AI 摘要層被當成可靠來源。

未來的內容，不只寫給讀者看，也寫給會替讀者做摘要的機器看。

這句話聽起來有點冷，但讀者本來就不欠你點擊。你真正要爭取的，是在他需要答案的那一刻，你的內容會不會被拿出來當作可信來源。

三件事合在一起，其實是在講同一個標準

把 Fable 5、Services Track、GEO 放在一起看，主線就很明顯了。

AI 不再只獎勵會展示的人。它開始獎勵會交付的人。

模型端是這樣。你不能只看它回答得多漂亮，要看它能不能跑完長任務。服務端是這樣。你不能只看顧問講得多新潮，要看他有沒有上線與維運能力。內容端也是這樣。你不能只看文章讀起來多完整，要看它能不能被機器正確引用，能不能在摘要時代繼續替你建立信任。

所以我現在判斷一個 AI 趨勢，會先問一個很土的問題：它有沒有讓某件事更容易被交付？

如果沒有，那多半只是熱鬧。熱鬧不是不能看，但不要把它放進你的核心工作流。你的時間沒那麼便宜。

如果有，那才值得花力氣。因為它可能改變的不只是效率，而是責任怎麼被分配、工作怎麼被驗證、內容怎麼被重用。

這也是為什麼實用主義者反而會在這波裡佔便宜。不是因為我們比較懂模型，而是因為我們不把模型當魔法。我們比較習慣問那個無聊但關鍵的問題：接上去之後，明天早上真的會少一個坑嗎？

我會先改的不是工具，而是任務本身

如果你現在也在看這波 AI 變化，我不建議你立刻去追每一個新工具。那會很忙，也很容易產生一種虛假的進步感。今天試一個模型，明天換一個 Agent，後天又研究一套 workflow builder。忙了一圈，真正麻煩的工作還是原樣躺在那裡。

我會先挑一件自己真的很煩、而且每次都要花時間收拾的長任務。不是「幫我寫一篇文章」這種乾淨任務，而是有資料、有例外、有驗證、有重工成本的工作。像整理舊內容、清理資料表、把一批文件轉成統一格式，或檢查網站上哪些頁面不適合被 AI 摘要引用。

然後把它寫成四件事：輸入是什麼，輸出長什麼樣，怎麼驗證，失敗時怎麼停。

這一步很笨，但很有效。你寫完就會發現，有些工作其實可以交給 Agent，有些工作只是你自己還沒想清楚。後者不能急著自動化，因為自動化只會讓混亂跑得更快。

至於 AI 服務商，我會少聽願景，多問交付。上線案例在哪？錯了怎麼回滾？誰維護？這幾個問題問完，大概就能篩掉一大半只會包裝的人。

內容也是一樣。別急著把全站文章都改成 GEO 模板。先挑最能代表你專業的五篇文章，重新看一遍：讀者一進來能不能馬上拿到答案？AI 摘要抓三句會不會抓歪？限制條件有沒有講？如果這篇文章被機器拿去回答別人的問題，你會不會放心？

這些事都不炫。但會留下資產。

冷靜講，這波 AI 洗牌不會先淘汰不懂 AI 的人。它會先淘汰把 AI 當魔法的人。

因為長任務、服務商認證、GEO 這三件事，都在把我們推回同一個現實：工具本身不會替你建立系統。你要先把工作整理成可重複、可驗證、可交付的形狀，工具才真的有地方發揮。

今天可以做一個很小的版本。

找一件你下週本來就要做、而且有點討厭的重複任務。不要急著問 AI 能不能改變世界。先問它能不能接其中一段，留下結果，講清楚風險，幫你少踩一個明天早上會爆的坑。

如果可以，這才叫進步。

常見問題

什麼是 AI 長任務？

AI 長任務是指 AI 可以跨多步驟、長時間處理目標，但仍需要清楚輸入、檢查點與人類驗證。

為什麼不是再換一個 AI 工具就好？

工具能力提升只能放大流程品質；如果任務拆解、驗證和交接混亂，長任務只會把錯誤累積得更遠。

個人工作流第一步該改什麼？

先把任務改成可交付、可驗證、可中斷回收的格式，而不是把完整目標一次丟給 AI。

延伸閱讀

課程筆記
|

危機時刻別再喊「衝啊兄弟們」：團隊真正需要的是「共享柔軟」

一句話結論

危機時刻真正能穩住團隊的不是口號，而是讓人承認脆弱、同步現況、一起承擔下一步的共享柔軟。

我之前帶過一個團隊，活動上線前一週出了大問題，連續三天凌晨三點還在改方案。到第四天早上，我頂著兩個黑眼圈召集大家開會，第一句話就是：「各位辛苦了，我們一定可以度過難關！」然後豎起大拇指，喊了句：「衝啊兄弟們！」

結果呢？氣氛比修 bug 還僵。幾個同事面面相覷，眼神裡明明白白寫著一句話：「老闆，你到底有沒有搞清楚現在的狀況？」

那場會散得很快。當天下午我一個人坐在會議室，才慢慢想明白一件事——我那句「衝啊兄弟們」，根本不是在激勵團隊，是在安慰我自己。我撐不住了，所以我需要喊一句聽起來很有力量的話，來蓋過心裡那個「萬一真的搞不定怎麼辦」的聲音。

後來我重讀湯君健《怎樣成為帶團隊的高手2.0》，第九講那段「非常時期的凝聚力打造」直接戳到我。他講的東西，跟我那天在會議室裡學到的，是同一件事。

危機管理中領導者與團隊坦白現況、共同承擔下一步

為什麼你越喊口號，團隊散得越快

多數管理者在危機時的第一反應，是撐場面、表現得像個無堅不摧的 leader。這幾乎是本能。但湯君健觀察過大量團隊後給出一個反直覺的結論：這種做法不只沒用，還會在你看不見的地方慢慢侵蝕團隊對你的信任。

原因其實很簡單——硬撐是一種情緒表演，而你的團隊感受得到。

你站在台上喊「我們一定可以」，心裡卻在算「萬一不行，我的退路在哪」。這種嘴上跟心裡對不上的矛盾，員工不是看不出來，他們只是沒說。而當一個 leader 拼命表現堅強，團隊通常會解讀成兩件事：第一，「他不信任我們能承受真相」；第二，「他想替我們把恐懼隔離掉」。前者讓人覺得有距離，後者讓人覺得被當小孩。兩者加起來，信任就開始漏。

你以為自己在穩定軍心，團隊看到的是你在演一齣連你都不信的戲。

我見過最極端的案例，是一個 startup 的 CEO 在裁員前一晚開全公司大會，全程笑著說「大家放心，我們現金流很健康」。隔天員工打開信箱，看到 HR 排好的資遣名單。整間公司的信任，在二十四小時內崩光。那不是裁員本身的傷害，是「你昨天還在騙我」的傷害——而後者，遠比前者致命。

「共享柔軟」到底是什麼

湯君健在第九講裡提出一個概念，叫「共享柔軟」。老實說，我一開始以為又是哪種心靈雞湯，準備跳過。後來認真讀進去才發現，這可能是我看過最反直覺、也最管用的危機領導策略。

共享柔軟的核心，講白了就一句話：願意把訊息透明化，讓團隊清楚知道「最壞的情況是什麼」。

你可能會問，這不就是把壞消息說出來而已嗎？差別在哪？

差別大了。把壞消息丟出來，很多時候是「公司快倒了，大家自求多福」——這是甩鍋。共享柔軟則是另一種姿態：「我們正面臨挑戰，但我願意跟你說清楚，這是我們現在的狀況，這是我們手上的選項，這是我打算跟你一起扛下去的決心。」前者是把球丟給員工，後者是邀請員工進來一起看牌。

湯君健在課程裡舉了西貝的例子。西貝的創辦人賈國龍曾經把帳本直接翻給員工看，坦白現金流只剩三個月。他不是要大家趕快跳船，而是要讓每一個人心裡有底——我們的處境是什麼、子彈還剩多少、最壞會走到哪一步。這個「翻帳本」的動作，就是共享柔軟最精準的示範。

所以示弱從來不是情緒發洩，也不是投降，而是「我願意跟你說實話」的一種姿態。團隊不需要你的表演，需要你的真實。你以為他們想看一個永遠不倒的英雄，其實他們只想知道，眼前這個人到底有沒有把他們當自己人。

示弱跟甩鍋，界線到底在哪

很多人一聽到「示弱」就本能性地抗拒，覺得那是把自己擺到弱勢的位置。會這樣想，通常是還沒搞清楚示弱跟甩鍋的差別。

湯君健在課程裡把這兩件事切得很乾淨：示弱是一種邀請，甩鍋是一種逃避。我自己帶團隊這幾年，把它再濃縮成三條可以當場拿來判斷的界線。

第一條，看訊息的方向。示弱是「我願意跟你說實話」，把資訊攤開給團隊；甩鍋是「這不是我的問題」，把責任往外推。同樣是承認狀況不好，一個是在分享，一個是在卸責，員工分得出來。

第二條，看有沒有方向感。示弱永遠帶著下一步——「這局很難，但我們手上還有 A 選項和 B 選項，我傾向先試 A」；甩鍋則是把人丟在原地——「我也不知道該怎麼辦，你們自己看著辦吧」。有沒有給出路，是示弱跟放棄之間那條最清楚的線。

第三條，看領導者站著還是躺平。你完全可以在團隊面前承認「我也很擔心」，這不丟臉。但你不能讓團隊感覺到「這盤已經爛了，老闆比我們還想跑」。示弱是領導者仍然站著伸出手，甩鍋是領導者自己先躺平。差一個動作，意思就整個顛倒。

實話，到底要攤到什麼程度

好，假設你被說服了，願意說實話了。下一個問題馬上來——實話要說到哪個層次？全抖出來會不會嚇到團隊？藏一半算不算又在演戲？

湯君健的框架在這裡幫了我大忙，我把它整理成由淺到深的三個層次。

最表層的是事實透明。發生了什麼事、現況如何、數據是多少，照實講，不包裝也不淡化。團隊成員不是傻子，你以為瞞得住的壞消息，他們遲早會從別的管道知道——而那時候傷害的就不只是這件事，還有你這個人。

往下一層是影響透明。這個狀況對團隊、對每個人會造成什麼影響？獎金會不會延後？方向會不會調整？預測得到的就說出來，預測不到的就老實承認「這部分我現在也不確定」。承認不確定，本身就是一種誠實。

最深的一層是情緒透明。這不是要你在台上崩潰大哭，而是真誠地說出「我自己也有擔憂，但我選擇跟各位一起面對」。這一層最難，因為它要你卸下 leader 的盔甲——但偏偏就是這一層，才是把信任真正焊死的那道工序。

這三層背後有一條不能破的原則：透明不等於全說，而是守住「不欺騙」的底線。你不需要把每個細節都抖乾淨，但你絕對不能讓團隊活在一個錯誤的理解裡。前者是分寸，後者是欺騙——這條線一旦跨過去，前面所有的努力都白費。

你不敢示弱，真正怕的其實是自己

講到這裡，我猜你心裡可能還有個聲音：「道理我都懂，但真要我在團隊面前示弱，我做不到。」

我太懂這種感覺了，因為我以前就是這樣。而當我把這份「做不到」拆開來看，發現底下藏著三層恐懼。

第一層，怕失去威信——「如果我表現出擔憂，他們還會服我嗎？」但真相是，威信從來不是來自「看起來很強」，而是來自「值得信任」。你在 crisis 時硬裝堅強，團隊心裡只會冒出兩個字：演戲。

第二層，怕場面失控——「萬一我說了實話，士氣崩盤怎麼辦？」可是你有沒有想過，不說實話，團隊就真的不知道嗎？他們多半早就感覺到了，只是在等你繼續演，然後在某個瞬間，對你失去全部的信任。崩盤從來不是因為你說了實話，是因為你被拆穿了。

第三層，最隱密，怕自己是全場唯一沒信心的人——「大家好像都很鎮定，只有我在怕。」但這裡有個殘酷又溫柔的事實：團隊也怕，你一點都不特別。你以為只有你在硬撐，其實每個人都在偷偷等你先看見他們的恐懼。

說到底，整件事的關鍵就是一次心態的翻轉：示弱不是認輸，而是「我願意跟你一起扛」的邀請。你不是要在團隊面前展演脆弱，而是要讓他們知道——我看見了我們共同的脆弱，但我選擇站在我們這一邊。

寫在最後

湯君健說的「共享柔軟」，剝到最裡面，其實就這一句話：真正的凝聚力，不是來自喊口號式的堅強表演，而是來自願意示弱、把實話攤開的那份勇氣。

我想把問題丟回給你：你上一次在危機裡選擇「硬撐」，是什麼時候？現在回頭看，那個選擇對團隊，到底是凝聚還是消耗？

下一次危機來敲門時，試試看把實話攤開。不是要你砸場子，也不是要你傳遞絕望，而是讓團隊知道：「我看到了，我們正面臨挑戰。我願意跟你說清楚，這是我們的狀況，這是我們的選項，而我會跟你站在一起。」

你可能會意外地發現，團隊的反應比你預期的穩定得多。因為當你願意把最壞的情況攤開，團隊反而得到了心理準備——而一個做好心理準備的人，才有辦法真正做出判斷、扛起行動。硬撐替你撐住的，從來只是一晚的面子；而共享柔軟替你守住的，是往後每一次危機裡，團隊還願意跟你並肩的那份信任。

常見問題（我知道你會想問）

示弱會不會讓團隊覺得領導者沒有威信？

不會。威信不是來自「看起來很強」，而是來自「值得信任」。湯君健也指出，危機時團隊最需要的是真實訊息，而不是領導者的情緒表演。你把實話攤開，反而會讓團隊覺得：這個人，是可以依靠的。

共享柔軟，跟直接承認「公司快不行了」有什麼不同？

差在「方向」。共享柔軟不等於傳遞絕望——把訊息透明化的同時，領導者仍然主導著情緒的基調。示弱是「我們正面臨挑戰，但我願意跟你說清楚，我們一起應對」；甩鍋是「沒救了，大家自求多福」。一個仍帶著方向，一個是放棄領導，這就是兩者最大的分水嶺。

延伸閱讀

參考資料來源

  • 湯君健《怎樣成為帶團隊的高手2.0》第九講：非常時期的凝聚力打造 — 共享柔軟、該示弱時要示弱、把實話攤開
網路行銷
|

KPI 文化如何扭曲創新？微軟像科技業的計劃經濟

一句話結論

微軟 KPI 文化的問題不是不重視績效，而是把可計算的數字誤當成真實市場回饋，最後讓組織優化報表而不是產品。

微軟 KPI 文化如何讓組織優化報表而不是產品

KPI 文化為什麼會讓組織選擇保守？

我有個朋友，在微軟做搜尋引擎相關的團隊待過很長時間。有一段話他跟我講過，我一直記得：

「我們的工程師不比Google差，但老闆每個月看的是點擊率報表，不是產品評價。用戶搜完找不到答案就走人了，但那不算在任何人的KPI裡。」

這句話讓我後來想了很多。

1998年的微軟，是全世界最令人害怕的公司。搜尋引擎Ready，電子書Reader比Kindle早了九年，車用電腦Windows Automotive是Ford和豐田的首選。三張牌，每一張都領先。

然後呢？Google吃掉搜尋市場，Amazon吃掉電子書，Tesla定義了「軟體定義汽車」這個品類。微軟在哪裡？在旁邊看。

多數分析會把這個故事講成「微軟創新能力不足」或者「組織太大反應太慢」。但我一直在想一個問題：如果微軟真的反應慢，為什麼後來雲端轉型做成了？Azure現在是全球第二大雲平台。顯然不是能力問題。

我覺得問題更深的邏輯在這裡：不是微軟沒有創新能力，是它的激勵機制系統性地獎勵了不創新。

蘇聯的經濟學家可以精確計算每年要生產多少噸鋼鐵、多少噸水泥。數字看起來很漂亮，工廠年年超標完成任務。但這些東西做出來好不好用，市場不會有人為計算出來的數字買單——工廠做出來的東西堆在倉庫裡，沒有辦法變成消費者的實際購買行為。

微軟的KPI文化，本質上就是這個問題。

搜尋引擎團隊的KPI是CPC（每次點擊成本）和廣告展示量。不是「用戶能不能找到正確答案」，是「這個月廣告展示位有沒有優化」。翻譯成人話：你要讓用戶多點廣告，不是讓用戶滿意。

Google在幹嘛？它在「給出正確答案」這件事上建立護城河。PageRank也好，知識圖譜也好，答案品質直接等於使用者留存，等於搜尋市場份額，等於長期廣告價值。用戶找到答案→用戶回來→用戶看更多廣告→廣告價值更高。這是一個正循環。

微軟的搜尋團隊把資源放在能完成數字的事情上——優化廣告投放位置、把自然搜尋結果往下壓、讓點擊意圖看起來比實際更高。用管理指標取代了用戶指標。用戶搜了一次找不到答案就再也不來了，團隊沒有人被問責，因為留住用戶不在KPI裡。

這不是技術爛，是激勵機制告訴他們應該這樣做。

電子書為什麼輸給 Kindle？

電子書的故事更說明問題。

Microsoft Reader在2000年代初的功能拿出來對比Kindle不會太難看。DRM技術更成熟，排版支援更好，書庫談判也早就開始了。然後亞馬遜贏了。

很多人把這個結果解釋為「亞馬遜內容策略更激進」或「生態系統更完整」。但如果你看過微軟內部當時的DRM設計文件，會發現另一件事：DRM的每一個選擇，都是為了解決內部業務單元的分帳問題，不是讀者體驗問題。

什麼意思？微軟不是一家公司，是很多家公司的集合體。Windows團隊、Office團隊、MSN團隊，各自都有營收指標和利潤歸屬。一本電子書賣出去，版權金要怎麼分？DRM技術細節要怎麼設計才能保護各業務單位的既有利益？這些問題吵了幾年，讀者在等的功能優化排不上議程。

Amazon沒有這個問題。貝佐斯不需要在Kindle內容團隊和AWS團隊之間調解Revenue Sharing，他的DRM邏輯只有一個：開放到願意把書拿來的出版社都能上架，讀者拿到書之後能在任何設備上讀。這才是書商要的生態。

部門KPI把讀者體驗卡死在內部政治談判裡，亞馬遜用開放生態把整個市場拿走。

車用電腦為什麼錯過 Tesla？

車用電腦的失敗是同一個故事的第三個版本。

1990年代末，Windows Automotive是Ford、豐田這些OEM廠商的首選車載資訊娛樂系統平台。技術領先，合作關係穩固，看起來不可能輸。

然後整個智能汽車時代被Tesla定義了。Tesla的車機邏輯是什麼？軟體定義汽車。OTA更新、語音助理、Autopilot生態——這些不是硬體問題，是軟體思維的問題，而軟體思維本來應該是微軟的主場。

但微軟的車用團隊在幹嘛？每一個功能決定都卡在與OEM廠商的指標談判裡。

Ford說我要這個功能，因為這季的促銷計畫需要它。豐田說這個功能不能加，因為我們內部測試還沒過。微軟的經理人站在中間，他的KPI是什麼？是不要讓現有客戶不開心。防守現有客戶，確保續約數字漂亮，這是能寫進年終評估的事情。定義未來市場，讓車機變成平台，這是沒有指標支撐、而且可能得罪現有客戶的事情。

Tesla出現的時候，微軟甚至沒有被邀請進投標名單。不是因為技術不行，是因為整個決策框架裡，根本沒有「成為平台」這個選項。

三個案例背後，是同一個 KPI 失靈機制

計劃經濟最大的問題不是計劃，是經濟沒有市場來修正錯誤。數字可以包裝，但市場不會說謊。

搜尋：點擊率KPI讓團隊優化展示位，市場選擇了答案品質更高的Google。

電子書：部門分帳KPI讓DRM設計服務內部政治，市場選擇了開放生態的亞馬遜。

車用：客戶續約KPI讓功能開發卡在談判裡，市場選擇了平台思維的Tesla。

三個案例，同一個機制。

經理人的晉升邏輯和創新需要的冒險邏輯是天然矛盾的。完成KPI→拿到獎金→獲得晉升，這條路徑清晰而且確定。押注長期平台→冒犯現有客戶→可能失敗→老闆問你數字在哪裡，這條路徑充滿不確定性，而且不被現有激勵機制獎勵。

在KPI文化下，「安全失敗」的成本遠低於「危險成功」。失敗了只要數字包裝過得去，沒人追責。但做了大膽決定結果不好，年終檢討第一個被點名。

所以經理人集體理性地選擇了保守。不是因為他們笨，是因為激勵結構讓保守是理性選擇。

「KPI讓經理人集體理性保守——激勵結構是必選項。」

組織行為學者寧向東講過一句話我特別認同：一個組織的激勵機制決定了這個組織能看到什麼問題，以及願意解決什麼問題。KPI文化下的經理人不是看不到機會，是看到機會之後算了一下，發現完成KPI的收益遠高於押注長期變革的收益。

這不是道德問題，是系統設計問題。

納德拉如何讓 KPI 重新服務市場？

說到微軟翻盤，多數文章會提成長型思維，會提《Hit Refresh》那本書，會提雲端轉型。

這些都對，但如果你只看表面，就會錯過最重要的那件事：成長型思維是口號，改獎金結構才是行動。

納德拉上任後做的最重要的事情不是重新定義使命，是重新定義了什麼行為能在這個組織裡被獎勵。

以前，微軟的獎金結構是部門各自結算，你完成你的數字，拿你的獎金。跨部門合作沒有指標，幫別人解決問題不算成績。納德拉改了什麼？讓高階經理人的獎金與18-24個月後的成果掛鉤，而不是這個季度的數字。讓跨部門客戶問題變成考核指標，打破業務單元之間只掃門前雪的牆。在高管會議裡設立失敗學習會議，讓團隊報告失敗案例、萃取教訓，而不是檢討失敗數字。

這三件事加在一起，翻轉的不是口號，是什麼行為能在這個組織裡被獎勵。

「成長型思維是口號，改獎金結構才是行動。」

蘇聯的經濟學家不是笨蛋。他們受過最好的教育，有最完整的數據，做了最嚴謹的計算。但計劃經濟的問題從來不是計劃本身不夠聰明，是經濟沒有市場來修正錯誤——你沒有辦法用計算取代消費者的實際選擇。

微軟的KPI文化也是這樣。經理人不是不聰明，他們是HR體系裡百里挑一選出來的精英。但當激勵機制告訴你完成數字比做對事情更重要，你會理性地選擇服從激勵機制，而不是服從長期價值。

納德拉用十年證明一件事：真正的護城河不是技術領先，是組織對風險的胃口。成長型思維不是一句口號，是一套重新設計激勵結構的系統工程。

你公司現在是哪一種？

如果你團隊的KPI讓大家忙著完成數字而不是解決客戶問題，你可能正走在計劃經濟的老路上。


常見問題

為什麼 KPI 文化像計劃經濟？

兩者都傾向相信中央設定的指標能代表真實需求，但市場價值往往無法被單一數字完整捕捉。

KPI 一定不好嗎？

不是。KPI 適合追蹤穩定流程，但不適合取代產品判斷、創新探索與客戶理解。

企業該怎麼避免 KPI 扭曲？

把 KPI 當作警訊和對話入口，而不是最終答案，並保留定性回饋與一線決策權。

延伸閱讀