ZCode被曝尝试上传564次，AI编程权限如何审查

一个只读研究 Agent，按作者三个月的记录，把「调用了不存在的 API」这类 bug 从约每五个任务一次，降到了每四十个任务一次，额外 token 消耗不到 10%。另一边，编程工具却被曝在后台打包仓库，连 Git 历史也卷了进去。读完 2026 年 9 月 21 日这批 AI 热点，我更关心代码写出来前后发生了什么。这篇聊六条线，从权限、文档、测试到界面和模型成本，挑出程序员今天就能核对的工程问题。

一、AI 编程工具能读仓库，就能上传全部 Git 历史吗？

先说结论，允许工具理解项目，和允许它把整个项目做成云端快照，是两项不同的授权。

关于 ZCode 的报道里，研究者在本地数据目录发现了一个约 313MB 的加密归档，对应约 345MB 的工作区内容，状态记录显示曾尝试上传 564 次。这个大归档最终没有成功上传，但另一个更小的仓库快照显示已被服务器接收。报道还称，厂商在 9 月 18 日确认了上传行为。事件转述｜DEV

这几个细节得分开读。

不能把「发现上传流程」写成「所有用户的商业仓库都已经泄露」，也不能因为那个大文件上传失败，就认为没有数据到达云端。当前这份材料是对研究报告和厂商回应的转述，具体版本、触发条件和受影响范围，还得回到原始记录核对。

我更在意的是，快照究竟包含哪些文件，上传前用户有没有机会知道。

当前代码里删掉的配置，可能还留在 Git 历史里。如果权限说明只告诉你「读取项目以提供编程帮助」，实际执行却包含完整历史归档，团队很难据此判断数据边界。加密解决的是传输或存储环节的一部分问题，并不会自动补上用户授权。

能读文件，不等于能替用户决定文件去哪儿。

同一天另一条桌面工具消息，可以放在旁边一起看。Kimi Code Desktop 据报道支持 macOS 和 Windows，提供内置终端、浏览器、Git 状态和 PR 跟踪，也把已有 CLI 任务带进图形界面。IT之家

界面把执行过程展示出来，对审阅改动有帮助。但「能看到 Agent 改了哪些文件」和「能看到客户端上传了哪些数据」仍然是两种可见性。这里不是说 Kimi 存在同类行为，而是桌面客户端越来越像开发工作台之后，我们不能只审查聊天框里的操作记录。

回到这块，技术负责人选工具时，我会把后台同步、快照内容、历史记录和上传目的地一起问清楚。前端开发者也别只盯着补全准不准，工具拿到的项目权限可能比一次补全请求大得多。

今天就能做的小验证，是用一个没有真实业务数据的测试仓库，放入几个容易识别的文件，再提交、删除其中一个，观察客户端数据目录、日志和网络请求。这样至少能区分它处理的是当前文件，还是连历史对象也一起处理了。

二、AI 总在编造 API，怎么让它真的先读文档？

大概率你也遇到过，AI 写出来的方法名特别合理，合理到你甚至怀疑是不是自己没看过新版文档。

那篇研究 Agent 实践里，作者举的例子是 client.batchUpsert()。库里实际存在的是 v4.2 加入的 upsertMany()，参数结构也不一样。实现 Agent 猜错之后，修复 Agent 又尝试三次，消耗了约 40k tokens，最终仍把任务标成阻塞。研究 Agent 实践｜DEV

作者的调整很具体。研究 Agent 只有读取和检索能力，不能写文件；实现任务必须等研究简报生成后才能分发；简报需要短、结构化，并附带置信度。

按作者自己的三个月记录，幻觉 API bug 从约 20% 的任务降到约 2.5%，额外 token 消耗不到 10%。这个数值得关注，但它测的是一个特定系统里的特定故障，不能理解成「所有 AI 编程错误减少了八成多」。任务数量、任务难度是否一致，也会影响结果。

我喜欢的是这套约束。

「请先读文档」会被后面的上下文挤掉，编排器的前置条件却不会因为聊天变长就自动失效。不过，置信度仍然是模型给出的判断，简报文件存在也只能证明流程跑过，不能证明研究正确。依赖版本、原文位置和最小调用示例，比一个孤零零的高分更有用。

顺着上面聊，另一篇契约实践正好补上了后半段。作者记录了一次响应字段从 content 改成 items 的变更，前端和 19 个测试文件仍沿用旧字段。另一轮对 218 个前端 API 调用点的扫描，还发现了 22 个返回 HTTP 500 的后端端点。接口契约实践｜DEV

