/goal 分析以下接口联调问题，【必须】先输出四段式诊断结构：① 请求链路图（含协议、域名、路径、关键中间件）；② 响应契约表（字段名|类型|是否必填|业务含义）；③ 差异定位点（标出请求方发的值 vs 接口文档约定值 vs 实际响应值，三列对齐）；④ 阻塞层级判断（HTTP层/网关层/服务层/DB层/缓存层）。每段用【段名】开头，段内不解释、不举例、不写代码。结构输出完毕后，再另起一行写“【结构结束】”，之后才可进入原因分析。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让Codeium在分析接口联调问题时，先输出清晰的结构化诊断框架，而不是直接跳到修复建议或泛泛而谈“检查网络”“确认参数”。结构缺失会导致后续排查无锚点、多人协作时理解错位、复盘时无法追溯判断依据。
强制AI先输出结构化诊断框架
在Codeium Chat输入框中，以/goal开头并严格使用以下指令：
/goal 分析以下接口联调问题，【必须】先输出四段式诊断结构：① 请求链路图（含协议、域名、路径、关键中间件）；② 响应契约表（字段名|类型|是否必填|业务含义）；③ 差异定位点（标出请求方发的值 vs 接口文档约定值 vs 实际响应值，三列对齐）；④ 阻塞层级判断（HTTP层/网关层/服务层/DB层/缓存层）。每段用【段名】开头，段内不解释、不举例、不写代码。结构输出完毕后，再另起一行写“【结构结束】”，之后才可进入原因分析。这一步的关键是/goal触发Codeium的流程锁机制——没有它，AI会把四段内容揉进一段话里，比如“请求走HTTPS到api.example.com/v1/user，返回data里id是number类型……”，根本无法拆解执行。
注入真实上下文锚点
粘贴问题描述时，必须包含三项不可省略的信息：
① 完整curl命令或Fetch调用代码（含headers、body、method）；
② 对应OpenAPI 3.0文档片段（至少包含paths下的该接口定义，含responses和schema）；
③ 实际收到的响应体（status code + headers + body，缺一不可）。
【缺少任一项，AI将无法生成差异定位点】。例如只给curl和响应体，AI不知道文档约定的status code应为201而非200，就会漏掉HTTP状态码校验这一关键阻塞点。
用角色+格式双重约束输出质量
方法一：指定身份与禁令
你是一名API治理工程师，正在为支付中心接口编写联调守则。只允许输出四类内容：【请求链路图】必须用→符号串联各节点（如HTTPS→CDN→Kong→Spring Cloud Gateway→payment-service）；【响应契约表】必须用|分隔三列，且字段名与文档完全一致（区分大小写）；【差异定位点】必须三列对齐，空值用
方法二：用示例封住格式漏洞
参考格式：
【请求链路图】HTTP→Nginx→Istio Ingress→auth-service→user-service
【响应契约表】code|integer|必填|HTTP状态码映射，0=成功
【差异定位点】code | 0 | 200 | type mismatch
【阻塞层级判断】网关层
注意：示例中的“Istio Ingress”不能简写为“网关”，否则Codeium会替换成“API Gateway”这类泛称，失去环境特异性。
验证结构是否真正可用
第一步：检查【差异定位点】是否出现三列对齐表格——若只有两列或文字堆砌，说明AI未解析文档契约，需重试；
第二步：对照【阻塞层级判断】，打开对应层日志（如Kong access.log或Spring Boot的DEBUG日志），确认该层是否真有记录；
第三步：拿【请求链路图】中任意一个→节点，在本地执行telnet或curl -v测试连通性，验证路径真实性。
这一步操作起来很简单，直接把curl -v命令复制进终端就行。
