简介：近期一则“编码智能体连续运行 7 天、从零生成数百万行代码浏览器”的传播引发广泛质疑。开发者实测后发现，相关代码存在难以编译、结构混乱等问题，暴露出长时自动化编码在工程落地中的关键短板。本文从任务拆解、上下文管理、验证闭环、代码质量与成本控制等角度，分析让智能体长时间自主编码为何仍然困难，并给出可落地的改进思路，帮助读者理性评估 AI 编码能力边界。
近期，一则关于编码智能体长时间自主工作的实验被大量转发。该实验宣称让大模型驱动的编码智能体连续运行约 168 小时，从零开始实现一个规模达到数百万行代码的浏览器项目。官方表述中强调，随着 Token 成本不断下降，AI 可以持续迭代，直到完成过去需要人类团队数月才能实现的目标。
该说法的传播速度很快。原因是它触及了一个极具吸引力的想象：如果让智能体“不眠不休”地运行几天，是否就能自动产出大型桌面级软件、操作系统组件或复杂工程系统？
热度尚未消退，开发者社区便开始对公开代码进行核验。多个技术博客和代码评审指出，该项目并未达到可交付的工程标准。主要问题包括：
有评论者用较为尖锐的词汇形容该成果，认为其更接近“由 AI 生成的工程废料”，而不是可运行软件。争议焦点逐渐从“AI 是否能力不足”，转向“展示方式是否存在误导”。
这次事件并不能简单理解为“AI 造假”或“模型退步”。它真正暴露的问题在于：长时自主编码在演示中可以被描绘得很美好，但在工程验证、可维护性和真实交付条件下，仍然面临严峻挑战。
本文并不针对某一具体模型或产品进行评价，而是希望从通用软件工程视角，分析长时 AI 编码为何难以稳定产出大型可运行系统，以及开发者应如何正确设计自动化编码流程。
当前常见的长时编码智能体通常采用“规划—执行—反馈”的循环结构。
以一次简化任务为例，流程可描述为：
用户输入目标→ 智能体拆解任务→ 根据上下文生成代码→ 执行构建或测试命令→ 读取错误信息→ 调整代码→ 进入下一轮迭代
这种结构在短时间内完成脚本生成、单文件修复或小模块实现时具有一定效果。但当任务规模上升到浏览器、操作系统、大型业务系统时，复杂度会发生质变。
“7 天生成浏览器”的叙事隐含了几个前提：
在现实工程中，这些前提几乎都不完全成立。
演示更关注“过程是否令人震撼”，而工程交付更关注“结果是否可构建、可运行、可维护”。两者之间的差距，是本次争议产生的重要原因。
演示可以只展示代码规模、文件数量、提交次数等视觉化指标；而工程验证必须基于构建通过率、测试覆盖率、缺陷密度、模块耦合度等硬性指标。
人类团队在开发浏览器级项目时，会先进行系统架构设计，将工程拆分为 UI、渲染、网络、存储、安全、插件、更新等多个子系统。每个子系统再拆解为稳定接口与实现模块。
而智能体在长时间运行中，很难从全局视角持续维护这种结构。随着文件数量增加，模型会倾向于“局部补丁式”生成，而不是进行整体重构。
最终表现是：早期文件还有一定组织，后期文件大量堆叠，命名混乱，职责不清，模块边界消失。
大型项目依赖关系必须被集中管理。智能体在追加新功能时，可能引入不兼容依赖、重复依赖或循环依赖。
常见问题包括：
这些问题在小型项目中可以获得快速修复，但在数百万行代码中会迅速放大。
即使上下文窗口已扩展至数十万甚至上百万 Token，一个数百万行代码的项目仍然远超其容量。
智能体无法一次性阅读整个工程。于是只能读取“局部视图”，例如当前目录、若干相关文件、错误日志片段和任务摘要。
这种“盲人摸象”式开发会导致严重的不一致：A 模块假定 B 模块返回字符串，B 模块实现的却是对象；C 模块调用已被删除的函数；D 模块与 E 模块互相等待对方初始化。
为了继续工作，智能体系统通常会压缩历史信息。例如将过去的决策摘要为几句话，将旧代码总结为接口说明。
这个过程中，重要的约束条件、设计动机、未完成事项和失败原因非常容易被丢弃。于是智能体可能反复犯同类错误，或者在后续修改中破坏此前已经正常工作的部分。
很多自动化编码演示把“是否生成代码”或“是否能形成文件结构”作为进展标志。但真正有效的最低验证标准至少是：
在浏览器这类项目中，还要进一步验证渲染是否正确、网络请求是否稳定、安全边界是否有效、插件机制是否可用。
理想的长期编码流程应遵循“小步提交、持续验证”的策略：
实现一个小功能→ 立即构建→ 执行单元测试→ 合并稳定提交→ 再进行下一步
但如果验证步骤缺失，智能体可能在一段错误代码之上继续生成大量新代码。最终，整个分支已经无法构建，仍然被统计为“代码产出”。
在自动化编码实验中，最容易统计的是：
但这些指标与软件是否可用并非正相关。相反，在缺乏质量约束时，智能体可能被隐式鼓励生成大量冗余代码，以提高表面产出。
工程中有一种常见判断：不合适的代码不仅是零价值，还可能带来维护负担。
如果生成代码无法编译，存量贡献为零；如果结构混乱但暂时可编译，它会增加后续修改成本；如果同一功能被重复实现，它会造成语义冲突和调试困难。
因此，在评估 AI 编码结果时，必须优先采用“可验证的有效产出”指标，而不是简单统计生成规模。
“做一个浏览器”并不是一个可执行的软件需求。可执行的需求应包含：
如果没有这些定义，智能体会在开放目标中不断发散，产出大量看似相关却无法集成的内容。
为了提高长时编码的交付质量，建议设置硬性关卡。例如：
每 500 行新代码→ 构建一次→ 运行基础测试→ 只有通过后才允许继续
这种机制可以阻止错误传播，同时为智能体提供清晰的阶段目标。
若构建失败，智能体必须优先修复构建问题，而不是继续添加功能。否则会形成不可逆的集成债务。
在实际工程中，更稳妥的做法是让智能体承担边界明确的模块：
这些任务具有以下特点：
而在顶层架构设计、跨模块接口制定、性能瓶颈定位、安全边界确认等高风险环节，仍然需要资深工程师主导。
建议采用“人机共同规划”模式：
人类负责总体架构与约束→ 智能体提出实现计划→ 人类确认关键接口与里程碑→ 智能体按阶段执行→ 自动化验证→ 人类评审边缘情况
这种方式兼顾了智能体的生成效率与人类的架构控制力。
在生成实现代码之前，要求智能体先产出接口契约。例如：
契约一旦固定，未通过人类确认不得擅自修改。这样可以减少模块间随意耦合。
每个稳定提交都应满足：
避免出现“一次提交中包含数百个文件”的不可评审状态。
在持续集成流程中设置质量门禁，包括：
智能体只有通过门禁后，其改动才会被并入主干。
在需要大规模实验时，企业可以借助云端资源为不同分支并行提供构建与测试环境。通用能力包括：
这些能力并不专属于某一家云厂商，而是大规模自动化软件开发中的通用工程基础设施。
智能体运行多久、消耗多少 Token、生成多少行代码，都不能代表项目质量。团队应关注：
例如：
边界不是限制能力，而是保护项目稳定性。
即便智能体可以连续工作，也应设计固定的人类复审节奏。例如每日或每完成一个里程碑后，对变更摘要、架构影响和异常行为进行评审。
这可以避免智能体在错误方向上运行过久，造成资源浪费。
对外沟通 AI 编码成果时，更可信的证据包括：
如果只有代码规模和时间叙事，而缺乏上述证据，开发者有理由保持谨慎。
“让 AI 连续运行数天并生成完整浏览器”的说法之所以能够快速传播，是因为它符合人们对自动化生产力的浪漫想象。但从软件工程角度看，大型项目不是代码的简单累加，而是结构、约束、验证和可维护性的综合产物。
当前编码智能体在小范围、可验证、契约清晰的任务中已经能够产生实际价值。然而，一旦进入长时间、开放目标、百万行代码级别的项目，仅靠模型不断生成内容，很难自动形成可交付软件。
真正值得投入的方向，不是追求“AI 连续肝了多久”，而是构建一套以编译、测试、评审和门禁为核心的自动化工程闭环。只有在这种硬约束下，AI 编码才能从“看起来很厉害”走向“确实可用”。
对于开发者和企业而言，更务实的策略是：
AI 长时编码的长期价值，不在于一次性生成多少代码，而在于能否持续、稳定地降低可靠软件的交付成本。