news 2026/4/24 3:05:16

AI 让我更累了,这不是错觉

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
AI 让我更累了,这不是错觉

早上朋友问我:

“用 codex 开发项目的效果如何?”

“还行吧。基本一个人干一个项目没问题。你呢?”

“claude 幻觉有点严重,天天改 bug。改错一点,就得折腾半天”

“我让AI跑一个开源项目也是差不多这种。改一个bug,频繁改不好。哈哈哈”

然后我刷到了下面这篇文章,把我们遇到过,和没遇到过的,都写在了里面。


上个季度我写的代码比职业生涯中任何一个季度都多。

我也比任何时候都更累。这两件事不是没有关系的。

我是做 AI agent 基础设施的。

是 OpenFGA(CNCF 孵化项目)的核心维护者之一,我做了 agentic-authz(用于 agent 授权)、Distill(用于上下文去重)、还有各种 MCP server。

我不是那种业余玩玩 AI 的人。

我是真的深入其中。

我做的是其他工程师用来让 AI agent 在生产环境里跑起来的工具。

但是,我遇到了 AI Code 的困境。

那种无论用什么工具、怎么优化工作流都解决不了的疲惫。

如果你是个每天用 AI 的工程师:

用来做设计审查、生成代码、调试、写文档、做架构决策,然后你发现自己比 AI 出现之前更累了,这篇文章就是写给你的。

你不是在瞎想。

你不是太弱了。

你正在经历一个真实存在的问题,只是整个行业都在假装它不存在。

如果像我这样全职做 agent 基础设施的人都会因为 AI 而倦怠,那谁都可能。

我想诚实地聊聊这件事。

不是那种"AI 太神奇了,这是我的工作流"的版本。

这是真实的版本。

就是那种你在晚上 11 点盯着屏幕,被 AI 生成的代码包围着还需要审查,心里纳闷为什么本该节省时间的工具却消耗了你一整天的版本。

没人警告过我们的悖论

让我困惑了好一阵子的是:AI 确实让单个任务变快了。

这是真的。

以前要 3 小时的工作现在 45 分钟就能搞定。

写设计文档、搭建新服务、写测试用例、研究陌生的 API。

都变快了。

但开发工作变得更难了。

不是更轻松。而是更难。

原因其实很简单,但我花了好几个月才想明白。

当每个任务花的时间变少了,你不会做更少的任务。

你会做更多的任务。

你的能力看起来变大了,所以工作就会膨胀来填满它。甚至更多。

你的老板看到你交付得更快,期望值就会调整。

你看到自己交付得更快,你对自己的期望值也会调整。

产出的下限在向上移动。

在 AI 之前,我可能会花一整天时间处理一个设计问题。

我会在纸上画草图,洗澡的时候想,出去走走,回来的时候就有思路了。

节奏很慢,但认知负担是可控的。

一个问题。一天。深度专注。

现在呢?我可能在一天内碰六个不同的问题。

每个都"用 AI 只要一小时"。

但在六个问题之间来回切换,对人脑来说代价极其昂贵。

(我也是,会在不同问题之间切换,比如这篇:等待 AI 干活的时候你都在做什么。)

AI 在问题之间不会累。

我会。

这就是悖论:AI 降低了生产的成本,但增加了协调、审查和决策的成本。

而这些成本完全落在人类身上。

莫名其妙成了审查员

在 AI 之前,我的工作是:想一个问题,写代码,测试,发布。

我是创造者、制造者。

这就是我们大多数人当初被软件工程吸引的原因,构建成功的那种感觉。

在 AI 之后,我的工作越来越多地变成:

写提示词,等待,读输出,评估输出,判断输出对不对,判断输出安不安全,判断输出符不符合架构,修复不对的部分,重新提示,重复。

我成了审查员、法官。

一条永不停歇的装配线上的质量检查员。

这是两种根本不同的工作类型。

创造让人充满活力。

审查让人精疲力竭。

有研究证明了这一点:生成性任务和评估性任务之间的心理差异。

生成性工作给你心流状态。评估性工作给你决策疲劳。

我第一次注意到这一点是在一周内,我大量使用 AI 来开发一个新的微服务。

