Kimi K3 实战指南：四大入口与真实案例详解

本教程适合：

• 想找一个能用、好用的国产大模型的普通用户
• 需要把 AI 接入真实工作流的开发者
• 在做技术选型的企业决策者
• 关注国产模型进展的 AI 从业者

第一章 破局者 Kimi K3 —— 开源、1M、免费的真相

后来很长一段时间，它的存在感低得像被整个 AI 圈按了静音键。

结果它不吭不响，一回来就是一个 2.8 万亿参数的 K3。

标题很猛：开源模型，代码能力直逼顶级闭源模型，首发实测。

但 K3 最值得看的，其实不是 2.8 万亿这个数字，也不是 1M 上下文。

官方把 K3 称为全球首个开源的 3 万亿级模型，这个定位没问题。

它的总参数是 2.8 万亿，原生支持视觉理解，模型最高上下文窗口是 100 万 token。

需要说清楚的是：K3 已经宣布开源，并给出了完整权重的发布时间。不是完整权重已经安安静静躺在仓库里，等所有人随便下载。

关于上下文，官方不同入口的档位差异很大：

• 网页 Agent 现在还是 128K
• Kimi Code 的 Moderato 档是 256K
• Allegretto 及以上，才解锁最高 1M
• 如果你要把它接进第三方 Coding Agent，通常还得手动把最大上下文设成 1048576

开源是真的，1M 也是真的，免费活动可能也是真的——但这些都是有条件、有时限、有边界的「真」。

它是一个你现在就能用、不用翻墙、大部分场景免费的顶级模型。

过去你要用最强的模型，得翻墙、得付费、得忍受网络延迟。现在，一个能力直逼第一梯队闭源模型的国产选项，摆在你面前。

我们只想说清楚一件事：K3 到底怎么用，才能真正帮你把活干完。

第二章 K3 的能力图谱 —— 哪里强，哪里弱

在开始用之前，你得先知道 K3 擅长什么、不擅长什么。

这一章不堆参数，只讲一件事：什么活交给 K3 靠谱，什么活别指望它。

✅ 强项：交互、界面、视觉、空间

实测下来，在交互、界面、视觉、空间这类场景，K3 完全可以当首选模型用。

• 它能一句话生成 40 多种网页组件风格——新拟态、苹果液态玻璃、极简主义，每个都是独立的 HTML + CSS
• 给它一个参考产品，它能复刻出能玩、带音效的 3D 小游戏
• 它的主动性很强。给一个大工程，它会自己拆任务、启动多个 Subagent 并行处理，任务拆分合理，互不干扰
• 有人给它服务器权限，让它跑了一整夜，第二天醒来，网站开发好了，代码也传到 GitHub 了

✅ 强项：长程、高难任务

马斯克开源了 Grok Build，大概 82 万行 Rust 代码。

有人把它同时发给 K3 和 GPT-5.6 做全量分析。K3 竟然把 XOR 混淆的 System Prompt 解密了，生成的文档信息密度极高。

⚠️ 弱项：复杂系统架构、后端核心逻辑

在架构设计、后端这类场景，K3 仍然落后于最强的闭源模型——Claude Fable 5 和 GPT-5.6。

如果你的任务重点是复杂的系统架构、后端逻辑，K3 可以用，但别指望它超过第一梯队。

⚠️ 弱项：简单、模糊的需求

K3 对长程、高难任务很擅长，但遇到简单、模糊的需求，反而会过度思考和发挥。

你只想要个简单结果，它可能给你整出一堆你没要的东西。

解决方法：需求越简单，约束要越明确。在系统提示词或 AGENTS.md 里把边界写清楚。

记住这张表，你就知道什么时候该把活交给 K3，什么时候该自己上手或换工具。

下一章，我们进入实操：K3 的四个入口，分别适合干什么。

第三章 四大入口使用指南 —— 网页 Agent、Kimi Work、Kimi Code、API

Kimi K3 不是一个单一的聊天框，而是一套完整的工作入口系统。它有四个入口：网页 Agent、Kimi Work、Kimi Code 和 API。每个入口能碰到的东西不一样，能做到的事情也不一样。

3.1 网页 Agent：零门槛的线上入口

适合做什么：

• 整理网上的公开资料
• 核查事实和数据来源
• 生成文档、表格、报告
• 不需要碰本地文件

手机和平板用户，可以在 Kimi App 的工具栏里切到 Agent 模式。

⚠️ 别把它当成 1M

很多人看到 K3 宣传 100 万上下文，就以为打开网页就能用 1M。

这意味着什么？网页正文、工具返回的内容、中间生成的文件，都会吃掉上下文。材料一多，很容易就超了。

实战提示词示例（调研类任务）：

假设你要调研 2025 年至今国内新能源汽车价格战，手上有 8 个官方链接。

调研 2025 年至今国内新能源汽车价格战。只使用我提供的 8 个官方链接，优先采用车企公告、财报和监管数据。

先交付一张事实表，字段包含：
- 日期
- 主体
- 动作
- 价格变化
- 来源链接
- 可信度

再给出公众号文章大纲。

材料冲突时单独放进「待核验」，这一轮不要写正文。

用完之后必须验证三件事：

1. 它到底访问了什么网站？
2. 事实表里的数字，能不能点回原始链接？
3. 两份材料打架的时候，它是老老实实写「待核验」，还是偷偷给你编了一个特别丝滑的结论？

等待与耐心：

1. 网页 Agent 单次任务一般需要 5 到 20 分钟，Agent 集群会更久。
2. 页面停一会儿很正常，先别手欠点「停止输出」，它可能还在后台干活。

