整理 | 褚杏娟

OpenFGA 核心維護者、Ona（前 Gitpod）軟件工程師 Siddhant Khare 最近寫了一篇博客吐槽了自己在使用 AI 編程中的“疲憊感”。

他以自身經(jīng)歷指出 AI 帶來的職業(yè)疲憊真實存在且被行業(yè)集體回避：單任務(wù)變快≠工作變輕松，反而更累，期間工程師任務(wù)量膨脹、頻繁切換引發(fā)深層耗竭；工作角色從創(chuàng)造者轉(zhuǎn)為高消耗的 AI 產(chǎn)出評審者，加之 AI 輸出的不確定性打破了工程師熟悉的確定性邏輯，持續(xù)帶來焦慮。

同時，行業(yè)技術(shù)迭代過快形成 “FOMO 跑步機”，頻繁追新工具造成時間浪費與知識衰減，還易陷入 “prompt 螺旋” 陷阱，長期依賴更會導(dǎo)致獨立思考能力退化，社交媒體的高光展示則進(jìn)一步加劇比較焦慮。他指出，AI 時代工程師的核心能力并非極致使用 AI，而是懂得設(shè)邊界、及時停止，保護認(rèn)知資源，追求可持續(xù)的長期產(chǎn)出。

他的博文引發(fā)了工程師們的共鳴。

“對我來說，這種疲憊感有點不一樣，它來自于不斷在‘寫一點代碼 / 做一點工作 / 看一點 review’和“‘停下來等大模型生成結(jié)果’之間來回切換。等待的時間是不可預(yù)測的，你根本不知道是該繼續(xù)等，還是該切去做別的事。于是你只能在機器“思考”的時候，隨便干點事打發(fā)時間。

你永遠(yuǎn)進(jìn)不了心流狀態(tài)，只能時刻盯著后臺任務(wù)什么時候跑完。這種持續(xù)的“警覺等待”會讓人特別消耗精力。我并不覺得自己更高效了，反而感覺自己像個偷懶的保姆，只是勉強看著孩子別把自己弄傷而已?！遍_發(fā)者 Parpfish 跟帖道。

“我知道這建議聽起來既不負(fù)責(zé)任又很幼稚，但我現(xiàn)在的做法是：每次給 Claude Code 提一個不知道要跑多久的請求，我就點上一根煙，放松一下。有時候我也會切去玩那種隨時拿起來、隨時放下都不影響的小游戲?！?/p>

“對我個人來說，編程很多年前就沒什么樂趣了，”Parpfish 也表示，“但有了 Claude Code 之后，我又重新覺得好玩起來了。雖然感覺不一樣，但在我現(xiàn)在這個人生階段，這樣反而更讓我享受?！?/p>

下面是 Siddhant Khare 的文章，我們進(jìn)行了翻譯，以饗讀者。

AI 疲憊真實存在，

但幾乎沒人談

你用 AI 是為了更高效，為什么反而比以前更累？這是每個工程師都得正視的悖論。

上個季度，我交付的代碼量超過職業(yè)生涯任何一個季度；同時，我也比職業(yè)生涯任何一個季度都更疲憊。這兩件事并不矛盾，甚至高度相關(guān)。

我的工作就是搭建 AI agent 的基礎(chǔ)設(shè)施。我是 OpenFGA（CNCF Incubating）的核心維護者之一；做過用于 agent 授權(quán)的 agentic-authz；做過用于上下文去重的 Distill；上線過 MCP servers。我不是偶爾玩玩 AI 的那種人，我在這個領(lǐng)域深扎很久，我寫的工具，正被其他工程師拿去把 AI agents 跑進(jìn)生產(chǎn)環(huán)境。

但即便如此，我還是撞墻了。那種疲憊不是換一套工具、再優(yōu)化一點流程就能解決的，而是一種更底層的耗竭感。

