PostHog 的 FDE 服务按里程碑收费，不按小时

PostHog 的公开手册写得很明确：前线部署工程师（FDE）的工作按里程碑报价，不按小时计费。手册里还有一条更严格的规定：任何交付物，一旦范围扩大到原来的两倍，就必须重新报价，不能悄悄延期了事。

这一决定也已经体现在公开的 /services 页面上。posthog.com 代码仓库的一个拉取请求（PR）把每个里程碑的最低价设为 5,000 美元，取代了此前的一条规定：费用约为客户第一年所购额度的 20%。该 PR 称，这是 FDE 团队有意做出的选择。

PostHog 没有解释原因。不过它在概览页面上写道，AI 让人们开发得更快，因此团队真正提供的价值是判断力、品味和推理能力。

PostHog 自己并没有把这两点联系起来。但如果真正的价值在于判断力，按小时计费就很难站得住脚，因为工时只能衡量产出。

对正在做 FDE 或想做 FDE 的工程师来说，这套模式值得细读。它展示了如何把平时难以看见的判断力，变成客户可以签收的东西：一个里程碑、一份报价、一次验收。

为什么工时是错误的衡量标准？

PostHog 的“How we work”页面说得很直白：FDE 的价值不在于产出多少，而更在于他们给工作带来的判断力。

设想两位 FDE 接到同一项任务。第一位用两周写了 3,000 行脚本。第二位先花两天向客户提问，发现计划迁移的事件中有三分之二早已没人使用，于是只用一周迁移了剩下的部分。

按小时计费，第一位赚得更多。按里程碑计费，第二位胜出，客户也一样。因此，这种定价模式迫使整个团队先回答“该做什么”，再回答“做多少”。

这个观点并非 PostHog 独有。IndiaNIC 在讨论代理机构定价时指出，一旦 AI 压缩了交付物背后的工时，按小时计费就会惩罚干得快的人、奖励干得慢的人。

客户也有自己的顾虑。Ghanemzadeh 从从业者角度撰写 FDE 定价相关文章，他描述了常见的按工时和材料计费的模式：工作没有明确的终点，总成本要到合作结束时才看得清。

里程碑必须足够窄，价格才可信

固定报价不是万能药。Ghanemzadeh 本人也指出，只有范围足够窄，“固定结果、固定价格”才是诚实的。正因如此，定价单位必须是定义清晰的里程碑，而不是一整个模糊的项目。

假设某客户想把分析数据从旧工具迁移到 PostHog。差的里程碑写的是“支持迁移”。好的里程碑写的是：三个主要应用的事件接入 PostHog，五个最重要的看板与旧系统数据一致，约三周完成。

第二种写法可衡量、有边界、可检查，所以才能报价。客户读到它时，要么点头，要么说“其实我们最需要的是收入看板”。两种回答都有用，因为分歧在任何人写下一行代码之前就暴露出来了。

PostHog 的手册还鼓励 FDE 尽早分享未完成的工作，方便同事对方向提出意见。落到里程碑上，实际的建议是：描述发给客户之前，先请一位同事读一遍草稿。这个阶段判断失误，代价比之后任何阶段都高。

范围扩大时怎么办？

回到迁移的例子。第二周过半，客户问：既然在做了，能不能顺便把数据同步到数据仓库？对很多工程师来说，本能反应是答应下来，让客户满意。

PostHog 的规定恰恰拦住了这种本能：范围翻倍的交付物必须重新报价，而不是作为额外工作顺手消化。这条规定同时保护了双方。FDE 不会被拖进一个没有尽头的项目，客户也能得到明确的决策，而不是一张意外的账单。

这条规定背后的能力，是能在不伤害关系的前提下说出“可以，但那是另一个里程碑”。现在就可以练习，对象是那些不断找你加活的内部团队。

“完成”意味着客户方有人签字

根据 PostHog 的“Working with customers”页面，只有交付物已经上线，并由客户方一位指定负责人验收，里程碑才算完成。不是“客户看起来挺满意”，也不是“工时用完了”，而是由一个具体的人负责说出“这个通过了”。

在迁移的例子中，这个人可能是客户的数据负责人，他打开五个看板，确认数据一致。这就要求你在一开始就明确：谁来签字，按什么标准检查。

一条相关的建议：写好文档，让验收人不需要你坐在旁边也能检查工作。如果只有 FDE 自己知道脚本怎么跑，这个签字就很难拿到。

每个里程碑之后留下什么

里程碑可以结清一张发票，但 PostHog 不希望经验也随之结束。手册要求 FDE 把为某个客户构建的东西，只要对其他客户也有用，就转化为示例、模板或产品改进。

概览页面补充说，在多次合作中反复出现的模式，会沉淀为可复用资产和产品改进。

DataCamp 点出了其中涉及的能力：产品判断力，就是决定哪些部分应为单个客户定制、哪些属于核心产品。选错了，就会留下一堆没人能维护的一次性代码。DataCamp 还提到，优秀的 FDE 会把一线经验带回产品工程团队，让平台对所有人都变得更好。

在迁移的例子中，为第一个客户写的脚本，整理之后可能成为第十个客户的模板。这同样是判断：哪些部分足够通用、值得投入，哪些应该保持一次性。

维度	如果按小时计费（对比情景）	PostHog 的 FDE 模式
定价单位	工作时长	每个里程碑，设最低价
客户成本	合作结束后才知道总额	每个里程碑事先可知
AI 加快工作时	干得快的人吃亏	价格与交付物挂钩，与工时无关
范围扩大时	很容易不断追加工时	范围翻倍即重新报价
终点	容易以工时或预算耗尽为准	已上线并由客户方指定负责人验收
留下什么	没有具体要求	示例、模板、产品改进

中间一列是根据按小时计费的逻辑推演出的对比情景，并不描述任何特定公司。逐行对照可以看到，右列总是迫使工程师更早、更公开地做决定。判断力无法直接衡量，这是组织间接看见它的一种方式。

面试和简历可以借用 PostHog 的信号

PostHog 的手册提供了一套现成的信号可供对照：按里程碑报价、范围扩大即重新报价、由客户方指定负责人签字验收、把经验转化为可复用资产。阅读任何 FDE 岗位描述时，都可以留意这些机制的痕迹。

面试时，可以直接借用 PostHog 的规定发问：交付物范围翻倍时，团队是重新报价，还是悄悄延期？还可以问客户方由谁签字验收，以及你的工作中哪些部分会被做成模板，用于下一次合作。

写简历时，可以沿着一个里程碑的生命周期来写：开工前你约定了哪个可检查的结果，什么时候说过“那是另一个里程碑”，客户方由谁验收了工作，你留下的东西又如何让下一项工作做得更快？

如果你已经是 FDE，成本最低的练习是：每项工作都以半页“完成”的定义开头，以客户签字收尾。当编码速度不再能区分工程师的高下，这两个习惯就是别人愿意付钱的地方。