乐于分享
好东西不私藏

开发日志 | 国际站询盘AI总结工具——针对外贸业务员交接客户、主管复盘场景

开发日志 | 国际站询盘AI总结工具——针对外贸业务员交接客户、主管复盘场景

引文
介绍一下写作动机——
我是个Steam十几年的老玩家,下班回到家偶尔也会看一眼Steam库
近几年更新的Steam库顶部UI有一个新情报速递板块,
这里像banner一样可以快速看到库存游戏的更新或者新闻
*Steam库UI
而最近我正在开发一个桌面客户端的国际站辅助工具
它用于总结业务员和买家的沟通,
其中UI产品设计思路以及技术路线选择我自己觉得有那么点意思,
便想着要不要试着写一篇公众号文章记录一下?
但是一向有纠结症的我特别讨厌写公众号标题
(不是说不会当标题党,而是考虑万一以后产品或者人在圈子里火了
大家岁月史诗倒查文章,岂不是一点也不经扒?)
于是我干脆参照P社新闻标题格式,给接下来可能会有一系列的公众号文章用上<开发日志>的标题。
就当给未来要向外贸圈推广的工具预热
哪怕未来工具无人问津,
这篇文章也是个互联网上的痕迹,属于是针对自己的GEO
*参照Paradox HOI4的新闻动态,虽然现在叫做<开发者角>
喜欢二战历史的朋友应该基本都玩过某钢4
回归正题——

文章标题,

国际站询盘AI总结工具

