AI 研发提效进行到哪儿，谁来守住质量底线？

近几年 AI 工具快速融入研发流程。各类产品不断涌现，百家争鸣，而开发者的工作方式也在悄然发生变化。效率的提升已经成为共识，但与此同时，质量与可信性也被推到前台：在提速的同时，研发该如何守住质量底线？

近日 InfoQ《极客有约》X AICon 直播栏目特别邀请了众安银行技术委员会主席沈斌、华为云 PaaS 首席前端架构师侯凡、字节跳动 TRAE 架构师宁啸威一起，从前端、后端、架构等多视角探讨 AI 提效研发现状。

12 月 19 日-12 月 20 日，全球人工智能开发与应用大会将在北京举办，目前正在征集议题中，欢迎关注！

部分精彩观点如下：

• 在思考如何打造下一代 AI Native 产品时，重点是如何在人与 AI 之间找到平衡点。在 AI 能力尚未足够强大、无法完全放手的阶段，这个交互平衡点显得尤为重要。

• 无论是 RAG，还是上下文增强，或者 MCP，这些都只是手段，而不是目的。目标是搭建开放生态，让业务团队能够把 AI 当作大脑接入。

• 未来大量 Web 应用可能会消亡，包括网站和 APP，因为交互方式将转向自然语言。前端界面会极度简化，像谷歌最初的搜索框那样，而企业则主要提供后端的服务能力。

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

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

AI 在研发中的角色演变

沈斌： 很多团队最初接触 AI 时，是用它做一些具体的小任务，比如写测试、生成代码。但现在，我们看到 AI 介入了更多研发环节，甚至影响到架构设计和组织协作。我们常说的 AI 时代，是从 2022 年底 ChatGPT 推出后开始的。当时业界普遍称之为 AI 的“iPhone 时刻”。从那时起，AI 提效的话题迅速涌现。回顾近三年，我清晰地看到 AI 应用经历了三个阶段。

第一阶段是 AI 辅助编程。在这一阶段，AI 更多地作为工具存在，最常见的形式是 IDE 插件。这个阶段的模式很典型：左边是编辑器，右边是聊天框，遇到需要写小算法或简单任务时，就在聊天窗口中获得 AI 的提示，再应用到编辑器中。

这一模式持续了大约一年，后来出现了以 Cursor 为代表的 IDE 工具，我称之为“氛围编程 1.0 时代”。它在 Chat 模式的基础上引入了 Agent，可以自主完成一些简单任务，不再局限于局部方法，而是能应对简单的需求，研发效率因此明显提升。

第三阶段是今年 2 月份 OpenAI 联合创始人 Andrej Karpathy 提出的 Vibe Coding 概念，催生了当前火热的 Claude Code。这种形态从 IDE 升级为 CLI（命令行）模式，我称之为“氛围编程 2.0 时代”。相比 IDE，CLI 模式虽然门槛更高，但用户群体更广泛，玩法更多样，定制自由度也更高。

侯凡： 当前网上对 AI 的看法往往有两个极端。第一个认为，AI 是下一代生产力革命，能带来颠覆性的效率提升。尤其是在 ToB 业务场景中，我们每天都能看到很好的实践案例。这种声音信心十足，认为 AI 会像当年云服务改造那样，重塑研发工具并显著提升效能。第二个则是在真实研发过程中感觉好像“没什么用”。他们并不像爱好者那样兴奋，而是认为当前 AI 的产出很难直接进入生产系统。

我相信各大公司也有类似经历。一方面，管理层寄予厚望，希望借助 AI 工具让效率提升数倍以上。但实际情况是，生成的大量代码很难放心直接入库。比如 Agent 模式一次生成一万行、两万行代码，但我们敢不敢真的直接把这些代码提交到生产库？当然，AI 在个人开发场景中很有价值，比如写小游戏、小 Demo，甚至家庭小应用，我自己也受益颇多。但换到 ToB 场景，要考虑的事情和因素就要复杂得多。

