Tenex 的 AI 原生研发：按成果付费，让智能体读懂项目

AI 降低了编写代码的成本，却没有自动解决软件开发中的其他难题：应该做什么、如何验收、谁来维护，以及如何奖励真正有价值的工作。

Tenex 的 Alex Lieberman 与 CJ Hess 围绕这些问题，介绍了他们在工程组织和企业 AI 落地中的实践。核心问题是：当开发速度越来越快，如何衡量工作的价值，而不只是计算投入的时间？

一、按成果付费，也要看见代码之外的工作

Tenex 的出发点是改变传统的按小时计费模式。如果工程师借助 AI 更快完成相同任务，按小时收费反而可能让收入下降。Tenex 希望让激励方向与效率提升保持一致。

目前，故事点仍是其工程师薪酬的重要组成部分。Alex 表示，外界担心的虚报工作量、为积累点数而交付低质量代码，并不是他们遇到的最大问题。负责客户留存与增长的 AI 策略人员，也有动力对无助于客户的工作提出异议。

更难处理的是那些不容易被拆成工单的贡献：

CJ 的工作变化体现了这一点：随着模型能力增强，他直接编写代码的时间减少，整理客户上下文的时间增加。围绕已交付任务设计的薪酬制度，也需要为这些工作留出空间。

据 Alex 介绍，Tenex 已发展到 75 人，客户包括《财富》2000 强企业和中型企业。客户需求也在从 AI 辅助开发，逐渐扩展到企业范围内的 AI 转型。

Tenex 使用的 MetaHarness，不只是让智能体更快写代码的工具，而是一套共享技能、项目文档与命令行工具组成的工作体系。

其中一个关键做法是：计划和决策与代码一起纳入 Git 管理。 当智能体重新接手任务时，它不仅能查看已经实现的内容，也能了解团队为什么这样设计。

这套工作方式强调让人和智能体围绕同一份项目记录协作，并结合 Linear、GitHub 和客户进度更新等工作界面。需要被清楚表达的不只是代码，还有计划、验收标准、决策及其依据。

不过，结构化管理并非越多越好。对于只做一个项目的小团队，这样的体系可能过于繁重。它的价值需要与维护这些记录的成本一起衡量。

“Kill My SaaS”实验提供了一个具体案例：团队尝试替换一款年报价为 4.3 万美元的会议演讲者管理工具，共收到 72 份提交作品。

一个值得注意的结果是：人工评委选出的获胜作品，在 AI 评委的排行榜上仅列第 19 名。这说明，检查软件能否通过一组场景，与判断人们是否愿意使用它，并不是同一项工作。

对于自建软件，Alex 提醒，企业规模越大，替换既有系统的成本和风险往往越高。即使只是一个较小的工具，也需要有人持续维护。节省下来的费用，是否足以覆盖长期投入，不能只看首次开发成本。

支持自建的一方则强调，收益不只是减少账单。拥有工作流的控制权，意味着可以改善演讲者与运营人员的体验，更快迭代，而不必等待供应商排期。

因此，这里的取舍并非简单的“购买还是开发”，而是要同时考虑订阅支出、替换风险、持续维护，以及自主改进工作流的价值。

Alex 对垂直领域 AI 产品总体持谨慎态度。他提出两个疑问：如果每家企业都需要高度定制，产品如何保持软件业务的利润率？随着通用模型持续进步，专用产品中的多少任务会被通用工具吸收？

另一种观点则以 Harvey、OpenEvidence 等产品为例，强调领域数据、专门界面、系统集成和用户习惯仍可能发挥作用。即使底层模型人人可用，围绕模型构建的工作环境也不一定容易替代。

彭博终端是讨论中的一个类比：交易员可以从其他渠道获取市场数据，但终端把数据、工作流、沟通与使用习惯结合在了一起。

CJ 进一步区分了两类产品：一类主要提供“让智能体执行某项任务”的能力；另一类则改善围绕任务展开的实际工作流。

这让问题变得更具体：哪些产品会成为用户持续工作的场所，哪些能力最终会变成既有智能体中的一个功能？

Tenex 的实践没有给这些问题提供统一答案，但呈现了 AI 原生研发的几项现实取舍：效率提升后如何分配收益，如何记录业务上下文，以及如何权衡快速构建与长期维护。

对于正在引入 AI 编程的团队，一个值得讨论的起点是：当前的考核与交付机制，能否识别那些让代码值得被写出来的工作？