195 lines
15 KiB
Markdown
195 lines
15 KiB
Markdown
# 1
|
||
|
||
## 背景
|
||
|
||
### 我的写作流程
|
||
|
||
```md
|
||
# 深度创作流程
|
||
|
||
这里涉及到写文章的工作流程，每个环节的产物。我将之前的从灵感到发布的全部过程梳理一下。
|
||
由于`knowledge-vault`知识库已经重构完成，我就按照新的知识库来模拟。
|
||
|
||
1. 产生灵感。我会记录下来。不论是PC还是手机，这个记录一般会进入`knowledge-vault/diary`
|
||
2. 确定观点。基于灵感，做深入洞察。这个主要在`knowledge-vault/discussions`中完成，可能会有多个智能体参与，会直接在不同平台上与LLM探讨，甚至会做Deep Research。
|
||
3. 确定创作。因为写文章需要一整段时间，且不是所有的观点都会进入写作。确定创作主要包括确定什么题材——用什么主笔智能体/skill，文章思路，选定的素材，是否要作为我已有的系列中后续的一篇等等，相当于项目计划书初稿。我会在`writing-workbench/projects`中建立一个子项目，这时候日期确定，项目标题可能是临时的。
|
||
4. 确定文章立意。将确定创作阶段的成果扔给主笔，以前素材都会进提示词，现在我会告诉主笔智能体，引用了哪些素材文件（包括确定观点阶段的讨论结论，过往文章，调研报告等等）；文章思路等内容还是文字描述。这部分放哪儿？
|
||
5. 确定文章提纲。这个过程，不论是主笔，还是评审员都可能会开启多轮会话，因为确定提纲是整个创作流程中最重的环节，一次会话往往都在十几个回合。
|
||
1. 我与主笔交流，生成初版提纲放在`outlines`中，这个最终参与评审的提纲一个版本就是一个文件，不会有多个文件；提纲生成可能会是多轮对话，这个对话过程存在哪里（以前我都保存在`knowledge-vault/discussions`中）。
|
||
2. 评审提纲。调用其他评审的Skill，来做评审。在搭建评审委员会之前，需要我明确指定谁来参与评审。与提纲生成类似，评审有三部分内容要考虑保存：
|
||
- 参与评审的素材准备，（之前一股脑放在提示词里），如果只放提纲，不放素材（上下文）大概率很多评审不过；
|
||
- 评审过程记录，我的智能体不是只出评审意见报告，还可以进行交流讨论（比如张辽不但是红队，还是建设性苏格拉底）；
|
||
- 评审意见结果。
|
||
3. 我汇总各评审意见，写应对策略，交给主笔修复提纲。然后重复前两个步骤，直到我认为OK。
|
||
4. 文章提纲确定后，对于复杂些的，会再生成一个附录提纲，放在提纲末尾。
|
||
6. 撰写正文。一般这时候都会重启会话。包括了正文的每次讨论输出，和最终正文。
|
||
1. 按章或按小节输出，我自行合并，正文初稿。
|
||
2. 进入正文初稿的评审。这个主要是措辞的修复。大多数评审1、2轮就通过了。
|
||
7. 撰写正文附录。对于跨学科，概念多的会基于附录提纲生成附录。包括了附录的讨论，附录会合并进正文。
|
||
8. 生成Metadata。包括了Metadata的结果，插图，和合并进正文。
|
||
1. 调用Skill生成Metadata，我放到正文的头信息中，包括关键词、摘要等等。
|
||
2. 生成插图，我上传到服务器，将URL放到头信息中。
|
||
9. 启动审判庭。以前的文章在提纲阶段下的力气少，所以进入审判庭的多。现在很少了。审判庭是一个由10个左右的智能体协作机制。
|
||
10. 基于审判意见修改。
|
||
11. 然后是建面向用户的模型阶段。可能直接抽取模型，也可能会调用`建模者委员会`，由6个智能体构成的协作机制。包括了讨论稿，和最终的模型说明正文。
|
||
```
|
||
|
||
### 评审环节的改造
|
||
|
||
在本项目中，我尝试细化`4. 确定文章立意`和`5. 确定文章提纲`。旧项目我删掉了：
|
||
原因是到几个评审智能体评审后，结果发现全是主会话的模拟Agent调用，完全没达到效果。
|
||
|
||
### 素材提炼的改造
|
||
|
||
这个是在深度创作流程的环节2`确定观点`中细化。
|
||
在我的知识库项目中，我基于CCPE System打造的Agent做了一个Skills文件夹，里面有`viewpoint-discussion-distillation`一个多智能体协同，位置：`C:\Users\wangq\Documents\Codex\knowledge-vault\skills\knowledge-processing\viewpoint-discussion-distillation`。
|
||
|
||
下面是这个协同技能的Readme
|
||
我试图在知识库中打造一个蒸馏的技能（具体agent调用的是CCPE System的）。
|
||
我最近对一个讨论稿做了三次蒸馏(view-points)，这三次的工作路径在：
|
||
|
||
* C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\viewpoint-development\2026-06-05-失望性情感隔离
|
||
* C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\viewpoint-development\2026-06-05-失望性情感隔离2
|
||
* C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\viewpoint-development\2026-06-05-失望性情感隔离3
|
||
|
||
前后花了有大约两天时间（具体约6个多小时）。
|
||
|
||
## 任务
|
||
|
||
我计划基于这些写一篇新文章，这个新文章，你的工作路径在`C:\Users\wangq\Documents\Codex\writing-workbench\projects\active\2026-06-12-Anti-Overengineering-Gate`
|
||
|
||
现在是讨论阶段，我首先需要汇集素材。
|
||
原来的**深度创作流程**，讨论是在知识库中，现在我已经确定要写这篇文章。
|
||
由于本项目下还没有正式开始写作，本次即是第一次写作的尝试，基于本篇文章的写作过程，同时做流程梳理和文件夹的规划。
|
||
|
||
我觉得一步步的，先**收集素材**。
|
||
|
||
## 收集素材
|
||
|
||
我觉得应该先汇总整理现有散落得内容，将其先归类汇总到`2026-06-12-Anti-Overengineering-Gate`，作为原始输入。
|
||
即，先汇集`评审环节的改造`和`素材提炼的改造`的工作过程说明，做信息的压缩和汇总。
|
||
不够得，我再补充。即，我再与其他智能体讨论，生成深刻洞察。
|
||
这样，原始素材能够汇集完成。
|
||
|
||
## 指令
|
||
|
||
你对这个**任务**怎么看，你有什么建议？
|
||
|
||
我建议你这一步做，但边界要收紧：**不是把所有历史过程搬进 `writing-workbench`，而是把它们压缩成可写作调用的素材包**。
|
||
|
||
我的判断是：
|
||
|
||
1. `knowledge-vault` 仍然保存原始讨论、蒸馏工作区、过程细节。
|
||
2. `writing-workbench/projects/active/2026-06-12-Anti-Overengineering-Gate` 保存本篇文章生产所需的“可消费材料”。
|
||
3. 这次“收集素材”的目标不是立刻写立意或提纲，而是先建立一个 **article-facing material dossier**：它回答“这篇文章能从哪些已发生的工作中提炼出问题、经验、原则、案例和反例”。
|
||
|
||
我建议第一步产物分成三类：
|
||
|
||
- `source-map.md`：列出引用来源，包括三次 `失望性情感隔离` 蒸馏路径、评审环节改造旧项目教训、相关 CCPE / Writing Workbench 设计文件，只做索引和用途说明。
|
||
- `00-creation-plan/material-dossier.md`：把散落内容压缩成写作素材，不放全文。结构可以是：背景事实、失败案例、关键矛盾、已验证原则、可转化为文章观点的材料、仍需补充的问题。
|
||
- `00-creation-plan/open-questions.md`：专门放“还不够深”的问题，供你后续再和其他智能体讨论，而不是混在素材汇总里。
|
||
|
||
我不建议一开始就建复杂的评审目录或多 Agent 流程。你这篇文章本身主题是 Anti-Overengineering Gate，最好的做法是让项目结构也体现这个原则：**先满足当前阶段，不提前实例化后面 5-8 个阶段的重型目录**。等素材包确认后，再进入“确定文章立意”。
|
||
|
||
下一步如果你同意，我建议我先只做一件事：检查这个项目目录和上游三个蒸馏目录，然后起草 `source-map.md` + `material-dossier.md` 的第一版，不进入提纲、不调用评审、不模拟任何 Agent 输出。
|
||
|
||
# 2
|
||
|
||
在我将来的文章里，这两次流程改造都是原始素材，从我以前的写作流程/经验看，每个流程改造过程有1000字足以。
|
||
我以前的做法，都是基于Web版的ChatGPT或Gemini，有两种：
|
||
1. 我提供原始的素材文档，LLM帮我做信息压缩
|
||
2. 完全手工整理
|
||
|
||
---
|
||
|
||
我现在基本上也是这个思路，我需要有这两个流程的信息压缩后的初稿，我基于这个，才能和AI/Agent继续讨论，以产生深刻的认识/洞察。
|
||
以前这部分信息压缩文件，都是在知识库的disscussion下，包括文章写作过程，正式稿。
|
||
现在迁移后，知识库这部分文章讨论的原文件夹被命名为`historical-article-discussions`，将文章写作流程剥离到现在这个`writing`项目。
|
||
那么，我的问题是：
|
||
* 这个压缩信息的工作，我应该放在知识库里还是现在`writing`项目里；基于这个，我后续还需要做洞察。因为知识库中目前没有承担写作的任务了，我可能要改结构。
|
||
* 上面问题确认后，才是本次的，如何压缩信息。
|
||
|
||
---
|
||
|
||
先回复问题，确认思路。
|
||
|
||
我的建议：**这次压缩信息的工作应放在 `writing-workbench` 当前文章项目里，不放回 `knowledge-vault/discussions`。**
|
||
|
||
理由是边界已经变了：这两个“流程改造过程”现在不是泛知识探索，而是已经被你选中，作为这篇文章的原始素材。它们的压缩初稿服务于后续文章立意、洞察讨论、提纲生成，所以应该进入：
|
||
|
||
`C:\Users\wangq\Documents\Codex\writing-workbench\projects\active\2026-06-12-Anti-Overengineering-Gate`
|
||
|
||
但我建议采用“双层归属”：
|
||
|
||
1. **原始过程和历史档案**仍留在 `knowledge-vault`
|
||
包括三次蒸馏工作区、旧文章讨论、旧评审失败记录、historical-article-discussions。这些是源头，不复制全文。
|
||
|
||
2. **面向本篇文章的信息压缩稿**放在 `writing-workbench`
|
||
例如两个 1000 字左右的文件：
|
||
- `00-creation-plan/material-compressions/review-process-reform.md`
|
||
- `00-creation-plan/material-compressions/material-distillation-reform.md`
|
||
|
||
3. **后续产生的“深刻洞察”先放在本文章项目里**
|
||
因为它们一开始仍然是文章立意材料。等文章完成后，如果其中有可复用的方法论、模型、规则，再回流到 `knowledge-vault/rules` 或相关索引中。
|
||
|
||
所以我不建议现在为了这次压缩去改 `knowledge-vault` 结构。更稳的做法是：`knowledge-vault` 继续做源库和归档，`writing-workbench` 承担“从源材料到文章生产”的中间加工。等这篇文章跑完，再根据真实过程决定是否给 `knowledge-vault` 增加一个专门的“可复用洞察/方法论回流”结构。
|
||
|
||
本次压缩信息的下一步，可以先做一个很轻的结构：在项目里建立 `source-map.md` 记录来源路径，再建立两个压缩稿。压缩稿不追求文学表达，只追求“事实过程 + 问题暴露 + 改造动机 + 初步原则 + 可继续追问的问题”。这会比直接进入立意讨论更稳。
|
||
|
||
# 3
|
||
|
||
很好，我也是这么想的。
|
||
后续观点/知识的深加工讨论过程，我会放在知识库中，结果（讨论稿或是报告），我会放在本项目中。
|
||
我觉得名字不应该叫`material-compressions`，而直接叫`materials`，因为在我眼里，都是最原始的材料，不论是抽取的信息，还是讨论稿（讨论稿本身可能我在知识库中就做一次抽取/压缩），亦或是报告（Deep Research）。
|
||
后续，基于`materials`，我们可以根据文章的议题做二次加工。
|
||
|
||
若这个思路一致，你接下来有两件事：
|
||
1. 记录在规则类的说明上，以便后续延续这个思路；
|
||
2. 开始做上述两个流程的信息材料抽取
|
||
|
||
有问题随时问。
|
||
|
||
已按你的思路落地。
|
||
|
||
我做了两类改动：
|
||
|
||
1. 在 [docs/operating-playbook.md](C:/Users/wangq/Documents/Codex/writing-workbench/docs/operating-playbook.md:113) 增加 `Materials Layer` 规则，明确 `00-creation-plan/materials/` 是文章项目内的材料承接层：上游原始讨论留在 `knowledge-vault`，面向本篇文章的压缩稿、讨论稿、报告结果放在 `writing-workbench` 当前项目。
|
||
|
||
2. 在项目 [2026-06-12-Anti-Overengineering-Gate](C:/Users/wangq/Documents/Codex/writing-workbench/projects/active/2026-06-12-Anti-Overengineering-Gate/project.md:1) 下建立最小素材阶段文件：
|
||
- [project.md](C:/Users/wangq/Documents/Codex/writing-workbench/projects/active/2026-06-12-Anti-Overengineering-Gate/project.md:1)
|
||
- [status.md](C:/Users/wangq/Documents/Codex/writing-workbench/projects/active/2026-06-12-Anti-Overengineering-Gate/status.md:1)
|
||
- [source-map.md](C:/Users/wangq/Documents/Codex/writing-workbench/projects/active/2026-06-12-Anti-Overengineering-Gate/source-map.md:1)
|
||
- [review-process-reform.md](C:/Users/wangq/Documents/Codex/writing-workbench/projects/active/2026-06-12-Anti-Overengineering-Gate/00-creation-plan/materials/review-process-reform.md:1)
|
||
- [viewpoint-material-distillation-reform.md](C:/Users/wangq/Documents/Codex/writing-workbench/projects/active/2026-06-12-Anti-Overengineering-Gate/00-creation-plan/materials/viewpoint-material-distillation-reform.md:1)
|
||
|
||
两份材料抽取稿分别约 2362 / 3074 字符，属于“1000 字级初稿材料”，没有推进到正式立意或提纲。
|
||
|
||
验证过：文件存在、内容 UTF-8 抽读正常、`git diff` 只显示 playbook 规则变更；`git status --short` 里还显示一个既有未跟踪目录 `projects/active/2026-06-04-Sanguo-test-slug/`，我没有处理它。
|
||
|
||
下一步建议你先读两份 `materials`，直接在其中标注“哪里不准 / 哪里还浅 / 需要补哪段经验”，然后再决定是否把后续洞察讨论开到 `knowledge-vault`。
|
||
|
||
# 4
|
||
|
||
## 关于`review-process-reform`
|
||
|
||
我这里其实还有其全对话的讨论记录：
|
||
**CCPE侧：**
|
||
1. `C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\technology\Codex\1.重构CCPE\写作相关智能体\重构提纲评审流程1.md`
|
||
2. `C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\technology\Codex\1.重构CCPE\写作相关智能体\重构提纲评审流程2.md`
|
||
|
||
**Writing侧：**
|
||
1. `C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\technology\Codex\3.重构写作流程\2.搭建Agents.md`
|
||
2. `C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\technology\Codex\3.重构写作流程\2.以三国为测试1-模拟服.md`
|
||
|
||
基于这四个文件，可以完整呈现出`review-process-reform`的全貌，我给的文档里的内容可能还有引用，这个你都可以按需阅读，当然由于旧的文章项目（完全模拟）没用，我删掉了文件夹，这些文件不存在了。
|
||
|
||
我觉得你可以基于这些讨论记录，重新优化下`review-process-reform`的内容。
|
||
|
||
已创建交接文档：
|
||
|
||
[context-handoff.md](C:/Users/wangq/Documents/Codex/writing-workbench/projects/active/2026-06-12-Anti-Overengineering-Gate/context-handoff.md:1)
|
||
|
||
里面记录了当前边界、已完成材料、两份 `materials` 的核心内容、不要重复的事项、下一轮建议讨论入口，以及给新会话的简短启动指令。重点是把后续会话稳稳停在“洞察讨论”阶段，不误入立意、提纲、评审或写作。
|
||
|
||
验证过：文件 UTF-8 可读，项目根目录下已出现 `context-handoff.md`，关键段落 `Do Not Repeat`、`Suggested Next Discussion`、`Current Open Decisions`、`Resume Instruction` 都存在。当前 `git status` 仍有之前的 `docs/operating-playbook.md` 修改和当前项目未跟踪目录；另有既存未跟踪 `projects/active/2026-06-04-Sanguo-test-slug/`，我没有处理。
|