过去一年，海外工程圈关于“AI 到底怎么用”的争论，已经从“要不要用”彻底转向了“怎么管住它”。有意思的是，吵得最凶、共识也最扎实的，恰恰是三个特别工程、特别不性感的话题：**规格（Spec）、上下文（Context）、评测（Evals）**。这三场讨论在 HN、Reddit、X 上刷了几个月的屏，但中文圈的讨论量少得可怜——很多人还停留在“AI 写码 = 聊天框里要代码”的阶段。今天把这三场争论的正反方观点、代表性工具和可抄作业的做法一次讲透。 --- ## 话题一：Spec-Driven Development，是解药还是新瓶装旧酒？ ### 事情是怎么烧起来的 2025 年 7 月，AWS 悄悄开了一个预览版 IDE，叫 **Kiro**（kiro.dev）。按官方介绍，它脱胎于亚马逊内部团队多年沉淀的“规格先行”开发流程：你先和它一起把需求写成三份文件——`requirements.md`（用一种叫 EARS 的语法写验收条件，形如“WHEN 用户提交表单 THE SYSTEM SHALL 校验手机号”）、`design.md`（技术方案）、`tasks.md`（任务清单）——然后 AI 才开始动手写码。每一步产物都是人可以审、可以改的普通 Markdown。 真正的爆点是 2025 年 9 月：**GitHub 官方开源了 Spec Kit**（github.com/github/spec-kit），把这套流程做成了通用工具。上线没几天就冲上 GitHub Trending 前列，Star 很快破万（以仓库实时数据为准）。它不绑定某个 IDE，用 `specify init` 初始化项目后，会生成一整套斜杠命令，配合 Claude Code、Copilot、Gemini CLI、Cursor 等十来种主流 Agent 使用： ```mermaid flowchart TD A["specify init 初始化"] --> B["constitution 立项目宪法"] B --> C["specify 写规格"] C --> D["plan 出技术方案"] D --> E["tasks 拆任务"] E --> F["implement 逐条实现"] F --> G["测试与验收"] G -->|不通过| C G -->|通过| H["合并上线"] ``` 注意里面最容易被忽略的一环：**constitution（项目宪法）**。你把“永远用 TypeScript 严格模式”“所有接口先写失败用例”这类团队规矩写进去，之后每一份规格的生成都受它约束。相当于给 AI 发了一本员工手册。 ### 三方观点，吵得很凶 **真香派**的观点很直接：AI 写码的速度瓶颈根本不在打字，而在“你根本没想清楚要什么”。裸奔式 vibe coding 的结局就是 3000 行没人看得懂、AI 自己都改不动的祖传屎山。规格文档是唯一能让人和 AI 对齐的锚点，而且它是 Git 里的一等公民，可以 review、可以 diff、可以回滚。Kiro 的存在本身就是背书——亚马逊内部用这套流程造了多年服务。 **抬杠派**在 HN 上的火力也很猛：这不就是瀑布模型吗？三十年前我们就试过“先写详规再动手”，最后规格和代码两张皮，文档永远过期。只不过这次写规格的苦力从初级工程师换成了大模型。还有人吐槽 Spec Kit 生成的文件太多太重，小项目套这套流程纯属自虐。 **中间派**（也是我站的一派）的说法最实用：关键不是“要不要写规格”，而是**规格的粒度要和变更频率匹配**。核心业务逻辑、涉及钱的接口、多人协作的模块——值得写规格；改个按钮颜色、写个一次性脚本——直接让 AI 干。Spec Kit 自己也支持从任意阶段切入，不是强制瀑布。 ### 对中文用户的启示 国内团队用 AI 写码最常见的翻车姿势是：需求在产品经理脑子里、口头转述给开发、开发再口头喂给 AI——信息经过三次有损压缩。而 spec-driven 把这个链条物化成了文件，AI 改坏了什么、当初为什么这么设计，全都有据可查。对于要过等保、要写交付文档、要接外包验收的国内团队，这套流程几乎是为你们量身定做的——规格文档顺手就是交付物，一份功夫两份收益。 --- ## 话题二：Context Rot——长上下文的皇帝新衣 ### 一份研究掀了桌子 模型厂商营销页上最诱人的数字就是上下文窗口：100 万 token，能塞下一整个代码库。2025 年 7 月，向量数据库公司 **Chroma** 发布了一份研究报告《Context Rot》（research.trychroma.com/context-rot），测了 18 个主流模型，结论很不给面子：**输入越长，模型表现越差——而且往往远在标称窗口上限之前就开始烂**。更扎手的发现有三个： 1. “大海捞针”测试里，干草堆不是中性的——同样是 10 万 token 的填充内容，换成更像真实文档的材料，针就捞不上来了； 2. 干扰文档越多，RAG 检索质量掉得越狠； 3. 连“重复某个词几遍”这种幼儿园任务，上下文一长模型都会数错。 ### 术语之争背后的方法论之争 几乎同一时间，“context engineering（上下文工程）”这个词被 Shopify CEO Tobi Lütke 在内部备忘录里带火，Karpathy 转发背书后彻底出圈。支持者认为这是继 prompt engineering 之后真正的核心竞争力：上下文窗口是稀缺资源，你要像做内存管理一样做**上下文预算**。反对者则冷笑：这不就是把 prompt engineering 换了个更贵的名字？ 吵到 2025 年 10 月，**Anthropic 官方下场**，发了工程博客《Effective context engineering for AI agents》，算是给这场争论定了调。他们给的工程手段非常具体： ```mermaid flowchart TD A["上下文预算超支"] --> B["Compaction 压缩历史"] A --> C["结构化笔记落盘"] A --> D["子代理隔离污染"] B --> E["只保留高信号内容"] C --> E D --> E E --> F["继续执行任务"] ``` - **Compaction（压实）**：对话接近上限时，把历史摘要成一段高密度笔记再继续，Claude Code 里那个 `/compact` 就是这个思想的产物； - **结构化笔记**：别把决策留在聊天记录里，让 Agent 把关键结论写进 `AGENTS.md`、`CLAUDE.md` 这类文件——文件是可以被重新精准加载的，聊天记录只能被模糊回忆； - **子代理隔离**：让脏活（全网搜索、大文件遍历）由子代理去干，主上下文只收回一段结论，污染不进主战场。 ### 对中文用户的启示 国内厂商同样在卷超长上下文，但“窗口大”和“用得好”是两回事。最有价值的行动点就一句话：**把你的上下文当成每月定额的工资来花**。系统提示词砍到最短、工具说明按需挂载、历史对话勤压缩、重要决策一律落盘到 Markdown 文件而不是留在会话里。我见过太多人的 Agent 越聊越蠢，第一原因就是 20 万 token 的窗口里塞了 18 万 token 的废话。 --- ## 话题三：Evals——没有评测集的 Agent 是盲盒 ### 从“vibe check”到“必须有评测” 前两个话题吵的是“怎么喂 AI”，第三个话题吵的是“怎么知道 AI 有没有变好”。前 GitHub 数据科学家 **Hamel Husain**（早年给 Copilot 搭数据体系的那位）在博客《Your AI Product Needs Evals》（hamel.dev/blog/posts/evals/）里把话挑明了：凡是靠“我感觉最近回答变好了”来做决策的团队，都是在开盲盒。他后来和伯克利的 Shreya Shankar 开的评测课程，一度是海外 AI 工程师圈最热门的付费内容之一。 社区的正反方也很经典。反对派说：小团队哪有资源搞评测平台？提示词改两行还要跑回归测试，太重了。支持派甩出的数据很伤人：他们见过太多“改好了 A 场景、悄悄弄坏 B 场景”的事故，根因都是没有评测集——**LLM as judge 都不可靠，因为裁判自己都没被人校准过**。Hamel 给出的流程其实朴素得惊人：先从真实用户里捞 100 来条翻车样本做错误分析，归类出失败模式，再挑 20-50 条做成固定测试集，此后每次改提示词、换模型、升级版本都跑一遍。没有平台，一个表格加一个脚本就够了。 ### 对中文用户的启示 这可能是三个话题里最值得抄的：国内做 AI 应用的团队，绝大多数连 20 条的回归测试集都没有，改 prompt 全靠手点几个 case 试。本周就能做的最小动作：把用户聊天记录里最让你尴尬的 20 条 bad case 存进一个 CSV，写一个 50 行的评测脚本让模型按 1-5 分打分——从此你的每一次 prompt 改动都有数字背书。 --- ## 信息差总结 | 你以为的 | 海外工程圈已经在做的 | |---------|---------------------| | AI 写码就是聊天框要代码 | 规格文档是 Git 一等公民，Kiro 和 Spec Kit 把它流程化了 | | 上下文窗口越大越好 | Context Rot 研究实证：长输入 universally 掉分，要按预算管理 | | 决策留在聊天记录里就行 | Anthropic 官方套路：压缩、落盘、子代理隔离三件套 | | 改提示词凭手感 | 20 条 bad case 起步的最小评测集，每次改动过回归 | | 评测是大厂才能玩的重活 | 一个 CSV 加一个脚本就能起步 | ## 行动指南 1. **今天**：打开 github.com/github/spec-kit，在一个练手项目里跑 `specify init`，用 `/speckit.specify` 把一个真实小需求写成规格，感受一下“先审规格再放 AI 进来”的手感； 2. **本周**：给主力项目建一个 `AGENTS.md`，把架构决策、踩过的坑写进去，让每次会话冷启动就带着记忆； 3. **本周**：用 `/compact` 的思路清理你的长会话，或者干脆拆会话——一个会话只干一件事； 4. **周末**：攒 20 条真实 bad case，写个脚本跑通第一次回归评测； 5. **持续**：把“这次改动评测分变化”写进你的 PR 描述，两周后你会回不来。 ## 参考来源 1. GitHub Spec Kit 仓库：https://github.com/github/spec-kit 2. AWS Kiro 官网（定价与预览信息以官网为准）：https://kiro.dev 3. Chroma 研究报告《Context Rot》：https://research.trychroma.com/context-rot 4. Anthropic 工程博客《Effective context engineering for AI agents》：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents 5. Hamel Husain《Your AI Product Needs Evals》：https://hamel.dev/blog/posts/evals/ --- > 本文由「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 等场景全覆盖。