聊聊AI Coding

关于AI Coding这个话题，其实一直被持续的讨论，同时相关的工具和产品都在不断的演进，包括各类的Copilot插件、集成AI的IDE以及一些Remote的AI Agent，伴随着也开始讨论AI Coding会不会替代程序员（可能Junior Engineer为主）；但是从我们当前身边的实践来看，对于AI Coding的效果和跟个人日常coding工作的结合度的情况可能会存在不同的反馈和声音，有很爽的，有爽了几次的，有一直用着但是可能也说不出滋味的，也有浅尝辄止的。

2025年5月，O'Reilly邀请了一些资深人士和技术畅销书的作者，针对AI Coding的出现以及能力的持续提升，是否会替代掉Promgramming这一职业的开放性讨论，结论可能也没出乎大家意料，都是不buy in这个观点的；笔者结合这个会议里的内容和自己的一些思考，在这里和大家分享交流下一些观点。

AI Coding的两种方式

AI Coding的方式两种，Vibe Coding和非Vibe Coding（两种方式的划分没有官方口径，只是为了方便在这里聊下Vibe Coding）。

▐  Vibe Coding

Vibe Coding，翻译是“氛围编码”（感觉蛮贴切），本质上是一种我们使用AI能力进行编码的方式，在这个模式下，我们把AI当成一个回答问题的机器，我们描述我们的诉求，让它帮我们写一段可运行的符合诉求的代码，如果产出的版本有问题（不符合诉求或者是运行错误），我们会根据相关的反馈（编译器、运行时错误、诉求差异点描述）重新调整我们的prompt，让AI进行迭代优化，直到解决问题为止，特点是我们不会深入到具体的实现以及实现涉及到的技术细节。

Vibe Coding可以帮助一个没有任何前端及前端编程语言知识的人快速搭建前端页面或者应用，这属于部分”爽到了“的人的反馈；但是在Vibe Coding也会遇到一些典型的问题，比如：

1. 你会发现，每次你的提问，它更多的是在解决整个问题的部分。
2. 它会修复一个问题，但是又会引入一个问题。
3. 它在修复一个问题的时候，会连带着变更其他部分的实现等。

但是如果你愿意持续的花时间和AI沟通，去做调整，你通过checkpoint的方式来进行不断的问题精准定位和小步调优，应该还是可以达到可执行的目标的；（当然可能也有持续交互了几天，最终放弃的）。

插图-来源O'Reilly

这种AI Coding方式的使用比较多见于非软件工程师（产品或运营）面向功能来使用AI做Coding和结果交付，或者是刚开始转型做全栈的工程师在非自身专业领域下的前期实践（后面应该还是会深入到具体技能和知识的学习中，结合专业和知识的能力使用AI做Coding，大概率不属于Vibe Coding的范畴）。

▐  非Vibe Coding

插图-来源O'Reilly

非Vibe Coding要有具体Coding的技能和对相关技术知识有一些了解（或者尝试结合AI的能力，去做快速的学习，去了解相关的language的一些原理和当前所要使用到的技术的一些细节），通过更精准的描述需求以及过程结果交付中出现问题的本质，去协同AI高效迭代和解决问题（如果你不了解，可能你连一个有价值的问题都问不出来），并且针对一些小的错误可以做手动的修改（有时候看似一个很小的问题，比如改一个样式，死活教不会，要不是连带改了很多，就是又变成啥也不改~~~），和AI进行co-programming，进而可以比较快速地去解决他的问题。

当前AI编程的能力

当前的LLM在面向一个新的功能、模块、系统，从0-1编码的能力在不断提升，因为这样的编码任务没有历史包袱，没有潜在约束，同时可以比较好的通过一些标准的评测方式去验证对错，比如编译器、单测、部署反馈等，但是对于这种在庞大的历史代码中去分析代码结构、模块、服务，然后根据需求找到变更点，并且按照当前架构设计下的原则和约束去做变更的能力还是非常不足的。

LLMs的输出本质上还是依赖用来训练它的数据，在编程领域，我们看到的好的代码的输出，包括好的规范，优雅的实现，都是基于LLMs被训练的数据的规范化和高质量，因此LLMs的编码价值在一些规范标准、类库相对集中且通用的编码语言中，能提供更好的价值。

我们在教导学生，培训实习生或者在面试应聘者的时候会考核他们从0-1编写代码的能力，但是当这些人真的进入到公司、企业岗位上的时候，他们绝大部分的时间都不是用于从0-1去编写某个模块、系统或者是平台，而是更多在做阅读、分析已有代码（可能是代码遗产），在当前的代码库中做一些调整、调试和重构，整个过程直接编码的代码量一般都不会太多；这样的现实可能也是造成大家对于AI Coding的使用体感有比较大差异的一个因素。

