tupingr
5b428d0810
- 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>
88 lines
4.1 KiB
Markdown
88 lines
4.1 KiB
Markdown
# 决策故事：当两个架构要合并——30 项决策是怎么做的
|
||
|
||
## 背景
|
||
|
||
ErrLens 不是一个从零开始的项目。
|
||
|
||
在正式立项之前，我已经花了几周时间写了一个叫「家庭教育小程序」的架构设计——17 份文档，约 60,000 字，覆盖了小程序端、数据库、图像处理、交互设计、UI 规范、测试方案、部署方案等方方面面。
|
||
|
||
唯一的问题是：那个架构是面向「小学 5-6 年级学生家长 + 仅数学」的，用的是「微信云开发 + 云函数」的技术栈。而 ErrLens 定位已经变成了「小学初中学生 + 数学英语 + 自建后端」。
|
||
|
||
两套架构，一个旧一个新，重叠但不兼容。旧架构不能直接复用——技术栈变了。但也不能扔掉——里面有很多经过 Spike 验证的工程方案（图像处理管线、打印设计、UI 规范）。
|
||
|
||
问题变成：**怎么系统地把旧架构中有价值的部分提取出来，合并到新架构里，而不是陷入无休止的细节讨论？**
|
||
|
||
---
|
||
|
||
## 方法：结构化对比，逐项决策
|
||
|
||
我让 Arch AI 把 17 份旧文档全部读完后，把两套架构的差异拆成 30 个独立维度，按性质分成四类：
|
||
|
||
### 第一类：冲突项（8 项）
|
||
|
||
两套设计说了不同的话，必须二选一。
|
||
|
||
| 示例 | 旧架构 | 新架构 | 结论 |
|
||
|------|--------|--------|------|
|
||
| 技术栈 | 微信云开发 | NestJS + PostgreSQL | 选新架构，因为需要 Coze 沙盒自动化测试 |
|
||
| 目标用户 | 家长操作 | 学生本人 | 两者都要，学生和家长都可以操作 |
|
||
| 学科范围 | 仅数学 | 数学+英语 | 新架构已锁定 |
|
||
|
||
### 第二类：旧有新增（9 项）
|
||
|
||
旧架构有但新架构缺失的有价值功能。
|
||
|
||
| 示例 | 旧架构设计 | 决定 |
|
||
|------|-----------|------|
|
||
| 错题打印 | 完整 PDF 生成+下载流程 | 纳入 MVP，P0 |
|
||
| 图像预处理管线 | 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 负责剩下的——这就是「人机协同」在架构设计上的应用。**
|