GitHub Copilot用Rust重写80万行代码，如何验收

80 万行 Rust、128 个 PR，GitHub 说，Copilot 运行时这次重写主要由一名开发者在几个月里推进，AI 写了大部分代码。这个规模很抢眼，但我更在意后半句，它是逐步合并、增量发布的，中间也修过回归问题。代码产量上去了，验收并没有消失。9 月 17 日这份 AI 热点日报，我想沿着交付、开发环境、模型选型、安全、成本和任务记忆六条线聊聊，帮天天写业务的程序员判断哪些值得试，哪些先别急着跟。

一、AI 写了 80 万行代码，测试全绿就能合并吗？

先说结论，我最想从 Copilot 这次迁移里学的，是怎么拆交付。

根据 GitHub 官方博客，Copilot 智能体运行时从 TypeScript、Node.js 和 V8 迁到了 Rust，重写后的生产代码超过 80 万行，跨 128 个 PR 合入主分支，过程中持续发布。GitHub 还报告了数量级的性能提升，以及主要由一名开发者推进的投入情况。

这里有两个数字不能混着读。80 万行描述的是重写规模，不是有效业务功能增加了多少；数量级的性能提升属于 GitHub 对这个运行时的报告，不能顺手推成「我们的 Node.js 服务换 Rust 也能快十倍」。

至于「AI 已经可以独立完成大型重构」，我不认同这个转述。原文里有人拆任务、推进合并、处理回归，不能把这些劳动从账上抹掉。

代码生成规模变大了，验收责任还在人身上。

另一篇关于 AI 生成测试的讨论，刚好给这条新闻补了一个反面。实现和测试来自同一段对话，断言又照抄实现里的常量，最后很容易得到一组彼此同意的代码。

这不等于同一个 Agent 写测试就一定没用。关键是预期从哪里来。业务规则、历史兼容要求和外部接口契约，都可以成为独立依据；把刚生成的结果复制进断言，就没有这种独立性。

拿前端购物车举个例子，规格已经约定「金额按分计算，折扣不能让应付金额低于零」，就可以先把这些规则固定下来，再交给 Agent 改实现。

下面这段 JavaScript 用固定的业务样例约束待测函数，预期值不从实现里反算。

import assert from "node:assert/strict";

export function verifyPayable(calculatePayable) {
  const cases = [
    { subtotal: 10000, discount: 1500, expected: 8500 },
    { subtotal: 10000, discount: 12000, expected: 0 },
    { subtotal: 0, discount: 0, expected: 0 },
  ];

  for (const { subtotal, discount, expected } of cases) {
    // 输入与预期都来自已确认的业务规则，金额单位为分。
    assert.equal(calculatePayable(subtotal, discount), expected);
  }
}

最容易翻车的是 expected 那一列，如果它也是看着新实现填出来的，这个示例照样会变成自我证明。

回到这块，团队引入 AI 编程以后，更该统计的是任务验收通过率、回归问题和人工返工时间。行数可以看，但拿它当主要绩效指标，很容易奖励最贵的那种忙碌。

今天就能挑一个准备重构的纯函数模块，先写几个来自产品规则的样例，再让 Agent 修改。顺手故意改坏一个边界条件，看看测试到底会不会红，比盯着 PR 摘要踏实。

二、VS Code 把 Agent 放进开发容器，能解决环境不一致吗？

写业务最烦的一类问题，是代码看起来没毛病，命令却跑在了另一套环境里。你以为它用了仓库要求的依赖，实际调用的可能是宿主机上的工具。

IT之家对 VS Code 1.138 的报道提到，新版支持在本地开发容器里运行智能体会话。启用 chat.agentHost.devContainer.enabled 后，具有受支持容器配置的本地文件夹可以选择在开发容器中运行，前提是安装 Docker。

这个变化跟前端项目挺贴近。Agent 可以跟着项目指定的工具和依赖工作，不再默认依赖本机那套环境。对于多人维护的仓库，环境配置终于有机会和代码一起被审查。

不过，容器里跑通也不能直接等同于 CI 跑通。两边的配置是否一致，仍然要看仓库怎么维护。

同一报道还介绍了 Codex harness 的扩展，支持在 ChatGPT 应用和 VS Code 之间延续会话，并选择 GitHub Copilot 或 ChatGPT 订阅。这里改变的是入口和接入方式，不能据此推断不同订阅的额度、计费和工具能力完全相同。

顺着上面聊，Cline 项目说明给出了另一个方向。CLI、桌面应用、VS Code、JetBrains 和 SDK 使用同一引擎，项目规则也可以在多个入口加载。

