1. 从标题拆解这次发布的真实分量1.1 为什么“终端得分90.8%”比跑分数字更值得关注看到“90.8%终端得分”这个数字我第一反应不是“又破纪录了”而是去翻Terminal-Bench这个评测到底在考什么。Terminal-Bench不是那种给模型喂几道选择题、看它选得对不对的评测它考的是模型在真实终端环境里完成多步骤任务的能力——比如让你在Linux环境下配置一个服务、排查一个依赖冲突、写一段脚本把日志里的异常提取出来。这类任务的特点是没有标准答案的路径只有最终状态对不对。模型得自己决定先看什么、再改什么、改完怎么验证。90.8%这个数字意味着什么我拿自己日常用AI辅助运维的经验来类比以前让模型帮我写个awk命令提取日志它经常给我一个语法看着对、但字段分隔符搞错的版本我还得自己调。现在如果终端任务通过率能到九成说明模型对shell语义、文件系统操作、进程管理的理解已经跨过了一个临界点——它不再只是“生成看起来像命令的文本”而是真的在模拟执行路径。这对做DevOps、SRE、后端开发的人来说价值远大于某个语言理解榜单涨了两个点。1.2 “代码跑通率翻倍”背后的工程含义标题里“代码跑通率翻倍”这个说法我一开始是持怀疑态度的因为“跑通”的定义太宽泛了。但结合DeepSWE这个关键词来看大概率指的是在SWE-bench类任务上的表现——给一个真实开源仓库的issue让模型定位bug、修改代码、跑通测试。这类任务的难点不在于写代码而在于理解代码库的上下文这个函数被谁调用、这个变量在哪个模块初始化、改完之后会不会破坏其他测试。跑通率翻倍如果是从30%到60%那是从“基本不能用”到“可以当助手用”的质变如果是从15%到30%那还是“玩具阶段”。但不管基数是多少翻倍这个幅度说明模型在长上下文理解、跨文件引用、测试反馈循环这几个环节上有了实质性改进。我自己的体验是以前让模型改一个跨三个文件的bug它经常只改一个文件就交差然后测试报错它又不知道错在哪。如果新版本能自己跑测试、看报错、再回去改那整个工作流就完全不一样了。1.3 这次更新对普通开发者的实际影响很多人看到“Google深夜突袭发布”这种标题第一反应是“又来了跟我有什么关系”。但如果你日常写代码、调API、做自动化脚本这次更新里有两个点值得你花时间一是终端任务能力的提升意味着你可以更放心地把一些重复性的环境配置、日志排查工作交给模型二是代码跑通率的提升意味着AI编程插件的实际可用性会上一个台阶。我试过不少AI编程工具最大的痛点不是它不会写而是它写完了你得花大量时间debug它的输出。如果跑通率真的翻倍那这个debug成本会显著下降。2. 核心能力拆解终端、代码与API的三层跃迁2.1 Terminal-Bench 90.8%到底考了什么Terminal-Bench的评测集我翻过一些公开资料它的任务设计非常“接地气”。举个例子给你一个目录里面有几个日志文件和一个损坏的配置文件要求你找出配置错误、修复它、然后重启服务并验证服务正常响应。这种任务在真实运维里天天发生但对AI来说它需要同时具备文件读写能力、文本解析能力、进程管理知识、以及最重要的——知道自己什么时候该停下来验证。90.8%的通过率意味着模型在绝大多数情况下能自己走完这个闭环。我实测过类似场景以前的模型经常犯的错是改完配置文件不检查语法就直接重启服务起不来它又不知道去看systemctl status的输出。新版本如果真能达到这个水平那对于中小团队的运维自动化来说是一个很实在的提效工具。你可以把一些标准化的环境初始化、服务部署、日志巡检任务写成prompt让模型在终端里自己跑。2.2 DeepSWE与代码跑通率翻倍的技术逻辑DeepSWE这个关键词指向的是深度软件工程任务。这类任务和普通的代码生成有本质区别普通代码生成是“给我写一个快排”DeepSWE是“这个仓库的登录接口在并发情况下会返回500你找到原因并修复”。后者需要模型具备仓库级代码理解、调用链追踪、测试用例阅读、以及修改后的回归验证能力。跑通率翻倍的技术支撑我推测主要来自三个方面一是上下文窗口的扩展让模型能一次性读入更多相关文件二是训练数据里加入了更多“修改-测试-再修改”的轨迹数据让模型学会了迭代式修复三是对测试反馈的利用更充分模型不再是一次性输出而是能根据测试结果调整方案。这对做开源贡献、维护老项目的人来说特别有用——老项目的代码风格不统一、文档缺失人去看都头疼如果模型能自己摸索着改对那效率提升是肉眼可见的。2.3 API调用量激增背后的开发者行为变化热搜词里“API调用量”和“免费大模型API”同时出现这个组合很有意思。它说明两件事一是开发者在大量尝试把模型能力集成到自己的工具链里二是免费额度仍然是很多人选择模型的重要考量。我自己的做法是对于终端任务和代码修复这类高价值场景用能力最强的模型对于批量文本处理、简单分类这种低价值场景用便宜甚至免费的模型。这次更新后我建议你重新评估一下自己的API调用策略。如果终端任务能力真的到了90%以上那以前你觉得“AI搞不定、必须人工”的运维脚本编写、环境排查工作现在可以试着交给模型。调用量上去了但省下来的人力时间更多。关键是找到那个平衡点哪些任务值得用贵模型哪些用便宜模型凑合就行。3. 实操指南如何把新能力接入你的日常工作流3.1 终端任务自动化的最小可行方案如果你想试试让模型帮你处理终端任务我建议从一个最小闭环开始日志异常提取与初步归类。具体做法是写一个prompt模板把日志文件路径、你关心的异常关键词、以及期望的输出格式告诉模型让它在终端里自己用grep、awk、sort、uniq这些命令组合出结果。我自己的模板大概是这样的你是一个终端任务助手。当前目录下有一个名为 app.log 的日志文件。 请完成以下任务 1. 提取所有包含 ERROR 或 FATAL 的行 2. 按错误类型取每行第一个冒号前的部分分组统计出现次数 3. 输出格式为错误类型 | 出现次数 | 最近一次出现的时间戳 4. 最后给出一个总结指出出现频率最高的错误类型这个任务看起来简单但以前的模型经常在awk的字段分隔符上翻车或者时间戳提取的正则写错。如果新版本真能达到90%的终端任务通过率那这种模板你可以放心地批量用。关键是先在小任务上验证再逐步扩大范围。3.2 代码修复任务的prompt设计要点让模型修bug最大的坑是它改着改着就跑偏了。我的经验是prompt里必须包含四个要素问题描述、复现步骤、相关文件列表、验证方式。缺了任何一个模型都容易给你一个“看起来对但跑不通”的补丁。举个例子如果你要让模型修一个Python的KeyError不要只说“修一下这个bug”。你应该这样写项目路径/home/user/myproject 问题运行 pytest tests/test_api.py::test_user_login 时抛出 KeyError: user_id 复现步骤 1. cd /home/user/myproject 2. pytest tests/test_api.py::test_user_login -v 相关文件 - src/api/auth.py登录接口实现 - src/models/user.py用户模型定义 - tests/test_api.py测试用例 要求 1. 先阅读上述文件理解数据流 2. 定位 KeyError 的根源 3. 修改代码确保测试通过 4. 修改后重新运行测试验证这种结构化的prompt配合模型自身的测试反馈循环能力能把修复成功率拉高不少。我实测下来加了“修改后重新运行测试验证”这一条模型自己发现并纠正错误的概率明显上升。3.3 API集成的成本与效率平衡如果你打算把模型能力集成到自己的产品里API调用成本是个绕不开的话题。我的策略是分层调用第一层用便宜模型做意图识别和简单分类第二层用强模型做复杂推理和代码生成。比如用户输入一段自然语言查询先用小模型判断这是“查数据”还是“改配置”还是“问问题”然后再路由到对应的处理逻辑。这次更新后我建议你重新测一下强模型在终端任务上的表现。如果90.8%的通过率在你的实际场景里也能复现那以前需要人工介入的很多运维操作现在可以做成自动化流程。成本上一次强模型调用的费用可能比你让一个工程师花半小时排查环境问题要便宜得多。关键是算清楚账你的时间值多少钱模型调用值多少钱。4. 常见问题与排查技巧实录4.1 模型在终端任务中“卡住”的典型场景我遇到最多的情况是模型执行了一个交互式命令然后终端在等待输入模型却以为命令已经执行完了。比如apt-get install在某些情况下会弹出确认提示模型没处理这个提示后续步骤全乱套。解决办法是在prompt里明确要求“所有命令必须使用非交互模式”比如apt-get install -y、pip install --no-input。另一个常见问题是路径问题。模型在/tmp下创建了文件然后cd到别的地方去操作再回来找文件时路径写错了。我的做法是在prompt里强制要求“所有文件操作使用绝对路径”并且在任务开始时就让模型pwd一下确认当前目录。4.2 代码修复任务中“改对了但跑不通”的排查这种情况通常不是逻辑错误而是环境问题。模型改的代码在它自己的沙箱里能跑但在你的环境里因为依赖版本不同而失败。排查思路是先让模型输出它修改后的完整文件内容你人工diff一下看有没有引入新的import或者改变了函数签名。然后检查依赖pip freeze对比一下模型环境和你环境的差异。我踩过的一个坑是模型把requests.get改成了httpx.get逻辑上没问题但我的环境里没装httpx。所以现在我在prompt里会加一句“不要引入新的第三方依赖除非明确说明并给出安装命令”。4.3 API调用中的限流与重试策略如果你在批量调用API限流是必然会遇到的。我的做法是在代码里实现指数退避重试第一次失败等1秒第二次等2秒第三次等4秒最多重试5次。同时监控返回的429状态码如果连续出现就降低并发数。另外对于终端任务这种可能跑很久的调用一定要设置超时。我一般设120秒超过就中断并记录避免一个卡住的任务拖垮整个队列。还有一点把每次调用的prompt和返回结果都存下来方便后续排查和优化。我自己的日志里会记录任务类型、prompt长度、返回时间、是否成功、失败原因。积累多了之后你就能看出哪些类型的任务模型擅长、哪些容易翻车。4.4 常见问题速查表问题现象可能原因排查动作解决技巧模型执行命令后无输出命令进入交互模式等待输入检查命令是否需要-y或--no-inputprompt中强制要求非交互模式文件找不到相对路径基准不一致让模型先pwd确认目录强制使用绝对路径修改后测试仍失败引入了新依赖或改了接口diff修改前后文件检查importprompt中禁止引入新依赖API返回429调用频率超限查看响应头中的限流信息指数退避重试降低并发任务执行超时命令卡死或模型陷入循环设置超时中断记录现场拆分任务减少单次调用复杂度模型输出格式不对prompt约束不够明确检查prompt中的格式要求给出具体的输出示例5. 从这次更新看AI编程工具的选择逻辑5.1 终端能力为什么是编程助手的分水岭我用了不少AI编程工具发现一个规律能写好代码的模型很多能管好终端的模型很少。写代码是“生成”任务模型只要输出文本就行管终端是“执行反馈”任务模型得理解命令的副作用、处理执行结果、根据结果调整下一步。这中间的差距就像“会写菜谱”和“会炒菜”的区别。这次终端得分到90.8%如果实测能复现那意味着AI编程助手从“副驾驶”向“自动驾驶”迈进了一步。你可以把整个开发环境的初始化、依赖安装、测试运行、日志排查都交给模型自己只负责审查最终结果。这对独立开发者和小团队来说价值尤其大——你没有专门的运维人员但模型可以帮你把环境管起来。5.2 代码跑通率对项目交付节奏的影响跑通率翻倍最直接的影响是减少了“AI写代码、人debug”的循环次数。我以前用AI辅助写代码大概30%的时间花在写prompt上70%的时间花在调试AI的输出上。如果跑通率翻倍这个比例可能变成50%对50%甚至更好。对于赶项目的人来说这意味着你可以更放心地把一些模块交给AI去实现自己专注于架构设计和核心逻辑。但要注意跑通率翻倍不等于“AI写的代码可以直接上生产”。测试通过只是最低标准代码的可读性、可维护性、边界条件处理还是需要人工审查。我的做法是AI生成的代码测试通过后我还会过一遍重点看异常处理、日志记录、以及有没有硬编码的魔法数字。5.3 多AI协作的实际操作方式热搜词里“多AI协作”出现频率很高我自己的实践是用不同模型做不同的事。比如用一个模型做代码生成用另一个模型做代码审查再用一个模型写测试用例。这样做的原因是不同模型的训练数据和偏好不同一个模型犯的错另一个模型可能能发现。具体操作上我会把第一个模型生成的代码连同原始需求一起发给第二个模型prompt是“请审查这段代码找出潜在的bug、边界条件遗漏、以及不符合最佳实践的地方”。实测下来这种交叉审查能发现不少单模型自己发现不了的问题。当然成本也会上去所以只对关键模块这么做。6. 一些实操中的个人体会6.1 不要迷信跑分要信自己的场景90.8%的终端得分、翻倍的代码跑通率这些数字看着很唬人但你的场景可能和评测集不一样。我的建议是拿你自己最常做的三个任务分别用旧版本和新版本跑一遍对比通过率和耗时。如果提升明显那就值得切换如果差不多那就再等等。我自己的测试集是一个日志分析任务、一个跨文件bug修复任务、一个API接口的单元测试生成任务。这三个任务覆盖了我日常工作的主要场景。每次有新模型发布我都用这三个任务跑一遍记录结果。积累了几次之后我就能看出哪些更新是“真提升”哪些是“跑分提升”。6.2 免费额度怎么用才划算免费大模型API的额度我一般用在两类任务上一是批量文本处理比如把一堆日志摘要成短句二是低风险的代码补全比如写个简单的工具函数。对于终端任务和复杂代码修复我还是用付费的强模型因为失败重试的成本太高免费额度省下来的钱不够弥补时间损失。另外免费额度适合用来做“探针”先用免费模型跑一遍如果它能搞定那就不用调强模型了如果搞不定再把任务转给强模型。这样能在不增加成本的前提下过滤掉一部分简单任务。6.3 后续可以关注的方向这次更新里提到的终端能力和代码修复能力我觉得后续有两个方向值得关注一是多轮终端交互的稳定性模型能不能在长时间运行的任务里保持上下文不丢失二是跨仓库的代码理解模型能不能同时理解多个相关仓库的代码做出协调一致的修改。对于日常使用我建议你先从终端任务自动化入手把那些重复性的环境配置、日志排查工作写成模板让模型去跑。跑顺了之后再逐步扩展到代码修复和测试生成。不要一上来就搞大工程小步快跑边用边调才是比较稳妥的路径。最后分享一个小技巧在prompt里加上“如果你不确定某个步骤先输出你的推理过程再执行命令”这样模型在遇到模糊情况时会更谨慎减少瞎猜导致的错误。我实测下来这一句话能让终端任务的首次通过率提升不少。 
长河君 · 2026/10/26 21:00:15 · 阅读 1.2k Google深夜发布新模型：终端任务得分90.8%，代码跑通率翻倍
1. 从标题拆解这次发布的真实分量1.1 为什么“终端得分90.8%”比跑分数字更值得关注看到“90.8%终端得分”这个数字我第一反应不是“又破纪录了”而是去翻Terminal-Bench这个评测到底在考什么。Terminal-Bench不是那种给模型喂几道选择题、看它选得对不对的评测它考的是模型在真实终端环境里完成多步骤任务的能力——比如让你在Linux环境下配置一个服务、排查一个依赖冲突、写一段脚本把日志里的异常提取出来。这类任务的特点是没有标准答案的路径只有最终状态对不对。模型得自己决定先看什么、再改什么、改完怎么验证。90.8%这个数字意味着什么我拿自己日常用AI辅助运维的经验来类比以前让模型帮我写个awk命令提取日志它经常给我一个语法看着对、但字段分隔符搞错的版本我还得自己调。现在如果终端任务通过率能到九成说明模型对shell语义、文件系统操作、进程管理的理解已经跨过了一个临界点——它不再只是“生成看起来像命令的文本”而是真的在模拟执行路径。这对做DevOps、SRE、后端开发的人来说价值远大于某个语言理解榜单涨了两个点。1.2 “代码跑通率翻倍”背后的工程含义标题里“代码跑通率翻倍”这个说法我一开始是持怀疑态度的因为“跑通”的定义太宽泛了。但结合DeepSWE这个关键词来看大概率指的是在SWE-bench类任务上的表现——给一个真实开源仓库的issue让模型定位bug、修改代码、跑通测试。这类任务的难点不在于写代码而在于理解代码库的上下文这个函数被谁调用、这个变量在哪个模块初始化、改完之后会不会破坏其他测试。跑通率翻倍如果是从30%到60%那是从“基本不能用”到“可以当助手用”的质变如果是从15%到30%那还是“玩具阶段”。但不管基数是多少翻倍这个幅度说明模型在长上下文理解、跨文件引用、测试反馈循环这几个环节上有了实质性改进。我自己的体验是以前让模型改一个跨三个文件的bug它经常只改一个文件就交差然后测试报错它又不知道错在哪。如果新版本能自己跑测试、看报错、再回去改那整个工作流就完全不一样了。1.3 这次更新对普通开发者的实际影响很多人看到“Google深夜突袭发布”这种标题第一反应是“又来了跟我有什么关系”。但如果你日常写代码、调API、做自动化脚本这次更新里有两个点值得你花时间一是终端任务能力的提升意味着你可以更放心地把一些重复性的环境配置、日志排查工作交给模型二是代码跑通率的提升意味着AI编程插件的实际可用性会上一个台阶。我试过不少AI编程工具最大的痛点不是它不会写而是它写完了你得花大量时间debug它的输出。如果跑通率真的翻倍那这个debug成本会显著下降。2. 核心能力拆解终端、代码与API的三层跃迁2.1 Terminal-Bench 90.8%到底考了什么Terminal-Bench的评测集我翻过一些公开资料它的任务设计非常“接地气”。举个例子给你一个目录里面有几个日志文件和一个损坏的配置文件要求你找出配置错误、修复它、然后重启服务并验证服务正常响应。这种任务在真实运维里天天发生但对AI来说它需要同时具备文件读写能力、文本解析能力、进程管理知识、以及最重要的——知道自己什么时候该停下来验证。90.8%的通过率意味着模型在绝大多数情况下能自己走完这个闭环。我实测过类似场景以前的模型经常犯的错是改完配置文件不检查语法就直接重启服务起不来它又不知道去看systemctl status的输出。新版本如果真能达到这个水平那对于中小团队的运维自动化来说是一个很实在的提效工具。你可以把一些标准化的环境初始化、服务部署、日志巡检任务写成prompt让模型在终端里自己跑。2.2 DeepSWE与代码跑通率翻倍的技术逻辑DeepSWE这个关键词指向的是深度软件工程任务。这类任务和普通的代码生成有本质区别普通代码生成是“给我写一个快排”DeepSWE是“这个仓库的登录接口在并发情况下会返回500你找到原因并修复”。后者需要模型具备仓库级代码理解、调用链追踪、测试用例阅读、以及修改后的回归验证能力。跑通率翻倍的技术支撑我推测主要来自三个方面一是上下文窗口的扩展让模型能一次性读入更多相关文件二是训练数据里加入了更多“修改-测试-再修改”的轨迹数据让模型学会了迭代式修复三是对测试反馈的利用更充分模型不再是一次性输出而是能根据测试结果调整方案。这对做开源贡献、维护老项目的人来说特别有用——老项目的代码风格不统一、文档缺失人去看都头疼如果模型能自己摸索着改对那效率提升是肉眼可见的。2.3 API调用量激增背后的开发者行为变化热搜词里“API调用量”和“免费大模型API”同时出现这个组合很有意思。它说明两件事一是开发者在大量尝试把模型能力集成到自己的工具链里二是免费额度仍然是很多人选择模型的重要考量。我自己的做法是对于终端任务和代码修复这类高价值场景用能力最强的模型对于批量文本处理、简单分类这种低价值场景用便宜甚至免费的模型。这次更新后我建议你重新评估一下自己的API调用策略。如果终端任务能力真的到了90%以上那以前你觉得“AI搞不定、必须人工”的运维脚本编写、环境排查工作现在可以试着交给模型。调用量上去了但省下来的人力时间更多。关键是找到那个平衡点哪些任务值得用贵模型哪些用便宜模型凑合就行。3. 实操指南如何把新能力接入你的日常工作流3.1 终端任务自动化的最小可行方案如果你想试试让模型帮你处理终端任务我建议从一个最小闭环开始日志异常提取与初步归类。具体做法是写一个prompt模板把日志文件路径、你关心的异常关键词、以及期望的输出格式告诉模型让它在终端里自己用grep、awk、sort、uniq这些命令组合出结果。我自己的模板大概是这样的你是一个终端任务助手。当前目录下有一个名为 app.log 的日志文件。 请完成以下任务 1. 提取所有包含 ERROR 或 FATAL 的行 2. 按错误类型取每行第一个冒号前的部分分组统计出现次数 3. 输出格式为错误类型 | 出现次数 | 最近一次出现的时间戳 4. 最后给出一个总结指出出现频率最高的错误类型这个任务看起来简单但以前的模型经常在awk的字段分隔符上翻车或者时间戳提取的正则写错。如果新版本真能达到90%的终端任务通过率那这种模板你可以放心地批量用。关键是先在小任务上验证再逐步扩大范围。3.2 代码修复任务的prompt设计要点让模型修bug最大的坑是它改着改着就跑偏了。我的经验是prompt里必须包含四个要素问题描述、复现步骤、相关文件列表、验证方式。缺了任何一个模型都容易给你一个“看起来对但跑不通”的补丁。举个例子如果你要让模型修一个Python的KeyError不要只说“修一下这个bug”。你应该这样写项目路径/home/user/myproject 问题运行 pytest tests/test_api.py::test_user_login 时抛出 KeyError: user_id 复现步骤 1. cd /home/user/myproject 2. pytest tests/test_api.py::test_user_login -v 相关文件 - src/api/auth.py登录接口实现 - src/models/user.py用户模型定义 - tests/test_api.py测试用例 要求 1. 先阅读上述文件理解数据流 2. 定位 KeyError 的根源 3. 修改代码确保测试通过 4. 修改后重新运行测试验证这种结构化的prompt配合模型自身的测试反馈循环能力能把修复成功率拉高不少。我实测下来加了“修改后重新运行测试验证”这一条模型自己发现并纠正错误的概率明显上升。3.3 API集成的成本与效率平衡如果你打算把模型能力集成到自己的产品里API调用成本是个绕不开的话题。我的策略是分层调用第一层用便宜模型做意图识别和简单分类第二层用强模型做复杂推理和代码生成。比如用户输入一段自然语言查询先用小模型判断这是“查数据”还是“改配置”还是“问问题”然后再路由到对应的处理逻辑。这次更新后我建议你重新测一下强模型在终端任务上的表现。如果90.8%的通过率在你的实际场景里也能复现那以前需要人工介入的很多运维操作现在可以做成自动化流程。成本上一次强模型调用的费用可能比你让一个工程师花半小时排查环境问题要便宜得多。关键是算清楚账你的时间值多少钱模型调用值多少钱。4. 常见问题与排查技巧实录4.1 模型在终端任务中“卡住”的典型场景我遇到最多的情况是模型执行了一个交互式命令然后终端在等待输入模型却以为命令已经执行完了。比如apt-get install在某些情况下会弹出确认提示模型没处理这个提示后续步骤全乱套。解决办法是在prompt里明确要求“所有命令必须使用非交互模式”比如apt-get install -y、pip install --no-input。另一个常见问题是路径问题。模型在/tmp下创建了文件然后cd到别的地方去操作再回来找文件时路径写错了。我的做法是在prompt里强制要求“所有文件操作使用绝对路径”并且在任务开始时就让模型pwd一下确认当前目录。4.2 代码修复任务中“改对了但跑不通”的排查这种情况通常不是逻辑错误而是环境问题。模型改的代码在它自己的沙箱里能跑但在你的环境里因为依赖版本不同而失败。排查思路是先让模型输出它修改后的完整文件内容你人工diff一下看有没有引入新的import或者改变了函数签名。然后检查依赖pip freeze对比一下模型环境和你环境的差异。我踩过的一个坑是模型把requests.get改成了httpx.get逻辑上没问题但我的环境里没装httpx。所以现在我在prompt里会加一句“不要引入新的第三方依赖除非明确说明并给出安装命令”。4.3 API调用中的限流与重试策略如果你在批量调用API限流是必然会遇到的。我的做法是在代码里实现指数退避重试第一次失败等1秒第二次等2秒第三次等4秒最多重试5次。同时监控返回的429状态码如果连续出现就降低并发数。另外对于终端任务这种可能跑很久的调用一定要设置超时。我一般设120秒超过就中断并记录避免一个卡住的任务拖垮整个队列。还有一点把每次调用的prompt和返回结果都存下来方便后续排查和优化。我自己的日志里会记录任务类型、prompt长度、返回时间、是否成功、失败原因。积累多了之后你就能看出哪些类型的任务模型擅长、哪些容易翻车。4.4 常见问题速查表问题现象可能原因排查动作解决技巧模型执行命令后无输出命令进入交互模式等待输入检查命令是否需要-y或--no-inputprompt中强制要求非交互模式文件找不到相对路径基准不一致让模型先pwd确认目录强制使用绝对路径修改后测试仍失败引入了新依赖或改了接口diff修改前后文件检查importprompt中禁止引入新依赖API返回429调用频率超限查看响应头中的限流信息指数退避重试降低并发任务执行超时命令卡死或模型陷入循环设置超时中断记录现场拆分任务减少单次调用复杂度模型输出格式不对prompt约束不够明确检查prompt中的格式要求给出具体的输出示例5. 从这次更新看AI编程工具的选择逻辑5.1 终端能力为什么是编程助手的分水岭我用了不少AI编程工具发现一个规律能写好代码的模型很多能管好终端的模型很少。写代码是“生成”任务模型只要输出文本就行管终端是“执行反馈”任务模型得理解命令的副作用、处理执行结果、根据结果调整下一步。这中间的差距就像“会写菜谱”和“会炒菜”的区别。这次终端得分到90.8%如果实测能复现那意味着AI编程助手从“副驾驶”向“自动驾驶”迈进了一步。你可以把整个开发环境的初始化、依赖安装、测试运行、日志排查都交给模型自己只负责审查最终结果。这对独立开发者和小团队来说价值尤其大——你没有专门的运维人员但模型可以帮你把环境管起来。5.2 代码跑通率对项目交付节奏的影响跑通率翻倍最直接的影响是减少了“AI写代码、人debug”的循环次数。我以前用AI辅助写代码大概30%的时间花在写prompt上70%的时间花在调试AI的输出上。如果跑通率翻倍这个比例可能变成50%对50%甚至更好。对于赶项目的人来说这意味着你可以更放心地把一些模块交给AI去实现自己专注于架构设计和核心逻辑。但要注意跑通率翻倍不等于“AI写的代码可以直接上生产”。测试通过只是最低标准代码的可读性、可维护性、边界条件处理还是需要人工审查。我的做法是AI生成的代码测试通过后我还会过一遍重点看异常处理、日志记录、以及有没有硬编码的魔法数字。5.3 多AI协作的实际操作方式热搜词里“多AI协作”出现频率很高我自己的实践是用不同模型做不同的事。比如用一个模型做代码生成用另一个模型做代码审查再用一个模型写测试用例。这样做的原因是不同模型的训练数据和偏好不同一个模型犯的错另一个模型可能能发现。具体操作上我会把第一个模型生成的代码连同原始需求一起发给第二个模型prompt是“请审查这段代码找出潜在的bug、边界条件遗漏、以及不符合最佳实践的地方”。实测下来这种交叉审查能发现不少单模型自己发现不了的问题。当然成本也会上去所以只对关键模块这么做。6. 一些实操中的个人体会6.1 不要迷信跑分要信自己的场景90.8%的终端得分、翻倍的代码跑通率这些数字看着很唬人但你的场景可能和评测集不一样。我的建议是拿你自己最常做的三个任务分别用旧版本和新版本跑一遍对比通过率和耗时。如果提升明显那就值得切换如果差不多那就再等等。我自己的测试集是一个日志分析任务、一个跨文件bug修复任务、一个API接口的单元测试生成任务。这三个任务覆盖了我日常工作的主要场景。每次有新模型发布我都用这三个任务跑一遍记录结果。积累了几次之后我就能看出哪些更新是“真提升”哪些是“跑分提升”。6.2 免费额度怎么用才划算免费大模型API的额度我一般用在两类任务上一是批量文本处理比如把一堆日志摘要成短句二是低风险的代码补全比如写个简单的工具函数。对于终端任务和复杂代码修复我还是用付费的强模型因为失败重试的成本太高免费额度省下来的钱不够弥补时间损失。另外免费额度适合用来做“探针”先用免费模型跑一遍如果它能搞定那就不用调强模型了如果搞不定再把任务转给强模型。这样能在不增加成本的前提下过滤掉一部分简单任务。6.3 后续可以关注的方向这次更新里提到的终端能力和代码修复能力我觉得后续有两个方向值得关注一是多轮终端交互的稳定性模型能不能在长时间运行的任务里保持上下文不丢失二是跨仓库的代码理解模型能不能同时理解多个相关仓库的代码做出协调一致的修改。对于日常使用我建议你先从终端任务自动化入手把那些重复性的环境配置、日志排查工作写成模板让模型去跑。跑顺了之后再逐步扩展到代码修复和测试生成。不要一上来就搞大工程小步快跑边用边调才是比较稳妥的路径。最后分享一个小技巧在prompt里加上“如果你不确定某个步骤先输出你的推理过程再执行命令”这样模型在遇到模糊情况时会更谨慎减少瞎猜导致的错误。我实测下来这一句话能让终端任务的首次通过率提升不少。