Cursor Composer 2.5实测：用20轮长任务逼出"sustained work"的真实边界

第12轮。

旧版本的Cursor Composer正在重新定义一个函数——parseApiResponse()——它自己在第9轮刚写完的那个。

我盯着屏幕，没有愤怒，只有一种见怪不怪的疲惫。这种感觉相信每一个用过Composer做长任务的人都经历过：模型像一条记忆只有7秒的金鱼，在你精心搭建的上下文里游来游去，然后开始重新发明轮子。

Cursor Composer 2.5的发布，官方主打的卖点是"sustained work"——持续工作能力。但这个词到底是什么意思？是上下文窗口变大了？是中途不再掉链子？还是只是一个让人感觉良好的PR词汇？

我决定认真测一次。

---

为什么这次测试值得认真对待

Composer 2.5的核心变化是底层模型换成了Kimi K2.5。这不是小改动。Kimi K2.5是月之暗面针对代码和长文本场景专门优化的模型，上下文窗口相比前代有显著扩展，官方公布的代码能力基准分在多个评测集上有提升。

但基准分是基准分，工作流是工作流。一个模型在HumanEval上拿高分，不代表它能在第18轮对话里还记得你第2轮定义的架构决策。

所以"sustained work"这个卖点，我需要在真实工作场景里验证：

• 它是上下文保持力的提升？ 跑到第N轮，模型还记不记得前面的决策？
• 它是稳定性的提升？ 前5轮和后15轮的输出质量有没有衰减？
• 还是纯粹是营销语言？ 换个底层模型，感知差异接近于零？

---

测试设计：我怎么让结果可信

我最怕的是"感觉好了"式的评测——换了版本，心理预期不同，所有东西都觉得更好。所以这次测试的设计原则是：同一批任务，同一套评估维度，新旧版本交叉跑。

测试任务清单

我选了三类代表性任务，覆盖不同的长任务挑战：

一个真实的Python后端项目，混杂着三年前的写法和后来打补丁的逻辑，函数命名不一致，注释稀少。目标是在保持功能不变的前提下，完成模块化重构。预计需要15-20轮对话。

把一套REST API从v1升级到v2，涉及5个文件的联动修改：路由定义、请求处理、数据验证、错误处理、测试用例。每一轮修改都要求模型记住前面已经改过的文件状态，不能重复修改或遗漏。

一个复现概率约30%的竞态条件bug，需要通过多轮假设-验证-排除的方式逼近根因。这类任务对"记忆"的要求最高——每一轮的排除结论都必须被后续轮次记住，否则会原地打转。

评估维度

每个任务从三个维度打分（1-5分，主观但标准固定）：

• 上下文保持力：第N轮时，模型是否还记得前面的关键决策（函数签名、架构选择、已排除的假设）
• 中途崩溃率：出现幻觉、重复造轮子、"忘记"已有代码的频率
• 输出质量稳定性：前5轮和后15轮的输出质量是否有明显衰减

---

逐项对比结果

任务一：遗留代码重构

# 第18轮输出片段
注意：这里复用了第2轮定义的 normalize_field() 函数
而不是重新实现，保持与 DataSchema 的一致性

def process_legacy_record(record: dict) -> ProcessedRecord:
normalized = normalize_field(record.get('raw_data', ''))
return ProcessedRecord(
id=record['id'],
data=normalized,
schema_version=DataSchema.V2  # 第5轮确认的版本号
)

这段代码里的注释不是我要求加的——模型自己标注了"复用了第2轮定义的函数"，说明它确实在追踪对话历史中的关键决策节点。

任务二：跨文件API修改

这个任务的核心挑战是跨文件状态追踪——模型需要记住"这个文件已经改过了，那个文件还没动"。

旧版本在这里的崩溃方式很有规律：它会在第8-10轮重新"发现"某个文件需要修改，但实际上那个文件在第3轮就已经处理完了。更糟糕的是，有一次它给出了和第3轮修改相矛盾的方案，如果直接采纳会导致代码冲突。

新版本的表现好很多，但有一个有趣的边界条件：当我在对话中途切换了叙述风格（从中文提问切换到英文提问），它的跨文件追踪能力出现了短暂的混乱——在第11轮遗漏了一个之前已经确认要修改的端点。恢复中文提问后，下一轮又回到正轨。

