為什麼你的"AI 優先"戰略可能大錯特錯？

今天刷到《Why Your”AI-First”Strategy Is Probably Wrong》這篇文章（原文翻譯我放到下面）幾次，說點不一樣的。與其說 AI First，不如說軟件工程 First。

這篇文章看着在講 AI，底下全是軟件工程。

拋開後面講組織和人的部分，原文前半段的重點簡單總結一下：

AI 時代，人成了瓶頸。 PM 花幾周做需求，AI 兩小時就能實現，PM 成了瓶頸。QA 測三天，AI 寫代碼只要兩小時，QA 成了瓶頸。團隊 25 個人，對手幾百人，人力也是瓶頸。

怎麼辦？把人從鏈條裏拿掉。 AI 寫代碼、AI 審查代碼、AI 跑測試、AI 部署上線、AI 監控線上狀態，出了問題自動回滾。每天定時掃描日誌，自動發現問題、分配任務、跟蹤修復。整條流水線跑起來，人只需要在關鍵節點做判斷。

至於文中提到的統一代碼庫，錦上添花，和 AI First 關係不大。有當然更好，沒有也有很多替代方案。

整套方案聽下來，邏輯自洽，效果也漂亮：一天部署好幾次，功能當天上當天撤，數據說了算。

但先別急着照搬，先對照自己的情況想幾件事：

第一，自動化測試。 AI 改完代碼，你得有辦法確認它沒搞崩別的功能。測試覆蓋不夠的話，每次 AI 提交代碼你都得人工迴歸一遍，那速度根本快不起來。

第二，CI/CD 流程。 從提交代碼到部署上線，中間的測試、審查、發佈、回滾，是不是全自動跑通了？這條流水線不通，AI 寫得再快，代碼也堆在那兒等人手動處理。

第三，A/B 測試和線上監控。 新功能上線之後效果好不好，得有數據說話，效果不好得能隨時關掉。沒有這套機制，AI 一天產出五個功能，你都不知道哪個該留哪個該砍。

第四，任務管理。 任務得拆到合適的粒度，生命週期得跟蹤得住。一個大而模糊的任務丟給 AI，現在的能力還啃不動。多個 Agent 同時幹活的時候，誰做哪個、哪個優先、做到什麼程度，這些都得有地方管。

第五，系統架構。 架構太亂或者壓根沒有架構的代碼，AI 維護起來跟人一樣頭疼。上下文塞滿了還是搞不清邊界在哪，改一處崩三處。

這幾條裏如果有做不到的，就得靠人去補。補不上，AI First 就只是一句口號。

什麼場景適合，什麼不適合

但假設你全做到了，就能 AI First 了？

還是不行。這套玩法只適合一部分場景。

適合的場景： 後端邏輯為主、界面不復雜的產品，比如 API 服務、數據處理平台、內部工具。功能好不好，跑一下數據就知道，不需要人去盯着每個像素。原文裏的就是個 Agent 平台，本質上是後端驅動的產品，可以用這套打法。

再比如早期產品快速試錯，功能上了不行就撤，用戶預期本來就沒那麼高，AI 的速度優勢能充分發揮。

不適合的場景：

• • UI 密集的產品。 自媒體天天喊前端已死，但你讓 AI 做個複雜界面試試，各種易用性問題、交互細節、視覺還原，它搞不定的。否則馬斯克靠 AI 早就改了不知道改版 X 多少次了。
• • 功能質量敏感的產品。 Anthropic 和 OpenAI 不知道 AI First 嗎？他們敢在 Claude Code 和 Codex 上這麼搞嗎？讓 AI 全自動迭代自家的核心產品，用戶不罵死才怪。
• • 安全性要求高的場景。 銀行系統、在線交易平台，AI 代碼出個差錯，那可不是回滾能解決的。

AI First 的真正終點

AI First 的方向沒有錯，它代表的是一種意識的轉變：每做一個決策的時候，想一想這件事能不能讓 AI 來做，如果不能，缺什麼條件，怎麼把條件補上。

但這種意識要落地，靠的不僅是買幾個 AI 工具的訂閲，還需要把基礎搭好。 測試、CI/CD、監控、架構、任務管理，這些做紮實了，AI 的能力自然能釋放出來。做不好，加再多 AI 也是在沙子上蓋樓。

