夜雨聆风
今天下午，一位做HR的朋友来找我。他在一家大型互联网企业负责海外业务，遇到的问题很具体：内部系统主要由国内团队建设，部分指标仍然是中文，有些英文翻译也不完整。海外同事打开页面，看到的不只是语言障碍，还有一堆不知道口径的指标。
按传统路径，他会给产品经理提需求，等团队翻译指标、补充说明，再配合内部平台完成多语言切换。需求进入排期后，两周一个迭代，从提出到真正看到效果，常常要等上一个月。
他的第一反应却是：能不能先做一个浏览器插件？同事安装后，打开相应页面，中文指标自动变成英文；鼠标移上去，还能看到指标口径。这个需求并不宏大，却能立刻减少真实工作的摩擦。
一、一个小问题，为什么总要等一个月
传统产品机制擅长建设公共能力，却不一定擅长承接零散、局部、急迫的小问题。
产品团队要考虑通用性、系统兼容、上线风险，还要照顾不同国家的语言版本。这样的治理没有错。问题在于，一个只影响少数海外同事的阅读障碍，很容易排在更大需求后面。业务每天都在被卡住，系统只能按版本节奏往前走。
过去，职能部门能做的通常是催排期、找临时翻译，或者整理一份指标说明文档。AI让中间多出了一条路：先不改生产系统，围绕眼前页面做一个贴身的小工具，验证同事是否真的因此看懂、用得顺，再决定要不要进入正式产品路线。
图1：大系统按迭代建设，小问题也可以先走一条低风险验证路径。
二、他没有等排期，先把插件做了出来
当业务问题足够具体，第一版产品不需要完整，只需要让当事人看到变化。
我鼓励他自己做。他并不是产品经理，也不是开发工程师，但我知道他有能力把这件事跑起来。更重要的是，这个问题有清晰的输入和输出：输入是页面上的中文指标，输出是可读的英文名称与口径解释；是否有效，让海外同事打开页面就能判断。
浏览器插件之所以适合这个场景，是因为它可以在页面加载后读取和调整页面内容。Chrome官方文档也明确说明，内容脚本能够读取网页细节并修改页面。换句话说，它不一定要重做后台系统，就能先在使用者这一侧补上一层翻译和解释。
他当天把第一版做了出来。页面上的指标可以被替换，鼠标悬停时也能看到说明。技术上没有复杂到需要一个大项目，真正困难的地方是：你能不能把“国际化做得不好”这句抱怨，缩成一个可以马上动手的具体动作。
三、没有系统权限，就先造一个可验证现场
权限不足不等于无法验证，关键是把生产风险与方案验证分开。
插件做完后，他遇到了下一个问题：自己没有目标系统权限，真正使用系统的是对方。如果一直等权限，原型就会停在“我这里应该能跑”。我让他请对方发一张脱敏截图，再根据截图生成一个模拟页面，发布到测试环境。
这个模拟页面不连接真实系统，也不处理真实员工数据，只还原与测试有关的界面结构。安装插件后打开类似页面，指标翻译和悬停解释照样能够运行。越南同事一看，就知道这件事是不是自己想要的。现场反馈是：主要障碍已经解决，剩下的是少量指标与口径继续打磨。
图2：先用脱敏截图和模拟页面验证价值，再决定是否进入正式系统。
这个动作的价值，不在于模拟页面有多像，而在于它把一次讨论变成了可体验的结果。对方不必读需求文档，也不必想象插件上线后的样子。打开页面、移动鼠标、看懂指标，几分钟就能给出下一轮反馈。
四、真正的爽感，来自当天闭环
AI带来的爽感，不是“我也会写代码了”，而是一个真实问题终于不再悬着。
他告诉我，做完以后很有爽感。原因很简单：下午还只是同事的一句抱怨，几个小时后已经变成一个可以试用的东西。问题被看见、方案被做出、结果被验证，这个闭环很短，也很真。
以后他会花更多时间，在HR工作里寻找这样的机会。可能是一个字段解释工具，也可能是政策问答、候选人信息整理或跨语言沟通辅助。它们未必一开始就值得立项，但值得先用一个小工具把价值跑出来。
图3：问题越具体，反馈越直接，越适合先做成小工具。
五、HR的新位置，是离业务更近一点
职能部门最稀缺的AI能力，不是掌握多少技术名词，而是听得见业务在哪个动作上难受。
这位朋友真正做对的第一步，不是选择了插件，而是认真听了海外同事的声音。他没有把问题概括成“系统国际化能力不足”，也没有急着推动一个多语言平台。他先看见了一个人每天打开页面时，在哪些指标上停顿，为什么停顿，什么变化会让对方立刻轻松一点。
有了这个颗粒度，AI才有用武之地。你可以让它协助还原页面、生成插件、补充翻译，也可以让它根据反馈快速修改。人仍然负责判断问题值不值得解决，确认口径是否正确，决定什么能进入生产环境。AI接走的是中间那段过去需要开发资源才能完成的实现工作。
图4：岗位不会因为做了一个插件就变成产品经理，但会多出解决业务问题的新能力。
六、Agent加Skill，先接走一段小活
很多需求不需要大而全的AI方案，先让AI接走一段边界清楚的活，价值就已经开始发生。
Agent可以理解目标、判断下一步并调用工具；Skill则把某一类做法、规则和验收方式封装起来。放到这个案例里，Skill可以沉淀“识别页面指标—匹配翻译—展示口径—记录未命中项”的做法，Agent负责根据页面状态选择和执行。第一版甚至不必把所有步骤都做成自治系统，只要最小工具能稳定解决问题，就足以产生价值。
OpenAI的Agent实践指南建议从渐进式路径开始，先控制复杂度；Anthropic的工程经验同样强调从简单、可组合的方式起步，只在确有必要时增加自主性。这与业务现场的判断一致：能用确定规则解决的，不必为了追求“智能”而增加复杂度。
当然，小工具不等于生产系统。正式部署前仍要经过信息安全审查，明确插件能读取哪些页面、是否接触个人数据、翻译词库由谁维护、异常时怎样停用。低风险验证可以快，进入生产必须稳。这条边界不能因为AI写代码更快而被跳过。
七、先笨拙地解决问题，产品能力才会长出来
一个人真正懂AI的标志，是能让业务在很短时间里看到一个可验证结果。
很多流程与职能部门的同学会下意识地怕技术，觉得插件、Agent、Skill都是开发团队的事。其实你不必先成为工程师。你要先练的是另一套基本功：走到真实工作旁边，听懂对方的困难，把问题缩到足够小，再和AI一起做出第一版。结果有人使用，反馈能够回来，你就完成了一次真正的产品循环。
这种能力不会从一场培训里突然长成。它来自一次次小闭环：今天帮海外同事看懂指标，下一次把常见口径沉淀成词库，再下一次让未命中的内容自动进入复核清单。小工具逐渐稳定，使用者越来越多，才有理由申请正式权限、进入产品排期，或者把它升级成组织级能力。
企业里真正需要的，也不只是少数“懂AI的人”。更好的状态是，每个职能岗位都有人能识别业务摩擦，知道AI能做什么，也知道哪些边界不能越过。他们不等一个宏大方案从天而降，而是先贴身服务，把问题解决到对方愿意继续使用。
我戏称这位朋友是“懂AI的HR”。这个称呼的重点不在AI，而在HR。他没有离开自己的专业，反而因为AI更靠近了真实业务。积小成大，产品机会就会从这些被认真解决的问题里长出来。
如果你也在流程、HR或其他职能岗位上，正在寻找可以当天闭环的小机会，欢迎加入我的AI流程与组织变革交流群。我们一起拿真实问题练手，把Agent和Skill放进具体工作里，不辜负这个时代。
