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 才真正从一次性工具,转变为组织能力的一部分。
游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。
同类文章
批处理BAT入门教程第一篇
提供13个批处理实战技巧,覆盖全盘查找并删除文件夹或文件、拷贝移动文件、创建畸形文件夹及设置隐藏属性等场景,可一键完成系统维护与文件管理工作,极大提升自动化操作效率和便捷性。
从零开始批处理命令For循环详解与实战案例
批处理For命令支持 d、 l、 r、 f四个参数。 d仅列出当前目录下的目录名; r递归搜索指定路径及其子目录中的文件; l生成数值序列; f可解析文件、字符串或命令输出,通过delims、tokens、skip、eol等选项灵活处理内容。
批评你的人是你生命中的贵人
批评你的人往往最值得珍惜,因为他们关注你、助你成长。面对批评应包容反思,用行动改进而非辩解。接受批评是自我完善的过程,能让人少走弯路,避免重复犯错。这样的人正是生命中的贵人,值得感恩与珍惜。
测试人员角色定位与职责详解
测试人员角色经历了从找问题、保证质量到分析风险的转变,最终核心职责是提供关键信息,协助团队创造优秀产品。这包括识别问题、评估风险及帮助团队了解项目状态,而非单纯把关或追求完美。
经营成功测试生涯的实用方法与策略
一、测试生涯的起点 1989年,我在田纳西大学攻读研究生时,意外地从软件开发人员转行成为一名软件测试工程师。这并非我主动选择,说起来还有些戏剧性——某个早晨,教授质问我为何缺席那么多开发会议,我解释说这些会议总是安排在周末早上,对我这个第一次离家、刚入学的学生来说实在不便。结果呢?等待我的不是解聘通
- 日榜
- 周榜
- 月榜
相关攻略
2026-07-03 16:15
2026-07-03 16:14
2026-07-03 16:14
2026-07-03 16:14
2026-07-03 16:14
2026-07-03 16:14
2026-07-03 16:13
2026-07-03 16:13
热门教程
- 游戏攻略
- 安卓教程
- 苹果教程
- 电脑教程
热门话题

