林俊旸點贊！AI-First是年輕人的機會，最佳實踐公開了

AI應用風向標（公眾號：ZhidxcomAI）
編譯｜江宇
編輯｜漠影

智東西4月15日報道，近日，前蘋果機器學習專家、前Meta GenAI科學家、硅谷AI創企CreaoAI聯合創始人兼CTOPeter Pang，在X上發了一條熱帖，閱讀量突破百萬，引發業內廣泛討論。

不少行業人士紛紛轉發評論，其中就包括前阿里通義千問團隊負責人林俊旸，他還分享了自己對“AI-first”戰略的獨到見解。

在這篇名為《為什么你的“AI優先”戰略可能大錯特錯》中，有幾個核心觀點值得關注：

1、人在AI時代可能成為障礙。

產品經理花幾周設計需求，而AI兩小時就能實現；QA測試需要三天，而AI寫代碼只用兩小時；團隊人數有限，遠比不上競爭對手。效率的提升被傳統流程嚴重限制。

2、AI-first意味著把人從日常構建鏈條中解放出來。

AI可以獨立完成代碼編寫、審查、自動測試、部署上線和監控狀態，出現問題自動回滾。每天AI定時掃描日志、發現問題、分配任務、跟蹤修復，人只在關鍵節點做判斷。

3、AI-first的成功依賴五個前提條件：自動化測試、CI/CD全流程自動化、A/B測試與線上監控、任務管理和清晰的系統架構。

任何環節做不到，AI的速度優勢就無法釋放，AI-first也只是“一紙空談”。

4、AI-first的真正目標是提升決策和流程效率，而非讓AI干所有工作。

它強調在每次決策時思考AI能做什么、缺失哪些條件，并建立扎實的基礎設施，使AI能力真正釋放。

5、小白更容易受益。

在AI-first轉型中，適應能力比積累的經驗更重要。要訓練批判性思維，學會評估論證、發現漏洞、質疑假設。學習什么是好的設計，能力會逐步累積。

以下是該文章的全文翻譯（智東西在不改變原意的前提下，做了簡單的編輯）：

我們99%的生產代碼是由AI完成的。上周二上午10點，我們上線了一個新功能，中午進行了A/B測試，下午3點因為數據不支持而下線。晚上5點，我們上線了一個更優版本。

三個月前，這樣一個周期至少需要六周。但我們圍繞AI重新構建了整個流程，改變了團隊計劃、開發、測試、部署和組織的方式，改變了公司中每個人的角色。

CREAO是一個Agent平臺。團隊中有10名工程師。我們從2025年11月開始構建Agent，但從兩個月前，我從底層重構了整個產品架構和工程工作流。

OpenAI在2026年2月提出了一個概念，與我們的做法不謀而合。他們稱之為：Harness Engineering（Harness工程）——工程團隊的主要職責不再是寫代碼，而是讓Agent能夠執行有用工作。

當出現問題時，解決方案從來不是“更努力”，而是：“缺失了哪項能力？如何讓Agent可以理解并執行？”

我們自己也得出了這個結論，只是當時沒有名稱。

1、AI-First并不等于使用AI

大多數公司只是把AI附加到現有流程上。工程師用Cursor，產品經理用ChatGPT起草規格說明，QA用AI生成測試。流程沒變，效率提高了10%到20%，結構沒有改變——這只是“AI輔助”。

而AI-first意味著你要重新設計流程、架構和組織，假設AI是主要的構建者。你要問“如何重構一切，讓AI完成構建，工程師提供方向和判斷？”這種區別是指數級的。

我看到一些團隊聲稱自己是AI-first，但他們只是把AI加到循環里，并沒有重構循環。

一個典型例子就是所謂的“vibe coding”，這只能產生原型。生產系統需要穩定、可靠和安全，你需要一個能保證這些屬性的系統，prompt是一次性消耗品。

2、我們為什么必須改變

去年，我觀察團隊工作，發現三個瓶頸，如果不解決，會扼殺效率：

• 產品管理瓶頸

PM（產品經理）們幾十年如一日，花數周研究、設計、撰寫規格說明。但Agent能在兩小時內實現一個功能?；〝翟驴紤]問題，然后在兩小時內實現功能是沒有意義的。

PM必須進化為快速迭代的產品架構師，通過“原型—發布—測試—迭代循環”進行設計。

• QA瓶頸

