大模型正在深刻改变研发流程的各个环节，推动自动化与智能化。辅助编程、Coding Agent……AI 是如何从“辅助工具”变成核心生产力的？大模型原生开发时代到来了吗？

近日 InfoQ《极客有约》X AICon 直播栏目特别邀请了平安科技高级产品经理吴朝雄、百度资深架构师颜志杰和汽车之家客户端架构师杜沛，在 AICon 全球人工智能开发与应用大会 2025 北京站（12 月）即将召开之际，共同探讨 LLM 时代的软件研发新范式。

部分精彩观点如下：

• AI 在测试中更多是提效工具，而非替代方案。距离“原生开发时代”还有相当距离，现在只是走在“半坡上”。
• 提示词其实是一种“角色扮演”，你要让模型理解你的意图，就要让它进入特定角色，比如“作为某领域的专家”，让模型在特定规则与业务逻辑下执行任务。
• Coding Agent 代表了通用智能体的发展路径，能独立完成软件研发任务的智能体，其潜力将远超特定工具层面的自动化，因为它更接近人类在物理与逻辑层面的行动模式。
• 我们希望 AI 不只是做演示级别的 Demo，而是真正能满足产品开发的实际需求，产出可维护性强的代码，而不是仅仅能“跑起来”的代码。
• 会用 AI ≠ 结果更好，不会用 AI ≠ 结果更差。考核的核心仍然是你最终的产出与影响，而不是过程里的工具选择。

以下内容基于直播速记整理，经 InfoQ 删减。

1 LLM 原生开发时代

吴朝雄：很多观点还是认为“AI 写代码”只是更高级的自动补全、不算范式变革。你们怎么看？

颜志杰：“一半是火焰，一半是海水”。我们看到各种新闻时，会惊叹于 AI 的不断进化，它能完成越来越多任务、击败专业人士、甚至带来可观收益。然而，作为程序员，在实际开发中，尤其是在多年积累的代码基础上进行开发时，常常会发现 AI 并没有想象中那么“神”，有时甚至显得笨拙。所谓“火焰”的部分，是指 AI 在一些相对独立、结构清晰的小任务或 0 到 1 的创新场景中表现突出；而“海水”的部分，则是复杂、庞大的现实任务，尤其是在已有代码库中落地时，挑战依然巨大。

对于不会写代码的人，只要能清楚表达意图，就能借助大模型具备软件开发的能力。举个例子，用“豆包”修图已经让很多不会用 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% 以上，但由于后续仍需人工进行 code review 与规范验收，整体提效约可达原来的 1.5 倍。

相比传统自动化工具，AI 的优势在于处理大规模工程项目时能更快定位、规划和生成逻辑，不再需要耗费数小时甚至数天运行分析。在代码审查方面。过去我们依赖静态扫描或动态分析，如今 AI 可以结合规范进行自动检测。针对不同技术栈、不同项目场景，只要设定好规则，AI 就能识别潜在问题。通过这种双重机制，我们显著减少了测试阶段的 bug 数量，下降幅度可达 30%–40%。虽然目前还难以精确评估线上 bug 的减少幅度，但测试阶段的改善已经非常明显。

总体来说，这三个场景是我们在开发环节中最具代表性的 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% 左右。过去人工编写的测试脚本常出现逻辑漏洞或断言错误，而现在模型在理解接口文档、参数含义、代码逻辑及数据库结构后，能自动判断应先落库还是先查询数据，从而生成更合理的执行流程。

举个例子：以前人工编写一个复杂接口的自动化测试脚本，通常需要一小时到半天不等，成本高且重复劳动多。现在通过模型生成，只需几分钟即可完成可执行用例，后续仅需微调即可，大大降低了人力投入。

我们目前的重点是实现从用例生成到调试、评审、执行、诊断、报告生成的全流程自动化。这不仅需要多个 agent 协同，还需系统级的流程编排。我们的底层能力已初步搭建，计划在明年底前实现完整的全流程自动化编排体系。

这将帮助我们真正跨越“原生时代”的技术壁垒，实现从辅助到自主的转变。过去测试人员需要思考如何设计用例，而未来他们只需关注“测什么”，也就是业务场景是否被充分覆盖。AI 将承担设计和实现的繁琐部分，让测试人员转型为质量架构师，从事更高层次的质量保障与体系设计。

