AI 编程后，我更累了

没错，以前是你是技术专家，精心种一块地，现在是种地不要技术了，种的地反而多了，几百亩地，还是得浇水施肥，变成了体力劳动，累😮‍💨

不要读 AI 的代码，而是读 AI 的方案，不要用读代码的方式来保障质量，而是用测试结果结果来体现质量，不管 AI 代码写多的多花哨，测试不过就是不过。AI 生产的代码量可能会越来越多，用 AI 开发软件也会越来越复杂。

确实，最近也有这种负担。要不不读，要读负担很重

The creator of Clawd: "I ship code I don't read"

古法编程还有思考-执行两个循环的过程，相当于做了负载均衡。现在 AI 极大缩减了执行的时间，就把负载全压到思考上了。

@Nexora 最近发现 ai 写的代码测试能过，但细看代码，常常藏着 repository.findAll().stream()
.filter(item -> item.getId() == xx)
.collect(Collectors.toSet());这种设计。用的 codex 5.3 最新模型+技术规范 skills

用了 AI ，就得所有过程抛给 AI ，人工 review 太累了，而且 AI 写的代码真的很啰嗦，到后面根本没有精力去 review 。

老板：你就说是不是比以前快了吧。
同事：代码我早就不看了。

AI 编程技术进步确实使人更累，编码更多人能做了，竞争更激烈

+1 我也是

你就说薪酬和年终奖有没有上去吧？

@devzhaoyou 我觉得你说话好有道理

系统编程是这样的吧，总共没有多少代码，但是要在大脑里完全走一遍。David Cutler 在采访的时候就说过，他每写点东西就要在大脑里把整个代码的流程跑几遍，确保没问题了再写。

AI 编程会越做越好的，你帖子里面说到的这些问题，会逐步解决。

以后是面向测试编程了. 各种 case 各种结果定好,中间怎么实现管不了那么多了😂

有强迫症，所以一直拿 ai 当 csdn 用（雾，
chatgpt 刚出 plus 就买了，一直是根据需求出范例或者问 ai 建议那样，
可能是做嵌入式吧，有的时候为了快速看一些效果才会 vibe ，比如写个前端对接我的东西之类的。
很久很久前还在上学，我男票不会代码，用类似 dw 那种拖拽工具写 h5 ，然后给我让我帮他改我编辑器开后产生了很大的心理阴影，所以我心里比较抗拒别的东西生成的代码，虽然我并不反对甚至支持这项技术。

真的，现在非常累

肯定更累了，现在正在过渡期，过渡期的温水煮青蛙

就像机器取代编织工，不学习使用机器肯定最终被淘汰，但是这个肯定是一个发展过程，不可能一步达成

人就跟固态硬盘一样，读写次数是有寿命的。

只不过老板们借 ai 这个大手，把人当耗材，每年毕业的大学生还想要高薪水，这局面至少持续 20 年吧

你现在得考虑，这种高压下，你能干多久？你的身体能撑多久？真撑很久的话你能活到多久？

@middle2000 有道理。ai code 全面代替人工的过渡期。。

ai 吞吐太快我难以对齐，确实更累了。而且 llm 可以 worktree 并行我不可以，虽然效率高但是因为责任问题自己看的大脑都麻了。

思路错了。

AI 相当于程序员，你用 AI ，你的角色不是程序员，而是技术总监。

你需要把你的要求，写入到规范文档与配置文档里，然后让 AI 去实现并检查，而不是你去检查 AI 的代码。

最近也在想这个问题，不久的将来代码一定不需要由人类 review 了，因为人类已经是这个链路上的瓶颈。
也许人类可以 review ai 写的文档，也许人类什么都不需要干

@Unicorns96
让 AI 去 code review AI 。比如你用 gpt 写代码，然后开 claude 或者 gemini 去审核。
最好是让他一个一个类去读去审，能抓出不少这种毛病。

To 楼主
善用 architect 功能，很多决策可以在写代码之前做，能避免一些你说的二则的问题。也可以让 AI 多读读已有代码，让他去学习现有的编程风格。能用 memory bank 固化的就善用 memory bank 。
再剩下的问题就只能捏着鼻子接受了。毕竟你招几个实习生来写，也未必能写得比 AI 好……

项目推进太快了人肯定累，这个应该是你们老板的问题，换用 AI 写代码不等于还能百分之百速度干活，人还是得休息的。

都 vibe 了还 review 啥，等捅了篓子就拿大礼包去下一家继续 vibe 完事

@Nexora 不读 AI 写的代码？你敢上线，运维的时候就有多痛苦，上线出问题是要加班加点解决的，等不了你在那里慢慢查。开发时拉的屎，运维时还得吃（只不过看是谁吃了，每个公司不一样），哈哈哈哈

我想到的，一种做法是放权，AI 是员工，你是领导，只管结果正确就行；一种是把 AI 当成自己的替身，想办法把自己的开发习惯迁移给 AI

改过一个 AI 写的项目 比重写一遍还累

现在老老实实自己写了（小 demo 还是让 AI 写，不用维护） 让 AI 负责优化一个 UI 和把代码梳理好看一些

最绝望的是老板真相信外面吹的牛逼，疯狂压榨你工期

@devzhaoyou 贴切！

@Nexora 还是要读的，很多时候不出问题还好，出了问题时间就是金钱。这个核心问题还是推进太快了，每天时间被压缩了，如果节奏延长一倍会轻松很多。