到了周三,我再也无法做出简单的决定了。

这个函数应该叫什么名字?

我不在乎。

这个配置应该放在哪里?

我不在乎。

我的大脑已经满了。不是因为写代码:而是因为判断代码。

成百上千个小判断,整天,每天。

残酷的是,AI 生成的代码比人写的代码需要更仔细的审查。

当同事写代码时,我知道他的模式、他的强项、他的盲点。

我可以略过我信任的部分,专注于我不信任的部分。

对于 AI,每一行都是可疑的。

代码看起来很自信。

它能编译。它甚至可能通过测试。

但它可能在生产环境中、在高负载下、在凌晨 3 点以微妙的方式出错。

所以你得阅读每一行。

阅读不是你写的、由一个不理解你代码库历史或你团队约定的系统生成的代码,是令人精疲力竭的工作。

这也是为什么我觉得 agent 安全和授权这么重要。

如果我们无法审查 AI 产生的所有内容——我们做不到,没法规模化——那么我们需要首先约束 agent 能做什么的系统。

最小权限访问、作用域 token、审计跟踪。

你越不需要担心"AI 是不是做了危险的事",你就越有认知预算用于真正重要的工作。

这不仅仅是安全问题。

这是人类可持续性问题。

不确定性问题

工程师接受的是确定性的训练。

相同的输入,相同的输出。

这就是约定。

这就是让调试成为可能的原因。

这就是让推理系统成为可能的原因。

AI 打破了这个模式。

我有一个在周一运行完美的提示词。

为一个 API 端点生成干净、结构良好的代码。

我在周二为类似的端点使用了相同的提示词。

输出在结构上不同,使用了不同的错误处理模式,还引入了我没要求的依赖项。

为什么?没有原因。

或者说,没有我能知道的原因。

没有"模型今天决定走另一条路"的堆栈跟踪。

没有"温度采样选择了路径 B 而不是路径 A"的日志。

它就是......不同了。

对于一个整个职业生涯建立在"如果它坏了,我能找出原因"之上的人来说,这是非常令人不安的。

是一种缓慢的、磨人的、背景噪音式的焦虑。

你永远无法完全信任输出。

你永远无法完全放松。

每次交互都需要警惕。

我试图对抗这个问题。

我对提示词进行版本控制。

我构建了详尽的系统消息。

我创建了模板。有些有帮助。

但没有一个解决了根本问题:你正在与一个概率系统协作,而你的大脑是为确定性系统设计的。

这种不匹配是一个持续的、低压力的来源。

这种挫败感实际上促使我构建了 Distill——用于 LLM 的确定性上下文去重。

没有 LLM 调用,没有嵌入,没有概率启发式方法。

纯算法在约 12 毫秒内清理你的上下文。

我希望 AI 管道的至少一部分是我可以推理、调试和信任的东西。

如果模型的输出将是不确定的,我至少可以确保输入是干净和可预测的。

我交谈过的处理得最好的工程师是那些已经与之和解的人。

他们把 AI 输出当作来自一个聪明但不可靠的实习生的初稿。

他们期望重写其中的 30%。

他们为这种重写预留时间。

当输出错误时他们不会感到沮丧,因为他们从未期望它是正确的。

他们期望它是有用的。

这和能用是有区别的。

害怕掉队的恐惧

深呼吸,试着跟上最近几个月的AI行业里新产品发布的节奏。

Claude Code 发布了子 agent,然后是技能,然后是 Agent SDK,然后是 Claude Cowork。

OpenAI 推出了 Codex CLI,然后是 GPT-5.3-Codex:一个帮助自己编码的模型。

新的编码 agent 宣布了后台模式,支持数百个并发自主会话。

Google 推出了 Gemini CLI。

GitHub 添加了 MCP Registry。

收购每周都在发生。

Amazon Q Developer 获得了 agent 升级。

CrewAI、AutoGen、LangGraph、MetaGPT——选你的 agent 框架,每周都有一个新的。

Google 宣布了 A2A(Agent-to-Agent 协议)来与 Anthropic 的 MCP 竞争。

OpenAI 发布了自己的 Swarm 框架。

