一个小模型意图识别系统的 5 天进化实录：支付宝 618

这是2026年的第35篇文章

（ 本文阅读时间：约 25 分钟 ）

01

业务背景

2026 年，AI 不再是一个 buzzword——它已经切切实实地渗透进了每一行代码、每一次技术决策。说来惭愧，作为一个校招入职不到两年的程序员，我的 IDEA 已经吃灰半年多了。那些曾经引以为傲的快捷键肌肉记忆，如今被同事们调侃为"古法编程"。大模型这波浪潮，不是未来已来，是过去已去。

6 月，支付宝 CY26-618 电商大促如期而至。今年的技术命题只有一个：让 AI 能力真正触达 C 端用户，真正走进 C 端用户的购物体验。

先看结果——下面是我们在这场大促中交出的答卷：

AI 找优惠一期：以 Agent 为本

一期的核心能力是猜你喜欢式的智能推荐。结合了用户画像、跨阵地消费行为、点击偏好等多维数据，让 AI 从20多个权益池中，自主筛选并推荐它认为用户最可能感兴趣的权益。

这套方案的优势是零门槛——用户打开页面就能看到优惠，不需要任何操作。从产品逻辑上看，它更像一个推荐系统：如果 AI 比用户自己更了解用户的消费偏好，为什么还要让用户费力思考？最好的服务，是预判需求、主动满足。

不过，推荐逻辑有一个天然局限：当用户带着明确诉求进来时——比如我就想买手机，有什么券？——推荐系统只能给出它认为你可能喜欢的，而不是你当下真正想要的。换句话说，一期擅长回答你可能喜欢什么，但无法回答你现在想要什么。

AI找优惠一期-推荐版

AI 找优惠二期：以人为本

二期在一期推荐能力的基础上，增加了对话式交互。核心理念是：当用户有明确诉求时，搜索比推荐更准确——用户比 AI 更懂自己当下想要什么，我们要做的不是替用户做决定，而是听懂用户说的话，然后精准响应。

具体来说，二期让用户可以主动输入自然语言表达需求（想买个蓝牙耳机，200 以内/有没有手机券），系统理解意图后精准匹配权益或商品。对话式的交互形态也为后续的多轮追问、意图流转打开了想象空间。

AI找优惠二期-会话版

我在其中做什么

在二期的整体链路中，我的工作聚焦在一个关键环节：意图识别。整个动线大致如下：

意图识别是整个链路的「翻译层」——它把用户说的人话，翻译成下游系统能消费的结构化查询。意图判错了，后面召回再准也没用；关键词提错了，搜出来的东西牛头不对马嘴。所以这个模块虽然只占链路的一小段，但对最终体验的影响是决定性的。

02

意图识别：让AI听懂人话

在自然语言处理领域，意图识别（Intent Detection）是一个经典命题——从搜索引擎的查询理解，到对话系统的槽位填充，再到推荐系统的用户建模，本质上都在回答同一个问题：用户到底想要什么？

用户意图不是一个待检索的答案，而是一段持续演化的心理过程。

传统的做法是把意图当作一个分类任务：预设几十个意图标签，用标注数据训练一个分类器，输入一句话，输出一个标签。这套范式在封闭场景下工作得很好——比如订机票，查天气，设闹钟。但面对开放域的消费场景，问题就暴露了：用户的表达方式无穷无尽，"想给女朋友买个生日礼物"和"有没有适合送人的东西"说的是同一件事，但传统分类器很难将两者映射到同一个意图。更关键的是，用户的真实意图往往是跨品类的、流动的、甚至是用户自己都说不清楚的——这不是一个分类问题能解决的。

大语言模型的出现改变了游戏规则。LLM 不再依赖预设的标签体系，它可以直接理解语义、追踪上下文、进行推理。这让意图识别从分类问题变成了理解问题——不是把用户的话塞进某个预定义的桶里，而是真正读懂用户在说什么。

落到我们的场景，AI找优惠的交互形式很简单：用户输入一句话，AI 推荐合适的权益和商品。

但一句话背后的意图千差万别。我们首先把用户意图分成了四种类型：