從這個角度看，AI First 的終點未必是讓 AI 幹所有的活，而是藉着這股力量，把你一直想做但沒動力做的工程改進，真正推動起來。

仰望星空是好的，但也還要腳踏實地。

為什麼你的“AI 優先”戰略可能大錯特錯【翻譯】

作者：Peter Pang
原文：Why Your “AI-First” Strategy Is Probably Wrong^[1]

我們 99% 的生產環境代碼都是由 AI 編寫的。上週二早上 10 點，我們上線了一項新功能，中午進行了 A/B 測試，結果下午 3 點就把它砍掉了，因為數據表現不佳。下午 5 點，我們又發佈了一個優化後的版本。如果放在三個月前，這樣一個完整的迭代週期至少需要六個星期。

我們能做到這一步，絕不是因為在代碼編輯器裏裝了個 Copilot 插件那麼簡單。我們徹底打破了原有的工程研發流程，並圍繞 AI 進行了全面重構。我們改變了做計劃、寫代碼、測試、部署以及團隊組織的方式。我們甚至重塑了公司裏每個人的角色。

CREAO 是一個 AI 智能體 (AI Agent) 平台。公司有 25 名員工，其中 10 名是工程師。我們在 2025 年 11 月開始研發智能體，就在兩個月前，我從零開始，徹底重組了整個產品架構和工程工作流。

OpenAI 在 2026 年 2 月發佈了一個新概念，完美總結了我們一直在做的事情。他們稱之為腳手架工程 (Harness Engineering，(注：Harness 原意為馬具或安全帶，在軟件工程中通常指測試支架或腳手架，這裏指為 AI 提供工作環境和約束條件的系統工程))：工程團隊的核心工作不再是寫代碼了，而是賦能智能體，讓它們去完成有價值的工作。當系統出錯時，解決辦法絕不是“再試一次”或“再努力點”。真正的解決思路是去問：AI 缺失了什麼能力？我們該如何讓這個能力對智能體變得清晰可見，並強制它們去執行？

我們自己摸索出了這個結論，只是當時還沒有一個現成的名詞來定義它。

“AI 優先”不等於“使用 AI”

大多數公司只是把 AI 強行塞進現有的工作流裏。工程師打開 Cursor 輔助寫代碼，產品經理用 ChatGPT 幫寫需求文檔，測試團隊 (QA) 嘗試用 AI 生成測試用例。整個工作流程還是老樣子。效率確實提升了 10% 到 20%，但本質上的結構沒有任何改變。

這頂多叫“AI 輔助” (AI-assisted)。

真正的“AI 優先” (AI-first)，意味着你要基於“AI 是主力構建者”這一核心假設，徹底重新設計你的流程、架構和組織。 你要停止問“AI 能怎麼幫助我們的工程師？”，轉而問“我們該如何重構一切，讓 AI 去做構建工作，而工程師只負責指引方向和判斷好壞？”

這兩種思路帶來的差距，是指數級的。

我看到很多團隊自稱“AI 優先”，卻依然在跑原來的敏捷衝刺週期，用着一樣的 Jira 任務看板，開着一樣的每週站會，還要經過一樣的 QA 驗收簽字流程。他們只是把 AI 強加進了現有的循環裏，而沒有重新設計這個循環。

這種現象的一個典型表現，就是現在常說的憑感覺編程 (Vibe Coding)。打開 Cursor，不斷調整提示詞直到代碼能跑通，提交代碼，然後不斷重複。這種方式只能用來做原型驗證。一個真正用於生產環境的系統，必須是穩定、可靠且安全的。當 AI 來寫代碼時，你需要建立一個能兜底並確保這些特性的系統。你需要構建的是系統，而那些提示詞是用完即棄的。

我們為什麼必須改變

去年，我仔細觀察了團隊的工作方式，發現了三個差點要了我們命的瓶頸。

產品管理的瓶頸

我們的產品經理過去要花好幾周的時間來調研、設計和詳細規劃產品功能。幾十年來，產品管理一直都是這麼運作的。但是，AI 智能體實現一個功能只需要兩小時。當開發時間從幾個月被極度壓縮到幾個小時，那長達數週的規劃週期就成了最大的拖油瓶。

花幾個月去構思一個想法，然後只用兩小時就把它做出來，這太不合邏輯了。

