Kimi API 官方提示词最佳实践：任务约束与示例提示指南

一句话结论

Kimi 官方建议把任务、背景、角色、输入边界、执行步骤、参考文本、示例和输出约束写清楚；复杂或长对话任务还应分类、摘要或分块处理，以减少模型猜测。

适用场景

• 适合的任务：需要稳定格式、明确边界、参考材料或多步处理的 Kimi API 请求；也适合为长对话和长文档设计输入流程。

• 不适合的任务：把通用提示方法当成 K3.1 Pro 专属能力、性能基准、成功率保证或 API 参数调优结论。

• 适用的模型版本：Kimi API 文档没有在本页限定具体模型版本；页面顶部有 Kimi K3.1 Pro 上线提示，但正文是通用提示指南。

• 适用的客户端、Agent 或 API：Kimi API 的 Chat Completions 消息，尤其是 system 与 user 消息；具体客户端仍需按自身接口组装请求。

• 推荐的推理档位和参数：未注明。原文没有公开 reasoning_effort、temperature、top-p 或其他参数的推荐值。

可直接使用的内容

原文明确给出的写法

以下内容是官方页面的短例或忠实转述，不是 K3.1 Pro 的专属测试：

1. 把模糊请求改成可执行请求。 原文把“How to add numbers in Excel?”改成：询问如何对 Excel 表格每一行求和，并把结果放到名为“Total”的最右列。它同时把“Work report summary”细化为总结 2023 年工作记录、按月份列出亮点、总字数不超过 500 字并给出全年总结。

2. 在 messages 中声明角色。 官方示例在 system 消息中写明助手身份、语言能力和安全边界，再在 user 消息中提出“我叫李雷，1+1 是多少？”这说明角色应放在 API 请求的角色消息里，而不是只靠任务正文暗示。

3. 用分隔符区分输入。 原文使用 <article>...</article> 包住两篇文章，也展示了 Abstract: 与 Title: 的分段写法；分隔符让待处理内容和指令有清晰边界。

4. 把处理顺序写成步骤。 官方示例要求先把三引号中的文本总结为一句，并加上 Summary: 前缀，再把这句话译成英文并加上 Translation: 前缀。

5. 用少量示例表达风格。 原文说明 few-shot 示例通常比罗列所有排列组合更高效，但示例本身是占位形式：Respond in a consistent style 与 Insert text here，页面没有提供可验证的成品输出。

6. 约束长度时优先用段落或项目数。 页面允许同时写“两句话、50 个词”，但明确提醒词数不够精确；模型通常更容易遵守指定的段落数或项目符号数。

7. 给出参考文本和缺失答案时的处理。 官方示例要求模型只依据三引号中的文章回答；找不到答案时输出 I can't find the answer.

8. 拆分复杂任务。 对有大量独立规则的客服场景，原文建议先判断查询类别，再只应用与该类别相关的后续规则。

9. 管理长输入。 长对话可在达到上下文阈值后摘要早期轮次；长文档可逐章摘要，再汇总摘要，必要时把前文摘要带入后续章节。

本文不另造完整提示词。复用上述写法时，应依据自己的任务组合指令，并保留输入数据、参考材料和输出要求之间的边界。

测试或工作流步骤

1. 先写清最终任务和验收标准，再补充读者、语言和语气；不要先堆砌角色描述。

2. 把用户内容、参考资料和指令用三引号、XML 标签或标题分开，并说明每个区块的用途。

3. 将多步任务写成有序步骤；需要分支时先分类，再列出该类别对应的规则。

4. 对事实问答加入“只依据参考文本”的规则和无答案时的固定响应。

5. 用一个能代表真实任务的输入/输出对说明格式；只有需要稳定风格时才使用 few-shot。

6. 长度约束优先写段落数、项目数或字段数；如果同时写词数，应把词数当作近似要求。

7. 长对话达到上下文阈值时摘要早期轮次；长文档按章节分块，逐步汇总摘要。

8. 在 Kimi API 中把稳定的角色和全局规则放入 system 消息，把本轮数据和任务放入 user 消息，再由客户端按实际接口发送。

9. 用真实输入检查缺失数据、边界条件和格式；本文没有使用 API Key，因此没有声称任何线上效果、成功率或延迟。

原始证据与数据

• 官方页面标题为 Best Practices for Prompts，页面导语明确说目标是通过清晰指令、示例、角色和输出约束，让 Kimi 的 system/user prompt 更可靠、可控。

• 页面原文列出九类建议：清晰指令、补充细节、指定角色、使用分隔符、明确步骤、提供输出示例、指定输出长度、提供并使用参考文本、拆分复杂任务；后半部分补充长对话摘要与长文档递归分块摘要。

• Excel 求和、2023 年工作总结、两篇 <article>、摘要与标题、三引号总结翻译、I can't find the answer. 等均为页面可见示例或固定短句；页面没有给出对应的评分、成功率或对照实验数据。

• 页面展示的 API 片段使用 messages 数组及 system/user 角色，但没有在本页公布模型参数、推理档位、上下文阈值数值或通用效果保证。

适用边界

• 这是 Kimi API 的通用提示词方法论页面，不是 kimi-k3.1-pro 专属实验、模型卡或基准报告。页面顶部的 K3.1 Pro 上线提示不能改变正文的通用定位。

• 角色、分隔符、步骤、示例和长度约束是写法建议，不是保证模型必然遵守的控制协议；真实表现仍取决于输入、模型版本、客户端实现和任务难度。

• 页面公开的是提示方法和局部示例，没有一份适用于所有任务的完整 prompt；本文没有补写模型内置指令或效果承诺。

• 原文建议摘要和递归分块，但没有规定统一的上下文阈值、摘要格式、压缩比例或质量指标；这些参数需由调用方按任务验证。

• 本页没有公开 temperature、top-p、reasoning effort、工具配置或 API 计费建议；不要从本指南推导参数优劣或 K3.1 Pro 的专项性能结论。

• “示例比覆盖所有排列更高效”是页面的提示方法说明，不是本页提供的独立对照实验结果；原文示例也多为占位文本。

复现说明

1. 打开官方 Best Practices for Prompts，核对页面标题、章节和上述短例。

2. 使用一个已授权的 Kimi API 客户端，按原文写法分别组织 system 与 user 消息；使用自己的任务、示例、参考文本和输出约束。

3. 分别测试有无分隔符、步骤、参考文本和输出示例的版本，记录完整输入、输出格式、缺失信息处理和失败样本；不要把一次结果当成模型能力结论。

4. 对长对话和长文档另测摘要、分块和汇总流程，记录上下文长度、摘要损失和最终任务是否完成。

5. 本稿只核实官方公开文档，没有发起 API 请求，没有测量成功率、延迟、成本或 K3.1 Pro 专属效果。