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