摘要

Augment 的核心判断是，企业级编程首先是上下文基础设施问题，而不是“从提示词生成应用”的问题。 它的目标客户拥有数百乃至数千名开发者，维护着数百万行持续演进的代码；即便上下文窗口达到100万 token，按每行10 token计算，也只能容纳约10万行代码。因此，产品把“完整理解代码库”作为代码补全、聊天和智能体的基础能力。
它的技术护城河，是同时针对相关性、分支级实时更新、安全性和约300毫秒补全延迟优化的检索栈。 Augment 每次击键都会发起请求，组合使用自研检索器、静态分析、多个模型和用户引导；由于现有产品无法在不复制代码库的情况下，实时提供每位开发者独立分支的视图，Augment 还自建了向量数据库。Guy Gur-Ari 的限定很重要：精细分块有助于处理尾部场景，但“如果检索器足够强、模型足够强，分块就不该成为瓶颈”。
本期讨论中杠杆最高、甚至低调得近乎可笑的 AI 开发实践是：从10到20个自己深度理解的样本开始。 先建立现成方案的基线，必要时手动比较迭代结果，等评估集趋于饱和后再扩展；随后还要结合内部试用和用户反馈，因为没有单一指标能覆盖真实用户的提示词分布和预期分布。目标是把“哲学问题”变成实验。
只要延迟和成本允许，现代 RAG 应优先优化召回率，而不是精确率。 Nathan Labenz 的原则是“把超参数调高”，Gur-Ari 表示认同：如今的模型筛选50或100个检索片段的能力远胜早期系统，而强行把答案压进前5或前10个片段，会让检索难度呈指数级上升。例外是指令：上下文越多，模型仍可能跳步骤或忽略要求。
Augment 的免费层可能形成有价值的数据飞轮，而企业数据则保持隔离，不得用于训练。 IDE 中的活动可以揭示开发者最终选择了哪段代码，从而围绕正确性、风格和代码库惯例，对优劣输出开展强化学习。Gur-Ari 称真实用户数据是“圣杯”，因为它能最大限度缩小训练任务与实际生产使用之间的差距。
代码智能体能创造显著客户价值，却也会冲击传统 SaaS 经济模型。 一条指令可能触发10次乃至更多大型模型调用；Gur-Ari 表示，过去几个月里 Augment 的智能体已经替他写下了全部代码，而部分用户在今天的30美元和60美元套餐之上，已经足以证明每月1,000美元的价格合理。Augment 已融资约2.5亿美元，可以承受试错，但随着智能体运行数小时、整夜甚至无需直接用户触发，Gur-Ari 预计按消耗计费会变得更加重要。
AI 可能很快生成大多数新增代码行，但不会取代负责决策、引导和监督工作的开发者。 Gur-Ari 认为3到6个月的普及预测可能过快，但也不相信转型需要3年：“如果拿走人类，不会发生任何好事。”Augment 仍在招聘优秀的初级工程师，但 Gur-Ari 无法有把握地预测3到6年后的软件就业，并建议自己的大孩子考虑与物理世界联系更紧密的领域。

精读

1. 企业软件开发受制于继承而来的上下文

Augment 成立于2022年，早于 ChatGPT 问世，当时自动补全是最直观的产品信号。Gur-Ari 的团队认为模型正在跨过可用性门槛，但选择了更难的市场：服务于维护和扩展既有系统的专业开发者，而不是生成彼此隔离的全新应用。
典型客户拥有数百名开发者，部分客户甚至有数千名。代码库可能采用 monorepo，也可能按微服务拆分，但通常一开始就是数百万行代码，这意味着功能开发无法脱离历史架构、内部 API、组织惯例，以及仍留在代码树中的过时模式。
Nathan 的个人工作流是把一个小项目拼接起来粘贴给模型，但到了企业规模就会在数量级上失效。Gur-Ari 估算每行代码约10 token，因此即使上下文窗口达到100万 token，也只能覆盖约10万行代码，“而在行业里，这仍然被视为一个小项目”。
上下文并不只是找到一个函数签名。模型必须在多个可行 API 中做选择，填入正确参数，遵循组织偏好的调用方式，并区分当前示例与过时示例；否则，即使理解了局部任务，也会给出糟糕的补全或聊天答案。

2. 每次击键都会触发意图识别与检索问题

Augment 曾通过3个持续数月的研究项目探索代码库理解的3种路径，最终落地于重检索架构。它会上传并索引代码库，使用定制训练的检索模型，再为代码补全、聊天请求和智能体任务选出相关代码。
每次击键都可能启动检索和生成，但 Gur-Ari 希望整条补全链路在约300毫秒内完成。这个预算既包括在大型代码库中识别相关代码，也包括生成答案，因此速度与端到端质量一样，都是“极其重要的功能”。
补全比问答更难，因为用户不会提供一个干净的查询。Augment 需要从光标位置、部分代码以及可能存在的注释中推断开发者意图，然后决定模型需要的是函数签名、当前使用示例、相关实现，还是展示“不该怎么做”的反例。
生产系统混合使用 RAG、静态分析、多个模型，以及通过指定文件或目录实现的显式引导。Gur-Ari 将具体细节称为“秘密配方”，但也降低了一个常见执念的重要性：更好的分块主要解决尾部问题，而“如果检索器足够强、模型足够强，分块就不该成为瓶颈”。

