一个开发者为什么放弃Postman，写了200行代码

去年有份开发者调研显示，87%的工程师每周花超过3小时在API调试上。但真正让人崩溃的不是时间，是重复——每次接口变更，你都要重新走一遍：拿token、调接口、验数据、确认没坏。Postman能搞定这些，但一位工程师还是决定自己写个工具。200行代码，没有界面，纯命令行。这背后不是技术洁癖，是对工作流的重新理解。

从"点按钮"到"写剧本"：API测试的思维转换

作者遇到的具体场景很典型：内部系统间的服务器对接，不是浏览器里点点就能验证的前后端交互，而是涉及客户端凭证、访问令牌、请求体校验的链式操作。

这种工作在纸面上很简单，现实中迅速变成重复劳动。API每变一次，整个流程就要重测。有时用用户密码换token，有时用客户端凭证，然后调正式接口、验证入参出参，确认一切正常后才能开始写自己的集成代码。

Postman当然能做这些。作者也用过。

但问题出在工作流。

集成开发时，你不是发一个请求看一个响应就完事。你需要可重复的方式来证明：认证流程能走通、token能正确获取、依赖接口按预期响应、最终调用返回有效数据。这和手动探索API是完全不同的需求。

手动工具适合第一次学接口。但一旦工作变成可重复的，你就需要更像"测试"、而不是更像"仪表盘"的东西。

这就是tat要填的坑。

真正的痛点：我们测的是"端点"，但集成是"旅程"

作者花了段时间才意识到，问题不只是工具，而是对API测试的思考方式。

大多数工具推着你按端点单独测试：检查GET /users返回200、验证POST /orders创建资源、确认DELETE /orders/{id}返回204。但集成工作从来不是这样的。

真实场景永远是链式的：先用客户端凭证换token、再用token调用户列表、取第一个用户ID查详情、用详情里的数据创建订单。这不是端点测试，是流程测试。

作者想要的是描述真实集成旅程的方式，而不是写孤立的检查点。一旦想通这层，tat的设计就清晰了。

它不只是发请求，是测流程。

为什么必须是CLI和JSON：开发者的环境本能

这个项目源于具体场景，不是要做通用API平台。作者需要轻量方案满足四个条件：用纯JSON定义测试、支持步骤间传递数据、能断言响应内容、能塞进CI流水线。

最后一点很关键。

作者想要自然融入CLI工作流的工具。终端里待着的时间很长：代码编辑器、脚本、Git工作流、AI编程助手都在那里。如果API测试工具也能在这个环境里跑顺，整个闭环就会更快。

所以tat是JSON驱动、CLI优先。

公平地说，Postman不限于GUI。它有Newman和Postman CLI，作者也清楚这点。但问题在于，那仍然不是他想要的工作流形态。

首先，他希望测试定义以纯文件形式存在项目里，格式简单、专为API检查设计。其次，执行要轻量、可脚本化、能在CI里跑。第三，输出要干净，方便和shell工具链拼接。第四，工具本身要极小，没有运行时依赖，几毫秒启动。

Postman的CLI方案在这些点上都有摩擦。文件格式是专有的，执行需要Node环境，输出需要额外处理才能解析，启动时间以秒计。

作者不是要做Postman的替代品。他是在优化自己的特定工作流：快速迭代、版本控制友好、和现有工具链无缝衔接。

AI工作流的隐秘接口：为什么小工具突然重要了

原文标题里有个容易被忽略的点：fits With AI Workflows（适配AI工作流）。作者没展开，但这是理解tat的关键语境。

2024年以来，AI编程助手的普及改变了开发者的工具偏好。Cursor、GitHub Copilot、Claude Code这些工具都深度集成在编辑器/终端环境里。当你让AI"帮我写个测试这个API的脚本"时，它生成的是可执行的代码或shell命令，不是Postman集合文件。

tat的JSON格式在这里成了优势。它足够简单，AI可以可靠地生成和修改；它又足够结构化，能被程序解析。作者提到"AI coding assistant already live there"（AI编程助手已经住在那里），暗示了这种协同。