如果你是每天都在用 AI 的工程師，做設(shè)計評審、生成代碼、排查 bug、寫文檔、做架構(gòu)決策，并且你發(fā)現(xiàn)自己在“AI 時代”反而比以前更累，那這篇文章就是寫給你的。你沒有在幻想，也不是你不夠強。你感受到的是真實存在的東西，只是行業(yè)在集體回避它：大家拼命講效率、講產(chǎn)出，卻不講代價。一個全職做 agent 基建的人都能在 AI 上 burnout，這件事可能發(fā)生在任何人身上。

我想實話實說。不是那種“AI 太神了，這是我的工作流”的版本，而是真實版本：夜里 11 點，你盯著屏幕，周圍堆著一大片 AI 生成的代碼還得你去 review，你開始懷疑那個本該幫你省時間的工具，為什么反而吞掉了你整天的時間。

沒有人提醒過我們的悖論

有件事我曾經(jīng)想了很久才想明白：AI 的確能讓單個任務(wù)更快，這不是謊言。以前要 3 小時的事情，現(xiàn)在 45 分鐘就能搞定，寫設(shè)計文檔、搭服務(wù)骨架、補測試用例、研究不熟的 API……都更快了。

但我的工作日變得更難了，不是更輕松，而是更難。

原因一旦看清就很簡單，只是我花了幾個月才真正意識到：當(dāng)每個任務(wù)變快，你不會做更少的任務(wù)，你只會做更多。你的“產(chǎn)能”看起來提升了，于是工作會膨脹來填滿它，甚至還會超出。你的領(lǐng)導(dǎo)看到你交付變快了，預(yù)期會跟著調(diào)整；你看到自己交付變快了，對自己的預(yù)期也會跟著調(diào)整?；鶞?zhǔn)線被整體抬升。

在 AI 之前，我可能會用整整一天只專注一個設(shè)計問題：在紙上畫草圖、洗澡時想、出去走走、回來突然清晰。節(jié)奏慢，但認(rèn)知負(fù)擔(dān)可控，一天只扛一個問題，深度專注。

現(xiàn)在呢？一天可能要摸六個問題。每個問題都“只要一小時，AI 幫你很快搞定”。但在六個問題之間來回切換，對人腦的代價極其昂貴。AI 不會在問題之間疲憊，我會。

這就是悖論：AI 降低了“生產(chǎn)”的成本，卻抬高了“協(xié)調(diào)、評審、決策”的成本，而這些成本幾乎全部落在人的身上。

你變成了 reviewer，

而你從沒簽過這份合同

以前我的工作流程是：想清楚問題 → 寫代碼 → 測試 → 發(fā)布。我是創(chuàng)造者，是建造者，這也是很多人最初喜歡工程的原因：能親手把東西做出來。

AI 之后，我的工作越來越像：寫 prompt → 等 → 讀輸出 → 評估輸出 → 判斷是否正確 → 判斷是否安全 → 判斷是否符合架構(gòu) → 修不對的部分 → 再 prompt → 再重復(fù)。我變成了審稿人、裁判、質(zhì)檢員，站在一條永不停歇的流水線旁邊。

這是一種完全不同的勞動類型。創(chuàng)造會給人能量，評審會消耗能量。相關(guān)研究早就指出，“生成型任務(wù)”和“評估型任務(wù)”在心理體驗上截然不同：生成更容易進(jìn)入心流，評估更容易觸發(fā)決策疲勞。

我第一次明確意識到這點，是在某一周用 AI 重度開發(fā)一個新 microservice 的時候。到周三，我連簡單的決定都做不動了：這個 function 該叫什么？無所謂。配置放哪？也無所謂。我的大腦不是因為寫代碼累，而是因為“判斷代碼”累，每天一整個時間都在做無數(shù)個細(xì)小判斷，會把你掏空。

更殘酷的是：AI 生成的代碼，往往比人寫的更需要謹(jǐn)慎 review。人寫的代碼我大致知道對方的習(xí)慣、長處、盲點：可信的地方可以快掃，不放心的地方重點看。AI 不一樣，每一行都值得懷疑。代碼看起來很自信，能編譯，甚至能過測試，但可能在極隱蔽的地方錯得很深，直到線上、在高壓負(fù)載下、凌晨三點才爆出來。