你要同时交 Word、PPT 和 Excel，或者要做大规模并行搜索，再去看 Agent Swarm（集群模式）。

开放没开放、还有多少额度，以你账号里当天显示的为准。

小结：你第一次用 K3，就从网页 Agent 开始。但别把它当成 1M。

3.2 Kimi Work：碰本地文件的桌面入口

适合做什么：

• 读取本地 PDF、Word、Excel
• 整理本地文件夹
• 操作浏览器（登录、搜索、截图）
• 运行 Python 或 Shell 脚本

它支持 Windows 和 Apple 芯片的 Mac。按照 K3 发布时的说明，要用 Kimi Work 3.1.0 或更高版本。

核心能力：

• 挂载你授权的文件夹，读取和整理文件
• 运行 Python 或 Shell
• 配合 Kimi WebBridge 操作 Chrome 和 Edge

⚠️ 权限边界：第一次别把整个硬盘交出去

也正因为这样，第一次用的时候，千万别把整个硬盘直接交出去。

假设你有 3 份 PDF 在本地，想提取里面的数据。

不要直接授权整个硬盘，新建一个测试目录，只放那 3 份 PDF。

只读取我授权的「新能源汽车专题」目录。

不要移动、改名、删除或覆盖原文件。

提取 3 份 PDF 里的：
- 公司
- 报告期
- 车型
- 价格
- 销量
- 管理层表述
生成 local-facts.md。

每条数据附文件名和页码，无法确认的内容标成「待核验」。

完成后列出读取过的文件，不执行其他操作。

完成以后，随手抽 3 条数据，回到原 PDF 看文件名、页码和数字。

AI 最可怕的错误，不是它告诉你「我不会」，而是它很自信地把一个错误数字，写得像真的一样。

关于 Kimi WebBridge 的隐私边界：

Kimi WebBridge 是一个 Chrome/Edge 插件，可以让 Kimi Work 操作浏览器。

官方说明里写的是：浏览器桥接和操作在本机完成，登录态不会离开设备。

但是，登录凭证留在本机，不等于任务读到的所有内容都不会进入模型上下文。

敏感场景的底线：

• 财务、客户、内部系统，这些东西还是按敏感数据来处理
• 发帖、下单、提交表单、删内容、发消息，最后一下点击，留给自己

长程任务记得定期检查：

• 运行时间
• 输入来源
• 保存位置
• 失败以后怎么办

小结：Kimi Work 最重要的，不是比网页多了几个按钮。而是它开始碰你的真实文件和真实登录态了。

3.3 Kimi Code：终端里的 Coding Agent

Kimi Code 是终端里的 Coding Agent。

适合做什么：

• 读懂现有项目
• 做对修改
• 自己跑测试
• 发现问题
• 把坑填上

安装（macOS/Linux）：

curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash

安装（Windows PowerShell）：

irm https://code.kimi.com/kimi-code/install.ps1 | iex

远程脚本会直接执行，介意的话，先打开脚本链接看一眼。

Windows 还需要 Git for Windows。走 npm 安装的话，Node.js 要 22.19.0 或更高。

第一次启动：

第一次启动输入 /login，然后用 /model 切到 K3。

官方专门提醒过，中途从其他模型切到 K3，或者客户端没有完整回传历史思考内容，输出可能会很不稳定。

实战示例（只读方案阶段）：

假设你有一个 verified-facts.csv 文件，想做一个单页数据可视化网站。

只读检查当前目录和 verified-facts.csv，给出一个单页数据可视化网站的实现方案，不修改文件。

页面要有：
- 时间线
- 品牌筛选
- 价格变化图
- 来源抽屉

必须适配手机。

列出文件结构、验证方式和需要我确认的设计选择。

实战示例（执行阶段）：

/goal 根据已确认方案完成网页。
所有图表只能使用 verified-facts.csv。
实现品牌筛选、来源查看和移动端布局。
运行测试和构建，修复发现的问题。
完成标准是：
- 构建通过
- 控制台无报错
- 关键交互可用
并列出改动文件和验证结果。

验证清单：

• 品牌筛选，数据变不变？
• 图表数字，能不能回到 CSV？
• 来源抽屉，能不能打开？
• 手机宽度，文字会不会挤成一团？
• 测试和构建，到底是真跑了，还是只留下一句「理论上可以」？

⚠️ 关于 /yolo：

Kimi Code 默认会在写文件和执行命令前弹审批。

/yolo 能跳过很多确认，但第一次用，真别开着它碰业务项目。

打个比方：一个刚认识 10 分钟的同事，突然跟你说「哥，管理员权限给我，我保证不乱动」，你敢给吗？

上下文档位：

• Moderato：可以用，但上下文是 256K

最笨但最靠谱的办法，就是打开产品页，看你当前入口和会员档位到底写了多少。

小结：Kimi Code 真正要看的，不是第一屏代码有多长。

3.4 API：水电煤级别的接入

如果前面三个入口已经能解决你的问题，这一段可以直接跳过。

接入地址：

https://api.moonshot.cn/v1

先去 API Key 页面创建 Key，再装 SDK：

python3 -m pip install --upgrade 'openai>=1.0'

把 Key 放进环境变量，不要塞进代码，更别顺手推到公开仓库。

$env:MOONSHOT_API_KEY = '你的 API Key'

export MOONSHOT_API_KEY='你的 API Key'

最小可运行示例：

import os
from openai import OpenAI
client = OpenAI(
    api_key=os.environ['MOONSHOT_API_KEY'],
    base_url='https://api.moonshot.cn/v1',
)
response = client.chat.completions.create(
    model='kimi-k3',
    messages=[
        {'role': 'user', 'content': '用一句话介绍 Kimi K3。'},
    ],
)
print(response.choices[0].message.content)

