wantsong
/
knowledge-vault
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
knowledge-vault/discussions/technology/Codex/0.规划与重构/0.环境规划-writing-2026-06-15.md

32 KiB
Raw Permalink Blame History

1

阅读这里的3份文档：

  1. C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\technology\Codex\0.规划与重构\2026-06-15\00-五库重构总纲.md
  2. C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\technology\Codex\0.规划与重构\2026-06-15-规划总结.md
  3. C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\technology\Codex\0.规划与重构\2026-06-15\02-writing-workbench调整意见.md

目前在writing-workbench中，实际上没有正式启动项目，因为写作流程跑不下去。C:\Users\wangq\Documents\Codex\writing-workbench\projects\active下的两个项目，可以算作只是测试验证，但是就发生了2026-06-15-规划总结中发现的问题。 这也是本次重构的核心原因。

有问题提出。

我读完三份规划文档，也核对了当前 writing-workbench 的入口文档和两个 active 项目。我的核心判断是：现在最需要问清楚的不是“怎么补流程”，而是“什么东西不再允许进入 active article project”。

我建议先回答这几组问题：

  1. projects/active 是否只能放“正式文章项目”？ 现在 2026-06-04-Sanguo-test-slug 只有一份讨论稿，更像测试材料，不像项目。是否要新增 projects/sandbox/、projects/tests/ 或 projects/candidates/，把这类验证对象从 active 中隔离出去？

  2. “已决定写作”到底需要多强？ 是用户说“这要写成文章”就够，还是必须同时有：工作标题、目标读者、材料范围、当前命题、下一步产物？如果不定义，material_intake 很容易继续吸入开放讨论。

  3. insight_discussion 默认应该放哪里？ 02-writing-workbench调整意见.md 倾向让观点生成和隐形规则显影留在 knowledge-vault，但当前 Anti 项目的 handoff 又允许“项目内小范围 positioning discussion”。这里需要定默认规则：项目内只能做“服务本篇文章的定位讨论”，还是默认回 knowledge-vault，只把结果稿放回 materials/？

  4. 是否需要一个“pre-project / candidate”层？ Anti-Overengineering-Gate 已经有项目壳，但还在问“这篇文章真正要写什么”。这说明它介于材料包和正式文章项目之间。要不要承认这个中间态，而不是强行叫 active article project？

  5. 现有模板是缩小，还是保留但降权？ PROJECT_STRUCTURE.md 仍然默认包含 outline review、tribunal、model-writing 等完整链条。要不要做一个 lite-skeleton，只包含 project.md / source-map.md / status.md / materials / decision-records，把 full structure 改成扩展模板？

  6. “真实调用”边界是否要写进 Writing Workbench，而不只写进 CCPE？ 现在 WORKBENCH.md 还写“dispatches writer or reviewer sessions”，但没有强制说明：没有真实 thread/sub-session/invocation record，就不能产生正式 reviewer report。这个规则是否要成为本仓库硬规则？

  7. 当前两个 active 项目怎么处理？ 我的倾向是：2026-06-04-Sanguo-test-slug 移出 active，标成 test/sandbox；2026-06-12-Anti-Overengineering-Gate 暂留 active 或改成 candidate，但明确禁止进入立意/提纲/评审，直到用户确认命题。

  8. README / WORKBENCH / playbook 是否要把“不要自动进入下一阶段”写成默认停止规则？ 目前文档说了进入条件，但没有足够强地说：材料承接完成后默认停止，等待用户决定，不自动 positioning、不自动 outline、不自动 review。

如果先做改造，我会建议第一刀只改边界和状态，不动大流程：新增项目类型/状态说明，降权模板，加入 no-simulation 和 material_intake stop rule，然后迁移或标记两个 active 测试项目。这样能直接针对这次失败原因，而不是继续加结构。

