跳转至

Kimi K3 实测：半天复刻录屏工具

Ch09.077 Kimi K3 实测：半天复刻录屏工具

📊 Level ⭐⭐ | 9.8KB | entities/kimi-k3实测把一个29美元月的录屏工具半天复刻成免费mac-app.md

Kimi K3 实测：半天复刻录屏工具

v×c score: 56 | stars=4 来源: https://mp.weixin.qq.com/s/S9L601L6j54ZvHAcuLr3Bg 发布: 花叔 (2026-07-17)

摘要

开发者使用 Kimi K3（Kimi Code 的内置模型）在不到一天的时间内完成了一个原生 macOS 录屏 App（HuaStudio）的全流程开发，从零到提交苹果审核。该 App 对标月费 29 美元的 ScreenStudio 录屏工具，实现了自动运镜、鼠标轨迹跟踪、壁纸背景、摄像头浮窗、时间轴剪辑等核心功能，最终 27 个文件、七千多行代码。Kimi K3 展现了接近 Opus 4.8 的编程手感，尤其在规划能力、长程执行能力和自我调试能力上表现突出，但也存在偶尔需要返工、输出速度较慢的不足。

核心要点

  • 项目规模：27 个文件、七千多行代码的原生 macOS App，从零到提交苹果审核不足一天
  • 对标产品：ScreenStudio（月费 29 美元的专业录屏工具）——可自动剪辑、运镜、重绘鼠标轨迹、添加壁纸背景
  • 系统级开发：原生 macOS App 需要直接操作屏幕捕获、鼠标事件、实时视频合成等底层系统 API，无法依赖浏览器沙箱保护
  • 规划能力：K3 能够将大目标自主拆解为一串里程碑，从最小可运行闭环（录→停→存）逐步叠加差异化功能
  • 自我调试能力：遇到原生 mac 开发的"暗坑"（如窗口关闭后 App 自杀、光标与画面时间不对齐），K3 能自己看报错、查日志、改方案、再跑一遍
  • "许愿式优化"：开发者随口说"把导出效率提升 200%"，K3 自主制定方案并分步实施，最终让导出速度显著提升

深度分析

1. 从"网页/插件"到"原生系统级 App"——AI 编程能力的重要跨越

这不仅仅是一个开发速度的案例，更是一个能力维度的跃迁。大部分 AI 编程工具的演示案例集中在 Web 应用、脚本、前端组件等"沙箱友好"的场景——这些场景有浏览器兜底，API 调用相对标准化，错误处理空间大。

而原生 macOS App 开发完全不同：

  • 直接与操作系统底层打交道（Core Graphics、AVFoundation、屏幕捕获）
  • 每一个系统调用都需要精确的时序和资源管理
  • 调试复杂：崩溃可能发生在编译时、运行时或系统级
  • 合规要求：提交苹果审核需要满足 App Store 的严格规范

作者此前用 Fable 5 + Claude Code 做过一个浏览器插件版录屏工具——只能在 Chrome 标签页内录制。从浏览器插件到原生 macOS App，"把地基整个换掉"的重构难度远高于新建一个 Web 应用。K3 能完成这个跨越，说明它在系统编程和底层 API 使用上具备了接近人类中级开发者的能力。

2. 规划 + 长程执行 —— 当前 AI 编程模型的核心分水岭

文章中最有价值的观察是 K3 的规划能力和长程执行能力。这两项能力正在成为 AI 编程模型的分水岭：

维度 基础模型（Sonnet 级别） 高级模型（K3/Opus 4.8 级别）
单函数/单文件生成 ✅ 可靠 ✅ 可靠
跨文件理解 ⚠️ 有限 ✅ 全面的工程感知
自主任务拆解 ❌ 需人工指导 ✅ 自主拆解里程碑
长程状态维护 ❌ 容易丢上下文 ✅ 维护任务清单
自我调试纠错 ❌ 需人类提示 ✅ 自主看日志改方案
模糊需求澄清 ❌ 仅按指令执行 ✅ 引导用户明确需求