產品經理必須進化成具備產品思維的架構師，以快速迭代的節奏工作，否則就得退出開發環節。產品的設計必須通過“快速原型 - 發佈 - 測試 - 迭代”的循環來完成，而不是靠委員會開會去評審那些長篇大論的需求文檔。

測試 (QA) 的瓶頸

情況如出一轍。AI 智能體花兩小時上線一個功能後，我們的 QA 團隊要花好幾天去測試各種邊緣和極端情況。開發兩小時，測試三天。

於是，我們用 AI 構建的自動化測試平台取代了人工 QA，用 AI 來測試 AI 寫的代碼。驗證的速度必須趕上開發的速度。否則，你只是在離舊瓶頸十英尺遠的地方，又建了一個新瓶頸而已。

人力的瓶頸

我們的競爭對手有 100 倍甚至更多的人在做同樣的工作，而我們只有 25 人。我們不可能靠瘋狂招人來趕超他們，我們只能靠“重新設計”來殺出一條血路。

我們需要把 AI 深度貫穿到三個系統中：如何設計產品、如何實現產品、以及如何測試產品。如果其中任何一個環節依然靠純人工，它就會拖垮整個流水線。

一個大膽的決定：統一架構

我得先拿代碼庫開刀。

過去我們的架構散落在多個獨立的系統中。修改一個功能可能需要同時動三四個代碼倉庫。從人類工程師的角度來看，這勉強還能應付。但從 AI 智能體的視角來看，這就像個黑盒。智能體看不到全貌，無法推理跨服務的連鎖反應，也不能在本地跑集成測試。

我不得不把所有代碼整合到一個大型代碼庫 (Monorepo) 中。原因只有一個：讓 AI 能縱覽全局。

這就是腳手架工程理念在實際中的運用。你把越多部分的系統轉化為 AI 可以檢查、驗證和修改的形態，你獲得的槓桿效應就越大。碎片化的代碼庫對 AI 是隱形的，而統一的代碼庫對它們來說則是清晰易讀的。

我花了一週的時間設計新系統：規劃階段、實施階段、測試階段、集成測試階段。接着，我又用了一週時間，利用智能體幫忙重構了整個代碼庫。

CREAO 本身就是一個智能體平台。我們用自己的智能體，重建了運行智能體的平台。如果一個產品能自己構建自己，那就說明這條路走得通。

我們的技術棧

下面是我們的技術棧，以及每個模塊的作用。

底層基礎設施：AWS (亞馬遜雲服務)

我們運行在 AWS 上，使用了自動擴縮容的容器服務和熔斷回滾機制。如果部署後監控指標惡化，系統會自動回滾到上一個安全版本。

CloudWatch 是整個系統的中樞神經。所有服務都有結構化的日誌，設定了超過 25 個自動警報，自動化工作流每天都會查詢自定義指標。每一個基礎設施部件都會暴露出結構化、可查詢的信號。(注：結構化日誌指按統一格式記錄的日誌，便於機器讀取；可查詢信號指 AI 能直接檢索的關鍵運行數據) 如果 AI 讀不懂日誌，它就無法診斷問題。

CI/CD：GitHub Actions

每一次代碼修改都要經過一個死磕到底的六階段流水線：

驗證 CI → 構建並部署到開發環境 → 測試開發環境 → 部署到生產環境 → 測試生產環境 → 正式發佈

每個拉取請求 (Pull Request, 簡稱 PR，(注：即提交代碼變更的請求)) 上的把關機制，強制執行類型檢查、代碼規範檢查、單元和集成測試、Docker 構建、利用 Playwright 進行的端到端測試，以及環境一致性檢查。沒有任何一個階段可以跳過。不允許任何人工強行綠燈。整個流水線是絕對確定性的，這樣 AI 才能預測結果並推理出失敗的原因。

AI 代碼審查：Claude

每一個 PR 都會觸發 Claude Opus 4.6 進行三輪並行的 AI 審查：

1. 1. 代碼質量：檢查邏輯錯誤、性能問題、可維護性。
2. 2. 安全性：漏洞掃描、認證邊界檢查、注入攻擊風險。
3. 3. 依賴項掃描：供應鏈風險、版本衝突、開源協議問題。

這些是必須通過的攔截關卡，而不只是提提建議。它們和人工審查並行運作，批量攔截人類容易漏掉的錯誤。當你一天要部署 8 次時，沒有哪個肉眼凡胎的工程師能對每個 PR 都保持高度專注。

