大模型进入研发体系后，我们看到了这些变化

现在再提“AI 写代码”，很多工程师大概只会笑笑：不就是日常工具之一吗？自动补全、代码生成、快速搭建原型……几乎已经成了标配。今天我们不讨论“AI 会不会取代程序员”这类问题，而是想问一句：AI 进了我们日常开发流程之后，哪些事情真的变了？又有哪些没变？

近日 InfoQ《极客有约》X AICon 直播栏目特别邀请到了 同程旅行工程效能架构师杨方伟、网易游戏高级技术经理林香鑫、百度资深研发工程师颜志杰，在 AICon 全球人工智能开发与应用大会 2025 北京站 即将召开之际，探讨他们在实践中的所感所想：从写代码到理解需求、从个人效率到团队协作，大模型到底改变了什么？

部分精彩观点如下：

• 能率先感受到 AI 收益的工程师通常具备以下特点：积极拥抱变化、有优秀的交流与调适能力和快速学习与整合能力、基础知识扎实。

• 生产效率提升十倍，未必导致岗位减少十倍，反而可能催生十倍以上的新需求，岗位总量仍会增长。

• 指标应服务于改进，而非成为目的本身。

• 当前 AI 代码生成更适用于 0-1 阶段的原型开发、非线上 / 非核心业务系统和垂直场景的特定任务。

在 6 月 27-28 日将于北京举办的 AICon 全球人工智能开发与应用大会上，我们特别设置了 【大模型助力研发的实战经验】 专题。该专题将聚焦企业级落地的实战经验，邀请行业领军企业的专家就大模型在研发领域的实践经验、存在问题及应对策略展开深入交流，共同加速新研发范式的落地。

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

完整直播回放可查看：https://www.infoq.cn/video/miDLBhDV2w4zUx8Fbmtt

杨方伟：大模型带来的改变不只是提效，有人说它改变了协作方式，有人说它改变了知识分布、角色分工。大家在自己的场景里，感受到的是哪一类变化最突出？或者说，有没有哪一项工作，会觉得“要是没有大模型，现在根本搞不动了”？

杨方伟： 最近使用工具时，偶尔会出现账号锁定等问题，这时就发现没有 AI 编码工具非常不适应。尽管起初使用时能力有提升，但工具缺失后，与旧编码方式差异显著。因此，大模型在研发效率的多维度提升是基础，但非全部。例如，在代码生成、辅助学习加速、调试问题定位方面提供了很大帮助。

在协作方式演进上，主要有两个方面。其一，知识共享新范式：大模型成为团队内部的动态、可交互知识库，新成员通过对话快速理解项目技术和细节，减少对资深工程师的频繁打扰。其二，跨领域协作：它有助于理解跨团队文档如产品设计初稿、API 文档等，降低沟通门槛。在角色分工上，大模型赋能初级工程师更快胜任复杂任务，同时解放资深工程师专注于架构设计、复杂问题攻坚、技术创新及 AI 生成内容审查优化。

颜志杰： 因为我以前一直从事 DevOps 平台相关的工作，软件研发首先我想到的是 DevOps 的双环模型，从 Plan 需求到编码 Code、Build、Test、DePloy、monitor 等；在这些环节都做了大量的工作比如需求管理推敏捷、推自动化测试、推 CICD、预案管理等去推动环节的自动化，带来研发提效等；

但这里有两个环节，Code 和 Build 基本都是以人为主导，因为这些是没办法通过规则来穷举完成的，在大模型出来之前，至少我没办法想象可以把这两个环节搞自动化了：让 AI 理解需求去编码 Code、去做 CR、出现问题之后自动的去 Build 修复；而现在，随着模型能力增强、推理模型的推出，模型具备『慢思考』能力，逐渐开始有能力干好这些『强逻辑』的事情；而且这个进化速度是很快的，比如 cursor 的 composer、Comate 的 zulu、Augument 等等，可以看到在 SWE-Bench 上的分数，直接修 github 的 issue 测试上都涨的很猛，这两个环节打通之后，串联以前的 devops 工具平台，AI 可以异步的托管任务，而且可以跟人可以更好的配合完成工作，业界不仅是通用的任务像 mauns、genspark，研发领域也有 devin、github 的 SWE-Agent 都在这条线上发展。

