坤霆@全栈技术研究室

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

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

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

信息在组织边界丢失

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

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

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

但工程师听到的是什么?

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

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

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

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，你会发现类型编程几乎成了一门独立的学科。

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

最近在和几个技术管理者交流时，发现他们都在规划或已经落地了BFF（Backend for Frontend）架构。问为什么要做BFF，得到的答案惊人地一致："解耦前后端"、"提升开发效率"、"这是最佳实践"。

但当我问："你们团队有多少后端开发？前端开发呢？"，答案通常是"后端6-8人，前端3-4人"。这让我意识到一个问题：大部分团队上BFF，可能不是因为真的需要，而是因为"别人都在用"。

我想聊聊这个话题，不是要否定BFF的价值，而是想说：很多团队高估了BFF的收益，低估了它的成本。

BFF真正解决的问题

先说清楚，BFF不是伪需求。它在特定场景下确实有价值：

场景一：多端适配。你的后端API是为Web设计的，现在要支持移动端、小程序、IoT设备。不同端的数据需求、交互逻辑差异很大，用一套API很难搞定。这时候BFF可以为每个端定制API，后端保持稳定。

场景二：聚合调用。前端一个页面需要调用5-6个后端服务，串行调用太慢，并行调用又要处理复杂的依赖关系。BFF可以在服务端聚合这些调用，减少前端的复杂度和网络开销。

最近看到一个问题："全栈工程师是不是什么都要会？"下面的回答分成了两派，一派说全栈就是要前端后端数据库运维都精通，另一派说全栈是个伪概念，啥都会等于啥都不精。

两边都有道理，但我觉得都错了重点。

做了很多年全栈，从后端写到前端，再到带团队做架构，我的观察是：大部分人误解了全栈工程师的核心价值。全栈不是让你成为技术全才，而是给你一个完整的视角去理解系统、做决策、解决问题。

追求全能是个陷阱，追求全局观才是正道。

全能是个伪命题

先说个真实场景。

在金融业务中，经常会遇到性能问题。前端说页面慢是因为接口慢，后端说接口慢是因为前端请求太多，DBA说数据库压力大是因为查询写得烂，运维说服务器资源不够要扩容。

这时候如果你是个"全能型"全栈，你会怎么做？去优化前端的渲染逻辑、重写后端的查询语句、调整数据库索引、然后去研究服务器配置？

听起来很厉害，但实际上这是在用战术上的勤奋掩盖战略上的懒惰。

真正的问题可能是：这个需求本身就不合理，或者整个架构设计有问题。

前几天团队来了个新人，看到我们的CR流程后很兴奋："你们的Code Review好规范啊，每个PR都要两个Approver才能合并。"我笑了笑没说话。

因为我知道，这套看起来"规范"的流程，实际上每天都在发生这样的事情：开发者提交一个几百行的PR，半天没人review；着急上线就去钉钉群里@几个人；被@的人打开看一眼，觉得代码没大问题就点了Approve；测试环境跑了一遍没报错，代码就合并了。

整个过程看起来很严谨，实际上谁也不知道这段代码到底干了什么。

大多数CR都是形式主义

我见过太多团队把Code Review当成一种"仪式感"——必须要有这个环节，但没人在乎它到底有没有效果。

最常见的场景是：PR提交后，reviewer们象征性地打开看一眼，扫过去没发现明显的bug或者格式问题，就点了Approve。至于这段代码的设计是否合理、是否有更好的实现方式、是否会给系统带来潜在风险，没人去深究。

为什么会这样？因为review代码比写代码累。

最近看到前端组有同学在讨论要不要把某个逻辑抽成公共工具函数。这个场景太熟悉了，几乎每个团队都在纠结类似的问题：到底什么该复用，什么不该复用？

我的观察是，大部分关于代码复用的讨论都建立在错误的前提上。不管是组件库、工具函数库，还是Copy-Paste，都不是真正的答案。真正的问题在于，我们对"复用"这个概念的理解就是错的。