我喜欢这个方向。团队最不想维护的，就是编辑器里一份规矩，终端里又一份，自动化脚本还得重新解释一遍。

但「同一引擎」和「同一执行条件」是两回事。编辑器里有人看 diff，脚本里可能无头执行；同样的一条任务，在不同入口拥有的权限、凭证和审批方式可能不同。迁移入口时，这些差异比聊天界面长什么样更要紧。

环境能复现，Agent 的结果才更容易复查。

对技术管理者来说，这类更新的价值不一定马上体现在生成速度上，而是减少排查「它到底在哪儿跑的」所花的时间。对开发者来说，会话跨应用延续很方便，但项目环境和订阅边界还是得分别看。

要我选，我会拿同一个小修复，在宿主机和开发容器各跑一次，让 Agent 报出实际工具版本，再执行仓库原有构建命令。Cline 的多端入口也可以这样比较，先确认结果和权限，再考虑团队统一用哪个入口。

三、GPT-6 Astra、U2-Flash 和小模型，业务项目该怎么选？

说实话，新模型名字越多，我越不想一上来就问谁最强。

今天关于 GPT-6 Astra 的信息来自 dev.to 的发布转述。文章称它主打扩展推理、多 Agent 协同和计算机操作，并分阶段向多个渠道开放。

这条我会先当跟进线索。给到的链接是社区文章，里面也没有最终 API 定价。不能因为文章写了多个平台，就认定自己的账号今天已经能用，更不该直接按旧模型价格估新项目预算。

另一边，量子位对 U2-Flash 的报道给出了更具体的接入与价格信息。报道列出的输入、输出价格分别是每百万 Tokens 0.6 元和 1.2 元，缓存命中价格为 0.12 元，并称支持 OpenAI 与 Anthropic 两套协议。

低价值得看，但要带着条件算。报道中的速度提升、任务时间缩短，是相对上一代 U2 的结果，不是相对你正在用的任意模型。标题里的 1 亿 Tokens 试用额度，也不能直接当成所有账号都能无条件领取的长期预算。

协议兼容可以减少迁移工作，却没有替你回答工具调用是否稳定、复杂任务会重试几次。

这里还有一个容易被大模型发布挤掉的选项。MarkTechPost 对 GLiFormer 的介绍称，它用编码器完成实体、关系和嵌套 JSON 抽取，Large 版本约 5.756 亿参数。报道中的嵌套 JSON 指标为 91.10 F1，接近同一比较里 GPT-5.6-luna 的 91.96。

这个数字得放在那个抽取任务里读。它不能说明两个模型的编程能力接近，更不能证明业务里可以直接替换。

GLiFormer 的取舍倒是很清楚。字段值从原文片段里选，再组织成结构，因此不会凭空生成一段原文中没有的值文本。但选错片段、分错记录、接错父子关系，仍然可能发生。

如果需求是从工单里提取产品、故障和关联记录，这条路线值得研究；如果需求是结合隐含信息给出处理建议，单纯抽取就未必够了。

选型先分任务，再比分数。

我的读法是，这三条消息分别代表复杂任务能力、调用单价和任务专用模型，不能排进一张简单的总榜。今天可以从仓库或业务里选 20 个有明确答案的真实任务，抽取、代码修改、工具调用分开记，固定验收条件，再比较成功率、重试次数和完成一次任务的费用。Astra 是否能参与，先看实际账号可用性。

四、Agent 能读网页又能改代码，权限边界到底放在哪？

这里有个坑，接入的工具越多，Agent 读到的内容就越不能被一视同仁。

Apify MCP 接入文章介绍了通过托管 MCP 服务发现、调用爬虫和读取结果的方式。这类接入把实时网页数据带进了工作流，省掉了一部分手写集成。

但网页进来了，网页里的指令也可能一起进来。

关于 MCP 间接提示词注入的文章讨论的就是这个边界。用户要求总结网页，页面却夹带了让 Agent 调工具、读文件或改变任务的内容。问题出在外部数据被当成了新的行动依据。

所以，工具返回成功，只能说明调用完成，不能替返回内容背书。MCP 负责连接工具，也不会自动决定那段文本有没有权指挥后续操作。

你要是也在做内部 Agent，别把全部防线压在提示词里的「不要听网页指挥」上。读取资料、修改仓库、访问凭证和发布结果，应该有各自的执行限制；否则一次内容误判就可能越过好几层权限。