这些是作者项目里的记录，不能拿来推算普通团队的故障率。但问题很熟悉，模型可以读懂最新接口，也可能完全不知道哪些调用方还依赖旧行为。

文档解决 API 怎么用，契约解决这次改动不能弄坏谁。

要我选，我会把研究简报和仓库内的接口约束接起来。涉及的包版本、请求响应字段、错误分支、现有调用方，都需要能落到文件和测试上。单独再加一个 Agent，却继续让接口约定散落在聊天记录里，收益会很有限。

也不用给每个改文案任务都加研究阶段。陌生 SDK、跨版本升级、涉及多个调用方的接口调整，更值得付这笔成本。今天可以挑一个最近失败的依赖调用任务，要求实现前先列出版本、文档依据和受影响的调用点，再看这些信息有没有拦住原来的错误。

三、AI 写的代码和测试全绿，为什么还不能放心合并？

说实话，我对「代码写完了，测试也补了」这种交付越来越想追问一句，测试到底在保护什么？

一篇代码审查实践做了个很小的实验。原有八个测试全部通过，作者在临时副本里删除一个关键条件，结果变成七个通过、一个失败。这个条件限制了推送令牌只能由当前所有者删除。破坏不变量审查法｜DEV

业务场景并不复杂。设备令牌先属于 A，后来转移到 B，此时 A 的延迟注销请求到了，系统必须保留 B 的令牌。测试需要保护的就是这个条件，而不是笼统地验证「注销接口返回成功」。

下面用一个最小 JavaScript 例子说明这类测试在拦什么。

import assert from "node:assert/strict";

const tokens = [
  { token: "android-1", owner: "B" },
  { token: "ios-1", owner: "A" },
];

function unregister(rows, actor, token) {
  return rows.filter(
    row => !(row.token === token && row.owner === actor)
    // owner 条件防止旧账号删掉已转移的令牌
  );
}

assert.deepEqual(
  unregister(tokens, "A", "android-1"),
  tokens
);

最容易翻车的是 row.owner === actor 这一行，把它删掉后断言应该失败；如果仍然通过，就要检查测试有没有真正执行到待审查的实现。

这段只是说明方法。原文里的验证更扎实，测试运行真实路由器并读取 libSQL 测试数据库中的记录，外部 HTTP 才被 mock。它证明的是那个删除条件确实受到测试保护，并没有证明整套权限系统都安全。

再看另一篇关于测试冻结的文章，问题往前走了一步。如果 AI 可以同时改实现、改 fixture、改验收依据，测试全绿有可能只是标准跟着答案一起变了。作者提出保存随机种子、失败时的最小输入、fixture 内容哈希，以及绑定异常类型和消息摘要的失败记录。测试失败特征与冻结｜DEV

这里有个坑，把测试文件设成只读，并不能自动得到一套可靠测试。它只是防止执行者修改某些验收材料；材料本身是否覆盖业务风险，仍然要由人判断。异常消息变化也可能来自无害重构，不能见到摘要不同就断言出现了新漏洞。

但这两篇放在一起，对 AI 编程的审查很有启发。关键业务约束要能被反例击穿，验收输入要能重放，重要的测试依据还要有独立维护边界。

测试变红，有时比测试变绿更能说明问题。

今天审一个 AI 生成的 diff，可以只挑一个最重要的条件，在临时副本里故意移除它。权限过滤、金额上限、重复提交保护都适合；看见测试准确失败，再恢复实现，比继续让模型补十个只验证正常路径的用例更有信息量。

四、Agent 调错工具、超时重试，应用应该在哪儿拦住它？

你要是也在做 Agent，应该把「模型选了一个合法工具」和「这次调用符合用户意图」分开看。

关于工具路由的文章举了一个很好的例子。用户问「我能把预约改到周四吗」，可能只是查询可用时间，也可能准备执行改约。查询工具和修改工具都能接住这句话，但副作用完全不同。工具路由边界｜DEV

工具名选对、JSON 格式正确、请求返回成功，这三个条件加起来，仍然不足以证明用户授权了修改。

另一篇架构文章主张，把验证循环、严格工具 schema 和不可逆操作的人工确认放进系统。Agent 架构与容错｜DEV

我认可这个方向，不过人工确认也要有内容。一个只写「是否继续」的按钮，没告诉用户将改哪条记录、付多少钱、发给谁，确认价值很低。模型负责提出操作，业务代码仍然要根据登录身份、资源归属和当前流程状态决定能不能执行。

