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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

这些数字不能直接改写成“8轮问题解决率从83%提升到98%”，也不能仅凭它们证明生产收益。原始记录与限制见仓库README。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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