于是你只能逐行讀。讀自己沒寫過、由一個不了解你代碼庫歷史和團隊約定的系統(tǒng)生成出來的代碼，是一種非常消耗人的工作。

這也是為什么我一直覺得 agent 安全和權(quán)限這么重要。我們不可能 review AI 產(chǎn)出的所有東西，規(guī)模一上來就做不到了，那就必須先在系統(tǒng)層面約束 agent 能做什么：最小權(quán)限原則、范圍限制 tokens、審計軌跡。你越不需要擔(dān)心“AI 會不會做出危險動作”，你越能把認(rèn)知預(yù)算留給真正重要的工作。這不僅是安全問題，更是“人能否長期承受”的可持續(xù)問題。

非確定性問題：AI 破壞了

工程師最熟悉的契約

工程師從業(yè)訓(xùn)練的底層假設(shè)是確定性：同樣的輸入，得到同樣的輸出。它是調(diào)試的基礎(chǔ)，也是系統(tǒng)推理的基礎(chǔ)。

AI 把這份契約撕了。

我有個 prompt 周一跑得完美，生成了結(jié)構(gòu)清晰、很干凈的 API endpoint。周二我用同樣的 prompt 做一個類似 endpoint，輸出結(jié)構(gòu)卻明顯不同，這次錯誤處理換了套路，還引入了我沒要的依賴。

為什么？沒有原因。更準(zhǔn)確地說，沒有我能觸達(dá)的原因。這里沒有“模型今天換了想法”的 stack trace，也沒有日志告訴你“temperature sampling 走了 B 路徑不是 A 路徑”。它就是……不一樣了。

對一個職業(yè)生涯建立在“壞了我就能找到為什么”的人來說，這種體驗會帶來持續(xù)的、背景噪音式的焦慮。它不一定戲劇化，卻足夠磨人。你無法完全信任輸出，也無法真正放松，每一次交互都必須保持警惕。

我試過對抗，給 prompt 做版本控制，寫復(fù)雜的 system message，做模板。一部分有用，但都無法解決根本矛盾。你在和一個概率系統(tǒng)協(xié)作，而你的大腦天生更擅長確定性系統(tǒng)，這種錯位會長期產(chǎn)生低強度壓力。

也正因為這種挫敗感，我后來做了 Distill：為 LLM 做確定性的上下文去重，不調(diào)用 LLM，不用 embeddings，也不靠概率啟發(fā)式，而是用純算法，在大約 12ms 內(nèi)把 context 清理干凈。我至少想讓 AI pipeline 里有一段東西是可推理、可調(diào)試、可信的。模型輸出再怎么不確定，輸入至少要干凈、可控。

我發(fā)現(xiàn)適應(yīng)得最好的一批工程師，通常已經(jīng)“和不確定性和解”了。他們把 AI 當(dāng)作一個聰明但不靠譜的實習(xí)生寫的初稿，默認(rèn)要重寫其中 30%，并且提前把這部分重寫時間算進(jìn)計劃。他們不會因為輸出錯了而憤怒，因為他們從來沒期待它“正確”，只期待它“有用”。這兩者差別很大。

“FOMO 跑步機”：你永遠(yuǎn)追不上

深呼吸一下，試著只跟上最近幾個月的變化：Claude Code 先發(fā) sub-agents，再發(fā) skills，再發(fā) Agent SDK，再發(fā) Claude Cowork；OpenAI 上線 Codex CLI，又上 GPT-5.3-Codex，一個甚至“參與了自我編寫”的模型；新的 coding agents 宣布 background mode，可并發(fā)上百個 autonomous sessions；Google 推出 Gemini CLI；GitHub 增加 MCP Registry；并購幾乎每周發(fā)生；Amazon Q Developer 得到 agentic 升級；CrewAI、AutoGen、LangGraph、MetaGPT，隨便挑一個 agent framework，每周都冒出新版本；Google 發(fā)布 A2A（Agent-to-Agent protocol）對標(biāo) Anthropic 的 MCP；OpenAI 發(fā)布自己的 Swarm framework；Kimi K2.5 采用 agent swarm 架構(gòu)，編排 100 個并行 agents；“Vibe coding”成了熱詞；OpenClaw 上線 skills marketplace，一周之內(nèi)研究者在 ClawHub 發(fā)現(xiàn) 400+ 惡意 agent skills；與此同時 LinkedIn 還會冒出一句話：“2026 年不做 sub-agent orchestration，你就已經(jīng)過時了?！?/p>

