第七课　别再用token证明价值：把客户现场变成最高保真的评测集

从13%的演示到企业生产

Wu先拿Devin在2024年刚发布时的印象开玩笑。最初的基准成绩和“首位AI软件工程师”叙事引发巨大关注，随后很多工程师发现，演示能力与自己的复杂代码库之间仍有距离。

SWE-bench是一套用真实GitHub问题及其修复来评估模型的软件工程基准：系统要生成代码补丁，再由项目测试判断问题是否真正解决。Wu提到的13%，指向Devin早期在这类任务上的表现。发布瞬间，工程师一面惊叹Agent能够自己使用终端、浏览器和编辑器，一面担心职业被替代；一周后，很多人又发现它在真实工作中经常需要救场。Wu用Cognition后来在旧金山投放的自嘲广告概括这段变化：“我们现在真的好用了。”笑话背后的问题是，一项基准能力怎样穿过两年产品迭代，变成企业愿意依赖的生产能力。

到2026年，Cognition提供云端Agent、CLI（命令行界面）和IDE（集成开发环境，把编辑、运行和调试放在同一工具中）等多种入口。Wu真正想解释的不是功能列表，而是这些能力怎样进入企业。她画了两个圆：一个是产品能做的事，一个是客户真正的问题。产品市场契合，不是圆里各有多少内容，而是重叠面积有多大。

这些产品界面对应不同的人机分工。命令行适合工程师在熟悉的终端中调用Agent；IDE让人可以在代码旁边持续协作；云端Agent则拥有独立计算环境，可以在后台运行较长任务。Wu本人在Windsurf并入Cognition后加入，因此也亲历了从IDE内协作到云端委派的产品组合。真正的企业部署往往不是三选一，而是根据任务形状安排入口。

Cognition在内部也用Devin改变自己的开发方式。Wu展示的公司口径称，过去六个月里，在招聘相对滞后的情况下，团队仍然合并了接近一个数量级更多的高质量pull request（PR，拉取请求）——也就是开发者提交一组代码变更，请团队审查后合并进主代码库。这个数字不能直接推导到客户，但说明“部署”并不是售后包装：如果厂商自己都没有把Agent接入日常工程流程，就很难理解客户会在哪些环节卡住。

FDE的工作就是从两边扩大重叠：把Devin部署到最有价值的工程问题，也把现场反复出现的障碍送回产品。

只做第一件事，会让FDE变成善于使用现有产品的实施团队；只做第二件事，则容易收集大量意见却没有当期客户结果。Cognition把两边视为同一任务：一次现场工作既要证明某个工程问题可以被Agent解决，也要告诉产品团队下一项能力为什么值得建设。

写代码大约只是问题的20%

在一个企业软件生命周期里，需求进入积压清单，工程师理解遗留系统，开发、测试、审查、发布、监控，再长期维护。生成一段代码只是其中一环。

现实企业很少从空白仓库开始。团队面对的是多年积累的服务、没人愿意碰的迁移、版本落后的语言、发布冻结窗口，以及只有少数老员工理解的依赖。一个用户故事进入backlog（待办开发任务清单）以后，要先判断影响范围，再找到代码位置，补测试、通过审查和CI（持续集成，代码提交后自动构建与测试），协调发布，最后观察生产行为。Agent在中间写出代码，并没有自动完成这条链。

Wu在演讲中把编码估为整个问题的约20%。这个比例不是通用研究结论，但方向很关键：模型即使能写出正确代码，也未必知道哪项战略计划最重要、怎样在旧系统中验证、谁批准发布、出了问题怎样回滚、几年后谁来维护。

所以Cognition的FDE不是把Agent随手扔进代码库。一天可能有四五小时客户会议，再有四五小时亲手配置和构建。会议不是“非技术工作”，而是用于识别最高杠杆的业务计划、理解代码交付链，并决定哪里适合自动化。