防御式架构的另一份实践，把参数范围限制为 1 到 10，并给外部调用设置了四秒超时，失败时返回空数组。Schema 与超时实践｜DEV

这套思路能借，四秒不必照抄。搜索、文件分析和长任务的耗时特征不同；失败时统一返回空数组，也容易把「服务不可用」包装成「没有查到任何内容」。

下面这段 JavaScript 把只读搜索的参数校验、超时和错误状态分开，避免上层拿着一个空结果继续猜。

async function searchDocs(input) {
  if (
    typeof input?.query !== "string" ||
    !input.query.trim() ||
    !Number.isInteger(input.limit) ||
    input.limit < 1 ||
    input.limit > 10
  ) {
    return { ok: false, reason: "invalid_arguments" };
  }

  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), 4000);

  try {
    const response = await fetch("/api/docs/search", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(input),
      signal: controller.signal,
    });

    if (!response.ok) {
      return { ok: false, reason: "upstream_http", status: response.status };
    }

    const data = await response.json();
    if (!Array.isArray(data.items)) {
      return { ok: false, reason: "invalid_response" };
    }
    return { ok: true, items: data.items };
  } catch {
    return {
      ok: false,
      reason: controller.signal.aborted ? "timeout" : "request_failed",
    }; // 保留失败原因，不让模型把故障当成零条结果
  } finally {
    clearTimeout(timer);
  }
}

最容易翻车的是把 abort() 当成服务端工作已取消，它只能发出客户端中止信号；后端耗时任务还需要自己的截止时间和取消机制，返回条目的字段也需要进一步校验。

回到业务里，单次请求超时还不够。Agent 如果一直重试，照样能把总耗时和成本抬上去，所以任务级别还得有尝试次数和预算上限。写操作涉及重试时，也要处理重复执行。

今天可以拿十句模糊请求做路由回放，再给外部服务分别注入超时、429 和格式错误。重点看系统会不会误触发写操作，以及它告诉用户的是「没有数据」还是「这次查询失败」。

五、AI 生成 UI，怎样才能不把前端变成临时代码堆？

今天前端相关的几个项目，我最想放在一起看的是 Agent-Native 和 JSON-Render。

Agent-Native 的做法是把业务能力定义为共享 action。模型把它当工具调用，UI 从代码里调用，两条路径共用验证、权限和实现，还能共享应用状态。Agent-Native｜GitHub

JSON-Render 则把生成范围限制在预定义组件和动作里。模型生成结构，由相应渲染器交给 React、Vue、Svelte、React Native 等目标处理，而不是每次都自由写一套组件代码。JSON-Render｜GitHub

这两个方向解决的问题不同，但可以接到同一个产品里。共享 action 管业务操作，受约束的渲染结构管界面表达。用户在界面里选中了哪条记录，Agent 能读到；Agent 生成的结果，用户可以在已有界面中继续编辑和确认。

我更看好这种适合审阅的产品形态。

比如做 AI 办公提效，模型整理出一份客户跟进建议，业务人员需要检查对象、调整内容、决定是否发送。比起让用户在聊天记录里找最终版本，一个能编辑、能展示差异、能明确提交范围的界面，更接近日常工作。

组件白名单限制展示范围，业务权限仍然要在执行层检查。

别把「输出 JSON」理解成「输出安全」。合法结构里也可能有错误的客户 ID、不合适的链接，或者用户没有权限执行的 action。结构校验拦格式问题，授权检查拦越权问题，内容是否符合任务还需要另一层判断。

远程 MCP 编排应用内公告的案例，也走了类似路线。模型提交公告内容、目标插槽和触发条件，客户端按规则决定什么时候展示，不必为每次运营公告临时加一个 React 组件。MCP 应用内编排｜DEV

这里我会保留一点距离。它是具体产品的实践介绍，规则化渲染并不能承诺所有场景都没有水合问题，也不能让内容发布天然无需审查。适用范围越清楚，收益越容易判断，公告、引导和固定报表比任意页面生成更适合先试。

今天可以挑一个已有公告弹窗，只允许模型填写标题、正文和按钮，目标位置仍由现有组件负责。然后故意给它未知组件名、未授权动作和不允许的链接，看错误到底在生成端、服务端还是渲染端被拦下。

六、1M 上下文和低价小模型，哪个更能降低 Agent 成本？

