Tenex 的 AI 原生工程实验：代码更容易生成之后，组织如何改变

一、嘉宾背景

在这期 Latent Space 访谈中，Tenex 联合创始人 Alex Lieberman 与特别项目负责人 CJ Hess，讨论了一家 AI 原生团队如何组织工作，以及它在服务企业客户时遇到的阻力。CJ 开场先纠正了主持人的介绍：他并非工程总监，而是公司首位员工，软件工程师出身。Alex 更多谈商业模式与企业客户，CJ 则侧重内部工程系统的运作。

Alex 将 Tenex 定位为帮助企业走向 AI 原生的应用 AI 合作伙伴。按他的描述，公司从 AI 辅助开发服务起步，随后应客户要求，扩展到更广泛的 AI 转型工作。他在节目中称，Tenex 成立约十八个月，共有七十五名员工，约九成岗位是工程师或 AI 策略顾问；客户一半来自财富两千强，另一半是年营收一亿至五亿美元的中型企业。这些经营数据来自他的介绍，未经独立核验。

CJ 负责的特别项目包括内部工程 harness 和平台建设，目的是帮助能够承担实际工作的后台代理进入企业环境。两人的判断由此具有明确的位置：他们既在改造自身的工程生产方式，也在参与客户的 AI 实施。这些经验能揭示具体的组织与交付问题，但其适用范围仍需结合企业自身情况判断。

二、本期主要内容

CJ 对薪酬制度的关注，来自自己的咨询经历：AI 让他更快完成项目，按小时收费却意味着收入随之减少。Tenex 吸引他的地方，正是让工程师按产出获得回报。公司主要以双方约定的故事点衡量工程产出。Alex 说，收入最高与最低的工程师大约相差四倍；这一差距反映了公司内部的薪酬分布，并不能直接说明两者的业务贡献也相差四倍。

按产出付薪，随之而来的问题是如何定义产出、如何约束质量。Alex 说，AI 策略顾问的激励与客户留存和增长挂钩，可以制衡工程师追求交付数量的动机。按他的观察，虚增故事点或交付质量欠佳的代码，尚未成为主要困扰；更难处理的是架构设计、客户会议等非编码劳动该如何计酬。这是他对内部运作的评价，访谈没有提供独立的质量审计结果。

CJ 认为，模型承担越多实现工作，理解客户需求、为模型提供上下文就越有价值。他提到，只要上下文合适，模型可以完成解决方案的九成。这是他的经验判断，不能视为适用于所有项目的成功率。但它指出了计酬中的一个问题：如果需求理解仍由人承担，仅按编码任务衡量产出，就可能漏掉让代码真正有用的前期工作。

Tenex 为此建设了名为 meta harness 的内部工程体系。它从标准化 skills 起步，逐渐扩展为仓库文档和 CLI，支持计划、可视化、客户说明材料，以及代理的执行与决策记录。CJ 说，这些材料会提交到 Git；随着模型能力提升，一些结构和格式要求已经放松，但仍要求代理留下活动与决策依据。

保存这些记录，是因为代码通常只能呈现做了什么，未必能解释为什么这样做，也无法完整保留客户讨论中的背景。把上下文和理由留在仓库里，后续接手的工程师与代理就能自行检索，减少对原始参与者记忆的依赖。至于这套工作方式带来的产出变化，Tenex 追踪每位工程师每月的平均故事点。CJ 估计，当年的工程产出大约翻倍，同时承认故事点标准至少每季度重新校准一次。因此，这个数字应作为内部观察来理解，无法等同于计量条件固定的生产率实验。

三、核心观点：推理、例子与边界

给员工配备模型工具，距离让组织把工作交给代理，还有多远？Alex 以 Tenex 正在接触的约一百家企业为范围，估计九成已经部署通用模型，六成开展过培训，五成有效部署了编码代理，而在非工程工作中使用生产代理的只有约百分之五。这些估计不代表整个市场，却呈现了他在客户中看到的落差：工具已经普及，能够承接业务的代理仍然少见。

CJ 用四十个人承担相似职能、却各有做法的例子解释这一落差。逐个帮助员工使用 AI，可以容纳不同的工作习惯；让后台代理主动完成工作，再交由人审阅、退回，就需要共同的输入、步骤和验收标准。缺少这些标准，系统难以判断结果是否正确，也难以建立有意义的评估。标准化因此是自动化的准备工作，但这并不意味着统一流程就足以解决实施中的所有问题。

权限是另一道门槛。Alex 说，客户反复提出两类需求：自动处理重复性的后台工作，以及控制模型能够读取哪些数据。Tenex 为此从定制权限系统，逐渐转向自有网关方案。工具具备访问数据的能力，并不等于使用它的员工拥有相应权限，两者需要在系统设计中明确对应。访谈没有展开网关如何执行权限、如何验证隔离效果，因此还无法据此判断其解决企业安全问题的程度。

