<!-- title: HN新共识：没eval的AI应用别上线 -->
<!-- domain: trending -->

最近两周翻 HN 和 Reddit，能明显感觉到海外AI社区的风向在变：吵了几年的“模型谁更强”正在退烧，取而代之的是三个更务实、也更值得国内开发者抄作业的话题——**没有 eval（评测集）的 AI 应用不许上线**、**Agent 互联协议 A2A 进了 Linux 基金会**、**“AI 审 AI 代码”的工具爆发式增长**。这三个话题国内讨论热度都不高，但每一个都直接影响你明年怎么干活。今天把它们一次讲透。

---

## 话题一：Eval-Driven Development，正在成为新教条

过去你问“这个 AI 应用做得怎么样”，答案是“我试了几个 prompt，感觉还行”。现在你去 r/LLMDevs 或者 HN 发这种回答，会被围攻。社区已经形成了新共识：**LLM 应用不改测试，跟裸奔没区别**——因为模型会静默升级、prompt 改一个字全局行为就漂移、RAG 换个 embedding 全链路重测。

这套实践被叫做 **EDD（Eval-Driven Development，评测驱动开发）**，对标的正是十年前的 TDD。逻辑很简单：LLM 输出是概率的，但你的**验收标准必须是确定的**。

### 各方观点

- **支持派**：观点很直接——“你不会把没跑过单元测试的代码 deploy 到生产，为什么敢把没跑过 eval 的 prompt deploy 上去？”他们引用的常见教训是：换了个新模型，某个长尾场景（比如日期解析）准确率从 95% 掉到 60%，而团队两周后才发现。
- **反对派**：认为 eval 维护成本被严重低估——评测集本身会过时，覆盖的场景永远赶不上真实用户输入的长尾，最后沦为“为了绿而绿”的形式主义。还有人吐槽部分团队拿 LLM 当裁判（LLM-as-judge），“用幻觉模型给幻觉模型打分”。
- **中立派**：立场是分层——核心收入链路必须上 eval，玩具项目随缘；而且 eval 不是一次性工程，要跟着用户反馈持续长。

我的判断：这场争论的结局类似当年的“要不要写测试”——反对声音会一直存在，但工程团队的默认动作已经变了。

### 可以上手的三件工具

1. **promptfoo**（开源，github.com/promptfoo/promptfoo，官网 promptfoo.dev）——目前社区里最轻量的选择。不写代码就能测：写一个 `promptfooconfig.yaml`，把 prompt、测试用例、断言列进去，命令行一键跑分。
2. **Langfuse**（开源可自部署，github.com/langfuse/langfuse，官网 langfuse.com）——主打 tracing + 评测一体化，OpenAI SDK 换个 base_url 就能接入，适合想看“每一次调用到底发生了什么”的团队。
3. **Braintrust**（braintrust.dev，商业产品有免费额度）——托管式 eval 平台，数据集管理做得比较细，创业团队用得多。

### promptfoo 十分钟上手

```bash
npx promptfoo@latest init        # 生成 promptfooconfig.yaml 模板
# 编辑 yaml：填 prompt、provider、测试用例与断言
npx promptfoo@latest eval        # 跑评测，命令行直接出对比表
npx promptfoo@latest view        # 打开本地 Web 界面看逐条结果
```

关键玩法是把 eval 塞进 CI：GitHub Actions 里加一步 `promptfoo eval --prompts prompts/`，设置失败阈值。从此 prompt 改动和代码改动一样，**不过测试不许合并**。断言除了关键词/正则，还支持 LLM-as-judge 和语义相似度，可以混着用。

### 工作流长这样

```mermaid
flowchart LR
    A[收集真实用户badcase] --> B[沉淀进评测数据集]
    B --> C[编写promptfoo断言]
    C --> D{CI: promptfoo eval}
    D -- 达标 --> E[合并上线]
    D -- 回归 --> F[定位漂移原因<br/>模型升级/prompt/RAG]
    F --> B
    E --> G[线上tracing<br/>Langfuse]
    G --> A
```

注意这是个闭环：eval 数据集的源头是线上真实 badcase，不是拍脑袋编的。只写 10 条理想用例的团队，测不出任何东西。

---

## 话题二：A2A 进驻 Linux 基金会，Agent 互联标准开抢

第二个信号烈度更高。Google 在 2025 年推出的 **A2A（Agent2Agent）协议**——让不同厂商的 Agent 互相发现、派活、收结果的开放协议——已经捐给了 **Linux 基金会**独立运营（据 Linux 基金会公告，官方称有上百家企业参与），代码在 github.com/a2aproject/A2A。

很多人第一反应：“这不是和 MCP 打架吗？”社区吵的就是这个：

