GPT-6.1 Terra价格与跑分，Claude Code交付验收

同样是让 AI 操作电脑，一组测试里，GPT-6.1 Terra 和 GPT-6 Astra 都拿到 57.6%，单任务成本却分别是 0.29 美元和 4.82 美元。另一边，Claude Code 已经被接进工业软件，生成 PLC 程序后继续编译、下载到仿真器，再检查电机是否按要求启停。便宜和能干都在往前走，但「做完了」到底算什么，反而更难判断了。2026 年 10 月 27 日这期 AI 热点，我们沿着六条线聊模型选型、交付验收和权限边界，看看哪些值得程序员动手，哪些先别急着跟。

一、AI 编程模型降价了，什么时候才值得换？

先说结论，我会把 Terra 放进日常任务的候选名单，但不会因为 API 单价低，就直接切掉现有模型。

按 MarkTechPost 的报道，GPT-6.1 Terra 的输入、输出价格分别为每百万 token 1 美元和 5 美元。在专业电脑任务测试 Agents’ Last Exam v1 中，medium 推理强度下，它与 GPT-6 Astra 同为 57.6%，单任务成本分别为 0.29 美元和 4.82 美元。

这组数字很诱人。但测试对象是专业电脑任务，不能直接拿来估算一个 React 仓库的维护账单。

连同一个模型，推理强度也会改变这笔账。Terra 开到 max 后，这项测试的成绩升至 60.0%，单任务成本增至 1.01 美元。多拿 2.4 个百分点，花费超过原来的三倍。对批量任务来说，默认拉满推理强度，未必划算。

便宜模型是否省钱，要算到验收通过那一刻。

编程成绩也得带着设置读。IT之家转述的 Terminal-Bench 4.0 数据显示，Terra 在最高推理强度下达到 50.3%，前代为 21.5%。提升很明显，但最困难的编程任务，报道仍建议交给更强的模型。

另一条候选是 Kimi K3.1 Pro。按 dev.to 的解读，其官方 Terminal-Bench 4.0 成绩为 65.7%，API 输入、输出单价为每百万 token 2 美元和 10 美元。它更贵，也报出了更高的终端任务成绩，不过不同报道里的数字，不能脱离评测配置直接拼成采购排名。

还有个容易看漏的时间条件。Kimi 的完整权重计划于 11 月 4 日开放，截至这期日报所述阶段还不能下载，许可证也未公布。打算自部署的团队，现在可以准备评测任务，别先把部署排期当成已经确定的事。

回到这块，模型选型真正影响的是任务怎么分。范围清楚的依赖更新、局部修复，可以先测成本更低的候选；跨模块改造、验收条件模糊的需求，仍要看更强模型能否少走弯路。这个分法是我的取舍，不是上述跑分已经证明的结论。

真要决定换不换，我会拿仓库里最近 20 个能当天复跑的小任务，固定工具权限、推理强度和验收条件，同时记录重试与人工修正时间。只看 token 账单，容易把省下的钱花回审查里。

二、模型说代码写完了，怎么证明它真的能用？

Claude Code 接入 PLC 的实验，比又一个代码生成演示更有意思。

作者在 Windows、TIA Portal V19、Openness 19.0 和 S7-PLCSIM Advanced 6.0 环境中，通过 MCP 让 Claude Code 从空设备出发，生成程序、编译、下载到仿真器，再执行三个行为场景。按这篇实验记录，结果是零编译错误、零警告，电机顺序启动、停止和故障场景均通过。

关键不只是接上 MCP。

需求已经写得很具体。启动后电机 1 运行，持续 3 秒再启动电机 2；停止允许信号断开，或者出现故障，两台电机都要立即停止。输入地址、输出地址、功能块组织方式，以及不要保存工程，都提前划定了。

所谓一条提示词，里面其实装着一份验收约定。

对前端来说，这件事很好迁移。让 AI 「修复表单」太宽泛；要求它覆盖重复提交、接口失败、请求超时后的按钮状态，才有机会判断是否完成。但 PLC 仿真通过仍不等于现场安全可靠，同样，浏览器里跑通一遍，也不代表并发、网络故障和真实数据都没问题。

