做独立产品这件事，说起来容易，真动手了才知道水有多深。这是一个独立开发者将职场小需求变成主力产品的真实故事。我们将跟随 Zipic 作者十里的视角，一起回顾产品从 0 到 1 的全过程。本篇聚焦产品设计与决策思考。
Mac App Store 固然使用简单，但可能并不适合所有的产品。本文中，我们将跟随 Zipic 作者十里的视角，来解决一款 macOS 独立应用的分发与售卖问题。
图片压缩软件还有什么技术难点？本文充满了硬核、实用的 macOS 开发经验，从 SwiftUI 的组件适配到 Core Graphics 的底层应用，从 Raycast 扩展的集成到 PDF 压缩的实现，不仅解决了性能瓶颈，更让原生体验达到了极致。
近期AI赛道异常“内卷”，硅谷甚至出现了“996”乃至“007”的新闻。AI在编码（如Cursor、Anthropic）和解决复杂问题（如ACM竞赛夺冠、IMO金牌水平）上的表现，似乎已超越大部分程序员。
这引发了一个普遍的焦虑：AI coding + AI debug 是否将形成一个完美闭环，从而替代程序员？
然而，在快手这样拥有亿级日活（DAU）的复杂业务场景中，我们的实践表明，需要冷静看待这一议题。AI并非替代者，而是团队产出的放大器。今天的分享，将围绕快手在性能稳定性领域如何利用AI进行智能诊断与实践，揭示AI在真实工业场景中扮演的角色。
快手移动端稳定性建设经历了四个清晰的阶段：
每个阶段都基于上一阶段的成果进行迭代，这与移动互联网发展的节奏同步。
尽管硬件性能（如iPhone）已提升百倍，软件架构（如GMPC）演进多年，但大前端的性能稳定性问题远未解决。复杂性体现在多个维度：
从算法复杂度视角看，我们解决问题的“算法”本质未变，但“输入”却因业务增长和技术栈扩张（如新增鸿蒙）而急剧增加，导致问题规模（年报警事件超150起，必解问题超2000个）庞大。
我们观察到团队中一个普遍的困境：
AI的机遇正在于此——它有望成为打破这一循环的放大器，将专家经验沉淀和复制，赋能整个团队。
AI x 稳定性：整体策略与架构设计
稳定性体系覆盖研发生命周期多个环节（开发、测试、监控、排障、应急处置）。我们选择从 “问题处置” 切入，因为这里是消耗研发时间最多的“重灾区”。问题处置又可细分为：
我们判断，AI在工程领域的落地形态将是 “Agent（智能体）” 。因此，我们从一开始就以可扩展的Agent框架为基础进行架构设计。
我们的性能稳定性Agent架构分为四层：
AI辅助根因排障——从“破案”到“自动修复”
一个典型的NPE（空指针）崩溃，堆栈全是系统代码，无业务逻辑。它仅在特定活动场景下偶发，现场信息缺失，线下难以复现。直接将此堆栈扔给ChatGPT，它能解决吗？ 实践表明，非常困难。
调研数据显示，96%的研发认为日常排障有痛点，其中69%认为现场信息太少，50%认为日志太多。行业数据也指出，开发者35-50%的时间花在调试验证上。这印证了我们的新范式：“Code is cheap, show me the (bug-free) fix.”
排障本质上是逆向推理的认知活动，与侦探破案高度相似：
AI的能力在此链条上并非均匀：
我们自研了Holmes排障工具，核心思路是动静结合：
特别是Holmes UI视图，它能在崩溃时捕获：
面对Holmes采集的海量、复杂信息，我们通过Agent编排来让AI消化：
提升准确率的关键在于“上下文工程”，目标是达到“适定问题”状态：
AI x 根因排障：效果展示
性能分析的火焰图数据量巨大（十几秒可能产生60MB数据），分析门槛高、效率低、易遗漏。
我们的方案是：
AI加速故障应急处置——与时间赛跑
以iOS 26升级导致大量历史版本App崩溃为例。传统手段各有局限：
应急处置的核心在于时效性，必须与故障扩散赛跑。
我们自研了Ekko安全气垫系统，其核心思想是：在崩溃发生后、应用闪退前，动态修改程序执行流，让其“跳回”安全状态继续执行，实现类似游戏“R技能”的时光倒流效果。
Ekko 崩溃阻断：覆盖所有崩溃类型
Ekko是 “售后方案” ，只在崩溃发生时触发，避免了无异常用户端的性能损耗，保证了安全性。
即使有了Ekko，配置和使用它依然复杂（需指定跳转地址、恢复上下文等），在紧急状态下人工操作易出错、易遗漏。
我们引入故障应急处置Agent，实现：
在“黑天鹅”事件中（如某次误操作导致千万级崩溃），AI冷静、全面的分析能力，能有效避免人在高压下的决策失误。
回到最初的焦虑，Linus Torvalds的观点值得深思：“代码的审查和维护本身就充满挑战。” AI不会改变这一本质，而是帮助我们更好地应对它。
我们的结论是：
在快手亿级DAU的复杂战场上，AI × 性能稳定性的探索刚刚启航。未来将是人机协同（Human in/on the Loop） 的深度结合。我们应积极拥抱AI，将其作为强大的杠杆，释放工程师的创造力，共同应对大前端领域越发复杂的稳定性挑战，奔赴星辰大海。
在过去的几天里，我回顾了这一年来 Swift、SwiftUI 以及 SwiftData 的演进。总的感觉是：惊喜虽不算多，但“成熟感”却在不经意间扑面而来。
自2017年Google提出Transformer后，AI在各领域实现突破。
2023年起，大语言模型商业化加速，年增速达30倍以上。
AICoding 领域是发展最快的学科之一，因为反馈机制明确（“对就是对，错就是错”）。
| 阶段 | 描述 | 人机角色 | 典型能力 |
|---|---|---|---|
| L1 | 人类主导，Agent实时辅助 | 人主导，AI辅助 | 代码提示（如GitHub Copilot） |
| L2 | 人类布置任务，Agent生成代码 | 人布置单一任务 | 单一任务代码生成 |
| L3 | 人类设定范围，Agent推进多环节流程 | 人设定范围，AI推进流程 | 生成方案 + 生成代码 |
| L4 | 人类输入PRD，Agent端到端交付 | 人输入PRD，AI端到端交付 | 需求解析 + 架构设计 + 编码 |
| L5 | 人定义目标，多Agent分工协作 | 人定义目标，多AI协作 | 多Agent模拟完整软件团队 |
“前端开发像是在标准化、开放的乐高环境中工作；客户端则像是在碎片化、半封闭的复杂系统中进行精密工程。”
科学评测体系的建立：从SWE-bench到Mobile-SWE-bench
**SWE-bench**：由普林斯顿与芝加哥大学推出，基于真实GitHub Issue，要求AI生成PR来修复问题，以单元测试通过率为评测标准。
局限性：侧重于Bug修复而非功能实现，项目多集中后端，缺少移动端特有考量（如UI还原、多模态输入）。
移动端评测 Mobile-SWE-bench：
把整个需求的测评级分成三类, 可以看到哪怕是业界比较火的一些模型放在测试集中表现也
一般, 30%已经算是很高了.
为什么这些 Code Agent 都表现不佳?
PRD 是 “产品需求文档”(Product Requirements Document) 的缩写. 在传统的软件和产品开发流程中，PRD 是一个核心文档。它由产品经理（或业务分析师）撰写，详细描述了一个产品、功能或项目应该做什么、为谁而做以及要达到什么目标。
一个典型的 PRD 通常包含：
这里探讨的是一种前沿的、由AI驱动的开发范式。在这个范式中，PRD 的角色发生了根本性的转变：
一个实际的业务场景和需求分析, 用户登录页面，包含手机号输入框、密码框、登录按钮、忘记密码链接及成功/失败反馈。
流程:
端到端提升：定制化Code Agent在Easy/Medium/Hard需求集上，比通用Agent（如GPT-5、Claude）提升约10%。
客户端实现PRD到代码的完全直出目前尚不可能，但可通过“评测驱动子能力提升”路径逐步推进。
应关注四个关键课题：
1. 如何构建科学的端到端评测体系？
2. PRD该如何拆解、拆解到什么粒度？
3. 如何保证UI高还原度出码？
4. 如何实现组件的智能召回与闭环迭代？
这边文章是 Qcon 上海站 2025 来自支付宝的KMP分享总结, 主题为”AI Agent编码助手实战：面向KMP原生跨端实现研发提效”
文章参考: 支付宝 MYKMP 原生跨平台解决方案
文章参考 : AI Agent 编码助手实战：面向 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架构上进行了深度扩展，构建了增强型跨端框架，其分层架构如下：
目前，该KMP跨端架构已在支付宝多个核心业务场景（如“我的”、理财、直播、消息页，以及出行服务、健康管家等独立APP）中落地，覆盖安卓、iOS、鸿蒙三大平台，均实现了与原生开发对标的高性能体验。整体已支撑亿级PV，成为支付宝内重点发展的主流原生跨端技术栈。
尽管KMP技术带来效率提升，但其研发全流程仍存在若干痛点：
针对上述痛点，我们对现有AI编码工具进行了调研，结论是：目前缺乏一款能与客户端基础框架深度结合、支持KMP技术栈、并适配支付宝终端研发工程体系的专用编码助手。
具体对比如下：
因此，我们期望打造一款具备跨端特色的AI编程伙伴，以解决实际研发问题，提升效率。
构建了KMP的编码助手，其核心目标是运用AI技术为KMP开发带来“二次加速”。以下从方案构思到核心功能实现进行剖析。
项目初期，我们从四个维度评估了可行性：
整体架构分为三层：
为帮助开发者快速上手Compose UI，我们提供了两种生码方案：
启动链路：通过Node服务连接Sketch应用、IDE插件和Webview。
设计稿转IR：将设计稿元素转换为中间表示（IR），包括类型、参数、样式及视图层级信息。
IR转Compose：依据规则将IR映射为Compose组件与修饰符。
优化与输出：通过人工规则与模型二次优化，对生成的代码进行组件化、数据驱动等重构，输出高质量的生产级代码。
再来整体对比下，从原始设计稿，到原始 Compose UI，再到模型二次优化的界面效果。这里能感受到模型二次优化后，基本上能够还原设计稿组件，但是代码更加直接可用。
我们自然而然的会想有更加简便，且支持高阶 UI 组件库的方案，就是图生码。
数据构造, 构建自动化流程，通过大模型生成随机Compose代码→渲染截图→生成精确的图文数据对，解决了训练数据匮乏问题。
模型训练, 采用LoRA（低秩适应）等参数高效微调技术，对多模态大模型进行SFT（监督微调）和强化学习，使其获得精准的UI页面解析能力，能识别AntUI高阶组件。
后处理增强, 针对模型幻觉导致的位置、颜色、布局偏差，结合传统图像算法进行校准，提升输出IR的精确度。
为帮助开发者快速上手KMP逻辑开发与解决线上问题，我们构建了基于RAG和MCP的智能助手。
背景
开发者常咨询这三类问题：
RAG 检索问答基本流程:
针对开发者不熟悉多端尤其是鸿蒙平台的痛点，我们通过定制Agent工作流解决问题：
KMP 模块在三端平台构建失败，无法定位原因
KMP 核心产物需要同时三端构建，一旦出现构建失败问题，传统排查方式效率比较低下，花费的时间从几分钟到一小时不等。
这里我们通过 Agent 工作流的方式，帮助开发者主动触发构建，利用 KMP 日志分析脚本，提取关键日志，再结合现有构建知识库进行召回，最终由模型整理组织答案。从而加快构建失败问题的排查速度。
开发者可以直接将闪退日志输入给 Agent ，Agent 会触发闪退分析的工作流，先用 KMP 堆栈反解工具提取关键内容并解析，再将解析结果返回给 Agent，由 Agent 结合当前的项目代码上下文，给出原因和解决方案。
如何将众多工具（堆栈分析、模板生成、文件操作等）整合到大Agent中？我们采用了本地MCP（Model Context Protocol）路由机制。
KMP编码助手将持续优化与创新，重点方向包括：
最后再来看一下AI Agent面向软件开发整个的生命周期,你可以发现 agent正在以一个非常非常快的速度改变我们的工作方式. 从构思到开发到落地, agent在每一个环节都会驱动我们来进行一些创新.
比如
简而言之, AIAgent正在引领一场软件开发的全新的变革, 这将会深深地改变我们之后的一个工作方式, 那在这里呢也也祝愿大家能够在AI人工智能席卷而来的浪潮里面抓住机遇勇于创新, 说不定会有意想不到的惊喜和收获.
登录