你有没有过这种感觉——走进一个房间，抬头就看到一个黑色的小圆球对着你。

家里的智能摄像头、公司的安防系统、小区门口的人脸识别，它们无处不在。不管你怎么说服自己"又没做什么亏心事"，那个镜头始终让你不太舒服。

我也一样。所以当我上周在 GitHub 上看到一个叫 RuView 的项目时，愣了好一阵。

这个项目做的事情很简单也很颠覆：用普通 WiFi 信号来感知你的存在、呼吸频率、心率，甚至能做姿态估计和跌倒检测。不需要摄像头，不需要穿戴任何设备，一颗 9 美元的 ESP32 芯片就够了。

WiFi 怎么"看"人

先别急着觉得这是科幻。

WiFi 信号本质上是一种射频电磁波。它在房间里传播时，会被人体吸收、反射和散射。你站在 WiFi 路由器和接收器之间，信号就会产生可测量的变化。通过分析这些变化——技术上叫 CSI（信道状态信息）——可以推断出空间里正在发生什么。

这个方向学术界已经研究了十几年。2015 年 MIT 的 RF-Capture 就展示过用 WiFi 信号追踪人体姿态；后来的 DensePose、MultiFormer 不断刷新精度。WiFi 感知在学术圈不算新鲜事。

最近几个月，一个趋势在我身边越来越明显：团队里用 Cursor、Copilot、Claude Code 的人越来越多，但大家聊的不再是"AI 生成的代码有多好"，而是"review AI 代码有多累"。

一个同事上周跟我吐槽：以前 review 同事的代码，至少能理解他的思路，知道为什么这么写。现在 review AI 生成的代码，逻辑上没毛病，但总觉得哪里不对——命名风格不统一，错误处理过度防御，有些地方用了团队从没用过的设计模式，还有些地方莫名其妙地绕了一圈。

他说了一句让我印象很深的话："我感觉自己不是在 review 代码，是在面试一个永远不累的实习生。"

这句话点破了一个很多人还没意识到的事情：AI 编码工具正在把工程师的核心工作从"写代码"变成"审代码"，而大部分团队还没有为这个转变做好准备。

代码审查量在暴增，但审查能力没跟上

先说一个最直观的数据。Cursor 官方说他们的用户已经有超过 50% 的代码是 AI 生成的。我自己团队的感受也差不多——一个中等复杂度的需求，以前可能写两天，现在用 AI 辅助，大半天就能出初稿。

但"出初稿"和"能上线"之间，隔着一道巨大的鸿沟。

一个真实场景

某个周一早上，安全团队收到告警：一个客服账号在周末两天内导出了5000条客户记录。排查下来，这个客服在9:00正常登录系统，角色权限允许查看客户信息。到10:00，他已经批量导出了大量数据；10:15，这些文件被转发到了他的个人邮箱。

安全团队的结论是："用户具有相应权限。"

这句话才是问题所在。客服确实有查看客户记录的权限，但他的正常工作模式是一天处理20个工单，每次查看一两条记录。两天导出5000条数据，完全不在正常行为范围内。这个偏差，本应在操作发生的那一刻就被系统捕捉到，而不是等到事后审计。

登录时的授权为什么不够用

大部分系统的授权模型是这样的：用户登录时验证身份，根据角色分配权限，之后在会话期间的所有操作，都默认信任那次登录的授权结果。

这个模型在过去是够用的。系统部署在内网，用户在公司电脑上操作，数据访问模式相对固定。但在云环境下，这套逻辑开始松动。

原因很直接：登录时的授权只解决了"能不能做"的问题，没有回答"该不该做"。

上个月，我们默默地把三个微前端子应用合并回了两个。没有发公告，没有写技术复盘，就是安安静静地把代码挪了回去，删掉了两个仓库，关掉了四条CI流水线。