终端能打出回答，才算 Key、地址、模型名和账户余额都接通了。

定价（截至 7 月 17 日官方口径，实际以官网为准）：

• 缓存命中输入：2 元 / 百万 token
• 缓存未命中输入：20 元 / 百万 token
• 输出：100 元 / 百万 token

模型名怎么选：

• 开放平台：用 kimi-k3
• Kimi Code 会员接口：用 k3
• 第三方 Coding Agent：要开 1M，有些配置里要写 k3[1m]

API 的几个坑：

1. 视觉输入：不能直接扔普通公网图片 URL，要用 Base64 data URL 或 ms://<file-id>
2. 多轮对话和工具调用：得把完整的 assistant message 原样传回，不能只留下最后那段答案
3. 思考模式：K3 始终开启思考模式，思考力度只支持 max
4. max_completion_tokens：默认 131072，最高可以设到 1048576
5. 联网搜索工具：还在更新，不建议现在就塞进生产流程

小结：API 这东西，说到底就是水电煤。普通人不需要先研究管道怎么铺，打开水龙头能用就行。只有准备盖一整栋楼的人，才真的需要往后看。

同一个 K3，真正变化的，是它能碰到什么，又能替你做到哪一步。

第四章 真实战场的考验 —— 三位开发者的实战案例

真正能证明 K3 实力的，是它在真实生产环境中的表现。

• 数字生命卡兹克：用 K3 维护 AIHOT，处理用户反馈，修复 Bug
• 铁锤人：对标年收入 130 万+的盈利产品 Rotato，复刻核心功能
• 向阳乔木：一夜开发 6 个完整项目，全部上线开源

这些不是「生成一个 3D 游戏」的炫技，而是真正的生产任务。

4.1 卡兹克：用 K3 维护 AIHOT 的真实日常

数字生命卡兹克运营着 AIHOT，一个 AI 资讯聚合网站。他长期使用 Claude Code，这次决定用 Kimi Code + K3 来测试。

他给自己定了一个标准：不用 Claude Code，因为模型配上自家的 harness 框架，才是最适配的。

案例一：修复 Kimi 官方 Blog 抓取失败

问题：AIHOT 没有抓到 Kimi K3 发布的 blog。

卡兹克把这个问题直接扔给了 K3：「修一下，看看 BUG 出在哪里。」

让模型修自己公司的 Bug，这种感觉确实挺 NTR 的。

K3 的排查过程：

1. 定位问题：发现 Kimi 官方 Blog 又改版了，而且就是前两天的事
2. 找到根因：告警是 14 天断流才告警，改版后新格式没识别到
3. 修复：把告警改成 3 天，修复了 Blog 解析逻辑
4. 验证：3 分钟修复完，Kimi K3 发布信息正确出现在了 AIHOT 上

案例二：一次性批量处理积压的用户反馈

背景：卡兹克的飞书每天会推送用户在 AIHOT 上提报的反馈。他通常每天过一遍，把说得对的扔给 Agent 去修。

这两天他比较忙，攒了一批，决定一次性全部扔给 Kimi Code。

K3 读了运维文档，连上服务器，给自己列了 7 个待办，开启了 8 个 Agent。

• 研究阶段：开启 8 个 Agent，开始研究
• 执行阶段：开了 7 个工作区，7 路 Agent 并行开发
• 提交：大概 1.5 小时后，所有任务全部开发完毕
• 通知：2 小时后全部做完，用飞书邮箱发出通知

结果：完成得非常好，流程全部做完，没有任何 BUG，该完成的也都完成了，不该完成的两个任务也做了说明。

UI 体验：卡兹克特别提到，Kimi Code 的 UI 展示非常清晰，一目了然，他真的很喜欢。

方案设计对比：卡兹克还测了几个任务的方案设计，把 K3 的方案和 GPT-5.6 Sol 的方案扔给 Fable 5 去评选。

结论：跟 GPT-5.6 Sol 大概是 55 开的级别，思考的维度和方面确实都有差异。

Fable 5 最终选的是 K3 的方案（方案二），但发现 GPT 的方案里也有 K3 没考虑到的，最终还是得合并一下效果才是最好的。

案例三：热点榜单翻车记（真实教训）

任务：添加热点榜单，背后加了大概 500 个热点信源。

• 非常勤勤恳恳地做完了所有任务
• 推了 PR，过了 CI，部署上线
• K3 按照过去新监控信源的规则进行回补
• 直接把 500 个热点信源的 9000 条信息一次性怼进来
• 直接把 AIHOT 的信息处理队列给堵满了
• 后续进来的所有精选信息都在这 9000 条后面排队
• 结果：AIHOT 将近 1 个小时没有任何新资讯进站

根因：AIHOT 的系统有性能限制，一个信息进来要经过：

• 结构化处理 → 实体提取 → 预筛 → 正文清洗 → 精选评分 → 向量化处理 → 事件聚簇 → AI 摘要

中间光大模型调用就有好几次，同时并发最多处理 6 个资讯。

反思：这个队列并发没有考虑到的事，背后的本质是现在的并发处理不了 500 条以上的新闻信源，所以这个方案必须要推倒重来。

卡兹克测试后发现，GPT-5.6 Sol 也完全没有考虑到这个问题。他觉得除了 Fable 5 之外，其他模型都很难考虑得非常全面。

案例四：审美与前端效果

审美能力：Kimi 这家公司一直以来的审美就很强，K3 在前端效果上又迎来了一波飞跃。