所以回到问题，从 devops 环的角度来看，编码和 Build 这两类场景变化最突出，也就是让 AI 更像一个人一样可以异步的委托工作，可以跟人很方便的交流沟通，使用其他工具来完成任务，这项工作确实是离开了大模型根本搞不动，这也是百度目前持之以恒探索的方向，只要这个方向取得了突破，一定会反向驱动 Plan 需求管理的澄清、以及链接 Test 测试环节，整个研发范式将会发生更大的变化。

林香鑫： 大模型实现了专业能力的跃迁：例如策划人员可借助大模型的编码能力快速验证思路原型可行性，通过迭代形成有效 Demo 后再与研发讨论，这从根本上改变了传统“需求 - 研发 - 验收”的低效循环。新模式允许在构思过程中同步使用 AI 工具实现原型论证，预判并排除潜在风险点，从而提升需求到研发的前期验证效率。

另一协同变化是团队更积极积累知识资产。此前文档因检索困难而价值有限，但大模型结合 RAG 的检索能力激励团队完善文档体系——当成员需要信息时，首选 AI 检索而非直接咨询同事，这实质提升了协作效率。企业与团队的工作模式正悄然变革：工作者优先考虑“哪个 AI 工具能解决当前任务”，而非传统“先找人对接”的路径。这种思维习惯的转变，正是大模型时代的关键特征。

杨方伟：你们有没有遇到过某种类型的工程师，在用了 AI 工具之后，突然交付效率大幅提升，表现变得非常亮眼？

颜志杰： 从个人视角衡量 AI 收益，第一类是“enable”（赋能），即借助 AI，我能完成原本无法胜任的任务。例如，团队中一位后端开发人员，需要创建一个用于 Kubernetes 集群及组件问题排查的表单工具。这类需求若在以往，需协调前端资源排期。但如今，利用 Code Agent、Bot.new 等 AI 工具，生成简单的前端页面或网站已相当便捷。这种实现从无到有、弥补技能空白的情况，其收益是显著的。不过，这类效率提升通常不被纳入常规的研发效能度量体系。它更多是让人直观感受到 AI 能切实解决问题，体感强烈。但它的确属于简单的、非线上长期运行的需求范畴。实际上，只要善于使用 AI，具备成为全栈工程师的潜力很大。

第二类收益则是“enhance”（增强），即 AI 作为助手提升现有能力。例如，大模型具备生成深度报告的能力，产品经理可借此高效完成用户调研与分析。我了解到金融领域进行竞争对手分析时，也大量运用此能力生成报告，人工再进行校验即可。对程序员而言，目前“enhance”更多体现在处理非核心任务的托管上，例如编写单元测试或生成测试用例。这确实能提升日常活动效率，但若期望因此带来整体工作表现的显著提升（如让管理者明显察觉），则比较困难。因为编码等工作在程序员的时间占比并非绝对主导，沟通协调等耗时也不少。关键在于，AI 无法承担最终责任，因此端到端任务仍离不开人工校验。

总结来说，“enable”让我掌握新技能，实现突破，这种亮眼效果明显。而“enhance”作为能力增强，由于 AI 不能完全担责，无法端到端交付任务，其提升比例不会特别显著。况且，工作中存在大量 AI 无法触及的部分，节省的时间会被其他事务填充。因此，“enhance”带来的直观感受相对不那么强烈。

林香鑫：AI 正在重新定义“强者”的标准，在 AI 时代，具备以下几种特质的人更可能脱颖而出：第一类是具有强烈主动学习意愿但经验尚浅的人。例如团队中高潜力但经验欠缺的成员，他们可利用 AI 工具快速学习现有知识。我们内部开发了能深度理解代码仓库设计逻辑的模块。一位新人借助此工具，仅用两天就理清了原本预计需两周熟悉的代码仓库整体逻辑。这证明：强烈的学习意愿结合 AI 工具，能极大缩短成长周期，这是一种显著的自我强化路径。

第二类是“有想法且能动手”的人。例如策划人员能独立完成原型开发，非专业人员能借助 AI 产出更高质量的国际化翻译。在公司内部，大量需求本不属于某人的职能范围，以往需依赖他人实现想法。现在，个人可以结合自身想法与 AI 能力独立完成，实现职能外的能力跃迁。这本质上是颜老师提到的“enable”（赋能），它扩展了个人的知识广度——只要愿意行动，就能获得多方面的能力加持。

