从个人痛点出发，到业务方主动要求试用，这位产品经理独立打造的薪酬答疑AI Agent经历了一段跌宕起伏的旅程。本文复盘了从场景圈定、技术选型到无人问津的困境，最终通过降低使用门槛、提升可信度与给出行动建议，让工具真正被用户接纳。成败关键不在技术，而在“人愿不愿意用”。

最近我有了个小小的里程碑：业务方主动找我说，要试用我做的薪酬答疑 AI agent。

从5月开始独自筹备、设计、开发，到6月无人问津，最后7月终于终于业务方主动跟我说要试用。

这个过程我踩了许多坑，但也有了很多心得，于是在这个暴雨天，一一给大家分享。

一、最开始，是始于我的自身痛点

最一开始，薪酬答疑其实并非是我发现的业务机会点，而是更直接的——我自己的痛点。

内行的朋友们都知道，薪酬系统上线并不是终点，数并不是算出来就行，解决了各种薪酬咨询、答疑才是说是“完成线”。

在这个咨询答疑的过程中，虽然我已经提前安排了培训，也有业务同事专门负责对一线员工答疑，但是免不了还有一些业务人员页不知道问题所在的工单，会流转到我这里。

而在排查问题的过程中，我则需要几个方案库、规则库来回切换，找到问题的根因并帮助业务人员解决。

这个过程——少则10-20分钟，多则1-2个小时。问题一多起来，可能一个下午都花在咨询答疑上，这真的非常耗散我的精力。

我想——能不能让AI来替我寻找问题根因，能不能让AI来干这个活？

于是，这个AI的想法就从我脑海里立下来了——我要做一个薪酬答疑 AI agent。

二、从业务场景范围到技术方案选型，我不停踩坑

从场景范围的圈定，到技术方案的选型，我几乎是一路踩着坑走过来的。

一开始我很贪心，想做一个大而全的 agent，能解答薪酬相关的所有咨询疑问。可真正动手才发现，现有的薪酬核算链路实在太长了：想把这个 agent 搭起来，根本不可能靠我一个人完成——需要研发帮忙梳理代码规则，需要业务帮忙梳理咨询答疑的类别，还得圈定清楚：不同类型的咨询，各自该走什么样的 workflow 去排查问题。

但这些都还不算最麻烦的。真正把我卡住的是：怎么保证这个 agent 能安全、脱敏地读到薪酬相关的数据和代码？这意味着我得去拉通公司的安全部门和数据平台。这个工作量太大了，而且在他们眼里，我这个需求到底有多少价值，还不一定。光是拉通、开会、对齐的时间，我就耗不起——我想要的，是一个能快速解决问题的 agent。

所以我很快放弃了这条路，转头去梳理：在薪酬答疑这件事里，到底哪一部分最耗时、占比最重。

最后，我锚定了一个现阶段最容易落地的场景——薪酬差异对比。

之所以是它，是因为在整个薪酬答疑里，差异对比恰恰是最耗时、最标准化、也最容易先落地的一块。

背景大概是这样：有些线下试跑的薪酬方案上线后，业务需要把系统算出的结果和线下核算的结果做对比。这个过程非常麻烦、非常耗时——业务通常要花上 1-2 周来核查，即便是像我这样比较了解系统逻辑的人，对一遍也得花 1-2 天。

只说到这里，场景其实还是有点大。不同业务线的薪酬方案，复杂度差别很大，复杂度高的业务线落地起来依然很吃力。于是我又把范围收窄了一圈，锚定在海外地区的薪酬方案对比上。

海外地区还处在发展阶段，薪酬方案相比国内，结构要清晰得多；再加上整体系统建设起步较晚，数据源和代码逻辑都比较干净。这些都给了我一个很好的起点。

花了一段时间把场景定下来后，我开始着手设计整体的产品方案。

我没打算把这件事做得太复杂——毕竟我做 AI agent 的经验不多，小步快跑、快速迭代才是最适合我的方式。所以我最初的构想很简单：

业务方把线下表和系统表放一起 – AI分析 – AI给出结果

本以为这么简单就搞定了，结果发现，是我把事情想得太简单了。

大家都知道，AI 有几个老毛病：不擅长算数字、输出是概率性的、还爱一本正经地产生幻觉。

而这几个毛病，一旦碰上数据、尤其是数据对比这种场景，就会被无限放大——用 AI 来做，几乎必然会遇上它瞎胡说、乱编造的情况。

一开始我想着先跑起来，再用评测集的方式去兜底。但很快发现，这条路对我来说根本走不通——我没有精力、也没有时间去做一套评测集。（毕竟这是我独立在做的，本职工作一点没少，那段时间还多兼了一条业务线的账单结算，这个小项目也没争取到任何内部资源。你大概能想象，我能投进去的时间和精力都非常有限。这个话题我就不展开了。）

可 AI 只要出一次错，业务方就很难再信任它了。所以我要的不是 95% 的准确，而是 100%——是的，薪酬差异对比这件事，只要不是 100% 准确，对用户来说就等于 0。

怎么办？在和 AI 反复探讨之后，我又一次改了产品方案。说白了就是一句话：对比交给代码来做，AI 只负责把结果翻译成人话。

但故事到这儿远没结束，后面我还是在不停地摸索、掉坑、再爬出来：AI 怎么获取业务上下文？怎么判断差异产生的原因？判断出来之后，又该怎么向业务解释“这个差异其实是正常的”？以及最关键的——怎么让业务相信 AI 输出的结果就是对的？

限于篇幅，这里不展开详述。之后有机会再一一跟大家分享，这里就直接放一张最后我定下的产品方案图：

三、上线了，但业务方没一人想用

好不容易终于终于，我把这个产品做上线了，我兴高采烈的拿给业务，期望业务能试用一下。

