笔记 G：从微观组件到人机交互的艺术
[Chief Architect's Note]： 细节决定成败：微观组件代码的“死板逻辑”构成了系统不崩塌的坚实骨架，而人机交互的“包容艺术”则赋予了系统直觉般的灵魂。两者若不能统一，系统要么是一堆无法使用的极客玩具，要么是一个外表华丽但内部时刻准备爆炸的定时炸弹。
模块一：组件级设计 (Component-Level Design) —— 将架构落地为逻辑
组件级设计是连接高层架构与底层代码的桥梁，它的目标是将架构模型转化为可操作的软件细节。
- 逐步求精 (Stepwise Refinement)：这是一种自顶向下的设计策略。我们从一个宏观的、高抽象级别的功能声明开始，通过连续的迭代，一步步将其细化（Elaboration）为底层的程序细节。
- 逻辑表示法：在细化到最后一步时，我们不能直接写代码，而是要使用UML活动图 (Activity Diagram) 或 伪代码 (Pseudocode) 来表示控制流和数据结构。这有助于在编码前暴露出逻辑缺陷。
模块二：设计原则 —— SOLID 与可重用性
在面向对象系统中，仅仅把代码拆开是不够的。Pressman 在书中特别强调了以下几项核心设计原则，它们是降低组件复杂度、提升可重用性的金科玉律：
- 开闭原则 (Open-Closed Principle, OCP)：“模块应对扩展开放，对修改关闭”。这意味着你应该通过抽象（如接口）来缓冲可能的变化，添加新功能时不应去修改原有的核心逻辑。
- 里氏替换原则 (Liskov Substitution Principle, LSP)：子类必须能够替换其基类。这本质上要求遵循契约 (Contract)：任何组件都必须满足基类隐含的“前置条件 (Precondition)”和“后置条件 (Postcondition)”。
- 依赖倒置原则 (Dependency Inversion Principle, DIP)：依赖于抽象，而不是具体实现。代码是最终极的“具体”，过早陷入具体代码的依赖，会让系统牵一发而动全身。
模块三：用户界面设计 (UI Design) 的三大黄金法则
如果说组件设计是为了让机器“好受”，那 UI 设计就是为了让用户“好受”。Theo Mandel 提出了交互设计的三大黄金法则：
- 置用户于控制地位 (Place the User in Control)：不要用僵化的流程绑架用户。提供灵活的交互方式，允许操作被中断 (Interruptible) 和撤销 (Undoable)，并隐藏底层的技术细节，让用户感觉自己是在直接操纵对象。
- 减少用户的记忆负荷 (Reduce the User's Memory Load)：人类的短期记忆非常有限。系统应提供视觉线索而不是要求用户回忆，建立有意义的默认值，使用基于现实世界的隐喻 (Metaphor)，并以渐进式 (Progressive fashion) 的方式披露复杂信息。
- 保持界面一致性 (Make the Interface Consistent)：在整个应用或产品线中，维持视觉逻辑、输入机制和导航方式的绝对一致，让用户建立可靠的肌肉记忆。
模块四：交互设计 (HCI) 过程 —— 研究、分析、设计与评估的闭环
好的体验不是天才的灵光一现，而是严谨工程过程的产物。
- 用户分析 (User Analysis)：创建用户画像 (Personas) 和客户旅程地图，深刻理解目标用户的心理模型 (Mental Model) 和物理工作环境。
- 任务分析 (Task Analysis)：将用户故事转化为用例，并使用逐步求精的方法将宏观任务分解为一系列微观操作步骤。
- 设计与构造 (Design & Construction)：定义界面对象和操作，创建线框图和低保真原型。
- 评估验证 (Evaluation)：让用户“试驾”原型，通过非正式反馈或严格的可用性测试 (Usability Testing) 收集数据，推动下一次迭代。
架构师的深度思考维度
[Engineering Mindset] (工程权衡逻辑)
- “逻辑复杂度”与“可维护性”的博弈：我们花大量时间做“逐步求精”和应用“SOLID 原则”，短期看是在增加设计时间，但这是为了将高耦合的“复杂度”拆解为多个低耦合的单一体。如果不这么做，技术债务将导致代码变为一座不可触碰的纸牌塔。
- “功能强大”与“界面简洁”的矛盾：强大的功能往往意味着满屏幕的控件。我们通过应用黄金法则中的“渐进式披露 (Progressive Disclosure)”和“一致性原则”，在不削减功能的前提下，通过隐藏次要路径来换取界面的极简与优雅。
[AI-Era Mapping] (AI 时代的演进与实战)
- 用“契约式设计”钳制 AI 幻觉：当使用 Cursor 生成底层组件时，大模型极易在边界条件（Edge cases）上“自由发挥”甚至产生幻觉。利用 LSP 原则中的契约式设计 (Design by Contract) 思想，我们可以在 Prompt 中死死钉住“前置条件 (Preconditions)”和“后置条件 (Postconditions)”。只要 AI 生成的代码违背了输入/输出的契约，Cursor 就会在运行测试时瞬间报错，从而通过物理护栏锁死 AI。
- 用“UI 黄金法则”缓解“AI 焦虑”：在开发基于大模型的 Agent 时，用户最大的痛点是“不可控的黑盒恐惧”。此时，“置用户于控制地位” 尤为关键：必须为 Agent 设计“中断”和“撤销”按钮；“减少记忆负荷” 要求 Agent 必须在对话流中保持上下文的可见性（如显示当前引用的文档）；同时，Agent 的思考过程（如 Chain of Thought）必须以 “一致的隐喻”（如加载进度条或骨架屏）展示，让用户随时掌控当前状态。
[Memory Trigger] (记忆触发器)
- 比喻：“高端机械腕表”。组件级设计（Component Design）是手表的机芯，几百个齿轮（模块）高内聚、低耦合地咬合，遵循着严密的机械契约（SOLID 原则）；而用户界面设计（UI Design）是表盘和表冠，用户不需要知道陀飞轮怎么转（隐藏技术细节），只需要直观地看到时间（减少记忆负荷），并且转动表冠时的阻尼感永远精准如一（界面一致性）。
特别模块：Cursor 逻辑颗粒度与组件重构指令
# [Cursor Refactoring Prompt]: The Architect's Scalpel
**Target Component**: `ComplexOrderProcessor.ts`
**Role**: 精通 SOLID 原则和“逐步求精 (Stepwise Refinement)”的首席底层架构师。
**Context**:
当前的 `processOrder` 函数过于庞大，违反了开闭原则 (OCP)，且逻辑颗粒度太粗。我需要你按照以下架构步骤对其进行重构。
**Task Constraints**:
1. **[Stepwise Refinement]**: 首先，不要直接写实现代码！请向我输出该函数的“伪代码流程图”或“活动步骤列表”，将大逻辑分解为 4-5 个高抽象级别的子步骤。
2. **[Interface Segregation & DIP]**: 为每一个子步骤定义一个独立的接口 (Interface)。确保核心逻辑依赖于这些接口，而不是具体的外部服务（如具体的数据库类或第三方支付 API）。
3. **[Design by Contract]**: 为你拆分出的每一个子组件，在注释中明确写出它的契约：
- `@Precondition` (执行前必须满足的状态)
- `@Postcondition` (执行后保证的结果)
- `@Throws` (明确定义的异常边界)
**Action**: 请先输出步骤 1 的设计规划。待我 review (审查) 同意后，再进行具体的代码拆分与生成。
架构师寄语：通过这套指令，你不是在让 AI 盲目地“写代码”，而是在逼迫它像一个真正的工程师一样“做设计”。控制住逻辑的颗粒度，你就控制住了 AI 的灵魂。