3 AI 落地研发最先撞墙的是什么

吴朝雄：当 AI 写代码、写测试、生成数据，真的进入真实业务后，最先撞墙的是什么？是稳定性？幻觉？规则不懂？还是团队不敢用？

颜志杰：目前最大的问题在于 AI 的效果缺乏稳定性。当 AI 带来的收益不足以抵消改变原有工作习惯的成本时，落地就会变得非常困难，因为这种改变往往“反人性”、也“反直觉”。尤其是当人们尝试改变习惯后，发现效果依然不确定，那就更难推广与落地。因此，关键问题在于“稳定的效果”。比如在早期的 Copilot 模式中，AI 用于代码续写或测试用例生成，对开发者的使用习惯影响不大，而且确实带来了一定收益。因为与传统基于规则的补全相比，AI 的补全更智能，所以这种落地相对容易。

但现在业界流行的 SPEC 模式却更复杂。开发者需要先进行需求澄清，不再是自己直接写代码，而是要通过与 AI 的自然语言交互逐步实现。特别是在大型存量代码库中，AI 很难处理如此庞大的上下文。它有时能正确修改，但更多时候虽找到了问题，却以不符合逻辑的方式修改。例如，本该复用的函数被重复生成，或日志库被莫名替换。这些问题都让实际落地非常困难。

因此，我们需要承认当前 AI 仍缺乏稳定性。若要务实推进落地，应从小任务开始，而非寄望“一句指令解决所有问题”。一句话对人来说都未必能准确表达，更何况对模型。即使写好了 SPEC，也不能保证模型完全遵守逻辑。模型偶尔会“抽风”，即便明确要求它不做某事，它仍可能执行。

所以我认为应像传统软件开发那样，从小任务、类工建设入手，写好文档、做好设计，逐步放大任务规模，探索人机协作的边界。随着信任与方法的积累，AI 能承担的工作比例会逐渐提高，落地过程也会更加稳健。这是我对这一问题的理解与建议。

杜沛：这实际上属于“信任建立”的问题。尤其在初期使用时，例如在 IDE 中输入需求，十次问答 AI 可能有两次回答不准确。用户往往会记住失败的那两次，因为那意味着额外的时间成本——要反复提问、修正，甚至多次都错，从而降低信任。在工具推广中，这种稳定性与容错机制尤为关键。如果 AI 结果不稳定，用户信任的建立就非常困难。

算力问题也是一个重要因素。算力影响的不仅是能力，还有使用体验。模型响应越快，用户容忍错误的意愿就越高。比如从原先 2 分钟的生成降到 10 秒，即使结果出错，试错成本也低；但若等待 5 分钟仍出错，用户体验就会极差，负面反馈也更多。

从数据来看，AI 使用率差异巨大：有的用户 AI 参与率能达到 50%，有的不足 10%。我们分析发现，很多低效使用者的问题在于提示词太简单，只给出一个关键词或一句模糊话，导致模型误解意图、输出偏离目标。这种不当使用也加剧了体验差距。

我们常收到反馈称“AI 生成结果不对”，但很多时候问题在于输入模糊。为此，我们尝试在相同项目中预置模板或规范，提前定义依赖与规则，以减少 AI 发散造成的偏差。

观众：用好 AI 做研发，对人员的能力模型是什么样的？

吴朝雄：以测试领域为例，首先面临的问题就是“提示词工程”的理解。作为产品经理，我经常对接测试需求方，发现他们在使用我的 AI 工具或自动化测试平台时，往往在提示词能力上存在明显短板。

在我看来，提示词工程的概念类似于“用户故事”。从产品视角来看，一个完整的用户故事需要把需求讲清楚，包括在什么角色、什么场景下，要解决什么问题，达成什么目标。提示词也是如此，应包含角色、场景、目标、任务等元素。提示词其实是一种“角色扮演”，你要让模型理解你的意图，就要让它进入特定角色，比如“作为某领域的专家”，让模型在特定规则与业务逻辑下执行任务。

