32 KiB

Raw Blame History

Codex 上下文注入稿：CCPE / writing-workbench / video-workbench / skills-vault 当前规划总结

0. 本摘要用途

这是一次围绕 CCPE System、writing-workbench、video-workbench、knowledge-vault、skills-vault 的阶段性规划总结，用于后续在 Codex 中继续讨论项目结构、工程边界和下一步改造。

本摘要不展开 HiFi Agent Studio 的整体方法论，只聚焦当前几个具体工程项目的判断：

深度创作流程在 Agentic 化时遇到的问题，为什么原本预期在 writing-workbench 上推进的工作暂时难以顺利开展。
为什么自动化更适合优先落在降维输出流程，例如 video-workbench。
CCPE System 目前还需要补充哪些工程治理内容。
CCPE System 与 skills-vault 的边界和协作关系。

1. 当前背景

用户过去有一套成熟的深度创作流程，主要基于 Web 单智能体环境运行。

这个流程已经长期实践，用户用它产出了 200 多篇深度文章，总量超过 100 万字。流程中曾经存在 40+ 个不同功能的 Agent / Prompt / 角色，例如主笔、红队评审、认知结构检测、巨观模型评审、降维输出导演等。

过去的 Web 单智能体流程，本质是用户本人作为主控 Runtime：

用户决定什么时候调用哪个角色；
用户决定某个角色是否延续会话；
用户判断上下文是否污染；
用户判断哪些评审意见值得采纳；
用户判断韩愈是否直接修复提纲，还是先出修订计划；
用户判断张辽是否需要继续追问；
用户判断什么时候进入正文、什么时候回炉立意。

在 Web 环境中，这些隐性判断由用户本人承担，所以流程表面上看起来成熟、自然、可控。

但在 Codex / Claude Code 这类 Agentic 环境中，流程必须外显为：

文件；
状态；
输入输出协议；
invocation packet；
prompt-to-send；
returned output；
human gate；
authority；
runtime state；
stop rule；
audit；
trace；
artifact contract。

因此，用户原本以为只是把一两个成熟写作环节搬到 Agentic 下自动化，实际却变成了：把长期由用户本人承担的“人肉 Runtime”显性化、协议化、可追踪化、可防伪化。

这造成了显著的复杂度跃迁。

2. 深度创作流程目前遇到的问题

2.1 writing-workbench 的原始期望

用户原本设想在 writing-workbench 中改造深度创作流程中的一两个关键环节，尤其是：

观点素材进入立意；
韩愈生成提纲；
张辽、认知显影、巨人认知等角色对提纲评审；
用户裁决；
韩愈修复提纲；
必要时多轮循环。

这个流程在 Web 单智能体时代已经多次跑通，用户认为它只是一个成熟流程的 Agentic 迁移。

2.2 第一次尝试：写作提纲评审流程改造失败

第一次尝试的目标是抽取“提纲评审小闭环”。

旧流程大致是：

用户给出提纲；
张辽进行红队评审；
认知显影进行认知结构检测；
巨人认知进行宏观模型评审；
用户综合意见；
韩愈修复提纲；
视情况循环。

在 Codex 中测试时，原本计划生成 dispatch pack，分发给各个评审员，然后收集 report。

但真正失败点不是目录、文件或流程结构，而是 真实调用边界是假的：

dispatch-pack.md 只是任务说明，不等于真正的 agent invocation packet；
主会话读取张辽、韩愈、认知显影、巨人认知的 prompt 后，模拟生成了各自的输出；
所谓张辽 report、认知显影 report、巨人认知 report，并非来自独立 Agent / Thread / Sub-session；
它们只是主会话在同一上下文里角色扮演的结果；
这不符合“多智能体独立评审”的验证目标。

所以第一次尝试被判定为无效。

关键教训：

