告别“被阻塞”：用 Mock 机制在协作中强行推进

其实很多时候我们所谓的“被阻塞”，纯粹是心态问题。分享一个我早年入行时的教训：刚进公司那会儿，合作的 .NET 开发休假一周，我需要的接口一个都没有。当时我一个纯前端，根本不懂 .NET，第一反应就是“没接口没法写代码”，打算在那儿干等。

后来我想通了，与其等对方回来，不如自己造个“假”的。在开发领域这叫 Mock 或 Stub。简单来说，就是根据预期效果，自己写一套模拟数据接口。虽然是假的，但它能让前端逻辑先跑起来，不用等后端部署完才能看到界面。

等那个开发回来后，虽然接口定义跟我猜的不完全一样，但我只需要把模拟数据替换成真实接口就行，整体进度反而快了一大截。当时主管还觉得我效率极高，让我给其他前端分享这套方法。

这件事给我的启发是：在职场中，尤其是现在推进 AI Agent 或复杂大模型实操时，不要死磕某个缺失的环节。如果某个 API 还没调通，或者某个提示词还没优化好，先用一个静态的 JSON 文件或者手动模拟的输出结果把整个工作流（Workflow）搭建起来。

这种“伪装”的推进方式能让你快速验证逻辑可行性，而不是在等待中浪费时间。

对于习惯于“等指令”的打工人来说，这种思维转换很关键。你可以尝试以下简单的 Mock 方案来绕过阻塞：

// 假设后端接口还没出，先在本地写一个 mock-data.json
{
  "status": "success",
  "data": {
    "user_id": "12345",
    "ai_response": "这是一个模拟的AI回复，用于测试前端UI布局",
    "timestamp": "2023-10-27T10:00:00Z"
  }
}

然后用简单的拦截器或者本地服务器把请求指向这个文件。这样你就能在没有后端支持的情况下，完成 80% 的开发工作。