AI 让所有工种都更累了
我是做内容和运营的，和各位 AI Coding 的朋友们感觉一致

@Nexora 赞同大佬的观点，看结果就行

@Nexora ai 生成的测试用例有时候也会骗人, 不可能完全不读代码的

熟悉的领域让 AI 来辅助我，而不是接管我。
不熟悉的领域，完全依赖 AI 。依赖 AI 的时候，用 AI 来完全闭环，只要中间一环需要人工审阅就很累。

同感，更累了。
昨天看到一篇文章，感觉写的非常好，转过来感兴趣的可以看一下



软件工程师 SiddhantKhare 最近写了一篇博客文章，吐槽 AI 编程为自己带来的“疲乏的感觉”，引发了其他工程师们的共鸣。他结合亲身经历指出，AI 引发的职业倦怠是真实存在的问题，却长期被行业有意无意地忽视。单项任务提速并不意味着整体工作负担减轻，实际上正好相反，任务总量不断膨胀，高频的上下文切换带来了深层次的精力透支。

与此同时，工作角色也在悄然转变。工程师从原本的创造者沦为高认知消耗的 AI 产出审核者，而 AI 输出固有的不确定性又与工程师习惯的确定性思维产生冲突，持续滋生焦虑情绪。此外，行业技术更新节奏过快催生出一种 "FOMO 跑步机" 效应，频繁追逐新工具不仅浪费时间，还加速了已有知识的贬值，工程师也容易陷入反复调试提示词的“prompt 螺旋”之中，长此以往，独立思考和解决问题的能力逐渐退化。社交媒体上铺天盖地的高光展示，则进一步放大了比较焦虑。


Khare 认为，在 AI 时代，工程师真正的核心竞争力不在于将 AI 用到极致，而在于懂得为自己设定边界、适时叫停，守护有限的认知资源，以实现可持续的长期产出。

以下为 Siddhant Khare 的文章翻译


AI 疲劳是真实存在的，但是并没有人谈论这一点

你用 AI 来提高生产力。可为什么你比以往任何时候都更加疲惫不堪？这是每个工程师都必须面对的悖论。

上个季度我交付的代码量超过了我职业生涯中的任何一个季度。同时，我也感到比以往任何一个季度都更加精疲力竭。这两个事实并非毫无关联。

我以构建 AI 智能体基础设施为生。我是 OpenFGA （ CNCF 孵化项目）的核心维护者之一，我开发了用于智能体授权的 agentic-authz ，开发了用于上下文去重的 Distill ，交付了 MCP 服务器。我不是那种偶尔玩玩 AI 的人。我深陷其中。我构建的工具被其他工程师用于在生产环境中让 AI 智能体运转起来。

然而，我撞上了一堵墙。那种筋疲力竭的感觉，无论多少工具或工作流程优化都无法修复。

如果你是一名每天使用 AI 的工程师——用于设计评审、代码生成、调试、文档编写、架构决策——并且你注意到自己不知为何比 AI 出现之前更加疲惫，这篇文章是写给你的。你不是在想象。你不是软弱。你正在经历某种真实存在的东西，而整个行业却完全假装它不存在。如果一个全职构建智能体基础设施的人都能因为 AI 而产生职业倦怠，那么这种事可能发生在任何人身上。


我想诚实地谈谈这个问题。不是那种“AI 太棒了，这是我的工作流程”的版本。而是真实的版本。那种你晚上 11 点盯着屏幕，周围全是还需要审查的 AI 生成代码，疑惑着那个本该节省你时间的工具如何吞噬了你一整天的版本。

无人预警过的悖论

有件事困扰了我很久：AI 确实让单个任务变快了。这不是谎言。过去需要 3 小时的事，现在只要 45 分钟。起草设计文档、搭建新服务脚手架、编写测试用例、调研陌生的 API——全都变快了。

但我的工作日变得更难了，不是更轻松，而是更难。

原因一旦看清就很简单，但我花了数月才明白。当每个任务耗时变少，你并不会做更少的任务，而是会做更多的任务。你的能力看似扩展了，于是工作量也随之膨胀，甚至超载。你的经理看你交付更快，期望值随之调高。你自己也发现自己交付更快，自我期望也随之调高。基准线被动抬升了。

AI 之前，我可能花一整天只解决一个设计问题。在纸上画草稿，洗澡时思考，出门散步，然后带着清晰的思路回来。节奏虽慢，但认知负荷是可控的。一个问题。一天。深度专注。现在呢？我一天可能处理 6 个不同的问题。每个问题“用 AI 只需一小时”。但在 6 个问题之间切换，对人类大脑来说代价极高。AI 不会在问题间感到疲惫。我会。

这就是悖论：AI 降低了产出的成本，却提高了协调、评审和决策的成本。而这些成本全部由人类承担。

你成了评审员，而这并非你本意。

AI 之前，我的工作是：思考问题、写代码、测试、交付。我是创作者、制造者。这正是当初吸引我们大多数人进入工程领域的原因——构建本身。

AI 之后，我的工作日益演变为：写 prompt → 等 → 读输出 → 评估输出 → 判断是否正确 → 判断是否安全 → 判断是否符合架构 → 修不对的部分 → 再 prompt → 再重复。我成了评审员、裁判员、永不停歇的装配线上的质检员。

这是性质完全不同的工作。创造让人充满活力，评审让人精疲力竭。有研究支持这一点：生成性任务与评估性任务在心理上的差异。生成性工作带给你心流状态，评估性工作带给你决策疲劳。