如果有人在半年前问我"微前端到底好不好"，我大概率会给他列一堆优点：独立部署、技术栈无关、团队自治。但现在我的回答变了：看你的团队到底有没有拆的必要。

这个判断听起来像废话，但我见过太多团队在这件事上栽跟头，包括我自己。

拆的时候有多爽，合的时候就有多痛

故事的开始总是相似的。一个大型前端项目，十几个开发者在同一个仓库里撞来撞去，merge冲突是家常便饭，发版节奏互相牵制。有人提了微前端，方案评审会上大家眼睛都亮了——每个团队自己的子应用、自己的发布节奏、自己的技术栈，互不干扰，多美好。

我们也是这么想的。2024年初，基于qiankun把主应用拆成了五个子应用，按业务域划分。前半年确实爽：团队A改了代码不用等团队B review，团队C想用新版本的React自己升，团队D甚至单独搞了一套构建流程。

问题是从第二年开始集中爆发的。

最近有个趋势越来越明显：前端工程师看着 Copilot、Cursor 生成的 UI 代码，开始焦虑自己是不是要被替代了。

我觉得这个焦虑方向搞错了。真正值得关注的事情，不是 AI 写的代码比你好，而是 AI 可能根本不需要写代码了。

谷歌刚发布的 A2UI v0.9 就是这个方向上的一步。A2UI 全称 Agent-to-UI，是一套与框架无关的标准，让 AI 智能体声明 UI 意图，由 Web、移动端、桌面端原生渲染。关键词是"声明意图"——AI 不需要生成 HTML、CSS 或组件代码，它只需要说"我需要一个什么界面"，平台自己搞定渲染。

这件事值得认真聊聊。

AI 生成代码的真正问题，不是代码质量

现在 AI 写前端代码的方式，本质上是"生成一堆代码，人来兜底"。Copilot 也好，Cursor 也好，甚至那些号称能生成完整页面的工具，都在解决同一个问题：怎么让生成的代码能跑起来。

但跑起来只是最低标准。在生产环境里，一段前端代码要真正"能用"，得跟已有系统严丝合缝地集成：用团队的设计系统、符合品牌规范、支持无障碍访问、不超标性能预算、跟现有状态管理兼容、能扛住国际化。

上周看到一个案例，震得我好一阵没缓过来。

一家三个人的小公司，AWS 月费常年维持在十几美元的水平。某天早上，创始人打开邮箱，发现一封来自 AWS 的账单提醒——单日费用 1.4 万美元。不是月度，是单日。

排查的结果更让人窒息：一个 EC2 实例上的静态密钥不知道什么时候泄露了，攻击者拿着这个密钥大量调用 Bedrock 的 Claude 模型，跑了一整夜的推理任务。从安全角度看，这甚至不算什么高级攻击，就是一个最基础的凭证扫描 + 资源滥用。但从财务角度看，一家月支出十几美元的公司，在一夜之间欠下了一笔可能需要半年才能消化的债务。

这个案例之所以让我印象深刻，是因为它揭示了一个在 AI Agent 时代正在加速放大的系统性风险：算力消耗的速度，已经远远超过了传统风控系统的反应速度。

传统账单风控的三道防线，全部失灵

大多数公司的云成本风控，本质上就三道防线：

第一道：预算告警。 设置一个月度预算阈值，超过 80% 发邮件提醒。问题是，AI 算力的消耗速度是指数级的。一个大模型推理任务可能在几分钟内就烧掉几百美元，而告警系统的检测周期通常是小时级甚至天级的。等告警邮件送达，预算早就被打穿了。

最近帮一个 Node.js 中间层排查 OOM。一个聚合接口，把三四个下游接口的数据拼一下吐给前端，单次请求的数据量也就两三 MB,看着毫无压力。但 Grafana 上常驻内存随 QPS 线性爬升，GC 触发得越来越频繁,终于在晚高峰把进程撑爆了。

翻代码，逻辑大致是这样：

