Kimi K3.1 Pro 提示词大全：5 个场景直接复制出结果

Kimi K3.1 Pro 已在 HiAPI 上线，新用户注册送 200 积分。下面是 5 个真实可用的提示词，覆盖排障、代码审查、方案对比、长文档分析和数据处理。每个提示词都可以直接复制，点链接会自动填好。

1. 系统排障：从报错日志定位根因

把报错日志扔给模型，让它按链路逐层排查，输出根因和修复步骤，而不是笼统的"检查网络连接"。

输出样例参考：模型会列出排查链路（如 Nginx 反向代理配置 → 后端服务健康状态 → 数据库连接池），每层给出检查命令、预期结果和异常表现，最后锁定根因（如"PostgreSQL 连接池耗尽导致新请求排队超时"），并给出两步修复方案。

你是一名后端排障工程师。下面是一段生产环境报错日志。请按以下步骤排查：

1. 逐行解读日志中的关键时间点和错误码
2. 按调用链路（入口 → 中间件 → 服务 → 数据库）逐层分析可能原因
3. 给出最可能的根因（不超过 3 条）
4. 每条根因给出验证命令和修复步骤

输出格式：
## 日志解读
## 逐层排查
## 根因分析
## 修复步骤

日志：
[粘贴你的报错日志]

用这个提示词排障 →

kimi-k3.1-pro，reasoning_effort: high。参考：约 $0.03（输入约 3000 token + 输出约 2000 token）。

要点：提示词里定义了输出结构和排查链路，模型不会跳步骤，也不会给出"重启试试"这种无效建议。排障类问题 reasoning_effort 设为 high 或 max 更有用——low 有时会跳过中间层直接猜结论。

2. 代码审查：结构化 JSON 输出

让模型审查代码并输出 JSON，可以直接入库做 CI 检查。K3.1 Pro 的 json_schema 模式确保输出字段、类型和枚举值严格匹配你的定义。

输出样例参考：模型会返回一个 JSON 对象，包含 issues 数组（每条含 file、line、severity、category、description、suggestion），summary 对象（含各严重级别计数），以及 overall_score（0-100）。严重级别严格按 critical / major / minor / style 四档分类。

你需要审查下面的代码。请严格按 JSON Schema 输出审查结果，不要在 JSON 之外输出任何文字。

审查维度：
- 逻辑错误和边界条件
- 性能问题（N+1 查询、不必要的循环）
- 安全风险（SQL 注入、XSS、未校验输入）
- 代码风格和可读性

输出 JSON Schema：
{
  "issues": [
    {
      "file": "string",
      "line": "number",
      "severity": "critical | major | minor | style",
      "category": "logic | performance | security | style",
      "description": "string",
      "suggestion": "string"
    }
  ],
  "summary": {
    "critical": "number",
    "major": "number",
    "minor": "number",
    "style": "number"
  },
  "overall_score": "number (0-100)"
}

代码：
[粘贴你的代码]

用这个提示词审查代码 →

kimi-k3.1-pro，response_format: json_schema。参考：约 $0.04（输入约 4000 token + 输出约 2500 token）。

要点：必须传 response_format: {"type": "json_schema", "json_schema": {...}} 才能锁定输出格式。提示词里也写一遍 Schema 是双保险——即使 json_schema 没生效，模型也会按格式输出。severity 用枚举值而不是自然语言描述，保证下游能直接做分支判断。

3. 技术方案对比：多维度评分表

两个技术方案摆不平的时候，让模型从多个维度打分、算总分，比让同事拍脑袋公平。

输出样例参考：模型会生成一个对比表格，维度包括性能、可维护性、生态成熟度、学习成本、团队匹配度等 5-6 项，每项给出 1-10 分和一句话理由，最后加权算出总分并给出选择建议。

我需要从两个技术方案中选一个：方案 A 和方案 B。请从以下 6 个维度逐一对比，每个维度打分（1-10）并写一句话理由，最后加权算总分，给出推荐。

