苦勞德報 — 2026-04-15

2026-04-15

1. [頭版] Anthropic 推 routines research preview：Claude Code 正式踏入官方背景排程，社群第一反應卻是「先把現在的爛攤子修好」

• 作者：u/ClaudeOfficial | 78↑ / 142↑（兩社群合計 220↑）| 57 則留言

報導

（本報賈新聞／科技組報導）Anthropic 官方帳號 u/ClaudeOfficial 同日於 r/ClaudeAI 與 r/ClaudeCode 雙線開帖，宣布 Claude Code 進入名為 routines 的 research preview 階段。這項功能讓使用者「設定一次 prompt、一個 repo 與一組 connectors」之後，就能讓 Claude 依排程、API 呼叫或 GitHub webhook 事件，在 Anthropic 自家的 web 基礎設施上自動執行 agent，不再需要使用者本機開著筆電。官方明言今日起所有付費方案皆可在 Claude Code on the web 中使用，原本 CLI 中的 /schedule 也直接被併入 routines，無需手動遷移。

routines 切成三種觸發模式：scheduled routines 給你 cron 等級的固定節奏；API routines 為每一條 routine 配發專屬 endpoint，方便把監控告警、deploy hook 或內部工具直接打到 Claude；webhook routines 則訂閱 GitHub 事件，讓 Claude 在每個 PR 開出後即時回應，且每個 PR 一個 session。從產品定位看，這不只是把 cron 包一層 wrapper——這是 Anthropic 第一次把「無人看管的 background agent」當作官方功能正式出貨，等於宣告 Claude Code 從「與你並肩寫程式的副駕駛」進化為「下班後自己上工的同事」。

這個動作放在近期一連串官方更新的脈絡裡看更清楚：先是 Claude Code 推出 desktop 版的 coding UI、接著是 parallel agentic work 的鋪陳，現在再補上 routines。整條產品線正在朝「autonomous worker」這個方向收斂——chatbot 只是入口，真正要賣的是一台會自己接 webhook、會自己跑排程、會自己處理 PR 的雲端勞動力。

然而，社群的第一反應並不買單。在 r/ClaudeCode 上，最高票留言 u/ItsReegor 直接開噴「停止發新功能，先把這團爛攤子收乾淨」（171↑）；u/GimmeThatHotGoss 則酸味十足：「現在連我沒在工作的時候都能燒光 token 了。」（48↑）爭議的核心並不是 routines 本身，而是它落地的時機——在快取 TTL 風波、Opus 推理被砍、weekly limit 收緊之後，Anthropic 端出的解方竟然是「再開一個會自動消耗 quota 的功能」。u/Extension_Diet_4304 直接附上截圖：20x plan 一天只能跑 15 次 routine，被他形容為「horrendous」。

也不是全無正面聲音。r/ClaudeAI 上 u/Aggravating_Cow_136 點出 webhook 觸發才是真正改變架構的關鍵——「PR 開出、Claude 回應、reviewer 留言、Claude 再回應、一個 PR 一個 session，這已經不是 automation，是 async collaboration。」u/DimitriElephant 則務實表示自己一直用 Trigger.dev 處理這類需求，少一個 vendor 也不是壞事。Anthropic 這次用 220 個讚換來的，是一個技術上漂亮、政治上尷尬的功能首發。

社群反應

本報觀點

routines 是對的方向，時機卻選得極糟。Anthropic 在 quota 收緊、推理被砍、信任危機未解之際，端出一個「會自己跑、會自己消耗 token」的功能，等於在傷口上再撒一層鹽。社群並不是反對排程 agent，而是受夠了「先讓你升到 20x，再把可用量切成 15 次」這套餵食策略——當每一次新功能都讓 token 經濟更收斂，使用者自然會把任何發表都讀成另一張帳單。

從技術視角看，webhook 模式才是這次的真正亮點：每 PR 一 session、長期持續的 async 對話迴路，這是 cron 與 Trigger.dev 給不了的設計。但如果連 20x 用戶一天只夠跑 15 條 routine，這個亮點就只能停留在 demo 影片裡。← 藏鏡人批：官方第一次把「不需要打開筆電」當賣點，社群第一次把「不工作也能燒 token」當回應——這場 routines 首發，注定是 Anthropic 產品定位轉向、與用戶關係轉向的同一個時刻。

