坤霆@全栈技术研究室

大部分技术Leader在招人时都有个朴素的信念：能力越强越好，人越聪明越好。但在真实的团队管理中，我发现一个反直觉的现象：很多时候，团队出问题不是因为能力不足，而是因为认知跨度太大。

什么是认知跨度？就是团队成员在技术理解、业务认知、工作方式上的差距。这个差距小的时候是良性竞争，大了就是团队撕裂。

一个真实的场景

金融科技行业里有种很常见的情况：你招了一个大厂出来的P7，技术很强，对代码质量要求高，喜欢讨论架构。但你的团队主力是P5，关注的是怎么快速把需求做出来。

前两周还好，P7会主动做code review，提重构建议。一个月后矛盾就出来了：P7觉得"这代码没法维护，得重写"，P5觉得"功能都正常，改它干嘛"。三个月后，P7要么离职，要么就闭嘴了。

这不是谁对谁错的问题。这是认知跨度的问题。

认知跨度的三个维度

在技术团队里，认知跨度体现在三个地方：

技术深度的跨度。有人觉得"能跑就行"，有人觉得"必须优雅"。前者关注的是业务价值，后者关注的是技术品味。放在同一个项目里，一个想快速迭代，一个想精雕细琢，怎么配合？

做了这么多年技术，我发现一个挺有意思的现象：几乎每次技术方案评审，都会有人提出一个"理论上最优"的方案，但最后落地的，往往是那个"看起来不够优雅"的方案。

这不是偶然。背后有一套残酷的逻辑。

那个"完美方案"为什么总是死在会议室里

上周技术评审会，前端团队提出要引入微前端架构，理由很充分：模块解耦、独立部署、技术栈自由、团队自治。PPT做得精美，架构图画得漂亮，甚至连落地路线图都准备好了。

然后架构师问了一句："谁来维护基座？iframe降级方案谁负责？跨应用通信出问题谁排查？"

会议室安静了30秒。

最后的决定是：继续用现有的Monorepo + 模块化方案，虽然不够"先进"，但团队都熟悉，出问题知道怎么修。

这不是个例。我见过太多"技术上正确"的方案，死在各种现实问题上：

- 服务化改造，拆到一半发现团队根本撑不起这么多服务
- TypeScript全面迁移，三个月后发现一半团队还在用any
- GraphQL替代REST，半年后发现后端团队都不会写resolver
- Kubernetes上云，结果运维团队连基本的Pod调试都不会

有个场景在金融科技公司几乎每周都会上演:产品经理说"这个需求很简单,就是加个按钮",工程师听到的是"又要改架构"。

会议室里的氛围瞬间凝固。产品经理觉得技术团队在找借口,工程师觉得业务方根本不懂技术。双方都没说错,但都没说对。

这不是沟通技巧的问题,是认知框架的断层。

信息在组织边界丢失

我观察过一个现象:同一个需求,产品经理在需求评审会上讲五分钟,工程师回去讨论要两小时。

不是工程师理解力差,是信息在跨部门传递时发生了质变。

产品经理说"支持用户自定义理财目标",他脑子里是一个完整的业务场景:用户设定目标金额和期限,系统推荐合适产品,定期提醒达成进度。这个场景在产品原型里是完整的,在用户故事里是清晰的。

但工程师听到的是什么?

前端听到的是:新增表单、字段校验、状态管理、埋点上报。后端听到的是:数据库表设计、接口规范、权限校验、数据迁移。全栈工程师听到的更复杂:前后端联调、缓存策略、异常处理、监控告警。

同样五个字,解析出来的工作量相差十倍。

这就是组织边界的代价。产品经理思考的是"用户价值",工程师思考的是"技术实现"。两者的抽象层级不在同一个维度,信息当然会失真。

Monorepo 最近几年成了前端工程化的显学。Google、Meta、微软都在用，Turborepo、Nx 这些工具层出不穷，到处都在讲 Monorepo 的好处。但我观察下来，大部分团队引入 Monorepo 之后，要么是用成了"巨型仓库"，要么是过度拆分变成了"伪 Monorepo"。

真正的问题不是 Monorepo 本身，而是大家搞错了它的适用场景。

先说结论：Monorepo 不是银弹

很多团队看到 Google 用 Monorepo 管理几十亿行代码，就觉得自己也该用。但这里有个认知偏差：Google 的 Monorepo 是为了解决他们特有的问题——跨团队代码共享和依赖管理。

你的团队有这个问题吗？

