Title: 彻底爆了！一文吃透AIGC、Agent、MCP的概念和关系-腾讯云开发者社区-腾讯云

原文地址

导语: 近年来，人工智能 领域涌现出许多新概念和新技术，其中AIGC、MCP和 Agent 成为了业界和学术界的热门话题。本文将深入浅出地介绍这三个概念，帮助读者全面理解它们的内涵、区别与联系，以及在实际应用中的价值。

AIGC

AIGC，全称为 AI Generated Content，意为“人工智能生成内容”。它指的是利用人工智能技术（尤其是大模型，如GPT、Stable Diffusion 等）自动生成文本、图片、音频、视频等多种内容的过程。2022 年 11 月 30 日，OpenAI 的 ChatGPT 正式上线（基于 GPT-3.5），引爆了 AIGC 热潮。

多模态技术

• 单模态： 只处理一种类型的数据，比如只处理文本（如GPT-3.5）、只处理图像（如图像识别模型）。
• 多模态： 能够同时处理两种及以上类型的数据。例如，既能理解图片内容，又能理解文本描述，甚至还能结合音频、视频等信息进行综合分析和生成。对应的场景有。

RAG 技术

RAG（Retrieval-Augmented Generation，检索增强生成） 技术，是一种将信息检索（IR） 与大型语言模型（LLM） 的文本生成能力相结合的人工智能框架。其核心思想是：当 LLM 需要回答一个问题或生成文本时，不是仅依赖其内部训练时学到的知识，而是先从一个外部知识库中检索出相关的信息片段，然后将这些检索到的信息与原始问题/指令一起提供给LLM，让LLM基于这些最新、最相关的上下文信息来生成更准确、更可靠、更少幻觉的答案。

大型语言模型虽然拥有海量的知识和强大的语言理解与生成能力，但也存在一些关键限制：

1. 知识局限性/过时性： LLM 的知识主要来源于其训练数据截止日期之前的信息。对于训练数据之后发生的事件、新研究、最新数据或特定领域的细节，LLM 可能不知道或给出过时的信息。
2. 幻觉： 当 LLM 遇到其知识库中不明确或不存在的信息时，它可能会“捏造”出看似合理但事实上错误或不存在的答案。
3. 缺乏来源/可验证性： LLM 通常无法提供其生成答案的具体来源依据，使得验证答案的准确性变得困难。
4. 特定领域知识不足： 通用 LLM 可能缺乏对某个特定公司、组织或个人私有知识库的深入了解。

RAG 正是为了解决这些问题而诞生的。

智能体 Agent

“智能体”（Agent）在计算机科学和人工智能领域指的是一个能够感知环境、自主决策并采取行动以实现特定目标的实体或系统。 它可以是软件程序、机器人硬件，甚至是生物实体（如人类或动物），但在 AI 领域通常指软件智能体。

Agent 和 AIGC 最大的区别：

1. AIGC 主要以生成式任务为主，而 Agent 是可以通过自主决策能力完成更多通用任务的智能系统。
2. 常见的 AIGC 系统（文生文，文生图）的核心就是一个生成模型，而 Agent 是一个集Function Call 模型（下文会详细介绍）、软件工程 于一体的复杂的系统，需要处理模型和外界的信息交互。
3. Agent 可以集成 AIGC 能力完成某些特定的任务，也就是 AIGC 可以是 Agent 系统里面的一个子模块。

Agent 最大的特点是，借助Function Call 模型，可以自主决策使用外接的一些工具来完成特定的任务。

Function Call 模型

什么是 Fucntion Call 模型

Function Calling（函数调用） 是大型语言模型的关键技术。前面有提到过RAG技术是为了解决模型无法和外接数据交互的问题，但是RAG的局限在于只赋予了模型检索数据的能力，而Function Calling允许模型理解用户请求中的潜在意图，并自动生成结构化参数来调用外部任何函数/工具，从而突破纯文本生成的限制，实现与真实世界的交互，比如可以调用查天气、发邮件、数学计算等工具。

Function Call 模型最早由 OpenAI 在 2023 年 6 月 13 正式提出并发布，首次在 GPT-4 模型上实现了 Function Calling 能力。OpenAI 作为大语言模型的领路人，其发布的模型的 API 协议都会行业标准，后面国内外新发布模型都会按照 OpenAI 的协议作为标准实现。截止目前，支持 Fucntion Calling 能力的主流模型如下表：

除了上面的知名度高的模型，还有一些其他开源或闭源模型也支持了 Fucntion Calling 能力，但是截止目前为止，GPT-4 仍然是公认的 Fucntion Calling 能力最强的模型。

工作原理：三步闭环流程

Function Call 模型的工作流程如下图：

步骤详解：

1、定义函数（开发者预设）

向 LLM 描述函数的用途、输入参数格式（JSON Schema），例如：

1
2
3
4
5
6
7
8
9
10
11
12

{
  "name": "get_current_weather",
  "description": "获取指定城市的天气",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {"type": "string", "description": "城市名称"},
      "unit": {"enum": ["celsius", "fahrenheit"]}
    },
    "required": ["city"]
  }
}

• name 是工具名称
• description 是这个工具的用途
• parameters 是这个工具需要的输入参数

2、模型决策与生成参数

用户提问：“北京今天需要带伞吗？”

→ LLM 识别意图需调用 get_current_weather

→ 生成结构化参数：

1

{"city": "北京", "unit": "celsius"}

3、执行函数 & 返回结果

• 程序调用天气API，获真实数据：{"temp": 25, "rain_prob": 30%}
• 将结果交回LLM，生成最终回复：“北京今天25°C，降水概率30%，建议带伞。”

核心优势：LLM 的“手和眼睛”

Agent

OpenAI 发布 Function Call 模型后，Agent 才开始发展。而 Agent 真正进入到公众视野，被大家广泛关注的事件是 2025年4月 Manus 发布了通用智能体产品，引入了Computer Use 和 Browser Use，首次展现出智能体的强大能力。

Agent 的工作流程

实际上上文提到的 Function Call 模型的工作流程图，已经算是一个 Agent 的雏形了，不同点是，Agent 完成一次任务，实际上会循环调用模型，可能会调用多次 Function Calling，每次需要调用什么工具，完全由模型决策。一个最简单的 Agent 调用流程图如下：

比如有一个出行规划的智能体，这个智能体配置有天气查询、驾车规划、公共交通规划、骑行规划、步行规划等工具。用户询问“我在深圳，5月1日想去自驾去北京旅行，帮我规划一下出行方案。”，一个可能的具体的执行流程如下：

怎么开发一个自己的 Agent

最简单的方法就是把 Agent 的提示词（prompt）、工具、llm 调用，工具执行都硬编码到代码中，这样确实可以快速开发一个特定功能的 Agent。这样的实现会带来一些问题：

1. 提示词（prompt），工具需要调整的时候，需要改配置或者代码，灵活度不够高；
2. 如果要开发一个新功能的 Agent，整体代码可能需要重新实现一遍。

为了解决这一系列的问题，coze 、dify 、 腾讯云智能体开发平台等智能体开发平台相继出现。借助这些平台，开发者甚至不需要会编程，不需要 服务器 资源，就可以开发一个自己的Agent，Agent 的整个执行流程完全由平台在云上执行。智能体开发平台的架构一般包含 插件配置、Agent 配置、Agent 执行模块、插件执行模块，发布模块。

• 插件配置：所有 Agent 的工具都统一管理起来，而不是散落在各个 Agent 内部，这样可以做到工具的复用。一般平台会自带一些插件，比如网络搜索、文件上传、AIGC 工具等，同时也支持开发者添加自己的自定义插件。
• Agent 配置：配置 Agent 的 提示词 (prompt)，使用的模型，以及选择插件配置中的一批工具提供给模型做选择。
• 发布配置：开发者把自己的 Agent 开发调试稳定以后，发布成稳定版本就可以提供给用户使用了。
• 插件执行：执行某个特定的插件，返回结果。
• Agent 执行：实现通用的 Agent 执行流程，调用插件执行模块实现工具调用。

下图是用腾讯云智能体开发平台，开发一个简单的 Agent 配置和实际执行效果图。

Multi-Agent

除了使用智能体开发平台快速开发自己的 Agent 以外，还可以使用 sdk 的方式进行开发。2025 年 3 月 11 日，OpenAI 重磅发布 OpenAI Agent SDK！AI 开发范式彻底颠覆！使用 sdk 可以快速配置一个自定义的 Agent 后执行，相比智能体开发平台，sdk 具有更高的灵活性和自主可控性。

同时，在 OpenAI Agent SDK 中，首次引入了 Mulit Agent 的概念。在此之前，通过智能体开发平台，我们开发出来的 Agent 都只是单 Agent。一个单 Agent 的能力有限，只能解决特定领域的一个任务，而一个复杂任务往往需要执行多个领域的任务才能完成。而 OpenAI Agent SDK 可以让开发者定义多个领域的 Agent，并且给这些 Agent 配置一些转交关系，允许某个 Agent 把特定的任务交给另外一个合适领域的 Agent 来执行，多个 Agent 之间协同和互动来完成一个复杂任务。

在 OpenAI Agent SDK 发布以后，以腾讯云智能体开发平台为代表的相关产品都相继支持了 Multi-Agent 模式。

Agent 的发展

Agent 目前的发展还处于一个较初期的阶段，但是发展速度很快。在一些垂直领域比如代码生成 Cursor / 腾讯云 AI 代码助手 CodeBuddy、广告营销等方向已经有了比较好的落地。而更通用的 Agent 目前除了看到 Manus 落地以外，还没看到其他比较好的应用模式落地。相信随着时间发展，会有越来越好用，越来越通用的 Agent 应用诞生。

MCP

什么是 MCP

MCP（Model Context Protocol，模型上下文协议）是由人工智能公司Anthropic于2024 年 11 月 24 日正式发布并开源的协议标准。Anthropic 公司是由前 OpenAI 核心人员成立的人工智能公司，其发布的 Claude 系列模型是为数较少的可以和 GPT 系列抗衡的模型。

为什么需要 MCP

MCP 协议旨在解决大型语言模型（LLM）与外部数据源、工具间的集成难题，被比喻为“AI应用的USB-C接口“。通过标准化通信协议，将传统的“M×N集成问题”（即多个模型与多个数据源的点对点连接）转化为“M+N模式”，大幅降低开发成本。

在 MCP 协议没有推出之前：

1. 智能体开发平台需要单独的插件配置和插件执行模型，以屏蔽不通工具之间的协议差异，提供统一的接口给 Agent 使用；
2. 开发者如果要增加自定义的工具，需要按照平台规定的 http 协议实现工具。并且不同的平台之间的协议可能不同；
3. “M×N 问题”：每新增一个工具或模型，需重新开发全套接口，导致开发成本激增、系统脆弱；
4. 功能割裂：AI 模型无法跨工具协作（如同时操作 Excel 和 数据库），用户需手动切换平台。

没有标准，整个行业生态很难有大的发展，所以 MCP 作为一种标准的出现，是 AI 发展的必然需求。

总结：MCP 如何重塑 AI 范式：

MCP 的发展情况