组件库的幻觉

前端圈最大的迷思之一是：我们需要一个强大的组件库。

这个想法听起来很美好。把所有常用的UI组件抽象出来，封装成统一的库，然后各业务线直接调用。听起来既能保证一致性,又能提高效率。

但现实总是很打脸。

我见过太多这样的场景：某个业务需要一个带搜索功能的下拉选择器，组件库里有个Select组件。产品经理说要加个"最近搜索"功能，组件库维护者说这是业务定制需求，不该放在公共组件里。业务开发者只好在外面包一层。然后产品经理又说搜索结果要支持分组显示，再包一层。最后这个Select组件被包了三层，代码比从头写一个还要复杂。

问题出在哪？出在我们把"复用"等同于"抽象"。

最近看到团队在讨论页面首屏加载优化，有人提出要把某个 10KB 的图片压缩到 8KB，说能省 20% 的体积。我突然意识到，前端性能优化可能是我见过的最容易被过度执行、也最容易做错方向的技术工作。

不是说性能优化不重要，而是大部分人根本不知道自己在优化什么，也不知道这个优化到底值不值得。

性能优化的第一个迷思：技术指标不等于用户体验

打开任何一篇性能优化的文章，你都能看到一堆指标：LCP、FCP、TTI、FID、CLS。这些指标确实有价值，但问题是，你真的理解这些指标背后的含义吗？

我见过一个团队花了两周时间把 FCP 从 1.2 秒优化到 0.8 秒，但实际上首屏还是白屏，因为真正有意义的内容要等接口返回才能显示。用户看到的"快"，和监控平台上的数字，完全是两回事。

LCP 优化≠用户感知快。LCP 是"最大内容绘制"，但如果你的最大内容是一张无关紧要的背景图，优化它有什么意义？用户真正关心的是"我能不能看到商品价格"、"我能不能点击购买按钮"，而不是你的背景图加载了多快。

微前端这几年很火,但我见过太多团队在盲目引入后陷入困境。最常见的情况是:团队只有3-5个前端开发,维护着2-3个业务模块,却花了两个月时间接入qiankun,结果代码复杂度翻倍,问题却没解决几个。

这不是qiankun的问题,而是大部分团队根本不需要微前端。

微前端解决的是组织问题,不是技术问题

很多人把微前端当成技术架构来看,这是第一个误区。

微前端的核心价值在于让不同团队能够独立开发、独立部署自己的模块,而不是解决技术上的模块化或性能问题。如果你的团队只有一个前端组,那么引入微前端就像一个人住别墅——空间是有了,但打扫卫生的时间也翻倍了。

我在金融业务中见过一个典型案例:公司有理财、基金、保险三条业务线,分属三个独立团队,各团队技术栈不同(React、Vue、Angular都有),发布节奏也不一致。这种情况下,微前端是合理的选择,因为组织边界清晰,技术隔离是刚需。

但大部分团队的情况是:前端是一个Team,后端可能分了几个服务,然后看到微服务很流行,就觉得前端也该"微"一下。这就是刻舟求剑了。

微前端带来的复杂度被严重低估

引入微前端后,你要面对的问题比想象中多得多:

前端圈对状态管理的执念，可能是过去十年最大的集体焦虑。从Flux到Redux，从MobX到Recoil，从Context API到Zustand，每隔一两年就会冒出一个"更简洁"的方案，然后大家又开始新一轮的重构和争论。

但我越来越怀疑一件事：我们在用前端的方式解决本不该存在的前端问题。

状态管理焦虑的根源

大部分前端开发者第一次接触Redux的时候，都会有类似的困惑：为什么一个简单的计数器需要写这么多代码？action、reducer、dispatch、connect，整整一套ceremony，就为了让组件拿到一个数字。

当时流行的解释是："这是为了可维护性。" 等项目大了你就懂了。

确实，等项目大了，我懂了。但我懂的不是Redux的好处，而是我们把太多不该放在前端的状态放在了前端。

