云图回忆录

我进入云图的第一天，正好是 1024 程序员节。

那天，我先和一个朋友组队参加比赛，拿了冠军，接着去办云图的入职。现在回头看，这是一个挺好的开头：一场比赛刚结束，一份新工作又开始了。当时脑子里没有这么多感想，只觉得一切都是 so fresh，什么都是新的。

后来，我在云图实习了两年，正式工作了两年。现在，我正准备离开这里，去 Seed 的一个 Infra 团队，做一些可能 out of my scope 的事情。趁记忆还算清楚，也恰好又走到一个新旧交替的时刻，我想把这四年记录下来。

实习

刚进云图时，我做的是大数据研发相关的工作。最开始的一段时间都在学习 Spark、Hive、HDFS、MapReduce，熟悉公司的数据开发组件，也补一些后端开发的知识。

接到的第一个 work，是迁移一个很老的服务。

原来的服务不断轮询数据，再循环执行任务。我们要把它迁成触发式，入口需要改，后面压着的大量业务逻辑也要跟着梳理。此前我几乎没有碰过这么复杂的业务和项目。那时候也没有今天这么成熟的 AI 和 coding 工具，只能沿着调用链一层层往下翻，把每个分支在什么条件下进入、最后影响了什么，都靠自己理清楚。

所幸最后做完了，效果也不错。这个任务很普通，甚至可以说只是一个简单的 landing job，但它给了我一种很朴素的信心：老服务再乱，只要肯花时间、肯把逻辑理清，它还是能动的。

我也是从这个项目开始，慢慢熟悉公司内部的大数据组件，知道一件事怎样才算真正落了地。那时我发现，互联网行业很重要的一个特质，是细致加靠谱。只要足够细心，做事足够靠谱，很多困难都能一点点拆掉。它未必需要一个人多聪明，但需要你把事情接住。

接下来做的是商品竞争分析。商家需要知道，自己的商品到底在和谁竞争。我们从人群的流入流出，以及竞争人群的重合程度出发，计算商品之间的竞争密度。

这是我第一次在真实需求里感受到数据的价值。商家以为的竞品，和数据里呈现出来的竞品，经常并不一致。他可能认为竞品是 A、B、C，但真正看过他的商品、最后却买了别的商品的那群人，流向的可能是他原本完全没有放进边界里的选项。

我也是在那时理解了“数据不会说谎”这句话。人的判断总会带着自己所处位置的主观视角，数据则给了我们一个更接近真实行为的入口。这也让我理解了字节为什么崇尚数据驱动：它不是让数字替人作判断，而是让判断先接受真实行为的校验。

后来我也逐渐知道，数据虽然不会说谎，口径却会影响人们看见什么。数据驱动从来不只是把一个数算出来，还包括怎样把这个数放回产品，让人能继续用它作判断。

这个项目里有一件事，我后来一直记得。同一个指标，用我们认为更科学的口径算出来是 3500 万，但平台其他地方沿用的口径算出来是 3350 万。从局部看，3500 万也许更合理；可一旦换上去，客户就会在同一个平台看到两套不同的数据。

客户不会研究两套算法分别做了什么，只会问：到底哪个数是真的？何况很多口径本来就很难说有绝对的对错。对客户而言，绝对值未必最有意义。他更需要一把稳定的尺子，知道自己在行业、大盘和竞品之间处于什么水位。只要大家一直用同一把尺子，比较就仍然成立。

平台已经用了 3350 万，继续沿用它，反而是更合适的选择。改成 3500 万会带来一次无法解释的突变，我们也不可能轻易回溯所有历史数据。这个时候，一致性比局部准确性更要紧。客户一旦 confused，后面的解释会变得非常昂贵。

以前我会把注意力都放在“这个数准不准”上。做完这个需求后，我开始承认，现实世界远比一道算法题混沌。判断一个数是否正确，还得多走一步：把它放回产品会发生什么？别的报表能不能继续用？客户能不能沿着同一道口径作决策？这些同样属于“正确”的范畴。

