149 lines
6.2 KiB
Markdown
149 lines
6.2 KiB
Markdown
# 五库重构总纲
|
||
|
||
```yaml
|
||
created: 2026-06-15
|
||
scope: ccpe-system / knowledge-vault / writing-workbench / video-workbench / skills-vault
|
||
purpose: 为后续分项目细化调整提供共同上下文
|
||
status: adjustment-brief
|
||
```
|
||
|
||
## 1. 本次小结的核心判断
|
||
|
||
这次调整不是推翻五库拆分，而是修正 `writing-workbench` 的期待边界。
|
||
|
||
原来对深度创作的设想偏工程化：希望用目录、模板、上下文包、提纲版本、评审轮次和 Runtime 把深度文章生产拆成可执行流程。实践后发现，深度创作的关键部分不是稳定流程，而是大量尚未显性的个人判断规则：
|
||
|
||
- 什么材料只是背景，什么材料真正支撑文章命题。
|
||
- 什么时候继续讨论观点，什么时候进入写作项目。
|
||
- 什么时候需要真实调用评审者，什么时候主会话辅助判断足够。
|
||
- 提纲问题是结构问题、立意问题、材料问题，还是读者可见性问题。
|
||
- 自动化应该在哪里停止，等待人工确认。
|
||
|
||
因此，深度创作目前不能被理解为“全流程自动化生产线”。更准确的定位是：
|
||
|
||
```text
|
||
knowledge-vault = 长期知识源、讨论归档、隐形规则显影处
|
||
writing-workbench = 已决定写作后的项目现场、过程记录和辅助场地
|
||
ccpe-system = 专家智能体、Runtime、Model Card、协议的工程化车间
|
||
video-workbench = 从深度文章/模型降维为视频包的独立生产场地
|
||
skills-vault = 可测试、可安装、可复用的小型自动化工具源头
|
||
```
|
||
|
||
## 2. 这次转向
|
||
|
||
### 从“自动写作流程”转向“人工导演 + 文件化辅助”
|
||
|
||
`writing-workbench` 仍然有价值，但不能承载从灵感、观点讨论、材料显影到文章完成的全部过程。它应从“自动化流水线”收缩为：
|
||
|
||
- 文章项目已经成立后的承接空间。
|
||
- 保存本篇文章使用的材料压缩稿、source-map、阶段产物和过程记录。
|
||
- 在需要时为主笔、评审者、Metadata、模型提炼准备上下文包。
|
||
- 记录人工确认门和决策轨迹。
|
||
|
||
### 从“讨论归档历史化”转向“article-discussions 继续活跃”
|
||
|
||
`knowledge-vault/discussions/article-discussions` 不应被简单历史化。深度创作中的观点生成、隐形规则提炼、多智能体讨论和失败案例复盘，仍然应留在 `knowledge-vault` 的讨论层。
|
||
|
||
`writing-workbench` 不应抢走讨论基地职责。它只承接“本篇文章已经决定要写”之后的项目化材料和阶段产物。
|
||
|
||
### 从“流程完整性”转向“复杂度通过真实边界验证”
|
||
|
||
复杂结构不是问题，问题是复杂结构没有真实执行边界。例如：
|
||
|
||
- 主会话模拟张辽、认知显影、巨人认知，却误以为完成了真实评审。
|
||
- dispatch pack 只是任务说明，却被当成 canonical agent 的完整启动包。
|
||
- 材料处理从摘要升级到 topic docs、routing、model-mining，却没有下游用途和停止条件。
|
||
|
||
新的原则是：每增加一层复杂度，都要通过四个检查：
|
||
|
||
```text
|
||
必要性：这层是否解决真实问题？
|
||
真实性：是否真的调用了对应角色/工具/流程？
|
||
可追溯性：结果能否回到来源、上下文和决策？
|
||
下游用途：产物是否有明确消费者？
|
||
```
|
||
|
||
## 3. 后续分项目调整的共同规则
|
||
|
||
### 规则一：不要把深度创作强行自动化
|
||
|
||
深度创作属于高不确定性、强人工判断、长上下文协商工作。AI 可以做辅助，但不能默认替代立意、取舍、采纳、放弃、发表判断。
|
||
|
||
### 规则二：Runtime 不等于自动化
|
||
|
||
在 CCPE 中，Runtime 可以是交互式协议。它的价值不一定是自动跑完，而是明确：
|
||
|
||
- 阶段
|
||
- 输入输出
|
||
- 参与者
|
||
- 文件落点
|
||
- 人工确认门
|
||
- 停止条件
|
||
- 不允许模拟的正式角色输出
|
||
|
||
### 规则三：讨论过程仍然是资产
|
||
|
||
单智能体时代保留讨论稿不是坏习惯，它反映了深度工作需要过程记忆。迁移到 Agentic Engineering 后，目标不是删除讨论过程，而是区分：
|
||
|
||
```text
|
||
完整讨论过程 -> knowledge-vault/discussions
|
||
本篇文章消费的材料 -> writing-workbench/projects/.../materials
|
||
可复用规则/模型 -> knowledge-vault/rules 或 ccpe-system/model-cards
|
||
可自动执行的小工具 -> skills-vault
|
||
```
|
||
|
||
### 规则四：先显影隐形规则，再工程化
|
||
|
||
现在最重要的工作不是立刻重构所有目录和模板，而是把隐形规则显影出来。只有稳定、重复、可验证的规则，才进入：
|
||
|
||
- `ccpe-system` 的 Agent / Runtime / Model Card
|
||
- `skills-vault` 的自动化 Skill
|
||
- `knowledge-vault/rules` 的人类可读模型文档
|
||
- `writing-workbench` 的项目操作模板
|
||
|
||
## 4. 后续使用方式
|
||
|
||
当你进入某个具体项目继续调整时，建议提供三份上下文：
|
||
|
||
```text
|
||
1. 本总纲：
|
||
C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\technology\Codex\0.规划与重构\2026-06-15\00-五库重构总纲.md
|
||
|
||
2. 对应项目调整意见：
|
||
同目录下对应项目文件
|
||
|
||
3. ChatGPT 的总结：
|
||
C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\technology\Codex\0.规划与重构\0.环境规划2026-06-15.md
|
||
```
|
||
|
||
如果具体项目已有入口文档，还应让新会话先读该项目自己的 README / AGENTS / WORKBENCH / handoff 文件。总纲只提供跨项目判断，不替代项目内现状。
|
||
|
||
## 5. 建议调整顺序
|
||
|
||
建议不要同时在五个项目里大改。顺序如下：
|
||
|
||
```text
|
||
1. knowledge-vault
|
||
先确认 article-discussions、viewpoint-development、rules、skills 的边界。
|
||
|
||
2. writing-workbench
|
||
收缩定位，改成“已决定写作后的项目现场”，修订 README / WORKBENCH / playbook。
|
||
|
||
3. ccpe-system
|
||
修订文章相关 Runtime 和 Agent 路线，强调交互式、人工确认、no-simulation。
|
||
|
||
4. video-workbench
|
||
保持独立，不被 writing-workbench 的收缩误伤；它更适合结构化生产。
|
||
|
||
5. skills-vault
|
||
只接收稳定、可测试、低不确定性的自动化工具，不接收深度创作主流程。
|
||
```
|
||
|
||
## 6. 最重要的边界句
|
||
|
||
```text
|
||
深度创作不是不能被支持，而是不能被提前自动化。
|
||
```
|
||
|
||
这句话应成为后续调整 `writing-workbench`、`ccpe-system` 和 `knowledge-vault` 关系时的主判断。
|