Files
ai_soc_sw/docs/share/phase-01/决策故事_旧架构合并.md
T
tupingr 5b428d0810 chore(phase): Phase 1 收尾 — 一鸡多吃 + Dev工作台初始化 + Phase 2启动
- Phase 1 标记 100% 完成,Phase 2 标记 ACTIVE
- Dev AI 工作台重写:8个任务入队 + 依赖关系图
- 一鸡多吃:6篇对外分享文章(项目缘起/框架思路/阶段复盘/3篇决策故事)
- 新增 share-context Skill(内部文档→对外分享自动化)
- P01 文档同步更新(需求/架构/接口定义)

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-26 12:01:04 +08:00

4.1 KiB
Raw Blame History

决策故事:当两个架构要合并——30 项决策是怎么做的

背景

ErrLens 不是一个从零开始的项目。

在正式立项之前,我已经花了几周时间写了一个叫「家庭教育小程序」的架构设计——17 份文档,约 60,000 字,覆盖了小程序端、数据库、图像处理、交互设计、UI 规范、测试方案、部署方案等方方面面。

唯一的问题是:那个架构是面向「小学 5-6 年级学生家长 + 仅数学」的,用的是「微信云开发 + 云函数」的技术栈。而 ErrLens 定位已经变成了「小学初中学生 + 数学英语 + 自建后端」。

两套架构,一个旧一个新,重叠但不兼容。旧架构不能直接复用——技术栈变了。但也不能扔掉——里面有很多经过 Spike 验证的工程方案(图像处理管线、打印设计、UI 规范)。

问题变成:怎么系统地把旧架构中有价值的部分提取出来,合并到新架构里,而不是陷入无休止的细节讨论?


方法:结构化对比,逐项决策

我让 Arch AI 把 17 份旧文档全部读完后,把两套架构的差异拆成 30 个独立维度,按性质分成四类:

第一类:冲突项(8 项)

两套设计说了不同的话,必须二选一。

示例 旧架构 新架构 结论
技术栈 微信云开发 NestJS + PostgreSQL 选新架构,因为需要 Coze 沙盒自动化测试
目标用户 家长操作 学生本人 两者都要,学生和家长都可以操作
学科范围 仅数学 数学+英语 新架构已锁定

第二类:旧有新增(9 项)

旧架构有但新架构缺失的有价值功能。

示例 旧架构设计 决定
错题打印 完整 PDF 生成+下载流程 纳入 MVPP0
图像预处理管线 CLAHE+笔迹去除,经 Spike 验证 前置到 OCR 之前
UI 设计规范 完整规范文档,28 个图标 整体迁移

第三类:新有新增(7 项)

新架构创新,旧架构完全没有。直接保留,不讨论。

第四类:各有优劣(6 项)

两边方案各有利弊,需要权衡。

示例 结论
知识点编码:业务编码 vs 数字 ID 两者并存,ID 内部关联 + code 对外暴露
题目匹配:关键词 vs AI 语义 两阶段:关键词粗筛 → AI 精排

30 项决策,逐条过。人类拍板,AI 记录,一项一项写入架构文档。


思考:为什么能在一小时内完成 30 个决策?

如果让我一个人对着两份架构文档做合并,至少需要两天——读旧文档需要半天,对比需要一天,写合并方案再半天。

但 AI 可以:

  1. 并行阅读:17 份旧文档在 30 秒内全部读完并提取要点
  2. 结构化拆解:自动将差异按「冲突/新增/缺失/优劣」分类
  3. 草拟选项:每个维度列出优劣对比,方便人类判断
  4. 即时落地:决策一旦确认,5 分钟内更新完所有相关文档

人类的角色非常清晰:做判断。 AI 负责列出选项、分析利弊、写成文档——人类只需要说「同意」「不同意」或「换个方案」。

这个协作模式的核心是:人类不需要被 AI 告诉该怎么做,而是让 AI 把所有信息准备好,自己做决定。


关键收获

  1. 分类框架是决策效率的关键。 「冲突/新增/缺失/优劣」这个四象限让复杂对比变得可管理。下次遇到类似问题可以直接复用。

  2. 决策粒度要适中。 太细(每个字段风格讨论)浪费精力,太粗(「技术栈全换」一句话)埋隐患。30 项这个数量级刚好——半天做完,该覆盖的都覆盖了。

  3. 旧资产不要扔。 旧架构虽然技术栈变了,但设计思路、工程参数、Spike 验证结论都是真金白银的积累。要有系统的方法提取价值。


一句话总结

架构合并不需要你穷尽每一个细节。把它拆成独立的决策单元,人类逐项拍板,AI 负责剩下的——这就是「人机协同」在架构设计上的应用。