“2025年 AI coding 将如何演进”播客文稿
YouTube：https://www.youtube.com/watch?v=Ux5k0ACfgDU
唐小引： 刚才我们聊到了 AI coding 整个的发展演进，比如从 Copilot 的竞逐，再到 Agent 的出现。当然，现在很多小伙伴依然在使用 Copilot，同时我们也看到这些 AI 工具的创造者们紧跟需求，不断迭代。比如有位小伙伴提到通义灵码，在我们直播前刚刚进行了全新的升级发布，待会儿陈鑫老师会详细介绍。基于这些背景，我们组织了今天的对话。
让我们隆重邀请今天的嘉宾。首先是不在国内，但国内 AI 编程界总能听到他声音的海龙老师。海龙总，给大家打个招呼并做一下自我介绍吧。
张海龙： 大家好，我是张海龙。我是一名程序员，现在每天也在写代码，希望今天能和大家有良好的交流。
唐小引： 谢谢海龙总。虽然海龙总已经是创业者，但依然保持着浓厚的程序员特质。他持续在 CSDN 和自己的渠道输出很多文章，大家可以持续关注。接下来是今天很多观众都是他的粉丝 - 宝玉老师。
宝玉： 大家好，很高兴有机会在这里和大家一起继续分享 AI 编程相关的经验。我本身也是程序员，每天会花大量时间使用 AI 和 AI 编程工具。同时我也在 X 和微博上与很多网友互动，经常会收集到大家使用 AI 过程中的问题、困惑或反馈，我也会尽我所能做出解答。今天是另一种形式的交流，很期待接下来和大家的互动。
唐小引： 谢谢宝玉老师。接着是我们国内 AI 编程工具在 CSDN 开发者调查报告中排名前两位的负责人。请陈鑫老师和勤锴老师给大家打个招呼。
陈鑫： 大家好，我是来自阿里云的陈鑫。我们做通义灵码，主要服务于中国的开发者，包括很多企业的开发者，我们都有很多交流。借这个机会给大家讲一讲目前中国 AI coding 整个领域大家的需求和进展。
郑勤锴： 大家好，我是来自智谱 AI CodeGeeX 团队的技术负责人。我们 CodeGeeX 是国内最早开始做代码大模型和智能编程助手的产品之一。今天很高兴能和各位老师一起聊一聊 24 年 AI coding 的进展，以及对 25 年的一些展望。
唐小引： 感谢各位老师。接下来我们正式进入今天的对话。首先，因为我们现在正处于岁末年初，如果让各位老师来总结 2024 年 AI coding 的发展，你们会想到哪些关键词和重要命题？
唐小引： 海龙总，要不您先来，您是前辈。
张海龙： 2024 年我相信大家都了解，今年在 AI coding 上有一个很大的进步，就是出现了 Cursor。大家以前认为 GitHub 做了 Copilot 这么长时间，这个方向上的竞争可能已经结束了，产品形态也相对稳定了。但没想到会出现 Cursor 这样具有颠覆性效果的产品。如果回想 2024 年，这是给我印象最深刻的，而且我现在每天都在用，确实带来了非常好的效果，是今年这个领域最惊艳的事件。
唐小引： 还有第二个吗？
张海龙： 我其实别的工具也都用了，但是都没有让我觉得很心动。
唐小引： 好的。宝玉老师，您来分享一下。
宝玉： 我总结几个关键词。第一个是很火的话题 - 不懂代码的产品经理也能开始借助 AI 编程写程序。这是前段时间争议很大的一个话题。我现在先提几个点，但不展开讨论，如果大家有兴趣我们后面可以继续探讨。
刚才提到了 Cursor，但我想强调的是，Cursor 之所以能火起来，不完全是因为它在交互上的创新，更重要的是因为它背后模型的升级。我认为很大的功劳是 Claude 推出的 3.5 Sonnet 模型，它已经成为现在 AI 编程工具的标配。这个模型在上下文长度、生成速度和生成质量几个方面都达到了很好的平衡，才让像 Cursor 这样的工具有机会被大众熟知，能真正解决问题。
说到模型，还有一个重要的是 Anthropic 的 Claude 3.5 Sonnet 模型，对编程领域来说也是 2024 年的一个重要突破。这个模型相对来说使用成本会高一些，所以可能使用的人不如 Claude 多。我因为花了一些钱每天在用，对比下来会发现 Claude 3.5 Sonnet 生成的代码质量明显更好。如果用程序员级别来说，Claude 的代码生成水平大概在刚到中级或稍微高一点的级别，而 Claude 3.5 Sonnet 已经接近高级程序员水平。它写的代码质量有时候比我还要好，而且在我不熟悉的领域也能生成很好的代码。
最后一个关键词是 AI Agent。这个话题也很火，去年 Devi n 推出了第一个我认为可以算作真正意义上的 AI Agent。虽然还比较初级，但是未来可期。
唐小引： 那宝玉老师我追问一下，您刚才提到 Cursor 背后主要依赖于 Claude 模型，但 Cursor 其实支持多个模型。您的意思是 AI coding 的性能很大程度上依赖于它使用的底层模型吗？
宝玉： 没错，这确实是个很好的问题。去年最火的几个编程工具中，Cursor 是最突出的一个。后面还有类似的 Windsurf，它背后主要也是用的 Claude。还有一些不需要本地搭建环境的工具如 v0.dev，它也是用的 Claude。
很明显地，v0 和 Cursor 最开始都是用 GPT-4，但没有火起来。因为 GPT-4 的问题在于它的上下文长度有限，没有 Claude 那么长，所以它的初始提示词不能很长。如果你的提示词或者输入的代码稍微长一点，它的输出就会受限。但 Claude 不一样，它不仅能接受很长的提示词，而且即使输入很长，它也能很好地抓住你的指令，生成高质量的代码。如果没有这些模型的支撑，像 Cursor、v0 这样的工具是不可能成功的。
唐小引： 既然如此依赖底层模型，那为什么大家不直接使用模型，而是要使用 AI 编程工具呢？
宝玉： 这也是个好问题。比如我现在用 o1 Pro，它其实是没有工具的。我的痛点在于每次跟它交互，我都要手动把每个代码文件复制出来，要整理我的提示词，然后穿插这些代码，每次都要做很多繁琐、重复的选择代码块的工作。
使用这些工具后，我在 Composer 里直接 add 一下要引用的代码，选择几行代码，写下提示词，贴上截图，这些繁琐的工作它都能自动完成了。这是对于我这样比较专业的用法。对于不那么专业的用户来说，他们甚至不需要专业地选择代码，只要给出大致的指令，工具就会猜测你可能需要的代码，在背后帮你把这些脏活累活都做了。这对于降低使用门槛帮助相当大。
所以我认为两者是相辅相成的，你既需要强大的模型，也需要在交互上有便利性和突破。
唐小引： 好的，谢谢宝玉老师。陈鑫老师和勤锴老师也可以分享一下你们的关键词和重要命题，以及对前面讨论的观点有什么补充。
陈鑫： 我觉得这个领域在过去一年发展得太快了。从产品角度来看，最关键的是对整个领域发展节奏的判断。2024 年年初的时候，因为 Devin 特别火，大家觉得应该往 Agent 方向发展，做一个端到端直接产出有效产品的形态可能会更好。但是模型的发展是有阶段性的，在当时的模型水平下，效果其实是不及预期的。
不过我们也没有预料到后面在多个文件小范围生成的效果会那么好，特别是在配合像 Cursor 那样优秀的人机交互模式后，能做到生产级的落地。可以看到不同的探索方向带来了不同的结果。
总的来说，现在整个 AI coding 领域模型的发展比我们想象的要快。年初做 SLB 测试集的时候，我们认为年底可能做到 30-40 分左右就不错了，但现在大家都很轻松地超过了 50 分，甚至达到 70 分。这个领域还是充满想象力的，我们现在很难判断 3-6 个月后模型会发展到什么程度。
郑勤锴： 确实如大家所说，去年一个重要的时间点是 Claude 3.5 模型的发布。这让 Cursor、Windsurf 等工具变得非常好用。同时交互方式也更接近 Agent，这得益于模型能力的提升，它可以很好地支持各种指令的跟随和复杂工具的调用。
最令我激动的是，目前这些工具确实能够提高我的生产力。我每天写代码时的体验与之前的 Copilot 类产品有明显不同。我现在主要使用 Windsurf 作为 IDE，虽然也体验过 Cursor，但我更习惯 Windsurf。我的整个编程流程发生了很大变化：以前基于 Copilot 时需要自己写很多代码，Copilot 只是帮你做一些补全。现在由于更自动化的 Agent 的引入，当你问一个问题后，Agent 会帮你写很多代码。
这时 review 代码会很花时间，所以我开发了一些新方法，比如在解决任务时先写单元测试，然后让 Agent 去尝试实现。这样我的 review 压力就小了一些 - 如果它能通过单元测试，说明写得还不错，我只需要确保单元测试写得准确清晰。这对我的编程工作方式产生了很大改变，让我感到非常兴奋。它真的能帮助像我们这样的程序员提高生产力。
当然，这需要一段时间让大家去适应。大部分用户还是更习惯补全的形式，如何与 Agent 互动是我们今年需要思考和适应的问题。
唐小引： 好的。勤锴老师提到了一个关键点 - 在 Cursor 和 Windsurf 的对比中，您选择 Windsurf 作为主要生产力工具。其他几位老师使用的是什么工具呢？陈鑫老师？
陈鑫： 如果通义灵码没有做 Agent 模式，确实其他产品会更好用。现在我当然主要使用零码，但也会使用其他产品做深度体验。在体验过程中，我们需要去研究它们的技术实现和设计细节，这方面我收获很多。
唐小引： 宝玉老师呢？
宝玉： 我主要是 o1 Pro 配合 Cursor 两个一起使用。写程序时我会用一个叫 Repl Prompt 的小工具，它可以让你选择整个代码库中相关的模块代码。因为上下文很重要，我会把相关代码都选上，然后在专门的 Prompt 栏写我要实现的功能，整体发给 o1 Pro。等它生成结果后，我 review 一下再复制粘贴过来。
简单任务就直接用 Cursor。相比 Windsurf 和 Cursor，我个人更喜欢 Cursor 一些。
唐小引： 为什么？
宝玉： 这取决于你是更多使用 Agent 还是 Composer。我自身相对来说没有太依赖 Agent，更多使用 Composer。我更习惯自己先构思好、模块设计好，然后再给出指令让它生成，最后我再 review。我还是比较传统的老程序员写法。而很多习惯用 Agent 的可能更倾向于给一个指令就让它实现一个模块，不太关心具体实现方式。这种场景下 Windsurf 可能做得更好一些。
唐小引： 对的。勤锴老师选择 Windsurf 是因为它的 Agent 功能吗？
郑勤锴： 是的，主要是因为它的 Agent 自动化能力。它在处理问题时会自动帮你查找相关文件，了解项目信息等。我觉得它的用户体验做得比较好，包括我前面提到的单元测试场景，它可以自动运行测试、查看结果，进行反复迭代。整体的自动化体验让我感觉更顺畅。
唐小引： 好的。海龙总，您主要使用哪个生产力工具？
张海龙： 如我最开始说的，在 IDE 相关的 AI 工具中，我只用 Cursor。而且我用得很简单，不用 Composer 也不用 chat，我只用它的补全功能。我认为 Cursor 真正的精髓就是补全，其他功能我都试过，但觉得不太行。不过它的补全功能做得真的太好了。
唐小引： 您能详细说说吗？代码补全功能从早期 IDE 到现在一直在发展，Cursor 带来了哪些全新的体验？
张海龙： Cursor 本质上在做一件事 - 意图揣测，就是猜你接下来想要做什么。它不仅仅是补全代码，而是在预测你的下一步意图。无论是通过自己训练的小模型还是其他手段，它的猜测准确率都很高。大家喜欢用 Cursor 的 Tab 键就是因为这个，你会发现连续按 Tab 的次数越来越多。这对整个开发体验带来了很大的提升。
除了动作预测外，它的补全内容的准确性也确实不错。它不只是帮你找到位置，改动的内容准确率也很高。虽然不能达到百分之百，但比预期要好得多，所以我一直在使用这个功能。
唐小引： 从大家的分享中，我们看到了不同的生产力工具选择。接下来我想请海龙总分享一下，对整个 AI coding 的进展观察，特别是关于 Agent 这块。我记得您之前因为常在硅谷，提到在 2024 年初整个行业的共识就已经是往 Agent 方向发展。现在我们看到国内的通义灵码和 CodeGeeX 都在做 Agent。您从硅谷的角度，能分享一下对 AI coding 发展现状和 Agent 的思考吗？
张海龙： 首先，AI coding 其实分很多方向。像今天我们讨论的主题是面向专业开发者的工具，我们暂时不讨论面向非专业用户的那部分。对于专业开发者来说，又可以分为同步工作和异步工作两种模式。目前我们做得特别好的是同步工作，无论是以 IDE 形式存在，还是插件形式，或者网页形式，只要是同步工作都属于一类。另一类是异步工作，这方面目前基本上还没有做得特别好的产品，我们正在努力尝试做一些异步工作的 Agent。
在硅谷，我的感受是 2024 年初大家就已经认为同步工作这个方向可能没有太多可做的空间了，因为有 GitHub Copilot 的存在。我很清楚地记得 2024 年 6 月在旧金山有一个叫 AI Engineer 的会议，国内报道不多。在那个会议的 Agent 分会场，所有创业项目的分享中，只有 Cursor 在讲 Copilot 相关的内容。结果最后只有它真正做成了，这是一个很有趣的现象。
所以我对整个 Agent 的发展并不像大家那么乐观。我认为通用的 coding agent 是做不出来的。因为在实际的软件工程中，当你遇到企业级代码仓库时，还有大量的业务上下文、工程上下文，比如如何 setup、依赖哪个仓库、依赖哪个特殊环境，甚至依赖哪个特殊 IP。关键是这些上下文每天都在变化，你如何让大模型能够持续跟进这些变化？
大模型是静态的，它没有与时俱进，没有跟着项目一起成长。现在做的所有 RAG 效果都不太理想，就像一个应届毕业生进入公司，每天都在记笔记，但他不会成长。这样的"员工"怎么可能好用呢？所以我认为通用的 coding agent 是做不出来的，这是一个比较悲观的判断。因此我们更相信垂直的 coding agent。
唐小引： 垂直是指往哪个方向发展？
张海龙： 其实在硅谷，创业项目最多的就是垂直 Agent，专注于软件开发生命周期中的某个具体环节。比如有的只做 code review，像我们只做 unit test，有的做 integration test 和 E2E test，有的做 code documentation，有的做 code refactoring。就是只专注做某一件具体的事情。
唐小引： 也就是说，解决软件开发生命周期里的某一个具体环节？
张海龙： 对，因为这里面有大量的行业 know-how 和需要打磨的细节。如果你说做一个通用的比如 Devin，我相信专业程序员用过就会发现这东西还是不能用的。太通用的东西，如果真能做出来那就是 AGI 了。
唐小引： 其他三位老师对海龙总这个观点有什么看法？
宝玉： 我想打一个比方。海龙总从现在的角度来看这个观点是对的，这就像在飞机发明之前，我们总是想去模仿鸟类飞行。最终会得出结论说我们永远无法像鸟一样飞行，所以永远无法发明飞机。AI 编程也类似，基于现在的企业代码和软件架构，这条路可能确实会走死，就像模仿鸟类飞行一样难以实现。
但如果我们的技术能够向 AI 靠拢，开发一些对 AI 友好的代码（虽然可能对人类不那么友好），采用模块化的方式，就像现在建筑领域开始使用 3D 打印技术一样。这种 3D 打印建筑与传统建筑工程完全不同，效率也完全不同。未来的 AI 编程如果不局限于现有代码模式，而是能把模块做得更加规范，就会有新的可能。
我们现在在 UI 方面已经看到一些雏形了。当你让 AI 生成界面时，它会使用像 shadcn/ui 这样的库和 Tailwind CSS 这样的标准样式表，能生成不错的 UI 效果，只需要发个截图就能生成界面。这就是一个预兆，说明在 UI 领域已经开始朝这个方向发展了。从今年来看可能还比较遥远，但是五年、十年后，它可能就会像今天的 AI 编程一样达到一个临界点。到那个临界点后，发展会一日千里，那时可能就真的会替代我们了。
陈鑫： 我的观点其实和海龙总比较像。我认为开发者现在主要还是通过对话的方式与机器交互，不管是写代码还是解决问题。今天自然语言最大的问题是不能精确描述我们的需求。如果是粗略的描述，就不可避免需要多轮迭代，需要人机紧密配合，最后它可能会理解错误。即使它百分之百不出错，我描述时也可能会有问题。
如果今天我们把语言精确到业务逻辑级别，你会发现它就变成了一个程序，不管用什么形式表达。所以现在的情况很尴尬，在当前这种模式下，只要需求复杂到一定程度就离不开程序员的把控。如果需求只是做个 demo 或展示、做个简单工具，确实可以脱离代码了，这方面已经逐步形成了相应的产品路线，一些产品已经做出来了。
但是面对现在庞大的数字化体系，它的业务逻辑非常复杂。如果要实现完全的 AI 编程，要么就是实现 AGI，要么整个编程范式就要颠覆，代码的重要性可能会降低。但从目前来看，我们还看不到这种可能。而且从模型训练角度来说，不管是训练静态代码还是训练 Agent，我们还是按照原有思路去处理代码和模拟人的问题解决过程。在模型训练的根本上，我们还没有发现与现有人类解决程序问题的模式有颠覆性变化。如果训练模型都没有变化，我不太确定能否出现一个超越现有模式的 AGI。
唐小引： 通义灵码现在在做的 Agent 是属于通用的还是垂直的？如果是垂直的，主要在哪些方面？
陈鑫： 通用的部分也是同步模式，类似于 Cursor、Windsurf 这种，是离不开人的把控的。我们定位 Agent 就是一个强执行力的工具。给它限定上下文，它能做得不错，但没办法做复杂的架构设计或软件设计和执行。我们判断它的准确率可能在 60% 以上、80% 以下这个水平，这种人机交互配合人的监督是比较合适的。
如果准确率能到 95% 以上，这个模式可能会发生变化。但目前来看，就像海龙说的，年初的时候大家对通用智能体比较看好，但后来始终没有做出来。
唐小引： 好的，接下来让勤锴分享一下您的看法。
郑勤锴： 对海龙总的观点，我可能有一些不同的看法。因为我们是专门做大模型的公司，目标一定是走向 AGI。我认为 coding agent 是 AGI 的前置步骤，你需要先实现这一步才有可能达到 AGI。但确实现在还有一定距离。
在 2024 年，我们也在探索如何处理企业级的大型代码库。我们发现代码阅读是一个非常大的需求。当你面对几千个文件的项目时，如何理解这些代码对大家来说都是很大的挑战。新员工入职一个公司，可能要花几周时间去读懂公司的老代码库。所以我们在 CodeGeeX 里做了一个"项目地图"功能，可以可视化呈现整个项目，展示它的架构、依赖关系，每个节点都可以进一步深入查看更多细节。
我们认为未来随着更多的 Copilot 和 Agent 的集成，很多代码都是 AI 写出来的，人去理解这些代码会有一定困难，所以需要有更好的代码阅读方式。我们还做了一个"幽灵注释"功能，你在看文件时不需要把注释直接加到文件里，可以看到每一行代码旁边有个虚拟的注释来提示这段代码在做什么。
如果要实现 coding agent 能够真正处理这些复杂项目，我认为要在模型训练方式上有很大改进。今天如果我们对比不同的 Agent 实现，比如 Cursor 和 Windsurf，它们的底层实现其实很类似。它们效果的差异主要在于上下文管理 - 我们在流程中该给模型看哪些内容？是不是只看几个相关文件？需不需要给它看用户的历史操作、其他代码库，或者之前看过的文档？
很多知识性的东西我们都没有给到模型，它没办法基于这些信息去解决问题。我也体验过 OE Pro 这样的模型，它的能力确实非常强，只是我们给它上下文时有局限性。就像宝玉老师说的，我们需要工具来帮助梳理整个代码库，但实际上还有更多信息，比如文档信息、你之前修改的代码、commit 记录等。如果这些信息都能让模型知道，它解决问题的效果会更好，这是我们觉得需要去探索的方向。
唐小引： 好的，我们接着看下一个问题。对于所有专业开发者来说，AI 编程的发展确实非常快。不过很多人比较苦恼的是，对于生成简单功能或做个小游戏，这些工具都表现不错，但在实际业务中，开发者更关心的是如何在大型复杂项目里应用这些工具。几位老师有什么相关案例或经验可以分享吗？陈鑫老师和勤锴老师可以先说说，因为你们做工具时应该主要面向企业级落地，可以讲讲这方面的具体情况。
郑勤锴： 对，谈到企业级落地时，一个很大的问题是企业内部的代码都有自己的一套东西，比如自己的框架、API 等。如果用通用模型，这些问题是很难解决的。所以在企业环境中总是离不开私有化部署的讨论。我们需要对企业内部的代码进行强化训练，至少要让模型能够理解这些企业内部工具在做什么。
这是一个很特殊的地方 - 你没法直接使用 Cursor 或其他云端模型，即使云端模型可能非常强大，但它缺少特定的知识背景。目前的解决方案一方面是在这个领域进行微调，另一方面需要建立企业知识库做进一步强化。这是目前落地时的基本流程。
唐小引： 那现在 CodeGeeX 是否已经能够帮助开发者处理大型项目了？是否能胜任这样的工作？
郑勤锴： 目前我们做的一方面还是像 Copilot 那样的代码补全，以及一些简单的问答功能。另外就是我前面提到的项目地图等新功能，帮助企业处理那些历史代码库，帮助程序员更好地理解这些代码。因为有些代码的复杂程度非常高，需要有人去梳理，我们在这方面起到了帮助作用，能让开发者更快地上手。但现在还做不到帮他们改那些代码，一改就会涉及很多地方，现在还无法做到一改就能成功。不过我们确实能帮助开发者更快地理解代码。
唐小引： 那陈鑫老师，通义灵码在这方面的情况如何？特别是关于如何解决历史遗留代码的问题？
陈鑫： 我们观察到，目前国内开发者普遍还是在用 Copilot 这种模式。像 Cursor 这种模式，或者说 Agent、Composer 这种玩法，都还处于初期阶段。我们粗略判断，可能只有 10% 到 20% 的普及率，绝大部分人还没有使用。
他们最核心的痛点有两个：第一是不知道怎么跟 AI 对话。在生产环境下描述需求是非常复杂的。他们不知道如何写提示词，描述不好就导致 AI 回答很差，然后就失去了信心。第二个问题是 context（上下文）的处理。在复杂工程中，如果 context 给得不对或给得太少，AI 就无法理解整个架构，可能会出现一些幻觉，比如新增错误的类或改错地方，这会导致准确率下降。
再加上我们很多代码写得不规范，注释少，甚至命名都有问题。这些都是我们需要解决的关键卡点，只有解决这些问题，这些工具才能在企业级真正深入落地。另外，国内的模型与海外模型还有几个月的差距，我们需要通过进一步的模型训练，让模型在解决复杂问题时具备多步推理能力和自主探索能力。只有把这些细节都做好了，才能让大部分人体验到 AI 的魅力。所以现在还有很长的路要走，这只是个开始。
唐小引： 提示工程确实是当前的痛点。宝玉老师，您之前分享过 AI 辅助编程存在两个问题：一是大家不知道如何写提示词，二是 AI 生成的代码可能会带来新的 bug，而修复这些 bug 又可能引发更多问题。您能分享一下这方面的观点和经验吗？
宝玉： 我确实在 2024 年非常痴迷于研究提示词，花了大量时间去学习和研究各种提示词。但现在我的观点有所改变 - 提示词的技巧其实没有那么重要。那些如何写结构、如何扮演角色等技巧，慢慢你会发现有点华而不实。
特别是对编程来说，我认为有几点特别重要：首先，最重要的是你使用什么模型，这是根本性的问题。关于企业历史代码要做 RAG 或微调的观点，我个人不太认同。这有点像"garbage in garbage out"（垃圾进垃圾出）的问题 - 对那些历史遗留代码越是做微调和 RAG，生成的质量反而会越差。相反，那些没有被这些代码"污染"的好模型，反而能生成更高质量的代码。
生成代码有一个非常重要的技巧，就是上下文。而最好的上下文是什么？是写得很好的代码。就像照葫芦画瓢，有一个好的葫芦，就能画出好的瓢。如果没有好的参考，就很难生成好的代码。
所以我写代码时，会先把几个关键模块认真打磨，做得比较规范和高质量。后面的代码就可以参照这些已经写好的代码，把它们作为提示词的一部分提交给 AI。企业内部的代码也是类似的道理 - 当我要实现某个模块时，不需要把整个代码库都给它，只要给出相关的代码，甚至只需要给出一些关键模块的注释或函数名、API 的 Schema，AI 就能很好地理解上下文了。
所以核心是如何给 AI 合适的上下文，而不是代码有多复杂或有多少历史遗留问题。重点是操作者要能精准地选择合适的内容，这需要你本身对代码有深入理解，要足够专业，能用程序的语言而不是自然语言去精准描述需求。
经过反思，我总结了三个关键点：第一是指令，要用编程的关键词去准确描述需求；第二是上下文，要给出这个功能或 bug 相关的所有信息，可以是概要性的也可以是完整代码，但一定要充分，因为 AI 没有读心术，它不知道你想要什么；第三是原子化的提示词，就是在架构设计或写提示词时，要让模块尽量松耦合。
比如 React 前端现在就做得比较好，一个个组件都是独立的。我要改某个 UI 功能，只需要选中相关的几个组件或状态，这就是一个独立的单元，把这个发给 AI 就可以了。所以提示词的关键不在于技巧，而在于你的指令、上下文，以及让每次交互都是原子化的、独立的，不要包含太多 AI 不知道的信息。
唐小引： 说到这些工具的使用体验，刚才陈鑫老师和勤锴老师，你们是否从工具层面考虑过如何解决用户的痛点问题？比如对用户提问的理解准确性、上下文理解等方面，你们有没有一些能力可以封装，让用户在使用时少一些困扰？
陈鑫： 关于提示词这块，我们现在的主要思路是，在做 IDE 插件时尽量让开发者有控制力，让他们知道自己给了模型什么输入，以及模型是基于这些输入来给出输出的。这种透明度是需要把握的，所以我们更多是做一些推荐。
比如当开发者要修改当前代码时，我们可以推荐他可能需要把哪些其他文件作为相关 context 引入进来。当然，这种方式其实有一个隐性假设：就是认为如果给模型太多 context，它会混乱出错。这是个隐性假设，如果这个假设不存在了，如果上下文可以足够长，模型的指令遵循能力也足够强，那我们就可以直接做自动上下文了，根据用户意图自动感知需要引用哪些文件。这将是更高程度的自动化。
但从目前模型的现状来看，还需要更多人工操作。我们现在所有做得比较成功的产品，实际上都是与模型配合得比较好的，你要了解模型大概是什么水平，然后匹配合适的交互方式。这绝对不是开发者想要的终态，这是一种妥协。
郑勤锴： 对，我们目前为了解决用户提示词表达不清晰的问题，主要是基于知识库去连接用户之前的文件或文档，还会用一些联网方式去搜索类似问题。这是目前的解决方案。
我们正在尝试一些更灵活的方式。比如我们可以类比我们自己在开发时是怎么解决问题的：当我们需要解决一个问题时，会先查看项目结构，看看哪些文件可能和当前问题相关，然后去打开看。我们会使用 VS Code 的快速跳转功能，点击一个变量或函数定义就能看到它在哪里定义、在哪里被使用。
如果我们能让模型学会使用这些能力，就可以更精准地找到相关内容，而不是像之前那样只依赖 RAG，用语义相似度检索出十个、一百个片段然后做倒排这种粗糙的方式。我们希望让模型能更自主地找到相关信息，这些信息可能更精准地帮助它理解用户需求。
唐小引： 好的。海龙总，首先想请教您一个关键问题：从研发生命周期来看，第一步是如何让 AI 理解复杂的业务需求，这是个核心问题。另外还包括代码性能把控等方面，您有什么经验可以分享？在硅谷看到的情况又是怎样的？
张海龙： 我理解您的问题是在问如何让 AI 编程工具理解业务需求，从而更好地落地。但这个其实不是最直接的问题，而是一个手段。我们需要先思考，让它理解需求的最终目的是什么？是要它帮你写代码，还是写文档，还是做其他事情？你让它理解需求之后要它做什么？
实际上，我目前没有看到谁在真正尝试让 AI 理解复杂的业务需求。你看 Cursor 也不会让你先把需求文档扔给它，只有像 Bard 这种面向非专业人群的工具才会让你描述你想要什么。我把这种称为"许愿"式的交互 - 它根本说不清楚具体要什么，就是在许愿。
在专业领域，首先一个复杂项目基本上是没有清晰的需求的。我相信在座的都有经验，就像阿里巴巴那么多项目，哪有什么清晰的需求？很多都是在人的脑子里。所以让大模型去理解现在企业里复杂项目的需求，是没有可执行方案的。实际上大家做的方向也不是往这个方向走，而是尽量做一些通过代码能够推导出来的东西，然后带一点点人类的输入，大概是这样的逻辑。
唐小引： 所以您是说，现在大家期望 AI 能理解清楚需求，这本身其实是一个伪需求？
张海龙： 是的，连人都没办法描述清楚，你让 AI 理解什么呢？去看看 Cursor 的效果，它的成功不是因为它理解需求，它根本不理解需求。它就是在猜，就是在照葫芦画瓢。它只是这个画瓢的能力特别好，然后能在画完瓢后给你一些改进，它有这种能力。
宝玉： 对，我认同这点。首先，现在的 AI 确实不可能理解复杂需求，因为它受限于上下文窗口的长度，也没有记忆能力。但是对于人分解之后的模块级需求，如果交给 Cursor，它其实是能很好实现的，而且理解得也不错。
所以我觉得这可能是海龙老师对 Cursor 的一个误解，因为他主要用 Tab 补全功能，较少使用 Composer。我认为 Cursor 和 Claude 这些模型对模块级别的需求，已经可以理解得很好了。
郑勤锴： 我也想补充一下使用这些工具的个人体会。我发现这跟使用方式真的有很大关系，同一个人用 Agent 模式，不同人的体验可能完全不同。我们不要把它想得太神奇，觉得它什么都能解决，你就把它当作一个高级的补全工具。
如果你自己都不知道这个问题怎么解决，用 Agent 模式大概率也是不行的。就算它帮你写出代码，你可能也看不懂。但如果你已经知道怎么解决，有详细的思路，你告诉它先做什么再做什么，这个架构应该怎么设计，它其实就是帮你起到一个补全的作用，只是一个更高级的补全。它帮你把这些写出来，所以我觉得这个是大家要理解的。
不要期望说出了个 bug，你一句提示词说"帮我修复一下"就能解决。其实你得告诉它该改哪里，这个问题到底出在哪里。如果你很详细地告诉它，它其实就是帮你做执行，把这个东西实现出来而已。
张海龙： 欸，我有个好奇的问题，如果真的要很详细地告诉它该修哪里，你为什么不直接改呢？打字不是更累吗？
郑勤锴： 关键是它解决问题不只是一两行代码，可能涉及十几行，需要在多个地方做修改。你跟它讲清楚后，它可以直接把所有地方都改好。包括跨文件的修改，它也能同时帮你处理好。这样确实能省时间，就是在你很清晰知道要做什么，并且有好的单元测试的情况下，你可以让它做这些具体的改动。
宝玉： 我再补充一个在交互上很有用但可能被忽略的点 - 多模态功能。现在无论是 Cursor 还是 Claude，你都可以传一个 UI 的截图，或者出现 bug 时的错误截图。这样就可以省去很多文字描述，直接得到好的结果。
唐小引： 好的，谢谢几位老师的精彩分享。基于我们看到的程序员痛点问题，我想先请教海龙总一个问题。以前写代码我们都很讲究代码整洁之道，程序员的高下之分很大程度上取决于代码质量。那么在 AI 编程盛行的时代，对于代码质量和性能，是依然需要严格把控，还是说只要能实现功能就可以了？
张海龙： 这是我们最近一直在思考的问题。首先，只要软件工程还存在，质量就很重要。除非哪天代码完全消失了，否则质量永远重要。保障质量的手段有很多，比如传统软件工程中的 code review 就是一种保障。现在很多公司在做 Agent 来做 code review，但我理解国内对 code review 的实践其实很少，因为它确实很花时间，而且对人的要求非常高。
现在代码质量的问题可能会更严峻，因为大量代码你都没有经过大脑思考，都是 AI 帮你补出来的。你可能大概看一眼，发现编译没错误，IDE 里所有的 lint 都通过了，CI 也通过了，你就觉得没问题。但实际上你并没有真正认真思考每一个字符是怎么回事，所以里面可能潜藏着很多小问题。
我认为在 AI 生成代码的时代，会有大量垃圾代码被创造出来，因为创造垃圾的成本太低了。在严肃场景下你如何保证最终质量是好的，这很重要。这也是为什么我们选择做 unit test 的原因 - 我们认为单元测试是保障质量的有效手段之一。
既然让 AI 帮你写了那么多代码，补了那么多代码，那你是不是要确保这些代码符合你的预期？所以我们就再搞一个 Agent 帮你写测试，因为没有开发者喜欢写测试。我们让 Agent 帮你处理这些脏活累活。
但是我觉得没有什么神奇的解决方案 - 如果你本身水平很差，搞不清楚性能问题是怎么回事，你也不会因为有了 AI 就变得更好。所以我们最近在思考一个观点:AI 其实不能提高你的上限，AI 是个放大器，它不拉高上限。我觉得大家还是要关注质量，该做的 code review、unit test 这些动作还是得做，甚至比以前更重要。
唐小引： 那您觉得程序员和 AI 编程工具的理想配合状态是怎样的？
张海龙： 首先，你要用各种自动化检查来保障质量，这在 IDE 里现在已经很成熟了。然后要把那些好的软件工程实践加上去，比如好好写测试，甚至用测试驱动开发，认真做 code review。你不能因为这边省了工作就完全不管质量。除非你根本不在乎质量，否则最后一定会出问题。
所以我觉得这种配合确实让你的效率变得很高，但最后保障质量还是要花一些人工成本。包括一些新的 Agent 工具的出现，会辅助你来做这些事情。
唐小引： 好的。其他几位老师对此有什么看法？特别是在国内，我看到基本上程序员都是在加班加点地写代码，要靠人力去做 code review 在团队中落地其实是有难度的。在 AI 编程时代，我们该如何确保代码质量，如何推进这些实践？
陈鑫： 现在在我们看到的企业里，质量是刚需，越大的企业越希望能用 AI 来帮助做单元测试、辅助 code review。我们也发现，先写测试再让大模型基于测试去写业务逻辑，它可以写得更精准一些。这其实也是一种用单元测试的方式去告诉模型应该怎么写业务逻辑。
另外，我们觉得现在 AI 生成代码跟以前我们去社区里复制优秀代码其实差别不是太大，它只是让整个复制的效率变得更高了。本质上没有区别，以前大家也是复制后改一改，现在也是生成后调一调，只是现在效率更高。
从质量保障角度来说，肯定还是需要人来把关。我们可以通过一些提示词的限定来避免一些低级错误，比如在一些容易踩坑的地方加入规范提示。每个工程可能都有一些特殊的规范，我们可以把这些规范内置进去，阻止一些低级错误的发生。但这也是有限的，如果只是从性能角度看，我们很难用提示词去描述一个很好的性能要求，模型就能做到。它可能只能防止一些低级错误。
所以最终质量还是要靠后面各个环节的把关。其中单元测试可能是模型最容易替代的部分，然后是 code review。但从测试生成这块来看，大部分还得靠人，目前模型还没有那么强的能力去使用工具替代人做黑盒测试，尤其是在理解需求方面也做得比较差。所以我们会按这样的顺序来为企业提供功能。
唐小引： 听下来感觉大家普遍认为测试工作是最容易实现自动化和智能化的，可能是 AI 最容易直接胜任的领域，是这样吗？
陈鑫： 从目前趋势来看确实如此。虽然现在的产品还没有完全做到那一步，但从能力上来看，测试这个领域确实有很大的发展空间。
唐小引： 那么这是不是意味着测试工程师会更容易被取代？
郑勤锴： 我觉得不完全是这样。这个转变实际上是所有开发者都需要经历的开发范式上的转变。以往可能更多关注实现的细节和个人经验，现在这些具体实现 AI 可以帮你加速，所以你需要思考其他方面的内容。
海龙老师提到了测试驱动开发，这个理念其实在 90 年代就提出来了。为什么它一直难以推广？因为它对人的要求很高 - 你需要在写代码之前就清楚地知道这个任务要做什么，理解它的输入输出会是什么，会有哪些边界情况。这其实需要开发者对业务有很深的理解，所以推进起来比较困难。
如果要让人用测试驱动开发的方式，他一开始要想很久。对于初级程序员来说，他可能想都想不清楚，直接就开始写了，写完才知道要做什么。但在未来，当你给出一个需求，AI 能够更快地完成实现时，你就需要先思考好这个功能要以什么方式呈现，可能就需要把测试驱动开发作为辅助实践 - 你先想明白要它输出什么，然后再让它去实现。
AI 的到来可能真的会促成测试驱动开发或其他新的开发范式的普及。这对程序员的要求是不一样的，大家需要把精力更多放在思考架构、最佳实践等方面，而不是只关注实现细节。
唐小引： 前面提到了测试，还提到了 code review 非常耗时。那么，我们能否将 code review 这个环节直接 AI 化呢？
张海龙： 这个问题我其实非常困惑。我听到陈鑫说他觉得 code review 比较容易做，但我的感受是 code review 是最难做的环节之一。因为我们团队深度实践 code review，你会发现很多时候 code review 需要的上下文实在太多了，它甚至需要对业务需求的理解。
有些地方这个代码只能这么写，它从常理来看可能不太符合规范，但在这个场景下它就是只能这么写。有很多这样的上下文。我的意思是，虽然我们也试过很多 code review 的产品，但大部分感觉都在说一些"正确的废话"，就像以前的代码扫描工具一样。它能扫出来一些问题，但大部分都是我知道就这样，我也不想改的问题。
要做到令人满意的 code review 效果，我没有看到一个特别好的路径，这是很难的。就纯 AI 来说，目前还做不到。
唐小引： 您的观点是短期内做不到，还是从长远来看都很难实现？
张海龙： 从长远来看都很难。我觉得如果 code review 能做得特别靠谱，那你让 AI 直接写需求或修 bug 就有可能了。
陈鑫： 对，我刚才说 code review 这个场景是企业的刚需，但做起来确实很难。我们现在第一版只是加入代码的上下文，在相似上下文中可能解决一些样式问题和风格问题，或者一些简单的逻辑错误，大概也就能解决 20%-30% 的问题。
但企业对 code review 的要求是希望你能帮我发现一些业务上的、逻辑上的问题。这些问题就涉及到与需求的结合。确实就像海龙说的，如果今天没有办法很明确地理解需求，并且来判断代码写得对不对，那这个 code review 只能说是做了一小部分。但这个需求，企业是特别希望有的。所以这块如果产品真能做出来，会有很大的市场空间，但从目前来看确实没有做得太好。就像我们做到现在发现，在初级层面是有一些用，但是离自己的预期还很远。
唐小引： 陈鑫老师，刚才海龙总说从长期来看也是很不现实的，您觉得呢？
陈鑫： 确实，就大家看到的问题都类似。如果它能够达到企业的预期，能让企业非常满意，那它一定是能做很好的代码实现，因为它对需求理解很强，知道怎么写，才能知道你写的对不对。但目前以模型的能力来看，它直接理解一个复杂的需求，类似 PRD 这样的东西是根本做不好的。
它只能做一些确定性的事情，我们叫详细设计转换成代码。但详细设计实际上已经是开发者明确告诉我今天要做什么，在什么范围里面做，应该怎么做，而且还得通过多轮迭代才能做好。所以这是现实。
如果今天 AI 能对一个复杂的需求，甚至整个代码库都有很好的理解，这意味着很多方向都攻克了。那就是说，这个直接从需求到代码，类似 Devin 这种模式，以及直接做测试，就是理解需求然后直接在界面上点击就行。现在使用工具对 AI 来说并不难，但难的是它不知道怎么点，也不知道点了以后对不对。所以如果这些问题都攻克了，那确实可能就接近 AGI 了。
张海龙： 我相信目前我们看不到，但是终态肯定会走到那一步。不过目前来看还看不到，可能还需要上下文长度暴增一百倍，比如达到两千万或者一亿 token 的上下文，我觉得才有希望。
唐小引： 好的，让我们继续讨论。宝玉老师，勤锴老师，请分享一下你们对 code review 的思考。
宝玉： 我认为 code review 恰恰是程序员目前不可替代的核心能力之一。如果我们讨论 AI 替代程序员的可能性，代码审查是最难被取代的领域之一。而且作为程序员，我建议现在更应该重视代码审查，即使以前可能不太关注这方面。
有了 AI 之后，因为你不需要花太多精力去写代码，反而有更多精力去 review 代码。另外，代码审查这件事情因为涉及到需求和任务的上下文，AI 很难完全理解这些背景。但作为程序员，你是参与了整个过程的，你可以跟任何人沟通，你有完整的上下文，所以你能更好地理解和审查这些 PR。
如果 AI 生成的代码你不认真 review 就直接合并进去，将来就很难维护。所以这个关系要搞清楚，一定要在代码审查上投入更多精力。前面有位老师提到了代码扫描工具，以前这些工具会扫描代码中可能的安全漏洞和性能问题，但采纳率比较低，因为它指出的问题经常不够准确。AI 在这方面可能会做得更好，可能能在很大程度上替代这类工具。
唐小引： 我想继续追问，您刚才提到 code review 是不可替代的，您觉得还有哪些是程序员不可替代的核心能力？
宝玉： 让我们先来看看当前 AI 的几个固有缺陷。第一个是上下文长度不够，就像海龙老师说的，可能需要增加一百倍才能完整理解一个代码库。这是一个硬伤。
第二个是 AI 缺乏环境感知能力。它可能可以运行代码、调用工具，但对代码运行的结果很难有直观认识。UI 也是类似的，即使有了多模态能力，如果要完成一个复杂操作，比如订机票这样的流程，现在还是需要人来操作。这涉及到环境感知和行动能力的不足，这也是大家对 AI Agent 的一个期望，但目前还有欠缺。
基于 AI 的这些局限性，有些能力是现在无法替代的。比如需求分析 - 需求分析需要和产品经理、客户进行沟通，有些东西用语言很难描述清楚，用截图也不行，因为可能涉及动态的交互。有时候人与人之间都说不清楚，AI 就更难理解了。
另外，由于上下文的限制，复杂的架构分解也是 AI 做不到的。不是说 AI 的架构能力差，而是因为上下文限制，它无法处理复杂系统的架构分解。这是非常重要的一块，因为一个复杂系统需要多人协作，甚至需要多个 AI 协助，都需要先进行分解。然后还要把这些部分整合起来，这个过程 AI 是无法替代的。
最后就是前面提到的环境感知问题，特别是在调试方面。这是新手最痛苦的地方 - AI 可以很快生成代码，但当出现问题时，你可能完全不知道该怎么办，可能卡在某个地方很久。要么放弃，要么找专业人士帮助，或者运气好 AI 突然给出了正确答案。这块是专业程序员很难被替代的领域，因为只有程序员知道如何运行、如何重现问题，然后一步步缩小范围，最后可能借助 AI 或自己的专业知识来解决。这些都是目前很难被替代的能力。
唐小引： 说到调试，这也是程序员的一个疑惑点。因为大家在遇到报错或异常时，会把问题描述给 AI 来分析和修改。对于程序员来说，人工调试在未来是否依然重要，还是这部分主要会被 AI 化？
张海龙： 说到 debug，这其实是最早这波 AI Agent 创业公司尝试的方向之一。可能这些公司到今天已经不在了，但没有成功的。这个需求实在太强烈了，所有人都在想，如果能让 AI 修 bug，那就太厉害了。但这里面很多东西都是相关联的，写 feature 和修 bug 本质上没有区别。code review 某种程度上也是在修 bug。
我认为这些工作目前还是需要人来做。这里面有个很重要的概念叫 reproduce（重现问题）。写过程序的都知道，如果你能重现问题，就基本能修好。但问题是重现本身就是一个极其困难的事情，对 AI 来说更是如此。
你看我们做 SLB（编程能力测试），打榜的时候最难的就是这一点 - 很多问题你根本没法重现。人都很难重现的问题，就更别说让 AI 去重现了。所以我认为这条路从目前来看，AI 是不可能替代程序员做这件事的，这恰恰是人最大的价值所在。
唐小引： 接下来我想讨论一个所有程序员都很关心的问题 - AI 编程工具在跨文件跨工程的代码生成方面的能力。我知道国内以前有很多代码编写规范，比如阿里的 Java 规范在程序员圈子里很有名。海龙总，从硅谷的角度来看，跨文件和跨工程的代码生成能力现在发展到什么程度了？
张海龙： 跨工程（跨 project、跨 repo）的能力我基本没见过。跨文件现在已经有不少了，就是说我解决一个问题可能需要修改多个文件中的代码。但实际测试下来，在真实的企业级项目中，如果不是那种能整个塞进上下文的小项目（比如做个商店网站或博客这种），超过三个文件的修改，准确率就会急剧下降。
如果你现在在一个复杂的代码库里，指望 AI 帮你做一些涉及超过三个文件的修改，那么从统计上来说，如果你让它做 100 个这样的任务，大概率都会失败。它可能会做出修改，但修改大概率是错的。这是我们目前看到的统计数据。
从业界著名的 SLB 榜单也能看到这一点 - 在多文件修改的成功率上，所有参与者的成绩都很低。这是现状，但我相信随着上下文的逐步扩展和 AI 对上下文注意力的提升，这个能力会逐步提高。现在是三个文件，可能明年再开这个会的时候就变成六个文件了。所以目前不要指望 AI 能帮你处理特别复杂的任务，不要有这样的期望。
唐小引： 我记得通义灵码最新版本提到了多文件处理能力，陈鑫老师能否分享一下最新的进展？
陈鑫： 对，多文件目前还是限于几个文件的范围。我们做了新一代的交互，后面也会往 Agent 方向发展，让模型有更多的自探索能力，去获取足够的上下文来完成问题。这个方向基本上是大家都看得比较清楚的，不管是模型还是产品都在往这个方向努力。
但是受限于上下文长度，目前还是没办法做到跨工程。就算在单个工程里做一些复杂的架构探索都比较难。我们越来越意识到，未来模型训练一定要考虑如何对解决问题的流程进行建模。比如从一个 issue 出发到最后生成 PR，中间的思考过程是什么，开发者是怎么一步步探索解决问题的，包括使用 IDE 工具做了哪些操作。
我们需要把这整个过程模拟出来再去训练模型，模型才能具备自主完成任务的能力。这样才能让整个准确率和用户体验进一步提升。再往上，就是我们如何对整个软件架构进行建模，让模型能够理解软件架构。
目前在这个方向上做的人还比较少。对于一个复杂工程，它的软件架构是怎样的，模型如何去抽象和理解这件事，研究得比较少。这可能是下一阶段我们这类产品必须要突破的方向，让模型能够生成更准确的代码，具备一定的架构能力。如果要涉及跨工程，那还要考虑微服务调用、稳定性、通信协议等更多问题，包括架构设计、领域建模，这些目前都看不到实现的可能。
唐小引： 刚才海龙总提到超过三个文件就会大幅降低准确性，这个数量限制在通义灵码中也是这样吗？
陈鑫： 从 token 计算来看，1000 个 token 大概对应十几 k 的代码量。在 50-60k 的上下文范围内，大概能处理几千行代码，可能涉及几十个文件。但加上多轮对话和多模态输入，实际上现在模型能处理的代码范围是非常有限的。最多也就是能处理十几个文件，这是目前的现实情况。
郑勤锴： 我们这边也观察到，项目中涉及多文件的改动，成功率确实很低。所以我们现在先专注于帮助理解项目，至少先把项目的整体情况梳理清楚，帮助开发者了解项目是什么样的。
刚才几位老师提到了 code review、单测以及需求理解等问题，我们确实需要想办法进一步提高这些能力。虽然目前看起来很遥远，但我们必须思考如何实现它。就像陈鑫老师说的，模型的训练方式需要改变，我觉得这里面一个很重要的点是整个代码领域的基础设施需要针对 AI 进行升级。
什么是基础设施呢？比如说，我们现在的模型训练数据都来自 GitHub。Git 在上一个时代是很好的基础设施，它帮我们保存了所有的代码信息，包括 commit 记录、变更等。但这些其实还不够，因为它只保存了结果，而程序员是如何得到这些代码的，这种 know-how 的过程都没有保留下来。
现在很多代码是由 AI 生成的，但 AI 是怎么生成这些代码的，这个过程完全遗失了。最终只有一个结果，如果程序员加了注释，你可能还有一点信息，如果没加注释，就什么信息都没有了。这样的低质量代码会越来越多。
在今天这个时代，我们可能需要更新这样的基础设施。我们能不能在写出代码之后，把这些过程都记录下来，甚至和代码一起存储？这段代码是怎么来的，可能是通过与 AI 交互得来的，也可能是我自己加了一些改动，把这些 know-how 全部存储下来，让模型可以学习。这样才能让模型进一步提升。
至于以往的那些 know-how，程序员都很懒，不爱记笔记也不爱写注释。那么有没有可能用 AI 来辅助，让这个过程变得更容易，帮助把这些知识积累沉淀下来，让未来的模型能更好地学习？这是我们可以思考的方向。否则的话，程序员的知识都停留在各自的脑海中，或者分散在零星的文档里，而且程序员写文档的积极性本来就不高。我们需要想办法把这些知识性的东西积累下来，供未来的模型学习。
宝玉： 我想补充一点。刚才几位老师提到训练模型时要考虑思考过程和架构，其实我现在看到一个趋势：当我们开发新项目做技术选型的时候，会把 AI 因素考虑进去。我们会选择 AI 熟悉的、AI 生成质量好的、AI 遵守规范的技术栈。
这意味着现在不是 AI 向我们妥协，而是我们在向 AI 妥协。比如前端开发，有个 CSS 框架叫 Tailwind CSS，还有个 UI 框架叫 shadcn/ui。如果你用 Claude 生成代码，它大概率会用这些框架，即使你在提示词里要求它用其他框架，它还是可能会用这些技术架构。
慢慢地，因为大家都想用 AI，不得不向 AI 妥协，这会导致一些技术标准的形成。这是把双刃剑 - 一方面确实会扼杀新框架的发展空间，另一方面当标准形成后，代码生成反而会变得更简单，未来维护起来可能也更容易。
唐小引： 刚才大家都提到了关于复杂架构这方面的挑战。对于开发者来说，AI 帮我们写代码确实很快，是很好的提效工具。但程序员们有个疑问：快一定就是好吗？因为大家还是很关注代码架构、可控性和可扩展性。在追求速度和保证质量之间，该如何找到平衡点？
张海龙： 我觉得关于这个问题，首先，从我的角度来看，大家要积极使用这些工具。不管怎样，你得用起来，可能需要花一点钱。我觉得值得投资，你应该去尝试各种新工具，尝试媒体上报道的新产品。通过使用，你会形成自己的体感，知道该如何与 AI 打交道。
从今天各位嘉宾的分享可以看到，即使是同一个工具如 Cursor，每个人的使用方式和体验都不一样。所以我认为没有一个绝对的标准说在这个时代该怎么做会更好。但我觉得效率这个问题很有意思 - 经常有客户问我："用了你们的工具，程序员能提效多少？"这其实是个很棘手的问题。你写代码快了，但如果他又多花两个小时摸鱼，这个效率到底是提高了还是降低了？
这就像你的理发工具一样，只有你自己知道哪把剪刀好用。你使用的所有 AI 工具就是你的"剪刀"，所以要多尝试，找到最适合自己的使用方式。这就是我目前的态度 - 我主要用 Cursor，同时我们也会使用一些自己开发的 Agent 来做单元测试。
陈鑫： 说到快和慢这个问题，现在 AI 确实能为开发者生成大量代码。不管是通过推荐还是通过 Agent 程序生成的代码，我们发现开发者的整体体验是正向的，大家觉得好用也愿意用。
但问题在于对 AI 存在一些过度预期。我们要思考 AI 到底能给我们带来颠覆性的生产力变革，还是仅仅作为一个小助手？如果你把它定位为一个助理或执行者，认为它能帮你提升 10%-20% 的效率，未来可能达到 30% 左右，这种预期是比较容易接受的。如果期望它能带来颠覆性改变，这是很多企业的想法，但目前来看还达不到，而且可能还会带来一些其他投入，比如需要加强质量控制和 review 工作。
不过总的来说，现在这类产品的价格比较低，即使付费使用，每月也就几十到上百块钱。对于开发者来说，这类产品具备刚需、便宜、高频三个特点，所以从商业角度来说是比较成立的。关键是我们能否在复杂场景的生产级落地上持续突破，包括在架构理解上的突破，以及改善用户输入体验。
就像勤锴提到的，我们是否要做一些工作让 AI 更理解代码，也就是所谓的"AI friendly"。比如代码库是否需要更多注释，命名更规范，或者添加一些辅助性文档，让 AI 更容易理解代码库。这些都需要在细节上继续努力，这样大家会觉得这个工具越来越好用。总的来说，在现在这个时代，不用肯定是不行的，很快开发者之间的效率就会形成明显差距。
宝玉： 我同意前面的观点，也想补充一点：我们要认识到当下的编程范式可能会因为 AI 的引入而发生改变。就像我们现在开发 Web 应用时，已经开始倾向于使用那些 AI 比较擅长的框架和工具。这不是一个坏事，因为它可能会推动整个行业向更标准化、更容易维护的方向发展。
但这并不意味着我们应该放弃对代码质量的追求。相反，因为生成代码变得容易了，我们应该把更多精力放在架构设计、代码审查和测试上。用 AI 来提高效率，但把节省下来的时间用在更有价值的思考和质量保证上。
郑勤锴： 我想强调的是，我们要改变看待 AI 的方式。不要把它想象成一个神奇的工具，认为它能解决所有问题。更合理的方式是把它看作一个高级的补全工具或助手。当你自己对问题已经有清晰的思路和架构设计时，AI 能帮你更快地实现这些想法。
这就像有了一个效率更高的执行者，但方向和决策还是需要人来把控。所以在追求速度的同时，我们不能放弃对整体架构和代码质量的思考。事实上，因为实现变得更快了，我们应该有更多时间来做这些更有价值的思考工作。
唐小引： 让我们继续讨论一些关键的问题。首先是客户和老板最关心的问题：AI 到底能提升多少效率？它能直接取代程序员吗？程序员们很困扰，因为软件工程需要精确和完整性，如果过分夸大 AI 的能力可能会带来问题。我们该如何向客户和老板解释这一点？
张海龙： 我认为 AI 不会取代程序员这个问题是不会发生的。虽然我就在这个行业，但我坚信这一点。我们今天讨论了很多原因，为什么人的角色依然很重要。我认为 AI 工具就像剪刀、锤子这样的工具，你不能指望只靠工具就能理发，还是需要人来操作。不用这些工具可能会慢一些，但核心还是人的作用。
所以作为老板和客户，要对 AI 有合理的预期。不能幻想买一个产品就可以裁掉人，这是不现实的。这种想法本身就是错误的，你可能会因为裁掉人而失去业务。但同时，作为开发者确实需要武装自己，就像陈鑫老师说的，你一定要用起这些工具，否则老板会觉得你效率太低，可能会考虑换个效率更高的人。
在这个时代，大家对整体效率会有一个普遍预期。就像在都用汇编语言的年代，没人指望你一周能开发出一个完整的应用。但现在有了这么多先进的工具，大家对基本效率的预期就会提高。两年后，所有老板和客户可能都已经形成了新的效率基准线。所以一方面不要担心被替代，另一方面要跟上时代的基本预期，这是最基本的。如果你现在能特别好地使用这些工具，遥遥领先，可能还能获得一些红利。
唐小引： 之前程序界有个梗，就是用代码量来衡量程序员的工作，这被认为是很不合理的。那么现在 AI 能产生大量代码，这些代码算不算程序员的工作量？您觉得怎样衡量程序员的工作更合理？
张海龙： 代码量肯定不是好的衡量标准，因为很多最难的问题可能只需要改一行代码，但最难的是找到这一行代码在哪里。所以我不认可按代码量来衡量工作内容和工作量。我也不认可去区分多少代码是 AI 写的，多少是你写的，这些都是不对的。
我的观点是，只要是你提交的代码就是你的，你要对这些代码负责，哪怕是 AI 生成的。你不能在出问题时说"这是 Copilot 或通义灵码生成的，跟我没关系"。你是那个要点击确认按钮的人，这个责任你必须要承担。
陈鑫： 从我们给中国企业提供的指标来看，主要还是看 AI 代码生成占比，就是 AI 生成的代码和人写的代码的总比例。这个比例本身没有绝对意义，因为即使采纳 AI 生成的代码，你还是需要大量的调试和阅读工作，这部分成本并没有算在这个比例里。
但这个比例有相对意义。最早发布产品时可能这个值是 10%-20%，现在到了 30% 多，每次更新模型和功能，这个值都会上升，未来可能会达到 50% 甚至 80%。这至少说明在手写代码这件事上，大家的模式发生了变化。我们认为当这个比例超过 50% 时，可能很多人都不会直接上手写代码了。
这个指标代表着人机交互模式的变更，体现了企业对 AI 的重视程度和应用成熟度。我们认为它与整体提效是正相关的。所以我们一直跟企业强调，这个值只是代表 AI 在企业里的落地程度是否越来越好，如果越来越好，就应该坚定不移地推进，而不是用这个来考核团队说必须达到多少比例。
因为如果直接用过程指标来考核，比如代码量或千行缺陷率这类指标，最终会带来反作用。现在有了 AI 工具，每天生成几千行甚至几万行代码变得特别容易，而且从表面上看这些代码可能还不错，但实际上可能都是无效的。所以我们是用这样的思路来指导企业。
唐小引： 好的。接下来讨论一个程序员们非常关心的问题 - 35 岁危机。在 AI coding 盛行的时代，35 岁危机会变得更严重还是能起到缓解作用？
张海龙： 这个问题我特别有发言权，因为我就是一个典型的 35 岁以上的程序员，现在已经 40 岁了。我认为 AI 绝对是对年长程序员有利的。你的手速可能比不上年轻人，但现在不需要拼手速了。你有丰富的经验，知道什么是对的，知道架构该怎么设计，知道如何准确表达需求。这些都对年长的程序员非常有利。所以我认为 35 岁程序员的春天来了。
陈鑫： 是的，我们现在用 AI agent 写代码，它可以实现跨语言编程。以前写小工具可能还需要先学习新语言，现在可以直接让 AI 生成。这样一来，经验丰富的架构和设计经验比以前更重要了，反而学习新语言和技术的门槛降低了。
这正是 AI 最擅长的 - AI 擅长执行，但不擅长设计和创新。而有经验的程序员不仅有丰富的经验和创新能力，在职场打磨多年后还特别擅长沟通。所以这确实对有经验的人更有利。
宝玉： 不过老程序员也有一个潜在的劣势 - 接受新事物的意愿。很多 35 岁以后的程序员可能对 AI 这种新技术不太愿意接受和使用。相反，年轻人都很愿意尝试新东西。
这让我想起那个被老虎追的故事 - 你不需要比老虎跑得快，只要比其他人跑得快就行，因为老虎只会吃掉跑得最慢的人。AI 的到来也是类似的，关键不完全是你的年龄，35 岁的经验确实是优势，但如果你不用 AI，这些经验优势就完全发挥不出来。只有当你积极使用 AI，并且用得很好，才能充分发挥这些优势。
郑勤锴： 这不是人和 AI 的竞争，而是人和人的竞争。会用 AI 的人一定会淘汰不会用 AI 的人，所以大家还是要积极拥抱 AI。虽然现在还处在早期阶段，但更重要的是知道如何与 AI 配合，这是很关键的。要多用，一定要多用。
唐小引： 最后，让我们展望一下 2025 年，AI 编程的发展方向是什么？刚才海龙总已经提到了从硅谷到国内的整个 AI 编程工具的发展情况。在 2025 年或未来两年，您认为从 Agent 方面会有什么进一步的变化吗？
张海龙： 我相信在 2025 年，我们会看到很多 Agent 实际落地到企业中使用。当然，我还是坚持认为会是垂直化的 Agent。因为我们已经看到一些苗头，我们的一些客户已经在非常积极地采纳这些工具。
最终你会看到在代码仓库里有很多提交者是 Agent。前天在另一个会议上我说，如果你查看现在仓库里的贡献者，会发现很多是 Agent。我认为这件事在两年内就会实现 - 会有很多 Agent 驻留在代码仓库里，它们不是同步工作的，跟 IDE 也没有关系，而是住在仓库里做各种各样的事情。
无论是修 bug、写测试、补充文档，还是做各种其他工作，就像有一堆小机器人在你的仓库里帮你处理那些你不想做的脏活累活。我相信在两年内一定能看到这样的场景。
唐小引： 这就是您预见的未来两年的里程碑？
张海龙： 是的。
陈鑫： 从我们这边观察到的趋势来看，确实 Agent 将会迎来爆发期。因为 Agent 提供了一种更加顺畅的人机交互新模式。从短期来看，我们肯定会逐步增强 Agent 自主解决问题的能力，这是确定的发展方向。
但从长远来看，一个更深层的问题是：它是否会改变现有的编程模式？这是我们内部讨论最多的问题。比如说，现在的 DevOps 工具链是否会被完全重构？未来写代码的大多数人是否还需要掌握编程语言？这些都是我们需要探索的方向。
所以从时间线来看，未来六个月内会是 Agent 的爆发和落地期。但很可能已经有一些团队在布局更具颠覆性的方向了。这与整个模型技术的演进趋势是一致的，因为从模型技术的角度来看，2025 年也被认为是 Agent 的关键之年。
宝玉： 让我从另一个角度来看这个问题。目前 AI 还没有颠覆软件工程的整体模式，它只是在某些阶段提供了加速。比如在原型阶段，它可以快速实现一个原型；在编码阶段，它能提升一定的效率。也就是说，它现在主要集中在这两个阶段有明显提升，其他阶段还没有看到显著改善。
我认为在未来两年，DevOps、运维和测试方面应该会有明显进步，这是可以预期的。从模型能力来说，我之前比喻过，Claude 现在已经达到了初中级程序员水平，而 o1 Pro 达到了中高级水平。在未来两年内，这个发展会很快，普通模型像 Claude 可能会进化到中高级水平，更高级的模型在模块级编程能力上会更强。
至于 AI Agent，虽然大家预期很高，也很期待看到成果，但这可能恰恰是最容易让人失望的地方。我对这块没有那么乐观，我认为两年时间太短了。但如果放眼更远，比如五年或十年，可能会以我们现在想象不到的方式落地，但不会是在未来两年内实现。
郑勤锴： 我想补充的是，希望能看到更加新颖的训练方式出现。我们可以想得狂野一点：现在都是基于已有的代码去训练，但如果我们有足够多的资源，能收集到现有优秀程序员的编程过程该多好。比如说，如果 Google 能把他们内部那么多高级程序员的编程方方面面的知识都记录下来，把这些过程都保留下来，然后训练一个 Agent。
这个 Agent 不是我们自己去想几个动作让它去编排，而是它真的能模仿各种高级程序员是如何工作的。就像 next token prediction 一样，做 next action prediction，把这些程序员从需求到改代码到测试的方方面面都记录下来，训练出一个更好的模型。我觉得这是很值得期待的方向。
我不确定是否会有公司去做这样的尝试，但如果以这种方式去做，应该能从本质上提高模型在 coding 方面的水平。我希望能看到这样突破性的尝试。
唐小引： 海龙总，刚才您提到了一个很关键的点。我记得您之前做过一个比喻，说从 Copilot 到 Agent 的转变，就像是从工具变成了劳动力。您能给程序员们详细解释一下 coding agent 是怎么回事，会给开发者带来什么样的变化吗？
张海龙： 这就像是招了个小弟。coding agent 就像带小弟一样，比如你开了个理发店，这个小弟可能只负责帮你打扫碎发，处理这些你不想做的脏活累活。关键是你不用盯着他干活，不用全程监督，它可以解放你的注意力，这是最大的区别。
用 Copilot 的时候，你会发现你的注意力一直被占用着。但用 Agent 时，你可以把这部分注意力解放出来，不用一直关注这些细节工作。人最稀缺的其实是注意力，当你能够解放人的注意力时，这个价值是非常大的。Agent 吸引人的地方就在于它能解放你在某些具体事务上的注意力。所以程序员可以把 Agent 当成各种初级实习生，把各种繁琐的工作交给它们去做，你只需要验收成果就可以了。
唐小引： 宝玉老师前面提到了 o1 和 o1 Pro 在 coding 方面的能力差异，很多用户都很关心这一点。能否详细说说它们的区别？
宝玉： 主要有几个关键的差异点。首先是上下文长度的差异，这在写代码时非常重要。o1 的上下文好像是 32k，而 o1 Pro 是 128k，这直接决定了你能输入和生成多少代码，这是很明显而且重要的区别。
第二个是推理时间的差异。o1 是一个推理模型，需要思考过程。普通的 o1 可能是生成一个初稿，review 一下就输出了。但 Pro 版本虽然没有公开具体原理，但从结果来看，同样的提示词能得到更好的结果。以我的经验推测，它可能内部有投票机制，会同时生成多个不同版本的代码，然后选择更好的那个输出。所以从最终结果来看，o1 Pro 确实会好很多。
当然，价格也差了十倍，一个是 20 块钱一个月，一个是 200 块钱一个月。如果你经常使用的话，其实还是很划算的。相当于每个月花 200 块钱雇了一个中高级程序员，而且它还能当顾问。因为有时候不仅是生成代码，在做设计或定方案时，你都可以和它反复讨论。
o1 的一个限制是每周只有 50 次使用机会，这个额度很容易就用完了。用完之后就没法用了，会让人很难受。这就像从 GPT-4 降级到 GPT 3.5 的感觉 - 用过 GPT-4 的人都知道这种落差。特别是在编程和技术咨询方面，用了 o1 之后你就不想再用 GPT-4 或 Claude 了，用了 Pro 版本后就更不想受限于使用次数了。这是我的使用体验，我觉得对于每天都要写代码的人来说，这个投资是很值得的。
唐小引： 接下来有一个来自用户的重要问题，关于 AI coding 的安全和隐私保护，特别是在企业级落地方面。海龙总，您能分享一下硅谷在这方面的经验吗？
张海龙： 您指的是企业代码泄露的问题对吗？实际上，这个问题在全球都是类似的。我认为任何认真对待安全的大型企业都会有这方面的顾虑，所以无论是在硅谷还是其他地方，它们都倾向于选择私有化部署方案。
值得注意的是，像 OpenAI 这样的平台也支持私有化部署，只是价格比较高。从我的观察来看，美国和其他地区的主要区别在于，可能只有更顶级的企业才会提出这样严格的要求。而在国内，即便是规模较小的企业也会要求代码不能传到外网，不管这些代码实际上是否具有高价值。
但从安全性角度来说，如果你真的关心代码安全，选择私有化方案是必然的选择。目前我看到的大多数面向专业开发者的 AI coding 产品，都提供了私有化部署的选项。
陈鑫： 确实，安全性是企业最关心的问题之一。我们发现很多企业在采用 AI 编程工具时，首先考虑的就是如何保护自己的知识产权和代码安全。这也是为什么我们在设计产品时，从一开始就考虑了私有化部署的需求。
私有化部署不仅解决了安全问题，还能让模型更好地理解企业特定的代码规范和架构风格。这样的本地化训练可以显著提升代码生成的质量和符合度。
唐小引： 还有一个用户很关心的问题：对于想学习 AI 编程的开发者，有哪些推荐的书籍资源？勤锴老师，我记得你们之前是不是出过相关的书籍？
郑勤锴： 是的，我们确实出版过一些关于工具使用的书籍，主要介绍 Copilot、CodeGeeX 等工具的使用方法。不过说实话，这个领域发展太快了，很多技术都在持续更新，所以更建议大家紧跟前沿技术的发展。
张海龙： 我建议多看看宝玉老师的微博和推特，他分享了很多实用的经验。
唐小引： 对，还有 CSDN 上的内容也很值得关注，宝玉老师在那里也有很多深度分享。宝玉老师，您觉得学习 AI 编程最有效的方式是什么？
宝玉： 我想分享一个很重要的观点：学习 AI 编程很像学游泳，你很难仅仅通过看书或视频就学会。你必须真正"下水"，通过实践来学习。就像编程本身一样，AI 编程也需要大量的实践经验。
使用得越多，你就会获得越多细微的感受，最终这些经验会内化成为你的技能。现在的书籍可能无法跟上最新发展，我建议看 B 站、YouTube 上的教程，特别是 YouTube 上有很多优质内容。当你想实现某个具体功能时，可以先找一个相关的视频教程看看，然后自己动手操作。
最后一个很重要的建议是：要舍得投资。至少订一个 20 块钱的 Cursor 会让你的学习事半功倍。如果总是想着用免费或者试用版，最终可能会因为效果不够好而产生挫败感，觉得这些工具没有别人说的那么神奇。但可能只是因为你没有用到最好的模型而已。
唐小引： 说到投资这一点，海龙总，您之前提到程序员很难为自己花钱，更多依赖企业付费，您对此有什么看法？
张海龙： 在我们公司，Cursor 的费用是可以报销的，我们推行全员使用 Cursor 的政策。我非常赞同宝玉老师的观点 - 要用就用最好的工具。这是个心理预期的问题，为了省那么一点钱，你可能错过了重要的时代红利。这是值得投资的，建议想办法说服老板给你报销。
唐小引： 那要怎么说服老板呢？
张海龙： （笑着说）老板喜欢看代码行数，你就给他看行数。告诉他："看，以前我一天写一百行，现在一天能写一千行了。"
唐小引： 陈鑫老师和勤锴老师，我想请教两个问题：第一，你们有什么建议可以分享给大家？第二，作为国内的 AI 编程工具，你们要直接和海外产品竞争，如何让开发者们认识到你们产品的价值，吸引更多人使用？
陈鑫： 这个领域确实发展很快，虽然国内外模型之间确实存在一些差异，但从最新一代模型来看，这个差距已经在缩小。我们更注重解决企业在实际生产中遇到的具体问题。所以我们开发了很多有趣的功能，包括一些垂直化的能力，这些其实是海外产品没有很好解决的问题。
随着我们的产品能力和模型能力的提升，甚至在某些垂直领域的超越，我们还是很有信心的。因为这个领域的竞争才刚刚开始，就像之前大家都认为 GitHub Copilot 已经一统天下了，结果又出现了很多新的竞争者。这个赛道还有很大的发展空间，做着做着就会发现还有太多不够的地方，差得还很远。
郑勤锴： 对，我觉得虽然大家现在看到国产产品和国外产品有一定差距，但请保持期待。我们正在迎头赶上，无论是模型能力还是产品体验，我们都在不断迭代。我相信总有一天我们能达到同等水平，甚至在某些方面实现超越。
唐小引： 好的，感谢几位老师为我们带来的 AI coding 年度总结和展望，也感谢直播间里所有热情参与讨论的观众。CSDN 在 2025 年会继续围绕大家关心的痛点问题，推出更多深入的对话和技术实践内容。欢迎大家持续关注我们的公众号和视频号，所有内容都可以在这里获取。再次感谢大家，我们今天的直播就到这里结束了，请直播间的观众可以发送一些庆祝或点赞的消息。也请各位老师跟大家说再见。
张海龙： 拜拜！
宝玉、陈鑫、郑勤锴： 谢谢大家，再见！