Kimi K2.7 Code 五题实测：模型评测最该看的不是谁赢，而是谁真的完成了任务

这条视频表面是在问一个很热闹的问题：Kimi K2.7 Code 到底是不是 K2.6 的“套皮升级”？作者拿 5 道题做对比，粒子动画、刚体物理、软体交互、UI 设计、代码 review 全部上场，记录质量分、token、运行时间和成本。最后结论也很清楚：K2.7 Code 赢了，质量总分约 153.5，对 K2.6 的 79，差距 74.5；但赢得并不碾压，速度慢了很多，成本也更高。

但这条视频真正值得深扒的地方，不是“K2.7 赢了”这个结论。模型发新版时，网上最容易出现两种低质量判断：一种是看官方 benchmark，直接相信“涨了多少点”；另一种是随手丢两三个 prompt，凭主观感觉喊“变强了”或“套皮”。这条视频好在它给了第三种做法：把模型放进可运行、可验收、可比较的任务里，让模型自己暴露“完成任务”和“看起来像完成任务”的差别。

五道题里最有价值的不是分数，而是失败形态。K2.6 有几次速度很快，但快到只交了空壳、黑屏、没反应；K2.7 往往会花更久时间做验证和迭代，但也会出现“车还没碰上就触发碰撞”“做了窗户却没做窗帘”“UI 细节像 AI 生成”的问题。这里面有一个很关键的判断：AI 编程能力不能只看输出代码，也不能只看最终截图，要看它是否理解了验收条件，是否能用运行结果反查自己的实现，是否愿意为质量付出时间和 token。

所以这条视频对我们最有用的，不是它替 Kimi 打了多少分，而是它示范了一个可以迁移的模型评测框架：选任务要覆盖不同能力，评价要区分“可运行”和“符合题意”，结论要同时看质量、时间、token、成本，最后还要承认不同场景下“值不值”没有统一答案。

一、视频讲了什么：用五道题把“升级”从口号拉回验收

作者开场先交代背景：自己做了多期 AI 挑战，Kimi 多次上场，也拿过冠军；Kimi K2.7 Code 发布后，他要对比 K2.7 Code 和 K2.6，看看是真升级还是 PPT 升级。这个开场很有效，因为它没有从官方宣传开始，而是从“我拿同一套实战题测一下”开始。

测试规则也比较明确：5 道题，两个模型同台，记录质量得分、token 消耗、运行时间。题目覆盖粒子、物理、软体、设计、代码 review。这个组合比单一 benchmark 更接近真实使用，因为工程场景里模型不是只会解算法题就够了。前端动画考验模型的视觉目标拆解和浏览器运行能力；物理题考验三维建模和行为逻辑；UI 题考验审美与布局；代码 review 则考验静态分析、项目理解和 bug 判断。

第一题是信封燃烧粒子和形变。K2.6 很快出结果，但运行失败黑屏，直接归零。K2.7 用了 21 分钟，耗时接近 9 倍，却完整跑通：火焰分层、燃烧前沿不规则推进、纸张焦化和变黑、最后消失。它也有瑕疵，比如灰烬逻辑不够合理，但至少完成了核心任务。这里的核心不是“慢模型更好”，而是“快但黑屏没有任何生产价值”。

第二题是两车相撞。K2.6 秒级交付，却只交了空壳，看不到车，按钮也没有有效反应。K2.7 能看到车，能运行，有慢动作和粒子，但碰撞逻辑错了：距离还很远就触发碰撞，车身形变也没有做。这个案例特别有教育意义，因为它不是完全失败，而是假完成。真正做验收的人不能只看“有车、有按钮、有粒子”，还要看核心物理事件是否成立。

第三题是风吹窗帘，软体物理加鼠标交互。K2.6 做出了窗帘，但物理和交互不够完整；K2.7 做出了背景、窗户、挂环等周边元素，却漏掉了最关键的窗帘。这个失败很典型：模型把“场景相关元素”做得热闹，却丢掉题目主语。对工程任务来说，这叫需求中心偏移。它不是不会写代码，而是没有牢牢抓住验收目标。

