过去一年，海外工程圈关于“AI 到底怎么用”的争论，已经从“要不要用”彻底转向了“怎么管住它”。有意思的是，吵得最凶、共识也最扎实的，恰恰是三个特别工程、特别不性感的话题：规格（Spec）、上下文（Context）、评测（Evals）。这三场讨论在 HN、Reddit、X 上刷了几个月的屏，但中文圈的讨论量少得可怜——很多人还停留在“AI 写码 = 聊天框里要代码”的阶段。今天把这三场争论的正反方观点、代表性工具和可抄作业的做法一次讲透。
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 使用：
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 改坏了什么、当初为什么这么设计，全都有据可查。对于要过等保、要写交付文档、要接外包验收的国内团队，这套流程几乎是为你们量身定做的——规格文档顺手就是交付物，一份功夫两份收益。
模型厂商营销页上最诱人的数字就是上下文窗口：100 万 token，能塞下一整个代码库。2025 年 7 月，向量数据库公司 Chroma 发布了一份研究报告《Context Rot》（research.trychroma.com/context-rot），测了 18 个主流模型，结论很不给面子：输入越长，模型表现越差——而且往往远在标称窗口上限之前就开始烂。更扎手的发现有三个：
几乎同一时间，“context engineering（上下文工程）”这个词被 Shopify CEO Tobi Lütke 在内部备忘录里带火，Karpathy 转发背书后彻底出圈。支持者认为这是继 prompt engineering 之后真正的核心竞争力：上下文窗口是稀缺资源，你要像做内存管理一样做上下文预算。反对者则冷笑：这不就是把 prompt engineering 换了个更贵的名字？
吵到 2025 年 10 月，Anthropic 官方下场，发了工程博客《Effective context engineering for AI agents》，算是给这场争论定了调。他们给的工程手段非常具体：
flowchart TD
A["上下文预算超支"] --> B["Compaction 压缩历史"]
A --> C["结构化笔记落盘"]
A --> D["子代理隔离污染"]
B --> E["只保留高信号内容"]
C --> E
D --> E
E --> F["继续执行任务"]
/compact 就是这个思想的产物；AGENTS.md、CLAUDE.md 这类文件——文件是可以被重新精准加载的，聊天记录只能被模糊回忆；国内厂商同样在卷超长上下文，但“窗口大”和“用得好”是两回事。最有价值的行动点就一句话：把你的上下文当成每月定额的工资来花。系统提示词砍到最短、工具说明按需挂载、历史对话勤压缩、重要决策一律落盘到 Markdown 文件而不是留在会话里。我见过太多人的 Agent 越聊越蠢，第一原因就是 20 万 token 的窗口里塞了 18 万 token 的废话。
前两个话题吵的是“怎么喂 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 加一个脚本就能起步 |
specify init，用 /speckit.specify 把一个真实小需求写成规格，感受一下“先审规格再放 AI 进来”的手感；AGENTS.md，把架构决策、踩过的坑写进去，让每次会话冷启动就带着记忆；/compact 的思路清理你的长会话，或者干脆拆会话——一个会话只干一件事；本文由「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 等场景全覆盖。