1. 项目背景与核心痛点
作为一名长期奋战在前端开发一线的工程师,我深知接口联调过程中的各种"痛"。记得去年参与一个电商项目时,后端团队因为排期问题延迟了两周才提供完整接口文档,而前端页面早已开发完成。那段时间我们不得不手动编写各种Mock数据,光是维护不同场景的测试用例就耗费了大量时间。更糟的是,当线上出现接口异常时,测试环境复现问题简直像大海捞针——要么是数据不对,要么是网络环境差异导致。
这些经历促使我开发了"顾得助手"Chrome插件中的网络智能调试功能。这个工具主要解决三大核心痛点:
- 前后端进度不匹配:后端接口未完成时,前端无法进行有效联调
- 异常场景模拟困难:500错误、网络延迟、空数据等边界情况难以真实模拟
- 线上问题复现成本高:需要反复修改代码或配置才能复现特定线上问题
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 功能特性与技术选型
2.1 核心功能矩阵
该调试助手具备以下核心能力:
| 功能类别 | 具体能力 | 技术实现要点 |
|---|---|---|
| 请求拦截 | 支持fetch和XMLHttpRequest全量拦截 | 重写原生API + Service Worker配合 |
| Mock规则配置 | 支持请求头、请求体、响应体、状态码、延迟时间等全方位Mock | 规则引擎 + AST语法树分析 |
| 交互方式 | 可视化界面操作与自然语言指令双模式 | 多模态输入解析 + 意图识别 |
| 持久化能力 | 规则会话级持久化,支持导入导出 | IndexedDB + 自定义序列化协议 |
| 智能辅助 | 多轮对话上下文保持,支持模糊指令识别 | LangGraph状态机 + 向量检索 |
2.2 为什么选择LangGraph?
在技术选型阶段,我对比了多种方案:
- 纯Prompt工程:随着场景增多,Prompt会膨胀到难以维护,且多轮对话状态管理困难
- 传统状态机:灵活性不足,难以处理自然语言的不确定性
- **LangChai
