6.2 KiB
五库重构总纲
created: 2026-06-15
scope: ccpe-system / knowledge-vault / writing-workbench / video-workbench / skills-vault
purpose: 为后续分项目细化调整提供共同上下文
status: adjustment-brief
1. 本次小结的核心判断
这次调整不是推翻五库拆分,而是修正 writing-workbench 的期待边界。
原来对深度创作的设想偏工程化:希望用目录、模板、上下文包、提纲版本、评审轮次和 Runtime 把深度文章生产拆成可执行流程。实践后发现,深度创作的关键部分不是稳定流程,而是大量尚未显性的个人判断规则:
- 什么材料只是背景,什么材料真正支撑文章命题。
- 什么时候继续讨论观点,什么时候进入写作项目。
- 什么时候需要真实调用评审者,什么时候主会话辅助判断足够。
- 提纲问题是结构问题、立意问题、材料问题,还是读者可见性问题。
- 自动化应该在哪里停止,等待人工确认。
因此,深度创作目前不能被理解为“全流程自动化生产线”。更准确的定位是:
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,却没有下游用途和停止条件。
新的原则是:每增加一层复杂度,都要通过四个检查:
必要性:这层是否解决真实问题?
真实性:是否真的调用了对应角色/工具/流程?
可追溯性:结果能否回到来源、上下文和决策?
下游用途:产物是否有明确消费者?
3. 后续分项目调整的共同规则
规则一:不要把深度创作强行自动化
深度创作属于高不确定性、强人工判断、长上下文协商工作。AI 可以做辅助,但不能默认替代立意、取舍、采纳、放弃、发表判断。
规则二:Runtime 不等于自动化
在 CCPE 中,Runtime 可以是交互式协议。它的价值不一定是自动跑完,而是明确:
- 阶段
- 输入输出
- 参与者
- 文件落点
- 人工确认门
- 停止条件
- 不允许模拟的正式角色输出
规则三:讨论过程仍然是资产
单智能体时代保留讨论稿不是坏习惯,它反映了深度工作需要过程记忆。迁移到 Agentic Engineering 后,目标不是删除讨论过程,而是区分:
完整讨论过程 -> knowledge-vault/discussions
本篇文章消费的材料 -> writing-workbench/projects/.../materials
可复用规则/模型 -> knowledge-vault/rules 或 ccpe-system/model-cards
可自动执行的小工具 -> skills-vault
规则四:先显影隐形规则,再工程化
现在最重要的工作不是立刻重构所有目录和模板,而是把隐形规则显影出来。只有稳定、重复、可验证的规则,才进入:
ccpe-system的 Agent / Runtime / Model Cardskills-vault的自动化 Skillknowledge-vault/rules的人类可读模型文档writing-workbench的项目操作模板
4. 后续使用方式
当你进入某个具体项目继续调整时,建议提供三份上下文:
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. 建议调整顺序
建议不要同时在五个项目里大改。顺序如下:
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. 最重要的边界句
深度创作不是不能被支持,而是不能被提前自动化。
这句话应成为后续调整 writing-workbench、ccpe-system 和 knowledge-vault 关系时的主判断。