从功能集合，
到优雅系统。

为什么有的产品像一张不断膨胀的功能清单，有的产品却简洁、强大，而且越用越觉得顺手？本手册把你想学习的能力称为系统级产品设计思维：把复杂问题组织成清晰的概念、关系、状态与边界，再把它们翻译成用户能够理解的体验。

这不是一种神秘天赋，也不只是写 PRD、画原型或选择技术栈。它是一套可以练习的判断方法：识别什么值得解决，建立恰当模型，在约束下取舍，再通过真实使用修正判断。

对象抽象与过程抽象，要一起使用

对象视角回答“系统里有什么，谁拥有什么责任”；过程视角回答“事情怎样发生，状态如何改变”。只列对象，系统会静止；只画流程，责任和数据归属容易模糊。这两种视角并不等同于必须选择面向对象或面向过程的编程语言风格。

同一条流程，应能映射到对象的状态变化；同一个对象，也应能在真实场景里找到存在理由。优秀的抽象不是名词越多越专业，而是能解释更多场景，又不制造不必要的负担。

“顶级”不是功能最全，而是多个目标之间的平衡

这是本手册提出的观察框架，不是经过统计验证的产品质量公式。不同产品对这些维度的权重不同，也不存在一套永远正确的架构。

第一性原理防止盲目照抄；领域建模防止堆功能；边界设计防止牵一发动全身；交互思维防止只顾内部优雅；工程约束防止只做演示；产品取舍防止无限膨胀。

第一步：把目标写成用户结果

“让团队通过统一入口调用多个模型，在上游异常时知道请求发生了什么，并能够核对用量与费用。”这比“做账号管理、分组、计费、报表”更适合用来判断功能是否必要。

第二步：识别那些不能混为一谈的概念

这里的目标不是把对象压到最少，而是避免把身份不同、变化原因不同、确定性不同的东西挤在同一个概念里。真实项目可能需要进一步拆分；也可能在更小范围里合并部分实现。

第三步：别让一个“状态”承担全部含义

一次请求可以经历多次尝试；执行完成与费用确认，也可能发生在不同时间。因此，“请求成功”“某次尝试超时”“用量待确认”可以同时成立于不同记录，不能用一个全局 status 含糊地表示。

上图仅表示一次尝试的简化生命周期。结果未知时，先核查或对账；核查后可能转为已确认结果，必要时进入人工处理。不能仅凭本地超时直接断定远端未执行。

第四步：写出能验收的业务不变量

这些是本例选择的设计约束，不是自动成立的工程事实。实现时仍须设计事务、唯一约束、授权检查、恢复机制与测试。“有请求 ID”也不等于系统就具备端到端幂等性。

第五步：用一次变化检验模型

给系统增加一家协议不同的模型供应商。合理的预期是：新增或修改协议适配、能力声明、凭证配置与相应测试；调用方身份、账务记录的基本语义，不应因此被整体重写。

但若新供应商带来全新的收费方式、异步任务或数据保留要求，模型也可能确实需要演进。低耦合不是零修改，而是修改与真实变化相称。

一条正常流程，不足以定义一个模块

假设要给 Agent 设计上下文治理。如果聊天界面负责截断，工具模块负责摘要，子 Agent 各自压缩，记忆系统又另存一份历史，问题不是“组件不够多”，而是责任散落，缺少统一的规则与事实来源。

可以先约定一个清晰边界：上下文模块接收任务所需材料与预算约束，返回构建后的上下文、来源清单以及截断或压缩的说明。至于内部采用什么算法、是否独立部署，可以随后决定。

“把所有逻辑收进一个万能服务”同样会产生问题。模块要为相关责任提供清晰接口，而不是变成任何需求都能往里塞的容器。

把异常也做成产品的一部分

以上为教学文案，不是对所有 503 的统一解释。实际提示必须根据错误来源、发送阶段与日志证据生成。结果未知也不代表系统可以无限等待，应定义核查时限与人工处理入口。

用五条路径验收，而不只验收“成功”

发现过度设计的三个信号

没有真实使用者的通用性：为了“以后可能需要”建立万能插件系统。无法解释的层级：每层只转发一次调用，却增加理解成本。把决定都推给用户：每个技术参数都暴露成配置，但没有可靠默认值。

解决方法不是一律删除，而是追问：这层边界到底隐藏了什么复杂性，保护了什么变化，服务于什么已知场景？如果说不清，先用更直接的实现。

选择一个你熟悉、可以合法访问的产品。第一轮只研究一个闭环，不研究整个平台。比如：在一个网关里发起调用，并在失败后核查记录。

不要以“与原作者不同”判定自己错误

真实产品可能受到历史版本、团队规模、商业目标与迁移成本的影响。你的简化方案更小，不必然更优秀；真实实现更复杂，也不必然更合理。比较时要写清双方的约束，再评价取舍。

“帮我做一个世界级、功能完善、高内聚低耦合的产品”，表达了愿望，却没有定义判断标准。更有效的合作方式，是让 AI 围绕具体问题、约束、证据和反例推进。