实习时还做过一次 OLAP 引擎迁移。原来的链路先在 Hive 层完成聚合，再把结果导入 ClickHouse，存下来的已经是聚合值。产品临时想换口径，或者用户希望有另一种计算方式，研发就很难改，因为最底层的明细已经不在了。

后来我们设计了一套使用 Bitmap 的 OLAP 方案，把聚合推迟到查询时再做。这样出数仍然很快，口径也灵活了很多。乍看之下，这是一个 win-win 的方案，大家都很满意。

但真正放到线上，会发现事情没有这么简单。查询时聚合很吃 CPU 和内存，存储也贵，还需要足够好的 SSD。明细数据进来以后，链路中的任何一个环节卡住，整段计算都有可能出问题，系统并不鲁棒。

产品和运营看到的是又快又灵活，这很正常，他们负责用户体验。技术侧则必须把后面的资源、成本和稳定性一起算进去。收益和钱要放在一起算，要算 ROI。一个功能看起来漂亮，并不代表它就是最合适的选择。

我做事的习惯也在那时发生了变化。刚来的时候，只想着怎么把功能做好；后来每做一个方案，都会再问一句：这样选真的是对的吗？有没有成本更低、稳定性更好、ROI 更高的方式？

转正以后

实习快结束时，我做了不少技术分享，也会把自己的 idea 写成文档，分享给大家。别人因此更容易知道我做过什么，我也确实得到了一些同学的认可。

到了转正答辩，大家对我的期待比较高，希望我能拿到 SSP，所以还帮我申请了加面。但第一场答辩并不顺利。Mentor 后来告诉我，很多业务问题被我绕着弯规避掉了，大家并没有那么满意。

这件事让我很难受，也让我意识到，自己可能正站在一个“无知的顶峰”上。你觉得自己已经做得很好，别人看到的却并不是这样。反馈刺耳，不代表它没有用。至少在那次答辩里，我需要承认，有些问题我没有真正回答，有些表达习惯也必须改掉。

后来我争取到了那轮加面，表现得还不错，最后也拿到了一个很好的 offer。那段时间，有不少人陪我演练，帮我调整说话的习惯。转正从一开始的不顺利走到后面的顺利，我一直很感谢这些帮助。

秋招时，我也拿到了阿里、腾讯、Kimi 等公司的 offer，最后还是选择留在字节。核心原因是，我喜欢这里的人才观：和优秀的人一起，做有挑战的事情。

身边的人足够好，自己一个人扛不住的事，就有人能一起扛。事情也得足够难。太简单的事情里，很少会发生真正有意思的东西。

我很喜欢一句话：人生要么 suffering，要么 boring。比起 boring，我更愿意选 suffering。我的职业生涯才刚开始，不想每天只做已经会的事情。那对我来说，可能过于无聊了。

正式入职

正式入职以后，我开始接触 AI、AI Agent，以及更多当时还很前沿的新东西。

最早做过一个实体切词项目。它第一次让我清楚地看见，所谓业务规则可以混沌到什么程度。

比如，“老虎”是一种动物，而动物不允许切词，这是一条很明确的规则。但如果有个达人就叫“老虎”，这个词又应该被切出来。站在技术视角看，这种 case 很 confusing，甚至不够“漂亮”；可业务本身就是会有这些不讲道理的例外，会有各种黑词、特殊词和不断变化的边界。

技术不能因为规则不漂亮就拒绝业务。我们能做的，是想办法让这些例外以更容易扩展、清理和维护的方式存在。

Brooks 在《人月神话》里用“焦油坑”形容软件工程，我越来越觉得这个比喻准确。我们能做的，很多时候就是继续在焦油坑里挣扎。程序员大概也是一个需要愿意进入焦油坑的职业。如果完全不喜欢处理这种混沌，做这一行会很痛苦。