工程師還可以在任何 GitHub Issue 或 PR 中圈一下 @claude，讓它提供實施方案、開啓調試會話或進行代碼分析。AI 智能體能看到整個大型代碼庫。所有的上下文在不同的對話中是無縫貫通的。

自愈反饋循環

這是整個體系的靈魂。

每天早上（UTC 時間 9:00），自動化健康檢查工作流準時啓動。Claude Sonnet 4.6 會查詢 CloudWatch，分析所有服務的錯誤模式，並生成一份系統健康執行摘要，發送到團隊的聊天羣裏。這都不需要任何人主動去吩咐。

一小時後，分診引擎啓動。它會將生產環境裏的錯誤信息進行分類聚類，從 9 個維度評估每個問題的嚴重程度，並在任務管理系統中自動生成調查工單。每個工單都貼心地附帶了日誌樣本、受影響的用戶、受影響的接口以及建議的排查方向。

系統還會自動去重。如果現有的工單已經涵蓋了同類錯誤，它會更新那個工單。如果以前解決過的問題又出現了，它會敏鋭地檢測到倒退 (Regression) 並重新打開工單。

當工程師提交修復代碼時，同樣的流水線會接管一切。Claude 會進行三輪審查，CI 進行驗證。六階段部署流水線將其推送到各個環境並進行測試。部署完成後，分診引擎會再次檢查監控數據。如果原先的錯誤解決了，工單就會自動關閉。

每個工具只負責一個階段。沒有哪個工具試圖包攬一切。這個日常循環創造了一個“自愈閉環”：以最少的人工干預，完成錯誤的檢測、分診、修復和驗證。

我曾對《商業內幕》的記者說：“AI 會負責寫代碼並提交，人類只需要負責審核有沒有戰略風險就行了。”

功能開關與輔助技術棧

我們用 Statsig 來管理功能開關 (Feature Flags，(注：一種在代碼中控制功能是否啓用的技術，允許在不重新部署代碼的情況下隨時開關功能))。每個新功能上線前都藏在開關後。發佈模式非常穩健：先對團隊內部開放，然後按百分比灰度發佈，最後全面開放或直接砍掉。所謂的“一鍵關閉”能瞬間停用功能，根本不需要重新部署。如果一個功能導致數據指標變差，我們幾個小時內就會把它撤下來。糟糕的功能在上線當天就會“死掉”。A/B 測試也是跑在同一套系統上的。

Graphite 負責管理代碼分支：合併隊列會重新跑一遍驗證，只有一路綠燈才會合併到主幹。這讓我們可以一邊高頻提交代碼，一邊有條不紊地審查。

Sentry 報告所有服務的結構化異常，再由分診引擎將其與監控數據結合。Linear 則是面向人類的界面：自動創建帶有嚴重程度評分和調查建議的工單，後續驗證通過後自動關閉。

一個功能如何從想法走向生產環境

新功能開發路徑

1. 1. 架構師以結構化提示詞的形式定義任務，包含代碼庫上下文、目標和約束條件。
2. 2. 智能體拆解任務、規劃實施方案、編寫代碼並自動生成配套的測試。
3. 3. 開啓 PR。Claude 進行三輪審查。人類審查員只檢查高維度的風險，而不去逐行死磕代碼。
4. 4. 流水線驗證：類型檢查、代碼規範、單元測試、集成測試、端到端測試。
5. 5. 排隊、重新驗證、通過後合併。
6. 6. 六階段部署流水線將其推送到不同環境，每個階段都伴隨測試。
7. 7. 面向團隊內部開啓功能開關。逐步灰度發佈。緊盯數據指標。
8. 8. 一旦數據惡化，隨時一鍵關閉。遇到嚴重問題自動觸發熔斷回滾。

Bug 修復路徑

1. 1. 監控系統偵測到錯誤。
2. 2. Claude 分診引擎評估嚴重程度，自動創建一個包含完整排查上下文的工單。
3. 3. 工程師介入調查。此時 AI 其實已經做完了診斷工作。工程師只需驗證結論並提交修復代碼。
4. 4. 走同一套嚴格的代碼審查、驗證、部署和監控流水線。
5. 5. 分診引擎重新驗證。如果確認解決，工單自動關閉。

