# 从选题到交付：我的第一次智能客服黑客松开发复盘

我是小熊同学，一名正在学习AI产品与Agent开发的研究生。这份记录根据赛后的一次个人分享整理，回顾自己怎样选题、做调研、补技术、搭原型，以及在时间紧张时做取舍。

过程中有试错，也有一些后来才想明白的地方。把具体步骤写下来，供第一次参赛、正在边学边做的朋友参考。

这是一份公开整理版，省略了录音信息、私人沟通、个人身份细节和非公开业务信息。技术实现与指标以仓库当前README、源码和评测记录为准。

## 一、先选择一个自己能理解、也愿意继续学的场景

拿到不同赛道后，我先想了三个问题：自己已有的知识能帮助到哪一步？还需要补多少技术？能不能在有限时间里做出一条完整流程？

我过去接触过智能硬件业务和用户需求，对售后问题有一定理解。部分其他方向需要补充更多硬件或音视频工程知识，因此选择了智能客服。

这次选择给我的启发是：先找到已有经验与真实问题的交集，再把不熟悉的部分拆成可以学习和验证的小任务。

## 二、先体验产品，再整理需求

我亲自体验了公开可访问的客服入口，观察一段求助如何开始、需要提供哪些信息、什么时候会追问、什么时候进入人工处理。

也参考了几类成熟电商与支付平台的公开交互，记录它们在快捷提问、信息确认、多轮衔接和问题分流上的做法。对公开用户反馈，我把它当作寻找问题的线索，继续结合具体场景判断。

这些体验只是有限样本，不能据此概括某家企业全部渠道的能力。我更想从中提取可验证的问题：

| 观察方向 | 我转化出的产品问题 |
|---|---|
| 用户说不清产品和故障 | 能否用候选选项或图片线索帮助表达？ |
| 用户记不住订单信息 | 能否在授权范围内主动查找，让用户确认候选？ |
| 多轮对话反复收集信息 | 能否保留当前产品、已尝试步骤和反馈？ |
| 回答看起来合理却缺少依据 | 能否展示知识来源，并限制不适用的建议？ |
| 单个工单处理完就结束 | 能否将工单集合整理成团队可核查的经营线索？ |

先写下具体问题，再决定加什么功能，比一开始就罗列很多技术名词更容易推进。

## 三、围绕问题补技术，而不是一次学完所有框架

在此前的一次行业交流中，我接触过用本体组织业务信息的思路。想到这个方向后，我回过头查阅公开技术资料，也结合自己学过的建模和图论知识理解实体、关系与规则。

决赛准备期间，我又补充学习了RAG、工作流、Agent编排和可观测性等概念，并通过小项目理解自然语言怎样连接数据读取和工具调用。

我当时还不能把每个框架都讲得很深入，于是先围绕几个具体问题学习：

- 产品、订单、知识、证据分别保存在哪里？
- 一次求助怎样关联到正确的产品？
- 哪些判断由模型提出，哪些必须由明确规则计算？
- 检索不到、信息冲突或接口失败时，系统下一步怎么办？
- 怎样让别人看见答案背后的来源？

AI工具帮我解释概念、梳理方案和指出可能的遗漏，我再回到资料、代码与小范围验证中检查。工具认可一个想法，并不能替代实际验证。

最后，我把项目的职责拆成两部分：Service Ontology组织对象和证据，Decision Ontology表达规则与动作边界。当前工程仍使用JSON关联和Python逻辑，部分业务变化也需要改代码；这是我在后续复盘中进一步厘清的边界。

## 四、先搭原型，让输入、处理和输出接上

早期先做HTML交互页面，对接模型接口，再用模拟资料验证流程。后续结合比赛提供的脱敏工单、订单和知识资料，继续调整关联与展示。

我逐渐意识到，“页面能打开”“接口有返回”和“用户能把问题推进下去”是不同的验收点。

