第五课　最稀缺的工程能力，是在写代码之前说清楚不做什么

周五晚上的SAP请求

周五晚上，一名销售发来消息：一家重要客户需要 SAP S/4HANA 集成，能不能尽快做？

这个场景之所以典型，是因为每个参与者都在做自己的工作。销售想在季度结束前拿下一家战略客户；客户希望新财务平台能够进入已有ERP；工程师看见一个技术问题，第一反应是搜索SAP接口文档。没有谁明显做错，但如果团队沿着各自的局部目标直接行动，就可能在还不知道集成用途之前，先承担一项长期产品责任。

FDE最容易给出的答案是“能”。客户重要，交易临近，工程师又能直接动手。问题是，销售口中的“紧急”可能只是本季度额度的紧急，不一定是客户业务的紧急。团队若对每项请求都立刻承诺，很快会被几十个半成品拖垮。

Mehr特意反对一种流行形象：把FDE看成所有技术售前角色的“最终进化形态”，仿佛职责就是拥有更高权限、更快对客户说“可以”。Ramp的FDE属于工程组织，目标是让核心产品和新的Agent能力适用于大型企业。它当然服务交易，却不能只按单笔交易优化。每一次承诺都会进入代码库、发布流程和支持队列，影响下一批客户。

Mehr的第一原则是：Always be scoping——永远在界定范围。

这不是故意拖延，而是先把请求放回完整上下文：

• 客户为什么现在需要？不做会发生什么？
• 真正的用户有多少，何时会开始使用？
• 今天有没有手工替代办法？成本多高？
• 客户自己的技术团队可以承担什么？
• 其他在谈客户会不会遇到同一问题？
• 这个承诺会挤掉队列里的哪一项工作？

范围判断同时面向客户和公司。FDE既不能把销售目标伪装成用户价值，也不能因为追求完美架构而错过交易和学习机会。

对于SAP请求，一轮合格的scoping至少会继续追问：谁会触发同步，数据从Ramp流向SAP还是反过来，客户已经拥有哪种中间件，失败时是否允许人工补录，是否存在安全与审计截止日期，客户工程团队能否直接使用Ramp API。答案可能证明必须建设正式集成，也可能发现短期手工导出足以支撑试点，或者由客户现有集成平台完成更合理。

最重要的一问，是把当前客户放回整条需求管线：还有多少在谈客户使用S/4HANA？相邻客户使用的是同一种接口，还是完全不同的部署版本？如果只为一个季度末交易编写专用连接器，它会不会挤掉能服务十家客户的另一项能力？FDE的范围判断因此也是一种投资组合管理。它不是判断请求是否有价值，而是判断它相对于其他机会是否最值得现在做。

需求里缺少的那个限定词

Ramp曾为一家客户开发移动报销能力，团队自然地同时支持Apple的iOS与Google的Android这两种主流移动操作系统。后来才知道，客户的移动设备管理政策只允许iOS。Android部分从第一天起就没有必要。

当时Ramp自己的移动团队已经排满任务，FDE决定自己补位。两名工程师临时学习iOS和Android开发，连续工作数周，把两个版本都做了出来。团队带着完成大项目的兴奋向客户索取Android测试用户名单，才听说这家企业强制员工使用iOS设备。不是Android用户很少，而是根本不存在。

这个教训看似简单，却击中需求工作的常见偏差：工程师会自动补全缺失信息，而且通常按“完整产品”补全。客户说“移动端”，团队脑中出现“两大平台”；客户真正的约束却是“公司配发且受管的iPhone”。

scoping不是把需求写得更长，而是找出能删掉大量工作的事实。

浪费并非来自技术难度，也不是客户临时改口，而是团队没有验证最基础的使用环境。工程师越有能力，越容易快速填补空白；一旦“完整实现”被视为专业，就更难停下来问一个听上去过于简单的问题。scoping的纪律正是把未经验证的名词拆开：移动端是哪一种设备，集成是哪一组动作，实时究竟需要多少秒。

第二原则：用token扩张，而不是只用人头扩张

Ramp的第二原则是“scale with tokens”。如果FDE需求随大型客户增长，而每增加几个客户就必须增加同等人数，团队成本和沟通复杂度会线性上升。编码Agent提供了另一条路：把可重复的资料整理、规范生成、代码实现和测试交给Agent。

Mehr加入Ramp时，FDE只有两名工程师；两年半后，他负责的相关组织约有30人，覆盖FDE、开发者API和新的AI服务。团队扩大说明企业需求真实存在，也让人头扩张的上限变得清楚：更多工程师会带来更多客户上下文、更多交接和更复杂的优先级协调。若工作方法不变，人数并不会按比例转化为吞吐。

“用token扩张”也不是把工资预算机械换成模型账单。它要求不断重画人的工作：今天由FDE手工完成的资料汇总、补充提问和初稿规范，六个月后是否可以成为Agent步骤？若可以，需要什么工具、记忆和评测？团队的扩张单位从“再招一个同样的人”，逐渐变成“让现有工程师监督更多高质量工作循环”。

