AI极客实战案例日报

01｜案例是什么？

Oh Story（仓库 zenstory-ai/oh-story-claudecode，MIT）是一套面向中文网络小说的 Agent Skill 包，覆盖长篇与短篇的全流程：扫榜选材 → 拆解爆款 → 搭大纲写正文 → 去 AI 味 → 生成封面图。它以 13 个 skill 的形式装进你已经在用的编程 Agent（Claude Code、Codex CLI、Google Antigravity、OpenCode、ZCode、OpenClaw、Reasonix 等），写作用的模型就是该 Agent 的模型，不需要 GPU，也不需要另配模型。项目自带 demo 与样例文件，可直接看到「写第 21 章」这个动作从头到尾产出了什么。

02｜为什么今天值得关注？

• 为什么以前不容易做：用 AI 写长篇，最难的从来不是「写出好句子」，而是连续性——第 80 章不能与第 7 章的伏笔打架，角色不能突然知道他还不知道的事。靠对话记忆硬撑，上下文一压缩就丢伏笔。
• 为什么现在变得容易：① Agent Skills 让「写作方法论」可以被拆成一个个可加载的文件，而不是塞进一段超长提示词；② hook（钩子）机制让「写正文前必须已有细纲」这类门禁可以被程序强制执行；③ 用文件系统做状态存储，不再依赖模型的记忆。
• 为什么值得花时间：网文是中国独有的、体量极大的内容产业。一个能扛住几百章连续性的写作工作流，其价值不在「AI 写小说」这个噱头，而在「长任务状态管理」这套方法——它可以直接迁移到任何长周期、多步骤的 Agent 任务上。

03｜案例的前世今生

前世。2023–2024 年，「AI 写小说」的主流形态是把设定和大纲塞进一段超长提示词，再让模型续写。这条路在第 10 章左右就开始崩：角色性格漂移、伏笔失踪、时间线错乱——因为模型的上下文是有限的、会被压缩的，而长篇需要的是持久状态。

发展。三件事改变了做法：① RAG 与文件检索让「按需读取设定」成为可能；② Agent Skills 规范（2025–2026）让「一套写法」可以被拆成多个可加载文件、按需注入；③ hook/门禁机制让「流程约束」从「提示词里的请求」变成「程序上的必然」。

今生。Oh Story 的做法是把长篇写作拆成四个可以独立维护的层：设定、大纲、正文、追踪。关键在于「追踪」层——它把连续性写进一份固定 7 栏、硬上限 12KB 的上下文文件，下一章只读这一份，且明确区分「作者真相」与「读者已知」（作者认为这是「角色提前知道答案、伏笔写飞」的主要来源）。写作前有 guard-outline-before-prose.sh 拦截缺细纲的章节，写完跑确定性的检查脚本（查截断、查 AI 句式、查标点），再由 storyctl.py 提交状态并整份重生成派生视图——手改派生文件会被 check 拒绝。

下一步可能怎么发展（分析 / 推演）。这套「用文件系统承载长任务状态 + 用脚本做确定性门禁」的结构，很可能会被搬出网文领域：长周期研究报告、系列课件、产品需求文档、连续剧剧本——任何「需要记住前面写过什么」的创作都可以复用。以上为推演，非事实。

04｜原始资料

• 开源仓库zenstory-ai/oh-story-claudecode（MIT，Python，建于 2026-04-22）
  https://github.com/zenstory-ai/oh-story-claudecode
• 项目主页官方站点
  https://zenstory.ai/oh-story
• 发布记录Releases（最近内容版本 v0.8.4 于 2026-09-27 发布）
  github.com/zenstory-ai/oh-story-claudecode/releases
• 窗口内提交PR #455（10-03 14:11 北京时间）与 PR #456（10-03 16:56 北京时间）
  github.com/zenstory-ai/oh-story-claudecode/pulls
• 完整样例demo/ 目录（含长篇续写、拆文报告、状态卡等成片文件）
  github.com/zenstory-ai/oh-story-claudecode/tree/main/demo