這兩條路徑用的是完全同一套流水線。同一個系統，同一個標準。

成果如何

在過去 14 天裏，我們平均每天進行 3 到 8 次生產環境部署。在舊模式下，這整整兩週的時間裏，我們連一次發佈都做不出來。

糟糕的功能在上線當天就會被砍掉。新功能在構思出來的當天就能上線。A/B 測試能實時驗證業務效果。

很多人以為我們是在犧牲質量換取速度。恰恰相反，用戶參與度上升了，付費轉化率也上升了。我們做出了比以前更好的產品，因為反饋閉環變得極短。每天發佈一次你能學到的東西，絕對比每個月發佈一次要多得多。

全新的工程組織架構

未來只會存在兩種類型的工程師。

架構師

只有一兩個人。他們設計標準作業程序，教 AI 如何工作。他們構建測試支架、集成系統和分診網絡。他們拍板系統架構和邊界。他們來定義在智能體眼裏什麼才叫“好”。

這個角色需要極其深厚的批判性思維。你要做的是挑 AI 的刺，而不是盲從它。當智能體提出一個方案時，架構師要能敏鋭地找到漏洞：它遺漏了哪些失效模式？越過了哪些安全邊界？積累了什麼技術債？

我擁有物理學博士學位。讀博期間我學到的最有用的東西，就是如何質疑假設、給論點做壓力測試，以及尋找邏輯漏洞。在未來，批評 AI 的能力將比寫代碼的能力更有價值。

當然，這也是最難招人的崗位。

操作員

其他所有人。工作依然重要，但結構變了。

現在是 AI 給人類分配任務。分診系統發現了一個 Bug，創建工單，亮出診斷結果，然後把它分配給合適的人。人類去調查、驗證，並批准修復方案。AI 負責提交代碼，人類負責審核有沒有風險。

這些工作依然需要極高的技能和專注力，但它們不再需要舊模式下那種從頭構建系統架構的推理能力。

誰適應得最快？

我觀察到了一個出乎意料的現象：初級工程師比資深工程師適應得更快。

沒有形成傳統思維定式的初級工程師，感到如虎添翼。他們掌握了能無限放大自身影響力的工具，而且沒有十幾年的老習慣需要去破除。

而擁有豐富傳統經驗的資深工程師，則經歷了最痛苦的掙扎。他們過去需要辛辛苦苦幹兩個月的活，現在 AI 一小時就幹完了。對那些花了好幾年時間才練就一身稀缺技能的人來說，這實在是一個難以接受的暴擊。

我不是在評判對錯，只是陳述我看到的現實。在這場變革中，適應能力遠比積累的過往技能更重要。

人性的一面

管理層的消亡

兩個月前，我要花 60% 的時間在人員管理上。對齊優先級、開會、給反饋、輔導工程師。

今天：不到 10%。

傳統的 CTO 模型告訴你，要賦能團隊去做架構，培訓他們，把工作交接出去。但如果這個系統只需要一兩個架構師，那我就必須先親自動手去建。我從“管理者”變回了“建造者”。我現在每天大概從早 9 點寫代碼到凌晨 3 點。我設計系統的底層邏輯和架構，維護整個基礎設施的腳手架。

壓力更大了。但我很享受這種純粹“建造”的快樂，而不是天天去跟人“對齊”。

爭吵少了，關係好了

我和聯合創始人以及工程師們的關係，反倒比以前更好了。

轉型前，我與團隊的大部分互動都是在開會。討論技術取捨，爭論優先級，為技術決策爭得面紅耳赤。在傳統模式下，這些對話是必需的，但也極其耗費心神。

現在我依然會和團隊交流。我們聊工作之外的話題，輕鬆閒聊，或者組織團建去放鬆。我們相處得更融洽了，因為我們不再為那些現在完全可以讓系統代勞的工作而吵架了。

焦慮是真實存在的

我不想假裝大家都很開心。

當我不再每天找大家溝通工作時，一些團隊成員感到了不安。CTO 不找我說話意味着什麼？在這個新世界裏我的價值到底在哪？這些擔憂都非常合理。

有些人在羣裏爭論“AI 到底能不能取代我的工作”，花的時間比實際幹活的時間還長。轉型期不可避免地會帶來焦慮。對此我也沒有什麼完美的安撫話語。