| 原型阶段检查什么 | 为什么要检查 |
|---|---|
| 输入能否到达后端 | 避免页面只有预设播放效果 |
| 返回结果是否真实对应本轮输入 | 避免不同问题收到同一段演示话术 |
| 信息不足时是否能继续澄清 | 真实用户往往不会一次提供完整资料 |
| 能否看到来源与规则 | 让回答可以检查，而不只看语言是否流畅 |
| 失败时有没有明确状态 | 不能把接口失败包装成正常理解结果 |

这些检查也让我开始从“还能加什么”，转向“这一条链路有没有走通”。

## 五、把想法收敛成三个核心方向

我结合已有项目与业务经历，逐渐把功能整理成三个方向：

| 方向 | 当时想解决的问题 | 当前怎样理解它 |
|---|---|---|
| 双本体与业务约束 | 多产品、多证据、多规则容易混在一起 | 明确对象、来源、条件与允许动作，持续核查实现边界 |
| Bad Case驱动的改进闭环 | 遇到错误后，希望能够定位并修正 | 保存轨迹、分类排查、人工修复和回归验证 |
| 面向商家的经营归因 | 零散工单难以形成团队可用的信息 | 将集合统计、候选规则、源表行号与核查建议串起来 |

我过去的GTM经历让我会多想一步：消费者的问题得到回应之后，一线客服、运营和业务管理者还能从这些信息中得到什么帮助？

因此，用户端关注表达、消歧、排障和引用；商家端增加邮件草稿、经营看板与归因助手。当前邮件主要是待审核草稿，归因主要是核查线索；真实发送、退款换货和收益验证还需要外部系统与业务流程接入。

## 六、用具体案例检查，再回到相应模块修改

我采用Persona模拟不同诉求和沟通风格，观察客服在多轮对话中的表现，并结合规则断言与LLM Judge寻找问题。

后来更加明确：评测分数只说明某种条件下的结果，还要看输入、检索来源、规则状态和具体回复，才能知道哪里出了问题。

| 案例里发现的问题 | 我们回头检查的环节 |
|---|---|
| 同名产品回答混用 | 产品消歧、型号过滤与案件状态 |
| 已知产品后仍让用户自行找订单号 | 主动订单关联与候选卡片 |
| 通用排障也被订单核验阻塞 | 问题分流与通用支持工作流 |
| 上传成功但没有识别结果 | 多模态返回状态、文字证据和后续检索 |
| 中文表达搭配英文产品名后语言切换错误 | 语言判断、追问与推荐问题 |
| 建议缺少来源或超出业务边界 | 引用校验、规则条件和降级处理 |

修复时，我尝试把失败分清：是知识不适用、检索没有命中、规则条件不完整，还是回复表达出了问题。然后修改对应知识、策略或代码，再看回归样例。

这里的“自进化”是人工参与的持续改进。当前没有自动训练模型、自动调整向量权重，也不应把点赞或点踩直接当成知识正确性的证明。

### 公开写结果时，也要把口径说明白

赛后整理材料时，我们将历史结果和修复复测分开列示：

| 结果 | 正确的阅读方式 |
|---|---|
| 83.8%（62/74） | 历史在线核心任务首轮硬性断言通过率 |
| 98.6%（73/74） | 修复后核心任务单轮复测通过率 |
| P50约2.63秒 | 历史完整回答时延的中位水平，不是平均时延或首字时延 |

