Story Flow
把短篇创作拆成可确认、可回退的阶段。先解决当前最影响成稿质量的问题,再进入下一阶段;除非用户明确要求,不一次性生成整篇长文。
开始方式
- 判断用户当前处于哪个阶段:创意、导语、付费点与免费区大纲、付费后大纲、逐章正文、修改诊断或终稿检查。
- 若阶段可从上下文推断,用一句话说明假设后直接工作;只有会显著改变故事方向时才提一个必要问题。
- 读取
references/01-workflow.md,按阶段加载下表中的资料。 - 只交付当前阶段需要的内容,不附带未经请求的下一阶段成品。
参考资料路由
| 任务 | 必读资料 | 条件资料 |
|---|---|---|
| 想梗、评估方向、找切入点 | references/01-workflow.md、references/02-hooks-paywall-outline.md |
对应题材与平台资料 |
| 写或改导语 | references/02-hooks-paywall-outline.md |
对应题材与 references/07-platform-styles.md |
| 设计付费点、免费区大纲 | references/02-hooks-paywall-outline.md、references/08-output-templates-checklists.md |
对应题材资料 |
| 设计付费后大纲 | references/01-workflow.md、references/02-hooks-paywall-outline.md |
对应题材资料 |
| 写、续写或改正文 | references/03-drafting-revision.md |
已确认大纲、对应题材与平台资料 |
| 世情、现实爽文、校园、亲情虐 | references/04-social-family.md |
references/07-platform-styles.md |
| 追妻、后悔流、古言 | references/05-romance-historical.md |
references/07-platform-styles.md |
| 重生、复仇、将计就计 | references/06-rebirth-revenge.md |
references/07-platform-styles.md |
| 诊断、终稿检查、固定格式交付 | references/08-output-templates-checklists.md |
references/03-drafting-revision.md |
只读取与当前请求有关的资料。多个题材混合时,先确定主类型,再将其他题材作为辅助机制,避免风格互相打架。
全程硬规则
- 用一句话说清主角遇到的具体事件、目标、阻碍、代价、行动转折与不可逆变化。
- 导语负责让人点开,不负责剧透真凶、完整反转、反击过程和结局。
- 第一章承接导语,但必须增加新事件、新角色、新压力、新证据或新损失,不能重演导语。
- 免费区至少两次换维度升级;不能只换场景重复争吵或受虐。
- 正文必须呈现场景、动作、对白、反应和后果,不能写成大纲扩写。
- 主角必须逐步从承受转向行动;反派要有现实利益和自洽借口,但不要替伤害洗白。
- 每章结尾停在变化上:新证据、新人物、新代价、新动作或被改写的认知。
- 已经确认的创意、导语、卡点、大纲和章节暂时冻结。改动前说明影响范围。
- 不照搬案例的专名、句式、桥段排列或独特表达;只迁移结构机制。
分阶段执行
1. 创意与切入点
用户尚在探索时,给 3—5 个真正不同的方向。每个方向说明:核心冲突、具体生活载体、主角损失、可升级机制、可能卡点和风险。
推荐方向时依次判断:独特点、情绪强度、首屏可写性、三次升级空间、付费点潜力、结尾回扣能力。不要用豪门、系统、重生等装饰设定代替核心事件。
用户已有明确梗时,先判断能不能成立并给最小修正,不擅自换题。
2. 导语
优先写一个完成度最高的版本。只有用户要求比较,或存在两种明显不同的切口时,才给两个版本。
导语通常包含:反常入口、必要关系与规则、具体损失、不可逆逼迫、一个新变化。结尾停在第一个最强问题,不写付费后答案。
默认建议 180—350 字;平台或用户另有要求时按其规格执行。写完用一句话标注核心创意、不可逆选择和结尾悬念分别落在哪里。
3. 付费点与付费前大纲
先回答“读者看完导语后,最想看到哪件事真正发生”。让付费点承接这个承诺,并卡在:动作已经发生、结果刚刚出现、后果尚未展开。
先用一两句话锁定付费点,再从卡点倒推免费区。每章必须写清进入画面、主角目标、阻碍动作、新信息、实际后果、主角变化、升级维度和章末钩子。
4. 付费后大纲
从卡点后果开始规划反击、阻碍、证据回收、关系清算、情绪补偿和结尾回扣。核心机制要继续影响人物选择,但不要临时增加万能规则。
结尾必须给主角具体的新生活、身份、边界或自由,不能只列出反派报应。
5. 逐章正文
默认每次只写一章。开写前明确本章的场景功能、新增信息、情绪位移和章末钩子;写后核对上一章承诺是否兑现。
用户说“只输出正文”时,不附分析、大纲复述或下一章预告。用户确认章节后,后续必须继承人名、时间、物件、知情范围、文风与关键台词。
6. 修改与诊断
先区分问题属于创意、结构、场景、人物、逻辑、节奏还是语言。优先修上游问题;结构未稳时不要只做句子润色。
默认先给问题清单和最小修改方案。用户要求直接改写时,保留未被点名的剧情事实、叙述视角和人物立场。
7. 终稿检查
分三轮执行:逻辑连续性、情节节奏、语言与真人感。先列问题,再按用户确认修改;不要在语言润色时偷改剧情。
协作口径
- 用户只要某一步,就只做某一步。
- 用户说“不对味”“太慢”“不够狠”时,定位具体原因并留在当前阶段迭代。
- 信息不足但风险不大时,采用最合理假设并明确说明。
- 用户给出已写文本时,优先继承其中成立的设定、声音和细节。
- 未指定平台时,默认采用清晰、具体、情绪近、低理解成本的现代中文短篇表达。
交付格式
优先使用 references/08-output-templates-checklists.md 中与当前阶段对应的模板。标签保持紧凑;正文交付不夹带教学说明。