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

169 lines
5.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# ccpe-system 调整意见
```yaml
created: 2026-06-15
project_path: C:\Users\wangq\Documents\Codex\ccpe-system
status: adjustment-brief
```
## 1. 当前判断
`ccpe-system` 的大方向是正确的:它不是普通提示词库,而是 AI 认知资产工程工作台。特别是它已经明确:
```text
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、人工确认门等问题。但它仍容易被后续会话理解为“把文章提纲生成与评审流程工程化跑通”。
新的判断是:
```text
文章相关 Runtime 应优先服务“交互式规则显影与辅助调度”,而不是追求自动化生产文章。
```
## 2. 建议调整
### 2.1 文章 Runtime 从“生产协议”降级为“交互式辅助协议”
建议后续修订文章相关 Runtime 时,把核心目标改为:
- 明确当前文章阶段。
- 明确哪些材料进入当前阶段。
- 明确哪些角色需要真实调用。
- 明确哪些输出只是草案,哪些是 canonical participant 的正式输出。
- 明确何处必须等待用户判断。
- 明确何时停止,而不是继续生成下一阶段。
Runtime 不应默认承担:
- 自动确定文章立意。
- 自动生成终稿提纲。
- 自动分发所有评审者。
- 自动综合并要求主笔修订。
- 自动进入正文写作。
### 2.2 保留 `article-context-architect`,但降低其自动化边界
`article-context-architect` 仍然有价值,因为材料过多时确实需要上下文工程角色。
但它应被明确限制为:
```text
上下文架构助手,而不是文章判断者。
```
它可以输出:
- source digest 草案。
- premise context pack。
- outline-aligned context pack。
- dispatch pack。
- 材料缺口和用户确认项。
它不应输出:
- 正式文章立意。
- 正式提纲评审意见。
- 主笔修复方案。
- 用户采纳决定。
### 2.3 把“真实调用边界”提升为文章 Runtime 的第一原则
应保留并强化 no-simulation 规则:
```text
不要模拟韩愈、张辽、认知显影、巨人认知等 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。现在建议暂停完整扩展。
更合理的路线是:
```text
1. 保留已有文章提纲 Runtime 作为实验性协议。
2. 用 Anti-Overengineering Gate 项目总结它的失败与边界。
3. 先抽象“深度创作人工确认门”和“真实调用边界”。
4. 再决定是否需要 Article Production Orchestrator。
```
### 2.5 新增一个更小的候选资产
相比完整生产 Runtime现在更需要一个小型判断协议
```text
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` 后,建议新会话先读:
```text
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` 的调整目标是:
```text
继续做认知资产工程,但不要把高不确定性深度创作提前自动化。
```
它应该把这次失败经验转化为更强的分类能力:
```text
Prompt / Agent / Skill / Runtime / Model Card 之外,还要先判断:
这是深度判断工作,还是可自动执行工作?
这是规则已显性化,还是规则仍在形成?
```