商汤科技”从炫技到实用：AI 产品价值闭环”演讲大纲及内容整理

AI 企业落地现状分析

MIT 调研数据

• 95% 的企业 AI 落地失败：MIT 调研显示，过去一年多超过 95% 的企业侧 AI 落地项目失败，只有 5% 的企业在 PNL（损益表）上看到了 AI 的价值
• 技术与企业节奏错配：技术发展过快，企业在节奏和决心上存在错配
• 自建效率低下：企业自建 AI 解决方案的成功效率是外部专业供应商的 1/3
• 前台应用效果不佳：虽然期望 AI 在前台工作带来价值，但现在证明有效的主要是后台自动化
• 员工与管理层利益冲突：CEO 希望 AI 降本增效，但员工担心失业，会自己采购 AI 工具而不使用企业内部的 AI 系统

企业 AI 探索历程

• 早期阶段：全参数微调、预训练（算力要求高）
• 中期发展：微调、强化学习
• 当前状态：不再关注模型本身，转向各种 Agent（营销 Agent、客服 Agent、数据 Agent 等）

智能体（Agent）的定义与现状

Gartner 报告对智能体的严格定义

• 智能体洗白现象：许多低代码产品、RPA 产品重新包装为智能体概念
• 非智能体的产品：
  • 模型本身不是智能体
  • RPA 不是智能体
  • 仅结合 RAG 的产品不是智能体
  • 简单的意图分发 chatbot 不是智能体

真正智能体的核心特征

• 完整闭环：感知 → 思考 → 决策 → 行动 → 反思
  • 思考：面向任务主动选择规划路径
  • 反思：过程中发现问题及时修正
• 企业客户不关心技术黑盒，只关心端到端的解决方案和确定性的高精度结果

C 端与 B 端的差异
Agent 看上去效果很好, 但是要抽卡, C 端声量高，但企业侧落地率低

• B 端要求：
  • 确定性、高精度场景
  • 不接受”抽卡”式的随机结果
  • 需要在高精度下解决企业问题

大模型解决的核心问题

• 开放式场景：大模型主要解决开放式场景问题
• 确定性场景不适用：规则明确、容错率低的场景不建议使用大模型, AI 无法生成100%正确的答案
• 传统信息化的局限：如果场景非常确定，传统企业信息化建设已能满足需求, 不需要用大模型, 但AI 可以改善交互体验，但会带来精度下降和不确定性, 是不符合企业要求的, 看下来目前 AI 对企业侧还没有完全 ready

市场机遇与政策支持

政策红利

• 人工智能+ 政策：类比 10 年前的”互联网+”政策，催生了 BAT 等头部企业
• 具体目标：2027 年实现 70% 以上的终端智能和智能体应用
• 市场空间：政策落地后将有配套实施政策，市场需求旺盛
• 供给不足：供给侧还无法完全解决市场需求, 有巨大的空间
• 蓝海机遇：怎么为企业和个人提供巨大的商业化价值

不同层级的价值需求

企业 AI 价值价值是什么?

• 企业层面：管理价值，战略部署实施，标准程度低但企业价值高
• 团队层面：协同价值，解决部门间沟通协同、部门墙等问题
• 个人层面：降本增效，包容程度高但企业价值低

从下到上, AI 对企业的价值越高; 从上到下, 标准化程度越高

• 效率瓶颈：企业效率瓶颈不在个人，而在部门间协同
• 沟通策略：与不同层级人员沟通需要针对其关注点

价值实现的挑战

中国开源模型发展迅速,许多企业开始自己部署开源模型（如文心一言、千问等）

• 采购额度低：上半年公开招投标的大模型一体机采购额仅 1400 万
• 热度与实际落地的差距：虽然 AI 热度很高，但企业真正大额采购和使用的比例很低
• 根本原因：企业需要的不是模型本身，而是场景化的价值和可量化的提升

商汤的 AI 原生产品策略

• 能力工程：底层技术能力
• 数据飞轮：数据处理和循环利用
• 交互优化：用户体验提升
• 工作流协作：企业流程整合

合作伙伴策略

• 行业 Know-how：与垂直领域合作伙伴结合
• 专业分工：商汤专注底层 AI 能力，合作伙伴提供行业专业知识
• 创业趋势：越来越多行业专家选择 AI 创业，寻求专业 AI 公司合作

AI 面向个人使用工具的愿景

• PC 时代：Office 套件，基于电脑能力实现专业模板和原子化能力
• 互联网时代：云协同，垂直场景工具（如 figma）
• AI 时代：跨平台、跨数据源，从过程交付到价值交付

AI 时代的特点

• 数据处理能力：处理大量非结构化、结构化数据
• 知识关联：强大的知识关联能力
• 场景适配：复杂场景、多样场景的理解和适配
• 人机协同：结果导向的人机协同工作模式

商汤数据分析智能体产品

产品整体图

• 2024年1月：发布国内第一个数据分析智能体, (那时候还没有智能体这个概念)
• 核心发现：大模型具有强大的工具调用能力
• 技术能力：
  • 调用本地电脑和沙盒
  • 代码编写能力
  • 数据可视化
  • 文件分析

给跟大模型离的不是那么近的用户群体做推广

• 真实用户：老师、学生、医生、制造业管理者、大巴司机等
• 用户特点：日常工作中与 AI 接触不多，但发现产品能实际解决问题
• 产品迭代：从 1.0 对话框产品模式到 2.0 针对简单/复杂场景数据分析能力，计划年底推出 3.0, 仍需要平衡模型与用户体验

产品精度保证

技术路径选择

为什么不选择 ChatBI/Text2SQL：

• SQL 局限性：SQL 主要用于数据库查询，不适合业务数据分析
• 精度问题：SQL 语言数据量有限，模型精度只有 80% 多，企业无法接受
• 数据库依赖：需要成熟数据库，但很多企业数据以表格、文档、图片形式存在, 即使头部公司的数据库建设也不完善

对于企业用户推广:

• 客户验证：头部客户几百个真实用户实测
• 用户角色：运营、商务等业务人员
• 精度要求：95% 以上准确率，保证企业侧可用性

C 端到 B 端的转化路径

• 增量价值：数据分析为员工提供增量价值，不会威胁工作
• 实际案例：销售人员用于商机动态管理和查询
• 采购动机：业务部门主动要求私有化部署或系统对接
• 正向激励：帮助员工更好管理工作，对 KPI 和职业发展有正向作用