```js
const responses = await Promise.all(
endpoints.map(url => fetch(url).then(r => r.json()))
)
return res.json(merge(responses))
```

看起来人畜无害。`fetch` 拿到的是流，`.json()` 一次性消费它，`merge` 拼好再 `res.json()` 序列化出去。整个链路里数据至少出现了三份：原始响应体、解析后的对象、合并后的对象。再加上序列化时的字符串缓冲，单请求峰值轻松到原始数据的四五倍。这还没算 V8 把这些短命对象塞进新生代、触发 Scavenge 的开销。

上周四晚上十点半，我收到一条告警：生产环境的理财持仓页白屏率从0.1%飙升到8%。排查了两小时，最后发现是一个间接依赖发布了"patch"更新，把一个工具函数的返回值从数组改成了迭代器。没有破坏性变更声明，没有 major 版本升级，就是一个小小的 1.2.3 到 1.2.4。

这种事在 Node.js 生态里不算新鲜。每个在前端或 BFF 层待过几年的工程师，大概率都经历过类似的"幽灵故障"——代码没动，依赖没升，线上突然就挂了。问题出在哪？出在我们把 semver 当成了契约，但它充其量只是一份君子协定。

semver 的承诺本身就是模糊的

semver 的规则看起来很简单：major 变更代表不兼容的 API 修改，minor 是向后兼容的功能新增，patch 是向后兼容的问题修复。三段式版本号，清晰明了。

在技术领域深耕近二十年，我先后跨越了通信、软件、互联网等多个行业，并在金融科技领域潜心笃行近十年。一路上，我经历了从后端到前端的技能迁移，也完成了从普通工程师到研发管理者的角色跃迁。我曾作为初创成员，从零开始搭建起一支高效的团队；也曾与伙伴们并肩作战，见证了核心业务突破万亿规模的高光时刻。

然而，当技术管理走到深水区，我逐渐感受到了那面无形的玻璃天花板——单纯的技术视角在面对复杂的商业战略、跨部门协同以及宏观市场变化时，常常显得力不从心。

为了突破认知瓶颈，重塑个人品牌，并构建更宽广的资源网络，我选择在职业生涯的黄金期主动求变。2026年，我顺利拿到了上海交通大学安泰MBA综合管理方向的拟录取通知。

这段备考之路，既是一次严苛的自我测试，也是一场关于"取舍"的修行。以下是我的一些实战经验，希望能为正在筹备考研的学弟学妹们提供一些落地、有价值的参考。

一、择校：谋定后动，选择最契合的土壤

对于在职备考的人来说，精力的分配是极其奢侈的，因此择校的精准度决定了备考的性价比。我选择交大安泰MBA，主要基于三个维度的考量：

上周和一个刚升 Tech Lead 的朋友吃饭，他半开玩笑说了句："我以前觉得最焦虑的是线上故障，现在发现最焦虑的是打开 Slack 不知道该回哪条消息。"

他不是在抱怨工作量。他困惑的是一个更根本的问题——他不确定自己现在到底该干什么。

这位朋友技术能力没得说，组里最难的问题都是他啃下来的。升职之后，他给自己定的策略很简单：还是干最难的活，顺便把管理的事也带着做了。三个月下来，最难的技术活他还在干，管理的事全是"顺带"——顺带开个会，顺带审批个需求，顺带和产品对个方案。团队产出反而不如他一个人扛活的时候。

这个故事不新鲜。我见过太多优秀的工程师在走上管理岗之后经历类似的挣扎。不是能力问题，是角色切换的认知滞后——你以为只是多了一些职责，其实是在换一个职业。

升的是 Title，丢的是手感

工程师的身份建立在什么上面？解决问题的能力。一个 bug 搞定，一个功能交付，一个性能瓶颈突破——每一个都是明确的、可感知的成就。这种正反馈循环是工程师职业早期的核心驱动力。

