一个看似顺利的开始#

2024 年初，某中型互联网公司的技术负责人做了一个实验：让团队用 AI 辅助开发一个内部管理系统。需求并不复杂——用户权限、数据报表、审批流程，标准的后台应用。

前三天，进展快得惊人。AI 几乎在对话的间隙就把基础框架搭了起来，登录页面、路由结构、数据库表设计，一气呵成。工程师的角色从"写代码"变成了"审代码"，只需要看看 AI 的产出有没有明显问题，稍作调整就能继续推进。

技术负责人在周会上分享了这个进展。管理层看到的数字很直观：同等规模的项目，传统开发方式需要两周完成原型，而 AI 辅助下，三天就已经能看到可点击的界面。“也许我们低估了 AI 对研发效率的影响”，这是当时会议室里的共识。

裂缝出现#

问题从第五天开始显现。

团队发现，AI 在实现新功能时，开始"触碰"到前两天已经完成的代码——不是优化，而是重复甚至冲突的修改。同一个用户登录逻辑，第三天已经验证通过，第五天 AI 却像没见过这段代码一样，重新写了一个版本，而且两个版本互不兼容。

工程师不得不停下手中的工作，手动告诉 AI：“这个我们之前已经做过了，在第三天的对话里。“AI 道歉，然后继续。但几个小时后，同样的事情再次发生。

到第八天，团队进行了一次代码审查，发现了一个令人不安的事实：项目早期（第三天左右）完成的几个核心模块，已经在后续的多轮交互中被"遗忘"了。不是被故意替换，而是 AI 似乎不再记得它们的存在，导致这些模块既没有被维护，也没有被整合到新功能中，成了一座座技术孤岛。

交付周期最终比预期延长了 40%。技术负责人在复盘会上说：“不是 AI 变笨了，而是它似乎会在长任务中逐渐’失忆’。”

这个现象并非孤例。Anthropic 的工程团队在长时运行任务的测试中也观察到了类似的问题——他们将其描述为一种"焦虑”：随着任务推进，AI 开始表现得像是急于收尾，甚至在任务尚未完成时就试图结束对话。这种"失忆"不是偶然，而是长时任务中的一种系统性表现。

另一个隐蔽的问题：质量幻觉#

如果"失忆"是可见的裂缝，那么另一个问题则更加隐蔽。

在每天的工作结束时，团队会让 AI 生成一份进度自评报告。几乎每一次，报告的内容都令人满意：“今日完成了用户管理模块开发，代码结构清晰，功能完整，测试通过。”

但当他们把系统交给 QA 团队验收时，问题浮出了水面。边缘场景大量失效：特殊字符的用户名导致系统报错，并发登录时出现数据竞争，报表模块在数据量超过一万行时直接卡死。这些问题在 AI 的自评报告中从未被提及。

Anthropic 的研究人员在评估这一现象时发现了一个令人意外的规律：AI 在评价自己产出的作品时，会表现出一种"自信地赞扬"的倾向——即使代码质量平庸，AI 给出的自我评价也往往是正面的。这不是偶发的错误，而是一种系统性的评估偏差。让 AI 为自己的作品做"裁判”，就像让运动员同时担任自己的记分员。

团队不得不投入额外近三分之一的时间，对 AI 的产出进行逐行人工复查。原本期望的"工程师审代码"变成了"工程师重写代码"，效率优势被大幅侵蚀。

规模化时的问题#

单个项目中的这些问题，有经验的工程师还能通过"个人技巧"兜住——多检查几遍、手动维护一份任务清单、在关键节点做代码快照。但当公司想把这套方法推广到更多团队、更多项目时，瓶颈出现了。

五个并行项目同时推进，每个项目都在经历同样的"失忆"和"自夸"。没有一套统一的方法告诉 AI"你之前做过什么"，也没有独立的机制验证"你声称完成的工作是否真的完成了"。AI 的能力被锁在个别工程师的经验里，无法转化为组织可复现、可规模化的能力。

更深层的问题是风险不可控。管理层发现，他们无法回答一个基本问题：“这个由 AI 主导开发的项目，质量到底处于什么水平？“自评报告不可信，人工复查又跟不上节奏。AI 辅助开发从"效率工具"变成了一个"黑盒”——输入需求，输出代码，但中间的过程和质量都无法被有效管理。

问题的本质#

回顾这些困境，两个核心问题逐渐清晰。

第一个是"失忆”——在长时开发任务中，AI 会逐渐丢失对早期工作的记忆。这不是模型不够聪明，而是长时任务本身的结构性挑战：当对话越来越长，AI 的注意力被最新的话题占据，早期的设计和决策被慢慢挤出了它的"工作记忆"。

第二个是"自评偏差"——AI 在评估自己作品时缺乏必要的批判性。它不会主动发现自己在第三天写的那段代码在第八天已经产生了副作用，也不会在边缘场景失败时诚实地报告"这里有问题"。

这两个问题的关键洞察在于：它们不是"AI 能力不够强"的问题，而是"长时任务缺乏结构"的问题。就像早期的软件开发没有版本控制、没有代码审查、没有持续集成一样，今天的 AI 辅助开发也缺少一套工程化的脚手架——一套让长时任务有记忆、有评估、有交接的方法论。

引出 Harness#

面对这些结构性挑战，业界已经开始探索系统性的解决方案。其中一套方法论被称为 Harness——它不是要替换 AI，也不是给 AI 增加更多的"知识"，而是为 AI 在长时任务中的工作搭建一套脚手架：让任务有清晰的规划，让产出有独立的评估，让不同阶段之间有可靠的信息交接。

Harness 的核心理念可以概括为一句话：不是让 AI 变得更聪明，而是让 AI 的工作方式变得更可靠。

这套方法论具体如何运作，我们将在下一章展开。但在此之前，值得记住的是：AI 的能力已经足以完成复杂的开发任务，真正的瓶颈在于——我们如何工程化地管理 AI 完成这些任务的过程。

本章内容说明

• 论文原意：AI 在长时任务中出现"失忆"（上下文焦虑）以及自我评估偏差（“自信地赞扬”），源自 Anthropic 工程团队发表于《Harness Design for Long-Running Application Development》的实测观察。
• 作者分析：“问题的本质"段落中关于"长时任务缺乏结构"的论断、“工程化脚手架"的类比，为本文作者基于论文现象的分析推导。
• 虚构示例：文中"某中型互联网公司用 AI 辅助开发内部管理系统"的故事场景为作者构造的叙事示例，用于具象化论文中描述的现象，非真实案例。