游乐游手机版
首页/AI教程/文章详情

AI越来越强,为何你反而更疲惫?

时间:2026-07-03 15:48
AI能力提升但人类反而更累,因为需为AI生成结果兜底、审查速度跟不上生产速度,且知识未沉淀。返工根源在于产品定义不清晰。未来应建立产品事实层,沉淀决策与认知,让人类负责关键判断而非逐行审查。

过去半年,AI 编程能力的进化速度确实令人惊叹。无论是编写代码、补充测试用例、自动生成文档、辅助调研分析,还是修复程序缺陷,许多以往需要数天甚至数周才能完成的任务,如今仅需数小时即可交付。

然而,一个越发明显的现实是:AI 技术越来越强大,开发者却并未因此感到更轻松,反而承受了更沉重的负担。

这种疲惫感的根源,并不仅仅是工作量的增加,更在于注意力、判断力与责任感的持续透支。

AI 执行速度极快,但最终的保障责任依然落在人身上。

AI Agent 可以在短时间内生成大量代码与测试脚本,但这些输出是否正确、是否安全、是否符合产品目标,仍然需要人工判断。问题在于,AI 的生产速度已远远超过人类的审查效率。一个 Agent 一小时能产出数千行代码,但工程师很难在同一时间段内真正理解这些代码的逻辑与影响。

由此形成了一个悖论:

若不做代码审查,系统风险不可控;若逐行认真审查,AI 带来的效率优势又几乎被抵消。

在实际工作中,许多人已经没有足够的时间去完整验证 Agent 的产出,只能粗略检查能否运行、测试是否通过、页面显示是否正常,然后默认任务完成。然而,“可以运行”与“真正正确”之间,往往存在显著差距。

一篇题为《说好的烧一辈子 token 呢》的分享中提到,AI 可能会生成大量价值有限的测试用例,拖慢 CI/CD 流水线;当问题出现时,开发者既不清楚哪些内容该删除,也难以判断所谓的修复是否真正解决了实际缺陷,还是仅仅用 mock 绕过了症状。

我们交付了大量产出,但真正沉淀下来的知识却很少。

另一个更值得关注的问题是:借助 AI 完成了很多工作,但开发者自身的经验积累并未同步增长。

在传统开发模式下,工程师通常清楚某个功能为何存在、方案为何如此设计、哪些路径被放弃、当前实现存在哪些限制。即便代码并不完美,参与者至少理解整个决策过程。

而在 Agent 辅助编码的场景中,工作流程往往变成:

人提出需求,Agent 搜索代码、生成方案、反复修改,最终功能跑通。

结果仓库里留下的通常只有代码本身。

至于 Agent 为何这样编写、做过哪些判断、哪些约束来自产品需求、哪些只是模型的临时选择,往往无从追溯。

于是,产品虽然交付了,但产品背后的知识并未随之交付。几个月后,团队只看到一堆可以运行的代码,却很难解释它为什么是现在这个状态。

这意味着,大量 Token 只完成了一次性劳动,并未转化为长期的组织资产。

真正值得沉淀的,不只是代码,而是:如何定义问题;确认了哪些事实;做出了什么取舍;为什么选择这个方案;哪些假设仍然未被验证。

如果这些内容没有留存下来,下一次遇到类似问题时,团队依然需要从头消耗 Token。

返工的根源,往往不在于模型能力不足。

很多 AI 导致的返工,表面上是 Agent 没有理解需求。

但深入追问会发现,问题通常不是 Agent 不够智能,而是团队自身也没有形成稳定、明确、可引用的产品定义。

产品经理在聊天中提过一种方案,设计稿表达的是另一种方案,代码里保留着历史逻辑,会议上又临时调整了边界。Agent 每次工作,都需要重新拼接这些碎片信息。

于是,大量 Token 被消耗在重新理解项目、搜索历史信息、猜测真实需求、修正上一轮误解上。

更棘手的是,当前的 Agent 大多是本地优先的。它运行在某位开发者的电脑和代码仓库中,只有一段局部上下文。一个工程师与 Agent 讨论了一下午,第二天另一个 Agent 并不知道之前发生过什么。

Git 可以同步代码,却很难同步产品认知。

Agent 之上,需要建立一层产品事实层。

这也是我正在打造 Product Spec 系统的原因。

\