这些是职责，不一定是四个独立 Agent。同一个 AI 也能分阶段承担；更换角色或增加 Agent，并不自动带来独立判断。关键在于：评审是否能够指出反例，结论是否有证据，而不只是互相赞同。

五阶段可复制提示词

将方括号内容替换成你的项目事实。一次只执行一个阶段；阶段产物有重大缺口时，先修正，再向下推进。

你是我的产品研究与问题定义伙伴。我们这一轮只定义问题，不设计页面，不写代码，不直接给出技术栈。

【项目背景】
产品或想法：[填写]
目标用户：[填写]
我观察到的具体困难：[填写]
已有材料或证据：[填写；没有就标注“暂无”]
本轮可投入的时间、预算和人员：[填写]
不能违反的约束：[填写]

请按以下顺序工作：
1. 区分已知事实、待验证假设与未知项，不把推断写成事实。
2. 将需求改写为“什么人在什么情境下，要完成什么结果，现在被什么阻碍”。
3. 提取 3 个优先场景，为每个场景写触发、输入、期望结果、失败代价和现有替代方案。
4. 给出本轮目标、非目标、约束，以及能观察或测试的成功条件。
5. 指出最危险的 3 个假设，并建议成本最低的验证办法。
6. 输出一页项目简报，不增加未经论证的功能。

遇到关键缺失信息时，只提最影响判断的问题；若暂时无法获取，明确写出临时假设及其风险。
请停止在本阶段，不要自动进入架构设计。

你是我的领域建模伙伴。以上一阶段的问题简报为约束，不照抄竞品菜单，不先设计数据库表。

【输入】
已确认的问题简报：[粘贴]
优先场景与约束：[粘贴]

请完成：
1. 提出少量核心概念，并说明各自的身份、责任、生命周期、归属与存在理由。
2. 写出易混淆概念的“是什么 / 不是什么”；区分对象、属性、规则、事件与查询结果。
3. 用对象视角画概念关系，再用过程视角走完一个完整场景；核对两者是否一致。
4. 对关键对象列出合法状态、触发事件、转换条件和结果未知的处理方式。
5. 写出 5—8 条可验证的业务不变量。
6. 给出至少两种合理模型，比较理解成本、变更成本、实现难度与适用边界。
7. 主动删除没有独立责任、没有现实场景支撑的概念；保留删除理由。

不要默认采用微服务、事件溯源或复杂 DDD 分层。标出任何尚未确认的抽象。
最后给出你的推荐及不推荐另一方案的原因；停止，等待本轮评审。

你是我的系统与交互设计伙伴。只使用已经选定的模型，新增概念必须说明原因。

【输入】
选定的领域模型：[粘贴]
核心场景、约束、不变量：[粘贴]

请完成：
1. 按变化原因划分逻辑模块；说明数据归属、输入、输出、权限、错误和版本策略。
2. 区分逻辑边界、代码边界与部署边界，给出当前规模下最简单的可行实现。
3. 走通成功、失败、并发、恢复、安全五类路径。
4. 单独处理超时、重复提交、部分成功、取消、权限撤销与结果未知。
5. 对重试写明前提、幂等范围、次数或时间预算；不要声称一个请求 ID 就能保证端到端只执行一次。
6. 把系统状态翻译为用户能理解的文案：当前情况、已知影响、未知项、下一步动作。
7. 为最小闭环列出 Given / When / Then 验收用例。

请明确列出无法保证的行为、待验证工程假设与可能误导用户的文案。
不要为了界面简洁隐藏风险，也不要为了架构完整增加无依据的模块。

你现在是独立的设计评审者，而不是替方案辩护的作者。仅依据下面的材料判断。

【输入】
问题简报、模型、契约与验收用例：[粘贴或提供文件]

请审查：
1. 找出最可能导致用户损失、数据不一致或不可恢复结果的 5 个问题。
2. 找出职责重复、概念混淆、隐式依赖和没有实际场景的抽象。
3. 构造反例：新增供应商、重复事件、响应丢失、权限变更、进程重启、流式输出中断。
4. 对每个问题输出：证据或假设、触发条件、具体后果、严重程度、最小修复、对应测试。
5. 提出可以删除、推迟或由现有机制组合实现的功能；说明不会破坏哪些核心承诺。
6. 区分已证实缺陷与风险猜测，不为了凑数量编造问题。
7. 对有争议的选择给出两个方案及适用条件，不做无条件的“最佳实践”推荐。

最后给出：阻断项、可带条件接受项、后续观察项。没有运行证据的内容，不得标为“已验证”。

你是负责实现与验证的工程伙伴。以已评审设计为基线，先交付最小纵向闭环，不一次性铺满所有页面。

【输入】
已评审方案：[粘贴或提供文件]
阻断问题及处理结论：[粘贴]
开发环境与可用权限：[填写]