2

  1. projects/active 是否只能放“正式文章项目”？ 现在 2026-06-04-Sanguo-test-slug 只有一份讨论稿，更像测试材料，不像项目。是否要新增 projects/sandbox/、projects/tests/ 或 projects/candidates/，把这类验证对象从 active 中隔离出去？

    这是我尝试在这里写文章，发现没法进行下去。我又回到了旧的写作流程上，在knowledge-vault中，我实际上已经完成了文章的撰写工作：

    • C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\article-discussions\认知截肢与无摩擦滑流\记录全部的讨论交流：
      • 有主笔/韩愈的两次会话，比如认知截肢与无摩擦滑流讨论1-韩愈.md
      • 有与各提纲评审员的多次会话讨论，比如认知截肢与无摩擦滑流评审-巨人.md，认知截肢与无摩擦滑流评审1-张辽.md等
      • 有提纲的历次版本，比如认知截肢与无摩擦滑流提纲1.0.md
      • 有文章的metadata，认知截肢与无摩擦滑流提纲Metadata.md
    • C:\Users\wangq\Documents\Codex\knowledge-vault\sayings\2026\2026-06-13-cognitive-amputation.md是成稿

    我的想法：我后续还是计划在这里尝试写作，但是项目推动决策会更灵活——由我来判断，这里准确说是工具调用地，而不是生产地。帮我记录一些讨论过程，讨论结果，省一些体力活；而不是自行决定如何往下跑。

  2. “已决定写作”到底需要多强？ 是用户说“这要写成文章”就够，还是必须同时有：工作标题、目标读者、材料范围、当前命题、下一步产物？如果不定义，material_intake 很容易继续吸入开放讨论。

    在这里建立项目，就意味着决定进入写作。前期工作在knowledge-vault中已经完成了。 比如，2026-06-04-Sanguo-test-slug，实际上素材部分包括了四部分，这些完毕后，才会进入到写作阶段：

    • C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\agents\社会学家GPT\社会学讨论.md，实际上有历史学讨论和社会学讨论；
    • C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\agents\虎贲卫&龙骧营\思想考古\短视频时代的知识论危机-思想考古过程.md，是思想考古讨论过程；
    • C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\agents\虎贲卫&龙骧营\思想考古\短视频时代的知识论危机-思想考古报告.md，是思想考古报告

我考虑的，在这里的工作流程为：

  1. 我在Web上完成素材，包括讨论稿、报告这些内容
  2. 我在Web上完成初步提纲提炼后进入writing-workbench。我建立文章项目，并提供或者指出原始提纲这些文件路径。
    1. 之所以这样考虑，是因为素材内容量很大，必须使用高上下文的LLM，通盘了解后，才能有个初步提纲
    2. 即使初步提纲出来，也可能存在未充分利用现有素材的情况
  3. writing-workbench的起始阶段从提纲评审开始：
    1. 基于初步提纲，需要对素材进行压缩，但是要考虑损失的情况，即本身提纲对素材利用不充分，在压缩时反而把素材的那部分内容去掉了
    2. 基于压缩的素材和提纲，调用评审智能体进行评审，生成评审结果
    3. 主笔智能体进行新提纲的撰写
    4. 评审可能会进行多轮
  4. 撰写阶段，基于评审后的提纲和素材生成文章正文初稿

期间，所有的决策，包括是否再次评审，谁来评审，是否进入撰写，撰写是基于章还是基于节，等等，都由我/用户显示发指令进行。

考虑到现在的流程不完善，我考虑初期writing-workbench分为两个过程：

  1. 定义需要的能力，包括智能体或者Skill；由CCPE System或者Skills-vault来负责完成。
  2. 调用具体的智能体或者Skill完成具体的工作。

定位：对于过程1，writing-workbench相当于是甲方，规划自己的工作计划，调用的工具/Agent/Skill，缺失的部分由乙方（CCPE，Skills）提供。

writing-workbench工作过程产物，全部保留在自己的工作目录下，包括素材的加工，评审员、主笔的讨论内容，不回到knowledge-vault。 knowledge-vault中的成果正文部分，也由我自行维护。

基于以上内容，重新规划下writing-workbench，假设不考虑/不借鉴现有的规则，你有哪些问题？

基于你这版定位，我会把问题重新聚焦为：writing-workbench 不是“生产地”，而是用户主控写作流程中的工具调用地、记录地、临时加工地。那么关键问题如下。

一、项目入口

  1. 一个 writing-workbench 项目是否必须已经有“Web 初步提纲”？ 如果必须，那么项目入口不再是 material_intake，而是 outline-review-intake。

  2. 项目创建时，最低输入是什么？ 我建议至少是：原始提纲路径、素材来源清单、用户给出的当前写作目标。是否还需要工作标题、目标读者、预期文章类型？

  3. 如果 Web 上只完成了素材讨论，还没形成初步提纲，是否禁止建项目？ 这会决定 writing-workbench 是否允许 candidate 项目。

