skill

research-cockpit

Agent-maintained project cockpit: a zero-dependency offline dashboard (trajectory flowchart + hypothesis-space graph + pending decisions) that keeps humans in command of agent-run projects.

sanngotall/research-cockpitcommunitylistedunreviewed

Use skill

Set up

Skills are installed by placing their folder where your agent loads skills.

Download ZIP from GitHub Open the repository

The download comes from github.com/sanngotall/research-cockpit itself, not from our server, so what you get is exactly what its author published.

Install instructions come from the README

Skills do not use an MCP config. Follow the steps in the README below.

README

synced Oct 17, 2026

Research Cockpit · 项目驾驶舱

零依赖、离线可用的项目可视化驾驶舱——由 AI Agent 按规范生成并动态更新，让人类在 Agent 大规模执行之后，依然握着方向盘。 A zero-dependency, offline project dashboard that AI agents generate and maintain — so the human stays in command after agents do the running. ｜ English

为什么需要它

当 AI Agent 开始成建制地替你跑实验、写报告，人类会撞上三种真实的失控（均来自真实项目）：

裁决积压——长跑期间人类未接入，决策欠账一次性堆积，等你想裁的时候已经看不过来了；
隐性前提——AI 推导出的中间结论被后续推理当成前提反复使用，却从未被单独验证；
死胡同循环——AI 在错误的局部空间里越优化越深，靠换超参/换配方"再调调看"原地打转，而人类灵感恰恰在这种时刻才能破局。

项目驾驶舱把整个项目压缩成一页 60 秒可扫读的"认知主干"，并把它变成人类与 AI 之间固定的决策界面：AI 负责铺开实验空间，你负责收紧研究边界。

它长什么样

视图	回答的问题
① 研究轨迹 · 流程图	我走过的路——泳道=阶段；死胡同红色节点带"为何进/何证据退出"；决策点琥珀色停在当前
② 方案空间 · 点线图	我手里的牌——节点=方案（色=验证状态、大小=信息价值、光圈=簇），箭头=依赖方向，连线小字=关系说明
⏳ 待裁决清单	现在轮到人做什么——每项附 AI 建议
⚠️ 隐性前提面板	我脚下没验的地基——仍被当作前提使用、但未充分验证的假设

三分钟上手（人类视角）

# 1. 把本仓库放进你的项目（或仅拷贝 template/ 到任意位置）
cp -r template/  <你的项目>/research-cockpit/
# 2. 按 template/data.example.js 的注释填写 data.js
# 3. 双击 index.html —— 没有服务器、没有构建、没有依赖

Agent 接入（Skill 方式，推荐）

本仓库根目录的 SKILL.md 是给 Agent 读的执行规范（数据契约、更新纪律、自检清单）。以 ZCode 为例：

# 项目级安装：拷贝到
<项目根>/.zcode/skills/research-cockpit/

之后在 Agent 会话里说"建/更新/刷新驾驶舱"或调用 /research-cockpit。Agent 的一切更新动作都只是修改 data.js——渲染器由本仓库模板统一升级，项目侧永不手改。

使用说明

人类怎么读：60 秒阅读协议

时间	看什么	判断
20 秒	状态头一行 + 下一决策点（页面顶部蓝条）	状态没变、没有待裁 ⇒ 今天不用往下看
20 秒	△ 变化 chips（自上次更新的 ≤3 条）	只看发生了什么变化
20 秒	⏳ 待裁决清单	有需要你拍板的，逐项看建议与出处
有余力时	两张图扫一眼，哪里扎眼点哪里（节点/连线点击出右侧详情）	图是索引，细节在点击里，不往图上堆

配套心法：你不需要重建整个项目的知识图谱，只需要知道"我在哪、目的地、下一个转弯点"。其它一切挂在节点上，需要时再展开。

交互速查

操作	效果
滚轮	以鼠标为中心缩放（25%~500%）
＋ / − / 复位	中心缩放 / 回到 100%
空白处拖拽	平移画布
点击节点（两图皆可）	右侧栏显示 id、状态、说明、出处
点击连线	右侧栏显示两端节点、关系类型、关系详注
悬停点线图节点	聚焦其邻域（非邻居淡化），移出复原
缩放到 <85%	点线图连线小字自动隐藏（防远视图拥挤）
状态筛选（点线图上方）	隐藏/显示对应状态的方案节点

更新流程（谁做什么、什么时候做）

触发时机：①长跑/攻坚队列收口 ②重大裁决前后 ③你主动索要（"更新驾驶舱"）。