第三类至关重要。当前与大模型的主要交互方式是聊天，而提问能力的差异会导致结果悬殊。我们曾举办基于 AI 的编程比赛，评委观察发现：优秀作品与普通作品的关键差异在于参赛者如何定义问题本身——他们发现问题的规模与深度截然不同。工作场景同理：日常存在各种问题，有人善于主动发掘，有人习惯被动执行。在 AI 时代，精准定义问题的能力尤为关键。这类人一方面能理清问题本质，另一方面擅长运用 AI 工具，在双重加持下能解决的有效问题远多于他人。

杨方伟： 综合来看，能率先感受到 AI 收益的工程师通常具备以下特点：首先，他们积极拥抱变化、好奇心强，乐于尝试新工具，积极探索大模型在工程中的应用场景，并不畏惧试错风险。其次，他们具备优秀的交流与调试能力，当问题出现时，能清晰准确地与 AI 沟通（通过优化提问等方式）以修正结果，并随着模型迭代调整交互策略。第三，他们拥有快速学习与整合能力，能迅速掌握 AI 工具特性并融入现有工作流，而非仅将其视为简单攻略工具，能从更广泛、更联系的视角审视问题。第四，基础知识扎实的工程师收益更大，因其能更敏锐地发现问题，并快速做出准确判断及有效优化。

杨方伟：大家有没有看到某种努力现在已经变得“不值钱”了？比如以前靠死磕 debug ，现在 AI 一下就搞定了？反过来，有没有觉得有些事 AI 始终替代不了——它快，但你们还是更信得过工程师？

林香鑫： 这本质上是关于核心竞争力的问题——不同时代需要不同的核心竞争力。过去，在没有快速检索或大模型辅助时，精细记忆 API 调用方式等技能能显著提升效率。但在 AI 加持下，这类技能的价值被稀释了，因为提示词或快速查询即可获取相关信息，使其变得相对廉价。另一种情况是重复性的 debug，我们可能陷入忙碌状态却解决着同类型甚至相同的问题，未思考如何系统性提升效率，这类产出同样容易沦为廉价劳动。

在大模型能力日益强大的背景下，我们需要思考：假设团队平均水平为 4 分，而大模型已达 4.5 分，团队应如何超越它？答案显然不是继续做 3-4 分的工作，这应交给大模型，而是聚焦于大模型目前难以胜任的领域。我认为有几个关键方向：

首先是对关键业务需求的深度理解。具备此能力的工程师相对稀缺——他们能深入业务背景，形成关键的技术决策。这对大模型而言目前难以企及，因其主要响应明确指令或在训练数据范围内工作，缺乏对具体业务背景和客观条件的真正理解。工程师应在此领域建立核心竞争力。

其次是解决非典型问题的能力。典型问题大多可通过大模型找到答案，非典型问题则包含两方面：一是对前沿技术的理解与整合，即洞察行业动态，识别工作痛点，并整合新技术解决问题。例如，我们团队持续探索快速迭代的 AI 编程技术（如代码库检索、智能生成、纯 AI 代码生成），进行试验并逐步形成可落地的方案。这一过程漫长且需要深度探索，并需结合实际工作需求。以游戏研发为例，许多前沿 AI 编码技术在游戏开发场景下并不适用。这就需要我们思考如何在特定领域使其可用，这构成了我们在该领域的核心能力。二是跨领域解决方案的创新。例如，我们正致力于衔接游戏策划案与开发环节，这需要深度融合两端经验，并利用大模型将之提炼为通用化方案。

综上所述，通用技能的价值在于“知道如何应用”即可。未来的核心竞争力将更依赖于在专业领域做深做透，并具备解决综合性业务问题的能力。

颜志杰： 核心在于避免与 AI 或机器比拼记忆等特定能力，应寻找自身独特的竞争优势。这让我联想到一个相关话题：随着大模型日益强大，我们是否还需要学习编程？一年前我曾与大学教师探讨，他们也在思考教学是否需要调整？当时的结论是：AI 目前仍是工具，理解计算机原理和编程技巧，是进入该行业的入门关键。

实际上，在 AI 辅助下学习编程可能比以往任何时代都更具价值。生产效率提升十倍，未必导致岗位减少十倍，反而可能催生十倍以上的新需求，岗位总量仍会增长。因此，我认为澄清一点很重要：即使 AI 能解决 80% 的 Bug，剩余 20% 的复杂问题仍需人类解决。在互联网公司等场景中，快速定位、止损的能力变得更为关键。对于研发人员或希望进入编码相关行业的人来说，掌握原生的编码能力、理解基础原理至关重要——但这并非要求死记硬背，而是理解其本质。