• 部署文档docs/hosts.md（各编程 Agent 的部署差异与安装排查）
  github.com/zenstory-ai/oh-story-claudecode/blob/main/docs/hosts.md
• 讨论区GitHub Discussions
  github.com/zenstory-ai/oh-story-claudecode/discussions

05｜作者是谁？

仓库归属组织 zenstory-ai，配套官网域名为 zenstory.ai，另有 Telegram 交流群与 GitHub Discussions——属于团队 / 组织级项目，而非单人一次性作品。README 中出现的 demo 说明写作样例来自「项目作者自己的长篇」，可见开发者本人也是目标用户。团队的具体构成、公司信息、是否已商业化，公开资料未披露，本文不猜。

06｜解决了什么真实问题？

从需求侧看，痛点集中在「长篇的持续性」：

• 需求一（网文作者）。写到第 80 章，前面的伏笔、角色状态、时间线已经多到记不住。人写都容易错，让 AI 写更容易崩；而一旦崩了，改一处要牵动几十章。
• 需求二（新人入行）。网文行业有明确的方法论（扫榜 → 拆文 → 商业化写作），但新手缺少「把方法论落成动作」的工具，只能靠自己摸。
• 需求三（多平台分发）。同一部作品要在起点、番茄、晋江、七猫、知乎盐言等不同平台适配，格式与节奏要求不同。
• 共同点：不是「写不出字」，而是「写长了就守不住规矩」。

07｜完整技术栈

08｜完整 Workflow

路径 A：长篇续写（源自 README 的 demo 实录）

路径 B：拆文分析　/story-long-analyze 拆解目标作品（README 以《盘龙》开篇 23 章约 6.2 万字为例），按特定读者口味逐维度打分（开篇钩子、节奏、爽感等），并要求「评分要给得出理由」。

09｜它到底是怎么实现的？

这套系统真正的技术贡献有四点，每一点都可以脱离「网文」独立成立：

① 状态与展示分离（Single Source of Truth）。所有派生视图（上下文、伏笔、角色状态、时间线）都由 _tracking-state.json 整份重新渲染，且「手改派生文件会被 check 拒绝」。这直接消灭了「文档和状态不一致」这类最常见的团队协作问题——人写长文档会走样，程序渲染不会。

② 把「连续性」压缩成固定 12KB。控制上下文体积是 Agent 工程的核心约束。作者用「固定 7 栏 + 硬上限 12KB + 不进正文 prompt」三个约束，让续写只依赖一份稳定的状态快照，而不是整部作品的历史对话。

③ 区分「作者真相」与「读者已知」。这是一个非常专业的小说工程概念：作者知道结局，读者不知道。混淆两者，就会出现「角色提前知道答案」这种崩坏。项目把它做成了两份独立的记录文件。

④ 用 hook 把「请求」变成「必然」。「写正文前必须有细纲」如果只写在提示词里，模型可能忘；做成 guard-outline-before-prose.sh 钩子，就变成了流程上的硬约束。这是本案例最值得迁移的一条工程经验。

10｜手把手复现

Step 1（原文）。安装 skill：npx skills add zenstory-ai/oh-story-claudecode -y -g。加 -g 为全局安装（所有目录可用），去掉则只装到当前目录；更新时重新执行同一条命令即可。

Step 2（原文）。也可以直接对 Agent 说一句话：「安装这个 skill https://github.com/zenstory-ai/oh-story-claudecode」（适用于支持导入 GitHub 仓库 / skill 的平台）。

Step 3（原文）。部署环境：在写作项目根运行 /story-setup（Codex 用 $story-setup），它会把 hooks / agents / references 部署到位。

Step 4（原文）。然后新开会话。升级后同样要重跑一次 /story-setup。

Step 5（原文·可选）。若已有连载作品，用 /story-import 把已发布章节反向重建成可续写工程。

Step 6（原文）。写下一章：/story-long-write 写第21章——skill 会先检查细纲是否存在，缺则先补纲，再走写作与检查链。想拆解参考作品用 /story-long-analyze。

