我作为创始人做的第一款产品，并不是在上线那天失败的。它是在第 41 天失败的。
那是 2023 年一个周二上线的。典型的那种上线 —— 清单跑完，三个人发短信互相恭喜。五周后，使用量曲线拐向了一个我们没有设计过的方向，某个监管辖区变了一条我们没在盯的规则，而客户方内部最早支持这个项目的那位负责人跳槽去了别家公司。那会儿外部工程团队已经走进下一个项目整整三十天了。客户给我们打了电话。我们是这笔交易里的咨询方。我们也在 SOW 里写得很清楚 —— 我们不做上线后支持。
我们还是接了这通电话。我们花了四周时间解决了那个问题 —— 公平地说，它是那家工程团队合同意义上的胜利，同时是我们合同之外的麻烦。四周结束的时候，我第一次把一句话写了下来，这句话后来成了这家公司的运作前提：
“让咨询公司写策略、设计公司画线框、开发公司写代码、运维公司兜底” —— 这套分工本身就是问题。
这篇文章谈的是我们为什么留下来。它也谈另一件事：为什么我们认为行业对这个问题的主流答案 ——“交付”是一个时间点，“维护”是另一份合同 —— 正是让大多数技术项目悄悄失去意义的原因。
把一个刚上线的产品交给陌生人的代价
一个产品在上线后的六个月里，会发生比之前一年更多的真实事情。用户真的开始点那些我们以为没人会点的地方；监控第一次在凌晨三点报警；客服开始收到我们从未设想过的问题；监管部门动了一条规定；合作方的 API 换了认证方式；同公司的另一款产品上线，把唯一在关注这个产品的内部 stakeholder 的注意力吸走了。
这些事情每一件都是一节课。而这些课大多数只在事件发生的前后四周内存在 —— 如果没有人带着上下文在看这个产品，那节课就会溶解掉，剩下的是安静的债务：某个指标莫名其妙地下滑、一个没人记得为什么做过的小功能、客服粘贴同一个答案去回应其实一个下午就能修掉的问题。
如果设计和工程团队在 v1 那天就解散，这些真实事件就无处着陆。实际会发生的情况是：客户内部团队 —— 他们既没造过这个东西，也常常不知道它为什么被造成现在这个样子 —— 继承了一堆 Jira 工单和一张 PagerDuty 排班表。一个季度之内，大部分教训丢了。两个季度之内，这个产品的走向就取决于”当时谁在值班”，而不是”谁还记得它本来想做成什么”。
我们在咨询位子上见过这种情况反复发生。这是好的计划上线后悄悄不再是好计划的头号原因。
具体的做法
每个我们参与上线的项目，都有一位驻场工程师，以及一位产品经理，在上线后至少 12 周内直接拥有它。监控、增长度量、合规续约、小版本，全部由他们负责。这不是”维护合同”—— 这是交付的一部分。
// 默认的合作形态
const shape = {
phase_0: '咨询', // 第 1–3 周
phase_1: '设计', // 第 2–8 周
phase_2: '建造', // 第 6–18 周
phase_3: '上线', // 第 18 周
phase_4: '运维', // 第 18 周 → 持续 ★
};★ 号那一行才是这篇文章真正想说的部分。
“交付”不是一个时间点。它是一种持续状态 —— 软件还在跑、还在被用、还在被改。
三条原则，每一条都是写进合同的承诺
嘴上说”我们留下来”是免费的。把公司结构设计成”留下来是默认选项” —— 这才是我想讲的。
1. 我们签客户的指标，不签自己的
传统工程服务商的成功标准是”按规格、按时间、按预算交付”。这是服务方自己的局部最优，对客户来说常常并不相关。我们每一次合作都定义一个量化指标，属于客户 —— 比如”每月使用这台设备的讲解员人数”、“创意审核单轮周期时间”、“p99 同步延迟” —— 然后在上线后的至少一个完整季度里，每两周汇报一次。如果指标不动，我们的合作就是不成立的，无论 deliverable 清单打了多少勾。
这意味着我们有时候会拒单。如果一个潜在客户说不出上线后他们会用哪个指标来判断这个项目 —— 这本身就是这个项目还没准备好的信号；我们会直接说出来。
2. 造这个东西的工程师，也是接下来至少 12 周运维它的工程师
这在人员调度上是讨厌的。它意味着我们不能把一个工程师完全排进下一个项目，直到上一个项目在真实世界里验证过了。它在 resourcing 板上留下一道显眼的空缺 —— 一个追求周转效率的团队会立刻把人调走，去避开这道空缺。
我们愿意承担这道空缺。另一种做法 —— 把一个刚上线、还烫手的产品丢给一个第一次读代码的人 —— 会制造出这个行业里最常见的那种合作形态：“雇我们来修上一家供应商留下的东西”。我们宁愿少接一些项目，也要让每一个项目真正度过上线后最关键的那段时间。
3. 我们把学到的东西写下来，公开，带日期
只存在于客户和我们之间 Slack 私聊里的运维经验，不叫学习 —— 叫正在过期的上下文。每一次 on-call 复盘、每一次指标变动、每一次产品假设发生变化，都会写进一份文档 —— 文档归客户所有，我们持续追加。上线后 12 周时，这份文档通常就是这个产品在全世界范围内最准确的描述 —— 比它当初上线所依据的那份 PRD 还准确。
这样做的目的不是流程。目的是 —— 当这个产品最终完整交还给客户内部团队的时候，他们接手的是推理过程，不只是代码库。
两个具体发生过的地方
一家博物馆硬件合作方
我们在 2024 年为一家博物馆硬件合作方的下一代智能导览设备做了固件与平台层。这款设备为博物馆场景而设计 —— 在博物馆里，“访客会怎么走”这件事的分布真的很奇怪：人会在一句话讲到一半的时候走开，会停在没有 RF 视距的地方，会以一种让朴素蓝牙 Mesh 瘫掉的方式扎堆。
上线版本的固件通过了上线前的测试规范。它通过的原因是：那份规范是写固件的同一批工程师自己写的。这是一种我们在第三周才察觉到的失败模式 —— 当时博物馆现场的工作人员开始反馈，在那条三大展览交汇的走廊上，有一种安静的设备之间切换失败的规律在反复出现。上线前测试里没有任何一项模拟过三群访客同时聚集、RF 部分重叠这种场景。
因为我们有一位驻场工程师就在运维阶段里，这个规律四个工作日之后变成了一个固件 hotfix。因为我们合同意义上定义了一个上线后指标（从生产遥测里观测到的”静默切换失败率”），这次修复就有一把尺子量自己。因为我们一路把运行假设写下来了，这次 hotfix 能对照最初的推理被审查，而不是对照”大家还记得”。
这里面没有工程英雄主义。有的只是”没有供应商接缝”—— 刚好在那个接缝一旦出现就会让客户对博物馆策展方损失一个季度信任的节点上。而在这个行业里，策展方不轻易把信任再给回来。
堃悟信息 (Kunwu)
堃悟那笔合作里，我们是咨询方，不是工程方。那是一次针对广告法审核平台的战略评审 —— 技术架构、供应商选择、MVP 划界。是那种”交付物是一份文档、大多数公司在文档被签字那天就离开”的项目。
我们以一种较轻的方式留了下来，参与到平台后续 12 周的建设过程里 —— 这段建设由另一家工程方在做。不是来反复质疑；而是作为已经知道为什么某个架构决定被这样做出的评审方。其中两个决定在第六周和第九周承受了压力 —— 工程团队想抄看起来显而易见的近路。因为我们把决定带着理由写下来过，我们有能力用四十五分钟把对话重新锚定，而不是花两周时间把分析重新推一遍。
平台如期上线。更重要的是，它按照被设计的那根架构脊柱上线，而不是它的降级版本。
这对客户和未来的同事各意味着什么
给正在读这篇文章的客户：你从我们这里买到的东西，本质上不仅仅是一个 v1。它是 v1 之后，造出 v1 的那批人还在。定价体现了这一点；合作结构体现了这一点；人员调度约束也体现了这一点。如果你的采购流程把”建造”和”运维”当成两家供应商、两行预算 —— 那我们大概率不是一个合适的选择。不是因为工作做得更差，而是因为报价结构扛不住这道切分。
给正在考虑加入的工程师、设计师、运维人员：这份承诺的代价是个人性的。我们招人的速度比 pipeline 允许的更慢 —— 因为我们不愿意把一个人从一个还烫手的产品上调走，去追下一个。但作为回报，你做的工作不会在上线六周后蒸发掉。你会看到你造的东西到底有没有用。
“留下来”不是品德，是一种纪律。它是让前面三个阶段值得去做的理由。