协作流 A
选题 → 提纲 → 页面 → 上线
适合把一条想法、一个公开笔记或一次日常经验，快速做成一页可上线的教程。
Claude
把主题压缩成一句定位、6–8 个小节，以及页面到底为谁而写。
Codex
新建页面、接入首页与父页入口、更新日志、搜索索引和 sitemap。
subagent
并行检查相关入口、链接、重复措辞、父级导航与线上命中文案。
交付物： 1 个新页面 + 若干父页入口 + 1 条更新日志 + 可访问线上链接。
新增子页 · 知识库协作流
先别问哪个模型更强，先把你的内容系统拆成三个岗位
很多人能用 AI 很快写出第一篇页面，却总是很难把知识库长期跑顺。真正卡住的点通常不是生成能力，而是缺少分工： 选题和结构没人兜底，页面落仓库时缺入口与上下文，到了上线阶段又没人补回归和验收。 只要还是一个线程包办所有角色，你就会不断在“想题、写稿、改页面、校链接、做部署”之间切换，最后每件事都做了，却没有形成稳定系统。
适合谁看
适合已经用过 Codex / Claude / Agent 工作流，想把科研笔记、方法教程、内容站或个人知识库长期做下去的人。
看完能直接带走
- • 角色分工：谁负责定义、谁负责落地、谁负责 sidecar 检查
- • 3 条常用协作流
- • 一个今天就能开始的最小可用系统
①
为什么知识库 / 内容站的难点不在首篇文章
真正难的是持续迭代：题从哪来、资料怎么进系统、上线前谁来做最后一轮验收。
漂移
选题会反复摇摆
没有一个角色专门负责“把需求说清楚”，就会不断重开线程，最后做成很多半成品。
脱节
资料和成品容易断开
原始笔记、科研结果、Prompt 和最终页面如果不进同一套仓库，内容很快就变成不能复用的碎片。
验收
上线前检查总是最后才想起来
链接、父页入口、更新日志、搜索索引、sitemap，往往不是不会做，而是没人稳定负责收尾。
一句话总结： 你缺的往往不是更多 prompt，而是一个更稳定的内容生产分工： 定义问题 → 落地仓库 → 并行验收。
②
角色分工：Codex / Claude / subagent 各干什么
三个角色不是三个聊天窗口，而是三种责任边界。
Claude
负责把问题讲清楚
- • 明确这一页到底解决什么问题
- • 写页面结构、段落逻辑和标题层级
- • 把验收标准和文案口径定清楚
Codex
负责把仓库和页面做出来
- • 新建 HTML / SVG / 数据文件
- • 接父级入口、相关链接、站内索引
- • 提交、部署、线上验收与回写仓库
subagent
负责 sidecar 工作
- • 摸底旧页面、梳理相邻入口
- • 做链接检查、回归检查和一致性复核
- • 只交付主线程能直接消费的结果
不要这样分工： 让一个线程同时负责“想题、写稿、改页面、补入口、跑部署、验收回归”。 这样最常见的结果不是效率更高，而是上下文切换更多，最后每一步都做得不够稳。
③
先给自己一个最小可用系统
先把最小目录结构和最小发布流程跑顺，再谈更复杂的任务编排。
knowledge-base/ ├── CLAUDE.md # 规则、口径、验收边界 ├── content/ │ ├── drafts/ # 草稿、提纲、半成品 │ └── published/ # 已发布内容的 Markdown / 素材回写 ├── references/ # 论文、截图、原始资料、外部链接整理 ├── public/ │ └── ai-skills/ # 最终要上线的 HTML / 资源 ├── docs/ │ ├── specs/ # 页面设计、结构说明 │ └── handoffs/ # 交接记录、复盘 └── updates/ # 上线记录、变更摘要
最小系统的目的
不是把目录做得多完整，而是让“资料 → 草稿 → 页面 → 上线记录”至少能在同一套仓库里闭环。
现在先不用做的事
如果你还没稳定输出 3–5 篇内容，不必一上来就设计复杂的状态机、自动调度或超重的任务系统。
先跑起来的最低标准
每做完一页，都能回写到仓库、挂到父页入口、留下一条更新记录，并能在正式域名上访问。
④
三条最常用协作流
这三条流程最适合“知识库 / 内容站 + 科研项目 + 持续上线”的组合场景。
协作流 B
科研项目 → 笔记 → 知识卡 → 可发布页面
适合把一项分析、一个研究方法、一次实验复盘，沉淀成以后还能继续复用的知识资产。
Claude
从论文、分析脚本或会议记录中提炼出真正值得公开的结构和核心判断。
Codex
整理附件、制作页面、补下载入口、把原始结果与最终成品对齐到仓库路径。
subagent
核对数字、链接、图表标题和下载文件是否与页面描述一致。
交付物： 不是一篇孤立文章，而是一条“原始资料 → 方法说明 → 页面成品”的可回溯链。
协作流 C
大任务拆分 → 并行处理 → 汇总上线
适合你已经知道要做什么，但内容较多、入口较多、验收环节较多的页面扩展任务。
主线程
保留最关键的结构判断、页面骨架和最终部署，不把拍板动作外包出去。
subagent A / B
分别负责父页入口摸底、回归测试、死链检查、文字一致性扫描等 sidecar 工作。
Claude
在主线程需要时，补足验收口径、CTA 设计和文章层次，但不代替仓库操作。
关键规则： 一个 subagent 只做一件事，只交一份可直接消费的结果，不要把“把整页都搞定”这种模糊目标交出去。
⑤
上线前的最小发布流程
知识库能长期稳定，靠的不是灵感，而是每次上线都走同样的一套收尾动作。
先定一句话目标
这页是给谁看、解决什么问题、看完之后读者能做什么。
用 Claude 把结构和验收标准写清楚
标题层级、父页入口、相关链接、更新记录、上线后要命中的关键词，先写出来。
用 Codex 在 worktree 里实现
新建页面、接资源、改入口、更新数据文件，保持变更边界清楚。
把检查任务拆给 subagent
检查链接、面包屑、父级入口、死链、文案一致性与线上命中，不要让主线程被细碎检查反复打断。
部署并回写更新日志
正式域名可访问、更新日志可追溯、搜索索引与 sitemap 已收录，这次上线才算真正完成。
最小发布清单（可直接照着跑） - 页面一句话定位已确定 - 新页已接到父页 / 首页入口 - 面包屑与相关入口可点击 - updates.json 已补一条记录 - global-search-index.json / sitemap.xml 已刷新 - 线上 curl 命中标题、关键词和更新记录
⑥
常见误区：为什么很多知识库越做越乱
不是因为你不会用模型，而是因为角色、交付物和回写动作都不够稳定。
误区 1：一个线程包办所有角色
你会觉得一直在前进，但其实一直在切换上下文，最后结构、页面和验收都不够稳。
误区 2：把 subagent 当总包
如果没有边界、文件范围和交付格式，subagent 只会把执行成本换成新的阅读成本。
误区 3：一开始就搭很重的系统
如果还没稳定产出，过早设计复杂任务系统，往往只会增加维护负担。
误区 4：页面做完却没回写知识资产
真正值钱的不是单页，而是你以后还能继续复用的资料、结构、Prompt 与上线链路。
⑦
什么时候升级到 skill / worktree / .tasks/
升级不是为了显得更系统，而是为了把已经反复出现的工作稳定下来。
skill
当结构开始重复
如果你不断在做相似页面、相似 Prompt、相似验收清单，就该把这类动作沉淀成可复用 skill。
worktree
当主工作区开始变脏
如果多个专题同时在改，worktree 可以帮你把每次上线任务隔离开，减少互相污染。
.tasks/
当并行任务明显变多
如果你已经有多个页面、多个 sidecar 检查和多条上线链路同时推进，就值得把任务状态写进 `.tasks/ + worktree` 最小系统。
这页的下一步： 如果你已经能稳定跑完上面的最小系统，下一步最值得做的就是把 .tasks/ + worktree 做成一个真正可用的最小任务系统：任务有状态、实现有隔离、上线有回执、交接有落点。
⑧
今天就能开始的 30 分钟版本
不要等完整系统，先做一页能上线、能回写、能被下次复用的内容。
- 先选一个你已经讲得最顺的主题，哪怕只是一个日常协作经验。
- 让 Claude 帮你把页面定位、标题层级和验收标准先写出来。
- 让 Codex 在仓库里把新页、父级入口、更新记录和上线验收一次做完。
你的知识库真正开始起飞，不是从“收集更多素材”开始， 而是从第一条能稳定复用的协作流开始。
可直接点击的相关入口
站内延伸阅读
下面这些页面和本页一起看，能更快把“AI 协作”升级成真正可重复的内容生产系统。