二、素材处理

  1. 素材压缩的目标是谁来定义？ 是“服务当前提纲评审”，还是“尽量保留全部潜在写作可能性”？这两者会导向完全不同的压缩策略。

  2. 当“初步提纲可能漏掉素材重点”时，压缩产物应分几层？ 例如：outline-aligned digest、unused-material candidates、risk-of-loss notes。否则压缩会强化旧提纲的盲区。

  3. 素材加工结果是否全部留在项目内？ 你已经倾向“全部留在 writing-workbench”，那还要不要保留 source-map 指向 knowledge-vault 原文，防止项目内压缩稿变成事实源？

三、评审调用

  1. 评审智能体是由 writing-workbench 直接调用，还是只生成 invocation/prompt，由用户去 Web 或其他平台调用？ 这决定“真实调用记录”怎么保存。

  2. 每次评审是否都必须保存完整讨论过程？ 你说要省体力活、记录讨论过程。需要明确最低记录：完整 session、最终 report、decision-ready summary，三者是否都必须有？

  3. 评审员列表由谁决定？ 默认不自动派发，那么项目文档里应该只提供“候选评审能力清单”，每轮由用户显式点名。

四、主笔与提纲迭代

  1. 主笔智能体重写提纲时，输入权威顺序是什么？ 用户原始提纲、素材压缩稿、评审报告、用户裁决，谁优先？如果评审意见冲突，主笔能不能自行取舍？

  2. 多轮评审什么时候停止？ 既然停止由用户决定，系统是否只负责提示“可选下一步”，不能声明“已通过/应进入正文”？

  3. 新提纲版本如何编号？ 需要区分 Web 初始提纲、评审后提纲、用户手修提纲、主笔修复提纲，否则后面会混。

五、正文撰写

  1. 正文生成默认按章、按节，还是由用户每次指定？ 你已明确由用户决定，那 playbook 应禁止自动从提纲进入全文生成。

  2. 正文初稿生成时，是否允许主笔补充素材外内容？ 如果允许，要标注“模型补充”；如果不允许，要强制 source-grounded。

  3. 文章正文成稿是否回写 knowledge-vault？ 你说 knowledge-vault 成果正文由你自行维护，那么 writing-workbench 只保存项目过程和可选草稿，不负责发布归档。

六、能力建设与调用分离

  1. “定义需要的能力”和“调用能力完成工作”是否应成为两个明确模式？ 例如：
  • capability-request mode：写需求，交给 CCPE / skills-vault。
  • execution mode：调用已有 Agent / Skill 处理当前项目。

  1. 缺能力时，项目是否暂停？ 还是允许用 manual placeholder？如果允许，占位产物必须不能冒充正式 Agent 输出。

  2. writing-workbench 作为甲方，向 CCPE / skills-vault 提需求时，需求单放在哪里？ 项目内？全局 requirements/？还是 ccpe-requests/？

七、目录和状态

  1. projects/active 是否只放“用户已经决定要推进的文章工具调用项目”？ 如果是，2026-06-04-Sanguo-test-slug 可以不是错误，只是它缺少项目壳和 source-map。

  2. 是否需要新增状态，而不是新增目录？ 例如：outline_review_intake、material_compression、review_round、outline_repair、drafting_requested、paused_waiting_user_decision。

  3. 当前 material_intake 这个阶段名是否要废弃或降级？ 按你的新流程，真正入口不是材料进入，而是“已有 Web 提纲后的评审准备”。

我认为最核心的问题只有一个：writing-workbench 的第一阶段到底叫不叫“提纲评审准备”？如果答案是是，那么整个仓库应围绕“用户带着 Web 提纲和素材路径进来，Codex 帮忙压缩、调用、记录、整理，但不自行推进阶段”重写。

3

一、项目入口

  1. 一个 writing-workbench 项目是否必须已经有“Web 初步提纲”？
    是的，现在的上下文窗口限制，导致material_intake无效，所以必须已经有“Web 初步提纲”。

  2. 项目创建时，最低输入是什么？
    我有不同的主笔，这个其实已经确定了文章的类型。比如启动时，我要求主笔是韩愈，那就是学术性散文；是蒙田，那就是随笔。 你可以读一下这个提纲，C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\article-discussions\认知截肢与无摩擦滑流\认知截肢与无摩擦滑流提纲1.0.md。这个就是初稿提纲的范本，其他初稿提纲都会是这个样。

  3. 如果 Web 上只完成了素材讨论，还没形成初步提纲，是否禁止建项目？ 是的，如果没有提纲，不会开始项目。

