跑分榜单看多了人会麻木。SWE-bench 刷到 70% 又怎样真到了自己项目里一个跨文件重构就能让模型原形毕露。Step 5 Preview 发布那阵子我朋友圈里转发的全是 benchmark 截图但我更关心的是这玩意儿在我日常那种改一个函数、牵动三个模块的脏活里到底能不能扛住。所以这篇文章不聊榜单只聊我亲手跑的两个真实编程任务——一个是给一个中型 Python 项目做跨文件重构另一个是从零搭一个带视觉输入的小工具。全程记录包括它翻车的地方。先说清楚 Step 5 Preview 的几个关键标签方便你判断这篇内容跟你有没有关系。它是MoE 架构总参数量很大但每次推理只激活一部分专家这意味着它的响应速度和显存占用跟总参数不是线性关系它支持1M Token 上下文这个数字对编程任务的意义远大于对聊天任务的意义因为一个真实项目的代码库动辄几十万 token它还支持视觉输入也就是你可以直接丢截图、丢 UI 设计稿、丢报错弹窗进去。这三个特性组合起来决定了它适合什么场景、不适合什么场景。下面我用两个任务把这些特性一个个拆开验证。1. 为什么我选这两个任务而不是刷 LeetCode1.1 跑分任务和真实编程任务之间隔着一道鸿沟大部分模型评测用的编程题本质上是单文件、单函数、输入输出明确的封闭问题。你在一个文件里写一个solve()测试用例跑通就完事。但真实项目里代码是长这样的一个功能横跨models/、services/、api/三个目录改一个字段名要同步改数据库迁移、Pydantic schema、前端类型定义、以及三个地方的单元测试。这种任务的难点不在于算法而在于上下文关联和约束保持——你得同时记住十几个文件的现状还得保证改完之后没有一处遗漏。我选第一个任务就是因为它天然具备这种跨文件、多约束的特征。这是一个我维护了两年的内部数据处理项目大概 40 个 Python 文件核心逻辑是把上游的原始数据做清洗、聚合、再输出成报表。我要做的重构是把原来散落在各个 service 里的日期处理逻辑统一抽到一个date_utils模块里并且把原来用字符串传日期的接口全部改成datetime对象。这个任务听起来简单但它涉及 12 个文件的修改、3 处隐式的类型假设、以及一个我故意没告诉模型的坑——有个地方用了strftime的本地化格式直接改类型会静默出错。第二个任务我选了一个从零开始的小工具一个能读取截图、识别里面的表格、然后输出 CSV 的脚本。这个任务专门用来压测视觉输入能力。我会给它三种输入一张干净的 Excel 截图、一张手机拍的歪斜表格照片、一张带合并单元格的复杂报表截图。看它在不同质量输入下的表现差异。1.2 这两个任务分别压测什么能力第一个重构任务压测的是长上下文下的全局一致性。1M Token 的窗口意味着我可以把整个项目代码库塞进去但能塞进去和能用好是两回事。我要观察的是它会不会在改了 A 文件之后忘记 B 文件的约束它能不能主动发现我故意埋的那个strftime坑它给出的重构方案是最小改动还是推倒重来第二个视觉任务压测的是多模态输入的实际可用性。很多模型的视觉能力在描述图片内容上表现不错但一到从图片里提取结构化数据就拉胯。我要看的是它能不能准确识别表格的行列结构、能不能处理合并单元格、以及在图片质量下降时错误率怎么变化。这两个任务还有一个共同点它们都有明确的验收标准。重构任务的验收标准是所有测试通过 那个 strftime 坑被正确处理视觉任务的验收标准是输出的 CSV 和原始表格逐单元格对比。有明确标准才能客观评价而不是靠感觉还行。提示如果你也想测试一个模型在编程上的真实能力建议不要用 LeetCode 题。找一个你自己熟悉的、有测试覆盖的中型项目让它做一个你曾经亲手做过的重构。你心里有标准答案才能看出它到底行不行。2. 任务一跨文件重构的完整过程记录2.1 我是怎么把项目上下文喂进去的Step 5 Preview 支持 1M Token 上下文但我不建议你无脑全塞。我的做法是分三层组织输入第一层是项目结构说明我用tree命令输出目录结构然后手动标注了每个目录的职责第二层是核心文件全文我把涉及重构的 12 个文件完整贴进去没有做任何截断第三层是约束说明我用自然语言写清楚了重构目标、不能破坏的接口、以及测试命令。这里有个细节值得说我特意没有告诉它那个strftime坑的存在。我想看它能不能自己发现。如果它只是机械地把str改成datetime那这个坑就会在运行时才暴露。如果它能主动扫描所有日期相关的调用点发现有一处用了本地化格式那说明它是真的在理解代码而不是模式匹配。实际输入大概 8 万 token 左右远没有到 1M 的上限。但即使是 8 万 token我也能明显感觉到它在处理跨文件引用时的表现比小窗口模型稳。具体来说当它修改services/report_service.py里的一个函数签名时它会主动去检查api/routes.py里有没有调用这个函数并且同步更新调用处。这种改一处、查多处的行为在小窗口模型上经常需要你手动提醒。2.2 它给出的重构方案和我预期的差异我预期的方案是保守重构新建date_utils.py把重复的日期解析逻辑抽成parse_date()和format_date()两个函数然后逐个文件替换调用。但 Step 5 Preview 给出的方案更激进一些它不仅抽了工具函数还建议我把datetime的时区处理也一并规范化理由是你的项目里混用了 naive datetime 和 aware datetime这是未来 bug 的温床。这个建议本身是对的但它超出了我的重构范围。我当时的第一反应是这模型话太多但仔细想了想它其实是在做一件有价值的事识别技术债并主动提示。我最后采纳了它的部分建议——统一用 aware datetime但时区规范化的完整改造留到下一个迭代。这种模型提出建议、人来决定范围的协作模式我觉得比模型完全听话更有价值。不过它也有判断失误的地方。它建议我把date_utils放在utils/目录下但我的项目里utils/是放通用工具的日期处理属于业务逻辑应该放在core/下。这个错误说明它对项目约定的理解还是停留在表面——它能读懂代码但读不懂为什么这个项目这样组织代码。2.3 那个我故意埋的 strftime 坑它发现了吗答案是发现了但方式很惊险。它在生成重构方案的时候并没有主动提到这个坑。但在实际执行修改的过程中当它改到services/export_service.py这个文件时它停下来了输出了一段类似这样的话这个文件里有一处date.strftime(%Y年%m月%d日)的调用如果date从字符串变成datetime对象这个调用本身不会报错但输出格式会依赖系统 locale在非中文环境下会变成英文月份。建议显式指定 locale 或者改用固定格式。这正是我想看到的。它没有在方案阶段就发现说明它的全局扫描能力还有提升空间但它在执行到具体文件时发现了说明它的局部注意力是可靠的。这个差异其实反映了一个更深层的问题长上下文不等于全局理解。即使 1M token 全塞进去了模型在处理具体某个文件时注意力还是会聚焦在局部。所以我的经验是不要指望模型一次性发现所有跨文件的隐式问题你要给它逐文件执行的机会让它在每个文件上都有足够的注意力预算。2.4 重构完成后的测试结果和遗留问题最终结果是12 个文件全部修改完成测试套件 47 个用例通过了 45 个。失败的 2 个用例都跟时区有关——就是我前面提到的 naive/aware 混用问题。这其实印证了模型最初的建议是对的时区问题不解决重构就是留了个尾巴。我手动修了这 2 个用例整个过程大概花了 15 分钟。加上模型执行重构的时间大概 3 分钟整个任务从开始到完成不到 20 分钟。如果我自己手动做这个重构保守估计要 2 到 3 个小时。这个效率提升是实打实的。但有一个遗留问题值得警惕模型在修改过程中有一处把try/except块里的异常处理逻辑简化了。原来的代码是捕获ValueError和TypeError分别处理模型改成了统一捕获Exception。虽然测试通过了但这种过度简化在长期维护中是有风险的。我后来手动改回来了。这提醒我模型的重构倾向于让代码更短但更短不等于更好。你要在验收的时候特别关注这类顺手简化。3. 任务二视觉输入在表格识别上的真实表现3.1 三种不同质量的输入图片结果差异有多大我准备了三张图。第一张是用 Excel 直接截图导出的分辨率高、字体清晰、网格线完整。第二张是用手机拍的有轻微透视变形、光线不均、但内容可读。第三张是一张复杂的合并单元格报表有跨行跨列的标题、有嵌套的表头。第一张图Step 5 Preview 的表现几乎完美。它准确识别了 6 列 23 行数据输出的 CSV 逐单元格对比全部正确。我特意检查了几个容易出错的点数字里的千分位逗号、日期格式、以及一个空单元格的处理全部正确。第二张图准确率大概在 95% 左右。错误集中在两处一个是把0识别成了O另一个是把一个模糊的8识别成了6。这两个错误都是典型的 OCR 问题跟模型的视觉理解能力关系不大更多是图像质量问题。值得一提的是它在输出 CSV 的同时主动标注了以下单元格识别置信度较低建议人工复核并列出了具体位置。这个主动标注的行为很实用。第三张图也就是合并单元格那张表现明显下降。它把跨行的标题行重复填充到了每一行导致输出的 CSV 里出现了冗余数据。这个问题其实不是识别错误而是结构理解错误——它看懂了每个单元格的文字但没看懂这个单元格跨了 3 行这个结构信息。我后来在提示词里明确说了注意合并单元格跨行标题只保留在第一行它才改对。3.2 视觉输入和纯文本提示词配合时的注意事项这里有个我踩过的坑我一开始只给了图片没有给任何文字说明。结果它输出的 CSV 用了它自己猜的列名而不是图片里实际的列名。后来我加了一句CSV 的表头使用图片中第一行的实际文字它就改对了。这说明一个事视觉输入不是文字提示词的替代品而是补充。图片提供的是是什么文字提示词提供的是要什么。你只给图片模型只能猜你的意图你给了图片又给了明确的输出要求它才能准确执行。另一个注意事项是关于图片的分辨率。我测试下来如果图片的宽度低于 800 像素表格里的文字识别错误率会明显上升。建议在截图或拍照时保证表格区域的文字高度不低于 20 像素。如果是手机拍照尽量正对表格避免大角度倾斜。3.3 把视觉识别结果接入自动化流程的可行性我最终把这个脚本接到了一个半自动化的流程里每天定时扫描一个指定文件夹如果有新的表格截图就自动识别并输出 CSV然后发一封邮件通知我复核。这个流程跑了一周处理了大概 30 张图其中 28 张的识别结果可以直接用2 张需要人工修正。这个可用率让我觉得视觉输入在半自动化场景下是靠谱的但全自动化还不行。原因是当识别出错时模型自己不知道出错了。它输出的 CSV 看起来格式完整、内容合理但某个数字可能就是错的。如果你不人工复核错误就会静默传播。所以我的建议是视觉识别 人工复核是目前最务实的组合不要追求全自动。4. MoE 架构和 1M 上下文在实际使用中的体感4.1 MoE 架构对编程任务意味着什么MoE 架构的核心是每次推理只激活部分专家。对编程任务来说这意味着两件事第一响应速度比同等总参数量的稠密模型快第二不同任务可能激活不同的专家所以它在某些任务上表现特别好在另一些任务上可能一般。我的体感是在代码生成和重构这类任务上它的表现很稳定响应速度也快。但在需要深度推理的算法设计任务上比如设计一个分布式锁的实现方案它的表现就没有那么突出。这可能是因为算法设计需要激活更多推理型专家而代码生成更多依赖模式型专家。关于MoE 架构要全部参数进显存吗这个问题答案是不需要。MoE 的推理只需要加载被激活的专家参数所以显存占用远低于总参数量。但具体占用多少取决于每次激活几个专家、以及路由策略。这个细节对部署成本影响很大如果你是自己部署建议先查清楚具体的激活参数配置。4.2 1M 上下文在真实项目里的实际利用率我前面提到我的重构任务只用了 8 万 token。那 1M 上下文到底什么时候能用满我的经验是只有当你把整个代码库 完整文档 历史对话全部塞进去的时候才可能接近这个量级。但实际使用中塞得越多模型的注意力越分散反而不如精准投喂效果好。我的做法是用 1M 上下文做背景用精准投喂做任务。具体来说我会把项目结构、核心接口定义、编码规范这些背景信息一次性放进去然后在每个具体任务里只贴相关的几个文件。这样模型既有全局视野又不会被无关信息干扰。这个策略的效果很明显。当我只贴相关文件时模型的重构准确率明显高于全塞进去的情况。所以我的结论是1M 上下文的价值不在于能塞多少而在于能塞下完整的背景。你要把它当成工作记忆的扩展而不是信息垃圾桶。4.3 响应速度和成本的实际感受响应速度方面在 8 万 token 的上下文下它的首 token 延迟大概在 2 到 3 秒后续 token 的生成速度很快。整个重构任务的 12 个文件修改它用了大概 3 分钟完成。这个速度对我来说是可以接受的因为它比我手动做快太多了。成本方面我没有精确计算但体感是比预期便宜。MoE 架构的稀疏激活在这里帮了忙——虽然总参数量大但每次推理只激活一部分所以单位 token 的成本没有想象中那么高。如果你是按 token 计费建议先跑几个小任务估算一下成本再决定要不要用它做大规模重构。5. 两个任务跑下来我总结的几条实操经验5.1 提示词怎么写才能让模型少犯低级错误第一条经验明确输出格式。不管是重构还是视觉识别你都要在提示词里写清楚输出什么格式。比如重构任务我会说输出完整的修改后文件内容不要用 diff 格式视觉任务我会说输出标准 CSV表头用图片第一行文字。格式不明确模型就会自己猜猜错了你还得返工。第二条经验给出验收标准。我会在提示词里写修改后所有测试必须通过或者输出的 CSV 必须能直接被 pandas 读取。有了明确的验收标准模型在生成过程中会自我检查减少低级错误。第三条经验分步骤执行。不要一次性让它重构整个项目而是先分析、再给方案、再逐个文件执行。分步骤的好处是你可以在每一步之间介入纠正方向。我这次就是先让它给方案我确认后再让它执行避免了它跑偏。5.2 哪些任务适合交给它哪些最好自己动手适合交给它的任务跨文件的重构、重复性的代码修改、从截图提取结构化数据、生成测试用例、解释陌生代码库。这些任务的共同点是有明确的输入输出、有可验证的结果。最好自己动手的任务涉及核心业务逻辑的设计决策、需要跟产品需求对齐的架构调整、以及任何改错了后果很严重的地方。模型可以给你建议但最终决策要你自己做。还有一个我个人的原则任何模型生成的代码在合并到主分支之前我都要逐行看一遍。这不是不信任模型而是因为模型的错误往往是看起来对但实际错的类型你不逐行看根本发现不了。这次重构里那个try/except被简化的问题就是逐行看才发现的。5.3 关于视觉输入我踩过的三个坑第一个坑图片太模糊。我一开始用了一张压缩过的截图结果表格里的数字识别错了好几个。后来换成原图问题就没了。教训是视觉输入的质量直接决定输出质量不要在图片质量上省钱。第二个坑没有指定输出编码。我输出的 CSV 里有中文但没指定编码结果用 Excel 打开是乱码。后来在提示词里加了输出 UTF-8 编码的 CSV就正常了。这个坑很小但很烦人。第三个坑忽略了合并单元格。前面详细说过模型对合并单元格的结构理解不够好需要你在提示词里明确说明。如果你的表格有合并单元格一定要在提示词里写清楚跨行标题只保留在第一行或者合并单元格的值填充到所有子行。5.4 我对 Step 5 Preview 的整体评价用一句话总结它是一个靠谱的编程搭子但不是编程替身。它在跨文件重构和视觉识别这两个任务上的表现超出了我对预览版的预期。MoE 架构带来的速度优势、1M 上下文带来的全局视野、视觉输入带来的多模态能力这三个特性组合起来确实能解决一些以前很麻烦的问题。但它也有明显的边界它不理解项目约定、它倾向于过度简化、它在合并单元格这类结构理解上还不够好。这些边界意味着你不能完全放手你得在旁边盯着在关键节点介入。我后续还会继续用它做更多的任务特别是想试试它在读陌生代码库和生成测试用例这两个场景下的表现。如果你也在用类似的工具做编程任务欢迎交流你的踩坑经验。有一点我越来越确信工具的能力上限取决于你用它的方式。同样的模型会写提示词的人和不会写的人用出来的效果差很远。