我是在重度使用 AI 构建一个 microservice 的那周首次意识到这点的。到了周三，我甚至无法做简单决策了。这个函数该叫什么？我不在乎。这个配置该放哪里？我不在乎。我的大脑已经满载。不是因为写代码，而是因为评判代码。每天一整个时间都在做无数个细小判断，会把你掏空。

残酷的讽刺在于，AI 生成的代码需要比人类编写的代码更仔细的评审。同事写代码时，我了解他们的模式、长处和盲点。我可以略读我信任的部分，聚焦于我不确定的部分。但面对 AI ，每一行都值得怀疑。代码看起来信心十足。它能编译。甚至可能通过测试。但它可能以微妙的方式出错，只在生产环境中、在负载下、在凌晨三点才浮出水面。

所以你只能逐行审阅。而阅读不是你写的、由一个不懂你代码库历史或团队约定的系统生成的代码，是令人精疲力竭的工作。

这也是我认为 agent 安全和授权至关重要的原因。如果我们无法评审 AI 生成的所有内容——实际上我们也做不到，无法大规模做到——那么我们就需要从一开始就约束智能体能力的系统。最小权限访问、范围限定 token 、审计追踪。你越不需要担心“AI 会不会做出危险动作”，你越能把认知预算留给真正重要的工作。这不仅是安全问题，更是“人能否长期承受”的可持续问题。

非确定性问题

工程师是在确定性的环境中训练出来的。相同输入，相同输出。这是契约。这使调试成为可能，使系统推理成为可能。

AI 打破了这份契约。

我有一个提示词，周一用起来完美无瑕，为某个 API 端点生成了干净、结构良好的代码。周二我为类似端点用了同样的提示词。输出结构完全不同，采用了不同的错误处理模式，还引入了一个我并未要求的依赖。为什么？没理由。更准确地说，没有我能触达的原因。这里没有“模型今天换了想法”的 stack trace ，也没有日志告诉你”temperature sampling 走了 B 路径不是 A 路径”。它就是……不一样了。

对于一个整个职业生涯建立在“如果它出问题了，我能找出原因”之上的人来说，这让人深感不安。不是戏剧性的那种。而是缓慢、磨人、背景式的焦虑。你永远无法完全信任输出。你永远无法彻底放松。每一次交互都需要保持警觉。

我曾试图对抗这一点。我对提示词做版本控制。我构建了复杂的系统消息。我创建了模板。有些方法有帮助。但没有一个能解决根本问题：你在与一个概率性系统协作，而你的大脑是为确定性系统而生的。 这种不匹配是一个持续存在的、低强度的压力源。


这种挫败感实际上促使我构建了 Distill——为大型语言模型提供确定性上下文去重。没有 LLM 调用，没有嵌入，没有概率性启发式算法。纯粹靠算法在大约 12 毫秒内清理你的上下文。我只想让 AI 流程中的至少一部分是能够被推理、调试和信任的。如果模型的输出注定是非确定性的，我至少能确保输入是干净和可预测的。

我与那些处理这种情况最好的工程师交流过，他们都已经与之和解。他们把 AI 输出看作一个聪明但不可靠的实习生写的初稿。他们预期要重写其中的 30%。他们会为这种重写预留时间。当输出错误时，他们不会沮丧，因为他们从未期待它是正确的。他们期待它是有用的。这之间有本质区别。

FOMO 的跑步机

深吸一口气，试着跟上仅仅过去几个月的节奏。Claude Code 推出了子智能体，然后是技能，然后是 Agent SDK ，然后是 Claude Cowork 。OpenAI 发布了 Codex CLI ，然后是 GPT-5.3-Codex——一个名副其实能自我编码的模型。新的编码智能体宣布了具有数百个并发自主会话的后台模式。Google 推出了 Gemini CLI 。GitHub 增加了 MCP 注册中心。收购每周都在发生。Amazon Q Developer 获得了智能体升级。CrewAI 、AutoGen 、LangGraph 、MetaGPT——随便选一个智能体框架，每周都有新的。Google 宣布了 A2A （ Agent-to-Agent 协议）与 Anthropic 的 MCP 竞争。OpenAI 推出了自己的 Swarm 框架。Kimi K2.5 发布了，其智能体群体架构可协调 100 个并行智能体。"氛围编码"成了流行词。OpenClaw 推出了技能市场，一周内，研究人员就在 ClawHub 上发现了超过 400 个恶意智能体技能。而在这所有事情之间，有人在 LinkedIn 上发帖："如果在 2026 年你还没使用带子智能体编排的 AI 智能体，你已经被淘汰了。"


这不是一年的变化。这只是几个月。

而且我还没列全。我深深陷入了这个陷阱。我花周末评估新工具。阅读每一份更新日志。观看每一个演示。努力留在前沿，因为我害怕落后。实际情况是这样的：周六下午我花时间设置一个新 AI 编码工具。周日我建好了一个基本工作流。到了下周三，就有人发帖说另一个工具"好得多"。我感到一阵焦虑。下个周末，我又开始设置那个新东西。旧的那个则闲置不用。从一个编码助手换到另一个，再到下一个，又回到第一个。每次迁移都耗费我一个周末，却只换来大约 5%、我甚至无法恰当衡量的改进。