所以我想抛一个问题：Vibe Coding 或 Agent 模式下，AI 自动生成的大量代码，大家真的敢直接提交到企业生产库吗？

沈斌： 我们团队其实也是最近两个月才开始深入使用 Claude Code。从经验来看，AI 并没有智能到能独立完成一个完整的需求，更多时候需要我们通过上下文和提示词帮助它理解需求和编写代码。Claude 官方也提出了一个开发范式——EPCC：Explore、Plan、Code、Commit。也就是说，AI 依然遵循研发的基本流程：理解需求、设计方案、编程、测试。

一个常见的误区是以为 AI 能“一句话搞定全部”，实际上更好的做法是分环节让 AI 协助。比如通过自定义 Agent 或者使用 PromptX 框架定义不同角色，让它分别担任架构师、产品经理等角色，辅助完成相应环节，但每个环节完成后仍需要人工介入。

我常提醒团队，AI 不会替你担责。无论代码是 AI 写的还是人工写的，最终责任都在工程师本人。因此，AI 对人的要求实际上更高。它确实能提升效率，但也要求开发者具备更强的理解和把控能力。

宁啸威： 与一两年前相比，AI 已经深度融入研发流程，不再只是写 demo、单测或生成样例代码的工具，而是覆盖了需求调研、PRD 评审、技术设计、测试及 CI/CD 等各个环节，真正贯穿了整个交付生命周期。

在我们团队内部，AI 编程的渗透率几乎已达到 100%。在使用 AI 工具的过程中，我们不断获得新的思路和启发，也对产品提出更多改进。在公司层面，AI 编程也受到高度重视，AI 工具被强力推广应用到各业务团队。以核心团队为例，头条和抖音的前端团队对 TRAE 的使用率已经很高。过去 iOS 或安卓开发同事将 Figma 设计稿还原为代码可能需要一两天，现在通过接入 Figma MCP 生态，借助 TRAE 或其他工具，“design to code”仅需几分钟。

市面上涌现了许多 AI 编程产品，在真实的编码场景中，决定用户口碑的一大因素是如何处理好“人与 AI 的交互”。以 Cursor 为例，它会在生成代码时要求开发者参与 review，在每个环节设置 checkpoint，允许纠偏或回滚，确保开发者对结果保持掌控，这种协作方式正是其核心竞争力所在。我们最近也在思考如何打造下一代 AI Native 产品，重点就是如何在人与 AI 之间找到平衡点。在 AI 能力尚未足够强大、无法完全放手的阶段，这个交互平衡点显得尤为重要。

侯凡： 两年前，很多人担心 AI 会让工具团队失去价值。但结合实践来看，答案显然是否定的。代码能不能入库，取决于后续研发流程。即使是人工编写的代码，也必须经过严格的扫描和校验，AI 生成的代码当然也一样。

从我们的经验来看，研发流程并没有因为 AI 出现而被打破，而是加速了各个角色的效率。无论是开发者、测试人员还是架构师，最终都需要有人对结果负责。这意味着，AI 并没有减少“人”的必要性，而是让人承担更高层次的决策和责任。

随着 MCP 等生态的出现，Agent 的能力更像是一种“硅基人”，可以调用工具，与“碳基人”协作。我们内部做开发者调研，开发者真正花在编码上的时间大约只有 30%，其余更多时间用于与产品、架构、测试沟通，以及自测和 CI/CD 流程。也就是说，AI 在需求设计、任务拆解、测试辅助等环节的作用更值得关注。

我的总结是：一方面，AI 的确显著提升了研发效能，但它并没有完全颠覆现有模式，至少目前还没到那一步；另一方面，AI 的使用门槛不低，对开发者的工程能力和工具使用能力要求更高。我们需要保持理性和平和的心态，把 AI 看作是技术创新带来的重大提升，而不是一劳永逸的替代。未来或许会出现颠覆性的一天，但眼下更关键的是结合好的工具、模型和工程实践，把 AI 真正用好。

提效的“质”和“量”