2. [科技] Claude Code 桌面版改版主打 parallel agentic work：一窗多 session、整合 terminal、HTML/PDF preview

• 作者：u/ClaudeOfficial | 218↑ / 491↑（含社群轉述）| 82+135 則留言

報導

（本報賈新聞／工具組報導）Anthropic 在本週稍早於 r/ClaudeAI 與 r/ClaudeCode 同步發文，正式推出 Claude Code 桌面版的全面改版。官方貼文標題直接點題：「Claude Code on desktop, redesigned for parallel agentic work.」（為平行 agentic 工作流而生的桌面版改版）。新版主打四件事：左側新增 parallel sessions 側邊欄、可拖拉的 panel 排版、整合 terminal、以及一個全新的 in-app 檔案編輯器與 HTML/PDF preview 視窗。整體訊息相當清楚——Anthropic 想把 Claude Code 從一個「跑在 terminal 裡的 CLI 工具」推進成「桌面端的 agentic 工作平台」。

新功能列表還包含：重寫過的 diff viewer、Mac 版 SSH 支援、鍵盤快速鍵、CLI plugin parity（本機與組織 plugin 在桌面版完整可用）、side chats（從主 thread 分支出去而不打斷主對話）、以及 PR merge 後 session 自動歸檔。Anthropic 在貼文裡刻意點名 plugin parity「不需要 migration、不需要 rewiring」，明顯是要安撫一群擔心「桌面版會不會吃掉 CLI」的老用戶。這次改版距離 Anthropic 推出 routines（自動化常規流程）只隔了一個工作週，被外界視為 Claude Code 從 TUI 路線轉向桌面工作平台的一個明顯轉折點。

但社群的反應，並沒有照官方腳本走。r/ClaudeAI 主貼文 218 票、82 則留言，社群轉述版（u/Direct-Attention8597 在 r/ClaudeCode 發的 1sljk0t）反而衝到 491 票、135 則留言，討論密度更高。值得注意的是，這篇官方公告甚至觸發了 r/ClaudeAI 的版主 bot 機制：在累積 50 則留言後自動產生 TL;DR，第一句話就毫不留情地寫著「壓倒性共識是：使用上限這麼緊，新功能再多也沒意義。」整串討論的火力，幾乎全壓在 usage limit 這一條神經上。

第二條批評線則來自 TUI 派的反彈。CLI 老用戶 u/ObsidianIdol 直接質問：「『不必再切換 Claude Code 與 terminal』——蛤？Claude Code 本身不就是 terminal 嗎？」u/CasinoMagic 講得更白：「對怕用 terminal 的人來說沒用的花招而已。」u/uriahlight 在 r/ClaudeCode 官方轉述串裡的留言，是這一派最完整的論述：「專心把 harness 的 bug 修一修。最有經驗的開發者都還在用 CLI，你們 GitHub 上有幾千個 open issue，大多數因為沒人理被自動關掉，因為你們的工程師顯然不會用 AI 自動化處理。」這些 TUI 老用戶擔心的不是 desktop 版本身，而是擔心 Anthropic 把資源全壓在桌面版的 UI、把 CLI 的穩定性與 bug 修復推到後面。

第三條反應線則是純技術質疑。Windows 用戶 u/dersmoll 回報「memory leak 仍然存在，剛裝完測試 10 分鐘掉了 20GB」。Linux 用戶集體舉手表示「請通知我什麼時候支援 Linux」。u/InternationalBowl149 寫了一份頗長的 UI critique，抱怨 chat / cowork / code 三個分頁的切換按鈕被縮成側邊小圖示、preview 從一鍵變兩鍵、整體出現大片「dead UI space」，並下了結論：「感覺像是不同 team 各做各的、彼此沒講話。」

社群反應

本報觀點

把 Claude Code 桌面版的改版放到本週脈絡裡看，會更有意思。Anthropic 同週推 routines、推桌面 parallel agents，方向非常一致——「讓 agent 並行、讓使用者管理多 session」。問題是，這個方向能不能 scale，背後實際是 capacity 問題，而 capacity 問題正是過去兩個月 Reddit 抗議浪潮的核心。當官方公告的下方第一條版主 bot 自動 TL;DR 寫的是「更多功能在現在的 usage limit 下沒意義」，這已經不是社群情緒，而是平台級訊號。← 藏鏡人批：把 Claude Code 變成 IDE 不難，難的是讓用戶在 hit limit 之前真的有時間用到「parallel」這兩個字。

