AI赋能研发新纪元：效率跃升与质量坚守的双重挑战

近年来，人工智能技术迅猛渗透至软件开发全生命周期，各式创新产品如雨后春笋般涌现，呈现百花齐放之势，而开发者的日常工作模式也在无声中重塑。效率的显著提升已成为业界普遍认知，但与此同时，软件质量与系统可信性也被推向风口浪尖：在追求开发速度的浪潮中，研发团队该如何稳固质量基石？

近期 InfoQ《极客有约》联合 AICon 直播节目特邀众安银行技术委员会主席沈斌、华为云 PaaS 首席前端架构师侯凡、字节跳动 TRAE 架构师宁啸威三位专家，从前端工程、后端架构、系统设计等多维视角，深入剖析 AI 提效在研发领域的当前实践与未来趋势。

部分核心见解如下：

• 在构思下一代 AI Native 产品形态时，核心议题是如何在人类智慧与人工智能间寻求最佳协同点。尤其在 AI 能力尚未成熟到可完全自主运作的阶段，这一交互平衡的把握至关重要。
• 无论是 RAG（检索增强生成）、上下文扩展，还是 MCP（模型上下文协议），这些技术本质上是实现路径而非终极目标。根本方向在于构建开放生态系统，使业务团队能够将 AI 作为智能中枢无缝集成。
• 未来大量传统 Web 应用与移动 APP 可能逐渐式微，因为交互范式将向自然语言对话转移。前端界面将极致简化，类似早期谷歌的单一搜索框，而企业的核心价值将更多体现在后端服务能力的输出上。

以下对话内容基于直播实录整理，由 InfoQ 进行精简编辑。

AI 在研发中的角色演进历程

沈斌：多数团队初期接触 AI 时，主要将其用于解决特定微观任务，例如编写测试用例、生成代码片段。然而当前，AI 已渗透至更多研发阶段，甚至开始影响架构决策与团队协作模式。业界常提及的 AI 时代，通常以 2022 年末 ChatGPT 的发布为里程碑，彼时被称为 AI 的“iPhone 时刻”。自此，AI 提效议题迅速升温。回顾近三年，AI 在研发中的应用清晰呈现三个阶段演变。

第一阶段是 AI 辅助编程。此阶段 AI 主要扮演工具角色，最常见形态为 IDE 插件。典型模式为：左侧是代码编辑器，右侧为聊天窗口，当需要实现小型算法或简单功能时，通过对话获取 AI 建议，再手动应用到代码中。

该模式持续约一年后，出现了以 Cursor 为代表的集成开发环境，我称之为“氛围编程 1.0 时代”。它在聊天模式基础上引入了 Agent 能力，可自主完成某些简单任务，不再局限于局部代码，而是能处理相对完整的需求，从而显著提升开发效率。

第三阶段是今年初 OpenAI 联合创始人 Andrej Karpathy 提出的 Vibe Coding 概念，催生了当前热门的 Claude Code。此形态从 IDE 进阶至 CLI（命令行）模式，我称之为“氛围编程 2.0 时代”。相比 IDE，CLI 模式虽对用户技能要求更高，但适用场景更广，定制灵活性与玩法多样性也大幅增加。

侯凡：当前网络对 AI 的评判常呈现两极分化。一方认为，AI 是下一代生产力革命，将带来颠覆性效率变革。尤其在 ToB 业务中，每日都能见证优秀实践案例。这股声音充满信心，坚信 AI 将如同当年云计算改造产业般，重塑研发工具链并大幅提升效能。另一方则在真实开发中感到“收效甚微”。他们不像技术爱好者那般兴奋，而是认为当前 AI 产出物很难直接应用于生产系统。

我相信大型企业均有类似体验。一方面，管理层怀抱高度期待，希望借助 AI 工具实现效率倍数级增长。但现实往往是，生成的大量代码难以放心直接入库。例如 Agent 模式一次生成上万行代码，但我们是否敢于将其直接提交至生产代码库？当然，AI 在个人开发场景中价值显著，如编写小游戏、演示原型或家庭应用，我本人也从中获益良多。但切换到 ToB 场景，需考量的因素则复杂得多。

因此我想抛出疑问：在 Vibe Coding 或 Agent 模式下，AI 自动生成的大规模代码，各位是否真的敢于直接部署到企业生产环境？

沈斌：我们团队近两个月才深入使用 Claude Code。从实践看，AI 尚未智能到可独立完成完整需求，更多需要开发者通过上下文与提示词引导其理解需求并编写代码。Claude 官方也提出 EPCC 开发范式：探索（Explore）、规划（Plan）、编码（Code）、提交（Commit）。这意味着 AI 仍遵循研发基本流程：理解需求、设计方案、编写代码、测试验证。

一个常见误区是期望 AI“一语搞定所有”，实际上更优做法是分阶段寻求 AI 协助。例如通过自定义 Agent 或使用 PromptX 框架定义不同角色，让其分别承担架构师、产品经理等职责，辅助完成相应环节，但每阶段结束后仍需人工审核。

我常告诫团队，AI 不会代为担责。无论代码源自 AI 或人工，最终责任仍在工程师自身。因此，AI 实际上对开发者提出了更高要求。它确实提升效率，但也要求开发者具备更强的理解力与掌控力。

宁啸威：对比一两年前，AI 已深度融入研发流程，不再仅是编写演示代码、单元测试或生成示例片段的工具，而是覆盖需求调研、PRD 评审、技术设计、测试及 CI/CD 等全环节，真正贯穿了软件交付生命周期。