沈斌：提效一般会想到速度加快，但其实在质量、稳定性、安全性上 AI 也会带来变化。大家自身或者团队方面有没有这些方面的变化？在质和量上，AI 分别带来了哪些提升？

宁啸威： AI 提效已经是一个公认的事实，也有大量内部和外部的数据支撑。具体到代码质量，AI 生成的代码是否能上线、是否能达到团队的平均水平？很多情况下，AI 生成的代码比开发者从零手写的更规范、更标准。原因在于大模型在训练过程中引入了大量优秀的代码实践。我们也能明显看到一个特点：AI 生成的代码往往会附带详细注释，并在接口和函数层面遵循统一规范，这在规范性方面甚至优于人类开发者。

从更广的研发流程看，传统提升代码质量依赖后置流程，如单元测试、集成测试、冒烟测试、代码评审，以及上线前的流水线 CI/CD。过去很多开发者不愿意写单测，往往在开发结束后才仓促补充，导致覆盖率低或质量不高。而引入 AI 后，单测可以前置到开发阶段。我们团队与质量团队合作开发了单测 Agent，结合 TRAE 的 MCP 和自定义 Agent 能力，打通公司内部研发工具，使得在开发过程中就能自动提升单测覆盖率。在这种确定性任务中，AI 的效果非常好，超过 80% 的场景能覆盖传统的自测环节。

另一个例子是代码评审。人工评审往往涉及对架构、业务或产品的理解，而机器无法完全替代。但 AI 可以作为辅助，做初步检查，例如变量命名、格式规范，或者标注出难以理解的代码段。AI 还能为 PR 生成总结和解释，帮助 reviewer 更快理解上下文，从而起到沟通桥梁的作用。

当然，仅仅识别问题还不够，关键在于修复。随着项目规模和复杂度增加，问题种类会越来越多，AI 是否能真正解决它们是一个挑战。我们尝试在 CI/CD 和研发流程中引入自动化 bug fix，让 AI 根据静态检测或 review 发现的问题进行修复尝试，并提交 MR 供工程师参考。这种方式目前还在试点阶段，更多是提供建议，但能形成从发现到解决的闭环。

沈斌： 刚才提到单元测试，其实随着 Vibe coding 的发展，一个较早的概念又开始流行，就是 TDD（测试驱动开发）。通过先写测试来告诉 AI 预期效果，再让它生成代码，整体的可控性会更强。

侯凡： 我们的实践中发现，AI 带来的质和效能提升，按理说应当释放开发者的精力，让他们更多思考架构、测试用例等。但现实中，效率提升像打开潘多拉魔盒，带来了“量”的激增。比如，一个新员工在 AI 辅助下，仅一周就能产出高质量代码，结果在单位时间内涌入的需求数量大幅增加。

这对测试环节是个挑战：以前一个版本需要测 10 个需求，现在可能要测 20 个。测试人员是否也要用 AI 来测 AI 生成的代码？但这样就形成 AI 生成代码再由 AI 测试的循环，与软件工程的可信性原则相悖。尤其在我们这种强调流程的公司，测试环节必须独立，不能完全依赖生成端的结果。

因此，质和量的提升同时带来新问题：需求和代码量增加，但上线前必须经过的流程并不会减少。未来测试环节的压力会更大，这需要新的方法去优化。从更长远看，AI 生成与 AI 测试的循环也引发伦理和可信性问题，尤其在关键系统中。

质量始终是所有生产系统以及软件研发的底线。那么在实践中，质量应当如何保障？我们的思路是依然要把 Agent 看作工具。工具最大的价值在于它的确定性，它不是黑盒的神经网络，而是基于一条条清晰规则的逻辑系统。

因此我认为，随着 AI 的发展，反而会带来更多对确定性工具的需求。谁来守住底线？谁来约束和判断 AI 生成的代码？这就需要借助传统工具。很多传统的理念，如 TDD 等，其实在过去因为开发者没有时间而难以真正落地。而现在 AI 提升了效率，把时间还给了开发者，很多理念和方法都有可能重新得到实践。开发者可以更多地专注于工具开发，让 AI 生成的代码在规则范围内运行，从而做到可控和可信。只要经过既有的代码检查、安全扫描等工具的验证，我们就可以在新的语境下更好地应用这些规则。

