一、Kimi K3 简介
Kimi K3 是月之暗面于 2026 年 7 月 17 日发布的全球首个 3 万亿参数级开源大模型（实际 2.8 万亿），具备原生视觉理解、100 万 token 上下文及长程 Agent 任务执行能力，定位为软件工程、知识工作与深度推理场景的旗舰模型 。
能力表现与评测
- 编程与 Agent：在 Arena.AI 前端代码榜单登顶（超越 Claude Fable 5）；支持 48 小时+自主 Agent 运行，可独立完成芯片设计、GPU 编译器构建等复杂工程
- 知识工作：能自主搜集分析数十篇文献、处理百份 PDF，生成含交互式可视化的深度研究报告
- 综合排名：整体略逊于顶级闭源模型（如 Claude Fable 5、GPT-5.6 Sol），但稳定超越 GPT-5.5、Opus 4.8 等梯队，在中文理解与特定编程任务上表现突出
价格
Kimi K3 是目前国内最贵的模型，相比前代K2.6的涨价幅度如下： - 输入侧：缓存未命中的输入价格从6.5元/百万token涨到20元/百万token，涨幅约207.7%；缓存命中的输入价格从1.1元/百万token涨到2元/百万token，涨幅约81.8%。
输出侧：输出价格从27元/百万token涨到100元/百万token，涨幅约270.4%，也就是涨了超3.7倍。
横向对比来看，它的定价仍远低于Claude Fable 5等海外顶级闭源模型，仅为其约三分之一的价格。
二、Dynamic Workflows 实验介绍
在公众号文章 Dynamic Workflows 工程化实践（下）：PM视角实战指南 中介绍了开源实验项目phuryn/dynamic-workflows-experiment，以它为案例演示一个可复现、可验证、可沉淀为团队技能的产品发现工作流。phuryn/dynamic-workflows-experiment是 Product Compass 文章的配套实验，它要验证的论点是：
动态工作流的价值不在于单次扇出并行（那用普通 subagent 就够了），而在于"上一阶段的输出决定下一阶段"的多阶段编排。
实验虚构了一个产品Reelay：一个流媒体聚合器，目标是成为"今晚看什么"的决策层。
为了让结果可验证，作者用了**合成数据 + 答案钥匙（answer key）**的设计：
- 先在
ground-truth/answer-key.md里预埋8 个已知机会点和目标分数； - 按 5 种 persona、每人 2–3 个预埋痛点，生成 100 份 600–900 字的访谈稿；痛点只以故事形式出现，绝不出现"opportunity / feature / pain point"等标签词；
- 盲跑分析工作流，不喂答案钥匙，看它能否还原预埋排名。
任务书根据 100 份访谈 生成 3 个 HTML 原型。为此设计 harness 六阶段流水线：
100 份访谈 → Extract（每份一个 agent，抽取机会点：slug / persona / 引述 / 三个 1-5 分） → Canonicalize（一个 agent 把同义 slug 聚成 6-10 个规范需求——先做归并再计数） → Score（纯代码，无模型：频次 × 重要性 × (5 − 满意度)） → Ideate（前 5 名各由 agent 提 3 个方案） → Triage（独立 judge 按 ROI 三角测量出前 3） → Build（agent 用 frontend-design skill 为 3 个赢家各写一个静态 HTML 原型） → Loop（低置信度抽取换更强模型重跑；渲染不出来的原型重建）
关键设计对抗式质量控制：方案由生成 agent 和独立评审 judge 分开完成；置信度低于 0.6 的提取自动升级模型重试。
三、K3模型的运行结果
运行总结：
运行日期：2026-07-19
工作流文件：discovery-harness.js
输入：./interviews目录下的 20 份访谈记录（001.md–020.md）
机会排名
| 排名 | 机会 slug | 描述 | 出现访谈数 | 频率 | 重要性 | 满意度 | 得分 |
|---|---|---|---|---|---|---|---|
| 1 | decide-what-to-watch | 克服选择疲劳和决策瘫痪，快速决定要观看的内容 | 19 | 4.03 | 4.30 | 1.50 | 60.70 |
| 2 | subscription-overload | 管理多个流媒体订阅：不清楚哪个平台有哪个节目、费用与使用可见性、取消麻烦、共享账号、以及统一的跨平台搜索/发现/想看清单 | 20 | 3.24 | 3.92 | 1.79 | 40.75 |
| 3 | co-watching | 与家人或远程朋友协调共同观看，包括安排、同步和决定一起看什么 | 9 | 3.20 | 3.80 | 1.80 | 38.91 |
| 4 | parental-controls | 将孩子限制在适龄的安全档案中，并保持家庭成员档案之间的清晰边界 | 4 | 2.40 | 4.60 | 1.60 | 37.54 |
| 5 | cross-device-resume | 跨设备/跨服务保持播放连续性、观看历史和进度，包括续播、间隔后的回顾、手机与电视之间的搜索状态接力 | 12 | 3.00 | 3.60 | 1.87 | 33.84 |
| 6 | new-release-tracking | 追踪关注剧集的新季/新集发布状态，并及时提醒，避免错过 | 4 | 2.75 | 3.25 | 2.00 | 26.81 |
| 7 | social-recommendations | 收集、保存并信任来自朋友/家人的推荐，并知道推荐内容在哪里可看 | 8 | 2.75 | 3.38 | 2.13 | 26.68 |
与 ground truth 对比
预期前三名机会为decide-what-to-watch、subscription-overload、cross-device-resume。本次运行结果：
decide-what-to-watch排名第 1subscription-overload排名第 2cross-device-resume总体排名第 5，但仍被 judge 选为TOP 3 获胜原型之一。
前三名获胜原型
| 对应机会 | 方案 | 描述 | 输出文件 |
|---|---|---|---|
decide-what-to-watch | Vibe Check | 根据用户当下的心情/能量，快速将所有已连接平台的片源收窄为一小组可立即播放的推荐。 | outputs/vibe-check.html |
subscription-overload | Universal Watchlist & Availability Router | 统一的跨服务想看清单，显示每部内容当前在哪个平台播放、价格、是否即将下架，并一键跳转到对应应用。 | outputs/universal-watchlist-availability-router.html |
cross-device-resume | Continue Watching Sync | 统一的跨服务进度层，记录用户在任意剧集/电影上离开的位置，并可在任意设备或已连接服务上即时续播。 | outputs/continue-watching-sync.html |
三个原型均为独立的静态 HTML 文件，使用内联 CSS/JS，无外部依赖。每个构建 agent 在保存后都会回读文件并确认renders: true。
运行诊断
| 指标 | 数值 |
|---|---|
| 处理的访谈数 | 20 |
| 首次运行 token | 约 496,000 |
| 重试 token | 约 140,000 |
| 工作流总 token | 约 636,000 |
| 首次运行状态 | 已完成，但最后验证/重建 agent 遇到 API 用量限制。 |
| 重试状态 | 成功完成；一次构建尝试被安全分类器拦截，第二次尝试成功重建。 |
| 残留文件清理 | 已删除首次运行遗留的outputs/reelay-picks.html，使输出目录与最终 TOP 3 保持一致。 |
注意
- 运行时间进11分钟
- 花费 tokens 496 K
四、另一模型的运行结果
运行总结：
注意
- 运行时间进41分钟
- 花费 tokens 2.53 K
与 K3 对比
（1）花费时间约是 K3 的4倍
（2）花费 tokens约是 K3 的5倍
五、生成 html 效果对比
K3 Universal Watchlist & Availability Router:
另一模型：
K3 Cost-Per-Watch Nudges:
另一模型：
K3 Cost-Per-Watch Nudges:
另一模型：
可以看出：K3 的 html 输出效果更好。
六、结论
Kimi K3 作为编程与 Agent在 Arena.AI 前端代码榜单第一模型，对复杂任务完成的效果远远超出了国内另一先进模型。
（1）更好：花费时间约是 K3 的4倍
（2）更省：花费 tokens约是 K3 的5倍
（3）更好：生成 html 更美观、功能更强
K3 跑完才发现，另一模型可能没有很好完成 harness ，好像没有与 ground-truth 对比环节。这才是关键。