Step 7（本文补充的建议）。第一次先只跑「导入 + 拆文 + 补细纲」，不写正文，确认状态卡与伏笔表的结构符合你的写作习惯后，再进入正文生成。

Step 8（本文补充的建议）。把状态卡（12KB 上限）当作你的「写作交接单」：每次收工前确认「下一章承诺」一栏写清楚了，这比让模型记住一切更可靠。此建议为本文推导。

11｜Prompt / Code / Config

原作者公开的内容（可直接引用）：

• 安装与初始化命令：npx skills add zenstory-ai/oh-story-claudecode -y -g、/story-setup、/story-long-write 写第21章、/story-long-analyze、/story-import
• 状态卡结构（README 给出完整示例）：固定 7 栏——当前位置 / 长期约束 / 活跃伏笔 / 下一章承诺 / 连贯性风险 等
• 门禁与检查脚本名：guard-outline-before-prose.sh、storyctl.py chapter check、check-ai-patterns.js、check-degeneration.js、normalize-punctuation、tracking_commit.py check
• 词表与世界观词汇替换表：README 提到写作前会做「工程词」检查（避免正文出现编程味表达）
• 显式发布清单：.clawhub/publish.json（ClawHub 分发用）

原作者未公开的内容：各专业 Agent 的完整系统提示词、100+ 份方法论文档的全文、hooks 的完整实现。本文不编造。

12｜踩坑

13｜中国用户能不能直接做？

• 国内访问：有限制——仓库与 skill 通过 GitHub / npx 分发，直连不稳定，通常需要加速。
• 注册：无需注册，无账号体系；项目结构完全落在本地文件系统。
• API：不额外需要 Key；成本发生在你使用的编程 Agent 与模型上。
• 成本：skill 本体免费开源；主要成本是模型调用（长篇续写属于长任务，token 消耗随章数增长）。
• 技术门槛：有一定门槛 需要会用命令行、理解 Agent 的 skill / hook 机制；不需要 GPU（README 明确说明）。

14｜国产替代方案

15｜中国企业可以怎么用？

• 企业场景 1｜内容工作室 / MCN。把选题拆解、系列内容规划、跨平台改写做成类似的 skill 包，用状态文件管住长期选题库与人物设定。
• 企业场景 2｜长文档生产。白皮书、系列课件、产品手册——凡是要写 50 页以上、且前后必须一致的内容，都可以复用「状态卡 + 门禁脚本 + 派生视图重生成」这套结构。
• 企业场景 3｜版权与合规审查。把「本章退役登记」「作者真相 vs 读者已知」这类记录用于内容审核留痕，形成可追溯的创作过程档案。

16｜中国消费者可以怎么用？

• 网文创作者：用 /story-import 把手上连载的作品导入，让 AI 帮忙补细纲、查伏笔漏洞，而不是替你写。
• 长篇爱好者：用 /story-long-analyze 拆解自己喜欢的作品，理解「为什么这段好看」。
• 写作新手：把「扫榜 → 拆文 → 商业化写作」这条方法论当成入行地图，先学规矩再动手。

17｜如何变成一个赚钱的项目？

产品化：不做「另一个写作工具」，而做「长篇连续性保险」——订阅制的状态管理与一致性审查服务，用户带自己的稿子进来，输出伏笔报告与风险清单。

服务化：给内容工作室做「AI 写作流水线搭建」，交付 skill 包 + 状态规范 + 团队培训。

咨询化：「如何让 AI 参与长篇创作而不崩」本身就是稀缺咨询：帮团队设计角色设定库、伏笔台账、审核门禁。

培训化：《AI 辅助长篇创作实战》——面向网文作者与编剧，2 天训练营，产出可运行的写作工程。

内容化：「我用文件系统管住了 100 章的伏笔」是天然的内容选题，适合 B站、公众号、小红书。

18｜变现路径