将这个情况乘以每个类别——编码助手、聊天界面、智能体框架、多智能体编排平台、MCP 服务器、上下文管理工具、提示词库、群体架构、技能市场——你得到的是一个永远在学习新工具、却从未深入任何一个工具的人。单单 Hacker News 首页就足以让你应接不暇。今天是"Show HN：自主研究群体"，明天是"Ask HN：AI 群体将如何协调？"没人知道。但每个人都在构建。

最糟糕的是知识的衰减。2025 年初，我花了两周时间构建了一个复杂的提示工程工作流。精心设计的系统提示、少样本示例、思维链模板。效果很好。三个月后，模型更新了，提示的最佳实践变了，我一半的模板产生的效果还不如一句简单的指令。那两周时间就这样消失了。不是投资，是耗费。同样的事情也发生在我搭建的 MCP 服务器上——我构建了五个定制服务器（ Dev. to 发布器、Apple Notes 集成、Python 和 TypeScript 沙箱等），然后协议演进了，接着 MCP 注册中心在 GitHub 上线，突然就有了成千上万个预制好的。我的一些定制工作一夜之间变得多余。

智能体框架的快速更迭更糟。我目睹团队在一年之内从 LangChain 转到 CrewAI ，再到 AutoGen ，再到自建编排。每次迁移都意味着重写集成、重新学习 API 、重建工作流。那些等待观望、按兵不动的人，往往比那些过早采用、被迫迁移两次的人处境更好。

此后我采用了不同的策略。我不再追逐每一个新工具，而是深耕于它们之下的基础设施层。工具来来去去，但它们解决的问题不会变。上下文效率、智能体授权、审计追踪、运行时安全——无论本月流行哪个框架，这些都是持久存在的问题。这就是为什么我在 OpenFGA 上构建

agentic-authz ，而不是将其绑定到任何特定智能体框架。这就是为什么 Distill 工作在上下文层面，而非提示词层面。在不会快速更迭的层次上构建。我仍然密切关注领域动态——当你为其构建基础设施时，你必须这样做。但我关注它是为了理解生态系统的走向，而不是为了采纳每一样新事物。保持信息灵通和被动反应是两回事。


“再多一次提示”的陷阱

这种陷阱很隐蔽。你试图让 AI 生成某个特定的东西。第一次输出 70%正确。于是你优化提示词。第二次输出 75%正确，但破坏了第一次已正确的东西。第三次尝试：80%正确，但结构变了。第四次尝试：你已经折腾了 45 分钟，而你自己从头写的话 20 分钟就能完成。

我称之为"提示词螺旋"。这是 AI 版的"绕远路修枝"（ yak shaving ）。你从一个明确的目标开始。三十分钟后，你却在调试你的提示词，而不是调试你的代码。你在优化你对语言模型的指令，而不是解决实际问题。

提示词螺旋尤其危险，因为它让你感觉很有效率。你在迭代。你在接近目标。每次尝试都稍好一点。但边际回报正在快速递减，而你已忘记了目标从来不是“让 AI 产生完美输出”。目标是交付功能。

我现在有个硬性规定：尝试三次。如果 AI 在三轮提示内无法达到 70%的可用度，我就自己写。没有例外。就这一条规则，为我节省的时间比我学过的任何提示技巧都多。

完美主义遭遇概率性输出

工程师往往倾向于完美主义。我们喜欢干净的代码。喜欢通过的测试。喜欢行为可预测的系统。这是优点，不是缺陷——正是这点让我们擅长构建可靠的软件。

AI 输出从不完美。它总是"相当好"。完成了 70-80%。变量名有点偏差。错误处理不完整。边缘情况被忽略。抽象层次与你的代码库不匹配。它能运行，但不正确。对完美主义者来说，这是折磨。因为"差不多对"比"完全错"更糟糕。完全错，你可以扔掉重来。差不多对，你得花一小时修修补补。而修补 AI 输出格外令人沮丧，因为你是在修正别人的设计决策——这些决策是由一个系统做出的，而这个系统并不具备你的品味、你的背景、你的标准。

我不得不学会放手。不是放弃质量——我仍然在意质量。而是放弃对"AI 会产出质量"的期待。我现在把每一次 AI 输出都当作粗糙的草稿。一个起点。原材料。它在出现的瞬间，我就在心里给它贴上"草稿"的标签。单是这种心态转变，就让我的挫败感减少了一半。

最难以适应 AI 的工程师，往往是最优秀的工程师。那些标准最高的人。那些能注意到每一个瑕疵的人。而 AI 奖励的是一种不同的技能：能够快速从不完美的输出中提取价值，而不过度执着于使其完美。

思考能力的萎缩

这是最让我恐惧的一点。我是在一次设计评审会上注意到这点的。有人要求我在白板上推理一个并发问题。没有电脑。没有 AI 。只有我和一支马克笔。而我感到吃力。不是因为我不知晓相关概念——我知道。而是因为我数月没有锻炼这个“肌肉”了。我外包自己的初稿思考给 AI 太久了，以至于我即兴思考的能力已经退化。

这就像 GPS 和导航。有 GPS 之前，你会构建大脑中的地图。你了解你的城市。你能推理路线。经过多年使用 GPS ，你没有它就迷路了。这项技能萎缩了，因为你不再使用它。同样的事情正在 AI 和工程思考中发生。当你总是先问 AI ，你就停止了构建那些源自于亲自与问题搏斗的神经通路。搏斗正是学习发生的地方。困惑正是理解形成之处。跳过这些，你会得到更快的输出，但也会得到更浅的理解。

