本文大多是我随口用 Wispr AI 口述完成的。

决定做远程公司时，我给自己定了一条基本原则：把原本要花在办公室租金上的钱省下来，用于线下见面，每季度至少一到三次。我们刚刚在圣路易斯结束了第一次全员（也就是3个人）的线下集中办公。虽然只有短短两天半，但感觉相当高效，我想把其中值得复用的做法记录下来，也推荐给其他人。

让每一小时都有任务

我做的第一件事，就是在白板上把团建期间的每一个小时都划分出来，列出我们想在期间完成的所有事项（本质上就是时间块规划，只不过是以团队为单位）。我们也确保每个人都能提出自己希望在团建中讨论的内容，让大家结束时都觉得有所收获。

这么做的一个经典问题是，低估误差会不断累积。一个原定一小时的讨论，很可能会拖到三小时，这完全正常。缓解的办法是在每天结束时预留一些弹性时间，用来消化超时的讨论（我们标记为问号）。因为公司还处在非常早期的阶段，我们并没有对接下来要讲的每一个环节做会前准备。在更大规模的团建中，我见过有人会提前一两天做准备，确保每个议题都有充分的背景铺垫。

财务复盘

我们几个人加起来，前后在四五家搞过团建的远程公司待过，但在团建期间做全面财务复盘的却很少见。我猜这多少是因为大家对公开所有财务数据（包括每个人的工资）比较保守，再加上当客户和 SKU 很多时，做账本身就很复杂。对我们来说这都不是问题，因为目前我们的薪资是完全透明的，资金来源和客户/收入来源也都非常简单。

这个会的基本目标，是让公司里的每个人结束时都清楚：钱在哪里、从哪里来、到哪里去，以及未来可能在哪里赚到更多。这能给人，尤其是员工，一种关于现金跑道和公司基本生存能力的安全感。

对我们而言，这个环节只花了15分钟，因为情况实在太简单，我随口就能讲清楚。

客户复盘

我们对服务对象的理解越清晰，产品和工程的优先级就越明确。我承认这方面我们仍在摸索，也不太确定能给出什么建议，只能说我坚信，以客户为中心、甚至对客户保持执念，才是做大公司的正确路径——至少能让公司保持诚实，而不是以技术、研究或所谓“氛围”为中心。

架构梳理

把整个代码库丢给 ChatGPT，让它生成一个 Mermaid 图，用方框和箭头展示各个主要模块及其关联。然后放到 Excalidraw 上按需调整、配色，让整体大致说得通。接着带着全公司一起过一遍。

背后的基本原则是：每个人都有权对下一步该做什么发表意见，但我们必须对“当下已有的东西”拥有共同的基本事实。

有人质疑过这个环节为什么重要。理论上，在一家更大的公司里，CEO 完全可以把技术团队当成黑盒，不再关心实现细节。抛开团队规模不谈，我仍然认为，让非工程背景的人理解架构是有意义的，这样他们才能理解已有的技术押注，不会提出离谱的功能需求。如果可能，还能主动发现那些可以产品化为功能的系统设计。

当然，作为技术创始人，我也会借这个机会夹带一些私货，表达我想推动的想法，这就顺势引出了下一个议题……

原则讨论会

线下团建的好处之一，就是能有意跳出日常，去“经营业务”而不是“在业务中忙碌”。这个概念来自 Richard Gerber 的《E-Myth Revisited》一书，我其实没读过，但听太多人聊过，感觉就像已经读过一样。所以这是一个专门讨论“我们如何工作、未来想如何持续工作”的会。

作为第一次创业的创始人，我觉得这个会非常提气，它是打造我理想中公司的最高杠杆——可以公开表达我最坚信的原则，并以此接受大家的监督，去培养能够复利增长的成功习惯。换句话说，我可以直接把我信奉的工作文化“说出来让它成真”，大家要么提出异议，要么就基本认同并执行。

这次原则讨论会的主要灵感，大概来自亚马逊领导力原则和 Ray Dalio 的《原则》一书。Ray 的首要原则是“痛苦+反思=进步”。在亚马逊，有14条由 Jeff Bezos 总结的领导力原则，代表了各种鲜明的立场。我认为原则贵在精简——每一个字都应该有分量，这样才有约束力。原则太多，就记不住，也太容易为不遵守找借口。我们最后定了5条，可能还多了一两条，毕竟比公司人数还多。最难的当然是对那些合理的补充说不。

一个核心的、尚未定论的原则之争

目前，在 AI 方面我最坚信的一条原则是“产品引领流程，流程引领平台”。换句话说，我们会从第一性原理出发，思考对客户而言最好的产品是什么，并不惜一切代价做出最好的产品——无论是软件与人工的结合。然后我们会把其中的人工部分系统化为流程，并尽可能地，最终把这些流程表达、编码、泛化为软件。