金融系统出bug和出资损，是两个完全不同的量级。功能写错了，改过来就是；页面丑了，迭代一轮就行；但钱算错了，那是客诉、是赔付、是监管约谈，严重的时候直接停业整改。

我观察到一个很普遍的反应模式：出了资损，先加测试用例；又出一次，加人肉对账；再出一次，加发版审批。每一步都在做加法，每一步都离根本原因更远。因为大部分人把资损当成了一种"严重的bug"，用防bug的思路来防资损。这个认知偏差才是资损反复出现的根源。

资损不是bug的严重版

普通bug和资损的核心区别在于：bug是你功能做错了，资损是你的功能没做错，但钱错了。

一个理财产品页面，把年化收益率3.5%展示成3.8%，这是bug。但用户基于3.8%做了购买决策，实际到账按3.5%结算，用户体验上的落差就是资损——即使从功能角度看，展示模块和计算模块各自都"按逻辑运行"。

更典型的场景：用户申购一笔理财，网络超时，前端重试了一次，后端处理了两笔。这两笔处理的每一笔单独看都没"错"——接口接收请求、参数校验通过、数据库写入成功。但因为缺少幂等约束，结果就是资损。

"Vibe Coding"这个词火了有一阵子了。Andrej Karpathy说他写代码时更像是给AI指个方向，然后让AI去实现，自己更像是在"vibing"——感受代码的走向，而不是一行行敲出来。这说法一出，无数开发者深有共鸣。毕竟谁不想当那个只管提需求、不用写实现的人呢？

这体验确实爽。你告诉AI"帮我写一个用户认证模块"，唰唰唰生成了一个看起来像模像样的实现。你甚至不用读完每一行代码，直接点运行，测试通过，感觉自己效率起飞。

但我观察到一个现象：Vibe Coding在Demo里无所不能，在生产环境里处处掣肘。那些靠AI快速拼出来的代码，一旦进入有历史包袱的真实业务系统，就开始不断露馅。而且问题往往不是代码本身有Bug，是这些代码跟现有系统格格不入。

这不是AI不够聪明。这是Vibe Coding这个工作方式本身的前提就不成立。

你以为在写代码，其实在丢上下文

Vibe Coding的核心体验是什么？你只需要表达意图，代码自动出来。这个体验让人上瘾，因为它跳过了编程中最痛苦的部分——把模糊的想法翻译成精确的逻辑。

但有一个被忽略的前提：你跳过的那些部分，恰恰是你建立代码上下文的过程。

上周清理日历的时候顺手做了个统计——我所在的技术团队，10个人，一周62个会议。人均每周6.2个，平均每天1.2个。如果按每个会议40分钟算，将近四小时。还没算上会前准备和会后消化，还没算上那些"5分钟碰一下"的临时通话。

这不是个别现象。我跟同行聊过，金融科技领域尤其严重——合规对齐要开会，风险评审要开会，跨团队排期要开会。一个需求的开发周期里，真正写代码的时间可能还不到一半。

很多团队的第一反应是"减会"——砍掉每日站会，缩短周会，设立无会议日。然后呢？信息断了，对齐塌了，出问题的概率反而上升。砍完的会议像野草一样换个形式长回来。

我后来想明白了这件事：会议不是问题，会议是症状。就像发烧不是病，是身体在对抗感染。你把体温压下去，不等于治好了。

每个砍不掉的会，都在替系统还债

技术团队里的会议，大致可以分几类。每一类背后都藏着不同的问题。你不可能一刀切地减掉它们，因为砍掉会议后露出来的那个洞，可能比会议本身更危险。

同步会：你的模块边界画错了

两个子系统需要"定期同步"，这是最常见的一种会。前端和后端每周对齐，A团队和B团队双周同步。听起来很合理，但仔细想想——如果两个模块之间需要定期人工同步，说明什么？

上周组里一个产品上线前的合规评审会上，合规专员盯着一段前端代码问了一个问题："这个收益率计算逻辑，用户在购买前看到的结果和购买后持仓页显示的结果，走的是不是同一条计算链路？"

