Short Novel Write

Short Novel Write

用于把“写一篇短篇小说”做成稳定流程，而不是一次性吐一大段不可控文本。

本技能当前采用“先把本地写作能力做稳，再逐步把稳定动作下沉成工具”的路线。 默认场景是：用户希望 Agent 能围绕一个方向，生成创意、收敛方案、写出完整短篇，并落盘为本地文件。

当前阶段定位

• 先解决本地短篇写作
• 默认输出 Markdown 成稿
• 优先把流程跑通，再逐步沉淀工具
• 不默认绑定知乎、飞书或其他平台

如果后续仓库新增了稳定工具，本技能优先调用工具完成确定性动作。 如果工具还不存在，不要卡住，直接按流程继续完成写作任务。

CLI 调用约定

当前仓库已经提供统一 CLI：

• tools/story_cli.py

当任务进入“完稿自检”或“保存成稿”阶段时，优先通过 CLI 调工具，而不是在技能里手动重复做同一套确定性判断。

PowerShell 调用前先切到 UTF-8：

[Console]::InputEncoding = [System.Text.UTF8Encoding]::new($false)
[Console]::OutputEncoding = [System.Text.UTF8Encoding]::new($false)
$OutputEncoding = [Console]::OutputEncoding
chcp 65001 > $null

统一调用方式：

@'
{"action":"inspect","payload":{"content":"# 标题\n\n## 简介\n...","target_char_range":[5000,8000],"summary_char_range":[50,120]}}
'@ | .\.venv\Scripts\python.exe tools\story_cli.py

当前优先使用的动作：

• build_story_plans

基于已选创意包生成 3-4 组完整故事方案

• build_story_payloads

把已选方案收口成稳定正文输入

• build_story_drafts

基于正文 payload 生成完整 Markdown 草稿

• inspect

一次同时做结构检查和质量检查

• save

保存最终 Markdown 成稿

默认工具链顺序：

build_story_plans -> build_story_payloads -> build_story_drafts -> inspect -> save

如果当前目标是直接产出可进入保存阶段的版本，而不是保留原始首稿做对比：

• 优先在 build_story_drafts 阶段显式开启 auto_revise=true
• 同时传对应风格的 revision_profile_name
• 让草稿在进入 inspect 前先走一轮自动修订后处理

如果存在可用的 LLM 配置：

• 创意包、方案、正文草稿都优先尝试 generation_mode="llm"
• deterministic 版本主要作为流程基线、测试基线和回退方案

如果 LLM 链路返回 AGENT_FALLBACK_REQUIRED：

• 不要卡住等待
• 直接由 skill/agent 手动继续完成当前环节

适用场景

当用户出现下面这些意图时，可以使用本技能：

• “写一篇短篇小说”
• “给我几个短篇创意”
• “按这个设定扩成一个完整故事”
• “先出方案，再开始写”
• “帮我把这个脑洞写成短篇”

工作原则

1. 先收敛，再展开。

先确定创意和方案，再写正文，不直接一把梭全文。

1. 默认自动继续。

用户没有明确说“停下来让我选”时，不要在每一步都卡住等待。

1. 先保证完整，再追求华丽。

完整故事、清楚冲突、有效转折、可读结尾，优先级高于辞藻。

1. 工具做确定性动作。

去重、统计、检查、落盘这些能力尽量交给工具；创意判断和写作推进仍由技能主导。

默认流程

触发技能后，按下面顺序推进，除非用户已经明确给出了其中一部分信息。

1. 判断输入类型

先判断用户属于哪一类：

• 已有核心创意，只需要展开
• 只有模糊方向，需要补创意
• 已有创意和部分结构，需要继续写
• 已有正文草稿，需要续写或修订

如果用户已经给了明确设定，不重复追问同一件事。

2. 补创意或整理创意

如果用户没有核心创意：

• 生成 4 组差异明显的创意
• 每组至少包含：
• 一句话钩子
• 核心关系
• 主冲突
• 可能的反转方向
• 推荐题材标签

如果用户已有创意：

• 先把创意整理成一句话钩子
• 明确主角目标、阻力和代价
• 找出最适合写成短篇的冲突入口

如果用户没有指定“我来选”，就默认从候选里自动选出最适合落地的一组继续。

3. 确定篇幅档位

默认给出下面 4 档：

• 3000-5000 字，约 4-6 章
• 5000-8000 字，约 6-8 章
• 8000-12000 字，约 8-10 章
• 12000-15000 字，约 10-12 章

用户未指定时，默认使用 5000-8000 字，约 6-8 章。

4. 生成故事方案

围绕已确定的创意，生成 3-4 组方案。 每组方案至少包含：

• 暂定标题
• 题材与氛围
• 一句话卖点
• 主角目标
• 核心关系
• 主冲突
• 转折点
• 结尾方向
• 章节节奏概览

标题不要直接照搬用户原句。 默认要求是：

• 优先控制在 6-16 个汉字
• 具体、有画面感、有记忆点
• 不要像一句剧情说明

