关注「索引目录」公众号，获取更多干货。
我们正处于软件开发的关键时刻。短短几年内，LLM（语言学习助手）就从令人印象深刻的聊天机器人发展成为直接集成到IDE（集成开发环境）中的功能齐全的编码代理。
这促使整个行业竞相利用人工智能提升开发者的速度。目前已有 84% 的开发者使用人工智能工具，而像谷歌这样的公司也表示，其 25% 甚至更多的代码都是由人工智能生成的，这无疑表明了人工智能的强大力量。
目前来看，这还没有转化为代码生成量的显著增加，但这种情况正在发生变化。模型和工具正在快速发展，智能体现在能够并行处理更长的编码任务。
目前，这种工作流程仍在完善中。我们正处于过渡阶段，工具虽然有用，但通常需要大量的验证，这限制了最终提交到 PR 的代码量。但随着工具的不断改进，每个开发者的代码产量只会越来越高。
这就是目标。各个团队现在采用这些工具，期望它们能持续提高开发人员的效率，最终使同样的团队能够编写出5倍甚至10倍的代码。
但实现这一目标后，未来将面临一项严峻挑战。由此带来的代码输出爆炸式增长，势必会加剧现有的持续集成/持续交付（CI/CD）瓶颈，其加剧程度与代码效率的提升成正比。
隐形队列
想象一下这样的工作流程：一位开发人员同时运行三个 Cursor 会话。一个会话重构身份验证服务，另一个会话为通知系统添加新功能，第三个会话优化数据库查询。一天结束时，她已经准备好了三个待发布的 PR。将这种情况乘以一百位开发人员，你就能体会到即将涌入传统 CI/CD 流水线的代码规模有多么庞大。
如果不对验证基础设施进行与开发者工具同步的现代化改造，代码生成速度的提升永远无法转化为生产力的同等提升。相反，这将导致合并危机。所有提交的 PR 都会继续堆积在同一个瓶颈：验证环节。
代码审查成了新的瓶颈。即使有了人工智能辅助审查，仍然需要人工签字确认。如果团队实现了开发人员产出提高 5 倍的目标，那就意味着每周有数百个 PR 需要人工审核、测试和批准。积压的 PR 越来越多，积压的 PR 也越来越长，冲突也越来越多。
但真正的混乱发生在合并之后。所有代码都部署到了预发布环境，结果预发布环境崩溃了，因为在所有微服务都一起部署之前，没人能真正测试它们的交互情况。现在，100名开发人员被困住了，只能眼巴巴地看着崩溃的预发布环境，等待有人来收拾残局。
唯一的出路
只有一个解决办法，而且这个办法与直觉相悖：多做测试，但要更早进行测试。
不是单元测试，也不是模拟测试，而是真正的集成测试，端到端测试，针对实际服务运行的测试。但关键在于：在本地开发阶段，甚至在提交 PR 之前，就针对每一次代码变更执行这些测试。
换个角度想。现在，Cursor 会话正在生成代码。它编写了一个新的 API 端点，更新了三个服务调用，并修改了一个数据库模式。开发人员审查了代码，觉得没问题，然后提交了 PR。接下来就是漫长的等待。代码审查队列。持续集成 (CI) 流水线。在预发布环境中进行手动测试。也许成功了，也许失败了。无论如何，你都要等上几个小时甚至几天才能知道结果。
如果 Cursor 在编写代码的同时，也启动一个轻量级的测试环境，部署这些更改，运行集成测试，并验证一切是否正常，所有这些操作都在开发人员切换回该选项卡之前完成，那会怎么样呢？
那不是科幻小说。在智能体时代，发展就应该这样进行。
这次是真的要左倾了
我们讨论“左移”已经很多年了。这一次，它不是可选项，而是关乎生存的关键。
其模式是：人工智能代理生成的每个代码单元都在本地开发过程中进行端到端测试。不是在合并之后，也不是在PR审查期间，而是在编写过程中。
当这种方法奏效时，奇迹就会发生。提交审核的 PR 不再是碰运气，而是已经过验证。审核人员会看到：“15 个集成测试通过，3 个端到端流程验证通过，契约测试也已完成。” 代码审核变得快捷高效，信心倍增，合并迅速完成，预发布环境始终保持绿色状态。
这时 Signadot 就派上用场了。
让它成真
解决方案并非更好的代码审查工具或更快的持续集成流水线，而是将验证本身并行化。
并行验证
要解决队列阻塞问题，我们必须在本地开发期间启用完整的集成测试。
Signadot 允许开发人员使用现有的测试环境作为共享基线。通过隔离请求而不是复制基础设施，每个开发人员都能获得一个沙盒化的虚拟私有测试环境。
这使得 100 多名开发人员可以在同一集群上并行进行测试，而不会互相影响。无需排队，没有资源争用，也无需等待测试环境空闲。
通过 MCP 实现代理原生基础架构
Signadot 通过 Signadot MCP（模型上下文协议）服务器直接集成到 AI 编码工作流程中。
像 Cursor 和 Claude Code 这样的工具现在可以“与”基础设施“对话”。它们使用简单的英语命令来实例化沙箱、配置路由，并直接从代理界面管理资源。
代理程序不需要您切换上下文。它处理基础设施的方式与处理代码的方式相同。
双向隧道
一旦请求沙箱，Signadot 就会在代理的本地环境和远程 Kubernetes 集群之间建立一个安全的双向隧道。
从集群中的测试环境 UI 触发的请求会被路由到您的本地计算机。同时，您本地运行的服务会直接访问集群中的远程依赖项——数据库、身份验证和其他微服务。您是在真实的堆栈上进行测试，而不是在模拟环境中。
基于流量捕获的AI驱动测试生成
当您与本地服务交互时，Signadot 会捕获实际的请求/响应流量。编码代理会分析这些捕获的流量，自动生成功能性 API 测试，确保您的更改不会破坏现有合约。
无需手动编写测试用例。代理程序会观察您的服务实际运行情况，并编写测试用例来验证这些行为。
自主调试循环
测试失败？代理程序会读取直接从 Signadot 沙箱流式传输的实时日志，以精确定位错误。它会修正代码，并立即在同一个沙箱中重新运行测试。
这样就无需人工干预即可形成闭合的反馈回路。智能体会不断迭代，直到测试通过，所有这些都在本地开发过程中完成。
发布 PR 时，请附上沙箱链接。审核人员可以清楚地看到测试内容、测试结果以及验证的边界情况。PR 会在几分钟内从“需要调查”变为“可接受”。
真正的解锁
智能编码工具承诺代码生成速度提升 10 倍，各公司都在竞相实现这一目标。但如果没有细致的合并前测试，我们的发布速度仍然只能达到 1 倍。
最终胜出的公司并非那些编写代码最多的公司，而是那些能够以与编写速度相同的速度验证并发布代码的公司。这意味着测试的粒度要与编码的粒度保持一致：每一次更改、每一个分支、每一次实验。
瓶颈正在转移。问题是你的测试基础设施是否也随之转移。
在 Signadot，我们正在构建一个平台，让智能编码真正高效。因为 PR 队列中的代码没有价值，生产环境中的代码才有价值。
关注「索引目录」公众号，获取更多干货。