再往后做 Multi-Agent system，遇到的问题其实很像。业务需要的多 Agent 系统通常非常定制，因为业务有很强的主张，也有许多特化的 workflow。与此同时，它又必须足够稳定。完全开放的 Agent loop 可以有很强的探索性，却很难保证每一次都按业务需要的方式交付。

我们要做的，是在灵活性还存在的情况下，把业务主张放进去。探索性强的环节，可以让 Agent 自己走；需要稳定交付的环节，仍然得把控制逻辑写清楚。确定和不确定的边界怎么切，要由业务决定。通用 Agent 可以在 playground 里跑得很好，但进入生产以后，一定要回答稳定性的问题。

后来，我们也学会了用更好的 Harness 去管理这种不确定性。但在项目初期，如果目标是尽快交付一个结果稳定的版本，workflow 往往无法避免。

这和当年做 OLAP 很像。一个东西足够灵活时，人们很容易看见它能做什么；代价要等它真正进入业务以后才会显现。拿到效果之后，还得再问：成本是什么，谁来接住，谁来管控？

那段时间，周末我还会自己搭 Agent 平台，试各种大模型服务，算是一种充电。我把这些尝试写成文档。后来组里开始做 Agent 相关项目时，Leader 看到了那份文档，知道我做过类似的事情，就把一个原本未必会由我负责的项目交给了我。

那一次，我真正感觉到了 connect the dots 的重要性。乔布斯在 2005 年的斯坦福演讲里说，人不可能站在现在就把未来的点连起来，只能回头看，才知道它们怎样成为了一条线。做一件事的时候，你不知道它有没有用，也不知道什么时候能用上。但一些当时没有答案的积累，会在未来某个机会里重新出现。

当然，拿到机会只说明你走到了项目门口，能不能做成，还得进项目再看。项目能否落地，无外乎业务、技术和软素质几个方面。业务和技术先不展开，软素质反而是我后来感受很深的一部分。

我们的 AI Agent 项目牵涉的人很多。每个人都从自己的职能出发看问题，关心的点完全不同。你眼里无关痛痒的事，在别人那里可能就是主要矛盾。于是大家要花很多时间把各自的想法和约束讲出来，再找一个都能接受的方案。有时谁也说服不了谁，只能反复掰扯。

项目变大以后，最棘手的经常不是技术本身，而是人。准确一点说，是人带来的沟通线、上下文和责任边界。

一个人能处理的沟通线是有限的，能同时握住的 context 也是有限的。作为研发负责同学，我需要把事情拆开。每一个会被单独关心的问题，都尽量落到一个组件里，再把这个组件要解决什么、边界在哪里讲清楚。组件有明确的负责人，围绕它的讨论和责任才有人接，复杂度也才算真的拆了出去。

与此同时，问问题和回答问题也是很重要的素质。问别人问题时，要先给出足够的 context。大家不是凭位置拍决策，而是拿着同一份上下文讨论。一个问题只有在拥有足够上下文的情况下，才真正成为一个可以讨论的议题。否则，你只是把困惑抛给了另一个人。

关于 AI 时代下的素质

AI 执行事情的能力已经非常强。至少在我现在的工作里，几乎 100% 的代码都是 AI 写的。在这种情况下，研发真正重要的事情是什么？和产品、运营相比，我们还应该承担什么？

我绕了一圈，答案还是两个字：靠谱。

产品会把可能性推得很远，运营会从客户视角判断事情，研发则必须把系统究竟能承载什么说清楚，再细致、可靠地把它落下来。我们需要理解底层原理，需要有设计的品味，也需要在各种看起来都能工作的方案里作选择。这些恰恰是今天还很难完全交给 AI 的部分。

当然，也许几个月以后，边界又会变化。但 whatever，Taste is all you need。对研发尤其如此。

靠谱再往前走一步，是把问题定义清楚。

“我要做一个好的系统”，不是一个被良好定义的问题，因为没有人知道“好”具体意味着什么。可如果问题变成“我们要做一个能够处理长上下文的 Agent”，再把验收标准、上下文长度、任务持续时间和失败条件说清楚，工程问题才真正出现。