离线编程助手的实践给出了另一个尺度更小的例子。作者用 OpenCode、Ollama 和 Qwen3.5 9B，在断网后完成了一次修复。不过，项目只依赖 Python 标准库，改动只有一行，而且已有测试。

我认可它证明了本地模型能参与完整修改流程。至于能不能接手大型前端项目，这次实验还回答不了。

两条实践放在一起，最有用的信号是交付过程开始包含实际执行，而不只是展示生成结果。对应的成本变化也很直接，模型可能少写几行代码，却多花时间跑测试、处理失败；这部分调用不能省略，因为它才决定修改是否合格。

下面这个 JavaScript 记录结构，用来区分修改、执行证据和最终验收，适合放进一次小型模型对比。

const delivery = {
  task: "提交失败后允许用户重试",
  model: "candidate-a",
  checks: [
    { name: "成功后禁止重复提交", passed: true },
    { name: "接口失败后恢复按钮", passed: true },
    { name: "请求超时后允许重试", passed: false },
  ],
  evidence: {
    testReport: null, // 没有报告时，保留证据缺口
    browserTrace: null,
  },
};

const accepted =
  delivery.checks.every((item) => item.passed) &&
  Boolean(delivery.evidence.testReport) &&
  Boolean(delivery.evidence.browserTrace);

最容易翻车的是 passed 的来源，如果它仍由模型口头填写，这张记录只是把自我评价换成了对象。

你要是也在做 AI 编程接入，可以挑一个提交按钮或登录流程，故意让接口失败一次、超时一次，再观察模型有没有执行验证。当天跑完这两个场景，比继续优化一句「请确保代码可靠」更有用。

三、AGENTS.md 怎么会变成攻击入口？

这里有个坑，团队为了让 Agent 少犯错，往往会给它更多项目说明；但它越愿意听这些说明，谁能修改说明就越重要。

关于 AGENTS.md 攻击面的文章转述研究称，攻击者可以把恶意操作包装成项目约定，诱导编程代理调用工具。针对 Codex 的测试成功率超过九成，但这是特定研究环境中的结果，不能读成真实用户有九成会失陷。

下载目录中的攻击案例更贴近日常使用。文章转述，一份位于 ~/Downloads 的恶意 AGENTS.md，诱导从该目录启动的 Agent 安装可疑 npm 包。研究人员随后用打开计算器的无害载荷复现，报告成功率为 90%，但没有交代完整测试次数、版本和权限配置。

这两篇报道可能涉及相关研究，不能把它们当作两轮独立复测来叠加可信度。它们指出的入口却很具体，启动目录里的文字，有机会进入工具执行链。

危险动作也不只装包。相关报道还讨论了 API 端点被改写后，请求及认证信息可能被送往受控服务器的路径。是否真的泄露、能否重放，取决于配置是否生效和认证方式，不能看到一个环境变量就认定所有凭据都会被盗。

所以我更关心动作权限。

OpenShell 的介绍给出的方向，是在 Agent 与宿主机器之间放运行时边界。文件访问、系统调用和网络出站都受策略约束，凭据则只向获准目的地注入。不过，这篇介绍没有攻击对照实测，而且允许访问的目的地仍可能成为数据外流通道。

工具执行前权限检查的文章则把检查位置说得更直接。模型提出调用之后，工具真正执行之前，根据 Agent 身份、工具和参数决定放行还是拒绝。

项目文件可以解释怎么工作，不能替运行环境扩大权限。

代价当然有。限制安装和出站连接，会让自动修复更容易中断。但如果省掉这层检查，后续排查就得回答它读过什么、发到哪里、凭据是否要撤销，工作量更难控制。

我会在临时目录放一份要求安装未批准测试包的指令文件，用没有真实凭据的环境观察 Agent 如何处理。再从执行层确认安装和出站确实被拒绝，别只看它有没有回答「我会遵守安全规则」。

四、多模型共用技能库，语义缓存还能直接复用吗？

顺着上面聊，团队现在不只想让 Agent 更听话，还想把一次积累反复用起来。技能库复用操作经验，语义缓存复用已有回答，两者都在省重复劳动，但复用条件不能省。