• 一个建筑的屋檐，下面挂着密密麻麻的竖排文字线绳
• 像珠帘一样自然垂下来
• 鼠标划过去或者手指拨过去，字体会像门帘一样被拨动摇摆

Prompt 特别简单，第一版出来就已经有那个意思了，整体雏形是对的，但细节上还比较粗糙。

10 分钟左右，直出了一版。有一些小细节需要优化，他用提示调整了一下粉鱼的尺寸和游动速度，还有蓝鱼的数量，加了个 BGM。

他说：「小粉鱼最后被一群蓝鱼裹挟着消失的时候，我突然一下感受到了一些身不由己的感觉。」

他让 GPT-5.6 Sol 也复刻了一下，结果……

案例五：写作不是强项

卡兹克把他上周发的文章《设计人生》前面大半部分给 K3，让它用他的 Skill 续写结尾。

当最下面那句「祝你也逼出一点，早该被自己听见的话」出现的时候，他就知道完犊子了。

• 如果能用上 Claude，最好的写作模型还是 Claude Opus 4.6，吊打世界所有
• 如果用不上，只能用国内模型写作，那就用 DeepSeek V4 Pro

卡兹克的总体评价：

卡兹克买的是 699 的会员，跑了一夜，各种测试任务还有多 Agent 的真实环境开发，烧了很多 Token。

他觉得 K3 的价格肯定便宜不了，API 价格基本跟 Sonnet 系列对标。

建议：如果想买 Coding Plan，感觉得快点去买，不然算力限制，大概率后面会跟 GLM 一样限购。

在开发的精准性和完整性上，符合他的预期，国内最佳，没有之一。

几乎跟 Kimi 发出来的跑分体感一致，是一个综合型模型，每个地方都还不错，可能达不到 Fable 5 经常给你的那种神之一手的感觉，但也可以把项目和规划放心地交给它。

4.2 铁锤人：对标盈利产品 Rotato 复刻

一觉醒来，看到全网都在刷 Kimi K3 和旗鼓相当 Opus！！但我发现了一个问题，很多案例都不是生产中的案例。独立开发写代码根本就不会去写一些炫酷的前端页面、3D 游戏……

铁锤人说：「很多案例都不是生产中的案例。独立开发写代码根本就不会去写一些炫酷的前端页面、3D 游戏。他们只在乎一件事情：做一个赚钱的软件。」

所以他要测试：K3 是否强到能帮他对标一个盈利的软件，做出自己的版本？

目标产品 Rotato：

• 年收入估计在 130 万+人民币
• 产品设计真的漂亮
• 主要功能：做吸睛的手机、电脑动画
• 用户：软件开发者
• 用途：在社交媒体上为自己的产品吸引流量

核心挑战：

• 构建高精度的 3D 模型
• 构建好看、吸睛的动画效果
• 需要很好的设计品味和技术实力

核心问题：缺少设计能力和技术能力的开发者，如何学习到它的精髓，然后实现自己的版本？

第一步：让 K3 做技术调研

• 截到页面的图
• 读 Chrome 的网络面板
• 读网页源代码

说清楚：我们不是去抄别人的代码，只是在能看到的范围内，了解一下别人的项目选型和架构。

我要研究 {竞品网址} 上的竞品
请你使用你的视觉功能和代码能力
对这个竞品做一次全面的技术分析
从产品设计到代码实现
最后写成一份技术文档，存成 rotato-tech-analysis.md

它自己开浏览器，自己截图，自己翻网络面板，自己读源码，全程你一根手指都不用动。

第二步：照着复刻

拿到技术文档后，铁锤人直接让 Kimi 照着复刻了一版。

但你把它跟 Rotato 摆在一起看，差距一眼就出来了：

• 阴影不够好看
• 转场动画也差点意思

这是图形学和审美的活，而这恰恰是大部分程序员的短板。

铁锤人的方法论：不懂领域也能复刻

1. 列出所有可能的方案方向：听清楚，是所有可能的，漏掉的那个说不定就是唯一能走通的路
2. 联网查资料，标注成功概率和时间：给每个方案标上成功概率和要花的时间
3. 按指标排序，从头开始试：概率最高、花时间最短的排最前面，然后从头开始，一条一条往下试

因为概率高、时间短的方案能让你最快动起手，试完一轮就长一点认知，有了认知才判断得了后面那些难的。

反过来，一上来挑个又难又慢的，最后不仅浪费 Token，还浪费钱。

K3 干这种长程调研的活已经很够用了，它确实把一整套方案给扒出来了。

第三步：实现自己的版本

经过一轮搏斗，铁锤人终于搞懂了整个项目的技术方案：

1. 使用 3D 引擎配合高精度模型构造出好看的界面

有了基本的技术认知后，就可以自己去实现自己的版本了。

注意：我们不能照搬对方的代码，仅仅研究对方的技术栈，就能让模型找到方向实现。

经过一番搏斗，铁锤人把这个产品的核心功能复刻出来了。

• 材质还行
• 因为苹果版权原因，不能用 iPhone 的模型，用了自己的手机模型
• 灯光配置、阴影配置都是自己调的

后面大部分时间都耗在调阴影和灯光上。由于铁锤人自己缺少专业知识，K3 就一直不停地试，试了很久，最后也没试出效果来。

换 Opus 去做，效果也不怎么样，甚至还改差了。

最后拿 Fable 5 试了一下，它一下就判断出问题的根源在哪。Fable 5 的知识面确实广。

铁锤人的模型选型观：

• 强度媲美 Opus 4.8
• 比起 Fable 5 的知识深度，还是有差距
• 但它便宜：Sonnet 的价格，Opus 的性能
• 最关键的是，你用 Anthropic 的模型，它随时可以剥夺你使用它的权利