业务看到后，很惊喜的和我说了声谢谢，然后1天、2天、1周、2周，杳无音讯。

这时候我知道了，他根本没用。

为什么会这样？我不得其解。而刚好这个过程中我也在筹备其他事项，没有深究。

直到前段时间，我又有了相关场景的工作，我拿一份真实数据实测，用工具和 AI 各跑了一遍，才想明白这工具为什么没人愿意用：

1. 用之前要先耗一堆时间调表。 每个人的线下手工表都不一样，工具靠字段去识别对比，就得先逼着大家把表格改成模板。在核对这个场景下，光前置准备就把人拦在门外。
2. 结论没有“可信度”。 工具扒拉一下给出一堆差异，数字都很大，然后轻飘飘写几句原因分析。使用方看完根本不敢相信，我自己都得再核几眼。
3. 没有下一步建议。 比如算出一大批看起来异常、其实正常的数据，即便知道它是正常的，但结果是每位员工有3000元的差异？这是无法接受的，对于业务方看完还是不知道该怎么办。

那一刻我意识到：一个工具能不能“算出差异”，根本不是重点。重点是——工具是否足够简单、丝滑上手、用的人信不信得过、看完知不知道下一步干嘛。

四、最后，业务方终于和我说要试用我的agent

想通第一版为什么没人用之后，我没有急着加功能，而是对着那三个问题，一个一个去解。

1、把「调表」这道坎，直接从用户面前拿走。 第一版最大的劝退点，就是用之前要先花时间调表、套模板。这一次我换了思路——给 agent 填充了大量的业务上下文和专业术语，把读表、解析字段、字段映射这些前置动作全部交给 agent 去做。用户不用再改表，把线下表原样丢进去就行。

2、用「摊开过程」换回可信度。 agent 既不能简单粗暴地只甩一个结果，也不能长篇大论地堆一堆数字和对比分析。真正能让业务信任的做法，是把「过程」摊开给他们看——先圈定一个大范围，再一条条地对比，最后才下结论。人看得见它是怎么一步步推导出来的，自然就敢信。

3、「下一步建议」，我决定先跑通SOP，再交给agent指示行动。 一开始我总想着让 agent 连「接下来该怎么办」也一并给出来，但很快发现这一步最容易翻车。于是我暂时退了一步——先用「人工 + agent」的方式，由我来补上下一步的判断；直到我们互相摸索出一套彼此都认可的 SOP 流程，再把这一步交给 agent。看似退了一步，实际上却让业务在心理防线上，慢慢接受了 agent 的介入。

同时，我也没有一上来就让业务自己上手，而是先由我初步核验 agent 输出的结果，确认没问题了，再移交给他们。

就这样，经过 1-2 次会议，业务亲眼看到 agent 输出的结果确实靠谱之后，慢慢对它建立起了信任，还主动告诉我：他们内部也想试用这个 agent。为了让他们更快上手，我这周还把 agent 搬到了一个大家更容易操作的平台上，进一步降低了使用门槛。

当然，我也确实赶上了两点运气：公司恰好在这段时间解决了数据安全合规，agent 可以直接读数据；业务方也刚上线新方案、正缺人手验证。这些外部条件帮我省去了重复造轮子的功夫，让我能把精力全押在「怎么让业务愿意用」这件事上。

五、写在最后：工具的成败，不在技术，在“人愿不愿意用”

整个过程和项目，虽然只是我个人在AI领域的探索和试水，但最让我高兴的是：AI 跑出来的结果获得了使用方的认可，他们主动表示愿意试试这个工具。对一个内部工具来说，使用者从“不相信”到“愿意试一试”，这一步比把工具做出来难多了。

如果要把这一路最核心的心得提炼出来，我觉得是这 3 条：

1、场景选对，从自己的痛点开始最简单，但一定要有拓展性。 从自身痛点出发，是最容易找到、也最容易验证的起点。但更关键的是：我的痛点，往往不只是我一个人的痛点。在「海外薪酬差异对比」这个场景里，业务方其实面临着和我一模一样的困扰——所以当我解决了自己的问题，也就顺手解决了他们的问题。选对一个「自己痛、别人也痛」的场景，工具才有真正被需要的土壤。

2、认清 AI 的能力边界，不同场景用不同的切入方式。 AI 不是万能钥匙，关键在于看场景下菜。在「必须 100% 准确」的差异对比里，我把精确计算交给代码，只让 AI 做它擅长的——把结果翻译成人话；而在需要理解业务、解释差异原因的环节，才把上下文和判断交给 AI。同样是 AI，切入方式选对了，价值才立得住。

3、建立产品和用户之间的信任，比功能本身更重要。 技术从来不是万能的。产品经理最忌讳的，就是把产品粗暴地丢给用户，然后指望他们自己用起来。真正该做的，是带入用户视角，多和他们交流、观察反馈，一点点抹平使用障碍——这份信任，既要体现在产品设计里，也要体现在后续的运营中。第一版没人用，不是算得不准，而是我没把用户放进来；直到我陪着业务一步步看结果、一起磨流程，他们才终于愿意主动说一句「我想试试你的 agent」。

技术决定了工具的上限，但决定它到底有没有用的，是人愿不愿意用。一个再聪明的 agent，如果使用方不敢信、不想用，它的价值就是 0；反过来，哪怕它做的只是一件小事，只要有人真的用了起来、并且愿意依赖它，它就活了。

所以做到最后，我越来越相信：一个好工具的标准，不是“我做了什么”，而是“别人愿意用它做什么”。技术是我的起点，但让人愿意用，才是这件事真正的终点。

这条路我还在走，坑估计也还会接着踩。但只要还有人愿意对我说一句“我想试试你的 agent”，我就觉得，值了。