共享技能库的讨论区分了项目事实与行为要求。项目用 pnpm、迁移文件放在哪里，这些可以共享；编辑前是否必须检查路径、失败几次后停止重试，则是在改变模型的行动方式。

作者引用一项研究，在 103 个任务与技能配对中，同一技能包对最强模型的评分影响约为 +31，对最弱模型约为 −8.8。不过，文章没有交代完整模型名称、指标单位和配置，作者也没有复现，不能把它写成成功率一升一降多少个百分点。

我的读法是，它足以提醒团队做分模型验证，还不足以证明共享技能库普遍有害。

另一边，Sulci 1.0 的发布说明尝试复用语义相近请求的答案。作者在 50 个会话、每会话 200 次调用分发的负载中，报告冷缓存命中率为 33.4%，同会话预热后为 99.7%；p95 会话仍有 53 次请求发给模型。

99.7% 看起来几乎把模型调用消掉了，但这批请求本身高度重复，不能直接套进你的业务预算。更要紧的是，提供的正文没有列出关键的错误命中率和正确拒绝率，暂时还不能判断它会不会把不该共享的答案也共享出去。

省下来的是调用，复用错了增加的是返工。

技能和缓存的共同难点，是环境变了以后，旧结果还适不适用。一个针对强模型的检查规则，可能让小模型绕远；一份昨天生成的权限说明，今天换了租户或角色就可能答错。

下面这个 JavaScript 示例只演示缓存隔离范围，让语义匹配发生在相同业务上下文内。

function cacheScope(request) {
  return JSON.stringify([
    request.tenantId,
    request.role,
    request.permissionVersion,
    request.documentVersion,
    request.model,
    request.promptVersion,
  ]); // 任一条件变化，都重新划定复用范围
}

function findCachedAnswer(request, candidates) {
  const scope = cacheScope(request);
  return candidates.find(
    (item) => item.scope === scope && item.query === request.query
  ); // 此处只做精确匹配，尚未引入语义判断
}

最容易翻车的是 permissionVersion 没有随授权变化更新，字段写进对象不等于隔离已经有效。

当天可以拿同一批任务，分别比较有无技能包，再把租户、角色、文档版本不同但措辞相近的问题放进缓存测试。命中率和工具调用数值得看，错误复用与人工返工更要一起记。

五、千万 token 上下文，能替代检索和文件上传设计吗？

说实话，千万 token 很容易让人产生一个念头，把仓库和附件全塞进去，省得再找文件、切片和做检索。

Fern 0.1 的报道展示的恰好是这种想法的边界。它从预训练阶段支持 10M tokens，上下文单针检索测试获得满分，但 Agent 编码能力仍落后于前沿模型。

找得到，不代表改得对。

报道还介绍了一组仓库预测实验，Fern 随可见内容增加而改善。但这组窗口以 bytes 计量，不能和 tokens 混着读；在相同的 1M-byte 窗口下，Fern 的指标也没有胜过 Kimi-K3。它证明了更多输入对这组实验有帮助，尚未证明整仓输入优于检索相关文件。

落到 AI 办公提效，文件还有另一层问题，用户上传它，究竟想让谁处理？

FodyChat 的附件设计把入口分成文本提取和原文件上传。提取结果先放进输入框，让用户确认后发送；原文件则作为可移除附件，随消息交给接收方。

这个区分我很认可。客服截图可能只是给人工客服看，合同可能只是留档，没有必要一律送进模型。这样能少做解析、少传模型输入，也能让用户知道下一步会发生什么。不过，具体能省多少费用，文章没有给对照数据。

想进一步接入外部信息，AI SDK 接搜索的教程提供了 MCP 路径，但免费额度为每 IP 每天最多 25 次，还受共享每日容量约束。示例做了类型检查和真实搜索测试，模型环节用的却是模拟模型。

因此，搜索工具能调用，不等于真实模型已经会搜、会引用、会判断搜索是否足够。

对前端产品来说，我会先把信息入口设计清楚，再决定上下文要开多大。当天就能拿长文档、客服截图和跨文件修改各跑一次，分别比较整份输入、提取后确认、按需检索的结果，同时记下延迟与费用；不要用「都装进去了」代替效果判断。