这时我们可以继续往下找：究竟有哪些因素影响长上下文？是用 compaction 把上下文压下来，让 Agent 能继续执行；还是用 Multi-Agent 架构拆分上下文，让不同 Agent 各自承担一部分？问题一旦被定义清楚，就会出现许多可以验证的工程路径。

所以，重要的事情从来不只是解决问题。很多时候，定义问题更重要。要反复问自己：这个问题真的被良好定义了吗？我们看到的是信号还是噪声？拿到反馈以后，应该迭代答案，还是应该重新定义问题？

但定义问题也需要一种克制：我们可能比自己想象得更聪明，也比自己想象得更笨。聪明在于，人确实能在陌生系统里找到路径；笨在于，我们经常把时代和环境推着我们向前的速度，误认成自己的能力。

我之前听张小珺和姚顺宇的访谈，记住了一个很好的说法：我们不一定是冲浪的人，本质上可能只是那道浪。我们只是冲得足够快，不代表所有结果都是因为自己做得足够好。把这件事想清楚，会让人对自己的判断多一点克制。

我也希望自己能有强观点。没有观点，就很难在复杂问题里作选择。但有强观点的同时，也要保持足够小的 ego。你可以相信自己的观点是对的，也要允许证据和别人的反驳改变它。能提出主张，也能被说服，这两件事并不冲突。

再往前，我甚至越来越不希望只用“研发”定义自己。我更喜欢 Builder 这个词。

Builder 意味着真的为一件事从头到尾负责：用户怎么使用？我们想传达什么？什么样的产品能把这个理念交付出去？为了做到它，研发上需要作出哪些努力？AI 正在抹平许多过去清晰的分工边界。我们不必先划定“这是不是研发该做的”，可以回到更本质的问题：我们到底要构建什么，解决用户的什么需求？仅此而已，不必先把事情想得那么复杂。

从这个角度看，我很感激 AI。它逼着我们重新回到研发的本质：从整体视角定义问题，然后把问题解决掉。

AI 时代真正值得看的，是一个人的本质能力。他是否对未知保持好奇，愿不愿意探索，也愿不愿意为探索承担责任和风险；他是否有自驱力，能不能持续学习。至于今天懂不懂 Agent Harness、Spark，或者其他某一项技术，当然有用，但都不会一直是最重要的东西。

离开云图

回看这四年，我很感谢那些愿意相信我的 Mentor 和 Leader。说得自信一点，我也感谢他们慧眼识珠：看到我有过一些积累，就愿意多给一次机会，让我去承接他们的期待。

我在这里学到了很多。一个研发应该有的基本素养，一些前沿的技术品味，还有把事情做成的方法，这些都是很宝贵的财富。

这四年也让我更相信字节这个组织。至少在我的经历里，只要做出了结果，过程又能被看见，通常就会得到相应的回报。大家愿意根据事实判断一个人。你把一件事接住了，下一次就会有更多机会。我的努力在这里被看见过，也被认可过。

现在，我准备去 Seed。过去学过的 Spark、大数据和 OLAP 并没有因此失效。最近学习 Infra 相关的东西时，我发现所谓 PD 分离、AE 分离，底下仍然是分布式计算的那些问题。技术名词在变，看待系统的研发品味没有变。一法通万法。

技术变化得太快，没有哪一项具体技能可以一直管用。但这四年教会我的，是持续学习本身，也是在陌生问题面前继续往下拆的能力。

四年前的 1024，我拿着一个比赛冠军进了云图，觉得一切都很新鲜。最近一次 1024，我又拿了一个 AI Agent 比赛的冠军，准备离开云图。

新的系统也会很复杂，新的项目少不了和人磨合。那里大概还有一些超出我当前能力范围、更有挑战的事情，等着我去解决。但我还是愿意探索未知。

云图很好，只是我还想把自己的能力拼图补得更完整。比起继续只看业务的问题，我更想知道底层是怎么运转的。

又一次 so fresh。感激过去，珍惜现在。