这个细节很重要：Kimi K2.5对中文上下文的处理似乎比英文更稳定。对于主要用中文工作的开发者来说，这是一个实质性的优势。

任务三：20轮bug定位

这是三个任务里新版本优势最不明显的一个。

原因在于：bug定位任务的核心不只是"记住"，还需要推理链的连贯性。每一轮的假设和排除，需要形成一个逻辑完整的探索树。

旧版本的问题是"忘记"——第8轮排除的假设，第14轮又重新提出来。新版本基本解决了这个问题，但出现了另一个模式：过度自信。它在第12轮给出了一个听起来很确定的根因分析，但这个分析实际上是基于不完整的信息——它忽略了第7轮我提到的一个关键细节（竞态条件只在高并发场景下出现）。

旧版本的问题是记忆力，新版本的问题是判断力。很难说哪个更好处理。

---

"sustained work"，这个卖点到底成立吗？

综合三个任务的结果，我的判断是：

"sustained work"是真实的，但它的成立条件比官方说的要窄。

---

给不同层级用户的使用建议

如果你是刚开始用Cursor的用户

先搞清楚Composer模式怎么开：在Cursor里按 Cmd+Shift+I（Mac）或 Ctrl+Shift+I（Windows）进入Composer，然后在设置里确认底层模型已经切换到2.5版本。

如果你是进阶用户

最大化"sustained work"优势的关键，不是模型，是你的任务设计方式。

几个实测有效的做法：

• 在对话开头用一个结构化的"上下文锚点"：列出关键决策、已确认的函数签名、不能改动的约束。每隔5-7轮重新粘贴一次这个锚点，帮助模型"刷新记忆"。
• 把跨文件任务拆成明确的阶段：不要让模型同时追踪5个文件的状态，每次聚焦1-2个文件，完成后明确告诉它"这个文件已完成，接下来处理下一个"。
• 对推理型任务（bug定位）保持主动质疑：新版本的过度自信是个陷阱，每次它给出"根因"时，追问它"你是否考虑了第X轮提到的Y条件"。

---

如果你想跳过Cursor订阅，直接测Kimi K2.5

Cursor是个很好的套壳产品，但它的问题是你无法控制每一轮的system prompt——这意味着你的测试结果很难复现，也很难排除Cursor本身的处理逻辑对结果的影响。

如果你想做更干净的长任务测试，可以通过 [api.884819.xyz](https://api.884819.xyz) 直接调用Kimi K2.5的API。这样你能完全掌控每一轮的上下文注入方式，测试结果更可信，也更容易找到你自己工作流的最优配置。国产模型在平台上完全免费，没有月租，注册即送体验token，适合先跑一批任务感受一下再决定要不要深度集成。

---

带走一个判断框架，而不是一个结论

我不想给你一个"值不值得升级"的简单答案，因为这个问题的答案取决于你的任务类型。

用这三个问题来判断"sustained work"对你是否成立：

1. 你的典型任务轮次超过10轮吗？ 不超过，升级感知差异不大。

2. 你的任务有明确的状态边界吗？ 有（文件边界、函数边界），新版本优势明显。没有（开放式探索），优势打折。

3. 你主要用中文工作吗？ 是，Kimi K2.5底层有额外加成。否，优势缩水。

三个问题都是"是"，升级毫不犹豫。两个"是"，升级大概率值得。一个或零个"是"，可以等下一个版本。

---

这次测试让我意识到一个更底层的问题：Composer这类工具的上限，其实是被你的任务拆分方式卡住的，不是被模型卡住的。

模型的上下文窗口再大，如果你把一个本质上需要分阶段推进的任务塞进一个连续对话里，质量衰减是必然的。

下一篇我想聊聊：同样是让AI做长任务，"一个大prompt扔进去"和"用工作流编排拆成小步骤"，实际完成质量差多少——我已经跑完数据了，结果出乎我的预料。

---

#Cursor #AI编程 #Kimi K2.5 #代码工具 #AI测评 #8848AI #开发者工具 #长上下文