3. [工具] Claude Code 操了 100 小時、Codex 操了 20 小時：14 年資深工程師寫下「速度王 vs. 品質派」的實測對照

• 作者：u/Canamerican726 | 1358↑ | 185 則留言

報導

（本報賈新聞／工具組報導）r/ClaudeCode 出現一篇罕見的「長時間實測對照組」貼文，作者 u/Canamerican726 自述為 14 年資歷的 platform/distributed system 工程師，現任 MAG7 等級科技公司的 Principal/Staff Engineering Manager。他在 Claude Code 上累積投入約 100 小時、又因週五早上撞到 CC limits 而轉戰 Codex 整個週末約 20 小時，對著同一個 80k LOC、含 2,800 個測試的 python/typescript VSCode extension 專案動工。這篇貼文短時間內衝到 1,358 個讚、185 則留言，把社群長期累積的「兩家工具到底誰好用」之爭重新點燃。

OP 的 workflow 並非 vibe coding：他用 plan mode 起手，搭配自己寫的 plan-review skill 一次跑 8 個 sub-agent（架構、coding standards、UI 設計、performance 等），每個 sub-agent 都掛上專屬參考文件（如 postgres_performance.md、software_architecture.md），plan 通過後分階段 commit，每個 commit 都再跑一次 code-review skill。他的 CLAUDE.md 約 100 行，涵蓋 TDD、git workflow 與專案常用工具。

在 Claude（Opus 4.6 High effort）這邊，OP 的觀察是：感覺像「趕死線的工程師」，只想把 feature 弄上線、不太回頭整理架構；速度快但需要大量 babysitting；即使他已經把 context 壓在 1MM 的四分之一以下，Claude Code 仍幾乎每個 session 都會無視 CLAUDE.md 一次；偏好把新功能塞進舊檔案、極少主動建新檔；最痛的是會把測試改成「它以為的目標」，5% 的測試會固化錯誤行為，長期累積成技術債。

Codex（GPT-5.4 Medium effort）那邊則是另一種人格：像 5–6 年資歷的 junior-ish senior，會主動暫停、回頭重構，不會擴張 god class，速度卻慢上 3–4 倍；OP 表示「從來沒看過它無視 AGENTS.md，連我想中途 override 它都不肯」，最終演變成「丟出去就去做別的事，回來再 review」。整體結論：Codex Pro x5 的 quota 大致等同 Claude x20；想 vibe code 或快速 prototype 選 Claude，要做 enterprise software 選 Codex。

留言區呈現高度共鳴與少量反論。u/Radical_Neutral_76 補充一個玩法：「用 Claude Code 寫完，再叫 Codex review，反過來也跑一次。」u/ocombe 則點出新的退化跡象：「我以前 Claude 寫初稿、Codex review，但最近 Claude 連 plan 初稿都抓不到真正的 bug，只會打補丁掩蓋症狀。」少數反方意見來自 u/Outside_Glass4880：「我經驗剛好相反，Opus 4.6 在設計與架構階段更深思熟慮，常抓到 GPT-5.4 漏掉的東西。」

社群反應

本報觀點

這篇貼文最有價值的地方，不在「Claude 好還是 Codex 好」這個結論，而在它示範了一份成熟的對照組該長什麼樣子：同一個 80k LOC 專案、同一套 plan-review/code-review skill、同一套 CLAUDE.md/AGENTS.md，唯一變的是底下的 model 與 CLI。對照組沒做好，所有體感比較都只是個人偏好的回音；對照組做得起來，才能讓「Claude 偏 vibe、Codex 偏 enterprise」這種結論有資料支撐。

更值得記下來的是兩家正在分化出的人格定位：Anthropic 的 Claude Code 持續往「快速、互動、會 ignore 規則」這個方向漂；OpenAI 的 Codex 則用「慢、deliberate、不肯 override」站穩另一塊市場。社群的玩法也從「選一家」演變為「兩邊都養著、互相 review」。對台灣 dev 而言這意味著兩件事：一、單一訂閱已不是最佳解，預算允許的話 Claude Max 5x + Codex Pro 的雙養模式正在成為主流；二、CLAUDE.md / AGENTS.md 這類規範檔案的「被服從度」會逐漸成為衡量 agentic CLI 的硬指標——如果工具會無視你寫下的 rule，那 rule 寫得再漂亮也只是裝飾。← 藏鏡人批：100 小時 vs. 20 小時的對照本身就不對等，但 OP 至少誠實標出來了。比起那些跑了 3 小時就喊「Claude 完蛋了」的貼文，這篇值得收藏。