Agent上線后，QA團隊花幾天測試邊緣情況。開發兩小時，測試三天。我們要用AI生成的測試平臺取代了人工QA，驗證必須與實現速度一致，否則新的瓶頸會出現在原瓶頸下游。

• 人數瓶頸

競爭對手可能有100倍以上的人力，我們無法通過增加人數來追趕，只能通過AI重構來實現。三個系統必須由AI貫穿：產品設計、實現、測試。任何一個保持手工操作，都會限制整個流水線。

3、大膽決定：統一架構

我必須先修復代碼庫。

舊架構分散在多個獨立系統中，一處修改可能需觸碰3-4個倉庫。人類工程師尚可管理，但對AI Agent而言，太不透明，無法推理跨服務的影響，也無法在本地運行集成測試。

我必須把所有代碼統一到一個monorepo中，讓AI能看到全部內容。

這是Harness工程的實踐原則：系統越多被Agent可讀、可驗證、可修改，杠桿作用越大。

我花一周設計新系統：規劃階段、實現階段、測試階段、集成測試階段。另一周用Agent重構整個代碼庫。

4、技術棧

以下是我們的技術棧及每部分的作用。

• 基礎設施：AWS

我們在AWS上運行，使用自動擴縮容容器服務和熔斷回滾機制。指標下降時，系統自動回。CloudWatch是中樞神經系統。每個服務的日志結構化，可查詢，25個報警，指標每天由自動化工作流查詢。AI如果無法讀取日志，就無法診斷問題。

• CI/CD：GitHub Actions

每次代碼變更經過六階段流水線：驗證CI→構建部署開發環境→測試開發環境→部署生產環境→測試生產環境→發布

每個階段必不可少，也不能手動跳過。流水線是確定性的，因此Agent可以預測結果并推理失敗原因。

• AI代碼審查

每次PR觸發三次并行AI審查：代碼質量、安全掃描與依賴核查。

這些審查門檻是“硬性需求”，人類無法全量關注每個PR。工程師還可在GitHub Issue或PR中@Claude，Agent能看到整個monorepo，上下文跨對話傳遞。

5、自愈反饋循環

核心機制為：

每天UTC 9:00，會運行自動化健康工作流，分析所有服務的錯誤模式，并生成執行摘要發至團隊。

一小時后，分診引擎運行。聚類生產錯誤，按九個嚴重性維度評分，自動生成Linear任務，包含日志樣本、受影響用戶和端點、建議調查路徑。

系統去重。如果同樣錯誤模式已存在任務，更新它；若已關閉任務再次出現，檢測回歸并重新打開。

工程師推送修復，流水線同樣處理，三次Claude審查、CI驗證、六階段部署，部署后分診引擎重新檢查CloudWatch，如原錯誤解決，Linear任務自動關閉。

每日循環形成自愈閉環：錯誤被自動檢測、分診、修復和驗證，人工干預最少。

6、從功能想法到生產

• 新功能流程

1. 架構師定義任務（結構化prompt + 代碼庫上下文、目標、約束）
2. Agent分解任務、計劃實現、寫代碼、生成測試
3. PR打開，Claude三次審查，人類審查戰略風險
4. CI驗證（類型檢查、lint、單元/集成/端到端測試）
5. Graphite merge queue重跑CI，合并通過
6. 六階段部署流水線推進開發和生產環境的測試。
7. 功能門控為團隊開啟，逐步增加比例并監控指標。如有問題，可用關閉開關立即下線，嚴重問題觸發熔斷回滾。

• Bug修復路徑

1. CloudWatch和Sentry檢測錯誤
2. Claude分診引擎評分，生成Linear任務
3. 工程師調查，AI已完成診斷，人工驗證并提交修復
4. 走同一套嚴格的代碼審查、驗證、部署和監控流水線
5. 分診引擎復核，任務解決自動關閉

兩個流程使用同一套流水線，一個系統，一個標準。

7、成果

14天內，每日平均3-8次生產部署。舊模式下，兩周可能連一次發布都沒有。

錯誤功能當日下線，新功能當日上線。A/B測試實時驗證效果。

很多人以為我們為了速度犧牲質量，但用戶參與度和付費轉化率提升。因為反饋循環更緊密，每日發布學到的東西比每月發布更多。

8、新工程組織

新組織將存在兩類工程師：

• 架構師

1-2人。設計SOP教AI工作，構建測試、集成和分診系統，決定架構和系統邊界，定義Agent“好”的標準。需要深度批判性思維，質疑AI、發現漏洞、分析潛在安全和技術負債。

• 操作員