四种类型定义清楚之后，优先级就自然出来了：

• ITEM 和 BENEFIT，一定是 L1（最高优先级）。用户已经明确说了要什么，不需要追问，直接推荐。

• VAGUE，这才是需要模型动脑子的地方。用户有购物倾向但品类不明确——模型需要进一步判断这个意图的明确程度，给出 L2～L4 的优先级打分，同时引导用户澄清意图，直到达到L1等级。

• IRRELEVANT，无关。用户就是来闲聊的，别硬塞优惠券。

到这里，问题定义清楚了。但接下来要面对的是一个更棘手的工程问题：用什么模型来跑这套意图识别？

03

模型选型— 4 小时从调研到拍板

选模型不是拍脑袋，得先想清楚约束条件。我们的约束有五条：

1. 快：用户在对话框等回复，首 token 必须在 1～2 秒内出来，不然用户就走了。

2. 省：618 大促流量不小，用 DeepSeek-V4-Pro 级别的模型按 token 计费，预算扛不住。

3. 准：四种意图类型的区分不是关键词匹配。模型得理解"想给女朋友买个礼物"和"有没有适合送人的东西"是同一回事。

4. 记得住：一次对话，system prompt 5000 token左右，用户输入 50 token左右，模型输出 100 token左右。模型上下文大小32K是合理底线。

5. 别越界：会场侧不持有商品数据，没有SKU列表，没有推荐算法。模型只需要做一件事——把用户的自然语言翻译成下游能消费的【意图类型，关键词，用户描述摘要】。它不需要懂商品，不需要做推荐，它是一个翻译官，不是一个导购。

模型唯一要做的事：把「人话」翻译成「机器能懂的查询语言」。意图类型告诉下游「用户想要什么」，优先级告诉下游「有多确定」，关键词告诉下游「具体搜什么」。

接下来的模型选型，要在快、省、准、记得住、别越界这五条约束下，找到最适合的模型。基于上述的分析，要求时延短，场景不复杂，可以预想到用户意图识别模型应该是一个小模型，而我们的时间窗口只有 4 个小时——从开始调研到产出评估报告，中间没有喘息空间。

3.1 站在巨人的肩膀上：别人是怎么选的？

与其从零开始翻模型列表，不如先问问踩过坑的人。我们快速联系了三个有类似场景的团队，学习一下前辈的经验：

• A 团队在一期用 Qwen3-14B 做用户意图识别，后续迭代升级到 Qwen3-235B。原因在于他们的品类集中在自身域内，需要在模型里注入用户在该域内的特殊领域知识（如积分、专属权益等），因此对模型理解能力有更高要求。

• B 团队用 Qwen3-8B做用户意图识别。他们的场景是与某对话式生活助手类产品联动——当用户在该助手中输入的文案被识别为购物 / 订单/ 泛导购场景时，会走对接链路调用意图识别。他们把整条链路拆成两个阶段：第一阶段核心是理解用户请求、识别子意图、抽取类目 / 场景 / 实体，生成"粗分类 + 决策摘要"；第二阶段才把商品相关内容补齐。

• C 团队用 Qwen3-30B 做用户意图识别。

三个团队三种选择，没有标准答案。但这一圈问下来，候选范围迅速收敛到了 Qwen3 系列——8B、14B、30B。三个档位都有团队在实战中使用，说明这个系列在意图识别场景下经过了线上验证。

3.2 候选名单：从七到四的筛选

结合外部经验，我们从蚂蚁内部大模型推理平台上拉取了所有 8B、14B、30B 档位的 Qwen3 系列模型，初始候选共七个：

七个模型覆盖了纯文本、多模态、嵌入三种类型。我们需要从中筛选出真正适配意图识别场景的候选。

3.2.1 排除多模态模型

Qwen3-Omni-30B-A3B-Instruct 和 Qwen3-VL-8B-Instruct 被首先排除。理由有二：

第一，输入形态不匹配。当前AI找优惠的交互形式是用户输入纯文本，没有任何图片、语音或视频输入。多模态模型的视觉编码器和音频编码器在这个场景下完全闲置——你为这些能力支付了额外的推理开销，但它们永远不会被用到。

