不焦虑的架构师:从重新定义和AI的关系开始

回顾我的架构生涯，一直都有着隐隐的焦虑：对失控的焦虑和对决策的焦虑。

失控的焦虑："架构原则真的落地了吗？系统和组织有没有按规划的方向在走？有没有冒出新的问题，但是不知道？"
决策的焦虑："我做的架构决策，会不会有问题？信息调研清楚不清楚？决策判断究竟正确不正确？"

诚然，有些架构师确实是“技术大神”——但是大多数时候，架构师也都是普通人，我本人就时常会感到自己的精力有限，知识盲点、信息盲点和能力盲点都有很多，所以在很多时候真是如履薄冰。

不过，这种状态已然终结，进入了一个更好的，如鱼得水的状态。究竟是如何做到的呢？今天早上的经历就是个好例子，一起来看一下。

发现：模块的职责边界有点模糊

我的系统里有一套异步任务管理的逻辑，在前端这边，我本来以为它已经分离得比较干净了：通用的任务列表 UI 早就提到了公共包里，各个应用只要接一下就能用。但今天早上，我翻代码的时候发现了一个不对劲的地方：好像还有若干文件放在应用包里面，比如 apiCelery.ts、 TasksPage.tsx、 taskDataProvider.ts，而且，apiCelery.ts更是直接依赖了一个应用专属的 HTTP 客户端。

要不要改一下？肯定要改。问题是，该怎么做？

以前是要想方案的。如果忙，那就看看优先级，顾不上的话，就先不改了。不过，现在由于Agent的能力足够强，那么，可以有一种新的方案：和AI Agent聊上几句。我打开了Cursor的对话窗口：

我真的是和AI在商量。我没有说“请帮我重构”，而是“你认为合理吗”。

这是和AI的一种新的关系。这种关系已经建立了很久了。

如果把 AI 当只负责干活的员工，你会说"“请帮我重构”，它就动手，干完交差。好处是快，问题是——你让它干的事，你自己得费劲想清楚。如果自己还没想清楚，它干出来的东西大概率不是最终要的，改来改去，反而更慢。
如果把 AI 当值得全权委托的对象，你会说“你来决定怎么改”，把判断权交出去。听起来很省心，但往往会掉到坑里。AI的能力当然很强，但是架构决策这东西强依赖于上下文，没人比你自己更清楚上下文、约束和取舍，我也很难想到这么复杂的东西如何简单简洁的把上下文说清楚。全权委托的结果往往是：AI给的方案技术上是正确的，但不符合你的实际场景。
第三种就是协作关系。我说出自己的判断，但是邀请AI一起来做判断。它的回答可能印证了我的判断，也可能让我发现自己漏掉了什么——无论是哪种，我都比刚才更清楚了。而且还有个好处，后续要做点什么，这个上下文已经在讨论的过程中建立起来了。

Cursor去做了调研，然后给了我一些建议：

你的方向是对的，但 UI 层其实已经做了依赖倒置——TaskTable 不依赖 aisolveCoreApi，只依赖一个 TaskDataProvider 接口。真正没有收口的是 HTTP 层。

Cursor的建议是：如果没有第二个前端要接同一套任务 UI，现在修改收益有限，建议先小步走。

理解了这个情境之后，我说，“我确实有第二个前端要接同一套任务 UI”。

这其实是我假想的场景——当然我知道很快会发生。这里有个小插曲，Cursor很主动的到我的代码库中去搜“第二个前端”了。所以我不得不说：

后面就是Cursor的自主重构了，没啥意外，暂且不表。

意外发现的盲区

重构完之后，我去看了看改动了哪些文件，然后就发现有两个文件变得非常薄——TasksPage.tsx 只剩十来行，就是绑一下 HTTP 客户端然后渲染通用组件；taskApi.ts 更是只有一行，创建一个 API 实例。两个文件干的都是同一件事的边角，我就想，应该合并到一起。

我提了要求。Cursor 照做了，把 taskApi.ts 合并进了 TasksPage.tsx。但合并之后，它说了一句话：

如果觉得从页面文件里 import taskApi 别扭，可以再拆出去一个单独的文件。