二、素材处理

  1. 素材压缩的目标是谁来定义？ 保留全部潜在写作可能性。

  2. 当“初步提纲可能漏掉素材重点”时，压缩产物应分几层？ 例如：outline-aligned digest、unused-material candidates、risk-of-loss notes。否则压缩会强化旧提纲的盲区。 我觉得压缩，是否体现原报告/讨论稿内容即可，不同的材料可能压缩的方式也不一样：

    • 我往往会基于思想考古报告来写作，这个甚至可以考虑不压缩；
    • 我提供的我自己的过往文章，或者讨论稿，这个可能会有些发散，可以考虑压缩多一些。 如何具体压缩，可能需要试跑几轮后，才能初步确定。

  3. 素材加工结果是否全部留在项目内？ 素材加工的结果全部保留在项目内。 保留source-map，这样备查。至少可以查到原文，发现是否过度压缩，有损压缩。

三、评审调用

  1. 评审智能体是由 writing-workbench 直接调用，还是只生成 invocation/prompt，由用户去 Web 或其他平台调用？ 这决定“真实调用记录”怎么保存。 由 writing-workbench 通过子会话调用评审智能体、主笔智能体和其他技能。 如果用户去 Web 或其他平台调用，那这个和我现在写文章没啥区别，writing-workbench就没有必要存在了。

  2. 每次评审是否都必须保存完整讨论过程？ 是的，需要记录讨论过程，完整session，最终report都必须要。

  3. 评审员列表由谁决定？
    甚至都不需要提供“候选评审能力清单”，每轮用户自行显示点名。

四、主笔与提纲迭代

  1. 主笔智能体重写提纲时，输入权威顺序是什么？
    现在主笔修订提纲一般是这样的过程，可以参考：

  2. 我同时提供多份评审意见，我的反思，我的意见，让主笔汇总判断合理性

  3. 基于主笔的判断，我发出修订指令，或者继续调整方向的指令；关键决策是我做的。

  4. 主笔完成修订

  5. 多轮评审什么时候停止？
    系统可以提供建议，提示下一步。不能声明已通过，声明了也没意义。

  6. 新提纲版本如何编号？ 保持一致的编号即可，web初始提纲就是1.0，评审后修订的，从2.0开始。 评审后提纲不准确，评审只有评审意见，基于评审意见才开始修订；用户不会主动修改提纲，用户发出的也是评审意见，等同于评审员。 个别微调的，可以起小版本号，比如3.1。

五、正文撰写

  1. 正文生成默认按章、按节，还是由用户每次指定？ 绝对禁止全文生成，否则干的多错的多。这个正文生成，已经作为主笔的工作方式，内嵌到其提示词中了。主笔不会去全文生成，我们这里清楚这个逻辑就行。

  2. 正文初稿生成时，是否允许主笔补充素材外内容？ 允许，本身评审意见就会要求补充案例，这个很可能超出了素材。这里可以考虑要标注。

  3. 文章正文成稿是否回写 knowledge-vault？ 是的，因为knowledge-vault 成果正文是面向发布的，还有发布的相关内容要填写。这里只负责项目过程，草稿生成就行。 当然本地留一份正文完整稿，也是可以的；因为这个是后续润色优化的基础。 不保留，我就会指向到knowledge-vault 成果正文作为润色的源。

六、能力建设与调用分离

  1. “定义需要的能力”和“调用能力完成工作”是否应成为两个明确模式？
    是的，应该是两个明确的模式：
  • capability-request mode，这个是“供应商”的工单
  • execution mode，这个是自己的工作工单

  1. 缺能力时，项目是否暂停？
    产生供应商工单后暂停。直到我通知配套的Agent准备好。 绝不能冒充，因为素材多，主会话会很快超出上下文。而且尤其是专家智能体，冒充的完全没质量。

  2. writing-workbench 作为甲方，向 CCPE / skills-vault 提需求时，需求单放在哪里？ 全局的requirements/，根据我最开始提供的文档，明确是CCPE还是skills-vault的。 然后我根据这个需求单，去到具体项目打造。

