AI 编程工具的发展令人目不暇接。从年初 Devin 这款被称为“首个真正的 AI工程师”的产品发布，到年中 Anthropic 在 Claude 3.5 Sonnet 模型推出「Artifacts」功能的重大突破，再到 Cursor、Windsurf 等新一代 IDE 的崛起，AI 正在重塑程序员的工作方式。然而，技术的演进也带来了新的思考：通用 Coding Agent 是否真的可行？AI 能否真正理解复杂的业务需求？35 岁以上的程序员将何去何从？
1 月 15 日，CSDN 对话直播栏目《万有引力》迎来第二期。在栏目主理人 CSDN &《新程序员》执行总编唐小引的主持下，Gru.ai CEO 张海龙、知名 Prompt Engineer 宝玉、阿里云通义灵码技术负责人 陈鑫，以及智谱 AI CodeGeeX 团队技术负责人 郑勤锴围绕程序员们最为关心的 AI 编程一起展开深入对谈。
欢迎收听 & 订阅《万有引力》小宇宙频道~
张海龙
-
我不太相信通用的 Coding Agent 能做出来。在实际软件工程中，企业级代码仓库涉及大量的业务上下文、工程上下文，这些上下文每天都在变化，大模型很难持续跟进。
-
Code Review（代码审查）是最难被 AI 替代的环节之一。因为 Code Review 需要的上下文实在太多，它甚至需要对业务需求的理解。
宝玉
-
提示词的技巧其实没有那么重要。编程领域提示词的关键点：一是使用什么模型；二是如何给 AI 合适的上下文；三是让每次交互都是原子化的、独立的。
-
Code Review 是程序员目前不可替代的核心能力之一。因为程序员是参与了整个过程的，可以跟任何人沟通，有完整的上下文。
陈鑫
-
现在国内开发者普遍还是在用 Copilot 这种模式。像 Cursor 这种 Agent、Composer 的玩法，都还处于初期阶段，可能只有 10% 到 20% 的普及率。
-
在当前这种模式下，只要需求复杂到一定程度就离不开程序员的把控。面对现在庞大的数字化体系，它的业务逻辑非常复杂。如果要实现完全的 AI 编程，要么就是实现 AGI，要么整个编程范式就要颠覆，代码的重要性可能会降低。但从目前来看，我们还看不到这种可能。
郑勤锴
-
企业内部的代码现在缺乏强化训练。在企业环境中总是离不开私有化部署的讨论，至少要让模型能够理解这些企业内部工具在做什么。
-
高级程序员编程工作方式已经发生很大改变。以前基于 Copilot 时需要自己写很多代码，现在由于更自动化的 Agent 的引入，当你问一个问题后，Agent 会帮你写很多代码。
以下是对话全文，经 CSDN 精编整理：
唐小引：如果让各位来总结 2024 年 AI Coding 的发展，你们会想到哪些关键词和重要命题？
张海龙：2024 年 AI Coding 最显著的突破是 Cursor 的出现。大家以前认为 GitHub 做了 Copilot 这么长时间，这个方向上的竞争可能已经结束了，产品形态也相对稳定了。但没想到会出现 Cursor 这样具有颠覆性效果的产品。如果回想 2024 年，这是给我印象最深刻的产品，而且我现在每天都在用，确实带来了非常好的效果，是今年这个领域最惊艳的事件。
唐小引：还有第二个吗？
张海龙：我尝试过其他工具，但都没有让我感到特别心动。
宝玉：我总结几个关键词。第一个是很火的话题——不懂代码的产品经理也能开始借助 AI 编程写程序。这是前段时间争议很大的一个话题，我们后面可以继续探讨。
刚才提到了 Cursor，但我想强调的是，Cursor 的成功源于两个关键因素：创新的交互模式，以及更重要的是其采用了 Claude 3.5 Sonnet 模型作为底层支持。这个模型在上下文长度、生成速度和生成质量几个方面都达到了很好的平衡，才让像 Cursor 这样的工具有机会被大众熟知，能真正解决问题。
如果从代码生成水平来说，Claude 的代码生成水平大概在刚到中级或稍微高一点的级别，而 Claude 3.5 Sonnet 已经接近高级程序员水平。它写的代码质量有时候比我还要好，而且在我不熟悉的领域也能生成很好的代码。这个模型虽然使用成本会高一些，但对编程领域来说确实是 2024 年的一个重要突破。
最后一个关键词是 AI Agent。这个话题也很火，去年 Devin 推出了第一个可以算作真正意义上的 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 里直接添加要引用的代码，选择几行代码，写下提示词，贴上截图，这些繁琐的工作它都能自动完成了。这是对于我这样比较专业的用法。对于不那么专业的用户来说，他们甚至不需要专业地选择代码，只要给出大致的指令，工具就会猜测你可能需要的代码，在背后帮你把这些脏活累活都做了。这对于降低使用门槛帮助相当大。
所以我认为两者是相辅相成的，你既需要强大的模型，也需要在交互上有便利性和突破。
陈鑫：这个领域在过去一年发展得太快了。从产品角度来看，最关键的是对整个领域发展节奏的判断。2024 年初，受 Devin 热潮影响，业界普遍认为 Agent 导向的端到端解决方案是发展方向。但模型的发展是有阶段性的，在当时的模型水平下，效果其实是不及预期的。
出乎意料的是，在小范围多文件代码生成方面，特别是在配合像 Cursor 那样优秀的人机交互模式后，能做到生产级的落地。可以看到不同的探索方向带来了不同的结果。
总的来说，现在整个 AI Coding 领域模型的发展比我们想象的要快。年初做 SLB（编程能力测试）测试集的时候，我们认为年底可能做到 30-40 分左右就不错了，但现在大家都很轻松地超过了 50 分，甚至达到 70 分。这个领域还是充满想象力的，我们现在很难判断 3-6 个月后模型会发展到什么程度。
郑勤锴：确实如大家所说，去年一个重要的时间点是 Claude 3.5 Sonnet 模型的发布。它不仅提升了 Cursor、Windsurf 等工具的实用性，更推动了交互模式向 Agent 方向演进。这得益于模型能力的提升，它可以很好地支持各种指令的跟随和复杂工具的调用。
最令我激动的是，目前这些工具确实能够提高我的生产力。我每天写代码时的体验与之前的 Copilot 类产品有明显不同。我现在主要使用 Windsurf 作为 IDE，虽然也体验过 Cursor，但我更习惯 Windsurf。我的整个编程流程发生了很大变化：以前基于 Copilot 时需要自己写很多代码，Copilot 只是帮你做一些补全。现在由于更自动化的 Agent 的引入，当你问一个问题后，Agent 会帮你写很多代码。
这时，review 代码确实会占用较多时间，所以我开发了一些新方法：在解决任务时先编写单元测试，然后让 Agent 来实现具体功能。这样大大降低了 Code Review 的压力——如果代码能通过单元测试，基本证明实现是合格的，我只需要确保单元测试本身的准确性和完整性。这种工作方式的转变让我感到很兴奋，确实能显著提升程序员的工作效率。
唐小引：在 Cursor 和 Windsurf 的对比中，勤锴老师选择 Windsurf 作为主要生产力工具。其他几位使用的是什么工具？
陈鑫：现在我主要使用通义灵码，但也会使用其他产品做深度体验。在体验过程中，我们需要去研究它们的技术实现和设计细节，这方面我收获很多。
宝玉：我主要是 o1 Pro 配合 Cursor，两个一起使用。写程序时我会用一个叫 Repo Prompt 的小工具，它可以让你选择整个代码库中相关的模块代码。因为上下文很重要，我会把相关代码都选上，然后在专门的 Prompt 栏写我要实现的功能，整体发给 o1 Pro。等它生成结果后，我 review 一下再复制粘贴过来。简单任务就直接用 Cursor。相比 Windsurf 和 Cursor，我个人更喜欢 Cursor 一些。
唐小引：为什么？
宝玉：这主要取决于个人的使用偏好是偏向 Agent 还是 Composer。我自身相对来说没有太依赖 Agent，更多使用 Composer。我更习惯自己先构思好、模块设计好，然后再给出指令让它生成，最后我再 review。我还是比较传统的老程序员写法。而习惯使用 Agent 的开发者通常倾向于通过指令直接实现模块功能，相对不太关注具体实现细节。这种场景下 Windsurf 可能做得更好一些。
郑勤锴：Windsurf 的 Agent 自动化能力很好。它在处理问题时会自动帮你查找相关文件，了解项目信息等。我觉得它的用户体验做得比较好，包括我前面提到的单元测试场景，它可以自动运行测试、查看结果，进行反复迭代。整体的自动化体验提升了开发效率。
张海龙：在 IDE 相关的 AI 工具中，我只用 Cursor。而且我主要使用它的补全功能，很少用到 Composer 和 chat。我认为 Cursor 真正的精髓就是补全，其他功能我都试过，但觉得不太行。不过它的补全功能做得真的太好了。
唐小引：代码补全功能从早期 IDE 到现在一直在发展，Cursor 带来了哪些全新的体验？
张海龙：Cursor 本质上在做一件事——意图揣测，就是猜你接下来想要做什么。它不仅仅是补全代码，而是在预测你的下一步意图。无论是通过自己训练的小模型还是其他手段，它的猜测准确率都很高。大家喜欢用 Cursor 的 Tab 键就是因为这个，你会发现连续按 Tab 的次数越来越多。这对整个开发体验带来了很大的提升。
唐小引：从硅谷的视角，能请海龙总分享一下对 AI Coding 发展现状和 Agent 的思考吗？
张海龙：首先，AI Coding 其实分很多方向。在专业开发领域，又可以分为同步工作和异步工作两种模式。目前我们做得特别好的是同步工作，无论是以 IDE、插件还是网页形式实现，只要是同步工作都属于一类。另一类是异步工作，这个领域目前还处于探索阶段。
在硅谷，业界普遍认为到 2024 年初，由于 GitHub Copilot 的主导地位，同步工作这一领域的创新空间已较为有限。2024 年 6 月在旧金山曾有一场名为 AI Engineer 的会议，国内报道不多。在那个会议的 Agent 分会场，所有创业项目的分享中，只有 Cursor 在讲 Copilot 相关的内容。结果最后只有它真正做成了，这是一个很有趣的现象。
所以我对整个 Agent 的发展预期并不像大家那么乐观。尤其是在通用性方面，我认为通用的 Coding Agent 是做不出来的。因为在实际的软件工程中，企业级代码仓库还涉及大量的业务上下文、工程上下文，比如如何 setup、依赖哪个仓库、依赖哪个特殊环境，甚至依赖哪个特殊 IP。关键是，这些上下文每天都在变化，如何让大模型能够持续跟进这些变化？
大模型是静态的，它没有与时俱进，没有跟着项目一起成长。现在做的所有 RAG 效果都不太理想，就像一个应届毕业生进入公司，每天都在记笔记，但他不会成长。这样的“员工”怎么可能好用呢？所以通用的 Coding Agent 是做不出来的，这是一个比较悲观的判断。因此我们更相信垂直的 Coding Agent。
唐小引：垂直是指往哪个方向发展？
张海龙：在硅谷，创业项目最多的就是垂直 Agent，专注于软件开发生命周期中的某个具体环节。比如有的只做 Code Review，像我们只做单元测试，有的做 Integration Testing（集成测试） 和 E2E Testing（端到端测试），有的做 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。
郑勤锴：对海龙总的观点，我可能有一些不同的看法。因为我们是专门做大模型的公司，目标一定是走向 AGI。我认为 Coding Agent 是 AGI 的前置步骤，你需要先实现这一步才有可能达到 AGI。但确实现在还有一定距离。
在 2024 年，我们也在探索如何处理企业级的大型代码库。我们发现代码阅读是一个非常大的需求。当你面对几千个文件的项目时，如何理解这些代码对大家来说都是很大的挑战。新员工入职一个公司，可能要花几周时间去读懂公司的老代码库。为了解决这个问题，我们在 CodeGeeX 中开发了“项目地图”功能，它能够直观地可视化项目结构，不仅展示整体架构和依赖关系，还允许通过节点深入查看具体实现细节。
我们认为未来随着更多的 Copilot 和 Agent 的集成，很多代码都是 AI 写出来的，人去理解这些代码会有一定困难，所以需要有更好的代码阅读方式。我们还做了一个“幽灵注释”功能，你在看文件时不需要把注释直接加到文件里，可以看到每一行代码旁边有个虚拟的注释来提示这段代码在做什么。
如果要实现 Coding Agent 能够真正处理这些复杂项目，我认为要在模型训练方式上有很大改进。今天如果我们对比不同的 Agent 实现，比如 Cursor 和 Windsurf，它们的底层实现其实很类似。它们效果的差异主要在于上下文管理——我们在流程中该给模型看哪些内容？是不是只看几个相关文件？需不需要给它看用户的历史操作、其他代码库，或者之前看过的文档？
唐小引：对于所有专业开发者来说，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 没有读心术，它不知道你想要什么；
第三是原子化的提示词，就是在架构设计或写提示词时，要让模块尽量松耦合。
唐小引：说到这些工具的使用体验，想请教陈鑫老师和勤锴老师是否从工具层面考虑过如何解决用户的痛点问题？比如对用户提问的理解准确性、上下文理解等方面，你们有没有一些能力可以封装，让用户在使用时少一些困扰？
陈鑫：关于提示词这块，我们现在的主要思路是，在做 IDE 插件时尽量让开发者有控制力，让他们知道自己给了模型什么输入，以及模型是基于这些输入来给出输出的。这种透明度是需要把握的，所以我们更多是做一些推荐。
例如，当开发者需要修改当前代码时，我们可以推荐引入哪些相关文件作为上下文。当然，这种方式基于一个隐性假设：过多的上下文可能导致模型混乱或出错。这是个隐性假设，如果这个假设不存在了，如果上下文可以足够长，模型的指令遵循能力也足够强，那我们就可以直接做自动上下文了，根据用户意图自动感知需要引用哪些文件。这将是更高程度的自动化。
但从目前模型的现状来看，还需要更多人工操作。我们现在所有做得比较成功的产品，实际上都是与模型配合得比较好的，你要了解模型大概是什么水平，然后匹配合适的交互方式。这显然并非开发者期望的最终状态，而是一种折衷方案。
郑勤锴：为了解决用户提示词表达不清晰的问题，我们目前的解决方案主要是通过知识库关联用户的历史文件或文档，并结合联网搜索类似问题。
我们正在尝试一些更灵活的方式。比如我们可以类比自己在开发时是怎么解决问题的：当我们需要解决一个问题时，会先查看项目结构，看看哪些文件可能和当前问题相关，然后去打开看。我们会使用 VS Code 的快速跳转功能，点击一个变量或函数定义就能看到它在哪里定义、在哪里被使用。
如果模型能够掌握这些能力，就可以更精准地定位相关内容，而不再局限于依赖 RAG 或通过语义相似度检索大量片段并进行倒排的粗糙方式。我们希望让模型能更自主地找到相关信息，这些信息可能更精准地帮助它理解用户需求。
唐小引：从研发生命周期来看，第一步是如何让 AI 理解复杂的业务需求，这是个核心问题。另外还包括代码性能把控等方面，海龙总有什么经验可以分享？在硅谷看到的情况又是怎样的？
张海龙：我理解您的问题是关于如何让 AI 编程工具理解业务需求以实现更好的落地。然而，这并非最直接的问题，而是一种实现手段。我们需要先思考，让 AI 理解需求的最终目的是什么？是要它帮你写代码，还是写文档，还是做其他事情？你让它理解需求之后要它做什么？
实际上，我目前没有看到谁在真正尝试让 AI 理解复杂的业务需求。像 Cursor 也不会让你先把需求文档扔给它，只有 Bard 这种面向非专业人群的工具才会让你描述你想要什么。我把这种称为“许愿”式的交互——用户无法清晰描述具体需求，更像是在表达愿望。
在专业领域，首先一个复杂项目基本上是没有清晰的需求的。我相信在座的都有经验，就像阿里巴巴那么多项目，哪有什么清晰的需求？很多都是在人的脑子里。因此，让大模型理解企业复杂项目的需求，目前尚无可行的解决方案。实际上大家做的方向也不是往这个方向走，而是尽量做一些通过代码能够推导出来的东西，然后带一点点人类的输入，大概是这样的逻辑。
唐小引：所以您是说，现在大家期望 AI 能理解清楚需求，这本身其实是一个伪需求？
张海龙：是的，连人都没办法描述清楚，又要让 AI 理解什么呢？看看 Cursor 的效果，它的成功不是因为它理解需求，它事实上根本不理解需求。它就是在猜，就是在照葫芦画瓢。只是说它“画瓢”的能力特别好，然后能在画完瓢后给出一些改进。
宝玉：对，我认同这点。首先，现在的 AI 确实不可能理解复杂需求，因为它受限于上下文窗口的长度，也没有记忆能力。
但是对于人分解之后的模块级需求，如果交给 Cursor，它其实是能很好实现的，而且理解得也不错。所以我觉得这可能是海龙老师对 Cursor 的一个误解，因为他主要用 Tab 补全功能，较少使用 Composer。我认为 Cursor 和 Claude 这些模型对模块级别的需求，已经可以理解得很好了。
郑勤锴：我也想补充一下使用这些工具的个人体会。我发现这跟使用方式真的有很大关系，同一个人用 Agent 模式，不同人的体验可能完全不同。我们不要把它想得太神奇，觉得它什么都能解决，你就把它当作一个高级的补全工具。
如果你自己都不知道这个问题怎么解决，用 Agent 模式大概率也是不行的。就算它帮你写出代码，你可能也看不懂。但如果你已经知道怎么解决，有详细的思路，你告诉它先做什么再做什么，这个架构应该怎么设计，它其实就是帮你起到一个补全的作用，只是一个更高级的补全。它帮你把这些写出来，所以我觉得这个是大家要理解的。
不要期望说出了个 bug，你一句提示词说“帮我修复一下”就能解决。其实你得告诉它该改哪里，这个问题到底出在哪里。如果你很详细地告诉它，它其实就是帮你做执行，把这个东西实现出来而已。
张海龙：我有个疑问，如果真的要很详细地告诉它该修哪里，为什么不直接改呢？打字不是更累吗？
郑勤锴：关键在于，解决问题往往涉及多行代码，可能需要跨多个位置进行修改。你跟它讲清楚后，它可以直接把所有地方都改好。包括跨文件的修改，它也能同时帮你处理好。这样确实能省时间，就是在你很清晰知道要做什么，并且有好的单元测试的情况下，你可以让它做这些具体的改动。
唐小引：以前写代码我们都很讲究代码整洁之道，程序员的高下之分很大程度上取决于代码质量。那么在 AI 编程盛行的时代，对于代码质量和性能，是依然需要严格把控，还是说只要能实现功能就可以了？
张海龙：这是我们最近一直在思考的问题。只要软件工程依然存在，代码质量就至关重要。除非代码彻底消失，否则质量永远是不可忽视的核心。保障质量的手段有很多，比如传统软件工程中的 Code Review 就是一种保障。目前许多公司正在尝试用 AI Agent 进行 Code Review，但国内对 Code Review 的实践相对较少，主要因为它耗时且对人员能力要求较高。
现在代码质量的问题可能会更严峻，因为大量代码你都没有经过大脑思考，都是 AI 帮你补出来的。你可能粗略检查一下，发现编译无错误，IDE 的 lint 工具和 CI 都通过了，便认为代码没有问题。但实际上你并没有真正认真思考每一个字符是怎么回事，所以里面可能潜藏着很多小问题。
我认为在 AI 生成代码的时代，会有大量垃圾代码被创造出来，因为创造垃圾的成本太低了。在严肃场景下你如何保证最终质量是好的，这很重要。所以，我们认为单元测试是保障质量的有效手段之一。
既然 AI 生成了大量代码，开发者是否需要确保这些代码符合预期？所以我们就再搞一个 Agent 帮你写测试，因为没有人喜欢写测试，我们通过 AI Agent 来处理这些“脏活累活”。但是我觉得没有什么神奇的解决方案——如果你本身水平很差，搞不清楚性能问题是怎么回事，你也不会因为有了 AI 就变得更好。所以我们最近在思考一个观点：AI 其实不能提高你的上限，AI 是个放大器，它不拉高上限。我觉得大家还是要关注质量，该做的 Code Review、单元测试这些动作还是得做，甚至比以前更重要。
唐小引：那您觉得程序员和 AI 编程工具的理想配合状态是怎样的？
张海龙：首先，要用各种自动化检查来保障质量，这在 IDE 里现在已经很成熟了。然后要把那些好的软件工程实践加上去，比如好好写测试，甚至用测试驱动开发，认真做 Code Review。不能因为这边省了工作就完全不管质量——除非你根本不在乎质量，否则最后一定会出问题。
因此，这种协作方式确实提升了效率，但保障质量仍需投入一定的人工成本。包括一些新的 Agent 工具的出现，会辅助开发者来做这些事情。
陈鑫：现在在我们看到的企业里，质量是刚需，越大的企业越希望能用 AI 来帮助做单元测试、辅助 Code Review。我们发现，先编写测试再让大模型基于测试生成业务逻辑，可以提高代码的精准度。这其实也是一种用单元测试的方式去告诉模型应该怎么写业务逻辑。
此外，我们认为 AI 生成代码与以往从社区复制优秀代码的差异并不大，只是效率显著提升。本质上没有区别，以前大家也是复制后改一改，现在也是生成后调一调，只是现在效率更高。
从质量保障角度来说，肯定还是需要人来把关。我们可以通过一些提示词的限定来避免一些低级错误，比如在一些容易踩坑的地方加入规范提示。每个工程可能都有一些特殊的规范，我们可以把这些规范内置进去，阻止一些低级错误的发生。但这也是有限的，如果只是从性能角度看，我们很难用提示词去描述一个很好的性能要求，模型就能做到。它可能只能防止一些低级错误。
因此，最终的质量仍需通过各个环节的严格把控来保障。其中单元测试可能是模型最容易替代的部分，然后是 Code Review。但从测试生成这块来看，大部分还得靠人，目前模型还没有那么强的能力去使用工具替代人做黑盒测试，尤其是在理解需求方面也做得比较差。所以我们会按这样的顺序来为企业提供功能。
郑勤锴：这个转变实际上是所有开发者都需要经历的开发范式上的转变。以往可能更多关注实现的细节和个人经验，现在这些具体实现 AI 可以帮你加速，所以你需要思考其他方面的内容。
海龙老师提到的测试驱动开发理念早在 90 年代就已提出，但推广难度较大，主要因为它对开发者的能力要求较高——开发者需要在写代码之前就清楚地知道这个任务要做什么，理解它的输入输出会是什么，会有哪些边界情况。这其实需要开发者对业务有很深的理解，所以推进起来比较困难。
对于初级程序员而言，他们可能尚未理清需求便开始编写代码，直到完成后才明确目标。但在未来，当你给出一个需求，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 只能说是做了一小部分。但这个需求，企业是特别希望有的。所以这块如果产品真能做出来，会有很大的市场空间，但从目前来看确实没有做得太好。就像我们做到现在发现，在初级层面是有一些用，但是离自己的预期还很远。
如果 AI 能够满足企业的期望，那它必然具备出色的代码实现能力，因为它对需求有深刻理解，能够判断代码的正确性。但目前以模型的能力来看，它直接理解一个复杂的需求，类似 PRD 这样的东西是根本做不好的。它只能处理确定性任务，例如将详细设计转化为代码。但详细设计实际上已经是开发者明确告诉了 AI 今天要做什么、在什么范围里面做、应该怎么做，而且还得通过多轮迭代才能做好。
这是个现实的问题。如果 AI 能够理解复杂需求甚至整个代码库，那意味着许多技术难题已被攻克。那就是说，这个直接从需求到代码，类似 Devin 这种模式，以及直接做测试，就是理解需求然后直接在界面上点击就行。现在使用工具对 AI 来说并不难，但难的是它不知道怎么点，也不知道点了以后对不对。所以如果这些问题都攻克了，那确实可能就接近 AGI 了。
张海龙：我相信目前尚未实现，但最终一定会达到这一目标。不过目前来看还看不到，可能还需要上下文长度暴增一百倍，比如达到两千万或者一亿 token 的上下文，我觉得才有希望。
宝玉：我认为 Code Review 正是程序员目前不可替代的核心能力之一。如果我们讨论 AI 替代程序员的可能性，Code Review 是最难被取代的领域之一。而且作为程序员，我建议现在更应该重视 Code Review，即使以前可能不太关注这方面。
有了 AI 之后，因为你不需要花太多精力去写代码，反而有更多精力去 review 代码。另外，Code Review 这件事情因为涉及到需求和任务的上下文，AI 很难完全理解这些背景。但作为程序员，你是参与了整个过程的，你可以跟任何人沟通，你有完整的上下文，所以你能更好地理解和审查这些 PR。
如果不对 AI 生成的代码进行认真审查就直接合并，未来将难以维护。所以这个关系要搞清楚，一定要在 Code Review 上投入更多精力。前面有位老师提到了代码扫描工具，以前这些工具会扫描代码中可能的安全漏洞和性能问题，但采纳率比较低，因为它指出的问题经常不够准确。AI 在这方面可能会做得更好，可能能在很大程度上替代这类工具。
唐小引：您刚才提到 Code Review 是不可替代的，那还有哪些是程序员不可替代的核心能力？
宝玉：首先，当前 AI 的固有缺陷之一是上下文长度不足，正如海龙老师所说，可能需要增加百倍才能完整理解一个代码库。这是一个硬伤。
其次，AI 缺乏环境感知能力。尽管它能够运行代码和调用工具，但对运行结果缺乏直观理解。UI 也是类似的，即使有了多模态能力，如果要完成一个复杂操作，比如订机票这样的流程，现在还是需要人来操作。这涉及到环境感知和行动能力的不足，这也是大家对 AI Agent 的一个期望，但目前还有欠缺。
基于 AI 的这些局限性，有些能力是现在无法替代的。比如需求分析——需求分析需要和产品经理、客户进行沟通，有些东西用语言很难描述清楚，用截图也不行，因为可能涉及动态的交互。有时候人与人之间都说不清楚，AI 就更难理解了。
另外，由于上下文的限制，复杂的架构分解也是 AI 做不到的。不是说 AI 的架构能力差，而是因为上下文限制，它无法处理复杂系统的架构分解。这是非常重要的一块，因为一个复杂系统需要多人协作，甚至需要多个 AI 协助，都需要先进行分解。然后还要把这些部分整合起来，这个过程 AI 是无法替代的。
最后就是前面提到的环境感知问题，特别是在调试方面。这是新手最痛苦的地方——AI 可以很快生成代码，但当出现问题时，你可能完全不知道该怎么办，可能卡在某个地方很久。要么放弃，要么找专业人士帮助，或者运气好 AI 突然给出了正确答案。这块是专业程序员很难被替代的领域，因为只有程序员知道如何运行、如何重现问题，然后一步步缩小范围，最后可能借助 AI 或自己的专业知识来解决。这些都是目前很难被替代的能力。
唐小引：说到调试（Debug），这也是程序员的一个疑惑点。因为大家在遇到报错或异常时，会把问题描述给 AI 来分析和修改。对于程序员来说，人工调试在未来是否依然重要，还是这部分主要会被 AI 化？
张海龙：说到 Debug，这其实是最早这波 AI Agent 创业公司尝试的方向之一。可能这些公司到今天已经不在了，但没有成功的。这个需求实在太强烈了，所有人都在想，如果能让 AI 修 bug，那就太厉害了。但这里面很多东西都是相关联的，写 feature 和修 bug 本质上没有区别。Code Review 某种程度上也是在修 bug。
我认为这些工作目前还是需要人来做。这里面有个很重要的概念叫 reproduce（重现问题）。写过程序的都知道，如果你能重现问题，就基本能修好。但问题是重现本身就是一个极其困难的事情，对 AI 来说更是如此。
唐小引：接下来我想探讨一个所有程序员都关心的问题——AI 编程工具在跨文件、跨工程代码生成方面的能力。国内有许多代码编写规范，比如阿里的 Java 规范在程序员圈内非常有名。海龙总，从硅谷的角度来看，跨文件和跨工程的代码生成能力目前发展到什么程度了？
张海龙：跨工程（跨 project、跨 repo）的能力我几乎没见过。跨文件的能力目前已经有所进展，例如解决一个问题可能需要修改多个文件中的代码。但在真实的企业级项目中，除非是能够完全塞入上下文的小型项目（如商店网站或博客），超过三个文件的修改，准确率会急剧下降。
在复杂的代码库中，如果期望 AI 完成涉及超过三个文件的修改任务，从统计数据来看，100 个任务中大概率会失败。AI 可能会进行修改，但修改结果往往是错误的。这是我们目前观察到的现象。
从 SLB 榜单中也能看出这一点——在多文件修改的成功率上，所有参与者的成绩都很低。这是现状，但我相信随着上下文长度的扩展和 AI 对上下文注意力的提升，这一能力会逐步提高。目前是三个文件，或许明年这一数字会增加到六个。因此，现阶段不要对 AI 处理复杂任务抱有过高期望。
陈鑫：是的，多文件修改目前仍局限于几个文件的范围。我们正在开发新一代交互模式，并朝着 Agent 方向发展，赋予模型更多自探索能力，以获取足够的上下文来解决问题。这一方向已被广泛认可，无论是模型还是产品都在朝此努力。
然而，受限于上下文长度，跨工程的能力目前仍无法实现。即使在单个工程中进行复杂的架构探索也颇具挑战。我们逐渐意识到，未来的模型训练必须模拟解决问题的流程。例如，从 issue 到生成 PR 的中间思考过程，开发者如何一步步解决问题，包括使用 IDE 工具的操作。
我们需要模拟这一完整流程来训练模型，使其具备自主完成任务的能力，从而提升准确率和用户体验。更进一步，我们需要对软件架构进行建模，使模型能够理解架构。目前，这一领域的研究较少。对于复杂工程，模型如何抽象和理解软件架构仍是一个未解之谜。这可能是下一阶段我们必须突破的方向，使模型能够生成更准确的代码并具备一定的架构能力。如果涉及跨工程，还需考虑微服务调用、稳定性、通信协议等问题，包括架构设计和领域建模，这些目前都难以实现。
唐小引：刚才海龙总提到超过三个文件的修改会大幅降低准确性，这一限制在通义灵码和 CodeGeeX 是否也存在？
陈鑫：从 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 妥协。例如，在前端开发中，CSS 框架 Tailwind CSS 和 UI 框架 shadcn/ui 被广泛使用。如果你用 Claude 生成代码，它大概率会使用这些框架，即使你在提示词中要求使用其他框架，它仍可能选择这些技术架构。
唐小引：让我们继续探讨一些关键问题。首先是客户和老板最关心的问题：AI 到底能提升多少效率？它能否直接取代程序员？程序员们对此感到困扰，因为软件工程需要精确性和完整性，过度夸大 AI 的能力可能会带来问题。我们该如何向客户和老板解释这一点？
张海龙：我认为 AI 不会取代程序员，这一点是毋庸置疑的。尽管我身处这个行业，但我坚信这一点。我们今天讨论了许多原因，解释了为什么人的角色仍然至关重要。AI 工具就像剪刀或锤子，你不能指望仅靠工具就能理发，仍然需要人来操作。没有这些工具可能会慢一些，但核心仍然是人的作用。
因此，作为老板和客户，需要对 AI 有合理的预期。不能幻想购买一个产品就可以裁员，这是不现实的。这种想法本身就是错误的，裁员可能会导致业务受损。同时，开发者确实需要武装自己，正如陈鑫老师所说，你必须使用这些工具，否则老板可能会认为你效率低下，进而考虑更换效率更高的人。
在这个时代，大家对整体效率有一个普遍的预期。就像在汇编语言时代，没人指望你一周内开发出一个完整的应用。但现在有了这么多先进工具，大家对基本效率的预期自然会提高。两年后，所有老板和客户可能都已形成新的效率基准线。因此，一方面无需担心被替代，另一方面要跟上时代的基本预期，这是最基本的要求。如果你现在能熟练使用这些工具并遥遥领先，或许还能获得一些红利。
唐小引：此前程序员圈有个梗，就是老板会用代码量来衡量工作，这被认为是不合理的。那么现在 AI 能生成大量代码，这些代码是否应计入程序员的工作量？您认为如何更合理地衡量程序员的工作？
张海龙：代码量肯定不是一个好的衡量标准，因为许多最难的问题可能只需要修改一行代码，但最困难的是找到这一行代码的位置。因此，我不认可用代码量来衡量工作内容和工作量。我也不认可区分多少代码是 AI 生成的，多少是人工编写的，这些都是不合理的。
我的观点是，只要是你提交的代码，就是你的责任，即使是 AI 生成的。你不能在出问题时说“这是 Copilot 或通义灵码生成的，与我无关”。你是点击确认按钮的人，必须承担这一责任。
陈鑫：从我们为中国企业提供的指标来看，主要关注 AI 代码生成占比，即 AI 生成的代码与人工编写代码的比例。这一比例本身没有绝对意义，因为即使采纳 AI 生成的代码，仍需要大量的调试和阅读工作，这部分成本并未计入比例中。
然而，这一比例具有相对意义。最初发布产品时，这一比例可能是 10%-20%，现在已超过 30%。每次更新模型和功能，这一比例都会上升，未来可能达到 50% 甚至 80%。这至少表明，在手写代码方面，大家的模式正在发生变化。我们认为，当 AI 代码生成占比超过 50% 时，许多人可能不再直接手写代码。
这一指标反映了人机交互模式的变化，体现了企业对 AI 的重视程度和应用成熟度。我们认为它与整体效率提升呈正相关。因此，我们一直向企业强调，这一比例仅代表 AI 在企业中的落地程度是否在提升。如果确实在提升，就应该坚定推进，而不是用它来考核团队，要求必须达到某个比例。
唐小引：接下来我们探讨一个程序员们非常关心的问题——35 岁危机。在 AI 编程盛行的时代，35 岁危机会加剧还是得到缓解？
张海龙：这个问题我特别有发言权，因为我是一个典型的 35 岁以上程序员，现在已经 40 岁了。我认为 AI 绝对对年长程序员有利。你的手速可能不如年轻人，但现在不再需要拼手速了。你拥有丰富的经验，知道什么是对的，了解如何设计架构，以及如何准确表达需求。这些都对年长程序员非常有利。因此，我认为 35 岁程序员的春天来了。
陈鑫：是的，我们现在使用 AI Agent 编写代码，它可以实现跨语言编程。以前编写小工具可能需要先学习新语言，现在可以直接让 AI 生成。这样一来，经验丰富的架构和设计能力变得比以往更加重要，而学习新语言和技术的门槛则降低了。
这正是 AI 最擅长的——AI 擅长执行，但不擅长设计和创新。而有经验的程序员不仅拥有丰富的经验和创新能力，还在职场中磨练出了出色的沟通能力。因此，这确实对有经验的人更有利。
宝玉：不过，年长程序员也有一个潜在的劣势——接受新事物的意愿。许多 35 岁以上的程序员可能对 AI 这种新技术不太愿意接受和使用。相反，年轻人更愿意尝试新事物。
这让我想起那个被老虎追赶的故事——你不需要比老虎跑得快，只要比其他人跑得快就行，因为老虎只会吃掉跑得最慢的人。AI 的到来也是如此，关键不完全在于你的年龄。35 岁的经验确实是优势，但如果你不使用 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（下一步行动预测），记录程序员从需求到代码修改再到测试的全过程，从而训练出更好的模型。我认为这是非常值得期待的方向。
我不确定是否有公司会尝试这种方式，但如果能实现，将从根本上提升模型在编程方面的能力。我希望能看到这种突破性的尝试。
但从安全性角度来看，如果你真正关心代码安全，选择私有化方案是必然的。目前，大多数面向专业开发者的 AI 编程产品都提供了私有化部署选项。
陈鑫：确实，安全性是企业最关心的问题之一。我们发现，许多企业在采用 AI 编程工具时，首先考虑的是如何保护知识产权和代码安全。这也是为什么我们在设计产品时，从一开始就考虑了私有化部署的需求。
私有化部署不仅解决了安全问题，还能让模型更好地理解企业特定的代码规范和架构风格。这种本地化训练可以显著提升代码生成的质量和符合度。
唐小引：宝玉老师此前提到 o1 和 o1 Pro 在编程能力上的差异，许多用户对此非常关注。能否详细说明它们的区别？
宝玉：主要有几个关键差异。首先是上下文长度，这在编写代码时非常重要。o1 的上下文长度为 32k，而 o1 Pro 为 128k，这直接决定了你能输入和生成多少代码，这是一个显著且重要的区别。
其次是推理时间的差异。o1 是一个推理模型，需要思考过程。普通 o1 可能生成初稿，经过简单 review 后输出。而 Pro 版本虽然没有公开具体原理，但从结果来看，相同的提示词能得到更好的输出。根据我的经验推测，它可能采用内部投票机制，生成多个版本的代码后选择最佳输出。因此，o1 Pro 的结果确实更优。
当然，价格也相差十倍，o1 每月 20 元，o1 Pro 每月 200 元。如果你经常使用，这其实非常划算。相当于每月花 200 元雇佣一名中高级程序员，而且它还能充当顾问。因为不仅是生成代码，在设计或制定方案时，你都可以与它反复讨论。
o1 的一个限制是每周只有 50 次使用机会，这一额度很容易用完。用完后无法继续使用，会让人感到不便。这就像从 GPT-4 降级到 GPT-3.5 的感觉——用过 GPT-4 的人都知道这种落差。特别是在编程和技术咨询方面，使用 o1 后你就不想再用 GPT-4 或 Claude 了，使用 Pro 版本后更不愿受限于使用次数。这是我的使用体验，我认为对于每天编写代码的人来说，这一投资非常值得。
唐小引：还有一个用户很关心的问题：对于想学习 AI 编程的开发者，有哪些推荐的书籍资源？勤锴老师，我记得你们之前是不是出过相关的书籍？
郑勤锴：是的，我们确实出版过一些关于工具使用的书籍，主要介绍 Copilot、CodeGeeX 等工具的使用方法。不过说实话，这个领域发展太快了，很多技术都在持续更新，所以更建议大家紧跟前沿技术的发展。
张海龙：我建议多看看宝玉老师的微博和推特（https://baoyu.io/blog），他分享了很多实用的经验。
宝玉：我想分享一个很重要的观点：学习 AI 编程很像学游泳，你很难仅仅通过看书或视频就学会。你必须真正“下水”，通过实践来学习。就像编程本身一样，AI 编程也需要大量的实践经验。
使用得越多，你就会获得越多细微的感受，最终这些经验会内化成为你的技能。现在的书籍可能无法跟上最新发展，我建议看 B 站、YouTube 上的教程，特别是 YouTube 上有很多优质内容。当你想实现某个具体功能时，可以先找一个相关的视频教程看看，然后自己动手操作。
最后一个很重要的建议是：要舍得投资。至少订一个 20 块钱的 Cursor 会让你的学习事半功倍。如果总是想着用免费或者试用版，最终可能会因为效果不够好而产生挫败感，觉得这些工具没有别人说的那么神奇。但可能只是因为你没有用到最好的模型而已。
唐小引：说到投资这一点，海龙总之前提到程序员很难为自己花钱，更多依赖企业付费，您对此有什么看法？
张海龙：在我们公司，Cursor 的费用是可以报销的，我们推行全员使用 Cursor 的政策。我非常赞同宝玉老师的观点——要用就用最好的工具。这是个心理预期的问题，为了省那么一点钱，你可能错过了重要的时代红利。这是值得投资的，建议想办法说服老板给你报销。
唐小引：那要怎么说服老板呢？
张海龙：老板喜欢看代码行数，你就给他看行数。告诉他：“看，以前我一天写一百行，现在一天能写一千行了。”
陈鑫：这个领域确实发展很快，虽然国内外模型之间确实存在一些差异，但从最新一代模型来看，这个差距已经在缩小。我们更注重解决企业在实际生产中遇到的具体问题。因此，我们开发了很多有趣的功能，包括一些垂直化的能力，这些其实是海外产品没有很好解决的问题。
随着我们的产品能力和模型能力的提升，甚至在某些垂直领域的超越，我们还是很有信心的。因为这个领域的竞争才刚刚开始，就像之前大家都认为 GitHub Copilot 已经一统天下了，结果又出现了很多新的竞争者。这个赛道还有很大的发展空间，做着做着就会发现还有太多不够的地方，差得还很远。
郑勤锴：对，我觉得虽然大家现在看到国产产品和国外产品有一定差距，但请保持期待。我们正在迎头赶上，无论是模型能力还是产品体验，我们都在不断迭代。我相信总有一天我们能达到同等水平，甚至在某些方面实现超越。
“AI 会取代程序员吗？”——这个问题如今愈发令人困扰。伴随着 Cursor 等 AI 编程助手爆火，面对日新月异的技术，不少开发者感到迷茫：未来的程序员究竟该何去何从？是被 AI 取代，还是与 AI 共舞？在这个充满变革与机遇的时代，我们需要重新思考软件开发的未来。为此，CSDN 特别策划推出了最新一期特刊：《新程序员 008：大模型驱动软件开发》。
读过《新程序员》的开发者曾这样感慨道：“让我惊喜的是，中国还有这种高质量、贴近开发者的杂志，我感到非常激动。最吸引我的是里面有很多人对 AI 的看法和经验和一些采访的内容，这些内容既真实又有价值。”
能学习到新知识、产生共鸣，解答久困于心的困惑，这是《新程序员》的核心价值。欢迎扫描下方二维码订阅纸书和电子书。
（文：AI科技大本营）