多 Agent 流程的价值来自真实独立视角，而不是主会话模拟多个角色。正式评审报告必须来自真实 invocation，并具备 invocation record。主控会话只能 orchestration、routing、synthesis、bounded verification，不能冒充 Agent 输出。

由此产生了后续规则：

dispatch pack 不等于 invocation packet；
如果外部平台运行，需要生成 prompt-to-send.md；
正式报告必须有 canonical prompt 路径、输入上下文、执行载体、returned output；
如果无法真实调用，应停在 blocked_waiting_for_participant_output 或 prompt-to-send 状态；
模拟输出必须标记为 simulation_only: true、formal_output: false、excluded_from_synthesis: true。

2.3 第二次尝试：素材提炼流程成功但 ROI 失控

第二次尝试是在 knowledge-vault 中围绕 viewpoint-discussion-distillation 做长讨论蒸馏。

原始材料大约 5 万字，是一次 7 回合的长讨论。用户希望：

打造一个拆解讨论稿的流程 / Skill；
用这个流程拆解讨论稿；
将拆解结果作为后续写文章、优化模型或其他任务的基础。

最初的旧方法是 chunk-first：

先把材料按 R01-R07 分块；
各 worker 做局部 topic discovery；
再试图把局部 topic 拼成整体结构。

这个方法暴露出“盲人摸象”问题：

每个 worker 的局部观察可能是真的；
但整体主题、主轴、层级、模型演化线会被误判；
局部真实容易冒充整体结构。

后续改造引入了 Whole-Source Gestalt Alignment：

如果源材料仍处于高上下文模型可承载范围内，应先完整阅读；
先判断源材料是 coherent、mixed、fragmented；
coherent source 先建立全局画像、核心张力、主结构、模型演化线、层级风险；
mixed source 先宏主题拆分；
fragmented source 不强行制造层级，采用 flat discovery。

第三轮流程最终完成了：

source-map；
whole-source gestalt；
topic map；
material routing log；
topic docs；
coverage audit；
distortion risk log；
human confirmation；
downstream handoff。

从方法论上看，这次流程是成功的，因为它修复了 chunk-first 的结构误判，并建立了可追溯的知识加工链条。

但从 ROI 看，它非常不划算：

原始稿只有 5 万字；
用大上下文模型其实可以直接整理；
这次多轮流程累计消耗约 3000 万 tokens；
这不是“蒸馏一篇讨论稿”的正常成本；
更准确地说，这是在构建并验证一套知识加工 Runtime 的系统建设成本。

关键判断：

第二次不是纯粹“大炮打蚊子”，而是用一只蚊子测试了造炮厂、炮兵训练手册、弹道审计制度和战后复盘体系。问题不是流程完全没价值，而是把“系统建设成本”误记成了“单次内容处理成本”。

2.4 深度创作流程为什么暂时难以继续大规模推进

深度创作流程的核心不是简单文本生产，而是高不确定性判断。

它涉及：

观点是否成立；
立意是否值得写；
切入角度是否正确；
提纲结构是否承载了主命题；
哪些评审意见值得采纳；
哪些意见只是角色风格导致的噪音；
上下文何时污染；
何时应该重启会话；
模型是否应该升层；
附录脚手架是否需要前置；
文章是否进入正文阶段。

这些都不是纯 P 域的工程求解，而是 P / I 混合任务。它们不是不能 Agentic 化，而是不能一上来就 Full Runtime 化。

当前 writing-workbench 的大问题是：

用户原本以为是在自动化成熟写作流程中的一两个环节；实际上 Codex 要求用户先把大量隐性专家判断显性化为协议、状态、调用边界和人工决策门。这使得原计划的 writing-workbench 改造暂时难以顺利开展。

因此，深度创作流程下一步不宜继续追求完整自动化，而应转向最小真实闭环。

建议的最小闭环：

输入观点素材；
生成 premise-context-pack；
真实调用韩愈，输出立意 / 提纲；
真实调用张辽，输出评审；
用户做 decision record；
真实调用韩愈，输出修复版；
保存 invocation records；
停止。

