西秦记全球AI热点
AI Coding 蜜月期之后，我们重新思考了 AI 提效
AI Coding 蜜月期之后，我们重新思考了 AI 提效 – DolphinDB – 博客园
未来的竞争，不属于写代码最快的 AI，而属于工程环境更好、基础设施更强、业务理解更深的人。
Google CEO Sundar Pichai 在 Cloud Next 大会上透露，公司新产生的代码中已有 75% 由 AI 生成，而六个月前，这个比例还只有 50%。OpenAI 里普通工程师的 AI 使用已经大部分转向了自研的 Codex；如今这部分工程师约 99% 的输出 Token 都来自 Codex，人工敲键盘的角色已经被压缩到近乎象征性。
我们自己深度使用 AI Coding 半年下来，最开始也是这个感觉——直到真正把它放进企业系统里跑起来，才发现代码生成变快之后，露出来的是一堆过去被“写代码慢”这个瓶颈掩盖住的问题。
这篇文章想聊的，就是我们在实践里踩过的坑，以及从中总结出来、觉得值得参考的几个结论。
从代码补全，到能够理解需求、搜索资料、分析代码、制定方案，再到自主修改代码、编写测试、运行验证，Coding Agent 已经开始从“辅助工程师写代码”，走向承担完整的软件开发任务。
过去，一个中型研发需求从接手到首次看到 Demo，往往要经历需求分析、代码阅读、技术调研、方案设计、内部讨论和实际开发。即便需求本身不复杂，从真正开工到见到结果，通常也需数周。
而在使用 Agent 后，这一过程被压缩到完全不同的尺度——一两天内完成需求理解、资料搜索、方案调研、代码设计、功能开发和测试，甚至一次性产出 2～3 万行 C++ 代码。有些相对独立的问题，几小时甚至一两个小时就能得到完整结果。更令人印象深刻的是，它不只“写代码快”，还能先给出一套看起来相当专业的解决方案，再交由工程师判断是否采用。
这种体验很容易让人产生一种判断：既然 AI 已经能够完成这么多工作，那么软件研发是不是很快就会进入一个新的阶段——人负责提出需求，AI 负责完成实现？
前不久，我们希望让 DolphinDB 的部分 Join 算子支持跨时间分区计算。用户通常按交易日分区存储数据，以便分布式执行。但对于加密资产这类 7×24 小时连续交易的场景，交易数据不再天然以自然日为边界，跨天、跨时间分区的计算需求越来越常见，因此我们决定补齐这部分能力。
结果相当惊人：不到两个工作日，Agent 基本完成了从分析现有代码、理解需求、设计方案，到编写功能、补充测试、生成设计和使用文档的完整流程。初步测试也未发现明显问题。
按照传统研发流程，这类需求涉及底层执行逻辑、分区机制和多个 Join 算子，人工开发往往需要数周甚至更久。Agent 将这一过程压缩到了不到两个工作日。当时我们的第一反应不是怀疑，而是兴奋——AI Coding 的效率确实令人震惊。
这些问题并不简单是“代码写错了”。Agent 对需求的理解基本正确，算法设计也没有明显问题。真正的问题在于，它并没有完整掌握几十万行代码背后那些分散的技术约束：哪些分区方式存在特殊限制，哪些数据类型尚未支持，哪些能力只存在于 SQL 层而函数式接口尚未实现，以及哪些历史遗留限制会影响新功能。
这次经历并未让我们降低对 AI 的判断，反而让我们更确信：AI Coding 已足够强大，真正值得重新思考的是——当代码生产速度大幅提升后，企业的软件研发体系应如何改变？
一个需求从提出到上线，远不止编码。需求分析、方案设计、开发、Review、测试、发布，每个环节都可能是瓶颈。过去编码占用大量时间，提升编码效率收益明显；但 Agent 能在几小时内完成过去数周的工作后，其他环节的重要性迅速上升。
若 AI 将开发从五天缩至一天，但 Review 仍需两天，测试仍需三天，发布仍需两天，整体周期不会缩短五倍。甚至可能出现相反情况：AI 产生更多代码和 PR，Review 和测试工作量增加，原本不突出的环节成为新瓶颈——这正是阿姆达尔定律在软件工程中的体现。
我们看到的“两小时写完，后续几周解决问题”，许多时候并非 AI 写错，而是复杂系统中修 Bug 往往是在补充原有架构和能力的缺失。局部功能可快速完成，但要进入复杂生产系统，涉及的依赖、验证和兼容性远超功能本身。
因此，AI Coding 下一阶段的关键不是让 AI 写得更快，而是让整个交付链路能承接这种速度——Code Review、自动化测试、CI/CD、发布和运维，都需逐步进入 AI 驱动的工程体系。
使用 AI 优化功能的经历让我们重新审视“AI 为何在复杂老系统中出错”这个常见问题。
最容易归因的是“幻觉”，但我们的感受并不完全如此。Agent 找到的资料、分析的结构、设计的方案可能都合理，问题在于这些信息往往只是系统事实的一部分。一个运行多年、数十万行代码的软件，真正约束不会全写在架构文档里——它们藏在历史接口实现、异常处理逻辑、事故后遗留的保护代码，或团队默认的规则中。人类工程师虽未必一次性看清所有，但至少知道“哪里可能有坑”，知道该问谁、重点检查什么。
Agent 则不同，它像一个能力很强但刚入职、未受公司培训的新人。给它独立的新系统（如内部新模块，无历史债、架构清晰），它能表现出色；但进入运行多年的大型系统时，面对“分区”“别名”等看似普通的功能，背后却可能存在大量历史代码和技术债。Agent 能理解一部分，却难以保证已覆盖所有隐藏约束。
所以，我们越来越认为，企业 AI Coding 的核心问题，不是简单增加 Token、文档或 Context Window，这已经不只是 Context Engineering，而是走向了更广义的 Environment Engineering。
代码生成日益廉价后，“重新实现一遍”会变得异常容易。但企业真正稀缺的从来不是代码本身。
一家运行多年的科技公司，真正沉淀的是数据库、计算引擎、中间件、内部 SDK、业务组件，以及围绕它们形成的大量生产验证能力。熟悉技术栈的工程师默认会复用这些能力——遇到数据处理，不会重写数据库；需要复杂计算，调用已有引擎；需要业务能力，寻找现成组件。
而对 Agent 来说，如果这些能力没有被显式暴露出来，它很可能根本不知道企业已经拥有它们，于是转身就把轮子又造了一遍。
在深度使用 AI Coding 之后，我们的感受并非“AI 不过如此”，反而是越来越清晰地意识到：AI 的能力已经足够强大，强大到足以实质性改变软件开发的生产方式。然而，恰恰是 AI 越强，越让我们看清一个本质问题——代码从来只是软件生产中的一个环节，而企业真正需要提升的，也远不止写代码这一件事。
1. 从 Coding Efficiency 走向 Delivery Efficiency
AI Coding 最容易被量化的，是代码生成量、Token 消耗、PR 数量和开发耗时。但这些指标，并不天然等同于企业真正关心的业务结果。
试想，如果 AI 让一位工程师一天开出十个 PR，而代码审查、测试和发布流程依然只能消化两个，那么企业得到的就不是十倍的交付能力，而是八个堆积在队列中等待处理的 PR。
因此，AI Coding 的 ROI，最终还是要回……
出处：https://www.cnblogs.com/DolphinDB/p/22733056（Hacker News 热度榜第 7 名 · 热度 96 · 讨论 0）