对比维度及权重：
- 性能（权重 25%）
- 可维护性（权重 20%）
- 生态成熟度（权重 20%）
- 学习成本（权重 15%）
- 团队现有技术栈匹配度（权重 15%）
- 社区活跃度（权重 5%）

输出格式：
| 维度 | 方案 A 得分 | 方案 B 得分 | 理由 |
|---|---|---|---|
| 性能 | | | |
| ... | | | |
| **加权总分** | | | |

最后一段：推荐理由（不超过 3 句）

方案 A：[描述方案 A，比如技术栈、架构、关键依赖]
方案 B：[描述方案 B，比如技术栈、架构、关键依赖]
背景：[可选：团队规模、现有技术栈、业务场景]

用这个提示词对比方案 →

kimi-k3.1-pro，reasoning_effort: high。参考：约 $0.04（输入约 3000 token + 输出约 3000 token）。

要点：权重按你的实际情况调整。如果团队已经有偏向，把权重直接写进提示词，模型会在算分时体现。不要只给方案名——把每个方案的关键技术选型、依赖和团队情况写清楚，模型才能给出有依据的分数。

4. 长文档分析：从整本手册提取关键信息

把几十页的技术文档、会议记录或用户反馈扔进去，让模型提取你真正关心的几个点。K3.1 Pro 的 1M token 上下文足够吃下整本手册。

输出样例参考：模型会先概括文档主题和结构，然后对每个关键问题逐条回答，最后列出容易遗漏的边界情况和矛盾点。

下面是一份完整的技术文档。请按以下结构提取关键信息：

1. 文档主题和结构概览（一段话）
2. 回答以下具体问题：
   - [问题 1]
   - [问题 2]
   - [问题 3]
3. 文档中提到的所有限制条件和前提假设（逐条列出）
4. 容易遗漏的边界情况（至少 3 条）
5. 文档中有矛盾或不清晰的地方（如果有）

文档：
[粘贴文档全文]

用这个提示词分析文档 →

kimi-k3.1-pro，reasoning_effort: max，max_tokens: 8000。参考：约 $0.07（输入约 15000 token + 输出约 3000 token）。长文档输入 token 按实际文档长度计算，这里按约 1 万汉字的保守估测。

要点：问题 2 和 3 换成你真正想从文档里知道的事，不要留模板里的 [问题 1]。文档很长时 reasoning_effort 设为 max，low 在长上下文场景容易漏信息。重复分析同一份长文档时，第二次起缓存读只要 $0.2156/M token（输入价的 1/10）。

5. 数据分析：从原始数据生成洞察报告

给一段 CSV 或 JSON 数据，让它自动统计、发现趋势、找出异常，直接输出可粘贴到周报的报告。

输出样例参考：模型会先做数据概览（行数、字段、时间范围），然后输出关键指标统计、趋势描述、异常数据点标注，最后给出 2-3 条可执行的建议。

你是一名数据分析师。下面是一份原始数据。请完成以下分析并输出一份报告：

1. 数据概览：行数、字段列表、时间范围、数据完整度（缺失率）
2. 关键指标统计：按字段类型自动选择适当统计量
   - 数值字段：均值、中位数、最大值、最小值、标准差
   - 分类字段：Top 5 类别及占比
3. 趋势分析：如果有时间字段，按周/月聚合主要指标，描述趋势
4. 异常检测：标注偏离均值超过 2 个标准差的数据点
5. 结论和建议：2-3 条可执行建议

输出格式：Markdown 报告，分段标题，关键数字加粗。

数据：
[粘贴你的 CSV 或 JSON 数据]

用这个提示词分析数据 →

kimi-k3.1-pro，reasoning_effort: high。参考：约 $0.03（输入约 2000 token + 输出约 2000 token）。数据量大时输入 token 会相应增加。

要点：数据里不要有敏感信息（真实用户 ID、手机号、密钥）。如果数据行数很多，前面 200 行足够模型发现趋势和异常——K3.1 Pro 不需要全量数据也能给出准确的统计结论。