Kimi K2.5 发布了 agent swarm 架构,协调 100 个并行 agent。

"氛围编码"成为一回事。

OpenClaw 推出了技能市场,在一周内,研究人员发现 ClawHub 上传了 400 多个恶意 agent 技能。

在这中间的某个地方,有人在 LinkedIn 上发布"如果你在 2026 年还没有使用带有子 agent 编排的 AI agent,你就已经过时了。"

那不是一年。那是几个月。

而且我还在遗漏东西。

(国内也是一样的快节奏,小米都加入大模型梯队了,发布了新模型。)

我深深地陷入了这个陷阱。

我花周末评估新工具。

阅读每个变更日志。观看每个演示。

试图保持在前沿,因为我害怕落后。

这实际上是什么样子的:我会在周六下午设置一个新的 AI 编码工具。

到周日我会有一个基本的工作流。

到下周三,有人会发布一个"更好得多"的不同工具。

我会感到一阵焦虑。

到下个周末,我会设置新东西。

旧东西会闲置不用。

一个编码助手到下一个再到下一个,又回到第一个。

每次迁移花费我一个周末,给我可能 5% 的改进,我甚至无法正确衡量。

将此乘以每个类别:编码助手、聊天界面、agent 框架、多 agent 编排平台、MCP server、上下文管理工具、提示词库、swarm 架构、技能市场。

(还有国内很火的 OpenClaw,Hermes,Harness 工程。)

你变成一个永远在学习新工具但从未深入了解任何一个的人。

仅 Hacker News 首页就足以让你头晕目眩。

一天是"Show HN: 自主研究 Swarm",第二天是"Ask HN: AI swarm 将如何协调?"

没人知道。每个人都在构建。

最糟糕的是知识贬值。

我在 2025 年初花了两周时间构建了一个复杂的提示词工程工作流。

精心制作的系统提示词、少样本示例、思维链模板。

它运行良好。

三个月后,模型更新了,提示词最佳实践发生了变化,我的一半模板产生的结果比简单的一行提示词更差。

那两周时间没了。

不是投资。而是花费。

我的 MCP server 设置也发生了同样的事情:

我构建了五个自定义 server(Dev.to 发布器、Apple Notes 集成、Python 和 TypeScript 沙箱等),然后协议演进,然后 MCP Registry 在 GitHub 上发布,突然有数千个预构建的。

我的一些自定义工作一夜之间变得多余。

Agent 框架的损失更严重。

我看到团队在一年内从 LangChain 到 CrewAI 到 AutoGen 到自定义编排。

每次迁移都意味着重写集成、重新学习 API、重建工作流。

等待并什么都不做的人往往比早期采用并不得不迁移两次的人处于更好的位置。

(所以有个说法,学AI什么时候都不晚,现在都来得及学。因为前期你错过的,都已经过时了。)

从那时起,我采用了不同的方法。

我不再追逐每个新工具,而是深入研究它们下面的基础设施层。

工具来来去去。

它们解决的问题不会。

上下文效率、agent 授权、审计跟踪、运行时安全:这些是持久的问题,无论这个月哪个框架流行。

这就是为什么我在 OpenFGA 上构建了 agentic-authz,而不是将其绑定到任何特定的 agent 框架。

这就是为什么 Distill 在上下文级别工作,而不是提示词级别。

在不流失的层上构建。

我仍然密切关注这个领域——当你为其构建基础设施时,你必须这样做。

但我跟踪它是为了了解生态系统的发展方向,而不是采用每个新东西。

了解信息和被动反应是有区别的。

"再试一次提示词"陷阱

这个陷阱很隐蔽。

你试图让 AI 生成特定的东西。

第一次输出是 70% 正确。所以你改进提示词。

第二次输出是 75% 正确,但破坏了第一次正确的内容。

第三次尝试:80% 正确,但现在结构不同了。

第四次尝试:你已经花了 45 分钟,而你本可以在 20 分钟内从头开始编写。

我称之为提示词螺旋。

这是 yak shaving(为了解决一个小问题而引发一系列无关任务)的 AI 等价物。

你从一个明确的目标开始。

三十分钟后,你正在调试你的提示词而不是调试你的代码。