未来要解决“量”的问题，就必须依靠这种确定性工具的约束和判断。AI 真正的价值在于它与现有工具体系的结合与碰撞，我们需要思考的，是如何通过这种融合来形成新的创造力。目前我们的实践仍然是基于工具的持续发展，而不是减少工具的使用需求。

从需求管理、架构管理，到代码仓库托管、CI/CD 等环节，所有工具都要面对 AI 带来的“量”的增加。最终，我依然认为工具要承担起确定性校验的责任，而 AI 则带来新的认知方式。两者的结合，会在研发效能领域打开广阔的发展空间。

沈斌：AI 提效的结果必然是“质”和“量”双提升。在众安集团内部，有一个团队较早开始并深入推进 AI 的实践。今年二、三季度的数据表明：开发岗位的效率提升大约在 30%，主要集中在代码编写和代码评审环节；测试岗位的提效约为 25%，涵盖用例编写和自动化测试；运维岗位的提升也在 25% 左右，尤其体现在 DevOps 相关场景。此外，在运维中一些复杂问题的排查上，AI 的帮助尤为明显。

我还观察到一个现象：提效效果不仅与岗位相关，也与使用者的经验水平有关。从“下限”来看，AI 编写的代码往往比大多数开发者更规范，因而下限更高。但从“上限”来看，人类开发者的能力仍然更强。因此在高阶开发者手中，AI 的提效更为显著；而在初级开发者手中，虽然 AI 能帮他们写代码，但他们常常无法完全理解这些代码。当出现问题时，他们不得不依赖 AI 修复 Bug，这实际上会带来 AI 应用上的反噬。

当然，AI 工具也存在弊端，比如幻觉问题。AI 难以避免在某些局部埋下隐蔽的 Bug，例如逻辑取反或边界条件处理缺失。这些问题肉眼浏览不易发现，却可能带来严重后果。因此不能过度依赖 AI，人工审查依然必不可少。

侯凡： 对我们这一代程序员来说，AI 的出现无疑极大提升了效率，因为我们经历了从零到一的编程过程，本身具备判断能力，能够正确使用 AI。但对于刚入行的年轻人来说，他们一上来就遇到强大的 AI，就像 Z 世代天生就是互联网原住民一样，他们或许会成为“AI 原生程序员”。

过去我们会担心，过度依赖电子产品会削弱思考能力。同样，现在也有人担心，年轻程序员会因为过度依赖 AI 而丧失独立思考。但换个角度看，他们从大学开始就接触 AI 编程工具，不可能拒绝它的存在，AI 会成为他们成长的必然环境。

因此更值得思考的问题是：未来的程序员应当如何与 AI 共生？他们的学习路径会否发生变化？需要掌握哪些新的知识与能力？虽然我没有明确答案，但可以肯定的是，AI 已经无法回避，下一代开发者必须学会与它共处，并找到与 AI 共同进步的方式。

观众：对于复杂业务的增量需求，业务逻辑和存量代码这块业内工具都还有差距，有什么好的优化思路和方向吗？

宁啸威： 每当一个新的 AI 模型发布时，总会有大量宣传，说它在测试集上取得了多么优异的成绩，解决了多少 SWE 问题。但在真正的生产环境中，我们面对的并不是那些人为设计的确定性任务，而往往是规模庞大、结构复杂的代码仓库，可能动辄几十万行，其中包含了大量随时间流逝而遗失在文档或代码中的业务和领域知识。

在这种场景下，AI 如何才能真正参与到效率提升中？如果是是一年前，受限于模型能力，这个问题还难以回答。但随着模型的演进，我们观察到一些趋势，尤其是“Agentic”能力的出现。新的模型更倾向于主动思考、主动感知，并且能够主动调用工具。