- **互补派**（目前的主流观点）：MCP 解决的是“Agent 怎么**用工具**”（Agent ↔ 工具），A2A 解决的是“Agent 怎么**用 Agent**”（Agent ↔ Agent）。一个 Agent 完全可以同时通过 MCP 调 API、通过 A2A 把子任务外包给别家 Agent。协议层级不同，不冲突。
- **竞争派**：认为两个协议都在往对方地盘渗透，长期必然撞车，最终“谁的应用多谁赢”，别迷信基金会背书。
- **怀疑派**：Agent 互联的需求本身还没被验证——“我的 Agent 为什么要信任你一个来路不明的 Agent？”安全、身份、计费这些配套没跟上之前，A2A 更像期货。

A2A 的核心机制值得了解：每个 Agent 在 `/.well-known/` 路径下挂一张 **Agent Card**（JSON 名片），声明自己能干什么、怎么联系；任务以 Task 为单位流转，长任务支持流式更新，还能传文件等 Artifact。设计上明显是冲着“跨企业边界协作”去的。

### 对国内开发者的启示

这是典型的**标准窗口期博弈**。协议本身开源、门槛不高，现在读懂 A2A + MCP 的分工，比三个月后看别人案例要值钱得多。国内 Agent 框架（各家平台都在自建协议层）与国际标准如何互通，是一个几乎没人做、但出海团队迟早要面对的问题。务实建议：**不必现在 All in，但你的 Agent 架构设计里，应该把“对外暴露一张标准 Agent Card”和“工具调用走 MCP”当成两个独立模块预留**，未来切换成本会低一个数量级。

---

## 话题三：AI 写的代码，正在被另一个 AI 审

第三个话题最接地气。社区现在默认的爆款组合是：**用 Agent 写代码，用 AI Code Review Bot 审代码**。这一波代表产品：

- **CodeRabbit**（coderabbit.ai）：这一品类的头部，PR 一发自动逐行评审、生成摘要。对**开源仓库免费**，商业版按席位订阅（具体价格以官网为准）。国内出海的开源项目接一个，README 上的“Reviewed by CodeRabbit”徽章都成了某种社区身份标识。
- **Greptile**（greptile.com）：主打“理解整个代码库再评审”，而不只是看 diff，擅长抓跨文件的逻辑问题。
- **Graphite**（graphite.dev）：从 stacked diff 工作流切入，把 AI review 作为合并流程的一环。

HN 上的争论也很有意思：

- **支持方**晒出数据：Bot 抓出的空指针、越界、漏掉的边界条件不比初级工程师少，而且**永远不烦、秒回**。
- **反对方**核心论点只有一个：**AI 评审会制造虚假安全感**。“机器人说 LGTM，人就不看第二眼了——可恰恰是最危险的架构级问题，所有 Bot 都看不出来。”
- **中间派**的实践最值得抄：Bot 负责第一层“廉价错误”（bug、风格、测试缺失），人只审“该不该做”和“架构对不对”。分级评审，各干各的。

对个人开发者的行动建议很直接：GitHub 开源仓库现在就能免费接 CodeRabbit（在 coderabbit.ai 用 GitHub 登录、选择仓库安装 App 即可），私有仓库可以先靠 Claude Code / Copilot 的 review 模式顶替，等团队规模上来了再上付费方案。

---

## 信息差总结

| 维度 | 多数人还以为 | 海外社区已经默认 |
|---|---|---|
| 上线标准 | “我手动试过几个 prompt” | 没有 eval 集的 AI 功能禁止合并（EDD） |
| 评测工具 | “AI 应用没法自动化测试” | promptfoo/Langfuse 十分钟接入 CI |
| Agent 协议 | MCP 就是全部 | A2A 管 Agent 互联，MCP 管工具调用，分层共存 |
| 代码评审 | 人审人写的代码 | AI 审 AI 写的代码，人只审架构与需求 |
| 评审价值 | 评审找 bug | Bot 找 bug，人找“方向性错误” |

## 行动指南

1. **今晚**：挑一个你手上最不稳的 prompt 功能，`npx promptfoo@latest init` 建 20 条用例（至少一半来自真实 badcase），跑一次基线。
2. **本周**：把 promptfoo eval 加进 CI，设个 80% 通过率阈值；线上接 Langfuse 看真实流量。
3. **本月**：读一遍 A2A 的 Agent Card 规范（github.com/a2aproject/A2A），在自己 Agent 项目里做协议隔离设计；给开源仓库接上 CodeRabbit 白嫖一轮 AI 评审。

这三个动作的共同点是：都不追新模型，而是把“概率系统”装上“确定性护栏”——这正是当前海外工程社区审美转向的全部含义。

## 参考来源

- promptfoo 官网与开源仓库：https://github.com/promptfoo/promptfoo / https://promptfoo.dev
- Langfuse 开源仓库：https://github.com/langfuse/langfuse
- A2A 协议（Linux 基金会项目）：https://github.com/a2aproject/A2A
- CodeRabbit 官网：https://coderabbit.ai
- Graphite 官网：https://graphite.dev

（注：本文观点整理自 HN/Reddit 社区长期公开讨论与上述项目官方文档；涉及价格、参与企业数量等易变信息以官网为准。）

---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护。
> 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
