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

Next Token 博客

沿着任务提交、失败重试和结果交付读代码，再查设计理由。用一个具体例子，把架构讲解变成可以核对和复用的判断。

发布：2026-11-10
更新：2026-10-26

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

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

## 沿着一个后台任务读下去

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

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

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

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

## 改一个条件，看看方案还合不合适

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

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

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

## 记下这个决定当时解决了什么

Michael Nygard 提出的[架构决策记录](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions)，用短文保存重要决定的背景、状态和后果。Martin Fowler 的[说明](https://martinfowler.com/bliki/ArchitectureDecisionRecord.html)也建议保留旧决定，在被替代时链接到新的记录。

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

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

## 相关资料

- [使用 REA 与模型分析架构、整理经验的尝试](https://nexttoken.tv/weekly/007/transcript#quote-3fb85b619a2fda8c51d1)及其[复用目的](https://nexttoken.tv/weekly/007/transcript#quote-e5214dbc3daa7801eb8e)
- [架构能力需要实践机会的讨论](https://nexttoken.tv/weekly/007/transcript#quote-b2df0bd183e54d599af5)
- [Michael Nygard：Documenting Architecture Decisions](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions)，2011 年 11 月 15 日；查阅于 2026 年 10 月 26 日。
- [Martin Fowler：Architecture Decision Record](https://martinfowler.com/bliki/ArchitectureDecisionRecord.html)，2026 年 3 月 24 日；查阅于 2026 年 10 月 26 日。

## 来源与相关链接

- [网页版文章](https://nexttoken.tv/blog/learning-architecture-with-ai)
- [Weekly #007 完整文字稿](https://nexttoken.tv/weekly/007/transcript)