先说结论：执行越便宜，范围越值钱
AI 时代最稀缺的工程能力，是在写代码之前说清楚不做什么——执行越便宜，范围越值钱。它叫 scoping（范围界定）：动手前确认谁使用、为什么紧迫、现有能力能否解决、哪些工作应该删掉。Ramp 把它列为 FDE（Forward Deployed Engineer，驻客户现场并对业务结果负责的工程师）团队第一原则——Always be scoping，永远在界定范围。据工程总监 Leo Mehr 在 2026 年 6 月 30 日 AI Engineer World’s Fair FDE 议程的演讲：他加入时 Ramp FDE 只有约 2 人，两年半后相关组织约 30 人；一套内部请求 Agent 把需求往返从数小时到数天缩到秒级，他估算节省约 20% 的 scoping 时间（内部估算）。岗位背景见《FDE 是什么岗位》。
周五晚上的SAP S/4HANA请求
对每个请求都立刻说”能”，FDE 很快会被几十个半成品拖垮。
场景是真事：周五晚上，销售发来消息——重要客户需要 SAP S/4HANA 集成，能不能尽快做。S/4HANA 是 SAP 的新一代 ERP 套件，承载财务、采购等核心记录。销售要拿下季度末的战略客户，客户要接进已有 ERP，工程师第一反应是搜接口文档——没人明显做错，但”紧急”可能只是本季度额度的紧急，未必是客户业务的紧急。
一轮合格的 scoping 要问：谁触发同步，数据从 Ramp 流向 SAP 还是反向？客户已有哪种中间件？失败能否人工补录？有无安全审计截止日？客户团队能否直接用 Ramp API？答案可能证明必须做正式集成，也可能发现手工导出足以支撑试点。
最重要的一问把单笔交易放回整条需求管线：还有多少在谈客户用 S/4HANA？只为一个季度末交易写专用连接器，会不会挤掉能服务十家客户的另一项能力？FDE 的范围判断因此也是一种投资组合管理：它不是判断单个请求有没有价值，而是判断它相对于其他机会是否最值得现在做。
反例：Android用户根本不存在
工程师会自动补全需求里的缺失信息，而且通常按”完整产品”补全——移动报销的教训就出在这里。
Ramp 曾为客户开发移动报销能力，移动团队排满，FDE 决定补位：两名工程师临时学习 iOS 和 Android 开发，连续数周做出两个版本。向客户索取 Android 测试用户名单时才听说：这家企业的移动设备管理（MDM）政策只允许 iOS——Android 用户根本不存在，工作从第一天起就没有必要。
客户说”移动端”，团队脑中是”两大平台”，真正约束是”公司配发且受管的 iPhone”。浪费不来自技术难度——团队没验证最基础的使用环境。scoping 的要点是把未验证的名词拆开：移动端是哪种设备，集成是哪组动作，实时需要多少秒——合格的 scoping 找出能删掉大量工作的事实。
四段生命周期：上下文、范围、规范、实施
Ramp 把 FDE 工作拆成四段：上下文、范围、规范、实施；两端相对容易自动化，中间靠人的判断，且整条流水线会不断回流。
| 阶段 | 主要工作 | 自动化程度 |
|---|---|---|
| 上下文 | 汇集 Slack、Notion 与历史项目里的材料 | 相对容易自动化 |
| 范围 | 判断业务优先级、产品方向与工程代价 | 最难，靠人的判断 |
| 规范 | 把已定范围写成可验证的文档 | 中间段，依赖人的判断 |
| 实施 | 依据明确规范完成中等规模功能 | 相对容易自动化 |
四段看似顺序流水线，实际不断回流：实现时发现 API 缺能力，迫使重写范围；评测暴露成功标准不完整，又回到客户上下文；相似需求在第三个客户出现，规范就该升级为核心产品。
用token扩张：内部请求Agent与20%的时间节省
Ramp 的第二原则是 scale with tokens（用 token 扩张）：每增加几个客户就得增加同等人数，成本和沟通复杂度线性上升。
原入口”FDE requests” Slack 频道里，提交者详细程度差异极大：有人附完整 Notion 页面，有人只写一句”需要SAP集成”——FDE 大量时间花在把一句请求变成可以判断的请求上。第一版 Agent 只做读取请求、追问缺失信息一件事，就把第一次响应从小时或天缩到秒，提交者在记忆新鲜时立即补充；后来的版本多轮对话直到生成初步规范，还配了企鹅形象让员工更愿意互动——内部自动化同样有采用问题。
按演讲中的内部估算，它节省约 20% 的 scoping 时间；20% 只是第一阶段，更重要的是 Agent 把 scoping 从人脑里的习惯变成可观察、可改进的问题序列——哪些字段最常缺失、哪些请求被否决，都能写回系统。用 token 扩张也绝非把工资预算换成模型账单：今天手工做的资料汇总，六个月后能否交给 Agent，值得持续重画。
Agent流水线靠评测不靠信心
多段 Agent 衔接时，每一段都会放大前一段的偏差：模糊的背景生成错误范围，错误范围生成精致规范，最后得到结构漂亮但无人需要的代码。Ramp 的对策是评测（evals）、评分规则（rubrics）与人工反馈。
rubric 可以是一套明确检查项：规范是否写出真实用户、当前绕行、成功指标和非目标；是否验证产品已有能力；是否列出权限、安全和维护影响；是否说明为什么现在做。它不保证判断正确，却让明显缺口在实现前暴露。评测样本还要包含历史上的好决定和坏决定——只喂批准的项目，Agent 只会学习把请求写得更像应该通过。
更难的是上下文：帮助中心能告诉 Agent”产品声称怎样工作”，装不下产品经理脑中的历史——某接口为什么故意不开放、哪位客户的例外不能推广。展开见FDE 评测与FDE AI 工具箱。
两种失败：垃圾炮与慢工厂
Mehr 用两个极端收束：没有扎实 scoping 的 Agent 工厂会变成”拼命烧 token 的垃圾炮”（token-maxxing slop cannon），高速生成不需要的功能和维护债务；不用 Agent 的团队，又会被对手更快的工程循环抢走客户。真正的路线是同时提高两种能力：更严格地决定做什么，更自动化地完成已决定的工作——前者保护方向，后者扩大吞吐。
给读者的最小问题清单
把这份清单贴在需求入口，专拆”移动端、集成、实时”这类未验证名词：
- 这个名词指哪种具体设备、系统或动作？谁用，多少人，何时开始？
- 现在的手工替代方案是什么，成本多高？失败能否人工补录？
- 有没有安全审计截止日？客户自己的团队能承担哪部分？
- 这个需求在需求管线里出现了几次？为它写的专用实现会挤掉什么？
任何一问含糊，先回到上下文收集，别急着写代码。scoping 之外的组队与流程关口，见要不要组建FDE团队。
常见问题
AI项目为什么会烂尾？
多数烂尾发生在写代码之前：移动端、集成、实时这类名词未经核实，“紧急”混入销售的季度额度，进入代码库后才暴露范围错误。对策是 Always be scoping 加评测兜底。
怎么判断一个AI需求该不该接？
用投资组合视角问三个问题：还有谁需要它、专用实现会挤掉什么、手工替代成本多高。三个答案都含糊就不接。
scoping会不会拖慢交付？
合格的 scoping 是一轮追问，Ramp 用请求 Agent 把往返缩到秒级，内部估算节省约 20% 的 scoping 时间；范围压缩常让交付更小、价值更早出现。