突破传统模式

• 自下而上：业务部门主动找到产品方
• 打破壁垒：解决自顶向下和自底向上的矛盾

技术精度突破

• 百分百准确率：大模型做不到 100%, 但是在语义相对清晰的情况下，大模型调用工具可达到 100% 准确率
• 适用场景：
  • 持续计算
  • 数据匹配
  • 数理计算
  • 异常检测
• 前提条件：用户语义相对清晰

企业问题解决

• 系统连接：连接企业系统和本地数据
• 行业知识结合：结合企业和行业 Know-how 进行深度分析
• 数仓集成：与企业数据仓库结合

失败案例分析

金融公司财务部门推广失败：

• 容忍度低：财务数字绝对不能出错, 场景容忍度非常低
• 专业性高：财务人员操作极其专业，10 秒能解决的问题觉得 AI 太慢
• 用户反馈差：导致后续无人使用

成功场景特征

• 增量价值明显：对用户有明显的增量价值
• 容忍度较高：场景容忍度比较高
• 适用场景：
  • 企业运营：趋势分析报告、供应链管理
  • 商务产品：不是非黑即白的工作环节
  • 数据分析能力不强的业务人员

传统 BI 的问题

• 低代码困境：
  • 专业开发人员觉得拖拉拽太复杂，宁可写代码
  • 业务人员觉得拖拉拽太复杂，宁可找人帮忙
• 定位模糊：既要又要还要，导致上不下的产品定位

产品功能优化

二次编辑能力

• 核心需求：AI 生成结果不是 100%，但最终交付必须是 100%
• 支持格式：Excel、PPT、文本等可二次编辑文档
• 表格编辑：针对格式、数字、颜色等的二次编辑功能

用户体验优化, 相比精度提升 1-2 个点，快速编辑功能用户感知更强, 显著提高用户黏性

任务规划模块（2.0 功能）

开发背景

• 用户调研发现：60% 用户满意，40% 觉得不可用
• 不可用原因：
  • 用户不知道自己的需求
  • 分析数据不全
  • 无法给出更好的分析结果

解决方案

• 意图完善：判断用户意图是否完整，意图不完整的话, 通过引导式方式帮助用户明确需求
  • 数据补充：通过数据调用、联网检索等获取更多专业数据
• 任务拆解：帮助用户做分析思路大纲拆解,用户确认后给出最终结果

任务规划的产品理念

• 像向领导汇报工作一样，先确认需求再执行
• 解决一句话生成复杂结果但需求不清晰的问题
• 避免等待很长时间后发现结果不符合预期

商业模式与合作策略

• 商汤优势：算法、ToB 交付能力
• 商汤劣势：垂直领域行业 Know-how
• 策略选择：专注行业适应性强的通用场景

行业覆盖

• 通用性强：数据分析流程相对通用，类似代码
• 广泛应用：教育、医疗、金融、零售等各行各业
• 合作模式：与合作伙伴结合行业 Know-how，商汤提供技术底层

AI vs 传统 BI 的差异

• 定位差异:
  • AI 不是要代替 BI, AI 主要是做数据库清洗整合、跨系统融合, 在已有数据要素基础上，结合行业 Know-how 做深度分析
• 推动方式差异:
  • 传统 BI：IT 部门牵头
  • AI 方案：业务部门发起，IT 部门配合落地部署

解决的问题:

• 平台与业务部门协调：解决过去平台和业务部门关系不友好的问题
• 双赢结果：帮助平台部门完成 KPI，帮助业务部门找到有用产品

客户案例分析

头部消费电子公司案例

• 时间线：2023年7月接触，年底正式上线
• 业务痛点：
  • SMB 部门大量业务运营数据分散在各系统
  • 业务人员不擅长 Python 数据分析
  • IT 提单需要 2 周到 1 个月才能生成报告, 业务很难快速发展

解决方案与效果

• 实施周期：1 个月系统设计，2 个月内完全上线 POC，月底付费
• 人力投入：仅需 2 人，传统 BI 可能需要 10 人以上
• 效果提升：
  • 分析周期缩短 90% 以上
  • 超过 70% 业务人员明显受益

企业服务方法论

• 头部企业服务流程
  1. 业务部门试用：优先找业务部门
  2. 需求收集：收集业务需求
  3. 内部部署：与 IT 人员共同构建平台
  4. 种子用户测试：内部招募种子用户
  5. 大批量上线：测试成功后大规模推广
• 小企业服务模式
  • 轻量化推广：相对简化的推广流程 saas

时间优化, 从最早的 3 个月缩短到最快 2 个月, 但私有化还是很难

市场推广策略

客户沟通重点

• 不谈技术：不讲模型、不讲 benchmark
• 关注价值：重点讲案例、效率提升、收入增长

客户选择标准

• 有资金实力：有预算支持
• IT 实力：有一定的 IT 实施能力
• 合作意愿：愿意共建和探索
  比如金山

市场推广节奏

• 当前阶段：头部企业和C 端用户为主
• 中腰部市场：预计 2026-2027 年才会完全起来
• 策略重点：与行业最强企业合作，打造标杆案例后向下推广

总结与展望

• 从炫技到实用：AI 产品必须解决实际问题，创造可量化价值
• 场景选择关键：选择合适的应用场景比技术本身更重要
• 价值闭环：从技术能力到用户价值到商业价值的完整闭环

本期聚焦 2025 年 Swift、SwiftUI、SwiftData 的表现，其他内容涵盖 CloudKit 实战、Non-Sendable 设计、依赖加速、2D 照片变 3D 场景等

Lua 5.5.0 已经正式发布。所以，skynet 的 Lua 版本也随之升级。

skynet 维护了一份修改版的 Lua ，允许在多个虚拟机之间共享函数原型。这可以节省初始化 Lua 服务的时间，减少内存占用。

跨虚拟机共享函数原型最困难的部分是函数原型会引用常量字符串，而 Lua 在处理短字符串时，需要在虚拟机内部做 interning 。所以 skynet 的这个 patch 主要解决的是正确处理被 interning 的短字符串和从外部导入的函数原型中包含的字符串共存的问题。具体方法记录在这篇 blog 中。

这个 patch 的副产品是允许在多个 Lua VM 间共享常量表。打了这个 patch 后，就可以使用 skynet.sharetable 这个库共享只读常量表了。