七、目录和状态

  1. projects/active 是否只放“用户已经决定要推进的文章工具调用项目”？ 如果是，2026-06-04-Sanguo-test-slug 可以不是错误，只是它缺少项目壳和 source-map。 我觉得可以考虑再做一个简化，我们这个是写文章的项目，不是开发项目。所以不是特殊情况，一定会做完。简化的结果就是projects/不再分子文件夹了。

  2. 是否需要新增状态，而不是新增目录？ 这个状态可能不一定准，实际很有可能，提纲审了几轮后，我再补充素材，需要重新压缩加工…… 我倾向于用文件夹。

  3. 当前 material_intake 这个阶段名是否要废弃或降级？ 是的material_intake这个阶段实际上是评审提纲的子阶段了，对素材的加工。 而对素材进行加工的原因就一个，现在的上下文窗口限制。

我认为最核心的问题只有一个：writing-workbench 的第一阶段到底叫不叫“提纲评审准备”？如果答案是是，那么整个仓库应围绕“用户带着 Web 提纲和素材路径进来，Codex 帮忙压缩、调用、记录、整理，但不自行推进阶段”重写。

是的。整个仓库应围绕“用户带着 Web 提纲和素材路径进来，Codex 帮忙压缩、调用、记录、整理，但不自行推进阶段”重写

读了你给的提纲范本。这个范本说明 writing-workbench 的入口确实不应该是“材料进入”，而应该是“已有 Web 初纲后的提纲评审与修订工程”。它已经包含：主笔类型、文章体裁、统摄隐喻、结构原型、核心论点、模块目标、写作协议。也就是说，项目启动时已经越过了开放观点生成阶段。

我建议把 writing-workbench 重规划为下面这个定位。

核心定位

writing-workbench 是文章写作的本地工具调用与过程记录场。

它不负责开放素材讨论，也不负责判断文章是否值得写。用户已经在 Web / knowledge-vault 中完成前期讨论和初纲生成后，才进入这里。进入后，它负责：

  • 接收 Web 初稿提纲和素材路径。
  • 围绕提纲评审准备上下文。
  • 对素材做必要压缩或引用整理。
  • 通过真实子会话调用主笔、评审员、Skill。
  • 保存完整 session、report、提纲版本、用户裁决和草稿。
  • 在缺能力时生成供应商工单，然后暂停。
  • 不自行推进阶段，不冒充专家，不自动全文生成。

推荐结构

我会建议废掉 projects/active / completed / abandoned 这种开发项目式分层，改成：

projects/
  2026-06-04-sanguo/
  2026-06-13-cognitive-amputation/
requirements/
  ccpe/
  skills-vault/
templates/
  article-project/

每个文章项目内部用状态和文件夹表达进度，而不是靠 active 目录表达。因为你这里的文章项目大概率都会完成，中途真正重要的是“当前停在哪个用户决策点”。

项目内建议结构：

project.md
source-map.md
status.md
decision-log.md

00-intake/
  initial-outline-v1.0.md
  intake-note.md

01-materials/
  source-digests/
  source-links.md
  compression-notes.md

02-outline-review/
  round-01/
    review-brief.md
    reviewers/
      zhang-liao/
        session.md
        report.md
      giant-cognition/
        session.md
        report.md
    user-reflection.md
    synthesis-for-writer.md

03-outline-repair/
  writer-session-v2.0/
    session.md
    outline-v2.0.md
    repair-notes.md

04-drafting/
  section-sessions/
  draft-v1.md

05-revision/
  revision-sessions/
  draft-v2.md

publish/
  local-final.md
  knowledge-vault-target.md

工作流

入口固定为：

Web 初稿提纲 + 素材路径 + 主笔身份 -> writing-workbench 项目

第一阶段不叫 material_intake，而叫 outline-review-prep 或 outline-review-intake。素材加工只是它的子任务，原因是上下文窗口限制，不是因为项目还没进入写作。

流程应是：

  1. 用户创建项目，提供初纲和素材路径。
  2. Codex 建立 source-map，复制或引用初纲为 initial-outline-v1.0.md。
  3. Codex 根据评审需要处理素材：有些报告不压缩，有些讨论稿压缩，有些过往文章只摘取相关段落。
  4. 用户点名评审员。
  5. Codex 通过真实子会话调用评审员，保存完整 session.md 和 report.md。
  6. 用户提供反思、判断和修订指令。
  7. Codex 调用主笔子会话，生成 outline-v2.0.md。
  8. 是否继续评审、是否进入正文、按章还是按节写，全部等待用户显式指令。
  9. 正文草稿保留在本项目；发布成稿由用户维护到 knowledge-vault/sayings，项目内可记录目标路径。

两个模式

