做電影網(wǎng)站需要什么手續(xù),網(wǎng)站源代碼制作,自建網(wǎng)站避免侵權,wordpress優(yōu)化加速緩存中國這是我在「Agent 實戰(zhàn)營」里給到大家的一次「課程加餐」#xff0c;和大家分享了我最近美國之行的一些一線見聞與真實感受。最后同學們也提了不少問題#xff0c;我會在文章結(jié)尾整理出來#xff0c;如果你也有類似困惑#xff0c;希望能對你有所啟發(fā)。首先感謝 AWS 的邀請和大家分享了我最近美國之行的一些一線見聞與真實感受。最后同學們也提了不少問題我會在文章結(jié)尾整理出來如果你也有類似困惑希望能對你有所啟發(fā)。首先感謝 AWS 的邀請讓我有機會參加 AWS re:Invent 2025。在這次美國之行中我不僅參加了這場全球頂級的技術大會更有幸與 OpenAI、Anthropic、Google DeepMind 等硅谷頂級 AI 公司的多位一線從業(yè)者進行了深入交流其中大多數(shù)觀點都得到了不同公司專家的交叉驗證。2 萬人的 NeurIPS 真的是超級大會Gemini 一個展臺周圍就圍成了這樣從 Las Vegas 的 re:Invent 會場到 San Diego 的 NeurIPS再到灣區(qū)的 AI 公司十幾天的密集交流讓我學到了非常多。主要包括以下五個方面AI 輔助編程Vibe Coding的實踐經(jīng)驗分析了不同場景下效率提升的巨大差異從創(chuàng)業(yè)公司的 3-5 倍提效到大廠和研究機構效果有限的深層原因?？茖W化的應用開發(fā)方法論介紹了頂級 AI 應用公司普遍采用的 Rubric-based Evaluation 體系?；Ｐ凸镜慕M織與資源配置深入分析了 Google、OpenAI、xAI、Anthropic 等公司的優(yōu)劣勢包括算力資源、薪酬結(jié)構以及模型團隊與應用團隊的合作現(xiàn)狀。創(chuàng)業(yè)公司的戰(zhàn)略選擇基于資源和人才的現(xiàn)實約束分析了創(chuàng)業(yè)公司應該避開的領域和應該專注的方向。Context Engineering 的核心技術討論了應對 Context Rot 的關鍵技巧以及文件系統(tǒng)作為 Agent 交互總線的設計模式。Vibe CodingAI 編程1. AI 編程效果的兩極分化現(xiàn)象在與多家硅谷公司深入交流后我們發(fā)現(xiàn)了一個重要共識Vibe Coding 的效果呈現(xiàn)顯著的兩極分化。這種分化不是偶然的而是由任務性質(zhì)、組織類型、代碼類型的根本差異所決定的。某些場景下AI 編程能帶來4-5 倍的效率提升但在另一些場景中AI 幾乎幫不上忙甚至會產(chǎn)生負面影響。創(chuàng)業(yè)公司的 MVP 開發(fā)場景是 AI 編程表現(xiàn)最為出色的領域。這種場景的核心特征是從 0 到 1 的原型開發(fā)重點在于速度和尋找產(chǎn)品市場契合度Product Market FitPMF而非在復雜的現(xiàn)有系統(tǒng)上進行修修補補。創(chuàng)業(yè)公司通常使用 React、Django、FastAPI 等主流框架而 AI 在這些技術棧上擁有充足的訓練數(shù)據(jù)能夠直接生成大量的樣板代碼。更重要的是創(chuàng)業(yè)團隊規(guī)模較小不需要跨部門協(xié)調(diào)決策和執(zhí)行都非常迅速Code Review 流程也相對簡單。在這種環(huán)境下典型的 CRUD 業(yè)務邏輯、簡單的 API 開發(fā)、前端表單和頁面制作以及數(shù)據(jù)處理腳本都能實現(xiàn)顯著的效率提升。一次性腳本和膠水代碼One-off Scripts 和 CRUD Code是另一個普遍適用的高效場景。無論是數(shù)據(jù)分析腳本、數(shù)據(jù)遷移工具、批量處理程序這樣的一次性腳本還是配置文件、數(shù)據(jù)轉(zhuǎn)換層、API 調(diào)用封裝、測試用例生成這樣的樣膠水代碼AI 都能發(fā)揮出色的作用。這類任務的共同特點是邊界清晰、輸入輸出明確不需要深入理解復雜的業(yè)務邏輯即使出錯影響范圍也相對有限。值得一提的是即使是 OpenAI、Google 的研究人員也大量使用 AI 來編寫這類代碼。然而大廠的日常開發(fā)卻呈現(xiàn)出截然不同的結(jié)果。效率提升之所以有限根本原因在于大廠工程師的時間分配結(jié)構開會占用 30%部門間扯皮協(xié)調(diào)占 20%撰寫文檔占 20%定位 Bug 占 15%而真正的**編碼時間僅占 15%**。AI 只能優(yōu)化這最后 15% 的時間對整體效率的影響自然有限。此外大廠系統(tǒng)的復雜度極高需要深入理解現(xiàn)有架構涉及多個團隊的代碼庫還要考慮向后兼容性AI 在這種環(huán)境下容易引入回歸錯誤。嚴格的多輪 Code Review、各種 lint 檢查、冗長的上線流程也使得即便 AI 寫得再快后續(xù)流程的時間成本依然不變。Research Code代表了 AI 編程的能力邊界。這類智力密集型代碼包括修改模型架構如 Attention 結(jié)構、調(diào)整訓練算法、優(yōu)化數(shù)據(jù)配比等往往只需要修改 3 行代碼但需要深思熟慮很久。由于這些都是前沿研究訓練數(shù)據(jù)中并沒有相關內(nèi)容需要深厚的理論背景和創(chuàng)新思考每個研究項目都具有獨特性不存在標準做法。因此研究人員主要將 AI 用于編寫輔助腳本如數(shù)據(jù)分析和可視化而將核心算法邏輯完全留給人類。最后核心基礎設施代碼是一個需要格外謹慎的領域用不好就是幫倒忙了。這類代碼對性能極其敏感要求極低的延遲和手動優(yōu)化而 AI 生成的代碼通常不是最優(yōu)的。同時任何 Bug 都可能導致大規(guī)模系統(tǒng)故障需要對邊界情況有深入考慮AI 容易遺漏關鍵的 corner cases。涉及認證、授權、加密、簽名等安全關鍵邏輯時更不能有任何疏漏。因此這類代碼最好還是由人來寫。2. 硅谷一線團隊的 Vibe Coding 最佳實踐為了防止 AI 把代碼寫亂我們結(jié)合硅谷多家公司的經(jīng)驗總結(jié)出了一套成熟的工程化流程。這套流程的核心是將 AI 當作“不太靠譜的初級程序員”來管理通過嚴格的約束和檢查機制確保代碼質(zhì)量。PR 行數(shù)限制是整套流程的基礎。單個 PR 必須嚴格控制在 500 行以內(nèi)這個限制對 AI 和人類都具有重要意義。對于 AI 而言過長的上下文容易導致幻覺和邏輯崩壞明確的任務邊界能避免 AI “跑偏”同時減少不同模塊間的耦合風險。對于人類而言500 行是 Code Review 的認知極限超過這個數(shù)量Review 質(zhì)量會大幅下降。具體的標準會根據(jù)場景有所調(diào)整后端和 Agent 核心代碼嚴格限制在 500 行前端 React 代碼可以放寬到 2000 行測試用例可以超過 500 行。要做到這一點人的職責就變成了提前進行需求拆分和任務分解這也是 Vibe Coding 中人的核心價值之一。全自動化的多 Agent 協(xié)作工作流代表了業(yè)界最先進的實踐。當線上出現(xiàn) Issue 或有新的功能需求時系統(tǒng)會自動創(chuàng)建相應的 ticket并觸發(fā) Coding Agent 開始編寫代碼。代碼生成后不會直接提交 PR而是自動觸發(fā) 3-5 個不同的 Review Agents 并行執(zhí)行這些 Agents 使用不同的基座模型部分甚至是購買的第三方 Code Review 服務。與此同時系統(tǒng)會運行完整的自動化測試套件包括單元測試和集成測試。只有當所有 Review Agents 都認為代碼沒有問題且所有自動化測試通過時系統(tǒng)才會自動生成 PR 并通知相關人員。最后人類進行最終的審查檢查 AI 可能遺漏的業(yè)務邏輯問題確認是否符合項目整體架構并決定是否合并。對于簡單問題這個流程可以實現(xiàn)完全自動化人只需要做最后的確認。測試驅(qū)動的質(zhì)量保障是整個體系的安全網(wǎng)。核心理念是必須建立充足的測試覆蓋測試用例成為 AI 代碼的保護屏障沒有測試的代碼不允許 AI 隨意修改。同時要保護測試用例本身不能讓 AI 隨便刪除或修改測試用例防止 AI 為了“讓測試通過”而刪除測試。此外還要建立內(nèi)部的 Rubric-based Benchmark評測標準類似第六章講的 Evaluation 方法針對不同場景設定不同的評價指標并通過自動化打分機制快速驗證每一次改動的效果。對于無法在 500 行內(nèi)完成的大型重構或新特性開發(fā)則需要采用人機協(xié)作的方式。首先由人編寫詳細的技術設計文檔明確架構和模塊劃分定義接口和數(shù)據(jù)流。然后根據(jù)設計文檔拆分成多個子任務確保每個子任務都控制在 500 行以內(nèi)。在具體分工上核心業(yè)務邏輯對性能要求極高的部分、對業(yè)務理解要求很深的部分以及涉及復雜架構決策的部分由人來完成數(shù)據(jù)轉(zhuǎn)換格式化、API 調(diào)用封裝、重復性的 CRUD 操作、測試用例生成等邊緣代碼由 AI 負責。整個過程采用迭代方式AI 先寫一版人 review 后決定保留或修改逐步集成并持續(xù)測試。頂級 AI 公司的應用開發(fā)“科學方法論”這次與 Google DeepMind、OpenAI 和 Anthropic 頂級 AI 公司應用開發(fā)團隊的深入交流中最令我震撼的是他們做應用的科學性和嚴謹性。這些公司不是在“試” Prompt而是在“測”系統(tǒng)。雖然三家公司的具體實踐有所差異但核心理念高度一致數(shù)據(jù)驅(qū)動、嚴格評估、持續(xù)迭代。1. 嚴格的評估體系Evaluation System構建頂級 AI 公司絕不會憑感覺上線應用而是建立了完善的Rubric-based Evaluation System基于細則的評估體系。這套體系的核心是對每個測試案例的每個指標進行自動化打分。任何版本在上線前所有關鍵指標都必須達到預設的標準。如果某項指標無法達標必須經(jīng)過高層特別批準并提交明確的后續(xù)整改計劃。這種嚴格的標準確保了產(chǎn)品質(zhì)量的穩(wěn)定性和可預測性。2. 數(shù)據(jù)飛輪與自動化迭代機制測試數(shù)據(jù)集的構建和維護是整個體系的基礎。每個功能模塊都配備專門的測試數(shù)據(jù)集有專人負責根據(jù)線上出現(xiàn)的問題案例持續(xù)構造和維護數(shù)據(jù)集。一旦發(fā)現(xiàn)新問題就會立即加入到測試數(shù)據(jù)集中形成持續(xù)改進的閉環(huán)。全自動化評測流程通常需要幾個小時來處理幾百個測試案例團隊習慣于晚上提交任務第二天早上查看結(jié)果。系統(tǒng)使用 LLM 作為評判者每個評估指標都有專門的 Prompt 來進行判斷嚴格按照預定義的細則進行打分。雖然也會請人工標注數(shù)據(jù)來評價結(jié)果但能夠達到甚至超過 LLM Judge 水準的人工標注成本極其高昂。3. 基礎模型團隊與應用團隊的微妙關系通過深入了解我發(fā)現(xiàn)了一個重要現(xiàn)象基座模型公司內(nèi)部做應用本質(zhì)上等同于外部創(chuàng)業(yè)公司做應用。模型團隊的優(yōu)先級排序非常明確首先是四大通用 Benchmark數(shù)學能力、代碼能力、電腦操作、深度研究其次是長期的模型智力提升和通用能力增強這些被認為是對模型長遠發(fā)展最重要的方向。而垂直領域的需求則排在極低的優(yōu)先級上基本不會得到響應。這種優(yōu)先級設定帶來了一個有趣的結(jié)果應用團隊很難影響模型團隊的發(fā)展方向。無論是內(nèi)部應用團隊還是外部創(chuàng)業(yè)公司都面臨著同樣的限制使用相同的基座模型 API無法影響模型訓練方向無法要求針對性優(yōu)化。不過基座模型公司的應用團隊確實具有兩個獨特優(yōu)勢一是可以更方便地找到模型團隊來 Review Prompt改進 Context Engineering二是 Token 成本采用內(nèi)部計價比外部公司調(diào)用 API 便宜很多這也解釋了為什么 Cursor 的 API 成本遠高于 Claude Code 的訂閱費用。相對而言外部創(chuàng)業(yè)公司反而在某些方面更有優(yōu)勢可以同時使用多家模型而 Google 內(nèi)部只能使用 Gemini可以創(chuàng)建 Mashup Agent將 OpenAI、Anthropic、Gemini 混合使用在技術選型上更加靈活自由。硅谷巨頭眾生相優(yōu)勢、劣勢與內(nèi)幕1. Google DeepMind資源優(yōu)勢與組織效率的博弈Google DeepMind 展現(xiàn)出了四大顯著優(yōu)勢。首先是創(chuàng)始人的高度重視和強大組織能力。ChatGPT 發(fā)布后Google 聯(lián)合創(chuàng)始人 Sergey Brin 親自重返公司DeepMind CEO Demis Hassabis 展現(xiàn)出卓越的技術和管理能力成功將幾千名頂尖人才凝聚在一起避免了嚴重的內(nèi)耗和政治斗爭。雖然合并過程中存在一些摩擦但整體團隊向心力依然很強。這與其他公司形成鮮明對比Meta 的扎克伯格將 AI 管理權下放給 Alexandar Wang而后者不親自管細節(jié)又進一步下放給團隊微軟和蘋果的高層對 AI 技術細節(jié)的理解相對有限。Gemini App 被并入 DeepMind 的決策也體現(xiàn)了一個重要認知做應用本質(zhì)上就是研究工作需要科學的方法論、大量實驗和數(shù)據(jù)驅(qū)動以及完善的評估體系。其次是碾壓性的算力資源優(yōu)勢。Google 采用 TPU 和 GPU 雙軌戰(zhàn)略自研的 TPU 提供了持續(xù)穩(wěn)定的算力供應多年積累的 Nvidia GPU 采購也形成了雄厚基礎總算力可能是 OpenAI 的數(shù)倍。這種算力優(yōu)勢直接體現(xiàn)在模型規(guī)模上OpenAI 的主力模型 GPT-4o 系列參數(shù)規(guī)模為幾百 B雖然經(jīng)歷了幾代演進但參數(shù)規(guī)模一直沒有顯著增加主要通過測試時縮放思維鏈來提升能力。相比之下Google 的 Gemini 2.5 Pro/3 Pro 擁有數(shù) T 參數(shù)比 OpenAI 主力模型大一個數(shù)量級甚至 Gemini 3 Flash 的參數(shù)規(guī)模就與 GPT-4o 相當。OpenAI 之所以無法使用更大模型主要受制于算力不足訓練和服務都需要大量資源而 ChatGPT 作為行業(yè)標桿擁有超過 10 億用戶API 調(diào)用量巨大。相比之下Gemini 用戶量約 6 億API 調(diào)用量約為 OpenAI 的 1/5因此可以“任性”地使用更大的模型。第三個優(yōu)勢是充足的人力資源配置。以圖片生成模型為例Google 的 Nano Banana Pro 算法團隊不到 10 人但數(shù)據(jù)和基礎設施團隊接近 1000 人而 OpenAI 對應模型的算法團隊同樣不到 10 人但數(shù)據(jù)加基礎設施的人員數(shù)量差了一個數(shù)量級。人員充足的優(yōu)勢主要體現(xiàn)在能夠針對特定場景構造大量訓練數(shù)據(jù)比如原理圖、九宮格圖片等這些都需要大量人工標注和數(shù)據(jù)構造工作。當前的基座模型仍然高度依賴人類構造的數(shù)據(jù)僅靠互聯(lián)網(wǎng)數(shù)據(jù)遠遠不夠。第四個優(yōu)勢是生態(tài)入口的天然便利。Chrome 瀏覽器右上角直接集成了 Gemini 按鈕用戶體驗比 ChatGPT Atlas、Perplexity Comet 等獨立瀏覽器插件更好可以直接詢問當前頁面問題或總結(jié)長文。Google Workspace 的深度集成讓 Gemini 可以直接操作 Calendar、Drive、Gmail 等核心應用這些都是天然的用戶基礎。多年積累的 YouTube 視頻數(shù)據(jù)為多模態(tài)訓練提供了寶貴資源Google Search 直接展示 AI 摘要也成為了新的流量入口。然而Google 也面臨兩個明顯的短板。首先是大公司固有的效率問題。復雜的流程使得數(shù)據(jù)集構建、評估體系建立需要大量時間產(chǎn)品迭代速度遠不如創(chuàng)業(yè)公司甚至連 OpenAI 這樣的中型公司迭代速度都比 Google 快。內(nèi)部人員最擔心的就是 OpenAI 和創(chuàng)業(yè)公司的速度優(yōu)勢雖然自身資源豐富但“船大難調(diào)頭”的問題始終存在。其次是只優(yōu)化通用需求不涉足垂直領域的戰(zhàn)略局限。模型團隊的優(yōu)先級排序非常明確通用 Benchmark 第一模型智力和長期能力提升第二垂直領域需求基本沒有精力響應。這種策略對創(chuàng)業(yè)公司而言反而是機會窗口因為垂直領域需要大量 Context Engineering 工作不是通用數(shù)據(jù)飛輪就能解決的而且我們使用的模型與 Gemini App 團隊使用的完全相同技術起點是平等的。2. OpenAI品牌光環(huán)下的多重焦慮OpenAI 雖然擁有 AI 領域最強的品牌認知度堪稱 AI 界的“扛把子”但內(nèi)部實際上承受著巨大壓力對 Google 的追趕感到非常焦慮。Google 在資源、算力、數(shù)據(jù)等方面都占據(jù)優(yōu)勢地位這種壓力感在公司內(nèi)部非常明顯。人才結(jié)構問題是 OpenAI 面臨的一個重要挑戰(zhàn)。公司招聘了太多學術背景的人員導致學術思維與工程思維之間產(chǎn)生沖突。學術人員希望驗證自己的學術想法但這些想法在工程實踐中可能并不實用這在注重結(jié)果導向的 xAI 絕對不會發(fā)生。2023 年 Ilya Sutskever 等核心科學家的離職主要原因就是認為 Sam Altman 的資源分配不公太多資源用于服務線上用戶而訓練新模型的資源不足。算力資源困境是 OpenAI 面臨的核心矛盾。作為擁有超過 10 億用戶的平臺OpenAI 必須在有限的算力下在訓練和服務之間做出平衡。這種資源約束導致了一些用戶體驗上的妥協(xié)早期 ChatGPT Plus20 美元/月采用暴力截斷上下文Context Window 僅有 32k tokens導致嚴重的幻覺問題——丟失前面的上下文后后續(xù)輸出完全是胡說八道。大小模型路由策略也引起了爭議GPT-5 實施自動路由讓小問題使用小模型但路由準確性不足重要問題可能被分配給小模型而用戶無法看到具體是哪個模型在回答導致體驗下降和用戶投訴。不過OpenAI 在Codex方面確實做得出色代碼生成能力很強針對真實使用場景進行了大量優(yōu)化而不僅僅是針對 Benchmark 進行調(diào)優(yōu)。3. xAI極致效率與零容忍文化xAI 展現(xiàn)出了與其他公司截然不同的企業(yè)文化。Elon Musk 明確宣示“我們沒有 Research Engineer只有 Engineer”No Research Engineer, only Engineer意思是不要進行學術研究只要工程結(jié)果。這與 OpenAI 形成鮮明對比——OpenAI 有大量學術背景人員浪費資源嘗試論文中的想法導致工程交付延遲而 xAI 絕不允許這種情況發(fā)生。工作強度是 xAI 的另一個顯著特征。全員每周工作 70 小時以上是常態(tài)體現(xiàn)了“絕不讓機器等人”的企業(yè)文化。工程師經(jīng)常在深夜 12 點爬起來查看 Loss 曲線和各種指標發(fā)現(xiàn)問題立即重新提交任務否則第二天就會浪費十幾個小時的訓練時間。這種強度與其他公司形成對比OpenAI、Anthropic、DeepMind 的核心團隊普遍每周工作 60 多小時Google 非核心部門甚至一周只上 3 天班。4. Anthropic聚焦策略與技術創(chuàng)新Anthropic 采取了明確的戰(zhàn)略聚焦將Coding設為第一優(yōu)先級Agents包括 Computer Use設為第二優(yōu)先級。同時Anthropic 一直在推廣 Skills 機制動態(tài)加載 Prompts認為這是非常重要的 Agent 技術。5. AI 人才戰(zhàn)史無前例的薪酬軍備競賽硅谷 AI 行業(yè)的薪酬水平已經(jīng)達到了令人震驚的程度。剛畢業(yè)的頂級 PhD年薪包可達 150-200 萬美元條件是研究水平較高雖然大部分是期權但 OpenAI 已經(jīng)足夠大可以兌現(xiàn)。在頂級 AI 公司有一定經(jīng)驗的算法工程師年薪包達到 400-500 萬美元條件是在頂級 AI 公司有相關經(jīng)驗或有知名學術工作。Meta Super Intelligence 級別的大神年薪包超過 1000 萬美元主要是 Meta 股票且可以兌現(xiàn)“一億美金招聘”的新聞確實屬實。Meta 的 Super Intelligence 團隊開始瘋狂挖人把整個市場的薪酬水平拉了起來。AI 與非 AI 工程師之間的薪資差距達到了驚人的 3-4 倍。非 AI 工程師年薪通常為 25-30 萬美元Google 正常水平而 AI 工程師年薪超過 100 萬美元。這意味著會 AI 和不會 AI 之間存在天壤之別的薪資差距行業(yè)已經(jīng)高度分化。營銷投入也達到了前所未有的規(guī)模。從舊金山機場出來高速公路兩側(cè)幾十公里范圍內(nèi)幾百個廣告牌基本都是 AI 公司的廣告。Snowflake 等傳統(tǒng)公司也在拼命講 AI 故事Redis 甚至打出了“My boss really wants you to know were an AI company”我老板非常想讓大家知道我們是 AI 公司這樣的廣告所有公司都在向 AI 靠攏。AI 人才戰(zhàn)與當年團購大戰(zhàn)的本質(zhì)區(qū)別非常明顯。團購時代的錢主要花在招運營、做地推、打廣告上核心是搶市場、搶商戶、搶用戶采用人海戰(zhàn)術而 AI 大戰(zhàn)的錢主要花在招頂尖人才和購買 GPU 上核心是訓模型、拼算力、搶人才采用精英戰(zhàn)術。基座模型公司核心研究團隊的人均算力配置達到 500-1000 張 GPU人均薪酬超過百萬美元人的薪酬和硬件成本已經(jīng)在同一數(shù)量級?；Ｐ凸久媾R的資源困局使得它們只能專注于“大事”。由于每個人的機會成本極高必須做能夠影響數(shù)億用戶的通用能力不能讓年薪幾百萬的員工去做垂直領域的小場景應用。垂直領域市場規(guī)模小投入產(chǎn)出比算不過來讓年薪幾百萬的人做一個垂直行業(yè)顯然不經(jīng)濟。因此這些公司只能聚焦于數(shù)學、編程、電腦使用、深度研究等影響所有用戶的基礎能力這才配得上他們的資源投入規(guī)模。這種現(xiàn)狀為創(chuàng)業(yè)公司提供了重要的機會窗口。6. 對創(chuàng)業(yè)公司的戰(zhàn)略啟示如何在巨頭夾縫中生存基于對硅谷巨頭的深入觀察我總結(jié)出創(chuàng)業(yè)公司在 AI 時代的幾條生存法則。首先絕對不要與基座模型公司正面硬碰。通用 Coding Agent、通用 Deep Research、通用 Computer Use 這些領域創(chuàng)業(yè)公司必敗無疑。原因很簡單真正懂模型訓練的人年薪極高創(chuàng)業(yè)公司融資幾百萬到幾千萬美元招幾個人錢就沒了訓練通用模型即使只是后訓練也需要幾百到幾千張卡創(chuàng)業(yè)公司根本租不起通用能力需要海量高質(zhì)量數(shù)據(jù)大廠擁有 YouTube、Web Search 等生態(tài)優(yōu)勢創(chuàng)業(yè)公司無法獲得這些數(shù)據(jù)。除非含著金鑰匙出生否則不要碰通用領域。其次不要輕易涉足模型訓練。真正懂模型的人都在大廠不會輕易出來創(chuàng)業(yè)公司根本挖不起中等水平的人做不出競爭力訓練模型需要大量試錯新手很容易把錢燒光還訓不出模型開源模型加微調(diào)的策略也面臨困境開源模型質(zhì)量比閉源模型差兩個數(shù)量級微調(diào)很難彌補這個差距除非是極其偏門的垂直領域。只有在針對特定場景的小模型、領域比較偏門通用模型能力不足、有明確數(shù)據(jù)優(yōu)勢的情況下才可以考慮訓練。第三采用正確的人才戰(zhàn)略。核心原則是招聘聰明、學習能力強但沒有 AI 背景的人。這個策略之所以有效是因為 AI 領域發(fā)展太快復利效應較弱最佳實踐每 3-6 個月就變一次。新人可以快速走到前沿聰明加學習能力強加肯鉆研6-12 個月就能達到業(yè)內(nèi)中等偏上水平不需要 PhD 學位和大廠背景但成本優(yōu)勢巨大相差 5-10 倍。最后保持正確的心態(tài)等待你的 Wave。不要被 AI 人才的天價薪酬產(chǎn)生焦慮。每個人和公司都有不同的發(fā)展階段他們能拿高薪是因為趕上了這一波浪潮在正確的時間做了正確的事情積累的技能恰好匹配當前需求。關鍵是保持相關性在沒有機會的時候不要放棄踏實打好基礎組建工程能力強、學習能力強、凝聚力強的團隊保持第一性原理思考緊密跟蹤最前沿的產(chǎn)品和研究預判模型和產(chǎn)品趨勢當機會來臨時已經(jīng)準備就緒能夠快速開發(fā)產(chǎn)品并快速推向市場在用戶量增長時構建起數(shù)據(jù)飛輪。ChatGPT、Gemini App、Cursor 都擁有數(shù)據(jù)飛輪這是成功的關鍵。核心技術實踐Context Engineering 與文件系統(tǒng)1. Context Engineering上下文工程這是 Anthropic 團隊重點強調(diào)的技術方向也是我們和 Anthropic 專家在 re:Invent 會場深入討論的核心話題。Context Engineering 被定義為“優(yōu)化 token 效用以對抗 LLM 固有約束的學科”The discipline of optimizing the utility of tokens against the inherent constraints of LLMs。這一定義揭示了在大語言模型應用中如何高效利用有限的上下文空間來達成最佳性能的核心命題。1.1 Context Engineering 的完整框架Anthropic 提出了一個系統(tǒng)化的 Context Engineering 框架該框架圍繞四個核心維度展開每個維度都有其獨特的設計原則和實踐方法。維度一System Prompt系統(tǒng)提示在系統(tǒng)提示的設計中核心原則可以概括為“Say less, mean more”即“少說但意思更明確”。這要求我們使用最少但最精準的指令來傳達意圖采用清晰、簡單、直接的語言進行表達。同時內(nèi)容需要以結(jié)構化的方式組織并把握合適的抽象層次既不能過于死板僵化也不能流于模糊不清。維度二Tools工具設計工具設計遵循“Every tool earns its place”的原則意味著每個工具都必須證明其存在價值。優(yōu)秀的工具應該是自包含且獨立的功能之間不存在重疊目的明確清晰。此外工具需要具備明確的參數(shù)定義、簡潔清晰的描述以及清晰可辨的成功和失敗模式讓使用者能夠準確預判工具的行為表現(xiàn)。維度三Data Retrieval數(shù)據(jù)檢索數(shù)據(jù)檢索的核心原則是“Load what you need, when you need it”即按需加載。這種理念體現(xiàn)在 JIT ContextJust-In-Time 上下文的實踐中要求我們在預加載和動態(tài)獲取之間找到平衡點。理想的系統(tǒng)應該允許 Agent 自主獲取所需數(shù)據(jù)通過設計良好的檢索工具來實現(xiàn)這一目標。正如 Anthropic 的專家所言“不要發(fā)送整個圖書館發(fā)送一個圖書管理員”Dont send the entire library. Send a librarian這生動地詮釋了智能檢索的精髓。維度四Long Horizon Optimizations長期任務優(yōu)化對于需要長時間執(zhí)行的復雜任務核心策略包括采用歷史壓縮策略Compaction strategy來管理不斷增長的上下文通過結(jié)構化的筆記記錄Structured note-taking來保存關鍵信息以及在適當時機使用 Sub-Agent 架構來分解復雜任務。這些策略共同確保了系統(tǒng)在長期運行中保持穩(wěn)定和高效。1.2 Data Retrieval 的范式轉(zhuǎn)變在數(shù)據(jù)檢索領域正在發(fā)生一場從傳統(tǒng)方法到現(xiàn)代方法的重要轉(zhuǎn)變。傳統(tǒng)的 Pre-Loading 方法也就是傳統(tǒng)的 RAG 方式傾向于預先加載所有可能相關的數(shù)據(jù)這種做法雖然簡單直接但往往導致大量無用信息占據(jù)寶貴的上下文空間。新的 Just-In-Time 即時加載方法代表了 Context Engineering 最重要的轉(zhuǎn)變之一它包含三個核心策略。策略一Lightweight Identifiers輕量級標識符這一策略的核心理念是傳遞 ID 而非完整對象Agent 只在真正需要時才請求詳細信息。舉例來說系統(tǒng)可以傳遞user_id: 12345這樣的標識符當 Agent 需要完整信息時再調(diào)用get_user()函數(shù)來獲取完整的用戶資料。這種方式大大減少了不必要的數(shù)據(jù)傳輸。策略二Progressive Disclosure漸進式披露漸進式披露強調(diào)從摘要信息開始讓 Agent 根據(jù)實際需要逐步深入探索。典型的應用場景是文件處理流程先展示文件列表需要時再提供文件元數(shù)據(jù)最后才加載完整的文件內(nèi)容。這種層層遞進的方式既保證了信息的可得性又避免了信息過載。策略三Autonomous Exploration自主探索自主探索的理念是提供發(fā)現(xiàn)工具而非直接進行數(shù)據(jù)轉(zhuǎn)儲。這種 Agentic Search 的方式讓 Agent 能夠自主導航信息空間主動尋找所需信息。例如系統(tǒng)可以提供search_docs()和read_doc(detail_level)這樣的工具而不是一次性加載所有文檔。這賦予了 Agent 更大的自主權和靈活性。1.3 Context Window 與 Context RotContext Window 的限制所有前沿的大語言模型都面臨著一個根本性限制單次交互能處理的最大 token 數(shù)是有限的。以 Anthropic 為例其 context window 容量為 200k tokens。什么是 Context Rot上下文腐化然而即使在這個限制范圍內(nèi)隨著上下文的不斷增長輸出質(zhì)量也會出現(xiàn)下降趨勢這種現(xiàn)象被稱為 Context Rot上下文腐化。上下文腐化的產(chǎn)生源于多個相互關聯(lián)的因素。首先是 Context Poisoning上下文污染當上下文中存在相互沖突的信息時模型的推理能力會受到破壞。其次是 Context Distraction上下文干擾過多無關信息會轉(zhuǎn)移模型的注意力使其難以聚焦于真正重要的內(nèi)容。第三個因素是 Context Confusion上下文混淆當上下文中存在大量相似項時模型對這些信息的區(qū)分能力會變得模糊。最后是 Context Clash上下文沖突當不同指令之間存在相互矛盾時模型將難以決定遵循哪一條指令。研究結(jié)論Chroma 的技術報告《Context-Rot: How Increasing Input Tokens Impacts LLM Performance》的研究結(jié)論表明所有模型在處理長上下文時都會出現(xiàn)性能下降這是一個普遍存在的挑戰(zhàn)。1.4 三種長期任務策略當任務的復雜度超過 context window 容量時我們需要采用特殊的策略來應對。Anthropic 提出了三種行之有效的解決方案。策略一Compaction壓縮壓縮策略的核心做法是定期總結(jié)中間步驟并對歷史信息進行壓縮處理。系統(tǒng)會用壓縮后的摘要來重置上下文只保留關鍵信息以供后續(xù)使用。這種方法的權衡在于我們需要犧牲部分細節(jié)來換取系統(tǒng)持續(xù)運行的能力。例如與其保留完整的對話歷史不如壓縮為“用戶想要 X嘗試了 Y學到了 Z”這樣的精煉摘要。策略二Structured Memory/Note-taking結(jié)構化記憶/筆記結(jié)構化記憶策略讓 Agent 維護顯式的記憶工件這些工件存儲在外部的持久化存儲中。Agent 可以在這些“工作筆記”中記錄決策過程、關鍵學習和當前狀態(tài)所有信息都以結(jié)構化格式保存。當需要時系統(tǒng)按需檢索這些信息而不是將所有內(nèi)容都保留在上下文中。典型的應用包括決策日志和關鍵發(fā)現(xiàn)文檔這些文檔成為 Agent 的“外部大腦”。策略三Sub-Agent Architectures子代理架構子代理架構通過將復雜任務分解為多個專門的 Agent 來應對挑戰(zhàn)。每個 Sub-Agent 都擁有專注、清晰、狹窄的上下文只負責特定的子任務。Main Agent 則負責編排整個流程并綜合各個 Sub-Agent 的結(jié)果。例如一個代碼審查 Agent 可以啟動專門的文檔檢查 Sub-Agent 來處理特定的審查任務。1.5 Skills 機制的工作原理什么是 SkillsSkills 是包含指令、腳本和資源的組織化文件夾Claude 可以動態(tài)發(fā)現(xiàn)和加載。Progressive Disclosure 的實現(xiàn)pdf/SKILL.md (主文件) ├── YAML Frontmatter (name, description) ├── Overview (概述) └── References: For advanced features, see /reference.md pdf/reference.md (詳細參考) └── Advanced PDF processing features... pdf/forms.md (專門功能) └── PDF form filling instructions...在這個結(jié)構中Claude 可以根據(jù)需要導航并發(fā)現(xiàn)更多細節(jié)。Discovery 機制讓 Claude 能夠逐步深入探索而 Executable Scripts 則提供了 token 高效性對于那些用傳統(tǒng)代碼更好完成的操作這種方式提供了確定性和可靠性。Skills 在不同產(chǎn)品中的應用方式也各有特色。在 Apps 中Skills 會被自動調(diào)用提供最佳的用戶體驗。在 Developer Platform 上開發(fā)者可以通過 Code Execution API 將 Skills 部署到產(chǎn)品中。而在 Claude Code 環(huán)境中Skills 同樣會被自動調(diào)用特別適合開發(fā)者的工作流程。1.6 Tool Design 最佳實踐優(yōu)秀的工具設計需要兼顧多個要素。首先工具應該有簡單準確的名稱讓使用者一目了然。其次需要提供詳細且格式良好的描述包含工具返回什么信息、如何正確使用等關鍵說明。在設計多個工具時必須避免過于相似的工具名稱或描述以免造成混淆。實踐表明工具執(zhí)行單一操作時效果最好參數(shù)嵌套層次盡量控制在一層以內(nèi)。提供清晰的示例也至關重要這些示例應該展示期望的輸入和輸出格式。同時開發(fā)者需要注意工具結(jié)果的格式化確保返回的信息易于理解和處理。最后但同樣重要的是必須對工具進行充分測試確保 Agent 能夠很好地使用它們。1.7 Context Engineering 的實戰(zhàn)案例案例 1Deep Research AgentDeep Research Agent 面臨的挑戰(zhàn)極具代表性它需要閱讀和分析大量文檔需要進行多輪搜索和分析在這個過程中Context 很容易出現(xiàn)爆炸式增長。通過應用 Progressive Disclosure 原則這個問題得到了有效解決。整個流程被分為三個階段在第一階段搜索Main Agent 負責規(guī)劃整體的搜索策略。在第二階段分析系統(tǒng)啟動多個 Sub-Agent 來分析每篇文檔。這些 Sub-Agent 只接收文檔 ID 和分析目標這樣的輕量級標識符只在需要時才讀取完整文檔內(nèi)容。在第三階段綜合一個全新的 Agent 負責綜合所有分析結(jié)果。這個 Agent 讀取所有 Sub-Agent 寫入的分析文件這體現(xiàn)了 Structured Memory 的應用最終生成完整的研究報告。案例 2Coding AgentCoding Agent 是 Context Engineering 框架的完美應用示范。在 System Prompt 層面它包含明確的編碼規(guī)范和架構指引。在 Tools 層面它配備了 ls、read、write、edit、grep、bash 等自包含的工具。在 Data Retrieval 層面它通過 grep 和 search 工具按需加載文件而不是預加載整個代碼庫。在 Long Horizon 層面它利用文件系統(tǒng)記錄決策和狀態(tài)使用 Sub-Agent 處理獨立的文件修改任務。1.8 有效建立和維護上下文的收益挑戰(zhàn)解決方案收益Handle context window limitsCompaction, Sub-Agents, Structured MemoryReliability可靠性Reduce context rotProgressive Disclosure, JIT LoadingAccuracy準確性Optimize for prompt cachingStructure context properlyCost Latency成本與延遲1.9 不同模型的 Context Engineering 策略不同的大語言模型對 Context Engineering 的響應方式存在顯著差異這要求我們根據(jù)具體模型調(diào)整策略。Claude (Anthropic)對于 ClaudeAnthropic而言優(yōu)先使用 Skills 機制能夠取得最佳效果。動態(tài)加載 Prompts 在 Claude 上表現(xiàn)優(yōu)異因為該模型在訓練時專門針對動態(tài)上下文更新場景進行了優(yōu)化天然支持 Progressive Disclosure 的理念。GPT (OpenAI) 和 Gemini (Google)相比之下GPTOpenAI和 GeminiGoogle則不推薦使用動態(tài)加載方式因為效果不夠理想。對于這些模型更好的實踐是在開頭的 System Prompt 中明確定義所有規(guī)則。當需要引入新規(guī)則時建議采用總結(jié)當前狀態(tài)并啟動新 Agent 的方式。不過Sub-Agent 架構用于隔離任務在這些模型上同樣有效Progressive Disclosure 和 JIT Loading 等策略依然適用。通用建議通用的建議是充分利用每個模型的特性不要生搬硬套其他模型的最佳實踐。雖然四個維度的框架System Prompt、Tools、Data Retrieval、Long Horizon是普適的但在具體實施時需要根據(jù)場景選擇最合適的模型和策略。2. 文件系統(tǒng)作為 Agent 的交互總線Anthropic 提出了一個頗具洞見的觀點Coding Agent 是所有通用 Agent 的基礎。這一觀點得到了業(yè)界的廣泛認同Manus 在一篇關于上下文工程的經(jīng)典文章中也指出文件系統(tǒng)是 Agent 架構的核心組成部分。3. 為什么要用文件系統(tǒng)要理解文件系統(tǒng)的重要性我們首先需要認識到 Tool Call 一次性輸出大量內(nèi)容所帶來的問題。Tool Call 一次輸出大量內(nèi)容的問題從穩(wěn)定性角度看當 Tool Call 需要一次性輸出幾百行內(nèi)容時如果中途發(fā)生中斷之前所做的所有工作都會付諸東流無法實現(xiàn)斷點恢復。從迭代性角度看Tool Call 的輸出是一次性的無法進行修改。如果想要改動其中某一段內(nèi)容就必須重新生成全部內(nèi)容這使得“草稿-修改-定稿”這樣自然的工作流程難以實現(xiàn)。文件系統(tǒng)的優(yōu)勢文件系統(tǒng)則完美地解決了這些問題。從持久化的角度看內(nèi)容一旦寫入文件就會被永久保存即使 Agent 崩潰文件依然存在可以隨時恢復并繼續(xù)工作。從可迭代性的角度看我們可以讀取文件內(nèi)容修改其中的某一部分可以多次修改并逐步完善這種工作方式就像人類撰寫文檔一樣自然流暢。文件系統(tǒng)還具有出色的通用性。無論是ls命令用于列出文件read_file用于讀取內(nèi)容write_file用于寫入內(nèi)容edit_file用于修改內(nèi)容還是delete_file用于刪除文件所有主流的大語言模型都能理解并正確執(zhí)行這些操作。這種普遍的兼容性使得基于文件系統(tǒng)的 Agent 架構具有極強的可移植性。3.1 Coding Agent 作為基礎能力當我們談論 Coding 作為基礎能力時需要理解這里的“Coding”是廣義的概念。為什么說 Coding 是基礎它不僅僅指編寫 Python 或 Java 代碼更包括撰寫文檔、生成報告以及創(chuàng)建任何結(jié)構化內(nèi)容。其核心本質(zhì)在于對文件的讀寫和編輯操作。Deep Research 的案例Deep Research 的案例生動地展示了這一理念。當系統(tǒng)需要生成一份長篇研究報告時錯誤的做法是嘗試用 Tool Call 一次性輸出整個報告。這種方式面臨的問題是幾千行的內(nèi)容輸出過程容易中斷而且寫完之后無法進行修改。正確的做法是充分利用文件系統(tǒng)的能力首先使用write_file(report.md, ...)寫入第一章內(nèi)容然后進行更多調(diào)研接著使用append_file(report.md, ...)添加第二章如果發(fā)現(xiàn)第一章需要修改可以隨時使用edit_file(report.md, ...)進行調(diào)整。所有主流模型都有很強的 Coding 能力值得注意的是所有主流的大語言模型都具備很強的 Coding 能力這為基于文件系統(tǒng)的 Agent 架構提供了堅實的技術基礎。3.2 Main Agent 和 Sub-Agent 的信息傳遞在 Agent 系統(tǒng)的架構設計中一個關鍵問題是 Main Agent 和 Sub-Agent 之間如何高效地傳遞信息。為什么用文件系統(tǒng)而不是函數(shù)調(diào)用相比于傳統(tǒng)的函數(shù)調(diào)用方式文件系統(tǒng)提供了更優(yōu)雅的解決方案。函數(shù)調(diào)用方式存在明顯的局限性它需要序列化復雜的數(shù)據(jù)結(jié)構字符串長度受到嚴格限制整體靈活性不足。文件系統(tǒng)的優(yōu)勢而文件系統(tǒng)則展現(xiàn)出明顯的優(yōu)勢。在這種架構下Main Agent 將任務描述和輸入數(shù)據(jù)寫入文件Sub-Agent 讀取這些文件執(zhí)行指定任務然后將結(jié)果寫回到新的文件中最后 Main Agent 讀取結(jié)果文件并繼續(xù)執(zhí)行下一步操作。這種方式建立了清晰的輸入輸出邊界就像 Unix 管道那樣優(yōu)雅而高效。重點 QA 實錄Q1垂直領域做微調(diào)Finetune還是用閉源模型經(jīng)過深入分析我的結(jié)論是閉源模型 Context Engineering 開源模型 Finetune。這個判斷基于幾個關鍵因素閉源模型在知識密度、思維密度以及泛化能力方面都顯著領先開源模型。閉源模型的 CoT思維鏈更加緊湊高效而開源模型往往需要冗長的推理過程。只有在三種特殊情況下才建議考慮開源模型微調(diào)領域極其偏門、數(shù)據(jù)隱私要求極高、或者成本極度敏感。需要特別注意的是小模型如 MiniMind在處理復雜邏輯推理數(shù)據(jù)時很容易訓練崩潰這是一個需要謹慎考慮的技術風險。Q2個人化Personalization是真問題嗎個人化絕對是真問題而且是未來的核心競爭力。理想的 AI 應該能夠適應每個用戶的價值觀和偏好提供真正個性化的服務。然而技術實現(xiàn)上存在顯著的難度差異。事實信息如生日、地址等相對容易處理但用戶偏好User Preference極其困難。主要挑戰(zhàn)在于用戶偏好具有強烈的上下文依賴性容易出現(xiàn)過度泛化的問題——比如用戶的一次性行為被系統(tǒng)誤認為是長期偏好。解決這個問題需要構建精細的 Evaluation 體系來平衡個性化程度這是一個需要長期投入的技術方向。Q3端云協(xié)同 Agent 的前景和挑戰(zhàn)端云協(xié)同是必然趨勢因為 Agent 需要在后臺持續(xù)運行而云端擁有更強大的算力資源。然而核心挑戰(zhàn)在于APP 狀態(tài)同步問題。這包括幾個具體難點登錄狀態(tài)沖突如微信的單點登錄限制、IP 地址差異觸發(fā)的風控機制、以及重復登錄帶來的用戶體驗問題。理想的解決方案是實現(xiàn)系統(tǒng)級狀態(tài)同步類似豆包手機采用的“影子系統(tǒng)”技術或者更理想的操作系統(tǒng)級 APP 鏡像同步機制。這需要在系統(tǒng)架構層面進行深度創(chuàng)新而不是簡單的應用層解決方案。Q4對我們使用 AI 寫代碼有什么建議核心原則是人必須懂的比 AI 多。在 AI 編程時代人的角色應該從 Coder 轉(zhuǎn)變?yōu)?Architect Reviewer。建議的工作流程是由人進行需求拆解確保單個任務控制在 500 行以內(nèi)前端可放寬至 2000 行然后由 AI 進行具體的編碼實現(xiàn)接著運行自動化測試和多 Agent 代碼 Review最后由人進行 Final Review重點檢查業(yè)務邏輯合理性和整體架構一致性。這種分工能夠最大化發(fā)揮人和 AI 的各自優(yōu)勢同時確保代碼質(zhì)量和系統(tǒng)穩(wěn)定性。Q5如何保證模型升級后工作流還能正常運行唯一的答案是建立完善的Evaluation評估體系。這是因為基座模型的升級、Prompt 的調(diào)整都可能帶來意想不到的變化僅憑主觀判斷很難發(fā)現(xiàn)潛在的回歸錯誤Regression。一套完整的評估體系應該包括持續(xù)更新的測試數(shù)據(jù)集能夠覆蓋各種邊緣情況基于細則Rubric-based的評估標準確保評判的客觀性和一致性自動化運行和報告機制及時發(fā)現(xiàn)問題以及問題閉環(huán)優(yōu)化流程確保發(fā)現(xiàn)的問題得到有效解決。這種科學化的方法論是確保系統(tǒng)穩(wěn)定性的唯一可靠途徑。Q6如何獲取 AI 前沿信息最推薦的渠道是X(Twitter)。這個平臺是第一手論文發(fā)布、技術討論和行業(yè)大佬分享見解的源頭。很多國內(nèi)的 AI 資訊賬號的內(nèi)容實際上也源自 Twitter 上的討論和分享。Twitter 的實時性和開放性使其成為了解 AI 前沿動態(tài)最有效的平臺無論是新論文發(fā)布、技術突破、還是行業(yè)趨勢討論都能在第一時間獲得最新信息。Q7顧此失彼的 Prompt 怎么辦這個問題有兩個有效的解決方案。第一個解決方案是使用 Evaluation 防止 Regression。通過自動化評估體系可以確保對 Prompt 的修改不會破壞現(xiàn)有功能任何改動都需要通過完整的測試驗證。第二個解決方案是結(jié)構化的 Prompt 組織。不要簡單地堆砌規(guī)則而是要像編寫“新員工手冊”一樣構建有層次結(jié)構和邏輯指導的 Prompt 體系充分考慮各種情況和例外場景。這種結(jié)構化的方法能夠減少規(guī)則間的沖突提高系統(tǒng)的穩(wěn)定性和可維護性。如果你對文中這些實踐細節(jié)本身就很感興趣想知道它們在真實項目里是怎么一步步落地的我的Agent 實戰(zhàn)營以及正在寫的新書基本就是圍繞這些場景展開的系統(tǒng)整理。期待你的加入