第四题是 iOS 29 UI 概念，要求桌面端和移动端两个形态。K2.6 做出完整 UI，但不像目标风格，布局处理也一般；K2.7 更精致一些，但用了 emoji，状态栏和页面细节仍有明显 AI 味。这个题告诉我们，UI 评测不能只看“页面有没有做出来”，还要看风格一致性、细节可信度、响应式布局和审美约束。模型越会生成完整页面，越容易用完整性掩盖审美偏差。

第五题是代码 review。这里的看点不是谁多找了几个问题，而是作者用了自己熟悉的项目和已知 bug 清单做核对。口播里出现了不同口径：有“找到几个真实问题”的数量比较，也有“严格评分接近平手”的结论。我们不需要死抠某个数字，关键是这个题把模型从“写 demo”拉到了“读真实项目”。真实项目 review 的难点在于，模型要分辨真正 bug、潜在风险、风格建议和幻觉报告，这比写一个 isolated demo 更接近生产。

最终数据形成了一个矛盾但真实的结论：K2.7 Code 质量明显领先，K2.6 有三道题翻车；但 K2.7 的总耗时约 47 分 03 秒，K2.6 约 10 分 43 秒，K2.6 快 4.4 倍；token 上 K2.7 约 298.6K，K2.6 约 288.9K，多 3.4%；成本上 K2.7 约 1.45 美元，K2.6 约 0.98 美元，贵约 48%。这正是模型评测最该呈现的复杂性：更高质量并不自动等于更高性价比，具体要看你买的是时间、质量、稳定性，还是便宜试错。

二、7 段文案拆解

【1】开头钩子：反常识问题 + 新模型热度 + 实测承诺

这条视频的钩子类型是“热点 + 质疑 + 数字化实测”。“Kimi K2.7 Code 算是 2.6 套皮吗？”这句话比“新版 Kimi 发布了”更抓人，因为它直接把观众带进争议：到底是真升级，还是换个名字继续卖？短视频里，争议不是为了吵架，而是为了让观众知道接下来会有一个判断。

前 3 秒的底层逻辑是反官方宣传。模型厂商会说 benchmark 涨了多少，用户真正关心的是“我拿来干活会不会更强”。作者没有空谈，而是立刻给出“五道题实测”。这个数字很重要：一道题太随意，十几道题太重，五道题刚好让观众觉得有覆盖面，又能在 4 分多钟内看完。

钩子评分可以给 4.5 星。它不靠情绪爆破，不是“震惊全网”，而是非常垂直精准：关注 Kimi、AI 编程、模型评测的人，会立刻想看结果。更高明的是，作者并没有预设结论，而是把悬念留给过程：“到底是真升级还是 PPT 升级”。这让后面的分题展示有了叙事张力。

【2】人设与声音：技术挑战型裁判，带一点赛博斗蛐蛐的口吻

博主人设很清楚：不是官方测评员，也不是纯娱乐博主，而是“技术挑战型裁判”。他有连续做 AI 挑战的历史，有自己的评分体系，也有真实项目拿来做 review。这给视频建立了可信度。观众不一定完全同意他的评分，但会相信他不是随便丢 prompt 玩一下。

声音风格是高语速、高密度、带吐槽。比如“少说废话，直接开始挑战”“翻车了”“假碰撞是致命 bug”“除了窗帘都做出来了，甚至挂窗帘的环都有，就是没窗帘”。这些句子不是单纯搞笑，它们把技术失败翻译成普通观众能立刻理解的画面。黑屏就是零分，车没碰上就爆炸是假碰撞，窗帘题没有窗帘就是需求偏移。

这个声音适合的受众是 AI 编程用户、模型观察者、技术内容消费者、喜欢看模型对战的人。它不适合想看严肃论文式评测的人，但适合抖音场景：要快，要有结论，要看得见失败。

可借鉴的语言习惯是“先给裁判视角，再给具体证据”。作者不是只说“这题 K2.7 好”，而是说火焰分层、燃烧前沿、焦化阶段、灰烬逻辑；不是只说“两车相撞不行”，而是指出距离很远就触发碰撞、车身形变没做。短视频技术测评要有吐槽，但吐槽必须落在可见证据上。

【3】信息密度与节奏：一题一个小高潮，结尾用四维数据收束