先不要同时上：

认知显影；
巨人认知；
多轮 committee；
完整正文；
附录脚手架；
coverage audit；
downstream model mining。

核心目标不是完整写作自动化，而是验证：

一个真实主笔 + 一个真实红队 + 一个用户裁决 + 一次修复回合，能否在 Codex 下可靠运行。

3. 自动化更适合优先放在降维输出上，例如 video-workbench

3.1 深度创作与降维输出是两套流程

用户过去的工作中，深度创作和降维输出本来就是两套流程：

深度创作负责“发电”：形成复杂观点、文章、模型、思想结构；
降维输出负责“输出”：把深度文章的一两个点转成视频、PPT、口播、短内容、多模态素材。

规划上也应该拆成两个项目：

writing-workbench：深度创作；
video-workbench：降维输出、多模态内容生产。

它们不应混成一个 Runtime。

3.2 降维输出流程更适合 Agentic 自动化

用户已有降维输出流程，大致是：

阶段 0：剧集统筹与架构；
阶段 1：破题提案，给出 3 个切入角度；
阶段 2：定基调与总纲；
阶段 3：搭分镜逻辑骨架；
阶段 4：音画深潜产出；
阶段 5：自动生成图片、配音，图生视频暂时人工或半人工；
阶段 6：剪辑，人工；
阶段 7：发布，暂时人工。

这个流程和深度创作相比，更适合自动化，因为：

阶段边界清楚；
成功标准更外显；
验收更容易；
低判断、高摩擦的环节多；
文件型产物多；
工具链明确；
错了容易改；
对核心思想质量的伤害较小。

可自动化的部分包括：

长文拆点；
文章模型提炼；
剧集拆分建议；
单集时长预算；
1 分钟约 220 字的字数控制；
破题角度候选；
视频总纲；
分镜骨架；
分镜深潜；
配音稿；
生图提示词；
TTS 文本拆分；
音频生成；
图片生成；
文件命名和素材归档；
剪辑清单；
平台标题、简介、标签候选。

保留人工裁决的部分包括：

是否拆系列；
选哪个破题角度；
总体基调；
核心隐喻；
分镜骨架是否通过；
重要画面风格；
图生视频抽盲盒选择；
最终剪辑；
是否发布。

因此，当前更建议把自动化优先级放在 video-workbench，而不是继续强攻 writing-workbench 的深度创作核心。

3.3 video-workbench 的推荐定位

video-workbench 可以作为 Agentic MVP：

输入：

一篇深度文章；
关联 model card / rules；
目标平台；
目标时长；
是否系列化。

输出：

剧集拆分建议；
EP.01 三个破题提案；
用户选择记录；
视频总纲；
分镜骨架；
分镜深潜产出；
配音稿；
生图提示词；
TTS 文本文件；
图片生成清单；
音频生成清单；
剪辑清单；
发布文案候选。

video-workbench 更像生产工坊：P 域为主，少量 I 域。它适合用“模板化生产 + 人工抽检 + 关键决策门”的方式自动化。

4. CCPE System 当前还需要补充的内容

CCPE System 的核心定位不变：

CCPE 是用于设计、审计、重构和维护 Prompt、Agent、Skill、Workflow、Runtime Protocol、Cognitive Model assets 的上下文协议工程框架。

它的核心原则仍然是：

不要把所有 AI artifact 都当成 Prompt。第一任务是分类，第二任务是结构诊断，第三任务才是创建或重构。

现有分类包括：

CCPE-Lite；
CCPE-Agent；
CCPE-Skill；
CCPE-Runtime；
Model Card；
Model Index。

但基于最近几轮实践，CCPE 需要补充 Agentic 工程治理层，尤其是以下内容。

4.1 Project Intake / Mode Selector

每次任务启动前必须先分诊：