这次 Lua 5.5 的更新引入了 external strings 这个特性，已经大幅度减少了 Lua 加载字节码的速度。我比较倾向于在未来不再依赖额外的 patch 减少维护成本。所以建议新项目避免再使用共享常量表，减少对 patch 过的 Lua 版本的依赖。

---

Lua 5.5 基本上兼容 Lua 5.4 ，我认为绝大多数 skynet 项目都不需要特别改动。但在升级后，还是建议充分测试。注意：更新仓库后，需要用 make cleanall 清除 lua 的编译中间文件，强制 Lua 重新编译。直接 make clean 并不清理它们。

Lua 5.5 有几处更新我认为值得升级：

1. 增加了 global 关键字。对减少拼写错误引起的 bug 很有帮助。skynet 自身代码暂时还没有使用，但后续会逐步添加。

2. 分代 GC 的主流程改为步进式进行。过去版本如果采用分代模式，对于内存占用较大的服务，容易造成停顿。所以这类服务往往需要切换为步进模式。升级到 Lua 5.5 后，应该就不需要了。

3. 新的不定长参数语法 ...args 可以用 table 形式访问不定长参数列表。以后可以简化一部分 skynet 中 Lua 代码的实现。

0️⃣ 🐼 序章：回疆的慢车与急惊风 回疆，赛里木湖畔的数字荒原。 这里是系统资源的边缘地带，网络带宽如同细细的涓流。大熊猫侯佩正蹲在一块虚拟的岩石上，第 10086 次尝试刷新他的“高德地图导航”。

做独立产品这件事，说起来容易，真动手了才知道水有多深。这是一个独立开发者将职场小需求变成主力产品的真实故事。我们将跟随 Zipic 作者十里的视角，一起回顾产品从 0 到 1 的全过程。本篇聚焦产品设计与决策思考。

Mac App Store 固然使用简单，但可能并不适合所有的产品。本文中，我们将跟随 Zipic 作者十里的视角，来解决一款 macOS 独立应用的分发与售卖问题。

图片压缩软件还有什么技术难点？本文充满了硬核、实用的 macOS 开发经验，从 SwiftUI 的组件适配到 Core Graphics 的底层应用，从 Raycast 扩展的集成到 PDF 压缩的实现，不仅解决了性能瓶颈，更让原生体验达到了极致。

AI × 大前端性能稳定性：快手亿级 DAU 下的智能诊断实践

近期AI赛道异常“内卷”，硅谷甚至出现了“996”乃至“007”的新闻。AI在编码（如Cursor、Anthropic）和解决复杂问题（如ACM竞赛夺冠、IMO金牌水平）上的表现，似乎已超越大部分程序员。

这引发了一个普遍的焦虑：AI coding + AI debug 是否将形成一个完美闭环，从而替代程序员？
然而，在快手这样拥有亿级日活（DAU）的复杂业务场景中，我们的实践表明，需要冷静看待这一议题。AI并非替代者，而是团队产出的放大器。今天的分享，将围绕快手在性能稳定性领域如何利用AI进行智能诊断与实践，揭示AI在真实工业场景中扮演的角色。

快⼿性能稳定性背景

发展历程

快手移动端稳定性建设经历了四个清晰的阶段：

• L1 基础可观测（2019）： 自研APM，替换Bugly，建立基础监控能力。
• L2 工具平台化（2021）： 专注于具体稳定性问题的治理，诞生了KOOM等开源工具。
• L3 体系化运营（2024）： 构建故障防御体系，推出Holmes（排障）、Ekko（应急处置）等系统。
• L4 智能化探索（2025~至今）： 引入AI，追求成本与效率的最优解。

每个阶段都基于上一阶段的成果进行迭代，这与移动互联网发展的节奏同步。

当下与未来的核心挑战

尽管硬件性能（如iPhone）已提升百倍，软件架构（如GMPC）演进多年，但大前端的性能稳定性问题远未解决。复杂性体现在多个维度：

• 业务复杂： 用户操作、数据、物理环境千变万化，不可穷举。
• 技术栈复杂： 原生、React Native、Flutter、H5、小程序等多栈并存，运行时机制、内存模型、线程模型差异巨大。
• 系统机制复杂： 深入底层（ART、V8、内核），疑难杂症多。
• 协作复杂： 跨团队快速迭代，质量保障难度高。

从算法复杂度视角看，我们解决问题的“算法”本质未变，但“输入”却因业务增长和技术栈扩张（如新增鸿蒙）而急剧增加，导致问题规模（年报警事件超150起，必解问题超2000个）庞大。

团队困境：资源错配与成长瓶颈

我们观察到团队中一个普遍的困境：

• 专家工程师深陷于解决只有他们能处理的复杂Bug，时间被占满。
• 普通工程师因经验不足无法解决这些Bug，难以快速成长。
• 结果是，两者都无法有效成长，形成恶性循环，最终影响系统稳定性。

AI的机遇正在于此——它有望成为打破这一循环的放大器，将专家经验沉淀和复制，赋能整个团队。

AI x 性能稳定性介绍

AI x 稳定性：整体策略与架构设计

战略聚焦：从问题处置切入

稳定性体系覆盖研发生命周期多个环节（开发、测试、监控、排障、应急处置）。我们选择从 “问题处置” 切入，因为这里是消耗研发时间最多的“重灾区”。问题处置又可细分为：

• 根因排障（慢性病治疗）： 复杂的、偶发的、需要深度推理的问题。
• 应急处置（急诊抢救）： 突发的、需要快速止损的线上故障。
  这与大语言模型（LLM）在信息总结、逻辑推理、方案生成方面的能力高度契合。

实施架构：面向Agent的演进

我们判断，AI在工程领域的落地形态将是 “Agent（智能体）” 。因此，我们从一开始就以可扩展的Agent框架为基础进行架构设计。

我们的性能稳定性Agent架构分为四层：

• Agent业务层： 承载具体场景的智能体，如根因修复Agent、故障应急Agent、指标巡检Agent。
• Agent产品层： 定义与用户的交互形态，如生成Kim报告、自动提交MR修复、多轮对话、流式响应。
• Agent框架层： 提供技术支撑。我们选择了灵活性强的AutoGen框架，支持Agent编排、链式规划、图编排，以及ReAct、CoT等推理策略，并能与Claude Code、Gemini CLI等协同。
• Agent基建层：
  • AI基建： 灵活选型模型（轻量/深度/多模态），通过MCP（Model Context Protocol）将内部平台（如监控平台Keep）工具化，结合RAG进行知识增强。
  • 服务基建： 确保Agent系统本身可观测、可调试、可降级、成本可控。这是系统能否稳定运行的关键。