角色	动作
你	说"更新驾驶舱"，或给出裁决结果（如"6 项全部采纳"）
Agent	对照落盘材料列变化清单 → 只改 `data.js` 的变化项 + `meta.updated` + `meta.diff`（≤3 条）→ 跑自检 → 请你刷新验收
你	打开页面扫一眼，发现与事实不符当场指出

更新铁律（违反即失真）

只改 data.js——index.html/app.js 是模板，永不手改；升级=重新拷贝；
只重组、不新造——每个事实必须有落盘出处并登记进 meta.sources；
状态只随证据变更——Agent 不得凭推断改状态档；
计数对账——图中方案数必须与来源账本对得上（计数声明先实测）；
diff ≤3 条——历史靠 git，不在文件里堆流水账。

示范教学：从零建舱到一次真实更新

以本仓库自带的虚构演示项目「结构化抽取技能模块」（template/data.example.js）为例，走一遍完整流程。打开 template/data.example.js 边看边做最直观。

第 0 步 · 备料（决定成败的一步）

先确认三份已落盘的材料：轨迹权威源（阶段/决策/死胡同从哪读）、方案账本（备选路线记在哪）、数字唯一来源（读数找谁核对）。没有落盘材料就先补材料，不要凭对话记忆填数据——驾驶舱的全部可信度建立在这一步上。

第 1 步 · 建骨架

mkdir <项目>/research-cockpit && cd $_
cp <模板>/index.html <模板>/app.js .
cp <模板>/data.example.js data.js   # 然后把里面的虚构内容全部替换成你的

第 2 步 · 填状态头（meta）

meta: {
  project: '结构化抽取技能模块',
  statusLine: '阶段：实验轮 2 收口待裁 ｜ 主干状态：4/5 判据过线 ｜ 待裁决 3 项 ｜ 最大不确定性：跨格式泛化未验',
  nextDecisionPoint: '三项终裁：接受止损 / 扩数据重试 / 定组合范式为主线',
  diff: ['E3 修复重跑双 PASS', 'P2 判无效（改写子路线不可行）', '终裁材料交付'],
  metrics: [{ label: '补强 vs 裸底座', value: '+29.5pt', note: '双种子均值 · 全部配对显著' }],
  sources: [{ path: '04_报告/收口判读.md', role: '裁决材料' }]
}

要点：statusLine 一行写完四要素（阶段/主干/待裁数/最大不确定性）；metrics 的 note 必须带口径（均值还是单次）；sources 是强制的。

第 3 步 · 画轨迹流程图（flow）

泳道 = 时间阶段，自左向右；节点挑四种就够起步：stage（阶段）、deadend（死胡同）、gate（判读门）、decision（决策点）。

flow: {
  lanes: [{ id: 0, label: '起点' }, { id: 1, label: '准备' }, { id: 2, label: '实验主线' },
          { id: 3, label: '攻坚' }, { id: 4, label: '裁决' }, { id: 5, label: '展望' }],
  nodes: [
    { id: 'exp2',   lane: 2, kind: 'stage',   status: 'info',    label: '实验轮 2', sub: '扩数据 ×2' },
    { id: 'd2',     lane: 2, kind: 'battle',  status: 'pending', label: 'D2 判定主体', sub: '止损待裁' },
    { id: 'syn2',   lane: 3, kind: 'deadend', status: 'refuted', label: '同义改写入训', sub: '修复无效 · 真退出' },
    { id: 'verdict',lane: 4, kind: 'decision',status: 'pending', label: '统一终裁 3 项', sub: '材料已交付' }
  ],
  edges: [
    { from: 'exp2',  to: 'd2',     kind: 'branch', label: 'D2 未证实→攻坚' },
    { from: 'd2',    to: 'syn2',   kind: 'branch', label: '换数据配方' },
    { from: 'syn2',  to: 'd2',     kind: 'exit',   label: '无效·真退出' },
    { from: 'd2',    to: 'verdict',kind: 'main',   label: '三路复现·止损建议' }
  ]
}

死胡同的画法是精髓：branch 边进去（当初为什么试）、exit 红边回来（什么证据判死、真退出还是变体续命）。图上一眼看到"这条路死没死、怎么死的"，死胡同就不会变成心理欠债。

第 4 步 · 填方案空间（space）

space: {
  groups: [{ id: 'g1', label: '方法路线' }, { id: 'g2', label: '数据与配方' }],
  nodes: [
    { id: 'M-01', group: 'g1', label: '组合范式', status: 'verified', value: '高', one: '模块+守卫示例 92% 双显著' },
    { id: 'D-01', group: 'g2', label: '同义改写入训', status: 'refuted', value: '中', one: '−4pt 带内，不可行' }
  ],
  edges: [
    { from: 'D-01', to: 'M-01', kind: 'downstream', label: '机制旁证', detail: '改写失败支撑"演示通道不可替代"' }
  ]
}