在客户生态里，FDE会检查积压很久的功能、尚未完成的安全修复、缺失测试、告警分诊和迟迟推进不了的迁移。不同任务需要的Agent配置不同：有的适合在明确工单到来时自动启动，有的需要先由人拆分，有的只能生成候选改动并等待专家审查。所谓“把产品能力映射到问题”，不是给所有团队开通账号，而是为每一种任务设计触发、上下文、验证和交接。

会议与键盘工作各占半天，也说明FDE不能只做关系管理。工程师听完战略目标后，要亲自进入代码库验证假设：依赖是否真如客户所说，Agent能否运行测试，权限缺口在哪里。没有动手验证，客户访谈容易停留在愿望；没有客户理解，技术实验又容易落在低价值任务。

自动化自己，才算完成部署

找到场景之后，FDE会把Agent接入事件与告警，使它自动响应，而不依赖工程师每天手工触发。目标是“把自己从任务里自动化掉”：建立稳定上下文、触发条件、审查与交付路径。

例如，某类告警出现后，Agent可以自动读取相关服务、查找近期改动、提出修复并运行验证；积压中的重复迁移任务可以按模板持续执行。FDE最初可能手工示范每一步，但如果三个月后仍必须由同一个人登录、复制提示和点击启动，部署没有形成系统。真正完成的标志，是客户自己的事件能够稳定驱动Agent，结果进入原有工程流程。

这一步也迫使团队回答投资回报。运行了多少session、消耗多少token，只说明机器很忙；客户关心的是项目是否更早完成、积压是否减少、有效PR是否被接受、关键系统是否更快维护。

Wu给出三组匿名或公开案例口径：在一个三个月部署中，Agent提供了相当于约150人规模的额外工程容量；某些交付周期缩短约82%；相较单点工具，合并的PR数量接近翻倍。她还提到巴西数字银行Nubank的ETL迁移、拉美银行的遗留税务系统，以及美国住房奖励与支付平台Bilt的工程输出。ETL即“抽取、转换、加载”，是把数据从源系统取出、清理转换，再送入目标数据平台的工程流程。这些数字来自Cognition在演讲中的案例展示，不应被当成所有客户都能复制的行业基准。

她特意把指标一层层拆开。第一层是session和由此估算的“有效工程小时”，它回答Agent运行了多少有生产意义的工作，但仍可能被质疑只是另一种使用量。第二层是项目交付周期，把部署前后的ticket（工作项）、sprint（短周期迭代）和完成时间进行比较，观察工作是否真的提前结束。第三层是被合并的PR，因为只有进入主干的改动才更接近组织接受的产出。

三层指标的关系很重要。大量session却没有合并PR，说明Agent也许在反复尝试；PR增加而项目周期不变，瓶颈可能已经转移到审查、发布或组织协调；周期缩短却故障增加，又不能称为价值。FDE要把Agent活动量连接到交付结果和质量，而不是挑一个最好看的数字。

公开案例让这种差别更具体。Wu提到Nubank一项ETL迁移原本投入约50名工程师，Devin参与后按公司口径在约三分之一时间内完成；另一家拉美大型银行的税务识别系统迁移，包含COBOL、JCL等遗留技术。COBOL是长期用于银行、保险和政府批处理系统的编程语言，JCL是IBM大型机上用来描述批处理作业如何运行的控制语言。该项目所需人力约减少一半；Bilt案例则强调合并PR和每周工程输出。案例的共同点不是某个统一提升倍数，而是Agent被放进了边界清楚、可以用完成时间和接受结果衡量的工程任务。

真正的评测集在客户那里

如果FDE只完成客户目标，工作只做了一半。现场遇到的问题需要被整理成产品团队能使用的证据：

• 这是所有企业都会遇到的挑战，还是一名用户的特殊习惯？
• 一个临时绕行方案（workaround）是否暴露了产品缺口？
• 这项功能解决后，会影响多少部署和多少收入？
• 模型在哪种代码库、工具链或流程中系统性失败？