注意：以上为基于案例结构的潜在商业模式分析，非已验证的商业成功；项目未公开任何收入信息。

19｜如果我是一个中国独立开发者（7 天 MVP）

1. Day 1：装好 oh-story，用国产 Agent + 国产模型跑通「导入一部作品 → 补一章细纲」。
2. Day 2：把「伏笔台账」单独抽出来做成一个可独立使用的 skill（这是最可迁移的部分）。
3. Day 3：做一个最小界面：上传 TXT / Markdown 稿件 → 输出伏笔与人物一致性报告。
4. Day 4：找 3 位连载作者免费试用，收集「哪条报告最有用」。
5. Day 5：按反馈收敛到 1 个杀手功能（建议：伏笔漏收提醒）。
6. Day 6：写一页说明 + 一个真实案例（作者原稿前后对比），做成落地页。
7. Day 7：定一个低价订阅（如按部作品收费），开始小范围推广。

20｜如何迁移到其他行业

21｜培训课程设计

22｜培训师点评

23｜最终判断

说明：以上是案例属性描述，不是排名。「变现潜力高」是因为网文/编剧人群付费意愿明确且方法论可复用于其他长内容；「复现难度中」是因为需要熟练使用 Agent 的 skill / hook 机制。

01｜案例是什么？

开发者 KimYx0207 维护的开源中文教程仓库 AI-Coding-Guide-Zh（MIT）：把当前主流 AI 编程工具——Claude Code、OpenClaw、Codex、WorkBuddy——的教学内容组织成四条并行的学习路径（编程 / 助手 / Agent / 办公），目前公开的规模是「50 篇完整教程 + 1 张速查卡 + 80 万+ 内容量 + 1500+ 实操示例」。它最特别的地方不是内容多，而是像软件一样管版本：仓库用 Release 记录每一轮复核的范围与结论。

02｜为什么今天值得关注？

• 窗口内的事实（可用 API 核实）：2026-10-03 这一天，该仓库在窗口内（10-03 12:00 → 10-04 12:00）连续发布了 三个版本：v5.3（北京时间 17:04）「四主线全面核查与实操修正」、v5.4（19:12）「正文、当前功能与跟练的第二轮复核」、v5.5（22:13）「四工具教学补齐与近期变化复核」。同一天还有 15 次提交在窗口内落地。
• 为什么以前不容易做：AI 编程工具迭代极快，教程的生命周期常常只有几周——今天写的操作步骤，下个版本就失效。中文圈尤其严重：一手文档多为英文，中文教程多为转载与拼凑。
• 为什么现在变得值得做：① 工具生态从「一个工具」变成「一个矩阵」（Claude Code / OpenClaw / Codex / WorkBuddy 各有所长），用户需要的是选择与迁移的路径，而不是单点技巧；② Agent / Skill 这些概念让「一套方法能否迁移到另一个工具」成为真实问题。
• 为什么值得花时间：「教程即产品」是一种很少被认真对待的商业形态——它同时具备内容资产、社群入口、培训素材三重属性。

03｜案例的前世今生

前世。中文 AI 工具教程的第一阶段是「翻译与搬运」：把官方文档翻一遍，配上截图。问题在于更新无机制——工具一升级，教程就成了误导。

发展。第二阶段是「个人经验帖」：某位博主写自己怎么用某个工具解决了某个问题，可读性强但不成体系，也没人负责更新。第三阶段开始出现「仓库化的教程」——用 Git 管内容、用 Issue 收反馈、用 Release 记版本。

今生。本项目属于第三阶段的成熟样本：它不只写内容，还建立了「复核」这个动作。窗口内一天连发三个版本，版本说明写的是「全面核查与实操修正」「第二轮复核」「四工具教学补齐」——这不是新写了一章，而是对既有内容做交叉验证。README 的版本说明（v5.5「四工具教学补齐与近期变化复核」）也印证了这一点。