请按以下顺序执行：
1. 说明最小闭环包括什么，以及本轮明确不做什么。
2. 先列验收用例与关键不变量，再划分可独立验证的小步骤。
3. 每次只实现一个能端到端验证的切片；保留清晰边界，不提前建设通用平台。
4. 运行实际可执行的检查：正常流程、异常、授权、重复处理和必要的并发或恢复测试。
5. 报告修改内容、运行命令、实际结果、未运行项目和阻塞原因。没有执行过的测试不得声称通过。
6. 用模拟数据或桩实现的部分必须标明，不能包装成真实集成完成。
7. 发现模型不适用时，先记录冲突、备选与影响，不要用隐式特殊分支悄悄绕过。
8. 维护一份设计决策日志：背景、选择、放弃方案、证据、代价、重新评估条件。

涉及生产数据、付费外部操作、凭证或不可逆动作时，先说明风险与必要授权，不自动执行。
完成后，按验收用例逐条给出“通过 / 失败 / 未验证”及证据，再提出下一轮最值得验证的一个假设。

每次交接，固定携带这五样东西

不要只把上一轮聊天全文继续堆给 AI。将事实与决定整理成短而稳定的项目基线；在发生变更时记录版本与原因。这样你才能分辨它是在继续设计，还是悄悄换了一套前提。

可以按每周约 5–8 小时安排，也可以根据已有能力压缩或延长。十二周是练习结构，不是成为顶级设计者的保证。真正的判断力仍需要多轮真实项目与使用反馈。

下面是训练用的自评工具，不是科学量表，也不用于证明产品一定优秀。不同维度不能相互抵消：即使总分很高，严重权限漏洞或不可控扣费仍可能阻断交付。

看到一个精妙设计，不要只收藏截图。记录它解决了什么矛盾，有哪些备选，为什么选择现在的方案，以及何时应该改变这个选择。

不需要先读完五本书才开始实践。下面按本手册的训练目标安排阅读切入点；顺序可以调整，每本书都配一项立即可做的练习。

十二个术语，用自己的话讲清楚

领域模型

用一组概念、关系与规则解释业务；不是数据库结构的同义词。

统一语言

在团队讨论与实现中保持关键概念含义一致。

限界上下文

一个模型和词汇含义有效的范围；跨范围需要明确转换关系。

业务不变量

无论执行顺序或异常如何，在约定边界内都必须维护的规则。

状态机

描述对象有哪些状态，以及什么条件允许发生哪些转换。

契约

调用双方对输入、输出、权限、错误与行为保证的明确约定。

高内聚 / 低耦合

相关责任集中；不同责任通过清晰边界协作，不相互窥探内部细节。

幂等

在约定操作与范围内，重复处理不会重复产生应只发生一次的业务效果。

纵向切片

围绕一个用户目标，贯通界面、业务逻辑与数据的最小可运行部分。

心智模型

用户对系统如何工作的理解；它会影响预期和操作。

变更影响面

一次变化实际牵涉的概念、模块与行为；不是单纯的改动文件数。

设计决策记录

保存选择背景、候选方案、理由、代价、证据与重新评估条件。

参考资料与案例边界

资料入口于 2026 年 10 月整理核对。本文是基于本次讨论整理的学习框架与原创练习，不是对任何一本书的完整摘要。引用支持相应概念；教学案例、评分标准与训练路线属于本手册的建议，不是原作者的统一规范。产品文档可能变化，请以原文为准。

1. John Ousterhout · A Philosophy of Software Design ↗

   作者主页；对应复杂度、模块与软件设计的延伸阅读。

2. Eric Evans · DDD Reference ↗

   作者团队提供的领域驱动设计术语与模式参考。

3. Martin Fowler · Bounded Context ↗

   限界上下文与模型之间关系的说明。

4. Nielsen Norman Group · Mental Models ↗

   用户如何形成对系统行为的预期。

5. Claude Code 官方文档 · Extend Claude Code ↗

   Skills、MCP、Hooks、Subagents 等扩展的职责区分。产品能力会演进。

6. AWS Builders’ Library · Timeouts, retries, and backoff with jitter ↗

   超时不代表没有副作用；重试、退避与幂等性的工程约束。

7. Basecamp · Shape Up / Set Boundaries ↗

   先确定投入边界，再塑造方案；固定时间、调整范围。

8. Designing Data-Intensive Applications · 官方书籍网站 ↗

   数据系统的可靠性、可扩展性与设计取舍。

9. Don Norman · The Design of Everyday Things ↗

   概念模型、映射、反馈、约束与人本设计。

本文件正文与交互不依赖网络。打开外部参考资料需要联网；这里不嵌入远程字体、追踪脚本或第三方资源。

选你最熟悉的系统，只拿一个任务练手。以 API 网关为例：用户提交一次调用，上游响应丢失，用户想知道现在是否可以重试。

练完以后，用三个问题检查自己

抽象是否更清楚？我能否说明哪些应该统一，哪些必须区分。
取舍是否有依据？我能否解释为什么不做某件事。
验证是否真实？我能否指出哪个结论来自运行或观察，哪个仍只是一个假设。

AI 可以加快提出方案、寻找反例和实现验证的过程。但你要保留对价值与取舍的判断。每一次具体的观察、一次失败的推演、一次被证据推翻的决定，都会成为下一次更好设计的材料。