当一个产品的价格比对方便宜，而且能稳定使用，而且效果还不赖的时候，他肯定会选择这个模型。

• Fable 5：拿来做规划，解决复杂问题
• K3：当中层模型，写代码，做那些不难的功能
• 其他模型：还没赶上来的模型，只适合纯写代码

这就跟计算机的缓存系统一模一样：越往上越贵、用得越省，越往下越便宜、跑得越多。

4.3 向阳乔木：一夜开发 6 个完整项目

向阳乔木一直用 Codex 和 Claude Code。测了 Kimi K3 后，竟有超预期惊喜。

他直接给了 Kimi K3 服务器权限，一口气开发了 6 个完整项目，全部上线、免费开源。

覆盖范围：

• 前端
• 后端架构 / 数据库开发
• AI 模型调用
• 本地已有项目优化迭代

一直用 Codex 和 Claude Code，测了 Kimi K3 后，竟有超预期惊喜，真的是强！刚用时，不了解情况，只敢给一些简单任务，后面越用越牛逼。后面直接给了 Kimi K3 服务器权限，一口气开发了 6 个完整项目……

项目一：IMDB 电影推荐网站

• 一般视频网站都只支持电影名搜索，不知道名称就不好找片子
• 想用 AI 帮推荐电影，实时检索 IMDB 库展示，最好还能在线看
• 找到一个免费 IMDB 数据库叫 OMDB
• 把 API key 和文档发给 Kimi K3
• 要求调乔木 AI PRD Skill、LLM Skill、网站部署 Skill
• 要求写产品方案并开发上线

K3 的执行过程：

• 激活了所有要求的 Skill
• 思考 58 次，调用了 82 次工具
• 先搭后端 sqlite 数据库，后写前端页面
• 甚至设计了 favicon 和 OG 图，让网站看起来更正式、专业
• AI 全自动测试，很像一个人在喃喃自语：「首页感觉对了。看结果页和详情弹窗」
• 测试通过后上线，调用了 Vercel CLI 部署
• Cloudflare 解析绑定了域名

后续还有两轮对话，他仅补了详情页观影地址和 100 个轮播提示，一次性全搞定。

细节亮点：页面顶部背景，竟然是用 OMDB 返回的电影海报封面拼接做的背景。前端审美果然是 Kimi 传统强项。

项目二：iOS 应用（乔木提词器）优化

背景：向阳乔木之前用 GPT 5.5 开发了一个 iOS 应用（乔木提词器）。

测试方法：直接把 GitHub 仓库给 K3，让它找优化空间。

K3 的表现：

• 代码质量中上
• 但依然找到 5 个高危漏洞
• 4 个性能问题
• 2 个架构问题
• 不少 UX 问题

修复过程：

• 预感工作量大，直接启动了 5 个 Subagent 修复
• 任务拆分合理，互不干扰
• 很快修改完成，编译通过
• 唤起 iOS 模拟器让向阳乔木体验

项目三：Switch 3D 游戏复刻（Mastermind）

背景：向阳乔木的女儿特别喜欢 Switch 上的《世界游戏大全 51》中的猜颜色游戏。

• 每次选四个颜色
• 通过反馈信息（颜色和位置是否正确）
• 用最短轮次，给出正确的颜色和顺序排列
• 为了视觉效果和可玩性，直接上 3D 版
• 顺便测模型的 Three.js 建模能力

结果：

• 第一版生成后就能玩，甚至还带音效
• 但界面需优化
• 为增加竞争性，改成云端数据库，记录每个玩家的最好成绩做排行榜

项目四：Gif 压缩 Skill

• Gif 是比视频更容易展示的格式
• 在公众号中，视频需要点击才能播放
• 但公众号有限制：Gif 最大为 10M，不能超过 300 帧，帧率要控制在 12-20 fps

需求：让 Kimi K3 帮写一个 Gif 压缩 Skill。

• 10 分钟就开发完成
• Skill 质量不错
• 能自动剪掉过长静态帧
• 在保证画质前提下，降低文件大小

npx skills add joeseesun/qiaomu-tiny-gif

项目五：82 万行 Grok Build 代码分析

背景：马斯克开源了 Grok Build，大概 82 万行 Rust 代码。

测试：向阳乔木同时发给 Kimi K3 和 GPT 5.6 Sol Ultra 做全量代码分析、挖掘，最后生成飞书文档对比。

K3 的表现：

• 竟然把 XOR 混淆的 System Prompt 解密了
• 文档信息密度极高
• 挖掘出不少有趣的工程设计

GPT-5.6 Sol Ultra：

• 同样完成了任务
• 粗看标题很厉害，语言更流畅
• 但仔细读发现内容有点空洞

项目六：arXiv 论文网站

背景：arXiv 是最流行的论文预印本发布网站，新 AI 论文一般都会发布到这里。但网站全英文，搜索查找不方便。

参考 imdb.qiaomu.ai 的代码，开发一个更好用的 arxiv 网站
列出一些值得看的论文或主题，也可以搜索优质论文
可以一键下载 pdf 或在线看论文
调用乔木 llm 中的 Deepseek flash v4 做 AI 解读和推荐引擎
网站域名叫 arxiv.qiaomu.ai 用乔木设计 skill 开发（你选最合适的风格，不要问我）
代码开源到 github
arXiv 的 api 参考：
https://info.arxiv.org/help/api/basics.html#using

结果：第二天醒来，网站开发好了，GitHub 也上传了。

更多彩蛋：

• AR 3D 眼镜试戴：提示词相当简单，竟然支持 webcam 摄像头，人脸识别等
• UI 学习网站：一句话让 Kimi K3 生成 40 多种网页组件风格，如新拟态、苹果液态玻璃、极简主义等