实践一：实践：AI 辅助根因排障

AI辅助根因排障——从“破案”到“自动修复”

从棘手案例说起

一个典型的NPE（空指针）崩溃，堆栈全是系统代码，无业务逻辑。它仅在特定活动场景下偶发，现场信息缺失，线下难以复现。直接将此堆栈扔给ChatGPT，它能解决吗？ 实践表明，非常困难。

调研数据显示，96%的研发认为日常排障有痛点，其中69%认为现场信息太少，50%认为日志太多。行业数据也指出，开发者35-50%的时间花在调试验证上。这印证了我们的新范式：“Code is cheap, show me the (bug-free) fix.”

排障的本质与AI能力边界

排障本质上是逆向推理的认知活动，与侦探破案高度相似：

1. 观察与数据收集（勘查现场）
2. 提出假设（推测嫌疑人）
3. 设计并执行实验（验证推测）
4. 确认解决方案（定罪）

AI的能力在此链条上并非均匀：

• 擅长区（激发与引导）： 信息总结、模式匹配、基于专家经验规则进行初步分类。
• 薄弱区（需人机协同）： 模型能力有上限，对垂直、私域工具的使用需要学习。
• 瓶颈区（需分治规避）： 受限于推理深度、上下文长度，易产生幻觉。对于“越查越深”的Bug，需要人工提前拆解步骤。
  

核心工具：Holmes——动静结合的排障“现场还原”

我们自研了Holmes排障工具，核心思路是动静结合：

• 静态信息（Tombstone）： 日志、崩溃堆栈、内存快照。相当于“死亡现场”。
• 动态信息（Debugger）： 调试器、性能分析器、动态追踪。相当于“一步一步死给你看”。

特别是Holmes UI视图，它能在崩溃时捕获：

• ViewTree元信息： 布局、状态、文本、图片资源。
• TouchEvent元信息： 触摸事件响应链和轨迹。
• Activity/Fragment元信息： 生命周期状态。
  通过AI逆向推理，可以从这些信息中还原用户操作路径，极大辅助定位问题（例如，精确指出是点击了哪个按钮后发生的崩溃）。

实施路径：Agent编排与上下文工程

面对Holmes采集的海量、复杂信息，我们通过Agent编排来让AI消化：

1. 故障概览Agent： 先汇总基本信息（版本、堆栈、基础代码上下文）。
2. 基于规则分类： 根据专家经验规则，将问题分配给专项Agent（如UI崩溃Agent、空指针Agent）。
3. 专项排障Agent： 例如UI崩溃Agent，它会调用MCP工具获取详细的UI日志和源码，进行分析，最终生成修复Diff或报告。

提升准确率的关键在于“上下文工程”，目标是达到“适定问题”状态：

• 欠定问题（信息太少）： 会导致输出模糊、幻觉。
• 超定问题（噪声太多）： 会稀释注意力，导致误导。
• 适定问题（恰到好处）： 为Agent提供单一职责、直接相关的上下文，才能获得确定性解。我们通过Few-shot示例和量化标准来逼近这一状态。

AI x 根因排障：效果展示

拓展：AI火焰图分析

性能分析的火焰图数据量巨大（十几秒可能产生60MB数据），分析门槛高、效率低、易遗漏。

我们的方案是：

• 数据预处理： 对原始火焰图数据进行压缩、初筛、关键事件关联。
• AI分析层： 让AI理解性能数据，自动分析卡顿、启动、帧率、功耗等多维度问题，直接定位到源码并给出优化建议，将分析过程从“小时级”缩短到“分钟级”。
  

实践二：AI 加速应急处置

AI加速故障应急处置——与时间赛跑

应急场景的挑战

以iOS 26升级导致大量历史版本App崩溃为例。传统手段各有局限：

• 商店更新： 覆盖率低（一周约50%），用户流失风险大。
• 回滚： 对系统级变更无效。
• 热修复： 涉及大量版本和历史代码，工作量大，且最关键的是不够“急”。

应急处置的核心在于时效性，必须与故障扩散赛跑。

核心武器：Ekko——线上“时光倒流”

我们自研了Ekko安全气垫系统，其核心思想是：在崩溃发生后、应用闪退前，动态修改程序执行流，让其“跳回”安全状态继续执行，实现类似游戏“R技能”的时光倒流效果。

Ekko 崩溃阻断：覆盖所有崩溃类型

Ekko是 “售后方案” ，只在崩溃发生时触发，避免了无异常用户端的性能损耗，保证了安全性。

AI赋能应急处置流程

即使有了Ekko，配置和使用它依然复杂（需指定跳转地址、恢复上下文等），在紧急状态下人工操作易出错、易遗漏。

我们引入故障应急处置Agent，实现：

1. 自动分析： Agent接收报警，自动分析故障维度（如操作系统、芯片型号、版本分布），快速界定影响范围。
2. 辅助决策： 根据分析结果，建议是否启用以及如何配置Ekko兜底。
3. 生成与发布： 自动生成兜底配置，并串联流水线完成白名单、审核、灰度、全量发布流程。

在“黑天鹅”事件中（如某次误操作导致千万级崩溃），AI冷静、全面的分析能力，能有效避免人在高压下的决策失误。

总结与展望：认知提升与人机协同

Agent开发的核心感悟

• 思维切换（Thinking in LLM）： 从图灵机的确定性思维，转向理解LLM的概率自回归本质。明确其能力边界（擅长/薄弱/瓶颈区），知道何时用模型、何时用程序、何时用工具。
• 识别与释放瓶颈： 提示词工程无法突破模型认知上限，但能激发其表现。在模型推理深度有限的前提下，需基于专家知识提前做好任务拆解（分治）。
• 评测体系至关重要： 建立科学的Agent能力评估体系，其重要性不亚于上下文工程。这关乎迭代效率和成本控制。

回顾初心：AI是放大器，而非替代者

回到最初的焦虑，Linus Torvalds的观点值得深思：“代码的审查和维护本身就充满挑战。” AI不会改变这一本质，而是帮助我们更好地应对它。

我们的结论是：

• 人类弱化（生产力释放）： AI将接管“体力型”排障和“死记硬背型”任务。
• 人类强化（思考力升级）： 工程师将更聚焦于辨别因果、验证结果、系统性思考、创造性实验以及深度的业务理解与战略决策。