现在我每天第一个小时刻意不用 AI 。我在纸上思考。我手绘架构。我以缓慢的方式推理问题。这感觉效率低下。也确实效率低下。但这能保持我的思维锐利，而这种锐利度在接下来使用 AI 的时间里会带来回报——因为当我的自身推理能力被激活后，我能更好地评估 AI 的输出。

比较的陷阱

社交媒体上充斥着似乎把 AI 研究明白了的人。他们发布自己的工作流。他们的生产力数据。他们“两小时用 AI 构建了整个应用”的帖子。而你看着自己的经历——失败的提示词、浪费的时间、不得不重写的代码——你想：我到底哪里不对？

你哪里都没不对。那些帖子里是精彩集锦。没有人会发"我花了三小时试图让 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 智能体基础设施时，你会看到不可持续的 AI 工作流在大规模下造成的人力成本。这些问题不仅仅是个人层面的

。它们是系统性的。并且需要在工具层面解决，而不仅仅是个体层面。讽刺的是，倦怠期恰恰是我一些最佳工作成果诞生的时候。当我停止尝试使用每一种 AI 工具，开始思考真正出了什么问题，我第一次清晰地看到了问题所在。上下文窗口被垃圾填满——这成了 Distill 。智能体拥有全有或全无的 API 密钥访问权限——这成了 agentic-authz 。无法审计智能体实际做了什么——这正在成为 AgentTrace 。倦怠迫使我从消费转向构建。不是更快地构建更多功能，而是审慎地构建正确的东西。

真正的技能我认为 AI 时代真正的技能不是提示工程，不是知道用哪个模型。不是拥有完美的工作流。而是知道何时停止。知道何时 AI 输出已足够好。知道何时该自己动手写。知道何时该合上笔记本电脑。知道何时边际改进不值认知代价。知道你的大脑是有限资源，保护它并非懒惰——这是工程学。我们优化系统以实现可持续性。我们增加断路器。我们实现背压。我们设计优雅降级。我们应当为自己也这样做。AI 是我用过的最强大的工具。它也是最消耗心力的工具。两者皆是事实。在这个时代蓬勃发展的工程师，不会是使用 AI 最多的人，而是最明智地使用 AI 的人。如果你感到疲惫，不是因为你做错了什么。而是因为这本身就很艰难。工具是新的，模式仍在形成，而整个行业都在假装更多产出就等于更多价值。它不是。可持续的产出才是。我至今仍每天都在这个领域构建。智能体授权、上下文工程、审计追踪、运行时安全——让 AI 智能体真正在生产环境中工作的基础设施。我比以往任何时候都更致力于 AI 。但我按照自己的节奏，依循自己的方式，致力于构建重要的事物，而非追逐潮流的事物。照顾好你的大脑。这是你唯一的大脑，没有 AI 可以替代它。

@irrigate2554 对这是根本问题，如果还是之前那些工作量，配合上 ai ，可以说是一有大半时间在喝咖啡了。

看了好几个纯 AI 的开源项目，issue 多的一批。
其实现阶段就是把测试的事交给用户做，AI 面向 issue 编程，至于会不会拆了门补窗户，开发者也不在乎了，毕竟以前的开源项目每一行代码都倾注了心血，现在可不是这样了，十几分钟发一个版本。
尝试把自己当成完全看不懂代码的人，告诉 AI 现象，让他自己处理，可能才是正确的打开方式。

没有错，现在 AI 的最大问题是不会问问题限缩需求范围以及自己的输出，什么都给你一套大而全的东西，很多都是无用的甚至无效的。

@devzhaoyou 这就是我喜闻乐见的场景, 一部分工程师搞死另一部分工程师, 笑死我了, 这比 996 更要你们的命, 哈哈, 属于工程师们的斩杀线🤣

更像头驴了

太真实了：生成速度上去，但“理解/裁剪/取舍”的带宽没变。

我现在的解法是：强制把 AI 输出拆成小 PR （<=200 行可读），先让它写「设计+边界+不做什么」再写代码；然后用契约测试/属性测试兜底，把质量从“读完代码”转成“跑通不变量”。

再配一个 stop rule：看到它开始加抽象/加层，就先停，回到需求/历史包袱确认一遍。⑯

@Dragonish3600 感谢分享！

可不是，让 ai 不歇着，同时，自己也没歇着，更累

其实就是看领导给不给更多的任务压榨，如果没有多出太多，就稍微好一些，不然真的很痛苦

参考一下 https://effective-cursor.cyron.space/zh
用规则让模型熟悉你的项目。
毕竟本质来说，每一次的问答都是一个新的编码专家在帮你解决业务问题。
没有良好的文档，仅仅从代码中反推项目信息，效率低且有歧义，使用规则来约束他，确定项目功能边界。

属于是开发转审计员，功能需求、性能、安全、运维，AI 都全给你包圆了，要做的就是决策方案、审计风险。

体力活虽然少了，但只要职责在，很多事情都要亲自过一遍，人还是一个，知识跨度又多，人脑频繁在领域思维切换非常消耗精神力，AI 可以不停旋转运行，这相当于失去了工作节奏限制，人是不可能跟上的，纯纯认知负荷太高，猪脑过载了😄

更何况，资本家很多都是眼高手低，只会觉得 AI 能顶好几个人用，少数几个人负责输入就好了，程序员这个角色在 AI 大环境下自然会模糊很多，想要跟上节奏，就只能身兼多职，干更多不同类的活，各生产角色的边界也正在逐步丢失

知道你的大脑是有限资源，保护它并非懒惰——这是工程学。

