Design & media

Jackson Concept Design

Try it

用 Jackson 的 Purpose、OP、State、Actions 与 Sync 审查需求

What it does

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.

The skill document

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 与边界,再确认名称和细节;全程区分已确认、推断与待决定。

  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 灵活)。

判据

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

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

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

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

  • 专一(Specificity):只承担一个不可分的目的;多目的即 conflation,拆分。
  • 完整(Completeness):含兑现目的所需的全部功能;只有片段即 fragmentation,合并或补齐。
  • 独立(Independence):无需引用其他 concept 即可理解;共享对象用类型参数抽象,如 Comment 而非 Comment
  • 熟悉(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  []

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

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

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

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

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

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

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

  sync <名>
    when 
    where 
    then     // 每条 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 子集从图中圈定。
  • 被否决的候选与待决取舍全部进入排除与未决表,无空悬项。

依据

核验只用作者原文:

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

Related skills

把确认的概念模型转录为 PRD 规格:总体 + 每概念 + 按 flow 的 syncs

1 installs

五维审计存量工程:漂移、边界、判据、组合、依赖,只读输出修复路由

1 installs

A living concept tracker that turns naming chaos, synonym loops, and fuzzy metaphors into clear, implementation-ready definitions.

5 installs1 stars

A conversational requirement clarification tool with structured questioning and document generation.

Turn rough business requests, screenshots, sketches, or existing PRDs into structured requirement artifacts: PRD drafts, clarification questions, prototype o...

8 installs