Cloudflare 的安全审计 Skill提供了一个值得借鉴的验证安排。它把发现候选问题和验证候选问题拆给不同 Agent，并保留 confirmed、needs_validation、rejected 三种结果。

我尤其喜欢中间那个状态。证据不够，就把缺的事实留出来，不用为了交一份漂亮报告硬凑结论。

独立验证也有边界。新的 Agent 可以减少前一段对话带来的影响，但仍可能犯相似错误，不能因为换了一个会话就当成验证完成。

权限还会随时间变化。大规模会话管理的文章提醒，后台 Worker、WebSocket 和用户关掉浏览器后仍在工作的 Agent，都可能继续使用先前建立的信任。用户已被移出组织，任务却拿着旧权限继续执行，这才是长任务真正麻烦的地方。

今天可以用一份合成网页放入越权指令，观察只读任务是否会尝试写文件；再在后台任务执行中撤销测试账号权限，看看下一个敏感操作能不能停住。整个验证用假数据和测试工具就够，不必拿真实密钥冒险。

五、便宜模型、共享积分和本地推理，哪种才真能省钱？

做 AI 办公提效或内部自动化，成本往往分散在很多地方。模型费用最显眼，账号管理、运行等待和人工复查也会吃预算。

n8n 官方博客介绍的 Gateway credits，允许适用的自助式 Cloud 计划使用共享预付余额调用支持的模型和服务，减少分别创建供应商账号、配置 API Key 的步骤。

我会把它看成降低试用和管理成本的更新。官方表达了遵循供应商公开价格、便利性不额外溢价的目标，但实际选型仍得按可用服务和对应费率算。少管理几个 Key 很舒服，却不等于工作流自然变便宜。

本地推理则是另一种账。

关于 Colibri 的技术文章描述了把 MoE 常用部分留在内存、路由专家按需从磁盘加载的办法。文中给出的例子涉及约 372 GB 专家权重存储，以及每秒约一到两个 token 的生成速度。

「桌面上跑 744B」很容易让人兴奋，但这个速度不能跳过。它能否用于批量任务，取决于完成时限和吞吐要求；能否用于交互，也得看用户愿意等多久。

还有一个细节，文章虽然强调放置策略，例子里仍用了 int4 权重表示，不能理解成完全没有量化。按需加载解决的是驻留安排，不会把磁盘容量和读取时间变没。

对比之下，S3 成本 Agent 的方案更像一个适合业务团队借鉴的分工。确定性代码收集存储证据，LLM 判断用途、解释策略，最后生成 Terraform PR，交给已有流水线审查和应用。

Agent 不直接持有删除对象的权限，这个约束很有用。不过，生命周期规则应用后仍可能导致删除，不能把「Agent 没有删除权限」理解成整个流程没有数据风险。

回到成本，我更关心每完成一个合格任务花多少，而不是每百万 token 看起来多便宜。

下面这段 JavaScript 把失败重试也算进支出，只用通过验收的任务数作为分母。

export function costPerAcceptedTask(runs, hourlyRateYuan) {
  const accepted = new Set(
    runs.filter(run => run.accepted).map(run => run.taskId)
  );

  const totalYuan = runs.reduce((sum, run) => {
    return sum
      + run.apiYuan
      + run.computeYuan
      + run.reviewMinutes / 60 * hourlyRateYuan;
  }, 0); // 失败与重试不能从成本里删掉。

  return accepted.size ? totalYuan / accepted.size : null;
}

最容易翻车的是 accepted 的口径，同一个任务的多次运行要共用任务标识，验收标准也得一致，否则便宜只是统计出来的。

今天选一个已有自动化流程，把模型费用、重试和复查时间记下来就能开始比较。若要试本地推理，再补上机器占用和完成时间，不用为了省调用费先买一套硬件。

六、AI 编程助手恢复了聊天，为什么还是会把需求做偏？

大概率你也遇到过，历史对话明明还在，继续任务时却得重新解释已经定下来的事。

五种编程工具的会话恢复讨论把几个问题拆开了。回到原会话、新会话加载项目规则，以及长期积累任务记忆，并不是同一种能力。

这个区分对工具选型很有帮助。有恢复入口，不代表所有运行配置都能跟着回来；新会话会读编码规范，也不代表它知道上一个任务为什么放弃某个方案。

所以，VS Code 的跨应用会话延续解决了一部分使用摩擦，但团队仍需要一个能在对话之外确认需求的位置。