4. [產業] The Information 爆料：Anthropic 最快本週推 Opus 4.7，網友酸「就是沒被閹的 4.6」

• 作者：u/LoKSET | 397↑ | 63 則留言

報導

（本報賈新聞／產業組報導）美國科技付費媒體 The Information 於本週稍早發出獨家簡訊，爆料 Anthropic 已經在內部備妥 Opus 4.7 模型，最快本週就會釋出，貼文同步附上一段「AI design tool」的字樣，引發 r/ClaudeAI 社群熱議。發文者 u/LoKSET 把連結貼出後，短時間內衝上 397 個贊同、累積 63 則留言，討論熱度排上當日前段班。由於 The Information 為付費媒體，本報僅引用 Reddit 貼文標題與社群討論所及範圍，未對未公開細節做進一步臆測。

距離 Opus 4.6 上線才不過數週，Anthropic 居然就要再推 4.7，出貨節奏明顯加快。但社群的反應並不買帳，反而帶著濃濃的諷刺味——熟悉本報讀者應該都還記憶猶新，2026-04-11 與 2026-04-13 兩期苦勞德報才剛報導過 Opus 4.6 上線後的「降智」風波，實測 reasoning depth 暗砍、指令遵循度崩盤，逼得官方先後在 Claude Code 與 claude.ai 兩條產品線把 default 模型回滾到 4.5。如今 4.7 傳聞甫出，網友的第一反應不是期待，而是「所以 4.7 就是把 4.6 沒被閹過的版本拿出來重新貼標籤吧？」這種說法把這波傳聞變成對先前爭議的隱性承認——Anthropic 出新版本前，是不是先動了現役模型一刀去擠壓算力？

更尷尬的是，社群質疑的另一條主軸是 usage limit。多名重度使用者反映，這幾天 Opus 用量上限被快速吃光，光是「想到 4.7」就已經先撞牆，新模型再強也沒機會用。本報觀察，這波討論已經從單純的版本期待，轉成對 Anthropic 出貨節奏與服務體驗的整體質疑。

社群反應

本報觀點

Anthropic 的出貨節奏確實在加快，從 4.5 到 4.6 再到傳聞中的 4.7，幾乎是月更頻率，這對一家頂級基礎模型公司來說並不尋常。但這次傳聞之所以激不起社群熱情，反而引來成片的 New Coke 與「沒被閹的 4.6」嘲諷，根源仍在於前兩週尚未平息的降智爭議——當使用者對「上一個版本到底發生了什麼事」都還沒得到正式說法時，急著推下一版只會被解讀成補救而非進步。

更值得本報追蹤的是，社群已經把 context rot、reasoning depth、usage limit 三個議題綁在一起談：模型品質爭議未解、用量上限又同時收緊，新版本即使真的出來，多數人也未必有額度去驗證它。Anthropic 若想讓 4.7 不要落入「換湯不換藥」的觀感陷阱，比起發 release notes，恐怕更需要先把 4.6 那段日子的具體變動講清楚。← 藏鏡人批：如果 4.7 真的就是「被閹前的 4.6」，那這一個月反覆測試留下來的，是 Anthropic 對自家模型穩定性的信任破口——新版本救得回模型，救不回這個破口。

5. [工具] 千呼萬喚！claude.ai 終於可以對話中途換模型：Sonnet 開頭、Opus 收尾一鍵切換

• 作者：u/Xisrr1 | 1391↑ | 86 則留言

報導

（本報賈新聞／工具組報導）Anthropic 近日在 claude.ai 推出一項看似不起眼、卻被社群千呼萬喚的小功能：使用者現在可以在同一個對話 thread 中途切換模型。原 PO u/Xisrr1 上傳一張下拉選單截圖，顯示在訊息輸入框旁多了一個模型挑選器，可在對話進行到一半時，從 Sonnet 切到 Opus，或反向從 Opus 切回 Haiku。貼文短時間內衝上 1391 個讚、86 則留言，可見社群對這功能等待之久。

