Claude Code 带来的代码变革
如果要从 2025 年里挑出一个对开发者影响最大的 AI 工具，Claude Code 大概率会出现在很多人的第一选择里。无论是 X 上的讨论热度，还是程序员在真实开发场景中的使用频率，它都已经处在非常靠前的位置。
我自己从去年 9 月左右开始高强度使用 Claude Code 作为主力开发工具。最直观的感受，是随着大模型基础能力持续提升，以及 Claude Code 生态不断完善，从 MCP、Skill、Plugin，到后续的 Agent team 等能力逐步补齐，整个开发方式已经发生了明显变化。很多过去需要亲手完成的编码工作，如今都可以直接交给 Agent。
（如下是我本人最近两个月的 token 消耗情况
尤其是现在的 Claude Code + Opus 4.6 组合，在做原型和 Demo 时的推进速度已经相当夸张。过去可能需要花上几天时间反复搭框架、补细节、调接口的事情，现在往往几个小时内就能拉出一个可用版本，编码效率被大幅抬高。
不过，最近参加 Hackathon 时，我观察到了一个很有意思的现象：虽然我个人产出代码的速度比以前快了十几倍，但团队从产品想法形成到最终交付的整体周期，却没有按同样的比例缩短。真正卡住进度的，反而是那些"非编码"环节——我们仍然花费了大量时间在会议室里争论一个需求是否合理，反复沟通产品功能的边界在哪里，甚至为了单个页面的交互逻辑而来回拉扯。 Agent 把编码时间从几天压缩到了几小时，但需求确认和协作摩擦的时间却依然存在。
这个问题刚好在我读到 The Self-Driving Codebase 文章时，AI Agent 确实显著提升了编码阶段的产出速度，但在真实的软件交付流程中，测试、Code Review、部署、环境验证、问题回滚这些环节依然需要大量人工介入。只要这些步骤还停留在手动推进的状态，整个研发流程就很容易在后半段积压，团队总吞吐量也很难出现真正意义上的跃升。
类似的思路，最近也出现在 Stripe 团队公开分享的 Minions 平台中。Stripe 展示的重点，并不只是让 Agent 参与代码实现，而是把测试、执行环境、PR 生成和后续工程动作一并纳入自动化流程。工程师的关注点更多放在最终审核、质量把关和风险控制上。这样的变化，意味着 Agent 在工程体系中的位置开始发生转移：它已经能够承接持续执行的工作，并进入更完整的软件开发链路。
这也反映出当前 AI 行业中的一个重要趋势：Agent 的价值从代码生成，扩展到软件工程全流程的协作与执行。接下来的关键问题，已经变成如何让 Agent 在需求接入、任务拆解、编码实现、测试验证、代码审查、合并部署这些环节中稳定地 7x24 小时产出，并真正接入团队的日常研发流程。
7 X 24 小时的软件工程流水线
很多人在刚开始接触 Vibe Coding 时，都会对 Claude Code 频繁弹出的提权确认感到不适。操作一旦被反复打断，开发节奏就很容易被拖慢。于是，很多人（包括我自己）会直接加上 --permission-mode bypassPermissions。虽然我暂时还没有遇到 Agent 误操作到“删库跑路”这种极端情况，但这类用法显然不适合长期放在企业生产环境中。
继续往下看，很快又会碰到另一个问题：本地运行 Agent 的持续性太差。电脑合盖、设备休眠、网络波动，都会直接打断执行过程。OpenAI 和 Anthropic 显然也意识到了这一点，因此都在推进 Cloud Agent 这类产品形态，让 Agent 在云端持续运行，尽量摆脱本地设备的约束。
不过，真正体验过这类云端服务后就会发现，它们的控制粒度通常比较有限，对 MCP、Plugin 这类扩展能力的支持也还不够充分，整体操作手感距离本地 Claude Code 还有一段距离。
在这种背景下，很多人自然会想到另一条路线：把 Claude Code 部署到远程 VPS 上，通过 tmux 或类似机制持续运行。只要服务器保持在线，Agent 就可以长时间工作；开发者则通过 ssh 随时接入，继续查看进度或追加指令。
这个方案确实解决了“电脑合盖后任务中断”的问题，但新的难点也随之出现：怎样才能在手机等多端设备上，以足够轻量、方便的方式连接 VPS，并持续操作 Claude Code？
一个可行的答案，是使用 happy 这类工具，在多端之间接入 Claude Code，把远程 Agent 的操作链路真正打通。
即便如此，这套方案依旧只是"远程托管"——你仍然需要提前配置 MCP、准备 Skill 工具链，还得频繁查看日志、处理中间状态的报错。VPS 解决了 Agent 的"生存问题"（不断电），但没解决"自主问题"（要人盯）。
进一步思考后，一个更有意思的问题浮现出来：我们能否把目标从“远程使用 Agent”继续推进到“让 Agent 自主运转整条软件工程流水线”？The Self-Driving Codebase 提供的正是这样一种思路：把软件交付流程从"人盯着 Agent 做事"推进到"人负责验收与调度，Agent 负责持续执行"。
要实现这种"自动驾驶"式的流水线，至少需要重构三个环节：
-
触发层：从人工投喂到需求感知。 Agent 主动监听项目管理工具（Linear/Jira），自动读取需求文档、完成上下文理解，将大的 Feature 拆解为可并行的子任务，不再需要人类逐条输入指令。
-
执行层：从本地绑定到云端隔离。 每个任务在独立的沙箱环境（Sandbox）中运行，拥有隔离的代码分支、数据库副本和依赖环境。Agent 可以 7×24 小时并发执行，既不会搞乱你的本地开发环境，也不会因为电脑合盖而停摆。
-
交付层：从代码提交到完整证明。 Agent 提交的 PR 自带"作业证明"（Proof of Work）——通过的测试套件、安全扫描结果、性能基线对比。人类角色从"代码审查者"转变为"方案验收者"，只关注边界定义和风险决策，剩下的合并、部署、回滚都可以交给 Agent 按策略自动完成。
当然，对于大多数个人开发者而言，没必要一开始就追求企业级的完整流水线。更可行的起点是：在 VPS 上搭建一套最小化的 Agent 运行环境和基础任务编排。 这样可以随时丢给云端 Agent 去跑——哪怕你合上笔记本睡觉，它也能持续自查 Bug、修复问题、推进进度。（这里我推荐一下使用 hpai 去连接手机和 vps
构建 Agent 架构的工程挑战
全自动驾驶式的 Agent 流水线听起来很有吸引力：任务自动进入系统，Agent 自动拆解需求、实现代码、提交 PR、完成测试与部署，开发者只需要关注关键决策与最终结果。这样的图景确实令人兴奋，但工程现实远比想象复杂。对于大多数公司来说，难点在于如何围绕 Agent 建立一整套稳定可控的 infrastructure。
运行环境
第一层挑战，是为 Agent 提供一个完整、隔离、可靠的运行环境。
Agent 想要真正参与软件开发，光有代码仓库远远不够。它还需要访问构建工具链、测试框架、依赖管理系统、数据库副本、内部 API、私有镜像仓库，以及一系列与真实研发流程紧密相关的上下文资源。
这就意味着，企业需要为 Agent 准备一套接近真实研发环境的执行空间，例如隔离的虚拟机、容器化开发环境、带权限控制的沙箱等。
环境过于简陋，Agent 很多工作根本做不完；环境缺乏隔离，不同任务之间又容易互相污染，甚至影响生产资源。
进一步看，运行环境还要具备可复现性和可批量拉起的能力。只要 Agent 开始并发处理多个任务，环境初始化、依赖安装、状态清理、日志回收、执行缓存这些问题都会立刻变成工程瓶颈。
权限与治理
第二层挑战，是权限控制与治理机制。
如果完全照搬本地开发的思路，把读写权限、命令执行权限、网络访问权限全部开放给 Agent，那么任何一次误操作都可能带来非常高的代价。删除关键文件、错误修改配置、误触生产资源、泄露内部凭证，这些风险在企业环境里都无法忽视。
更关键的是，单靠 Prompt 中的提醒语句很难承担治理职责。告诉 Agent “不要删除文件”“不要修改某个目录”，这类约束更多只是一种行为引导。真正可依赖的治理机制，必须落在运行时层面，例如：
- 细粒度的文件系统权限控制
- 命令白名单与黑名单
- 临时凭证与最小权限访问
- 全量审计日志与可追踪执行记录
只有把这些能力放进底层执行框架中，公司才可能放心地让 Agent 长时间运行。
触发与任务编排
第三层挑战，是触发机制与多 Agent 编排。
如果每次都需要工程师手动发现问题、手动写 prompt、手动启动 Agent，那么整个系统依旧停留在“高级工具”阶段，谈不上流水线。
流水线的一个关键特征是保证任务能够持续进入系统，并按照预设规则自动运转。这就要求企业去设计清晰的触发源，例如：
- 来自 Linear、Jira、GitHub Issues 的需求工单
- 来自 Pull Request 的代码审查事件
- 来自 CI 失败、测试告警、安全扫描的系统信号
- 来自定时任务的批量检查与维护操作
有了触发源之后，还需要解决编排问题。一个 Agent 负责发现问题，另一个 Agent 负责定位原因，第三个 Agent 负责修复并提交 PR，最后再由专门的验证 Agent 完成测试与风险检查。任务一旦跨越多个阶段，系统就需要有明确的状态流转、责任边界和失败回滚机制。
否则，多 Agent 协作很容易演变成另一种混乱：任务重复执行、上下文丢失、多个 Agent 相互覆盖修改、错误被来回传递，却没有一个统一的调度中心去收敛结果。
On the Loop of Developer
回头看这几年 AI 在软件工程里的演进，会发现变化的速度远比很多人最初预想得更快。最早大家讨论的重点还是 Copilot 能不能把补全写得更准一些，后来变成 Claude Code、Codex 这类工具能不能直接接手一段完整任务，再往前走，问题已经扩展到了另一层：当 Agent 可以持续编码、持续执行、持续提交结果之后，软件研发流程本身会如何被重新组织？
真正发生变化的，并不只是“写代码更快了”。更深层的变化，在于软件开发正在从以人为中心的串行操作，逐步转向由 Agent 深度参与的持续执行系统。过去由工程师亲手串起来的需求进入、任务拆解、代码实现、测试验证、PR 生成、合并部署这些环节，如今都开始被重新拆分、重新连接，并交给后台长期运行的 Agent 去承接。
过去，工程师的大量时间会消耗在查文档、搭环境、改代码、读日志、修 CI、补测试这些具体执行动作上。接下来，更多注意力会被放到另一类问题上：需求是否值得做，产品方向是否成立，系统边界如何定义。
软件工程并没有因为 AI 而变得简单，真正被改变的是工程师分配时间与精力的方式。
从这个角度看，未来的软件工程师很可能会越来越多地站在 loop 之外，观察系统、设计约束、调整流程、验收结果，并在关键节点做出判断。真正有价值的能力，依旧包括技术深度和工程经验，只是它们的落点正在变化：从亲手完成每一个步骤，转向搭建一套可以长期稳定运转的系统；从关注单次编码效率，转向关注整条研发流水线的吞吐、质量与可靠性。