过去一周，AI 编程领域接连发生了几件容易被分开阅读的事。

8 月 17 日，Cursor 推出代码托管服务 Origin。它先开放仓库、拉取请求、代码浏览和 GitHub 同步，后续才会加入更多面向智能体的功能。两天以后，Cursor 又更新了云端智能体。智能体可以订阅拉取请求和 Slack 对话，在事件发生后继续工作，也可以带着一个长期目标反复处理测试失败和审查意见。

8 月 18 日，Anthropic 公开了一套内部 CI 值班方案。Claude 进入故障频道以后，可以读取监控、代码改动和团队留下的操作说明，先给出带证据的判断，再等工程师决定是否采取动作。8 月 21 日，Anthropic 又发布 AI 原生软件开发手册，开头用了一个很直接的判断。代码已经不再是开发流程里的主要瓶颈。

我把这几条消息排在一条时间线上，最扎眼的变化发生在写代码的前后。

智能体确实能更快地产生代码。省下的时间没有原样变成交付速度。需求还要说清，设计要有人确认，生成结果要跑测试，代码合并以后要盯部署，线上出错还得查原因。这些工作一直都在。过去，几天乃至几周的编码过程挡在中间，人们不容易看清它们各自花了多少时间。现在中间那段突然缩短，两边的等待、返工和判断便一起露了出来。

代码写完得太快，旧流程先堵住了

传统开发流程通常把大量时间留给实现。产品经理整理需求，工程师读完文档，再把设计一点点变成代码。测试、审查和部署排在后面，每一轮改动都要等前一轮写完。

智能体改变了这段时间的比例。Anthropic 在本周的开发手册里描述了一种很激进的做法。需求先写进 intent.md，随后生成可审查的 spec.md 和 plan.md。组织里的安全要求、代码规范和常见错误也被写成技能文件，跟着项目一起维护。一个阶段产生的文件通过人工确认以后，再触发下一个阶段。

这套方法带着很强的厂商立场，离多数公司的日常工作也有距离。它点出的麻烦却很具体。过去一天只能完成一项改动，安全团队还能逐行查看。智能体一天送来十项改动，审查人数没有随之增加，队列很快就会变长。团队若为了速度放松审查，问题会在部署以后出现。团队若保留原来的所有会议和签字，智能体带来的时间优势又会耗在等待里。

Google 的 DORA 团队在 2025 年调查了近 5000 名技术从业者，得到的结果与这项判断有一部分重合。AI 使用程度与交付吞吐量和产品表现呈正向关系，同时仍与交付稳定性呈负向关系。超过八成受访者觉得效率有所提高，仍有三成受访者很少信任或完全不信任 AI 生成的代码。DORA 给出的解释很朴素。改动量增加以后，自动测试、版本管理和快速反馈若没有跟上，原有弱点会更快进入生产环境。DORA 报告说明

写代码更快与软件更快上线，中间隔着一整套工程系统。AI 先加速了其中最容易演示的一段，剩下的环节开始决定总时间。

Cursor 要接管代码生成以后的等待

Cursor 做代码托管，第一眼很容易被理解成向 GitHub 扩张。现在就把 Origin 称为 GitHub 的替代品还太早。它处在早期测试阶段，只对付费用户逐步开放，面向智能体的功能也还没有全部发布。

Cursor 已经公开的功能仍然能说明它在解决什么问题。

一个云端智能体接到任务，先要拿到代码，再安装依赖，启动环境，找到相关文件。完成改动以后，它会创建拉取请求，等待测试和审查。测试失败了，它需要重新进入环境，恢复先前的目标，查看日志，继续修改。审查者晚几个小时留下一条意见，它又要被重新叫醒。

这些动作分散在代码托管、持续集成、聊天工具和智能体产品之间。每次交接都可能丢掉上下文，也会产生新的等待。Cursor 在 8 月 17 日发布的 Origin 先把代码和拉取请求放进自己的产品。8 月 19 日的更新又让云端智能体订阅拉取请求和 Slack 消息，持续处理 CI 失败与机器人审查意见。此前上线的环境构建功能会提前准备依赖和可运行副本，减少智能体每次开工前的安装时间。

把这几项功能放在一起，Cursor 想缩短的已经超出编码时间。它在处理任务开始以前的准备、代码写完以后的等待，以及一次长任务被多条外部消息打断以后怎样继续。

代码托管在这里有了新的用途。人类工程师把仓库当作协作和版本记录工具。长期运行的智能体还要从中读取目标、历史、测试状态和下一步动作。谁能让这些信息保持一致，谁就能减少智能体每次恢复工作时重新理解项目的成本。