K3 的任务清单自维护能力尤为重要：它在一个 7000+ 行、27 个文件的项目中能准确知道"现在该改哪个文件、这个改动会牵动哪里"。这种工程态感知（Engineering State Awareness）是当前评测基准（如 SWE-bench、HumanEval）难以充分测量的。

3. "许愿式编程"的人机协作新模式

"导出效率提升 200%"这段描述揭示了一种新的人机协作模式：开发者不再需要给出精确的技术方案，而是表达意图和期望标准，由模型自主完成目标分解和执行。

这与传统 AI 编程的"指令式协作"（"在第 42 行添加一个异常处理"）有本质区别：

传统模式：开发者 → 精确指令 → 模型执行 → 开发者验证
许愿模式：开发者 → 模糊目标 → 模型规划+执行 → 模型验证+报告 → 开发者验收

"许愿式编程"的有效性取决于两个前提：① 模型具备自主规划和执行能力（K3/Opus 4.8 级别）；② 开发者具备判断"好结果"的领域知识。两者缺一不可。

4. 与 Opus 4.8 的竞争力对比

文章将 K3 的体验定位为"两个月前 Fable 5 还没出来、天天用 Claude Code 配 Opus 4.8 的手感"——这是一个精确但含蓄的评价。具体来说：

  • K3 生成 27 文件/7K 行代码的项目一次成功，接近 Opus 4.8 的产出质量
  • 返工率比 Fable 5 稍高（"比用 Fable 5 的时候多一些"），需要更明确的指令表达
  • 输出速度偏慢（"简单问题也要想半天"），但如果开启 max 思考强度则质量更高
  • 定价（输入 $3/输出 $15 每百万 token）与 Claude Sonnet 完全一致，性价比优势显著

关键差异在于：K3 的总参数量号称 2.8T——"这是开源模型的尺寸之最"。大规模 MoE 架构带来的知识与能力密度优势在复杂编程任务中得到了实证验证。

实践启示

  1. AI 编程能力的下一个评估维度是"原生系统级任务"：Web App 开发已成为 AI 编程的基线能力。真正区分模型优劣的测试场景应该包括：系统级 API 调用、多文件工程重构、长程任务自主规划。SWE-bench 等基准正在往这个方向演进，但实际的项目级开发评测（如本文的完整 App 构建）更具说服力。

  2. 分阶段构建是 AI 主导开发的有效策略：作者要求 K3"每做完一个阶段，能编译能跑起来，再进下一步"——这种迭代式构建降低了一次性生成的复杂度，也让错误能在早期被发现和修复。对于复杂项目，这个策略可以复制。

  3. 模型的能力上限 = 开发者的上限：作者能完成一个原生 macOS App，不仅因为 K3 强，更因为作者有产品判断力（知道 ScreenStudio 好在哪里）、领域知识（macOS 开发的坑在哪里）和验收能力（导出效率提升 200% 是否真的实现了）。模型越强，判断者的价值越大。

  4. "返工率"比"首遍通过率"更能衡量模型的实际可用性：K3 偶尔需要多轮修正才能得到正确结果，但只要修正成本低（模型能理解问题并主动调整），整体的实际效率仍然很高。评估 AI 编程工具时，应该测量"端到端耗时（从需求到可运行）"而非"首遍生成通过率"。

  5. AI 编程的"工具链集成"体验比模型本身更重要：作者在 FanBox 中挂载 Kimi Code 作为 Agent 使用，而非在网页版 Chat 中对话——Agent 模式的"自主执行 + 实时反馈"循环是高效产出的关键。模型的编程能力需要通过好的 Agent 框架才能充分释放。

相关实体

  • Kimi K3 的行业影响力分析
  • Kimi Attention 残差架构
  • Claude Code vs Kimi vs MiniMax 编程对比
  • GPT-5.6 Sol 编程能力
  • Sol vs Fable 编程对比
  • Model vs Harness 能力框架
  • Fable 5 实战案例
  • AI Native 开发工作流

→ 原文存档