這還不是一年發(fā)生的事，是短短幾個月，并且我還漏掉了很多。

我也曾深陷其中：周末不斷評測新工具，追每一條 changelog，看每一個 demo，拼命留在所謂“前沿”，因為我害怕落后。

現(xiàn)實是什么？周六下午我搭起一個新的 AI coding tool，周日形成基本 workflow，而到了下周三，社交網(wǎng)絡(luò)開始吹另一個“更強”的工具，我就會焦慮；下一個周末又去搭新的，舊的躺著吃灰。從一個 coding assistant 遷到下一個、再遷下一個，最后又回到第一個，每次遷移耗掉我一個周末，換來大概 5% 的提升，而且我還很難測出來。

把這種循環(huán)乘以所有類別：coding assistants、聊天界面、agent frameworks、多 agent 編排平臺、MCP servers、context 管理工具、prompt 庫、swarm 架構(gòu)、skills marketplace，你會變成一個永遠(yuǎn)在學(xué)習(xí)新工具、卻從沒真正把任何一個工具用深的人。Hacker News 首頁就足夠讓人眩暈：今天是“Show HN：Autonomous Research Swarm”，明天是“Ask HN：AI swarms 怎么協(xié)作？”沒人知道答案，但大家都在造。

更糟糕的是知識衰減。我在 2025 年初花了兩周搭出一套復(fù)雜的 prompt 工程流程：精雕 system prompts、few-shot examples、chain-of-thought 模板。它當(dāng)時非常好用，三個月后模型更新，最佳實踐遷移，一半模板反而不如一句簡短指令效果好。那兩周不是“投資”，而是“消耗”。我的 MCP server 也是：我寫了五個自定義 servers（Dev.to 發(fā)布、Apple Notes 集成、Python/TypeScript 沙盒等），后來協(xié)議演進(jìn)，GitHub 上線 MCP Registry，突然出現(xiàn)成千上萬預(yù)制 servers，我的部分工作一夜之間變得可有可無。

Agent framework 的 churn 更夸張。我見過團隊一年內(nèi)從 LangChain → CrewAI → AutoGen → 自研編排連續(xù)遷移。每次遷移都意味著重寫集成、重學(xué) API、重建 workflow。那些選擇“等等再說”的團隊，很多時候反而比早早沖進(jìn)去、被迫遷兩次的人更占便宜。

后來我換了策略, 不再追每個新工具，而是深挖它們下面的基礎(chǔ)設(shè)施層。工具會來會走，它們解決的問題不會。context 效率、agent authorization、audit trails、runtime security，這些是跨框架、跨周期的耐久問題，這也是我把 agentic-authz 建在 OpenFGA 上、而不是綁死某個 agent framework 的原因；也是 Distill 做 context 層、而不是 prompt 層的原因：要構(gòu)建在不那么 churn 的層上。

我仍然會密切關(guān)注生態(tài)，做基礎(chǔ)設(shè)施的人必須如此。但我關(guān)注是為了理解方向，而不是把每個新東西都立刻搬進(jìn)生產(chǎn)。信息充分和被動反應(yīng)，是兩回事。

“再改一版 prompt

就好了”陷阱

這個陷阱非常陰險：你讓 AI 生成一個很具體的東西，第一版 70% 是對的；于是你 refine prompt；第二版 75% 的對，但把第一版對的地方弄壞了；第三版 80% 對，但結(jié)構(gòu)又變了；第四次你回過神來，已經(jīng) 45 分鐘過去了，而你自己從頭寫可能 20 分鐘就寫完。

