Metadata

name: jackson-concept-design
description: Models or reviews requirements as Jackson concepts defined by Purpose, OP, State, and Actions, then composes them with Syncs. Use this skill whenever the user asks to discuss requirements, review a concept model, or mentions 概念设计 / 概念建模; stop at model confirmation without producing PRD or code.

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：运行中为支持行为必须记住的事实，不是领域知识或数据库设计。记法用 Alloy 风格关系式（password: U -> String；课程 SSF 散文式等价）。User、Item 等实体通常只是类型参数或身份类型，不是顶层模块。
Actions：用户或系统执行的抽象行为，读取或改变 state；签名写 动作 (入参: 类型) : (出参: 类型) 加 requires/ensures，按输出模式拆 case——错误是独立的输出 case（: (error: String)），供错误 sync 匹配；不拆成界面步骤。
Queries（_ 前缀）：只读、不改 state 的查询（_getUser (session) : (user)），是常用读取模式的速记，专供 sync 的 where 段；不是 action。

设计循环

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

找需要：明确受益者、misfit、现有做法、期望结果与约束；把"要什么"追问成"为什么"。暂不讨论页面、数据库和服务。
识别候选：从具体场景自下而上找细粒度目的，优先熟悉、可复用的概念；不从名词表、实体、页面或团队边界映射。边界不明先保留备选。
逐个刻画：写 Name、Purpose、具体 OP，由 OP 推导 actions 和最小 state；删除行为不需要的 state，补齐必要 action，成立后参数化上下文对象。
批评边界：对每个候选过一遍资格判据与四词（见下节），结论只用：保留、拆分、合并、参数化、降级为 type/action/implementation、移至 sync、待确认。
组合再设计（记法与规则见「组合：Sync」）：
- 选入 concepts 并以类型参数实例化（include Session [User.User]）；
- 写 syncs 表达跨概念行为与应用入口；
- 核查未被 sync 提及的动作——它们不在应用中出现，须是有意排除；
- 按欠同步、过同步与 synergy 检视组合质量；
- 画依赖图、枚举子集，圈定 MVP 与讲解、开发顺序。
调整用三对 design moves：split/merge（控制力 vs 简单）、unify/specialize（通用 vs 贴合）、tighten/loosen（自动化 vs 灵活）。

判据

资格——候选是否够格成为 concept：

用户可感（User-facing）：用户能体验其功能；API 中程序员也是用户。
语义性（Semantic）：表达抽象意义，不是控件、样式或技术机制。
行为性（Behavioral）：有动态行为，不只是分类与属性。
目的性（Purposive）：独立带来真实、可评价的价值。
端到端（End-to-end）：从动作延伸到兑现目的的结果。

第六条资格——独立性——与四词中的独立是同一判据，见下。

四词——批评边界与输出判断统一用这四个词：

专一（Specificity）：只承担一个不可分的目的；多目的即 conflation，拆分。
完整（Completeness）：含兑现目的所需的全部功能；只有片段即 fragmentation，合并或补齐。
独立（Independence）：无需引用其他 concept 即可理解；共享对象用类型参数抽象，如 Comment<Target> 而非 Comment<Post>。
熟悉（Familiarity）：优先沿用已知概念并保持惯例；新概念须提供熟悉概念或其组合给不了的价值。

组合后再查：

复用（Reusability）：通常是四词达标的结果，不是充分条件。
一致（Integrity）：同一 concept 各处保持名称、目的与行为，组合不改变其含义。

常见误判速查

名称只是线索：Trash、Password、Reservation 因 purpose 与 behavior 成为 concepts。

候选	通常归属	另立 concept 的条件
User、Order 等实体	state 中的类型/身份	自身有独立目的和完整动态行为
表、类、微服务、页面、控件	实现或表达层	实现结构恰好承载一个完整 concept 时才可能对应；界面元素不成为 concept
register、save 等	单个 action	自身兑现独立目的时重新判断
故事、用例、feature、workflow	场景/流程切片	独立、端到端服务恰好一个目的且有自己的状态机
跨概念触发规则	sync	自有目的、状态和完整行为

组合：Sync

Sync 是概念之外的独立组合层：按因果规则，某些动作发生后引发另一些动作。Concept 规范不点名其他 concepts；组合只写在组合层（app 级的 syncs）。现行记法是 when / where / then 三段式（Beyond Objects，2026；示例改写自 Jackson 的 ExpiringUserSession）：

app ExpiringUserSession
  include User
  include Session [User.User]
  include ExpiringResource [Session.Session]

  sync login
    when Requesting.login (name, pass)
    where User._authenticate (name, pass) : (user)
    then Session.start (user), ExpiringResource.allocate (session, 300)

  sync loginFailed
    when Requesting.login (name, pass)
    where User._authenticate (name, pass) : (error)
    then Requesting.respond (error)

  sync terminate
    when ExpiringResource.expire (resource)
    then Session.end (resource)

语义规则（因果规则，现行版）：