要让大模型正确理解你的指令，关键在于让输入的结构足够严谨、颗粒度足够细。比如定义“角色”时，要明确是产品实习生、助理、高级经理还是总监。不同角色视角不同，模型的解读结果也会不同。因此，第一个重要能力是写好提示词，而这需要持续的刻意练习与训练。

第二个关键能力是“知识工程”。在研发领域，要让模型真正理解业务、帮助推动业务，就必须让它熟悉组织的知识体系。例如团队的流程规范、协作规范、人员管理、度量标准等。虽然这些在现实中可能以默认规则存在，但对模型来说，必须被整理成明确的文档，让它能够学习和引用。因此，使用 AI 的人需要具备撰写清晰、可拆解、可被模型理解的知识文档的能力。要为模型提供一套公开、可参考的方案，让它能基于这些资料进行模拟与推理。模型最擅长的不是从“无”到“有”的创新，而是基于已有知识进行“有到有”的推理。

颜志杰：对于想要变得优秀的人来说，这是最坏的时代，因为你原有的技能一个都不能丢。AI 还没有彻底改变工作范式，该懂代码的依然要懂代码；但同时这又是最好的时代，因为门槛变低了。很多过去需要花费大量精力的事情，现在借助 AI 就能高效完成。那些原本不会编程的人，若能善用 AI，效率甚至能超过传统开发者。因此，关键在于你如何认知这个时代、如何定义自己想成为的人，再去决定你的能力模型和发展路径。像提示词工程、知识工程等能力，都是不可或缺的。

吴朝雄：就像测试工作一样，要让模型理解你的规范，首先要把知识沉淀下来，而这些沉淀必须来自实际业务的经验，而不是由 AI 自己生成的。这些业务实践包括用例管理规范、代码管理规范、用例设计方法、代码设计原则等，都是研发人员必须掌握的基本知识。在此基础上，再去学习和掌握 AI 相关技术栈，并思考如何将这些技术与业务场景结合。要真正用好这些技术，就需要投入时间去理解、消化，并在实践中不断优化。

观众：现在大模型的应用的技术栈都是 java 或者 python 的，百度内部使用的什么技术栈？

颜志杰：我认为模型的技术栈与百度内部使用的技术栈并不存在直接关系。举例而言，搜索相关的程序可能是用 C++ 编写的，云端的程序则多用 Golang 编写。但这两者的角色不同，一个是模型的生产方，另一个是模型的应用方。生产方使用什么语言实现模型，并不会影响应用方使用什么语言来调用或集成。对于应用方而言，无论模型是用于补全 Golang、Java 还是 Python 代码，其效果在当前模型体系下基本是一致的。

4 从“工具”到“协作者”

吴朝雄：最近一个很明显的趋势是，行业似乎从“AI 助手”在走向“智能体协作”。在你们的经验里，什么事情是原先的 AI 助手做不到，但智能体能做到的？

杜沛：在我看来, 最大的区别在于"闭环能力"——AI 助手更多是单点辅助, 而智能体可以串联起完整的开发 - 测试 - 审查流程。具体来说，从人工编写到 AI 编写，再到 AI 自动测试，最后由人进行结果审查与逻辑核对。这个方向无疑是未来的趋势，也是一种理想化的人机协同模式。AI 参与写代码的关键问题在于如何保证生成代码的质量，特别是在业务开发中满足逻辑性和可靠性的要求。

我们希望 AI 不只是做演示级别的 Demo，而是真正能满足产品开发的实际需求，产出可维护性强的代码，而不是仅仅能“跑起来”的代码。如果生成的代码逻辑混乱或难以理解，后续维护人员需要重新阅读和分析，会带来额外的负担。因此，AI 生成代码必须达到人类开发者可接受的标准，确保逻辑清晰、约束合理，才能真正降低人力成本。

在测试环节，AI 测试与传统人工测试的关注点也不同。传统测试主要关注结果正确性，而 AI 测试由于缺乏完整的运行环境，无法直接判断结果的对错。因此需要为其提供运行环境，帮助 AI 验证代码的构建是否通过、语法是否正确、边界条件是否覆盖等。对于复杂应用，尤其在移动端，还需在真机上运行测试，增加了难度和成本。AI 测试不应仅停留在静态分析层面，而应延伸至动态运行状态的测试，才能形成更完整的闭环，从产品逻辑、代码质量、运行结果多维度提供保障。