下一步可能怎么发展（分析 / 推演）。教程类仓库最可能的进化方向是「可执行化」：不只教你点哪里，而是把操作本身做成 skill / 脚本，读者拉下来就能跑；进一步可能出现「教程自动校验」——用程序定期跑一遍文档里的命令，失效就报警。以上为推演，非事实。

04｜原始资料

• 开源仓库KimYx0207/AI-Coding-Guide-Zh（MIT，Python，建于 2026-02-11）
  https://github.com/KimYx0207/AI-Coding-Guide-Zh
• 发布记录Releases（窗口内 v5.3 / v5.4 / v5.5，均发布于 2026-10-03）
  github.com/KimYx0207/AI-Coding-Guide-Zh/releases
• 版本说明v5.5「四工具教学补齐与近期变化复核」
  github.com/KimYx0207/AI-Coding-Guide-Zh/releases/tag/v5.5
• 窗口内提交10-03 的 15 次提交（含 4 个 PR 合并）
  github.com/KimYx0207/AI-Coding-Guide-Zh/commits/main

05｜作者是谁？

GitHub 账号 KimYx0207，仓库含 1,060 个 Fork、5,000+ Star，话题标签包含 chinese、ai-tutorial、claude-code、openclaw——属于长期投入的中文技术内容创作者。具体身份（公司、职业）未公开披露，本文不猜。

06｜解决了什么真实问题？

从需求侧看，痛点是「学习成本与迭代速度不匹配」：

• 需求一（想入门的开发者）。AI 编程工具太多了，不知道从哪个开始、它们有什么区别、学哪个更划算。
• 需求二（已入门的用户）。学会一个工具后，想迁移到另一个（比如从 Codex 到 Claude Code），但两者的概念体系不同，找不到对照。
• 需求三（企业侧）。要给团队做 AI 工具选型与培训，缺少能直接用的中文材料。
• 共同点：不是「没有教程」，而是「没有一份跟得上工具迭代、且覆盖多个工具的对照式教程」。

07｜完整技术栈

08｜完整 Workflow

读者侧（学习路径）

作者侧（维护流程，源自窗口内提交记录）

09｜它到底是怎么实现的？

这个案例没有模型、没有 Agent、没有代码框架，它值得研究的是「内容工程化」的三条做法：

① 把教程当软件发版。「v5.3 / v5.4 / v5.5」这样的版本号，让读者知道「我看到的是哪一轮复核的结果」。对快速迭代的工具教程来说，这比内容本身更重要——它解决的是可信度随时间衰减的问题。

② 用 PR 与分支表达「这一轮改了什么」。窗口内的分支命名（docs/full-refresh-20261003、docs/round2-content-20261003、docs/refresh-workflows-20261003）本身就是一份维护日志：第一轮全面核查、第二轮内容复核、第三轮工作流刷新。这套流程与软件团队的协作习惯一致。

③ 用「四工具对照」建立迁移价值。单工具教程会被官方文档替代，多工具对照教程不会——因为「A 和 B 的差别在哪」是官方文档天然不会写的。

为什么它可以工作？因为它把「更新」当成核心功能，而不是附带动作。绝大多数教程仓库死于「写了就不管」，而这个仓库用 Release 机制把「我得持续复核」变成了公开承诺。

10｜手把手复现

Step 1（原文/仓库可观测）。clone 仓库，从速查卡开始建立全局印象，再按自己身份选一条主线（编程 / 助手 / Agent / 办公）。

Step 2（原文/仓库可观测）。读 Releases 页，确认当前读到的是哪一轮复核后的内容；工具升级后先回到这里检查。

Step 3（原文/仓库可观测）。按需自备四款工具的账号与额度，跟着实操示例做一遍——教程的价值在于「跟练」，不在阅读。

Step 4（本文补充的建议）。给自己建一个「团队版」：把与你业务相关的章节摘成内部文档，标注「已在本团队验证」与「未验证」两类，避免把教程当规范。

Step 5（本文补充的建议）。用同样的「版本号 + 复核范围」机制管理你自己的内部 AI 使用手册——很多团队的 AI 规范文档失效，就是因为没有人负责更新。