我叫它 prompt spiral，AI 時代的 yak shaving。你原本有明確目標(biāo)，半小時后卻在調(diào) prompt，而不是寫代碼。你在優(yōu)化“給模型的指令”，而不是解決真正的問題。

更危險的是，prompt spiral 會讓你產(chǎn)生“我在推進(jìn)”的錯覺。每一輪都有小進(jìn)步，你會繼續(xù)投入，但邊際收益正在快速遞減，你甚至忘了目標(biāo)從來不是“讓 AI 產(chǎn)出完美內(nèi)容”，而是交付功能。

我現(xiàn)在有一條硬規(guī)則：三次。三次 prompt 內(nèi)拿不到 70% 可用的結(jié)果，我就自己寫，沒有例外。這條規(guī)則省下的時間，超過我學(xué)過的任何 prompt 技巧。

完美主義遇上概率輸出：

最優(yōu)秀的人往往最難受

工程師傾向完美主義：喜歡干凈代碼、喜歡測試全綠、喜歡可預(yù)測系統(tǒng)。這不是缺點，是我們能做出可靠軟件的原因。

但 AI 輸出從來不是“完美”，永遠(yuǎn)是“還不錯”，大約 70–80%：變量名不對味，錯誤處理不完整，邊界條件沒考慮，抽象不符合你的代碼庫。能跑，但“不對”。

對完美主義者來說，這很折磨，因為“差一點對”比“完全錯”更糟。完全錯，你直接丟掉重來；差一點對，你會花一小時去修修補補。修 AI 輸出尤其痛苦，因為你在修“別人做的設(shè)計決策”，而這個“別人”并不分享你的審美、你的上下文和你的標(biāo)準(zhǔn)。

我不得不學(xué)會放下。不是放下質(zhì)量，我仍然在乎質(zhì)量，而是放下“AI 會產(chǎn)出質(zhì)量”的期待。我現(xiàn)在把每次 AI 輸出都當(dāng)作毛坯、當(dāng)作起點、當(dāng)作原材料。它出現(xiàn)的那一刻，我腦子里就貼上“draft”的標(biāo)簽。僅僅是這個心智框架的變化，就讓我的挫敗感減少了一半。

很多在 AI 上最痛苦的工程師，恰恰是最好的工程師：標(biāo)準(zhǔn)最高、細(xì)節(jié)最敏感、瑕疵一眼就能看出來。AI 獎勵的反而是另一種能力：能快速從不完美的輸出里榨取價值，而不把情緒綁定在“把它打磨到完美”。

思考能力在萎縮：

這才是最讓我害怕的

我在一次設(shè)計評審會上發(fā)現(xiàn)了這個問題。有人讓我在白板上推一個并發(fā)問題，沒有電腦、沒有 AI，只有我和一支筆，我居然卡住了。不是我不懂概念，我懂，而是我?guī)讉€月沒練這個“肌肉”了。我把“第一輪思考”外包給 AI 太久，導(dǎo)致從零推理的能力在退化。

它像 GPS 和導(dǎo)航。沒有 GPS 的年代，你會建立城市的心理地圖，能自己推路線。用了多年 GPS，你離開它就不會走了，因為這項技能已經(jīng)萎縮。

AI 對工程思考也是一樣：當(dāng)你總是先問 AI，你就少了自己掙扎的過程。而學(xué)習(xí)就發(fā)生在掙扎里：困惑是理解成形的地方。跳過它，你會更快拿到輸出，但理解會更淺。

我現(xiàn)在刻意讓每天的第一個小時不碰 AI：在紙上思考、手繪架構(gòu)、用慢的方法推問題。它確實低效，但它讓我的思考保持鋒利，而鋒利的思考會在我之后使用 AI 時帶來回報。因為你自己的推理被“熱身”后，你對 AI 輸出的評估會更準(zhǔn)確。

比較陷阱：社交媒體

只展示高光，不展示代價