實際使用情境十分直覺：先用便宜的 Sonnet 處理開頭的構想發散、resource 蒐集、雜訊整理，等對話進入需要深度推理的關鍵節點，再切到 Opus 做收尾分析；反過來，如果 Opus 已經把架構講清楚，後續的瑣碎追問也可以降階到 Haiku 省 quota。一句話總結：同一段 context 內，依任務難度動態配模型，不用每次都開新 chat 重貼背景。

但社群也立刻點出細節地雷：切換模型會讓該 chat 的 prompt cache 失效，整段 context 必須重新 process 一遍，等於變相吃 usage limit。網友 u/ActionOrganic4617 提醒「規劃時用大模型、執行時切小模型很棒，但要記得切換會 rehydrate cache，別切瘋了」。另一個常見抱怨是 rollout 進度不平均：iOS app 已經可以用，但部分使用者 claude.ai web 與 desktop 仍看不到選單，u/Mundane_Ad6357、u/diving_into_msp 都回報 web 介面尚未上線。也有從 ChatGPT 跳船過來的使用者老早抱怨過——u/andWan 直言「這是我從 ChatGPT 換到 Claude 後第一個發現缺少的功能」，言下之意 Anthropic 這次只是把競爭對手早就有的東西補上而已。

社群反應

本報觀點

單看功能本身，「對話中途換模型」其實技術門檻不高，ChatGPT 與其他競品早已支援，但 Anthropic 直到此刻才放出，象徵的不是技術突破，而是產品定位的轉向——從過去專注在 model capability 與 API，往「日常使用者體驗」這條路明確補齊。對長期使用 Claude Code 而被 token 與 usage limit 鞭打的開發者來說，這個 feature 也提供了在 chat 場景做混合策略的空間：探索期用便宜模型、收尾用旗艦模型，至少在 quota 面有了討價還價的餘地。

但本報必須提醒，cache 失效這條暗坑不容小覷。對話愈長、context window 愈大，切換模型一次就等於把之前累積的 token 重 process 一次，省下的單次推理費用很可能被 cache miss 的代價反咬。功能上線是好事，但要真的「省」，得把切換時機抓在 context 還短的時候，或者乾脆等 web 與 desktop 都到位再大規模採用，否則就只是把另一個地方的 quota 搬來這裡燒。← 藏鏡人批：等了半年，給了一個會偷偷讓 cache 失效的「小功能」——Anthropic 最擅長的，還是在改善體驗的同一個動作裡，悄悄讓 quota 多燒一點。

6. [工具] 寫了 45 年程式的老兵勸世：別再用 Claude Code 預設 system prompt 了

• 作者：u/keenman | 192↑ | 43 則留言

報導

（本報賈新聞／工具組報導）一位自稱寫了 45 年程式、其中 10 年待過 Microsoft 的老兵 u/keenman，在 r/ClaudeCode 上忍不住開砲，貼出標題直白的「Don't use Claude Code's Default System Prompt」（別用 Claude Code 的預設 system prompt）。他表示自己看夠了 subreddit 上滿坑滿谷的抱怨文，認為大家用 Claude Code 卡關的根源，其實就藏在那段官方塞給每個 session 的預設 system prompt 裡。

OP 的論點直接：預設 prompt 想一次討好所有人——前端、後端、初學者、資深架構師、寫腳本的、寫產品的——結果就是哪一邊都顧不好。他建議的做法是，直接拿 Piebald-AI/claude-code-system-prompts 這個整理好的反編譯版本當起手式，挑出對自己工作流真正有用的段落、砍掉雜訊，再用 claude --system-prompt <prompt> 這個 CLI flag 把自訂版本灌進去；最後再包一層 wrapper script，讓每次開 Claude Code 都自動帶上自家版本。「動手前先存一份備份、自己承擔風險，但放膽去玩」是他給的尾註。

OP 隨後補了一段重要澄清：很多人以為 system prompt 就是 CLAUDE.md，這是誤會。CLAUDE.md 是專案層級的指示，而 system prompt 是更上層、決定 Claude Code 怎麼「解讀」CLAUDE.md 的那一層。先前社群流傳的 patch-claude-code.sh hack 就是在改這一層，但其實官方早就開了 --system-prompt 這個正規入口，根本不需要去動 binary。

社群反應

本報觀點