我们团队内部，AI 编程渗透率已近 100%。在使用 AI 工具过程中，我们持续获得新思路与启发，也不断对产品提出优化建议。在公司层面，AI 编程备受重视，AI 工具被强力推广至各业务团队。以核心团队为例，头条与抖音前端团队对 TRAE 的使用率已处高位。过往 iOS 或安卓开发同事将 Figma 设计稿还原为代码可能需要一两天，如今通过接入 Figma MCP 生态，借助 TRAE 等工具，“设计转代码”仅需几分钟。

市面涌现众多 AI 编程产品，在真实编码场景中，决定用户口碑的关键因素之一是如何处理“人与 AI 的交互平衡”。以 Cursor 为例，它在生成代码时要求开发者参与审查，在每个环节设置检查点，允许纠偏或回滚，确保开发者对结果保持控制，此类协作模式正是其核心优势。我们近期也在探索如何构建下一代 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 生成摘要与解释，帮助评审者更快理解上下文，从而起到沟通桥梁作用。

当然，仅识别问题不足，关键在于修复。随着项目规模与复杂度增加，问题种类日益增多，AI 能否真正解决它们是项挑战。我们尝试在 CI/CD 与研发流程中引入自动化 bug 修复，让 AI 基于静态检测或评审发现问题进行修复尝试，并提交 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 修复缺陷，这实际上可能带来 AI 应用反噬。

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

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

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

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

观众：对于复杂业务的增量需求，业务逻辑与存量代码方面业内工具尚有差距，有何优化思路与方向？

宁啸威：每当新 AI 模型发布，总伴随大量宣传，称其在测试集取得优异表现，解决众多 SWE 问题。但在真实生产环境，我们面对的并非人为设计的确定性任务，而是规模庞大、结构复杂的代码仓库，可能动辄数十万行，其中蕴含大量随时间流逝而湮没于文档或代码的业务与领域知识。

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

我认为关键在于：AI 可作为“思考与感知的大脑”，但领域知识、专家经验与业务理解仍是人类护城河。AI 能读懂代码，却未必理解业务全局逻辑。故在人机协作中，我们需将业务知识供给 AI，使其在正确语境下发挥能力。

在公司内部，我们也探索相关实践。例如字节电商中台团队，他们通过结合大模型，构建专属领域知识库，并将其接入通用 AI 大脑。结果显示，在一些从零到一场景及老项目需求迭代中，AI 表现超预期，带来显著效率提升。

我们需做的是，将业务中流程化部分固化为工作流，而在需要创造性思考处，则充分运用模型的 Agentic 能力。工作流与 Agentic 思维模式并非对立，而需融合。随着模型能力增强，未来我们可将更多主导权交予 AI。

沈斌：目前是否有公开渠道或开源项目，可作为优质领域知识库来源？如此我们可借助 RAG 或 MCP，让 AI 更好参考这些知识。

宁啸威：无论是 RAG、上下文增强还是 MCP，这些仅是技术手段，而非终极目标。我们的目标是搭建开放生态，使业务团队能将 AI 作为大脑接入。但领域知识库建设并无统一标准，不同业务做法差异巨大。例如复杂 ToB 场景下，知识库需涵盖技术文档、PRD、设计文档乃至业务知识；而某些内部轻量级业务，知识库形态则完全不同。共性在于技术底层，如知识图谱构建或 RAG 实现，但具体实施仍取决于业务特性。作为底层支持方，我们职责是提供开放生态，让团队能在内部流动与沉淀知识。

侯凡：Agent 驱动模式要求模型对存量项目的理解愈发精准，这是趋势。但若当前模型能力不足以支撑超大规模代码库，该如何应对？我们实践走更务实路线，即“辅助模式”或“会话模式”。此模式下，主导权交予开发者，由他们进行任务分解，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（语言用户界面）。它打破了原有边界，从文本输入到多样化卡片排版，均集中于对话框中。

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

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

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

沈斌：其实已有类似概念，称 A2A（智能体到智能体）。

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

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

未来展望与期待

沈斌：放眼未来 3~5 年，若只能选一个方向，各位最期待 AI 在研发中实现何种突破？

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

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

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

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

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

听众：TRAE 的 solo 模式何时上线？

宁啸威：目前此功能仍处内部测试或试运营阶段。若想体验，可在我们海外版 TRAE 上申请等待列表。我们正积极协调模型资源，这并非刻意“饥饿营销”，而是因产品尚处早期，我们期望以最佳效果呈现给用户。

听众：需求直接转为 UI、且符合公司自有设计风格，有何优质 AI 实现思路？

侯凡：每家企业均有自身设计规范与组件库，这些规范无对错之分，仅基于企业对体验与设计的独特理解形成。AI 生成 UI 时，除需满足视觉效果外，还必须生成符合企业前端代码规范的代码，否则生成内容即使看似正确，也无法直接入库使用。

因此，目前几乎无通用捷径。要生成符合内部标准的页面，唯一方式是提供高质量内部语料与知识库，针对自身规范进行训练或增强。否则，AI 生成结果常仅停留于通用层面。

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

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

例如，Claude 在 8 月 15 日更新中推出三种模式：一是“默认模式”，由 AI 全流程完成编码；二是“解释模式”，AI 在编码过程中同步解释逻辑；三是“协作模式”，会刻意留出部分 TODO 项由人类开发者完成。此模式非常适合意向全栈发展者，通过与 AI 协同，可更快补齐技能短板。

观众：领域知识库采用何种载体？是纯文本吗？

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