别再等接口了，用 Mock 机制强行推进 AI 工作流的实操心得

在公司推行 AI 工作流或者开发复杂 Agent 时，最让人焦虑的不是技术难度，而是那种由于“依赖链断裂”导致的被动等待。最典型的场景就是：前端在等后端接口，或者某个关键的 AI 插件还没开发完，结果整个项目卡死在 Jira 的待办列表里，团队成员只能对着任务单发呆，美其名曰“被阻塞”。

其实很多时候，所谓的“被阻塞”在很大程度上是心态问题。分享一个我早年入行时的教训：刚进公司那会儿，我负责一个前端模块，结果合作的 .NET 开发突然休假一周，我需要的接口一个都没有。当时我心想自己不懂 .NET，没接口怎么可能写代码？于是理所当然地进入了“干等”模式。

后来我意识到，与其等待对方回归，不如自己造一套“假”的。在开发领域，这就是典型的 Mock 或 Stub 机制。简单来说，就是基于双方约定的预期效果，自己写一套模拟数据接口。虽然数据是假的，但它能让前端的业务逻辑先跑起来，不需要等到后端部署完环境才能看到界面效果。

当时我用这种方式把界面和交互全部跑通了。等那个开发回来后，虽然实际接口的字段定义跟我预想的略有出入，但我只需要花半小时把模拟数据替换成真实接口即可。整体进度反而比那些死等的人快了一大截，主管当时还觉得我效率极高，让我给其他前端分享这套方法。

这件事给我的核心启发是：在职场中，尤其是在推进 AI Agent 或大模型实操时，绝对不要死磕某个缺失的环节。现在很多 AI 项目的链路很长，如果某个 API 还没调通，或者某个 Prompt 的输出质量还没优化到理想状态，千万不要停下来等。你可以先用一个静态的 JSON 文件或者手动模拟的输出结果，把整个 Workflow（工作流）的骨架搭建起来。

这种“伪装”的推进方式，本质上是在快速验证逻辑的可行性。你通过 Mock 数据，可以提前发现 UI 布局在面对长文本时的崩坏问题，或者在逻辑分支上是否存在漏洞，而不是在等待中浪费时间，最后在接口接通的那一刻才发现之前的设计全是错的。

对于习惯于“等指令”的开发者或产品经理来说，这种思维转换至关重要。如果你现在正被某个缺失的环节卡住，可以尝试以下简单的 Mock 方案来绕过阻塞：

首先，在本地创建一个 mock-data.json 文件，模拟你预期的 API 返回结构。例如，如果你在测试一个 AI 回复的界面，可以这样写：

{
  "status": "success",
  "data": {
    "user_id": "12345",
    "ai_response": "这是一个模拟的AI回复，用于测试前端UI布局，验证文本换行和加载状态",
    "timestamp": "2023-10-27T10:00:00Z"
  }
}

然后，你不需要部署复杂的 Mock 服务器，只需要用简单的拦截器，或者在代码中临时将请求地址指向这个本地文件。这样你就能在没有后端支持的情况下，完成 80% 的开发工作。

总结起来，面对复杂的协作链路，不要把“依赖项缺失”当作停工的理由。用 Mock 机制强行推进，把风险前置，把验证提前，这才是高效协作的正确姿势。