这点是洼地的老板永远学不会的

是的就是认知负荷超载了，比如管理里确实有提到“一个人只能管 7 个直属手下”，这就是因为虽然每个人能力不同，但是时间是有限的，5-7 个人差不多就把你一天的时间和精力都压榨完毕了（但是像皮衣黄他老哥就能管 100 多个人，所以每个人方法不同，结果就是不同的），
那么 AI 呢，你从一开始就没有觉得自己是在管理一个“人”，所以也就不会用合理的方法去管理他们，我觉得今年的主题应该就是如何把管理学里如何管人的经验挪进去变成如何管理一个 AI 的组织架构

之前是细嚼慢咽 代码一行行的写出来 脑子能跟得上
战线长 像是牛吃草反刍 有时间反复打磨
用了 ai 写代码后 工期被压缩
然后就像八戒吃人参果 哐哐一顿吃
工业化流水线 毫无感情可言 于是你变成了产线工人

@Dragonish3600 非常非常真实有道理，我是做 C++的，总体也感觉用起来很累，大脑负荷很大。

怎么还有人觉得 ai 的代码可以一句不看，ai 写 ai review ？
到时候出了问题老板问到你头上，你来一句全是 ai review 的我不到呀，你看你走不走人就完事了。

@PTLin 是的，别被开源项目带偏了，开源项目出问题，开发者是不用负责的。公司线上出了问题，老板是要你负责的，万一因为 AI 少了几万块年终奖就得不偿失，在公司搞开发，AI 提效都是很虚幻的东西。

@Unicorns96 太典了🤣，写后端一不注意就给我来个全表搜索、嵌套循环查询、包 try catch 但是直接忽略 error

我也用 ai 写一些代码，但是我不会读 ai 写的代码，只是能保证 ai 写的代码有需要的时候我能读懂

坚持阅读、读懂 ai 的代码。确实会越累

@Nexora 说的对，其实不是 ai 带来的问题，是大型软件工程协作经验的匮乏，这就是 linus 干的事儿

需要测试保证质量

@jukanntenn >万一因为 AI 少了几万块年终奖就得不偿失

现实点，如果是“可能”少几万块钱 和 “每天 review AI 代码”二选一，我肯定选择前者。

反过来说，给你几万块钱让你 review 一整年 AI 写的代码你干吗？如果一毛钱都不给呢？

那就不用 ai ，你也就不痛苦了

@Dragonish3600 感谢。目前看见描述 AI 实践最好的文章

以前小明是后端，可以说自己不懂前端，不做。现在老板说要全栈， 小明还得做前端。 可是小明对前端理解不深，只能靠 AI 抽卡式编程， 做的累，看的累，测的也累。

我有一套工具，也许你可以试试： https://github.com/thiswind/cursor-agent-team

是让 AI 抡大锤还是小锤？
如果是抡大锤的话，提示词最终都可以归纳为:豆包给我卡里转 50w ，没什么好讨论的，自嗨就行。
首先，一个领域专家每天大脑的高质量运作的时间不会有较大变化，也就是不管你是自己写，还是你看别人的，单位时间的高质量产出不会有太大的变化。
那么该让 AI 做什么？应该分开用。
你原来工作内容分两步，方案设计场景推演，编写代码进行测试。这两部分别用不同的 AI 角色，可以省出相当多的时间。但是省出的时间，不能继续干一样的事，人的大脑不喜欢一直思考同一个事情，效率会越来越低（好像是思考快与慢中提到的）。

@dajj 还是要学的，自己轮大锤，让 AI 轮小锤。返工，是最大的成本。抽卡的代码，最终会陷入，改不动的地狱。

现阶段还是 SDD 来一步一步写，一次写完然后再改，现阶段还是很费 token

之前接单做项目，有个简单的大屏弹幕功能，我直接丢给 ai 写了，客户要求必须一直循环滚动显示，本地测了五分钟，看着没问题就上线了。结果第二天一用，一段时间后弹幕就没了，当时人家现场等着用，一大早电话就来说这个事情，赶紧起床起来排查，结果 ai 写的这一块，加了一堆缓存，数据拆分啥的，刚起来脑子也没开机，完全看懵了，电话又催的急，让 ai 自己排查修改改了好几轮也没改好，最后还是自己把代码看了几遍调试自己修改好了，从这以后 ai 出的代码我都要过一遍才敢用

@Dragonish3600 #37 求原文链接

第三次看到这贴翻上来，一路看过来，发现绝大多数“疲累”，属于程序员咎由自取。

首先明确一点，AI 是听指挥的，！绝对！不会主动增加使用者的工作量，那么问题就简单了，是程序员自己在不知不觉中加重了自身负担，也包括#37 转贴的长文作者。

核心的问题，有几楼已经说了，是大脑可承受的精力过载，那就…不禁要问：自身为什么会置于动辄上千行代码的境地？症结：任务分解不到位。

不要小看给 AI 的语言描述，实质上，在精确性或颗粒度方面，比与人交流相同意向的要求高很多。例如甲对乙描述工作任务，因为人类乙本身会过载，也就自然减轻了甲的负荷，但是，AI 的乙没有这一特性，它会将人类乙分多次累进的阶段性进度一次性反馈给甲，直接造成甲在短时间内过载，长此以往，甲必然心力交瘁、精疲力竭。

