--- layout: post.njk source: https://yage.ai/share/product-ai-friendliness-eval-20260802.html speaker: yage.ai title: |- 当产品不仅给人用，也给 AI 用：如何评估你产品的 AI 亲和度？ date: '2026-08-02' summary: 文章探讨了如何评估产品的 AI 亲和度，强调当产品不仅为人可用也需为 AI 可用时，必须建立量化、动态的评估体系。核心观点是应从关注通用模型榜单转向建立面向自家产品的纵向回归机制，通过静态 Lint 与动态执行的双层测试架构，将测试失败转化为产品改进的信号，最终实现 AI 亲和度的闭环优化。 area: tech-engineering category: ai-application tags: - ai-evaluation - agentic-workflow - dynamic-testing - product-feedback people: [] companies_orgs: [] products_models: - Supabase - Stripe media_books: [] draft: true status: evergreen --- 前段时间在《大航海时代，别再跟 AI 比划桨了》里，我们聊过一个很核心的转变：在 AI 时代，咱们技术人最大的范式升级，其实是别再像以前那样手把手替 AI 比划桨，而是建立起明确的授权与工具体系，把 AI 真正当成能独立干活的虚拟雇员。但说实话，当大家真正试着去落地这种授权时，几乎无一例外都撞到了同一面墙上。很多团队在给 AI 安排工程任务时发现，只要让 AI 试着调用自家的 SDK、命令行工具或者 API，过程就变得非常脆弱。AI 经常理解错 API 参数的隐藏约束，或者在声明式架构里手写出一堆不规范的数据库迁移脚本，甚至因为报错信息不够明白直接卡在半路无法继续。 遇到这种执行卡顿的情况，大家第一反应通常是觉得模型还是不够聪明，想着干脆等等下一代更强大的大模型算了。但如果我们真抽空去调取 Agent 的运行轨迹和调试日志，就会发现一个被长期忽视的尴尬现实：很多时候真不是模型智商不够，而是我们自家的产品在接口设计、报错反馈和文档组织上，对 AI 实在是太难用了。从授权 AI 干活到 AI 真的把活干妥，中间其实隔着一道硬关卡，那就是产品本身的 AI 亲和度。如果我们构建的产品未来不仅是给人用的，也是给 AI 用的，我们就得好好聊聊怎么去量化、评估并一步步改进产品的 AI 亲和度。 ### 现代产品的二元化使用者结构 回想一下过去几十年，咱们做开发者软件和 SaaS 产品时，脑子里的用户画像其实只有一种，就是坐在屏幕前的人类工程师。所有的 Web 控制台、交互界面、命令行输出格式，包括官方文档，都是按照人类的习惯、认知节奏和搜索习惯来设计的。人类开发者读文档时有很强的推断能力，遇到写得含糊的地方能靠经验脑补，看到简陋的报错信息也会习惯性地去 Google 或社区论坛搜一搜。但随着 Cursor、Claude Code、Codex 和 OpenCode 这些工具天天挂在大家的开发环境里，产品的实际使用者悄悄分化成了两拨人。 在《超越DRY：AI原生软件工程的思考》一文中，我们就曾探讨过这个趋势：AI 不再仅仅是协助人类敲代码的辅助插件，而是正在成为软件系统的一等公民用户。 2026 年 7 月 31 日，Supabase 在官方博客上开源了评测框架 supabase/evals，并在公开结果页放出了最新跑分。他们在文章里提到一个关键细节：Agent 已经成了开发者使用 Supabase 的主要方式之一。这些 Agent 每天都在频繁调用 Supabase 的 CLI 命令行、MCP Server、Agent Skills 以及 Markdown 格式的官方文档。这就意味着，现代产品的接口端其实正面对着两类使用者：一类是靠经验和直觉干活的人类工程师，另一类则是主要依赖上下文输入、缺乏现实经验的 AI Agent。人类能容忍文档里的隐式假设，但 Agent 必须依赖确切的规范、结构化的报错和精准的索引。如果产品本身缺少对机器的表达能力，Agent 就会在建 Schema、配置数据库 RLS 权限策略或者部署 Edge Functions 边缘函数时频繁试错、反复陷入死循环。 ### 破除迷思：看通用榜单 vs 建立纵向回归 Benchmark 的被测对象从 Agent 翻转到产品本身 面对 AI 在自家产品里经常遇到卡顿的情况，技术团队的第一直觉，往往是想去找一套现成的测试标准，来看看到底是谁不行。但这恰恰是绝大多数人踩到的第一个坑：大家第一反应通常是跑去翻 SWE-bench、MMLU 或者 LMSYS 这些公关榜单，指望换个排名更高的通用模型救场。但老实说，通用模型榜单测的是模型的通用代码能力上限，无法回答模型在特定产品架构里能不能把活干对。每个产品的工程细节差异太大了——无论是 Supabase 的权限策略配置、Stripe 的支付流程对接，还是 Convex 的数据响应式建模，都超出了通用榜单能测的范围。 正因如此，顶尖的 AI-Native 公司早已不再看通用榜单说话，而是开始给自家产品建立专属的评估体系。例如 Stripe 在 2026 年 3 月 2 日发布了支付集成基准测试，并在开源仓库 stripe/ai/benchmarks 里公开了包含 API 迁移、SDK 升级、Checkout 接入、Subscriptions 订阅管理以及全栈浏览器流的真实测试环境；Convex 在开源项目 get-convex/convex-evals 里整理了 8 类典型后端任务，并在公开排行榜里说明，他们通过配置文件每 4 小时自动跑一次评测，用版本哈希锁死测试集，持续用测试结果来调优官方开发者指南。这里面有个非常关键的转折：做自家产品的 AI 评估，目的并不是为了发出一张横向与竞品对比的公关榜单。真正有价值的 Benchmarking 是看自己的东西——建立面向自家产品的纵向回归机制。我们不跟外部竞品比高低，只看随着自家产品文档、CLI 指引或者 Skill 规范的改进，AI 在自家场景里的任务成功率是不是在稳定上升。 ### 被测对象是产品，修的也是产品 一旦从看通用榜单转向建立自家产品的纵向回归，团队的思考方式就会发生一个重要转变：当自动化评测在沙箱里跑失败时，大家不再习惯性地埋怨 AI 不够聪明，而是发现真正的被测对象其实是产品本身。Supabase 在跑 supabase/evals 时，记录下了几个很有价值的修复案例：官方原本提供了一个 Postgres 最佳实践的 Agent Skill，但在初始沙箱实测里成功率只有约 10%，团队随后重写了描述文本，激活率提升到了 60% 左右；在数据库迁移测试里 Agent 乱写迁移脚本，团队修正了 Skill 里的指导指引，引导 Agent 行为收敛到标准流程；当 Agent 使用 @supabase/server 包混淆概念时，团队新增了 Which package to choose 文档指南；团队还追踪了不同 Agent 工具链（MCP Server 与 Web 检索）在读文档时的页数与路径，精准区分是知识缺失还是检索行为偏差。 无独有偶，Stripe 在跑自己的集成评测时，也明确表示评测系统直接暴露并帮助团队修复了官方文档里此前没发现的多处 Bug。这些例子非常直观地说明了一个道理：测试失败并不意味着模型有缺陷，而是产品接口和文档设计有漏洞。评估系统就像是给产品安装了一台自动化检修仪，每一次失败都在指明产品侧具体该修哪里。 ### 区分静态门槛与动态执行 但在具体搭建这套检修仪时，很多人又会掉进第二个陷阱：混淆了表面格式检查与真实任务执行，被一些静态打分工具的表面分数带偏了方向。比如 2026 年 4 月出现的 Fern Agent Score 或者 Mintlify Agent Score，这类工具就像是针对网站文档的 Lighthouse 扫描，主要检查 llms.txt 在不在、路径格式规不规范、OpenAPI 描述充不充分等静态门槛。在 Fern 的扫描中，Supabase 的文档站曾被打出了 72/100 的低分；Mintlify 也给出了 81/100 的分数。单看这些静态得分，好像 Supabase 对 AI 不够友好。然而在 Supabase 自己的端到端动态测试里，Agent 在真实 Docker 沙箱里建表、配置权限和部署边缘函数的任务成功率却高达 95% 到 100%。 这种看似矛盾的反差，恰恰说明了静态门槛与动态执行的区别。静态门槛回答的是产品的机器入口好不好找、店门有没有开，适合放在 CI 流程里做代码规范检查，但保证不了 Agent 拿到文档后能把复杂的工程代码写对；动态执行回答的是 Agent 在沙箱里能不能真正把复杂任务做对，需要在真实的容器或虚拟机里派发任务，用确定性的测试代码去校验最后的数据库状态和系统行为。Mintlify 自己在 2026 年 7 月 17 日发表的文档 URL 探索实验（开源于 docs-url-discovery-bench）也证实了这一点：在 20 个文档站上跑的 2,400 次真实 Agent 检索表明，真正消除检索 404 错误的关键在于提供清晰的 Index 和 URL Map，而不单单是把 HTML 转成 Markdown。所以说，咱们千万不能用静态扫描的分数去替代端到端动态测试。静态检查负责看门槛合不合规范，动态评测才负责验证任务能不能最终干对。 ### 不要迷信最新技术，跟着 Evaluation 找到最适合的架构 既然确认了必须靠动态执行来验证，不少团队在改进产品时又会走入第三个误区：盲目追捧各种听起来最新颖、最复杂的 AI 交付概念。在实际开发中，大家很容易产生一种隐性的技术鄙视链，觉得在提示词里写指令已经是 2023 年的老土做法，既然进入了 Agent 时代与 AI-Native 流程，就必须用上最新的 Agent Skill、MCP Server 或者各种 Plugin。但工程上的硬道理是黑猫白猫抓到老鼠才是好猫，真正决定技术方案优劣的，永远是最终的任务成功率，而不是技术概念听起来够不够新潮。 为了验证不同交付路线的实际效果，我们可以把常见的方式拆开来看：一种是不给额外的上下文文档，依赖模型自带的先验知识；一种是提供默认的 Agent Skill 文件，让 Agent 自行判断是否使用；一种是在提示词指令里加入强约束，强制 Agent 调用特定的 Skill；还有一种则是把关键索引压缩成极简的文本文档（例如 AGENTS.md），直接内嵌在上下文里。 2026 年 1 月 27 日，Vercel 在官方博客上公布了针对 Next.js 16 API 的评测数据（评测代码开源于 vercel/next.js/evals），恰好对这几种方案做了一次清晰的对照： 不提供文档的基线 Baseline：任务通过率为 53% 提供默认的 Agent Skill（可选）：通过率依然是 53% 通过提示词指令强制调用 Skill：通过率上升至 79% 直接在上下文内嵌 8KB 的 AGENTS.md 索引：通过率达到了 100% 这一测试结果展示了一个令人意外的细节：在 56% 的案例中，Agent 并没有主动去调用预设的默认 Agent Skill。换句话说，如果不通过显式指令强行干预，给 Agent 配置默认 Skill 的实际效果，居然和不提供文档的基线状态基本一致。 这个实验并不是要证明 Skill 机制本身无效，而是揭示了一个容易被忽视的事实：如果不通过 Evaluation 进行量化检测，团队很可能会花费大量精力去维护一套复杂的 Skill 规范，却不知道 Agent 在大部分场景下并没有触发它。Vercel 最终根据 Evaluation 数据做出了非常务实的决定：放弃繁琐的默认 Skill 路线，转而在项目根目录提供压缩后的 AGENTS.md 索引。这也恰恰印证了前面的判断——别凭感觉去追最时髦的技术概念，跟着 Evaluation 跑出来的真实数据走，才能找到当前最适合你产品的 AI 上下文交付方式。 ### 如何为你的产品建立 AI Evaluation 闭环？ 产品 AI 亲和度闭环：失败是产品信号，不是模型 verdict 看清了通用榜单的局限、厘清了动态测试的必要性、也避开了盲目追新的误区之后，剩下的核心问题就是：我们到底该如何在自家团队里，把这套 AI 亲和度评估给跑起来？要把这套评估方法在自家团队里落下去，其实不需要一上来就搞得复杂，按照三步走就会很顺。第一步，建立源自真实痛点的题目集。不用在办公室里凭空想象场景，直接去翻客服工单、GitHub Issues 里的高频报错，以及社区开发者反馈最容易卡顿的地方，把这些真实踩坑点改写成 20 到 50 个可复现的自动化评测场景。 第二步，搭建静态 Lint 与动态 Eval 的双层测试架构。静态检查层（便宜、CI 级）放在 GitHub Actions 这类 CI 流程里，每次提交时秒级检查 Markdown 格式、失效链接、OpenAPI 结构与 llms.txt 规范；动态评测层（昂贵、每日/每周）参考 Convex 的调度设计，在隔离的 Docker 容器里拉起基础设施运行端到端任务，用确定性的测试脚本校验数据库状态和生成代码，并用版本哈希锁死评测集。第三步，贯通测试失败到产品修补的归因回路。每次评测成功率下降或者遇到阻碍时，别急着去调大模型的参数，而是深入调取 Agent 的工具调用轨迹和文档检索路径。直接在产品表面做修补，并通过下一次 Regression 验证行为收敛。 ### 总结 在大航海时代，授权 AI 独立干活的前提，是给你的产品装上一套能够持续自省的 AI 亲和度检修仪。 评测不是为了做公关榜单去跟竞品比较，而是为了在产品与 AI 之间建立一条清晰的反馈回路。别再纠结通用的模型排行榜，也别盲目追逐最新的技术概念，跟着 Evaluation 的真实数据走，让你的产品在未来的 AI 时代真正变得顺风顺水。