我认为关键在于：AI 可以作为“思考和感知的大脑”，但领域知识、专家经验和业务理解依然是人的护城河。AI 能看懂代码，却不一定能理解业务全局逻辑。所以在人机协作过程中，我们需要把业务知识提供给 AI，让它在正确的语境下发挥能力。

在公司内部，我们也在探索这方面的实践。比如字节的电商中台团队，他们通过与大模型结合，建立了专属的领域知识库，并将其接入到通用 AI 大脑中。结果显示，在一些 0~1 场景和老项目的需求迭代中，AI 的表现超出预期，带来了显著的效率提升。

我们需要做的是，把业务中那些流程化的部分固化为 workflow，而在需要创造性思考的地方，则充分利用模型的 Agentic 能力。workflow 和 Agentic 思维模式并不是对立的，而是需要融合。随着模型能力增强，未来我们可以将更多主导权交给 AI。

沈斌： 目前有没有一些公开渠道或开源项目，能作为比较好的领域知识库源头？这样我们就能借助 RAG 或 MCP，让 AI 更好地参考这些知识。

宁啸威： 无论是 RAG，还是上下文增强，或者 MCP，这些都只是手段，而不是目的。我们的目标是搭建开放生态，让业务团队能够把 AI 当作大脑接入。但领域知识库的建设并没有统一标准，不同业务的做法差异很大。例如复杂的 ToB 场景下，知识库不但需要涵盖技术文档、PRD、设计文档，甚至还要包含业务知识等；而一些内部轻量级业务，知识库形态就完全不同。共性在于技术底层，如知识图谱构建或 RAG 的实现，但具体要如何做，仍取决于业务特点。作为底层支持方，我们的职责是提供开放生态，让团队能在内部流动和沉淀这些知识。

侯凡：Agent 驱动模式要求模型对存量项目的理解越来越精准，这是趋势。但如果现在模型能力还不足以支撑超大规模代码库，该怎么办？我们的实践是走一条更务实的路线，即“辅助模式”或“session 模式”。在这种模式下，主导权交给开发者，由他们进行任务拆解，AI 提供辅助。因为在某些情况下，尽管 Agent 模式理论上效率更高，但由于准确率不足，调优成本过大，最终效果未必理想。而通过辅助模式，哪怕只是最基本的代码生成帮助，也能带来 20%~30% 的效率提升，对团队仍然有很大价值。

从点到面的落地挑战

沈斌：大家在推进 AI 研发工具和流程落地时，最大的难点是什么？是技术、流程还是人的观念？

侯凡： 我认为目前最大的问题主要是算力和 token 消耗带来的高成本。观念层面其实没有障碍，大家都认可 AI 的价值，也都愿意使用，但新的模式往往带来更高的计算消耗，对算力的需求非常大。开发者在使用 AI 时也会探索出很多自己的用法，这使得 token 消耗巨大，进一步推高了成本。

宁啸威： 成本问题确实是所有相关产品都绕不开的痛点。比如 Cursor 的定价策略多次调整，Claude Code 推出的订阅计划出现过用户花 200 美元却实际消耗上万美元算力的情况。这些都反映出算力成本限制了 AI Coding Agent 向大规模、国民级应用落地的速度。

除了成本，另一个问题是效果难以量化和提升。不同用户在使用时感受差异明显，比如有人觉得 Claude Code 在某些场景表现更好，有人则更喜欢其他 Copilot 工具的简洁。这种差异底层上受制于模型能力，而能否真正理解用户复杂需求、掌握整体代码上下文，取决于 Agent 的设计理念。如何在成本与效果之间取得平衡，是目前相关产品面临的深水区挑战。

沈斌： 我认为最大的难点在于公司管理层的认知是否对齐，尤其是一把手。企业大致存在两种情况：一种是认知落后，仍以传统方式推动研发，对 AI 提效不重视；另一种则是过于乐观，甚至认为 AI 能取代大部分研发人员，从而产生不切实际的幻想。这两种极端认知都会削弱企业的竞争力。