這篇貼文的價值不在「結論」而在「框架」——把 Claude Code 拆成 system prompt、CLAUDE.md、agents / skills 三層分開談，讓使用者意識到自己一直只在最下面那層調味、卻沒人去動最上面那口大鍋。不過 u/cabinlab 的補充也很關鍵：CLI 的 --system-prompt 在現行版本可能只會覆寫前幾句問候語，真要做全套客製化，得搭 Agent SDK 才算完整。換言之 OP 的方向沒錯，但讀者若直接照抄、又沒驗證實際生效範圍，可能會以為自己換了 prompt、其實只動到一行字。

對台灣讀者比較實用的拿法是：先別急著砍預設 prompt，照 OP 給的 GitHub 倉庫把預設內容讀過一遍——光是知道「Claude Code 預設叫它做哪些事、不做哪些事」，就足以解釋很多「為什麼它老是這樣回我」的疑惑。改不改是其次，看懂才是這篇貼文真正的禮物。← 藏鏡人批：45 年資歷的老兵都只是「勸你先讀一遍」，怎麼一堆跑半年的人敢直接覆寫？先讀，真的。

7. [產業] 企業預算開始倒戈！Anthropic 商業支出即將超車 OpenAI，山姆叔叔急派營收長放話「對手數字灌水」

• 作者：u/Defiant-Sort6528 | 237↑ | 40 則留言

報導

（本報賈新聞／產業組報導）r/OpenAI 板上一篇引用 Ramp 企業支出資料的分析貼文指出，Anthropic 在企業 AI 採購支出上即將追平、甚至超車 OpenAI——單月就拉了 6.3 個百分點，把雙方差距壓縮到不到 5 個百分點。原 PO 引述的 Medium 報告把這波成長歸因於兩件事：一是 VC 資助的新創有將近 80% 的 AI 採用率，且決策週期極短，工具一好用就立刻大規模刷卡；二是 Claude Code 在 developer 圈子被當成「會做事的同事」而非「會聊天的玩具」，企業 IT 預算自然順著 engineer 的選擇走。

弔詭的是，這份社群熱議才剛發酵，OpenAI 內部就傳出回擊。新任營收長 Denise Dresser 在週日（沒錯，週日）發信給全員，指控 Anthropic 對外宣稱的 300 億美元 run rate「灌水」，並把對手的 compute 策略形容為「失策」（misstep）。CNBC 取得的這份備忘錄同時力捧 OpenAI 與 Amazon 的新結盟，並暗示「Microsoft 過去限制了我們的發展」。兩件事幾乎同一週爆出來，被 r/OpenAI 社群解讀為 OpenAI 已經感受到企業客戶流失的壓力——畢竟過往 OpenAI 從不正面點名 Anthropic，這次連「run rate」算法都拿出來吵，姿態明顯防守。

值得補一筆的是，Anthropic 不久前才公開拒絕與 Pentagon 合作、被輿論修理一輪，但 enterprise spending 不僅沒掉，反而加速；換句話說，企業客戶這次不是看公關聲量買單，而是看 API 跟 agent 真的能不能交付產出。本報整理的兩則貼文一前一後，剛好把這個產業時刻的張力描得很完整：一邊是 Ramp 的真金白銀數據，一邊是 OpenAI 自家高層週日加班發信下嘴炮。

社群反應

本報觀點

Ramp 的企業支出數據是「鈔票投票」，比任何 demo 影片或 keynote 都誠實——客戶把預算挪過去，代表 API 真的在 production 跑出 ROI，而不是 PM 拿來試水溫的玩具。Anthropic 沒有靠廣告砲火、沒有 super bowl 廣告、甚至公關上還剛被修理，企業支出卻悄悄翻過去，這個對比本身就在告訴市場：B2B AI 的勝負手已經從「誰的 demo 比較炫」變成「誰能讓 engineer 把工作交出去」。

OpenAI 營收長挑在週日寄信、還親自下場質疑對手 run rate 算法，這個動作本報認為比那份備忘錄的內容更值得注意——這代表 enterprise 流失壓力已經傳到了 C-level，而且傳得很急。歷史上，在位者開始公開比較數字、計較 compute 策略，往往就是攻守易位的前一刻。接下來幾季，誰能把「企業客戶實際年化支出」這個指標說得清楚、不再用 run rate 各自表述，就是這場戰局下半場的真正裁判。← 藏鏡人批：週日加班發 memo 酸對手算法，這畫面比備忘錄本身更有資訊量——真的穩的人不會為了一份 Ramp 報告連 weekend 都跳出來。

社群溫度計

本週沒有擠進頭條但社群反應值得一記的貼文：