跟 AI 读架构，从一个后台任务开始

读完 AI 整理的项目说明，知道它用了什么框架、数据库和队列，到了自己的项目里，还是不知道该怎样选。这种落差很常见：技术名称容易记住，选择它时的条件却未必写在代码里。

第七期介绍过用 REA 分析大项目，再让模型讲解架构、整理文档的做法。拿到这份说明后，可以挑一个具体决定继续查，而不急着评价整套架构好不好。

沿着一个后台任务读下去

以一个假设项目为例：用户上传文件后，系统把转换任务放进队列。先找到任务在哪里创建、谁消费它、结果保存到哪里，看看用户怎样知道处理结束。

读到这里，能确认的是调用和数据流向。为什么选后台执行，还要继续找资料。可能是任务耗时太长，可能是要限制并发，也可能来自已有基础设施。没有设计记录时，让模型把这些解释列成候选，并指出各自需要什么证据。

接着查失败路径。进程在保存结果前退出，任务会不会再跑一次？再跑会不会生成重复文件？如果模型说可以放心重试，就让它指出防止重复写入的代码。找不到时，这一项判断还不能成立。

这样读下来，一份宽泛的架构讲解会变成几个可以继续查证的问题。

假设这个转换任务原来每小时只有几次，现在每分钟几百次。先估计单次处理耗时与可用并发，再看队列会积压多久。若用户必须等结果才能继续操作，也需要重新考虑后台任务的反馈方式。

这些分析不一定要求重做整个系统。可以在实验项目中只验证最担心的一项，例如重复提交是否会产生重复记录。记录输入、观察结果，以及还没覆盖的情况，比只保存一句该架构可扩展更方便以后使用。

有时答案是现有方案已经够用。为了一个低频任务引入复杂队列，可能反而增加部署和排障负担。理解架构也包括知道什么时候可以少做一点。

Michael Nygard 提出的架构决策记录，用短文保存重要决定的背景、状态和后果。Martin Fowler 的说明也建议保留旧决定，在被替代时链接到新的记录。

对于刚才的练习，笔记可以写明：文件转换通常要多久，用户能否离开页面，为什么采用后台执行，重复任务怎样处理。如果其中一项只是推测，就保留待查标记和相关代码位置。

下次遇到类似需求，先对照这些条件。若使用频率、等待方式和失败代价都不同，旧方案就只能提供问题清单，不能直接当作答案。