Step 6（本文补充的建议）。把教程里出现的命令整理成一份可执行脚本清单，定期跑一遍；能自动化验证的文档才是活的文档。

11｜Prompt / Code / Config

原作者公开的内容：

• 50 篇教程正文与 1 张速查卡（Markdown 全文公开）
• 版本说明（Release Notes）：如 v5.5「四工具教学补齐与近期变化复核」
• 四条学习路径的结构划分：编程 / 助手 / Agent / 办公
• 窗口内的分支与 PR 命名（可反映其维护流程）

本文未获取到的内容：教程内容的具体章节清单、每篇的独立校验记录、作者个人的写作提示词。本文不编造。

12｜踩坑

13｜中国用户能不能直接做？

• 国内访问：GitHub 直连不稳定，仓库内容基本为纯 Markdown，可离线阅读或镜像获取；教程本身包含 WorkBuddy 等国内可用的工具，方向对国内用户友好。
• 注册：阅读不需要；跟练需要对应工具的账号。
• API：教程本身不需要 Key；跟练四款工具时按各自规则申请额度。
• 成本：内容免费；跟练成本取决于所选工具的免费额度与付费档位。
• 技术门槛：普通用户可以开始 内容为中文、以图文为主；深入部分需要命令行基础。

14｜国产替代方案

15｜中国企业可以怎么用？

• 企业场景 1｜AI 工具选型。把四工具对照章节作为内部选型的参考材料，快速判断团队该从哪个工具切入。
• 企业场景 2｜团队内训教材底稿。以它为基础裁剪出一套内部培训材料，补上「我们公司的规范」这一层。
• 企业场景 3｜内部手册的版本机制。直接借用「版本号 + 复核范围 + PR」的做法，管理公司自己的 AI 使用规范文档。

16｜中国消费者可以怎么用？

• 个人入门：照着四条路径之一，从速查卡到跟练，把一款工具真正用起来。
• 转岗 / 求职：把「会用 AI 编程工具」变成可展示的技能，教程内容可作为练习清单。
• 做副业：把学会的流程包装成接单能力（小工具、脚本、自动化）。

17｜如何变成一个赚钱的项目？

产品化：把「对照式教程」升级为「企业 AI 工具能力矩阵」——按岗位输出学习路径与考核题，卖的是路径而不只是内容。

服务化：企业 AI 工具落地的陪伴式服务：选型 + 内训 + 手册维护，按季度收费。教程版式天然适合做交付物。

咨询化：为企业判断「该把哪些岗位的哪些工作交给 AI 工具」，属于流程咨询。

培训化：把四条主线直接改造成企业内训课（这也是本案例最直接的变现路径）。

内容化：拆解「教程如何像软件一样发版」，本身对做知识产品的人有很强吸引力。

18｜变现路径

注意：以上为基于案例结构的潜在商业模式分析，非已验证的商业成功；作者未公开任何收入信息。

19｜如果我是一个中国独立开发者（7 天 MVP）

1. Day 1：通读速查卡与一条主线，选定一个细分人群（建议：中小企业的非技术岗，如运营/客服主管）。
2. Day 2：把教程裁剪成该岗位的「10 个能用 AI 完成的具体任务」清单。
3. Day 3：为其中 3 个任务做成可直接跑的操作脚本 / 提示词模板。
4. Day 4：招 3 位该岗位的人免费试学，记录卡点。
5. Day 5：按卡点重写材料（大概率是「术语太多」），并加上 5 分钟视频讲解。
6. Day 6：做一个落地页 + 微信/飞书答疑群，先聚人再收费。
7. Day 7：推出「岗位版 AI 提效课」，低价试卖，验证付费意愿。

20｜如何迁移到其他行业

21｜培训课程设计

22｜培训师点评

23｜最终判断

说明：以上是案例属性描述，不是排名。「复现难度低」指作为一个内容资产模型极易复制（会写、会维护即可）；「不变现风险」在于内容品类竞争激烈，需要明确的受众切分。