AI协同粒度的不同影响

同时AI Coding在我们日常迭代和协同编码中，可能会出现以下几个维度的问题，需要我们在使用的时候做关注的：

• 单个Commit中可能引入的问题：

• 会引入一些无用的代码，或者是对于需求的实现或者对于实现中出现的问题的优化解决存在问题；

• 单词需求迭代中可能引入的问题：

• 对于一些问题的解决，是靠偏“蛮力”|”硬编码“的方式在表层做解决，而不是深入分析问题之后去做根解；
• 对于需求的实现度有不足之处；
• 人和AI的协同处于摸索阶段，没有合理做好分工、协同，使得需求迭代过程变得更加复杂，会出现类似“这个还不如我自己写”这样的声音和反馈；

• 持续的协同、迭代、交付周期中可能引入的问题：

• 由于AI是基于通用类库面向功能做实现，因此基本都是“烟囱式”的，整体架构缺乏设计，在代码层面看会缺乏复用；
• 同时实现会变复杂，这里可能会出现有些封装好的服务、工具类（特指企业或公司或团队内部构建的二方库和公共基础类），都会被“忽略”，每次迭代都是不辞辛劳地0-1去做实现；
• 可维护性比较差，这里的可维护性主要是指可读性和变更成本，可读性差来源于横向设计和抽象不足，单个方法可读性不会太差，可能因为更好更合适粒度的function抽取以及更标准的命名有所提升，但是在理解整体上会表现明显不足，因为缺乏整体的层次和框架；变更成本高也是体现在一些横向变更上，单方法|单服务内部变更成本不会太明显劣势；

这些提到的可能会出现的问题，是可以被优化的，比如：

1. 我们可以更好的设计给到AI做Coding的任务；
2. 在Prompt中增加架构约束和一些规范的条目；
3. 增加内部服务的列表和说明，通过RAG的方式检索召回可以使用到的服务和方法；
4. 基于一个fundation模型做代码库的微调，帮助模型更懂当前代码库的结构、模块、内部服务等；

当然，我们上面论述基于这样一个前提，当下软件工程设计围绕的主体是“人”，那有没有可能以后整个过程是围绕“AI”来运作，所有Coding、设计和需求交付迭代都是AI来完成，那所谓理解问题、人和“AI”协同问题是否都可以认为不存在了？因为明显如果是纯AI Coding的世界里，不需要架构设计、不需要开发框架、不需要考虑复用性，因为AI能够快速理解、快速遍历、快速执行且工作量不敏感（个人认为这样的“美好”憧憬可能可以实现，但是就目前的发展来看，短期不太可能，暂且留白~~~）。

人与AI在编程领域下的区别

提升Coding with AI效果的几点建议

和AI协同的路径

AI Coding的能力是否很强？可能有一些不同的声音；AI Coding的能力是否提升很快？我觉得对于这点可能会有更多的认同；我们不用去假设或者在AI Coding现有能力到底是匹配什么level的工程师上水平寻求共识，我们应该要去做的是正确的认知AI的能力，去正确地使用它，同时需要具备面向AI做高效提问的底层认知基础，才能进行更好的协同，达到提效的效果。

开发同学要学会更好的利用好AI的编码能力，可以思考下这五个维度：

1. 需要在Context上下文中给到完整的问题描述，需要知道问题背景，不能只是给一些非常简单的描述，不然AI就会自己发挥自己的“想象力”去重新定义问题并寻求解法，开始自我发挥。
2. Research，在AI给出回答，但我们发现并不符合诉求时，我们需要更进一步的去做一些了解，不能仅仅只是粘贴问题重新扔给AI，同时附上一句类似“解决下上述问题”这样的prompt以期得到非常好的解决；更高效的做法是，对这个问题做一定的解读，可以a、针对该问题通过进一步的提问来帮助AI快速定位和解决；b、让AI基于某个方面做一些了解、参考，然后优化或修复上述问题。
3. Reframing Problems，即在了解问题真正产生原因之后，面对这个问题，以AI可以更好理解的方式重新调整问题的结构，然后让AI去做迭代处理；（重复地去强调问题的表象，AI可能会给你几乎相同的答复和处理，感觉处于绕圈圈状态 ~~~）。
4. Refine，和上面reframing有一些相似，不过这个维度更多的是突出我们通过自身知识的结合，进一步去理解问题，并且针对问题的本质去做进一步提问（比如我们看到的是一个403访问问题，但是具体看了下问题描述，知道是跨域访问的问题，那可以结合这样的洞察，重新给出问题的描述让AI去做迭代解决）。
5. Critical thinking，辩证思考，对于AI给出的答案，我们需要去判断，这个输出有用吗？有意义吗？符合你的诉求的吗？然后需要针对不足的地方进行多轮提问交互，获得最终的结果。

