254 lines
13 KiB
Markdown
254 lines
13 KiB
Markdown
# 1
|
||
|
||
## 任务
|
||
|
||
阅读交接文档：`C:\Users\wangq\Documents\Codex\writing-workbench\projects\水晶裹尸布与生命体\handoff\outline-review-complete.md`
|
||
|
||
`水晶裹尸布与生命体`写作项目已经完成提纲，最新的提纲是`水晶裹尸布与生命体提纲4.2`。主笔是韩愈。
|
||
|
||
接下来进入撰写初稿阶段。
|
||
|
||
接下来需要两件事：
|
||
1. 先做环境准备：讨论确定撰写阶段的流程，及配套文件夹，文件；然后准备环境。
|
||
2. 环境准备号好后，进入撰写初稿的过程。
|
||
|
||
## 撰写环境及过程
|
||
|
||
现在`editor/韩愈/`目录下是评审提纲的会话回合。
|
||
我们要撰写的话，是否对其进行一个改造：
|
||
1. editor只有一个，所以韩愈和editor做个合并——`editor-韩愈/`。现在主笔这里多一层目录没意义。
|
||
2. 韩愈下分为`outline-revise/`和`draft/`两个目录，下面再放`会话`+`回合`。这样区分提纲和写作阶段。
|
||
3. 以前我用单智能体时，都是`深潜式`写作：比如4.2提纲`引言`、`结语`章中没有小节，就两次输出；第2章到第4章都有小节，就每次输出一个小节。这样主要是：
|
||
1. LLM的输出能力受限，我的文章一般都在7、8千字到几万字，一次性输出不了；
|
||
2. 要求LLM一次输出一章，也会遇到信息压缩的情况；
|
||
3. 我可以随时检查每一部分的输出质量，有问题随时调整；
|
||
4. 变成小节后，会让LLM充分利用素材，表达充分。
|
||
这种，以前单智能体，会由我来控制/把握上下文，遇到快超出的时候，我会把已经输出的文字作为上下文的一部分，让它继续输出下一部分。
|
||
4. 撰写时的提示词：
|
||
1. `intake/背景资料`，我会把评审提纲时补充的资料，也放进去。
|
||
2. 提纲4.2
|
||
3. 我的具体指令。
|
||
5. 我预期的输出：
|
||
1. 除了像评审阶段那样，每个目录记录每回合的输入、输出、packet和metadata
|
||
2. 能否提取每一次的正文初稿进一个汇总的Draft文件
|
||
3. 主会话能否对输出的正文做一个初步校稿
|
||
1. 主会话没有背景资料，提纲，相当于以读者身份阅读，这样便于检查出是否信息密度高，概念解释不够等问题。这些问题，我和主笔有时都难以发现——知识的诅咒。
|
||
|
||
## 指令
|
||
|
||
你对撰写阶段的环境和过程，有什么疑问，有什么建议？
|
||
|
||
我读完了 [交接文档](</C:/Users/wangq/Documents/Codex/writing-workbench/projects/水晶裹尸布与生命体/handoff/outline-review-complete.md:1>)、状态文件、工作台规则和提纲 4.2。我的建议是：**不要物理改名或移动现有 `editor/韩愈/r1.1-r2.1`**。这些是提纲评审阶段的历史证据，交接和日志已经引用它们；移动会制造证据路径漂移。撰写阶段应新开 `drafting/`，这也符合当前工作台模板。
|
||
|
||
我推荐的结构是：
|
||
|
||
```text
|
||
projects/水晶裹尸布与生命体/
|
||
editor/韩愈/ # 保留：提纲修订阶段原始证据
|
||
drafting/
|
||
drafting-plan.md
|
||
section-map.md # 按提纲4.2拆成“深潜式”写作单元
|
||
draft-context-ledger.md # 滚动上下文账本，避免每次塞全量历史
|
||
draft-v1.md # 汇总正文初稿
|
||
draft-notes.md
|
||
proofread-log.md # 主会话/冷读者初校问题
|
||
section-sessions/
|
||
han-yu/
|
||
00-intro/r1.1/
|
||
agent-invocation-packet.md
|
||
run-metadata.json
|
||
prompt-to-send.md
|
||
returned-output.md
|
||
extracted-draft.md
|
||
controller-proofread.md
|
||
01-1-1/r1.1/
|
||
...
|
||
```
|
||
|
||
流程上，我建议每个写作单元只让韩愈输出一个明确正文块，并强制返回结构：
|
||
|
||
```text
|
||
## 正文初稿
|
||
...
|
||
|
||
## 作者注记
|
||
...
|
||
```
|
||
|
||
这样主会话可以把 `## 正文初稿` 提取到对应 `extracted-draft.md`，再汇总进 `draft-v1.md`。每个单元完成后，主会话只做“读者侧初校”：概念解释不足、信息密度过高、衔接断裂、术语未铺垫、句子病灶。它不直接改韩愈正文，只写入 `proofread-log.md` 或单元内 `controller-proofread.md`，再由你决定是否让韩愈修。
|
||
|
||
一个关键点：**真正的“无背景读者”最好不是当前主会话**。因为当前主会话已经读了提纲和流程文件，严格说不再盲读。主会话可以做初步校稿；如果你要模拟外部读者，建议另开一个“cold reader”子会话，只给它 `draft-v1.md` 或某个 `extracted-draft.md`，不给背景资料和提纲。
|
||
|
||
我现在唯一需要你确认的是：是否接受这个方案，也就是**保留旧 `editor/韩愈/` 不动，新建 `drafting/` 作为撰写阶段环境**？确认后我就按这个结构准备文件和第一轮写作单元表。
|
||
|
||
# 2
|
||
|
||
由于每次新会话，读取文件都要经历两次，乱码一次，再用UTF-8读。
|
||
先补录一个全局规则，我所有的文件都是UTF-8编码，默认就是UTF-8。
|
||
|
||
**不做任何写作项目下的执行或调整。**
|
||
|
||
首先同意： 保留旧 `editor/韩愈/` 不动，新建 `drafting/` 作为撰写阶段环境。
|
||
包括其中的路径规划我也同意。
|
||
|
||
> 模拟外部读者
|
||
|
||
这个，我想按照目前规划的目录结构也好改，可以全文初稿出来后，再全文阅读就行。这个不是撰写阶段，而是润色阶段的事了。
|
||
所以这个要求可以忽略。
|
||
|
||
而关于目录结构，我有些问题：
|
||
* drafting-plan.md 记录什么，谁来生成
|
||
* draft-context-ledger.md 考虑到韩愈有全量上下文，提纲，和历史的输出，这个滚动记录的什么？
|
||
* draft-notes.md 干什么的
|
||
* proofread-log.md 现在只需要主会话了，还是都不需要了？
|
||
* section-sessions 下面不用再分`hanyu`了，主笔每次只有一个，不用标记是谁。提纲里有明确的记录，谁的提纲就是谁来写
|
||
* `00-intro/r1.1/` 这样拆分，很严谨，但是造成结构记录远远大于正文内容，ROI太低。我这次写的文章就是再说治理过度的问题。
|
||
* `00-intro/r1.1/` 目录下的一系列文件，我觉得也可以考虑删减。这个写作项目不是做软件开发；这样太费Tokens。
|
||
* 我发现的问题，是直接发指令，还是记录在哪里？我个人觉得直接发指令就好，不需要额外记录了；因为我的指令本身就被你记录在`prompt-to-send`中。
|
||
* 强制返回结构中的`作者标记`是什么？韩愈为什么会输出作者标记？
|
||
|
||
根本就是一个：简化治理成本，提高ROI。避免正文写了5000字，治理（各种日志）达到了50000字；日志应该远远低于正文内容量。
|
||
|
||
---
|
||
|
||
基于我以上的想法，你有什么考虑？
|
||
|
||
# 3
|
||
|
||
同意：`撰写阶段不建审计系统，只建写作流水线`
|
||
确认采用`轻量可追溯档`这个方式，同意你的建议目录规划。
|
||
先搭建本项目的撰写阶段目录，然后试跑。
|
||
|
||
考虑到你可能会参与到撰写过程，信息会压缩，我觉得你可以先记录规则到本写作项目的一个文件里。
|
||
等跑出来结果——全部正文初稿后，再考虑将这套固化到全局规则里。
|
||
|
||
---
|
||
|
||
现在准备写作的相关环境，和项目下的规则，这个可以临时写到`handoff/`下。
|
||
|
||
# 4
|
||
|
||
我刚发现背景资料中遗漏了一篇引文《生命的本质》，刚补上。
|
||
|
||
我想，我们改一下过程：
|
||
|
||
* 你让韩愈直接写对应的返回文件。
|
||
* 你每次只限定韩愈写哪一小节，有些和提纲重复的就不用发了
|
||
* 不用汇总到draft-v1了，这样比较占用你的context。本次写作，上下文比较少不到10万字；将来可能会远超这个数字。
|
||
* 这个我们将来再处理，对背景资料的内容进行一定的无损压缩。
|
||
|
||
对于这次试跑，我发现了几个问题：
|
||
* 主笔是应该站在“我”角度写文章的，但是正文里都是Owner。韩愈可能不知道Owner是啥，完全是第三人称的口吻。
|
||
* 标星部分的格式，
|
||
* 原文是： 生命支持舱*
|
||
* 期望是： 生命支持舱`*`
|
||
* 部分表达有些抽象/费解：
|
||
> 如果一个认知模型还没有显示出边界、代谢、反馈吸收与纠偏能力，那么再透明的外壳，也只能保存一个尚未成形的对象。它可以让人安心，可以让协作者交接，可以让审查者签字，却不能替那个对象证明生命已经发生。
|
||
这句话里引用了《生命的本质》的概念，前面资料里遗漏了这篇引文；但是读者可能没有这个概念，认知模型和生命有啥关系啊。
|
||
|
||
这次`引言`你也可以读一下，找一些问题出来，毕竟是试跑、试运行。先找出来问题。
|
||
|
||
**不要做具体的执行——让韩愈去调整**
|
||
先发现问题。
|
||
|
||
我只做问题发现，不执行调整。
|
||
|
||
**主要问题**
|
||
|
||
1. **叙述主体错了**
|
||
当前引言把作者写成了第三人称 `Owner`，例如“Owner 在二十余年的软件开发……”。正文应该站在你的作者视角写，`Owner` 只适合项目记录，不适合公开文章。
|
||
后续 prompt 里需要明确写：`Owner = 作者本人，正文中不得使用 Owner 称呼；涉及亲历经验时用“我”，涉及读者共同推演时用“我们”。`
|
||
|
||
2. **“我们”的使用还不够准**
|
||
韩愈风格需要“我们”的同行者视角，但这不等于全篇回避“我”。这篇文章有强烈的亲历复盘属性，开头应允许“我见过/我曾经/我这次付出的代价”，再切回“我们如何理解这种失败”。现在把亲历经验改写成第三方观察，削弱了可信度。
|
||
|
||
3. **星号格式需要硬约束**
|
||
当前是 `生命支持舱*`、`水晶裹尸布*`。你期望的是 `生命支持舱`*` 这种形式，即词后星号用反引号包住：`生命支持舱\`*\``。后续 prompt 要明确：所有术语标星使用 `概念名\`*\``，不得写成 `概念名*`。
|
||
|
||
4. **“生命”概念进入得太突然**
|
||
你指出的那句确实有问题：
|
||
“边界、代谢、反馈吸收与纠偏能力”直接从《生命的本质》借概念，但引言前面没有给读者搭桥。读者会问：认知模型为什么突然按生命判据来判断？
|
||
引言里最好先用更低门槛的说法，比如“它是否能在输入、反馈和修正中保持一套可复现的动作”，等第三章再正式展开边界、代谢、预测纠偏、非遍历性。
|
||
|
||
5. **“事实先于隐喻”还没完全做到**
|
||
引言已经列了 6 天、4.7 亿 Tokens、模型档案、来源索引等事实，但“生命支持舱/水晶裹尸布”的隐喻收束仍然比事实判据更强。更好的顺序是：先明确“我们没有验证动作复现”，再说“因此外壳的意义发生分叉”。
|
||
|
||
6. **开头略像通用议论文入口**
|
||
“我们在工作中并不缺少失败”到“更危险的是另一种东西”是顺的，但有一点泛。考虑这篇文章的强个人复盘属性，开头可以更早压入“我曾经以为这是一次昂贵但必要的建设，直到第六轮发现它只是在证明自己合规”这种具体冲击。
|
||
|
||
**流程调整我同意**
|
||
|
||
后续更合理的流程是：韩愈直接写 `*.returned.md`；主会话不再汇总 `draft-v1.md`；每次 prompt 只指定当前小节、特殊补充指令、必须避免的问题。这样治理负担更低，也避免主会话 context 被正文汇总吞掉。
|
||
|
||
对这次引言，核心修正方向不是重写逻辑，而是三件事：把 `Owner` 改回作者视角，降低“生命判据”的前置理解门槛，修正标星格式。
|
||
|
||
# 5
|
||
|
||
对于这次引言的问题，我建议重开会话。你重新准备提示词，将发现的问题作为注意事项放进去。
|
||
对于记录部分，我觉得可以，原先的改成：
|
||
* `00-intro.prompt-1.md`
|
||
* `00-intro.prompt-1.md`
|
||
本次的为：
|
||
* `00-intro.prompt-2.md`
|
||
* `00-intro.prompt-2.md`
|
||
|
||
删除`draft-v1.md`。
|
||
|
||
---
|
||
|
||
你觉得呢？
|
||
|
||
你若是同意，调整文件名，准备好`00-intro.prompt-2.md` 等我确认，先不要调度韩愈。
|
||
|
||
# 6
|
||
|
||
我删掉了这部分：
|
||
```
|
||
You may read the previous attempt for contrast, but do not imitate its problems:
|
||
|
||
```text
|
||
C:\Users\wangq\Documents\Codex\writing-workbench\projects\水晶裹尸布与生命体\drafting\sessions\00-intro.returned-1.md
|
||
```
|
||
```
|
||
|
||
修改`重写全文初稿的引言：` 为 `写全文初稿的引言：`
|
||
|
||
删除`- 不输出作者注记。`，这个是我们讨论的上下文，韩愈不知道这个。
|
||
|
||
`00-intro.returned-1.md`是我们的本地记录，韩愈都准备重启会话了，就是测试你的注意事项是否有效，它没必要看到过去的错误。
|
||
|
||
现在可以调度新韩愈会话，发送这个指令。
|
||
|
||
新韩愈会话已调度并返回，结果已由子会话直接写入：
|
||
|
||
[00-intro.returned-2.md](</C:/Users/wangq/Documents/Codex/writing-workbench/projects/水晶裹尸布与生命体/drafting/sessions/00-intro.returned-2.md:1>)
|
||
|
||
我做了独立验证：
|
||
|
||
- `Owner` 未出现
|
||
- 未越界写到“第一章”
|
||
- “形式正确，内容垃圾”只出现 1 次
|
||
- 标星格式是 `生命支持舱`*` / `水晶裹尸布`*`
|
||
- 子会话已关闭
|
||
|
||
这次我没有改写正文，也没有汇总到 `draft-v1.md`。
|
||
|
||
# 7
|
||
|
||
这次效果比较理想，我需要改的东西很少，达成了初稿的预期。
|
||
下一步，我们试试“撒把”的方式。
|
||
|
||
你直接调度它完成第一章，即在现在的会话上继续4次，完成第一章的全部小节。
|
||
我在第一章全部内容返回后，进入。
|
||
|
||
---
|
||
|
||
对此，你有没有什么问题？
|
||
|
||
# 8
|
||
|
||
我觉得后续都可以按照撒把的形式。
|
||
输出后续的全部章节。
|
||
|
||
我将在全部初稿完成后，统一修订。
|