举个真实场景：用户的投资组合数据。

前两天团队讨论新业务的技术方案,后端同学提议用 GraphQL,理由是"前端可以自己控制数据结构,不用频繁改接口"。我问了一句:"你们后端有多少人?"答:"3个人"。我说:"那别折腾了,RESTful 就够了"。

这不是第一次遇到这种情况。这些年做全栈,从后端写 API 到前端调 API 再到 BFF 层设计 API,见过太多技术选型上的执念。最常见的两个误区:一是觉得 RESTful 就是正统,必须符合所有规范;二是觉得 GraphQL 能解决前后端协作的所有问题。

事实上,这两个都不是银弹。

RESTful 的形式主义陷阱

大部分开发者第一次接触 API 设计,学的都是 RESTful 规范。GET 查询、POST 创建、PUT 更新、DELETE 删除,资源路径用名词不用动词,状态码要严格遵循 HTTP 标准。这些原则没错,但问题在于,很多人把它当成了教条。

前后端分离已经是前端圈的"政治正确"了。但最近几年，我观察到一个反常识的现象：不少团队在推进前后端分离几年后，又开始招聘全栈工程师，甚至把部分项目重新合并。

这不是技术倒退，而是对"分离成本"的重新认识。

前后端分离的三大隐形成本

大部分团队谈前后端分离时，强调的是"职责清晰"、"技术栈解耦"、"并行开发"。但很少有人提它的代价。

1. 沟通成本：从「对话」变成「会议」

以前一个功能，全栈工程师自己从前端写到数据库，遇到问题自己调试，半天搞定。

前后端分离后？先写需求文档，前后端对齐接口，联调发现参数不对，再开个会讨论，改完继续联调。原本半天的事，拉长成三天。

我不是说会议不重要，而是很多"会议"本质上是在弥补"认知鸿沟"——前端不知道后端为什么这么设计，后端不知道前端要什么。

金融业务尤其明显。理财产品的持仓逻辑，涉及到实时资产、历史收益、预期收益三种数据，前端需要合并展示。如果后端不理解前端的渲染逻辑，可能会返回三个接口；前端不理解后端的数据模型，可能会要求合并成一个接口但无法满足缓存策略。

这不是技术问题，是认知问题。

BFF（Backend For Frontend）这个概念被讨论了很多年，大部分文章都在讲它的好处：给前端更多控制权、减少沟通成本、提升迭代效率。但我想说点不一样的：BFF可能是过去十年最被滥用的架构模式，它给很多团队带来的不是效率提升，而是隐性灾难。

这个判断可能有争议，但基于我多年全栈实践的观察，大部分公司的BFF实践都走偏了。问题不在于BFF本身，而在于一个看似合理但实则危险的假设：前端团队应该拥有和维护BFF代码。

谁在真正维护BFF

先说个常见场景。你们公司引入了BFF架构，用Node.js写，部署在前端团队的代码仓库。最开始确实很爽，需要什么接口自己写，数据格式自己定，不用等后端排期。

三个月后，问题来了：
- 后端换了新的认证方式，BFF层要同步升级
- 用户反馈接口偶尔超时，排查发现是BFF内存泄漏
- 运营要做数据统计，需要在BFF加审计日志
- 监控告警BFF的某个依赖包有安全漏洞
- 后端要做灰度发布，BFF要配合调整负载均衡策略

很多团队在引入 Node.js 做 BFF（Backend for Frontend）层时，都会陷入一个误区：把它当成简单的接口转发器。写几个路由，调用后端 API，拼装数据，返回给前端，就算完成任务了。

这种理解不能说错，但实在太浅。

我见过不少团队的 BFF 层，最后都沦为"接口透传中间件"——前端要什么数据，就透传什么接口；后端改了接口，前端也跟着改。这样的 BFF 层除了增加一层延迟和维护成本，没有创造任何价值。