六、模型评测和 Agent 上线，为什么都要先检查运行环境？

同一套提示词，换个 API 端点分数就变了，你会先怀疑模型，还是先看服务怎么处理请求？

端点一致性检查的文章提醒，评测结果同时受模型、评测程序和托管端点影响。路由、截断、排队、超时，都可能混进最后的分数。

作者给出的探针包括重复发送同一提示、在长文本末尾放唯一字符串、检查工具参数能否解析并符合约束。提示集还记录 SHA-256 校验和，方便确认复跑内容一致。

这里别过度归因。找不到末尾字符串，不一定就是输入被截断；返回的模型名称一致，也不能单独证明底层模型没变。它们是排查线索，不是身份鉴定。

运行环境的问题，还会从评测一路延伸到恢复。

agentic-hosting 的备份实践把平台状态放进两个 SQLite 文件，但应用数据库的业务记录另存在 Docker 卷中。恢复平台账本，只能让系统重新知道有哪些数据库，订单和用户数据不会跟着自动回来。

这和模型评测其实是同一种错觉，拿到了一个看得见的结果，就以为整条链路都成立。

运维手册图建模的文章又补了一层。把告警入口、处理步骤、负责人和终点放进有向图，可以检查断链。但存在一条到终点的路径，不代表所有分支都能退出；作者也明确没有运行过节选中的确切代码。

对技术管理者来说，这些细节决定了 AI 提效有没有把成本转移给值班同事。演示顺利、测试通过、备份文件存在，都值得记录，却各自只覆盖了一段。

我会把当天的验证缩到可完成的范围，固定一组端点探针，抽一个应用恢复到临时环境，再沿一条失败告警走到明确终点。恢复不了业务数据、找不到接手人，或者工具调用格式不稳定，就先处理这些问题，再讨论扩大 Agent 使用量。

总结

这期能从发布公告和实践记录里确认的，是 Terra 已提供新的价格与接入选择，Claude Code 有了从 PLC 生成到仿真验证的案例，本地模型也完成过断网修改与测试。它们各自证明了一段流程，覆盖范围差别很大。

我的判断是，接下来更值得投入的地方，是把任务边界、验收证据和执行权限接起来。便宜模型接小任务，强模型处理难题，这个方向值得试；到底怎么分，还得由自己的仓库决定。

仍没被这些材料证明的，包括新模型能否稳定降低团队交付成本、技能库能否跨模型增益，以及高命中率缓存会不会错误复用答案。研究中的攻击比例也不能直接当成线上发生率。

AI 编程已经往实际执行走了。我们评价它的方式，也该从「回答看着不错」，走到「结果能验、失败能停、出了问题能恢复」。

参考

一、AI 编程模型降价了，什么时候才值得换？

先说结论，我会把 Terra 放进日常任务的候选名单，但不会因为 API 单价低，就直接切掉现有模型。

这组数字很诱人。但测试对象是专业电脑任务，不能直接拿来估算一个 React 仓库的维护账单。

便宜模型是否省钱，要算到验收通过那一刻。

二、模型说代码写完了，怎么证明它真的能用？

Claude Code 接入 PLC 的实验，比又一个代码生成演示更有意思。

关键不只是接上 MCP。

所谓一条提示词，里面其实装着一份验收约定。

我认可它证明了本地模型能参与完整修改流程。至于能不能接手大型前端项目，这次实验还回答不了。

下面这个 JavaScript 记录结构，用来区分修改、执行证据和最终验收，适合放进一次小型模型对比。

const delivery = {
  task: "提交失败后允许用户重试",
  model: "candidate-a",
  checks: [
    { name: "成功后禁止重复提交", passed: true },
    { name: "接口失败后恢复按钮", passed: true },
    { name: "请求超时后允许重试", passed: false },
  ],
  evidence: {
    testReport: null, // 没有报告时，保留证据缺口
    browserTrace: null,
  },
};

const accepted =
  delivery.checks.every((item) => item.passed) &&
  Boolean(delivery.evidence.testReport) &&
  Boolean(delivery.evidence.browserTrace);

