最小必要架构：什么不该做——删掉的多余功能，比加上的新功能更有价值
这是《AI数字员工系统设计与企业自动化实战》日志连载第 47 篇
作者：老高FDE-AI实战前沿
深度聚焦：企业AI落地实战、AI-Workforce、AI数字员工实战、企业Agent组织设计、企业Agent架构搭建
文章目录
- 最小必要架构：什么不该做——删掉的多余功能，比加上的新功能更有价值
- 前言
- 一、为什么"不做"比"做"更难
- 二、V1 不做清单
- 三、什么时候"该做了"：被需求逼着做
- 四、一个"过度设计"反例的完整复盘
- 五、架构的复杂度是"负债"，不是"资产"
- 六、流程也要分级：纪律用在值得的地方
- 七、三个容易踩的坑
- 坑 1：把"不做"当"偷懒"
- 坑 2：为了"面子"上新技术
- 坑 3：该做的时候不敢做
- 八、本章小结
- 结语
前言
先讲一个真实的反例。
有个团队做 AI 项目，需求其实就一个：采集企业信息、做个简单的画像。
但他们一上来就规划：数据湖 + 知识图谱 + 向量检索 + 微服务 + K8s……
结果呢？
项目还没跑通最小闭环，就被这一堆"高级架构"拖死了。三个月过去，一个能用的功能都没交付，团队还在纠结"数据湖的分层设计"。
这个反例，引出一个很多人忽视的能力：
克制，也是架构能力。
知道什么不做，和知道什么做，一样重要。而且往往更难。
今天讲"最小必要架构"：
删掉的多余功能，比加上的新功能更有价值。
一、为什么"不做"比"做"更难
做系统，人天然想做"加法"：上微服务、上数据湖、上知识图谱、上向量数据库……
因为"做"显得有产出，"不做"显得没做事。
但真相是反的：
| "做加法"的代价 | 说明 |
|---|---|
| 复杂度爆炸 | 维护成本远超价值 |
| 项目延期 | 被"高级架构"拖慢 |
| 资源浪费 | 钱和人力花在"用不上"的地方 |
| 死得更快 | 还没验证价值，就被架构拖死 |
V1 阶段最大的风险，不是"做得不够"，而是"做得太多"。
架构师的判断力，一半在"做什么"，一半在"不做什么"。而"不做"更难——因为它要抵抗"做加法"的诱惑，要判断"这玩意现在真的需要吗"。
二、V1 不做清单
我们真实系统的 V1 阶段，白纸黑字明确不做这些：
| 不做 | 为什么不做 |
|---|---|
| ❌ 微服务架构 | 单机 + 单体够用，微服务是"将来才需要" |
| ❌ 数据湖 / 数据仓库 | 数据池（SQLite + JSON）够用 |
| ❌ 知识图谱 | 关系表 + 标签够用 |
| ❌ 向量数据库 | 还没到"语义检索"的阶段 |
| ❌ K8s / 容器编排 | 单机部署够用 |
| ❌ 复杂消息队列 | 顺序执行够用 |
核心逻辑就一句：当前业务用不上，就不做。
而且，这个"不做清单"不该只存在脑子里，最好写进文档。我们真实系统的 PRD 里，就有一节"非目标"，白纸黑字列了八条：
第一版不做： 1. 智能路由 2. 多模型负载均衡 3. 自动成本优化 4. Benchmark 5. 微服务拆分 6. 消息队列 7. 向量数据库 8. 知识图谱写下来的"不做"，比心里想的"不做"，更能挡住后续的"顺手加一个"。
三、什么时候"该做了"：被需求逼着做
“不做"不是"永远不做”。那什么时候该做？
三个信号：
- 业务真的需要（不是"觉得将来需要"）；
- 现有方案真的扛不住（有数据证明，不是"担心扛不住"）；
- 复杂度值得（收益 > 成本）。
一句话：
被需求逼着做，而不是被想象勾着做。
我们真实系统的演进就是这样：V1 用 SQLite + JSON + 单体跑通最小闭环；数据量上来后，才逐步加"快照增量"“TTL”“数据字典”——每一个都是被真实需求逼着加的，不是想象驱动。
被逼着加，是"有依据的加法"；被想象勾着加，是"过度设计"。
四、一个"过度设计"反例的完整复盘
开头那个反例，值得完整复盘一遍——因为它太典型了。
想法： 做企业信息采集，一上来就规划"数据湖 + 知识图谱 + 向量检索"， 想"一步到位"。 结果： 项目还没跑通最小闭环，就被架构设计拖住了。 三个月过去，一个能用的功能都没交付。 如果重来： 1. V1 只做"采集 + 入库"最小闭环，用 SQLite + JSON； 2. 跑通后，数据量真的上来了，再逐步加"快照增量""TTL"； 3. 每一个加，都是被真实需求逼着加的，不是想象。 教训： 先跑通，再谈架构演进。 超前设计的架构，是"还没学会走就想飞"。五、架构的复杂度是"负债"，不是"资产"
这一条是核心认知，值得单独说：
每一行架构代码、每一个组件，都是负债——要维护、要排查、要升级。
加的架构越多，负债越重。
这张图就是"最小必要架构"的全部判断逻辑。
而且"克制"还有一层好处：架构简单，改起来快，才能随业务快速迭代。过度设计的系统，改起来慢，反而"进化"不动。
克制，是持续进化的前提。
六、流程也要分级：纪律用在值得的地方
最后补一个容易忽略的点：“最小必要"不只体现在"做不做架构”，也体现在"流程的轻重"。
| 级别 | 适用 | 流程 |
|---|---|---|
| 简单任务 | 一次问答、单文件小改动 | 轻流程，不套完整纪律 |
| 复杂项目 | 多步、跨文件、跨会话 | 重流程，启用完整纪律 |
用一个重流程去压一个"改一行代码"的小任务，本身就是过度设计。
架构要克制，流程也要克制。这是同一件事的两个面。
七、三个容易踩的坑
坑 1：把"不做"当"偷懒"
“这也不做那也不做，是不是偷懒？”
破解：区分动机——最小必要是"判断后不做"，偷懒是"没判断就不做"。前者有明确的"为什么不做"，后者是"懒得做"。
坑 2：为了"面子"上新技术
“团队里总有人想上微服务、上向量库——为了简历、为了面子。”
破解：问一句"当前业务用得上吗"。用不上，就是负债。扛住"面子"的诱惑，是架构师的必修课。
坑 3：该做的时候不敢做
“一直克制，结果数据量真扛不住了，还不敢加。”
破解：“不做"不是"永远不做”。被需求逼着做，就是"该做"的信号——那时加，是有依据的加法。
八、本章小结
今天讲的是最小必要架构。
核心认知：克制也是能力，架构复杂度是负债。
V1 不做清单：微服务、数据湖、知识图谱、向量库、K8s、消息队列。
该做的信号：被需求逼着做，不是被想象勾着做。
记住 3 个要点：
- 删掉的多余功能，比加上的新功能更有价值——复杂度是负债，不是资产
- V1 最大的风险是"做得太多"，不是"做得不够"——当前用不上就不做
- 克制是持续进化的前提——架构简单才改得快，改得快才进化得动
最后送大家一句话：
删掉的多余功能，比加上的新功能更有价值。
因为加的每一行，都是要还的债。
结语
这一篇讲的是"克制"。
到这里，第 7 周（进阶与展望）的内容就讲完了。我们聊了沉淀、失败、反模式、克制——但还有一个更大的话题没碰：未来。
下一篇：
《Day 48：未来趋势——AI 数字员工的下一站》
会讲清楚：岗位会怎么演进、"企业级"的分水岭在哪，以及一句特别重要的话——“未来不是 AI 替代人，是会用 AI 的人替代不会用 AI 的人”。
💬互动话题：你见过最典型的"过度设计"是什么？有没有"还没跑通就被高级架构拖死"的项目？评论区聊聊，说说如果重来，你会砍掉哪一块。
本文来自《AI数字员工系统设计与企业自动化实战》系列探索。
内容围绕：企业AI落地实战、AI-Workforce、AI数字员工实战、企业Agent组织设计、企业Agent架构搭建。
持续更新！