QPI 定性：
- Q：信息缺失；
- P：路径 / 转换 /生产问题；
- I：秩序、权衡、共识、责任问题。
任务性质定性：
- 一次性内容产出；
- 可复用能力沉淀；
- 治理级系统建设；
- 模型校准；
- 探索预演。
复用级别：
- one-off；
- reusable；
- governed。
运行档位：
- Lite；
- Standard；
- Full。

默认必须从 Lite 开始，只有被证据推动才升级。

4.2 Lite / Standard / Full

Lite

适用：

一次性任务；
低风险；
单模型可处理；
不需要真实多 Agent；
不需要完整追踪审计；
下游不依赖中间过程。

产物：

目标输出；
简短输入记录；
人工确认；
可选抽样检查。

禁止：

默认多 Agent；
默认 coverage audit；
默认 topic docs；
默认 downstream handoff；
默认 full runtime。

Standard

适用：

未来会复用；
有明确下游消费；
需要上下文包、结构化产物、局部追踪；
少量真实 Agent / Worker 调用；
有关键 human gate。

产物：

source/context pack；
confirmed structure；
reusable output artifacts；
decision record；
targeted audit；
minimal invocation record。

Full

适用：

多角色；
多来源；
高风险；
可追责；
长周期；
外部客户交付；
后续自动化强依赖过程真实性；
需要全链路审计。

产物：

full runtime；
invocation records；
authority map；
state machine；
coverage audit；
distortion-risk log；
recovery protocol；
downstream handoff。

4.3 Cost Ledger

必须区分四类成本：

Content Cost：内容产出成本；
System-Building Cost：系统建设成本；
Calibration Cost：模型校准 / 反馈修复成本；
Exploration Cost：探索预演成本。

红线：

禁止将系统建设成本伪装为单次内容任务成本。

这条直接来自 3000 万 tokens 事件。

如果一次 5 万字讨论稿蒸馏消耗 3000 万 tokens，不能简单记为“内容蒸馏成本”。应拆分为：

内容产出；
Runtime 原型建设；
no-simulation protocol 验证；
whole-source gestalt 流程验证；
worker / coverage audit 测试；
Agentic 边界探索。

4.4 Scope Drift Detector

系统必须识别任务漂移。

触发信号包括：

一次性任务开始创建通用 Protocol；
开始新增 Agent / Skill / Runtime；
开始设计未来复用目录结构；
原始产物迟迟不交付，系统却持续生成 routing log、coverage audit、handoff；
Lite 任务擅自派发多个 worker；
P 域任务滑入 I 域治理；
token 预算穿透；
开始讨论 invocation、authority、state、audit。

一旦触发：

挂起；
重问：我们还在做原始任务吗？
如果不是，是否正式立项为系统建设？
重做 QPI 和 Mode Selector；
重新分账；
人类确认后再继续。

4.5 Execution Authenticity

正式多 Agent / Worker 输出必须有真实调用证据。

最小 invocation record 包括：

agent / role id；
canonical prompt 或 Agent Spec 路径；
invocation carrier；
thread / sub-session id；
input context；
returned output；
timestamp；
output 是否进入 synthesis。

主控会话只可：

orchestration；
routing；
synthesis；
bounded verification。

主控会话不可：

冒充独立 Agent；
代写 reviewer report；
代写 worker extraction；
将 prompt-only / packet-only 阶段标记为 executed；
在没有真实返回时补写正式输出。

无法真实调用时，应停止在：

blocked_waiting_for_participant_output；
或生成 prompt-to-send.md 等待外部平台执行。

4.6 Simulation Labeling

所有模拟产物必须显式标记：

simulation_only: true
formal_output: false
excluded_from_synthesis: true

模拟可以用于：

价值流验证；
绿野仙踪阶段；
人类参考草稿。

模拟不得用于：

正式评审报告；
正式 worker output；
正式 synthesis；
downstream handoff；
coverage audit 依据。

4.7 Stop Rule

每个 Runtime 启动前必须定义：

