得物技术部最近出现了几起“越界”事件……

得物技术部最近出现了几起“越界”事件——

据不完全统计，最近有些研发同学的“越界”行为包括但不限于：放着需求文档不看，先跑去和用户聊几十轮；代码写一半，开始一条一条翻客服工单……

但是同时我们发现，“越界”行为出现的时候，问题就解决得更彻底一点。

这种反常背后的真相到底是什么？来看看他们自己怎么说……

【越界实录 #1】北辰：光看需求，可能不够……

北辰2021年校招入职，作为数据开发工程师，他的日常是产品把需求写好了，他负责拆方案、做实现。

但北辰最近干的事，应该不太符合这个岗位JD写的——他越过了开发的“边界”，把线画到了“好用的标准”上。

事情要从智链AI平台这个项目说起。

起初产品的诉求很简单：做一个通用取数平台，先落地，再优化。但北辰觉得“不够”——他没有从需求文档开始，而是先跑去和用户聊了一轮。

“我们在种子用户群收集了需求，大概拆解了有几十个用户场景”

几十个用户场景拆完，团队发现——用户真正要的可能不是一个问答工具。绝大多数诉求集中在跨表联查和模糊意图上，需要AI数据资产支撑和意图识别。原来预想的方案，从一开始就有点偏了。团队果断把方案从通用问答调整为结构化意图识别加知识库建设。项目上线后，有用户反馈说“终于不用求资源开发定制报表或者到处去拼数据了”——这句话说明方向对了。

但方向对了，不代表路好走。在拿到对的结果之前，难免遭到质疑。

“其他小伙伴听到我们一上来就要做一个通用型Agent的时候，对于实现复杂度和推广层面都有一定的质疑，并善意地建议我们先做定向化的场景。”北辰回忆道，“当时确实会有担心，但是我认为做定向场景和通用Agent之间有很大的差异性，没法做递进优化。”

他选择“先跑小样，用结果说话”。

“其实也是得益于团队的支持，这种允许我们先跑、出问题再调，而不是等方案完美才开始的氛围，让大家敢于提出'可能不对'的方案。失败的项目带来的经验沉淀，有时候比成功的项目更有价值。”

北辰还主动提过一个项目——AI-TAG。让AI帮业务阅读解析用户反馈，基于DIY规则灵活打标——以前业务团队每天要花大量时间人工翻看用户反馈，有了这个工具，几秒钟就能自动标记。上线后，业务团队主动找上门来对接新场景。

能这样一个个“找问题”而不是“等任务”，说白了是因为这里的问题都来自真实业务——用户反馈、运营痛点、数据需求，每件事都是真有人等着用的。团队也敢放权，校招生也能去碰有难度的东西。有业务压着，有空间试错，自然就敢往前多走一步。

【越界实录 #2】

东方朔：一个后端研发工程师，却潜入了商家运营群

东方朔21年校招入职，写Java的。

但他最近写着写着，不知不觉潜入了商家运营群……

事情要从商家AI助手项目说起。

刚开始，他只是负责实现对话接口、知识库检索。但他越来越觉得不对劲。

“我发现，我们做的东西好像不是商家真正想要的。”

东方朔没有等需求文档更新，而是自己去找了产品和运营同学。

“其实就是去问他们：商家到底在烦什么？他们每天问得最多的问题是什么？”

几轮聊下来，他拼出了一个之前在需求文档里看不到的画面：不少商家在入驻和日常运营中，会遇到保证金缴纳、商品审核、入驻流程等高频问题，且这些问题反复出现、需要重复咨询。与此同时，客服每天都要处理大量类似的重复问询。

“为了摸清楚，大家各自分工，一条一条翻商家客服工单。很快我们就发现，我们要做的根本不是一个回答问题的机器人，而是一个能真正帮商家解决问题的'智能伙伴'。”

东方朔提出用AI助手自动解答这些常见问题。但问题是——他对AI大模型并不熟悉。

那段时间，他把技术部组织的AI培训吃了个透，从LLM基本原理到Prompt工程，一周内啃了大量论文和技术文档。有个概念让他印象特别深——Harness。培训中用“都江堰”来类比：AI大模型的能力就像岷江之水，水量浩大，但如果不加引导就会泛滥；Harness的作用就像都江堰，通过规则、分流与反馈闭环，将算力引导到正确的轨道上。

“这个类比让我恍然大悟。”东方朔意识到，关键不是让AI直接输出答案，而是先搭一套规则框架，把AI的推理约束在正确的轨道上。他和团队花了几周时间，一条一条调优知识库——把客服工单里最高频的上百个问题逐条清洗、分类、建立应答逻辑。

项目上线后，其中一个功能“商家成长路径”——根据商家的入驻阶段和业务规模，智能推荐他们需要学习的内容——自动解答了60%的常见问题，客服压力减少30%，新商家上手时间缩短50%。

“看到结果符合预期的时候挺开心的，运营那边也给了很多正反馈。”

但回头看，这条路走得其实没那么顺。当东方朔提出加入'智能推荐'功能时，团队内部也讨论过如何保证推荐内容的准确性和可靠性。东方朔的想法也很简单：'这块必须做扎实，所以我们提前设计了验证机制。

团队用一周时间搭了原型，小范围试跑。当然也踩了几个坑——冷启动推不准、信息茧房越推越窄。不过好在部门有灰度发布体系，出问题能快速回滚并解决。

这种“先跑小样，用结果说话”的方式，后来在很多项目中都被反复验证。同样的“越界”，一遍又一遍地出现，每越一次，边界就扩大一点，问题就解决得更彻底一点。

看来，得物技术部最近出现的“越界”事件——并非真的“越界”，只是适时地“向前一步”。

把“边界”画到问题真正发生的地方：在客服的聊天记录里，在商家的抱怨声中，在用户对着后台一脸茫然的那一刻——因为在为用户真正解决问题这件事上，本身就不被岗位限制。