模型选择同样要放回具体任务中衡量。CJ 描述了多种模型与环境的配合：用 Codex 做审查和部分计算机操作任务，用 Amp 进行云端执行和跨模型审查。他关注的是实现、检查与执行环境如何协同。嘉宾认为，近期完成单项任务的模型成本有所下降；CJ 也保留了另一种可能：如果昂贵模型能显著改善结果，支出仍可能重新向它们集中。主持人则以移动电子表格单元格为例，追问更强的模型能力是否总能抵偿更高的费用。访谈没有提供统一的基准测试，模型是否值得付费，仍需看它在具体任务中带来的收益。

对垂直 AI 的分歧，集中在企业落地所需的工作能否形成可持续的产品价值。Alex 担心，企业的定制与集成需求会迫使软件公司持续投入大量服务，而前沿模型又可能吸收其中一些能力。主持人以 Harvey、OpenEvidence 反驳，强调专业数据、界面、集成和既有使用基础的价值，并用 Bloomberg、Superhuman 作类比，说明专业工具仍可能有充分的付费理由。这些例子支撑的是双方的论证，并非对相关公司竞争优势的独立验证。

CJ 进一步区分了两类产品：一类主要出售某项垂直代理能力，另一类先组织工作流程，再加入代理。前者如果缺少战略性数据或合规优势，可能更容易受到模型进步的冲击；后者则仍可能凭借对工作流程的组织能力保有价值。判断一个垂直产品的前景，需要具体看它掌握的是容易复制的任务能力，还是客户日常工作依赖的数据、流程与工具。

自建 SaaS 的讨论也涉及同样的长期判断。主持人称，一项年报价四万美元的服务，已经用约一千美元构建了替代品，但计划到下一场会议才投入生产，尚未积累完整的生产运行记录。这个案例能够说明初次开发成本的差距，却无法回答全年运行总成本是多少。Alex 强调，大企业替换既有系统，一旦失败，后果更重；拥有非核心软件也意味着持续维护和认知负担。主持人则补充，自建还可能改善参与者体验、加快迭代。采购还是自建，因此既要算开发与订阅费用，也要判断组织是否值得长期拥有这套软件。

四、学习与应用

对团队管理而言，Tenex 的实践首先提出了一个问题：产出、质量和协作劳动如何分别得到评价？采用故事点付薪，需要事先约定估算办法、交付验收者和返工处理方式，也需要让架构设计、需求澄清、客户沟通获得相应评价。AI 策略顾问的激励安排提供了一种制衡思路，但客户留存和增长无法自动证明每项技术决策都正确。随着模型能力变化，计量标准也需要调整；比较历史产出时，应同时保留标准变化与实际交付内容，避免把故事点增长直接等同于商业收益增长。

在仓库中保存上下文，可以从近期项目入手：除代码之外，留下任务目的、关键约束、方案选择的理由、客户讨论中促成方向变化的信息，以及执行和验收记录。这些材料的用途，是让接手者能够理解“为什么这样做”。CJ 提到部分格式要求已经放松，也说明团队需要持续检查记录是否有助于后续决策，而不能只看模板是否填满。

选择企业代理项目时，可以先从一项重复工作开始，请不同执行者说明各自如何判断任务完成，再梳理共同输入、例外情形和退回条件。如果团队尚未对正确结果形成一致认识，先提供个人辅助工具、继续整理流程，更符合 CJ 描述的实施条件。进入自动执行阶段，还需要明确数据读取权限、结果由谁审阅，以及何时交回人工。Tenex 的网关方案提供了一个方向，具体权限行为仍需验证。

模型采购和软件自建，都需要围绕完整任务计算得失。比较模型时，可以考察结果是否可接受、需要多少审查，以及每次完成任务的费用，再判断更强模型带来的改善是否值得额外支出。比较采购与自建时，则需要一起考虑初次开发、迁移、持续维护、故障影响和体验改善。主持人提到的低价替代案例可以启发试验，但尚不足以证明核心系统能够低风险替换。评估垂直产品，也需要追问模型能力提升后，产品所提供的数据、专业交互、系统连接和流程组织是否仍有必要。

自动化之后的人员安排，需要落实到具体职责。CJ 希望将人员从被自动化的工作转向其他业务问题，包括跨团队协调和战略性资源配置。这可以作为设计新岗位的起点，却不能保证员工一定会被保留；他也承认 AI 会改变并取代一些岗位。Alex 认为，雇主和员工都需要参与技能再培训，同时反对“AI 只会拿走人们不喜欢的工作”这种宽慰，因为许多人工作首先是为了收入。企业提出人员再配置时，需要说清后续职责、所需训练与转岗机会；员工也需要据此判断应补充哪些能力。Alex 认为，培训和使用支持可能与技术本身同样重要。提供工具账户之后，仍需有意识地教会员工如何将其用于实际工作。

访谈最后关于纽约的讨论，把这些问题重新带回客户。Alex 认为，纽约的 AI 社群规模小于旧金山，却有大量商业机会；结束时的讨论也强调，技术团队需要接触客户，让技术接受实际业务的检验。落实到项目中，就是在讨论每项新能力时，确认谁会使用、如何验收，以及谁承担长期责任。商业需求有助于确定值得解决的问题，自动化是否创造价值，则仍需由实际结果回答。

来源

• 原始节目：AI in NYC: How Tenex Builds an AI-Native Engineering Team — Alex Lieberman & CJ Hess