回到成本问题，虽然表面上 AI 的使用成本不低，但如果将 AI 视为“员工”，能带来 20%-30% 的研发效率提升，那么其投入是值得的。真正的挑战在于如何科学地量化这种提效。这涉及质与量的度量方法，本质上也是一个管理问题。

AI 重塑研发协作与架构

沈斌：AI 进入团队之后，在分工模式、协作方式，或者系统架构上，有没有发生明显变化？

我的观点可以概括为八个字：岗位左移，职级上移。所谓岗位左移，是指在 AI 提效的背景下，研发流程中的岗位会发生转移。测试向开发靠拢，开发向产品靠拢。同时，AI 会催生新的岗位，如 AI 产品经理、AI 架构师、提示工程师等，这些岗位已成为泛开发领域的重要组成部分。

职级上移更容易理解。由于 AI 对高级岗位的提效作用不如对初级岗位明显，因此未来团队中高级岗位的比例会提高，平均职级会整体上移。我们的内部尝试发现，在 AI 的辅助下，一个以高职级为主的团队，在同样成本下能交付更高的价值。

侯凡： 我是前端出身，一直关注 AI 对前端的冲击。相比代码生成，我更关注它对用户体验和交互方式的影响。传统 UI 是基于图形化的信息架构，如层级菜单，这是一种有边界的体验。而 AI 出现后，语言交互逐渐兴起，我们称之为 LUI（Language User Interface）。它打破了原有边界，从文本输入到多样化的卡片排版，都集中在对话框中。

未来可能会发展为“无边界体验”。就像抖音的推荐流替代了传统的列表浏览，AI 的生成和理解能力也可能推动交互模式发生根本变化。大家常提到钢铁侠的“贾维斯”，就是这种 AI 导向的信息系统，通过自然语言或感知触发完成交互。

AI 的出现会深刻改变前端架构，因为前端始终围绕交互模式演进。随着 AI 学习能力和理解能力的提升，它不仅能学习代码和知识库，还能理解产品结构和业务逻辑，这将带来新的框架、工具和创新。我认为 AI 不会取代程序员，而是会催生新的产品、新的技术领域和新的方法论。

宁啸威： 从后端和架构的角度看，过去流行的 SOA（Service Oriented Architecture）通过标准化接口拆分服务，以支持集成与复用。而 AI 的出现，特别是开放生态的建立，使研发和组织架构逐渐向 AI 中心化转变。比如 MCP 协议的应用，许多业务团队会在内部搭建 MCP Server，让公司内部的 Agent 能发现并使用他们的服务。这种模式可以称作 AOA（AI Oriented Architecture），或许会成为新的架构范式。

沈斌： 其实已经有一个类似的概念，叫 A2A（Agent to Agent）。

宁啸威： 未来研发组织可能会更加扁平化和网络化，由 AI 作为智能中介实现动态协作，快速匹配需求和能力，从而提高资源配置效率。

沈斌： 未来大量 Web 应用可能会消亡，包括网站和 APP，因为交互方式将转向自然语言。前端界面会极度简化，像谷歌最初的搜索框那样，而企业则主要提供后端的服务能力。

展望未来

沈斌：放眼 3~5 年，如果只能选一个方向，你最期待 AI 在研发中实现的突破是什么？

宁啸威： 我希望未来的 AI 能够从当前更像“高级工程师”的形态，逐渐向“架构师”的方向演进。这意味着 AI 不仅要具备更强的整体系统理解能力，还需要具备自我进化的能力。它能够不止停留在代码实现层面，而是参与到顶层架构的设计中。例如，当我们需要在不同技术方案或架构模式之间做出选择时，AI 可以基于现有项目特点、团队能力以及业务需求，提供更有针对性的架构建议。

未来，我希望 AI 能进一步介入顶层设计和技术决策，从而推动研发组织更加扁平化。那时，个人价值可能更多体现在战略规划和技术愿景上，而不是被琐碎的执行工作占据。