这不是偶然。越来越多的开发者工具开始采用"AI可读写"的设计：纯文本配置、标准输入输出、可组合的原子操作。tat的200行代码里，可能有一半是在确保这个接口的简洁性。

一个有趣的对比：Postman也在推AI功能，但它的AI是"在Postman里用"，而tat的逻辑是"在AI的环境里用"。前者是中心化的，后者是嵌入式的。对于已经习惯用自然语言驱动开发的工程师，后者的摩擦系数明显更低。

从个人工具到潜在范式：小即是大的逻辑

tat目前是个个人项目，但作者的开源策略值得注意。他没有追求功能完备，而是刻意保持极小：单一二进制文件、零依赖、子毫秒级启动。这种设计哲学和Go语言生态里的很多工具一脉相承——bat替代cat、fd替代find、ripgrep替代grep。

这些工具的成功不在于功能更多，而在于在特定场景下比通用工具快10倍。

API测试领域长期被Postman垄断，但垄断也意味着臃肿。Postman的免费版有请求数限制，团队协作需要付费，桌面应用启动慢，集合文件和代码仓库分离。这些"小问题"在日复一日的使用中累积成真实的成本。

tat的出现提示了一种可能的未来：API测试像单元测试一样，成为代码库的一等公民。测试定义和实现代码放在一起，版本控制统一管理，CI流水线原生执行，AI助手随时生成和修改。

这不是要杀死Postman。手动探索API、团队协作评审、非技术成员参与——这些场景Postman仍然最优。但在开发者个人的集成工作流里，轻量、可脚本化、AI友好的工具可能正在切走一块蛋糕。

事件复盘：一个工具诞生的完整时间线

让我们回到作者的原始情境，还原这个决策是怎么做出来的。

第一阶段：需求觉醒。内部API集成任务，服务器间通信，涉及认证链和数据校验。Postman能完成单次调试，但无法优雅地处理"如果token过期就重取，然后用新token继续"这类流程逻辑。

第二阶段：认知转换。意识到自己要的不是"更好的Postman"，而是"API测试的单元测试框架"。端点测试思维→流程测试思维，这个转变决定了后续所有设计选择。

第三阶段：约束收敛。明确四个硬需求：JSON配置、数据传递、响应断言、CI集成。同时排除GUI依赖，锁定CLI优先。

第四阶段：环境适配。发现AI工作流已成为日常开发环境的一部分，工具设计需要考虑"AI可生成、可修改、可解释"的特性。

第五阶段：极简实现。用最小代码量满足核心需求，拒绝功能蔓延，保持单一二进制和零依赖。

这个路径和许多成功的开发者工具一致：从个人痛点出发，解决具体场景，保持极简，让社区自然扩散。它不是创业公司的产品路线图，是工程师对自己时间的重新定价。

为什么这件事值得关注

tat本身可能永远不会成为主流工具。但它代表的趋势很重要：开发者正在重新夺回对工作流的控制权。

过去十年，SaaS工具倾向于把开发者拉进自己的平台：Postman的云端协作、Figma的设计系统、Notion的知识库。这些工具创造了价值，也创造了锁定。你的数据、你的工作流、你的习惯，都变成了平台的资产。

AI的普及正在逆转这个趋势。当AI可以生成代码、解释配置、转换格式时，"易用"的定义从"漂亮的GUI"变成了"AI能理解和操作"。纯文本、标准格式、原子化操作——这些曾经"对普通用户不友好"的特性，突然成了对AI友好的特性。

tat的JSON配置比Postman的图形界面更AI友好。它的CLI输出比Postman的格式化响应更容易被脚本消费。它的零依赖部署比Postman的桌面应用更容易塞进任何环境。

这不是复古，是接口层的代际更替。

对于25-40岁的科技从业者，这个案例的价值在于：它展示了如何在AI时代重新评估工具选择。不是看功能列表谁更长，而是看谁能无缝嵌入你的现有工作流——包括那个越来越重要的AI助手。

作者最后没有给出roadmap，没有承诺维护，只是开源了代码。这种"用就用的