这些数字不能直接改写成“8轮问题解决率从83%提升到98%”，也不能仅凭它们证明生产收益。原始记录与限制见[仓库README](../../README.md#评测结果与口径)。

这是我很重要的一次学习：说清做了什么，还要说清是怎样验证、在哪些条件下成立。

## 七、工具没有立刻用顺时，先缩小任务

早期开发时，所用工具与我当时的任务组织方式磨合得不顺，我在这一环停留了较久。后来调整工具和沟通方式，才逐渐推进起来。

这段经历不能概括一个工具的普遍能力，但让我认识到：投入大量时间之前，先用一个小任务验证适配程度；卡住后也可以及时求助或调整。

另一个有用的做法是阶段性整理上下文。我会把已经确认的需求、架构选择、待解决问题和下一步任务总结下来，再继续开发。这样更容易发现：哪些只是讨论过的想法，哪些已经真正写进代码。

回头看，我希望自己更早做三件事：

1. 先说明一个任务的输入、输出和验收方式。
2. 保留已经确认的约束与未解决的问题。
3. 将修改拆小，验证后再推进下一步。

## 八、开发之外，还要给部署和路演留时间

开发占用了大部分精力，留给演示材料和彩排的时间偏少。候场时，我看到其他团队的展示，也会紧张，意识到自己在时间分配上还有很多需要改进。

现场我选择引导评委直接打开可交互页面，让大家上手体验产品，再结合架构解释功能。这帮助我把已经完成的部分展示出来，也提醒我：下次应该更早准备好演示节奏和备用材料。

部署和交付同样需要检查。现在回头看，不能只以“发布成功”作为结束，还要从外部访问页面、检查接口状态、确认模型配置，试一下手机和文档链接。赛后整理仓库时，我们继续补做了这些检查。

答辩只有5分钟讲述和2分钟问答。我最后采用的讲解顺序是：

**真实场景 → 可体验功能 → 三个核心设计 → 技术架构与边界。**

我希望让评委能够顺着问题理解设计，并在追问时拿出具体来源。这个过程和科研中的问题定义、方法解释、证据展示有相通之处。

## 九、功能做得越来越多时，要回到核心需求

我一度想把聊天、邮件、看板、图谱、评测和更多辅助能力都做进去。临近提交时，才开始收起重复内容、删减展示和移除不稳定入口。

事后更愿意把目标写成：**在有限时间里，把最有价值的服务流程做顺，并留出验证和表达的时间。**

| 阶段 | 我下次会更早安排的事 |
|---|---|
| 开发前 | 选择核心场景，列出必须实现、暂缓实现的内容 |
| 开发中 | 用小案例检查输入、状态、检索和输出，不断累积Bad Case |
| 提交前 | 冻结功能、复测、检查部署与链接、彩排讲解 |
| 比赛后 | 整理代码和证据，公开能够确认的内容，继续修复不足 |

## 十、过去的经历，怎样在这次项目里接上了

| 过去的经历 | 这次派上用场的地方 |
|---|---|
| 智能硬件GTM相关实践 | 理解消费者、一线服务与经营管理的不同需求 |
| 数学建模 | 拆解变量、梳理关联、明确约束 |
| 科研训练 | 追问创新点与技术难点，重视验证口径 |
| 咨询与教学表达 | 整理复杂信息，尝试把问题讲清楚 |
| 项目路演 | 在有限时间内组织背景、方法和价值 |
| 出于好奇的阅读与交流 | 为新问题提供一些跨领域的联想 |

这些经历没有让我在一开始就知道所有答案。更多时候，是它们帮我找到一个切入点，再去查资料、试代码、请教和调整。

赛后也有继续交流和实习相关的机会，让我受到鼓励。我还在补技术基础，也希望继续练习把需求、实现和验证连接起来。

## 十一、我想继续保持的几个习惯

- **遇到不懂的概念，先写成具体问题。**带着问题查公开资料，再用小范围实现检查理解。
- **先确认能观察到什么，再讨论效果。**页面能打开、接口能返回、任务能推进，需要分别验证。
- **遇到失败先保留案例。**记录输入和状态，定位问题后再修复，避免只改话术。
- **把来源、版本和口径记下来。**方便自己复查，也方便别人审阅。
- **给交付留时间。**代码、部署、文档和讲解都属于作品的一部分。

这篇复盘记录的是当时的选择和后来补上的理解。欢迎指出问题，也欢迎交流各自的学习方法和开发经历。