这与我见过的一些把平台放在首位的创业公司截然相反。比如，先做一个无所不能的开源产品或云产品，然后再去寻找客户和使用场景。

我的总体感觉是，AI 领域最成功的领军者都打造了一个封装了神奇或前沿体验的产品，人们其实并不太在乎能否直接调用底层的 API，他们只关心最终结果。

如果未来你再推出支撑这一体验的开源产品或 API 平台，用户就会因为产品的品牌效应而愿意采用你的平台，就像亚马逊后来推出 Amazon Web Services 时，Amazon.com 为其做了背书一样。当然，这条规则也有例外。一方面，像 Character AI 这样以产品为先的公司，即便产品领先，也未必能胜出，也未必能成功将产品或平台变现。另一方面，也有一些没有强观点产品引领的平台，依然取得了相对的成功——比如 Together AI、Braintrust 和 Fireworks。

我确实担心，把产品放在首位而非客户放在首位，会让我们有借口变得以产品为中心，而不是以客户为中心。这也是我认为公司当前这条原则的一个缺陷。

一条更简单的原则

我提出的一条更简单、虽有争议但最终被接受的原则是：每天都要发布代码。这是一条行为层面的原则，而非理论或商业战略层面的，但我喜欢它带来的推进感。

背后的激励故事是 Nat Friedman 接手 GitHub CEO 时的做法。大多数新 CEO 上任后会花3到6个月与高管团队进行倾听之旅，再采取行动。而 Nat 却说：“我们要在接下来的100天里发布100个成果，并在这个过程中发现障碍”——通过实干来了解公司的运作方式。

显然，在一家小公司里，这话没什么争议，但我认为，正是这种贴近代码、也就贴近产品的投入，让我们能够快速前进。对创业公司而言，创业就意味着快速行动、迅速响应新技术和客户需求。

这条原则也直接体现在我们开头提到的时间块规划中。我们在团建的每一天都留出了写代码的时间，回应了那种担心——担心一做这种偏务虚的工作，实际业务就会停摆。

“巴士系数”交接

同样，这个会可能在小公司里最有用。目标是由最了解情况的人带着其他人走一遍整个系统的运行，包括获取权限、管理员账号以及熟悉系统管理。这样一来，即便有人休假，任何人都能接手继续工作。即使某个人暂时联系不上，另一个人也能把系统重新拉起来，哪怕多花点时间。

我建议开一个 Zoom，共享屏幕并录制，这样最后就能得到一份完整的流程录像，以备后用。市面上有些 AI 产品可以根据这类录像直接生成操作手册，但我还没试过，所以暂时无法推荐具体哪一款。

头脑风暴

在日常工作中，大家会抛出很多关于该做什么、能做什么的想法——既有核心产品层面的，也有产品扩展或其他想尝试的实验。这个会给大家提供了集中头脑风暴、碰撞创意的空间，但遗憾的是，从发散到收敛的切换非常困难。

我建议单独安排一个用于优先级排序的会，我们就是在团建最后做了收敛。

优先级排序

归根结底，排序的任务是创始人/CEO/产品经理的职责，所以它不完全是一场民主投票。把所有想做的事都摆到白板上，承认我们永远没有足够的时间全部完成，因此必须做出艰难取舍，这本身就很有价值。

我发现许多优先级评估体系，包括 Linear 和 JIRA 式的打分，都没有考虑到优先级会随时间变化。无论是普通的打分系统，还是艾森豪威尔矩阵式的评估，都没有纳入通过小而简单的尝试来获取信息的实验价值和“战争迷雾”。我提议采用一个双维度打分制，基于想法的“易实现程度”和“潜力”各打1到10分。然后我们会尝试为这两个维度的分数区间划定边界（也就是明确在“易实现”维度上1分和10分分别代表什么，在“潜力”维度上1分和10分又分别代表什么）。

之后我们会用相乘或相加的方式算出总分，对想推进的想法进行排序。我们还不太习惯“易实现”这个维度……

大家在这个维度上最纠结，因为我们把“E”理解成了“工作量”，但又希望分数越高代表越好，同时也清楚我们不能只挑低垂的果实。我们想要的是一个组合：既有预期回报不错、唾手可得的，也有更难但长期回报更高的事。

团建社交

大多数人都对尴尬的团建活动感到厌倦。说实话，除了聚在一起吃饭、去了一趟 Blueberry Hill，我们几乎没安排什么社交活动——如果你在圣路易斯，我强烈推荐去那里看看。我觉得这样也挺好，不过我也非常乐于听取更适合我们这种小团队的社交活动建议。