Step 5 Preview 的规格很吸引人。按报道，它采用 MoE 架构，总参数约 600B，每个 token 激活约 27B，支持 1M token 上下文，输入价格为每百万 token 1 美元，权重计划在 10 月 15 日开放。Step 5 Preview 报道｜MarkTechPost

另一篇报道提到，它在 Artificial Analysis 的评测中取得 44 分，并展示了 Blender 和游戏生成任务。Step 5 实测报道｜量子位

先把两个容易误读的地方划开。

截至这期日报的 9 月 21 日，计划开放权重不等于权重已经发布。「激活 27B」也不等于你只需要装下 27B 参数。按 600B 参数、BF16 每参数两字节粗算，单是权重就约 1.2TB，还没算 KV 缓存和其他运行开销。因此，不能从激活参数直接推导出普通消费级设备能轻松部署。

长上下文同样需要带着任务看。1M token 给了代码库级任务更大的输入空间，但能装进去多少内容，与模型能否找到关键依赖、正确修改并通过验收，是两回事。一次输入百万 token 的标价，也没有覆盖后续输出、推理和重复调用的全部成本。

另一个方向是 Jev。它的评测作者记录了约 22,500 次 API 调用、52.2M 输入 tokens 和 2.19 美元总成本，并把它定位成意图分类、工具选择等窄决策的候选模型。Jev 工程评测｜DEV

标题里的约 0.3 秒、每次约 0.00004 美元，不能当所有请求的固定承诺。输入长度会影响费用；原文也列出了约 32k tokens 的共享输入限制、纯文本输入和英语优先等边界。

我尤其不会把「安全命令放过率高」直接理解成「危险命令拦得住」。这是两个分母，判断权限风险时必须分别看漏报和误报。

所以我的取舍是，复杂改代码任务值得测试大模型，频繁而狭窄的路由问题值得测试小模型。前提是路由失误不会绕过执行层权限。小模型可以建议调用哪个工具，不能因为便宜、快，就接管最终授权。

今天真要决定换不换，我会选仓库最近二十个有明确验收结果的任务，固定工具权限、输入材料和重试上限。除了首轮成功率，还要记下最终验收通过率、总费用、耗时和人工修改量；路由模型另加一组中文模糊请求，看节省的调用费用有没有被后续返工吃掉。

总结

这批消息里，能从给出的原文摘录明确读到的是，Agent-Native 提供共享 action，JSON-Render 围绕预定义组件生成界面，研究 Agent 作者记录了自己的故障变化，Step 5 Preview 的报道列出了规格和后续开放权重计划。这些内容的证据层级不同，项目说明能说明设计意图，个人实验只能说明对应条件下的结果。

我的判断是，AI 编程接下来值得花时间的地方，会更多落在任务入口和验收出口。入口写清楚文档、契约、权限，出口检查实际结果、保留失败原因，再把可审阅的过程呈现在界面里。模型能力提升当然有用，但团队最终支付的是完成任务的费用，也包括失败后的重试和人的返工。

还不能直接下结论的部分，也别急着替它们补齐。研究 Agent 的降错幅度能否复现到你的仓库，Step 5 能否替换现有模型，ZCode 事件究竟覆盖哪些版本和用户，都需要各自的验证。

要我今天只挑一件事，我会找一个 AI 刚提交、测试全绿的改动，故意破坏其中最关键的业务条件。

看看测试到底会不会替你报警。

参考

一、AI 编程工具能读仓库，就能上传全部 Git 历史吗？

先说结论，允许工具理解项目，和允许它把整个项目做成云端快照，是两项不同的授权。

这几个细节得分开读。

我更在意的是，快照究竟包含哪些文件，上传前用户有没有机会知道。

能读文件，不等于能替用户决定文件去哪儿。

二、AI 总在编造 API，怎么让它真的先读文档？

大概率你也遇到过，AI 写出来的方法名特别合理，合理到你甚至怀疑是不是自己没看过新版文档。

作者的调整很具体。研究 Agent 只有读取和检索能力，不能写文件；实现任务必须等研究简报生成后才能分发；简报需要短、结构化，并附带置信度。

我喜欢的是这套约束。

这些是作者项目里的记录，不能拿来推算普通团队的故障率。但问题很熟悉，模型可以读懂最新接口，也可能完全不知道哪些调用方还依赖旧行为。

文档解决 API 怎么用，契约解决这次改动不能弄坏谁。

三、AI 写的代码和测试全绿，为什么还不能放心合并？