你正在优化给语言模型的指令而不是解决实际问题。

提示词螺旋特别危险,因为它感觉很有成效。

你在迭代。你在接近。

每次尝试都稍微好一点。但边际收益正在快速递减,你已经忘记了目标从来不是"让 AI 产生完美输出"。

目标是发布功能。

我现在有一个硬性规则:三次尝试。

如果 AI 在三次提示词内不能让我达到 70% 可用,我就自己写。

没有例外。

这条规则节省的时间比我学过的任何提示词技术都多。

完美主义遇上概率输出

工程师倾向于完美主义。

我们喜欢干净的代码。

我们喜欢通过的测试。

我们喜欢行为可预测的系统。

这是一个特性,而不是 bug:这正是我们擅长构建可靠软件的原因。

AI 输出永远不完美。

它总是"相当好"。70-80% 到位。

变量名稍微有点偏。错误处理不完整。边缘情况被忽略。抽象对你的代码库来说是错误的。

它能工作,但它不对。

对于完美主义者来说,这是折磨。

因为"几乎正确"比"完全错误"更糟糕。

完全错误,你扔掉重新开始。

几乎正确,你花一个小时调整。

调整 AI 输出特别令人沮丧,因为你正在修复别人的设计决策:

由一个不分享你的品味、你的上下文或你的标准的系统做出的决策。

我不得不学会放手。

不是质量——我仍然关心质量。

而是对 AI 会产生质量的期望。

我现在把每个 AI 输出视为粗略草稿。

一个起点。原材料。

我在它出现的那一刻就在心理上标记为"草稿",仅这种框架改变就减少了我一半的挫败感。

在 AI 上挣扎最多的工程师往往是最优秀的工程师。

那些标准最高的人。那些注意到每个不完美的人。

AI 奖励一种不同的技能:快速从不完美的输出中提取价值的能力,而不会在情感上投入使其完美。

思维退化

这是最让我害怕的。

我在一次设计审查会议上注意到了这一点。

有人要求我在白板上推理一个并发问题。

没有笔记本电脑。没有 AI。只有我和一支记号笔。

我挣扎了。

不是因为我不知道概念——我知道。

而是因为我几个月没有锻炼那块肌肉了。

我太长时间把初稿思维外包给 AI,以至于我从头开始思考的能力已经退化了。

这就像 GPS 和导航。

在 GPS 之前,在你心里有一个地图。

你了解你的城市。你可以推理路线。

多年使用 GPS 后,你无法在没有它的情况下导航。

这项技能萎缩了,因为你停止使用它。

AI 和工程思维正在发生同样的事情。

当你总是先问 AI 时,你停止构建来自自己与问题挣扎的神经通路。

挣扎是学习发生的地方。

困惑是理解形成的地方。

跳过那个,你会得到更快的输出但更浅的理解。

我现在故意每天第一个小时不使用 AI。

我在纸上思考。

我手工绘制架构。

我用缓慢的方式推理问题。

这感觉低效。它确实低效。

但它保持我的思维敏锐,这种敏锐度在我使用 AI 的这一天其余时间里会有回报:

因为我自己的推理已经热身,我可以更好地评估它的输出。

比较陷阱

社交媒体上充满了似乎已经搞清楚 AI 的人。

他们发布他们的工作流。

他们的生产力数字。

他们的"我用 AI 在 2 小时内构建了整个应用程序"的帖子。

你看看自己的经历:失败的提示词、浪费的时间、你不得不重写的代码。

你会想:我有什么问题?

你没有任何问题。

那些帖子是精彩集锦。

没人发布"我花了 3 小时试图让 Claude 理解我的数据库模式,最终放弃并手工编写迁移"。

没人发布"AI 生成的代码导致生产事故,因为它静默地吞下了一个错误"。

没人发布"我累了"。

比较陷阱被放大了,因为 AI 技能很难衡量。

对于传统工程,你可以看某人的代码并粗略评估他的能力。

对于 AI,输出取决于模型、提示词、上下文、温度、月相。

某人令人印象深刻的演示可能无法在你的机器上用你的代码库复现。

我对社交媒体上的 AI 内容变得更加挑剔。