OpenSpec 的项目介绍把重点放在创建、管理软件规格，让团队和编码 Agent 在工作过程中保持一致。它更接近需求协作工具，不能只看「AI 框架」几个字就把它当成通用模型评测系统。

codsh 0.23 的发布文章则描述了更硬的约束。确认后的目标、范围外事项和验收标准被写进 Mission Contract，写操作需要有需求映射，交付还要提供证据。

我赞成把这些内容落到文件里。对于一个持续几小时甚至跨天的任务，目标不能只靠对话摘要维持。

但写进文件不等于已经解决目标漂移。描述本身可能含糊，需求映射也可能只是勉强挂上关系。比如需求只要求修复筛选状态，Agent 顺手重写整个状态管理层，再把它标成「改善筛选」，形式上有映射，实际范围已经扩了。

验收标准要能拒绝结果，才有约束力。

前端项目很适合把要求写具体一些。筛选条件是否进 URL、刷新后是否恢复、空结果怎么显示、返回上一页是否保留状态，这些比「优化用户体验」更容易验证，也更容易交接给另一个 Agent。

今天挑一个半天以内的改动，把目标、范围外事项和可观察结果写进仓库，再让全新会话只靠这些内容继续。若它还得反复问你聊天里已经讲过的决定，缺的就是可交接的信息；若它理解了却仍然越界，就要检查执行约束。

总结

今天能从官方材料里确认的，是 GitHub 披露了 Copilot 运行时的 Rust 迁移过程，Cloudflare 项目给出了分阶段审计和独立验证流程，n8n 发布了共享余额接入服务的方式。VS Code 的新能力来自媒体报道，具体使用仍要落到对应版本和环境上。

我的判断是，AI 编程接下来更值得投入的地方，是可复现环境、明确验收和受控执行。模型能力当然重要，但一个更强的模型，接进模糊需求和宽松权限里，返工也可能更贵。

Astra 的社区转述还不足以让我建议团队立即迁移；GLiFormer 的榜单成绩、本地大模型的低速运行，以及 U2-Flash 报道中的提效数字，也都没有替你的业务完成验证。

要我选，明天我会先拿一个真实任务，把需求、环境、权限和验收固定住，再比较两个候选方案。能稳定做完、出了问题能追查、总成本算得清楚，这样的工具才值得留下。

参考

一、AI 写了 80 万行代码，测试全绿就能合并吗？

先说结论，我最想从 Copilot 这次迁移里学的，是怎么拆交付。

至于「AI 已经可以独立完成大型重构」，我不认同这个转述。原文里有人拆任务、推进合并、处理回归，不能把这些劳动从账上抹掉。

代码生成规模变大了，验收责任还在人身上。

拿前端购物车举个例子，规格已经约定「金额按分计算，折扣不能让应付金额低于零」，就可以先把这些规则固定下来，再交给 Agent 改实现。

下面这段 JavaScript 用固定的业务样例约束待测函数，预期值不从实现里反算。

import assert from "node:assert/strict";

export function verifyPayable(calculatePayable) {
  const cases = [
    { subtotal: 10000, discount: 1500, expected: 8500 },
    { subtotal: 10000, discount: 12000, expected: 0 },
    { subtotal: 0, discount: 0, expected: 0 },
  ];

  for (const { subtotal, discount, expected } of cases) {
    // 输入与预期都来自已确认的业务规则，金额单位为分。
    assert.equal(calculatePayable(subtotal, discount), expected);
  }
}

最容易翻车的是 expected 那一列，如果它也是看着新实现填出来的，这个示例照样会变成自我证明。

二、VS Code 把 Agent 放进开发容器，能解决环境不一致吗？

写业务最烦的一类问题，是代码看起来没毛病，命令却跑在了另一套环境里。你以为它用了仓库要求的依赖，实际调用的可能是宿主机上的工具。

不过，容器里跑通也不能直接等同于 CI 跑通。两边的配置是否一致，仍然要看仓库怎么维护。

顺着上面聊，Cline 项目说明给出了另一个方向。CLI、桌面应用、VS Code、JetBrains 和 SDK 使用同一引擎，项目规则也可以在多个入口加载。

我喜欢这个方向。团队最不想维护的，就是编辑器里一份规矩，终端里又一份，自动化脚本还得重新解释一遍。

环境能复现，Agent 的结果才更容易复查。

三、GPT-6 Astra、U2-Flash 和小模型，业务项目该怎么选？

说实话，新模型名字越多，我越不想一上来就问谁最强。