如果这一体系能实现动态测试闭环，AI 将能更好地驱动整个开发流程，提升智能体验。这种模式的理想形态高度依赖于大模型能力。目前出现的“世界模型”虽然主要用于机器人，但未来也可能应用到软件开发与测试中。若模型能理解的不仅是文本或静态图像，而是结合视频、操作行为、屏幕显示等多模态信息进行判断，那么开发流程将迎来质的提升。

吴朝雄：你提到整个研发流程会由 agent 协作完成。比如人类仅需输入开发意图，后续的代码生成与自测均由 AI 完成，人只需做最终审核。如果你们团队要实现这种流程的大规模落地，大概还需要多长时间？

杜沛：从目前情况来看，这个目标短期内难以完全实现。按照我的预期，要真正打通流程、形成闭环，至少还需要一年以上的时间。

颜志杰：AI 助手到智能体的演化，本质上是从“动脑、动嘴”升级到“动脑、动手、动嘴”的阶段。AI 助手主要处理思考和语言交互，而智能体则具备更强的自主执行能力。以研发领域为例，像 Devin 或 SWE Agent 就体现了这种形态。它们不再局限于 IDE 环境中的问答式交互，而是能在 DevOps 平台上自动执行任务，如代码生成、测试、验证、提交 PR，甚至在发现问题后自动修复并反馈结果。

这种模式体现出类人的逻辑链条：先观察，再推理，再行动，并持续感知环境变化。它不只是“口头助手”，而是能在异步环境中独立运作的执行体。过去仅依靠语言交互的助手无法完成端到端任务，如自动修复 bug、补全测试用例、执行调试与代码审查，而智能体则能通过自主推理与操作实现这一切。这正是智能体强大的核心，也被认为是未来十年的关键方向。

Coding Agent 代表了通用智能体的发展路径，能独立完成软件研发任务的智能体，其潜力将远超特定工具层面的自动化，因为它更接近人类在物理与逻辑层面的行动模式。

吴朝雄：智能体未来会走向统一的大平台，还是轻量化、插件化的生态？如果你们公司在研发类似产品，会倾向哪种形态？

颜志杰：我更倾向于在当前模型能力的限制下，发展轻量化、插件化的生态。研发场景是一个极其严谨的科学过程，拥有成熟的流程来保证质量与协作。贸然构建“大一统平台”既不现实，也容易脱离实际。更合理的做法是让 AI 以插件形式逐步融入现有的软件研发体系，先观察它在各环节能带来多少改进。当 AI 能稳定接管 50% 以上流程后，再谈平台化整合才有意义。毕竟模型本质是概率系统，稳定性仍需时间和经验积累来优化。如果许多关键环节仍需要人工介入，就不应追求“全能平台”的虚高目标。

吴朝雄：研发流程不仅涉及工具链，还包括人与项目的协作逻辑。这些协作往往在工具层面难以完全体现。当前的 agent 更多集中在单点问题的解决，比如帮助开发者发现或修复 bug。但在 DevOps 层面，未来可能会出现更高抽象层次的 AI 工作台，整合数据检索、任务调度、执行分析等能力。

例如 JIRA 已开始探索 AI 工作台，通过整合 DevOps 数据来实现项目进度追踪、代码库检索、任务完成情况分析、研发效能评估等功能。虽然目前仍以 AI 搜索为主，但雏形已经显现。国内多数产品还停留在单点 agent 阶段，尚未形成上层封装或生态体系。插件化生态仍是当下最稳妥、最现实的探索方向。

观众：程序员使用 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，通过日志查询平台就能快速生成 SQL 查询，无需他人协助。这种方式能显著提升个人能力的边界，使工作成果得到放大。只要你能善用 AI，让它真正帮助你解决以往无法完成的任务，你的价值自然会提升。

正如前面提到的，AI 在研发中目前主要体现为效率提升，但这只是阶段性结果。未来随着模型形态变化，输入方式将不再局限于文本，还可能包括视觉、听觉等多模态信息，届时能实现的功能会更多。只要能真正用好 AI，让它为你所用，你的能力与价值就会被放大，而不是取决于你属于哪一类工程师。