有了 AI Agent,人人都有机会成为大英雄

周一上午，客服小周收到一条工单：“我明明点了保存，怎么刷新后又变回去了？”

回复完客户，小周把这句话记了下来。当天又有人说“保存了也没用”；第三个人什么也没写，只发来一张设置页面的截图。

三条工单都落在客服系统的“设置问题”里，散在几十条反馈中。小周怀疑它们指向同一个故障。新版刚上线，等到下周汇总时再发现，可能已经有更多客户遇到了。

她想做一个小工具：每天把新工单按产品版本、操作步骤和客户描述放在一起看；相似的先归成一组，重复提交的标出来，每条线索都能点回原文。机器先找，客服再核。这样再有人用别的说法报同一个问题，也不容易漏掉。

小周打开公司内部的 AI Agent 搭建工具，把要求写了进去。她不懂怎么写页面，也不会接接口，但知道客服每天要看什么。她拿几条脱敏工单做样例，告诉 Agent：要能选时间范围和版本，显示工单号与客户原话；拿不准的放进“待确认”，不要替人改原始工单。

当天下午，Agent 做出一个能打开的页面。左边是归好组的反馈，右边能看客户原话和版本号，还能一键标记“确认”“分错了”。样子朴素，至少小周不用再开十几个标签页来回找。

她拿样例一试，就抓到一个错：Agent 把“保存后恢复旧值”和“页面刷新慢”归到了一组。小周把两张工单并排放给它看，解释前者是数据没留下，后者只是等得久。Agent 改了归类规则，又加上“待人工确认”一栏。她还让它标出同一客户重复提交的记录，统计时只算一次，原文照样保留。

第二天，IT 同事看了原型，帮她把工单系统的只读接口接进公司批准的环境，确认页面只对客服和相关产品同事开放。小周这才用真实工单跑了一遍，逐条点回原始记录核对。系统标出一组与新版设置有关的反馈：有的写“保存没用”，有的只上传截图，还有两张是同一位客户重复提交。

周三的产品例会上，小周打开自己做的“反馈雷达”，点开那组工单：“我怀疑不是客户不会用，是新版设置没保存住。”产品和测试同事照着里面的版本、操作步骤和客户原话检查，很快复现了问题。修复排进了当周的版本，客服也联系了受影响的客户。

这次排查能走得快，“反馈雷达”帮了大忙。它把散在各处的反馈摆到同一张桌面上，还留着通往原始记录的路。小周知道哪些话其实在说同一件事，系统帮她把这些判断变成了团队也能用的流程。

问题修好后，小周没有关掉“反馈雷达”。她让 Agent 加上每周汇总：先按版本和问题分组，附上原文，再由客服同事确认后发给产品。那次分错类的工单也留作样例。新同事接手时能看明白规则，发现不对也知道在哪儿改。

从几条工单出发，小周用 AI Agent 做了个不大的系统，帮团队找到并解决了一个产品问题。后来，它又成了每周有人打开、有人复核的工作台。

小系统，也能解决大问题

许多值得解决的问题，只有每天做这份工作的人看得见。销售知道客户跟进总漏哪一步，财务清楚报销单常缺哪份材料，仓库主管知道哪些缺货提醒来得太晚。他们也最清楚改到什么程度才算有用。

以前，说“做个系统”，通常意味着写需求、等排期、开评审。每一步都有理由，可一个范围很小的改进，也可能在等待中慢慢没了下文。

现在，员工可以借助 Agent 先动手。他们拿出真实样例，说明规则，让 AI 帮忙做页面、接流程、改代码，自己边用边纠错。这种 Vibe Coding 做出的第一版可能粗糙，却把一个模糊的主意变成了能打开、能操作、能指出哪里不对的东西。

小周的“反馈雷达”有工单入口、归类规则、原文和人工审核，已经是一套系统。范围很窄，却能让团队每周用。做系统可以从一个经常出错的环节开始，财务的报销核验、销售的跟进提醒也一样。

比如报销。财务同事最清楚哪些费用需要合同，哪些票据总缺审批记录。把这些规则做成提交前的检查页，员工自己就能先补齐材料。财务少退几次单，申请人也少等几轮消息。工具看着小，省下的却是许多人的时间。

做这样的小系统，得先弄清数据从哪里来、规则谁来定、结果给谁看。天天在流程里的人知道哪里容易出错，也能拿实际单据和对话检查第一版。Agent 帮他们把这套经验做成工具。

做系统不再只是 IT 团队的事。发现问题的人，也能亲手做出第一版。

IT 团队要把舞台搭好

小周能把“反馈雷达”做出来，靠的不只是会用 Agent。公司给了她内部工具、可读的工单数据和清楚的权限边界。她能试，也知道试到哪一步该找谁。

未来 IT 团队要把这样的舞台搭好，让每个有想法的人都有机会成为解决问题的英雄。工单有只读接口，试验能用脱敏样例，登录、表单、通知有现成组件。业务同事在公司批准的环境里动手，遇到权限或部署问题也找得到人。原型做出来，还有一条清楚的路能进入正式工作。

IT 团队别轻视非技术同事的 Vibe Coding。第一版界面可能简陋，代码也未必漂亮，作者却往往知道客户为什么着急、财务为什么退单、流程卡在了哪一步。IT 同事可以先和做工具的人一起跑一遍真实场景，再帮忙检查权限、测试结果，安排上线后的维护。

原型要交给整个团队长期使用，IT 还要帮忙部署和保障运行，明确谁接故障、谁改规则、数据留在哪里。员工能自己起步，也知道出了问题找谁。

一句“你又不懂开发，先提需求吧”，最容易把想做事的人挡回去。把小工具一概塞进漫长的排期，IT 就成了绊脚石；有人甚至会转去用未经批准的个人工具，问题反而更难管。

能自己动手，也要对结果负责

Agent 会犯错。小周第一次就发现它把两类问题混在一起，靠逐条复核才改了过来。系统越容易做出来，越需要有人知道它用了哪些数据、按什么规则判断、出了错谁来改。

小周负责工单怎么分、什么问题该升级，客服同事负责核对每周的报告。IT 负责数据连接、访问权限和运行保障。需要向客户作出承诺、修改正式记录或执行付款时，仍要由有权限的人确认。分工说清楚，小系统才能在第一次演示之后继续用下去。

规则也会变。新版换了名称，客户换了说法，Agent 又可能把两类问题混在一起。小周需要继续看误分的工单，客服团队要知道怎样暂停周报、怎样改回上一版规则。第一次做出来值得高兴，半年后还能放心用，才算真正做成。

管理者也得给员工时间和认可。小周整理样例、核对结果、教同事使用，都是实实在在的工作。让员工下班后再多干一份，热情很快会耗尽。找到问题、做出办法、维护下去，这些都应该算成果。

小周听出了几位客户在说同一件事，查到了证据，还把这次经历留成了一套每周都能用的办法。

这样的员工，企业里并不少。IT 把舞台搭稳，他们就能一个个走上来，用小小的系统，解决那些拖了很久的大问题。