我仍然密切关注这个领域:我必须这样做,这是我的工作。

但我从消费每个人的热门观点转向专注于那些真正在构建和发布的人,而不仅仅是演示。

信号与焦虑的比例很重要。

如果一个信息流让你感到落后而不是了解情况,它就没有为你服务。

真正有帮助的做法

以下是具体讲讲是什么改变了我和 AI 的关系,从对抗到可持续。

时间盒 AI 会话

我不再以开放式方式使用 AI。

我设置一个计时器。

这个任务用 AI 30 分钟。

当计时器响起时,我发布我有的东西或切换到我自己写。

这同时防止了提示词螺旋和完美主义陷阱。

分离 AI 时间和思考时间

早上用于思考。

下午用于 AI 辅助执行。

这不是死板的:有时我会打破规则。

但有一个默认结构意味着我的大脑在正确的比例下既得到锻炼又得到帮助。

接受 AI 的 70%

我停止试图获得完美输出。

70% 可用是标准。

我会自己修复其余部分。

这种接受是我工作流中减少 AI 相关挫败感的最大杠杆。

对炒作周期更策略化

我跟踪 AI 领域,因为我为其构建基础设施。

但我停止在发布一周内采用每个新工具。

我使用一个主要的编码助手并深入了解它。

我在新工具证明自己数月后才评估它们,而不是数天。

保持了解和保持反应是不同的。

记录 AI 在哪里有帮助,在哪里没有

我保留了一个简单的两周日志:任务、使用 AI(是/否)、花费时间、对结果的满意度。

数据很有启发性。

AI 在样板代码、文档和测试生成上为我节省了大量时间。

它在架构决策、复杂调试和需要深度了解我代码库的任何事情上花费了我的时间。

现在我知道什么时候该使用它,什么时候不该。

不审查 AI 产生的所有内容

这很难接受。

但如果你使用 AI 生成大量代码,你实际上无法以相同的严谨度审查每一行。

我将审查精力集中在最重要的部分:安全边界、数据处理、错误路径,并依赖自动化测试和静态分析来处理其余部分。

非关键代码中的一些粗糙度是可以接受的。

可持续性问题

科技行业有一个早于 AI 时代就存在的倦怠问题。

AI 正在让它变得更糟,而不是更好。

不是因为 AI 不好,而是因为 AI 移除了过去保护我们的自然速度限制。

在 AI 之前,你一天能生产多少有一个上限。

那个上限是由打字速度、思考速度、查找资料的时间设定的。

有时这很令人沮丧,但它也是一个调速器。

你不可能工作到死,因为工作本身施加了限制。

AI 移除了调速器。

现在唯一的限制是你的认知耐力。

大多数人不知道自己的认知限制,直到他们已经超越了它们。

我在 2025 年末倦怠了。

不是戏剧性的——我没有辞职或崩溃。

我只是停止关心了。

代码审查变成了橡皮图章。

设计决策变成了"AI 建议的任何东西"。

我在走过场,生产比以往更多,感觉比以往更少。

我花了一个月才意识到发生了什么,又花了一个月才恢复。

恢复不是关于少用 AI。

而是关于以不同方式使用 AI。

有边界。

有意图。

理解我不是机器,我不需要跟上机器的步伐。

在 Ona 工作帮助我清楚地看到了这一点:当你为企业客户构建 AI agent 基础设施时,你会看到不可持续的 AI 工作流在规模上的人力成本。

问题不仅仅是个人的。

它们是系统性的。

它们需要在工具层面解决,而不仅仅是个人层面。

戏剧性的是,倦怠期间是我一些最好的工作发生的时候。

当我停止尝试使用每个 AI 工具并开始思考实际出了什么问题时,我第一次清楚地看到了问题。

上下文窗口充满垃圾,这个问题后来成就了产品 Distill。

具有全有或全无 API 密钥访问的 agent,变成了 agentic-authz。

无法审计 agent 实际做了什么,正在变成 AgentTrace。

疲惫迫使我停止消费并开始构建。

不是更快地构建更多功能,而是深思熟虑地构建正确的东西。

真正的技能

我认为 AI 时代真正的技能是什么。

不是提示词工程。