说实话，我对「代码写完了，测试也补了」这种交付越来越想追问一句，测试到底在保护什么？

下面用一个最小 JavaScript 例子说明这类测试在拦什么。

import assert from "node:assert/strict";

const tokens = [
  { token: "android-1", owner: "B" },
  { token: "ios-1", owner: "A" },
];

function unregister(rows, actor, token) {
  return rows.filter(
    row => !(row.token === token && row.owner === actor)
    // owner 条件防止旧账号删掉已转移的令牌
  );
}

assert.deepEqual(
  unregister(tokens, "A", "android-1"),
  tokens
);

最容易翻车的是 row.owner === actor 这一行，把它删掉后断言应该失败；如果仍然通过，就要检查测试有没有真正执行到待审查的实现。

但这两篇放在一起，对 AI 编程的审查很有启发。关键业务约束要能被反例击穿，验收输入要能重放，重要的测试依据还要有独立维护边界。

测试变红，有时比测试变绿更能说明问题。

四、Agent 调错工具、超时重试，应用应该在哪儿拦住它？

你要是也在做 Agent，应该把「模型选了一个合法工具」和「这次调用符合用户意图」分开看。

工具名选对、JSON 格式正确、请求返回成功，这三个条件加起来，仍然不足以证明用户授权了修改。

另一篇架构文章主张，把验证循环、严格工具 schema 和不可逆操作的人工确认放进系统。Agent 架构与容错｜DEV

防御式架构的另一份实践，把参数范围限制为 1 到 10，并给外部调用设置了四秒超时，失败时返回空数组。Schema 与超时实践｜DEV

下面这段 JavaScript 把只读搜索的参数校验、超时和错误状态分开，避免上层拿着一个空结果继续猜。

async function searchDocs(input) {
  if (
    typeof input?.query !== "string" ||
    !input.query.trim() ||
    !Number.isInteger(input.limit) ||
    input.limit < 1 ||
    input.limit > 10
  ) {
    return { ok: false, reason: "invalid_arguments" };
  }

  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), 4000);

  try {
    const response = await fetch("/api/docs/search", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(input),
      signal: controller.signal,
    });

    if (!response.ok) {
      return { ok: false, reason: "upstream_http", status: response.status };
    }

    const data = await response.json();
    if (!Array.isArray(data.items)) {
      return { ok: false, reason: "invalid_response" };
    }
    return { ok: true, items: data.items };
  } catch {
    return {
      ok: false,
      reason: controller.signal.aborted ? "timeout" : "request_failed",
    }; // 保留失败原因，不让模型把故障当成零条结果
  } finally {
    clearTimeout(timer);
  }
}

五、AI 生成 UI，怎样才能不把前端变成临时代码堆？

今天前端相关的几个项目，我最想放在一起看的是 Agent-Native 和 JSON-Render。

我更看好这种适合审阅的产品形态。

组件白名单限制展示范围，业务权限仍然要在执行层检查。

六、1M 上下文和低价小模型，哪个更能降低 Agent 成本？

另一篇报道提到，它在 Artificial Analysis 的评测中取得 44 分，并展示了 Blender 和游戏生成任务。Step 5 实测报道｜量子位

先把两个容易误读的地方划开。

我尤其不会把「安全命令放过率高」直接理解成「危险命令拦得住」。这是两个分母，判断权限风险时必须分别看漏报和误报。

总结

要我今天只挑一件事，我会找一个 AI 刚提交、测试全绿的改动，故意破坏其中最关键的业务条件。

看看测试到底会不会替你报警。

AI雷达日报

今日看点

一、AI 编程工具能读仓库，就能上传全部 Git 历史吗？

二、AI 总在编造 API，怎么让它真的先读文档？

三、AI 写的代码和测试全绿，为什么还不能放心合并？

四、Agent 调错工具、超时重试，应用应该在哪儿拦住它？

五、AI 生成 UI，怎样才能不把前端变成临时代码堆？

六、1M 上下文和低价小模型，哪个更能降低 Agent 成本？

总结

参考

AI雷达日报

今日看点

一、AI 编程工具能读仓库，就能上传全部 Git 历史吗？

二、AI 总在编造 API，怎么让它真的先读文档？

三、AI 写的代码和测试全绿，为什么还不能放心合并？

四、Agent 调错工具、超时重试，应用应该在哪儿拦住它？

五、AI 生成 UI，怎样才能不把前端变成临时代码堆？

六、1M 上下文和低价小模型，哪个更能降低 Agent 成本？

总结

参考