侯凡： 我认为目前所有大模型在落地过程中，最大的问题是如何更好地理解具体的项目、团队和业务。为此，我们往往需要做大量前处理，包括语料准备和知识库构建。我希望 AI 自身能够具备一定的调优能力。通用大模型的能力已经多次被验证，真正的瓶颈在于准确性和上下文感知。如果能在工具化、平台化上降低准备成本，提高效率，我相信会极大促进大模型在企业中的落地。

沈斌： 我最期待的未来是可穿戴设备的落地和普及。原因在于，当前 AI 之所以无法闭环整个研发流程，一个关键问题是缺乏感知能力，也就是所谓的“具身智能”。举例来说，AI 可以沿着研发流程完成需求分析、文档设计、代码编写、单元测试，甚至部署。但在最后的业务验收环节，它无法像人一样在真实环境中验证需求是否达标。AI 只能在模拟环境中进行验证，缺乏与真实世界交互的能力。

因此，我认为如果可穿戴设备能够发展到足够成熟，比如当前已有的智能眼镜产品，它们体积轻巧，外观与普通眼镜接近，内置摄像头和传感器，能够感知周围环境。虽然目前在续航和算力上仍有局限，但未来一旦这些问题得到改善，AI 就能借助可穿戴设备获取真实世界的反馈。设想一下，如果每位研发人员都佩戴智能眼镜，它们能将物理世界的业务反馈实时传输给 AI，那么研发流程就能真正闭环，完成需求落地的“最后一公里”，这会使整个研发体系更加完善。

听众：TRAE 的 solo 模式什么时候上线？

宁啸威： 目前这一功能仍处于内部测试或试运营阶段。如果想要体验，可以在我们海外版的 TRAE 上申请 waitlist。我们正在积极协调模型资源，这并不是刻意的“饥饿营销”，而是因为产品还在早期阶段，我们希望能以最佳的效果呈现给大家。

听众：需求转 UI、且符合公司自有设计风格，有什么好的 AI 实现思路吗？

侯凡： 每家企业都有自己的设计规范与组件库，这些规范没有对错之分，只是基于企业对体验和设计的不同理解而形成的。AI 在生成 UI 时，除了需要满足视觉效果外，还必须生成符合企业前端代码规范的代码，否则生成的内容即使看起来正确，也无法直接入库使用。

因此，目前几乎没有通用的捷径可走。要想生成符合企业内部标准的页面，唯一的方式就是提供高质量的内部语料和知识库，针对自身规范进行训练或增强。否则，AI 生成的结果往往只能停留在通用层面。

观众：请问未来程序员方向是全栈吗？

沈斌：“全栈”这个概念其实提出已久，但由于技术门槛高，真正能完全胜任全栈的人并不多。在 AI 时代，人机协同让这一点变得更可能实现。对于前端或后端出身的程序员，通过 AI 的辅助，完全可以较快地掌握另一端的平均水平。AI 已经能达到中级开发水平，对于大多数非复杂需求，它生成的代码具备较高可用性。程序员可以在此基础上进行理解和反向学习，从而提升自己的能力。

例如，Claude 在 8 月 15 日的更新中推出了三种模式：一种是“默认模式”，由 AI 一条龙完成代码编写；第二种是“解释模式”，AI 在编写过程中同步解释代码逻辑；第三种模式则会刻意留下一些 TODO 项让人类开发者完成。这种模式非常适合想要向全栈方向发展的人，通过与 AI 协同，可以更快补齐短板。

观众：领域知识库用什么做载体？是纯文本吗？

宁啸威： 目前业界普遍的做法是使用向量数据库。具体来说，就是通过 Embedding 将语料存入向量数据库，再结合检索召回来使用。近期提出的 Agentic RAG，结合了 Agent 的自我演进和反思能力，能够实现更智能的召回和上下文索引。在当前阶段，RAG 技术体系仍与传统搜索技术栈高度相关，但在大模型应用场景下，也正不断融合新的实践与方法。