最小可用产物；
sufficient criteria；
optional artifacts；
human gate；
budget ceiling；
stop condition；
escalation condition。

系统不得因为“还能继续生成中间物”就继续扩展。

当已达到下游可消费状态时，应停止并交还人类控制。

4.8 Human Gate Contract

人工确认不能只写“等待用户确认”，必须结构化。

每个 Human Gate 应包含：

gate_id；
decision_owner；
input_artifacts；
decision_options；
default_action；
downstream_effect；
reversibility；
escalation_condition；
record_path。

这能防止 human-in-the-loop 变成装饰性签字。

4.9 Authority Matrix

每个 Agent / Skill / Runtime node 需要权限等级：

A0 Observe；
A1 Suggest；
A2 Draft；
A3 Modify；
A4 Decide；
A5 Execute；
A6 Block。

尤其需要拆分 A5：

A5-R：只读工具；
A5-W：写文件 / 改代码；
A5-X：外部 API / 发布 / 删除 / 客户可见动作。

A5-X 默认禁止自动执行，必须经过 Human Gate 或明确 Runtime 授权。

4.10 Runtime State Protocol

Runtime 需要标准状态：

initialized；
running；
blocked_waiting_for_human；
blocked_waiting_for_participant_output；
blocked_waiting_for_tool；
paused_by_scope_review；
paused_by_budget_guard；
failed_recoverable；
failed_terminal；
completed；
aborted_by_human；
archived。

每次状态变化应记录：

previous_state；
new_state；
trigger；
responsible_actor；
timestamp；
next_allowed_actions。

4.11 Tool Safety / Data Safety / Retry / Rollback

CCPE / Agentic Engineering Handbook 应补充：

工具最小权限；
沙箱目录；
dry-run / preview；
action plan；
action log；
回滚路径；
密钥不得进入 prompt；
客户资料外发确认；
敏感数据脱敏；
重试上限；
repair plan；
rollback protocol。

这部分在 Agentic 工程里非常重要，因为系统不只是“会说”，还会改文件、调 API、生成素材、写代码、发布内容。

4.12 Context Compiler

高价值 P 域和 I 域任务不能直接把原始材料倾倒给所有 Agent。

需要 Context Compiler：

source digest；
task-specific context pack；
role-specific dispatch pack；
decision context；
source index；
evidence index。

对 coherent long source，应先 whole-source gestalt，再 segmentation。对 mixed source，应先 macro-topic split。对 fragmented source，应 flat discovery，不强行升层。

4.13 Source Fidelity / Evidence Index

正式输出中的关键判断必须能回溯至：

原始来源；
source range / paragraph / block id；
参与该判断的 Agent / Worker；
判断来源是原文、推理、归纳、用户裁决还是模型补充。

禁止：

把中间摘要当 source of truth；
把模型综合判断伪装成原始材料事实；
无来源地生成“看似很合理”的结论。

4.14 Evaluation Stack

不能只靠“看起来不错”。

评测应分层：

E0 Smoke Test；
E1 Format Test；
E2 Factual Test；
E3 Reasoning Test；
E4 Expert Similarity；
E5 Decision Utility；
E6 Calibration Test；
E7 Governance Test。

不同场景启用不同层级：

Lite：E0-E2；
Standard：E0-E5；
Full：E0-E7。

4.15 Platform / Plugin Governance

Codex、Claude Code、OpenClaw、SuperPowers 等平台 / 插件的默认流程不能覆盖 CCPE 的治理底线。

尤其是 SuperPowers 这类偏软件工程的方法论插件，可能天然倾向：

spec；
planning；
TDD；
subagent；
review；
audit；
repeated verification。

这对代码工程有价值，但对知识蒸馏和写作流程可能放大过度工程倾向。

需要规则：

非代码任务默认禁用重型软件工程插件；
除非任务已正式升级为系统建设；
插件输出不得自动成为正式产物；
插件自动触发不得绕过 Mode Selector；
项目应声明 allowed / blocked / manual_only skills。