向阳乔木的总结：

虽然跟最顶级的 Fable、GPT 5.6 Sol Ultra 还有一点点差距，但体验已经非常接近，非常不可思议。

从前后端开发、数据库、AI 调用，到 iOS 优化、3D 建模、Skill 编写，没有任何一项拉胯。

怪不得 Kimi 会把版本号直接从 2.7 升到 3.0，看来团队也相当有信心。

4.4 三位开发者的共同结论

• K3 比预期效果还要好
• 国内最佳，没有之一
• 前端是舒适区，写作不是强项
• 强度媲美 Opus 4.8
• Sonnet 的价格，Opus 的性能
• 最关键的是不怕封号
• 体验比 GPT 5.5 和 Opus 4.8 还好
• 没有任何一项拉胯
• 不怕封号、放心用国产

这些不是营销话术，而是三位开发者真金白银买会员、跑项目、踩坑、填坑之后的真实感受。

第五章 如何与 K3 协作 —— 六段式提示词、验证方法、权限管理

这一章，我们聊聊如何把脑子里的需求，转化成 K3 能听懂、能执行、能交付的任务。

写任务提示词，本质上就是把人脑子里的默认信息掏出来。

人和人沟通的时候，很多东西不用说，对方也能猜到。但 AI 不行，你不说，它就不知道。

下面这套六段式，没什么玄学，就是尽量把人脑子里的默认信息结构化。

5.1 六段式任务提示词

第一段：目标（Goal）

为什么重要：目标决定了 K3 的决策方向。同样是「整理文档」，给老板看和给技术团队看，侧重点完全不一样。

为技术团队整理一份新能源汽车价格战的事实清单，用于产品规划会议。

第二段：背景（Context）

为什么重要：背景帮助 K3 理解你的约束条件。比如「只能用公开数据」和「可以用内部系统」，执行方式完全不同。

团队对新能源汽车行业不熟悉，需要快速了解 2025 年至今的价格战情况。
只能使用公开数据，不能访问付费数据库。
会议时间紧，需要在 2 小时内完成。

第三段：输入（Input）

写什么：必须读取哪些文件、目录、链接或数据，谁的优先级更高。

为什么重要：明确输入，K3 才知道从哪里找材料。如果不说清楚，它可能会自己去网上搜，搜出来的东西可能不是你想要的。

必须读取：
1. 我提供的 8 个官方链接（车企公告、财报）
2. 本地文件夹「新能源汽车专题」中的 3 份 PDF
优先级：
- 官方公告 > 媒体报道
- 财报数据 > 行业分析
不要使用：
- 社交媒体评论
- 未经验证的自媒体文章

第四段：过程（Process）

写什么：先做什么，后做什么。材料冲突怎么处理。哪些动作必须先确认。

为什么重要：过程控制了 K3 的执行路径。如果你希望它先整理事实、再分析，就得明确说出来。

第一步：读取所有输入材料，提取事实
第二步：将事实按时间线排序，标注来源
第三步：识别材料冲突，标记为「待核验」，不要自己编结论
材料冲突处理原则：
- 如果两份材料数据不一致，都列出来，注明来源
- 如果只有一份材料提到某个事件，标注「单一来源」
需要先确认的动作：
- 在生成最终文档前，先给我看一眼事实表，确认没有遗漏

第五段：交付（Deliverable）

写什么：文件格式、结构、长度、保存位置，要不要可编辑版本。

为什么重要：交付标准决定了 K3 的输出形式。如果你要的是 Excel，它给你 Markdown，那就白忙活了。

1. 事实清单（facts.csv）
- 字段：日期、主体、动作、价格变化、来源链接、可信度
- 保存位置：当前目录
2. 会议用 PPT（summary.pptx）
- 不超过 10 页
- 每页不超过 5 个要点
- 第一页是时间线，最后一页是待核验事项
3. 可编辑版本
- 所有图表用 Excel 生成，不要截图

第六段：验收（Acceptance Criteria）

写什么：哪些测试必须通过，哪些来源必须引用，不能出现什么，完成后怎么自检。

为什么重要：验收标准是 K3 的自检清单。没有验收标准，它可能觉得「差不多就行了」。

必须通过的测试：
- 事实表中的每条数据，都能点回原始链接
- 所有数字都有来源标注
- 没有「据说」「可能」「大概」这类模糊表述
不能出现的内容：
- 社交媒体评论
- 未经验证的预测
- 情绪化的形容词
完成后自检：
- 随机抽查 5 条数据，回到原始材料验证准确性
- 检查是否有材料冲突被偷偷「抹平」了

5.2 验证比生成更重要

K3 能生成一大堆内容，但生成的内容对不对，它自己不知道。

很多人看 AI 生成的文档，只看最后那段话读起来顺不顺。

AI 最可怕的错误，不是它告诉你「我不会」，而是它很自信地把一个错误数字，写得像真的一样。

如果 K3 给你一个事实表，上面写着「特斯拉 Model 3 降价 2 万元」：

• 点开来源链接，看原文是不是真的这么说
• 如果没有链接，问它：「这个数据从哪来的？」
• 如果它说「根据多方资料综合分析」，那就是编的

优先验证的内容：

• 关键数字（价格、销量、日期）
• 你不熟悉的内容
• 听起来「太完美」的结论

逻辑一致性检查示例：

• 「A 公司降价 10%」
• 「A 公司销量增长 50%」
• 「降价对销量没有显著影响」

这三条放在一起，逻辑上就矛盾了。AI 可能看不出问题，但你应该看得出。

5.3 权限管理：能力越大，责任越大