GitHub 的优势仍然很厚。开发者关系、开源项目、企业权限、审查习惯和第三方集成都已形成多年。Cursor 不需要立刻搬走所有仓库，也能通过同步功能先接过智能体工作所需的那部分信息。Origin 眼下更像一次方向明确的试验。AI 编程公司开始伸手处理代码产生以后发生的事。

故障响应展示了人会留下什么工作

代码进入生产环境，开发过程并没有结束。

Anthropic 本周公开的 CI 值班案例 提供了一个很具体的过程。一次故障里，大约 44 项测试停止运行。Claude 查到当天开启的一项功能开关与问题有关，并判断回退开关是安全的。工程师让同事执行回退，Claude 三分钟以后再次检查，确认跳过测试的规则已经移除，错误率也回到正常水平。

Anthropic 称，这套系统在故障创建后给出第一份证据分析的中位时间为 14 分钟，最快能在 4 分钟内指出根因。这个数字来自 Anthropic 自己的使用记录，目前没有独立评估。案例仍然值得看，因为它把人的位置写得很清楚。

Claude 负责盯警报、查监控、读代码变更、形成假设和验证结果。工程师决定是否回退。操作说明写在代码仓库里的 Markdown 文件中，由团队共同修改。告警触发可以依赖确定规则，升级判断可以交给智能体，生产动作仍受权限和人工确认约束。

这里的效率来自调查时间缩短。人没有从流程里消失，他从翻日志和拼接线索的位置，移到了批准动作和承担结果的位置。这个位置花不了很多分钟，却需要了解系统、判断风险，也需要有人在失败以后负责。

完成一段代码与完成一个任务差得很远

AI 编程产品常用生成速度展示能力。一个提示发出去，页面、接口和测试很快出现。真实任务会继续追问。需求里的十个条件是否都满足，代码能否接进现有系统，边缘情况有没有测试，部署后是否稳定，用户最后能不能拿到可用结果。

8 月 18 日提交的 StartupBench 专门测量这种差距。研究者没有自行设想一组方便评测的小任务。他们先分析已经获得市场采用的 AI 产品，再把其中的工作流程改写成需要提交完整成果的任务。多个模型在同一套智能体框架下接受测试，表现最强的模型也只能完整完成大约三成任务。很多运行已经推进了相当一段距离，最后仍然没有交出满足全部条件的结果。

这是一篇刚提交的预印本，任务选择和评分方法还需要同行继续检验。三成这个数字不能直接换算成某家公司里的智能体成功率。它至少提醒了一件事。生成许多中间产物，与完成一个有人愿意采用的工作流程，仍有很长一段距离。

另一项研究给出的提醒更尖锐。METR 在 2025 年让 16 名熟悉开源项目的开发者完成 246 项真实任务。允许使用当时的 AI 工具以后，任务平均多花了 19% 的时间。参与者在实验前预计 AI 会让自己快 24%，实验结束后仍觉得自己快了 20%。METR 研究

这项实验样本很小，使用的是 2025 年上半年的模型，参与者又对项目非常熟悉，结果不能用来否定 2026 年的编码智能体。它留下的疑问依然有效。开发者看到代码迅速出现，很容易高估节省的时间。阅读生成结果、纠正方向、等待工具、验证改动和清理不合适的实现，也会花时间，只是这些时间散在任务各处。

人的工作正在向需求和结果移动

如果编码继续变快，工程团队最缺的能力会换位置。

任务开始以前，有人要把模糊想法写成可以检查的目标，说明用户需要什么，哪些限制不能碰，怎样才算完成。任务结束以后，有人要判断证据是否充分，风险能否接受，失败时怎样退回去。中间的代码仍然重要，代码量本身会越来越难说明工作完成了多少。

Anthropic 在本周面向初创公司的使用指南中，把受访公司的经验归纳成五条原则，其中包括让更多人参与交付、自动处理重复工作、保持验证、允许重新构建，以及先在内部使用再推向客户。这些建议来自十多家使用 Claude Code 的公司，仍属于供应商整理的案例。它们共同指向的工作变化很实际。团队需要把知识写下来，把验收条件变得可执行，把高风险动作留在权限边界以内。

这会产生一笔容易被忽略的成本。规范要持续维护，测试要覆盖真实失败，权限要按动作划分，日志要能追到一次智能体运行，出错以后还要把教训写回下一次任务能读到的地方。工具生成代码的价格可能继续下降，维护这些判断条件的人力不会同时归零。

以后衡量 AI 编程，单看生成了多少代码会越来越失真。更有用的问题会落到任务完成率、返工时间、审查负担、上线稳定性和事故恢复速度。它们都发生在写代码的前后，也都需要团队为结果负责。