Qcon 2025 分享
简介
本次大会的主题是“大模型正在重新定义软件”，围绕这一主题设置了多个演讲专题，涵盖 Agentic AI、具身智能、端侧大模型的创新与应用、AIGC 重塑内容新生产力、金融大模型的工程化实践、大模型驱动的制造革命等多个前沿领域。大会邀请了来自快手、小红书、腾讯、Amazon Web Services、Snowflake等知名企业的技术专家担任联席主席和主题演讲嘉宾。
参会回顾
本次主要围绕 Vibe Coding（氛围编程）& AI Coding 来讲解大会上的一些主题。
氛围编程与规范开发：AI 编程的双驱动引擎
氛围编程的话题在 2025 年不管是研发还是产品，都已经快成为口头禅了，包括在本次大会，只要跟 Vibe Coding & AI Coding 沾边的，基本上是完全爆满的。
Vibe Coding 带来了诸多收益，比如完全不懂编程的人员，可以借助 AI 工具快速将自己的想法变成实际应用。那么硬币的另一面是什么？
氛围编程的两面性
正面：降低入门门槛、加速原型开发、激发创意实现。儿童可以通过 Vibe Coding 快速构建应用，以及各大社交平台上“从需求到部署 10 分钟”的演示视频。
负面：信息不足、无法控制、不算真正开发。表现为用户仅描述“看起来很美”，开发者面临“为什么我不行”的挫败感。
两大“陷阱”
“看上去很美”：观众印象深刻，但开发者错误崩溃、开发过程失控。
Demo 与 Product 的鸿沟：一个 Demo 只需要 works.any() (某一次能跑通就行)，而一个 Product（产品）必须 works.all() (所有情况下都稳定) 。
“我知道我在干什么”：非专业程序员替代专业人员，或专业人员仅懂 AI 代码，导致质量隐患。
Vibe Coding 的本质问题：信息不对称。
为什么“一句话编程” 往往行不通？因为一个简单的需求，比如“帮我生成贪吃蛇游戏”隐藏 300+ 业务/技术决策（如边界处理、碰撞检测、UI 交互），凸显隐藏信息冰山。
Spec 的定义与解决问题
Spec 本质：显式化的决策集合，包括业务决策（功能、用户体验）和技术决策（架构、依赖、性能）。
作为一名开发者，不写代码的时候，我们在干什么？
你与用户交流，了解他们面临的挑战与需求。
你从这些交流中提炼出洞察，并构思出能够解决这些挑战的具体目标。
你规划实现这些目标的方法。
你将这些计划与同事分享。
你把这些计划转化为代码。
你测试并验证结果是否符合你的计划，并达成最初的自标。
这整个过程，就是 Spec。 Spec 无处不在，家电说明书、药品说明书、甚至《民法典》，都是 Spec。
Spec 与传统氛围编程的思维对比。
解决痛点
填补 Vibe Coding 的信息不足，提供明确约束。
实现可控开发，避免“真实世界”中的随意性。
支持迭代：从粗粒度 Spec 开始，逐步细化。
Vibe 与 Spec 如何协作？（以 Kiro 为例）
Amazon 推出 Kiro 工具，集成 Spec-Driven 与 Vibe Coding。Spec-driven development（规范驱动开发）正在兴起，Kiro、GitHub Spec Kit、Cursor Plan Mode 都是这个趋势的产物。
Kiro 这个工具 展示了 Vibe 和 Spec 两个模式如何协同：
Spec 模式：用于处理复杂的开发任务 。它会将你的高级想法，转化为清晰的要求、系统设计和任务 ，让开发流程规范化，并提供清晰的追踪和控制。
Vibe 模式：作为一种会话模式 ，用于快速探索、解释说明，或者在 Spec 生成的基础上进行局部微调。
一个理想的工作流是：
使用 Spec 模式，根据 Figma 设计稿或需求文档，生成一个结构清晰的登录页面。
使用 Vibe 模式，进行微调，比如“把这个按钮换个颜色”或“调整一下边距”。
目前内部，前端部门同样实践过这一套，基于内部组件规范，通过 D2C + CCode MCP 工具输出具体页面，再利用 Frieren（前端自研 AI IDE 插件）进行微调，最终将整个页面输出。
[TODO 插入演示视频或者 Gif 图片]
范式转变：
过去是：代码 → 编译器 → 可执行程序。
现在是：Spec 描述 → LLMs → 代码
人与 AI 协作的未来
我们如何与 AI 协作？分享中的“信息矩阵”给了我们一个思路：
这个矩阵分为四个象限：你知道/你不知道，AI 知道/AI 不知道。
“待描述” (你知道, AI 知道)：这是需求描述。必须清晰地把你的需求（上下文）告诉 AI。
“待学习” (你不知道, AI 知道)：这是知识学习。你可以向 AI 学习新的技术、框架或最佳实践。
剩余部分 (AI 不知道的)：这是人与 AI 共同探索的领域。
从上下文到长期记忆：大模型记忆工程的架构设计与实践
记忆是下一条性能缩放曲线
Transformer 架构的根本限制是“无状态”——每次交互仅依赖有限上下文（通常4K-128K tokens），导致“健忘症”：无法跨会话积累知识，影响 Agent 的连续性和个性化。
模型驱动决定上限，应用驱动决定下限 → 内外协同，MemOS 融合范式。
前两阶段已接近“物理极限”（数据墙、计算墙、上下文窗口墙）。记忆作为第三变量，突破“一次性推理”范式，引入持续学习、个性化、状态不存在的上下文，重启 Scaling Law。
OpenAI 已将记忆从“功能点”提升为产品主线，等同于当年从 GPT-3 到 ChatGPT 的指令微调跃迁。记忆 ≠ 更大上下文，而是结构化、可更新、可共享的外部知识系统。
为什么需要记忆增强？实践痛点
记忆增强的必要性源于实践信息流的丰富性与模型架构的局限性的矛盾。在 Multi-一切场景下，无记忆系统将导致效率崩塌、体验断裂、成本失控。MemOS 等记忆管理框架 是化解这一矛盾的系统级解法，将大模型推向个性化、持续化、生态化的新阶段。
⼤模型与⽤户⽇常交流过程中形成的信息流是模型持续迭代提升的最优资源。
对于单个⽤户的 Session ⽽⾔，需要管理：
动态信息：临时参考信息、偏好信息、系统信息、MCP 执⾏信息、任务信息、响应信息（外部、推理、反馈交互）….
静态信息：本地知识库、云端知识库…(知识处理的完整流程框架)
MemOS 系统架构（类 OS 设计）
结合上面所述，从实践层⾯的痛点来看，记忆管理框架（记忆增强层）非常必要。
五大核心层
记忆存储层：底座，MemDB + Vector/Graph DB 混合索引；MemCube 为最小单元（行业/专家/用户 Cube），MemStore 支持发布/购买；分层：内置/外置参数、激活/明文、短期/长期记忆。
记忆治理层：安全内核，权限/水印/生命周期/隐私控制；MemHaluEval 幻觉评估 + MemControl 动态权限；MemCube 注册/Loader，确保合规可信。
记忆调度层：智能大脑，MemTrigger 多粒度触发 + 主动预测；埋点/队列/线程池，结合主题/轮次建模，将记忆推至最佳层（激活/长期）；支持业务流并行。
记忆编解码层：推理桥接，MemDecoding 联合解码（Query+Context+记忆）；脑图组织：主动抽取 COT + 二次边重构；支持主题路由/关键词/跨 Session/时序检索。
记忆应用层：开发者接口，Agent/Chat/Pipeline 直调 API/MCP/本地部署；分层建模 + 调度 + 脑图无缝注入 LLM。
TRAE 的思考：AI 时代程序员的认知进化
AI 已深度重塑编程的每个环节，从古法编程逐步演进至 AI 辅助编程、AI 结对编程，直至当前的 AI 自主编程。
开发者对 AI Coding 的诉求
开发者对 AI Coding 的需求聚焦于研发提效和辅助决策两大目标。具体包括：
代码补全，用于预测光标后代码或用户下一步编辑动作；
代码生成，根据自然语言生成代码、自主分析需求、自动运行命令、分析报错并持续迭代；
代码问答，理解项目代码信息，进行问答、分析总结，辅助学习和接手不熟悉代码库；
知识研究，提供即时准确信息，帮助分析问题并支持决策。这些诉求标志着编程从手动操作向智能化协作的转变。
AI 辅助编程阶段（Coding Assistant）
从古法编程向 AI 辅助编程的过渡强调工具化支持，代码补全演进为三个层次。
基本代码提示，预测下一个字符；全面代码补全，预测编辑位置、新增或修改存量代码，提供 Tab 键连续操作的多巴胺快感；超级补全，进一步预测多行代码或修改存量代码。
代码问答从简单 Markdown 块扩展至 Artifacts，集成代码编辑器、运行环境和预览功能。
在 IDE 内，AI 通过 Inline Chat 或 Side Chat 直接集成（内部如 Frieren、Costrict 等插件），避免窗口切换复制黏贴，贴近开发者习惯，提供充足上下文，支持代码检索（如 Embedding 与 Grep 的对比，或 Agentic RAG）。
在研究场景下，AI 辅助接手新项目或开源分析，取代人工逐行梳理代码关联，颠覆传统 IDE 核心功能如 LSP 跳转，虽仍有用但不再不可或缺。代码生成引入 Fast Apply，一键合并代码，支持 search-replace 工程替换、小模型兜底或整文件替换。此外，多样上下文来源涵盖 Figma 原型图、浏览器日志、终端输出、问题描述、Git 消息、合并与审阅，AI 全面渗透 IDE 各角落。
AI 结对编程阶段（Coding Agent）
AI 结对编程引入智能体（AI Agent），从单轮对话向多轮迭代转型，强调被动接受上下文向主动获取的转变。核心要素包括自主性提升、思考能力、调度能力、工具调用和上下文获取。
现在很多⼈觉得 AI 编程很震撼，也很多⼈觉得是垃圾，其实就是没找到如何与不同阶段的实习⽣相处的⽅式，没管理好⾃⼰的预期，短期⾼估 + 长期低估。
AI 被视为每个人专属的高潜实习生，避免常见误区：
甩手掌柜式管理（缺乏充分上下文）
超出能力边界任务（如期望代码模型生成图像）
低配模型使用或预算不足。
程序员角色从执行者转向指挥官，需要系统设计能力（模糊需求转化为 PRD 和 RFC）、项目管理能力（任务拆解，理解不同 LLM 和 Agent 特性）、高效沟通能力（总结问题、提供有效上下文、纠偏）和领导力（保持素养、随时补位）。
上下文工程是协作关键，采用 @Agent with #Context /do sth 范式，提供精炼上下文；引入自定义 Agent&Commands（如 /产品经理 或 /测试验收）、规则约束；补充专有知识（如 @file、@folder）、联网检索（#Web）或其他标签（如 #Problems、#Terminal、#Console、#Figma）；避免一句话需求，强调文档分析与任务拆解。
TRAE 协作模式与 SOLO 演进
协作模式从 AI 辅助 IDE 升级为 AI 主导 IDE，以 Agent 为中心，IDE、浏览器、终端仅为可调用工具。
SOLO 模式针对专业开发者，SOLO Builder 专注 Web APP 端到端交付，集成 Figma、Vercel Deploy、Firebase 等工具，服务 1-5 人团队，实现 0-1000 用户规模应用，未来扩展更多垂直 Agent。
前端⼯程 3.0：企业级智能研发与 Agent 系统落地
前端工程在 AI 时代的演进
企业级前端研发面临多重挑战，包括领域知识的繁杂性与灵活性、研发工具的碎片化、面向用户的高标准还原需求，以及自动化质检的落地难度。
这些问题源于前端基础框架、业务框架、组件文档的多样性，工具链的不统一，以及 2C 产品对像素级还原、交互复杂性和代码可维护性的严苛要求。
AI 时代为解决这些问题提供了机遇，通过重新构建业务和技术语义、智能化升级工具体系、提升模型在UI理解与生成、代码理解以及 Agentic 能力方面的表现，实现知识整理与二次输出的效率提升。
前端工程经历了从 V0.0（围绕 jQuery 与 Prototype 的页面时代）、V1.0（Node.js 与构建工具的模块化流行）、V2.0（Svelte 与 SSR 等框架的横纵向发展）到 V3.0（AI 全面覆盖前端工程体系）的演进，进入智能研发时代。
核心原则聚焦于三大关键思路：
上下文工程，用于理解前端技术语义并提升复杂项目代码生成效果
智能工具体系，实现单个研发环节的智能化升级并覆盖更多节点；
智能工作流，结合结构化工作流与智能决策，实现研发节点的高效流转。
上下文工程 - 企业级前端研发的上下文管理
企业级上下文管理强调精准召回与系统管理能力。精准召回包括项目结构与环境信息的预置、引用池关注、编辑变更追踪、编辑副作用感知，以及基于标记的上下文片段清理和批量操作反馈聚类。
通过构建具有仓库与技术栈信息的 Agent 编程环境，并引入 mention 引用机制（涵盖文件、文件夹、网页、工作空间、终端、知识库、MCP），实现上下文的实时性、聚焦性与可纠正性，提升利用率并减少负担。
系统管理方面，支持租户与知识库隔离、多模态处理，包括知识图谱录入、组件与文档解析、文件与代码解析等预处理步骤。随后通过智能提取 QA 对与 AI 分层总结，实现组件召回、代码召回与日常答疑。
智能的工具体系 - 让工具具备智能
传统 MCP 工具虽开放度高，但存在工具质量参差、描述不清晰、交互界面不友好、用户指定成本高以及调用时机难以控制等问题。为此，引入“Agents as Tools”概念，将传统确定性工具升级为具备智能决策能力的智能工具，实现从单点问题解决向系统性复杂问题分治的转变。
以 UI 自动化为例，用户查询如“生成订单列表页数据为空的测试用例”可通过用户意图识别、代码分析、关键接口提取、Mock 数据生成、智能场景组编排、自然语言用例生成、PE 设计、多环境调度（模拟器、真机、浏览器）、执行指令生成、多模态识别与结果断言等步骤完成。
全研发生命周期覆盖智能编码（领域知识增强、D2C 组件识别）、智能调试（Console 报错修复、实时预览）、智能 Mock（场景组生成、保鲜）、智能审查（AST 与 AI 规则）、智能质检（远端与本地扫描）以及 UI 大盘（NL 用例、多模态比对）。
开放体系设计分为 UI 开放（自定义面板、共享对话）、Agent 开放（领域 Agent 状态同步、入口透出）、工具开放（内置 MCP 如 read_file、jsdoc、playwright，以及 MCP Marketplace），结合模型能力、IDE 能力与上下文注入，支持企业级研发场景。
智能工作流 - 基于 Multi-Agent 的 Agentic Workflow 实现
智能工作流旨在让每位研发者具备前端专家经验，应对用工生态复杂、新人多、专家经验难沉淀、工具碎片化、项目规范多样以及流程推进难等问题。Agentic Workflow 结合结构化工作流与自主决策，提升泛化性、可控性与可靠性，融合领域经验、工具供给、执行规则以及大模型的智能决策。
核心问题包括场景广泛性、问题动态性、上下文传递、交互易用性、上下文限制与多 Agent 一致性。工作流控制分为任务编排（意图识别拆解、任务链生成）、任务调度（Agent 执行循环、上下文收集、场景意图识别、交付注入与审查路由）以及执行层。
采用 Swarm 架构优势，实现上下文有效共享：全局上下文（需求输入、拆历史交付）、执行上下文（核心信息驱动下游）、节点私有上下文（执行细节），通过上下文循环与压缩技巧，确保信息准确传递。
“前端工程 3.0”覆盖代码生成、UI 还原、智能调试、质检、评审、埋点、单测生成等 10 余研发环节，用户覆盖蚂蚁超 40% 前端研发者，代码采纳超 220 万行，项目数超 3000，支持 8 余 BG 与数十部门定制，并开源 Neovate Code 基础能力。