3. 开发者离开代码的速度并不一致

Augment 观察到两类相互重叠的开发者。一类仍然紧贴编辑器，高度依赖代码补全；另一类主要通过聊天工作，分配任务、审查提议的修改，而不是亲自编写每个函数。
“Next Edit”延续了以代码为中心的工作流，同时扩展了自动补全能力：它可以脱离光标位置运行，删除或修改既有代码，辅助范围也不再局限于追加文本。这种辅助不要求开发者放弃编辑控制权。
智能体模式又后退了一步：它可以编辑多个文件、运行测试、执行命令，并返回一个更大的工作单元。不过在大型代码库中，开发者仍然经常亲自检查并修复代码；Gur-Ari 预计，企业级自主工作流会晚于从零生成应用的场景到来。
Augment 支持 VS Code、JetBrains 和 Vim，而不是强迫所有人使用 VS Code 的分叉版本。分叉能带来更深的界面控制，但也意味着要维护更新和安全补丁——这对企业销售尤其关键——同时还要求 JetBrains 用户进行较大的工作流迁移。

4. 实时分支隔离迫使 Augment 自建数据库

Gur-Ari 对新鲜度的要求非常具体：开发者或聊天功能刚创建一个函数，下一次编写测试的请求就应该立即检索到它。因此，模型需要的是几乎实时反映每位开发者当前代码的视图，而不只是一个静态代码库索引。
这些视图必须保持隔离，因为出于安全等原因，两个开发者的功能分支不能相互泄漏。同时，Augment 又希望对共享代码库内容只保留一份去重后的表示，而不是为每位团队成员复制一个庞大的索引。
传统的近似向量技术通常会对 embedding 聚类，以降低查询成本。频繁更新会让这些结构难以维护，而带过滤条件的视图又可能导致统计搜索完全错过相关子集；Gur-Ari 表示，Augment 创立时，他们知道的产品没有一个能同时满足这些要求。
数据库建设过程很难，更大客户的代码库也仍在带来持续的扩展工作。Erik 认为它可能成为一个独立产品；Gur-Ari 原则上认同，但表示 AI 实验室反复遇到可以商业化的基础设施，真正困难的战略纪律是专注于“最好的 AI 助手”。

5. 10个样本足以启动严肃的 AI 研究

Gur-Ari 在启动检索或模型项目时，默认只使用10到20个经过精心人工标注的样本。先运行最简单的现成基线，判断它能解决20%、80%还是介于两者之间的问题；等这组样本趋于饱和，再加入更难、更多样的案例。
小样本的优势在于研究者对每个案例都足够熟悉，而不在于统计规模有多大。研究者可以把所有案例记在脑中，理解一次改动为何有效或无效。对于本质上主观的任务，真实标签甚至可以后置：让新旧系统并排运行，再手动评判全部10个样本。
Nathan 将这种做法与创意工作联系起来：两位评审可能会对哪份剧本、旁白或图片选择最好产生分歧。即便如此，围绕10个“完成得很好”的样本达成共识，也能暴露团队内部未被发现的分歧，为实验提供稳定的起点。
没有任何评估能与用户体验完全对齐。提示词分布、用户预期和质量维度都难以压缩成一个数字，因此 Gur-Ari 坚持认为，系统上线后必须进行内部试用并直接收集用户反馈：评估仍然不可或缺，但不能替代对真实使用情况的观察。

6. 现代 RAG 靠检索更多取胜，而不是假装精确率没有成本

现实世界的检索“几乎从来不是单一手段”。Embedding 可以与结构化过滤器及其他有用信号结合，同时向模型提供足够多的材料，确保正确证据在其中；对于现代模型，召回率通常比无可挑剔的精确率更重要。
Nathan 的原则是“把超参数调高”：检索更多片段，并围绕每个命中点向更远范围扩展，同时接受一定的延迟和成本。只要这些取舍可负担，Gur-Ari 完全赞同，因为模型处理干扰信息的能力已经大幅提升。
让答案出现在前50或100个片段中的某处是可实现的；但强行把答案压进前5或前10个片段，会让研究问题“难上一个指数级”。Gur-Ari 预计，长上下文检索还会持续进步，因为 Transformer 的注意力机制本来就是为了筛除噪声、聚焦相关材料而设计的。
但指令密度是一个例外。模型可能能够容忍大量检索证据，却仍无法遵循很长的命令清单，跳过步骤或默默忽略要求。因此，检索上下文扩展和指令遵循是两个不同的问题，当前也面临不同的上限。