在场的两个前端工程师面面相觑。答案是"不是"。购买前用的是推荐接口的预计算数据，持仓页用的是资产接口的实时结算数据。两条链路，两套精度处理，两组四舍五入规则。在普通业务里这根本不算事——数据来源不同，展示逻辑不同，非常自然。但在金融业务里，这意味着用户可能看到购买前年化3.52%，购买后变成3.51%。

0.01%的偏差，万亿规模下就是上亿的资金差异预期。合规专员当场拍了桌子，上线延期两周。

这个场景在互联网公司几乎不会发生。但在金融科技团队，它是日常。

金融业务的代码有两套读者

大部分工程师写代码时心里只有一个读者：运行时环境。代码能不能跑，跑得快不快，内存占不占得住——所有的优化方向都指向机器。

金融业务的代码不一样。它有两套读者：机器和审计。而且讽刺的是，审计这个读者往往比机器更难伺候。机器只要逻辑正确就行，审计要的是"逻辑正确且可追溯且可解释且可复现"。多出来的这三个"且"，才是金融科技工程真正的成本。

DRY——Don't Repeat Yourself。这四个字母可能是软件工程里被引用最多、被误解最深的原则。

每个程序员入行第一天就被告知：重复代码是邪恶的，看到重复就要提取，看到提取就要抽象，看到抽象就要泛化。于是我们疯狂地消灭重复——公共函数、工具类、基础库、共享模块......代码库越来越"干净"，重复率越来越低，CI里没有任何duplicate code的警告。

然后某一天，一个业务需求来了——需要改动某个"公共"逻辑。你打开那个被47个地方引用的utils函数，改了一行，跑了一下测试——绿了。上线，结果三个业务线同时报警。你突然发现，那三个业务线依赖的是同一个函数的三种不同行为，被那个"公共"函数强制统一了。

你消灭了重复代码，但你制造了耦合。而耦合，是比重复贵十倍的技术债。

重复代码不是问题，问题是不知道为什么重复

所有关于DRY的讨论，都默认了一个前提：重复等于坏。但这个前提本身就是幻觉。

重复代码至少有三种完全不同的面目。

第一种是意外重复——两个开发者不知道对方写了同样的功能，造了两个轮子。这种重复才是真正需要消灭的，因为它意味着信息浪费和潜在的不一致。

打开任何一个前端项目的代码，搜索 `catch`，你大概率会看到这样的画面：

```javascript
try {
await fetchData();
} catch (e) {
console.error(e);
message.error('操作失败，请稍后重试');
}
```

后端也好不到哪去：

```javascript
try {
await processOrder(orderId);
} catch (err) {
logger.error('订单处理失败', { orderId, error: err.message });
throw new BusinessException('系统异常，请重试');
}
```

这两段代码有一个共同的特质——它们让你觉得错误被"处理"了。日志打了，提示也弹了，异常也抛了，一切看起来都很体面。

但你仔细想想：用户看到"操作失败，请稍后重试"之后能做什么？重试？然后呢——再失败一次？运维看到一条"订单处理失败"的日志，能定位到什么？是库存扣减超时，还是支付回调丢失，还是风控拦截？

前端的现状有点荒诞：我们嘴上说自己在写 UI，实际上大部分时间在跟数据较劲。Redux、Zustand、React Query、SWR、Dva、Pinia——每出一个新方案，大家就觉得"这次终于对了"。但如果你把所有这些方案放在一起，去掉它们的外壳看本质，会发现一个尴尬的事实：它们解决的问题，数据库几十年前就解决了，而且解决得更好。

我们不是在做状态管理，我们是在重新发明数据库。只是发明得很差。

一个 Redux Store 就是一个简化版数据库

Redux 可能是最明显的例子。你写一个 Redux store 的时候，本质上在做什么？