第二，推理效率不对等。以 Qwen3-VL-8B-Instruct 为例，即使输入为纯文本，其视觉模块仍然占用显存并参与计算图。同等参数规模下，纯文本 Dense 模型的 TTFT 和吞吐都优于多模态模型。在 618 大促对延迟极度敏感的场景下，这是不可接受的代价。

当然，如果未来产品迭代方向是用户拍照上传商品图片 → AI 识别并推荐优惠，多模态就是刚需。但那是另一个项目的事，不影响当前选型。

3.2.2 排除嵌入模型

Qwen3-Embedding-8B 也被排除。嵌入模型确实有人在意图识别场景中使用——方案是将用户输入向量化，与预定义的意图向量做相似度匹配，归入最近意图类别。这套方案的优势是极快、极便宜。但它不适合我们的场景；

第一，任务性质不匹配。我们的意图分类不是简单的【文本 → 标签】映射。用户说想给女朋友买个礼物，模型不仅要判断这是模糊意图，还需要生成追问文案（如预算大概多少？有什么偏好吗？）。嵌入模型只能输出向量，无法生成自然语言；

第二，语义理解深度不足。嵌入模型的相似度匹配基于表层语义。"有没有数码产品的券"和"百亿补贴有手机吗"在嵌入空间里可能很接近（都提到商品+优惠），但我们的业务需要区分商品意图和权益意图。嵌入模型对这种细粒度意图边界的区分能力远弱于 LLM；

第三，维护成本。用嵌入模型需要维护意图向量库、持续更新阈值、处理边界 case。而一个 LLM 的 system prompt 可以直接承载所有规则，改规则就是改 prompt，不需要重建向量索引。

3.2.3 最终候选：四位选手

排除多模态和嵌入模型后，剩下的四位全部是 Qwen3 纯文本系列：

阵容挺全：有轻量级的 8B，有中坚力量的 14B，还有两个 30B 的 MoE 选手。实际效果如何？往下看。

3.3 评测的第一步，不是跑模型

很多人做模型选型的第一反应是：把候选模型拉出来，跑一遍 benchmark，看谁分高选谁。

但这里有一个被忽略的前提——你拿什么来跑？如果评测集本身不可信，跑出来的分数就是垃圾进、垃圾出。这跟训练神经网络是一个道理：标签错了，loss 再低也没意义。

所以我们做的第一件事不是跑模型，而是准备用例集。

3.3.1 第一步：基于业务规则，定向构造用例

我们没有从线上随机采样，而是根据第二章定义的四种意图类型和分类规则，按业务规则定向构造用例。每条用例必须满足三个条件：

1. 覆盖边界：每种意图类型都要覆盖典型场景和边界场景。比如 ITEM 不仅要包含"我想买个手机"这种直白表达，还要覆盖"有没有数码产品的券"这种商品+权益双重意图的边界case。

2. 贴近真实：用例的语言风格要像真实用户——口语化、有省略、甚至有错别字。"请为我推荐一款适合送女友的生日礼物"不行，"给女朋友买个礼物，不知道买啥"才行。

3. 可标注性强：每条用例的意图类型和优先级必须有明确答案，不存在这样判也行那样判也行的歧义。连人都纠结的 case 直接扔掉。

按照这套规则，我们构造了一份结构化的训练用例集（TRAIN_DATA.yaml），每条用例包含 name（用例名）、expected_type（期望意图类型）、expected_level（VAGUE 类型的 L2-L4 等级）、prompt（用户输入）、expected_output（期望输出的 JSON 结构）。数据集按意图类型分块组织：

评测训练数据集举例说明