負責具體執行任務的團隊成員。他們的工作仍然關鍵，但流程和責任與傳統角色有所不同。AI分配任務，分診系統生成任務并指派給合適人選，人類調查、驗證、批準修復。

任務包括Bug調查、UI優化、CSS改進、PR審查、驗證。需要技能和專注，但不要求傳統架構推理能力。

9、誰適應得最快

在AI-first轉型中，團隊發現初級工程師適應得比資深工程師更快，因為他們沒有長期的傳統工作習慣包袱，可以更自然地利用AI工具放大影響力。

而資深工程師則適應較慢，他們過去需要兩個月完成的工作，現在AI一小時就能完成，這對長期習慣深厚的人來說，是一大挑戰。

在這個轉型中，適應能力比積累的經驗更重要。

10、人類層面

• 管理工作減少

兩個月前，我60%時間用于管理?，F在低于10%。從管理轉向構建，工作時間從早9點工作到凌晨3點點，設計SOP和架構，維護Harness。

雖然更累，但我更享受構建的過程。

• 爭論減少，關系改善

以前團隊交流多為會議、爭論、權衡，現在非工作話題更多，關系更好。

• 不確定感真實存在

在轉型過程中，部分團隊成員感到不確定：CTO不天天交流意味著什么？我在新模式下的價值是什么？

有些人花更多時間在討論AI能否替代他們的工作。

我的原則是，無論是人還是AI出現問題，都不因為一次錯誤就懲罰責任方。團隊會通過改進審查流程、加強測試和增加約束條件來解決問題，從而保證系統安全和穩定。

11、跨越工程之外

其他部門仍手工操作會成為瓶頸。工程、產品、市場和增長團隊運行在統一的AI-native流程中。如果某個職能按Agent速度運作，而另一個按人工速度運作，慢的那部分就會限制整體效率。

12、對工程師的啟示

價值從代碼產出轉向決策質量?？焖賹懘a越來越不重要，而評估、批判和指導AI變得更重要。

產品感覺和判斷力也關鍵：能否在用戶反饋前發現問題，并提前做出調整？

我告訴19歲的實習生：訓練批判性思維。學會評估論證、發現漏洞、質疑假設。學習什么是好的設計。這些能力會逐步累積。

13、對CTO與創始人的啟示

1. 如果你的PM流程耗時超過構建時間，從這里開始著手。
2. 在擴展Agent前先構建測試Harness。快速的AI輸出如果缺乏驗證，會產生快速累積的技術債務。
3. 先從一個架構師開始，一個人構建系統并證明其可行。系統穩定后，再讓其他人進入操作員角色。
4. 推動AI-native進入每個職能。
5. 做好心理準備：有些人會反對。

14、對行業的啟示

OpenAI、Anthropic及獨立團隊在結構化上下文、專業Agent、持久記憶和執行循環方面達成共識。Harness Engineering正成為行業標準。

模型能力是驅動這一轉變的時鐘：Opus 4.5做不到的事情，Opus 4.6可以完成。下一代模型還將進一步加速。

我相信一人公司模式將會普及：一個架構師帶Agent即可完成100人工作，許多公司無需第二名員工。

15、我們仍處于早期

我接觸的大多數創始人和工程師仍在按傳統方式運作。有人在考慮轉型，但很少有人真正實踐。

工具對任何團隊都是可用的。我們的技術棧沒有專有限制。競爭優勢在于決定圍繞這些工具重構一切，并且愿意承擔成本。

成本是真實存在的：員工的不確定感，CTO每天工作18小時，資深工程師重新審視自身價值，舊系統消失而新系統尚未完全驗證的兩周過渡期。

我們承擔了這些成本。兩個月后，數據說明一切。

林俊旸的觀察與思考

在Peter Pang的AI-first實踐之后，前阿里通義千問團隊負責人林俊旸也分享了他對AI-first戰略的理解：

• 批判性思維至關重要

在Agent時代，人類需要與AI“辯論”，通過列舉理由、分析問題，達成更深入的認知和全面的判斷。

• 健康且結構良好的組織與系統必不可少

完善的體系與高效工具能讓人類與AI協作效率成倍提升，同時為員工爭取更多時間照顧身心、探索新機會。

• 新人更容易受益

因為經驗包袱較輕，對當前困難的恐懼少。資深工程師則需仔細甄別哪些經驗值得保留，哪些與第一性原則相符。

林俊旸總結道：“無論如何，AI-first都是極其令人興奮的機會。”