Wu把客户现场称为最高保真的评测集。实验室基准用预先定义的任务衡量能力；企业现场同时包含模糊目标、权限、遗留代码、人员协作和实际代价。它不仅告诉产品“模型做错了”，还告诉公司“这个错误为什么值得优先修”。

高保真也意味着高噪声。客户问题可能来自产品缺陷，也可能来自错误配置、缺少权限、代码库本身没有测试，或组织不愿改变审查流程。FDE的任务不是把每次失败原样转发给产品，而是给失败建立形状：在哪类仓库出现，前置条件是什么，有多少客户重复遇到，修复之后能解锁哪类任务。

这样整理过的现场证据能够降低路线图风险。产品团队不必只凭最大客户的声音或最激动的销售请求排优先级，而可以看到某个能力缺口影响多少部署、价值多大、是否已有可靠评测。workaround也不再只是临时技巧：如果多支团队都用同一种绕法，它很可能指向应该原生支持的功能。

从token-maxxing到可测结果

早期Agent市场常把使用量当作成功：更多用户、更多session、更多token。模型成本被补贴时，这种指标看起来像增长。进入大型和受监管企业后，预算负责人会问：这些消耗改变了什么？

Token指标还有一个结构性问题：供应商收入可能随使用量增加，客户成本也同时增加。若系统把失败重试、无效探索和过长上下文都算成“采用增长”，双方利益并未对齐。结果指标则迫使团队面对更严格的问题——一美元模型成本换来了什么，节省的人类审查时间有没有被别的瓶颈吃掉。

Wu把下一阶段称为智能编排：Agent承担合适任务，并用结果衡量。一个CLI或IDE可以让个别工程师更快，但要让整个组织更快，还要改变积压管理、代码审查、发布流程和非技术协作。组织速度不是个人速度简单相加。

这也是她对单点工具边界的判断。一个很强的IDE助手可以让最积极的工程师效率显著提高，但企业总体产出还受项目选择、依赖协调、合规审查和上线节奏约束。只有把Agent接入这些组织流程，并让技术与非技术参与者都能看见和信任结果，个体速度才可能转化为组织速度。

什么样的人适合这项工作

Cognition寻找“T型而带尖峰”的人。横向需要客户沟通、业务、流程和技术理解；纵向可以来自不同强项：有的人像产品经理，擅长设计产品组合；有的人是创始人型通才；有的人拥有很深的工程专长。

Wu并不要求每个人在所有维度同样强。产品经理背景的人如果擅长判断产品怎样嵌入流程，可以在产品设计上形成尖峰；创始人型人才习惯在模糊条件下跨职能推进；深技术工程师则能在陌生代码库和客户会议中成为真正的专家。业务感可以通过现场逐步培养，技术可信度却很难只靠话术替代。

团队反复追问两个问题：“为什么要解决这个问题？”以及“怎样让这个经验改善所有客户？”前者防止在低价值任务上烧token，后者把现场劳动变成产品资产。

这套工作也要求相当强的客户承诺。Wu提到团队曾让一名成员在巴西靠近客户生活约十个月，只为确保部署成功。不是每个项目都需要如此长期驻场，但它说明Cognition理解的“deployed”并非偶尔做演示，而是愿意进入客户的节奏，对结果负责到系统真正运行。

她最后说“每个人都是go-to-market”。这不是要求所有工程师去卖软件，而是强调产品、现场和商业不能互相甩锅。产品修复一个现场缺陷是在帮助进入市场，FDE让客户成功是在验证产品，客户反馈改变路线图又回到工程。只要企业购买的是实际工程结果，团队就共同处在价值交付链上。

到这里，我们已经有了问题、范围、流程、产品化和评测。最后一课把这些零件放进一座完整的软件生产系统：信号怎样进入，Agent怎样构建，验证怎样约束，发布之后又怎样产生下一轮信号。FDE也将在这里从单个项目负责人变成软件工厂的设计者。