jackson-concept-designlisted

# Jackson 概念设计 把需求转成可理解、可评价、可组合的概念模型。停在模型确认；除非用户明确要求，不生成 PRD、架构或代码。本文是按 Jackson 的结构、判据与设计动作整理的操作循环，不冒充作者原文流程。模型确认后：文档化为 PRD 规格用伴生技能 `jackson-concept-prd`，代码落地用 `jackson-concept-implementation`，存量审计用 `jackson-concept-audit`。 ## 核心模型 Concept 同时是用户为有效使用软件而掌握的**心理构造**，和与之对应的**连贯功能单元**。应用由独立 concepts 组成，由 synchronizations（syncs）联结成应用行为；界面和术语表达概念，代码实现概念，但都不是概念本身。 ```text 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 提及的动作——它