社交媒體上到處都是“看起來已經(jīng)把 AI 玩明白的人”：曬 workflow、曬產(chǎn)出數(shù)據(jù)、曬“我兩小時用 AI 做完一個 app”。你回頭看自己的經(jīng)歷：prompt 失敗、時間浪費、生成代碼不得不重寫，于是你開始懷疑自己是不是哪里不對。

你沒有任何問題。那些帖子是高光剪輯。沒人會發(fā)：“我花了三小時讓 Claude 理解我的數(shù)據(jù)庫 schema，最后放棄，遷移還是手寫。”沒人會發(fā)：“AI 生成的代碼線上吞錯導(dǎo)致事故?！睕]人會發(fā)：“我很累?！?/p>

更麻煩的是，AI 技能很難衡量。傳統(tǒng)工程里，你看看代碼大致能判斷水平；AI 輸出卻受模型、prompt、上下文、temperature、甚至玄學(xué)因素影響。別人一個驚艷 demo，很可能在你的機器、你的代碼庫上復(fù)現(xiàn)不出來。

我后來對 AI 內(nèi)容變得更挑，我仍然關(guān)注這個領(lǐng)域，畢竟是工作，但我更少看“熱鬧”，更多看“真的在建和在交付的人”。信號和焦慮的比例很重要。如果一個信息流讓你更焦慮而不是更清醒，那它就不在為你服務(wù)。

真正有用的改變是什么

我具體說說，哪些做法讓我的 AI 使用方式從對抗變成可持續(xù)。

• 給 AI 使用設(shè)時間盒。我不再開放式使用 AI，會設(shè)定計時器：這件事用 AI 30 分鐘，時間到就交付現(xiàn)狀或自己寫。它同時攔住了 prompt spiral 和完美主義陷阱。

• 把思考時間和執(zhí)行時間分開。早上用來思考，下午用來 AI 輔助執(zhí)行。規(guī)則不絕對，但有默認(rèn)結(jié)構(gòu)，就能確保大腦既鍛煉也得到助力。

• 接受 AI 只做到 70%。我不再追求完美輸出，70% 可用就夠了，剩下我自己補。這個接受，是我減少 AI 挫敗感最有效的一件事。

• 對 hype cycle 保持策略性。我會跟蹤生態(tài)，但不再每個新工具一上線就立刻遷移。我只用一個主力 coding assistant，并把它用深。評估新工具看“幾個月后的驗證”，不看“幾天內(nèi)的熱度”。信息充分和被動反應(yīng)，是兩回事。

• 記錄 AI 什么時候幫忙、什么時候拖后腿。我做過兩周簡單日志：任務(wù)、是否用 AI、耗時、滿意度。數(shù)據(jù)非常清晰：AI 在樣板代碼、文檔、測試生成上省了大量時間；在架構(gòu)決策、復(fù)雜調(diào)試、需要深代碼庫上下文的工作上反而耗時。知道這一點后，我更清楚什么時候該用它，什么時候不該用。

• 不再試圖 review AI 產(chǎn)出的每一行。這很難接受，但如果你用 AI 生成大量代碼，你不可能以同樣嚴(yán)苛的標(biāo)準(zhǔn)逐行審。我的 review 精力集中在最關(guān)鍵的部分：安全邊界、數(shù)據(jù)處理、錯誤路徑；其它交給自動化測試和靜態(tài)分析。非關(guān)鍵代碼有一點粗糙是可以接受的。

可持續(xù)性問題：AI 不是治好

burnout，而是在放大它

科技行業(yè)的 burnout 早在 AI 之前就存在。AI 正在讓它更嚴(yán)重，不是因為 AI 很壞，而是因為 AI 移除了曾經(jīng)保護我們的“自然限速器”。

在 AI 之前，你一天能產(chǎn)出多少有上限：打字速度、思考速度、查資料的時間。這些限制有時令人沮喪，但它們也是一種“調(diào)速器”。工作本身會限制你把自己榨干的速度。

AI 拿掉了這個調(diào)速器?，F(xiàn)在唯一的上限是你的認(rèn)知耐力，而大多數(shù)人只有在把這條線沖破之后，才知道自己的極限在哪。

