很多团队都有一个内部提效平台。

上面集中了开发、测试、产品、运营能用到的各种工具：查环境状态、触发自动化用例、统计业务测试数据、生成报告……每个工具都是真实痛点催生的，功能不差，就放在同一个平台里，用的时候打开浏览器找到对应入口就行。

这套模式运转了好多年，没什么大问题。

直到 AI 开始普及。

开发同学越来越习惯在对话框里工作——查个文档、分析个报错、生成一段代码，全在 AI 里解决，根本不需要切换窗口。这个节奏一旦养成，再让他们「打开浏览器、找到入口、登录、填表单、等结果」，就会觉得：这也太慢了。

「直接问 AI 不就行了？」「平台那个功能在哪里来着，我找半天……」「算了，我直接问旁边的人。」

工具还在，没人动它，没人删它。但它悄悄从大家的工作流里消失了。

不是工具不好用，是使用方式和这个时代脱节了。

工具的问题，从来不只是功能

打个比方。

2010 年代，打车最方便的方式是站在路边招手。那时候如果有人做了一个「线上叫车网站」，功能再好，转化率也不会高——打开网站、填地址、等确认，整套流程比招手还慢。

不是工具不好，是工具跟当时的使用习惯不匹配。

后来有了手机 App，叫车变成「打开 App，点一下」，渗透率就起来了。再后来，你可以直接说「帮我叫辆车到公司」，然后就没你的事了。

工具的功能没有本质变化，但每一代调用方式，都让「想用」和「真的用」之间的距离短了一截。

工具的价值不变，但调用方式必须跟上时代。

AI 编程助手让大家习惯了「对话即操作」。这个习惯一旦养成，再切换回「打开浏览器、找到入口、登录、填表单、等结果」，摩擦感就出来了。不是工具没价值，是调用链太长，大家不愿意走了。

哪些工具可以直接「去页面化」

不是所有工具都应该去页面化，也不是所有工具都能去页面化。我大概分了三类：

第一类：查询类工具，最适合去页面化

这类工具的本质是「把数据取出来」，页面只是个展示壳。比如查某个版本的用例通过率、查某台机器的当前状态、看某个缺陷的历史记录。

这些数据背后都有接口，AI 直接调接口拿结果，比人点页面快十倍，而且还能做聚合——「帮我对比一下这个版本和上个版本的通过率变化」，这种问题人工根本不会去做，但 AI 几秒钟就给出来了。

举个例子：以前：打开测试平台 → 找到「统计」菜单 → 选时间范围 → 导出 → 自己算现在：「帮我看一下上周自动化用例的通过率，和前一周比有没有下降」→ 直接给结论

第二类：执行触发类，去页面化之后要注意「状态反馈」

触发一次自动化执行、重启一个测试环境、跑一个数据准备脚本——这些操作本身很简单，封成一个 AI 可以调用的工具不难。

难的是后续：跑完了吗？成功还是失败？失败原因是什么？

如果状态反馈是结构化的（日志可以解析、结果写进了数据库），AI 可以帮你轮询状态、分析失败原因、给出结论。这类工具是完全可以去页面化的。

如果状态反馈需要「看视频回放」或者「肉眼对比截图」，页面现在还是有存在价值的——但它的角色是「查看层」，而不是「操作层」。

第三类：复杂管理类，页面不消失，但角色变了

测试计划管理、用例库维护、环境配置——这类工具很复杂，不是三两个接口能搞定的，而且涉及到很多判断和决策。

这类工具不会消失，但使用方式会变：

以前：人打开页面 → 一步步填表单 → 点提交以后：AI 根据需求单草拟方案 → 推给人确认 → 人说「可以」→ AI 调接口真正创建

页面从「操作入口」变成了「审批和可视化」的地方。人不需要再逐步操作，只需要在最后做一个决策：「这个方案我认可。」

但有一个问题，大家都会遇到

想清楚了工具怎么演变，真正动手的时候，会碰到一个很现实的问题：

权限怎么管？谁用了这个工具，查了什么、改了什么，怎么留痕？

传统的 Web 工具，权限是绑在「登录 session」上的，谁登录了就有对应的权限，操作日志也有 user_id。

AI 代理调用工具的时候，调用者变成了 AI，这条链断了。如果不刻意处理，就会出现：工具被调了，但不知道是谁发起的，也不知道操作了什么。

这不是小问题，特别是对于权限比较敏感的工具。

核心原则：AI 是代理人，不是主体。权限永远绑在发起操作的人身上，AI 只是执行通道。这条原则如果不在架构层面保证，后面会很麻烦。

具体怎么做？一个比较实用的方案是：给 AI 层一个专用的服务账号，但每次调用必须带上「是谁发起的」这个字段（比如企微账号）。后端做两层校验：服务账号有没有权限调这个接口，发起人对这条数据有没有权限。

审计日志也在这一层统一记：谁、什么时间、通过哪个入口、调了哪个工具、查了什么。不需要每个工具自己写，统一在调用链的中间层拦截记录。

多个工具，怎么让大家用起来顺

还有一个问题：工具多了怎么管？

假设一个团队做了二十个工具，如果每个工具都要单独配置、单独维护，使用者的成本就很高了——你需要知道哪个工具在哪里，工具升级了你需要手动更新配置，不同工具的调用方式还可能不一样。

一个更好的做法是：做一个统一的工具网关，使用者只配置一个地址，背后的工具更新对他们透明。

大概的结构是这样的：

使用者 → 配置一个入口地址工具网关 → 统一做鉴权、审计、路由各业务子服务 → 各团队独立维护，互不干扰

这样的好处是：使用者不感知工具的内部变化，工具上架或升级，他们不需要改任何配置；开发工具的各个团队也不需要互相耦合，各自维护各自负责的部分；权限和审计在网关层统一处理，不需要每个工具重复实现。

工具的描述写好了，AI 就知道该用哪个；工具的 owner 定清楚了，出问题知道找谁；破坏性变更提前通知，不会突然影响使用者。

让工具「消失在背景里」，才是工具真正好用的标志。

后来那个平台怎么样了

我们后来做了一件事：没有重做平台，也没有新增功能，而是把现有的工具逐步接进了 AI 对话流——用自然语言触发，结果直接推送，不需要打开任何页面。

用了一段时间之后再看使用数据，那些「日活个位数」的工具，有些悄悄活过来了。

工具一个都没变。数据还是那些数据。逻辑还是那些逻辑。唯一变的，是调用方式。

这件事让我意识到：我们花了很多时间在问「工具做什么」，但很少问「工具怎么被调用」。在 AI 普及之前，这个问题的答案很固定，大家默认就是「打开页面操作」。但现在不一样了，调用方式本身就是一个设计决策，而且很可能比功能本身更影响最终有没有人真正用它。

工具的价值不在于它存在，在于它被用到。

一个判断标准：如果这个工具，用户需要主动想起来才会去用，那它大概率会被遗忘。好的工具，是在用户需要它的那一刻，它自然出现在对话里。

提效工具不会消失，但那个「打开浏览器，找到入口，填表单」的时代，可能真的快过去了。

— The End —

— 去外头站着 —

累了就出来透透气，一起停止内耗 🌬️