when 匹配已完成的动作（completion）及其输出；参数全部具名，允许只匹配子集。
where 经 queries 读取概念状态并绑定变量；绑定不成立则本条 sync 不触发。
then 触发新的动作调用（invocation）；绑定变量跨段传递，sync 同时是数据流。
外部请求也是动作：端点、定时器等外部入口具体化为 Requesting 伪概念的动作，由 sync 接力，响应同样由 sync 产生；应用动作 = 由 Requesting 触发的 sync。
错误即输出：动作失败输出 (error: …) 这个普通的可匹配 case，由错误 sync 响应或补偿，不需要事务语义。
行为保持：sync 只能调用概念已声明的动作、只能经 queries 读状态，不能使概念做出孤立时不可能的行为；组合因此不破坏一致（Integrity）。
旧版语义已废弃：书（2021）的 CSP 对称约束与"全有或全无"事务语义被作者本人放弃——"designers find this approach hard to understand … hard to implement, since it requires transactions"（Beyond Objects）。存量模型的旧记法按本节改写。
未被任何 sync 提及的概念动作不在应用中出现；排除是设计决策（Yellkey 不开放 renew），记入排除与未决表。
实现层由 mediator 或规则引擎落地 sync：组合层引用概念，概念之间零相互引用。

模式与信号：

Placeholder 动作：为同步而设计的概念提供占位动作，钉到其他概念的真实动作上——访问控制的 access、订阅的 notify。
欠同步：漏掉的自动化（Zoom 举手不随发言结束自动放下）→ tighten。
过同步：自动化抢走用户控制（日历删除事件即向邀请人发拒绝）→ loosen 或做成可配置。
分解线索：表面单概念、目的冲突，常是多概念同步（Facebook Like ≈ Upvote、Reaction 等的 sync）；回循环第 4 步拆分。
Flow：打穿概念的业务流程 = 一个外部请求触发、多条细粒度 sync 接力的动作链；流程本身不是另立概念的理由，升格判据见速查表末行（自有目的、状态和完整行为）。
Synergy：一个概念借另一概念实现自身功能，整体大于部分之和（Trash 做成 Folder，移动动作免费获得还原）；强求则反噬（Outlook 把系统日志装进邮件文件夹）。

依赖图与子集

Intrinsic dependency：concept 定义引用另一 concept——必须消除（参数化或移至 sync）。
Extrinsic dependency：在具体应用中，没有 C2 则纳入 C1 没有意义（Comment 依赖 Post）；可以存在，但不写进 C1 的定义。

以 extrinsic 依赖画图（Parnas 的 uses relation）：节点为概念，边 C1 → C2 表示含 C1 的版本必须含 C2。Parnas 规则：不能没有 B 就用 A，就永远不该想没有 B 用 A。

依赖图的产出：

产品家族：每个"不缺依赖"的概念子集是一个可行产品；用它圈定 MVP 与版本演进。
顺序：讲解与开发都先做被依赖者（先 Post 后 Comment）。

输出格式

每概念四节 + 可选 notes，除 notes 外零点名其他概念；确认后可经 jackson-concept-prd 原样落为与代码共存的 CONCEPT.md（与 wyx 架构护栏兼容）。

## 需求与 Misfits
- 用户 / 需要 / 问题 / 结果 / 约束

## Concepts

```text
concept <Name> [<TypeParam>]

## purpose
[恰好一个：为何存在、给谁什么价值]

## state
- <字段>: <TypeParam> -> <类型>

## actions
<动作> (<入参: 类型>) : (<出参: 类型>)
  requires [前置] ensures [效果]
<动作> (<入参: 类型>) : (error: String)
  [错误 case 单列，供错误 sync 匹配]
_<查询> (<入参>) : (<出参>)
  [只读；供 where 段]

## operational principle
after <动作> (<参数>) : (<结果>)
then <动作> (<参数>) : (<结果>)
[可多条场景，每条以兑现 purpose 收尾]

## notes
[可选。使用上下文备注的唯一落点（应用角色、类型参数实例化）；
不设 interactions / dependencies 段——跨概念信息属于 syncs 与依赖图]
```

- 判断: 专一 / 完整 / 独立 / 熟悉（每概念附结论）

## Synchronizations
```text
app <应用名>
  include <Concept> [<Type>]

  sync <名>
    when <Concept.action (参数)>
    where <Concept._query (参数) : (绑定)>
    then <Concept.action (参数)>    // 每条 sync 注明组合理由/风险
```

## 依赖图与子集
- 依赖: C1 -> C2, ...（extrinsic，只在此处；不写进概念规格）
- 子集: {MVP: ...} / {扩展: ...}

## 排除与未决
| 候选/问题 | 结论 | 理由/取舍 |

完成条件

每个 concept 恰好一个 purpose，OP 以兑现该 purpose 的结局收尾。
每个 concept 的四词判断均有结论，结论词出自设计循环第 4 步词表。
State 与 actions 完整规定行为（queries 只读不改 state），无界面、协议或表结构细节。
概念规格只含 purpose / state / actions / operational principle（可选 notes）；除 notes 外零点名其他概念，无 interactions / dependencies 段；跨概念行为全部落在 sync 块，且每条满足行为保持。
Sync 用 when / where / then 记法；每个可失败动作的 error case 有错误 sync 处理，或有意不处理并记入排除与未决表。
未被 sync 提及的动作均为有意排除；欠同步、过同步已按 tighten/loosen 检视。
依赖图画出且无违反 Parnas 规则处；MVP 子集从图中圈定。
被否决的候选与待决取舍全部进入排除与未决表，无空悬项。

依据

核验只用作者原文：

Beyond Objects（2026：现行规格五要素 + queries、when/where/then 因果语义、废弃书版事务语义）
WYSIWID 论文（规格四节无跨概念段、错误作为可匹配输出、规格即实现 prompt）
官方教程（含资格判据、 Sync 组合、依赖与子集）
概念设计综述（概念独立性原句 "Each concept is defined without reference to any other concepts"）
Design moves
6.1040 概念评分标准（使用上下文引用仅限 notes 段）

引用时区分原句、忠实转述与本技能的操作性综合。

Jackson Concept Design

安装技能