最后，一个根本原则是：AI 无法“背锅”。无论 AI 多强大，最终决策与掌控权仍在人类手中。因此，成为能指挥 AI 的决策者，掌握“方向盘”的人，其价值将随 AI 能力的增强而同步提升。

杨方伟： 扎实的基础知识能力至关重要，它直接决定了我们遇到问题时的问题排查方向。方向判断正确，解决路径就短；方向错误，则南辕北辙。这种方向的抉择能力，正是掌握基础知识的核心价值体现。

目前大模型的作用在于：当我们确定方向后，它协助解决该方向下的具体问题并提供相关参考，但核心决策要素仍需人类把控。这要求我们深入理解基础原理及业务知识——后者因其技术性较弱，掌握难度往往更大。

杨方伟：现在很多公司都在喊“组织效率提升好几倍”，但我们知道，坐在系统里写代码的人，未必真的感受到轻松了。大家有没有感受到效率压力？以及在面对交付节奏越来越快的趋势下，是怎么自我调整的？

颜志杰： 我的主观体验是，AI 带来显著提效的关键在于能否将任务自动化。若仅作为 Copilot 辅助编码或生成测试用例，且其输出仍需人工校验，则提升有限，远未达到质变。根据我们的观察，AI 当前能覆盖的任务在工程师整体工作时间中的占比并不高。即便这些环节效率提升，节省的时间也可能被其他新增任务迅速填充——尤其在业务发展迅速或竞争激烈的公司。因此，若未实现任务自动化，工程师对效率提升的感知并不明显。

一旦实现自动化，工作负荷才可能真正减轻。虽然尚未普及，但我相信临界点正快速临近——例如 Claude 宣称的“数小时完成编程项目”，这不仅代表模型能力跃升，更体现了工程能力的重大突破，比如大模型 memory，这种进步意味着，未来更多简单任务，如理解需求并生成完整代码，有望被自动化解决。

若自动化成为现实，工程师的精力应转向更具挑战性的领域：例如提升系统稳健性、处理 AI 无法解决的 10%-20% 关键问题。目前，业界报告显示的 AI 提效多在 10%-20% 区间。考虑到编码本身可能仅占工程师 30% 的时间，这种程度的提升难以带来显著体感变化。因此，现阶段一线研发人员对 AI 的压力感知有限。真正的压力可能源于业务本身的产品线节奏。工具平台团队则面临另一重压力：需向管理层证明 AI 的实际提效价值。

对于工程师的个人建议：AI 仍是当前提升生产力的最大变量。深入理解 AI 原理、熟练运用工具、探索构建自动化流程，确实能带来效率提升。这不仅能释放原有时间上限，更能将此前无法自动化的任务纳入自动化范畴。在此过程中，更早拥抱并掌握 AI 能力的人，将获得更大的竞争优势。

林香鑫： 压力最大的群体，或许是像我们这样开发 AI 工具的人。整个行业的迅猛发展和铺天盖地的革命性创新宣传，与实际落地应用常存在差距。但行业仍在高速内卷前行。对于负责内部效能或工具建设的团队而言，挑战在于：一方面需要证明自身能达到业界宣称的水平；另一方面，引入 AI 工具的关键是评估其实际影响——究竟是提升了效率，还是增加了使用成本？这至关重要。

从个人角度，焦虑感确实存在。AI 的发展推高了各职能岗位对提效工具的期望值。在需求交付链路中，常被质问“为何不用 AI 解决？”这反映出两点：一是对 AI 能力边界理解不足；二是现阶段存在 AI“无所不能”的过高期望。我们会针对具体业务场景测评模型能力，而非依赖通用宣传，以此评估某项工作能否通过 AI 提效。这个过程常陷入自我证明的循环：要么证明 AI 不行，要么证明自己不行。