如果用户不选，默认保留最有钩子、最适合短篇节奏的一组继续。

如果仓库内存在 tools/story_cli.py 且当前已经有可用创意包：

1. 优先调用 build_story_plans
2. 再用 list_story_plans 查看候选方案
3. 如果用户不选，默认自动挑一组最适合短篇节奏的方案继续
4. 选定后可用 update_story_plan_status 标成 selected
5. 如果走 LLM 链，不要默认和正文阶段共用同一个 llm_environment
6. 对豆瓣风格或其他长输出更敏感的风格，优先给方案阶段单独准备一个偏稳妥的环境

5. 锁定写作简报

开始正文前，先锁定最小写作简报：

• 最终采用的创意
• 暂定标题
• 目标字数
• 目标章节数
• 主角与核心关系
• 主冲突
• 关键转折
• 结尾落点

这一步的目的是防止正文写到中途失控跑偏。

如果仓库内存在 tools/story_cli.py：

1. 对已选方案优先调用 build_story_payloads
2. 再用 list_story_payloads 读取对应 payload
3. 后续正文阶段优先直接消费这个 payload，不要再从方案全文里重新抽字段

6. 写正文

默认先写简介，再写正文。

本地成稿默认结构：

# 标题

## 简介

50-120 字的钩子式简介

## 正文

### 1

正文内容

### 2

正文内容

正文要求：

• 开头尽快进入异常、冲突或悬念
• 每章都要推进事件，而不是原地抒情
• 至少出现 1 次有效转折
• 结尾要回应主冲突，不要写成突然中断
• 句式有长短变化，不能整篇都一个节奏

如果仓库内存在 tools/story_cli.py：

1. 优先调用 build_story_drafts
2. 再用 list_story_drafts 读取当前正文草稿
3. 默认直接在工具生成的 Markdown 草稿上继续修订，而不是重起一版自由重写
4. 如果用户不要求自己选，默认保留最顺手的一版草稿继续
5. 需要记录筛选结果时，用 update_story_draft_status
6. 如果走 LLM 链，正文阶段可以和方案阶段使用不同 llm_environment
7. 对豆瓣风格，正文环境默认要比方案环境更保守，优先给更长 timeout，不要直接复用知乎或方案阶段的环境
8. 如果当前要直接交付本地成稿，优先在 build_story_drafts 时开启：

• auto_revise=true
• 知乎风传 revision_profile_name="zhihu_tight_hook"
• 豆瓣风传 revision_profile_name="douban_subtle_scene"

1. 只有在需要保留“原始首稿”和“修订后稿”做对比时，才关闭 auto_revise

7. 完稿自检

全文完成后，必须参照 references/quality-checklist.md 做自检。 至少检查：

• 字数和结构是否符合档位
• 开头是否有钩子
• 中段是否空转
• 转折是否成立
• 结尾是否完成回收
• 标题是否贴题

如果仓库内存在 tools/story_cli.py，优先通过 CLI 的 inspect 动作完成第一轮自动自检。 自检时要读取返回 JSON 里的：

• data.overall_ok
• data.structure.issues
• data.quality.issues
• data.quality.suggestions

如果 overall_ok = false，先根据问题修订，再决定是否进入保存阶段。 自检时，基于正文再生成 1 个候选标题，与暂定标题比较后决定最终标题。

如果当前正文来自 build_story_drafts 且已开启 auto_revise：

• inspect 默认直接检查修订后的 draft 主记录
• 不需要再额外手动调用一次 revise_story_draft 才进入自检

如果当前成稿来自 build_story_drafts：

• 优先在这份草稿上做小步修订
• 修订后再次调用 inspect
• 不要因为某一轮检查失败就直接推翻整篇重写

8. 保存成稿

默认保存到：

• outputs/novels/

默认文件格式：

• UTF-8
• .md

如果仓库内存在 tools/story_cli.py，优先通过 CLI 的 save 动作落盘，并记录返回结果里的：

• data.output_dir
• data.output_path
• data.directory_created

如果没有 CLI，再直接按 UTF-8 保存，不要因此中断任务。

自动继续规则

• 用户已经给了参数，就沿用用户参数
• 用户没给创意，就自动生成候选创意
• 用户没选方案，就自动选择最稳的一组
• 用户没选篇幅，就默认 5000-8000 字
• 用户没要求分阶段确认，就不要每一步都停下来等

当前不默认做的事

下面这些能力不是本技能第一阶段默认目标：

• 自动发布平台
• 自动上传外部文档系统
• 自动回填运营表格
• 面向特定平台的格式适配

如果用户明确要求这些能力，可以后续追加，但不要把第一阶段技能写成平台流程合集。

与工具的边界

本技能负责：

• 决定写作流程
• 组织创意、方案、正文、自检
• 控制默认值和自动推进

工具更适合负责：

• 标题检查
• 字数统计
• 章节结构检查
• 文件保存
• 资源读取

结论很简单： 技能负责“怎么写”，工具负责“怎么稳”。

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: gyyxs88
• Source: gyyxs88/shortnovel_write
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.