每个人都应该注意到的CLI工具

Terry 的 AI 日记

今天来讲讲这两天的一个新感受，就是我感觉到 CLI 工具的普及。CLI 工具可以简单理解为没有常见图形化界面，90%的情况下都在一个黑色命令行窗口里，通过敲命令实现功能的软件形态。

我发现国内跟进 CLI 工具的公司非常多，从钉钉开始，最近好像还有其他工具也在跟进。CLI 这一波热潮，我觉得是“小龙虾”生态带火的。另外，对于 AI Agent 来说，它们其实需要更多“载具”——就像从 A 地到 B 地需要工具或载具一样。之前的工具或载具多是为人设计的，比如我们常用的 boss 直聘、B站等，都有界面；而 CLI 工具则是专门为 AI Agent 设计的，是为实现特定功能而存在的极简化、便于调用的软件界面。

前两天我提到一个想法，就是感觉我们已经“温柔地度过了 AGI 的奇点”。实际上，从现在 OpenAI 的产品和 Claude Code 来看，软件工程的奇点已经缓缓度过，而且过程很平缓。如今已经处于 AGI 功能完备、自然语言交互门槛极低的状态，可能很多人还没意识到，市场或许需要更多时间来接受这个事实。

对我自己来说，下一步有个较大的想法和启发：今天晚上睡觉时我在想，对于日常技能的封装，包括 AI 工具或可复用流程的封装，可以模仿 CLI 工具的模式。比如，若需要采集谷歌地图上的商家信息，就可以把这个流程固化成一个 CLI 工具，这样我的 Agent 调用时就能更直接、路径更短。

CLI 工具本身很完备，存在时间也长，对于 Agent 的训练语料来说，它们应该比较熟悉 CLI 工具的范式。比如拿到工具后如何使用，每个 CLI 工具都有 help 文件，里面会详细描述工具的使用方法。这是旧时代留下的范式，却很适合在新时代复用的标准。

所以下一步我准备进行的实践是：倾向于把常用、常复用的 Agent 工具，尝试封装成 CLI 格式。我的侧重点可能在网页端，因为网页端抓取信息更直接，日常也更常用，会做这样的尝试。相当于利用 Agent 自己造工具，再反过来给 Agent 使用。

最后，大家可以见证一波 CLI 工具的崛起。

今天来讲讲这两天的一个新感受，就是我感觉到 CLI 工具的普及。CLI 工具可以简单理解为没有常见图形化界面，90%的情况下都在一个黑色命令行窗口里，通过敲命令实现功能的软件形态。

我发现国内跟进 CLI 工具的公司非常多，从钉钉开始，最近好像还有其他工具也在跟进。CLI 这一波热潮，我觉得是“小龙虾”生态带火的。另外，对于 AI Agent 来说，它们其实需要更多“载具”——就像从 A 地到 B 地需要工具或载具一样。之前的工具或载具多是为人设计的，比如我们常用的 boss 直聘、B站等，都有界面；而 CLI 工具则是专门为 AI Agent 设计的，是为实现特定功能而存在的极简化、便于调用的软件界面。

前两天我提到一个想法，就是感觉我们已经“温柔地度过了 AGI 的奇点”。实际上，从现在 OpenAI 的产品和 Claude Code 来看，软件工程的奇点已经缓缓度过，而且过程很平缓。如今已经处于 AGI 功能完备、自然语言交互门槛极低的状态，可能很多人还没意识到，市场或许需要更多时间来接受这个事实。

对我自己来说，下一步有个较大的想法和启发：今天晚上睡觉时我在想，对于日常技能的封装，包括 AI 工具或可复用流程的封装，可以模仿 CLI 工具的模式。比如，若需要采集谷歌地图上的商家信息，就可以把这个流程固化成一个 CLI 工具，这样我的 Agent 调用时就能更直接、路径更短。

CLI 工具本身很完备，存在时间也长，对于 Agent 的训练语料来说，它们应该比较熟悉 CLI 工具的范式。比如拿到工具后如何使用，每个 CLI 工具都有 help 文件，里面会详细描述工具的使用方法。这是旧时代留下的范式，却很适合在新时代复用的标准。

所以下一步我准备进行的实践是：倾向于把常用、常复用的 Agent 工具，尝试封装成 CLI 格式。我的侧重点可能在网页端，因为网页端抓取信息更直接，日常也更常用，会做这样的尝试。相当于利用 Agent 自己造工具，再反过来给 Agent 使用。

最后，大家可以见证一波 CLI 工具的崛起。