车间设计师 v4
原则: "给代理一张地图，而不是一千页的说明书。" — OpenAI Harness Engineering 原则: "不要让生成者评估自己的工作。" — Anthropic GAN-Inspired Harness
车间设计五大支柱
此技能创建的所有工作空间必须满足以下五大支柱：
| 支柱 | 核心问题 | 原则 |
|---|---|---|
| 渐进式披露 | 代理能否只看到所需信息？ | 目录(~100行) → 指针 → 深层文档 |
| 机械执行 | 规则能否被机械地强制实施？ | 仅靠文档无法保持一致性 |
| 反馈循环 | 失败时能否进行结构性改进？ | 关注“缺少哪种能力”，而非“更努力” |
| 会话连续性 | 会话间的交接是否清晰？ | progress + feature-status + git |
| 熵管理 | 结构能否随时间推移保持稳定？ | 定期清理、文档新鲜度验证 |
两个层面的关系
┌─────────────────────────────────────────────────────┐
│ 第1层: 元层面（此技能的角色） │
│ │
│ 规划器 ──→ 生成器 ──→ 评估器 │
│ ↑ (单向顺序，禁止反向引用) │
│ └──── 不合规时反馈 ──────────────────────┘ │
│ │
│ 目的: 设计、生成并验证工作空间结构本身 │
└─────────────────────────┬───────────────────────────┘
│ 批准后结构完成
▼
┌─────────────────────────────────────────────────────┐
│ 第2层: 操作层面（已完成工作空间的角色） │
│ │
│ ┌ 初始化器 (仅首次运行) → 环境设置 │
│ │ │
│ └ 操作代理 (重复执行): │
│ 代理-A ─┐ │
│ 代理-B ─┼──→ 主席综合 ──→ 最终成果 │
│ 代理-C ─┘ (独立并行，互不通信) │
│ │
│ 目的: 执行实际任务 (分析、决策、报告等) │
└─────────────────────────────────────────────────────┘
第1层: 元层面 — 车间设计流程
L1 三种代理 (单向顺序，禁止反向引用)
规划器 → 生成器 → 评估器 按顺序传递成果。 每个代理仅接收前一阶段的成果，不看下一阶段的结果。
规划器 (策划代理)
分析用户意图，设计车间结构。
- 输入: 用户需求 (通过问题收集)
- 输出: 代理配置方案 + 文件夹结构草稿 + 评估标准建议
- 约束: 在看到生成器和评估器的结果之前进行设计
生成器 (构建代理)
将规划器的设计方案转化为实际文件。
- 输入: 规划器已批准的设计方案
- 输出: 实际的 .md/.json 文件 (完整产出清单见阶段 2)
- 约束: 在不预先看到评估器标准的情况下构建
评估器 (评估代理)
独立验证生成器的产出。
- 输入: 生成器创建的文件 + 规划器的评估标准
- 输出: 基于五大支柱的评分 + 功能验证结果 + 改进反馈
- 约束: 不考虑生成器的意图，仅查看结果
L1 阶段 0: 模式匹配 — 参考 harness-100 (新增 v4.1)
"99% 的优秀设计已经有人做过。找到它，然后改编它。"
在进入发现环节之前，从 harness-100(https://github.com/revfactory/harness-100, Apache-2.0) 中找出最相似的经过验证的典范，并以此作为参考基线。非开发者应转向 harness-starter-workspace 技能。
目标典范 (工作空间领域 73 个)
- 内容 #01–15，商业 #43–55，教育 #56–65，法律 #66–72，生活方式 #73–80，文档 #81–88，运营 #89–95，专业 #96–100
阶段 0 流程
- 从用户的 1~2 句话请求中提取领域关键词
- 在上述 73 个中提出前 3 个候选方案 + 用户确认
- 将选定的典范编号记录在
_workspace/00_input.md的reference_exemplar字段 - 匹配相似度 < 0.5 → 回退到自由设计模式 (按原阶段 1 进行)
阶段 0 结果对后续阶段的影响
- 规划器: 默认使用典范的 4~5 名专家 + 审查员配置
- 生成器: 强制使用典范骨架脚手架、
_workspace/NN_*.md编号约定 - 评估器: 使用典范的 8 个质量标准 (代理团队模式 / 领域专长 / 结构化输出 / 依赖DAG / 错误处理 / 规模模式 / 测试场景 / 触发边界) 作为评价标准
模式保真度 (定性评估，仅限阶段 0)
不包含在五大支柱自动评分中。在阶段 0 匹配典范时进行定性评估。
在阶段 0 选定的 harness-100 典范的 8 个质量标准 (代理团队模式 / 领域专长 / 结构化输出 / 依赖DAG / 错误处理 / 规模模式 / 测试场景 / 触发边界) 会 与评估器评分分开检查。
- 应用时间点: 阶段 0 (选择典范) 时 1 次，评估器通过后报告时 1 次
- 不进行评分: 不包含在五大支柱 22 项评分中
- pillar-weight: 仅可调整五大支柱的权重。模式保真度不是权重对象
审查员强制化
操作层必须包含审查员代理 (交叉验证角色)。在现有的主席综合模型中增加审查员交叉验证步骤。
触发边界 (should + NOT)
规划器/生成器必须在生成的 orchestrator skill.md 中必须包含 should-NOT trigger 部分。
领域框架注入
按类别自动注入经过验证的框架：
- 内容: AIDA, Pattern Interrupt, CURVE formula
- 商业: BMC, TAM/SAM/SOM, Porter's 5 Forces, RICE, Van Westendorp PSM
- 教育: Bloom's Taxonomy, ADDIE, CEFR, SM-2, Toulmin Model
- 法律: IRAC, MQM, GDPR/PIPA, IPC/CPC
- 生活方式: BMR/TDEE, ACSM Guidelines, Compound Interest
- 文档: Diataxis, PREP, STAR, MADR, SemVer
- 运营: SIPOC/RACI, 4C Framework, SMART, NPS/CSAT, BARS
- 专业: GHG Protocol, Cap Rate/IRR, IMRaD, Georgia-Pacific, Double Materiality
L1 阶段 1: 发现 — 规划器运作
发现由 4 个阶段的问题组成。 按顺序依次进行，但根据用户的回答，后续问题可能会分岔。 在收到一个阶段的答案后，再进入下一个阶段。 不要一次性提问所有问题。
1-1. 阶段 1 — 目标与背景 (WHY / WHO)
把握此工作空间存在的原因，而非其结构。
W1. 此工作空间想要解决的问题是什么？
(什么决策/分析/判断目前运作不佳？)
W2. 谁在使用它？
(仅代理 / 代理+人类 / 人类消费结果)
→ 后续问题: 用户的领域专业水平如何？
W3. 此工作空间的成功标准是什么？
(出现什么结果才能说“做得很好”？)
W4. 是否有类似的现有流程？
(是替代品 / 是新创建的)
→ 后续问题 [替代]: 现有流程最大的问题是什么？
→ 后续问题 [新建]: 是否有作为基准的系统？
后续问题分岔：
- W2 回答“人类消费结果” → “接收结果的人的职位/角色是什么？偏好什么格式？”
- W3 回答模糊 → “具体来说，产生什么产出才算成功？”
1-2. 阶段 2 — 产出与结构 (WHAT)
制作什么，需要哪些角度。
S1. 最终产出是什么？
(报告 / 决策记录 / 分析报告 / 策划方案)
S2. 重复的核心工作模式是什么？
(输入 → 分析 → 决策 → 记录 → 知识积累)
S3. 需要多少种视角/角色？每个角色的性质是什么？
(例如: 乐观/悲观/数据/经验/监管 — 相互冲突/补充)
→ 后续问题: 视角之间是否有优先级？是否平等？
S4. 是否需要主席(综合角色)？
(负责主会话 / 独立代理 / 不需要)
→ 后续问题 [需要]: 代理模型配置如何？
→ 参考 references/agent-archetypes.md 后提出建议
S5. 输入形式是什么？
(直接文本输入 / 文件上传 / URL / 复合形式)
S6. 应该保留下来的输出是什么？
(会话文件 / 决策记录 / 知识积累 / deep-research)
后续问题分岔：
- S3 回答 5 个以上视角 → “这些视角可以分组吗？顺序还是并行？”
- S4 回答“独立代理” → “主席的判断框架是什么？Go/Pivot/No-Go？”
1-2.5. 阶段 2.5 — 知识管理 (KNOWLEDGE) [有条件]
对于多议程研究工作空间，需要系统性地参考现有研究时使用的 wiki 选项。 对于单议程或非研究工作空间，则跳过。
K1. “是否需要在进行多个议程(研究主题)时，将现有研究参考到后续研究中？”
→ “否” → 不包含 wiki。转到阶段 3。
→ “是” → 转到 K2。
K2. 检查 /graphify 技能是否已安装 (自动检测)
- 检查 ~/.claude/skills/graphify/ 或 .claude/skills/graphify/ 是否存在
- 已安装 → 转到 K3。
- 未安装 → 提供说明：
┌─────────────────────────────────────────────────┐
│ wiki 由 /graphify 技能创建。 │
│ 没有此技能，将无法创建 wiki。 │
│ │
│ /graphify 是什么？ │
│ - 分析文档/报告以生成知识图谱 │
│ - 自动发现概念之间的联系并进行可视化 │
│ - 自动创建基于社区的 wiki 文档 │
└─────────────────────────────────────────────────┘
“是否要安装 graphify？”
- 全局安装 (~/.claude/skills/) [所有项目使用]
- 项目安装 (.claude/skills/) [仅此项目使用]
- 不安装 → ⚠️ “wiki 功能将被禁用。
45-wiki/ 文件夹会被创建，但会是空的。
之后安装 /graphify 后，可通过 /wiki-update 创建。”
→ 仅包含 wiki 结构，禁用状态。转到阶段 3。
K3. “wiki 仓库放在哪里？”
- 项目内部 (45-wiki/) [默认]
- 指定外部路径
K4. “开始新研究时，是否自动搜索 wiki？”
- 自动搜索 + 用户批准后引用 [默认]
- 仅允许手动调用 (/wiki-ref)
规划器输出中新增 (与 wiki 相关)：
wiki_enabled: true/falsewiki_location: "45-wiki/" 或用户指定路径wiki_auto_ref: true/falsegraphify_installed: true/falsegraphify_scope: "global" | "project" | "none"
⚠️ 保护 wiki 引用的独立性：
- 绝对禁止向阶段 A (独立研究) 代理注入 wiki 内容
- 仅在阶段 B (Creative Thinker) / 阶段 C (主席) 中，经用户批准后才允许引用
- 引用时，仅传递框架/方法论/数据点，而非结论
- 产出中必须记录 wiki_ref、ref_approved_by、ref_approval_date
1-2.6. 阶段 2.6 — 流程变更历史追踪 (FLOW HISTORY) [可选]
推荐用于工作流程预计会随时间推移而改进的项目。 对于一次性分析或一次性项目，可以跳过。
F1. “是否要记录将来工作流程改进或变更的历史？”
用途：
- 回顾项目改进历史 (为什么这样改变)
- 在需要回滚到以前版本时获取依据
- 为规划类似项目提供参考
※ 并非每个新会话都要读取。
仅在修改、回滚或移植流程时参考。
→ “否” → 不包含 05-flow-history/。转到阶段 3。
→ “是” → 转到 F2。
F2. “是否要自动将初始构建(v1)记录为 change 0001 记录？”
- 默认值: 是 (规划器发现期间的答案将作为设计依据保留)
- 否 → 仅创建 CHANGELOG，首次变更时手动记录
流程历史管理原则 (基于创建后的操作标准)：
此历史仅记录工作流系统(规则、流程、工具、提示、命令、脚本、CLAUDE.md)的
变更。系统创建的产出(研究成果、报告、分析、议程注册)不属于
记录对象。
区分标准：“如果没有此变更，下次执行的结果是否会不同？”
→ 会不同 = 系统变更 = 记录 / 不会不同 = 产出 = 无需记录
详情请见: 00-system/protocols/flow-change-protocol.md
规划器输出中新增 (与流程历史相关)：
flow_history_enabled: true/falseflow_history_initial_record: true/false(F2 的回答)
1-3. 阶段 3 — 环境与工具 (HOW)
在什么环境中如何运作。
H1. 使用的 AI 工具是什么？
(Claude Code / Desktop Claude / 其他)
→ 根据工具的不同，车间设置方式也会不同
H2. 会话间是否需要连续性？
(一次性分析 / 长期项目 / 多会话)
→ 如果是“长期”，则包含会话交接产出
H3. 代理模型配置是什么？
→ 通过网络搜索确认当前最新的 Claude 模型后提出建议
→ 不要硬编码模型名称。始终由用户决定
H4. 代理的自主程度如何？
(每次都需要人工确认 / 代理自主判断 + 报告 / 完全自主)
后续问题分岔：
- H2 回答“长期” → “预计的会话数量是多少？知识积累重要吗？”
- H4 回答“完全自主” → “升级标准是什么？什么情况下需要询问人类？”
1-4. 阶段 4 — 质量与评估标准 (QUALITY / EVALUATE)
掌握用户认为重要的价值，并达成评估标准的共识。
E1. 此工作空间中最重要的质量属性是什么？(选择前 3 项)
□ 分析深度 (非表面的洞察)
□ 独立性 (代理之间无影响的独立分析)
□ 注明来源 (基于依据的结论)
□ 一致性 (会话间保持质量)
□ 快速响应 (短处理时间)
□ 可扩展性 (易于添加代理/角色)
□ 文档化 (过程和结果的可追溯性)
□ 用户可及性 (非专业人士也能理解结果)
E2. 是否有未来的扩展计划？
(无 / 添加视角 / 应用于其他领域 / 加强自动化)
E3. 此工作空间中绝对不能妥协的是什么？
(例如: “代理之间不能互相影响”，“不能接受没有来源的结论”)
E4. 相反，初期没有也可以的东西是什么？
后续问题分岔：
- E1 回答“独立性” → “到什么程度？禁止共享结果？还是仅分析独立？”
- E3 的回答 → 作为评估器权重的关键输入使用
1-5. 评估权重共识 (完成阶段 4 后)
分析阶段 1~4 的回答，提出五大支柱的权重。 与用户达成共识后最终确定。
[权重提议流程]
步骤 1. 从阶段 1~4 的回答中提取关键词
- “必须独立” → 机械执行 ↑
- “长期项目” → 会话连续性 ↑, 熵管理 ↑
- “快速响应” → 渐进式披露 ↑
- “注明来源” → 机械执行 ↑
步骤 2. 从默认权重调整并提出
默认权重 (反映项目特性前):
| 支柱 | 默认 | 调整依据 | 建议 |
|------|------|----------|------|
| 渐进式披露 | 20% | (变动依据) | ?% |
| 机械执行 | 25% | (变动依据) | ?% |
| 反馈循环 | 20% | (变动依据) | ?% |
| 会话连续性 | 15% | (变动依据) | ?% |
| 熵管理 | 20% | (变动依据) | ?% |
“考虑到此项目的[依据]，
将[支柱]的权重从[默认]%调整为[建议]%。
如果您有意见或修改建议，请告知。”
步骤 3. 反映用户反馈
- 同意 → 确定
- “提高独立性” → 提高机械执行，降低其他支柱后重新提议
步骤 4. 最终审批
→ 使用协商确定的权重，而非 evaluator-protocol-workspace.md 中的默认权重
1-6. 模式自动映射
根据阶段 2 的回答自动推荐文件夹模式：
| 用户回答关键词 | 推荐模式 | 参考 |
|---|---|---|
| 分析、投资、决策、判断 | 模式 A (分析·决策型) | folder-patterns.md |
| 施工、工序、估算、建筑 | 模式 B (建筑·项目管理型) | folder-patterns.md |
| 研究、内容、报告 | 模式 C (研究·内容型) | folder-patterns.md |
| 长期编码、自动化构建 | 模式 D (长期代理型) | folder-patterns.md |
1-7. 规划器产出
① 项目背景摘要 — 目的、用户、成功标准、核心约束 (基于阶段 1~2) ② 代理配置方案 — 角色、性格、模型部署 ③ 文件夹结构草稿 — 模式映射 + 自定义 ④ 会话连续性设计 — 决定交接方式 (一次性 / 使用 progress.json) ⑤ 扩展策略 — 为未来扩展做准备的设计决策 (基于阶段 4 E2) ⑥ 评估标准 + 协商确定的权重 — 五大支柱检查清单 + 权重表
[规划器完成 — 请求用户审批]
请检查①~⑥，如有修改意见请告知。
一经批准，生成器将开始构建。
L1 阶段 2: 构建 — 生成器运作
规划器产出获批准后，按以下顺序创建文件。 生成器同时创建文件夹结构和文件内容。
2-1. 工作流程图 (Mermaid)
表示两个层面的图表。包含评估器→规划器的重新设计循环：
flowchart TD
USER[用户] -->|需求| P
subgraph L1[第1层: 元层面]
P[规划器] --> G[生成器]
G --> E[评估器]
E -->|不足 70~89%| G
E -->|重新设计 <70%| P
E -->|批准 >=90%| DONE[结构完成]
end
DONE --> INIT
subgraph L2[第2层: 操作层面]
INIT[初始化器\n仅首次运行] --> OP
subgraph OP[操作代理重复执行]
INPUT[输入] --> SPLIT[ ]
SPLIT --> A1[代理-A]
SPLIT --> A2[代理-B]
SPLIT --> A3[代理-C]
A1 --> CH[主席综合]
A2 --> CH
A3 --> CH
CH --> OUT[输出 + 状态保存]
end
end
2-2. 核心产出创建 (按顺序)
| 序号 | 产出 | 参考文件 | 备注 |
|---|---|---|---|
| 2-2a | WORKSPACE_TREE.md | folder-patterns.md | 确定文件夹结构 |
| 2-2b | CLAUDE.md (~100行) | claude-md-template.md | 充当目录，必须包含参考路由表 |
| 2-2c | AGENTS.md | (本技能内指南) | 代理操作规则 + model_config |
| 2-2d | 代理角色文件 | agent-archetypes.md | 00-system/prompts/*.md |
| 2-2e | 5种协议 | (本技能内指南) | 00-system/protocols/ |
| 2-2f | 会话交接产出 | session-handoff.md | progress.json + feature-status.json |
| 2-2g | 强制性规则 | enforcement-patterns.md | 结构可验证的规则 |
| 2-2h | 斜杠命令 | (基于规划器设计) | .claude/commands/*.md |
| 2-2i | README.md | (用户指南) | 快速入门 + 命令 + 故障排除 |
| 2-2j | 流程变更历史 wiki (可选) | flow-history-template.md | 仅在阶段 2.6 中 F1=是时创建 |
2-2b. CLAUDE.md 编写规则 (最重要)
→ 参考 references/claude-md-template.md。必须控制在 100 行以内。
CLAUDE.md 是代理的入口点。 过长的指令会变成“非指导”：
- 上下文会挤占任务和代码
- 代理会陷入局部模式匹配，而非有目的的探索
- 单一文档会迅速过时
必须包含的内容：
- 工作空间标识 (3行)
- 代理配置表
- 参考路由表 ← 渐进式披露核心
- 独立性原则指针
- 命令列表
参考路由表格式：
## 参考路由
| 情况 | 要读取的文件 |
|------|----------|
| 确认代理角色 | → 00-system/prompts/[role].md |
| 讨论进行规则 | → 00-system/protocols/council-protocol.md |
| 独立性原则详情 | → 00-system/protocols/independence-protocol.md |
| 检查会话状态 | → progress.json |
| 功能完成情况 | → feature-status.json |
2-2c. AGENTS.md 编写规则
必须包含：
- 第2层代理列表表 (角色 / 模型 / 激活条件)
- model_config 部分 (用户选择的模型 + 重新审视触发器)
- 主席综合方式 + 决策框架 (Go/Pivot/No-Go)
- 独立性原则摘要
- 上下文管理规则
...