它并非普通的 PRD 管理工具,而是一个面向 Agent 的人机协作系统,可以理解为位于所有 Agent 之上的“产品事实层”。

每次 Agent 工作时,都会产生大量与产品定义相关的信息,例如:某个功能为何存在;用户身份应该如何合并;哪些版本只向部分用户开放;某个字段为何废弃;哪个方案因安全或成本原因被否决;什么才算真正完成。

这些内容不应只停留在一次性对话中,而应该被提取出来,形成可版本化、可追踪、可确认的产品事实。

这样一来,新的 Agent 在开始工作前,无需重新猜测产品需求,而是可以直接读取当前有效的产品定义;工作完成后,再将新产生的事实、决策和变更提交回来。

代码仓库保存“系统现在是什么样”,Product Spec 保存“系统为什么变成这样”。

人不应该审核所有内容,而应该负责关键判断。

“Human in the loop”不意味着人要逐行检查 Agent 的所有输出。

如果所有代码、测试、文档和操作都必须由人逐项确认,人迟早会成为整个系统的瓶颈。

更合理的分工是:Agent 负责搜索、整理、生成、执行和验证;人负责目标、优先级、边界、取舍、品质和责任。

人真正应该关注的,不是 Agent 每一步的具体操作,而是:为什么要做;做到什么程度;什么才算完成;哪些结果可以接受;哪些代价不能接受。

AI 时代真正稀缺的,不再仅仅是编码能力,而是稳定的注意力、清晰的问题定义、产品判断力以及组织记忆。

未来衡量 AI 生产力,不应只看消耗了多少 Token、生成了多少代码、完成了多少任务,而应关注:每一次 Agent 工作之后,组织究竟留下了什么?

如果只留下代码,我们只是在制造更多未来需要理解与返工的内容。

如果还能留下事实、决策、约束和认知,那么 AI 才真正从一次性工具,转变为组织能力的一部分。

来源:https://cloud.tencent.com.cn/developer/article/2702073
上一篇阿里云老用户消费返现 个人最高100元企业200元 下一篇Cowart Codex无限画布,在图片上直接标注修改
本站内容用于信息整理与展示,如有侵权或内容问题请及时联系处理。

相关推荐

补充同频道和同主题内容,方便继续浏览更多相关内容。

同类最新

继续查看同栏目最近更新的文章。

更多
批处理BAT入门教程第一篇
AI教程 · 2026-07-03

批处理BAT入门教程第一篇

提供13个批处理实战技巧,覆盖全盘查找并删除文件夹或文件、拷贝移动文件、创建畸形文件夹及设置隐藏属性等场景,可一键完成系统维护与文件管理工作,极大提升自动化操作效率和便捷性。

从零开始批处理命令For循环详解与实战案例
AI教程 · 2026-07-03

从零开始批处理命令For循环详解与实战案例

批处理For命令支持 d、 l、 r、 f四个参数。 d仅列出当前目录下的目录名; r递归搜索指定路径及其子目录中的文件; l生成数值序列; f可解析文件、字符串或命令输出,通过delims、tokens、skip、eol等选项灵活处理内容。

批评你的人是你生命中的贵人
AI教程 · 2026-07-03

批评你的人是你生命中的贵人

批评你的人往往最值得珍惜,因为他们关注你、助你成长。面对批评应包容反思,用行动改进而非辩解。接受批评是自我完善的过程,能让人少走弯路,避免重复犯错。这样的人正是生命中的贵人,值得感恩与珍惜。

测试人员角色定位与职责详解
AI教程 · 2026-07-03

测试人员角色定位与职责详解

测试人员角色经历了从找问题、保证质量到分析风险的转变,最终核心职责是提供关键信息,协助团队创造优秀产品。这包括识别问题、评估风险及帮助团队了解项目状态,而非单纯把关或追求完美。

经营成功测试生涯的实用方法与策略
AI教程 · 2026-07-03

经营成功测试生涯的实用方法与策略

一、测试生涯的起点 1989年,我在田纳西大学攻读研究生时,意外地从软件开发人员转行成为一名软件测试工程师。这并非我主动选择,说起来还有些戏剧性——某个早晨,教授质问我为何缺席那么多开发会议,我解释说这些会议总是安排在周末早上,对我这个第一次离家、刚入学的学生来说实在不便。结果呢?等待我的不是解聘通