未来展望

在快手亿级DAU的复杂战场上，AI × 性能稳定性的探索刚刚启航。未来将是人机协同（Human in/on the Loop） 的深度结合。我们应积极拥抱AI，将其作为强大的杠杆，释放工程师的创造力，共同应对大前端领域越发复杂的稳定性挑战，奔赴星辰大海。

在过去的几天里，我回顾了这一年来 Swift、SwiftUI 以及 SwiftData 的演进。总的感觉是：惊喜虽不算多，但“成熟感”却在不经意间扑面而来。

---

AI Coding 实践：PRD 到代码直出的探索

• 分享分为四个环节：
  1. AI Coding 在客户端领域的发展阶段与现状
  2. 客户端AI Coding的关键解法
  3. 实际业务场景与需求分析
  4. 总结与展望

---

AI Coding 发展史和现状

AI模型发展速览

自2017年Google提出Transformer后，AI在各领域实现突破。
2023年起，大语言模型商业化加速，年增速达30倍以上。
AICoding 领域是发展最快的学科之一，因为反馈机制明确（“对就是对，错就是错”）。

AI Coding 发展的五个阶段（人机协作视角）

阶段	描述	人机角色	典型能力
L1	人类主导，Agent实时辅助	人主导，AI辅助	代码提示（如GitHub Copilot）
L2	人类布置任务，Agent生成代码	人布置单一任务	单一任务代码生成
L3	人类设定范围，Agent推进多环节流程	人设定范围，AI推进流程	生成方案 + 生成代码
L4	人类输入PRD，Agent端到端交付	人输入PRD，AI端到端交付	需求解析 + 架构设计 + 编码
L5	人定义目标，多Agent分工协作	人定义目标，多AI协作	多Agent模拟完整软件团队

• L4阶段 前端领域已有产品（如“Lovable”），

“直出”型产品的现状与挑战

• 文字稿提到：
  • 前端已有“直出”产品（如Lovable、Bolt.new），可用自然语言直接生成可运行应用。
    • 
  • 客户端领域曾有一款叫 Builder.ai 的产品，但在2025年7月左右“爆雷”，据称背后有700多名工程师，被质疑是否真为AI驱动。公司估值从18亿跌至零，客户端直出仍存巨大挑战。
    • 

客户端AI Coding的独特困境

从技术栈视角看客户端

• 技术栈碎片化：
  • 前端：标准化高（HTML/CSS/JS）、框架集中（React/Vue）。
  • 客户端：平台碎片化（iOS/Android API版本差异）、框架分散（SwiftUI、UIKit、Jetpack Compose等）。
• 构建与调试：
  • 客户端编译耗时、真机调试必要，反馈循环慢。
• 开发模式：
  • 前端热重载实时反馈；客户端生命周期复杂，架构模式多样（MVVM、VIPER等）。

从AI 模型视角看客户端

• 构建与调试复杂：编译时间长、真机调试必要，反馈循环缓慢。
• 训练数据稀缺：高质量客户端代码多在企业内部未开源，公开数据规模小。
• 代码模式多样：架构演进复杂（如Android从Activity到MVVM+Compose），上下文理解成本高。

结论

“前端开发像是在标准化、开放的乐高环境中工作；客户端则像是在碎片化、半封闭的复杂系统中进行精密工程。”

---

客户端AI Coding的关键解法

Mobile-SWE-bench

科学评测体系的建立：从SWE-bench到Mobile-SWE-bench

• **SWE-bench**：由普林斯顿与芝加哥大学推出，基于真实GitHub Issue，要求AI生成PR来修复问题，以单元测试通过率为评测标准。

  • 

• 局限性：侧重于Bug修复而非功能实现，项目多集中后端，缺少移动端特有考量（如UI还原、多模态输入）。

• 移动端评测 Mobile-SWE-bench：

  • 核心要素：高质量真实PRD、多模态输入（PRD+Figma）、详细测试用例、历史Commit基线、多维度评测方法。
    • 
  • 评测方法：人工评测、自动化测试、渲染树约束检查、视觉语言模型评估。
    • 

热门Coding Agents表现如何

把整个需求的测评级分成三类, 可以看到哪怕是业界比较火的一些模型放在测试集中表现也
一般, 30%已经算是很高了.
为什么这些 Code Agent 都表现不佳?

PRD的拆解与微调：将需求转化为结构化任务

PRD 是 “产品需求文档”(Product Requirements Document) 的缩写. 在传统的软件和产品开发流程中，PRD 是一个核心文档。它由产品经理（或业务分析师）撰写，详细描述了一个产品、功能或项目应该做什么、为谁而做以及要达到什么目标。

一个典型的 PRD 通常包含：

1. 背景与目标： 为什么要做这个功能？要解决什么问题？业务目标是什么？
2. 用户角色与画像： 为哪些用户设计？
3. 功能需求： 详细的功能描述，包括用户场景、操作流程。
4. 非功能需求： 性能、安全性、兼容性等要求。
5. 成功指标： 如何衡量功能是否成功（如用户使用率、性能提升等）。
6. 设计原型/线框图： 可视化地展示界面和交互。

这里探讨的是一种前沿的、由AI驱动的开发范式。在这个范式中，PRD 的角色发生了根本性的转变：

1. 从“给人看”到“给AI看”：
   • 传统PRD是写给开发、测试、设计等团队成员看的，需要人类的理解和解读。
   • 在AI Coding实践中，PRD（或其结构化、AI友好的变体）是直接输入给AI智能体或大语言模型的“高级指令”。
2. 成为AI的“蓝图”：
   • AI（例如GPT-4、Claude 3、DeepSeek等）会分析、理解PRD中的需求。
   • 基于对需求的理解，AI可以自动或半自动地执行后续开发任务，例如：
     • 生成技术设计： 设计系统架构、数据库Schema、API接口。
     • 直接生成代码： 产出前端、后端、测试代码的初稿。
     • 生成测试用例： 根据需求描述编写测试场景和脚本。
3. 对PRD质量的要求更高：
   • 必须更加清晰、无歧义、结构化。 AI无法像人类一样通过模糊的上下文或沟通来“猜”出真实意图。
   • 可能需要使用更标准化、机器可读的语言来描述需求，或者结合结构化数据（如流程图、状态图、清晰的验收标准列表）。

核心上下文 - PRD