更好地协同AI Coding的几点建议

个人和团队在协同AI时的一些注意点

这里的建议维度分个人和团队两个，个人维度下的建议这里再稍微highlight下，主要是：

1. 我们对于AI Coding交付的结果要做好review，编码工作虽然是“外包”给AI了，但是所有的责任都还在于个人，要求和之前保持一致；
2. 找到和AI交互的比较好的任务粒度和交互、迭代提问的方式，使得结合AI Coding变成一件有价值、有效果的事；
3. 在AI不可解决（包含能力不足或者是引导未果）问题时，主动介入，分析问题，选择进一步精准交互亦或者是人为处理；

在团队层面协同AI Coding有以下三点建议：

1. 在文化和在实践上，鼓励Coding with AI的积极尝试，鼓励一些好的实践方式和心得的分享，同等对待手写代码和AI产出代码的价值付出；
2. 横向建设一些代码质量的检测工具（可以结合规则做一些AI CR，同时现有头部企业也有针对AI Coding的评测工具）；
3. 引导Stay left，not shift right with AI，对于程序员来说，就是更多的去理解需求，理解用户习惯，梳理问题域，设计合理的解决方案，构建合适的架构，做好系统及模块设计，把编写可执行的代码，类似具体的function，具体的执行逻辑，更多的交给AI去做；

程序员需要重点建设的能力建议

下面几点建议主要是基于这样一个原则-“把AI擅长做的事情交给AI做，把时间更多分配在AI不能太能做好的事情”-之上做的思考：

1. Investigative skills（问题理解和任务拆分细化的能力）

1. 有能力正确的定义遇到的问题，并且可以合理的对问题做拆解，然后定义出不同的任务；
2. 针对上述拆解下来的任务，一步步结合AI的能力去做实现和验证，如果有偏差，要做出相应的调整；

2. Evaluative skills（评估的能力）

1. 能够满足我们诉求的解决方案通常都不只有一个，因此需要有能力去评估不同方式的优点和缺点，然后结合当前的业务、资源、key person的特性去做权衡，要拒绝盲目的遵从所谓的最佳实践，因为抛开上下文的不同，只看实现，没有太多意义；
2. 针对AI给出的结果，需要有评估的能力，并且给出相应的优化调整的prompt；

3. Innovation skills（创新的能力）

1. 主动学习新的框架、技能、编程语言的能力，可以在实践中运用新颖的、更高效的解法，做一些新的创新的能力；

除了上面几点和AI使用协同相关的建议之外，程序员还是需要持续打磨自己的基本功，包括但不限于各类的语言基础，各类常用中间件的使用和原理，主流的容器和框架，不要认为很多工作被AI替代之后，我们就可以不去学习精进，我们自身的能力和认知决定了我们能协同AI的能力所能获得的价值上限。

结语

AI Coding的能力无疑是在一直快速发展和提升中，但是说“替代“，稍显过分焦虑，但如果不予理会，那也会增加被“淘汰”的可能，反差态度的现状反应了一个问题，那就是持不同观点的两拨人，是因为在当前信息输入下经过自身思考框架加工后产出的判断结果有比较大的差异，说明这是一个需要持续去探索的领域，以及值得被持续学习、深入了解的领域；因此还是需要对AI Coding这个事情保持好奇，不管是完善输入，还是优化自身的思维框架，都是很有价值。

了解AI当前的能力，以及结合当前基于LLM的生成式AI的原理了解，提前判断AI能力会在哪些方面有持续的提升，在哪些方面可能会由于本身的局限性不太能有太突出的表现，继而对自身的能力提升和后续的发展方向做一些调整和改变，努力在AI时代下打造差异化竞争力。

参考资料

• https://learning.oreilly.com/videos/coding-with-ai/0642572017171/

团队介绍

本文作者 Mario，来自淘天集团-直播技术团队。淘宝直播作为全球领先的直播电商平台，正在重新定义人与商品、人与内容的连接方式。我们致力于打造沉浸式、互动式的购物体验，让数亿用户在这里发现好货、感受乐趣。无论是时尚穿搭、美食评测，还是科技新品发布，淘宝直播都在引领电商行业的创新潮流。同时淘宝直播也在推进打造行业领先的AI数字人技术，实现虚拟主播、智能互动、个性化推荐等创新功能。

¤ 拓展阅读 ¤

3DXR技术 | 终端技术 | 音视频技术

服务端技术 | 技术质量 | 数据算法