| name | workbench-benchmark-review |
| description | 对 trpg-workbench 做"创作型 AI workbench"参考项目对标 review。 当用户提到"对标分析"、"benchmark review"、"参考 Inscriptor/OpenPawz/OpenCode"、 "参考 leaked-system-prompts"、"system prompt 参考"、"如何写更好的 system prompt"、 "milestone 后的产品 review"、"post-milestone review"、"横向产品对比"、 "看看我们还缺什么"、"workbench 体验"、"agent 协作体验"、"信息架构"、 "创作控制感"、"workbench 协同"等场景时必须加载本 skill。 本 skill 只做 review 和分析，不直接改代码，不直接新建 milestone， 结论最终落入 docs/benchmark-reviews/ 目录下的分类文件中。
|
workbench-benchmark-review
这个 skill 是做什么的
对 trpg-workbench 做"创作型 AI workbench"参考项目对标 review。
trpg-workbench 的核心定位是：AI 驱动的创作型工作台——用户在这里管理 TRPG 资产、调度 AI Agent 协作、查阅知识库、审查规则，最终生成高质量创作物。Desktop 是承载形态之一，而不是产品定位本身。
本 skill 所说的 workbench，不只是 UI 布局与信息架构，还包括：
- Agent 编排：Director/Plot/NPC/Monster/Lore/Rules/Consistency/Document 各 Agent 的分工与调度方式
- 人机协作流程：澄清→计划确认→执行→patch 确认的交互节点设计
- 知识库 / RAG / 规则审查与创作流程的耦合方式：知识在什么时机注入、规则审查如何呈现、引用如何可见
核心目标：
- 对照成熟的 AI workspace / creative workbench 参考对象，评估 trpg-workbench 还缺哪些高价值能力
- 提炼能帮助 trpg-workbench 成为更好的"创作型 AI workbench"的机制
- 在 milestone 完成后做横向产品 review，输出可操作结论
- 结论落入
docs/benchmark-reviews/ 目录的分类文件，而不是只在对话中消失
不做什么：
- 不直接改代码
- 不直接新建 milestone（除非用户明确要求）
- 不追求"和参考产品长得像"或"功能数量追齐"
- 不以 desktop 体验为首要评估维度
默认参考对象
如果用户没有特别指定，默认使用以下三个参考对象，主次有别：
主参考：Inscriptor
定位： 创作型 workspace 的信息架构与内容编排标杆
借鉴侧重：
- 信息密度控制与视觉层次
- 内容组织方式（项目 / 文档 / 侧栏 / 工作区编排）
- 左栏导航 + 中栏编辑器 + 右栏面板的协同模式
- 创作工作流中的状态持久化与切换体验
- 非线性内容编辑与关联展示
为什么是主参考：
Inscriptor 的核心场景与 trpg-workbench 最接近——都是"创作者在工作台上管理复杂内容"。它代表了创作型 workspace 在信息架构上的成熟解法，是 trpg-workbench 最直接的参照系。
不照搬的部分：
- 视觉样式与品牌风格
- 不针对 TRPG 场景的纯写作流程
次参考：OpenPawz
定位： AI + desktop + local-first 产品骨架
借鉴侧重：
- 本地优先桌面 AI 应用的能力边界设定
- Provider / model / integration 抽象层设计
- Memory / agent / session 的组织方式
- 用户可感知的 AI 状态：
- 用户是否清楚 AI 当前在做什么（生成中 / 审查中 / 等待输入 / 等待确认）
- 当前使用了哪些模型、哪些知识库、哪些规则
- AI 状态切换时用户是否得到足够提示，而不是"黑箱进行中"
为什么是次参考：
OpenPawz 代表了"桌面 AI 产品如何把 agent 能力做成用户可理解、可控的工作台体验"，这与 trpg-workbench 中 Agent 面板 + 知识库 + rules 的设计方向高度相关。
不照搬的部分：
- 非创作场景的 agent 能力
- 其全部 integration 体系（trpg-workbench 范围更聚焦）
补充参考：OpenCode Desktop
定位： 桌面 AI 工具的成熟产品机制（特别是基础设施层）
借鉴侧重：
- 桌面端启动与错误恢复机制
- 模型配置与 provider 抽象（API key、provider 切换）
- Help / onboarding / 文档入口
- 构建与发布结构
为什么是补充参考：
OpenCode 在 desktop 基础设施层（启动恢复、provider config、发布体系）上是成熟参照，但它的产品人格是 coding agent，与 trpg-workbench 的创作工具定位存在本质差异。因此只借鉴其"桌面机制"层，不借鉴其"agent 交互人格"层。
明确不照搬：
- Terminal / coder-centric 交互模式
- Coding agent 特有的产品人格与输出风格
补充参考：leaked-system-prompts
来源： https://github.com/jujumilk3/leaked-system-prompts（14.5k stars）
定位： 工业级 system prompt 工程学习资源
借鉴侧重：
- 主流 AI 产品（ChatGPT、Claude、Gemini、Cursor、Copilot、Manus 等）生产级 system prompt 的结构与约束写法
- 工具调用规范的表达方式（伪代码 vs 自然语言）
- 负向约束（negative constraints）段落的设计
- 输出格式控制段落的写法
- 多轮上下文感知与 fallback 行为描述
为什么是补充参考：
trpg-workbench 的 Agent system prompt（apps/backend/app/prompts/ 下各 Agent）是产品核心竞争力之一。工业级产品的 system prompt 在约束清晰度、歧义消除和 LLM 行为可预测性上明显优于早期写法。参考此资源有助于系统性提升 Director / Rules / Consistency Agent 的 prompt 质量。
借鉴时的参考文件：
apps/backend/app/prompts/director/system.txt — 主要改进对象apps/backend/app/prompts/director/planning.txtapps/backend/app/prompts/director/clarification.txtapps/backend/app/prompts/_shared/ — 共享 prompt 片段
明确不照搬：
- 其他产品特有的业务约束（如 Cursor 的 coding 场景规则）
- 英文写法（trpg-workbench prompt 保持中文为主）
默认 review 主题
如果用户没有指定具体主题，优先从以下方向进行 benchmark review（按重要性排序）：
- Workbench 信息架构与内容编排 — 左栏/中栏/右栏的协同、资产树组织、编辑器与面板的关系
- Agent 编排与人机协作体验 — 用户如何感知 Agent 在做什么、如何介入和控制、澄清/确认流程
- 知识库 / RAG / 规则审查如何服务创作 — 知识查阅路径、规则审查结果的呈现与应用；具体关注：
- RAG 是否在合适时机介入创作，而不是静默注入或完全不可见
- Rules review 是否更像"协作建议"而不是"事后批改"
- 引用来源是否足够可见，用户能否追溯某段生成内容的知识依据
- 用户是否能理解知识库结果如何影响了当前生成
- 模型配置与 provider 抽象 — 多模型支持、API key 管理、切换体验
- Help / onboarding / 文档入口 — 新用户引导、功能发现、帮助文档
- 桌面端启动、错误恢复与发布结构 — 冷启动、崩溃恢复、更新机制
若用户指定了具体主题，只聚焦该主题，不扩展到其他方面。
参考判断原则
在分析每个借鉴点时，必须遵循以下原则：
1. 优先评估是否提升"创作控制感"
用户在使用 trpg-workbench 时，核心诉求是掌控自己的创作过程——知道 AI 在做什么、能随时调整、能审查结果、能修改资产。
借鉴一个机制之前，先问：它是否让用户对创作内容有更强的掌控感？还是只是让产品"看起来更完整"？
2. 优先评估是否改善"workbench 协同"
trpg-workbench 的核心工作流是：
左栏资产树 ↔ 中栏编辑器 ↔ 右栏 Agent 面板
↕ ↕
知识库/RAG rules/patch/confirm
每个借鉴点都应评估：它是否改善了这几个区域之间的协同体验？是否减少用户在区域间切换的认知负担？
3. 不以"更强大"为唯一标准
优先判断：
- 是否适合当前阶段的 trpg-workbench（1.0 之前的范围控制）
- 是否会破坏当前 skill / plan / 架构边界
- 是否和核心定位（TRPG 创作工具）契合
4. 不追求 feature parity
不要求 trpg-workbench 长得像参考产品、功能数量与之齐平、或交互风格趋同。
5. 优先借鉴机制，不借鉴外观
优先分析：协作机制、信息架构、onboarding 流程、配置抽象、help/docs/release 体系。
6. 每个结论都必须给出"为什么不做"的判断
如果某个参考点不适合当前项目，也必须明确说明理由，不能只列"可以参考的点"。
7. 结论必须可落地
不应停留在"可以优化"这类空话，必须落到：
- 写 skill
- 写 plan（进入哪个 milestone）
- 直接改代码（小改）
- 先不做（并说明触发重新评估的条件）
标准输出结构
每次 benchmark review 必须按以下结构输出：
Section 1：当前项目已做到的部分
按三个层次分别说明：
- 产品骨架已完成：功能链路打通，核心流程可运行
- 用户体验已完成：不只是能用，还有良好的感知、反馈与控制
- 骨架到位但体验细节未完成：功能存在但缺少状态可见性、错误提示、引导、或流程流畅度
Section 2：参考项目中最值得借鉴的点
只提炼 3~5 个高价值点，不罗列太多。每个点必须包含：
## 借鉴点 N：<简述>
**来源：** Inscriptor / OpenPawz / OpenCode Desktop
**借鉴理由：** 为什么这个机制值得关注
**当前差距：** trpg-workbench 现在的状态 vs 参考产品
**适合性判断：** 为什么适合 / 为什么不适合 trpg-workbench
**对创作控制感的影响：** 改善 / 无关 / 可能削弱（说明理由）
**对 workbench 协同的影响：** 改善哪个区域间的协同，或无关
**对 1.0 用户价值的影响：** 是否是 1.0 前必须解决的体验问题
**建议修改范围：** 需要改哪些模块 / 哪些 skill / 哪些 plan
**落地方式：** plan / skill / 直接改代码 / 先不做
Section 3：三类结论区分
| 类别 | 含义 | 判断依据 |
|---|
| 可直接参考的成熟机制 | 机制成熟，适合直接移植或小改即可用 | 与 trpg-workbench 场景高度匹配 |
| 可借鉴但需改造 | 核心思路可用，但实现需适配创作工具场景 | 机制好但目标用户/场景有差异 |
| 当前不应优先做 | 价值认可，但不适合当前阶段或范围 | 超出 1.0 范围或会破坏现有边界 |
Section 4：优先级结论
输出 Top 3 推荐改进方向，每项说明：
### Top N：<方向名>
- 建议行动：小改 / 新 milestone / 新 skill / 仅记录
- 预估影响：高 / 中 / 低
- 创作控制感提升：有 / 无 / 间接
- workbench 协同改善：有 / 无 / 间接
- 触发条件（若暂缓）：...
输出文件规范
review 完成后，必须将每个高价值结论单独写入 docs/benchmark-reviews/proposed/ 目录，文件名格式：
YYYY-MM-DD_<主题简述>.md
每个文件使用以下模板：
---
status: proposed
date: YYYY-MM-DD
source: Inscriptor / OpenPawz / OpenCode Desktop
theme: <review 主题>
priority: high / medium / low
affects_creative_control: yes / no / indirect
affects_workbench_collab: yes / no / indirect
recommended_action: plan / skill / code / defer
---
# <借鉴点标题>
## 来源与借鉴理由
...
## 当前差距
...
## 适合性判断
...
## 对创作控制感的影响
...
## 对 workbench 协同的影响
...
## 对 1.0 用户价值的影响
...
## 建议落地方式
- [ ] plan：进入哪个 milestone
- [ ] skill：写什么 skill
- [ ] 直接改代码：改哪里
- [ ] 暂缓：触发重新评估的条件
## 不做的理由（如适用）
...
文件创建后，告知用户文件路径，等待用户决策后手动（或指示 AI）将文件移动到 accepted/ / rejected/ / deferred/。
如何与 plans/milestones 衔接
本 skill 只做 review，不直接修改 .agents/plans/。但 review 结论中会明确标注：
- 若建议"写 plan"：指出应进入哪个 milestone（新建或追加到现有 milestone）
- 若建议"写 skill"：给出 skill 名称建议和职责边界
- 若建议"直接改代码"：给出文件范围和改动描述
用户决策后，由用户或单独指令来驱动具体实现。
Proposal 生命周期
docs/benchmark-reviews/ 中的 proposal 文件有四个状态，每个状态转移都有明确的触发时机和执行方：
| 状态转移 | 触发时机 | 执行方 |
|---|
proposed → accepted | 用户决策"要做"，确认进入某个 milestone 时 | 用户指令 / milestone 规划阶段 |
proposed → rejected | 用户明确决策"不做" | 用户指令 |
proposed → deferred | 用户决策"暂缓，条件满足后再评估" | 用户指令 |
accepted → completed | 对应 milestone 归档时，由 milestone-management Step 4b 执行 | milestone 归档流程 |
本 skill 的职责边界：
- 本 skill 只负责将结论写入
proposed/，并告知用户文件路径
proposed → accepted/rejected/deferred 的转移由用户决策后下达指令来执行accepted → completed 的转移由 milestone-management skill 的 Step 4b 负责，本 skill 不介入
注意：accepted/ 目录中的文件应在 milestone plan 的"背景与动机"或"来源"章节中被引用。如果某个 proposal 已被采纳进入 milestone 但未引用路径，归档时 Step 4b 将无法自动发现它，需要手动移动。
推荐调用模板
以下模板可直接复制使用：
通用对标 review（默认主题）：
请基于 workbench-benchmark-review，对照 Inscriptor + OpenPawz + OpenCode Desktop，
对当前仓库做一次 benchmark review，使用默认主题顺序。
先只输出 review，不改代码，不新建 plan，结论写入 docs/benchmark-reviews/proposed/。
Milestone post-review：
请基于 workbench-benchmark-review，对 M10 完成后的当前产品形态做一次 post-milestone benchmark review，
重点评估：workbench 信息架构、agent 编排与人机协作体验。
结论写入 docs/benchmark-reviews/proposed/。
单主题深度 review：
请基于 workbench-benchmark-review，只参考 Inscriptor，
深度分析 trpg-workbench 当前的左栏/中栏/右栏信息架构与参考产品的差距。
重点判断哪些机制能改善 workbench 协同，哪些不适合。
决策后落地：
docs/benchmark-reviews/proposed/2026-04-23_workbench-layout.md
这条结论我决定要做，请将其移入 accepted/ 并在 .agents/plans/ 中追加到合适的 milestone。
Agent 协作专项 review：
请基于 workbench-benchmark-review，只参考 Inscriptor + OpenPawz，
聚焦以下三个主题：agent 编排与人机协作体验、创作控制感、workbench 协同。
不讨论桌面启动、发布结构、provider config。
先只输出 review，结论写入 docs/benchmark-reviews/proposed/。