绝大多数从事 IT 技术类工作的人，都或多或少的存在‘意识->思路->表达’链条的精确度问题，甚至存在相当一部分人自认为能想清楚并说明白，实际上很可能归因于人类同事自行裁量所衍生的缓冲效应，对于照单全收且批量生成的 AI 来说，仍然是不到位的。

对症下药：不厌其烦的、分解再分解，将工作思路，掰开揉碎，用“挤牙膏”的模式，给 AI 尽可能细化的步进指令。
说易行难，几乎所有人，在人类社会的传统塑造下，都倾向于，拓展思维深度并言简意赅的表达，而对于由此导致 AI 造成过载的问题，需要反其道而行，尽量分层、分片、分块、分段、分步的制定胶片式指令，拉紧 AI 的缰绳，约束它，在自己可承受的舒适区间，一帧一帧的推进。

@Qiuchi 你这不至于啊……
https://www.google.com/search?q=Siddhant+Khare+FOMO

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

@fortytwo 感谢分享，又学到了！

@anonymous00 主要是领导认为有了 AI ，你什么就能全干。 用 AI 提升 50% 工作效率，但是领导给了 200% 工作量。

@anonymous00 你以为是数量的问题，实际上是质量和本质的问题

跟神经网络对话本身就已经改变了程序员的创造者的角色，变成了审阅者，所有的矛盾的根源都在这里。

忽视这个把所有的事情倒打一耙变成程序员不够努力，不知道是何居心

@dajj #73 没错，关键就是因为领导本人并不会直接与 AI 对接，也就很难认知到，以 LLM AI 产出的速度和密度，会给直接与 AI 对接的人类员工带来怎样的“超限”后果。



@catazshadow #74 我们谈的是：基于 LLM 的 AI ，哪来的“神经网络”？

不确定你说的“数量”、"质量"和"本质"是什么。程序员在 AI 面市之前，本身就是自编代码的“审阅者”，同时，上级也是下属成果的“审阅者”，这一角色并非 AI 赋予。所以，矛盾的根源，不是你说的“审阅者”，而是：人类无法承受 AI 高速、密集的代码产出所对应的工作负荷。

同类的工作负荷，如果是人类程序员或 Leader ，彼此身为人类，都有较为相近或匹配的过载阈值，所以对自己或 Leader 设定的综合任务的描述，都是在一段时间内，分批、分段的构思、编写并交付，对应的 review 负担也相对均衡，因此，在工作流程层面上，人就是天然的 breakpoint 。然而，AI 的过载阈值，大概只存在于交互的上下文深度的局限，远超人类日常所能应对的范围，程序员或 Leader 对 AI 产出代码的速度和密度无法适应又不做调整，仍然照葫芦画瓢的沿用与人沟通的方式对 AI 下达指令，而当前的 AI 并未内置 beakpoint ，于是，作为直接与其对接的人类搭档，被动“溢出”是早晚的事。

我见过的所有正常人，在工作中，大都推崇深度思维，习惯并追求“高屋建瓴”的纲领性沟通，这样的风格，对 AI 担当底层实现角色的工作模式来说却是致命的，比如各种 AI 犯蠢、AI 疲倦，有些是 AI 自身的局限或错误，但更多的不良感受，实际是使用者自己扔出的“回旋镖”。

OP 说“…改动动辄上千行…”，是 AI 故意把简单问题复杂化吗？ NO ，是 OP 在于 AI 交互时，把复杂问题简单化了（这很正常，因为这才是我们工作中真实的做法，归纳、总结，给出宽泛且模糊的描述，而后视情况不断修正），可它不适用于有 AI 参与的工作模式，从 OP 的表达中，尽管他感觉累，却没意识到其中的根源：他其实就是在不知不觉中、被 AI 给 overrun 了。

要避免被 AI overrun ，使用者需要做的只有一点：掌握节奏，也就是整理出各处必要的节点，并设置 breakpoint ，让 AI 跟随自己舒适的节奏。

综上，我在#69 的观点，不是你理解的“把所有的事情倒打一耙变成程序员不够努力”（从某个层面说，恰恰是太努力+无意识，反而让情况变糟了），而是：直接与 AI 对接的人类搭档，需要意识到并学会自己掌控节奏（如果必要的话，尽量设法让上级理解这一点）。

大陆车代码的程序员一天搞的不就是些垃圾业务代码，简直就是天生为 AI 而生的，你累只能说明你在没有 AI 的时候就很菜，只是你跟不上 AI 生成的代码而已，vibe → 成型 → 工程化，对于中国 99%的所谓互联网企业，完全够了，就这么简单

有人主张, 不要 review code, 而是要求 test, 只要 test 会过, 基本不管它写了什么, 有点像我们现在像不会去 review compiler 产生出来的 assembly 的意思像现在 openclaw 就是这个流派的最大宗 => “Don’t review code; review output / tests passed” 我个人觉得根本狗屁不通(强调只是个人观点), 理由是:

1. compiler 是高度确定性的而且严格验证的, 但 LLM 不是 =>
叫 LLM 产生 test case 有时候 test case 本身都是假的或质量不到位的, 那就算 test 过了也不表示没有问题你至少得去 review test case (所以完全不 review 应该不太靠谱)

2. 再来 LLM 因为 context window 及 RAG 能力不足的关系 =>
只能看到项目的部分无法关心全貌, 导致产生的源代码会极度多的重复内容, 完全不 DRY, 而这导致不符合 single source of truth 在需求变动或修改错误时, 很可能产生大量的不一致

3. 而 LLM 的 context window 有极限 =>
不但是现阶段有极限, 未来也很难突破极限(训练资料问题), 所以 2 是无解的