SuperPowers 不是唯一元凶，但它可能放大了工程化惯性。核心问题仍然是入口分诊、Mode Selector、Scope Drift、Stop Rule 缺失。

5. CCPE 与 skills-vault 的差异

5.1 为什么新增 skills-vault

在 Codex 讨论中发现，有些已经做好的 Skill 并不隶属于 CCPE。

例如：

fix-title；
markdown heading 修复；
文件清洗；
引用检查；
报告导出；
批处理；
source splitter；
TTS 生成；
图片生成辅助。

这些 Skill 本质上是自动化脚本 / 工具，不是专家智能体，不拥有业务目标，也不需要作为 CCPE Agent / Runtime 的核心资产。

因此新增 skills-vault：

skills-vault 是 automation-oriented Skills 的源码仓库。

它存放：

SKILL.md；
scripts；
tests；
fixtures；
examples；
install notes；
migration records。

它不存放：

CCPE agents；
committees；
runtimes；
model cards；
model indexes；
cognitive model assets；
CCPE System 原有内容。

5.2 三个位置的区别

skills-vault

源码主仓库。

负责：

automation Skill 实现；
脚本；
测试；
fixtures；
示例；
安装说明；
版本迁移记录。

例子：

skills-vault/
  skills/
    fix-title/
      SKILL.md
      README.md
      scripts/
      tests/
      fixtures/

`.agents/skills`

本机运行安装面。

负责：

Codex / Claude Code / 本地 Agent Runtime 可调用的安装副本。

它不是 source of truth。不应直接在 .agents/skills 中长期维护源码。

ccpe-system

系统架构工作区。

负责：

expert agents；
CCPE-Lite prompt cards；
durable agent specs；
committees；
runtimes；
model cards；
model indexes；
cognitive / method / evaluation skills；
对重要 external automation skill 的架构登记。

5.3 automation Skill 与 CCPE-Skill 的区别

需要区分三类东西。

Automation Skill

归属：skills-vault

特点：

可安装；
可执行；
通常有脚本；
有测试；
行为较确定；
主要处理文件、格式、批处理、导出、转换；
不拥有业务目标。

例子：

fix-title；
markdown-normalizer；
citation-checker；
report-exporter；
source-splitter；
tts-batch-generator；
image-prompt-exporter。

CCPE-Skill

归属：ccpe-system

特点：

可复用能力模块；
不一定有脚本；
可能是方法、流程、检查清单、推理协议、评估规则；
可能承载认知模型；
可被多个 Agent / Runtime 调用；
与业务语义、认知结构、评估规则有关。

例子：

cognitive-imaging skill；
assumption-stress-test skill；
argument-chain-inspection skill；
model-mining skill；
evaluation skill。

Runtime Capability / Project Capability

归属：

ccpe-system/runtimes/；
或具体项目 runbook，如 knowledge-vault、writing-workbench、video-workbench。

特点：

多步骤；
多角色；
有状态；
有 human gate；
可能依赖多个 Agent 和 automation Skill；
有上下文工程、调用记录、审计、handoff。

例子：

viewpoint-discussion-distillation；
writing-outline-review；
video-episode-production；
knowledge-material-routing。

这类不应放进 skills-vault 当普通工具 Skill。

5.4 CCPE 是否需要登记 skills-vault 的 Skill

不是所有 automation Skill 都需要 CCPE 登记。

只有当某个 Skill 进入更大的 Agentic 系统时，才需要登记。

需要登记的情况：

某个 CCPE Runtime 调用它；
某个 Agent Spec 将它列为 required capability；
某个 committee 运行依赖它；
该 Skill 有明确 authority / safety / evaluation 规则；
它成为可重复 workflow 的固定部分；
它会写文件、调用 API、修改客户可见产物。

登记文件只记录架构元数据，不复制源码。

建议登记位置可以是：

