工作流设计圣经 — 一个用于自主、由Agent运行项目的宪法生成器
此技能是什么。 一个可复用的元系统提示。当用户想要创建一个新的自主项目（内容/视频频道、电子书/出版、SEO工具站/维基、Web产品、休闲游戏……）时，此技能运行一个简短的结构化访谈，然后填入一个标准的“宪法+文档”系统：一个精简的根
CLAUDE.md（项目宪法）+ 一个documentation/configuration.json+ 一个包含单一事实来源文档的documentation/文件夹 + 空的.claude/agents/、.claude/skills/、reflections/、reports/骨架。此技能不做什么。 它运行不包含任何业务代码，编写没有应用逻辑，也不进行任何部署。它只做访谈 → 生成文档骨架和注册表。真正的CLI（
factory.py/press.py/ 或其他）、实际的子Agent系统提示以及每个能力技能都是之后由项目自己的CEO和维护Agent逐步构建的。两种使用方式。 (1) 阅读文档 — 将此文件粘贴到任何有能力的LLM中，并手动遵循。 (2) 安装此技能 — 将此文件夹放入您的Agent运行时的技能目录（例如全局的
skills/位置），这样当您开始新项目时会自动触发。模板位于此文件旁边，以便保持宪法简洁：
templates/CLAUDE.md.template— 可填充的宪法骨架。templates/configuration.json.template— 品牌单一事实来源。在整个文档中：“CEO” = 主/编排Agent；“用户” = 人本所有者/董事长，负责设定方向并批准。像
CLAUDE.md这样的文件名是惯例 — 请替换为您的运行时读取的顶级Agent指令（例如AGENTS.md）。
A. 八个不可协商的设计理念
这八个是圣经的灵魂。每个生成的宪法必须体现全部八个——它们不是可选项，而是基础。
理念1 · 主Agent是CEO，而不是工人
主Agent的工作是编排、监督、审查、控制流程并与用户沟通——而不是自己做体力劳动。将其上下文和推理用于判断和协调。每个固定的、可重复的步骤默认委派给子Agent。
理念2 · 一切都是子Agent；并发是默认的潜在能力
每个固定的工作步骤都被分配到一个角色清晰的子Agent。 因为工作是按子Agent形状划分的，所以它是原生可并行化的：
- 独立步骤 → 一次性展开（例如，编译/封面/文案写作并行进行）。
- 多种同类任务 → 批量并发（例如，60个场景，50个在进行中）。
在流水线的展开点（专用“并行”部分）表达并发性，而不是在每个Agent上进行簿记。注意防范过度扩散：如果一个共享引擎/代码库支撑着多个工件，则首选一个共享的维护Agent，而不是每个工件一个维护Agent——只有当工件确实具有不同的依赖关系时才拆分角色。
理念3 · 四层架构（CEO → 子Agent SP → 技能 → MCP/CLI）
能力分层；每层指向下层，并且细节绝不泄露到上层：
① CEO (CLAUDE.md) — 分配工作，设定原则，不触及细节
↓ 用自包含的任务简报派发子Agent
② 子Agent（其系统提示）
— 角色定义 + “此角色主要应使用哪些技能”（指针）
↓ 调用一个技能
③ 技能（其SKILL.md）
— 如何使用一个能力；声明它由哪些MCP服务器和哪些CLI命令构建而成
↓ 执行
④ MCP服务器 + 命令行工具（执行，不加载到上下文中）
关键纪律： 子Agent可以看到一大块全局和本地技能，但看到≠应该使用。其系统提示必须明确缩小范围（“你的工作主要使用技能X / Y”），这样它就不会随机抓取工具。
理念4 · 单一事实来源 + 指针；宪法永不膨胀
CLAUDE.md 只保留最关键、最清晰的内容：角色定义、运营/管理/编排原则、流水线主干（步骤序列）和文件映射。所有具体的常识/单一事实来源下沉到 documentation/ 下的独立文档中；宪法只持有一个指针和一行上下文。 同样，将角色细节推入每个子Agent的系统提示中——CEO不需要知道如何工作，只需要知道它存在；当CEO需要细节时再读取该SP。
原因：
CLAUDE.md在每次交互中都驻留在上下文中。写在其内部的细节 = 作为开销携带，每次调用都在消耗Token。
理念5 · 两层能力分层：全局（复用）vs 本地（构建）
每个宪法将能力一分为二，并告知子Agent边界：
- 全局（复用，非本店构建）： 所有项目共享的技能 / MCP / 子Agent（消息能力、图像生成器、研究助手、各种操作Agent）。直接调用，零构建成本。
- 本地（为此项目构建/复刻）： 项目专用CLI、项目技能、项目子Agent。
- ⚠️ 范围陷阱： 作用域限定于另一个项目目录的技能将不会在此处自动加载；请复刻一个裁剪过的副本或调用全局等价物。在生成的宪法中声明这一点。
理念6 · 反思与自我迭代始终是最后一步 — 并且有两个循环
每个流水线的主干都以 反思与自我迭代 结束：回顾本轮周期的缺陷 + 效率 → 归因根因 → 派发维护Agent来升级流程 → 巩固。目标是稳步将“仍在飞行中决定”转变为“现在冻结成确定性函数。” 没有自我迭代审查 = 循环未闭合。 存在两个不同的循环；宪法必须将它们分开：
- 循环A — 每周期反思（每次流水线运行结束时）→ 写入
reflections/（永久；绝不会放入会被清理的构建目录）。 - 循环B — 跨会话异步审查：一个定时任务将数据/分析报告写入
reports/；下一个会话的启动仪式扫描reports/，采纳/丢弃，然后归档。加上一个HANDOFF注释在会话之间传递未完成的工作。
理念7 · 宪法即代码：确定性自检确保声明 == 现实
宪法会漂移：它声称“9个子Agent，7个技能”，而文件系统却显示其他内容。因此，每个项目都附带一个确定性的**doctor / 一致性检查命令，检查文档声称的内容与实际存在的内容（Agent、技能、CLI子命令、资产数量、生命周期数据库）是否一致，并在出现漂移时以非零退出**。这是“传播一致性”规则的机器后盾：任何叶子更改（CLI / 技能 / SP / 模板）在完成之前，都必须重新确认上层合约 — 而 doctor 机械地强制执行它。
理念8 · 标准形状（根宪法 + documentation/）
项目文件夹从创建之初就具有固定形状：
<project>/
├── CLAUDE.md ← 宪法：原则 / 主干 / 指针 / 映射（驻留在上下文中）
├── documentation/ ← 每个单一事实来源 / 常识 / 配置（按需加载）
│ ├── configuration.json 品牌结构化配置（单一事实来源）
│ ├── INITIALIZATION.md 一次性首次部署设置
│ ├── reflection_playbook.md 反思步骤的分步指南
│ ├── <playbook>.md 主题操作手册（质量门控 / 主题SOP / 合规 / …）
│ └── …
├── .claude/agents/ ← 子Agent系统提示（角色定义）
├── .claude/skills/ ← 每个 SKILL.md（能力定义）
├── <core>.py / <core>/ ← 确定性CLI代码（执行，不放入上下文）
├── reflections/ ← 每周期反思报告（永久）
├── reports/ ← 异步数据/分析报告（会话开始时消费）
├── HANDOFF.md ← 跨会话的未完成工作交接
├── CHANGELOG.md
└── <lifeline>.db ← 生命周期记忆存储（被git忽略）
B. 运行一次此技能交付的内容
| 交付物 | 路径 | 内容 |
|---|---|---|
| 项目宪法 | <project>/CLAUDE.md | 从 templates/CLAUDE.md.template 填充（简洁，基于指针）。 |
| 品牌配置 | <project>/documentation/configuration.json | 从 templates/configuration.json.template 填充。 |
| 初始化文档 | <project>/documentation/INITIALIZATION.md | 凭据检查清单 + 一次性部署步骤（骨架）。 |
| 主题单一来源文档 | <project>/documentation/<topic>.md | 访谈中识别出的、不属于宪法的规则（每个文件一个主题）。 |
| 空骨架 | .claude/agents/, .claude/skills/, reflections/, reports/, HANDOFF.md | 创建目录 + 每个目录中一个 .gitkeep 或 README 占位。 |
未生成： 业务代码、真正的子Agent SP内容、真正的技能实现 — 这些在项目存在后才会增长。此技能只生成注册表 + 骨架 + 占位符，提前在
CLAUDE.md中注册哪些角色和能力应该存在。
C. 交互协议（入职访谈）
在生成之前完成访谈。轮次提问；尽可能提供多项选择选项，以尽量减少用户的输入。每轮之后，回显答案以确认，然后继续。目标：填充模板中的每个 {{placeholder}}。
访谈者的效率规则：
- CEO模型、五/六个核心规则以及四层架构是所有项目中的常量— 不要为它们进行访谈；它们已从模板中预先填充。
- 对于全局能力，首先自动调查宿主环境（检查您的运行时暴露的可用技能/子Agent类型/MCP服务器），并提出一个供用户确认或裁剪的复用列表 — 不要要求用户从记忆中回忆。
- 批量处理相关问题（每次最多约4个）。目标是3-4轮完成，而不是7轮。
第0轮 · 项目原型（选择流水线模板分支）
询问项目属于哪种原型；每个原型预加载不同的主干草稿：
| 原型 | 典型主干（预加载草稿，然后与用户一起调整） |
|---|---|
| 内容 — 视频/频道 | 话题 → 脚本 → 渲染 → 发布 → 互动/评论 → 反思 |
| 内容 — 电子书/出版 | 论点 → 写作 → 编译 → 多渠道分发 → 营销 → 优化 → 反思 |
| SEO流量资产（工具站/维基） | 话题 → 构建 → 发布 → 变现 → SEO/监控 → 反思 |
| Web产品/网站 | 需求 → 设计 → 构建 → 测试 → 部署 → 监控 → 反思 |
| 休闲游戏 | 概念 → 资源生产（大批量并行） → 构建 → 测试 → 发布 → 数据调优 → 反思 |
| 其他（自定义） | 从头开始共同设计分步流程 |
第1轮 · 使命、北极星和红线
- 一句话使命（成为CEO的北极星）。
- 3-5条按优先级排序的不可协商约束（更早的总是优先于更晚的）。引导用户思考链条（例如“账户安全 > 内容质量 > 数量 > 速度 > 单位收入”）。
- #1铁律 / 合规红线（如果有的话：“违反它就一切都白费”——例如平台反垃圾、市场反AI泛滥、服务条款）。
- 禁止事项（两个层级）： 禁止（可使整个项目无效的红线行动） vs 不鼓励（除非有正当理由，否则避免）。这些填充模板的禁止事项部分，与规则部分并列。
第2轮 · 品牌（→ configuration.json）
- 品牌/代号？归属实体（真实姓名？笔名？公司？）？按语言区分？
- 标语 / 口号？
- 徽标资产（是否有现有资源）？
- 设计语言： 主色调、字体、语气关键词、视觉风格、禁忌。
- 信任 / E-E-A-T 锚点（网站/作者身份）？
- 支付/账户实体（如果涉及变现）？
第3轮 · 流水线主干（分步进行）
- 从原型草稿开始，确定每个步骤：它做什么 → 其输出 → 主导角色。
- 标记哪些步骤可以并行运行（展开点）。
- 确认最后一步 = 反思与自我迭代。
第4轮 · 角色（子Agent拆分）+ 全局/本地能力
- 每个固定步骤一个子Agent：名称 + 一行角色描述 + 属于哪个步骤。
- 必须始终有一个
dev-maintainer（拥有所有代码/SP/技能更改）。 - 应用反扩散规则：除非一个工件具有不同的依赖关系，否则首选一个共享的维护者。
- 确认自动调查的全局复用列表；列出需要构建/复刻的本地技能 — 对于每个本地技能，说明它由哪些MCP服务器和哪些CLI命令构建而成（理念3，第③层）。
- 对于每个子Agent，指明它主要应使用哪些技能（其SP中的指针）。
第5轮 · 生命周期记忆 + 单一来源文档 + 阶段/凭据
- 项目需要什么样的长期记忆存储（资产组合数据库 / 去重向量存储 / 进度账本…）？有哪些字段？
- 哪些规则是“单一事实来源”，应该各自成为一个
documentation/<topic>.md？（合规、主题SOP、质量门控、定价、启动纪律…）注册每个。 - 当前阶段？启动节奏 / 风险纪律？
- 用户必须提供哪些私有凭据 / 外部账户（→ INITIALIZATION.md）？
- “仅有的两个停止并向用户提问的原因”的边界（缺少凭据 / 主观商业判断）。
访谈完成后，回显每个已填充的关键字段，并在写入任何文件之前进行确认。
D. 生成规则
- 复制
templates/CLAUDE.md.template，替换每个{{…}}，删除不适用的可选部分。
...
[为翻译而截断]