1、这个工具解决什么需求?
第三者快速、低成本理解买卖双方复杂长对话的需求
2、用户画像?
外贸业务主管、老板、刚接手老客户的销售人员
3、典型使用场景?
案例1:
新业务员入职,老业务员离职 
交接国际站线上客户场景
*(nano banana pro 生成漫画1)
案例2:
公司老板or外贸业务主管 带着一线销售人员 进行每周/每日的复盘会,
盘查客户跟进情况,了解业务卡点
*(nano banana pro 生成漫画2)
如果你正好可以想象得到这两个场景,且有需求
那么恭喜你,
你是我的目标用户
基于这份缘分,
接下来向你介绍这款工具的设计理念。
这款工具的设计理念很简单,
它像我们人工进行询盘总结的一样:
【点击访问我们在国际站后台【商机列表】
再【点击】某一个商机,【跳转】到【即时对话页面】
然后【向上滑动】,等待浏览器【加载消息历史
只不过我们是用人眼【看】,并在脑子里通过【想】来处理信息,
从而理解这段对话双方的意图——
例如:买家需要什么?为什么愿意/不愿意付款?
同时:销售人员如何与其沟通,从而促成买家下单?】
而工具则是通过【读】数据,并传参给LLM(大语言模型)
通过【推理】来理解对话的含义
基于AI最大的一个特长——长文本总结(得益于Transformer等框架)
面对长对话,我们只需要直接查看AI给的总结报告即可,
不必深入查看每一个细节
同时,也不再需要把下面的所有商机选项卡一个个点开,那样费时也费力
一切都只需要点击一下工具的这个按钮
就可以看到想要的总结报告
(目前还需要打磨,纯文字没有分点,很折磨人)
*输出结果UI v0.10 没脱敏处理
而针对关键的询盘/对话 ,根据需求再去详细查看,
这样就算是有的放矢,
真正节省企业最宝贵的外贸老板/业务主管的【精力】,
从而提升工作效率,降低管理成本
可能你觉得我叽里咕噜说了半天,
实际上我这个功能,
国际站官方的生意助手/AI版小满CRM不是早就实现了嘛?!
我想先在这里先回答你:
首先,你说得对
但是,在国际站入驻商家/企业这一方,我觉得吧,
爹有娘有,不如自己有
在AI军备竞赛的时代,
我们应该最起码有选择AI模型的权力吧?
(当然不可否认,官方默认的底层模型开源且实力先进
我自己也用Qwen蒸馏训练模型,
但这与我的主张并不冲突)
更何况,
上述的两个产品,如果你是深度用户应该不难发现:
AI总结功能的上下文长度限制在一定范围内,
你没法穷尽整个沟通的所有消息。
也就是说它生成的这份报告是不完全的,一定会漏掉很多信息。
我打个不太恰当的比方:
我和结婚多年的爱人,
虽然能记得最近几年的点点滴滴,
但是唯独忘记了和ta第一次见面的场景。
作为一个强迫症和纯爱战士,我完全无法接受。
因此我想要做出一个自己的工具
来解决长对话总结以及其他<AI自动打工方便我摸鱼>的需求
……
其他关于竞争的好处,垄断的坏处就不讲了,屁话太多
*如果你是从业多年程序员/产品经理
接下来建议跳过这一部分。
如果你对爬虫、RPA自动化完全不了解,也请跳过
如果你的主业不是开发或者产品,
对产品/技术方面或者AI很感兴趣,可以继续查看——
要实现自动化获取询盘沟通参数,
丢给LLM也就是AI并生成总结,
我们首先需要解决定位某个询盘的问题,
其次才是具体单一询盘的历史查询
已知2026年,AI浏览器概念已经不再新鲜,Comnet、ClaudeBrowser都具备针对用户浏览器消息的阅读理解能力,
那么他们是不是可以和人类一样点击按钮、操作鼠标滚轮呢?
理论上当然可以,(实际上也是如此,就像豆包手机那样)
但是一个员工双手离开鼠标键盘,看着屏幕内AI进行自动操作,
这简直就是一件违反“公序良俗”的事情,
在其他不明真相的同事眼里,你跟上班摸鱼有什么区别?
更别说老板,哪怕他知道你是在用AI自动化操作。
放开双手,意味着你的工作一定是不饱和的。
所以作为产品经理的角度,
我们应该要设计一个看不见的工具完全在后台进行操作
用户则正常在前台操作,互不影响
这样才能体现用户 下达指令的重要性,而不是做一个替代用户打工的工具。
而作为项目经理,有2条技术路线可以选择——
A.RPA(完全合规 就是稍微慢一点)
依托浏览器的正当性获取数据,然后使用PRA工具代替人工鼠标键盘进行点击滚动操作。
但是速度偏慢,效率低,整个每日复盘要花费的时间可能接近1小时甚至超出
与用户的工作空间产生冲突,这不符合产品经理的要求
B.轻量化 构建请求 获取数据(偏技术)
构建一个“小浏览器”,和服务器建立连接,从而获取想要的数据
这虽然符合产品经理的要求,
但是它可能会产生风险。
那么,这道选择题该怎么做?
纠结症的我本来就此会停下脚步,
对两个选择的后果都仔细思考再选择一个路线贯彻。
但是,作为一个练习时长1年缺乏相关经验外行程序员/vibe coder,
万万没想到,AI给我提出了一个意想不到的答案——
没有必要一定从A/B里面选择
可以采取折中方案
既 <人工扫码登录>,RPA的方式进入商机列表页面
拿到官方服务器所需要的所有会话密钥,
再丢到我们的<工具>内,进而高效获取所需的信息
这样就解决了纯RPA方案的低效、用户体验差,
以及纯轻量化构建请求方案的风险问题。
这个折中方案 相当于自行构建一个专属国际站从业者的“AI浏览器”(也就是垂直领域的agent)替代平时大家操作的chrome浏览器
来解决之前所说的AB选择难题。
说完这个工具的大致技术原理,
接下来聊点大家都能听明白的——
我作为这个工具开发者对于产品开发速度还是比较震惊的,
因为没想到这个MVP成功开发的这么快
原本以为获取数据和定位这两个环节要花上个至少一周,
而实际上依托chromeMCP和海外领先的闭源AI编程模型agent,工具的核心功能不到2天就实现了
我真的有点震惊。
而核心功能实现之后,接下来的时间和开发精力会耗在客户端小功能、UIUX的设计和测试上。
功能比如——
IP检测(基础功能,已实现);
LLM连接测试(基础功能,已实现);
自定义提示词输入(设计中,要限制用户输入的token上限);
AI总结内容的导出(基础功能,v0.10已实现JSON/MD格式导出);
……………………
实际使用场景待完善
……………………
多账号切换场景待完善
……………………
………………………………………………………………………………………………………………………………
2026 0329 23:43 记:  
这篇文章好像当时写的时候烂尾了,
今天也懒得补充
正在抓紧开发更为关键的功能,
下次再填坑吧。