今天想聊聊三个常见的认知误区，以及 BFF 层真正应该做什么。

误区一：BFF 只是为了"聚合接口"

很多人认为 BFF 层的核心价值是"把多个后端接口聚合成一个"。比如一个页面需要调用用户信息、订单列表、推荐数据三个接口，前端调三次太慢，所以在 BFF 层写个聚合接口，一次性返回所有数据。

这个思路听起来很合理，但问题在于：聚合只是手段，不是目的。

真正的目的是什么？是为前端定制适合它的数据结构和粒度。

最近半年，AI编程工具层出不穷。从GitHub Copilot开始，到Cursor、Claude Code、OpenClaw、Hermes Agent，每个都说自己是"下一代编程方式"。

用了几个之后发现，这些工具看起来都是"AI帮你写代码"，实际上解决的问题完全不同。

这不是功能对比，是设计理念的分野。

三种不同的定位

先说结论：OpenClaw、Hermes Agent、Claude Code 虽然都叫"AI编程工具"，但定位差异巨大。

OpenClaw：开源、可定制、工程师导向。

核心理念是"把AI当工具"。你可以自己部署、自己调教、自己定义workflow。它不是一个产品，更像是一个框架。

适合人群：愿意折腾、对隐私敏感、有特殊需求的团队。

Hermes Agent：自动化、任务导向、减少人工干预。

核心理念是"把AI当助手"。你下达一个任务，它自动拆解、执行、验证。你不需要一步步指导，它会自己判断下一步做什么。

适合人群：希望提高效率、不想深入细节、任务明确的场景。

每次做技术选型，团队都会认真调研：列出五六个候选方案，做技术对比表，分析优缺点，开会讨论半天。最后呢？React、TypeScript、MySQL、Redis，还是那几个。

新人会问："为什么不试试XX框架？它的性能更好啊。"老人会说："稳妥起见，还是用主流的吧。"

技术选型最大的谎言是：我们在做技术决策。实际上，大部分时候我们在做风险决策。

技术选型的三个阶段

做了很多年技术，观察到一个有意思的现象：工程师对技术选型的态度，会随着工作年限发生变化。

刚入行时，看到新技术就想用。看到有人在用Vue 3，立刻想在项目里试试；看到Rust很火，马上想重写服务；看到某个数据库号称性能是MySQL的10倍，恨不得立刻迁移。

这个阶段的特点是：只看优点，不看成本。

工作几年后，开始变得谨慎。新技术出来不会马上跟，会等社区成熟、生态完善、踩坑的人多了再考虑。这时候的决策标准是：技术是否成熟、团队是否掌握、是否有成功案例。

这个阶段的特点是：看优点也看缺点，但忽略了隐性成本。

在技术圈混久了，发现一个有趣的现象：那些把团队管得很好的技术Leader，往往在子女教育上也有一套。反过来，那些在团队管理上焦头烂额的，当了父母后也容易陷入同样的困境。

这不是巧合。管理团队和教育子女，底层逻辑是一样的：都是在试图影响另一个独立个体的行为。

只不过，在团队里你可以炒人，在家里不行。

控制的幻觉

见过很多技术管理者，刚升职时会犯一个错误：觉得"我是Leader了，我说了算"。于是开始制定各种规范、流程、制度，试图让团队按照自己的意图运转。

三个月后发现不对劲：表面上大家都遵守规则，实际上阳奉阴违。能偷懒就偷懒，能应付就应付，遇到问题第一反应是"这不在我职责范围内"。

为什么？因为把人当成了机器，以为输入指令就能得到预期输出。

人不是代码，不会严格按照你的逻辑执行。

子女教育也一样。很多父母觉得"我是家长，孩子就该听我的"。于是制定各种规矩：几点睡觉、看多久电视、周末上什么兴趣班。孩子小的时候可能还管用，到了青春期就会发现，你说什么他都反着来。

本质上都是"控制的幻觉"——以为通过规则和权威就能让对方按你的意愿行事。