效率提升是客观存在的，但呈现渐进式演进而非突变。模型能力的持续进步会逐步渗透到工作场景的各个节点，同时人们应用 AI 工具的能力也在提升，这两方面共同推动效率潜移默化地增长。关键在于思路转变：我们衡量的是编写代码的数量，还是解决问题的成效？我更倾向于后者。内部调研显示，工程师仅约 20-30% 时间用于编码，更多精力投入于问题排查、技术研究等。因此需重新定义“生产力”——它涵盖多方面积累，不仅限于编码本身。个人调整策略应聚焦两点：一是持续沉淀系统思维与架构设计能力，这在未来将愈发重要；二是提升与 AI 的协作能力。未来每个人可能指挥多个 Agent，如同运作一个“公司”，这些能力将成为核心竞争力。面对焦虑，最有效的方式是投资自身未来的能力，保持持续学习状态。

杨方伟： 效率焦虑与行业性焦虑是毋庸置疑的。从行业到公司再到个人，普遍存在一种紧迫感：担忧公司发展滞后于竞争对手，或个人所学技能被 AI 替代而落后于他人，这种焦虑将持续存在。面对这一趋势，自我调整的关键在于：首先，积极拥抱变化并持续学习；其次，聚焦价值创造而非简单重复劳动；更重要的是，作为研发人员必须守住质量底线——AI 终究是辅助工具，最终验证责任仍在人类。同时，需保持工作与生活的平衡，避免过度焦虑。当我们养成拥抱变化、持续学习的习惯，往往能带来积极的成果。

观众：因为 AI ，全世界的软件工程师会减少多少？

颜志杰： 我认为答案恰恰相反——数量会增加。逻辑在于：如果 AI 能大幅提升生产力，使更多人具备类似工程师的能力，那么将催生更多相关岗位。当大模型的使用成本降至一定程度，虽然单次 API 调用费用可能下降，但整体市场规模会因需求激增而扩大。本质是人的生产力提升后，会激发远超生产力增幅的更大需求，并以更低成本实现更多任务，最终推高对相关人才的需求总量。

杨方伟： 从程序员个体视角看，AI 似乎构成冲击。但从整个行业或解决现实世界问题的维度观察，AI 赋能将使我们能应对的问题量级呈指数级增长。技术变革短期可能引发波动，但长期必然对各行各业产生积极影响。当前大模型的潜力边界仍在探索中，此时讨论工程师数量减少为时尚早。更应看到的是：未来将有更多问题亟待解决，对人才的需求将持续扩张——这一前景是极其乐观的。

杨方伟：很多工程效能团队现在都在想办法评估研发效率。请问大家内部现在是怎么衡量工程师的效率的？有哪些是你们认为“靠谱”的指标？又有哪些数据，其实很容易被滥用、反而造成误解？

林香鑫： 衡量效能的一个典型标准是需求交付速度——即从需求提出到上线的周期缩短，通常意味着效能提升，这也是业界普遍采用的方式。引入 AI 后，我们也会额外关注其应用能力。虽然目前难以精确量化 AI 带来的效率提升，但可以肯定的是，有效使用 AI 工具必然有助于效率增长。我们现在会通过工具 / 场景的使用量数据以及用户满意度反馈，作为辅助性的考量维度。

颜志杰： 效能度量是个宏大话题，我分享一个思考框架：首先要回归顶层目标——在确保质量的前提下，提升个人或团队的吞吐量，即交付速度，常用指标包括单位时间交付需求数量、开发至上线的周期。但关键点在于：度量指标需与团队的具体实践紧密结合。例如：

在推行双周迭代（bi-weekly iteration）的团队中，核心指标可设定为“两周内完成的需求占比”。这能让成员直观感知：进入迭代池的需求是否可预期交付。

而对于 ToB 项目交付或游戏研发这种可能按季度 / 月度规划迭代的团队，指标则应调整为“季度内交付量”或“延期需求比例”。这种与团队流程、节奏挂钩的度量方式，才能带来切实的体感提升。度量本身成本高昂，只有指标与团队实际运作强关联，才能获得成员认可并产生推动力。否则，指标波动会引发大量精力消耗于数据验证而非效能改进。

杨方伟： 工程效能的核心指标在不同业务场景下可能略有差异，我们引入指标的目的，应是驱动或牵引团队解决当前阶段的关键问题，而非单纯追求数据。若某团队交付周期显著过长，将其作为重点跟踪指标便具有指导意义。因此，指标的选择需考虑阶段性需求和团队特性，避免滥用或引发误解。核心原则是：指标应服务于改进，而非成为目的本身。