# ============================================================
# ITEM — 品类词+规格属性
# ============================================================
- name: ITEM-128G白色手机
expected_type: ITEM
expected_level:
thinking:false
prompt: 想买个128G白色手机
expected_output:
intentType: ITEM
clarifyQuestion:""
intentSummary:"用户明确指定品类（手机）、容量（128G）和颜色（白色）"
keywords: ["手机","128G","白色"]
# ============================================================
# BENEFIT — 寻找优惠券/红包/权益
# ============================================================
- name: BENEFIT-有红包吗
expected_type: BENEFIT
expected_level:
thinking:false
prompt: 有红包可以领吗
expected_output:
intentType: BENEFIT
clarifyQuestion:""
intentSummary:"用户寻找可领取的红包权益"
keywords: ["红包"]

用例集的设计核心就一条：边界 case 比典型 case 更重要。典型 case 所有模型都能做对——我要买手机判为 ITEM 没什么好比的。真正拉开差距的是边界 case：商品+权益双重意图怎么判？多轮对话中意图从 VAGUE 流转到 ITEM 时模型能不能跟上？这些才是评测的区分度所在。

3.3.2 第二步：人工审查，锁定黄金用例集

用例集是使用 GLM-5.1 这类较聪明的模型，基于我们输入的判断规则生成的，但最终结果仍需人工审查一遍。下面是一个存在二义性的例子：用户输入「电脑配件有红包可以领取吗」。从语义角度，这应该归类为权益；但我们目前可能没有电脑配件相关的权益，用户输入这句话后页面会返回「抱歉，未能找到相关权益」，体验较差。所以，受限于权益多样性以及下游搜索接口的能力，这类 case 我们选择识别为商品意图——通过获取用户的购买意图，进而给用户推荐天猫或阿里妈妈的商品。

-name:ITEM-电脑配件+红包
expected_type:ITEM
expected_level:
thinking:false
prompt: 电脑配件有红包可以领吗
expected_output:
intentType:ITEM
clarifyQuestion:""
intentSummary:"品类：电脑配件；用户同时关注可领取的红包"
keywords: ["电脑配件"]

黄金用例集的核心价值不在于数量，而在于每一条都经过了人工校验，标注结果是可信的。这就像深度学习的训练集——你可以只有 100 条数据，但如果这 100 条的标签是人工精标的，它比 1000 条自动标注的数据更有评测价值。

3.3.3 第三步：使用候选集模型进行评测

有了黄金用例集之后，评测流程就很清晰了：四个候选模型各自跑一遍全部 case，输出意图类型和优先级，跟黄金标注对比，算准确率。这里有两点需要注意：一是如何保证模型调用的公平公正——我们采用蚂蚁内部大模型推理平台的调用脚本，保证每次都是一次全新调用，没有上下文干扰；二是保证各模型加载的系统提示词和用户输入是同一个版本，这样消融实验唯一的变量就是模型本身。

以下是一条 L4 用例在两个模型上的实际输出对比：

输入: 随便看看 |期望等级: L4 |思考模式: 关闭

Qwen3-8B 输出：

TTFT: 0.83s | Prompt tokens: 2723 | Completion tokens: 59

{
"level":"L4",
"recommendations":"我是购物助手，想找什么类型的商品，或者有什么购物方面的想法，随时告诉我。",
"intent_summary":"用户购物意图模糊，无明确品类、场景或目标。"
}

Qwen3-14B 输出：

TTFT: 1.09s | Prompt tokens: 2723 | Completion tokens: 57

{
"level":"L4",
"recommendations":"欢迎！想找什么类型的商品，或者有什么购物方面的想法，随时告诉我。",
"intent_summary":"用户购物意图模糊，无明确品类、场景或目标。"
}

3.4 四维评测：一张表看清四个模型

有了四个模型在 52 条黄金用例上的完整输出，接下来就是逐条比对、统计、分析。我们把评测拆成了效果、时延、成本、上下文四个维度，一张表汇总：

从我们的评测来看，我们最初选择的是14B，效果最好，时延也还不错。其次是8B，效果略低但时延最好。但因为资源问题，14B交付有风险，所以最终线上我们使用的是8B，不是因为 8B 完美，而是在所有约束条件下，它是最务实的选择。

04

系统提示词调优实战

选完模型只是拿到了一个还算趁手的工具。真正让这把工具变得锋利的，是接下来的系统提示词自进化。

4.1 从手工调参到自动化框架：三次迭代