但我有一個原則：我們不會因為一個工程師在線上寫了個 Bug 就開除他。我們會改進審查流程、加強測試、增加護欄。對待 AI 也是一樣。如果 AI 犯了錯，我們就去構建更好的驗證機制、更清晰的約束條件和更強的系統可觀測性。

工程之外

我看到一些公司在工程研發上採用了“AI 優先”，但其他部門依然是純手工作業。

如果工程師幾小時就能發佈一個功能，而市場部要花一週來發公告，那市場部就是新的瓶頸。如果產品團隊還在按“月”來做規劃，那產品規劃就是瓶頸。

在 CREAO，我們將AI 原生的運作方式推行到了所有職能部門：

• • 產品更新說明：由 AI 根據代碼變更記錄和功能描述自動生成。
• • 功能介紹視頻：由 AI 自動生成動態演示。
• • 社交媒體日常發佈：由 AI 策劃並自動發帖。
• • 健康報告和數據分析：由 AI 從監控和生產環境數據庫中提取生成。

工程、產品、市場和用戶增長都在同一個“AI 原生”的工作流裏運轉。如果一個部門以智能體的光速運轉，而另一個部門還在以人類的龜速爬行，那麼人類的速度就會拖慢整個公司的腳步。

這意味着什麼

對工程師而言

你的核心價值正在從“寫代碼的產量”轉移到“做決策的質量”。能快速敲代碼的能力，每個月都在貶值。而評估、批判和指導 AI 的能力，正在快速升值。

對產品的敏鋭度和品味至關重要。你能不能掃一眼 AI 生成的 UI 界面，在用戶抱怨之前就直覺發現它不對勁？你能不能看一眼架構提案，就一眼看穿 AI 漏掉的系統性風險？

我總是告訴我們 19 歲的實習生：去刻意練習批判性思維。學着去評估論點、尋找邏輯漏洞、質疑想當然的假設。去學習什麼是好的設計。這些技能是自帶複利效應的。

對 CTO 和創始人而言

如果你們產品規劃功能的時間，比寫代碼實現的時間還長，趕緊從那裏開始動刀子。

在大規模引入 AI 智能體之前，先建好測試的腳手架。沒有極速驗證做後盾的極速 AI，只會帶來快速累積的技術災難。

從一名架構師開始。找一個能把這套系統建起來並證明它行之有效的人。等系統跑通了，再安排其他人進入“操作員”的角色。

將“AI 原生”強行推入每一個職能部門。

做好心理準備，肯定會遇到阻力和反對。

對整個行業而言

OpenAI、Anthropic 以及許多獨立團隊都在向着同樣的原則靠攏：結構化的上下文、專業化的智能體、持久化的記憶，以及執行閉環。腳手架工程正在成為行業的標配。

驅動這一切的引擎是模型能力的進化。我把 CREAO 最近發生的所有質變，都歸功於過去這兩個月。Claude Opus 4.5 做不到的事，Opus 4.6 已經能做到了。下一代模型只會讓這種變革來得更猛烈。

我相信，“一人公司”將變得非常普遍。如果一個架構師帶着一羣智能體就能幹 100 個人的活，很多公司根本就不需要僱傭第二名員工。

一切才剛剛開始

我接觸過的大多數創始人和工程師，還在沿用傳統的模式。一部分人開始考慮轉型，但真正邁出這一步的寥寥無幾。

一位記者朋友告訴我，她就這個話題大概採訪了五個人。她說我們走得比任何人都靠前：“我覺得沒有任何人像你們一樣，完完全全重構了整個工作流。”

任何團隊都可以用現有的工具做到這一點。我們的技術棧裏，沒有任何一個是獨家機密。

真正的競爭優勢，在於你下定決心要圍繞這些工具徹底重塑一切，並願意承受隨之而來的巨大代價。這種代價是真金白銀且痛徹心扉的：員工的迷茫與焦慮、CTO 每天工作 18 個小時的煎熬、資深工程師對自身價值的自我懷疑，以及那段舊系統已拆毀而新系統還未跑通的、令人窒息的兩週真空期。

我們扛下了這些代價。兩個月後，數據說明了一切。

我們構建了一個智能體平台。而這個平台，正是我們用智能體建起來的。

引用連結

[1] Why Your “AI-First” Strategy Is Probably Wrong: https://x.com/intuitiveml/article/2043545596699750791