【必须】先完整输出判断标准，再进行问题归因与优化建议；未输出标准前，禁止出现任何sql语句、执行计划截图解读、方案名称或优劣结论。① 判断标准（仅列出条目，每条以“-”开头，不解释） p95查询响应时间≤180ms（当前基线为427ms） 单次慢查询平均扫描行数≤5000行 buffer hit ratio ≥98.2%（postgresql 15.6监控指标） wal写入延迟p99 ≤12ms 禁止修改现有应用代码逻辑 不允许停机超过3分钟 dba团队无tuning advisor使用权限 当前只允许在只读副本上执行explain analyze 支撑7月大促期间订单表单日写入量从80万条提升至240万条 满足财务月结报表生成耗时稳定在17分钟以内（当前波动范围14–29分钟） 日志保留周期需从30天延长至90天，不增加磁盘io压力② 各标准权重说明（用百分比，总和为100%，每条权重须基于你已知的上下
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要Claude在分析数据库优化问题前，先明确一套可执行、可验证、不依赖主观判断的判断标准，而不是直接甩出“加索引”“分库分表”这类泛泛而谈的建议——没有标准的优化分析等于凭空猜测。
强制Claude先输出判断标准再分析问题
在提示词最开头第一行就写：【必须】先完整输出判断标准，再进行问题归因与优化建议；未输出标准前，禁止出现任何SQL语句、执行计划截图解读、方案名称或优劣结论。
这一步是硬性闸门。Claude默认倾向跳过标准定义直奔结论，不加这道锁，它会在第一句就写“建议在user_id字段建B树索引”，后面全是理由堆砌，而你根本不知道它依据的是QPS还是锁等待时间。
【角色声明必须独立成句，且不可与任务描述合并成一句】
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
判断标准必须含三类硬性要素
明确要求标准包含且仅包含以下三类要素，缺一不可：
方法一：可量化指标
- P95查询响应时间≤180ms（当前基线为427ms）
- 单次慢查询平均扫描行数≤5000行
- Buffer Hit Ratio ≥98.2%（PostgreSQL 15.6监控指标）
- WAL写入延迟P99 ≤12ms
方法二：约束条件
- 禁止修改现有应用代码逻辑
- 不允许停机超过3分钟
- DBA团队无Tuning Advisor使用权限
- 当前只允许在只读副本上执行EXPLAIN ANALYZE
方法三：业务目标对齐项
- 支撑7月大促期间订单表单日写入量从80万条提升至240万条
- 满足财务月结报表生成耗时稳定在17分钟以内（当前波动范围14–29分钟）
- 日志保留周期需从30天延长至90天，不增加磁盘IO压力
【模糊描述会导致标准失效】
用结构化格式切断自由发挥路径
第一步：在提示词末尾追加格式指令，强制Claude把标准单独成块输出：
请严格按以下格式分段输出：
① 判断标准（仅列出条目，每条以“-”开头，不解释）
② 各标准权重说明（用百分比，总和为100%，每条权重须基于你已知的上下文推导，如“因订单表慢查询占比达63%，‘单次慢查询扫描行数’权重设为32%”）
③ 问题归因与优化建议（仅在此部分出现SQL、执行计划分析、具体操作步骤）
第二步：注入真实锚点堵住幻觉漏洞
直接写明：“当前数据库为PostgreSQL 15.6主从架构，主库配置32核64GB，只读副本为16核32GB；监控系统使用Prometheus + Grafana v10.4.3，慢查询阈值设为500ms。”
第三步：绑定业务节奏
加入时间锚点：“本优化方案需在2026年7月15日前完成上线验证，灰度窗口为7月10日–12日每日02:00–04:00。”
第四步：引用既定决策
写清：“上月DBA委员会已否决引入任何新中间件（包括pg_hint_plan、citus），所有优化必须基于原生PostgreSQL能力实现。”
这一步决定脚本能闭环运行。没有结构化反馈，就等于没有检查。