今天关于 GPT-6 Astra 的信息来自 dev.to 的发布转述。文章称它主打扩展推理、多 Agent 协同和计算机操作，并分阶段向多个渠道开放。

协议兼容可以减少迁移工作，却没有替你回答工具调用是否稳定、复杂任务会重试几次。

这个数字得放在那个抽取任务里读。它不能说明两个模型的编程能力接近，更不能证明业务里可以直接替换。

如果需求是从工单里提取产品、故障和关联记录，这条路线值得研究；如果需求是结合隐含信息给出处理建议，单纯抽取就未必够了。

选型先分任务，再比分数。

四、Agent 能读网页又能改代码，权限边界到底放在哪？

这里有个坑，接入的工具越多，Agent 读到的内容就越不能被一视同仁。

Apify MCP 接入文章介绍了通过托管 MCP 服务发现、调用爬虫和读取结果的方式。这类接入把实时网页数据带进了工作流，省掉了一部分手写集成。

但网页进来了，网页里的指令也可能一起进来。

所以，工具返回成功，只能说明调用完成，不能替返回内容背书。MCP 负责连接工具，也不会自动决定那段文本有没有权指挥后续操作。

我尤其喜欢中间那个状态。证据不够，就把缺的事实留出来，不用为了交一份漂亮报告硬凑结论。

独立验证也有边界。新的 Agent 可以减少前一段对话带来的影响，但仍可能犯相似错误，不能因为换了一个会话就当成验证完成。

五、便宜模型、共享积分和本地推理，哪种才真能省钱？

做 AI 办公提效或内部自动化，成本往往分散在很多地方。模型费用最显眼，账号管理、运行等待和人工复查也会吃预算。

本地推理则是另一种账。

「桌面上跑 744B」很容易让人兴奋，但这个速度不能跳过。它能否用于批量任务，取决于完成时限和吞吐要求；能否用于交互，也得看用户愿意等多久。

回到成本，我更关心每完成一个合格任务花多少，而不是每百万 token 看起来多便宜。

下面这段 JavaScript 把失败重试也算进支出，只用通过验收的任务数作为分母。

export function costPerAcceptedTask(runs, hourlyRateYuan) {
  const accepted = new Set(
    runs.filter(run => run.accepted).map(run => run.taskId)
  );

  const totalYuan = runs.reduce((sum, run) => {
    return sum
      + run.apiYuan
      + run.computeYuan
      + run.reviewMinutes / 60 * hourlyRateYuan;
  }, 0); // 失败与重试不能从成本里删掉。

  return accepted.size ? totalYuan / accepted.size : null;
}

最容易翻车的是 accepted 的口径，同一个任务的多次运行要共用任务标识，验收标准也得一致，否则便宜只是统计出来的。

六、AI 编程助手恢复了聊天，为什么还是会把需求做偏？

大概率你也遇到过，历史对话明明还在，继续任务时却得重新解释已经定下来的事。

五种编程工具的会话恢复讨论把几个问题拆开了。回到原会话、新会话加载项目规则，以及长期积累任务记忆，并不是同一种能力。

所以，VS Code 的跨应用会话延续解决了一部分使用摩擦，但团队仍需要一个能在对话之外确认需求的位置。

codsh 0.23 的发布文章则描述了更硬的约束。确认后的目标、范围外事项和验收标准被写进 Mission Contract，写操作需要有需求映射，交付还要提供证据。

我赞成把这些内容落到文件里。对于一个持续几小时甚至跨天的任务，目标不能只靠对话摘要维持。

验收标准要能拒绝结果，才有约束力。

AI雷达日报

今日看点

一、AI 写了 80 万行代码，测试全绿就能合并吗？

二、VS Code 把 Agent 放进开发容器，能解决环境不一致吗？

三、GPT-6 Astra、U2-Flash 和小模型，业务项目该怎么选？

四、Agent 能读网页又能改代码，权限边界到底放在哪？

五、便宜模型、共享积分和本地推理，哪种才真能省钱？

六、AI 编程助手恢复了聊天，为什么还是会把需求做偏？

总结

参考

AI雷达日报

今日看点

一、AI 写了 80 万行代码，测试全绿就能合并吗？

二、VS Code 把 Agent 放进开发容器，能解决环境不一致吗？

三、GPT-6 Astra、U2-Flash 和小模型，业务项目该怎么选？

四、Agent 能读网页又能改代码，权限边界到底放在哪？

五、便宜模型、共享积分和本地推理，哪种才真能省钱？

六、AI 编程助手恢复了聊天，为什么还是会把需求做偏？

总结

参考