这句话有点意外。Cursor 为什么会觉得"别扭"？还有人在引用 taskApi ？

接着问了一下，果然：KnowledgeBootstrapPage，知识体系构建页，在用 taskApi 做轮询。

我很意外为什么会有轮询。我的注意力一直在任务管理模块本身，没意识到还有别的页面在直接使用 taskApi。Cursor 因为分析了完整的引用关系，比我先看到了这件事。而这个被遗忘的消费者，带出了一个需要改进的设计。我看到了这个没想到的代码：

const pollTaskUntilDone = async (taskId: string) => {  //内容略    await new Promise((resolve) => setTimeout(resolve, 2000)); // 每 2 秒查一次  }};

这段代码的逻辑是：提交一个 Celery 异步任务之后，页面打开 Modal，然后开始轮询，每两秒查一次，最长等三十分钟，等任务完成了在当前页展示完整的构建报告。

为什么要这么干？我其实有点吃不准。我问Cursor：

现在问题就清晰了。接着讨论：

Cursor 给了三个方向：真异步、真同步、异步加推送。我选了最简单的：

好，现在改为真异步，去除不必要的轮询设计，保持简单。

改完之后，这个页面从大约四百行缩到了一百二十行。那个 while 循环消失了。

注意这个顺序。如果当时一上来就说“改掉”，可能真的会改出一个我没理解的东西。现在先让 Cursor 把代码看清楚、把设计意图弄明白，基于理解的判断，就容易多了，也可靠多了。

版本治理，并让未来的治理自己发生

前面两件事做完，代码干净了，接口抽象了，轮询也去掉了。但又发现了一个新问题：改完要发布新版本，发布完要升级依赖，升级完了要保证全仓版本一致。

这件事我之前已经有脚本，但我知道它不够好——每个应用各自写版本号，有的 ^0.1.3，有的 ^0.1.5，很容易出事。每当改了架构、抽象了接口、统一了契约，版本管理还是靠人记、靠人自觉，这个是不太合适的。这次不能继续凑合了，一鼓作气，搞定它吧。来，继续提问：

Cursor的判断是：逻辑成立，用 pnpm catalog 比继续堆 overrides 更干净，但"消费方版本矩阵"和"发布方内部依赖"是两层，不能混在一起管。还帮我评估了收益和成本——以我们包的数量，收益大于成本。

好。我说，“那就按你说的落地”。最终，我还提了个新的要求：帮我把这些规则写入文档。

一点体会

早上的这点时间，做了3次架构的演进：

把任务管理完整的封装到公共包，把项目特定依赖从公共包里分离。
把假“异步”（还是在轮询）改成真异步。
统一了全仓的版本管理，把发布治理写进了配置和脚本

现在不只是“代码变干净了”，而是更易于复用的组件，更有效的在未来让AI自我治理的机制（通过写入架构文档）。

整个过程中，我并不真的一直都知道答案。很多时候，我只是感觉“这样不对”“这样可能更好”。 Cursor也没有一直对——它忙着去找“第二个前端”，它判断不了“轮询该不该留着”，这也不算意外。

架构师的焦虑，很大程度上是一种孤独——一面对复杂系统，要做那么多判断，每一个判断，还会影响未来的判断。现在Agent能力足够强，可迅速调研，可建议方案和取舍，可快速执行。

架构师的角色还是那样，但是行为模式不一样了。核心已经和具体的细节调研以及跟踪执行无关，剩下的是架构师真正的价值：对设计的判断和取舍。

今天的判断有：

依赖倒置
去除“假异步”
统一管理版本
把版本管理策略写成文档，后续有AI自主管理和执行

AI做了剩下所有的事情：印证了模块修正的方向和边界，调研了不该有的依赖，建议了版本治理的方案...

这是一种更好的关系。

不要把AI只是当成工具，那样你只能得到执行。
不要无限信任AI，它有很多做不了的事情，搞不好你收获的是混乱和意外。
把它作为真正的同事，对话、然后给这个同事提供足够的信息，和它一起制定好未来系统演进的规则，然后让架构治理自己发生。