你提出的“甲方 / 供应商”关系很关键，应写成正式模式：

execution mode：当前文章项目内使用已有 Agent / Skill 完成具体工作。

capability-request mode：发现缺少 Agent / Skill / Runtime 时，生成需求单到：

requirements/ccpe/
requirements/skills-vault/

生成需求单后，当前文章项目暂停，直到用户确认供应商能力已准备好。禁止用主会话模拟专家输出。

关键规则

我建议写进仓库的硬规则有五条：

  1. 没有 Web 初稿提纲，不创建文章项目。
  2. 没有用户点名，不调用评审员。
  3. 没有真实子会话，不产生正式评审报告。
  4. 没有用户裁决，不进入下一阶段。
  5. 禁止全文生成；正文写作粒度由用户指令和主笔提示词共同决定。

我推荐的改造路线

有三种做法：

  1. 小改：只改 README / WORKBENCH / playbook，保留现有目录。 成本低，但旧结构里的 active、material_intake、完整 production runtime 惯性还会继续误导。

  2. 中改：重写规则文档，新增 requirements/，项目不再分 active/completed，模板改成“初纲评审起步”。 这是我推荐的。它能匹配你的真实流程，又不会一上来重做全部历史项目。

  3. 大改：把现有项目全部迁移成新结构，重建模板、索引、状态协议、需求工单协议。 更干净，但现在可能过重。

我的建议是走第二种：先把 writing-workbench 明确改成“Web 初纲后的提纲评审、主笔修订、正文草稿调用场”，再处理现有两个项目的归位。

4

我倾向于大改。甚至于我们重建一个新的项目都可以，因为现有的writing-workbench压根没用起来。 历史项目在过去的writing-workbench没做起来，但实际上我已经按旧流程完成了，所以这个历史项目在这里也没有存在的必要了。 且基于此，我之前已经重构了knowledge-vault。

这个远程仓库也只用了44KiB的存储空间。 所以，你判断下，是重建新项目还是清空本项目重写。

我的判断：清空本项目重写，不新建仓库。

原因很直接：

  1. writing-workbench 这个名字仍然准确
    新定位还是写作工作台，只是从“文章生产 Runtime”改成“Web 初纲后的本地工具调用与过程记录场”。项目名不用换。

  2. 现有仓库没有值得继承的工程资产
    当前只有 3 个 commit，远程也很小。现有 README、WORKBENCH、模板、projects/active 结构基本都是旧假设产物，继续保留会持续误导后续会话。

  3. 新建仓库会制造无意义边界
    你已经围绕 writing-workbench 做了规划讨论，路径也稳定。换新仓库反而要解释“旧 writing-workbench 和新 writing-workbench 的关系”，这是额外负担。

  4. 清空重写更符合这次重构性质
    这不是版本迭代，而是入口范式变了：从 material_intake -> article production 改成 Web 初纲 -> 提纲评审准备 -> 真实调用 -> 用户裁决 -> 分段正文草稿。

我建议操作方式是：

  • 保留 .git、远程、仓库名。
  • 删除现有工作区内容。
  • 重建最小结构：
README.md
WORKBENCH.md
docs/
  operating-playbook.md
  project-lifecycle.md
  invocation-policy.md
requirements/
  ccpe/
  skills-vault/
projects/
templates/
  article-project/
  • 不迁移两个历史项目。
  • 只在新 README 里用一句话说明：旧结构已废弃，仓库于 2026-06-15 按“Web 初纲后的工具调用场”重建。
  • 如果你想保留旧内容作为参考，可以先打一个 tag 或分支，例如 archive/pre-2026-06-15-rebuild，然后清空 master 重写。

我不建议新建项目。除非你想连名字也改，比如 outline-review-workbench，否则保留 writing-workbench 清空重写是最干净的。

5

好的，我们在这个项目上清空重写。 现在开始。

已在原 writing-workbench 仓库上清空重写，保留了 .git 和远程关系，没有新建仓库。

新结构现在是：

README.md
WORKBENCH.md
docs/
  capability-requests.md
  invocation-policy.md
  operating-playbook.md
  project-lifecycle.md
projects/
requirements/
  ccpe/
  skills-vault/
templates/
  article-project/
  requirements/

核心规则已经写入：项目必须从 Web 初稿提纲进入；material_intake 被移除；projects/active/completed/abandoned 被废弃；评审员和主笔必须真实子会话调用；缺能力时生成 requirements/ccpe/ 或 requirements/skills-vault/ 工单并暂停；禁止默认全文生成。