网页 Agent 只碰公开网页，风险可控。

Kimi Work 能碰你的本地文件和浏览器，风险就大了。

Kimi Code 能执行代码、修改项目，风险更大。

三条铁律：

1. 第一次用 Kimi Work，不要直接授权整个硬盘
2. 如果你让 K3 跑了一个长程任务，比如定时任务，记得定期看看它的执行日志
3. 如果发现它做了一些你没想到的事，赶紧停下来，搞清楚是怎么回事

5.4 从问题到任务：三个实战转化

很多人不知道怎么把一个模糊的需求，转化成 K3 能执行的任务。

示例一：整理竞品信息

错误的做法：直接发给 K3：「帮我整理一下竞品信息」

K3 的反应：它会问你一堆问题，或者自己猜，猜出来的东西大概率不是你想要的。

正确的做法（六段式落地）：

# 目标
为产品团队整理竞品的定价策略，用于下周的定价讨论会。

# 背景
我们正在做一款 SaaS 产品，主要竞品有 3 家（A、B、C）。
团队想知道他们的定价是怎么设计的，有哪些套餐，价格差异在哪里。

# 输入
竞品官网：
- A: https://...
- B: https://...
- C: https://...

# 过程
1. 访问每个竞品的定价页面
2. 提取套餐名称、价格、功能差异
3. 生成对比表

# 交付
一个 Excel 文件（competitor-pricing.xlsx），包含：
- 表 1：三家竞品的套餐对比
- 表 2：功能对比矩阵

# 验收
- 所有价格都标注了货币单位和计费周期
- 每个功能都标注了哪些竞品支持

示例二：修复 Bug

错误的做法：直接把代码扔给 K3：「这个代码有 Bug，帮我看看」

K3 的反应：它会读一遍代码，然后说「我没发现明显的问题」，或者猜测性地说「可能是这里有问题」。

正确的做法：

# 目标
修复用户登录功能的 Bug，用户反馈说「有时候登录成功了，但还是跳回登录页」。

# 背景
这个 Bug 是偶发的，大概 10 次登录会出现 1 次。
我们怀疑是 Session 管理或者前端状态管理有问题。

# 输入
相关文件：
- backend/auth.py
- frontend/LoginPage.tsx
- frontend/store/authStore.ts

复现步骤：
1. 打开登录页
2. 输入正确的用户名和密码
3. 点击登录
4. 偶尔会跳回登录页，而不是进入主页

# 过程
1. 读取相关文件，理解登录流程
2. 找出可能导致状态不一致的地方
3. 提出修复方案，不要直接改代码
4. 我确认方案后，再执行修复

# 交付
1. Bug 分析报告（bug-analysis.md）
2. 修复方案（包含改动的文件和代码片段）
3. 测试步骤

# 验收
- 修复后，连续登录 20 次，不再出现跳回登录页的情况
- 所有现有测试通过

示例三：做一个 Todo App

K3 的反应：它会做一个最基础的 Todo App，但可能不是你想要的样子。

做一个个人用的 Todo App，用于管理每天的开发任务。

# 目标
做一个个人用的 Todo App，用于管理每天的开发任务。

# 背景
我现在用的 Todo 工具太重了，我只需要一个简单的本地工具。
不需要云同步，不需要团队协作，只要能记录任务、标记完成、看历史就行。

# 输入
1. 用 Electron + React 做一个桌面应用
2. 数据存在本地（SQLite）
3. 界面要简洁，参考 Apple 的设计风格

# 交付
1. 可以运行的桌面应用
2. 打包后的安装包（macOS）
3. README（包含如何使用、如何修改）

# 验收
- 能添加、删除、标记完成任务
- 能按日期筛选任务
- 关闭应用后重新打开，数据还在
- 界面不要太丑

5.5 常见错误清单

错误一：任务太模糊

表现：「帮我优化一下这个项目」

问题：K3 不知道你要优化什么，它可能会优化代码格式，也可能会重构整个架构。

避免方法：说清楚你要优化什么。是性能？还是代码可读性？还是用户体验？

错误二：一次塞太多需求

表现：「帮我做一个电商网站，要有用户注册、商品展示、购物车、支付、订单管理、后台管理、数据分析……」

问题：任务太大，K3 可能会漏掉一些功能，或者做得很粗糙。

避免方法：拆分任务。先做 MVP（最小可行产品），能跑起来，再慢慢加功能。

错误三：只看输出，不验证

表现：K3 生成了一份报告，你看了一眼，觉得写得不错，就直接发给老板了。

问题：K3 可能会编数据、编来源、编结论。你不验证，老板发现了，丢脸的是你。

错误四：权限给得太大

表现：第一次用 Kimi Work，直接授权整个硬盘。

问题：如果 K3 执行错了，可能会误删文件、修改重要文档。

避免方法：新建测试目录，先小范围试试，确认没问题再扩大授权。

错误五：过度依赖 AI

问题：K3 不会替你做决策。它可以帮你整理信息、生成代码、做重复性工作，但最终决策还是你的。

避免方法：用 K3 来增强你的能力，而不是替代你的思考。

5.6 让协作越来越顺

沉淀模板： 如果你经常做类似的任务，把你的提示词保存下来，做成模板。

记录错误： 下次做类似任务，在提示词里加上「不要犯 XX 错误」。

逐步提高复杂度：

1. 第一次：让 K3 整理 1 个网页的内容
2. 第二次：让 K3 整理 10 个网页的内容，并生成对比表
3. 第三次：让 K3 整理 10 个网页 + 3 份本地 PDF，并生成报告

给 K3 反馈：

如果 K3 做得好，告诉它「这次做得不错，下次继续保持」。