大部分团队的实际情况是：
- 前端就 3-5 个人，管理的项目不超过 10 个
- 业务相对独立，跨项目共享的代码不多
- 没有复杂的内部依赖关系
- 团队协作流程还没稳定下来

这种情况下，Monorepo 带来的复杂度远大于收益。

做技术管理这些年,我发现一个有趣的现象:越是成功的技术Leader,越不愿意分享自己踩过的坑。大家都在讲"如何打造高效团队"、"OKR落地实践"、"技术人才培养体系",却很少有人聊那些让人坐立不安的尴尬时刻。

但恰恰是那些尴尬时刻,构成了技术管理的真实底色。

当你意识到自己是瓶颈

2019年,我负责的前端团队刚从5人扩到10人。团队扩张后的第三个月,我突然发现一个问题:所有人都在等我review代码。

不是他们不主动,而是我在无意识中给自己设置了一个隐形职责——"技术质量守门人"。每个PR我都要亲自看一遍,每个技术方案我都要参与讨论,每个难题组员都会第一时间找我。

表面上看这是负责任,实际上是灾难。

团队的吞吐量被我一个人的工作时间卡死了。更糟糕的是,我发现自己在培养"等待型工程师"——遇到问题不是先思考,而是先找Leader确认。这不是我想要的团队文化。

那段时间很煎熬。一方面我知道必须放手,另一方面又担心代码质量下滑。最让人尴尬的是,当我试图"授权"时,发现自己根本不知道该怎么做。

过去几年里,我习惯了"事必躬亲就能保证质量"的工作方式。现在要求我"不插手也能保证质量",完全是另一套技能。

每次看到 Dependabot 或 Renovate 提的 PR，我的第一反应不是"好，及时更新"，而是"又来了，这次会炸在哪"。

这不是危言耸听。见过太多次：一个看似无害的小版本更新，导致生产环境莫名其妙地挂掉；一个"修复安全漏洞"的补丁，带来了更严重的 breaking change；一个"只是升级 devDependencies"的操作，让 CI 流水线跑不起来。

行业里有个有意思的现象：所有人都在说"依赖要及时更新"，但实际操作中，大家都在拖延。不是因为懒，是因为怕。

这种恐惧是有道理的。

语义化版本的美丽谎言

Semantic Versioning（语义化版本）告诉我们：`major.minor.patch`三段式版本号清晰明了，patch 是 bug 修复，minor 是功能新增，major 才是破坏性变更。所以升级 patch 和 minor 是安全的，对吧？

对个屁。

去年金融业务的一次故障，就是因为某个依赖的 minor 版本更新。库的作者认为他只是"优化了内部实现"，所以只升了 minor。但这个优化改变了某些边界情况下的行为，恰好触发了我们业务代码里一个隐式依赖的逻辑。

写在前面

前几天和一个创业公司的 CTO 聊天，他说他们团队 5 个后端开发，已经拆了 12 个微服务。我问他为什么要拆，他说"为了未来的扩展性"。然后我问他现在的 DAU 是多少，他说"几千"。

这让我想起很多年前见过的一个场景：一个刚起步的业务，还在验证商业模式，技术团队已经开始讨论服务网格和分布式追踪了。最后业务没做起来，技术架构倒是挺先进的。

微服务这几年被捧得太高了。很多团队在根本不需要的时候就开始拆服务，结果把自己搞得焦头烂额。今天想聊聊这个话题，不是说微服务不好，而是大部分团队真的不需要它，至少不是现在。

微服务的真实成本

开发成本的指数级增长

很多人以为微服务只是把代码拆开而已。实际上，从单体到微服务，你需要解决的问题是指数级增长的：

服务间通信：HTTP 调用、gRPC、消息队列，你得选一个。然后你会发现，本来一个本地函数调用，现在变成了网络请求。网络不可靠，你得处理超时、重试、熔断。原本简单的代码，现在要考虑各种边界情况。

TypeScript这几年几乎成了前端的"标配"，不用TypeScript好像就落伍了。但我观察到一个现象：很多团队引入TypeScript后，开发效率反而降低了，尤其是启用了严格模式（`strict: true`）的项目。

这不是TypeScript本身的问题，而是大部分团队高估了自己的类型设计能力，低估了类型系统的复杂度。

类型系统的复杂度被严重低估

大部分人以为TypeScript就是"给变量加个类型"，但真正在大型项目中用TypeScript，你会发现类型编程几乎成了一门独立的学科。

看一个真实的例子，金融业务中的表单配置系统：