Jackson 概念设计

Jackson 概念设计

把需求转成可理解、可评价、可组合的概念模型。停在模型确认；除非用户明确要求，不生成 PRD、架构或代码。本文是按 Jackson 的结构、判据与设计动作整理的操作循环，不冒充作者原文流程。模型确认后：文档化为 PRD 规格用伴生技能 jackson-concept-prd，代码落地用 jackson-concept-implementation，存量审计用 jackson-concept-audit。

核心模型

Concept 同时是用户为有效使用软件而掌握的心理构造，和与之对应的连贯功能单元。应用由独立 concepts 组成，由 synchronizations（syncs）联结成应用行为；界面和术语表达概念，代码实现概念，但都不是概念本身。

Concept = Name + Purpose + Operational Principle + State + Actions

• Name：简短易记，唤起正确、熟悉的心理模型。
• Purpose：为何存在、给谁什么价值；need-focused、specific、evaluable，且恰好一个。
• Operational Principle（OP）：少量端到端典型故事，展示如何使用并兑现 purpose。写法：
  • 历史要足够长，结尾兑现 purpose——注册本身无价值，随后认证才展示 Password 的目的；
  • 一次只解释一个 concept，写 actions 与结果，不写界面、协议或表结构；
  • 先用当前场景的具体对象写以检验价值，成立后再改写为多态通用版本；
  • OP 解释本质，不替代规范：行为由 state machine（state + actions）完整规定。
• State：运行中为支持行为必须记住的事实，不是领域知识或数据库设计。User、Item 等实体通常只是这里的身份类型或多态参数，不是顶层模块。
• Actions：用户或系统执行的抽象行为，读取或改变 state；定义条件、输入、输出与效果，不拆成界面步骤。

设计循环

重复 1–5 直到 misfits 消失。先确认 purpose 与边界，再确认名称和细节；全程区分已确认、推断与待决定。

1. 找需要：明确受益者、misfit、现有做法、期望结果与约束；把"要什么"追问成"为什么"。暂不讨论页面、数据库和服务。

2. 识别候选：从具体场景自下而上找细粒度目的，优先熟悉、可复用的概念；不从名词表、实体、页面或团队边界映射。边界不明先保留备选。

3. 逐个刻画：写 Name、Purpose、具体 OP，由 OP 推导 actions 和最小 state；删除行为不需要的 state，补齐必要 action，成立后参数化上下文对象。

4. 批评边界：对每个候选过一遍资格判据与四词（见下节），结论只用：保留、拆分、合并、参数化、降级为 type/action/implementation、移至 sync、待确认。

5. 组合再设计（记法与规则见「组合：Sync」）：

   • 选入 concepts 并以类型参数实例化（include Session [User.User]）；
   • 写 syncs 表达跨概念行为与应用入口；
   • 核查未被 sync 提及的动作——它们不在应用中出现，须是有意排除；
   • 按欠同步、过同步与 synergy 检视组合质量；
   • 画依赖图、枚举子集，圈定 MVP 与讲解、开发顺序。

   调整用三对 design moves：split/merge（控制力 vs 简单）、unify/specialize（通用 vs 贴合）、tighten/loosen（自动化 vs 灵活）。

判据