• 核心上下文 - PRD：PRD是核心上下文，但当前PRD质量参差，AI难以聚焦。
  • 
  • 问题本质：PRD拆解是一个领域特定的命名实体识别（NER）任务，即从PRD中识别“UI控件实体”。
    • 
  • 控件实体分类：参考Apple HIG与Material Design，分为输入类、按钮类、浮层面板、导航栏、内容展示类等。
    • 
    • 
  • 微调方法：采用LoRA（低秩适配） 对模型进行轻量微调，显著提升控件识别的准确率与召回率。
    • 
    • 
  • 微调效果：带图评测的多模态模型F1分数达0.85，显著高于基线（0.57）。
    • 
    • 

UI高还原度出码：从设计稿到代码的准确转换

• 低还原度原因：
  • 
  • Figma设计稿不规范（绝对布局、标记不清）
  • 大模型存在幻觉（布局复杂时推理错误）
  • 还原度低，人工审核成本高
• 还原度检测流程：
  • 
• 还原检测方案和挑战：
  • 
• 还原度检测方案对比：
  • 
  • 静态代码分析：通过LLM推断约束关系，检测率**88.5%**，无需编译，易集成。
  • 运行时渲染树检测：需编译运行，检测率仅55.4%，链路集成难度大。
• 优选静态方案：通过约束信息与样式Token比对，实现高效高精度检测。
  • 

UI组件召回：避免重复造轮子，提升代码采纳率

• 组件召回闭环迭代
  • 问题：AI生成代码未使用企业内部组件，导致采纳率低。
    • 
  • 解法：基于代码上下文与开发意图，智能召回组件库中的最佳匹配组件。
  • 进化机制：通过UI自动化采集运行时属性与截图，自动构建训练数据集，实现组件的持续自学习与迭代。
    • 

---

典型业务场景与需求分析

一个实际的业务场景和需求分析, 用户登录页面，包含手机号输入框、密码框、登录按钮、忘记密码链接及成功/失败反馈。
流程:

1. PRD
2. 控件识别（手机号输入框、密码框、登录按钮、忘记密码链接）
3. 逻辑聚合(登录成功Toast、失败弹窗）
4. 结合企业组件库与设计规范生成代码

端到端提升：定制化Code Agent在Easy/Medium/Hard需求集上，比通用Agent（如GPT-5、Claude）提升约10%。

---

总结与展望

核心结论

客户端实现PRD到代码的完全直出目前尚不可能，但可通过“评测驱动子能力提升”路径逐步推进。
应关注四个关键课题：
1. 如何构建科学的端到端评测体系？
2. PRD该如何拆解、拆解到什么粒度？
3. 如何保证UI高还原度出码？
4. 如何实现组件的智能召回与闭环迭代？

未来方向

• 生产级评测集：积累真实PRD、Figma、Commit、测试用例等数据。
• 流动闭环的企业知识库：融入自动化流程，实现数据自收集与模型自进化。
• 全周期覆盖：从编码扩展至测试、CR、Bug修复、发布全流程。
• 跨平台垂类Agent融合：实现跨系统复杂任务的端到端闭环。

AICoding 核心价值

• AI Coding不是完全替代开发者，而是作为“副驾驶”提升效率、规范流程。
• 客户端AI落地的关键在于：高质量数据、领域适配、工程化闭环。
• 长期来看，AI将重新定义软件生产流程，推动研发模式向智能化、自动化演进。

Swift 与 Objective-C 最大的区别之一，就是 Optional（可选值）机制。 它从语言层面解决了“空指针崩溃”的问题，但如果使用不当，也可能引入新的 Crash。

这边文章是 Qcon 上海站 2025 来自支付宝的KMP分享总结, 主题为”AI Agent编码助手实战：面向KMP原生跨端实现研发提效”
文章参考: 支付宝 MYKMP 原生跨平台解决方案
文章参考 : AI Agent 编码助手实战：面向 KMP 原生跨端实现研发提效

AI Agent编码助手实战：面向KMP原生跨端实现研发提效

背景介绍：支付宝KMP原生跨端架构

本次分享首先对相关核心技术术语进行说明：

术语名称	术语介绍
KMP（Kotlin Multiplatform）	JetBrains 基于 Kotlin 推出的一套跨端框架，允许开发者使用 Kotlin 语言编写一次业务逻辑代码，然后将其编译成适用于多个平台的原生应用、Web 应用或服务端应用。
CMP（Compose Multiplatform）	JetBrains 提供的一套基于 Compose 基础库的声明式 UI 跨端框架，支持在 Android、iOS、桌面和 Web 开发共享 UI。
支付宝 KMP 原生跨端	在 “Kotlin + Compose Multiplatform” 的基础上，为支付宝终端开发者提供一整套完善的跨端框架能力。
AntUI 组件库	基于 Compose 编写的支付宝 UI 组件库，包含丰富且风格统一的 UI 组件。
OHOS、Harmony	OHOS 是鸿蒙项目的开源操作系统基底，而 HarmonyOS 是基于 OHOS 打造的商用智能终端操作系统。

KMP原生跨端的核心优势在于显著减少为不同平台重复开发的工作量，同时能保持各平台原生的最佳用户体验。

支付宝在基础KMP架构上进行了深度扩展，构建了增强型跨端框架，其分层架构如下：

• MY CMP -> UI与体验层：
  • 双渲染管线：除CMP默认的Skiko引擎外，自研了Canvas渲染引擎，以在内存、滑动流畅性等方面实现性能优化。
  • AntUI高阶组件库：提供丰富的企业级UI组件。
  • 自动化能力：集成自动化埋点（无需手动添加点击等事件上报）、UI重组耗时检测工具。
  • 运行时监控：对线上ANR（应用无响应）、掉帧、无限重组等问题进行监控。
  • 原生组件嵌入：支持在Android、iOS、鸿蒙平台嵌入原生渲染的View。
  • 上层框架：封装了导航、事件、应用生命周期等统一框架。
• MY KMP -> Kotlin跨平台层扩展：
  • 平台API导出：将各原生平台常用API导出为Kotlin接口供开发者调用。
  • Runtime优化：对平台运行时进行优化，降低内存占用并提升加载性能。
  • 自研LLVM技术：支持编译插桩等高级操作。
  • 编译器优化：通过前后端编译器优化，显著减小产物包体积。
  • 鸿蒙通信通道简化：去除了传统KMP鸿蒙开发中必需的C语言桥接层，实现了Kotlin与eTS（鸿蒙开发语言）的直接高效通信。
• 跨端基座：
  • C++基础库：将网络库等原生C++能力封装并透出Kotlin接口。
  • 原生平台能力增强：在鸿蒙平台深度集成其Pipeline、事件中心、渲染、资源加载等原生能力至KMP框架。
  • Tecla API：基于自研IDL（接口描述语言）提供的跨端、跨技术栈API调用机制。开发者只需调用Kotlin接口，即可在安卓、iOS、鸿蒙三端使用支付宝的中间件能力。
• 工程体系集成：将KMP框架无缝融入支付宝现有的工程研发体系，提升开发效率。

目前，该KMP跨端架构已在支付宝多个核心业务场景（如“我的”、理财、直播、消息页，以及出行服务、健康管家等独立APP）中落地，覆盖安卓、iOS、鸿蒙三大平台，均实现了与原生开发对标的高性能体验。整体已支撑亿级PV，成为支付宝内重点发展的主流原生跨端技术栈。

KMP研发现状、痛点与AI工具调研

尽管KMP技术带来效率提升，但其研发全流程仍存在若干痛点：

1. 起步阶段：开发者需从头学习Kotlin、Compose及KMP/CMP特有语法，存在较高的学习成本。
2. 开发阶段：开发者不熟悉框架提供的跨端API（如AntUI、Tecla）是否能满足需求及具体调用方式。
3. 测试阶段：主要依赖人工测试，效率低下，缺乏自动化与AI辅助手段。
4. 上线运维阶段：三端（尤其是KMP特有）的崩溃堆栈反解与分析耗时较长，问题定位与优化成本高。

针对上述痛点，我们对现有AI编码工具进行了调研，结论是：目前缺乏一款能与客户端基础框架深度结合、支持KMP技术栈、并适配支付宝终端研发工程体系的专用编码助手。

具体对比如下：

• 内部两款热门助手：能力丰富，但不支持KMP跨端开发辅助。
• Cursor：支持KMP技术栈，但缺乏转码等深度能力，无法融入支付宝工程体系，且不了解CMP在鸿蒙平台的特定知识。
• Cline：与Cursor存在类似问题，且其推理步骤复杂度较高。

因此，我们期望打造一款具备跨端特色的AI编程伙伴，以解决实际研发问题，提升效率。

KMP编码助手：方案与实践

构建了KMP的编码助手，其核心目标是运用AI技术为KMP开发带来“二次加速”。以下从方案构思到核心功能实现进行剖析。

整体可行性评估与架构

项目初期，我们从四个维度评估了可行性：

1. 图生码/设计稿生码：通过让大模型学习AntUI组件，验证了其能直接输出对应界面代码的可行性。
2. 算法支撑：具备在终端研发场景下产出领域自研算法模型的能力，以增强生码效果。
3. 生产资料支撑：拥有完整的KMP（含鸿蒙）技术栈研发能力、四端AntUI组件库的开发和维护能力，以及可通过Tecla透出的丰富基础框架能力，能为大模型提供充足的学习素材。
4. 插件结合方式：确定以Android Studio（KMP研发主要IDE）的IntelliJ IDEA插件形式进行集成验证。

整体架构分为三层：

• 客户端层：作为Agent与用户的交互界面（IDE插件）。
• Agent框架层（核心）：进行了工作流编排、任务分解、知识图谱构建、UI转换等核心改造。
• 基础服务层：支撑AI能力的Prompt工程、RAG检索、MCP协议调用及代码补全等服务。

界面开发提效：从设计稿/图片到代码

为帮助开发者快速上手Compose UI，我们提供了两种生码方案：

设计稿生码

• 效果：可将Sketch设计稿中的图层高精度（还原度90%以上）转换为Compose UI代码，并在IDE中实时预览。
• 实现链路：

  • 启动链路：通过Node服务连接Sketch应用、IDE插件和Webview。

  • 设计稿转IR：将设计稿元素转换为中间表示（IR），包括类型、参数、样式及视图层级信息。

    • 

  • IR转Compose：依据规则将IR映射为Compose组件与修饰符。

    • 

  • 优化与输出：通过人工规则与模型二次优化，对生成的代码进行组件化、数据驱动等重构，输出高质量的生产级代码。

• 挑战：处理了设计稿不规范、IR与Compose属性映射差异（如margin）、DIV类型具体化、图片资源转换、CSS风格属性适配等一系列复杂问题。
  • 
• 解决：利用大模型进行二次优化，将界面布局进行组件化以及数据驱动的封装，比如一个平铺列表，最终优化成 ServiceItem 组件，对应传参 ServiceData，最终代码就可以直接用于生产。
  • 

再来整体对比下，从原始设计稿，到原始 Compose UI，再到模型二次优化的界面效果。这里能感受到模型二次优化后，基本上能够还原设计稿组件，但是代码更加直接可用。

• 稿生码的优点:
  • 转换后还原精度高，
• 缺点
  • 不支持基于支付宝 AntUI 组件库还原，
  • 设计稿不够规范影响还原效果。

我们自然而然的会想有更加简便，且支持高阶 UI 组件库的方案，就是图生码。

图生码

• 背景：设计稿生码不支持AntUI组件，且受设计稿规范度影响。图生码旨在实现更简便且支持高阶组件的生码方案。
• 方案演进：
  • 方案一（图到代码直出）：将高阶 UI 组价库的知识按照统一格式，输入给 MLLM 学习后，直接将图片转换成 Compose 代码。
    • 
    • 问题: 让大模型读图直接输出代码。效果欠佳，细节处理差，且技术栈绑定Compose，难以扩展。
  • 方案二（图→IR→代码）：采用自研图生码算法。使用后训练的多模态大模型识别图片中的基础组件和AntUI组件，输出IR，再复用设计稿生码的转换规则生成代码。(此方案更优)
    • 
    • 图生码算法能力建设的三个阶段
      • 

      1. 数据构造, 构建自动化流程，通过大模型生成随机Compose代码→渲染截图→生成精确的图文数据对，解决了训练数据匮乏问题。

         • 

      2. 模型训练, 采用LoRA（低秩适应）等参数高效微调技术，对多模态大模型进行SFT（监督微调）和强化学习，使其获得精准的UI页面解析能力，能识别AntUI高阶组件。

         • 

      3. 后处理增强, 针对模型幻觉导致的位置、颜色、布局偏差，结合传统图像算法进行校准，提升输出IR的精确度。

         • 
  • 优势与挑战：方案二效果更精准，直接支持AntUI，且IR协议可扩展至其他原生技术栈。当前挑战在于进一步提升AntUI组件识别准确度，并构造更多特殊案例数据。

逻辑开发与运维提效：智能问答与诊断

为帮助开发者快速上手KMP逻辑开发与解决线上问题，我们构建了基于RAG和MCP的智能助手。

基于RAG的智能问答

背景

• 内部文档质量参差不齐，内容多且繁杂，较难查找阅读
• 阅读；由于文档质量不高，导致机器人答疑质量不高

开发者常咨询这三类问题：

1. Kotlin 跨端能力库中是否包含某项能力？
2. 这个 API 能力调用代码该怎么写？
3. AntUI 组件库是否支持包含某个组件？

RAG 检索问答基本流程:

• RAG流程优化：
  • 源数据处理：面对复杂的JSON源数据（如含千条API记录），利用自建Agent将其转化为格式规整、模型可读的Markdown文档。
  • 检索效果提升：以FAQ（问答对）形式替代传统的文本切片，并借助大模型从文档中提炼生成近4000条FAQ知识，提高召回准确率。
  • 体系性问题回答：将知识图谱的实体关系作为检索语料，使模型能理解模块与接口的层级关系，回答体系性问题。
  • FAQ增强：让模型为同一答案生成多种问法，提升问题命中的灵活性。

具体问题诊断与解决

• KMP构建/闪退排查：构建“构建失败Agent”和“闪退日志Agent”。其工作流为：先运行脚本提取日志关键信息，再通过RAG从知识库召回解决方案，最后由Agent组织答案反馈给开发者。
• KMP应用框架快速接入：该框架用于抹平三端生命周期差异。我们提供模板代码自动生成工具，开发者可一键将框架集成到项目中，将原本需3人日的接入工作自动化。

KMP 模块在三端平台构建失败，无法定位原因

针对开发者不熟悉多端尤其是鸿蒙平台的痛点，我们通过定制Agent工作流解决问题：
KMP 模块在三端平台构建失败，无法定位原因
KMP 核心产物需要同时三端构建，一旦出现构建失败问题，传统排查方式效率比较低下，花费的时间从几分钟到一小时不等。

这里我们通过 Agent 工作流的方式，帮助开发者主动触发构建，利用 KMP 日志分析脚本，提取关键日志，再结合现有构建知识库进行召回，最终由模型整理组织答案。从而加快构建失败问题的排查速度。

安卓/ iOS /鸿蒙，三端闪退如何排查

开发者可以直接将闪退日志输入给 Agent ，Agent 会触发闪退分析的工作流，先用 KMP 堆栈反解工具提取关键内容并解析，再将解析结果返回给 Agent，由 Agent 结合当前的项目代码上下文，给出原因和解决方案。

基于MCP的工具集成

如何将众多工具（堆栈分析、模板生成、文件操作等）整合到大Agent中？我们采用了本地MCP（Model Context Protocol）路由机制。

• MCP作用：一种标准协议，使工具能适配不同大模型。通过编写MCP协议描述工具功能，Agent可根据用户提示词自动路由并调用相应工具。
  • 
• 示例：当用户输入“分析鸿蒙闪退堆栈”并提供日志时，Agent能自动匹配并调用“闪退堆栈分析工具”的MCP，执行分析并返回根因与建议。
  • 
• 架构扩展：除本地MCP工具集外，未来规划提供远程MCP市场和Agent市场。
  • 

未来展望

KMP编码助手将持续优化与创新，重点方向包括：

1. 生码能力增强：支持Figma设计稿生码；优化图生码IR协议；探索智能Compose UI视觉验收。
2. 声明式UI动态化：结合模型对数据与UI组件的理解，通过自研KMP JS运行时与动态化技术，实现数据驱动的动态界面渲染。
3. 技术架构扩展：以KMP技术栈为核心，逐步将AI辅助能力扩展至其他原生技术栈（如纯Android、iOS开发）。
4. 生态建设：建设开放的Agent与MCP工具市场。

总结：AIAgent重塑软件开发生命周期

最后再来看一下AI Agent面向软件开发整个的生命周期,你可以发现 agent正在以一个非常非常快的速度改变我们的工作方式. 从构思到开发到落地, agent在每一个环节都会驱动我们来进行一些创新.
比如

• 需求分析里面我们可以让AI来给出UI/UX设计建议
• 开发与编码阶段, 可以让agent来帮助我们进行代码审查和质量保证
• 测试阶段也很重要, 可以让agent智能测试以及报告
• 在部署与发布上, agent可以帮助我们进行一个自动化的配置
• 在维护与运营阶段, agent可以帮助我们分析用户的反馈以及线上的性能监控和优化

简而言之, AIAgent正在引领一场软件开发的全新的变革, 这将会深深地改变我们之后的一个工作方式, 那在这里呢也也祝愿大家能够在AI人工智能席卷而来的浪潮里面抓住机遇勇于创新, 说不定会有意想不到的惊喜和收获.

Dart Mixin 详细指南 1. 基础 Mixin 用法 1.1 基本 Mixin 定义和使用 dart 2. Mixin 定义抽象方法 dart 3. 使用 on 关键字限制 Mixin 范围

手把手教你搭建Flutter项目的CI/CD自动化流水线。详细讲解GitHub Actions的工作原理，如何创建自动化测试工作流、如何配置单元测试工作流，帮助开发者快速上手CI/CD实践。

Xcode 26 开始提醒即将强制要求适配UIScene lifecycle，文章介绍了一个适配方案和注意点

引言 在 iOS 13 之前，iOS 应用通常只有一个主窗口（UIWindow）。但随着 iPadOS 的推出和多任务处理需求的增加，Apple 引入了 UIWindowScene 架构，让单个应用可

一、associatedtype的用法 在swift中，泛型T是一个非常强大的特性，它允许我们编写灵活且可复用的代码。而当我们在 协议（Protocol） 中需要使用泛型时，associatedtyp

下面内容只关注 GetxController / GetBuilder / Obx / 局部状态组件这些部分。

众所周知Swift中Array是值类型，如果其中元素为值类型和引用类型，分别会发生什么？ 相关验证方法 检查不同层次的地址 元素为引用类型 随便定义一个类，并创建列表1，然后直接赋值给列表2 用wit