4. 这表示针对 2 来说, 除非你的 test case coverage 接近 100%, 不然一定有很多奇奇怪怪没改到没一致的边角 bug =>
而 test case 过了也可能一团糟, 那除非你把 test case 设计得很严谨, 这回到了 1, 你必须很认真的 review 大量的 test case, 如果你想要都不 review LLM 的 code 的话, 但 review 大量的 test case 而 test case 本身也是 code, 也被 LLM 同 2 大量的 copy/paste, 你 review 起来也是一样累, 不然就是要让 LLM 在这里很严谨的作, 这导致鸡生蛋蛋生鸡, 你只是把 review production code 的心力换成了 review test code

所以只看 test case 会过而不去管 code 这个方法论, 有基本的问题, 更像是种 ai hype, 听起来很爽, 但实务上问题一大堆, 只是把一个问题换成了其它问题

@anonymous00 "基于 LLM 的 AI ，哪来的“神经网络”？"

水平暴露了

还有，程序员会审阅自己的代码但在这之前，更本质的角色是创造代码，你对这个更本质的角色避而不谈

不用回我了，开心就好

@bear330 说得好，很多人明天的代码比作今天的汇编，这也是忽略了计算机软件大厦是基于数学搭建，而数学又是严谨的这一前提


不过话又说回来

有个 so what 的问题很难说清楚，现在越来越多大厂开宣称某某软件没有人工编码……也就是说在大多数时候，尽管完全没办法从数学上证明 ai 是 100%可靠的，但大家已经在这么使用了，似乎也没有遇到致命缺陷，那么它的存在也就是合理的，这个情况对计算机行业来说确实是颠覆性的

@Nexora ai 写的不做 code review 很容易后期就成屎山了，人根本无法维护，虽然说可以让 ai 去维护，但是所花费的 ai 成本也是非常高的

@catazshadow 好啦，你最初无法正确的阅读、理解我的观点，冒然回复导致“跑错片场”的尴尬，自损了颜面，现在拿“神经网络”说事，试图移焦点、找回场子，其实更加失策。

“神经网络”是所有 AI 努力的里程碑式目标，没有任何一家 AI 敢号称自家成果是“神经网络”，LLM 模型的本质，是分布式序列化，而“神经网络”的门槛是多点并行联动。随便找一家 AI ，问它：目前的 AI 距离“神经网络”还有多远？都能得到与你的认识迥异的答案。

你要自负到何种程度、才会对自身的认知偏差如此笃定、甚至不屑于找 AI 问一句？除非你是穿错年代的时空旅者，否则，你那鱼目混珠的水平才是真正暴露。

@anonymous00 你哪怕只看的懂 transformer 的摘要都不至于这么丢人，100 来个单词都不会，还几把好意思在这倒打一耙

https://arxiv.org/html/1706.03762v7

第一句斗大的神经网络看不见？

还用 AI 生成回复，人工智障只会让你更智障，简直不知廉耻

@extrem 他们想让我们这么用, 因为项目越来越大, 被 LLM 搞得重复越来越多, 理论上你给他足够时间和足够的 token, 还有足够多的 test case 它还是可以修正, 这里重点是: 1. 不 review 是不行的, 只是 review 的是 production code 还是 test case, 那也是 code 2. 是改得好, 但成本会累加之后改一个问题就越花越多, 越改越久, AI 公司就想要我们这样玩

@catazshadow #83 你那所谓的“Neural Network”用语，早在 1950 年代就已经有某些先驱者提出了，因在流派开拓之初，将其定为目标愿景，直观取名并开展学术，它作为 AI 前身就已定调的学术名词，沿用至今，并非实际意义的“神经网络”（不论是电子类还是生物类），业界早已公认它名不副实，形同“抢注商标或域名”，如今，就连它在学术场合沿用时的误导性质也接近共识。

你在#74 借其字面、照本宣科的回复，我站上述立场，在#75 表达不认同，同时也牵出你回复中的另一问题，“跟神经网络对话本身就已经改变了…程序员的…角色”，难道跟 AI 的其他技术流派模型对话，就能保持程序员的角色？显然不能。

在当下，AI 主要承接的是程序员手动生成、录入代码的人工负担，其余构思、表达、审核、调试、验收等核心环节并未转移，只是各环节权重有调整，程序员角色依旧，说什么“更本质”？显然是伪命题。你误读在先，嘴硬只会骑虎难下。

@anonymous00

@livid 这人发 AI 生成的内容还不标注

@daokedao 言简意赅

@catazshadow 肤浅无知，自以为是，逞强嘴硬，黔驴技穷。

以前手写代码是一种享受，现在工期变得越来越短，活越来越多，这就不得不用 AI 。真的是 AI 让我们变得更累的吗，难道不应该怪那该死的资本家吗？

最近看到一篇文章： https://boristane.com/blog/how-i-use-claude-code/

@AN130 类似的事情 我也遇到过，所以现阶段还是不敢完全放手。
曾经我让 AI 写一些增删改查，它竟然写了个把数据库中的所有值都查出来，然后在 map 里做增删改，再写回去。
简单测试时候肯定是没问题，但是。。。

@anonymous00 嘴硬的是你，论文都贴给你了，斗大的神经网络看不见，非要白马非马还死不认帐

你这种低端物种怎么好意思当码农的？

反而我们这种完全不懂的才是最大的受益人.哈哈.越顶级的模型越好用