视频总时长约 284 秒，信息密度高。它的节奏不是平均叙述，而是每道题都重复一个可预测结构：题目说明、K2.6 表现、K2.7 表现、关键点评。这个结构让观众很快进入节奏，因为每一题都像一场小比赛。

0 到 34 秒是规则段，快速建立测试背景和评价维度。35 到 72 秒是第一题，用 K2.6 黑屏和 K2.7 跑通形成强烈对比，第一轮就把“速度不等于质量”的主题打出来。73 到 125 秒是第二、第三题，重点从“能不能运行”升级到“有没有满足核心需求”：车能显示但碰撞逻辑错，窗户有了但窗帘没了。126 到 179 秒是 UI 和代码 review，模型能力从可视 demo 转到设计判断和真实项目理解。

180 秒之后进入汇总段，质量、token、时间、成本依次出现。这个安排是对的：前面用案例让观众看到失败，后面用数据让观众记住结论。如果只上数据，会像表格；如果只上案例，会像主观吐槽。两者合在一起，才有“实测”的说服力。

节奏里有明显的“刺激 - 判断 - 再刺激”循环。每一道题都有一个可视失败或可视成功，然后作者给一句判断，再切下一题。留白时间不多，但这类内容本来面向高兴趣人群，观众愿意跟着跑。唯一风险是信息过密导致部分数字记不住，所以结尾总表非常必要。

【4】讲解手法与内容结构：不是跑 benchmark，而是跑验收场景

这条的内容结构可以概括为“争议问题 - 实测规则 - 分题对战 - 汇总指标 - 性价比判断 - 开放挑战”。它不是单纯 AIDA，也不是教程，而是一种比赛型评测结构。

最强的讲解手法是把“模型能力”具体化成验收场景。粒子题不是问“会不会写 Canvas”，而是看火焰形态、灰烬飘散、纸张形变；物理题不是问“会不会 Three.js”，而是看车是否真实相撞；软体题不是问“能不能生成窗户场景”，而是看窗帘是否受鼠标风力影响；UI 题不是问“有没有页面”，而是看风格、布局、移动端；review 题不是问“能不能列问题”，而是看问题是否真实存在。

这比普通模型评测更接近工作流。因为真实世界不会因为模型写了很多代码就买单，真实世界只问：功能跑了吗？核心需求满足了吗？异常处理了吗？细节像不像人做的？成本和时间值不值？

最有说服力的不是某个分数，而是“假完成”的识别。K2.7 在第二题有车、有粒子、有慢动作，但碰撞逻辑错；第三题有窗户、有挂环，却没有窗帘。这种失败比黑屏更危险，因为它容易骗过只看截图的人。作者把这种失败指出来，说明他的评分不是单纯看表面完整度。

【5】金句与记忆点：技术吐槽要能变成验收标准

这条里最容易被记住的句子，不是官方数据，而是几句带画面感的技术吐槽。

第一句是“真升级还是 PPT 升级”。这是模型发布测评的通用问题模板，适合所有新模型、新工具、新功能。

第二句是“速度很快，但是黑屏”。这句话可以变成工程判断：无效交付再快也没有价值。模型评测不能把运行时间和成功率割裂看。

第三句是“车还没碰上就碰撞了”。这句话代表另一类验收：界面元素齐全不等于行为逻辑正确。

第四句是“除了窗帘都做出来了，就是没窗帘”。这是需求中心偏移的经典表达。模型很会补全上下文，但有时会把主需求丢掉。

可复用金句模板可以写成：不要问模型有没有交付一个“像答案的东西”，要问它有没有命中题目的不可替代核心。黑屏是显性失败，假碰撞、假交互、假 UI、假 review 是隐性失败。真正的评测要优先抓隐性失败。

画面记忆点也清晰：黑屏、燃烧信封、两车未撞先爆、缺失窗帘、iOS 风格页面、代码 review 数据表。这些画面让观众不用理解全部技术细节，也能感知模型差距。

【6】收尾与 CTA：把模型对战变成连续挑战

结尾的 CTA 是关注账号，并让观众在评论区提供更难的 AI 挑战。这个 CTA 和内容主体衔接顺，因为视频本身就是挑战赛。观众看完自然会想：“那换更难的题会怎样？”“换别的模型会怎样？”“如果是我工作里的任务，会不会翻车？”

