将一篇或多篇学术论文,通过"教学法约束推理"转化为有理论根基的产品设计产物。 核心是构建"学术机制 → 约束交互 → 可解释推理链"的中间层, 再导出多种格式的设计产物。 本skill是一个 Pedagogical Grounding Engine(教学法落地引擎): 它不是论文摘要工具,而是把教学法意图(pedagogical intent)编译为 可执行的系统设计结构。PRD、System Prompt、Workflow 都是下游导出格式, 核心产物是 Traceability Map——每个设计决策都有明确的教学依据、 认知机制和可追溯的设计理由。 当用户有以下意图时触发本skill: - "把这篇/这几篇论文做成产品/app/提示词/工作流" - "paper to PRD / paper to prompt / paper to product" - "pedagogical grounding / 教学法落地" - "我想基于学习科学设计这个功能/系统提示词" - "从论文提取知识图谱/三元组/TPACK分析" - "我有几篇论文,帮我提炼成一个设计方案" - "...
Scanned 5/27/2026
Install via CLI
openskills install edu-ai-builders/pedagogical-grounding-engine---
name: pedagogical-grounding-engine
description: >
将一篇或多篇学术论文,通过"教学法约束推理"转化为有理论根基的产品设计产物。
核心是构建"学术机制 → 约束交互 → 可解释推理链"的中间层,
再导出多种格式的设计产物。
本skill是一个 Pedagogical Grounding Engine(教学法落地引擎):
它不是论文摘要工具,而是把教学法意图(pedagogical intent)编译为
可执行的系统设计结构。PRD、System Prompt、Workflow 都是下游导出格式,
核心产物是 Traceability Map——每个设计决策都有明确的教学依据、
认知机制和可追溯的设计理由。
当用户有以下意图时触发本skill:
- "把这篇/这几篇论文做成产品/app/提示词/工作流"
- "paper to PRD / paper to prompt / paper to product"
- "pedagogical grounding / 教学法落地"
- "我想基于学习科学设计这个功能/系统提示词"
- "从论文提取知识图谱/三元组/TPACK分析"
- "我有几篇论文,帮我提炼成一个设计方案"
- "帮我把教学法嵌入到产品/提示词中"
- "生成 traceability 图" / "把这篇论文可视化"
- "我有一个教学场景/教育想法,帮我设计成系统"(不一定有论文)
支持 Commands 模式:流水线跑完之后,用户可以随时用 /命令 召唤特定输出,
无需重跑流水线。命令列表见 ## Commands 章节。
---
# Pedagogical Grounding Engine
## 核心定位
> **把教学法意图(pedagogical intent)编译为可执行的系统设计结构。**
这个 skill 是一个编译器(compiler),不是摘要工具,不是 feature 生成器。
它有四个核心职责,按执行顺序排列:
| 职责 | 做什么 | 对应流水线层 |
|---|---|---|
| **Extract(抽取)** | 从论文/场景中识别学习目标、认知挑战、隐含的教学法、关键构念 | 第1-2层 |
| **Ground(落地)** | 把抽象理论转化为:认知动作(对比/分解/模拟)、知识结构(图/序列/层级)、学习流程 | 第3层 |
| **Map(映射)** | 把落地后的认知结构映射到:图 Schema、UI 组件、功能模块、系统行为 | 第4层 |
| **Justify(溯源)** | 为每个设计决策输出:为什么存在、链接到哪条理论、去掉会损失什么 | 第4-5层 |
**产物优先级**:Traceability Map(核心产物)→ System Prompt → PRD → Workflow
PRD 是下游导出格式,不是目的本身。
**输入不限于论文**:可以是论文文本、教学场景描述、用户痛点、或研究者的想法。
有论文时,论文提供理论依据;没有论文时,场景本身是出发点,系统帮助找到认知科学依据。
---
## 六层架构:四职责 × 五层流水线
四个职责是**内部推理逻辑**,五层是**执行内容**。两者不是平行关系,而是嵌套关系:
```
职责维度(Why & How) 执行维度(What)
──────────────────────────────────────────────────────────────
输入:论文(1篇或多篇)+ 场景描述
[也可以只有场景描述,没有论文]
│
┌─ EXTRACT ─────────────────┐ ▼
│ 识别:学习目标 │ [第1层] Core KG
│ 认知挑战 │ ──────────────────────────────
│ 关键构念 │ 阶段1-3:论文类型判断 + 元数据 + 构念识别
│ 隐含教学法 │ 阶段4:三元组提取(研究表征)
└───────────────────────────┘ 阶段4b:Representation Translation ← 跨语境迁移
│ · 研究语境 → 执行语境的 translation & transformation
│ · 不是填字段,是重构表征语言
│ · 显式化 translation_tension(边界条件变化)
│ · 输出:cognitive_mechanism / activation_condition /
│ failure_signature / execution_form
│ · 冲突 triple 输出双迁移路径,不裁决
阶段5:多篇合并(冲突保留,迁移后 triple 参与合并)
│
┌─ EXTRACT (cont.) ─────────┐ ▼
│ 识别:场景约束 │ [第2层] Context KG
│ 用户特征 │ ──────────────────────────────
│ 情境限制 │ 从场景描述提取:
│ 成功标准 │ · 六维度结构化约束
└───────────────────────────┘ · 每条约束标注 H/M/L + Must/Tradeoff/Nice
· 内部冲突预警
│
┌─ GROUND ──────────────────┐ ▼
│ 转化:抽象理论 │ [第3层] KG 融合 + Constraint Layer
│ → 认知动作 │ ──────────────────────────────
│ → 知识结构 │ · 消费已迁移的 triple:
│ → 学习流程 │ activation_condition → 直接对应检测
│ │ failure_signature → 设计张力/障碍识别线索
│ ← 这是核心壁垒 │ · 约束节点提取 + 约束间关系 + Resolution
└───────────────────────────┘ · 推断节点生成
│
┌─ MAP + JUSTIFY ───────────┐ ▼
│ 映射:认知结构 │ [第4层] Traceability Engine
│ → 图 Schema │ ──────────────────────────────
│ → UI 组件 │ · Pedagogical Grounding Checklist 门控(PG1-PG6)
│ → 功能模块 │ · 每个决策 = constraint-driven 推理链(4步)
│ → 系统行为 │ · 三层输出:Markdown + JSON + Canvas节点
│ │ · 跨决策连接网络
│ 溯源:为什么存在 │ · pg_checklist 字段嵌入 JSON
│ 链接到哪条理论 │
│ 去掉会损失什么 │
└───────────────────────────┘
│
▼
[第5层] 产物导出(Commands 系统)
──────────────────────────────────
产物优先级(反映四职责的输出层次):
· /model → Pedagogical Model(Extract+Ground的宏观产物)
· /trace → Traceability Map(Map+Justify的核心产物)
· /pgcheck → PG Checklist 报告(Justify的验证产物)
· /render → Canvas 可视化
· /prompt → System Prompt
· /prd → PRD + TASKS + DESIGN
· /workflow → Workflow 步骤
· /kg → KG 原始图数据
· /why → 单功能溯源
· /diff → 多论文对比
· /export → 全部产物
```
**关键原则**:PRD 是第8个命令,不是第1个。`/model` 和 `/trace` 在前,
因为产物的优先级反映的是"这个系统在做什么"——编译教学法,而不是生成产品规格。
---
## 第1层 — Core KG:论文本体知识图谱
### 目的
提取**与场景无关**的、可复用的知识机制。换了场景不会变。
### 多篇论文的三种模式(默认模式3)
| 模式 | 描述 | 适用 |
|---|---|---|
| 模式1 | 分别提取,用户手动指定哪些构念进入合并 | 用户对论文非常熟悉 |
| 模式2 | 自动合并,冲突标注后**暂停**等用户裁决 | 中等熟悉度,想参与决策 |
| **模式3(默认)** | 分别提取,自动合并,冲突**保留不裁决** | 快速推进,让张力在推理层浮现 |
合并规则(模式3):
- **互补节点** → 直接合并,保留双方来源标注 `[论文A]` `[论文B]`
- **同义节点** → 合并,标注 `[合并自A+B]`
- **冲突节点** → 双方保留,标注 `[冲突: A主张X, B主张Y]`,**不裁决,留给第3层**
### 每篇论文提取内容
**元数据(小表):**
| 字段 | 内容 |
|---|---|
| 标题 | |
| 研究类型 | 方法论 / 实验+原型 / 技术方案 / **元分析→停止该篇** |
| 核心机制 | 1-2句话 |
| 目标人群 | |
**Core KG 三元组(至少20条/篇):**
格式:`**主体** → 谓词 → **客体** [来源]`
覆盖:陈述性≥7 / 程序性≥8 / 产品implied≥5(标 `[F]`)
谓词统一使用词汇表(见 `references/kg-vocabulary.md`)。
**输出格式:**
```
## Core KG — [论文简称]
核心构念:...
三元组:(编号列表)
## Core KG — 合并结果(多篇时)
互补 / 同义 / 冲突节点各自列出
```
✅ 第1层完成:[每篇X条,合并后Y条,冲突Z个]
---
## 第2层 — Context KG:场景约束图谱
### 目的
将"在什么情境下用"转化为结构化约束节点。与论文内容无关。
### 场景输入(预设模板 + 自由描述双轨)
用户可以自由描述,也可以直接填模板,模型自动映射到六维度。
**六维度必须全部覆盖**,缺少任何一维主动追问:
```
目标用户:(谁在用?年龄/角色/技术水平/学习背景)
学习情境:(课堂/在线/异步/混合/研讨/自学)
核心痛点:(现在最大的问题是什么?)
成功标准:(什么叫"这个产品有效"?)
约束条件:(技术限制/时间/资源/平台)
已有设计假设:(如果有的话)
```
### Context KG 三元组(10-15条)
每个节点同时标注**优先级**(High/Medium/Low)和**可牺牲性**(Must/Tradeoff/Nice):
```
格式:**[节点]** → 谓词 → **[节点]** [优先级: H/M/L] [可牺牲: Must/Tradeoff/Nice]
示例:**沉默型学生** → 需要 → **低压力入场机制** [H] [Must]
**移动端兼容** → 要求 → **响应式设计** [L] [Nice]
```
这两个标注是 Constraint Layer 做权衡分析的输入依据。
✅ 第2层完成:[X条约束节点,六维度覆盖]
---
## 第3层 — KG 融合 + Constraint Layer
这是整个流水线的**约束显式化层**。它同时做两件事:
1. 识别 Core KG 和 Context KG 的对齐/张力/障碍(融合操作)
2. 把隐含的约束关系**提取出来并命名**(Constraint Layer)
---
### 3a. KG 融合操作(四种)
**操作1:直接对应**
`[论文机制A] ←直接对应→ [场景需求X]`
**操作2:间接激活(生成推断节点)**
`[论文机制B] ←间接激活(需要中间设计M)→ [场景需求Y]`
生成推断节点 M,标注 `[推断] ← 由 [CoreKG节点] + [ContextKG节点] 推导`
**操作3:设计张力**
`[张力: A机制 vs B机制,场景约束C使选择更复杂]`
不裁决,带入 Constraint Layer 处理。
**操作4:实现障碍**
`[障碍: 论文机制C 受限于 场景约束Z]`
必须在 Constraint Layer 给出 Resolution。
---
### 3b. Constraint Layer(🔥新增核心)
> **目的:把"解释结果"升级为"约束驱动结果"——解释为什么不是别的feature。**
#### Constraint 节点提取
从 Core KG 冲突节点 + Context KG 约束节点 + 融合操作结果中,提取出**命名的约束**:
```json
{
"id": "constraint_001",
"type": "pedagogical | technical | contextual",
"source": "论文A / 场景 / 推断",
"claim": "等距发言权对协作学习是必要的",
"priority": "High",
"negotiable": false
}
```
约束类型:
- `pedagogical`:来自论文的教学法主张(不可随意放弃)
- `technical`:来自场景的技术限制(有时可以降级)
- `contextual`:来自用户/情境的需求(有优先级,部分可牺牲)
#### 约束间关系(🔥关键)
这是让系统从"解释结果"变成"解释为什么不是别的结果"的核心结构:
```json
{
"constraint_a": "constraint_001(等距发言权)",
"constraint_b": "constraint_002(低认知负荷)",
"relationship": "conflict | tradeoff | amplify | independent",
"description": "实时显示所有人发言比例会增加界面认知负荷,
但不显示则无法支持公平参与目标",
"resolution": {
"decision": "用极简点状仪表盘而非数字表格",
"rationale": "在保留公平参与可见性的前提下,最小化界面复杂度",
"sacrifice": "牺牲精确数值,保留方向性感知",
"resulting_decision_id": "decision_001"
}
}
```
关系类型:
- `conflict`:两个约束直接矛盾,必须做出取舍
- `tradeoff`:两个约束可以同时部分满足,但有张力
- `amplify`:两个约束相互强化,合力指向同一设计方向
- `independent`:两个约束互不影响,可以独立处理
**Resolution 是 Traceability 节点的前置输入**:每个有 Resolution 的约束关系,直接对应第4层的一个设计决策。
#### 输出格式
```
## Constraint Layer
约束节点(N个):
[编号列表,含type/priority/negotiable]
约束间关系(M组):
1. [constraint_A] ← conflict → [constraint_B]
解析:[description]
Resolution → [resulting_decision简称]
2. [constraint_A] ← amplify → [constraint_C]
合力指向:[design direction]
```
✅ 第3层完成:[对齐N / 张力N / 障碍N / 约束节点N / 约束关系M(冲突X/权衡Y/强化Z)]
---
## 第4层 — Traceability Engine:核心推理层
### 层定位:Map + Justify
这一层实现两个核心职责:
- **Map**:把第3层的约束 Resolution 映射为具体的认知结构 → 系统行为
- **Justify**:为每个设计决策生成完整的溯源链(理论依据 + 认知机制 + 去掉会损失什么)
### ⛩ Pedagogical Grounding Checklist(门控,每个 P0 决策必须通过)
在生成任何 P0 Traceability 节点之前,逐项检查:
| # | 检查项 | 通过标准 | 数据来源 | 失败处理 |
|---|---|---|---|---|
| PG1 | **学习目标明确** | 这个设计决策服务于一个可陈述的学习目标 | Context KG 成功标准节点 | 降级为 P1,标注`[学习目标未明确]` |
| PG2 | **认知挑战识别** | 识别了用户在这个环节会遭遇的认知困难 | **Enriched triple 的 `learner_precondition` + `likely_failure_mode`** | 补充认知困难分析,或降级 |
| PG3 | **认知动作定义** | 设计触发的是哪种认知动作(从词汇表选择)| Core KG mechanism 字段 | 必须从词汇表中选择,不允许模糊描述 |
| PG4 | **信息结构合理** | 信息以适合该认知动作的结构呈现 | Enriched triple 的 `implementation_form` | 结构与认知动作必须匹配 |
| PG5 | **教学策略命名** | 能说出这个设计体现了哪种教学策略 | tpack-guide.md | 不能用"辅助学习"这类模糊词 |
| PG6 | **Traceability 完整** | 能回答"去掉这个设计,学习过程会损失什么" | **Enriched triple 的 `observable_indicator` 和 `likely_failure_mode`** | 这个问题答不出来 → 降级 P2 |
**认知动作词汇表**(PG3 必须从此选择):
`对比 / 分解 / 模拟 / 反思 / 检索 / 类比 / 迁移 / 归纳 / 评估 / 构建`
**检查结果处理**:
- 全部通过 → 生成完整 P0 Traceability 节点(含三层输出)
- 1-2项失败 → 降级为 P1,标注失败项,给出补救建议
- 3项以上失败 → 降级为 P2,或标注`[教学依据不足,建议寻找相关论文]`
- **没有 PG Checklist 结果的设计决策不允许成为 P0**
---
### 两个核心机制
### Traceability 节点结构(三层)
**层A:Markdown 可读层**
```
### [设计决策名称](优先级:P0/P1/P2)
**约束来源:**
- 解析自约束关系:[constraint_A] conflict [constraint_B]
- Resolution:[一句话说为什么是这个设计而不是别的]
**Core KG 三元组来源:**
- [具体三元组,含来源论文]
**Context KG 约束节点:**
- [具体约束节点,含优先级/可牺牲性]
**推理链(constraint-driven):**
1. 存在约束冲突:[A主张X,B要求Y,两者在场景Z下矛盾]
2. 约束优先级判断:[哪个不可牺牲,哪个可以降级]
3. Resolution:[具体的取舍决定,以及为什么]
4. 设计实现:[从 Resolution 推导出的具体功能设计]
**教学策略:** [名称](见 references/tpack-guide.md)
**TPACK区域:** [T/P/C/TP/PK/CK/TPK]
**Pedagogical Grounding Checklist:**
- PG1 学习目标:[这个决策服务于什么学习目标]
- PG2 认知挑战:[用户在此环节遭遇的认知困难是什么]
- PG3 认知动作:[对比 / 分解 / 模拟 / 反思 / 检索 / 类比 / 迁移 / 归纳 / 评估 / 构建]
- PG4 信息结构:[图 / 序列 / 层级 / 对比 / 网络]
- PG5 教学策略:[具体策略名称,不允许模糊描述]
- PG6 去掉代价:[去掉这个设计,学习/认知过程会损失什么]
- 通过状态:[✅ 全部通过 / ⚠️ N项失败(降级为P1)]
**产物类型:** [ui_feature / prompt_segment / workflow_step]
**具体内容:** [描述]
**跨决策影响:**
- 本决策影响:[decision_XXX](影响方式:[描述])
- 本决策被影响:[decision_YYY](影响方式:[描述])
**降级方案:**(如存在实现障碍)
- 风险:[描述]
- 降级:[简化实现]
```
**层B:JSON 机器层**
```json
{
"id": "decision_001",
"name": "设计决策名称",
"priority": "P0",
"constraint_resolution": {
"resolved_conflict": ["constraint_001", "constraint_002"],
"resolution_rationale": "为什么是这个方案而不是别的",
"sacrifice": "牺牲了什么"
},
"derived_from": {
"core_kg": ["三元组描述 [来源论文]"],
"context_kg": ["约束节点描述"],
"inferred": ["推断节点(如有)"]
},
"reasoning_chain": [
"约束冲突描述",
"优先级判断",
"Resolution",
"设计实现"
],
"pedagogy": {
"strategy": "教学策略名称",
"tpack_zone": "TPK"
},
"pg_checklist": {
"PG1_learning_objective": "这个决策服务的具体学习目标",
"PG2_cognitive_challenge": "用户在此环节遭遇的认知困难",
"PG3_cognitive_action": "对比 | 分解 | 模拟 | 反思 | 检索 | 类比 | 迁移 | 归纳 | 评估 | 构建",
"PG4_info_structure": "图 | 序列 | 层级 | 对比 | 网络",
"PG5_pedagogy_strategy": "教学策略具体名称",
"PG6_removal_cost": "去掉这个设计,学习/认知过程损失什么",
"passed": true
},
"artifact": {
"type": "ui_feature | prompt_segment | workflow_step",
"content": "具体描述",
"priority": "P0"
},
"cross_decision_edges": [
{
"target": "decision_002",
"direction": "influences",
"description": "参与度仪表盘增加认知负荷,影响Prompt设计的简洁性要求"
}
],
"fallback": {
"risk": "风险描述",
"simplified": "降级方案"
}
}
```
**层C:Canvas 图节点数据**
```json
{
"canvas_nodes": [
{"id": "n_constraint_001", "label": "约束名称", "type": "constraint",
"constraint_type": "pedagogical", "x_hint": 50, "y_hint": 200},
{"id": "n_decision_001", "label": "设计决策名称", "type": "decision",
"tpack_zone": "TPK", "priority": "P0", "x_hint": 700, "y_hint": 200},
{"id": "n_resolution_001", "label": "Resolution简称", "type": "resolution",
"x_hint": 400, "y_hint": 200}
],
"canvas_edges": [
{"from": "n_constraint_001", "to": "n_resolution_001",
"label": "conflict", "type": "constraint_conflict"},
{"from": "n_resolution_001", "to": "n_decision_001",
"label": "drives", "type": "resolution_to_decision"},
{"from": "n_decision_001", "to": "n_decision_002",
"label": "影响认知负荷", "type": "cross_decision"}
]
}
```
### Canvas 全局布局(五列)
```
列1(x≈50-250): Constraint 节点(按类型着色:教学法/技术/情境)
列2(x≈300-400): Resolution 节点(约束解析结果)
列3(x≈500-700): Core KG + Context KG 节点(来源层)
列4(x≈800-1000): Decision 节点(按TPACK着色)
列5(x≈1100+): Artifact 节点(产物层)
特殊边类型:
- constraint_conflict(红色虚线):约束冲突关系
- constraint_amplify(绿色实线):约束强化关系
- resolution_to_decision(紫色实线):Resolution驱动决策
- cross_decision(橙色虚线,双向箭头):决策间影响
```
### TPACK着色(Decision节点)
T:`#93c5fd` P:`#86efac` C:`#fcd34d` TP:`#a5b4fc` PK:`#6ee7b7` CK:`#fda4af` TPK:`#c084fc`
### Constraint类型着色(Constraint节点)
pedagogical:`#fecaca` technical:`#bfdbfe` contextual:`#fef08a`
### 数量要求
- P0:完整三层(Markdown + JSON + Canvas节点数据)
- P1:Markdown + JSON,Canvas简化
- P2:仅 Markdown
**⚠️ 关键约束:没有 constraint_resolution 字段的 P0 决策不允许进入第5层。**
✅ 第4层完成:[P0 X个 / P1 Y个 / P2 Z个,跨决策连接N条,Canvas节点共M个]
---
## 第5层 — 产物导出 + Commands
流水线完成后,**输出 Commands 菜单**,用户可以随时召唤任何产物,无需重跑流水线:
```
✅ 流水线完成。可用命令:
/model — 🆕 Pedagogical Model(学习目标+认知结构+教学法摘要,核心输出)
/trace — 输出完整 Traceability Map(Markdown 汇总表 + Canvas JSON)
/render — 直接渲染 Canvas 可视化(React Flow 组件)
/kg — 输出 KG 图数据(Core KG + Context KG + Constraint Layer 合并)
/prompt — 输出 System Prompt(含来源标注)
/prd — 输出 PRD + TASKS + DESIGN 三份规格文件
/workflow — 输出 Workflow 步骤序列
/constraint — 输出 Constraint Layer 详细报告(约束节点 + 关系 + Resolution)
/why [功能名] — 解释某个具体功能"为什么是这个设计而不是别的"
/diff [论文A] [论文B] — 输出两篇论文的构念冲突与融合分析
/pgcheck — 🆕 输出所有决策的 Pedagogical Grounding Checklist 完整报告
/export — 输出所有产物(完整包)
```
---
### /model — Pedagogical Model(🆕 核心产物,默认首选)
**这是整个流水线最上游的产物**,不依赖 PRD 或任何技术实现。
它回答的问题是:**"这个系统的教学法骨架是什么?"**
输出结构:
```markdown
## Pedagogical Model
### 学习目标层(Learning Objectives)
- 学习者通过使用这个系统,应该能够...(动词+认知层次)
- 例:"学习者能够对比两种教学策略在不同场景下的适用性"
### 认知挑战层(Cognitive Challenges)
- 这个学习领域中,学习者典型遭遇的认知困难:
- [挑战1]:来自 Core KG / Context KG 分析
- [挑战2]:...
### 核心认知动作图谱(Cognitive Action Map)
| 认知动作 | 触发场景 | 对应设计决策 | 教学策略 |
|---|---|---|---|
| 对比 | 用户看到两个基准报告 | decision_002 | 同伴比较学习 |
| 反思 | 用户完成评分后查看分布 | decision_003 | 元认知支持 |
### 信息结构选择(Information Architecture)
- 选择了 [图/序列/层级/对比/网络] 结构
- 理由:[来自 PG Checklist PG4 的分析]
### 教学法设计原则(Pedagogical Design Principles)
1. [原则1]:[一句话,来自论文/认知科学]
2. [原则2]:...
### 与 Traceability Map 的关系
Pedagogical Model 是"为什么要这样设计"的宏观叙事,
Traceability Map 是"每个决策的微观溯源"。
两者互为补充,前者是后者的上游语境。
```
---
### /pgcheck — Pedagogical Grounding Checklist 报告(🆕)
输出所有决策的 PG Checklist 汇总,并给出总体评估:
```markdown
## Pedagogical Grounding Checklist 报告
### 汇总评分
| 决策 | PG1 | PG2 | PG3 | PG4 | PG5 | PG6 | 通过 | 优先级 |
|---|---|---|---|---|---|---|---|---|
| [decision名称] | ✅ | ✅ | ✅ | ⚠️ | ✅ | ✅ | 5/6 | P1↓ |
### 未通过项详情
[decision名称] — PG4 未通过:
问题:信息以线性列表呈现,但认知动作是"对比",对比需要并排结构
建议:将两个选项改为左右对比卡片布局
### 总体教学法覆盖度
- 认知动作多样性:[用了哪几种认知动作]
- 教学策略覆盖:[用了哪几种教学策略]
- 高风险决策:[PG6 分析薄弱的决策,去掉后学习影响最大的]
```
---
### /trace — Traceability Map
**A1. Markdown 汇总表**(新增约束列):
```
| 决策 | 约束冲突 | Resolution | Core KG来源 | 教学策略 | TPACK | 优先级 | 影响决策 |
|---|---|---|---|---|---|---|---|
```
**A2. 汇总 Canvas JSON**(含 Constraint 节点和 Resolution 节点):
```json
{
"meta": {
"papers": [],
"scenario": "",
"generated_at": "",
"node_count": 0,
"edge_count": 0
},
"layout": {
"columns": {
"constraint": {"x_range": [50, 250], "color_by": "constraint_type"},
"resolution": {"x_range": [300, 400], "color": "#e9d5ff"},
"source_kg": {"x_range": [500, 700], "color_by": "kg_type"},
"decision": {"x_range": [800, 1000],"color_by": "tpack_zone"},
"artifact": {"x_range": [1100, 1300],"color": "#bbf7d0"}
}
},
"nodes": [],
"edges": []
}
```
---
### /render — 直接渲染 Canvas
执行 `/render` 时,生成一个**完整的 React Flow 组件**,可以直接在 Claude artifact 中预览:
```tsx
// 生成一个自包含的 React 组件
// 包含所有节点数据、边数据、着色逻辑
// 用户可以在 artifact 中交互(拖拽、缩放、点击节点查看推理链)
```
节点点击行为:
- 点击 Decision 节点 → 展开该节点的完整推理链(Markdown 可读层)
- 点击 Constraint 节点 → 展开约束节点的 claim + resolution
- 点击 Artifact 节点 → 展开产物描述
---
### /kg — KG 图数据
输出三层 KG 的合并图数据(不含 Traceability 推理层,只是原始 KG):
```json
{
"core_kg": {"nodes": [], "edges": [], "papers": []},
"context_kg": {"nodes": [], "edges": []},
"constraint_layer": {"constraints": [], "relationships": []}
}
```
适合:把 KG 作为独立产物使用,或传入其他工具做进一步分析。
---
### /prompt — System Prompt
从所有 `artifact.type === "prompt_segment"` 节点中提取,组装完整 System Prompt。
**每条规则必须附来源标注**:`[来源: decision_XXX,Resolution: 为什么这条规则存在]`
---
### /prd — PRD + TASKS + DESIGN
从所有 `artifact.type === "ui_feature"` 节点生成三份规格文件。
每个功能附 Traceability 节点ID 和 constraint_resolution 摘要。
详细模板见 `references/spec-templates.md`。
技术栈(硬性约束):Next.js 14 + TypeScript + Tailwind + shadcn/ui + lucide-react
存储:内存 Map / LLM:OpenAI API 直接 fetch / 禁止:auth、WebSocket、测试文件
---
### /workflow — Workflow
从所有 `artifact.type === "workflow_step"` 节点生成编号序列。
每步附:触发条件 / 执行动作 / 预期输出 / 来源 `[decision_XXX]`
---
### /constraint — Constraint Layer 报告
完整输出第3层的 Constraint Layer 结果:
- 所有约束节点(含 type/priority/negotiable)
- 所有约束间关系(含 relationship/description/resolution)
- 约束分析摘要:"哪些约束决定了整个设计方向"
---
### /why [功能名]
**专项查询命令**。用户可以追问任何一个功能"为什么是这个设计而不是别的"。
返回:
1. 这个决策的 constraint_resolution(牺牲了什么,为什么值得)
2. 被排除的替代方案(从约束关系中推导出来的"没走的路")
3. 如果某个约束改变,这个决策会如何变化
---
### /diff [论文A] [论文B]
**多论文专项命令**。输出两篇论文之间的:
- 构念冲突清单(及其在第3层的处理结果)
- 互补关系(合力强化了哪些设计方向)
- 覆盖盲区(A有B没有,或反之)
---
## 输出规范
- 每层结束输出 `✅ 第X层完成:[关键数字]`
- Canvas JSON 用 ` ```json ` 包裹
- React 组件用 ` ```tsx ` 包裹
- 规格文件用带文件名注释的 ` ```md ` 包裹
- 流水线完成后必须输出 Commands 菜单
- 全文结尾输出 `🚀 下一步` 段落
---
## 质量自检
**第1层**:冲突是否保留?每篇≥20条三元组?是否识别了隐含的教学法构念?
**第2层**:六维度全覆盖?每个约束节点是否有 priority/negotiable 标注?
**第3层**:Constraint Layer 是否提取了命名约束?是否分析了约束间关系?Resolution 是否明确说明了"牺牲了什么"?
**第4层**:
- P0 决策是否通过了全部6项 PG Checklist?
- PG3(认知动作)是否来自规定词汇表,而非模糊描述?
- PG6(去掉代价)是否有实质性回答,而非"会影响用户体验"这类废话?
- 推理起点是否来自 Constraint Resolution?是否标注了跨决策连接?
**第5层**:Commands 菜单是否已输出?是否包含 /model 和 /pgcheck?Canvas JSON meta 的 node_count/edge_count 是否准确?
---
## 层级详细规范(layers/)
每层有独立的处理规范文件,包含输入契约、处理流程、输出契约、错误处理、质量自检。
当 SKILL.md 的描述不够详细时,读取对应层的文件:
- `layers/layer1-core-kg.md` — 第1层:论文类型判断 + 三元组提取 + 多篇合并
- `layers/layer2-context-kg.md` — 第2层:场景输入双轨处理 + 六维度覆盖检查
- `layers/layer3-kg-fusion.md` — 第3层:四种融合操作 + Constraint Layer 完整流程
- `layers/layer4-traceability.md` — 第4层:决策生成规则 + 三层输出格式 + Canvas JSON schema
- `layers/layer5-export.md` — 第5层:所有命令的生成规范 + 错误处理
## 参考文件(references/)
- `references/kg-vocabulary.md` — KG 谓词词汇表 + EdTech 三元组集群
- `references/tpack-guide.md` — TPACK 七区域 + 教学策略词汇表
- `references/spec-templates.md` — PRD/TASKS/DESIGN 模板 + traceability.json 格式
- `references/canvas-renderer-hint.md` — Canvas 渲染选型(React Flow / Cytoscape / Obsidian)
## 示例文件(examples/)
- `examples/cscl-example.md` — 完整执行示例:CSCL论文五层流水线
- `examples/output-trace.json` — /trace 命令的示例输出(Canvas JSON)
- `examples/output-prompt.md` — /prompt 命令的示例输出
- `examples/output-prd.md` — /prd 命令的示例输出(PRD.md)
No comments yet. Be the first to comment!