MCP 自2024 年 11 月 24 日 发布以来，OpenAI、Google、微软、腾讯、阿里、百度等头部企业纷纷接入 MCP，推动其成为事实性行业标准。并且相继出现了 mcp.so 、mcpmarket 等超大体量的 MCP 服务提供商。国内的头部企业也相继加入 MCP 服务商的竞争中。在如此庞大的 MCP 市场下，开发者基本不需要开发自己的插件，直接使用 MCP 服务商的插件就可以直接开发大量 Agent。

同时很多头部企业，开始把自身原有的 API 业务开发成封装成 MCP 服务对外提供。比如：

1. GitHub Copilot 提供 MCP 的方式生成代码；
2. AWS 2025 年 6月推出开源工具 Amazon Serverless MCP Server，支持 Agent 直接操作云上资源，进行服务编排。
3. 腾讯地图、高德地图、百度地图均发布 MCP Server，支持在 Agent 中使用丰富的地图资源。
4. 腾讯云COS、百度网盘均已支持 MCP 协议的接入。

未来趋势：

• 与 AIOS 融合： MCP 正成为 AI 操作系统（如华为鸿蒙 HMAF）的核心组件，实现跨设备智能调度；
• 生态挑战： 大厂通过 MCP 构建“闭环生态”（如 阿里 集成高德地图），可能引发协议割裂，需推动跨平台协作标准。

MCP 不仅是技术协议，更是AI 生产力革命的基石——它让模型真正融入现实世界，成为人类工作的无缝延伸。

总结

整体上看，Agent 是在 AIGC、MCP 、大语言模型 LLM 等原子能力的基础上进行编排，以提供更复杂的 AI 应用。

原文地址

本文系统回顾了淘特导购团队在AI编码实践中的演进历程，从初期的代码智能补全到Agent Coding再到引入Rules约束，最终探索SDD（Specification Driven Development，规格驱动开发）——以自然语言规格（spec.md）为唯一真理源，驱动代码、测试、文档自动生成，实现设计先行、可测试性内建与文档永不过期。实践中发现SDD理念先进但落地门槛高、工具链不成熟、历史代码集成难，因此团队当前采用融合策略：以轻量级技术方案模板为输入 + Rules严格约束 + Agent Coding高效实现 + AI自动汇总架构文档，形成兼顾规范性、效率与可维护性的AI辅助编程最佳实践。

背景

业务背景

生成式AI技术的范式突破正驱动智能开发工具进入超线性演进阶段，主流代码生成工具的迭代周期已从季度级压缩至周级，智能体架构创新推动开发效能持续提升。

淘特导购系统承载着商品推荐、会场投放、活动营销等多样化的业务场景，技术团队面临着需求迭代频繁、代码腐化及团队协作度高的问题，如何提升开发效率、保证代码质量、降低维护成本成为我们面临的重要挑战。正是在这样的背景下，我们开始尝试将AI技术融入到日常开发流程中，探索从传统编码到AI辅助编程的转变之路。

AI编程工具的引入

2024年初，团队开始探索AI编程工具，希望通过AI提升开发效率和代码质量。最初接触的是Aone Copilot（阿里内部AI工具）的代码智能补全功能，后来逐步尝试Agentic Coding、Rules约束、SDD（Specification Driven Development）等多种AI编程模式。本文将详细记录我们的探索历程、实践经验以及对AI编程未来的思考。

代码智能补全与单方法改写

初识AI编程

场景1：代码自动补全

1
2
3
4
5
6
7
8
9
10
11
12
13

// 开发者输入：
public List<ItemCardVO> buildItemCards(List<ContentEntity> entities) {
    List<ItemCardVO> result = new ArrayList<>();
    // AI自动补全以下代码
    for (ContentEntity entity : entities) {
        ItemCardVO itemCard = new ItemCardVO();
        itemCard.setItemId(entity.getItemId());
        itemCard.setItemTitle(entity.getTitle());
        itemCard.setItemImg(entity.getPicUrl());
        result.add(itemCard);
    }
    return result;
}

场景2：单方法重构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// 原始代码（冗长难读）
public String getDiscountText(Long finalPrice, Long nnPrice) {
    if (finalPrice == null || nnPrice == null) {
        return "";
    }
    if (finalPrice <= nnPrice) {
        return "";
    }
    Long discount = finalPrice - nnPrice;
    if (discount <= 0) {
        return "";
    }
    String discountYuan = String.valueOf(discount / 100.0);
    return discountYuan + "元";
}
// AI重构后（简洁优雅）
public String getDiscountText(Long finalPrice, Long nnPrice) {
    if (finalPrice == null || nnPrice == null || finalPrice <= nnPrice) {
        return "";
    }
    Money discount = Money.ofFen(finalPrice).subtract(Money.ofFen(nnPrice));
    if (discount.getCent() <= 0) {
        return "";
    }
    return String.format("%s元", discount.getYuan());
}

初步收益

效率提升：

• 去年某次商详项目中，代码补全在对象构建、模型转换中减少70-80%的键盘输入。
• 单方法重构速度提升50%。

体验优化：

• 减少了查找API文档的时间
• 避免了拼写错误和语法错误
• 让开发者更专注于业务逻辑

遇到的问题

然而，这个阶段也暴露出一些问题：

1. 局限于局部优化：只能帮助完成单个方法或代码片段，无法理解整体业务逻辑
2. 缺乏上下文理解：不了解项目的架构规范和代码风格
3. 无法应对复杂需求：对于跨多个类、多个模块的需求无能为力

Agentic Coding的探索与挑战

Agentic Coding的尝试

带着上面的问题，我们开始尝试Agentic Coding模式，通过编写详细的提示词（Prompt），让AI一次性实现整个功能。

AI工具：Aone Copilot，模型：Qwen3-coder。

典型的Prompt结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

需求：实现NN页面红包模块
背景：
- 需要展示用户可用的红包列表
- 红包按门槛从小到大排序
实现要求：
1. 创建数据服务类 NnRedPacketDataService，查询用户红包
2. 创建模块VO NnRedPacketVO，包含红包列表、总金额等字段
3. 创建模块构建器 NnRedPacketModuleBuilder，组装数据
技术细节：
- 数据服务需要实现 DataService<List<FundQueryDTO>> 接口
- 数据服务实现类需要依赖FpProvider，并执行红包查询，参数请参考已有实现
- 模块构建器需要继承 BaseModuleBuilder<NnRedPacketVO>
- 使用 @Component 注解标记为Spring Bean
- 遵循项目代码规范
请生成完整的代码。

AI生成的代码示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

// 1. 数据服务
@Component
public class NnRedPacketDataService implements DataService<List<FundQueryDTO>> {
    @Autowired
    private FpProvider fpProvider;
    @Override
    public List<FundQueryDTO> execute(InvocationContext context, JSONObject req) {
        // 从配置获取红包池ID
        String poolIds = req.getString("nnRedPacketPoolIds");
        List<Long> fundPoolIds = Arrays.stream(poolIds.split(","))
            .map(Long::parseLong)
            .collect(Collectors.toList());
        // 查询用户红包
        return fpProvider.queryUserFundBuyPoolId(
            context, 
            fundPoolIds, 
            customRuleId, 
            securityCode
        );
    }
}
// 2. 模块VO
@Data
@Builder
public class NnRedPacketVO {
    private List<RedPacketItem> redPacketList;
    private String totalAmount;
    private String expandText;
}
// 3. 模块构建器
@Component
public class NnRedPacketModuleBuilder extends BaseModuleBuilder<NnRedPacketVO> {
    @Override
    public String getName() {
        return "nnRedPacket";
    }
    @Override
    protected NnRedPacketVO doBuild(InvocationContext context) {
        // 获取红包数据
        List<FundQueryDTO> funds = ContextUtils
            .<List<FundQueryDTO>>getBizResult(
                NnRedPacketDataService.class.getSimpleName(), 
                context, 
                500
            )
            .orElse(Collections.emptyList());
        if (CollectionUtils.isEmpty(funds)) {
            return null;
        }
        // 构建VO
        return NnRedPacketVO.builder()
            .redPacketList(buildRedPacketList(funds))
            .totalAmount(calculateTotalAmount(funds))
            .build();
    }
    private List<RedPacketItem> buildRedPacketList(List<FundQueryDTO> funds) {
        return funds.stream()
            .map(this::toRedPacketItem)
            .collect(Collectors.toList());
    }
    // ... 其他方法
}

显著的效率提升

Agentic Coding实现了开发效率的显著优化，通过提示词驱动的自动代码生成替代了传统手动编写，虽然Prompt设计需要额外时间，但综合效率提升效果明显。

快速暴露的问题

然而，在后续的需求迭代中，我们发现了严重的问题：

问题1：代码延续性差

现象： 同样的NN业务，第二次让AI实现时，生成的代码风格完全不同

1
2
3
4
5
6
7
8
9
10
11

// 第一次生成（简洁风格）
private String buildDiscountText(Money discount) {
    return String.format("省%s元", discount.getYuan());
}
// 第二次生成（冗长风格）  
private String buildDiscountText(Money discount) {
    BigDecimal yuan = BigDecimal.valueOf(discount.getCent())
        .divide(BigDecimal.valueOf(100), 2, RoundingMode.HALF_UP);
    String yuanStr = yuan.stripTrailingZeros().toPlainString();
    return "省" + yuanStr + "元";
}

影响： 同一个项目内，类似功能的实现方式五花八门，维护成本高

问题2：代码风格不一致

现象： AI不了解项目的代码规范，导致生成的代码风格和存量代码不一致。

问题3：团队协同性差

现象： 不同开发者写的Prompt差异大，生成的代码质量参差不齐

• 新手写的Prompt过于简单，AI生成的代码质量差
• 老手写的Prompt详细但冗长，难以复用
• 缺乏统一的Prompt模板和最佳实践

原因分析

这些问题的根本原因在于：AI缺乏项目特定的上下文和约束

• 没有项目规范： AI不知道项目的代码风格、架构模式、命名规范
• 没有领域知识： AI不了解淘特导购业务的特定术语和设计模式
• 没有历史经验： 每次都是”零基础”生成代码，无法从历史代码中学习

这让我们意识到，需要给AI建立”项目规范”和”领域知识”。

Rules约束 - 建立AI的”项目规范”

引入Rules文件

我们开始尝试用Rules文件来约束AI的行为，将项目规范、架构模式、领域知识固化下来。

Rules文件体系：

1
2
3
4
5
6
7
8

.aone_copilot/
├── rules/
│   ├── code-style.aonerule           # 代码风格规范
│   ├── project-structure.aonerule    # 项目结构规范
│   └── features.aonerule              # 功能实现规范
└── tech/
    ├── xx秒杀-技术方案.md      # 具体需求的技术方案
    └── xx红包模块-技术方案.md

Rules文件内容示例

代码风格规范（code-style.aonerule）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# 代码风格规范

## Java代码规范
- 类名使用大驼峰命名法（PascalCase）
- 方法名和变量名使用小驼峰命名法（camelCase）
- 常量使用全大写，单词间用下划线分隔（CONSTANT_CASE）

## 空值判断
- 集合判空统一使用：CollectionUtils.isEmpty() 或 isNotEmpty()
- 字符串判空统一使用：StringUtils.isBlank() 或 isNotBlank()
- 对象判空统一使用：Objects.isNull() 或 Objects.nonNull()