我在 2025 年末 burnout 了。不是戲劇化那種：我沒有辭職，也沒有崩潰。我只是開始不在乎了。code review 變成走過場，設(shè)計決策變成“AI 怎么說就怎么做”。我在機械地產(chǎn)出更多，卻感受更少。我花了一個月才意識到發(fā)生了什么，又花了一個月才恢復(fù)過來。

恢復(fù)并不是“少用 AI”，而是“換一種方式用 AI”：設(shè)邊界、有意圖，并且承認(rèn)我不是機器，我不需要跟機器同速。Working at Ona 讓我更清楚看到這一點：當(dāng)你為企業(yè)客戶做 AI agent 基礎(chǔ)設(shè)施，你會看到不可持續(xù)的 AI 工作流在規(guī)?；蟮摹叭祟惓杀尽薄＿@不是個人問題，而是系統(tǒng)問題，必須在工具層面解決，而不只是靠個人硬扛。

諷刺的是，我最好的幾個項目反而誕生在 burnout 期間。當(dāng)我停止追工具、開始思考到底哪里壞掉時，問題第一次變得清晰：context window 被垃圾填滿，這催生了 Distill；agents 拿著全權(quán)限 API key，這催生了 agentic-authz；無法審計 agent 做了什么，這正在變成 AgentTrace。疲憊迫使我停止消費、開始建設(shè)，不是更快地堆功能，而是更有意識地去做正確的東西。

AI 時代真正的技能

我認(rèn)為 AI 時代最重要的技能不是 prompt engineering，不是知道該用哪個模型，也不是擁有“完美工作流”，而是知道什么時候該停。

知道 AI 輸出什么時候“夠用”；知道什么時候該自己寫；知道什么時候該合上電腦；知道邊際提升不值得繼續(xù)消耗認(rèn)知；知道你的大腦是一種有限資源，保護它不是偷懶，而是一種工程能力。

我們做系統(tǒng)會優(yōu)化可持續(xù)性：加熔斷、做 backpressure、設(shè)計優(yōu)雅降級。我們也應(yīng)該對自己做同樣的事。

AI 是我用過最強的工具，同時也是最消耗人的工具，這兩件事可以同時成立。能在這個時代長期活得好的工程師，不會是用 AI 用得最多的人，而會是用得最聰明的人。

如果你很累，不是因為你做錯了，而是因為這件事本身就很難。工具很新，模式還在形成，行業(yè)卻裝作“更多產(chǎn)出 = 更多價值”。事實不是這樣。可持續(xù)的產(chǎn)出才是價值。

我依舊每天都在這個領(lǐng)域里建 agent authorization、context engineering、audit trails、runtime security，讓 AI agents 真正在生產(chǎn)環(huán)境可運行的基礎(chǔ)設(shè)施。我對 AI 的投入比以往更深，但我會按自己的節(jié)奏、用自己的邊界，去做真正重要的事，而不是追逐短暫的趨勢。

照顧好你的大腦。它只有一個，而任何 AI 都無法替代它。

https://siddhantkhare.com/writing/ai-fatigue-is-real

聲明：本文為 AI 前線整理，不代表平臺觀點，未經(jīng)許可禁止轉(zhuǎn)載。

會議推薦

InfoQ 2026 全年會議規(guī)劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產(chǎn)業(yè)落地，從技術(shù)前沿到行業(yè)應(yīng)用，全面覆蓋 AI 與軟件開發(fā)核心賽道！集結(jié)全球技術(shù)先鋒，拆解真實生產(chǎn)案例、深挖技術(shù)與產(chǎn)業(yè)落地痛點，探索前沿領(lǐng)域、聚焦產(chǎn)業(yè)賦能，獲取實戰(zhàn)落地方案與前瞻產(chǎn)業(yè)洞察，高效實現(xiàn)技術(shù)價值轉(zhuǎn)化。把握行業(yè)變革關(guān)鍵節(jié)點，搶占 2026 智能升級發(fā)展先機！

今日薦文

你也「在看」嗎？