它不是硬广式 CTA，而是内容机制的一部分。作者把账号定位成持续跑模型挑战的裁判，评论区给题就等于观众参与出卷。这样既能提高互动，也能降低后续选题成本。

沉锚设计在“赢得不算压倒性”和“值不值要看时间贵还是钱包贵”。这两个判断没有把结论说死，给评论区留下讨论空间。有人会说质量更重要，有人会说 47 分钟太慢，有人会说成本差距不大，有人会说真实工作流宁愿慢一点也要少返工。争议点就是互动点。

【7】可复制文案骨架

这条视频的骨架可以迁移到所有模型测评和工具升级评测里：

[开头钩子句 - 反常识/争议型]
某某新版本到底是真升级，还是换皮/PPT升级？

[核心信息 - 分 5 个测试场景]
① 先测一个基础可运行任务：看它是否真能跑通。
② 再测一个行为逻辑任务：看它是否只做表面。
③ 再测一个交互/复杂约束任务：看它是否抓住主需求。
④ 再测一个审美/产品任务：看它是否有细节可信度。
⑤ 最后测一个真实项目任务：看它是否能在复杂上下文里做判断。

[转折/高潮句]
它赢了，但不是每一项都赢；它更强，但也更慢、更贵。

[收尾 + CTA]
所以这次升级值不值，要看你买的是时间、质量还是便宜试错。评论区丢更难题，下一轮继续测。

适用场景：新模型发布测评、AI 编程工具评测、Agent 框架评测、设计工具升级评测、工作流自动化工具评测。最适合博主类型：技术挑战型、工程实测型、产品评审型。预估完播率中高，原因是每一题都有小胜负，结尾还有总表和争议结论。

三、这条真正可迁移的判断

第一，模型评测必须区分“跑得快”和“交付有效”。K2.6 多次很快，但黑屏、空壳、按钮无反应在生产里就是零。以后我们测任何 coding model，都不能只记生成时间，还要把“首次可运行率”“核心需求命中率”“需要人工修复次数”放进表格。

第二，验收要抓任务主语。窗帘题没有窗帘，哪怕窗户、挂环、背景都做得再完整，也不能算高分。真实业务里同理：用户要报名页，模型做了好看的首页但没有表单；用户要数据导入，模型做了 dashboard 但导入失败；用户要支付闭环，模型做了商品卡片但没有订单状态。这些都是主语丢失。

第三，最危险的失败不是黑屏，而是假完成。黑屏一眼能看出来，假碰撞、假交互、假数据、假 review 更容易混入交付。我们以后做自动验收，要重点设计“反表面完整度”的检查：元素在不在只是第一层，行为是否按条件触发才是第二层。

第四，代码 review 评测要用真实项目和已知答案。让模型随便 review 一个公开仓库，容易变成“谁更会讲风险”。拿自己熟悉的项目、带隐含 bug 清单、再人工核对，才知道模型是真的找到了问题，还是在输出通用建议。

第五，成本判断不能只看 token 单价。K2.7 贵约 48%，耗时也更久，但如果它能减少人工返工，在高价值任务里可能仍然划算；如果只是低风险草稿或批量探索，K2.6 这种快模型可能更适合。模型选型应该按任务风险分层，而不是全局选一个“最强模型”。

第六，官方 benchmark 只能当线索，不能当结论。Code Bench 涨了多少、thinking token 降了多少，都要落到具体任务里看。视频里“thinking token 降 30%”并不是五题全成立，这就提醒我们：模型宣传通常描述平均收益，真实工作流看的是分布、方差和失败模式。

四、四角度反思

1. 对我们做的事：自动学习不能只存结论，要存评测方法

如果我们只把这条归档成“K2.7 比 K2.6 强，但更慢更贵”，这个知识很快会过期。模型版本继续迭代，今天的胜负半年后可能没有意义。真正该存的是评测方法：五类任务覆盖、四类指标记录、失败形态分类、性价比按任务风险判断。

后续我们做自动学习归档，应该把“模型 A 赢了模型 B”降级为事实背景，把“怎么测出它赢、它在哪些地方是假完成、哪些指标互相冲突”升级为判断卡。知识库不该变成模型新闻数据库，而该变成可复用的评测与决策系统。

2. 对橙子自己能力：要从总结者升级成验收设计者