Mehr把FDE生命周期拆成四段：上下文、范围、规范、实施。两端相对容易自动化：Agent可以收集团队沟通工具Slack、文档与知识工具Notion和历史项目中的材料，也能依据明确规范完成中等规模功能。中间最难，因为它需要对业务优先级、产品方向与工程代价做判断。

这四段看起来像一条顺序流水线，实际会不断回流。实现时发现API缺少能力，可能迫使团队重写范围；评测暴露成功标准不完整，又要回到客户上下文；相似需求在第三个客户出现，规范也许应该从客户项目升级为核心产品。Agent系统不能只把文档从一个格式转换成另一个格式，而要允许证据改变上游决定。

Ramp因此搭了一个内部请求Agent。员工在Slack或Notion提交需求后，Agent会继续追问，直到信息达到可写规范的程度。Mehr称，原先需要数小时甚至数天的往返可以缩短到秒级，并估算节省约20%的scoping时间。这是其演讲中的内部估算，意义在于工作形态：Agent不替人决定优先级，而是让决定所需的信息更快齐全。

原来的入口是一个名为“FDE requests”的Slack频道。客户成功、销售和客户经理在这里提交阻碍交易或采用的问题，详细程度差异极大：有人附上完整Notion页面，有人只写一句“需要SAP集成”。FDE必须阅读材料、查询产品现状，再来回追问用户、时间、替代方案和成功标准。大量时间花在把一句请求变成可以判断的请求，而不是解决问题本身。

第一版Agent非常简单：读取请求，只问几条缺失问题。即使如此，它也把第一次响应从小时或天缩短到秒，提交者会在记忆仍然新鲜时立即补充。后来的版本会进行多轮对话，直到判断信息足以生成初步规范。Ramp甚至给它配了一个企鹅形象，让内部员工更愿意与它互动。这个细节说明，内部自动化也有产品采用问题；一套严肃而冷冰冰的表单未必比一个会追问的入口收集到更多事实。

20%的时间节省只是第一阶段。更重要的是，Agent把scoping从分散在人脑里的习惯，变成一套可以观察和改进的问题序列。团队可以检查哪些字段最常缺失，哪些回答仍然需要人工追问，哪些请求最终被否决，再把这些反馈写回系统。

Agent流水线需要评测，而不是信心

如果从上下文到实施都由多个Agent衔接，每一段都会放大前一段的偏差。模糊的背景生成错误范围，错误范围生成精致规范，最后得到结构漂亮但无人需要的代码。

因此，Ramp强调评测（evals）、评分规则（rubrics）与人工反馈。系统要知道一份好规范包含什么、哪些需求曾被否决、什么情况下必须升级给人；Agent还要拥有稳定上下文、技能、记忆和工具。

所谓rubric，可以是一套明确检查项：规范是否写出真实用户、当前绕行、成功指标和非目标；是否验证了产品已有能力；是否列出权限、安全和维护影响；是否说明为什么现在做。它不保证Agent拥有正确判断，却能让明显缺口在进入实现前暴露。评测样本还应包含历史上的好决定和坏决定，而不只是最终被批准的项目，否则Agent只会学习怎样把请求写得更像应该通过。

上下文是更难的部分。Notion、帮助中心和产品文档能告诉Agent“产品声称怎样工作”，却未必包含产品经理脑中的历史：某个接口为什么故意不开放，过去哪种方案造成过事故，哪位客户的例外不应一般化。要让Agent接近这种判断，团队必须把决策记录、代码状态、客户反馈和失败案例逐步连接起来，而不是只扩充知识库文章。

人在系统中的位置也随之变化。过去工程师亲自完成每一步；现在人更像评审者和编辑，集中使用“品味”（taste）：目标是否值得，范围是否过大，方案是否符合产品方向，代码是否在制造未来负担。

这里的“品味”不是无法解释的天赋。它来自看过足够多的客户请求、维护过自己曾经承诺的代码、理解公司产品方向，也知道什么样的局部胜利会制造全局失败。好的Agent会让这些判断出现得更频繁，因为它降低了收集和实现成本；它并不会让判断本身消失。

两种失败，必须同时避免

Mehr用两个很有画面感的极端收束全场。

如果没有扎实scoping，Agent工厂会变成“拼命烧token的垃圾炮”：它高速生成不需要的功能、重复集成和维护债务。如果只重视判断、完全不利用Agent扩张，竞争者又可能用更快的工程循环赢得客户。

真正的路线是同时提高两种能力：更严格地决定做什么，更自动化地完成已经决定的工作。前者保护方向，后者扩大吞吐。

范围压缩让第一次交付变得可控，却没有回答同一类需求第二次、第二十次出现时怎么办。下一课观察一家从50人长到500人的Agent公司，看看现场定制如何经过组织分工和产品漏斗，变成客户能够自助使用的能力。