Qwen3-8B 部署好了，第一版 system prompt 也写好了。我满怀期待地跑了一遍评测用例，加权得分80.8。不算差，但离"能用"还差一截。

于是我开始手动调 prompt。改两个词，重跑全部 case，肉眼对比输出差异。再改一段规则，再跑一遍。三四个来回之后，我就崩溃了——每次调整到底是在变好还是变坏，我完全靠感觉判断。某个 case 修好了，另两个 case 又坏了，我甚至不确定是不是自己记错了上一轮的结果。

手动调 prompt 的本质问题是：你没有反馈回路。你只有一双会疲劳的眼睛和一个会自我欺骗的大脑。

第一次迭代：搭建自动化闭环

思路很朴素：既然我手动做的事情无非是「跑评测 → 看分数 → 改 prompt → 再跑评测」，那为什么不让程序来做？

于是搭了一套自动化闭环：

框架会自动扫描reports/round_N/决定当前轮次，从prompts/system_prompt.md的 symlink 反推当前版本号，然后进入评测、打分、收敛判断、改写四个阶段。跑起来之后，我终于从人工调参中解放了出来——每次改完 prompt，跑一轮评测，分数自动出来，badcase 自动归类，自动改进系统提示词。

第二次迭代：引入 test_split，从背题到学习

第一版框架跑了几轮之后，一个致命问题暴露了：所有评测、打分、改写都在同一批数据上进行。改出来的 prompt 越来越像是在背答案。下图可以很清晰地看出，系统提示词耦合了太多训练集中用例的字样。

解决方案很直接：像训练深度学习模型一样训练系统提示词。我把用例集切分为训练集和测试集：

• 训练集：用于发现 badcase，驱动 prompt 改写。每轮改写器只分析训练集上的失分 case，从中抽象规则来优化系统提示词。

• 测试集：用于验证泛化能力。测试集不参与改写，只在每轮结束后独立评测。

引入 test_split 后，流程变成了在训练集上训练系统提示词，在测试集上测试系统提示词，通过训练集中的 badcase 来优化整体的系统提示词。

收敛条件也相应升级为双门槛：train ≥ 90 且 test ≥ 92，两者同时达标才算收敛。如果 train 涨了但 test 跌了，框架层会标注可能存在过拟合。这个设计倒逼改写器生产出真规则而非背答案。

第三次迭代：反过拟合的多层防线

test_split解决了数据层面的过拟合，但改写器本身如果设计得不好，也可能导致过拟合。改写器做的事情很简单：把当前prompt、评分反馈、badcase 列表、意图混淆模式拼成一条消息，发给 GLM-5.1 / DeepSeek-V4-Pro等聪明的模型，让它输出一版改进后的 prompt。但"怎么让它改得好"是门手艺。如果它倾向于在 prompt 里堆砌训练集的few-shot case来刷分，依然过拟合。于是我们在改写器层面加了四个规则。

一：案例服务于规则，不是规则服务于案例。

存在多个 badcase 时，改写器必须先抽象出它们背后共同的判定规则或边界条件，把规则写进 Rules——严禁通过批量枚举案例、堆砌 few-shot、用大量"例如 X 应该输出 Y"的方式来刷指标。

二：新增案例硬上限。

每个失分维度/每条规则下，本轮迭代最多新增 1 条示意性案例。而且案例必须用来说明规则的边界或反例，不能用于穷举。

三：区分 train/test 信号，防止噪声驱动改写。

改写器收到的反馈里明确区分了训练集 badcase和测试集 badcase，并且标注了意图混淆模式：

意图混淆模式格式如下（expected→actual，按总频次排序）

• ITEM→BENEFIT: train 3 / test 2 【两端共现·真实缺口】

• BENEFIT→ITEM: train 1 / test 0 【仅训练集·疑似噪声】

• VAGUE→IRRELEVANT: train 0 / test 2 【仅测试集·泛化不足】

改写器被要求对不同信号做不同处理：

• 两端共现= 真实规则缺口，必须优先抽象成规则修复

