调试接口时，一个常见的痛点就是Codeium给出的提示词过于模糊，导致请求参数经常猜错、响应结构难以把握，联调过程中反复修改代码、来回折腾。其实，只要掌握几个关键技巧，就能让Codeium准确理解你的意图，显著提升调试效率。

明确告诉Codeium你正在调试哪个接口

具体来说，为了让Codeium清晰理解你正在调试的接口，提示词的开头就应当直接写明HTTP方法、接口路径以及用途。例如“POST /api/v1/users/register 用于新用户注册，后端已部署至 http://localhost:3000”。如果不写清楚协议和地址，Codeium很可能默认生成mock数据，或者curl示例指向了错误的域名，导致完全偏离目标。

接着，把你实际发出的请求原始内容完整贴出来。这部分要涵盖全部的请求头（尤其是Authorization和Content-Type），以及完整的请求体。JSON格式务必保持缩进，不要压缩成一行，并用 ```json``` 或 ```curl``` 代码块包裹。这样做的好处是，Codeium能够直接读取你真实发送的数据，而不是依赖猜测。

在请求下方换行写“收到响应：”，然后粘贴服务端返回的原始响应体，包含状态码和正文。哪怕响应是空的、超时了、或者格式错乱，也要如实写清楚。比如“响应状态码504，无body”，或者“响应body为HTML错误页，内容：...”。只有把完整信息给到，Codeium才能准确定位问题。

让Codeium区分请求错误和响应解析错误

很多时候，接口联调卡住是因为分不清问题到底出在请求一端还是响应一端。一个有效的做法是，在提示词中明确标注问题类型，比如用分隔线写出“——请求错误——”或“——响应解析错误——”。前者聚焦header缺失、字段名拼错、必填字段漏传这些前端问题；后者则专注JSON结构不匹配、字段类型不符合预期（比如后端返回字符串“123”，前端却按number去解析）这类解析层面的陷阱。

另一种方式更直接：在提示词里加一句“请逐项检查：① 请求是否符合OpenAPI v3定义（如有）；② 响应status code是否在2xx范围；③ 响应body字段名、嵌套层级、数据类型是否与文档一致”。这样Codeium就不会泛泛而谈“检查网络”或“确认后端是否启动”，而是聚焦到具体的技术校验维度上。

附带最小可复现上下文

这是最关键的一步。不要贴整文件，只截取真正出问题的那几行调用代码，比如 axios.post(...) 或 fetch(...)，连同附近相关的变量定义一起贴进来。例如：const payload = { email: userInput, password: hash(pw) }; → axios.post(url, payload)。关键5到8行就足够了。缺少payload构造逻辑，Codeium很可能会误判是后端问题，实际上却是前端传了undefined。

如果项目里启用了拦截器、重试逻辑或自定义序列化器，必须单独列一行说明，比如“已启用axios请求拦截器，自动添加X-Trace-ID”。这些中间件会改变实际的请求行为，不写清楚的话，Codeium自然无法还原真实场景。

说到底，调试接口时让Codeium帮你排查问题，本质上是一个信息沟通的过程。你提供的信息越精确、越完整，它给出的诊断就越靠谱。反过来，如果提示词只写个“这个接口调不通”，那结果大概率也是泛泛的猜测。掌握这几个技巧，联调卡住的情况会明显减少。