橙子不能满足于把视频转成文字、把结论整理成博客。更高一级的能力，是看完一个案例后能设计出自己的验收表。比如以后遇到 AI 编程任务，橙子应该主动问：这个任务的主语是什么？不可替代的核心行为是什么？有哪些假完成风险？需要截图、日志、单测、浏览器自动化还是人工核对？

这条视频也提醒橙子，视觉分析和逐字稿不能只用来复述。视觉轨看到黑屏、车距、窗帘缺失；音频轨听到作者的评分、吐槽和数据。两轨合并后，才能提炼“假完成比显性失败更危险”。这就是深扒和转写的区别。

3. 对老大机构业务：AI 交付要建立“验收项”，不是相信模型自报完成

机构业务里如果要把 AI 用到页面制作、课程资料、运营素材、代码脚本、数据分析，最大的风险不是模型不会做，而是它做了一个“看起来差不多”的半成品。销售页有版式但没有转化逻辑，学员工具有按钮但没有状态反馈，数据报表有图表但口径错，自动化脚本能跑一次但异常场景崩。

所以机构内部应该把 AI 交付拆成验收项：页面要检查关键 CTA、移动端、表单、加载状态；代码要检查核心路径、错误处理、日志、测试；内容要检查事实、受众、转化动作；设计要检查风格一致性和细节可信度。AI 可以加速生产，但不能替代验收标准。谁掌握验收，谁才真正掌握 AI 生产力。

4. 对未来发展：模型竞争会从“会写代码”转向“会自证结果”

K2.7 的一个亮点是它会用 headless Chrome 抓关键帧、多轮验证后再报告完成。虽然它仍然会犯错，但方向很重要：未来 coding model 的关键能力不是“生成更多代码”，而是“运行、观察、修复、再运行”。一个模型如果不能自证结果，就会把验证成本甩给人。

未来强模型和弱模型的差距，可能越来越体现在闭环能力上：能不能调用浏览器检查 UI，能不能跑测试，能不能读日志，能不能发现自己的输出与需求不一致，能不能在成本可控的情况下迭代。模型评测也要跟着升级，不能停留在“答案文本像不像”，而要测“它能否完成一条真实闭环”。

五、落地步骤：把这条变成自己的模型评测 SOP

第一步，先给任务分层。不要只测算法题或只测网页题，至少覆盖五类：可运行 demo、复杂行为逻辑、交互约束、审美/产品、真实项目理解。这样才能看到模型不同维度的短板。

第二步，给每题写不可替代验收点。信封燃烧的验收点不是“有火”，而是燃烧前沿、纸张形变、灰烬逻辑；两车相撞不是“有车”，而是接触时机、碰撞反馈、形变；窗帘题不是“有窗户”，而是窗帘和鼠标风力交互。

第三步，记录四类指标：质量、时间、token、成本。质量是主指标，时间和成本是约束指标。不要把快模型直接判赢，也不要把贵模型直接判输。

第四步，单独记录失败类型。建议至少分为：黑屏/不可运行、空壳/按钮无效、核心主语缺失、行为逻辑错误、审美风格偏差、review 幻觉、过度工程化导致耗时失控。失败类型比总分更有复用价值。

第五步，把结论写成任务选择建议。比如：高风险交付用更强但更慢的模型，低风险探索用快模型；UI 初稿可以用便宜模型，最终实现要用能自验证的模型；代码 review 必须配真实项目和人工核对，不要相信模型自报。

结论

这条视频最值得学的不是 Kimi K2.7 Code 比 K2.6 多赢了多少分，而是它让“模型升级”回到了工程验收。一个模型可以更慢、更贵，但如果它显著降低黑屏和空壳，它在高价值任务里就可能值得；一个模型可以更快、更省，但如果它频繁交付假完成，就只能放在低风险探索里。

对我们来说，真正的收获是三句话。第一，模型评测要看失败形态，不只看胜负。第二，AI 编程交付要抓核心需求，不要被表面完整度骗过。第三，未来最有价值的模型不是最会说“我完成了”的模型，而是最会运行、观察、修复并证明自己完成了的模型。

这才是“真升级”和“PPT 升级”的分界线：不是发布页上的数字，而是真任务里的闭环能力。