ccpe-system/integrations/skills-vault/fix-title.registration.md

或：

ccpe-system/skills/tool/fix-title.external-skill.md

登记内容：

canonical_implementation: skills-vault/skills/fix-title
installed_path: C:\Users\xxx\.agents\skills\fix-title
skill_type: tool-skill / transformation-skill
used_by:
  - ...
authority:
  - may rewrite user-specified markdown file only
validation:
  - heading shift tests pass
safety:
  - dry-run recommended for canonical records
  - must not modify unrelated files
status: active

原则：

skills-vault 拥有 implementation source； CCPE 拥有 architecture registration； .agents/skills 是 runtime installation copy。

5.5 MCP 与 skills-vault 的关系

MCP 类似工具 / 外部能力接入层。

MCP 本身无需放进 CCPE 作为源码。但如果某个 Agent / Runtime 正式依赖某个 MCP server 或工具，就应在 CCPE 中登记其依赖关系。

登记内容类似：

canonical_implementation:
endpoint:
used_by:
authority:
allowed_operations:
forbidden_operations:
security_notes:
evaluation:
failure_behavior:

统一原则：

实现源码不进 CCPE；架构依赖进 CCPE；运行安装面不当 source of truth。

5.6 推荐边界句

可以把下面这句话作为以后判断归属的规则：

CCPE 资产拥有或组织业务目标；automation Skill 执行可复用动作。Skill 可以服务业务目标，但不自行定义业务目标。

更具体：

业务目标：Human / Agent / Runtime 决定
执行动作：Skill / Tool / MCP 完成
业务裁决：Human Gate / Runtime 决定
业务材料：Project Vault / Workbench 保存

6. 对现阶段项目的总体建议

6.1 writing-workbench：暂停 Full Runtime 化，改走最小闭环

不要继续把完整深度创作流程一次性 Agentic 化。

当前目标应降级为：

证明真实主笔调用；
证明真实红队调用；
证明 human decision record；
证明一次修复回合；
证明 invocation record；
停止。

不要默认上完整 committee、topic docs、coverage audit、正文生成、model mining。

6.2 video-workbench：作为优先自动化 MVP

优先把已有降维输出流程自动化：

文档拆分；
模型提炼；
剧集拆分；
破题提案；
视频总纲；
分镜骨架；
分镜深潜；
配音稿；
生图提示词；
TTS；
图片生成；
素材归档；
剪辑清单。

保留人工：

选题；
角度选择；
基调确认；
关键审美；
图生视频筛选；
剪辑；
发布。

这更符合 P 域生产工坊，ROI 更高，工程师也更容易跟进。

6.3 knowledge-vault：保留观点蒸馏能力，但增加 Lite / Standard / Full

viewpoint-discussion-distillation 的 Full 规格有价值，但不能默认运行。

应拆成：

Lite：单源讨论稿快速蒸馏；
Standard：可复用材料包；
Full：治理级知识加工 Runtime。

5 万字 coherent discussion 默认 Lite 或 Standard，不应默认 Full。

6.4 CCPE System：补 Agentic Engineering Handbook

CCPE 需要新增或整合一份工程守则，覆盖：

Project Intake；
Mode Selector；
Cost Ledger；
Scope Drift；
Execution Authenticity；
Simulation Labeling；
Stop Rule；
Human Gate Contract；
Authority Matrix；
Runtime State Protocol；
Tool Safety；
Data Safety；
Retry / Rollback；
Platform / Plugin Governance；
Evaluation Stack；
Context Compiler；
Source Fidelity；
Artifact Contract；
Runtime Maturity Model。

6.5 skills-vault：继续作为 automation Skill 源码仓

skills-vault 是必要的，不影响 CCPE 结构。

它是工具源码供应链，不是 CCPE 的替代品。

下一步建议：