## 日志规范
- 使用 LogUtil 工具类记录日志
- 错误日志格式：LogUtil.error("类名, 方法名, 错误描述, 关键参数={}", param, exception)

## 注解使用
- Service类使用 @Component 注解
- 数据服务实现 DataService<T> 接口
- 模块构建器继承 BaseModuleBuilder<T>

项目结构规范

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 项目结构规范
## 包结构
com.alibaba.aladdin.app/
├── module/              # 模块构建器
│   ├── nn/             # NN业务模块
│   ├── seckill/        # 秒杀业务模块
│   └── common/         # 通用模块
├── domain/             # 领域对象
│   ├── module/         # 模块VO（继承ModuleObject）
│   └── [业务名]/       # 业务领域对象（BO、DTO）
├── dataservice/impl/   # 数据服务实现
└── provider/           # 外部服务提供者
## 命名规范
- 数据服务：[业务名]DataService（如 NnRedPacketDataService）
- 模块构建器：[业务名]ModuleBuilder（如 NnFeedsModuleBuilder）
- 模块VO：[业务名]VO（如 NnRedPacketVO）
- 业务BO：[业务名]BO（如 NnRoundFeatureBO）

功能实现规范

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 功能实现规范
## 数据服务层
- 必须实现 DataService<T> 接口
- 使用 @Component 注解
- execute方法的第一个参数是 InvocationContext
- execute方法的第二个参数是 JSONObject businessReq
示例：
```java
@Component
public class NnRedPacketDataService implements DataService<List<FundQueryDTO>> {
    @Override
    public List<FundQueryDTO> execute(InvocationContext context, JSONObject businessReq) {
        // 实现逻辑
    }
}

模块构建器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

- 必须继承 BaseModuleBuilder
- 使用 @Component 注解
- 实现 getName()、doBuild()、bottomTransform() 三个方法
- 通过 ContextUtils.getBizResult() 获取数据服务结果
示例：

@Component
public class NnRedPacketModuleBuilder extends BaseModuleBuilder<NnRedPacketVO> {
    @Override
    public String getName() {
        return "nnRedPacket";
    }
    @Override
    protected NnRedPacketVO doBuild(InvocationContext context) {
        List<FundQueryDTO> funds = ContextUtils
            .<List<FundQueryDTO>>getBizResult(
                NnRedPacketDataService.class.getSimpleName(),
                context,
                500
            )
            .orElse(Collections.emptyList());
        // 构建逻辑
    }
}

技术方案模板

除了Rules文件，我们还为每个需求创建技术方案文档，明确定义需要生成的代码：

技术方案示例（NN红包模块-技术方案.md）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

## 业务定义
NN红包模块用于展示用户在NN业务场景下可用的红包列表。
## 业务领域对象
无（复用 FundQueryDTO）
## 模块领域对象
| 对象含义 | 实现方案 | 属性及类型 |
|---------|---------|-----------|
| NN红包模块VO | 新增 | 1. redPacketList：List<RedPacketItem> - 红包列表<br>2. totalAmount：String - 总金额<br>3. expandText：String - 展开文案 |
## 数据服务层
| 数据服务定义 | 实现方案 | execute |
|------------|---------|---------|
| NN红包查询服务 | 新增 | 1. 从配置获取红包池ID列表<br>2. 调用FpProvider查询用户红包<br>3. 过滤可用红包（状态=2，未过期）<br>4. 返回红包列表 |
## 模块构建器
| 模块构建器定义 | 实现方案 | doBuild逻辑 |
|--------------|---------|-------------|
| NN红包模块构建器 | 新增 | 1. 获取红包数据<br>2. 过滤门槛>20元的红包<br>3. 按门槛从小到大排序<br>4. 构建VO |

显著改善的效果

引入Rules文件后，我们看到了明显的改善：

代码一致性：

• 所有生成的代码都遵循统一的命名规范
• 项目结构清晰，模块划分明确
• 代码风格保持一致

开发效率：

• 技术方案填写时间从2小时降低到20分钟
• 代码实现时间从1天降低到2小时（需要人工收尾）

团队协作：

• 技术方案成为团队共同语言
• Code Review效率提升50%
• 新人上手时间从1周降低到2天

依然存在的问题

虽然Rules带来了显著改善，但仍存在一些问题：

1. 需求理解不够深入：AI仍然是基于技术方案”翻译”成代码，对业务语义理解有限
2. 测试质量参差不齐：虽然能生成单测，但测试用例的通过率和覆盖度仍需人工把关
3. 文档滞后：代码变更后，文档更新容易遗漏
4. 依赖关系管理：对于复杂的模块依赖关系，AI处理不够优雅

这些问题让我们思考：能否找到一种方式，让AI能更加规范和延续的coding？

SDD探索 - 规格驱动开发

SDD的引入

近期，我们开始初步尝试SDD（Specification Driven Development，规格驱动开发），使用了Spec Kit工具链。

SDD的核心理念：

规格是唯一真理源（Single Source of Truth）

• 所有的代码、测试、文档都从规格生成
• 规格即文档，文档永不过期

设计先于实现

• 先用自然语言描述”做什么”（规格）
• 再让AI生成”怎么做”（代码）

可测试性内建

• 规格中明确定义测试用例
• 自动生成完整的单元测试

Speckit执行流程

环境准备

我们主要使用了两种工具：

1. iflow + qwen3 coder plus + spec kit
2. qwen + qwen3 coder plus + spec kit

文件体系：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

├── .specify/
│   ├── memory/
│   │   └── constitution.md
│   ├── scripts/
│   └── templates/
├── specs/
│   └── 001-nn-redpacket-module/
│       ├── checklists/
│       │   └── requirements.md
│       ├── contracts/
│       │   └── api-contract.md
│       ├── data-model.md
│       ├── plan.md
│       ├── quickstart.md
│       ├── research.md
│       └── spec.md
└── req/
    └── nn-redpacket.md

speckit.constitution—制定整个项目的原则

这一步会生成项目全局的宪章，constitution.md

以下是部分节选：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

## 核心原则

### I. 模块化服务架构
所有服务必须遵循模块化设计原则，具有明确的关注点分离和定义良好的接口。每个模块应具有单一职责并可独立部署。模块必须以松耦合和高内聚的方式设计，以增强可维护性和可扩展性，遵循最小依赖原则。
### II. 阿里巴巴开发标准
所有代码必须遵循阿里巴巴Java开发指南（基于阿里巴巴Java编码规范）。这包括命名约定、异常处理实践、日志标准、安全最佳实践和性能优化模式。代码必须遵守样式一致性要求，以保持代码库的统一性。
### III. 质量保证实践
全面测试是强制性的：对所有业务逻辑进行单元测试，对服务交互进行集成测试，对API兼容性进行合同测试。代码覆盖率必须保持在80％以上，特别关注关键业务路径。代码质量工具必须集成到CI/CD管道中以执行标准，遵循阿里巴巴开发规范以确保质量和可靠性。
### IV. 模块设计原则
遵循单一职责原则，每个模块都有一个明确的目的。模块必须以松耦合和高内聚的方式设计，遵循关注点分离原则。模块边界应与业务能力和领域上下文对齐。所有模块都遵循最小依赖原则，仅导入必要的依赖项以减少系统复杂性。
### V. 项目架构设计原则
本项目采用分层架构设计，通过模块化组织代码，支持淘特投放业务的各种场景需求。架构层次包括：
1. **接入层**：处理请求接入和协议转换
2. **解决方案层**：业务解决方案的统一入口
3. **子解决方案层**：细粒度的业务处理能力
4. **模块构建层**：按业务功能划分的模块构建器
5. **数据服务层**：负责各种业务数据的获取、处理和封装
6. **外部服务层**：负责调用外部服务并进行模型转换
7. **领域模型层**：定义核心业务对象和数据传输对象
8. **基础设施层**：包含基础组件和框架封装
9. **通用模块层**：公共组件和工具类
### VI. 依赖管理
遵循最小依赖原则：每个模块应只拥有其实际需要的依赖项。避免模块之间的循环依赖。使用依赖注入实现松耦合。定期审核和更新依赖项以最小化安全漏洞。这确保了可维护和高效的代码结构。
### VII. 代码风格一致性
在整个项目中保持一致的代码风格，使用标准化的格式化规则。所有代码在合并前必须通过静态分析检查。一致地遵循设计模式，并对与标准实践的任何偏差提供清晰的证明。这确保了统一的代码规范和样式，符合项目标准。
### VIII. Speckit中文本地化
所有speckit相关文件、文档和配置都应使用中文，以支持本地开发团队。`.specify/`和`specs/`目录中的文件和相关speckit构件必须使用中文，以便本地开发人员更好地理解和维护，同时应为可能服务国际市场面向用户的组件保留国际化支持。
## 安全和合规要求
所有代码必须符合阿里巴巴的安全标准，并在部署前进行强制性安全审查。必须为所有暴露的端点实现适当的身份验证和授权。敏感数据必须根据内部合规要求进行处理。必须扫描依赖项中的安全漏洞。
## 开发工作流程
1. 所有代码更改必须遵循标准的阿里巴巴开发工作流程：功能分支、代码审查、自动化测试和CI/CD管道验证。拉取请求必须通过所有测试并获得指定审阅者的批准后才能合并。除非明确批准进行具有迁移计划的破坏性更改，否则所有更改必须向后兼容。每次更改都必须遵循模块设计原则并保持代码风格一致性。
2. 所有操作不要创建新分支，而是在当前分支下进行
3. 代码生成必须遵循code-generation-prompt.aonerule文件
## 治理
本宪法凌驾于所有其他开发实践之上，必须在存储库中的所有工作中遵循。对本宪法的任何修改都需要正式文档、团队批准和迁移计划。所有PR和代码审查必须验证是否符合这些原则。

speckit.specify—编写规格说明

这一步会新建一个分支，创建spec.md、requirements.md等文件，这里反复修改了多次，主要还是后续的执行不理想的返工。

NN红包模块规格说明（spec.md）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

# NN红包模块规格说明
## 功能概述
NN红包模块用于在NN频道页面展示用户可用的红包列表，帮助用户了解可以使用的优惠。
## 功能需求
### FR-1: 红包数据获取
**描述：** 系统应该能够查询用户在当前NN业务场景下可用的红包
**前置条件：**
- 用户已登录
- 配置了红包池ID（fundPoolIds）
- 配置了规则id（customRuleId）
- 配置了securityCode
**输入：**
- userId：用户ID
- fundPoolIds：红包池ID列表
- customRuleId：自定义规则ID
- securityCode：安全码
**处理逻辑：**
1. 调用FpProvider.queryUserFundBuyPoolId()查询红包
2. 过滤条件：
   - 红包状态（payStatus）= 2（可使用）
   - 红包未过期（当前时间在startTime和endTime之间）
   - 红包门槛 <= 配置的amountThreshold（默认20元）
**输出：**
- 返回符合条件的红包列表
**异常处理：**
- 如果FpProvider调用失败，返回空列表
- 如果用户未登录，返回空列表
...
...
...
**处理逻辑：**
1. 如果红包列表为空，不展示模块（返回null）
2. 构建NnRedPacketVO：
   - redPacketList：转换每个红包为RedPacketItem
   - totalAmount：计算所有红包金额总和
   - expandText：从配置获取展开文案
**输出：** NnRedPacketVO
## 非功能需求
### NFR-1: 性能要求
- 红包查询超时时间：500ms
- 如果超时，返回空列表，不影响页面其他模块
### NFR-2: 可扩展性
- 支持配置不同的红包池ID
- 支持配置不同的门槛限制
## 测试用例
### TC-1: 正常流程 - 有可用红包
**前置条件：**
- 用户ID：123456
- 配置的红包池ID：[1001, 1002]
- FpProvider返回2个可用红包：
  - 红包1：金额5元，门槛15元
  - 红包2：金额10元，门槛25元
**执行步骤：**
1. 调用 doBuild(context)
**预期结果：**
- 返回的VO不为null
- redPacketList包含2个红包
- totalAmount = "15.00"（5 + 10）
- 红包按门槛排序（红包1在前）
### TC-2: 边界条件 - 红包门槛超限
**前置条件：**
- FpProvider返回1个红包，门槛25元
- 配置的amountThreshold = 20元（2000分）
**预期结果：**
- 返回null（因为门槛超限，红包被过滤）
...
...

speckit.plan—制定实施计划

这一步会生成data-model.md、api.md等几个文件，最重要的是plan.md

speckit.tasks—任务分解

生成task.md

speckit.implement—实现代码

数据服务实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

@Component
public class NnRedPacketDataService implements DataService<List<FundQueryDTO>> {
    @Autowired
    private FpProvider fpProvider;
    @Override
    public List<FundQueryDTO> execute(InvocationContext context, JSONObject businessReq) {
        long userId = context.getUserId();
        if (userId <= 0) {
            return Collections.emptyList();
        }
        // 获取配置
        String poolIdsStr = businessReq.getString("nnRedPacketPoolIds");
        List<Long> fundPoolIds = parsePoolIds(poolIdsStr);
        Long customRuleId = businessReq.getLong("customRuleId");
        String securityCode = businessReq.getString("securityCode");
        // 查询红包
        List<FundQueryDTO> funds = fpProvider.queryUserFundBuyPoolId(
            context, fundPoolIds, customRuleId, securityCode
        );
        if (CollectionUtils.isEmpty(funds)) {
            return Collections.emptyList();
        }
        // 过滤可用红包（按规格FR-1的过滤条件）
        Long amountThreshold = businessReq.getLong("amountThreshold", 2000L);
        return funds.stream()
            .filter(fund -> fund.getPayStatus() == 2)  // 可使用状态
            .filter(fund -> isNotExpired(fund))         // 未过期
            .filter(fund -> fund.getAmountThreshold() <= amountThreshold)  // 门槛限制
            .collect(Collectors.toList());
    }
    private boolean isNotExpired(FundQueryDTO fund) {
        long now = System.currentTimeMillis();
        return fund.getStartTime() <= now && now <= fund.getEndTime();
    }
    // ... 其他方法
}

模块构建器实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

@Component
public class NnRedPacketModuleBuilder extends BaseModuleBuilder<NnRedPacketVO> {
    @Override
    public String getName() {
        return "nnRedPacket";
    }
    @Override
    protected NnRedPacketVO doBuild(InvocationContext context) {
        // 获取红包数据（FR-1）
        List<FundQueryDTO> funds = ContextUtils
            .<List<FundQueryDTO>>getBizResult(
                NnRedPacketDataService.class.getSimpleName(),
                context,
                500
            )
            .orElse(Collections.emptyList());
        // 如果无可用红包，不展示模块（FR-3）
        if (CollectionUtils.isEmpty(funds)) {
            return null;
        }
        // 红包排序（FR-2）
        List<FundQueryDTO> sortedFunds = sortFunds(funds, context);
        // 构建VO（FR-3）
        return NnRedPacketVO.builder()
            .redPacketList(buildRedPacketList(sortedFunds))
            .totalAmount(calculateTotalAmount(sortedFunds))
            .expandText(getExpandText(context))
            .build();
    }
    /**
     * 红包排序：NN专属红包优先，其次按门槛从小到大
     * 对应规格 FR-2
     */
    private List<FundQueryDTO> sortFunds(List<FundQueryDTO> funds, InvocationContext context) {
        JSONObject extraParams = getExtraParams(context);
        String nnPoolIdsStr = extraParams.getString("nnRedPacketPoolIds");
        Set<Long> nnPoolIds = parsePoolIds(nnPoolIdsStr).stream()
            .collect(Collectors.toSet());
        return funds.stream()
            .sorted(Comparator
                .comparing((FundQueryDTO fund) -> 
                    nnPoolIds.contains(fund.getFromFundId()) ? 0 : 1)
                .thenComparing(FundQueryDTO::getAmountThreshold))
            .collect(Collectors.toList());
    }
    // ... 其他方法
}

完整的单元测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

@RunWith(MockitoJUnitRunner.class)
public class NnRedPacketModuleBuilderTest {
    @Mock
    private InvocationContext context;
    @Mock
    private NnRedPacketDataService dataService;
    @InjectMocks
    private NnRedPacketModuleBuilder builder;
    /**
     * 测试用例 TC-1: 正常流程 - 有可用红包
     */
    @Test
    public void testBuild_WithAvailableFunds_ShouldReturnVO() {
        // 准备数据
        List<FundQueryDTO> mockFunds = Arrays.asList(
            createFund(1L, 500L, 1500L),   // 5元，门槛15元
            createFund(2L, 1000L, 2500L)   // 10元，门槛25元
        );
        // Mock
        when(dataService.execute(any(), any())).thenReturn(mockFunds);
        mockContext(context, "nnRedPacketPoolIds", "1,2");
        mockBizResult(context, NnRedPacketDataService.class.getSimpleName(), mockFunds);
        // 执行
        NnRedPacketVO result = builder.doBuild(context);
        // 验证（按规格预期结果）
        assertNotNull(result);
        assertEquals(2, result.getRedPacketList().size());
        assertEquals("15.00", result.getTotalAmount());
        // 验证排序：门槛低的在前
        assertEquals(1500L, result.getRedPacketList().get(0).getAmountThreshold());
    }
    /**
     * 测试用例 TC-2: 边界条件 - 红包门槛超限
     */
    @Test
    public void testBuild_ThresholdExceeded_ShouldReturnNull() {
        // 准备数据：门槛25元，超过配置的20元
        List<FundQueryDTO> mockFunds = Arrays.asList(
            createFund(1L, 500L, 2500L)
        );
        // Mock（配置amountThreshold=2000，即20元）
        JSONObject businessReq = new JSONObject();
        businessReq.put("amountThreshold", 2000L);
        when(dataService.execute(any(), eq(businessReq))).thenReturn(Collections.emptyList());
        mockBizResult(context, NnRedPacketDataService.class.getSimpleName(), Collections.emptyList());
        // 执行
        NnRedPacketVO result = builder.doBuild(context);
        // 验证（按规格预期结果）
        assertNull(result);
    }
    /**
     * 测试用例 TC-3: 异常场景 - FpProvider返回null
     */
    @Test
    public void testBuild_ProviderReturnsNull_ShouldReturnNull() {
        // Mock
        when(dataService.execute(any(), any())).thenReturn(null);
        mockBizResult(context, NnRedPacketDataService.class.getSimpleName(), null);
        // 执行
        NnRedPacketVO result = builder.doBuild(context);
        // 验证（按规格预期结果）
        assertNull(result);
    }
    /**
     * 测试用例 TC-4: 异常场景 - 用户未登录
     */
    @Test
    public void testBuild_UserNotLogin_ShouldReturnNull() {
        // Mock：userId = 0
        when(context.getUserId()).thenReturn(0L);
        when(dataService.execute(any(), any())).thenReturn(Collections.emptyList());
        mockBizResult(context, NnRedPacketDataService.class.getSimpleName(), Collections.emptyList());
        // 执行
        NnRedPacketVO result = builder.doBuild(context);
        // 验证（按规格预期结果）
        assertNull(result);
    }
    // 辅助方法
    private FundQueryDTO createFund(Long id, Long amount, Long threshold) {
        FundQueryDTO fund = new FundQueryDTO();
        fund.setFundId(id);
        fund.setAvailableAmount(amount);
        fund.setAmountThreshold(threshold);
        fund.setPayStatus(2);  // 可使用
        fund.setStartTime(System.currentTimeMillis() - 3600000);  // 1小时前开始
        fund.setEndTime(System.currentTimeMillis() + 3600000);    // 1小时后结束
        return fund;
    }
}

SDD带来的改进

一致性显著提升

代码层面：

• 所有代码都严格遵循规格说明，消除了理解偏差
• 不同开发者实现相同规格，代码风格完全一致
• 代码变更时，必须先更新规格，保证文档与代码同步

业务层面：

• 产品、开发、测试对需求的理解高度一致
• 减少了需求理解偏差导致的返工

可测试性大幅提升

测试覆盖：

• 自动生成的测试用例覆盖了所有正常和异常流程
• 测试用例与规格说明一一对应，确保完整性
• 边界条件和异常场景都有明确的测试用例

测试质量：

• Mock方式规范统一，符合项目最佳实践
• 断言准确全面，不会遗漏关键验证点
• 测试代码可读性好，易于维护

可维护性显著改善

文档永不过期：

• 规格说明就是最准确的文档
• 任何变更都先更新规格，再同步代码
• 新人通过阅读规格说明就能快速理解功能

变更影响分析：

• 修改规格时，清晰知道影响哪些代码模块
• 依赖关系在规格中明确定义
• 重构时可以基于规格验证正确性

代码可读性：

• 代码结构清晰，层次分明
• 注释完整准确，与规格保持一致
• 命名规范统一，易于理解

团队协作效率提升

• 新人通过阅读规格说明快速上手
• 跨团队协作时，规格成为统一语言
• 历史需求回溯更容易，规格即完整记录

SDD的问题与挑战

虽然SDD带来了价值，但在实践中也遇到了一些明显的问题：

问题1：规格编写门槛高

现象： 编写高质量的规格说明需要较强的抽象能力和文档编写能力

• 新手往往写不好规格，过于技术化或过于模糊
• 规格模板虽然有，但如何填写仍需要经验
• 不合格的规格对后面的代码实现影响

影响： 对于简单需求，写规格的时间甚至超过直接写代码

问题2：Spec Kit工具链不成熟

遇到的具体问题：

1. 规格解析不准确
   • AI有时无法正确理解规格中的复杂逻辑
   • 需要用非常精确的语言描述，稍有歧义就可能理解错误
2. 代码生成质量不稳定
   • 相同的规格，不同时间生成的代码质量差异大
   • 有时生成的代码过于冗长，有时又过于简化
3. 增量更新困难
   • 规格修改后，很难做到只更新变化的部分
   • 往往需要重新生成整个文件，导致手工修改的部分丢失

问题3：与现有代码库集成困难

现象： 我们的代码库已经有大量历史代码，SDD更适合从零开始的新项目

• 历史代码缺乏规格说明，无法纳入SDD体系
• 新老代码风格混杂，维护成本反而增加
• 团队一部分人用SDD，一部分人用传统方式，协作困难

问题4：学习成本高

数据：

• 写出合格的第一份规格说明，平均需要3-5次迭代
• 老员工接受度较低，认为”还不如直接写代码快”

SDD适用场景分析

经过3个月的实践，我们总结出SDD的适用场景：

适合使用SDD：

✅ 全新的项目或模块

✅ 核心业务逻辑，需要长期维护

✅ 复杂度高，需要详细设计的功能

✅ 多人协作的大型需求

✅ 对质量要求极高的场景

不适合使用SDD：

❌ 简单的工具函数或配置修改

❌ 快速验证的实验性功能

❌ 一次性的临时需求

❌ 对现有代码的小修改

当前最佳实践 -

Rules + Agentic Coding + AI文档汇总

融合各阶段优势

核心思路：

1. 用Rules约束AI
2. 用技术方案指导实现
3. 用Agentic Coding快速迭代
4. 用AI汇总文档保持同步

技术方案模板优化

我们优化了技术方案模板，更加轻量级：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# [需求名称]-技术方案
## 业务定义
[简要描述业务背景和目标，1-2句话]
## 业务领域对象
[如果需要新增/修改BO或DTO，在此说明]
## 模块领域对象
[需要新增/修改的VO对象]
| 对象含义 | 实现方案 | 属性及类型 |
|---------|---------|-----------|
| [对象名] | 新增/修改 | 1. 字段1：类型 - 说明<br>2. 字段2：类型 - 说明 |
## 数据服务层
[需要新增/修改的数据服务]
| 数据服务定义 | 实现方案 | execute逻辑 |
|------------|---------|-----------|
| [服务名] | 新增/复用 | 1. 步骤1<br>2. 步骤2 |
## 模块构建器
[需要新增/修改的模块构建器]
| 模块构建器定义 | 实现方案 | doBuild逻辑 |
|--------------|---------|-------------|
| [构建器名] | 新增/修改 | 1. 获取数据<br>2. 处理逻辑<br>3. 构建VO |

特点：

1. 比SDD规格更轻量，编写时间从2小时降低到30分钟
2. 比纯Agentic Coding更规范，有明确的结构约束
3. 聚焦于”做什么”，而非”怎么做”（实现细节交给AI）

AI文档汇总机制

即：让AI自动维护”整体架构与业务逻辑文档”

文档汇总流程

1

完成需求开发 → 提交AI："将本次代码逻辑汇总到汇总文档" → AI分析代码 → AI更新文档

Prompt示例：

1
2
3
4
5
6
7
8
9

我刚完成了NN红包模块的开发，请分析以下代码：
- NnRedPacketDataService.java
- NnRedPacketModuleBuilder.java
- NnRedPacketVO.java
然后将其业务逻辑汇总到"NN业务整体架构与逻辑文档.md"中，确保：
1. 描述模块的核心功能和业务价值
2. 说明数据流转过程
3. 列出关键的业务规则和判断逻辑
4. 保持与现有文档的风格一致

架构文档结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# NN业务整体架构与逻辑文档
## 一、业务概述
[业务背景、目标、核心价值]
## 二、整体架构
### 2.1 技术架构
[分层架构图、技术栈]
### 2.2 模块组成
[各个模块的功能和关系]
## 三、核心模块详解
### 3.1 NN Feeds模块
#### 3.1.1 功能说明
[模块的核心功能]
#### 3.1.2 数据流转
[数据从哪里来，经过哪些处理，最终输出什么]
#### 3.1.3 关键逻辑
[重要的业务规则、计算逻辑、判断条件]
#### 3.1.4 代码位置
[对应的类和方法]
### 3.2 NN红包模块
[类似结构]
### 3.3 NN吊钩层模块
[类似结构]
## 四、数据服务层
[各个数据服务的功能和依赖]
## 五、关键流程
[重要的业务流程时序图]
## 六、配置说明
[配置项说明]
## 七、扩展点
[未来可能的扩展方向]

AI汇总效果示例

AI生成的文档片段：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

### 3.2 NN红包模块
#### 3.2.1 功能说明
NN红包模块用于在NN频道页面展示用户可用的红包列表，帮助用户了解可以使用的优惠，提升转化率。
#### 3.2.2 数据流转
用户请求 → NnRedPacketDataService 
         → 调用FpProvider查询用户红包
         → 过滤可用红包（状态=2，未过期，门槛<=20元）
         → 返回红包列表
         ↓
NnRedPacketModuleBuilder
         → 获取红包数据
         → 红包排序（NN专属优先，门槛从小到大）
         → 构建NnRedPacketVO
         → 返回前端

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

#### 3.2.3 关键逻辑
**1. 红包过滤规则**
```java
// 只展示满足以下条件的红包：
// 1. 状态为可使用（payStatus = 2）
// 2. 未过期（当前时间在startTime和endTime之间）
// 3. 门槛 <= 配置的amountThreshold（默认20元）
if (fund.getPayStatus() != 2) return false;
if (fund.getStartTime() > now || now > fund.getEndTime()) return false;
if (fund.getAmountThreshold() > amountThreshold) return false;
**2. 红包排序规则**
```java
// 排序规则：
// 1. NN专属红包（配置的nnRedPacketPoolIds）优先
// 2. 其次按门槛从小到大排序
funds.stream()
    .sorted(Comparator
        .comparing(fund -> nnPoolIds.contains(fund.getFromFundId()) ? 0 : 1)
        .thenComparing(FundQueryDTO::getAmountThreshold))
**3. 总金额计算**
```java
// 计算所有可用红包的金额总和
String totalAmount = funds.stream()
    .map(FundQueryDTO::getAvailableAmount)
    .reduce(0L, Long::sum)
    .map(PriceUtils::getPriceFenToYuan)
    .orElse("0.00");