• 仅测试集= 当前规则对未见输入泛化不足，要往"判定原理"上改

• 仅训练集= 大概率是噪声或长尾，禁止为它单独加规则

四：得分已经达到要求的维度原样不动，只改不满足的维度。

这条规则防止改写器去修改已经工作良好的部分。

4.2 双轨评分体系：规则 + LLM

评分是这套框架的心脏。我们设计了 6 个维度：

规则打分跑得飞快——intent_accuracy 就是字符串比对，format_compliance 就是 JSON schema 校验，100 条 case 毫秒级出结果。

LLM 打分就慢多了。每个维度都要把 case 的输入、期望输出、实际输出拼成一段 prompt，发给相对聪明的模型（如 GLM-5.1/DeepSeek-V4-Pro）让它按 criteria 打分。4 并发跑完 100 条 case 大约需要 2-3 分钟。

规则打分管「对不对」，LLM 打分管「好不好」。意图类型对不对，规则就能判——ITEM 被判成 BENEFIT，不需要 LLM 来告诉你这是错的。但关键词提取得好不好、追问是否自然、摘要是否准确——这些需要语义理解，规则写不出来，只能靠 LLM。

权重分配也经过了仔细考量。业务侧最在意两件事：意图别判错（30%）和关键词别提取歪（30%），这两项占了近 60% 的权重。因为下游搜索和推荐完全依赖这两个字段——意图类型决定了走商品推荐还是权益匹配，关键词决定了搜什么。

4.3 模型大方向错了怎么办？

如果模型在修改过程中大方向和你预期的不一致怎么办？例如当你在解决一个badcase的时候，你希望在系统提示词中的Workflows中新增一个Step来解决问题，而不是修改整体的提示词。如下图，我希望新增一个Step先对用户输入的意图进行无关性的初筛，如果通过了初筛再进行下面的Step。

我们的做法是及时打断正在进行的Loop，发现模型走偏的时候要及时纠正。使用PromptOptimizer优化器先写一大方向正确的粗版本，纠正完大的方向之后再执行Loop。

4.4 上线前的Bad Case，别慌，小问题

上线前2天，我们发现了由于工程链路的兜底链路导致产品无法接受的badcase。因为AI找优惠二期的链路走到权益推荐时，当前用户如果没有可用的权益或权益召回失败了就会走到兜底的商品推荐，导致给用户推荐一些和用户输入毫无关联的商品，从而给用户带来割裂感。

如下图所示：当用户问了日本签证相关的优惠券，模型会识别成权益意图，而没有权益召回时会随机召回毫无关系的商品。

遇到问题不要慌，先排除是自己的问题。这里最"优雅"的解决方案是，权益召回的时候也需要做相关度打分并且去掉工程链路的兜底商品召回的逻辑。简单来说就是，如果召回的权益和用户输入完全不相关则不推荐权益同时也不推荐一些无相关的商品。但是考虑到AI会场一期还在线上运行，这个时候为了二期去做到极致的用户体验显然不合理，所以最终的方案是：让用户意图识别模块区分——如果用户输入了非电商属性的权益，就识别成无关意图。这个问题的核心还是为了提升用户体验，如果实在解决不了，上线后再解决也不大。

道理我都懂，但是修改系统提示词好像没那么简单。

第一步：新增和调整训练集，因为在之前的版本中，只要用户问到和权益相关的输入，模型都会识别成权益意图。

第二步：人工确认提示词修改的大致方向，写一版大方向正确的粗版本。

第三步：Loop，Loop，Loop！

第四步：评测！注意，评测的标准也需要同步修改

05

效果与收益

实验结论：互动深度驱动转化效率提升

一、实验设计

本次实验以普通版本作为对照组（baseline），将对话场景下的用户行为按互动深度拆分为三个实验组：自动首推组、预设按钮交互组、自定义对话组，分别观测 clicked-through rate（CTR）与人均价值贡献两项核心指标的相对变化。

二、核心发现

1. 自动首推 alone 无法带来正向转化

在仅由系统自动推荐、未激发用户主动表达需求的场景下，核心转化指标均低于 baseline：