要点：status 用固定词表（verified/optimized/refuted/open）；value 决定节点大小（信息价值）；边方向 = from → to 箭头指向依赖/下游方；detail 是点击连线时侧栏显示的详注。

第 5 步 · 隐性前提与待裁清单

premises:  [{ id: 'PR1', risk: '高', text: '合成任务结论可迁移到真实场景（未测）', usedBy: '全部价值主张' }],
decisions: [{ id: 'J2', status: 'pending', text: '组合范式定为产品主线', advice: '采纳（双显著；风险=单点泛化未验）' }]

这两块是驾驶舱区别于普通仪表盘的地方：前提面板逼着 AI 交代"哪些地基没验过"，待裁清单把球明确踢回给人。

第 6 步 · 自检与验收

node --check app.js                                        # 渲染器语法
node -e "global.window={};require('./data.js');console.log('OK')"   # 数据可执行
# 人工核对：方案节点数 == 来源账本登记数（写在项目 README 里备查）

双击 index.html：两张图都渲染、无红色错误横幅、随便点几个节点和连线看详情。通过后把数据来源映射写进项目 README。

第 7 步 · 一次真实的更新（收口之后）

假设 J2 已获用户批准。Agent 的动作：

// ① 节点改档：status: 'pending' → 'verified'（组合范式从探索臂转正）
// ② 裁决清单：J2 的 status: 'pending' → 'decided'
// ③ 状态头与 diff 同步刷新：
statusLine: '阶段：产品形态已定 ｜ 主干状态：… ｜ 待裁决 2 项 ｜ …',
diff: ['J2 裁定：组合范式定为产品主线', 'M-01 转正为已验证', 'D-02 扩数据重试被否决']

自检 → 请你验收。历史不留在文件里——git 提交就是版本快照，将来想对比两次更新间的变化，直接 diff 两个版本的 data.js。

常见错误对照

错误	正确做法
状态凭感觉/推断改档	只随落盘证据变更（实验数据、用户裁决）
结论写进图里但没有出处	`meta.sources` 登记全部来源，节点带 `ref`
图上方案数与账本对不上	计数声明先实测，更新后逐簇对账
图变挤了就去改 `index.html`	内容增长靠缩放平移消化；渲染器问题回到模板层修
`diff` 写成十条流水账	≤3 条，只写"人需要知道的变化"

数据契约 v1（摘要）

区块	内容
`meta`	状态头一行 + 下一决策点 + 变化 diff（≤3 条）+ 关键指标（必须带口径）+ 出处登记（强制）
`flow`	泳道节点（origin/stage/gate/battle/deadend/fix/breakthrough/decision/future）+ 语义边（main/branch/exit/variant/evidence/…）
`space`	方案节点（verified/optimized/refuted/open + 信息价值）+ 依赖边（箭头指向下游）
`premises`	隐性前提：内容、被谁使用、风险档
`decisions`	待裁清单：事项、建议、状态

完整契约与纪律见 SKILL.md §4。边的方向语义：from → to = 箭头指向依赖/下游方。

设计原则（这条线不动摇）

数据与渲染分离——项目侧只编辑 data.js；渲染器升级 = 重新拷贝模板；
只重组、不新造——每个事实必须有落盘出处并登记；驾驶舱不生产新结论；
状态只随证据变更——Agent 不得因推断改档位；计数声明必须与来源账本对账；
零依赖、离线、单文件夹——双击即用，数据不出本机；
确定性布局——同一份数据永远画出同一张图，git 版本之间肉眼可 diff；
词表跨项目固定——状态词/节点类型/边类型在任何项目里含义一致，这是复用性的根。

复用到其它项目

新项目里拷贝 template/ 两件渲染器；
重新做数据来源映射（轨迹权威源/方案账本/数字唯一来源——这一步永不跨项目继承）；
按新项目重定义泳道与方案簇；词表不改；严禁把上一个项目的数据带进来。

路线图

v1.2：界面文案国际化（数据本就语言无关）、节点拖拽与手工锚点
待选：git 版本间快照 diff 视图、待裁项本地勾选、停滞/循环分支自动检测、ego 邻域子图、暗色主题

背景

本工具诞生于一个真实 AI 科研项目的一次人机协作访谈：研究者的知识图谱构建速度跟不上 AI 的执行速度，访谈结论是——人类不需要重建完整知识图谱，需要的是一个保留灵感能力的研究轨迹界面。第一版界面（纯 Markdown）在该项目的阶段终裁中实测有效，随后被固化为本 skill。仓库中的示例数据为完全虚构的演示项目。

License

MIT