7. 定制训练必须用更快的实验速度证明其复杂性值得

Gur-Ari 反复看到一种倾向：过早转向复杂研究。他的建议是优先保持简单，相信面向任务的评估，先用尽现成模型和检索方法，只有实验显示简单方案仍然不够时才进行微调。
迭代速度影响的不只是何时找到解决方案，也影响能否找到。把一次实验从数小时缩短到数分钟，可能让团队完成100次尝试，而不是10次；这足以发现某个意外的开源模型、SQL 风格过滤器、embedding 或组合方案恰好适合该任务。
Augment 本身不预训练基础模型。在 Llama 出现之前、开源模型还很弱时，它押注公开技术和现有专家能力会快速改进这些模型；如今，它会针对检索、补全和 next-edit 生成，对强大的开源基础模型进行后训练。
Nathan 提议继续在专有公司知识上进行预训练，但 Gur-Ari 反对，认为这类数据集同时面临两个问题：对提示词来说太大，对高效训练来说又太小。多轮训练可能导致记忆化，持续更新也会制造摩擦，而为每位用户训练 email 模型在运营上并不现实；他会先部署一个智能体，让它反复搜索，直到认为自己已经找到答案。

8. 开发者行为形成罕见的训练数据飞轮

Augment 划定了明确的数据边界：企业客户数据不会被查看，并受到审计访问控制的保护。其免费社区层明确面向那些愿意让 Augment 检查自身活动、并将其用于改进模型的用户开放，无论他们的代码是否开源。
IDE 提供了普通聊天缺失的信号。聊天系统能看到问题和答案，却很少知道理想的真实答案是什么；而通过跟踪编辑会话，Augment 最终可以推断开发者真正想完成什么，因为实际工作发生在 IDE 中。
强化学习随后利用的是对比，而不是二元的正确答案：一份输出可能因为算法正确性、开发者偏好、风格，或与周边代码库保持一致而优于另一份输出。Augment 最初将这种“从开发者行为中强化学习”的方法用于打造更好的补全模型。
Gur-Ari 认为互联网数据基本已经被耗尽，剩下的路径是合成生成、付费人工标注和产品使用数据。用户数据是“圣杯”，因为它与部署任务一致；但要超越人类能力，最终仍需要外部奖励：可执行代码和科学实验都符合条件，而在没有更强评估者的情况下，自主判断一首诗则不符合。

9. 智能体使用打破传统 SaaS 的经济模型

Augment 已融资约2.5亿美元，但薪酬并不是唯一重要支出。每次击键都提供检索和推理服务，成本很高，训练还会增加支出；Augment 租用 GPU，而不是运营数据中心。单位价格下跌的速度，跟不上使用量增长和对最新模型的需求。
随着智能体介入，工作量及账单都会上升：一条指令可能触发10次或更多模型调用，包括大型文件编辑、shell 命令及对其输出的解释。价值也同样可观：Gur-Ari 表示，自己“几个月来没有写过一行代码”，而智能体已经写了大量代码。
目前每月30美元和60美元的套餐，与高度分化的使用量分布并存；即使现在，也有部分用户能够证明1,000美元的价格合理。Augment 已经销售仅在开发者实际使用产品时才消耗的 credits，使付费方式比无论是否采用都要购买的传统席位制更贴近实际活动。
本期没有给出明确的定价答案：企业客户重视可预测性，但与使用量挂钩的成本，以及越来越自主的智能体，都在推动按消耗计费。随着智能体运行数小时、整夜乃至数天，并通过 API 发起代码审查而非等待用户直接提示，按开发者订阅的模式可能越来越不合适。

10. AI 会先写代码，再获得完整的软件工程所有权

Gur-Ari 对 Dario Amodei 关于短期内出现超人类程序员的判断有一个狭义解读：查看一行新生成的代码，它越来越可能是模型写的。考虑到采用速度，3到6个月可能过快，但他也不认为这一变化需要3年。
生成代码不等于自主软件开发。人类仍然决定构建什么、引导智能体并监督结果；用 Gur-Ari 的直白说法，“如果拿走人类，不会发生任何好事。”模型还无法仅凭产品需求，就可靠地独立构建出完整系统。
更长期的劳动力需求远不确定。企业仍需要理解系统的人，因为“如果你只是凭感觉编写企业软件，最终会遇到麻烦”；但生产率提升后究竟需要多少开发者，没有人知道。Gur-Ari 无法有把握地预测3到6年后的情况。
Augment 仍同时招聘初级和高级工程师，筛选标准是卓越能力；Gur-Ari 预计，在转型过程中，从智能体中提取价值的能力会变得重要。但他给14岁孩子的建议是考虑机械工程、机器人或其他与物理世界紧密相关的领域，因为这些领域可能需要更长时间才会受到冲击。

Palmer Luckey 谈 AI 驱动的下一波军事科技 | EP #158 医疗领域，真实来源是对话：与 Abridge CEO Shiv Rao 对谈