如果 K3 做得不好，告诉它「这次 XX 地方做得不好，下次要注意 YY」。

虽然 K3 不会「学习」你的反馈（每次对话都是独立的），但这个过程能帮你理清楚自己的需求。

本章小结：

• 写清楚任务：用六段式提示词，把目标、背景、输入、过程、交付、验收都说清楚
• 验证比生成更重要：不要只看文字顺不顺，要检查数据来源、事实准确性、逻辑一致性
• 管理权限边界：新建测试目录，敏感操作留给自己，定期检查执行日志
• 从问题到任务的转化：把模糊的需求，转化成结构化的任务
• 避免常见错误：任务别太模糊、别一次塞太多、一定要验证、权限别给太大、别过度依赖
• 让协作越来越顺：沉淀模板、记录错误、逐步提高复杂度、给 K3 反馈

把任务说清楚，把验证做到位，K3 就能成为你的生产力倍增器。

第六章 K3 的局限与边界 —— 不回避问题，说清楚坑在哪

这一章不吹 K3，专门讲它的坑。知道坑在哪，你才不会踩。

6.1 复杂系统架构是短板

前面说过，K3 在前端、界面、长程任务上很能打，但在复杂系统架构、后端核心逻辑上，仍然落后于 Claude Fable 5 和 GPT-5.6。

建议：核心架构和关键后端逻辑，可以让 K3 出初稿，但一定要自己审，或者交给更强的闭源模型把关。

6.2 简单需求会过度思考

需求越简单、越模糊，K3 越容易自作主张，给你一堆你没要的东西。

建议：简单任务，把约束写死。明确告诉它「只做 X，不要做 Y」。

6.3 上下文不是默认 1M

很多入口的默认上下文远小于 1M：

• 网页 Agent：128K
• Kimi Code Moderato 档：256K
• Allegretto 及以上：1M

很多人以为打开就是 100 万，结果材料一多就超了还不知道为什么。

建议：材料多的时候，拆成事实整理、分析、成稿三轮，别一股脑全塞进去。

6.4 /yolo 不是用来保护你的

Kimi Code 默认会在写文件、执行命令前弹审批。/yolo 能跳过确认，但第一次用，千万别开着它碰业务项目。

打个比方：一个刚认识 10 分钟的同事，突然跟你说「哥，管理员权限给我，我保证不乱动」，你敢给吗？

6.5 登录凭证的隐私边界

还有一个容易忽略的点：登录凭证留在本机，不代表任务读到的内容不会进入模型上下文。

• 财务、客户、内部系统数据，仍按敏感数据处理
• 发帖、下单、提交表单、删内容、发消息，最后一击留给自己

6.6 定价与参数会变

• 定价会变：截至 7 月 17 日，官方定价是缓存命中输入 2 元/百万 token，缓存未命中输入 20 元，输出 100 元。真进生产前，再去看一眼官方定价页。
• 参数别乱传：K3 始终开启思考模式，思考力度只支持 max。几个采样参数是固定值，官方建议不要自己乱改。
• 联网搜索还在更新：这个工具还不稳定，暂时不建议塞进生产流程。

6.7 一句话总结

知道它哪里强、哪里弱、哪里危险，你才能真正把它用好，而不是被它坑。

第七章 未来展望 —— 能开始不算本事，能收尾才是工作

它真正的意义是：一个能力直逼第一梯队闭源模型的选项，第一次以「开源 + 免费 + 不用翻墙」的形态，摆在了国内用户面前。

过去你想用最强的模型，要翻墙、要付费、要忍受延迟。

用了这么多章，如果只让你记住一句话，我希望是这句：

你给它的任务越清晰，验收标准越明确，它的成功率就越高。

第一次把工作交出去，沟通成本一定很高。你得想清楚材料、权限、交付物，还得给它设计验收标准——可能比自己动手还慢。

但等规则、模板和验收方式都沉淀下来，后面每一次都会越来越快。

K3 不是一个聊天框，而是一套入口系统：网页 Agent、Kimi Work、Kimi Code、API。

这本书里的案例——修 Bug、复刻盈利产品、一夜开发 6 个项目——全都是真实场景里跑出来的，有成功，也有翻车。

真正决定你能做出什么的，不是模型有多强，而是你有没有想清楚自己要做什么，以及愿不愿意花时间，把和它协作的方式打磨顺。

结语

这不是一份炫技的 Demo 集锦，而是基于 4 位开发者真实实战经验整理的完整指南。

这份教程能给你：

• ✅ 四大入口的完整使用方法（避开官方文档没说的坑）
• ✅ 三个真实案例的实战经验（修 Bug、复刻产品、开发项目）
• ✅ 六段式任务提示词模板（直接复制改改就能用）
• ✅ K3 的能力边界对比（什么时候该用，什么时候别用）
• ✅ 权限管理和验证方法（不被 AI 坑的必备技能）

K3 的三个关键词：

1. 开源 —— 2.8 万亿参数，全球首个开源 3 万亿级模型
2. 免费 —— 大部分场景免费可用，不用翻墙
3. 能收尾 —— 不只会写代码，还能把测试跑绿、把项目部署上线

如果这份教程对你有帮助，点赞 + 转发 + 收藏，让更多人看到并且随时回来查阅，评论区也分享你用 K3 的实战经验。

说明

• 基于：2026 年 7 月官方资料与真实用户实测
• 更新：模型能力、定价、功能随版本更新，实际使用以官方最新信息为准
• 案例来源：@数字生命卡兹克、@铁锤人、@向阳乔木、@Ando

模型会一代代变强，而学会怎么和它协作的人，永远走在前面。