杨方伟：如果给“普通工程师”一个建议，让他在这一波大模型浪潮里更容易被看见，你会给他什么建议？

林香鑫： 工程师的核心价值在于其 解决问题的数量与深度，日常工作能力可细分为技术研发、规划统筹、需求理解、问题解决及工作协调等多维度。若要使自身被“看见”，关键在于产出强有力的成果——这源于上述能力的综合体现。工程师需清晰认知自身与目标的差距，在此时代背景下，我倾向于深度应用 AI 工具弥合差距：即通过掌握 AI 能力（涉及沟通、编码、问题解决乃至深度思考规划），聚焦解决更具价值的问题，这是实现可见度的首要路径。

其次，应推动技术回归业务价值。当前对 AI 前沿技术的认知与实践正逐渐成为分水岭：积极追踪技术动态、探索能力边界并将其融入工作的工程师，与尚未深入认知或应用 AI 的同行之间，能力鸿沟正日益显现。因此，将快速迭代的 AI 技术与实际业务价值衔接至关重要。

第三，保持好奇心与持续学习至关重要。AI 领域竞争加速，模型能力迭代迅猛。持续关注动态并将新知转化为自身能力，是应对未来的关键。

颜志杰： 思考“工程师如何被看见”，不妨反向自问：你希望与具备何种特质的同事共事？ 这些特质往往正是你需要努力的方向。抛开 AI 因素，工程师的核心在于内功修炼——追求卓越的专业能力是立身之本。同时，坚信复利效应的力量至关重要。当下学习资源极其丰富，掌握高效获取知识的方法并坚持学习，是基础能力。理想中的合作者，首先应是“靠谱”之人。

在 AI 时代，需将“精通并善用 AI 工具”视为基本功。熟练驾驭这一强大工具将成为你的关键竞争优势。模型能力迭代迅猛，不同使用者基于其交流方式，获得的结果差异显著，需主动理解其特性。即使现阶段某些任务 AI 未能完美解决，也应保持开放拥抱的态度——技术仍在加速演进。更早深度应用、将其转化为得心应手的工具，结合追求卓越的初心、相信复利效应的坚持，以及对理想合作者特质的思考，方能在时代变革中实现超越。

杨方伟：“被看见”这个词让我联想到餐饮业的例子：一家餐馆如何脱颖而出？除了广告，关键在于老板能快速行动，博采众长，在店面装潢、环境营造等各方面领先一步。它未必是最好，但一定是最快的先行者。对于我们工程师而言，同样需要保持这种“跑得快”的状态——敏锐捕捉前沿动态，积极吸纳新知，并据此审视和改进我们的解决方案。

另一种被看见的餐馆是经营数十年的老店。它们屹立不倒的核心在于扎实的“基本盘”——即百吃不厌的美味。对应到工程师，我们的“基本盘”是什么？那就是持续的好奇心与对技术的热忱。保持这两点，既能让我们更快地响应变化，也能使专业根基更加深厚扎实。

观众：日常工作中 AI 生成代码的占比大概是多少？人工调整的部分大不大？

颜志杰： 目前我们的代码生成占比在 40% 多，但这一数据可分为两部分来看：第一部分是代码续写场景，该场景存在明显瓶颈，通常达到 30%-40% 的生成比例已属于较高水平；另一部分则是类似 agent 逻辑的场景，即通过异步方式让 AI 直接完成特定需求，此场景下生成代码的采纳率可达 80% 甚至更高。综合两类场景来看，未来代码生成占比仍有增长空间。

林香鑫： 仅从代码编写环节看，目前 AI 生成占比约 30% 多。我们对研发全流程进行了细分调研，发现理解现有代码、代码调试及修复等环节实际占用了更多时间，因此我们正针对这些核心环节开展提效工作。从内部调研结果看，研发时间占比前三的环节依次为：理解已有代码、解决代码问题、编写代码。这一结论修正了 “研发工作以编写代码为核心” 的普遍认知，反而提示我们需将提效工作的重心放在前两个环节，而非局限于代码生成本身。

杨方伟： 我们正探索优化 AI 工具使用方式的路径，例如针对 “人工调整成本” 这一关键变量，在部分典型项目中发现：当人工调整比例达 40% 时，AI 生成效率与手动编写差异不大，投入产出比不高；而通过调整 IDE 规则等方式将人工调整比例降至 20% 时，部分项目提效可达 30%-40%。因此，建议结合具体项目分析人工调整空间，观察调整幅度与效率提升的关系，以此制定数据驱动的优化策略。