只迁移 CCPE 外部 automation Skills；
不迁移现有 CCPE 内容；
每个 Skill 增加 authority、safety、validation、installation note；
可选增加 manifest；
只有被 Runtime / Agent 正式依赖时才在 CCPE 登记；
登记不复制源码。

7. 当前最关键的工作原则

以后在 Codex 中继续规划时，必须优先遵守这些原则：

先分类，再创建。 不要看到一个能力就写成 Prompt、Agent 或 Skill。先判断它是 Lite、Agent、Skill、Runtime、Model Card、external automation skill，还是 project capability。
默认 Lite，证据驱动升级。 不要一上来就 Full Runtime。
内容任务与系统建设任务必须分账。 如果任务从“产出内容”滑向“建造流程 / Runtime / Protocol”，必须暂停重定性。
正式多 Agent 输出必须真实调用。 主会话不能模拟 Agent report。
模拟产物必须隔离。 simulation-only 不得进入正式 synthesis。
达到最小充分产物就停止。 不要让系统无限生成中间物。
深度创作先保守协议化，不急着自动化。 writing-workbench 当前只验证最小真实闭环。
降维输出优先自动化。 video-workbench 更适合作为 Agentic MVP。
skills-vault 管工具源码，CCPE 管架构和认知资产。 不要混仓，不要复制源码。
MCP / CLI / API 是工具能力。 只有当被 Agent / Runtime 正式依赖时，才需要在 CCPE 做 architecture registration。

8. 下一步给 Codex 的建议任务

可以让 Codex 基于本摘要继续做以下工作：

任务 A：审查 CCPE System 是否需要新增 integrations 目录

目标：

ccpe-system/
  integrations/
    skills-vault/
    mcp/
    cli-tools/

用于登记 external automation skills、MCP、CLI 工具等架构依赖。

任务 B：更新 CCPE classification rules

加入三分法：

automation Skill -> skills-vault
CCPE-Skill -> ccpe-system
Runtime / Project Capability -> ccpe-system/runtimes or project runbook

任务 C：把 Agentic Engineering Handbook 合并进 CCPE operating rules

重点加入：

Project Intake；
Mode Selector；
Cost Ledger；
Scope Drift；
Execution Authenticity；
Stop Rule。

任务 D：为 skills-vault 增加 skill manifest 模板

建议字段：

name:
type:
category:
canonical_source:
installed_paths:
entrypoints:
authority:
side_effects:
safety:
tests:
ccpe_registration:
status:
version:

任务 E：为 writing-workbench 定义最小真实闭环

仅包含：

premise-context-pack
real Han Yu invocation
real Zhang Liao invocation
human decision record
real Han Yu repair
invocation records
stop

任务 F：为 video-workbench 定义 MVP Runtime

以降维输出生产线为主，自动化：

series planning
angle proposals
video outline
storyboard skeleton
deep shot output
voice script
image prompts
TTS batch
image batch
asset manifest
editing checklist

人工保留：

angle choice
tone confirmation
visual approval
editing
publishing

9. 最后的核心判断

当前不是方向错，而是入口任务性质被低估。

用户原以为是在自动化成熟写作流程，实际是在把长期由人承担的隐性判断外显成 Agentic Runtime。

因此：

writing-workbench 的深度创作核心要慢，先做真实调用与人工裁决边界；
video-workbench 的降维输出生产线要快，是更适合自动化的 MVP；
CCPE System 要补运行治理和外部工具登记机制；
skills-vault 要独立作为 automation Skill 源码仓；
MCP、CLI、API、automation Skill 都是工具供给层，不应混入 CCPE 认知资产，但被正式依赖时需要在 CCPE 登记。

一句话总结：

CCPE 负责“谁在什么边界下完成什么认知 / 业务任务”； skills-vault 负责“可安装、可测试、可迁移的自动化工具能力”； writing-workbench 先验证深度创作的最小真实闭环； video-workbench 优先承接高 ROI 的降维输出自动化。

32 KiB Raw Blame History Unescape Escape