初创公司的目标导向研究：独立学科的艺术

Haoli Yin 2026-04-18 13.0 KB 33K 384 𝕏 文章列表

本文探讨了初创公司中研究工作的独特性。作者指出，创业研究并非学术研究的“降级版”，而是具有不同规则的独立实践。文章批评了将研究置于工程与学术两极之间的妥协观点，提出了“双时间尺度”框架：长期愿景应像科研投资一样资源配置，而短期冲刺则应作为工程问题解决。这种方法能帮助团队区分噪音与信号，避免研究人员的职业倦怠。

初创公司研究方法团队管理研发管理 AGI 目标导向职业发展

# Goal-Oriented Research is Its Own Discipline **作者**: Haoli Yin **日期**: 2026-04-17T16:56:09.000Z **来源**: [https://x.com/HaoliYin/status/2045184552155664490](https://x.com/HaoliYin/status/2045184552155664490) --- ![Image](/doc/722/image/img_e108d4b926fb.jpg) The most useful thing I’ve learned in two years as a Member of Technical Staff at a research startup is that startup research is not a watered-down version of academic research. It’s a different practice with different rules, and the people who treat it as a compromise of the academic version tend to either burn out or ship nothing. ## What the spectrum gets wrong When people talk about research versus engineering at a startup, they tend to imagine a spectrum with two poles. Engineering is one pole. There’s a feature that needs to be implemented. There are different ways to implement it, but the end goal is nearly 100% achievable and deterministic. You scope, you build, you ship. Academic research is the other pole. There are open problems that can be approached through many methods. You rank and prioritize candidate solutions given your hypotheses, and there’s a real chance that none of what you try will work. Great research questions that are well defined shouldn’t have solutions that work the first time around. Otherwise you aren’t being ambitious enough. Research requires iteration. Exploration is a forcing function in this environment that gives you more priors to make a decision on the next experiment to try. The standard story is that startup research lives somewhere between these two poles. You take an academic problem and give it a deadline. You take an engineering practice and loosen the success criteria. What you get is a compromise that pleases neither the researcher nor the engineer but ships occasionally. I don’t think this is what successful startup research actually looks like. The compromise framing assumes you’re trading off on the same axis. You aren’t. ## The actual structure When you’re doing goal-oriented research at a startup, you have to pick a point along the pareto that trades off exploration (research) versus exploitation (engineering). This trade-off doesn’t get made once at the project level. It gets made continuously, at every level, against a target that keeps moving. The sparse final reward of binary success criteria in research cannot be equated as is to the milestone structure of engineering. Achieving an x% gain on an eval is not the same kind of milestone as shipping a customer feature request in the UI. The eval gain might require a methodological pivot and weeks of staring at model outputs. The feature request requires a sprint plan and someone who knows React. Treating these as interchangeable items on the same backlog is how startups end up either shipping nothing or doing fake research that’s actually engineering with a fancier label. ## The framing trick So how do you plan research that has to ship? The framing I’ve landed on is this. The high level goal, the final deliverable, should be framed as the long-term research vision. Not because the goal is open-ended in the academic sense, but because the path to it is uncertain. The path might require several pivots. The success criterion is real but distant. The next immediate problem to tackle, the thing your team is actually doing this sprint, should be framed as an engineering problem. Here is the well-defined problem with supporting evidence and diagnosis so far. Here’s the specific time span we’re going to dedicate to throwing all possible human labor and compute and ranked candidate solutions at it. Once we run into the next problem, then we have collected more information about what failed or maybe worked, and we do the next round of planning. The current step is treated as a feature request along the way of the long-term research vision. Schematically: ![Image](/doc/722/image/img_cbc542e81446.jpg) This sounds like a semantic trick. I don’t think it is. The reframing changes how you actually run the work. It changes how you allocate. The long-term research vision gets resourced like a research bet: you commit budget against an uncertain payoff. The current sprint gets resourced like an engineering project: you commit specific people for a specific time, and you measure them against whether the well-defined sub-problem got solved. It also changes how you communicate. To customers and executives, the long-term vision is the story. To the team executing this week, the story is the time-boxed engineering problem. Trying to communicate the vision as a sprint goal makes the team feel like they’re failing constantly. Trying to communicate the sprint goal as the vision makes the customer think you have no ambition. The two registers are not interchangeable, and confusing them is a common failure mode. Most importantly, it changes how you decide when to pivot. If the sprint engineering problem fails, that’s information. You re-plan the next sprint with the new information. The long-term vision doesn’t change just because one sprint failed. But if multiple sprints in a row fail in similar ways, that’s a signal that the vision itself needs adjustment. The two timescales let you separate noise from signal. ## What this requires This framing only works if the leadership tier holds both timescales simultaneously. If your CTO only cares about the engineering sprint, the research vision evaporates and you become a feature factory. If your chief scientist only cares about the research vision, the engineering sprints lose discipline and nothing ships. The two have to be in active conversation, and the people doing the work have to translate between the two registers fluently. This is, I suspect, why the most senior people at research startups tend to be those who can hold both framings at once. Not because they’re equally good at every individual skill in the engineering-research simplex, but because they can make decisions that respect both timescales without collapsing one into the other. The rest of us are still learning how to do this. If you’re running a research startup, the sooner you stop planning for one timescale and start planning for two, the sooner you stop burning out the researchers on your team. ## 相关链接 - [Haoli Yin](https://x.com/HaoliYin) - [@HaoliYin](https://x.com/HaoliYin) - [8.5K](https://x.com/HaoliYin/status/2045184552155664490/analytics) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [12:56 AM · Apr 18, 2026](https://x.com/HaoliYin/status/2045184552155664490) - [8,525 Views](https://x.com/HaoliYin/status/2045184552155664490/analytics) --- *导出时间: 2026/4/18 18:46:28* --- ## 中文翻译 # 目标导向的研究本身就是一门独立学科 **作者**: Haoli Yin **日期**: 2026-04-17T16:56:09.000Z **来源**: [https://x.com/HaoliYin/status/2045184552155664490](https://x.com/HaoliYin/status/2045184552155664490) --- ![Image](/doc/722/image/img_e108d4b926fb.jpg) 在一家研究型初创公司担任技术成员的两年里，我学到的最有用的一课是：初创公司的研究并不是学术研究的稀释版本。它是一种有着不同规则的不同的实践，而那些把它当作学术版本妥协产物的人，往往会精疲力竭，或者什么也交付不出来。 ## 光谱模型的误区当人们在初创公司谈论研究与工程时，往往想象一条有两个极端的光谱。工程是一个极端。有一个需要实现的功能。实现方式有多种，但最终目标几乎是 100% 可实现且确定的。你规划范围，你构建，你交付。学术研究是另一个极端。有一些开放性问题，可以通过多种方法去探索。你根据假设对候选方案进行排序和优先级划分，而且你所尝试的东西很可能全都不奏效。定义良好的优秀研究问题，本就不应该第一次尝试就能解决。否则说明你不够有雄心。研究需要迭代。在这种环境中，探索是一种强制机制，它为你提供更多先验信息，帮助你决定下一个要尝试的实验。标准的说法是，初创公司的研究介于这两个极端之间。你拿一个学术问题，给它一个截止日期。你拿一种工程实践，放宽成功的标准。你得到的是一种妥协，既不能让研究者满意，也不能让工程师满意，只是偶尔能交付点东西。我不认为成功的初创公司研究实际上是这样的。这种妥协式的框架假设你在同一个轴上进行权衡。其实不是。 ## 实际的结构当你在初创公司做目标导向的研究时，你必须在帕累托前沿上选择一个点，来权衡探索（研究）与利用（工程）。这种权衡不是在项目层面一次性做出的。它是持续进行的，在每一个层面上，针对一个不断移动的目标。研究中二元成功标准所带来的稀疏的最终奖励，不能简单地等同于工程中的里程碑结构。在某个评测上取得 x% 的提升，与在用户界面上交付一个客户功能请求，不是同一种里程碑。评测的提升可能需要方法论上的转向，以及数周盯着模型输出的时间。而功能请求只需要一个冲刺计划和一个懂 React 的人。把这些当作同一待办清单上可互换的条目，正是初创公司最终要么什么也交付不了、要么做着实际上是工程却贴着更花哨标签的“假研究”的原因。 ## 框架技巧那么，你如何规划一个必须交付的研究？我最终采用的框架是这样的。高层目标，也就是最终交付物，应该被框定为长期研究愿景。不是因为目标在学术意义上是开放性的，而是因为通往它的路径是不确定的。这条路径可能需要多次转向。成功标准是真实的，但很遥远。而下一个要解决的紧迫问题，也就是你的团队在这个冲刺中实际在做的事情，应该被框定为工程问题。这是定义明确的问题，配上到目前为止的支持性证据和诊断。这是我们要投入所有可能的人力、算力以及经过排序的候选方案的具体时间跨度。一旦我们遇到下一个问题，我们就收集了更多关于什么失败了、或者什么可能有效的信息，然后进行下一轮规划。当前的步骤被视为通往长期研究愿景道路上的一个功能请求。示意如下： ![Image](/doc/722/image/img_cbc542e81446.jpg) 这听起来像一个语义上的花招。我不这么认为。这种重新框定改变的是你实际推进工作的方式。它改变了你如何分配资源。长期研究愿景像一项研究赌注那样获得资源：你针对一个不确定的回报投入预算。当前冲刺像一项工程项目那样获得资源：你投入特定的人在特定的时间内，并用定义明确的子问题是否得到解决来衡量他们。它还改变了你如何沟通。对客户和高管来说，长期愿景就是故事。对本周执行任务的团队来说，故事是那个有时间限制的工程问题。试图把愿景当作冲刺目标来沟通，会让团队觉得自己在不断失败。试图把冲刺目标当作愿景来沟通，会让客户觉得你没有雄心。这两种表达方式不可互换，混淆它们是一种常见的失败模式。最重要的是，它改变了你如何决定何时转向。如果冲刺的工程问题失败了，那就是信息。你用新信息重新规划下一个冲刺。长期愿景不会因为一个冲刺失败就改变。但如果连续多个冲刺以相似的方式失败，那就是愿景本身需要调整的信号。这两个时间尺度让你能够把噪声与信号区分开来。 ## 这需要什么这种框架只有在领导层同时掌控这两个时间尺度时才能奏效。如果你的 CTO 只关心工程冲刺，研究愿景就会蒸发，你会变成一个功能工厂。如果你的首席科学家只关心研究愿景，工程冲刺就会失去纪律，什么也交付不出来。两者必须保持积极的对话，而实际做事的人必须能在两种表达方式之间流利地转换。我怀疑，这就是为什么研究型创业公司里最高层的人往往是那些能同时持有这两种视角的人。不是因为他们在工程-研究复合体中的每一项技能上都同样出色，而是因为他们能做出尊重两种时间尺度的决策，而不把其中一种坍缩为另一种。我们其他人还在学习如何做到这一点。如果你在经营一家研究型创业公司，越早停止只按一种时间尺度做规划、开始按两种时间尺度做规划，就越早能避免耗竭你团队里的研究人员。 ## 相关链接 - [Haoli Yin](https://x.com/HaoliYin) - [@HaoliYin](https://x.com/HaoliYin) - [8.5K](https://x.com/HaoliYin/status/2045184552155664490/analytics) - [升级到 Premium](https://x.com/i/premium_sign_up) - [2026年4月18日上午12:56](https://x.com/HaoliYin/status/2045184552155664490) - [8,525 次浏览](https://x.com/HaoliYin/status/2045184552155664490/analytics) --- *导出时间: 2026/4/18 18:46:28*

相关文档