knowledge-vault/discussions/technology/Codex/0.规划与重构/2026-06-15/03-ccpe-system调整意见.md

ccpe-system 调整意见

created: 2026-06-15
project_path: C:\Users\wangq\Documents\Codex\ccpe-system
status: adjustment-brief

1. 当前判断

ccpe-system 的大方向是正确的：它不是普通提示词库，而是 AI 认知资产工程工作台。特别是它已经明确：

Runtime does not always mean automation.
Human-in-the-loop is first-class.
Scenario Probe before layering.

这次需要调整的不是 CCPE 的总体哲学，而是文章生产相关资产的目标表述。

此前围绕 article-outline-development.runtime.md 和 article-context-architect.agent.md 的设计，已经解决了真实调用、上下文包、no-simulation、人工确认门等问题。但它仍容易被后续会话理解为“把文章提纲生成与评审流程工程化跑通”。

新的判断是：

文章相关 Runtime 应优先服务“交互式规则显影与辅助调度”，而不是追求自动化生产文章。

2. 建议调整

2.1 文章 Runtime 从“生产协议”降级为“交互式辅助协议”

建议后续修订文章相关 Runtime 时，把核心目标改为：

• 明确当前文章阶段。
• 明确哪些材料进入当前阶段。
• 明确哪些角色需要真实调用。
• 明确哪些输出只是草案，哪些是 canonical participant 的正式输出。
• 明确何处必须等待用户判断。
• 明确何时停止，而不是继续生成下一阶段。

Runtime 不应默认承担：

• 自动确定文章立意。
• 自动生成终稿提纲。
• 自动分发所有评审者。
• 自动综合并要求主笔修订。
• 自动进入正文写作。

2.2 保留 article-context-architect，但降低其自动化边界

article-context-architect 仍然有价值，因为材料过多时确实需要上下文工程角色。

但它应被明确限制为：

上下文架构助手，而不是文章判断者。

它可以输出：

• source digest 草案。
• premise context pack。
• outline-aligned context pack。
• dispatch pack。
• 材料缺口和用户确认项。

它不应输出：

• 正式文章立意。
• 正式提纲评审意见。
• 主笔修复方案。
• 用户采纳决定。

2.3 把“真实调用边界”提升为文章 Runtime 的第一原则

应保留并强化 no-simulation 规则：

不要模拟韩愈、张辽、认知显影、巨人认知等 canonical participant 的正式输出。

如果当前环境不能真实调用对应参与者，只能生成：

• agent-invocation-packet.md
• prompt-to-send.md
• blocked_waiting_for_participant_output 状态

这条规则比“流程完整”更重要。

2.4 暂缓完整 Article Production Orchestrator

原来路线是先 Outline Review Runtime，再扩展到完整 Article Production Runtime。现在建议暂停完整扩展。

更合理的路线是：

1. 保留已有文章提纲 Runtime 作为实验性协议。
2. 用 Anti-Overengineering Gate 项目总结它的失败与边界。
3. 先抽象“深度创作人工确认门”和“真实调用边界”。
4. 再决定是否需要 Article Production Orchestrator。

2.5 新增一个更小的候选资产

相比完整生产 Runtime，现在更需要一个小型判断协议：

deep-creation-automation-boundary.protocol.md

它可定义：

• 哪些深度创作环节不可自动化。
• 哪些环节可由上下文工程辅助。
• 哪些环节可由自动化工具执行。
• 哪些输出必须标记为草案。
• 哪些输出必须来自真实 participant。
• 哪些节点必须人工确认。

这个资产可以先放在 workbench/analysis/，不急着进入 canonical runtime。

3. 暂缓事项

暂时不要做这些事：

• 不要把所有写作智能体升级为 Agent Spec。
• 不要把所有 Lite 都转换为 Skill。
• 不要继续搭完整 Article Production Runtime。
• 不要把深度创作的隐形规则直接写成自动化工作流。
• 不要让 CCPE 替代 knowledge-vault 中的讨论和规则显影。

4. 进入 ccpe-system 项目后的细化入口

进入 ccpe-system 后，建议新会话先读：

C:\Users\wangq\Documents\Codex\ccpe-system\README.md
C:\Users\wangq\Documents\Codex\ccpe-system\AGENTS.md
C:\Users\wangq\Documents\Codex\ccpe-system\workbench\upgraded\article-outline-development.runtime.md
C:\Users\wangq\Documents\Codex\ccpe-system\workbench\upgraded\article-context-architect.agent.md
C:\Users\wangq\Documents\Codex\ccpe-system\workbench\upgraded\agent-invocation-packet.protocol.md
C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\technology\Codex\0.规划与重构\0.环境规划2026-06-15.md

然后基于本文件细化：

1. 是否修订 article-outline-development.runtime.md 的目的和 Non-Goals。
2. 是否给文章 Runtime 增加“深度创作不可全自动化”的注记。
3. 是否新增 deep-creation-automation-boundary 分析稿。
4. 是否把 Anti-Overengineering Gate 的经验写入 CCPE 的 depth-vs-automation 规则。
5. 是否更新 model / runtime usage map。

5. 项目调整目标

ccpe-system 的调整目标是：

继续做认知资产工程，但不要把高不确定性深度创作提前自动化。

它应该把这次失败经验转化为更强的分类能力：

Prompt / Agent / Skill / Runtime / Model Card 之外，还要先判断：
这是深度判断工作，还是可自动执行工作？
这是规则已显性化，还是规则仍在形成？