#### 3.2.4 代码位置
- 数据服务：`NnRedPacketDataService`
  - 位置：`dataservice/impl/nn/NnRedPacketDataService.java`
  - 核心方法：`execute(InvocationContext, JSONObject)`
- 模块构建器：`NnRedPacketModuleBuilder`
  - 位置：`module/nn/NnRedPacketModuleBuilder.java`
  - 核心方法：`doBuild(InvocationContext)`、`sortFunds(List<FundQueryDTO>)`
- 模块VO：`NnRedPacketVO`
  - 位置：`domain/module/nn/NnRedPacketVO.java`
#### 3.2.5 配置项
```json
{
  "nnRedPacketPoolIds": "1001,1002,1003",  // NN专属红包池ID
  "amountThreshold": 2000,                  // 红包门槛上限（分）
  "expandText": "展开查看更多"              // 展开文案
}

思考总结

在淘特导购业务的AIcoding实践中，我们经历了从简单代码补全到Agentic Coding，再到基于规则和SDD的编程模式的演进过程。每个阶段都有其价值和局限性：

1. 初期探索让我们认识到AI在编码辅助方面的潜力，但也暴露了缺乏规范指导的问题；
2. Agentic Coding提升了功能实现的完整性，但可延续性和一致性仍有不足；
3. 基于规则的模式有效解决了代码规范和架构一致性问题，成为当前的主要实践方式；
4. SDD尝试虽然在理念上很有价值，但在实际应用中还需要进一步完善。

虽然在SDD编程方面遇到了一些挑战，但我们认为AI规范化编程是未来发展的方向。团队中的同学正在持续探索和优化：

1. 完善工具链：改进Spec Kit等工具，提升自动化能力
2. 优化流程整合：更好地将SDD模式与现有开发流程结合
3. 降低学习成本：通过培训和实践案例帮助团队成员适应新模式
4. 持续改进规则：根据实践经验不断完善规则定义

我们相信，通过持续的探索和实践，一定能找到更适合团队的AI辅助编程模式，进一步提升开发效率和代码质量。

Kuikly 开发框架笔记

Kuikly（Kotlin UI Kit，发音同quickly），是使用Kotlin开发了声明式UI框架，映射到系统原生控件做渲染，最终用KMM（Kotlin Multiplatform Mobile）实现跨端。
Kuikly是一个开发语言高度同源的跨端框架，从业务代码、UI框架、布局层以及渲染层全部使用Kotlin语言（iOS渲染层是OC），这样不仅减少跨语言通信的性能成本，而且开发体验上更纯粹和高效。编译产物上，Android端采用原生的AAR方式，而iOS端通过KMM编译生成.framework，这样就不仅保证了原生开发体验，也保证了原生性能。如果希望实现动态化，Android端可以通过KMM编译成SO，iOS端可以编译成JS（KMM已经可以编译成Wasm，未来有稳定版本后就可以正式使用）。Kuikly具有优异的原生开发体验，相比于Hippy，更符合终端开发习惯。

跨端框架对比

Kuikly 和 ComposeDSL 的对比

最终选择方向 2

对比官方Compose 区别

Kuikly 架构图

Kuikly 跨端渲染原理

1. 将 Kotlin 代码编译成各个平台可执行产物
2. 运行时调用各平台 Native 层渲染接口进行渲染
   1. RN 框架的流程 (三个虚拟树)
      1. 创建JS DOM 树 (平台无关)
      2. C++ 影子树 (平台无关)
      3. 原生渲染树
   2. 问题 - 跨语言序列化反序列化开销
   3. Kotlin 只维护一个树, 直接映射到原生渲染
      1. 在 Kotlin 层构建原型树
      2. 在 Kotlin完成测量和布局(影子树)
      3. 各平台支持统一的渲染接口, 如创建/删除/插入/设置属性/设置节点位置
      4. 转到平台各自原生渲染层,
3. 原生渲染层, 渲染分为三种类型承接:
   1. View 通用属性
      1. Modifier.border 映射到 View.border
      2. .background 映射到 View.background
      3. .scale 映射到 View.transform
   2. 原子组件
      1. Text () 创建组件 TextView
      2. Image() 创建组件 ImageView
      3. LazyXXX() 创建组件 ScrollView
   3. Canvas 渲染
      1. Canvan { drawRect, drawCircle} 转发原生 CanvasView -> drawRect/ drawCircle

Kuikly DSL语法

1. 声明式 api: 在原类拓展一个 init 的语法糖, 比如 TextView, 对应语法糖是 Text,
2. 使用@DslMarker解决不能 Text 不应该嵌套的问题

Diff 性能

调研结果：现有框架没有完全O（1）的解决方案

Kuikly 解决方案:

if -> vif
else -> velse
elseif -> velseif
when -> vbind
for -> vfor
开发的时候需要额外学习成本, 渲染时候能精确更新, 实现 O(1)的性能

怎么基于 Kotlin实现响应式?

1. 基于 Kotlin 的属性委托能力 by observable() 将属性变成响应式属性
2. 属性 getter/setter 触发时候, 触发依赖收集/订阅分发
3. 只收集单向依赖, 破解死循环

比鸿蒙原生还快

鸿蒙性能优化关键点

1. llvm 的 CPU Feature参数错误导致内联(inline)生效, 修正后性能提升 30%
2. 鸿蒙软件模拟了线程私有参数, 导致频繁 throw 的时候性能低下, 提升 30%
3. GC 优化

Vibe Coding 在代码生成与协作中的实践与思考 - 向邦宇

自我介绍：

• 多年从事研发者工具开发，包括内部 AI Coding 工具和 Web IDE 工具
• 从 2023 年开始，从内部 Copilot 转型到 AI Agent 方向
• 作为产品提供方，接触了大量内部用户，观察他们如何使用工具以及遇到的问题

演讲选题思考：

• Vibe Coding 概念出现几个月，但并非确定性的东西
• 不同人对 Vibe Coding 理解不同，使用的工具也不同
• 从两个视角分享：用户使用场景和问题、产品提供方的思考和解决方案

演讲结构：

1. 简单介绍业界和内部有哪些 Vibe Coding 工具在使用
2. 用户在使用 Vibe Coding 工具过程中遇到的问题
3. 作为 Vibe Coding 工具核心主导者的思考
4. 国产模型适配过程中遇到的问题和解决方案

Vibe Coding 产品形态

当前工具分类的模糊性：

• 大家对 Vibe Coding 工具的理解和分类不够清晰
• 每个工具都有人在用，但缺乏明确的定位

不同 Vibe Coding 工具的主要区别

1. Native IDE（原生集成开发环境）

• 代表产品：Cursor、Cline、阿里 Qoder 等
• 特点：以独立 IDE 形式存在
• 优势：灵活性高，功能完整

2. IDE Plugin（IDE 插件）

• 代表产品：内部 Aone Copilot 等
• 基于现有 IDE（主要是 VS Code 或 JetBrains）的插件形式
• 内部用户使用插件是比较主流的习惯
• 灵活性可能没有 Native IDE 那么高

3. Web IDE

• 入口在浏览器上
• 整个执行在远端容器里，可能是沙箱环境
• 优势：
  • 解决信任问题和云端执行的安全问题
  • 更适合协作：多个同学可以在同一个 Web IDE 里进行同步协作和分享
  • 跨平台支持

4. CLI 命令行工具

• 代表产品：Copilot CLI
• 最初没想到会受欢迎，但实际上非常受主流研发欢迎
• 未来可能在被集成的方式（如 CI/CD）中执行一些自动化任务
• 在这种场景下会有更高的可能性

内部 Vibe Coding 工具的使用实践

Aone Copilot（依托于 IDE 的Wibe Agent工具）：

• 内部协作多年的产品
• 用户规模：数万用户，每周几千周活
• 主要使用场景：
  • 代码生成
  • Bug 修复
  • 代码分析
• 用户分布：后端场景渗透率较高，前端用户更倾向使用 Native IDE（如 Cursor 或 Qoder）

AI Agent（异步容器执行的 Agent 工具）：

• 以 Web 端发起的容器内运行的异步任务工具
• 核心特点：用户通过自然语言发起任务
• 在异步容器里拉起 Agent，Agent 自己调用工具（搜索工具、文件读写工具、Shell 工具等）
• 用户角色更加多元：
  • 主要用户：后端开发
  • 其他用户：测试、前端、算法、产品、运营、设计、运维等
• 任务类型丰富多元：
  • 代码分析
  • 代码改动
  • 单元测试
  • 代码生成
  • 文案方案调研等

工具尤其是 Agent 带来的效率提升

数据观察（从 4 月份开始的 Agent 模式）：

代码提交量的显著提升：

• 蓝色线：高频用户（使用 Agent 模式）
• 橙色线：其他用户
• Agent 模式下，高频用户的每日代码提交行数有非常大的提升
• 到 9 月份，高频用户每天提交 540-560 行代码，其他用户只有 400 多行
• 至少从定量指标看，Agent 模式对提效肯定有帮助

用户分层现象：

• Top 10% 用户的代码提交量是其他人的两倍
• 认为 Agent 对人的提效可能大于两倍，因为大量工作在协同、开会等非编码环节
• Top 10% 用户的 Copilot 消耗占整体消耗的 80%

AI 新的应用场景：

• 单元测试由 AI 生成的提交代码占比越来越高
• JDK 升级、NPM 包升级、SDK 升级等工作已经可以由 AI 完成
  • JDK 11 及以上版本升级场景，内部基本全部交给工具处理
• 数据分析、数据整理工作部分交给 AI
• 传统必须由人完成的任务现在由 Agent 完成：
  • 测试过程中的截图
  • 压测过程中的重复任务
• 过去成本过高无法做的事情现在可以做：
  • 一次发布是否会引起其他相关系统故障
  • 每一行代码对其他系统的影响分析

用户使用 Vibe Coding 工具遇到的问题

用户情绪问题

AI 表现不足导致的崩溃：

• 后台日志中大量用户抱怨”AI 太笨了”等激动的话
• 用户反复删除代码、修改代码的行为
• 无论公司内部还是社区，都能看到用户因 Agent 能力不足而崩溃

GitHub 上的”八荣八耻”提示词：

• 用户分享给 Agent 的提示词规范
• 例如：”以不能修改原始代码为荣”等

5.2 代码质量问题

我们看到的 Vibe Coding 的问题是多方面的

1. 代码风格不一致
   • 生成的代码质量和风格差异较大
   • 在存量仓库里写代码时，可能以自己的风格编写，而非遵循项目规范
2. 边界条件处理不完善
   • 对复杂业务逻辑的边界情况处理不够充分
3. 性能缺陷
   • 生成的代码存在性能问题
4. 安全漏洞
   • SQL 注入类漏洞严重
   • 斯坦福研究表明：AI 生成代码中注入类漏洞比例约 45%
   • 其他安全问题：
     • 接口注入
     • XSS 攻击
     • 逻辑错误
     • 边界条件处理错误
     • 异常控制

• 数字越界

代码逻辑自洽问题

• AI 在代码生成过程中会有非常多的”自洽”
• 案例：数据去重函数及其对应的单元测试
  • 测试通过率 100%
  • 针对代码做了单测
  • 但如果让 AI 同时写单测和业务逻辑，无法保证质量
  • 会出现”自己和自己对话”的情况
• 建议：至少有一项（单测或业务逻辑）是人去 review 的

调试和维护困难

调试时间增加：

• 使用工具后，调试时间增加 30%-50%

1. 黑盒问题
   • Vibe Coding 更倾向于黑盒代码逻辑生成
   • 虽然最后会让人确认代码 diff 才能提交
   • 但生成过程是黑盒，不会有人认真看每一条
   • AI 生成代码像”黑魔法”，出问题时完全不知道如何下手
   • 技术债务越来越深
2. 上下文理解局限
   • 存量任务的业务逻辑可能积累十几年
   • 有些代码为什么要这么写？有些代码是否能去掉？对 AI 来说都很困难
   • Vibe Coding 工具缺乏全局思维
   • 生成的代码模块化程度不够，代码耦合度很高
   • 解决方案：RepoWiki, DeepWiki 等方案
3. 缺乏可追溯性
   • Vibe Coding 一次性生成大量代码
   • AI 无法知道：是新需求导致代码写错，还是一开始就写错了
     • 缺乏版本管理和版本概念
     • 一次生成代码出错后，不知道从哪个地方回滚
   • 现有方法：
     • 每次改完测试通过后提交一个 commit, 下次可以从这个 commit 回滚
     • 使用 Cursor 等回滚工具
   • 但仍然缺乏可追溯性，用户无法做版本管理，无法回到正确状态，只能重来

Vibe Coding 工具普遍不会使用常用的调试工具

• AI 普遍不会使用人类常用的调试工具
• 传统”古法编程”中，开发者大量使用 Debug、断点等工具
• 浏览器上也可以做调试
• 但让 Vibe Coding 工具使用这些调试工具去找堆栈、找问题非常困难
• 工具能力缺失导致的问题：
  • AI 只能打大量的 console.log, 让用户执行完后，把 log 或控制台的报错、打印信息再粘贴给工具
  • 需要人介入
  • 不是高效的模式
• 大模型的调试手段比较单一，传统调试方法无法被大模型用起来

Vibe Coding 工具本身存在的问题

1. 稳定性和成功率：

• 最大的问题
• Vibe Coding 工具执行时间很长（30 秒到 5 分钟）
• 不是每次都能成功
• 失败原因：
  • 模型问题
  • 工具反馈不对
  • 某些工具出错
  • IDE 本身不稳定
• 用户体验：用过一次发现不稳定，在时间紧、任务重时就不会再使用

2. 交互界面设计问题：

• 大量 Vibe Coding 工具产品频繁改版，功能丢失
• 案例：Devin
  • 改版后用户找不到原来的功能
  • 工具里增加越来越多功能（剧本、MCP 市场、知识引入等）
  • 现在再看又没有了
• 交互界面频繁改版

3. 沟通和交互障碍：

• 理解能力不足：AI 无法完全理解用户意图，需要反复确认
• 不同场景下确认的必要性不同：
  • 复杂任务：需要确认（如 SpecCoding - 先建需求、生成设计稿、再让 AI 做）
  • 简单任务：不需要确认，需要 Agent 自由探索

4. 长链路任务执行能力不足：

• 无法维持长期上下文
• Agent 大模型的 token 有上限
• 上下文过长时，记忆和召回能力不足

5. 工程工作流程中断：

• 大量工具（IDE, CLI, Web Agent 等）各有擅长领域
• 无法让用户在相同流程或上下文窗口里解决问题
• 案例：在 IDE 里做一件事,需要切换CLI, 重新给 Agent介绍诉求和需求
• 导致用户在不同工具间频繁切换

成本问题

成本问题导致各方不满意：

1. Agent 的 Token 消耗巨大：

• 代码补全场景：
  • 调用频次高
  • 单次消耗约 4000 Tokens
• Vibe Coding 任务：
  • 单次消耗百万级甚至千万级 Tokens
  • 原因：
    • 上下文更长
    • 交互轮次多（几十上百次）

2. Vibe Coding 加速带来的技术债务：

• 技术债务反而对 Agent 提出更高要求

3. 成本上升导致产品方频繁调整计费逻辑：

• 产品方（Cursor、Qoder 等）频繁切换计费逻辑
• 没有任何一款产品敢保证包月或无限次使用
• 成本压力导致产品设计不断调整：
  • 压缩上下文
  • 削减能力
• 恶性循环：
  • 成本降低 → 成功率下降 → 用户多试几次 → 成本又上升
• 产品方为了活下去压缩成本，但效果变差，用户要多试几次，成本又上去
• 使用闭源模型（Claude、GPT-4、GPT-5）后成本难以下降

5. 缺乏规模效应：

• 大模型应用有规模效应，但不明显
• 不存在”用户规模越大，成本就越低”的效应
• Token 成本是固定的

产品自身也遇到的挑战

产品的演进导致模型成本越来越高

Token 消耗的演进：

1. 代码补全场景：

   • 单个任务：约 4000 Tokens 输入
   • 输出：20-30 Tokens

2. Chat 模式：

   • 单个任务：约 1000+ Tokens 输入
   • 输出：约 4000+ Tokens

3. 单个 Agent 模式（IDE/CLI）：

   • 单个任务：约 10 万级 Tokens

4. 具备独立容器的 Vibe Coding Agent：

   • 能广泛使用各种工具
   • 实现各种内容、各种任务类型
   • 单个任务：百万级 Tokens

5. 未来的架构（Cursor, TRAE 等）：

   • 单个任务：可能上亿 Tokens

产品设计的两个同等重要目标：

1. 用户满意度
2. 成本控制能够匹配用户规模

产品形态的问题

1. 产品界面区分度不够：

• 无论 Chat 产品还是 Vibe Coding 产品，都处于摸索阶段
• 模型能力变化使产品不断变化
• 所有产品都是一个对话框（ChatGPT、DeepSeek、AI 产品）
• 用户难以区分不同产品的区别

2. 用户缺乏引导：

• 给用户一个对话框，但用户不知道应该输入什么
• “Prompt Free”现象
• 不同工具有不同使用场景，但用户往往一刀切
• 用户印象中产品应该能做什么，但试用后发现达不到目标
• 功能学习成本高，使用频次低
• 留存率非常低（Devin 等 Vibe Coding 工具都存在这个问题）

3. 缺乏一站式功能闭环：

• 无法在一个产品里解决所有问题
• 案例：
  • 一个 Vibe Coding Agent 能解决复杂产品问题
  • 但又能解决小白/初学者问题
  • 小白面临的问题不仅是代码能否写完，还有发布、部署、调试等
• 发展过程中存在各种调整

安全风险问题

案例 1：Cursor 删除本地代码：

• Cursor 把用户本地代码删掉
• 类似的小 case 还有一些

案例 2：Anthropic Claude 被劫持：

• 今年出现好几次
• Claude 被劫持后，让 Vibe Coding 工具在用户网络里探测漏洞
• 写代码把敏感信息暴露出来

内网使用的安全考虑：

• 不能完全相信 Vibe Coding 工具
• 供应链攻击问题
• 开源代码的风险：
  • 很多人在开源社区里种木马
  • 不注意可能拉取到的 SDK 或代码存在漏洞
• Vibe Coding 工具对代码和电脑有基本控制权
• 能够自由探索，找到系统漏洞并攻击

Agent 建设过程中一些经验分享

All In One 架构导致成本几句上升

最初的 All In One 架构问题：

• 建设 Vibe Agent 时采用的架构就是一个输入框
• 外围：MCP 工具、knowledge、Playbook 一些剧本
• 最外围：场景图（数据处理、后端开发、前端开发、代码浏览、风险管理等）

All In One 架构的问题：

1. 所有工具都放入沙箱
2. Context 特别长，无法压缩成本
3. 最开始一个任务调用 Claude 模型需要几百块钱成本，非常高
4. 任务成功率低
5. All-in-one 时，所有工具和 knowledge 放在一起：
   • 成本特别高
   • 占用特别长
   • 消耗大量资源
6. 很难针对不同场景进行调优
   • 案例：与 Bolt 等产品对比，发现它们在前端场景有很好实现
   • 但自己的产品在前端场景做得不够让人满意

知识和数据建设

1. 代码数据建设
   • 通过建设 DeepWiki、RepoWiki、Embedding 数据库
   • 增强对整体代码库的搜索、理解和搜索能力
2. 研发行为数据
   • 构建、CI/CR、发布、监控等行为数据
   • 背靠整个集团内部平台（发布平台、代码平台等）
   • 建立代码数据和需求数据与这些行为的组合
3. 文档知识库
   • 问题：文档知识库无法被Agent 直接用起来
   • 原因：
     • 文档可能过时
     • 前后矛盾
     • 图文混杂
     • 存在错误信息
   • 直接把这些信息丢给 Agent 会产生误导
   • 解决方案：
     • 不用传统 RAG 技术解决
     • 建立中间层
     • 面向 Agent 的数据处理协议
4. 开发者知识沉淀
   • 很多知识不在文档里，也不在代码里，在开发者脑子里
   • 需要产品设计帮助用户沉淀这些知识
   • 不是靠任何东西生成，而是靠人来写

Agent 对上下文记忆处理的几个核心

记忆处理机制：

• 写入
• 提取
• 压缩
• 隔离

1. 任务管理和技能交互
2. 文件操作
   • 读写编辑
   • 文件管理
3. 命令行和执行监控
   • Agent 可以执行命令行
   • 有些命令是长耗时的
   • 如何监听命令结果
   • 超时后如何 kill 掉
4. 浏览器自动化工具
   • 执行网页操作
   • 使用 Playwright 等方式点击页面, 帮助登录或解决交互问题
5. 手机相关工具
6. 多媒体工具
7. 开发工具
   • 将用户写的代码部署、调试到指定地方
8. 协作工具
   • 团队协作
   • 任务分享给其他人
   • 基于任务继续协作
9. 高级功能
   • 并行执行优化
   • 网络搜索

成本控制方案

Token 消耗优化历程：

• 最开始：400-1000 万 Tokens/任务
• 意识到这是最严重的问题
• 通过各种设计和操作降低 Token 成本

国产模型适配实践

为什么要拥抱国产开源模型

国外闭源模型的风险：

1. 成本高
       - 复杂问题往往很长
       - 能让 Agent 在复杂任务下跑起来的模型非常贵

2. 隐私问题：
       - 闭源模型存在合规风险

3. 被限流和被降质：
       - 即使用同一个供应商的模型
       - 不同时候表现也不一样
       - 有时会出现格式不对、陷入循环等问题

4. 国外模型的备案问题：
       - C 端用户使用可能存在备案问题

国产模型在短链和长链任务的问题

短链任务表现已经很好
长链任务还存在一些问题

国产模型存在的问题

1. 死循环问题：
       - Agent 有很多选择和路径
       - 执行过程中可能陷入某种循环
       - 反复出不来
       - 案例：反复打开一个文件、反复执行某一项命令
2. 格式遵循能力不足：
       - 常见问题：XML 标签格式不准确
       - 前后无法匹配
       - 导致无法被正确解析
       - 容易失败
3. 指令遵循问题：
       - 在高达百万 Token 的上下文下
       - System Prompt 里给的规则
       - 模型如果没有被训练到，很难使用这些工具
       - 运行过程中会忘记某些指令
4. 全局智能问题：
       - 观察发现模型存在全局任务理解能力缺陷
       - 容易陷入”一步一步看”的情况
       - Token 消耗大
       - 步骤时间长

解决方案

1. 针对稳定性问题：
       - 主流模型的切换和重试
2. 应对速度慢和 Infra 稳定性问题：
       - 当模型输出被截断时
       - 做一些有效输出或续写设计
3. 健康检查和死循环检测：
       - 在 Agent 里做检测
       - 针对重复执行某个指令的死循环场景
       - 相同错误点的无限循环问题
       - 陷入明显错误逻辑时能够检查到
4. 格式检查和修复：
       - 检测到不完整标签时
       - 通过堆栈方式自动补齐缺失的结束标签来修复

重试机制

主备切换

工具的解析与自动修复

成果

• 在内部基本已经把国外模型全部去掉
• 内部全部使用国产模型
• 实时检测任务是否进入死循环
• 进入死循环后进行干预：
  • 把后面任务执行截掉
  • 对任务总体做 summary 压缩
  • 让它继续往下走

模板化设计解决 Prompt Free 问题

Prompt Free 问题

普通用户/小白用户面临的问题：

1. 不知道产品能干什么
2. 知道要干什么，但不知道如何提要求
3. 不知道在产品里使用什么样的工具或知识
4. 导致任务成功率很低
5. Token 消耗也很大

模板化解决方案:

• 某个垂直任务，有人通过很多探索做成功了（很满意）能否把它抽象成一套模板？
• 针对不同垂直场景不断积累这些模板
• 使成功率变高，Token 消耗变低
• 面对对话框时给用户一些灵感

模板的本质：

• 一套工具的组合
• 一个知识的组合

使用流程：

1. 用户看到对话框
2. 先选一个模板
3. 再执行任务

效果：

• 约 50% 的用户任务现在都用了模板
• 使用模板后任务成功率提升

总结下：

• 固化 Prompt
• 固化工具
• 固化知识
• 形成模板后，用户生成任务时先选模板，再执行

架构上的更多创新

长上下文任务的问题

案例：

• 先做深度调研
  • 要先写一个网页
  • 再写一个 PPT

• 单 Agent 的问题：
  • 上下文非常长
  • 需要频繁做 summary、压缩
  • 裁剪工具输出
  • 才能保证任务质量高
• 没有子 Agent 之前的主任务需要频繁做所有琐事
  • 从上到下每个步骤：
    • 调网页
    • 打开网页
    • 把网页内容写下来
    • 做 summary
    • 写 PPT
    • 写网页
  • 项目越来越长, 任务执行完成率非常低, 效果也不好

Agents 拓扑解决方案

灵感来源：

• Manus 1.5, 提出 Agents 拓扑概念
• Agent 本身也是一个工具

实现方式：

• 假设有一个 Deep Research 工具，做得很好
• 可以自己做网页搜索、做 summary
• 主 Agent 只要调用它就够了
• 把这部分工具抽象出来，成为一个工具

演进路径：

• 过去：Function Call
• 后来：LLM Call
• 现在：用 Agent 来做
• 把一个 Agent 当作一个工具去做子任务

智能体时代的强化学习：AReaL框架与Agent最佳实践

以 RL 打造 Agent

两个核心”暴论”

1. Agent是未来五年AGI时代最重要的事。
2. 强化学习是构建Agent最关键的技术。

强化学习的历史发展与突破

强化学习的早期认知

大多数人对强化学习的认知来源于：

• AlphaGo：DeepMind用强化学习训练围棋智能体，击败李世石和柯洁
• OpenAI打Dota：2019年用强化学习击败两届世界冠军OG
• 其他游戏AI：腾讯打王者荣耀、星际争霸等

当年的强化学习智能体主要都是打游戏的，与大模型驱动的AGI时代似乎没有太大关系。

强化学习与大模型的结合转折点

2020-2022年的关键变化

GPT-3 API的问题：

• 2020年OpenAI推出GPT-3 API时存在严重问题
• 例子：输入”explain the moon landing to a six year old in a few sentences”
• GPT-3会输出重复内容：”explain the serious gravity, explain the serious relative, explain blah blah blah”
• 原因：大模型训练基于next token prediction，但用户给的是指令（instruction following problem）

注: “Next Token Prediction”（下一个 token 预测）是大语言模型（LLM）的核心机制。简单来说，它的意思是：给定一段文本的前面部分，模型预测接下来最可能出现的“token”是什么。

RLHF技术的突破：

• OpenAI花了两年时间解决这个问题
• 2022年推出InstructGPT，采用RLHF（Reinforcement Learning from Human Feedback）技术
• 方法：找人标注数据，判断哪些回答遵从指令，哪些不遵从
• 训练奖励模型，然后用强化学习让模型探索获得最高分数的回答
• 结果：同样的基座模型，有没有强化学习决定了好用还是不好用

注: RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习）是一种用于对齐大语言模型（LLM）的技术。它的核心目标是：让模型的输出更符合人类的偏好、价值观和意图，而不仅仅是“语法正确”或“统计上常见”。

强化学习推动AGI产品发展的三个阶段

• 第一阶段：2022年ChatGPT
  

  • 由RLHF技术引爆，让大家第一次感受到AGI能力
  • 强化学习捅破了窗户纸，让AGI能力真正可用

• 第二阶段：2024年推理模型（Reasoning Model）
  

  • 也称为思考模型（Thinking Model）
  • 特点：给模型一个问题后，它会先想一会，输出大量thinking token
  • 例子：帮我算个24点，思考模型(比如 deepseek)会先在”草稿纸”上写10分钟(输出thinking token)，然后给答案
  • 技术：也是强化学习驱动，模型自己探索如何思考, 思考什么，自己判断答案对不对, 也就产生了推理模型
  • 训练范式与RLHF类似，但判断标准可能不同

• 第三阶段：2025年Agent模型
  

  • 基于Agent的强化学习技术
  • 代表产品：ChatGPT Deep Research 等

Agent产品的发展与特点

成功的Agent产品案例

• ChatGPT Deep Research
  • 2024年第一个比较成功的Agent产品
  • 功能：给它一个topic，帮你做研究
  • 工作流程：
    • 花很多时间思考
    • 调用工具，在网上搜索很多topic
    • 可能运行20分钟到1小时
    • 最终给出非常详实、有大量引用和reference的报告
• Manus /ChatGPT Agent / Kimi Agent Mode
  • 功能更丰富，可以帮你做PPT
  • 在Sandbox（沙盒）环境中工作：
    • 读取PDF文件
    • 在阅读器中打开PDF
    • 存储PDF文件
    • 编辑和创建文件
    • 在虚拟机中进行各种操作

Agent能力的演进

从Deep Research到Manus的发展体现了Agent能力的进步：

• Deep Research：除了对话，可以调用搜索工具、浏览器工具，将信息放在Context Window中处理
• Manus：更进一步，加上了Sandbox工程AI，相当于有了自己的电脑

AI的能力演进：

1. 有了脑子（大模型）
2. 有了草稿纸和笔（Context Window）
3. 有了一台自己的电脑（Sandbox）

产品发展趋势分析

• 用户交互的变化
  • ChatGPT时代：需要很长的prompt，详细描述要做什么
  • Agent时代：用户说的话越来越抽象，越来越少
• AI能力的变化
  
  • ChatGPT：1秒钟给出文本输出
  • Thinking Model：1-2分钟思考后给出答案
  • Agent Model：1小时处理复杂任务，主动行动
  • 未来: 牛马 AI, AI一直在做事, 主动帮人安排
• 从Reactive到Proactive的转变
  
  • 传统模式：用户告诉AI做什么（Reactive）
  • 未来趋势：AI主动准备，告诉用户要不要（Proactive）
  • 例子：OpenAI的ChatGPT Plus每天主动推送早报等内容

未来愿景

理想的AI助手具体技术化来讲：

• 信息模糊处理：人很难把想做的事讲清楚
• 个性化：每个人的需求不一样
• 主动规划：主动安排和执行任务
• 提前工作：AI不需要休息，可以一直工作

什么是好的 Agent 团队

• 组织 AI 化
• 技术栈完整
• 持续高速0-1 创新, 高效迭代

为什么Agent需要RL(强化学习)

市面上Agent 有各种 framework, 这些框架主要通过拖拉拽的方式构建Agent工作流，但对于复杂的Agent问题存在局限性。

强化学习解决的三大核心问题

问题一：处理不确定性和冲突信息

• 案例：阿里CTO是谁？
  

  • 阿里和蚂蚁有很多子公司，每个公司都有CTO
  • 搜索”蚂蚁CTO”会得到很多不同的结果
  • 需要AI去理解和判断才能做出正确回答

• 案例：退票问题
  

  • 用户说”退票”，但上下文可能很不确定
  • 退什么票？需要AI主动提问澄清

问题二：长期记忆和个性化

• 案例：美团小美推荐
  
  • 我说”要吃晚饭，要清淡点”
  • AI推荐白灼生菜等蔬菜
  • 但我从来不点蔬菜，喜欢吃肉
  • “清淡点”对我可能意味着”清淡点的肉”
  • 需要从很长的记录中挖掘个性化信息

问题三：海量工具和模型选择

• 案例：Reddit上的模型组合使用
  
  • Claude写代码很聪明但Context Window短且贵
  • Gemini写代码不够聪明但Context Window长且便宜
  • 用户发现可以用Claude调用Gemini：让Gemini读代码，然后扔给Claude写
  • 相当于”聪明的人指挥体力无限的傻子干活”
  • 这种最佳实践应该由AI自己探索出来，而不是人工定义规则

强化学习的统一解决方案

强化学习可以用统一的框架解决这些复杂问题：

• 让AI在环境中自己探索
• 涌现出处理复杂任务的能力
• 比规则和Workflow更灵活和强大

搜索智能体案例深度分析-看似简单的问题实际很复杂

问题案例：伦敦奥运会中国金牌数

表面上的简单：

• 问题：伦敦奥运会中国拿多少块金银铜牌？
• 看起来很简单，百度搜索就能找到答案
• 官网显示：中国队拿了38块金牌，是2012年历史第二高的成绩

实际的复杂性：

• 正确答案应该是39枚金牌
• 原因：2012年伦敦奥运会女子田径竞走项目
• 中国派出三位选手，当时拿了第3、4、5名
• 后来第1、2名被查出禁药，被剥夺奖牌资格
• 11年后（2023年），中国选手获得了补发的金牌
• 所以现在问中国奥运会金牌数，答案应该是39枚

现有产品的表现
测试了多个产品：

• DeeSeek：搜出38枚金牌
• ChatGLM：38枚金牌
• ChatGPT：搜到了39枚金牌的信息，说”有一些资料显示数字略有差异，39枚金牌”，但最后结论还是38枚金牌（因为大量信息都是38枚）
• ChatGPT Agent Mode：会答对

传统方法vs强化学习方法

传统Multi-Agent System方法

需要构建复杂的多智能体系统：

• 搜索Agent
• 核查Agent
• 调用知识的Agent
• 检验Agent
• 需要很长很复杂的流程

强化学习方法

极简设计：

• 一个模型
• 两个工具：搜索工具 + 点击网页工具
• 让模型在环境中循环探索

实际效果：

• 第5轮搜到39枚金牌的新闻
• 开始疯狂核查
• 经过60多轮迭代
• 最终确定正确答案是39枚金牌
• 还具有泛化能力，可以添加更强的工具
• 32B模型可以在准确度上超越商用产品

强化学习的两大优势

1. 简单: 简化Agent的workflow, 不需要复杂的多智能体系统设计
2. 涌现: 让AI涌现出复杂的多步推理能力, 通过探索自动获得复杂能力

Agent RL 的核心难点

强化学习面临的三大挑战

要做好强化学习，必须解决三个问题：

1. 缺Infra和算法：强化学习算法运算速度很慢很慢
2. 缺数据：训练数据的获取和质量, 强化学习的数据是很缺很缺德, 预训练数据可以在网上扒, 但强化学习的数据不太能直接网上扒
3. 缺环境：Sandbox等执行环境的构建

如何全栈解决 Agent RL 的难点

Infra(基础设施)和算法优化

速度慢的根本原因

强化学习的三个流程：

1. 生成：让模型在环境中交互生成数据
2. 评分：用奖励模型计算奖励
3. 训练：放到训练集中训练

复杂性分析：

• 涵盖了三种完全不同的计算模块
• 预训练只有训练，SFT只有训练，评测只有评测
• 强化学习包含：训练、评测、在线生成、Sandbox等
• 是一个算法编排了多种完全不同计算模式的复杂系统

算法与系统协同设计的重要性

为什么需要协同设计：

• 强化学习算法创新很容易碰到系统瓶颈
• 四个系统模块(推理/训练/环境/算法整合)中任何一个打满都会成为瓶颈
• 强化学习算法很容易打到系统瓶颈

团队组织建议：

• 做算法的同学需要了解Infra
• 做Infra的同学需要了解算法
• 最好能坐在一起工作, 这是加快创新节奏的重要方式

具体的性能瓶颈

搜索智能体的统计数据：

• 平均搜索时间：要调用 google 搜索引擎, 一个batch 5-10分钟
• 长尾效应严重：特别难的prompt需要1-2小时
• 问题：如果每个batch都要等最慢的那个，一天24小时只能更新12-24次
• 导致大量CPU/GPU等待时间

AReaL的解决方案：异步架构

核心思想：推理不能等

• 一部分卡不停地做推理，没有等待
• 训练也没有等待，有数据就训练
• 中间用随时更新参数的方式
• 如果推理到一半需要更新参数，就停下来更新，然后用新参数继续rollout
• 实现完全没有系统资源浪费

技术创新：

• 系统上做异步调整
• 算法上做相应调整以适应异步更新
• 在Agent场景上实现5倍加速，且没有效果损失

训练数据问题

数据稀缺的问题

• 预训练可以直接从网上获取数据
• 强化学习的训练数据不能直接从网上获取
• 一般问题都跟简单, 用户提出的复杂问题很少，难以挖掘复杂问题的测试集

数据合成解决方案

Agenic合成数据方法：

1. 从网页上获取答案（搜索比较简单，从答案开始）
2. 从答案构造问题
3. 不断让问题变得更加复杂
4. 评估问题，保证问题和答案匹配正确
5. 难度检查：问题不能太难也不能太简单，需要适合强化学习自我提升的难度
6. 构造出适合的训练数据

开源贡献：

• 数据、代码和脚本都已开源
• 帮助社区训练更好的Agent产品

环境构建 - Aworld 项目

• 主要是Sandbox等执行环境的构建
• 未来会开源更多的Sandbox项目
• 帮助大家训练更好的Agent产品

让更多人用 RL 训练更好的 Agent

AReaL团队发展历程与经验总结

团队发展时间线

• 2020年：开始做开源学术项目，多智能体强化学习框架
• 2022年：第一个大规模游戏场景可用的强化学习分布式训练框架
• 2023年：当时最快的RLHF框架
• 2024年：开始做AReaL，专注Agent AI

技术循环的有趣观察

回到原点的循环：

• 2025年的强化学习与当年打游戏很像
• 有个大模型在”玩游戏”（Sandbox可以是浏览器或电脑）
• 遇到的问题与打游戏类似：有黑盒环境，很慢，不能修改游戏规则
• 五年后技术回到了当年的原点
• 系统设计和算法技术都有循环

重要的经验教训

技术需要两个条件才能发挥价值：

1. 技术需要对的时间
   • 强化学习如果在2022年以前，大家很难感知到价值
   • 不是大家的错，而是技术没有在对的时间被感知
2. 技术需要好的产品承载
   • 强化学习技术如果不是因为ChatGPT、RLHF、Agent model，大家可能也感知不到
   • 技术本身可能没有价值，需要好的产品去承载才能发挥更大价值

团队理念：

• 技术一定要产品化, 所有技术同学都应该尽可能把技术产品化
• 希望创造能够实现AGI的Agent产品, 成为支持产品持续进化的平台

总结与展望

核心观点回顾

1. Agent是AGI时代最重要的事情：从产品发展趋势和技术演进可以看出Agent的重要性
2. 强化学习是Agent的最关键技术：能够统一解决Agent面临的复杂问题，让AI涌现出复杂能力

技术发展趋势

• 从简单的对话模型到能够主动行动的Agent
• 从Reactive到Proactive的转变
• 从规则驱动到强化学习驱动的智能涌现
• 算法与系统协同设计的重要性日益凸显

未来展望

• Agent产品将越来越智能和主动
• 强化学习技术将在Agent领域发挥更大作用
• 需要更好的基础设施、数据和环境支持
• 技术产品化是实现价值的关键路径

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

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，将其作为强大的杠杆，释放工程师的创造力，共同应对大前端领域越发复杂的稳定性挑战，奔赴星辰大海。

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

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

AI Coding 发展史和现状

AI模型发展速览

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

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

• 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将重新定义软件生产流程，推动研发模式向智能化、自动化演进。

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

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

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

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

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人工智能席卷而来的浪潮里面抓住机遇勇于创新, 说不定会有意想不到的惊喜和收获.