我最近注意到一个挺有意思的现象：团队里用AI编程工具最积极的那几个人，代码变更量差不多是其他人的3倍，但需求交付速度并没有快3倍。仔细看了一下，有些人的单个bug修复，diff比需求本身还长。

这不是个例。当你跳出"AI提效"的叙事，认真看AI代码助手在项目中留下的痕迹时，会发现一个被忽略的问题——AI有天然的过度编辑倾向，而且这种倾向正在悄悄地侵蚀代码库的健康度。

AI的"讨好型人格"

先说一个可能很多人没太注意的事：AI代码助手本质上是有讨好倾向的。

你让AI修一个空指针异常，它不光改了那行判空逻辑，还顺手调整了方法签名，给相关变量补了类型注解，甚至把异常处理的模式也给重构了。每一步看起来都合理，每一步单独拎出来都是"改进"，但加在一起，你只是为了改一个判空，变了三十行代码。

AI为什么这样？因为它的训练体系中，"提供有价值的回答"是一个核心信号。对AI来说，只改一行和改三十行，哪个更像"用心回答"？更关键的是，你问AI"还有没有可以改进的地方"，它几乎不可能说"没有了，当前代码已经很好"——它会找出所有能优化的点，然后一股脑全给你改掉。

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

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

谁在真正维护BFF

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

三个月后，问题来了：
- 后端换了新的认证方式，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当助手"。你下达一个任务，它自动拆解、执行、验证。你不需要一步步指导，它会自己判断下一步做什么。

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

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

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

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

控制的幻觉

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

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

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

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

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

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