观众：如何保证 AI 生成代码逻辑的正确性？

杨方伟： 我认为当前 AI 的定位仍是辅助人类工作，而非人类辅助 AI。基于此，目前的工作重心仍需以人工把控为主。对于关键代码必须进行逐行逻辑审查，传统的 Code Revie 机制仍需严格保障，尤其是在重要项目中；对于非 Demo 项目，可适当放宽审查标准或简化流程。同时，传统工具链的规范性操作不可缺失，例如必须执行安全扫描，包括动态与静态扫描等。

林香鑫： 除通过 Code Review 和扫描工具及时发现生成代码的潜在问题外，我们还从生成逻辑源头探索优化路径。结合游戏开发中存在相似玩法或系统的特点，我们采取了两项内部实践：一是构建历史代码检索机制，为 AI 生成提供可参考的代码范本，使其在思路、逻辑和风格上与现有代码保持一致；二是打造 “研发空间” 概念，整合团队专属知识库，从 “将 AI Agent 视为团队成员并赋予其业务认知” 的角度，使其获取相关领域知识，从而生成更贴合业务逻辑的代码。

观众：怎么描述能让 AI 生成的代码更准确？

颜志杰： 以排序算法为例，AI 可能生成无数种写法，但要将其输出约束到现有代码库中，目前仍存在技术瓶颈。现阶段 AI 尚无法在复杂代码库中完整理解语义并进行上下文感知的开发。因此，需通过外部约束机制引导 AI 生成符合预期的代码，具体可采用以下方式：1）提供历史案例，例如针对特定需求点，展示历史上修改 Router、Service、Controller 等组件的完整流程；2）采用 Few-Shot 学习范式，通过少量示例让模型学习模式；3）制定明确规则，限定修改范围。通过结合自定义 Prompts 与规则引擎，可显著提升模型在约束条件下的输出质量。

当前实践表明，为 AI 设定明确边界，如 “仅修改指定 5 个文件”比放任其自由生成更具可行性。这种约束机制需结合规则系统、自定义提示词工程等技术手段实现，避免模型脱离既有代码范式进行 “开放式思考”。

杨方伟： 有效需求描述的标准应具备 “外行可理解性”，即非专业人员也能通过描述复现问题场景。

颜志杰： 然而在实际操作中，精确描述需求的成本往往远超代码实现本身。例如，编写 50 行代码可能需要 50 行以上的提示词才能确保 AI 理解意图。这一成本结构导致当前 AI 代码生成更适用于 0-1 阶段的原型开发、非线上 / 非核心业务系统和垂直场景的特定任务。对于线上稳定运行的复杂系统，当 AI 生成代码超过一定规模时，人工审查成本激增，甚至抵消自动化带来的效率提升。

当前用户接受度较高的应用模式是将复杂场景拆解为明确的子任务，例如针对 “数据库增删改查” 这类逻辑相对固定的场景，通过平台级规则引擎 + 简短提示词实现高效生成。此类场景通常具备 “需求明确但非模板化” 的特征，既避免了长提示词的编写成本，又能通过约束机制确保输出质量。反观需要长篇幅提示词的场景，约半数用户因投入产出比问题持观望态度。

观众：AI 应用的开发前景怎么样？

杨方伟： 从行业趋势来看，当前普遍认为 2025 年将是 AI 应用开发的爆发元年。我的直观感受是，尽管大量 AI 应用已处于蓄势待发状态，但尚未形成真正的爆发临界点。可以预见的是，AI 应用必然会迎来井喷式增长，其开发前景具有极高的市场潜力与发展空间。

观众：大家都在用什么模型和 Agent 工具？

林香鑫： 我们在内部构建了一套模型测评体系，针对不同业务场景对各类模型进行实测，并依据场景特性选择适配模型。观察近期模型发布动态可见，开发者均会着重强调模型的专项能力，例如 Claude 模型突出代码生成能力，OpenAI 则聚焦推理深度优化。这一现象表明，模型能力呈现垂直化发展趋势，其适用价值需结合具体业务场景评估。因此在技术选型层面，仅存在 “第一梯队模型” 的划分，而无 “绝对最优模型” 的定论，业务需求的差异化决定了模型选择的适配性逻辑。