直接给出结论：针对DeepSeek生成的接口联调问题排查提示词，单一模板无法通用。必须根据各发布平台的特性进行定制化适配，否则容易出现字段不匹配、格式错乱，甚至内容被系统直接过滤或吞没的问题。

举例说明：飞书知识库会自动屏蔽反引号包裹的代码块；GitHub Issues模板不支持“请用✅❌符号”这类非结构化指令。因此，要让提示词在不同平台稳定生效，必须针对平台特性进行“本地化”改造。以下三套方案可直接应用于实际场景。

内部Wiki版本：嵌入可交互的故障树导航

第一步，在提示词开头明确写道：“本页旨在帮助一线开发人员自主排查HTTP接口5xx错误”，同时清晰界定使用场景与目标读者。

第二步，将原提示词中的“列出可能原因”替换为“按以下路径逐层展开→【网络层】→【服务端中间件】→【下游依赖】→【数据库连接】”，每个节点使用双星号包裹，以便Wiki识别为锚点跳转，点击可直接定位至相应排查分区。

第三步，所有排查命令需附加复制按钮标识。例如，将 curl -v http://api.example.com/health 改为「执行：【复制运行】 curl -v http://api.example.com/health」，确保工程师可直接一键复制并执行，无需手动选取。

第四步，删除所有如“建议”“可以尝试”等弱化动词，统一替换为“必须验证”“立即检查”“确认已重启”。需强调：Wiki页面一经发布即作为标准操作流程（SOP）引用，语气必须具有执行刚性，杜绝任何模棱两可的表述。

飞书知识库版本：适配@成员与卡片联动机制

第一，将原提示词中的“检查Nginx日志”改写为「打开飞书日志卡片→选择【prod-api】环境→筛选status=502→点击【关联告警】查看最近3次触发」，直接映射至飞书的具体操作路径，避免抽象描述“查看日志”。

第二，所有需要多人协作的步骤，必须插入@角色标注。例如，“数据库连接超时”环节写明「@DBA负责人 确认max_connections是否已达阈值」，在飞书中该负责人将自动被@，从而启动排查流程。

第三，禁止使用反引号。所有代码段统一使用「代码段」组件标识。例如，将 tail -f /var/log/nginx/error.log 改为「代码段：tail -f /var/log/nginx/error.log」，原因在于飞书会自动剔除反引号，只有代码段组件能保证格式完整。

值得注意的细节：飞书会自动折叠包含“http://”的长链接，因此原始URL需要缩短并附加说明。例如，“查看监控大盘”后紧跟（短链：feishu.cn/xxx，指向Grafana实时面板），既能避免折叠，又可实现直接跳转。

GitHub Issues模板版本：严格对齐label与assignee规则

第一，在提示词开头插入固定字段：
```
---
name: 接口联调异常
about: 用于快速定位跨服务HTTP调用失败原因
labels: area/api, severity/P1, type/troubleshooting
assignees: backend-oncall
---
```
此格式为Issues模板的标准头部，label与assignee必须与仓库自动化流程严格匹配，否则机器人将无法自动分配工单。

第二，将原提示词中的“描述现象”强制拆解为三个必填字段：
【请求路径】（示例：POST /v2/order/create）
【复现频率】（单次/偶发/持续）
【上下游服务名】（示例：caller=payment-gateway，callee=inventory-service）
， 从而将模糊描述转化为结构化字段，消除了歧义。

第三，所有排查动作需关联GitHub Actions可触发的自动化脚本编号。例如，“检查TLS版本”后注明（对应脚本：tls-check-v1.3，详见.github/workflows/tls.yml）。这样工程师在执行步骤时，可一键触发对应脚本，无需手动输入命令。

第四，删除所有人称代词和语气词，禁止使用“你”“请”“我们”，仅保留客观动作指令。例如，将“你应该查看header”改为“提取Response Header中X-Request-ID字段”。此要求源于GitHub Issues模板的本质——它是一个规范、无情感的操作指令集合。