Staff 工程师的「发明工作」指南
文章摘要
Sujith Jay Nair 长期在平台团队工作，常写平台工程和产品管理相关的文章。这篇 2026 年 9 月 22 日的文章讨论一个平台团队特有的问题：工作从哪里来。
为什么要「发明工作」。 作者开篇说，平台团队是工程主导而非产品主导的：几乎从来没有产品经理递给你路线图，没有可追踪的收入线，也没有会丢失的市场。这意味着除非有工程师把工作发明出来，否则工作就不存在。平台团队持续的挑战，是想办法提升平台给系统用户带来的价值。在平台团队里，staff 工程师的一大块职责就是决定团队下一步该做什么，他把这叫做「发明工作」。好在可以帮助发明工作的信号早已存在，来自四个方向：系统、用户、组织和行业。文章就是一份解读这些信号的指南。
系统发出的信号。
- 由事故驱动的发现。 故障和相应的事后复盘，如果做得好，会清楚地告诉你该修什么、该替换什么。复盘很少直接指向一个要新建的东西，但如果你仔细观察故障如何影响用户，或者在团队修一个长期故障期间用户如何自己想办法让流程运转，偶尔也能发现。很少有团队把跨多次复盘寻找规律当作固定做法。它的主要缺点是：会让团队偏向最响亮、最近发生的故障，而不是最大的机会，而且它是最滞后的指标。
- 成本。 云账单可以弥补你没有收入这颗北极星的缺憾，但别停留在优化数据库查询、削减跨 VPC 流量费用上。如果能看到事业部的损益表，就去看；看团队的供应商合同和云账单明细，或者去问了解成本中心的人。对每个成本中心，弄清把这项职能「外包」对团队有什么好处，以及把它收进团队范围意味着什么；反过来，也要看看范围内哪些东西应该交给供应商、云服务或别的团队。核心教训是：自建还是外购不是一次性决定，随着范围、团队成员、技术和市场变化，可以重新审视。
- 自己的苦差事（toil）。 这是另一种成本，许多人看不见，有时连干这些活的人自己也看不见。每个团队都有苦差事，而它几乎从不被优先处理。陷阱在于：你的苦差事不等于用户的苦差事，解决前者改善的是单位经济，解决后者改善的是用户体验。
用户发出的信号。
- 持续发现。 作者以前写过，被迫使用平台的内部用户「并不最清楚工具的理想状态」，过度依赖用户访谈是平台产品管理的祸根，问人想要什么，他们只会说「更快的马」。但这不是不和用户交流的借口。持续发现就是和用户保持长期对话：每周、每月或每季度和 N 个用户聊，问他们最近一次用到平台的任务是怎么做的、用平台最痛的三个点是什么、如果解决了对他们意味着什么、还有谁有同样的问题。要深挖痛点：几乎每个真实问题都已经有人搞出了变通办法，没有变通办法说明痛得还不够。要对用户提出的解决方案提出质疑，弄清他们为什么想要，那些方案是否受限于现有设计。把痛点记录下来，按提及频率索引。用户访谈应该专注于共同理解问题空间，解决方案设计是另一个场合的事。
- 被「挪用」的用例。 这是作者最喜欢的启发式方法。有些平台有一种意外的特性：用户会拿它去做它从未被设计来做的事。应该花时间弄清楚，用户为什么宁可用你的平台、而不是其他替代品来解决问题。把这些被挪用的用例当作用户替你搭好的原型，判断哪些值得正式吸收。检验标准很简单：你的用户里还有谁有同样的问题？
- 与用户合作做原型。 被挪用的用例是事后发现的，合作做原型则是刻意安排同样的事：团队和用户一起在平台上做一个可能解决他们问题的原型。原型不是承诺会把功能加进平台，只是一次共同探索。吸收与否的检验标准相同。
组织发出的信号。
- OKR。 作者说这一条显而易见，列出来只是为了完整：如果团队已经定了 OKR（或被上面压下来一个），这项工作就已经被发明出来了，恭喜，看下一条。
- 经理重复启发法。 如果你在一周内听到经理（或经理的经理，或更上层）两次提到同一件事，背后很可能有一个没被解决的担忧。这是在一对一会谈里做笔记的好理由，或者去读那些 LLM 生成的纪要。但他认为这是发明工作最弱的方法：层级越高离用户越远，越可能建立在 HiPPO（薪水最高者的意见）之上。
- 迁移残骸。 平台的每次重大变更都需要迁移，任何主导过关键迁移的人都知道，采纳有一条长尾，就像《跨越鸿沟》里那条著名曲线：创新者、早期采用者、早期和晚期大众，最后是落后者。那些拖拖拉拉或永远不迁移的团队是重要信号，告诉你你的方案哪里不完整、为什么还有工作要做。内部平台必须服务比中位用户更广的群体，迁移残骸正好指出了「中位」方案没有照顾到的用户。
行业发出的信号。
- 描述性写作引出规范性写作。 想出点子很难，但这是你的职责：提出改进现有系统的新想法，并以规范性的形式（比如 RFC）提出。作者最喜欢的方法是描述现有系统，给同事、用户或新人写都行：为已经存在的系统写一份设计文档，并与做类似或相邻事情的业界先进系统作比较。描述的过程会暴露那些已经不再合理的决定，这是「以写作为思考」的最佳体现。
- 滞后就是你的套利空间。 了解行业趋势有真正的价值，但有更犀利的读法。作者认为任何一个计算领域都在捆绑和拆分之间长期摇摆：数据仓库把计算和存储捆在一起，数据湖把它们拆开，如今湖仓引擎又在重新捆绑；从单体到微服务的运动，现在正让位于模块化单体。内部平台也在同一方向上摇摆，只是因为想法需要时间扩散而有延迟。这种滞后是好事：你可以同时引入行业趋同背后的理由和证据，包括公开的事故复盘、迁移成功案例、对比基准、其他公司放弃的立场，不必自己花钱去产生证据，还能跳过行业已经抛弃的方向。失败的情况是滞后太久，成了最后跟进的那批团队。
哪个信号，何时使用。 十一个信号太多，不可能同时运行。作者沿两个维度给它们排序：信号白送给你多少论证，以及它是领先还是滞后指标。一端是「自带论证」的信号：事故复盘已经有受众和结论，成本中心已经用美元计价，OKR 跟踪的是已被发明的工作。这些用起来成本低，但都不同程度地滞后。另一端是需要你自己构建论证的信号：滞后套利能给出最强的论证，但立场最弱，因为证据来自公司外部；经理重复启发法零证据，但自带一些分量；持续发现给你用户痛点，但把它们变成规格是你的事。被挪用的用例居中，这正是作者最喜欢它的原因：它是领先信号，论证已经搭好并在生产环境中运行。合作做原型用自己动手的代价换来同样的证据。迁移残骸是晚一次迁移的同类交易：对刚做完的迁移来说它是滞后信号，对下一次迁移来说是领先信号。描述性写作既不给论证也不给紧迫感，但最有可能发现那些已悄然过期的决定。
结语。 作者说这不是一个信号短缺的问题，信号一直都在，上面的清单也并不完整。工程主导的平台团队的失败模式不是待办列表空空如也，而是待办列表由最响亮的信号拼凑而成，通常是事故，有时是越级领导的一句话。发明工作的关键不在于找到一个信号，而在于能说清为什么选这一个而不是另外十个。
HN 评论精华
帖子获得 381 分、93 条评论。评论区的焦点很大程度上落在标题措辞上，此外是平台团队到底该由产品还是工程主导的老争论，也有不少人从亲身经历出发补充。
「发明工作」这个说法本身。 最热的楼由 nmehner 开启：「发明工作」就是「需求工程」，这个词用得很怪。mytydev 建议用文中反复出现的「发现」（discovery），qrush 建议「定义工作」，theanonymousone 建议「主动式工程」。不少人坦言被标题误导：arealaccount 以为这是一篇讲如何优雅摸鱼的文章，Insanity 以为是讲「晋升工程」（找些能让你升职、除此之外毫无用处的东西来做），cush 和 colescodes 都以为是讽刺文，直到发现不是。groestl 认为这背后是哲学分歧：工作是本来就存在、等你去发现，还是你一想到它就开始存在？作者似乎持后一种世界观。gloryjulio 则替标题辩护：需求工程同样适用于高级工程师，他们拿到问题后梳理需求和实现路径；但 staff 工程师得自己去发现范围，这就是「发明」的由来，在大厂职级体系里，staff（L6）找不到团队的工作范围是会被绩效改进甚至解雇的。pradn 和 devmor 也认为这显然是半开玩笑的说法。
tessierashpool 则直接断言作者用了 LLM：第一段有两个被改成连字符的破折号和典型的冗长列表，后面几段的破折号被改成了分号和冒号，关于苦差事那一段「明显是机器生成的」。ahartmetz 附和说他只觉得文章缺乏连贯和方向，看到「At one end sit the signals that arrive pre-argued」这句时就不再怀疑了。
平台团队应当由产品主导。 dabedee 的评论是另一个讨论中心。他认为正是「工程主导、没有市场可失去」这种框架和心态，让平台团队服务不好别人，常常变成一座座发明工作的失调高塔。解决「没有市场」的办法是假装你服务的团队随时可能离开。文章列了那么多信号，偏偏没有这一条。被迫使用并不意味着内部团队没有别的选择、不会注意到；产品主导的意思就是在乎用户。hyperpape 指出文中提到了苦差事和复盘，这些与用户团队是相关的；dabedee 回答说那正是他不明白为什么需要「发明」的地方，他更想读的是如何找出那些团队真正需要什么，以及如何判断答案其实是什么都不用新建。leokennis 提名「假装用户随时会离开」为本月「思路清晰、表达优雅」奖。
围绕这一点，经历分成两派。hibikir 说他在开发人数不到 500 人的中小公司里一次又一次看到，把平台负责人交给技术强但对别人怎么工作毫无兴趣的人，结果就是一个接一个没人想用的项目：他们不爱和用户交流，于是写自己想用、做起来有趣的工具。carlmr 说他在大中小公司都见过内部平台变成「无用折腾的象牙塔」，很多项目被迫用内部平台，最后在要满足外部客户需求时还是去买了外部供应商的方案；WorldMaker 补充说，平台至少要有一个真实客户项目来自用验证，最好遵循重构里的「三次法则」：为一个项目做的「平台」是一次性的，为两个项目做的可能是巧合，为三个项目做才能看出真正的模式。DanielHB 讲了一段亲身经历：公司核心平台团队要求他的小团队接入新的授权系统，那套系统需要三个互相通信的 EKS 集群，主集群挂了全部挂，而且计划是拿他们当小白鼠，他强烈反对。
也有人为工程主导辩护。aleqs 说别以为产品经理不「发明」工作，领域越技术化，产品方产生的废话越多，工程方还得返工、清理或抗争；产品方往往还掌握对内沟通，结果是压制工程方的声音。oldnewthing 自己带一个平台团队，认为平台团队必须同时由工程和产品主导：纯产品导向也会让你偏离用户，他们的产品经理在发明没人要的能力，却忽视用户早已提出的大量需求。他举了一个正在争论的例子：一边是多个客户提出、能减少他们七成以上人工干预、两个月就能上线的韧性功能，一边是产品经理想要、没人提过的 AI 功能，后者占用 6 名工程师，进度落后、复杂度远超预期，年底肯定交付不了。alper 则说，给平台团队配齐完整的产品团队只会产能过剩，而且一般水平的产品经理连这类团队在做什么都搞不懂。viccis 只说了一句：「平台团队几乎从来没有产品经理递给你路线图？那就把我从梦中的假期叫醒吧。」
如何说服别人。 dirtbag__dad 是一位 staff+ 平台工程师，他说增加用户价值的事情其实一目了然，难的是在平台离客户最远的情况下讲出为什么要做任何事的故事。他曾和一位技术能力不强、却把自己放在平台工作最终决策位置上的大厂资深产品经理共事，对方一再否决他反复详细描述的工作：数据质量受损、延迟糟糕透顶。直到他展示了几张核心数据库超负荷、面临更严重事故风险的简单图表，才说服了对方。有趣的是，Gareth321 从产品经理一方回应：他和自己的技术负责人有同样的矛盾，他试过图表、讲故事、Jira、商业论证、SLA、客户访谈，什么都试了，但对方强烈抗拒为自己想做的事做任何解释，理由通常是「太复杂解释不清」和「这代码一团糟」，可他需要为工时负责，还要向更不懂技术的人解释钱花在哪里。boisterousness 毫不客气地说，他列的那一串在工程师看来九成以上是浪费时间的空话，好的产品经理应该自己消化这些，只把有用的部分和技术负责人沟通。
其他观点。 juancn 用的是「接下来什么会要了我们的命」哲学：找出它，想办法避免，循环往复；r3trohack3r 补了一句「先对付离船最近的鳄鱼」。Traubenfuchs 说自己升到类似 staff 的职位后，总监不停催他找新东西做，他压力很大，又不擅长想功能，就专攻省钱：缓存、批处理、调整规格、合并、优化；只要每年为公司节省的钱是自己薪水的两三倍，就不会被安排去做「注定失败」的登月项目，也不会被裁，还能拿到跑赢通胀的加薪，「好在过去浪费钱的罪孽无穷无尽」。skrtskrt 批评作者说完「没有收入线」两段之后就开始讲成本，这是偷懒的思考：成本线一直都在。froh 反驳说，系统工程师通过重构底层数据结构为公司省下 1TB 内存，与收入和市场无关，却实实在在改善了利润。OtherShrezzing 和 merrvk 则更犬儒：很多大公司雇平台工程师是为了经理「建立帝国」、扩充人头以便下一次跳槽，产出主要是给简历注水的忙碌工作。aprilthird2021 对这些误读有些不耐烦：作者不是字面意义上地发明工作，而是通过解读信号找出需要做的事，用户和客户通常不知道也不关心你的系统需要什么，这正是雇工程师的原因。crakhamster01 认为很多评论者本来就对平台团队印象不好，标题里「发明工作」的钩子正好迎合了这种成见，他自己觉得文章写得不错，信号建议也很准。mahboi 则回了一句：大家没看懂，是因为文章写得不好。Gareth321 补刀：考虑到文章的内容，这还挺讽刺的。