作者 | AICon 全球人工智能开发与应用大会
策划 | 罗燕珊
编辑 | 宇琪
如今，大模型正在深刻地变革研发的各个环节，推动着自动化和智能化的发展。你有没有想过，AI是怎样从一个辅助工具，逐渐演变成核心生产力的呢？我们是否已经迎来了大模型原生开发的新时代？
最近，InfoQ的《极客有约》栏目特别邀请了平安科技的高级产品经理吴朝雄、百度的资深架构师颜志杰和汽车之家客户端架构师杜沛，在即将于2025年12月举行的AICon全球人工智能开发与应用大会北京站之前，聊聊LLM时代的软件研发新模式。
想了解更多精彩内容，别忘了查看大会日程：
https://aicon.infoq.cn/202512/beijing/schedule
以下是一些精彩观点：
-
AI在测试中的作用更多是提高效率，而不是替代人类。要实现“原生开发时代”，我们还有一段路要走，现在可以说我们只是处于“半坡”上。
-
提示词就像是在进行“角色扮演”，要让模型理解你的意图，就需要让它进入特定角色，比如“作为某领域的专家”，这样模型才能在相应的规则和业务逻辑下完成任务。
-
Coding Agent代表了通用智能体的发展趋势，这种智能体能够独立完成软件研发任务，它的潜力远超特定工具的自动化，因为它更接近人类在逻辑和物理层面的操作模式。
-
我们希望AI不仅仅是做一些演示级别的Demo，而是真正能解决产品开发中的实际需求，生成可维护性高的代码，而不是仅仅能“跑起来”的代码。
-
会用AI并不意味着结果就一定更好，而不会用AI也不代表结果就一定更差。评估的核心依然是你最终的产出与影响，而不是你在过程中的工具选择。
完整直播回放可查看：
https://www.infoq.cn/video/KGWqbzH6IKGhgoUiKDEi
以下内容基于直播速记整理，经InfoQ删减。
1 LLM 原生开发时代
吴朝雄：很多人还是觉得“AI写代码”只是一种更高级的自动补全，并不算真正的范式变革。你们怎么看呢？
颜志杰：就像“一半是火焰，一半是海水”。我们看到很多新闻，惊叹于AI的不断进步，它能完成越来越多的任务，甚至超越专业人士，带来丰厚的收益。但作为程序员，在实际开发中，特别是在已有代码的基础上进行二次开发时，AI的表现往往不如预期，有时甚至感觉它显得笨拙。所谓的“火焰”部分，指的是AI在一些比较简单、结构清晰的小任务或从零到一的创新场景中表现出色；而“海水”部分，则是面对复杂且庞大的现实任务时，尤其是在已有代码库中的应用，挑战依然很大。
对于不懂代码的人来说，只要能清晰表达自己的意图，就能借助大模型实现软件开发的能力。比如，使用“豆包”修图，已经让许多人即使不会使用Photoshop也能完成图片编辑，实现了从“不会”到“能”的飞跃。但从程序员的角度来看，AI的帮助虽然越来越明显，却距离“范式变革”还有一段距离，实际上我们正站在转折的边缘。
目前，各种AI编程产品层出不穷，不再局限于IDE，比如Devin、SWE Agent等集成在DevOps平台的Web产品，还有Claude Code等命令行工具，能够深入研发流程。一个明显的趋势是，越来越多的公司开始披露其代码中AI生成的比例，而这个比例在快速上升，部分团队甚至已经超过了50%。这意味着AI已经深入到代码生产中，团队的开发习惯和工作方式也在悄然改变。
对于非研发群体来说，这无疑是一场范式变革；而对于依赖编码谋生的程序员来说，虽然还没有完全实现变革，但趋势已经非常明显。从整体影响力和效率提升的角度来看，现在还未达到“真正的范式变革”。
杜沛：AI的使用效果因使用者的能力差异而异。在我们公司，虽然大多数人都在使用AI辅助开发，但不同人的使用深度和场景差别很大。有的人仅仅用来做简单问答或辅助编写函数，而有的人已经通过Claude Code等工具构建自己的流程化智能体，用于方案设计和代码编写。
从整体来看，开发方式确实发生了显著变化。过去我们习惯通过搜索来解决问题，而现在许多问题可以直接通过模型来处理。不同模型之间的能力差距也在迅速缩小。半年前需要花费大量时间解决的错误或兼容性问题，现在可能几分钟就能搞定。但模型本身的局限性仍然存在，这限制了我们进入真正高效智能化开发时代的步伐。
以客户端开发为例，业务的复杂度非常高。不同平台都有大量的依赖、插件和业务线，AI在这些复杂场景下的表现仍然有限。尤其在涉及3D建模等视觉任务时，大模型对视觉内容的理解仍然比较薄弱。因此，在许多复杂场景中，AI还远未达到完全可用的程度。
不过，在标准化程度高的任务上，比如文档生成、代码结构化设计等，AI的表现非常出色。如果我们能提供足够清晰的引导、上下文记忆或预处理，AI就能高效地完成工作。例如在跨端开发中，从Android迁移到iOS这样的规范性任务，AI的帮助已经相当明显。虽然AI的全面接入尚未实现，但正处于转折阶段；随着模型能力的增强，我们将越来越接近真正智能化开发的时代。
吴朝雄：测试环节是整个研发流程中最复杂、分支最多的一部分，包括接口测试、UI测试、性能测试和手动测试等，每种类型的流程都是不同的。这些流程依赖于严格的组织规范与管理体系，而这些是AI目前还无法完全替代的。
在测试领域，AI最擅长的仍然是与稳定性相关的任务，比如数据生成、数据分析和数据监控等。它可以从大量数据中抽象出通用模式，帮助测试人员解决特定节点的问题。例如在生成测试用例方面，模型在文本类内容上表现不错，特别是在需求明确的场景下。如今，许多大模型经过蒸馏和训练，已经具备了特定领域的理解能力，比如通义灵码等研发领域的模型。
然而，在更复杂的测试逻辑上，比如微服务管理和数据拓扑关联等，模型仍然力有不逮。这些环节需要人类根据经验进行判断。AI可能能够生成局部的测试用例，但无法全面覆盖关联接口和异常场景等情况。
在测试领域，AI目前仍然主要扮演辅助角色，还无法达到与开发协同的水平。与代码生成相比，测试用例更依赖于具体的业务属性。例如在金融行业，数据安全和系统复杂度非常高，模型无法全面理解这些特定要求。AI在测试中更多是提高效率的工具，而非替代方案。要实现“原生开发时代”，我们还有很长的路要走，现在不过是在“半坡”上。
颜志杰：真正的范式变革意味着从“不能”到“能”，或者在可信度和可替代性上发生质变。无论是测试还是代码开发，现在的模型仍然很难胜任复杂任务，特别是在微服务等需要深厚专业知识的场景中。虽然现在的阶段还不属于真正的范式变革，但不可否认的是，AI已经在许多细分场景中极大地解放了我们的生产力。
2 哪些开发环节已经从“人做”变成“AI做”？
吴朝雄：在我们的一线实践中，哪些事情已经从“人做”变成“AI做”了呢？
杜沛：先说说我们在代码生成方面的实践，特别是与UI设计稿相关的“Design to Code”方向。其实我们在这方面起步较早，早在2023年AI刚崭露头角时，我们就开始尝试了。但那时模型的能力有限，常常出现“幻觉”，生成一些并不存在的内容。
随着多模态模型的出现，我们看到了新的突破点。过去在开发中，页面的复杂度会直接影响模型的生成效果。页面信息越多，模型越容易选择性遗忘，遗漏部分细节。多模态模型引入图像理解后，情况有了显著改善。我们尝试了Claude、豆包等多种方案，发现图像能够帮助模型更好地理解UI的意图。例如，某个按钮是“登录”还是“分享”，某个区域是“Banner”还是“列表”，这些原本隐含的交互信息通过图像理解能够被模型更准确地识别。
在此基础上，我们将图像理解与设计稿解析结合了起来。目前我们内部使用MasterGo，通过解析设计文件提取关键信息，并反复加权强化这些要点，减少噪音的干扰。这一方法在实际应用中取得了不错的效果。从结果来看，我们的代码生成可用度已经能达到80%到90%。我们还进行了多轮跟踪测试，验证了它对整体效率的提升。但这并不意味着人力投入就能减少到10%。因为模型生成的内容仍需人工复核，例如对像素级别的比对和界面验收等环节，依然需要人工严格检查。
我们在规范和记忆机制上进行了大量优化，使生成的代码更符合人类的开发习惯。同时，我们还探索了多端代码转换，这部分逻辑规则相对清晰，比如在一端验证通过的逻辑可以迁移到另一端，只需调整链路即可，这类任务AI处理得相当不错。例如，在H5、小程序或不同框架间的迁移中取得了良好效果。AI的代码生成质量可以达到70%以上，但由于后续仍需人工进行代码审查与规范验收，整体提效约可达原来的1.5倍。
与传统自动化工具相比，AI的优势在于在处理大规模工程项目时，能够更快地定位、规划和生成逻辑，不再需要耗费数小时甚至数天进行分析。在代码审查方面，过去我们依赖静态扫描或动态分析，而如今AI可以结合规范进行自动检测。只要设定好规则，AI就能识别潜在问题。通过这种双重机制，我们显著减少了测试阶段的bug数量，下降幅度可达30%到40%。虽然目前尚难以精确评估线上bug的减少幅度，但测试阶段的改善已经非常明显。
总体而言，这三个场景是我们在开发环节中最具代表性的AI应用。它们共同的特点是流程规范、任务可分解、结构化程度高。通过前期规划、阶段性检查和动态学习，可以显著提升整体开发效率。
AI的崛起：如何改变我们工作方式的故事
颜志杰：说到AI，它最擅长的就是处理那些重复又机械的任务。以前我们用自动化工具来完成这些工作，但总有些地方自动化帮不了忙。不过现在，AI正好填补了这些空白。拿我们团队的“文心快码”项目来说吧，我们要同时维护中英文的前端代码。过去这得人工分别搞定，现在我们设定一些规则，AI就能自动帮我们把中文版本转成英文。只要开发好中文的，AI就能轻松搞定英文版本，还能进行验证和单元测试。这种事情以前靠自动化很难实现，但现在AI能做到高效、稳定、精准。
接着，回到我之前提到的那个比喻：“一半是火焰，一半是海水”。AI在0到1的创造性任务上尤其出色。比如生成脚本或原型开发，这些东西不直接上线，但需要迅速验证想法。在这一点上，AI可以显著提升生产效率，让程序员把时间花在更复杂的任务上。此外，非技术人员如产品经理也能通过草图和自然语言生成原型，促进沟通与合作。这种变化，实际上已经彻底改变了我们的开发流程。
所以说，在0到1的“火焰”场景中，AI的潜能得到了充分展现。像Figma to Code这样的应用也属于这类相对简单的领域，因此AI在这些地方最先实现了高效应用。
至于生成测试用例，举个例子吧。当我在写接口测试用例时，如果只针对单个接口进行测试，就不需要绑定所有外部依赖，直接验证接口的输入和输出是否正确就行了。这种情况下，AI的表现确实很不错。当我们讨论“哪些事情从人做变成了AI做”时，我觉得可以从DevOps或者自动化的角度来看：哪些任务过去靠人工或传统自动化无法完成，而现在借助AI就能实现？重新梳理整个研发流程，我们会发现很多环节都能与AI的特长精准对接，这正是AI替代人工的关键所在。
吴朝雄：大模型的优势在于它能够生成多样化的数据和内容，这使得它特别适合用于数据构造或内容生成，比如常见的文档润色。这些任务的模式比较固定，AI轻松就能处理。以我熟悉的自动化测试为例，过去人力主要负责生成和调试接口用例，而现在AI在这方面发挥了很大的作用。
在简单的接口测试中，我们关注的通常不是背后的业务逻辑，而是接口能否正常运行。无论采用什么模型，这种测试都能完成。AI可以自动生成部分输入数据，当然人工也可以手动构造，但复杂度就不一样了。当测试的对象是复杂接口时，情况就大不相同了。
在我们公司内部，许多接口都需要数据安全管控，涉及身份验证或依赖上下游数据。一个接口通常依赖多个服务或数据库操作，光凭简单的输入参数是无法完成测试的。为了实现自动化，必须先执行数据库查询、预置数据，然后再调用接口。这种场景对编排逻辑的要求非常高，需要清晰的流程设计和强大的脚本能力。
以前人工编写脚本常常出错，导致逻辑混乱、结构复杂，很多时候脚本无法执行。而现在，模型能够理解数据库的限制、接口逻辑、参数定义和场景需求，自动组装上下文和执行逻辑，从而生成可运行的测试脚本。
目前在我们公司内部，通过共建和推广模式，我们把这项AI自动化能力推广到了各个子公司，用例数据的生成覆盖率已经达到60%左右。过去人工编写的测试脚本常常出现逻辑漏洞或断言错误，而现在模型在理解接口文档、参数含义、代码逻辑及数据库结构后，能够自动判断应先落库还是先查询数据，从而生成更合理的执行流程。
举个例子：以前人工编写复杂接口的自动化测试脚本，通常需要一小时到半天不等，成本高且重复劳动多。而现在通过模型生成，只需几分钟就能完成可执行用例，后续只需稍作调整，大大降低了人力投入。
我们现在的目标是实现用例生成到调试、评审、执行、诊断和报告生成的全流程自动化。这不仅需要多个代理协同工作，还需要系统级的流程编排。我们的基础能力已经初步搭建，计划在明年底前实现完整的全流程自动化编排体系。
这将帮助我们跨越“原生时代”的技术墙，实现从辅助到自主的转变。过去测试人员需要思考如何设计用例，而未来他们只需关注“测什么”，也就是业务场景是否被充分覆盖。AI将承担繁琐的设计和实现部分，让测试人员转型为质量架构师，专注于更高层次的质量保障与体系设计。
吴朝雄：当AI开始写代码、生成测试和数据，真正进入业务后，最先遇到的是什么问题？是稳定性、幻觉、规则不理解，还是团队不敢使用？
颜志杰：目前最大的问题在于AI的效果不够稳定。当AI带来的收益不足以抵消改变原有工作习惯的成本时，落地就会变得很困难，因为这种改变往往违背人性和直觉。尤其是当人们尝试改变习惯后发现效果依然不确定，那就更难以推广和落地。因此，关键的问题是“稳定的效果”。例如在早期的Copilot模式中，AI用于代码续写或生成测试用例，对开发者的使用习惯影响不大，而且确实带来了一定的收益。因为相比传统的基于规则的补全，AI的补全更智能，所以这种落地相对容易。
但现在流行的SPEC模式却复杂得多。开发者需要先进行需求澄清，不再是自己直接写代码，而是要通过与AI的自然语言交互来逐步实现。尤其是在大型存量代码库中，AI很难处理如此庞大的上下文。有时候它能正确修改，但更多时候，即使找到了问题，也会以不合逻辑的方式进行修改。例如，本该复用的函数却被重复生成，或者日志库被莫名替换。这些问题都让实际落地变得困难。
因此，我们需要承认当前AI仍缺乏稳定性。如果要务实推进落地，应该从小任务开始，而不是寄希望于“一句指令解决所有问题”。有时候一句话对人来说都未必能准确表达，更何况对模型。即使SPEC写得再好，也不能保证模型完全遵循逻辑。模型偶尔会“抽风”，即使明确要求它不做某事，它仍可能执行。
所以我认为应像传统软件开发那样，从小任务和类工建设入手，写好文档、做好设计，逐步扩大任务规模，探索人机协作的边界。随着信任与方法的积累，AI能够承担的工作比例会逐渐提高，落地过程也会更加稳健。这是我对这个问题的理解和建议。
杜沛：这实际上是“信任建立”的问题。尤其是在初期使用时，例如在IDE中输入需求，十次问答AI可能有两次不准确。用户往往会记住那两次失败的经历，因为那意味着额外的时间成本——要反复提问、修正，甚至多次出错，从而降低信任。在工具推广中，这种稳定性和容错机制尤为关键。如果AI的结果不稳定，用户信任的建立就会变得非常困难。
算力问题也是一个不可忽视的因素。算力不仅影响能力，也影响使用体验。模型响应越快，用户对错误的容忍度就越高。比如，如果生成时间从两分钟降到十秒，即使结果出错，试错成本也低；但如果等待五分钟却仍出错，用户体验就会非常糟糕，负面反馈也会增多。
从数据来看，AI使用率差异很大：有的用户AI参与率能达到50%，而有的则不足10%。我们分析发现，很多低效使用者的问题在于提示词过于简单，只给出一个关键词或一句模糊的话，导致模型误解意图，输出偏离目标。这种不当使用也加剧了体验差距。
我们常常收到反馈说“AI生成结果不对”，但很多时候问题在于输入模糊。因此，我们尝试在相同项目中预置模板或规范，提前定义依赖和规则，以减少AI发散造成的偏差。
观众：用好AI进行研发，对人员的能力模型应该是什么样的？
吴朝雄：以测试领域为例，首先面临的问题就是“提示词工程”的理解。作为产品经理，我常常对接测试需求方，发现他们在使用我的AI工具或自动化测试平台时，往往在提示词能力上存在明显短板。
在我看来，提示词工程的概念类似于“用户故事”。从产品的角度来看，一个完整的用户故事需要把需求讲清楚，包括什么角色、什么场景下，要解决什么问题，达成什么目标。提示词也是如此，应包含角色、场景、目标、任务等元素。提示词实际上是一种“角色扮演”，你要让模型理解你的意图，就得让它进入特定角色，比如“作为某领域的专家”，让模型在特定规则和业务逻辑下执行任务。
要让大模型正确理解你的指令，关键在于输入的结构要足够严谨、颗粒度足够细。例如定义“角色”时，要明确是产品实习生、助理、高级经理还是总监。不同角色的视角不同，模型的解读结果也会不同。因此，第一个重要能力是写好提示词，而这需要持续的刻意练习与训练。
第二个关键能力是“知识工程”。在研发领域，要让模型真正理解业务、帮助推动业务，就必须让它熟悉组织的知识体系。例如团队的流程规范、协作规范、人员管理、度量标准等。这些虽然在现实中可能以默认规则存在，但对模型来说，必须整理成明确的文档，让它能够学习和引用。因此，使用AI的人需要具备撰写清晰、可拆解、可被模型理解的知识文档的能力。要为模型提供一套公开、可参考的方案，让它能基于这些资料进行模拟与推理。模型最擅长的不是从“无”到“有”的创新，而是基于已有知识进行“有到有”的推理。
颜志杰：对于想要变得优秀的人来说，现在是个最糟糕的时代，因为你原有的技能一个都不能丢。AI还没有彻底改变工作方式，该懂代码的依然要懂代码；但同时这又是最好的时代，因为门槛变低了。很多过去需要投入大量精力的工作，现在借助AI就能高效完成。那些原本不会编程的人，只要善用AI，效率甚至能超过传统开发者。所以，关键在于你如何看待这个时代、如何定义自己想成为的人，再去决定你的能力模型和发展路径。像提示词工程、知识工程等能力，都是不可或缺的。
吴朝雄：就像测试工作一样，要让模型理解你的规范，首先得把知识沉淀下来，而这些沉淀必须来自实际的业务经验，而不是AI自己生成的。这些业务实践包括用例管理规范、代码管理规范、用例设计方法、代码设计原则等，都是研发人员必须掌握的基本知识。在此基础上，再去学习和掌握AI相关的技术栈，并思考如何将这些技术与业务场景结合。要真正用好这些技术，就需要投入时间去理解、消化，并在实践中不断优化。
观众：现在大模型应用的技术栈主要是Java或Python，百度内部使用的是什么技术栈？
从 AI 助手到智能体：未来开发的新趋势
颜志杰：我觉得，模型的技术栈和百度内部所用的技术栈其实没有直接的关联。比如说，搜索相关的程序可能是用 C++ 写的，而云端的程序则更偏向用 Golang。不过，它们的角色是不同的，一个是负责模型的生产，另一个则是模型的实际应用。究竟用什么语言来实现模型，并不会影响应用方选择什么语言来调用或者整合。对于应用方来说，无论这个模型是用来补全 Golang、Java 还是 Python 的代码，最终效果在现有模型体系下基本一样。
4 从“工具”到“协作者”
吴朝雄：最近我发现一个很明显的趋势，行业似乎正在从“AI 助手”向“智能体协作”转变。根据你们的经验，哪些事情是以前的 AI 助手无法做到，但智能体却能胜任的呢？
杜沛：我认为，最大的不同点在于“闭环能力”。AI 助手往往只是提供单点帮助，而智能体则能够将整个开发、测试和审查的流程连接起来。具体来说，它可以从人手动编写代码，到 AI 自动生成，再到 AI 进行测试，最后人来审查和核对结果。这个方向毫无疑问是未来的发展趋势，也是一种理想的人机合作模式。AI 参与代码编写的关键在于如何确保生成代码的质量，特别是在业务开发中要满足逻辑性和可靠性。
我们希望 AI 不仅仅是做一些演示，而是真正能够满足产品开发的实际需求，输出可维护性高的代码，而不是那种仅仅能“跑起来”的代码。假如生成的代码逻辑混乱或难以理解，后续的维护人员就得重新阅读和分析，这无疑会增加他们的负担。因此，AI 生成的代码必须符合人类开发者的接受标准，确保逻辑清晰、约束合理，这样才能真正降低人力成本。
在测试环节，AI 测试与传统人工测试的侧重点也有所不同。传统测试主要关注结果的正确性，而 AI 测试由于缺乏完整的运行环境，不能直接判断结果是否正确。因此，需要为 AI 提供一个运行环境，帮助它验证代码的构建是否通过、语法是否正确、边界条件是否覆盖等。对于复杂应用，特别是在移动端，还需在真实设备上进行测试，这无疑增加了难度和成本。AI 测试不仅要停留在静态分析上，还应该延伸到动态运行状态的测试，才能形成更完整的闭环，确保从产品逻辑、代码质量到运行结果的多维保障。
如果这个体系能够实现动态测试闭环，AI 将能更好地推动整个开发流程，提升智能体验。这种模式的理想状态高度依赖于大模型的能力。目前出现的“世界模型”虽然主要应用于机器人，但未来也可能在软件开发与测试中发挥作用。如果模型不仅能理解文本或静态图像，而是结合视频、操作行为、屏幕显示等多模态信息进行判断，那么开发流程将迎来质的飞跃。
吴朝雄：你提到研发流程将由智能体协作来完成。比如，人只需输入开发意图，后续的代码生成和自测都由 AI 完成，最后只需人来审核。如果你们团队想要大规模推动这种流程的落地，还需要多长时间呢？
杜沛：从目前来看，这个目标短期内很难完全实现。按照我的预期，要真正打通流程、形成闭环，至少还需一年以上的时间。
颜志杰：AI 助手向智能体的演变，实际上是从“动脑、动嘴”升级到“动脑、动手、动嘴”的阶段。AI 助手主要负责思考和语言交互，而智能体则具备更强的自主执行能力。在研发领域，像 Devin 或 SWE Agent 就体现了这种转变。它们不再局限于 IDE 环境中的问答式交互，而是能在 DevOps 平台上自动执行任务，比如代码生成、测试、验证、提交 PR，甚至在发现问题后能自动修复并反馈结果。
这种模式展示出了类人的逻辑链条：先观察，再推理，再行动，并持续感知环境变化。它不仅仅是一个“口头助手”，而是能在异步环境中独立运作的执行体。过去，依赖语言交互的助手无法完成端到端的任务，比如自动修复 bug、补全测试用例、执行调试与代码审查，而智能体则能通过自主推理与操作实现这一切。这正是智能体强大的核心，也是未来十年的关键方向。
Coding Agent 代表了通用智能体的发展路径，这种能够独立完成软件研发任务的智能体，其潜力将远超特定工具层面的自动化，因为它更接近人类在物理与逻辑层面的行动模式。
吴朝雄：智能体未来会走向统一的大平台，还是轻量化、插件化的生态？如果你们公司在研发类似产品，会倾向哪种形态呢？
颜志杰：在当前模型能力的限制下，我更倾向于发展轻量化、插件化的生态。研发场景是一个极其严谨的科学过程，需要成熟的流程来保障质量与协作。贸然构建“大一统平台”既不现实，也容易脱离实际。更合理的方式是让 AI 以插件形式逐步融入现有的软件研发体系，先观察它在各个环节能带来多少改进。当 AI 能稳定接管 50% 以上的流程后，再谈平台化整合才是有意义的。毕竟，模型本质上是概率系统，稳定性仍需时间和经验的积累来优化。如果许多关键环节仍需人工介入，就不应追求“全能平台”的虚高目标。
吴朝雄：研发流程不仅涉及工具链，还包括人与项目之间的协作逻辑。这些协作往往在工具层面难以完全体现。目前的智能体更多集中在解决单点问题，比如帮助开发者发现或修复 bug。但在 DevOps 层面，未来可能会出现更高抽象层次的 AI 工作台，将数据检索、任务调度、执行分析等能力整合在一起。
例如，JIRA 已开始探索 AI 工作台，通过整合 DevOps 数据来实现项目进度追踪、代码库检索、任务完成情况分析、研发效能评估等功能。虽然目前仍以 AI 搜索为主，但雏形已经开始显现。国内大多数产品仍停留在单点智能体阶段，尚未形成上层封装或生态体系。插件化生态仍是当下最稳妥、最现实的探索方向。
观众：程序员使用 AI 编写代码，如何通过代码质量为程序员打分，有什么参考指标来进行绩效考核呢？
颜志杰：目前几乎没有哪家公司会直接把“是否使用 AI 编码工具”或者“AI 生成代码的比例”明确写进绩效考核体系中。原因很简单：大家普遍还是把 AI 当作一个工具，它的意义在于提升效率，而不是用来评估个人的好坏。毕竟，AI 生成代码的“量”与开发者真正的“质”之间差距很大，代码多并不代表质量高，也不意味着问题少。现在确实有很多公司会自上而下推动使用，比如用强制或激励的方式去推广 Code Engine 类工具。
目前也还没有出现“因为不使用 AI 而被扣分”的考核体系。唯一我听说比较激进的案例是 Shopee，他们据说在绩效考核中已经纳入了一些与 AI 使用相关的指标，但具体细节我还没深入了解。我的理解是，这更多是鼓励机制，比如“用得好、效果显著的人会得到奖励”，而不是“用得不好就会被惩罚”。毕竟，使用 AI 少并不意味着你的产出不好。
我们在内部推广 AI 工具时，也遇到过类似的问题。有开发者会问：“如果我用 AI 生成的代码出现 bug，这责任算谁的？是我、AI，还是团队？”其实这个逻辑并不成立。你从网上复制一段开源代码，也没人会因此说那部分不是你写的。同理，AI 工具只是一个辅助来源。目前我们团队在绩效体系中完全没有针对 AI 使用或代码质量的直接考核项，因为从逻辑上来说，这两者并不能画等号。会用 AI ≠ 结果更好，不会用 AI ≠ 结果更差。考核的核心依然是最终的产出与影响，而不是过程中的工具选择。
杜沛：我们会做一些“正向鼓励”，比如内部表扬或展示用 AI 提升效率的好案例，但不会强制，也不会把它和绩效挂钩。其实，如果绩效中写“必须用 AI”，反而会产生反效果，可能大家为了应付指标而“假用 AI”，形式化操作，反而偏离了提升效率的初衷。所以我们更倾向于通过文化引导，而不是考核来推动 AI 的普及。
吴朝雄：许多人听到 AI 进入研发流程，第一反应是“那我是不是要被替代了？会影响我的收入吗？”但事实上，AI 更像是一种角色转变的工具，而不是替代的力量。拿测试岗位来说，AI 确实能帮助自动生成用例、发现缺陷、分析日志，但测试岗位并不会因此消失，而是转向更高层次的工作，比如验证业务逻辑、优化测试策略、整合分析数据等。AI 带来的不是岗位的消亡，而是岗位价值的重塑。开发和测试的工作也因此变得更加策略性和创造性。
5 价值与人
吴朝雄：在未来两年，哪类工程师的价值会被放大？为什么？
过去，编写自动化测试脚本往往需要人工手动完成，这样成本很高，复杂的脚本可能需要耗费数小时甚至半天时间才能写好，因为要实现一个完整功能测试往往涉及多个请求。以往，测试人员主要考虑如何设计一个准确、可用、能够反映业务功能的测试用例。而现在，AI 在很大程度上已经突破了“用例设计”这一难题。原因在于，AI 能直接利用详细的代码和需求文档来生成。
举个例子，在接口自动化测试中有接口文档，而在 UI 自动化中则有页面组件信息，这些元素都可以在前期进行沉淀。团队只需做好这些准备，后续在设计测试方案或测试用例时，就不需要耗费大量时间去思考脚本逻辑的构建，而是更关注测试本身的价值最大化。
重点转向“测什么”，也就是每个版本中要验证的代码与功能点。这才是测试人员更专业的部分。AI 的引入并不意味着可以不懂代码，反而要求更精通代码。类似的，产品经理的角色也在发生变化。以前，产品经理只需清楚表达逻辑，而如今如果希望模型辅助完成上下游流程，就必须将功能性和非功能性需求描述得清楚，并具备对系统架构的理解。未来，产品经理不仅要懂业务逻辑，还需熟悉技术架构与系统关系。单纯掌握局部需求的产品经理将可能被替代，因为模型能够根据业务逻辑生成出漂亮的需求文档。而那些具备综合竞争力、能够从全局视角解决问题的产品经理，将更具不可替代性。
如果一个产品经理既懂技术，又懂业务与测试，即使在每个领域不算精通，但具备全面理解，就能在向下游输出内容时发挥不可替代的作用。实际上，AI 的出现让产品角色变得愈加重要。随着自动化程度的提高，下游环节反而更依赖于产品的决策与协调。同样，对于其他岗位也是如此。以前端为例，基础的页面组件如今模型都能自动生成。但如果前端工程师同时理解后端逻辑与算法，就具备独特的竞争力。这种价值不在于页面是否好看，而在于对性能、架构以及前后端交互的整体把控。
掌握AI时代的核心竞争力，提升个人价值
当你能够从系统架构的角度来考虑设计问题，拥有全面的技术思维，这种能力是AI无法替代的。因为你不仅仅会写代码，更懂得团队整体架构的运作。AI的兴起让知识学习变得更深入，同时也推动各个角色从单纯的“执行者”转变为“评估者”或“决策者”。当你的能力增强、知识扩展、角色升级，你的个人价值自然也会水涨船高。
这种转变并不只发生在产品岗位，实际上所有的职位都在经历类似的变革。AI在研发领域的普及，突显了具备高水平技能的人才，而仅仅掌握基础技能的人则可能会被淘汰。要想彰显自身的价值，展现出你的核心竞争力至关重要。这不仅包括如何使用AI的能力，还需要有扎实的基础知识。
颜志杰：那些能够熟练运用AI的人，往往像优秀的架构师。架构师的重要性在于他们能清楚理解业务的边界和限制。虽然AI在处理小任务方面表现得相当出色，但在系统设计、分层和异常处理等方面，还是需要架构师来进行把控。AI无法承担系统的全面责任，因此架构师在更高层面统筹全局的能力显得尤为重要。
接下来，我们得说说协作能力。就算使用的是同款AI，有的人效率却能比其他人快五到十倍，这到底是怎么回事呢？关键在于是否能清晰地向AI表达任务，让模型真正理解你的意图。这其实不仅是一种思维能力，更是一种“放大效应”。
第三，持续学习和创新的能力也不可忽视。我们需要理解“如何做”和“为什么做”，因为技术更新的速度快得惊人，今天的技术明天就可能被取代。我认为最重要的能力是“品味”，这就像艺术领域的审美判断一样。未来，随着AI供给的丰富，真正能体现个人差异的，将是对产品“应该成为什么样”的判断力。就像乔布斯设计手机时所展现出来的那种独特感知。优秀的产品设计需要这种品味与调性，而这正是产品经理不可或缺的价值所在。
杜沛：虽然AI是基于概率的模型，但如果想真正把它用好，就必须理解它的工作原理和局限性。虽然我们不能直接去训练模型，但掌握高效使用的技巧能大大提升我们的工作价值。例如，全栈工程师的价值可能会更高。过去，想要精通多种编程语言几乎是不可能的，但现在借助AI，一些曾经难以完成的任务也能实现，甚至可能做得更好。
举个例子，前端工程师以前需要依赖数据分析师来完成数据查询，而如今借助AI，通过日志查询平台就能迅速生成SQL查询，无需他人协助。这种方式显著拓宽了个人能力的边界，让工作成果得以放大。只要你能善加利用AI，让它真正帮助你解决过去无法完成的任务，你的价值自然会提升。
正如之前提到的，AI在研发中的作用目前主要体现在提升效率上，但这只是阶段性的成果。未来，随着模型的不断演变，输入的方式将不再局限于文本，还可能涵盖视觉、听觉等多种信息形式，届时能够实现的功能将会更加丰富。只要你能真正利用好AI，让它为你所用，你的能力与价值就会被放大，而不再取决于你是哪一类工程师。
会议预告：
12月19日至20日，AICon 2025年度收官站将在北京举行。两天的时间里，我们将探讨Agent、上下文工程、AI产品创新等热门话题，与顶尖企业和创新团队的专家深入交流经验与思考。这是2025年的最后一场会议，绝对不容错过！