不是知道使用哪个模型。

不是拥有完美的工作流。

是知道什么时候停下来。

知道 AI 输出什么时候足够好。

知道什么时候自己写。

知道什么时候关闭笔记本电脑。

知道边际改进不值得认知成本。

知道你的大脑是有限的资源,保护它不是懒惰——它是工程。

(这也可以回答上篇文章里面试时会问到的问题,为什么你用AI会比别人更好:怎么把6周一次版本更新提升到1天8次部署?从用 AI 到 AI 优先。)

我们优化系统以实现可持续性。

添加熔断器(circuit breakers,当系统过载时自动断开保护系统的机制)。

实现背压(backpressure,控制流量防止系统过载的机制)。

设计优雅降级(graceful degradation,系统部分失效时仍能基本运行的能力)。

我们应该对自己做同样的事情。

AI 是我用过的最强大的工具。

它也是最消耗精力的。

两件事都是真实的。

在这个时代蓬勃发展的工程师不会是那些最多使用 AI 的人。

他们将是那些最明智地使用它的人。

如果你累了,不是因为你做错了。

而是因为这真的很难。

工具是新的,模式仍在形成,行业假装更多输出等于更多价值。

不是的。可持续输出才是。

我每天都在这个领域构建。

Agent 授权、上下文工程、审计跟踪、运行时安全:让 AI agent 在生产中实际工作的基础设施。

我把学到的一切都写进了 Agentic Engineering Guide:从授权模式到审计跟踪,没人谈论的难题。

我比以往任何时候都更致力于 AI。

但我按照我的条款、我的节奏、构建重要的东西而不是追逐流行的东西来致力于它。

照顾好你的大脑。

它是你唯一拥有的,没有 AI 可以替代它。

用 AI 的你,感觉如何?

欢迎评论区留言。

-END-


推荐阅读:

Claude Design 系统提示词被泄露:AI 如何成为你的专业设计师

万字深研 |Harness 工程实践:指令遵从率 20%,Hook 执行率 100%

89.2%攻击成功率!腾讯、字节研究发现 OpenClaw Agent 存在可利用结构性漏洞

拆解 Hermes Agent:开源 Agent 里唯一的闭环学习系统

490万浏览量的方案:用 LLM 构建持续更新积累的个人知识库

谷歌提示工程白皮书|Google Prompt Engineering White-paper

让你的OpenClaw替你打工:从0到1跑通小红书运营全流程(实战教程)

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/4/24 3:03:21

智能体AI安全架构:五大核心模式解析与实践

1. 智能体AI安全架构的五大核心模式解析在当今AI技术快速发展的浪潮中,智能体AI(Agentic AI)正成为改变行业格局的关键力量。作为一名长期从事AI系统开发的工程师,我见证了无数团队在追求功能创新的同时,往往忽视了安全…

作者头像 李华
网站建设 2026/4/24 3:03:19

集群升级与数据迁移:零停机升级的完整执行手册

文章目录 为什么升级不是"小事" 一、升级前的准备工作 1.1 理解 K8s 版本支持策略 1.2 kubeadm upgrade plan:升级前的全面体检 1.3 etcd 备份:升级失败的最后防线 二、Control Plane 升级:组件顺序决定成败 2.1 升级顺序的本质原因 2.2 kubeadm 升级 Control Pla…

作者头像 李华
网站建设 2026/4/24 3:03:17

PHP日期时间函数date() 详解

date()函数是我们在php开发中常碰到并且会使用到的一个日期函数,下面我来给大家介绍date()函数的一些基本扮靓和方法,有需要了解的朋友可进入参考.日期时间函数是PHP 的核心组成部分。无需安装即可使用这些函数。下面来详细说说date函数的具体用法&#…

作者头像 李华
网站建设 2026/4/24 3:00:31

量子计算中的经典性违反与补集采样游戏研究

1. 量子计算中的经典性违反研究概述量子计算利用量子态的叠加与纠缠特性,在特定问题上展现出对经典计算的显著优势。补集采样游戏(Complement Sampling Game)作为一个理论框架,清晰地展示了这种优势的量化表现。在这个游戏中&…

作者头像 李华