最容易翻车的是 passed 的来源，如果它仍由模型口头填写，这张记录只是把自我评价换成了对象。

三、AGENTS.md 怎么会变成攻击入口？

这里有个坑，团队为了让 Agent 少犯错，往往会给它更多项目说明；但它越愿意听这些说明，谁能修改说明就越重要。

这两篇报道可能涉及相关研究，不能把它们当作两轮独立复测来叠加可信度。它们指出的入口却很具体，启动目录里的文字，有机会进入工具执行链。

所以我更关心动作权限。

工具执行前权限检查的文章则把检查位置说得更直接。模型提出调用之后，工具真正执行之前，根据 Agent 身份、工具和参数决定放行还是拒绝。

项目文件可以解释怎么工作，不能替运行环境扩大权限。

四、多模型共用技能库，语义缓存还能直接复用吗？

我的读法是，它足以提醒团队做分模型验证，还不足以证明共享技能库普遍有害。

省下来的是调用，复用错了增加的是返工。

下面这个 JavaScript 示例只演示缓存隔离范围，让语义匹配发生在相同业务上下文内。

function cacheScope(request) {
  return JSON.stringify([
    request.tenantId,
    request.role,
    request.permissionVersion,
    request.documentVersion,
    request.model,
    request.promptVersion,
  ]); // 任一条件变化，都重新划定复用范围
}

function findCachedAnswer(request, candidates) {
  const scope = cacheScope(request);
  return candidates.find(
    (item) => item.scope === scope && item.query === request.query
  ); // 此处只做精确匹配，尚未引入语义判断
}

最容易翻车的是 permissionVersion 没有随授权变化更新，字段写进对象不等于隔离已经有效。

五、千万 token 上下文，能替代检索和文件上传设计吗？

说实话，千万 token 很容易让人产生一个念头，把仓库和附件全塞进去，省得再找文件、切片和做检索。

Fern 0.1 的报道展示的恰好是这种想法的边界。它从预训练阶段支持 10M tokens，上下文单针检索测试获得满分，但 Agent 编码能力仍落后于前沿模型。

找得到，不代表改得对。

落到 AI 办公提效，文件还有另一层问题，用户上传它，究竟想让谁处理？

FodyChat 的附件设计把入口分成文本提取和原文件上传。提取结果先放进输入框，让用户确认后发送；原文件则作为可移除附件，随消息交给接收方。

因此，搜索工具能调用，不等于真实模型已经会搜、会引用、会判断搜索是否足够。

六、模型评测和 Agent 上线，为什么都要先检查运行环境？

同一套提示词，换个 API 端点分数就变了，你会先怀疑模型，还是先看服务怎么处理请求？

端点一致性检查的文章提醒，评测结果同时受模型、评测程序和托管端点影响。路由、截断、排队、超时，都可能混进最后的分数。

运行环境的问题，还会从评测一路延伸到恢复。

这和模型评测其实是同一种错觉，拿到了一个看得见的结果，就以为整条链路都成立。

对技术管理者来说，这些细节决定了 AI 提效有没有把成本转移给值班同事。演示顺利、测试通过、备份文件存在，都值得记录，却各自只覆盖了一段。

总结

AI 编程已经往实际执行走了。我们评价它的方式，也该从「回答看着不错」，走到「结果能验、失败能停、出了问题能恢复」。

AI日报

今日看点

一、AI 编程模型降价了，什么时候才值得换？

二、模型说代码写完了，怎么证明它真的能用？

三、AGENTS.md 怎么会变成攻击入口？

四、多模型共用技能库，语义缓存还能直接复用吗？

五、千万 token 上下文，能替代检索和文件上传设计吗？

六、模型评测和 Agent 上线，为什么都要先检查运行环境？

总结

参考

AI日报

今日看点

一、AI 编程模型降价了，什么时候才值得换？

二、模型说代码写完了，怎么证明它真的能用？

三、AGENTS.md 怎么会变成攻击入口？

四、多模型共用技能库，语义缓存还能直接复用吗？

五、千万 token 上下文，能替代检索和文件上传设计吗？

六、模型评测和 Agent 上线，为什么都要先检查运行环境？

总结

参考