隔离配置后，框架文档还能带动编程代理吗

给 AI 一份框架文档，它能独立把功能做出来吗？Kumiko 团队重新做了一轮隔离评测：清空自家配置，让编码 Agent 只接触应用、依赖和任务说明。Sonnet 5.5 完成了全部四项任务；两个本地模型只做最简单的一项，一个用了 50 分钟通过，另一个运行 60 分钟后超时。

比模型输赢更有参考价值的是：评测器先坏了，文档也引用了过期 API，而强模型仍然能补齐缺口。对正在维护 AGENTS.md、选择本地模型的程序员来说，这次实验展示了怎样验证文档，也暴露了「测试全绿」容易掩盖的问题。

文档够不够用，先把团队配置拿掉

Kumiko 是面向多租户应用的 TypeScript 框架，基于 Bun、Hono 和 Postgres。从 0.364.0 开始，npm 包内附带 AGENTS.md，以及自动生成的功能、组件和示例应用索引。

他们此前已经测过四项任务，但 Agent 继承了团队自己的 Claude Code 配置。成功究竟来自包内文档，还是额外的 skills、规则和记忆，无法区分。

这轮评测从已发布的 0.393.0 包创建全新应用，在项目目录运行 claude -p，客户端为 Claude Code 2.1.310，并将 CLAUDE_CONFIG_DIR 指向空临时目录。Agent 可以读取应用和 node_modules，但看不到框架源码仓库。

四项任务分别是：创建带 CRUD 和列表页的实体、自定义写入处理器、带统计信息的概览页，以及接入内置 tags 功能。

完成后，评测器才复制隐藏验收测试，执行八项检查：类型检查、lint、单元测试、启动、schema 校验、连接真实 Postgres 的验收测试，以及两次 guard 检查。

隔离评测回答的是：拿掉团队私有配置后，发布出去的包是否仍然足以支撑任务。

第一轮全失败，问题却在评测器

隔离后的 Sonnet 首轮四项全失败，作者检查后发现，Agent 写出的代码没问题，评测器已经跟不上框架变化。

验收模板仍从 @cosmicdrift/kumiko-testing 导入 setupAppTestStack 和 seedTenant，而这两个辅助函数早已迁到 @cosmicdrift/kumiko-dev-server/testing。

另一处问题出在 bunx kumiko-guards@0.393.0。这个命令独立安装 guards 包，但该包引用了未声明的 @cosmicdrift/kumiko-types，检查尚未开始就崩溃。在正常应用里，这个依赖碰巧会被框架带进来，因此问题一直藏着。

他们修正了测试模板，让评测器使用项目已经安装的 guards，并补上缺失依赖，对应 kumiko-framework#4074。后续结果均来自修复后的评测器。

更有意思的是，Sonnet 在任务 02 的报告中指出：AGENTS.md 也写错了上述两个函数的包名。它从脚手架测试中找到可用导入，继续完成任务。文档随后在 kumiko-framework#4075 中修复。

这说明测试代码和文档可能一起过期。两边引用一致，并不能证明它们与当前版本一致。

本地模型的单轮速度，解释不了最终结果

修复评测器后，Sonnet 5.5 四项全部通过，每项耗时均不到五分钟，总费用为 $0.82。规则扫描只有一处命中：任务 04 的字符串里出现了 any，属于误报。

作者还定义了「响应时间」：从模型收到提示或工具结果，到答案最后一个区块输出完成，按流式时间戳计算。这个指标不能直接当作整个任务耗时。标题中的 99 秒，正文没有给出足够明细说明它对应哪项结果。

两个本地模型使用同一个 Claude Code 客户端，通过兼容 Anthropic 的本地端点调用。机器是 M4 Pro，统一内存 48 GB，GPU 可用约 37 GiB。

第一组为 Strata 0.2.6，运行 Q2_0 量化的 qwen3.8-flash-next，上下文 128K。权重达 66 GB，无法完整放进 GPU 内存，但仍能运行：输出约 4.5 tokens/s，读取提示约 9 tokens/s。每次请求携带 39k 到 43k tokens，几乎全部依赖提示缓存。首次响应耗时四分半，最慢一次回答用了五分钟。

它最终用 50 分钟完成任务 01，八项检查全绿，规则扫描无命中。

第二组是 Ollama 0.31.2 上的 Qwen3.5 9B，上下文 64K，模型大小 6.6 GB，能够完整放入 GPU，单轮回答更快。

但它撞上了 60 分钟上限，只通过两项 guards。这两项对几乎没改动的应用也会通过。应用因 Export named 'contactsFeature' not found 无法启动；过程中，模型还把功能代码写进 .gitignore，反复重写相同文件，Claude Code 两次压缩上下文。

在这一次运行里，更大的重度量化模型赢了。但证据只能到这里：每个模型对每项任务只运行一次，本地模型只做最简单的任务 01；本地每次响应最多输出 4,096 tokens，Sonnet 没有这个限制，上下文窗口也不一致。Strata 的耗时还高度依赖缓存。

我的判断

这轮实验最扎实的部分，是排除了团队配置干扰，并通过真实数据库和启动检查验证交付结果。相比只看生成代码是否像样，这套检查更接近日常开发的要求。

但「包内文档足够让 Sonnet 完成四项任务」，不能扩大成「文档已经完整」。Agent 还可以读取编译后的依赖代码，也可能猜对未写清的行为。

作者收集到的缺口很具体：personalData 在读取和排序时怎样处理，PII 字段能否默认排序，页面怎样注册到 client.tsx，create 返回什么，ne 过滤器会排除 NULL 行，以及「已经完成」应该使用哪个错误类。

tags 接入编辑页的方式、entityName 是否必填、示例误用框架内部测试初始化，以及 Strata 对 find 层级和行操作翻译键的疑问，也都没有阻止任务通过。

通过率衡量了模型与资料共同完成任务的能力，不能单独证明文档质量。

本地模型的结论同样要收窄。比起只按显存占用或 tokens/s 选模型，作者更关注最终能否交付，这个方向合理。但大模型低比特量化是否普遍胜过小模型，目前只是单次实验观察，没有重复运行和统一配置的对照数据。

能拿来做什么

• 维护框架或组件库时，可以用发布包创建全新应用，再清空 Agent 配置运行固定任务，检查文档是否依赖维护者机器上的隐性知识。
• 为 AI 编程建立验收流程时，应同时检查类型、启动和真实业务行为；guards 通过，只能说明相应规则没有报错。
• 选择本地编码模型时，可以记录任务完成率、总耗时、反复修改次数和缓存条件，再比较单轮生成速度。
• 每次评测结束后，可以要求 Agent 列出猜过的 API 和行为，并把这些疑问纳入文档修复，即使最终验收已经通过。