验证结果：文件清单只剩新结构；旧术语扫描没有命中 TBD/TODO/material_intake/Article Production Orchestrator/Outline Review Runtime；git status 显示旧 scaffold 删除、新文档和模板新增/修改。当前变更还没有 stage 或 commit。

6

我们本次重构工作完成，有了一个初始化完成的环境。 现在做一次远程提交，并打上tag。

已完成远程提交和打 tag。

本次提交：

  • Commit: 0721f81 rebuild: initialize writing workbench
  • Branch: master
  • Tag: v2026.06.15-init

已推送到远程：

  • origin/master -> 0721f81127e5911f7ca2c72392744bf904a353d7
  • v2026.06.15-init -> 已在远端存在

本地工作区现在是干净的。
::git-stage{cwd="C:\Users\wangq\Documents\Codex\writing-workbench"}
::git-commit{cwd="C:\Users\wangq\Documents\Codex\writing-workbench"}
::git-push{cwd="C:\Users\wangq\Documents\Codex\writing-workbench" branch="master"}

7

由于目前CCPE现在主要是为本项目服务的，所以对CCPE来说，你有什么补充说明没有？ 你需要一个本地项目说明么？刚改造知识库，准备了一个，你看你需要这个文件不，C:\Users\wangq\Documents\Codex\knowledge-vault\PROJECTS.md

需要。对 CCPE 来说，最好也有一个本地项目说明，而且我建议放在 ccpe-system 根目录，名字可以直接叫 PROJECTS.md 或 PROJECT-RELATIONSHIPS.md。

我看了 PROJECTS.md。它作为五库关系总表是有用的，但对 CCPE 还不够，因为现在 writing-workbench 已经重写了定位：它不是泛泛的“已决定写作后的文章项目现场”，而是更具体的 Web 初纲后的本地工具调用、真实子会话调用、过程记录场。CCPE 需要知道这个新入口，否则它后续很容易继续按旧的 Article Production Runtime 方向过度设计。

我建议 CCPE 的本地说明补充这些点：

  1. writing-workbench 是当前第一服务对象
    CCPE 现在优先供应：主笔 Agent、评审 Agent、提纲评审 invocation protocol、真实子会话记录规范、素材压缩/上下文包规则。

  2. CCPE 是供应商，不是项目现场
    文章项目过程、评审 session、正文草稿不进 CCPE；CCPE 只保存可复用的 Agent / Runtime / Model Card / Protocol。

  3. 从 writing-workbench/requirements/ccpe/ 接收工单
    CCPE 不主动猜测要造什么能力。只有当 writing-workbench 产生供应商工单，CCPE 才进入能力建设。

  4. 明确禁止模拟正式输出
    这条要写进 CCPE 根说明：packet / prompt / dispatch pack 不等于执行；正式评审和主笔输出必须来自真实 invocation。

  5. CCPE 当前的优先能力清单
    例如：韩愈主笔、张辽评审、巨人认知、认知显影、outline review packet、review report contract、writer repair packet。

  6. 与 skills-vault 分工
    如果是确定性脚本、文件转换、批处理，进入 skills-vault；如果是专家判断、Runtime、Agent、协议，进入 CCPE。

所以我的建议是：需要这个文件，而且应该以 writing-workbench 为第一消费场景重写一版 CCPE 本地项目关系说明。knowledge-vault/PROJECTS.md 可以作为总关系参考，但不能直接复制过去。

8

我的意思是：

  1. 你的项目库里需要一个Projects这样的文件么，若需要，你可以构造一个自己用的。
  2. 我后续要优化/重构CCPE，你有什么要给它的特殊说明，可以考虑出一个文件。我作为上下文放进初始会话中。

我新增了两个文件：

  • PROJECTS.md
    这是 writing-workbench 自己用的项目关系说明，明确它消费 knowledge-vault / ccpe-system / skills-vault，但不拥有上游知识、canonical Agent 或自动化工具源码。

  • docs/ccpe-rebuild-context.md
    这是给后续 CCPE 优化/重构会话使用的上下文文件，重点说明：CCPE 现在应作为 writing-workbench 的供应商，优先提供主笔、评审员、真实调用协议、no-simulation 规则、素材压缩/上下文准备规则，而不是继续设计完整自动写作 Runtime。

当前工作区只有这两个新增文件未提交。