Tenex 的 AI 原生研发实践：按成果付酬，让智能体读懂项目
当 AI 能让工程师更快完成任务，按工时付费就可能出现激励错位：同样的工作，做得越快，收入反而越少。Tenex 尝试把报酬与交付成果挂钩，但随着模型能力提升，另一个问题也变得突出：理解需求、设计架构和判断该做什么，应该如何计价？
Alex Lieberman 与 CJ Hess 介绍的实践，不只涉及编码工具，也涉及软件开发生命周期（SDLC）的组织方式。
一、按成果付酬，难点不只是防止“刷分”
Tenex 仍将故事点作为工程师薪酬的重要依据。Alex 表示，外界担心的估算膨胀、为积累点数而交付低质量代码，并不是他们遇到的最大问题。
其中一项约束来自角色分工：Tenex 的 AI 策略师负责客户留存和业务增长，因此有动力对不符合客户利益的工作提出异议。
更难处理的是那些无法整齐拆进任务单的工作：
- 理解客户真正要解决的问题；
- 设计系统架构；
- 判断哪些功能值得开发；
- 将客户背景整理为模型可以使用的上下文。
CJ 表示，随着模型变强，他直接编写代码的时间减少了，整理客户上下文的时间则增加了。以交付任务为中心的薪酬制度，也必须为这些工作留出空间。
据 Alex 介绍，Tenex 团队已发展至 75 人，客户包括《财富》2000 强企业和中型企业。客户需求也正从 AI 辅助软件开发，扩展到公司层面的 AI 转型。
二、MetaHarness：让代码仓库保存“为什么这样做”
Tenex 将一套共享技能、项目文档和命令行工具组合称为 MetaHarness。其关键做法是：把计划和决策与代码一起纳入 Git 管理。
这样，当智能体重新接手任务时，它不仅能看到已经实现了什么，还能理解团队为什么作出这些选择。
这套工作方式以人和智能体共同使用的项目记录为基础，并提供面向 Linear、GitHub 和客户进度更新的视图。需要明确记录的内容包括：
- 项目计划；
- 验收标准；
- 关键决策；
- 支撑判断与交付的证据。
这里的区别是：让智能体写代码更快，与让智能体理解项目，是两项不同的工作。
不过，结构化管理也有成本。Tenex 同时指出，对于只做一个项目的小团队，这样的流程可能过于繁重。
三、自建软件：开发便宜了，维护责任仍在
讨论中的一个案例，是“Kill My SaaS”实验：尝试替代一款年报价为 4.3 万美元的会议演讲嘉宾管理工具。
实验共收到 72 份提交作品。人工评委选出的获胜团队，在 AI 评委排行榜中只排第 19 名。这一差异提醒人们：检查软件是否满足一组场景，与判断用户是否愿意使用它，并不是同一回事。
对于企业自建软件，Alex 提出了两点顾虑：
- 企业规模越大，替换成熟系统的成本和风险往往越高。
- 即使只是一个小工具，也需要有人长期维护，节省的费用是否足以补偿持续投入，需要单独衡量。
支持自建的一方则强调，收益不只有账单上的节省。掌握工作流后，团队可以改善演讲嘉宾和运营人员的体验，并更快迭代，而不必等待供应商排期。
因此，这里的权衡不是简单比较订阅费与开发费，还包括工作流控制权、迭代速度与持续维护负担。
四、垂直 AI 的分歧：完成任务，还是承载工作流？
Alex 对垂直领域 AI 产品总体持谨慎态度。他提出两个问题：如果每家企业都期待独一无二的解决方案，产品如何维持软件业务的利润率？随着前沿模型进步，又有多少任务会被通用工具直接覆盖？
另一种观点则强调，即使底层模型人人可用，领域数据、专门设计的界面、系统集成和用户习惯仍然可能有价值。讨论中提到了 Harvey、OpenEvidence，以及作为类比的 Bloomberg 终端：用户购买的不只是数据，还包括工作流、沟通方式与既有使用习惯。
CJ 则区分了两类产品：
- 核心卖点是让智能体执行某项任务的产品；
- 改善这项任务周围实际工作流程的工具。
这使问题从“垂直 AI 会不会胜出”，转向了一个更具体的判断：哪些产品能成为用户持续开展工作的场所，哪些能力会被整合进用户已有的智能体？
值得继续讨论的问题
- 当编码不再是主要耗时环节，团队如何认可需求澄清、架构设计和上下文整理的价值？
- 项目文档应结构化到什么程度，才能帮助智能体而不拖累小团队？
- 决定自建工具前，谁负责维护，如何评估长期投入？
- 一个 AI 产品的价值，究竟在单次任务完成能力，还是在它承载的完整工作流？