为两类用户打造工具

在软件发展的大部分历史里，开发者工具只有一类用户：坐在屏幕前的人。我做的日志工具，现在有了两类用户。工程师每天在用，AI 智能体也在用。同时为两者设计，结果让它对双方都更好用了。

起点

这个工具最初是为了解决我自己的烦恼。我们的系统会生成非常大的二进制日志，而原来的查看工具加载慢、过滤更慢；没有颜色区分，没有像样的键盘导航，也没有命令行。每次排查都从等待开始，这些等待累积起来就是好几个小时。

于是我用 Go 写了一个新的，从第一行代码起就围绕大文件来设计。过去要几个小时才能打开的日志，现在几秒钟就能打开，还能一次批量处理多个日志。在乎工具的工程师很快就用上了它：那些离不开键盘、讨厌等待的人。

第一课：先做引擎，再做界面

最重要的一个决定，其实是为人做的，而不是为 AI。我把所有真正的工作都放进一个核心引擎，把每种使用方式都当作一层薄薄的前端：命令行、终端界面、网页、VS Code 和桌面应用。

这个决定带来了两次回报。每增加一个前端都很便宜，因为它复用了所有能力。而当智能体出现时，它最需要的东西早就准备好了：一个输出稳定可预期的命令行。智能体点不了图形界面，但它非常擅长运行一条命令、读懂返回的结果。

第二课：给智能体一张地图，而不是整片领土

人的第一反应，是把所有东西都塞给模型：完整的日志、所有日志格式、能找到的全部上下文。效果很差。模型被信息淹没，而你要为每一个 token 买单。

有效的做法是渐进式披露。智能体先拿到一张小地图：有哪些内容，以及如何获取。当它需要系统某一部分的细节时，只去要那一部分，别的不要。各个团队可以补充自己负责领域的知识，而不会让每一次请求都变得更重。

第三课：速度对智能体比对人更重要

人打开一份日志，读一遍就完了。智能体则会打开、过滤、验证一个猜想、再过滤，如此反复几十次。如果每一步要几分钟，智能体就毫无用处；如果只要一秒钟，你泡杯咖啡的工夫，它已经推理出答案。我当初为没耐心的工程师做的性能优化，正是让 AI 分析变得可行的前提。

第四课：人也应该用上 AI

智能体驱动工具只是故事的一半。另一半是，工程师可以用自然语言说出想要什么，打字或语音都行：比如「显示上次重启之后读卡器的所有错误」。工具会把这句话变成他们原本要手写的过滤条件。高手照样自己写过滤；其他人，再也不用先学会怎么写。

如果能对当初的自己说一句话

把命令行当作真正的接口，让它的输出朴素而稳定，其余的都只是外壳。一个让键盘党工程师用得顺手的工具，离能被智能体使用，已经走完了大半的路。