定义一个全局的数据结构——这叫 Schema。写 reducer 处理 action——这叫事务（Transaction），action 本身就是 WAL 日志。写 selector 查询数据——这叫查询引擎。写 middleware 拦截 action——这叫触发器（Trigger）。用 normalize 归一化数据——这不就是数据库范式吗？

前后端分离之后，我们发明了一个安慰自己的概念——"接口契约"。Swagger 文档一摆，TypeScript 类型一生成，团队觉得天上地下都對齐了：字段名对齐了，类型对齐了，必填选填对齐了。然后上线第一天就出了 bug——status 为 3 的情况前端压根没处理，amount 的单位后端返回的是分前端当成了元，createTime 在后端是 UTC 前端按本地时间解析了。

没错，类型是对上了。但类型对上和意思对上之间，隔的不是一行代码，是一个认知深渊。

接口文档给了我们一种虚假的安全感

我做过很多次前后端协作的接口评审，也主持过不少次。每次的流程都差不多：后端同事打开 Swagger 或 YApi，一个字段一个字段地过，前端同事点头说"收到"。大家都很认真，评审记录也写了，看起来协作很顺畅。

但评审过程有个微妙的问题——我们在确认的是"形状"，不是"语义"。

什么叫形状？`{ orderId: string, status: number, amount: number }` 这就是形状。字段名有了，类型有了，看起来很完整。但这句话里藏了多少没说清楚的东西？

做金融业务的前端，最常听到的抱怨就是"合规又来了"。每次需求评审，合规团队提出的数据隔离、操作留痕、访问控制要求，都像是在给工程师戴枷锁。我刚转金融业务那几年也是这么想的——好好的架构被合规要求弄得支离破碎，什么都要审计，什么都要脱敏，什么都要分权。

但做了几年之后，我发现一个反直觉的现象：那些被合规逼出来的设计，反而比"自由发挥"的架构更经得起时间考验。而那些早期没有合规约束、随意生长的系统，后来几乎没有一个不重构的。

这个观察让我重新理解了约束和设计的关系。

自由是设计的天敌

我见过两类系统的演化路径，差别很大。

第一类是金融业务系统。从第一天起就有明确约束：用户数据不能明文存储、敏感操作必须留审计日志、同一页面不同角色的数据要隔离、接口调用要有频率限制和幂等保证。这些约束在项目初期像紧身衣一样让人难受——写个列表页要考虑字段脱敏，做个按钮要判断权限再判断状态再判断是否可重复点击，发个请求要带traceId还要处理幂等。

第二类是内部工具和运营后台。没有合规约束，怎么方便怎么来。接口随便调，数据随便传，状态随便改，上线快、迭代快，大家都觉得效率高。

猜猜三年后哪个更健康？

每个产品经理都想要"实时"。实时报价、实时持仓、实时通知、实时风控——但凡跟"实时"沾边的需求，优先级都高得离谱。好像只要数据不是实时推送的，这个功能就不值得做。

但这里有个问题少有人追问：你看到的"实时"，到底实时到什么程度？

我见过太多团队在"实时"这两个字上栽跟头。不是技术做不出来，是做出来了才发现——用户根本分不清实时和准实时的区别，而团队却为那500毫秒的"实时"付出了整个架构的代价。

WebSocket的承诺和账单

先从最常见的"实时"方案说起。

WebSocket火了之后，几乎每个前端团队都想把长连接加上。HTTP轮询？那是不体面的技术债务。SSE？那是不完整的实时。只有全双工的WebSocket才配得上"实时"这两个字。

但WebSocket不是免费的午餐，它的账单分三层。

第一层是连接管理。一个WebSocket连接意味着服务端要维护一条持久化的TCP通道。听起来不复杂，但你算一下：10万个在线用户，10万条长连接，每条连接都有心跳、超时、重连逻辑。你的服务端不再是无状态的HTTP服务器了，它变成一个有状态的连接管理中心。这个转变的代价远比大多数团队预估的大。