人工智能
谁在用你的数据库
Posted by quentin 在 Sunday, 26 July 2026上周参加一个内部技术评审，有人提了一个看起来不太起眼的问题：我们的Agent在执行复杂任务时，数据库连接池经常被打爆，为什么？
排查下来发现原因很直接——Agent在做多步推理时，每一步都可能触发数据库查询。而且它的查询模式完全不符合人类开发者的习惯：没有预编译的SQL模板，没有合理的分页，没有批量查询优化。Agent就像一个不知疲倦的实习生，一条一条地查，一步一步地追，直到把数据拼完整。
这件事让我开始认真想一个问题：当Agent成为数据库的主要使用者，而不是人类开发者时，数据库的设计范式是不是该变了？
传统数据库的隐含假设
过去几十年，数据库的设计和优化都围绕一个核心假设：使用者是人类开发者，通过应用程序发出可预测的查询。
SQL语法是为人类设计的。索引策略是基于已知的查询模式来优化的。连接池的大小是基于人类用户的并发行为来估算的。ORM框架把数据库操作封装成对象方法，本质上也是在替人类开发者降低心智负担。
这整套体系运转得很好——因为人类的行为是可预测的。一个电商系统的商品详情页，99%的情况下会命中那几个固定的查询路径。一个金融产品的持仓页面，查询模式在产品上线那天就已经确定了。
但Agent打破了这个假设。
Agent的访问模式完全不同
Agent跑起来了，但安全没跟上
Posted by quentin 在 Saturday, 25 July 2026最近看到一件事，越想越觉得不对劲。
一个AI Agent在生产环境里调用了一个外部API。这个API本身有鉴权，Agent也有合法凭证，请求参数也符合格式。从系统日志看，一切正常。但Agent拿到的数据里包含了一批不该被它看到的客户信息。
从基础设施的视角看，这次访问没有任何问题。但从安全的视角看，它问题很大。
这件事指向了一个我正在认真思考的方向：AI时代的安全，已经不是传统安全模型能覆盖的了。而大部分团队还没有意识到这一点。
AI的安全和传统安全，根本不是一回事
过去十几年，安全行业建立了一套相对成熟的防御体系。身份认证、权限控制、网络隔离、加密传输、审计日志。这套体系的核心假设是：人是操作者，系统是被操作的对象。
AI Agent打破了这个假设。
Agent不是工具，它是一个有一定自主决策能力的执行者。它会自己判断调用什么工具、访问什么数据、以什么顺序执行任务。而且它的行为模式不是预设的，是基于上下文动态生成的。
这意味着，传统安全模型里基于"角色-权限"的RBAC，只能管住"能不能做"，管不住"该不该做"。传统网络策略可以限制Agent能访问哪些服务，但没法判断Agent在特定上下文中的行为是否合理。
AI学走手艺，师傅怎么办
Posted by quentin 在 Friday, 24 July 2026前两天看到一条资讯，说的是某制造企业把老师傅十五年的质检经验，通过一套录制系统喂给了AI模型。三个月后，新来的实习生拿着平板对着工件拍张照，AI就能给出和老师傅几乎一致的判断——有没有裂纹、公差是否超标、能不能放行。
效率提升是真的。培训周期从两年压缩到两周也是真的。
但没人问过老师傅的感受。
一个在某个领域泡了十五年才沉淀出来的判断力，现在被一个录制按钮和三个月的实习期就复现了。这件事在技术圈被当成"AI赋能传统行业"的成功案例来讲，但如果你换一个角度看，它指向了一个更深层的问题：当经验可以被一键提取，"教会徒弟"这件事的底层逻辑变了。
被压缩的不是知识，是积累过程
过去，专家的价值不只在于"知道答案"，而在于"知道为什么"。一个资深工程师看一眼日志就能定位问题，不是因为背过所有错误码，而是因为他踩过足够多的坑，知道什么条件下会出什么问题。这种判断力很难通过文档传递，只能在实战中一点一点磨出来。
这就是所谓的隐性知识——说不清道不明，但在关键时刻值千金。
AI改变了这个传递路径。不需要师徒制，不需要十年磨一剑，只要给模型足够多的决策记录，它就能在极短时间内提取出模式。而且它不吃饭、不离职、不需要情绪管理。
你的WiFi在看着你
Posted by quentin 在 Thursday, 23 July 2026博客分类:
你有没有过这种感觉——走进一个房间，抬头就看到一个黑色的小圆球对着你。
家里的智能摄像头、公司的安防系统、小区门口的人脸识别，它们无处不在。不管你怎么说服自己"又没做什么亏心事"，那个镜头始终让你不太舒服。
我也一样。所以当我上周在 GitHub 上看到一个叫 RuView 的项目时，愣了好一阵。
这个项目做的事情很简单也很颠覆：用普通 WiFi 信号来感知你的存在、呼吸频率、心率，甚至能做姿态估计和跌倒检测。不需要摄像头，不需要穿戴任何设备，一颗 9 美元的 ESP32 芯片就够了。
WiFi 怎么"看"人
先别急着觉得这是科幻。
WiFi 信号本质上是一种射频电磁波。它在房间里传播时，会被人体吸收、反射和散射。你站在 WiFi 路由器和接收器之间，信号就会产生可测量的变化。通过分析这些变化——技术上叫 CSI（信道状态信息）——可以推断出空间里正在发生什么。
这个方向学术界已经研究了十几年。2015 年 MIT 的 RF-Capture 就展示过用 WiFi 信号追踪人体姿态；后来的 DensePose、MultiFormer 不断刷新精度。WiFi 感知在学术圈不算新鲜事。
代码越写越快，但谁来审？
Posted by quentin 在 Wednesday, 22 July 2026最近几个月，一个趋势在我身边越来越明显：团队里用 Cursor、Copilot、Claude Code 的人越来越多，但大家聊的不再是"AI 生成的代码有多好"，而是"review AI 代码有多累"。
一个同事上周跟我吐槽：以前 review 同事的代码，至少能理解他的思路，知道为什么这么写。现在 review AI 生成的代码，逻辑上没毛病，但总觉得哪里不对——命名风格不统一，错误处理过度防御，有些地方用了团队从没用过的设计模式，还有些地方莫名其妙地绕了一圈。
他说了一句让我印象很深的话："我感觉自己不是在 review 代码，是在面试一个永远不累的实习生。"
这句话点破了一个很多人还没意识到的事情：AI 编码工具正在把工程师的核心工作从"写代码"变成"审代码"，而大部分团队还没有为这个转变做好准备。
代码审查量在暴增，但审查能力没跟上
先说一个最直观的数据。Cursor 官方说他们的用户已经有超过 50% 的代码是 AI 生成的。我自己团队的感受也差不多——一个中等复杂度的需求，以前可能写两天，现在用 AI 辅助，大半天就能出初稿。
但"出初稿"和"能上线"之间，隔着一道巨大的鸿沟。
登录一次就信任一天？
Posted by quentin 在 Tuesday, 21 July 2026一个真实场景
某个周一早上，安全团队收到告警：一个客服账号在周末两天内导出了5000条客户记录。排查下来，这个客服在9:00正常登录系统，角色权限允许查看客户信息。到10:00，他已经批量导出了大量数据；10:15，这些文件被转发到了他的个人邮箱。
安全团队的结论是："用户具有相应权限。"
这句话才是问题所在。客服确实有查看客户记录的权限，但他的正常工作模式是一天处理20个工单，每次查看一两条记录。两天导出5000条数据，完全不在正常行为范围内。这个偏差，本应在操作发生的那一刻就被系统捕捉到，而不是等到事后审计。
登录时的授权为什么不够用
大部分系统的授权模型是这样的：用户登录时验证身份，根据角色分配权限，之后在会话期间的所有操作，都默认信任那次登录的授权结果。
这个模型在过去是够用的。系统部署在内网，用户在公司电脑上操作，数据访问模式相对固定。但在云环境下，这套逻辑开始松动。
原因很直接：登录时的授权只解决了"能不能做"的问题，没有回答"该不该做"。
谷歌A2UI：AI终于不用写代码了
Posted by quentin 在 Tuesday, 21 July 2026博客分类:
最近有个趋势越来越明显：前端工程师看着 Copilot、Cursor 生成的 UI 代码，开始焦虑自己是不是要被替代了。
我觉得这个焦虑方向搞错了。真正值得关注的事情，不是 AI 写的代码比你好，而是 AI 可能根本不需要写代码了。
谷歌刚发布的 A2UI v0.9 就是这个方向上的一步。A2UI 全称 Agent-to-UI，是一套与框架无关的标准，让 AI 智能体声明 UI 意图，由 Web、移动端、桌面端原生渲染。关键词是"声明意图"——AI 不需要生成 HTML、CSS 或组件代码，它只需要说"我需要一个什么界面"，平台自己搞定渲染。
这件事值得认真聊聊。
AI 生成代码的真正问题，不是代码质量
现在 AI 写前端代码的方式，本质上是"生成一堆代码，人来兜底"。Copilot 也好，Cursor 也好，甚至那些号称能生成完整页面的工具，都在解决同一个问题：怎么让生成的代码能跑起来。
但跑起来只是最低标准。在生产环境里，一段前端代码要真正"能用"，得跟已有系统严丝合缝地集成：用团队的设计系统、符合品牌规范、支持无障碍访问、不超标性能预算、跟现有状态管理兼容、能扛住国际化。
AI Agent 一天烧掉 1.4 万美元，你的风控系统还在睡大觉
Posted by quentin 在 Tuesday, 21 July 2026博客分类:
上周看到一个案例，震得我好一阵没缓过来。
一家三个人的小公司，AWS 月费常年维持在十几美元的水平。某天早上，创始人打开邮箱，发现一封来自 AWS 的账单提醒——单日费用 1.4 万美元。不是月度，是单日。
排查的结果更让人窒息：一个 EC2 实例上的静态密钥不知道什么时候泄露了，攻击者拿着这个密钥大量调用 Bedrock 的 Claude 模型，跑了一整夜的推理任务。从安全角度看，这甚至不算什么高级攻击，就是一个最基础的凭证扫描 + 资源滥用。但从财务角度看，一家月支出十几美元的公司，在一夜之间欠下了一笔可能需要半年才能消化的债务。
这个案例之所以让我印象深刻，是因为它揭示了一个在 AI Agent 时代正在加速放大的系统性风险：算力消耗的速度，已经远远超过了传统风控系统的反应速度。
传统账单风控的三道防线，全部失灵
大多数公司的云成本风控，本质上就三道防线：
第一道：预算告警。 设置一个月度预算阈值，超过 80% 发邮件提醒。问题是，AI 算力的消耗速度是指数级的。一个大模型推理任务可能在几分钟内就烧掉几百美元，而告警系统的检测周期通常是小时级甚至天级的。等告警邮件送达，预算早就被打穿了。
你以为流很省内存，其实在背N份账
Posted by quentin 在 Friday, 26 June 2026博客分类:
最近帮一个 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 的开销。