如何使用 Kimi K3.1 Pro

要使用 Kimi K3.1 Pro，请选择一种接入方式，与模型开启一段新对话，并把你需要它完成的具体任务以及所需材料交给它。你可以通过 Kimi 的产品和 API 来访问该模型。iWeaver 也提供 Kimi K3.1 Pro 的使用，其中包含模型的免费试用。

最有用的首要任务是：它会产出你可以核对的结果——例如对比两份文档、解释一段难懂的内容，或修复一个可复现的代码问题。本指南将带你完成这些任务，并教你如何在不每次重头开始的前提下把结果打磨得更好。

选择在哪使用 Kimi K3.1 Pro

在开始之前，先查看 Kimi K3.1 Pro 的更新内容。

Kimi 的发布公告会列出可通过其官网、应用、Kimi Work、Kimi Code 和 API 进行访问。选择最适合你要完成的任务的接入路线。

这些路线在账号要求、使用额度和控制方式上各不相同。通过某一个服务访问模型，并不会自动确立另一服务的条款。

如果是第一次尝试，除非你的目标是做集成，否则不要去配置 API。从你能在聊天或文档工作流中完成并复核的任务开始。

定义任务、选择模型、提供素材、核对结果并进一步优化。

第 1 步：在添加材料之前先定义你要的结果

先写下你希望得到什么。“分析这些文件”留出的空间太大。相比之下，“对拟定的发布计划与面试记录进行对比，并识别未被支持的假设”会让模型拥有更明确的工作。

一个有用的任务描述通常包含四个要素：

• 你需要回答的问题。
• 答案应该使用的资料来源。
• 最终输出的形式。
• 需要特别留意的细节。

例如：

将发布计划与客户面试记录进行对比。输出一张表格：拟议功能、支持它们的面试证据，以及仍未解决的问题。仅使用所附材料。把你的建议与文档中已陈述的事实分开。

让第一轮的任务范围尽量小。你可以在确认模型理解了这些来源之后再进一步扩展。

第 2 步：开启全新的会话并选择模型

如果你在两个版本之间做选择，请查看 K3.1 Pro vs. Highspeed。

在你的服务可用的模型控制选项中选择 Kimi K3.1 Pro。在 Kimi Code CLI 里，官方模型选择器是 /model。其文档也建议：切换到新模型时使用全新的会话。

如果找不到该模型，请检查你的账号权限以及当前的模型列表。官方的 Kimi 客户端中，重启或再次登录可能会刷新可用性——具体做法可参考文档说明。第三方服务可能还有自己的上线/发布流程。

避免继续一段很长的对话，而其中包含来自不同任务的假设。使用全新会话能更轻松地提供正确的上下文，并判断模型的回复。

第 3 步：按可用的顺序提供素材

清晰地命名你的文件，并说明它们之间的关系。当前政策和旧政策应分别标注。面试记录在归因需要时，应保留发言者姓名或标识符。

在写出一段长答案之前，请模型先检查资料集合：

列出你可以使用的文档、它们看起来的日期，以及每一份文档帮助回答的问题是什么。标记任何你无法读取的文件，或任何会阻碍比较的信息缺失。

这个检查点可以让你更早发现不可读的附件或版本不匹配问题。它也给了你在模型基于素材构建论证之前先纠正范围的机会。

Kimi 提供了较大的上下文窗口，但你的实际可用额度取决于接入路线和套餐。不要假设一次上传就能包含项目里的所有文件。请核对服务的真实限制。

第 4 步：在生成一份“精修报告”之前先要证据

做文档类工作时，先从证据表开始。在 iWeaver 中，你可以先使用 AI 文档摘要器，让自己在向 K3.1 Pro 提交需要“聚焦对比”的请求之前，对素材有方向性的理解。

试试这个提示词：

提取用于回答研究问题所需的证据。针对每一点，展示来源名称、我可以核对的段落或位置，以及任何会改变其含义的限定条件。把冲突单独列出来。先不要写最终报告。

先检查这张表：每段内容是否支撑了该主张？关于某一位客户的陈述，是否被扩展成了“所有客户”？是否把预测当成了已观察到的结果？

当证据足够扎实时，再要求交付物：

把已审阅的证据整理成一份 600 字的简报。先写该简报所支持的决策，解释最强的证据，并以仍未解决的问题收尾。保留来源材料中的不确定性。

两阶段流程让你有机会在内容变成“精修文稿”之前纠正推理。

第 5 步：使用有针对性的后续追问

当答案偏离目标时，要精准定位问题所在。“再试一次”几乎不给方向。

如果回复太宽泛，让它聚焦到某一个决策点上。如果它把证据和观点混在一起，请让它拆成不同的部分。如果它给出了无支持的结论，请它指出是哪个来源确立了这个结论，以及哪些更弱的措辞才是有理由的。

例如：

修改第三段中的建议。面试记录确实体现了兴趣，但并未证明对方愿意付费。请把这一点说清楚，并说明需要什么证据才能解决该不确定性。

如果你想对 PDF 做可视化梳理，“PDF 转思维导图”的工作流可以帮助组织主题。在把某个分支标签当作详细主张依赖之前，请再核对一次来源内容。

用 K3.1 Pro 进行编码

如果你正在为同一项工作评估另一款模型，请使用 Kimi K3.1 Pro vs. Claude Opus 5.5 中的任务标准。

给编码任务一个可复现的起点，以及一个可观察的终点。包含报错信息、预期行为，以及相关的项目约束。

复现失败的 date-parser 测试。找出原因，做出最小且有依据的修改，并运行相关检查。说明修复会改变哪些行为，以及哪些用例你无法验证。

检查已改动的文件和测试结果。只有当实现确实支持该解释时，你的“自信解释”才有价值。

对于集成场景，请从文档中复制你所使用的接入渠道对应的模型标识符和端点。Kimi Code 和通用 API 都会采用“按渠道命名”的方式。不要把聊天菜单里的显示名称直接替换成 API 请求里的参数。

首次运行的故障排查

用一个已经完成的任务来决定接下来做什么。如果 K3.1 Pro 产出了合理的证据表，但报告没有聚焦，就优化写作指令。如果它错过了源细节，请先改进资料的组织方式，并先完成各个检查点。等小任务带来你能信任的结果之后，再扩展工作量。