• 商品点击率较 baseline 下降约11.8%；

• 人均价值贡献较 baseline 下降约8.3%。

2. 用户主动互动是转化的核心驱动力

一旦用户从被动接收转为主动交互，两项核心指标均呈现显著正增长：

3. 互动深度与转化效率呈正相关

数据显示，用户互动深度越深，转化效率越高。自定义对话组作为最深度的交互形态，商品点击率可达普通版本的3.7 倍，人均价值贡献可达普通版本的2.1 倍，成为拉动整体转化的关键路径。

三、业务启示

1. 不建议单独依赖自动首推承接转化：被动的系统推荐无法替代用户意图表达，难以形成有效的转化闭环。

2. 应重点引导用户进入主动交互：通过预设按钮、自定义对话等方式降低用户表达门槛，可显著提升 CTR 与价值转化效率。

3. 自定义对话是效率最高的转化场景：在资源有限的情况下，优先建设和优化自定义对话能力，可获得最高的转化杠杆收益。

---

06

踩坑总结

回头看这一周的开发历程，坑踩了不少，但真正有价值的不是踩过哪些坑，而是从坑里爬出来之后留下了什么方法论。

6.1 重复了 3 遍就要造轮子

这句话是我在这个项目里最强烈的感受。AI 时代，造轮子的成本被大幅降低了——以前写一个脚本可能要半天，现在对着 codingagent 说一句话，30秒就出来了。举两个例子。

第一个：单元测试调优脚本。每次AI写完单元测试后，都会先执行一遍mvn install再去跑一遍全量的单元测试，单元测试的数量一多那就是纯纯在浪费时间。所以干脆写了一个跑增量单元测试的脚本，每次AI写完一个PR后，将当前的分支和master分支做diff，然后让主Agent修改并执行增量的Java类，这样AI写单测的效率直接翻倍；

第二个：评测结果可视化脚本。系统提示词自进化框架跑起来之后，每轮评测会生成一堆 JSON 报告——各维度得分、收敛趋势、badcase 分布。数据都在，但全是冰冷的数字。每次想看看这一轮比上一轮到底好了多少，得手动翻两个 JSON 文件对比。翻了三次之后，我又写了一个 Python 脚本，把reports/目录下的所有轮次数据读出来，生成一张趋势图和雷达图。从那之后，每次 Loop 跑完，打开 HTML 看一眼就知道这轮是进步还是退步。

一个顺手的脚本可能只需要 5 分钟，但它能帮你减少 50 次重复操作带来的心智损耗，会大幅提升你开发的幸福感和满足感。

6.2 Switch Context 累，但是值得

这个项目的 5 天里，典型的节奏是这样的：

• 第一个窗口在开发Java代码，并且同时有2-3个worktree在工作；

• 第二个窗口在开发系统提示词调优框架；

• 第三个窗口在跑评测数据；

• .......

这不是多线程工作，这是频繁的上下文切换。每一次切换都有成本——你需要重新加载大脑里的「当前状态」，回忆刚才写到哪了、那个变量叫什么、这个 badcase 上一轮的数据是多少。

但这件事值得做。因为 AI 时代的开发模式变了：你的角色从执行者变成了调度者，工作的吞吐量不再取决于你打字多快，而取决于你能同时让多少个 AI 在正确的方向上运转。

AI 时代并行做事情的能力，人快速切换上下文的能力，是提高自己工作吞吐量的关键点。

6.3 保持热情 + 动手能力，是 AI 时代最难能可贵的技能

AI 时代，每个人对 AI 的认知参差不齐。有人觉得 AI 什么都能做，有人觉得 AI 什么都做不好，有人觉得 prompt engineering 不算工程，有人觉得系统提示词修改很简单。这些声音都有道理，因为每个人的判断都建立在自己有限的体感上。AI 时代，保持谦逊、务实、专注自己，才是梦想中程序员的模样

07

未来展望

7.1 React Agent 架构演进

当前方案的用户意图识别和商品相关性打分，是通过内部同步接口对外提供服务的，这就意味着无法以真正的流式方式对外提供服务。