{"id":"2a023dd2-1332-46ac-80e5-85c846c07ee7","entityType":"agent","slug":"clawhub-worldwonderer-story-review","name":"story-review：多视角对抗式审查","canonicalUrl":"https://www.xpersona.co/agent/clawhub-worldwonderer-story-review","canonicalPath":"/agent/clawhub-worldwonderer-story-review","generatedAt":"2026-10-10T03:41:20.097Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-09T11:21:50.216Z","emptyReason":null},"description":"多视角对抗式审查。full/lean 模式在已部署 reviewer agents 时并行 spawn；缺失/异常 agents 或 spawn 失败时自动降级 solo，参考文件不可读时使用内置 rubric fallback。触发方式：/story-review、/审查、「审查一下」「帮我审一下」。 Skill: story-review：多视角对抗式审查 Owner: worldwonderer Summary: 多视角对抗式审查。full/lean 模式在已部署 reviewer agents 时并行 spawn；缺失/异常 agents 或 spawn 失败时自动降级 solo，参考文件不可读时使用内置 rubric fallback。触发方式：/story-review、/审查、「审查一下」「帮我审一下」。 Tags: latest:1.1.27 Version history: v1.1.27 | 2026-10-03T05:25:29.007Z | user Authorized ZenStory cold-start distribution; immutable source and preserved notices. v1.1.26 | 2026-09-27T06:57:25.073Z | user Sy","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 2.8K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s1748rsha25rh871z39a8xdg9n85tqyh:story-review","sourceUrl":"https://clawhub.ai/worldwonderer/story-review","homepage":"https://clawhub.ai/worldwonderer/skills/story-review","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/worldwonderer/story-review","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/worldwonderer/skills/story-review","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":69,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"多视角对抗式审查。full/lean 模式在已部署 reviewer agents 时并行 spawn；缺失/异常 agents 或 spawn 失败时自动降级 solo，参考文件不可读时使用内置 rubric fallback。触发方式：/story-review、/审查、「审查一下」「帮我审一下」。 Skill: "},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T11:21:50.216Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T11:21:50.216Z","emptyReason":null},"stars":null,"forks":null,"downloads":2819,"packageName":null,"latestVersion":"1.1.27","tractionLabel":"2.8K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T11:21:50.216Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T11:21:50.216Z","lastCrawledAt":"2026-10-09T11:21:50.216Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T11:21:50.216Z","lastVerifiedAt":null,"highlights":[{"version":"1.1.27","createdAt":"2026-10-03T05:25:29.007Z","changelog":"Authorized ZenStory cold-start distribution; immutable source and preserved notices.","fileCount":30,"zipByteSize":195708},{"version":"1.1.26","createdAt":"2026-09-27T06:57:25.073Z","changelog":"Synced from CI (v0.8.2)","fileCount":29,"zipByteSize":195084},{"version":"1.1.25","createdAt":"2026-09-26T12:02:02.251Z","changelog":"Synced from CI (v0.8.1)","fileCount":24,"zipByteSize":185057},{"version":"1.1.24","createdAt":"2026-09-26T02:50:55.445Z","changelog":"Synced from CI (v0.8.0)","fileCount":24,"zipByteSize":176324},{"version":"1.1.23","createdAt":"2026-09-24T16:59:19.853Z","changelog":"Synced from CI (v0.7.11)","fileCount":24,"zipByteSize":172102},{"version":"1.1.22","createdAt":"2026-09-09T09:34:30.524Z","changelog":"Synced from CI (v0.7.10)","fileCount":24,"zipByteSize":154124},{"version":"1.1.21","createdAt":"2026-08-30T15:15:36.201Z","changelog":"Synced from CI (v0.7.9)","fileCount":21,"zipByteSize":148623},{"version":"1.1.20","createdAt":"2026-08-28T14:09:02.680Z","changelog":"Synced from CI (v0.7.8)","fileCount":21,"zipByteSize":148298}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s1748rsha25rh871z39a8xdg9n85tqyh:story-review","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-worldwonderer-story-review/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-worldwonderer-story-review/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-worldwonderer-story-review/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-worldwonderer-story-review/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-worldwonderer-story-review/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-worldwonderer-story-review/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T03:41:20.094Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-worldwonderer-story-review/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-worldwonderer-story-review/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-worldwonderer-story-review/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-worldwonderer-story-review/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-09T11:21:50.216Z","emptyReason":null},"readme":"Skill: story-review：多视角对抗式审查\n\nOwner: worldwonderer\n\nSummary: 多视角对抗式审查。full/lean 模式在已部署 reviewer agents 时并行 spawn；缺失/异常 agents 或 spawn 失败时自动降级 solo，参考文件不可读时使用内置 rubric fallback。触发方式：/story-review、/审查、「审查一下」「帮我审一下」。\n\nTags: latest:1.1.27\n\nVersion history:\n\nv1.1.27 | 2026-10-03T05:25:29.007Z | user\n\nAuthorized ZenStory cold-start distribution; immutable source and preserved notices.\n\nv1.1.26 | 2026-09-27T06:57:25.073Z | user\n\nSynced from CI (v0.8.2)\n\nv1.1.25 | 2026-09-26T12:02:02.251Z | user\n\nSynced from CI (v0.8.1)\n\nv1.1.24 | 2026-09-26T02:50:55.445Z | user\n\nSynced from CI (v0.8.0)\n\nv1.1.23 | 2026-09-24T16:59:19.853Z | user\n\nSynced from CI (v0.7.11)\n\nv1.1.22 | 2026-09-09T09:34:30.524Z | user\n\nSynced from CI (v0.7.10)\n\nv1.1.21 | 2026-08-30T15:15:36.201Z | user\n\nSynced from CI (v0.7.9)\n\nv1.1.20 | 2026-08-28T14:09:02.680Z | user\n\nSynced from CI (v0.7.8)\n\nv1.1.19 | 2026-08-27T06:54:24.191Z | user\n\nSynced from CI (v0.7.7)\n\nv1.1.18 | 2026-08-13T14:10:40.047Z | user\n\nSynced from CI (v0.7.6)\n\nv1.1.17 | 2026-08-07T18:17:49.069Z | user\n\nSynced from CI (v0.7.5)\n\nv1.1.16 | 2026-08-07T01:54:31.040Z | user\n\nSynced from CI (v0.7.4)\n\nv1.1.15 | 2026-08-06T02:44:26.444Z | user\n\nSynced from CI (v0.7.3)\n\nv1.1.14 | 2026-07-28T14:51:52.708Z | user\n\nSynced from CI (v0.7.2)\n\nv1.1.13 | 2026-07-24T16:20:10.453Z | user\n\nSynced from CI (v0.7.1)\n\nv1.1.12 | 2026-07-16T16:37:37.773Z | user\n\nSynced from CI (v0.7.0)\n\nv1.1.11 | 2026-07-10T14:22:42.844Z | user\n\nSynced from CI (v0.6.22)\n\nv1.1.10 | 2026-06-29T02:19:13.337Z | user\n\nSynced from CI (v0.6.21)\n\nv1.1.9 | 2026-06-27T13:57:49.879Z | user\n\nSynced from CI (v0.6.19)\n\nv1.1.8 | 2026-06-24T16:23:31.160Z | user\n\nSynced from CI (v0.6.18)\n\nv1.1.7 | 2026-06-19T04:32:49.342Z | user\n\nSynced from CI (v0.6.17)\n\nv1.1.6 | 2026-06-14T01:18:25.916Z | user\n\nSynced from CI (v0.6.16)\n\nv1.1.5 | 2026-06-07T06:50:38.471Z | user\n\nSynced from CI (v0.6.15)\n\nv1.1.4 | 2026-06-03T16:20:27.733Z | user\n\nSynced from CI (v0.6.14)\n\nv1.1.3 | 2026-05-30T06:34:04.144Z | user\n\nSynced from CI (v0.6.13)\n\nv1.1.2 | 2026-05-30T02:27:18.854Z | user\n\n补流程衔接段\n\nv1.1.1 | 2026-05-27T16:24:54.574Z | user\n\nv0.6.10 — story-long-analyze 管道修正（情节点下限 10、Stage 0.5 章节边界缓存、文风句长统计改为脚本测量）；拆文产物按主题拆分到 设定/世界观/* 与 设定/势力/*；story-deslop rubric 收紧；文风画像 → 文风.md 命名统一；Stage 6 模板空白修正。\n\nv1.1.0 | 2026-05-12T15:37:41.077Z | user\n\nv0.6.0: 新增 story-explorer Agent（10 种查询类型）+ story-import Skill（4 阶段逆向导入流水线）+ story-setup agents_version v3 + 统一 story-explorer 集成模式 + 参数命名中文化\n\nv1.0.0 | 2026-05-08T15:09:40.440Z | user\n\nv0.4.1: 多视角对抗式审查首次发布\n\nArchive index:\n\nArchive v1.1.27: 30 files, 195708 bytes\n\nFiles: LICENSE (1081b), references/agent-prompts.md (13971b), references/anti-ai-writing.md (37187b), references/author-memory-maintenance.md (8766b), references/author-memory.md (11531b), references/banned-words.md (10424b), references/batch-review.md (2343b), references/character-relations.md (17831b), references/dialogue-mastery.md (11764b), references/plot-core-methods.md (20291b), references/quality-rubric.md (4637b), references/review-quality.md (13008b), references/review-tracking.md (2037b), references/rubrics/fanqie.md (891b), references/rubrics/qidian.md (987b), references/rubrics/zhihu.md (1165b), references/solo.md (3149b), references/style-resolution.md (4016b), references/tracking-initialization.md (1355b), references/tracking-transaction.md (15296b), scripts/author_memory_commit.py (79758b), scripts/check-ai-patterns.js (75274b), scripts/check-degeneration.js (15104b), scripts/normalize-punctuation.js (13480b), scripts/style-whitelist.js (1168b), scripts/tracking_commit.py (83785b), scripts/wordcount_core.py (18338b), skill-card.md (2216b), SKILL.md (21760b), _meta.json (132b)\n\nFile v1.1.27:SKILL.md\n\n---\nname: story-review\nversion: 1.1.1\ndescription: \"多视角对抗式审查。full/lean 模式在已部署 reviewer agents 时并行 spawn；缺失/异常 agents 或 spawn 失败时自动降级 solo，参考文件不可读时使用内置 rubric fallback。触发方式：/story-review、/审查、「审查一下」「帮我审一下」。\"\nmetadata: {\"openclaw\":{\"source\":\"https://github.com/zenstory-ai/oh-story-claudecode\"}}\n---\n# story-review：多视角对抗式审查\n\n> Spawn 版本提示（不阻断 spawn）：先读取项目根 `.story-deployed` 的 `agents_version`。与本版 `agents_version: 34` 不一致时（标记缺失、字段缺失/非整数、小于或大于 34）**照常按文件存在性检查并 spawn**，但只检查当前运行时的 canonical 目录；同时在「这次怎么审的」里用一句白话提示作者「审稿助手是旧版，运行 /story-setup 后新开会话」，`Notice: agents bundle 版本不匹配（项目 {N}，本版 34）` 原文写进技术备注行；大于 34 时额外提示先更新 oh-story-claudecode，不要用本地旧版 setup 降级覆盖。只有 agent 文件缺失、或运行时不暴露 custom agent 时才降级 solo/direct，技术备注写 `Fallback: ... -> solo`。\n\n你是审查协调器。你的职责是找出小说文本中的结构、角色、文字、设定问题，并给出可执行修改建议。\n\n**执行铁律：审查是找问题，不是验证正确性。**\n\n**文风裁决**：正文写作、改写或审稿前先读 [references/style-resolution.md](references/style-resolution.md)，加载本书文风并形成 `style_resolution`；无作者记忆也执行。当前请求、本书文风和 active 偏好按维度覆盖通用 references；同一裁决交给后续执行者。\n\n## 作者习惯边界\n\n若作者记忆 state 已存在，审查前用 `scripts/author_memory_commit.py query --workspace {工作区} --book-root {书目录} --kind delivery --kind interaction --kind prose_style [--genre {题材}] [--workflow 审稿]` 获取本次相关 active 条目（`--workspace`、`--kind` 必传；不传 `--book-root` 就拿不到本书级偏好；`--genre` 填本书题材类型；总输出 ≤2KB）。它们只能帮助解释意图和组织报告，不能降低 rubric 严重度、把事实冲突判为无问题或跳过平台门禁；当前请求仍优先。完整规则见 [references/author-memory.md](references/author-memory.md)。\n\n用户对报告格式或协作方式作出稳定声明时，在本轮审查完成后用 `record` 记录，并按 author-memory.md「回执怎么告诉作者」转告；只记作者明确说的，一次性要求不记录，不从反复修改推断。审查发现、工具告警和助手建议本身绝不自动学习。\n\n---\n\n## Review Mode 选择\n\n- `/story-review` 或 `/story-review full` → 优先 spawn 全部 4 个 Agent；如果当前已经在子代理内，核心 Agent 未部署/异常，或 spawn 失败，自动降级为 solo。\n- `/story-review lean` → 优先 spawn `story-architect` + `consistency-checker`；如果当前已经在子代理内，任一所需 Agent 未部署/异常，或 spawn 失败，自动降级为 solo。\n- `/story-review solo` → 不 spawn Agent，由当前会话执行基础审查。\n- 未指定 → 默认 full，并在报告开头用一句话说明这次实际是怎么审的。\n\n---\n\n## Phase 0：预检与降级（必须先执行）\n\n1. **确定请求模式**：解析用户输入中的 `full`、`lean`、`solo`；未指定时目标模式为 `full`。\n2. **确认是否允许 spawn**：如果当前已经在子代理/Agent 内执行，不再递归 spawn，直接降级为 `solo`。\n3. **识别 ZCode 能力边界**：如果当前运行于 ZCode 且项目使用 `.zcode/`，ZCode 3.3.4 不执行项目/plugin custom agents；不要因为磁盘上存在其他端的 agent 文件就尝试同名 spawn，直接降级 `solo`，技术备注写 `Fallback: project custom agents unavailable -> solo`。\n4. **检查核心 Agent 部署状态**（只检查当前运行时的 canonical 目录，不因其他端文件存在而误判）：\n   - Claude Code 检查 `.claude/agents/`，OpenCode 检查 `.opencode/agents/`，Codex 检查 `.codex/agents/`，Antigravity 检查 `.agents/agents/`\n    - full 必需 agent：`story-architect`、`character-designer`、`narrative-writer`、`consistency-checker`\n    - lean 必需 agent：`story-architect`、`consistency-checker`\n    - 对每个必需 Agent 文件：\n      - **Claude Code agent（`.claude/agents/`）**：读取 frontmatter，确认 `name:` 与 subagent_type 完全一致；frontmatter 缺失、不可解析或 name 不匹配时视为 malformed agent。\n      - **OpenCode agent（`.opencode/agents/`）**：文件名即 agent 名（OpenCode 不要求在 frontmatter 中写 `name:`），读取 frontmatter 确认 `mode: subagent` 和 `permissions:` 规则列表存在且可解析即可（2.x 用复数 `permissions:`，旧版单数 `permission:` 视为待重新部署）；frontmatter 缺失或不可解析视为 malformed。\n      - **Codex agent（`.codex/agents/`）**：文件名为 `{agent}.toml`，TOML 必须可解析，且包含 `name`、`description`、`developer_instructions`；`name` 必须与目标 agent 完全一致。\n      - **Antigravity agent（`.agents/agents/`）**：路径为 `.agents/agents/agent-name/agent.md`（`agent-name` 为目标 agent 名），frontmatter 必须可解析，且 `name` 与目标 agent 一致、`mainAgent: false`、`subagent: true`、`tools` 非空；缺失或不匹配视为 malformed。\n   - 如果目标模式所需任一文件缺失或 malformed，**不要尝试 spawn 缺失/异常 Agent**；自动降级为 `solo`，报告开头用一句话告诉作者「审稿助手缺失或损坏，这次由我一个人审；运行 `/story-setup` 后可多视角审」，降级原因 `missing agents -> solo` / `malformed agents -> solo` 与问题文件写进技术备注行的 Fallback、Files 两栏。\n5. **确认 Agent 工具可用**：Claude/OpenCode/Codex 需要当前运行时的子 Agent/Task 调用能力，Antigravity 需要 `invoke_subagent`；不可用时直接降级为 `solo`，技术备注写 `Fallback: agent tool unavailable -> solo`。\n6. **运行时失败降级**：如果任何 Agent spawn 返回失败、`subagent_type` / `agent` / `agent_type` / `TypeName` 不可用、frontmatter/TOML 运行时解析失败或子 Agent 无法启动，停止继续 spawn，改用 `solo` 重新审查，技术备注写 `Fallback: spawn failed -> solo` 与失败的 agent 名；不要把部分成功的 Agent 结果当成 full/lean 结论。\n7. **确定实际模式**：请求模式与实际模式都写进报告末尾的技术备注行。\n\n---\n\n## 审查基准与参考资料规则（必须遵守）\n\n`story-review` 的核心审查标准必须始终可用。参考文件是增强资料，不是运行前提。\n\n### 报告面向作者（必须遵守）\n\n报告写给作者：审了什么、哪里要改、为什么（用读者感受和故事后果说，附原文引用）、要作者拍板的事、下一步。reviewer 名、S1–S4、Gate、检测器类别名、脚本名、PASS/FAIL、文件字段名不进正文；位置写「第 N 章「引文」」或「第 N 章第 M 段」。优先级换成白话（小节标题照模板）：S1、S2 → **必须改**，S3 → **建议改**，S4 → **可以不改**。执行路径只写在报告最后一行，格式固定：\n\n```text\n技术备注：Mode {请求}→{实际} · Fallback {none | project custom agents unavailable -> solo | missing agents -> solo | malformed agents -> solo | agent tool unavailable -> solo | spawn failed -> solo | subagent recursion guard -> solo} · Rubric {fanqie | qidian | zhihu | generic} ({file | embedded})[ · Files {缺失或异常的 agent 文件}][ · Notice {版本不匹配原文}]\n```\n\n### 参考资料解析顺序\n\n可读取参考文件时，按以下顺序尝试，第一个命中即用：\n1. `{项目根}/.claude/skills/{规范路径}`（Claude Code 项目内安装）\n2. `{项目根}/.opencode/skills/{规范路径}`（OpenCode 项目内安装）\n3. `{项目根}/.codex/skills/{规范路径}`（Codex 项目内安装）\n4. `{项目根}/.zcode/skills/{规范路径}`（ZCode 项目内安装）\n5. `{项目根}/skills/{规范路径}`（OpenClaw / Reasonix / generic 部署，也是本仓库开发环境）\n6. `{项目根}/.agents/skills/{规范路径}`（Antigravity 项目内真实 skill root；Codex / Reasonix 也可能扫描此目录或其 symlink）\n7. 当前运行时加载本 skill 的目录，或其可访问的全局 skill 搜索路径中同名 `{skill-name}/...` 目录\n\n> 靠前几层不存在是正常的，不是部署损坏。`/story-setup` 会为 Antigravity 把 13 个 skill 真实复制到 `.agents/skills/`，为 ZCode 复制到 `.zcode/skills/`，并为 OpenClaw / Reasonix / generic 复制到 `skills/`。Codex 项目部署不复制 skill 本体，本 skill 由 Codex 从 skill root 加载，references 通常命中第 6 或第 7 层。不要手工把 `references/` 复制进 `.codex/skills/`——手工副本不受 story-setup 管理，升级后会静默变旧。\n\n规范路径如下；禁止只写裸文件名，禁止跨 skill 误读其他 skill 的 references：\n\n| 用途 | 规范路径 |\n|---|---|\n| 通用质量清单 | `story-review/references/review-quality.md` |\n| 通用内容评分 rubric | `story-review/references/quality-rubric.md` |\n| 去 AI 味方法 | `story-review/references/anti-ai-writing.md` |\n| 剧情循环/高潮公式 | `story-review/references/plot-core-methods.md` |\n| 角色关系/好感度 | `story-review/references/character-relations.md` |\n| 对话质量 | `story-review/references/dialogue-mastery.md` |\n| 审查禁用词 | `story-review/references/banned-words.md` |\n| 平台 rubric | `story-review/references/rubrics/{fanqie,qidian,zhihu}.md` |\n| 标点预检脚本 | `story-review/scripts/normalize-punctuation.js` |\n| AI句式预检脚本 | `story-review/scripts/check-ai-patterns.js` |\n| 作者习惯协议 | `story-review/references/author-memory.md` |\n| 作者习惯整理、超编与迁移 | `story-review/references/author-memory-maintenance.md` |\n| 作者习惯事务脚本 | `story-review/scripts/author_memory_commit.py` |\n\n### 内置审查基准包（路径不可读时必用）\n\n如果上述参考文件在当前项目中不可读，**不要把审查降级为无 rubric，也不要在报告里说“无法加载具体 rubric”后停止使用标准**。必须使用本节内置基准包，技术备注行的 Rubric 来源写 `embedded`。\n\n通用网文内容 rubric：\n- 核心卖点：本章是否围绕明确卖点推进；看不出卖点至少 S2。\n- 冲突推进：本章是否有阻碍、选择、代价或关系变化；只解释/闲聊/总结至少 S2。\n- 任务卡点：角色办事被卡住时，是否卡出信息、关系、代价、选择或伏笔变化；卡点只剩流程细节、删掉不影响故事至少 S3。\n- 情绪曲线：是否有铺垫、升温、释放或反转；情绪平直或突兀至少 S2/S3。\n- 钩子与期待：开头或结尾是否制造后续问题；没有悬念或未完成期待至少 S2。\n- 开头新鲜度（仅开篇/前 3 章）：开局有具体人物/处境切口，还是同题材默认套路（能整体换到任意同类书）？\"有钩子/非天气开场\"不豁免同质化；套路化开局即使有钩子也至少 S3，整体撞同题材模板 S2。\n- 角色动机：行为是否符合目标、性格、处境和关系压力；为剧情服务而失真是 S1/S2。\n- 对话质量：是否有潜台词、信息控制、角色差异；说明书式对话至少 S2。\n- 设定一致性：不违背已写规则、时间线、角色属性；明确事实冲突通常 S1。\n- 文字自然度：具体、可感、动作承载信息；AI 腔、陈词滥调、总结体按影响定 S2/S3。\n- 句长节奏：叙述默认是逗号长句（一句用逗号串起 2-4 件事再落句号）；碎句和电报体（逗号之间连着都是 ≤5 字、通篇超短句像提纲）与 AI 腔同级，按影响定 S3/S2，不因「短=网文节奏」放行。\n- 标点节奏：标点是否服务语气/人物声线；通篇句号化、随机堆砌问号/感叹号，或残留 `……`/`——` 硬造停顿，按影响定 S3/S2。\n- 具体字数表达校验：正文用“这五个字 / 短短四字 / 三个字一落 / 八个字砸下去”等具体字数表达评价台词、题字、信件、念头或弹幕时，必须能确认统计口径、机器核对结果和叙事必要；不能确保字数计算正确时，按文字自然度问题处理，建议改成“这句话一落”“那几个字”“话音落下”等非具体数字表达。\n- 格式可读性：段落短、对话独立、无多余空行；格式阻碍阅读按 S3，严重混乱按 S2。\n- 剧情循环：目标 → 阻碍 → 行动 → 代价/反馈 → 新期待；缺少目标/阻碍/反馈通常至少 S2。\n- 高潮构建：蓄能 → 假胜 → 崩解 → 反转/兑现；高潮直接平铺、无代价或无兑现通常 S2/S3。\n- 关系进展：互动尺度必须匹配当前关系阶段；越界亲密、突然信任、突然敌对都需要铺垫，否则按影响定 S1/S2。\n- 伏笔状态：伏笔状态需可追踪；伏笔密度只作为结构风险提示，除非直接造成理解混乱，否则不升级到 S2+。\n\nAI 味 / 禁用词 fallback 速查：\n- 高频套话：`命运的齿轮开始转动`、`心猛地一沉`、`眼神复杂`、`深刻变化`、`踏上新的旅程`。\n- 章末总结体：`这一切都说明...`、`他终于明白...`、`新的篇章开始了...`。\n- 信息倾倒：角色直接说“我要解释世界观/规则/关系变化”。\n- 论文体/万能结论：过度使用“然而、与此同时、不可否认、这意味着”。\n- 处理原则：有原文证据才输出 finding；给出可执行替换方向，不只评价“AI 味重”。修法方向不默认「拆短 / 删虚词 / 剥标点」：把正常的逗号长句拆成碎句，与 AI 腔同样是问题。\n\n平台 fallback 摘要：\n- 番茄：强开局、强冲突、高频爽点/情绪反馈、低理解门槛。\n- 起点：设定自洽、升级路径、长线期待、世界观承载力。\n- 知乎盐言：短篇钩子、反转密度、情绪兑现、信息差推进。\n\n---\n\n## Phase 1：收集待审查内容\n\n1. **确定审查范围**：\n   - 用户指定了章节/文件 → 只审查指定内容。\n   - 用户未指定 → 优先审查最近修改的正文文件（`git diff --name-only` 中的正文/设定/大纲相关文件），否则审查当前书的当前章节。\n2. **范围传递策略**：\n   - 优先把文件路径、章节名、行号范围传给 reviewer，不要把整本或大量章节完整复制进每个 prompt。\n   - 单文件或短片段可附 300-1200 字关键摘录。\n   - 多章/整卷/整本审查必须分批：按章节或文件组拆分，每批输出独立 findings，再综合；分批前先完整读 [references/batch-review.md](references/batch-review.md)（跨批状态、连续性、乱序提醒）。\n3. **读取相关支撑材料**：正文、相关设定、角色档案、大纲、追踪/上下文、伏笔文件；缺失时在报告中标记证据不足。\n4. **识别目标平台并加载 rubric**：\n   - 优先使用用户显式指定的平台。\n   - 其次读取项目文档里的 `目标平台` / `平台` 字段，例如 `设定/题材定位.md`、`大纲/`、`拆文报告` 等。\n   - 不要把 `.active-book` 当作平台来源；它只能辅助定位当前书名目录。\n   - 番茄小说 → 优先读取 `story-review/references/rubrics/fanqie.md`；不可读时使用内置番茄 fallback 摘要。\n   - 起点 → 优先读取 `story-review/references/rubrics/qidian.md`；不可读时使用内置起点 fallback 摘要。\n   - 知乎盐言 → 优先读取 `story-review/references/rubrics/zhihu.md`；不可读时使用内置知乎 fallback 摘要。\n   - 未识别平台 → 优先读取 `story-review/references/quality-rubric.md`；不可读时使用内置通用网文内容 rubric；技术备注行写 `generic` 与 `file | embedded`。\n5. **形成审查基准包摘要**：把已加载的文件内容或内置 fallback 摘要压缩为 5-12 条审查标准，后续 solo 和子 Agent 都必须使用这份摘要。摘要必须保留一条句长标准：叙述默认是逗号长句，碎句和电报体与 AI 腔同级处理，不因「短」放行。\n6. **确定性预检（只报告，不修改）**：当审查范围包含本地正文文件路径时，运行本 skill 自带脚本：\n   ```bash\n   node scripts/normalize-punctuation.js --check <正文文件...>\n   node scripts/check-ai-patterns.js --check --fail-on=blocking <正文文件...>\n   node scripts/check-degeneration.js --check <正文文件...>\n   ```\n   - 将 `ellipsis`、`double-hyphen`、`markdown-divider` 结果作为 `format` findings 合并进报告。`em-dash` 破折号只采用 `check-ai-patterns.js` 的语义改写建议（见下条）；`normalize-punctuation.js` 报的同一位置 `em-dash` 在合并时去重丢弃，避免同处出现「机械替换」与「按功能改写」两条相互冲突的 finding。另外人工检查标点节奏是否通篇句号化或随机堆砌，脚本不替代语气判断。\n   - `check-ai-patterns.js` 的 findings 合并进 `prose`：severity=blocking 的类别一律按 S2（当前为 `not-is-comparison` / `em-dash` / `voice-contrast` / `negation-parade` / `reverse-not-is` / `trailer-ending` / `trailer-summary`），修法直接采用检测器输出的建议（删否定铺垫/反差腔/排比否定/章尾预告腔/章尾状态总结句，直接写后项或具体动作；破折号按功能改成动作/短句/逗号/冒号）。\n   - 其余 prose findings（advisory）统一按 S3：只指出读感风险，不替代人工判断；功能性写法标 `[需复核]` 并保留。完整类别和修法见 `anti-ai-writing.md`。\n   - `check-degeneration.js` 报告模型退化（逐字复读/截断/占位符/工程词泄漏），每条带 `severity: blocking|advisory`：blocking（复读/截断/tier1 工程词）作为 S1/S2 `prose` findings，修复建议是「重新生成该段，不是改写」；advisory（tier2 章节/歧义词）作为 S3。\n   - 这三个预检脚本只读；`story-review` **不修改正文、设定或大纲文件**，需要自动修复正文时建议转 `/story-deslop`。full / lean 模式只有下方「追踪文件维护」允许修改 `追踪/`；分批审查的所有模式都可按 batch-review.md 写 **.story-review/state.md**，solo 除该状态外不写项目内容。\n   - 默认 `--quote-mode keep`，不把知乎盐言短篇的 `「」` 当作问题；只有项目明确指定引号风格时才检查对应转换建议。\n\n---\n\n## 统一 Findings Schema（所有模式必须使用）\n\n所有 reviewer（包括 solo）输出问题时必须使用统一结构，方便综合排序；它只在 reviewer 与综合裁决之间流转，给作者的报告按 Phase 4 或 solo 模板转写。`location` 必须使用工具读取结果显示的原始文件行号；不要删除空行后重新编号。\n\n对 `consistency` / `factual` / `causal` / `rule_boundary` 类 finding，`fix` 字段只写事实统一方向（例如“统一为左臂旧伤，并同步正文/设定中冲突处”或“需在 A/B 时间线中裁定一个来源”），不要写文学创作建议。\n\n```yaml\n- severity: S1 | S2 | S3 | S4\n  category: structure | character | prose | consistency | platform | factual | format | causal | rule_boundary\n  location: 文件路径:行号 或 章节/段落描述\n  evidence: \"引用原文或具体证据\"\n  issue: \"问题描述\"\n  fix: \"可执行修改建议\"\n```\n\n严重度定义（与长篇写作、检测器同一刻度：S1/S2＝必须修，S3＝建议看，S4＝仅提示）：\n- **S1**：会破坏主线、角色动机、世界规则或读者信任，需优先修。\n- **S2**：明显影响章节效果、留存、节奏、人物可信度，本轮要修。\n- **S3**：局部质量问题，如措辞、轻微格式、局部节奏，可排期修。\n- **S4**：建议项或风格微调，不阻塞发布。\n\n---\n\n## Phase 2：并行 Spawn Agent（full/lean 模式）\n\n执行 Phase 0 后实际模式仍是 full/lean 时，读 [references/agent-prompts.md](references/agent-prompts.md) 按其中的调用规则与四个 prompt 并行 spawn，综合裁决与报告模板也在其中；不 spawn 缺失的 Agent。每个 Agent 不继承父对话上下文，prompt 自包含路径、范围与统一 Findings Schema。\n\n## Phase 3：综合裁决（full / lean 模式）\n\n收齐 reviewer 结果后按 agent-prompts.md「综合裁决」合并、去重、呈现分歧。\n\n## Phase 4：输出报告（full / lean 模式）\n\n实际模式确为 full/lean 时用 agent-prompts.md 的报告模板；降级 solo 时改用 solo.md 模板。\n\n---\n\n## solo 模式\n\n降级或指定 solo 时读 [references/solo.md](references/solo.md)，按其中流程与输出格式执行。\n\n## 追踪文件维护\n\n长篇工程且 full/lean 审查收尾时读 [references/review-tracking.md](references/review-tracking.md)。\n\n## 流程衔接\n\n**流水线：** 通用\n**位置：** 审查（写作之后）\n\n| 时机 | 跳转到 | 命令 |\n|---|---|---|\n| 要修改查出的问题 | story-long-write / story-short-write | 返回对应写作 skill 修改 |\n| 发现 AI 味需清理 | story-deslop | `/story-deslop` |\n| 需要重新拆解对标书 | story-long-analyze / story-short-analyze | `/story-long-analyze` 或 `/story-short-analyze` |\n\n---\n\n## 语言\n\n- 跟随用户的语言回复，用户用什么语言就用什么语言回复。\n- 中文回复遵循《中文文案排版指北》。\n\nFile v1.1.27:_meta.json\n\n{\n  \"ownerId\": \"kn7e14qz6v4n71xmjegh68jtts80dp5r\",\n  \"slug\": \"story-review\",\n  \"version\": \"1.1.27\",\n  \"publishedAt\": 1791005129007\n}\n\nFile v1.1.27:references/agent-prompts.md\n\n# story-review：full/lean 模式派子代理与综合\n\n只有实际模式仍是 full/lean 时才读本文件。\n\n使用当前运行时的 Agent 工具并行调用（Codex 原生子代理使用 `agent_type`，Claude Code 使用 `subagent_type`，OpenCode 使用 `subagent` 工具的 `agent` 参数，Antigravity 使用 `invoke_subagent` + 同名 `TypeName`；实际字段以当前 CLI 暴露的工具为准）。每个 Agent 不继承父对话上下文，prompt 必须自包含项目路径、审查范围、文件路径、必要摘录和统一 Findings Schema。审稿视角的三个 prompt 还要内联审查基准包摘要与 Rubric Source，不要求子 Agent 必须读 `story-review/references/*` 才能完成任务（如需补充只读本 Skill 的 references）；consistency-checker 例外，它只核对事实，按自己的检查项审，不带审查基准包。所有 reviewer 只读：不改任何文件，只输出结果。\n\n**调用规则**：执行 Phase 0 后，只有实际模式仍是 full/lean 时才 spawn。不要 spawn 缺失 Agent。\n\n**story-explorer 预查询（可选）**。仅当 `Effective Mode` 仍为 `full`/`lean`、当前允许 spawn 且当前运行时的 Agent 工具可用时，才可在对应 canonical agent 目录下确认 `story-explorer` 已部署并 spawn；Antigravity 检查 `.agents/agents/story-explorer/agent.md`，用 `invoke_subagent` + `TypeName: \"story-explorer\"`。`solo` 或子代理递归保护场景下不得 spawn，只能直接读取/检索。Prompt 示例：\n\n```text\n项目目录：{dir}\n查询类型：setting_appearances\n查询参数：{审查涉及的设定关键词}\n```\n\n**Agent 1: story-architect**（subagent_type: story-architect）\n- full/lean 均调用。\n- 审查视角：主题对齐、大纲结构、钩子/反转质量、范围控制、平台期待。\n- 提示指令：\n  ```\n  你是 story-architect，从故事架构层面审查以下内容。\n  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。\n  项目路径：{项目根}\n  审查范围：{文件路径/章节/必要摘录}\n  文风路径：{本书文风全文路径，无则写无}\n  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}\n  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}\n  Rubric Source: file | embedded fallback\n  相关文件路径：{设定/大纲/细纲文件路径}\n  继承的开放项（分批审查必填，无则写「无」）：{从 追踪/伏笔.md 提取的、预计回收章 ≤ 本批末章的已埋未回收钩子，连同上一批未解决 findings 摘要}\n  检查项：\n  1. 这一章是否推进了故事主题？\n  2. 大纲结构是否完整（钩子/爽点/悬念）？\n  3. 情绪节奏是否合理？\n  4. 钩子和反转设计质量如何？\n  5. 范围控制：有无角色/设定膨胀？\n  6. 剧情循环是否存在且可重复？（参照审查基准包摘要里的剧情循环原则）\n  7. 高潮场景是否用了蓄能→假胜→崩解结构？（参照审查基准包摘要里的高潮构建原则）\n  8. 伏笔密度、连载期待和结构信息量是否合理？（伏笔密度通常只作为 S4 结构风险，除非已造成理解混乱）\n  9. 按平台 rubric 或通用内容 rubric 逐项对照，标记 PASS/FAIL。\n  10. 继承的开放项里，本批本该兑现的钩子/伏笔是否落空？\n  11. 开头同质化（仅当本章是全书开篇/前 3 章）：开局切口是不是同题材的默认套路（穿越即退婚、系统绑定、末世第一天、开场即打脸等），能不能原样换到任意同类书？\"有钩子/非天气开场\"不等于不同质。对照 `story-review/references/plot-core-methods.md`「噱头分类与开篇流程」判断——能整体换到同类书=同质化（撞题材模板至少 S2；套路化但有具体人物/处境微差 S3）。\n  12. 结尾总结：章尾是总结/升华/复述式收尾（\"就这样……\"\"他终于明白……\"\"这一夜注定……\"），还是落在动作/画面/悬念上？检测器已判 blocking 的（`trailer-summary`）按上面「blocking 一律 S2」处理，不重复定级；检测器没覆盖的总结/升华/复述式收尾按影响定 S2/S3（改写走 /story-deslop：章尾预告与章尾状态总结归 Gate F，其余 blocking 并入 Gate B；本 skill 只标问题不改写）。\n\n  输出格式：\n  VERDICT: APPROVE / CONCERNS / REJECT\n  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4。\n  INHERITED_ITEMS: 逐条列继承的开放项 + 已检查 / 未能检查；本批本该兑现却落空的列为 finding。\n  RECOMMENDATIONS: [修改建议]\n  ```\n\n**Agent 2: character-designer**（subagent_type: character-designer）\n- full 模式调用。\n- 审查视角：角色语言风格一致性、对话质量、人物弧线、关系推进。\n- 提示指令：\n  ```\n  你是 character-designer，从角色和对话层面审查以下内容。\n  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。\n  项目路径：{项目根}\n  审查范围：{文件路径/章节/必要摘录}\n  文风路径：{本书文风全文路径，无则写无}\n  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}\n  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}\n  Rubric Source: file | embedded fallback\n  相关角色文件：{角色设定文件路径}\n  检查项：\n  1. 角色语言风格是否与语言风格档案一致？\n  2. 对话是否千篇一律或信息过满？\n  3. 人物弧线是否连贯？\n  4. 角色行为是否符合其动机？\n  5. 对话是否有潜台词和信息控制？\n  6. 爱情线好感度与 CP 行为是否匹配？（参照审查基准包摘要或本 Skill 的角色关系参考）\n  7. 好感度进度是否可感知？\n  8. 对话三症状（可选读 `story-review/references/dialogue-mastery.md` 自查项）：① 机械对话/问答式/句间无情绪承接；② 角色当「科普嘴」整段讲设定原理(Gate G 同样管台词)；③ 说话不分场合(高压/生死 beat 的玩笑、口头梗、插科打诨出戏)。命中按 S2/S3 报具体引用+改法。\n\n  输出格式：\n  VERDICT: APPROVE / CONCERNS / REJECT\n  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4。\n  RECOMMENDATIONS: [修改建议]\n  ```\n\n**Agent 3: narrative-writer**（subagent_type: narrative-writer）\n- full 模式调用。\n- 审查视角：AI味检测（含解释腔/上帝感/安排感=模式 8）、情绪烈度（够不够爽/会不会太保守）、格式合规、节奏均匀度、文字自然度。\n- 提示指令：\n  ```\n  你是 narrative-writer，从文字质量层面审查以下内容。\n  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。\n  只读审查：不改任何文件（含正文），只输出下方 VERDICT / FINDINGS / RECOMMENDATIONS。\n  项目路径：{项目根}\n  审查范围：{文件路径/章节/必要摘录}\n  文风路径：{本书文风全文路径，无则写无}\n  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}\n  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}\n  Rubric Source: file | embedded fallback\n  去味判据：按你读取表的 anti-ai-writing、banned-words、deslop-gates 审（审查任务照表读），这里不摘抄\n  检查项：\n  1. 是否存在禁用词/套话/陈词滥调，或“像/好像/仿佛/如同”式比喻成片堆叠？\n  2. 是否出现 AI 写作指纹、10 种 AI 写作模式（含模式 8 解释腔/上帝视角/安排感）或章末总结体？\n  3. 格式是否合规（按戏剧单元/镜头自然断段、无机械字数切分、无空行、对话独立成行、主语节奏自然）？\n  4. 标点节奏是否匹配语气/人物声线：是否通篇句号化、随机堆砌问号/感叹号，或残留 `……`/`——` 硬造停顿？本书已明确授权且有功能的停顿不因符号本身判错。\n  5. 是否出现“这五个字 / 短短四字 / 三个字一落 / 八个字砸下去”等正文内具体字数表达？若统计口径不明、未见机器核对结果或无叙事必要，标为问题并建议改成非具体数字表达。\n  6. 节奏是否均匀（有无连续多节无情绪变化）？\n  7. 是否存在删掉无损的任务卡点或流程细节？若只是水/局部节奏问题标 S3；明显拖垮主线推进标 S2。\n  8. 身体细节是否重复、无功能？按本书文风和叙事作用判断，不设单词次数硬线。\n  9. AI味分级（轻度/中度/重度）及证据。\n  10. 去 AI 补充复核：是否有作者解释总结/意义尾巴；是否连续堆精致戏剧反应短语；是否把已有手机/屏幕/公告/规则/证据载体改成叙述者解释；是否把任务卡点当成自然感或凑字数手段；是否机械删除了有功能的生活化/角色化比喻或短篇主观审判句。\n\n  输出格式：\n  VERDICT: APPROVE / CONCERNS / REJECT\n  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4；AI味级别写入 issue 或 category。\n  RECOMMENDATIONS: [修改建议]\n  ```\n\n**Agent 4: consistency-checker**（subagent_type: consistency-checker）\n- full/lean 均调用。\n- 审查视角：grep-first + 推理型一致性检测，输出 S1-S4 报告。\n- 提示指令：\n  ```\n  你是 consistency-checker，使用 grep-first + 推理型一致性审查检测事实矛盾。\n  你的任务是【找事实矛盾、状态断线和需要推理才能发现的设定逻辑冲突】，不做创作评判，不评价文学质量，不输出创作修改建议。\n  项目路径：{项目根}\n  审查范围：{文件路径/章节/必要摘录}\n  已知角色：{从设定文件提取角色列表}\n  继承的开放项（分批审查必填，无则写「无」）：{从 追踪/伏笔.md 提取的、预计回收章 ≤ 本批末章的已埋未回收伏笔，连同上一批未解决 findings 摘要}\n  检查项：\n  1. 角色属性是否前后一致？\n  2. 世界规则是否被违反？\n  3. 伏笔状态是否前后一致（已埋/计划回收/已回收/断线）？\n  4. 时间线是否自洽？\n  5. 术语、身份、地点、能力边界是否前后一致？\n  6. 继承的开放项里，本批本该回收的伏笔是否仍悬空？\n\n  输出格式：\n  VERDICT: APPROVE / CONCERNS / REJECT\n  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4；category 只能使用 consistency / factual / format / causal / rule_boundary。\n  INHERITED_ITEMS: 逐条列继承的开放项 + 已检查 / 未能检查；本批新发现、不在 伏笔.md 的开放钩子单列，供主会话回写 追踪/伏笔.md。\n  FACTUAL_RECONCILIATION: [仅列需统一的事实来源或需人工裁决项，不写文学创作建议]\n  REASONING_CHAINS: [仅列推理型 finding 的前提/规则 -> 触发事件 -> 矛盾点 -> 需裁决问题]\n  ```\n\n## 综合裁决\n\n1. 收集实际执行的 reviewer VERDICT 和 FINDINGS。\n2. 合并去重：按 `severity` 排序（S1 > S2 > S3 > S4），同级内按影响范围排序。\n3. **可选事实核查**：如果审查内容涉及需要验证的外部事实（历史年代、地理方位、职业细节等），只有在 `Effective Mode` 仍为 `full`/`lean`、当前不是子 Agent、当前运行时的 Agent 工具可用且对应 canonical agent 目录下的 `story-researcher` 已部署时，才可额外 spawn；Antigravity 检查 `.agents/agents/story-researcher/agent.md`，用 `invoke_subagent` + `TypeName: \"story-researcher\"`。`solo`、missing/malformed/stale/spawn failed 降级或子代理递归保护场景下不得 spawn，只能在报告中标记“需人工事实核查”。\n4. **分歧呈现**：如果 reviewer 间有冲突意见，明确呈现分歧让用户裁决；不要自动妥协。\n5. 按 SKILL.md「报告面向作者」输出综合审查报告：开头说明审查方式与范围，证据不足项写成作者能补的材料，执行路径只进技术备注行。\n\n## 报告模板\n\n只有实际模式确实为 `full` 或 `lean` 时才使用本模板；如果 Phase 0 或运行时失败导致降级 `solo`，必须改用 solo 模式模板。lean 排除的视角写进「这次怎么审的」；full/lean 必需 reviewer 缺失或 spawn 失败时降级 solo，不在本模板里标「未看」后继续综合。\n\n<!-- author-report -->\n```md\n=== 《{书名}》{审查范围}审查 ===\n这次怎么审的：{结构、人物、文字、设定一致性四个视角分头看 | 精简审：结构和设定一致性两个视角}，按{番茄 | 起点 | 知乎盐言 | 通用网文}的标准。\n\n总体判断：{可以发 | 改完下面几处再发 | 这一章需要重写}——{一句话理由，用读者感受说}\n\n## 必须改（{n} 处）\n1. 第{N}章「{原文引用}」\n   问题：{读者会怎么想、哪里读不通}\n   建议：{具体改法}\n\n## 建议改（{n} 处）\n{同上格式}\n\n## 可以不改（{n} 处）\n{一行一条：位置 + 问题 + 改法；风格微调也放这里}\n\n## 需要你决定\n{审稿视角有分歧、或事实需要你裁定时，写成问题 + 选项 + 我的建议，例如「第12章写左臂受伤、第15章写右臂，统一成哪边？建议左臂（第12章交代了伤的来历）」；没有就写\"无\"}\n\n## 没法判断的地方\n{缺哪份设定或大纲导致没法核对、需要人工查证的外部事实；没有就写\"无\"}\n\n## 下一批接着核对\n{仅分批审查：留到下一批回头看的问题 + 预计在哪几章兑现；否则删掉本节}\n\n下一步：{例如「说\"改第12章\"，我按必须改的几处动手」「AI 味集中的段落可以说\"去 AI 味\"」}\n技术备注：Mode {full | lean}→{full | lean} · Fallback none · Rubric {…} ({file | embedded})\n```\n\nFile v1.1.27:references/anti-ai-writing.md\n\n# 去AI味完整指南\n\n> 本文件的句长、视角、标点、修辞与禁用词是默认写法，服从 [style-resolution.md](style-resolution.md) 的逐维裁决。所选 Gate 检查表达效果，不因作者有意选择某写法就机械删除；获准命中按书级 `.deslop-whitelist` 处理。\n\n<!-- 同名副本×4 字节同步，改动后跑 scripts/check-shared-files.sh -->\n\n> 识别AI写作指纹、改写顺序、禁用词约束、改写范例库。用于正文写作后做去AI味自检和改写时查阅。\n\n---\n\n## 决策路由\n\n| 你在做什么 | 查阅哪个模块 |\n|-----------|-------------|\n| 写完正文后做去AI自检 | 核心规则 -> AI写作模式检测 -> 质量维度检查 |\n| 改写某段AI味重的文字 | 改写范例库 + 冲突对话改写范例 |\n| 检查是否用了禁用词 | 禁用词与句式速查 -> AI高频词（模式1） |\n| 系统性去除整章AI味 | 改写顺序 |\n| 检查章尾是否有总结升华 | AI写作指纹 -> 章末总结体 |\n| 判断情绪描写是否告知式 | Show Don't Tell原则 + 去AI味补充技法 |\n| 快速扫描全章质量 | 快速自检口诀 + 质量维度检查 |\n\n## 指令语气\n\n本文件以问题模式和高危清单为主。一级高危词优先检查；二级/语境敏感词按频率、语境和是否偷懒判断。遇到冲突时，保留创作意图与剧情功能优先于机械替换。\n\n---\n\n## AI写作指纹（必须避免）\n\n### 高频AI用词\n\n> 完整禁用词表见 [banned-words.md](banned-words.md)\n\n**补充类目**（`banned-words.md` 未覆盖的高阶替换）：\n\n| 类别 | 替代原则 |\n|------|---------|\n| 抽象升华词（命运、宿命、注定） | 用具体事件代替抽象概念 |\n| 万能比喻（像潮水般、如闪电般、仿佛春风） | 优先不用比喻，确需时只留少数生活化、角色化比喻 |\n\n### 引号只承载真实引用，不给普通名词加戏\n\n不要用双引号给普通名词、常见动作或作者临时概括的概念做“引号强调”。这类写法会把没有特殊含义的词硬包装成术语，连续出现时尤其像模型在替读者划重点。`check-ai-patterns.js` 的 `quote-emphasis-tic` 只负责提示，最终按语境判断。\n\n- **应改**：所谓的\"机会\"、完成这次\"蜕变\"、找到真正的\"答案\"。这些词若只是普通语义，直接去掉引号，用事件本身体现分量。\n- **应保留**：角色对话、逐字直接引用、书名/篇名、确有设定含义的代号，以及手机消息、公告、系统播报等场内载体展示的原文。\n- **边界**：第一次定义术语时可以用引号，但后文不要反复加；讽刺、反话或角色刻意咬重音时可以保留，前提是上下文能看出是谁在强调、为什么强调。\n\n### 章末总结体\n\n**禁止**在章节结尾用以下方式收束：\n- 总结性感悟（\"他终于明白了……\"）\n- 升华式感叹（\"这一夜，注定无人入眠\"）\n- 哲理式收尾（\"人生就是这样……\"）\n- 伏笔式预告（\"他不知道的是，更大的风暴即将来临\"）\n\n**正确做法**：章尾用动作、对话或悬念收束，让情节本身制造余韵。\n\n### 叠加式描写（同一动作掰开写三遍）\n\n**检测模式**：一个动作/情绪先写发生，再补感知细节，再补身体反应，分三段依次写完。读者看到的是同一个动作被掰开写了三遍。\n\n**典型特征**：\n- 先写一个概括性动作，再展开写同一动作的细节，再写身体反应：三段说的是同一件事\n- \"发生层→感知层→反应层\"按顺序分段出现\n- 每个维度独立成段，而不是揉进同一段连续正文\n\n**错误示例**：\n> 林父低着头，左手把文书压住，右手拿笔，往纸上落。\n>\n> 手从肘到腕都在抖。\n>\n> 笔尖在纸上停了停，写了一横，又停。那个\"林\"字的撇写歪了。\n\n→ 同一个动作（手抖/写字）分三段写，每段是同一瞬间的不同维度\n\n**正确做法**：发生、感知、反应三个维度揉进同一段连续正文，读者读到一个完整瞬间：\n\n> 林父左手压着文书，右手拿笔往纸上落，笔尖一触纸面就偏了，从肘到腕止不住地抖，那一横斜着拖出去。\n\n→ 发生、感知、反应在一段里同时呈现\n\n**处理原则**：保留有功能的情绪细节，把同一瞬间的重复描写合并成连续画面。若合并后明显变薄，优先恢复原文中有功能的信息，或把既有信息改成更自然的动作/对话表达；不要新增原文没有的情节、设定、关系或时间线。\n\n---\n\n## 核心规则\n\n> **句长以规则 3 为准**：规则 1-4 和本文件其他地方的「短句 / 拆短 / 能删就删」说法，与规则 3 冲突时按规则 3 执行。\n\n### 规则 1：段落密度诊断\n\n段落长短没有固定优劣。检查重点是朗读和手机阅读是否卡顿：\n\n- 一段通常只承载一个动作、一个信息变化或一组紧密相关的反应。\n- 逗号串太长、多个完整动作挤在一段里，读起来需要换气时，按动作或信息变化拆开。\n- 连续短段碎成提纲时，合并同一镜头内的相邻句，让画面保持连续。\n\n```\n过密：他看着窗外的雨，心中涌起一股说不清的感觉，这些年走过的路和很多已经忘记的事都在这一刻涌上心头。\n\n更自然：他盯着窗外的雨，雨从下午下到天黑。\n\"你还在想她？\"老刘问。\n他没说话。\n```\n\n### 规则 2：动作 + 对话 + 情绪反应\n\n动作、对话与情绪反应按场景需要交织，不按固定顺序轮换，不为凑齐三项补反应。\n\n情绪没有固定译法，关键节点也可以准确直写。上下文已让情绪成立，不另补反应；需要补足信息时，优先选择、台词、策略、物件或实际后果。\n\n身体细节只有带来新信息、影响动作或体现人物与场景特点时才保留。只在句尾重复标注情绪的微动作删掉，不换部位或同义动作。去味时沿用原文已有事实，不凭空添加摔杯子、攥袖口等行为。\n\n### 规则 3：句子该多长（短句是工具，不是默认）\n\n叙述（旁白）默认写成**逗号长句**：一句用逗号串起 2-4 个动作或信息，再落句号；逗号之间 8-12 字，整句 20-30 字。短句是偶尔的孤立重拍工具，不是叙述的默认写法。\n\n| 场景 | 句长 | 示例（长篇语料原句） |\n|------|------|------|\n| 日常 / 推进 / 描写（多数叙述句） | 逗号之间 8-12 字，整句 20-30 字 | 阴冷潮湿的气息扑面而来，身下铺着一层薄薄的稻草，湿漉漉地粘在皮肤上。 |\n| 对话 | 口语化，长短随角色 | \"你疯了？\"\"可能吧。\" |\n\n**不合格（与 AI 腔同级）**：\n- 逗号之间连着都是 ≤5 字的碎片（\"他抬手，开门，进屋，坐下\"式）\n- 通篇 3-8 字句、句号密得像提纲（电报体，见模式 9）\n- 一长一短机械交替（同样是模板）\n\n> **爆款语料校准**（七猫长篇 现言/都市/古言/玄幻/历史 125 本×前 8 章旁白统计）：逗号之间平均 8.8-9.6 字；整句平均 22-24 字；逗号长句占叙述句 74-80%；≤5 字的短片段约占两成，多是孤立的时间词、转折、动作重拍。短篇（盐言体）段落更短（≤15 字的单句段可近一半，长篇约两三成），但句子内部的节奏和长篇一样：**段落随体裁变短，句子内部不碎**。\n\n### 规则 4：口语化表达\n\n- 允许用俚语、粗话（符合角色身份）\n- 对话不要书面语（\"我认为此事不妥\" -> \"我觉得不靠谱\"）\n- 叙述也不要端着（\"他目光如炬\" -> \"他眼珠子一动不动盯着\"）\n- 短语优先于成语（\"无可奈何\" -> \"没办法\"）——只管对话和贴角色声口的叙述；旁白常用成语（不动声色、心不在焉一类）照留\n\n---\n\n## Show Don't Tell 原则\n\n| Tell（告诉） | Show（展示） |\n|-------------|-------------|\n| 他是个胆小的人 | 他把检查报告在手里翻来覆去看了三遍，还是不敢打开 |\n| 这间酒吧很吵 | 酒保凑到他耳边喊了两次他才听见 |\n| 她很富有 | 她随手把一张信用卡丢在桌上，卡面上的数字比这顿饭贵十倍 |\n| 两人关系很差 | 他把烟掐灭在她刚泡的茶杯里，她面无表情地把杯子推到一边 |\n| 他很聪明 | 三秒钟。他看了三秒钟就把文件合上了。\"第三页，第二行。\" |\n\n**核心方法**：\n1. 用行为代替形容词\n2. 用细节代替总结\n3. 用对话代替旁白说明\n4. 用后果代替情绪总结\n\n---\n\n## 质量维度检查\n\n### 1. 核心一致性（权重最高）\n- 剧情是否与大纲/前文一致\n- 人物行为是否符合人设\n- 设定是否有前后矛盾\n\n### 2. 表面改写（防AI指纹）\n- 是否包含AI高频用词（见上表）\n- 章尾是否有总结/升华\n- 是否有大段纯心理描写\n- 段落是否按戏剧单元/镜头自然断开，避免机械单句成段或为凑短碎成提纲（网文段落规则）\n\n### 3. 格式一致性\n- 对话格式统一：按项目/平台约定保持同一引号风格；知乎盐言短篇可用「」\n- 标点节奏匹配语气：避免通篇句号化；保留有功能的问号和少量感叹号；用动作/短句表达迟疑或打断，不用省略号或破折号硬造停顿\n- 场景切换有明显标记\n- 时间线清晰可追踪\n\n### 4. 可读性\n- 是否有连续多个长句压住阅读节奏，且缺少动作、对话或短句换气\n- 对话是否口语化\n- 是否有未解释的生僻词/设定术语\n- 节奏是否有快有慢（不能全是一种节奏）\n\n### 5. 逻辑连贯性\n- 角色动机是否合理\n- 事件因果链是否清晰\n- 时间线是否对得上\n- 角色的知识范围是否合理（不能\"开上帝视角\"）\n\n---\n\n## 快速自检口诀\n\n```\n一事一段，镜头自然断。\n对话要像人说话。\n心情不写心里话。\n结尾不搞大升华。\n打斗不写流水账。\n日常要埋伏笔桩。\n```\n\n> 网文段落规则：按戏剧单元/镜头/一件事结束自然断段；短段快读，长段承载完整推理、氛围和情绪链，避免机械单句成段或通篇同长度。\n\n---\n> **番茄高分样本校准**：番茄正文更接近“手机端短段 + 自然虚词 + 场内动作/对话推进”，不是机械指标达标。番茄高分样本 305 章窗口显示：段落中位约 23.5 字，50-60 字行宽平均只占 5.1%；平均对话占比约 20.6%，对话≥50% 仅 3/305，开篇对话 59/305；`地/得` 305/305、`很` 275/305、`像/好像/仿佛/如同` 267/305、顿号 176/305、省略号 281/305。结论：这些只能按语境复核，不能做 0 容忍硬禁令。\n>\n> **反投机边界**：不要为了“反检测”强制每句换行、把 `……` 改成 `........`、把 `地/得` 全改成 `的`、禁用所有顿号/“很”/“像”、强行开篇对话或按三番四证重排章节。去 AI 味是润色，不是结构重写；除非用户明确要求重写，否则不改变章节顺序、伏笔分布、对话占比和人物信息释放节奏。\n\n---\n\n## 禁用词与句式速查\n\n> 完整禁用词表和句式模板见 [banned-words.md](banned-words.md)\n\n### 正确替代示例\n- '他感到一丝紧张，手心全是汗' -> '他签名时划破了纸'（身体细节只在造成后果时留）\n- '\"好的。\"他说道' -> '\"好的。\"他把门卡塞回口袋'\n- '他深吸一口气' -> '他把话咽回去'\n\n---\n\n## 10 种 AI 写作模式检测\n\n### 模式 1：AI 高频词\n\n| 禁用 | 替换为 |\n|------|--------|\n| 不禁 | 删掉 |\n| 仿佛/宛如 | 删掉或用具体描写 |\n| 映入眼帘 | 删掉 |\n| 心中暗道 | 用动作展示思考 |\n| 沉声道/淡淡地说 | 换成动作标签 |\n| 脸色一变 | 用具体表情/动作 |\n| 嘴角微扬 | 他笑了/他翘了下嘴 |\n| 不由自主 | 删掉 |\n| 只见/此时此刻 | 删掉 |\n| 目光如炬 | 删掉或具体化 |\n\n### 模式 2：弱化副词泛滥\n阈值：每 1000 字超过 3 个 = AI 签名。重点监控：微微、淡淡、缓缓、轻轻。\n\n### 模式 3：意义膨胀\n- \"意义深远\" -> 写具体后果\n- \"前所未有\" -> 给出对比参照\n- \"可谓\" -> 删掉\n\n### 模式 4：万能结论\n- \"未来可期\" -> 用未解决的紧张感结尾\n- \"前途无量\" -> 删\n- \"充满希望\" -> 写具体的下一步动作\n\n### 模式 5：论文体段落结构\n小说中出现以下开头句 = AI 入侵：\n- \"不难看出\"\"由此可见\"\"事实上\"\"综上所述\"\n\n### 模式 6：书面语连词泛滥\n叙事散文中频繁出现：\"于是乎\"\"与此同时\"\"从而\"\"因而\"\"诚然\" -> 口语化替代或直接删除。\n\n### 模式 7：三连排比癖\nAI 喜欢把事情凑成三个以显\"完整\"。-> 砍到只剩最有力的一条。\n\n跨段「不是A。/也不是B。/只是C。」由 `formulaic-parallelism` 作 advisory：它可能是工整铺排，也可能承担辩解、悬念排除或情绪递进；只有重复提纲、拖慢画面时才压缩。该类提示与「至于X不X，怎么X」、同动词「不V A，不V B」都只作语义复核：对话也要检查，但有明确人物声线或任务功能时可保留；若来自细纲多个字段对同一要求的重复，正文只能消费一次，不能逐项复述。\n\n### 模式 8：解释腔 / 上帝视角 / 安排感\n最难察觉、却最\"像 AI\"的一类。叙述者跳出角色当下，去解释、剧透、总结、定性、拔高，读者能闻到\"作者在场\"和\"剧情被安排好了\"的味道。这正是\"说教感/上帝感/解释腔/机械感/刻意感/安排感\"的来源。\n\n| 表现 | 例（删/改） |\n|---|---|\n| 解释因果 | 「之所以…是因为」「原来…」「这意味着」「正是因为」-> 删。因果只从角色动作、对话、反应里让读者自己拼 |\n| 上帝视角剧透 | 「她不知道的是」「殊不知」「多年以后」「冥冥之中」「仿佛预示着」-> 删。只写角色此刻知道的，悬念让读者自己悬 |\n| 替读者下结论/定性 | 「演得真好」「这出戏她看过一遍」「他就是这样薄情的人」-> 删。把证据（神态、动作、台词）摆出来，定性留给读者 |\n| 替角色总结心理 | 「她明白，这一切都是命」-> 无新增信息就删；确有角色判断时保留带偏见的闪念，不强配身体反应 |\n| 总结/动机/评价链把意义说满 | 「他终于明白」「这是最好的选择」「所有人都会记住这一刻」-> 删掉定性，改成角色当下要处理的具体缺口、未完成动作或局部反馈；不是保留评价再硬塞物件/动作 |\n| 安排感/硬铺垫 | 为后文强行交代背景、整段回忆倒叙 -> 背景按角色此刻真实所需，用闪念、半句话、物件零碎带出，不集中交代 |\n| 升华式收尾 | 结尾对仗拔高、金句点题 -> 用一个动作或一句留白收住，把\"意思\"压进画面里 |\n| 抽象命运/开端收束 | 「命运终于露出獠牙」「早已布好的棋局」「这一刻终于明白」「属于他的反击才刚刚开始」-> 改成角色当下可见的文件、动作、对话或物理后果；`check-ai-patterns.js` 报 `abstract-summary-tic` 时优先处理 |\n| 套词密度过高 | 仿佛/一丝/一抹/深吸一口气/平静无波/指节泛白等成串复现（`cliche-density-tic`）-> 不是同义词轮换，整段回到角色当下证据：文件、动作、对话、物理后果 |\n| 套式反应细节 | 指尖轻叩、袖口里攥紧、指节泛白、目光移开、“语气平静得像在念……”等反应成片（`stock-reaction-tic`）-> 逐处做删除测试；只标注情绪而不改变选择、关系、物件或动作结果的删掉，不换部位和同义动作；有伤势、动作失败或情节后果的身体细节可留 |\n| 比喻密度过高 | 像/好像/仿佛/如同等比喻标记成片复现（`metaphor-density-tic`）-> 保留最能传递信息或情绪的一两个，其余改回具体动作、物件、声音、后果；不要换成新比喻 |\n| 系统公告公文腔过密 | 方括号规则/面板/公告行里硬规则词成片（`system-notice-formality-tic`）-> 保留为角色看见的屏幕/公告/规则载体；只在载体内部白话化部分硬词，或补角色当场看懂的具体后果，不改成叙述者解释 |\n\n**更隐蔽的一层（最难自查，没有标志词）**——同样是安排感/上帝感：\n- 评判性副词/补语：「关切得恰到好处」「笑得恰如其分」「不多不少」-> 作者在替读者盖章\"这是装的\"。只写动作（\"她掩了帕子，眼睛没动\"），装不装让读者自己判。\n- 剧透式点破潜台词：「那点笑她看得分明」「谁都看得出他在撒谎」-> 把藏着的挑明了。留着别点破。\n- 定性比喻/盖棺句：「像在宣判一件早已定好的事」「像看一件死物」-> 比喻在替角色下定论。非角色此刻强烈主观感受就删；要留也只能是她带偏见的瞬间感觉，不是客观断言。\n\n自检：每句问一遍——这是\"角色在经历\"，还是\"作者在讲解/安排\"？凡作者跳出来讲，删，或改成角色视角内的呈现。根治办法是锁定深度限知视角：只写视角人物此刻看得见、听得见、想得到的，镜头钉死在角色身体里，作者就没位置跳出来了。\n\n改法优先级：先删或原位替换污染句，不在段尾另补“人味”尾巴。需要补信息时，把原来的总结/动机/评价句改成角色当下能碰到的问题、手续、回信、付款、门外动静等具体压力；已有手机/屏幕/公告/门牌/表单等信息，优先作为角色看见的场内载体保留，不要转写成叙述者解释。具体载体跟剧情走，不套固定清单。\n\n**任务卡点不是固定公式，也不是通用补流程按钮**：它只是把已有解释落回角色当下要处理的缺口。先问原文有没有“要办的事”和“卡住的点”；有，才可以压成任务卡点；没有，就只删解释或改动作/对话，不新造事件链。改完再做“删掉试试”：删掉后不影响信息、情绪、关系、代价或伏笔，就压缩或删除。\n\n**但删解释腔 ≠ 把读者读懵**：新名词/新设定/新道具首次出现时，仍要让读者抓到一个锚——靠角色的动作反应、对话里半句自然提及、或场景里的物理后果，一笔带出它此刻的作用或分量；既不整段讲来历原理，也别只甩个零信息生词让读者干懵。人物记忆、情绪缓冲、因果承接也一样：如果一句看似解释/评价，实际承担小连贯（让读者知道角色为什么脸热、为什么停顿、为什么这一声压不住），不要机械删成摘录清单；把它压成角色当下的白话、动作、物件或半句念头。例：「蓝晶」首次出现不写\"这是储存记忆的装置\"，但可写她把蓝晶按上太阳穴、别人的记忆碎片炸开在眼前——功能被读者看见，全貌留作悬念。区分：锚是\"角色此刻撞上的可感知后果/记忆或情绪承接\"（留或压），解释是\"作者跳出来讲设定来历/原理/替读者下结论\"（删）。\n\n### 模式 9：过度压缩（电报体）\n\n去AI味删过头的反向指纹。每句都压到最短、结构虚词扫光、每个动作都补一个「了下/了一下」式轻反应。单句看着干净，连读像提纲，读者的体感是\"不流畅、喘不上气\"。删减的目标是删废话（解释、注水、凑数），不是删中文的自然冗余。\n\n| 表现 | 修法 |\n|---|---|\n| 非峰值叙述句也全部压成最短句 | 重拍句（动作/情绪/悬念峰值）保持短促；铺垫、过渡、日常动作写成自然白话句，保留 了/的/就/的时候 等结构虚词 |\n| 「扯了下/停了一下/拍了两下/松了半圈」式微动作高密度复现（check-ai-patterns.js 报 micro-action-tic） | 合并动作，换具体细节；不是每个动作都要接一个反应尾巴 |\n| 强调副词（连/才/又/只/全/反而）被扫光 | 删前判语义：承担人设、对比、讽刺义的保留（\"才二十三天\"删掉\"才\"，人设强调就反了） |\n| 对话语气词归零 | 按角色保留自然低频的 呢/吧/啊；也不反向猛加——人味来自结构自然，不是聊天腔 |\n| 叙述残留公文/文言腔（不得/须/未/已然/当前） | 换白话（不能/要/还没/现在）。系统公告、规则条文、面板播报可以保留冷硬功能；若 `system-notice-formality-tic` 报警，只在原载体内白话化一部分，不改成叙述者解释 |\n| 长文本里短叙述段成片（`overcompressed-prose-tic`） | 不是把所有短段拉长。先人工通读：重拍短句、密集镜头如果上下文顺，就保留；只处理读起来像提纲的过渡句，把它们并回同一镜头，让读者顺着动作、空间、因果读过去 |\n| 引号外叙述低连接密度且缺中长句（`low-connective-density-tic`） | 不是全局补“的/了/就”，也不处理台词/弹幕/系统播报的天然短促。先找叙述层读起来像提纲/电报体的断裂处，恢复必要连接、指代和中长承接句；有中长句链条的低功能词文本可保留 |\n\n自检：删完连读一遍，读感像提纲或流水口令，就是删过了——把非峰值句恢复成自然白话，不是接着删。\n\n本模式约束的是删减的度，不降低清理力度：选定 Gate 内的禁用词、套路句式、告知式心理照删照改；回填只回结构虚词和连接，不保留、不恢复任何模板措辞。\n\n### 模式 10：二修伪自然（油腻倒装 / 监控动作清单 / 对话指标化）\n\n一些“反检测提示词”会把文本推向另一种模板：为了提高突发性而乱倒装，为了真人感而机械加口误和脏话，为了手机阅读而强制每句换行，为了对话占比而把心理和叙述硬改成台词。这些不是自然网文，是二修痕迹。\n\n| 表现 | 修法 |\n|---|---|\n| 油腻倒装 | 不写“手里拿着刀，他冲了上去”这类伴随动作前置。连续同主语时，优先用场内物件、声音、局部身体或环境反馈自然换句首；不要滥用死物拟人 |\n| 监控摄像头式动作清单 | 同段连续“伸手拿起、取过、挑开、放下、转身……”像步骤表。合并琐碎动作，只保留有情绪、情节或空间功能的动作；必要时用角色犹豫、误判、旁人反应或环境反馈做缓冲 |\n| 高压场景误脱水 | 冲突、追杀、打斗可删解释和逻辑胶水；日常、暧昧、铺垫不能全章脱水。删的是废话，不是“的/了/就/但是”等自然连接 |\n| 吃字漏词 | 去 AI 后如果动词没有对象、动作指向不清、读者不知道谁对谁做了什么，要补回必要宾语、承载物或物理反馈；中文可省略，但不能省到像提纲 |\n| 对话指标化 | 不为凑 50%-60% 对话占比硬扩台词。台词只在角色真会说、此刻必须说时增加；长对白可拆动作，解释性对白优先压成冲突、回避或半句信息 |\n| 硬格式投机 | 不强制每句换行、50-60 字一行、不把省略号改成英文点、不把 `地/得` 全改错。按平台和项目既有格式走 |\n\n`check-ai-patterns.js` 的 `action-list-tic` 只提示监控动作清单，不是 blocking。功能性打斗/追逐/仪式步骤若动作链本身承担信息，可保留或标 `[需复核]`。番茄高分样本中该类命中为 0，因此适合作为“需通读”的风格提示，而不是硬性失败项。\n\n#### 工具提示处理\n\n`check-ai-patterns.js` 是本地写作 lint；blocking 只限确定性句式/标点问题，advisory 不作完成门槛。用户贴其他工具报告时，只把能落到正文的句式、段落、词汇问题转成具体修改点，不写“0% AI / 100% 真人”或“固定公式”，也不围绕分数反复微调。\n\n工具提示不高于读感规则。参考文本里若出现“仿佛/非常/感到”等套词或告知式心理，仍按模式 1-8 清理；不要机械补词、故意错字或按题材套壳。\n\n**去 AI 味补充判断**：\n- 优先处理：作者解释总结、意义尾巴、把情节翻译成“他意识到 / 这意味着 / 真正重要的是 / 这次成长”。优先删掉，或落回场内动作、对话、物件状态、任务状态和角色当场要处理的后果。\n- 场内载体优先：原文已有手机、屏幕、公告、门牌、表单、账单、物证、规则行时，保留为角色看见/读错/处理的文本或物件；不要把同一信息改写成叙述者解释规则。\n- 白话但不注水：少用精致戏剧反应短语（头皮发紧、眼皮一跳、心口一沉、胃里翻涌）连续替代剧情推进；能写普通动作/普通感觉就写普通动作/普通感觉，并保留自然的“的/了/就/但是/已经/之后/没有”等连接。\n- 题材文风优先：文风对标有帮助，但必须来自目标题材/本书文风指纹；不要把盘龙腔、旧网文腔、第一人称声口等当成跨题材万能修法。\n- 不要当通用修法：单纯加标题、补物件、补动作尾巴、拉长/压短句子、增加排队/门禁/记录体，不能替代具体的情节、视角和语言问题处理。\n\n#### 把提纲句写成连续段落\n\n当文本已无 blocking / 明显 advisory，但读起来仍像提纲时，只处理断裂处：\n\n1. 标出读起来像逻辑报告的段落：连续出现“他知道/他明白/这意味着/真正的问题/必须/需要”等判断链，却缺少当下动作、物件或对话反馈。\n2. 把叙述者结论落地：用角色当下能触到、听到、被迫处理的后果替代“他意识到/这意味着”。不要套固定物件清单，也不要把某个场景外壳当通用规则。\n3. 只在断裂处恢复自然连接和结构虚词；不设比例目标，不机械补连接。\n4. 系统公告、规则条文、面板播报可以保留冷硬短句；`system-notice-formality-tic` 报警时，只在原载体内白话化一部分硬规则词，或让角色当场看到具体后果，不改成叙述者解释。\n\n`overcompressed-prose-tic` / `low-connective-density-tic` 的具体修法：\n\n1. 圈出连续短叙述段，逐段标注功能：爆点/反转/恐惧重拍、密集镜头可继续短；铺垫、空间、因果、动作承接应并回同一镜头。人工读着顺，就不因该 advisory 继续拉长。\n2. 合并时优先补“动作顺序、空间方位、因果承接”，例如“抬头时/门外/已经/还/就/被”，而不是给每句硬塞“的/了/就”。\n3. 合并后再删套词和告知心理：读顺不是恢复 AI 腔，不能把“仿佛/感到/非常/好像”成片加回来。\n\n复核处理：如果清掉 `overcompressed-prose-tic` / `low-connective-density-tic` 后读感仍不稳，停止局部微调，转为段落级重写或人工读感对照。\n\n示例：\n\n```\n过度压缩：\n林遥抬头。\n雨棚外的街灯灭了。\n风也停了。\n柜台上的纸杯晃了两下。\n\n读顺后：\n林遥抬头时，雨棚外的街灯正一盏盏熄下去。风忽然停了，柜台上的纸杯还在原地轻轻打转。\n```\n\n\n---\n\n## 改写顺序（只排所选 Gate 的先后）\n\n下面三步只决定所选 Gate 内问题的处理先后，不另起一轮全篇去味；某一步没有对应的所选 Gate 就跳过。\n\n### 第一步：去泛化（Strip Generic）\n- 抽象情绪总结句 -> 按规则 2 判断：删重复说明，保留准确直写，需要时用原文已有信息落地\n- 假深度句 -> 删\n- 意义膨胀 -> 缩小到具体影响\n- 空洞结论 -> 删\n- 工整对比句式 -> 打散重写\n- 装饰性形容词堆砌 -> 白描\n- 过度使用\"于是\"\"然而\"\"此刻\" -> 删掉一半\n- 所有角色说话一样\"高级\" -> 区分语气\n\n**原则**：能删就删，不能删就用具体细节替换。\n\n### 第二步：去书面化（Cut Professional Diction）\n- 分析性用词（\"机制\"\"结构\"\"逻辑\"\"体系\"出现在小说中）-> 换成日常表达\n- 抽象名词滥用 -> 直接说事\n- 体制内用语（\"进一步\"\"深入\"\"推进\"\"落实\"）-> 删\n- 专业术语堆砌 -> 只保留必要的，用白话解释\n\n**例外**：保留专业感的场景（历史题材正式用语、文学向刻意密度、喜剧夸张修辞）。\n\n### 第三步：回自然感（Restore Natural Presence）\n- 具体的感官细节（气味、温度、触感）\n- 角色说话方式的区分（不同人不同语气）\n- 句首变化：连续 3+ 句用同一主语或同一词性开头时换开法（动作、场景、对话引入）\n- 节奏变化（长短句交错）：按情绪 beat、动作推进和戏剧单元自然调节句段长短；忌连续多段同一长度，也忌为凑短而碎成提纲。长短不是随机，沉淀处可放慢，冲突/反转处可骤短，完整推理与情绪链优先保持连贯\n- 社会位置感的对话（上级和下属说话方式不同）\n- 场景特有的记忆点\n- 项目特有的语言习惯（角色的口头禅）\n\n**原则**：少即是多。每段加 1-2 个具体细节就够了。\n\n### 执行范围\n\n调用方指定 Gate 时，只处理选定 Gate；改写顺序只排先后，不重新分级或扩大范围。未指定范围时，按实际问题选择适用检查。\n\n### 自检清单\n- 对话自然度检查：对话是否使用口语化表达，是否避免了书面语/正式腔调\n- 删掉任何一句，会影响理解吗？不会 = 可能多余\n- 不同角色能通过对话区分吗？\n- 有没有一个细节是这个场景特有的？\n\n---\n\n## 去AI味补充技法\n\n### Show vs Tell\n\n| 告知类型 | AI写法 | 自然写法 |\n|----------|--------|----------|\n| 告诉期待感 | \"他很期待\" | 展示期待->情绪->满足的链条 |\n| 告诉角色目的 | \"她想离婚\" | 用行动展示目的 |\n| 告诉角色态度 | \"她很冷静\" | 用对话和反应体现 |\n| 告诉剧情走向 | \"接下来会发生大事\" | 用铺垫->反转->延续展示 |\n\n### 心理描写润物细无声\n\n- 加括号标注内心活动 = 破坏代入感\n- 大段内心独白解释动机 = AI签名\n- 直接写\"她感到\"\"她意识到\" = 告知情绪\n\n**自然写法**：心理活动自然融入叙事，用行为暗示心理，用沉默/动作/反常行为表达内心。\n\n### 代入感检查\n- 主角行为读者能理解、共鸣、接受吗？\n- 反派够强吗？（弱反派 = 读者觉得主角赢了没意义）\n- 是否围绕人设写行为？（行为/语言/思维围绕人格展开）\n- 读者已知信息是否被有效操控？（信息差制造情绪波动）\n\n---\n\n## 改写范例库\n\n### 情绪落地示例\n\n| 原文与语境 | 处理 |\n|---|---|\n| 「他很紧张。再错一题，补考也过不了。」 | 情绪有具体原因，可以直写，不补手抖或出汗 |\n| 「她已经决定不再等他。她攥了攥袖口。」袖口动作无后续作用 | 删除第二句，不换成低头或咬唇 |\n| 「手腕的伤让他握不住笔，签名只写了一半。」 | 保留，身体状态造成动作失败，不能当作情绪套话删除 |\n\n### 场景描写范例\n\n**AI风场景**\n- '阳光透过窗帘的缝隙洒进来，在地板上投下斑驳的光影。空气中弥漫着淡淡的花香，仿佛整个世界都沉浸在一片宁静祥和的氛围中。'\n- 下午三点，客厅里只有钟在走。\n\n**AI风天气**\n- '天空阴沉沉的，乌云密布，仿佛随时都会下起倾盆大雨。凛冽的寒风呼啸而过，带着一丝刺骨的寒意。'\n- 要下雨了。风把晾在外面的衣服吹得乱晃。\n\n**AI风打斗**\n- '他的拳头犹如疾风骤雨般猛烈，每一击都蕴含着不容置疑的力量。对手的瞳孔微微收缩，显然没有预料到如此凌厉的攻势。'\n- 他一拳怼过去，对方没躲开，嘴角破了。\n\n### 结尾改写范例\n\n**升华式结尾** -> '他站在窗前，望着远方的天际线，终于明白了生活的真谛：有时候，放手才是最好的选择。' -> 他把烟掐了，回屋睡觉。\n\n**总结式结尾** -> '这一刻，一切都变了。她知道，从今以后，她的人生将翻开崭新的一页。' -> 她关上了那扇门。没回头。\n\n**感慨式结尾** -> '岁月如流水般悄然流逝……' -> 直接删掉这种段落。\n\n### 节奏调整范例\n\n> 以下范例处理的是臃肿修饰、堆叠比喻和抽象总结，不是「见长就拆」：改写后叙述仍以逗号长句为主（规则 3），不要把正常的逗号长句拆成短句串。\n\n**排比句**\n- '他看着她的眼睛，看着她的嘴唇，看着她微微颤动的睫毛，心中涌起一股难以名状的情感。'\n- 他看着她，她没说话。\n\n**臃肿长句去修饰**\n- '当他终于推开那扇沉重的木门时，映入眼帘的是一间昏暗的房间，空气中弥漫着陈旧的气息，墙角堆满了落满灰尘的箱子。'\n- 他推开木门，屋里昏暗，墙角堆着几个落灰的箱子。\n\n**工整段落打碎**\n- '她喜欢春天的花朵，喜欢夏天的阳光，喜欢秋天的落叶，喜欢冬天的白雪。每一个季节都有它独特的美。'\n- 她喜欢春天，别的季节也还行。\n\n---\n\n## 冲突对话改写范例\n\n### AI式温和对话\n- '我觉得你这样做不太合适，能不能考虑一下我的感受？' -> \"你眼里还有我吗？\"\n\n### AI式完美解释\n- '其实我这样做是有原因的，因为当时的情况非常复杂……' -> \"你能怎么着？\"她把茶杯重重放下。\n\n### 对话情绪五级递进范例\n\n同一冲突场景，从弱到强：\n\n1. **客观陈述**：\"你把我的东西扔了。\"\n2. **陈述+建议**：\"你把我的东西扔了，以后能不能先跟我说一声。\"\n3. **主观指责**：\"你凭什么动我的东西。\"\n4. **指责+命令**：\"你算什么东西，也配碰我的东西？滚出去。\"\n5. **指责+PUA**：\"我伺候你吃伺候你穿，你连个东西都放不好。你这辈子也就是这样了，离了我你什么都不是。\"\n\n### 震惊分层改写范例\n\n**AI式一步到位**：所有人都震惊了，不敢相信自己的耳朵。\n\n**自然分层震惊**：\n1. 对面的男人手抖了一下，茶杯里的水洒出来。\n2. 旁边的人互相看了一眼，有人往后退了一步，角落里有人开始掏手机。\n3. 刚才还趾高气扬的女人，脸上的笑僵住了。她张了张嘴，一个字没说出来。\n\n### 代入感修复范例\n\n**被动主角**：她很害怕，不知道该怎么办，只能等着事情过去。\n\n**主动主角**：她锁了门，把手机调成静音，打开了录音。\n\n---\n\n## 质量检查清单\n\n写完每章后，按此清单逐项扫描：\n\n- [ ] **段落控制**：段落按动作/信息变化断开，读起来不卡\n- [ ] **正文无破折号**：正文（含叙述和对话）无 `——`/`—`/`--`（用句号、逗号、短句或动作断句），不设置对话例外\n- [ ] **AI高频词扫描**：无不禁/仿佛/映入眼帘/心中暗道/沉声道/嘴角微扬/不由自主/只见\n- [ ] **弱化副词计数**：每1000字\"微微/淡淡/缓缓/轻轻\"不超过3个\n- [ ] **无三连排比**：没有AI式的\"三个一组\"修辞\n- [ ] **工整否定清单已复核**：跨段「不是A / 也不是B / 只是C」及其他 `formulaic-parallelism` advisory 已连同台词逐条复核；功能性修辞可保留\n- [ ] **无论文体**：无\"不难看出/由此可见/事实上/综上所述\"\n- [ ] **无书面语连词堆砌**：无\"于是乎/与此同时/从而/因而/诚然\"泛滥\n- [ ] **章尾无总结升华**：用动作/对话/悬念收束，无感悟/哲理/预告\n- [ ] **无大段心理描写**：心理活动不超过2段，无括号标注内心\n- [ ] **情绪落地**：按规则 2 保留准确直写与有功能的身体细节，删除重复说明，不给每个情绪词配动作\n- [ ] **对话口语化**：无书面腔，不同角色语气可区分\n- [ ] **标点不压平**：没有把质问、爆发、犹豫全部压成句号；也没有随机堆砌 `？`/`！`，或用 `……`/`——` 硬造停顿\n- [ ] **Show Don't Tell**：用行为代替形容词，用细节代替总结\n- [ ] **句长达标**：叙述默认是逗号长句（逗号之间 8-12 字、整句 20-30 字，规则 3）；短句只作偶尔的孤立重拍，用完回到逗号长句；没有连着的 ≤5 字碎片，没有通篇短句像提纲\n- [ ] **detector advisory 逐条复核**：`micro-action-tic` / `stock-reaction-tic` / `abstract-summary-tic` / `cliche-density-tic` / `metaphor-density-tic` / `reasoning-chain-tic` / `system-notice-formality-tic` / `overcompressed-prose-tic` / `low-connective-density-tic` / `action-list-tic` 命中时按脚本给出的修法处理：先通读判断是不是机械复现，确属再改；功能性写法保留或标 `[需复核]`，不做同义词轮换、不机械注水\n- [ ] **不做硬指标投机**：不为反检测强制每句换行、50-60 字一行、对话 50%-60%、英文点省略号，或把 `地/得` 全改成 `的`\n- [ ] **任务卡点服从原文边界**：抽象总结若改成角色办事被卡住，必须来自原文已有任务/证据/手续/物件缺口；不新增原文没有的事件链\n- [ ] **对话自然度测试**：无书面语痕迹 = 通过\n\nFile v1.1.27:references/author-memory-maintenance.md\n\n# 作者记忆维护\n\n[author-memory.md](author-memory.md) 的少见时刻补充：记一条、确认、替换、忘掉和优先级仍按那份协议，本文件只在下列情况读——作者说「整理作者记忆」，或回执 `warnings`／查询 `omitted_ids` 提示超编；写入因 `作者画像.md` 写满失败；书根就是工作区，或工具报 `state.book`、单书布局错误；要做存量迁移 `migrate`、多事件原子 `commit`、派生视图 `check`；冲突候选要落定；碰到升级前留下的旧条目。\n\n作者记忆借鉴“原始证据 → 候选 → 已确认画像 → 变更记录”的记忆管道，但把决定权留给作者。\n\n## 文件\n\n```text\n{工作区}/.story/作者记忆/          # 项目级 store：global / genre / workflow 条目，编号 AP\n├── _author-memory-state.json  # 唯一结构化权威\n├── 作者画像.md               # 仅 active，供作者查看与管理\n├── 待确认.md                 # pending / conflict，不参与约束\n└── 变更记录.md               # 最近 100 次、最新在前的事务记录\n{书}/.story/作者记忆/            # 书级 store：只存这本书的 book 条目，编号 BP，同样四个文件\n```\n\n三个 Markdown 文件都从 state 确定性生成，禁止手改；完整历史保留在 state，变更记录只展示最近 100 次。`作者画像.md` 是人类管理视图，普通写作 agent 不整份注入，而是调用 `query` 取得本次相关的紧凑上下文。\n\n## 任务映射表\n\n各 skill 入口的 `query` 命令按此表选 kind；写入时的预算提醒也按这四类任务组合估算。\n\n| 任务 | query kinds | 注入位置 |\n|---|---|---|\n| 正文初稿 / 续写 | `prose_style` + `story_design` | 主会话与实际正文 agent |\n| 去 AI 味 / 改写 | `prose_style` | 主会话与实际改写 agent |\n| 设定 / 大纲 | `story_design` + `workflow` + `interaction` | 主会话，不传正文 agent |\n| 审稿 | `delivery` + `interaction` + 必要的 `prose_style` | 主会话，不降低 rubric |\n\n审稿匹配项只用于交付格式、协作方式和“作者有意采用的表达选择”说明；问题严重度和 PASS/FAIL 仍由 rubric 决定。\n\n## 注入预算与容量\n\n- **写入不因注入预算失败**：`record` / `commit` 照常成功、给回执；工具按上表四类任务组合估算最坏查询情形（全局条目＋各 scope 维度最重的单一切片，切片按大小写无关归并、轻重按写作时真正读到的字段算，与真实查询同一把尺），装不进 2048 字节的组合在返回的 `warnings` 里点名将被略过的条目及其断言首句。\n- 写入落盘后另一级 store 读不出来（书目录不存在、`--book` 与书级记录不符等）也照常给回执，`warnings` 注明本次提醒没算上它。写书级条目时「本书＋全局」按实际条目精确计算；写项目级条目时只看得到项目级 store，顺手传 `--book-root` 就把当前这本书也算进提醒。\n- 查询按 **重要度 → 本书例外 → 最近更新** 排序装填（同一范围的条目必在同一 store，「最近」按该 store 的修订号比，不跨 store 比较），先丢的恒是重要度较低的条目——`importance` 决定超编时谁留在 prompt 里。装不下的条目跳过而不中断（一条长的不挡后面的短条），漏下的 ID 按同一优先级报进 `omitted_ids`（最多列 20 条，`omitted` 是真实总数）。\n- 注入预算之外还有一道硬上限：`作者画像.md` 超过 12288 字节时写入会直接失败并要求先整理。active 条目攒到几十上百条才会碰到（远在注入预算之后），碰到就走「整理作者记忆」；`forget` 这类减量操作在满编时照常可用。\n\n## 整理作者记忆\n\n作者说「整理作者记忆」，或回执 `warnings`／查询 `omitted_ids` 提示超编、写入因画像写满失败时：读项目级与当前书的 `作者画像.md`（每条都标了范围、重要度、把握和确认次数，重要度就是超编时的去留依据），提出合并同义条（`replace` 多合一）、退役过时条（`forget`）、给错标成 `high` 的条目下调重要度、把超长断言压缩成一句话的提案；项目级画像里还有「本书：」条目时，「对该书运行 `migrate --book-root`」列为默认提案项。清单用原话逐条列给作者确认（编号只放括号里），确认后按 store 各汇成一份 `commit` 事务提交（一份事务只写一个 store）。合并时保住每条的否定词、限定词和适用范围——合不动就退役其中一条，不要靠删限定词把两条凑成一条。整理只由作者发起或确认，不自动执行。\n\n## 冲突候选\n\n冲突候选（`conflict`）不能绕过旧规则直接 `decide=activate`。作者选新说法：用 `replace`，`old_ids` 同时列旧 active 条目和这条冲突候选，新条目直接 active、两条旧的标 `superseded`；作者留旧规则：对候选 `decide=reject`。旧条目被 `replace` / `forget` 撤下后，它不再是任何候选的冲突对象，冲突对象清空的候选退回 `pending`。\n\n## 单书布局\n\n书根就是工作区（`--book-root` 与 `--workspace` 同一目录）时，书级 store 改住 `{工作区}/.story/作者记忆/书级/`，与项目级各自一份 state；首次建立的书名优先取项目级存量本书条目里唯一的书名，再取目录名。旧版曾把书级 state 写在项目级位置，此后项目级读写都报 `state.book`；带 `--book-root {工作区}` 运行任一命令（含 `query`）会先把它原样移进 `书级/`，不改内容。这个目录其实是某个工作区里的一本书时（上一层叫 `长篇/` 或 `短篇/`，或某个祖先有 `.active-book` 或项目级 state），工具直接报错、不动任何文件，按报错改传 `--workspace`。\n\n## 存量迁移\n\n不做双读：升级前写进项目级 store 的 book 条目不再参与查询与预算估算，也不再接受新的 book 写入；它们仍在 `作者画像.md` 里可见、可 `decide` / `forget`。对每本书运行一次 `migrate --book-root {书目录}` 即可整批搬回来：断言、证据、确认次数、重要度原样保留，换成 `BP` 编号，原 `AP` 条目标 `superseded` 并注明去向；与全局条目的冲突关系在迁移后不再成立，这类候选退回 `pending`。书级每个源条目一笔事务，重跑只补没做完的一半。「整理作者记忆」看到项目级画像里还有「本书：」条目时，把迁移列为默认提案项。\n\n## 旧条目\n\n- 升级前写下的长断言不受 120 字节新建上限约束：原样重申它会**强化**原条目（确认次数 +1），不会因超长被拒；只有真正新建条目才校验 120 字节。\n- 存量 state 里推断类旧来源的条目照常可读、可确认、可退役；新写入仍只接受 `explicit_user`、`accepted_suggestion`、`manual`。\n\n## 其他命令\n\n先依次尝试 `python3`、`python`、`py -3` 找到 Python 3，再从当前 skill 根运行本地副本（`record` / `query` 见 author-memory.md）：\n\n```text\n{PYTHON} {当前 skill 根}/scripts/author_memory_commit.py init    --workspace {工作区} [--book-root {书目录}]\n{PYTHON} {当前 skill 根}/scripts/author_memory_commit.py commit  --workspace {工作区} [--book-root {书目录}] --input {工作区}/.story/work/作者记忆-事务.json\n{PYTHON} {当前 skill 根}/scripts/author_memory_commit.py migrate --workspace {工作区} --book-root {书目录}\n{PYTHON} {当前 skill 根}/scripts/author_memory_commit.py check   --workspace {工作区} [--book-root {书目录}]\n```\n\n- `commit`：高级批量入口，只在需要把多个动作绑定成一次原子提交时用（如整理作者记忆）。顶层传 `schema_version`、唯一 `transaction_id`、当前 `expected_state_revision` 和含 1–32 项的 `operations`（每项与单事件的 `operation` 同形）。一份事务只写一个 store；先在内存完成 schema、引用、容量和所有视图校验，操作按数组顺序应用，任一步失败则整份事务零写入，最后原子替换 state。过期修订会在任何写入前失败。事务文件在成功前必须保留，成功后删除；显式记忆请求按 author-memory.md「回执怎么告诉作者」转告。\n- `migrate`：把项目级 store 里某本书的存量 book 条目整批搬进 `--book-root` 的书级 store，幂等，中途失败直接重跑；返回 `migrated`（源→新编号），没有存量时为空。\n- `check`：从 state 重建并逐字核验所有派生视图；传 `--book-root` 时两级一起核验。\n- `init`：显式初始化 store；平常不需要，首次 `record` 会随事务创建。\n\nFile v1.1.27:references/author-memory.md\n\n# 作者记忆协议\n\n作者记忆保存跨会话复用的创作偏好，不保存小说世界里的事实，决定权留给作者。本文件管最常见的时刻：作者说出一条偏好，或要确认、替换、忘掉某条。少见情况读 [author-memory-maintenance.md](author-memory-maintenance.md)：整理作者记忆与超编、画像写满、单书布局与 `state.book` 报错、存量迁移、多事件 `commit`、`check`、冲突候选落定、升级前的旧条目。\n\n## 边界与优先级\n\n加载优先级从高到低：\n\n1. 安全、用户授权范围、明确的平台交付要求、字数与文件协议；句长、视角、修辞和标点偏好不属于不可覆盖的硬门禁；\n2. 用户在当前请求中的明确要求；\n3. 当前书的 `设定/文风.md`、题材定位、细纲和其他项目设定；\n4. 作者记忆中的本书偏好；\n5. 作者记忆中的题材、流程和全局偏好；\n6. 对标素材、通用方法和默认值。\n\n按表达维度取最窄适用要求：低优先级只补缺项，不与高优先级要求并列执行。通用 references 自称“必须/禁用”不改变此顺序；审稿不因作者有意采用的表达本身扣分，真实可读性与因果问题仍照常评价。\n\n作者记忆不能把本书事实写进 `.story/作者记忆/`，不能覆盖当前请求，不能降低审稿 rubric，也不能让去 AI 味改动剧情意图。小说事实继续由各书的 `追踪/` 和 `设定/` 管理。\n\n## 存放与路由\n\n两级 store，记忆随书走：`{工作区}/.story/作者记忆/` 存 global / genre / workflow 条目（编号 `AP`），`{书}/.story/作者记忆/` 只存本书的 book 条目（编号 `BP`）。每级各有 `作者画像.md`（生效条目）和 `待确认.md`（候选，不参与约束），都从 state 生成，禁止手改；不存在时写作、审稿、去味照常继续，首次 `record` 自动创建。\n\n- `--workspace` 必须显式传，指创作工作区根——承载多本书、`.active-book`、`长篇/`、`短篇/` 或 `拆文库/` 的那一层；已有记忆时，是项目级 state（不带 `book` 字段）所在的最近祖先。`长篇/`、`短篇/` 下的书目录永远不当 `--workspace`，也不要把用户主目录当默认工作区。\n- `--book-root` 是当前书的项目目录（`.active-book` 指向、或含 `设定/`、`正文/` 的那一层，如 `{工作区}/长篇/{书名}/`）；书名默认取书级 state 记的名字，首次取目录名，`--book` 可覆盖。书根就是工作区时读维护文件「单书布局」。\n- ID 前缀就是 store：`decide` / `forget` 看 `item_id`（`AP` 项目级，`BP` 书级），`remember` / `replace` 看 `scope.level`（`book` 书级，其余项目级）。书级操作必须传 `--book-root`，没传直接报错，不会退而写进项目级。\n- `replace` 与 `conflicts_with` 不能跨 store：本书例外按优先级覆盖全局规则，不算冲突，直接 `remember` 为 book 条目；要把全局规则改成本书规则，拆成 `forget` ＋ `remember` 两个事件。\n\n## 查询\n\n各 skill 入口已写好本任务的 `query` 命令（长篇正文由组装脚本代查）；没写命令的长篇设定、大纲等任务查 `story_design` + `workflow` + `interaction`，结果只给主会话、不传正文 agent。四类任务的映射表见维护文件。state 存在才查（两级都不存在时返回空结果、零写入）；结果合并项目级与 `--book-root` 所指书级（不传就拿不到本书条目），`--kind` 必传，输出不超过 2048 字节。\n\n普通创作只做一次本地 `query`，完整画像、证据、候选和 journal 不进 prompt。查询项是低优先级倾向，不是逐条打卡清单：自然吸收，不复述画像、不刻意提高词面命中率，不为命中牺牲连贯、节奏、字数或本书既定笔调。**`omitted_ids` 非空＝记忆超编**，不是「没有更多了」：转告作者并建议「整理作者记忆」，不得改读完整画像规避预算。待确认项不进 prompt，也不为确认它们中断任务；只在作者主动查看、候选积累到适合回顾的节点，或新偏好与 active 条目冲突时集中呈现。\n\n## 记不记、记成什么\n\n不装记录全部用户消息的 prompt hook，不在作者没开口时观察他，只记作者明确表达的偏好。是否属于长期习惯由 agent 判断，拿不准就只执行不记录；作者可明说“记住：……”，以回执验收。\n\n| 输入证据 | 处理 |\n|---|---|\n| “以后都这样”“我一直习惯……”等直接、稳定、范围清楚的原话 | `active`，`source=explicit_user` |\n| 用户明确接受助手提出的长期做法 | `active`，`source=accepted_suggestion` |\n| 作者原话像长期偏好但范围或稳定性含糊 | `pending`，取当前最窄合理范围；待确认只来自作者自己的话 |\n| 同类修改反复出现、从成稿或操作轨迹看出的模式 | 不记录、不推断；作者没开口的偏好不进记忆 |\n| “这一章别……”“这次给我……”等一次性要求 | 只执行，不记录 |\n| 角色、时间线、伏笔、世界观、当前剧情走向 | 写项目设定/追踪，不写作者记忆 |\n| 助手自己生成的文字、默认模板、工具告警、rubric 结论 | 不自我学习 |\n\n保留否定词、限定词和适用范围：`quote` 写原话，`assertion` 只做不改变语义的紧凑归纳，**新建条目限一句话（≤120 字节，约 40 个字）**，写不下就压缩措辞、不切限定词；背景写进 `reason`（不进 prompt），不另开字段。\n\n**一条偏好就是一条记录，例外和限定不许拆出去单列。** 「以后少用破折号，对话里也别用，除非表示打断」整条写成「破折号少用、对话里也不用，只在表示打断时保留」：超编时条目逐条被丢，拆开就可能只丢掉例外，把作者说过的限定变成绝对禁令。只有原话塞了**几条互不依赖**的偏好（如「多用短句」＋「章末留钩子」）才拆。\n\n范围：“本书 / 这个角色 / 这次连载” → `book`；“都市文 / 这类题材” → `genre`；交稿、检查、确认节奏等操作习惯 → `workflow`；“以后 / 一贯 / 我习惯”且无更窄限定 → `global`；含糊但可能稳定 → 最窄合理范围并置 `pending`。\n\n类型：`prose_style`、`story_design`、`workflow`、`delivery`、`interaction`。置信度与重要度均为 `low | medium | high`；超编时先丢重要度低的，按偏好的实际分量填，不要一律 `high`。`source` 只接受 `explicit_user`、`accepted_suggestion`、`manual`，工具拒绝推断类来源。\n\n## 确认、替换、忘掉与冲突\n\n- 同一类型、范围、归纳文本再出现，脚本强化原条目（累加证据与确认次数），不重复建条。\n- 新偏好与同一 store 的 active 条目矛盾：以 `conflict` 记候选，`conflicts_with` 列冲突 ID，本轮仍按当前要求执行；本书例外与全局规则不算冲突。冲突候选不能直接 activate，落定见维护文件「冲突候选」。\n- pending 用 `decide=activate|reject`。同一范围的规则改版用 `replace`，新条目启用、旧条目标 `superseded`；只有作者明确撤销或改变旧规则范围才跨范围替换。\n- 作者说“忘掉 / 这不再是我的习惯”用 `forget`，保留历史证据但不再加载。active 条目的语义不可原地偷改，语义变化必须 replace，历史才可审计。\n\n## 回执怎么告诉作者\n\n回复就两行纯文本，不加代码块或引用格式：第一行用一句人话说记住了什么、管哪本书或哪类场合，如「记住了：《{书名}》的对话一律用「」，以后写这本书都照这个来；想改随时说。」；第二行是机器回执作凭证，如「技术备注：Author Memory Receipt: r1 · BP001」。\n\n- 确认、替换、忘掉同理：「好，这条生效了：……」「换成了：……，原来的「……」不再用」「忘掉了：……」。只进待确认时说「这条先记在待确认里，你说\"确认\"才生效」；有冲突时用原话说明跟哪条旧习惯冲突。\n- `warnings` / `omitted_ids` 不原样贴：说「你的习惯攒得有点多，写正文时这几条可能顾不上：「……」」，并建议说「整理作者记忆」。不提字节、prompt、kind、scope；编号只能跟着原话出现。\n\n## 运行工具\n\n依次尝试 `python3`、`python`、`py -3` 找到 Python 3，从当前 skill 根运行本地副本：\n\n```text\n{PYTHON} {当前 skill 根}/scripts/author_memory_commit.py record --workspace {工作区} [--book-root {书目录}] --input {工作区}/.story/work/作者记忆-事件.json\n{PYTHON} {当前 skill 根}/scripts/author_memory_commit.py query  --workspace {工作区} --book-root {书目录} --kind {类型}（必传，可重复） [--genre {题材}] [--workflow {流程}]\n```\n\n- 子命令都可加 `--book {书名}`；写某本书时一律带 `--book-root`。事件 JSON 写在 `{工作区}/.story/work/`（不写系统 `/tmp`），成功后删掉；book 条目的 `scope.value` 填书名（书级 store 已记的名字，首次取目录名）。\n- 明确的“记住 / 确认 / 替换 / 忘掉”都走单事件 `record`：自动读该 store 当前修订、首次自动初始化，不手工读修订号或拼多操作事务。同一 `event_id` 同内容幂等返回原回执，内容不同则失败；返回的 `store` / `book` 说明写到了哪一级。\n- 成功才有 `Author Memory Receipt: rN · APxxx`，没有回执不得声称“已经记住”。**写入不因注入预算失败**：`warnings` 只是提醒（另一级 store 读不出来也在这里注明），按上节转告；有回执就是已记住，不要换 `event_id` 重试。\n\n## 事件格式\n\n新增或强化（`record` 输入；book 范围传 `--book-root`）：\n\n```json\n{\n  \"schema_version\": 1,\n  \"event_id\": \"conversation-2026-08-25-message-42\",\n  \"operation\": {\n    \"action\": \"remember\",\n    \"preference\": {\n      \"kind\": \"prose_style\",\n      \"scope\": {\"level\": \"global\", \"value\": null},\n      \"assertion\": \"对话尽量短，用动作承接情绪，不用大段解释\",\n      \"quote\": \"以后对话都短一点，情绪放动作里，别让角色长篇解释。\",\n      \"source_ref\": \"conversation:2026-08-25\",\n      \"source\": \"explicit_user\",\n      \"confidence\": \"high\",\n      \"importance\": \"high\",\n      \"status\": \"active\",\n      \"reason\": \"用户以“以后”明确声明长期偏好\",\n      \"conflicts_with\": []\n    }\n  }\n}\n```\n\n待确认用 `\"status\": \"pending\"`；冲突候选用 `conflict` 并填同一 store 的 active ID。确认、替换、忘掉时，把下列对象换进新事件的 `operation`（`BP` 编号传 `--book-root`）；`replace.preference` 字段同上但不传 `status`、`conflicts_with`，新条目直接 active：\n\n```json\n{\"action\":\"decide\",\"item_id\":\"AP002\",\"decision\":\"activate\",\"quote\":\"对，这就是我的长期习惯。\",\"reason\":\"作者明确确认\"}\n{\"action\":\"replace\",\"old_ids\":[\"AP001\"],\"preference\":{\"kind\":\"prose_style\",\"scope\":{\"level\":\"global\",\"value\":null},\"assertion\":\"以后对话允许更长的试探，但避免解释设定\",\"quote\":\"……\",\"source_ref\":\"conversation:2026-08-25\",\"source\":\"explicit_user\",\"confidence\":\"high\",\"importance\":\"high\",\"reason\":\"作者明确替换原有全局规则，不是新增本书例外\"}}\n{\"action\":\"forget\",\"item_id\":\"AP003\",\"quote\":\"忘掉这个偏好。\",\"reason\":\"作者明确撤回\"}\n```\n\nFile v1.1.27:references/banned-words.md\n\n# AI味禁用词与句式表\n\n> 表达默认值服从 [style-resolution.md](style-resolution.md)；文件结构与事实约束不豁免。\n\n<!-- 同名副本×6 字节同步，改动后跑 scripts/check-shared-files.sh -->\n\n## 默认优先检查的句式（先对照本书文风）\n\n写网文最毒的 AI 句式，作者一旦养成就会反复出现。以下是优先检查的句式：\n\n| 毒级 | 句式 | 错误例 | 修法 |\n|------|------|--------|------|\n| ★★★★★ | \"不是A，（而）是B\" / \"不是A，不是B，（而）是C\"（\"而\"可省略，省掉也算命中）| \"他不是冷漠，而是绝望\" | 直接写 B 或用更自然的表达 |\n| ★★★☆☆ | 跨段「不是A。/也不是B。/只是C。」 | 「不是嚎啕大哭。/也不是扯着嗓子喊不舍。/只是一个人走远了……」 | 语义复核；重复提纲或拖慢画面时压成 C，有辩解/悬念排除功能可保留 |\n| ★★★★ | \"，带着……\" 万能状语 | \"他笑了一下，带着一丝不易察觉的嘲讽\" | 删掉状语留主句，或换具体动作 |\n| ★★★★ | 无情绪声线：\"声音不大，却带着……\" / \"语气毫无波澜\" / \"平静无波\" / \"声音平直/平平/听不出情绪\" | \"她声音不大，却带着不容置疑的力量\" | 直接写台词内容、声音特征或动作 |\n| ★★★★ | \"他/她知道……\" | \"他知道这一切都来不及了\" | 用行为展示认知 |\n| ★★★ | \"仿佛/犹如/宛若……一般\" | \"仿佛能穿透一切一般\" | 删掉或白描 |\n| ★★★ | \"眼中闪过一丝……\" / \"嘴角勾起一抹……\" | \"眼中闪过一丝悲伤\" | 删掉；写他当场说的话或做出的决定 |\n| ★★★ | \"心中涌起一股……\" / \"心头一震\" | \"心中涌起一股暖流\" | 写它改变了什么：选择、台词、物件或后果 |\n| ★★★ | 抽象命运/开端收束：\"命运……棋局/獠牙\" / \"这一刻终于明白\" / \"反击才刚刚开始\" | \"命运终于露出獠牙；属于他的反击才刚刚开始\" | 回到角色当下可见的文件、动作、对话或物理后果 |\n| ★★ | 章末预告 \"他不知道的是……\" | \"他不知道的是，更大的风暴即将来临\" | 用具体钩子物件/事件收束，避免空泛预告 |\n\n> ★★★★★ 命中一处就要改；轻/中/重分档只按去 AI 味诊断的密度指标定。\n\n`check-ai-patterns.js` 的 `formulaic-parallelism` 还会提示「至于X不X，怎么X」和同动词「不V A，不V B」。这两类可能是功能性口语，因此只做 advisory；Gate B 必须连同台词读语境复核，若只是复述细纲/前文就压成一次判断，不能因 hook 豁免台词而跳过。\n\n**标点**：正文（含叙述和对话）禁用破折号 `——`/`—`、双连字符 `--` 和省略号停顿，改用句号、逗号、短句或动作断句；不设置对话破折号例外。盐言「」引号不在此列。\n\n---\n\n## 一级禁用词（出现即替换）\n\n> 什么词进一级：只收真人语料里几乎不出现、AI 特有的词。真人高频使用的自然副词和虚词不进一级，走二级密度控制。\n\n### 情态类\n仿佛、犹如、宛若、如同、一丝、一抹、些许、几分、隐约、毫无征兆、几不可闻、微不可察\n\n### 动作类\n深吸一口气、不禁\n\n### 表情类\n眼中闪过、嘴角勾起、眉头微皱、眉眼低垂、瞳孔微缩、瞳孔收缩、瞳孔一缩、指节泛白、眼神锐利、目光锐利\n\n### 心理类\n心中一动、心头一震、心下了然、心中暗道、心底泛起、不由得、心中一凛\n\n### 判断类\n不容置疑、不容置喙、不易察觉、显而易见、毫无疑问、不可否认、前所未有\n\n### 形容类\n坚定、闪烁着光芒、狡黠、深邃、凛冽、冰冷\n\n### 过渡类\n不由自主、情不自禁、自然而然、话锋一转\n\n## 二级禁用词（高频出现时替换）\n\n### 语境敏感词（仅高频或偷懒时处理）\n突然、陡然、骤然、猛然、好像、似乎、瞬间、猛地、死死地（角色口语、真实突发、时间压缩、视角不确定时可保留；用同义变体轮换规避重复不算豁免，按同一个词计密度）\n\n### 弱化副词（密度控制）\n缓缓、微微、轻轻、淡淡（每千字合计 ≤3；这四个词同时计入 `cliche-density-tic` 的套词密度统计；孤立自然使用可保留，成串出现或每个动作都垫一个时才替换）\n\n### 书面腔 → 口语化\n\n| 书面腔 | 口语化替换 |\n|--------|-----------|\n| 瓦解 | 消失 / 散了 / 没了 |\n| 无名火 | 烦躁 |\n| 往我心上捅刀子 | 心烦意乱 |\n\n### 总结句式\n- \"他/她终于明白...\"\n- \"他/她这才意识到...\"\n- \"这一刻，他/她终于明白/意识到...\"\n- \"从这一刻开始...\"\n- \"属于X的反击/复仇/故事，才刚刚开始\"\n- \"命运/宿命 + 齿轮/棋局/獠牙/改写/安排\"\n- \"此刻，他/她...\"\n- \"一切...都...\"\n- \"原来...\"\n\n### 排比句式\n- 连续3句以上相同结构的排比\n- \"有的...有的...有的...\"\n- \"一边...一边...一边...\"\n\n### 升华句式\n- \"这一刻...\"\n- \"他知道...\"\n- \"她明白...\"\n- \"这就是...\"\n\n## 禁用句式模板\n\n| 句式 | 示例 | 问题 |\n|------|------|------|\n| \"不是A，而是B\" | \"他不是冷漠，而是绝望\" | 最毒；直接写 B |\n| \"...，带着...\" | \"他说，带着一丝无奈\" | 万能状语 |\n| \"声音不大，却带着……\" | \"她声音不大，却带着不容置疑的力量\" | AI 最爱声音描写 |\n| \"仿佛能...一般\" | \"仿佛能穿透一切一般\" | 文言腔 |\n| 对话标签密度过高/公式化标签 | \"好的，他说道\" | 普通\"说\"可保留；高频或公式化时处理 |\n| \"他/她感到...\" | \"她感到一丝失落\" | 告诉而非展示 |\n| \"他/她意识到...\" | \"他意识到事情不对\" | 直接告知 |\n| \"眼中闪过一丝XX\" | \"眼中闪过一丝悲伤\" | 模板化 |\n| \"嘴角勾起一抹XX\" | \"嘴角勾起一抹冷笑\" | 模板化 |\n| \"心中涌起一股XX\" | \"心中涌起一股暖流\" | 模板化 |\n| \"取而代之的是\" | \"笑容消失，取而代之的是冰冷\" | AI 过渡模板；直接写新状态 |\n| \"淬了/淬着X\" | \"眼里淬了毒\" | AI 通感套路；写动作或台词 |\n| \"显得（有些）X\" | \"他显得有些兴奋\" | 告诉而非展示 |\n| \"心底/心里某个地方+软\" | \"心里某个地方软得一塌糊涂\" | 言情套句；写动作 |\n| \"（浑身）散发着一股X气息/气场\" | \"浑身散发着一股生人勿近的气息\" | 万能气场描写；写旁人的反应 |\n| \"命运/宿命 + 齿轮/棋局/獠牙/改写/安排\" | \"命运终于露出獠牙\" / \"早已布好的棋局\" | 抽象作者总结；改成角色当下撞见的文件、动作、对话、物理后果 |\n| \"这一刻终于明白/从这一刻开始/才刚刚开始\" | \"这一刻，他终于明白\" / \"反击才刚刚开始\" | AI 收束腔；删总结，用动作或未解决问题收尾 |\n\n## 比喻分类（默认复核，不默认全删）\n\n带\"像/如/仿佛/犹如/宛若\"的比喻不是一律 AI。真正高风险的是：成片堆叠、套用万能文学比喻、用精致比喻替代剧情推进，或在段尾替读者总结意义。本表用于识别需要复核的比喻类型：\n\n| 比喻类别 | 例 | 处理 |\n|---------|----|------|\n| 生活/角色化 | \"像一头被抛弃的野狗\" | 若贴角色视角、能传递信息或情绪，可保留 |\n| 物品/现象类 | \"像一把刀\" \"脸色惨白得像这漫天的雪\" | 普通功能性比喻可留；模板化或重复时改白描 |\n| 状态类（陈词滥调） | \"梨花带雨\" \"如沐春风\" | 优先删或改成具体动作/表情 |\n| 抽象类 | \"像命运的齿轮\" \"像上辈子的尘埃\" | 高风险，优先落回动作、物件、声音、后果 |\n| 假设类 | \"力道大得像是要把骨头捏碎\" | 若是角色身体感知可留；夸张堆叠时改事实后果 |\n\n处理原则：先看功能，再看密度。保留最能传递信息或情绪的一两个，其余改为直接描述、动词、名词、作用、结果或事实；不要把删掉的比喻替换成另一批新比喻。例 \"脸色惨白得像这漫天的雪\" 若只是套话 → \"脸色惨白\"；若雪景正在压迫角色，可保留或改成角色当下看到的具体画面。\n\n> `metaphor-density-tic` 是 advisory：提示通读复核，不是 blocking；生活化、角色化、单个有功能的比喻可以保留。\n\n## 替换策略速查\n\n| 原文类型 | 替换方法 | 示例 |\n|----------|----------|------|\n| 抽象情绪词 | 先看上下文是否已成立；再选选择、台词、物件、后果或一句直写 | “紧张”若不影响下一步可直写或删；若导致签名作废，就写作废的结果 |\n| \"感到XX\" | 删除“感到”后按场景决定是否还要情绪句 | “他感到愤怒”可写“他火了”，也可直接写他撤回报价；不要默认换成攥拳 |\n| 形容词堆砌 | 白描手法 | \"美丽动人的笑容\" → \"她笑了\" |\n| 书面表达 | 口语化 | \"不容置疑\" → \"就是\" |\n| 解释性描写 | 留白 | \"他因为害怕而...\" → \"他退后一步\" |\n| 连续排比 | 保留最强一条 | 3 句排比留 1 句 |\n| 总结升华句 | 直接删除 | \"这一刻，她终于明白了...\" → 删 |\n| \"不是A，而是B\" | 直接写 B 或更自然的表达 | \"他不是冷漠，而是绝望\" → 直接写 B |\n| 多余修饰（形容词/定语/量词/指示代词） | 删 | \"白色的药片\" → \"药片\"；\"手里那截链子\" → \"链子\"；\"飞驰的汽车\" → \"车\" |\n\n**替换不复用**：右列是方向示例，不是标准答案。同一禁用词在一章内多次命中时，各处给不同的具体化写法；同一个替换写法反复出现（每次都「垂下眼」、每个动作都补「了一下」），替换产物本身就成为新的模板指纹。\n\n**套词密度优先处理**：`check-ai-patterns.js` 报 `cliche-density-tic` 时，说明禁用词不是零星误用，而是聚成了模板腔。处理顺序不是同义词替换，而是先删抽象总结，再把情绪/判断落到角色当下可见的动作、物件、对话和具体后果。\n\n**套式反应逐处删除测试**：`stock-reaction-tic` 报警时，不代表禁止身体描写。逐处问：删掉后信息、选择、关系、物件或动作结果是否受损？无损就删，不把“指尖轻叩”换成“目光微沉”。伤势、动作失败、人物习惯或情节后果明确时可以保留。\n\nFile v1.1.27:references/batch-review.md\n\n# story-review：多章分批审查\n\n多章/整卷/整本审查要拆成两批及以上时读本文件；单章或少量章节一次审完不读。full、lean、solo 都适用。\n\n## 跨批审查落盘契约\n\n分批时维护 **{项目根}/.story-review/state.md**：\n\n1. 首批确定本次完整审查范围和批次顺序。每批综合裁决后，用同目录临时文件 + rename 原子重写 state.md，不能只把结果留在对话里。\n2. state.md 只记录完整审查范围、已完成范围、下一批，以及“上一批未解决 findings 摘要”。摘要项保留 location、issue 和预计核查/兑现范围。\n3. 下一批开始前先读取 state.md，把未解决摘要注入 reviewer prompt；已解决或用户明确不处理的项不再继承，但须在本批输出中说明。\n4. 每个项目同时只维护一条跨批审查；若新一轮与 state.md 中未完成范围不同，先说明会丢弃的旧进度并征得用户确认，确认后在首批完成时覆盖。续接时 state.md 缺失、损坏或本批超出既定范围，应明确报告并停止，不猜测旧内容；非分批审查不创建它。\n\n**.story-review/** 只保存审查状态，不属于小说事实追踪；不得借此修改正文、设定、大纲或 `追踪/`。\n\n## 每批开审前\n\n- **跨批连续性（分批必做）**：审每一批前，先读 `追踪/伏笔.md` 中状态为 `已埋` 且计划回收章 ≤ 本批末章的当前行，再按需读取相关 `追踪/逐章记录/第NNN章.md` 查变更原因；同时读取涉及角色的独立快照，并按上方契约把 state.md 的上一批未解决 findings 摘要作为「继承的开放项」注入 reviewer / consistency-checker prompt（solo 由自己逐条核对）。新发现但尚未登记的开放钩子先列为维护候选，收尾时必须有正文证据才能进入修订事务。\n- **乱序/重叠审查提醒**：若已审过靠后的范围（如先审 300-400），之后审靠前的范围（200-300）时，只有当本批**新增/改动了一个开放项、且其预计兑现章落在已审过的靠后范围内**，才提醒用户「200-300 的改动可能影响已审的 300-400」，并让用户选择复审受影响章节 / 全量复审 / 仅记为待办——**默认记为待办，不盲目全量重跑**。无具体跨范围依赖时不提醒。\n\nFile v1.1.27:references/character-relations.md\n\n# 角色关系与感情线操作手册\n\n## 决策路由\n\n| 你在设计什么 | 使用本章方法 |\n|-------------|-------------|\n| 角色间关系类型 | 人物关系类型表 |\n| 感情线核心人设 | 感情流人设核心法 |\n| 爱情线底层逻辑 | 男频/女频爱情线差异 |\n| 穿书/穿游戏角色选择 | 穿书角色选择法则 |\n| 多角关系/修罗场 | 修罗场收场策略 |\n| 好感度推进节奏 | 好感度体系 + 男频恋爱文攻略 |\n| 配角态度变化 | 配角攻略缓冲区 |\n| 角色共情写作 | 角色行为自洽检查 |\n| 角色目标与关系线 | 角色目标独立性 + 关系线设计 |\n\n---\n\n## 人物关系类型\n\n查表确定角色间的关系类型，然后按原则执行。\n\n| 关系类型 | 定义 | 功能 | 示例 |\n|---------|------|------|------|\n| 冲突型 | 双方利益/理念对立 | 制造张力，推动情节 | 宿敌、竞争对手 |\n| 联盟型 | 双方有共同目标 | 提供助力，制造羁绊 | 战友、师徒 |\n| 亲密型 | 情感纽带连接 | 制造软肋，提供情感支点 | 恋人、家人、兄弟 |\n| 权威型 | 上下级/支配关系 | 制造压力，限制主角行动 | 师父、老板、监管者 |\n\n**执行规则**：\n- 每个重要关系至少安排一次考验（背叛/牺牲/误解）\n- 关系必须有变化弧线（敌人变盟友、盟友变对手）\n- 禁止所有关系都是\"你好我好\"的铁板一块\n- 关系的功能必须服务于情节，不能只为甜/虐而存在\n\n---\n\n## 感情流人设核心法\n\n感情流中剧情为人设服务——每次剧情都要丰满人物或推动感情发展，否则就是无效剧情。\n\n### 构建步骤\n\n1. **确定人设核心**：写下最初出现在脑海里的角色特征（如\"想登上皇位的皇子\"\"病弱皇子\"）\n2. **围绕核心发散**：回答——为什么有这个核心？过去经历？环境影响？性格成因？\n3. **延伸剧情线**：核心自带的剧情必须写（有目标→目标线；有伤痛→治愈线）\n\n### 执行规则\n\n- 俗套剧情配上丰满人设也能脱离套路感\n- 两个主角都必须有闪光点和独立变化路线，不能一个人出彩另一个人黯淡\n- 高光不等于装逼——所有让读者对角色印象深刻的时刻都是高光，包括痛彻心扉的时刻\n- 生命不止恋爱——角色心里希望恋爱，但生命里不能只有恋爱，只有恋爱的角色立不住、很单薄\n\n---\n\n## 男频与女频爱情线底层逻辑差异\n\n**先确定目标读者群，再选择对应逻辑。两者不可混淆，否则读者会觉得\"不对味\"。**\n\n### 男频爱情线逻辑\n\n| 维度 | 说明 |\n|------|------|\n| 核心 | \"外在因素展示\"——主角和对象在一起体现两人的外在因素多优秀 |\n| 三种核心逻辑 | \"她要是我的该多好\" → \"这么优秀的人是我的了\" → \"这么优秀的人都喜欢我，我更优秀\" |\n| 围观者想法 | \"能得到这么优秀的女人，我好羡慕\"（非\"恋爱好甜\"） |\n| 女主 | 最好有多个女性角色喜欢主角，越多说明主角越优秀 |\n| 对象本质 | \"奖杯\"——一切动机的根本目的是胜利 |\n\n写男频感情线时，围绕\"展示优秀\"设计事件。\n\n### 女频爱情线逻辑\n\n| 维度 | 说明 |\n|------|------|\n| 核心 | \"连接\"——两人之间唯一、坚不可摧、最优先的情感连接 |\n| 连接要求 | \"我爱的是你这个人，外貌、财富、才华都不能替代这份连接\" |\n| 纯洁性 | 连接形成后应逐渐舍去外在因素影响 |\n| 双方 | 最好初恋+双洁——保障连接的纯洁性和唯一性 |\n| 围观者想法 | \"他们的恋爱好甜，我好羡慕\" |\n\n写女频感情线时，围绕\"深化连接\"设计事件。\n\n---\n\n## 穿书/穿游戏角色选择法则\n\n### 必须满足的条件\n\n- 叙事主角必须对原世界有相当熟悉度（最核心的期待感来源）\n- 确定穿越进熟悉的世界，一两句话交代清楚，不能超过一章还不知道身处何方\n- 必须选择穿越后有强戏剧性或强矛盾的角色（如穿越成恶毒女配）\n\n### 信息差设计\n\n- 在原世界基础上适当设计信息差，为叙事主角提供探索空间\n- 可以用原世界知识卡bug获取超额收益\n\n---\n\n## 修罗场收场策略\n\n修罗场本质是一种矛盾，控制对抗烈度，不能让爱情线对象之间出现不可调和的矛盾。\n\n| 收场方法 | 操作 |\n|---------|------|\n| 关联回事业线 | 让爱情线对象们把争风吃醋转化为\"比谁对主角事业线贡献更大\" |\n| 插入事业线突发事件 | 对抗进入白热化时，用突发事件让所有人从内斗切换成一致对外 |\n| 一笔带过 | 最多两人互相看不惯、说两句嘲讽话就过去，非常克制 |\n\n---\n\n## 傻白甜角色塑造避坑\n\n### 六个必避之坑\n\n1. 女主犯错不能是故意的，不能明知不能做偏要做\n2. 女主犯错不能违反道德——傻白甜最重要的是天真小孩子般的高道德感\n3. 不能站在道德高地指责他人（道德婊行为），自己却做不好\n4. 不能因为道德婊行为和队友发生矛盾后还让队友认错赞美她\n5. 正确做法：有更高道德标准 → 所作所为符合 → 为此显得与众不同和有点傻气\n6. 可以写成长线：坐到被她指责的人的位置上后，发现原来那个做法已是最好的选择\n\n### 反向用法\n\n塑造傻白甜反派时，把以上六点全加在她身上，让读者一见就厌恶。\n\n---\n\n## 人设改变的双向翻转法\n\n爱情线中关系发生变化时的人设调整方法。\n\n### 核心思路\n\n- 最好的改变是两个人都改变，且改变后恰好与之前两人之间的对应关系相反\n- 改变要基于原人设做局部调整，和原人设保持密切联系，避免随意改造\n\n### 执行规则\n\n- 人设变化发生在爱隔山海阶段之后（尤其是面对最大阻碍之后），不要再设计新的矛盾，只要发糖\n- 真正的阻碍已在前面解决，此时读者最迫切的渴望是多吃糖\n- 发糖要用实在的CP行为和悉心照顾表达爱意，不是\"我爱你\"式的工业糖精\n\n---\n\n## 角色行为自洽检查\n\n### 第一步：排除外部强推\n\n检查角色行为是否只是为了让剧情往某方向发展。如果角色\"恰好\"做了推进剧情的事但没有自身动机，标记为\"人设偏移\"，必须为该行为补充角色层面的合理理由。\n\n### 第二步：目标情绪确认\n\n写每段前明确三个要素：\n1. 本段目标情绪：这段剧情要让读者产生什么情绪？\n2. 角色性格特征是否支持该情绪：角色的设定属性是否自然导向此情绪方向？\n3. 角色行为是否符合使命定位：角色在本段的行为是否与其在故事中的功能定位一致？\n\n### 第三步：人设行为推导\n\n从角色已设定属性（经历/性格/目标/当前状态）推导其在场景中的行为：\n- 列出该角色在此场景下的2-3种可能反应\n- 评估每种反应与角色已有行为模式的一致性\n- 选择最符合人设且最有戏剧张力的那一种\n\n### 第四步：情绪一致性校验\n\n检查角色表达的情绪核心与场景目标情绪是否一致。不一致则调整角色行为或场景目标情绪，确保输出内容在情绪维度上自洽。\n\n**两种执行路径**：\n- 路径A：先定目标情绪 → 按人设推导角色行为 → 校验一致性\n- 路径B：先按人设推导角色行为 → 反推场景目标情绪 → 校验一致性\n\n---\n\n## 配角攻略缓冲区\n\n配角对主角态度的变化过程 = 主角攻略配角的过程，伴随巨大的期待感和爽点。\n\n### 缓冲区类型\n\n线上线下、背后议论、异地相处、地位差距、亲密度差距、信任程度、信息差等。\n\n### 操作步骤\n\n1. 始终保持缓冲区存在\n2. 在卷纲中挑出事件拐点（5~7个）\n3. 在每个拐点处标注配角状态和对主角的态度变化\n4. 每次攻略到关键点位时，配角的态度变化必须写清楚\n5. 态度变化本身就产生情绪波动和期待感\n\n### 执行规则\n\n- 配角不能像NPC一样站着等主角触发\n- 配角要有自己的行动，由配角观点引出事件\n- 正面角色也一样：和主角立场相同的人也应有自己的行动和动机\n\n---\n\n## 利用角色身份认知差制造冲突\n\n同一个角色在不同人眼中的\"声望\"是动态变化的，不是恒定值。\n\n| 视角 | 看重什么 | 对男主的评价 |\n|------|----------|-------------|\n| 世俗视角 | 家境对等，抗风险能力 | 综合条件匹配度 |\n| 男主自身 | 赚钱养家+感情 | 相对门当户对 |\n| 女主视角 | 感情+专一+爱 | 只要在乎的就门当户对 |\n| 富二代 | 外貌家世匹配度 | 我才更门当户对 |\n| 路人 | 综合条件对比 | 女主该嫁富二代 |\n\n**操作要点**：\n- 不同人对同一个角色的评价差异 = 天然的矛盾冲突来源\n- 恋爱文的核心爽点之一：不同维度的评价差\n\n---\n\n## 亦敌亦友关系\n\n最有魅力的人物关系类型。\n\n### 执行规则\n\n- 前提：两个角色本身都要有魅力，否则只是强行五五开的狗皮膏药\n- 核心：高度认可 + 绝对冲突 → 惺惺相惜 → 缺一魅力全无\n- 真正的宿敌 = 双方相互认可，外人盖章不算\n\n---\n\n## 竞争者定位与亲情线用法\n\n### 竞争者（鲶鱼效应）\n\n- 定位：给男主/女主增加紧张感上压力 → 推动攻略进度\n- 剧情设置重点在\"高潮节点前\" → 属于铺垫环节\n- 对高潮后续写剧情作用不大 → 不是续命手段\n\n### 亲情线的四个方向\n\n| 方向 | 作用 | 使用时机 |\n|------|------|---------|\n| 男方助力 | 提供金钱地位权力 | 高潮前发挥 |\n| 男方阻力 | 设置障碍让主角得到认可 | 节点前后都能用 |\n| 女方助力 | 温柔乡感情补给站 | 高潮前发挥 |\n| 女方阻力 | 父母不同意→为了认可去努力 | 节点前后都能用 |\n\n助力主要在高潮前，阻力节点前后都能用，阻力更好发挥。\n\n---\n\n## 男频恋爱文写法攻略\n\n### 读者为什么看恋爱文\n\n| 价值 | 来源 |\n|------|------|\n| 情绪价值 | 填补\"被需要、被在乎\"的情感空缺 |\n| 自尊价值 | 女主条件好→带出去有面子→配角羡慕嫉妒 |\n| 高身份女主原因 | 更强的装逼打脸工具人+更大的自尊满足 |\n\n### 核心技法：把恋爱当升级文写\n\n- 暧昧拉扯的过程才是最有吸引力的\n- 好感度进度条：每一步推进 = 升级文中的一个\"等级\"\n- 每一个事件是一次\"升级\"→ 通过冲突、化解、理解和共鸣让好感攀升\n\n### 好感度升级路径\n\n路人 → 好人（扶老奶奶过马路） → 正直勇敢的好人（挺身而出） → 不错的朋友（理解原生家庭困境） → 喜欢但不知（特殊契机看到彼此不为人知的一面）\n\n### 关键原则：主角不主动追求\n\n- 当前男频读者普遍反感\"舔狗\"人设\n- 推动好感靠男主自身优秀品质吸引，不是主动追求\n- 男主帮女主是举手之劳不经意为之 → 女主因此记住他\n\n### 感情升级的不对称性\n\n- 两条进度线：表面社会关系（路人→朋友→情侣）+ 实际情感好感度\n- 两条线不应齐头并进 → 一条快一条慢 → 带来丰富的矛盾冲突\n- 情感线快于社会线 → 辉夜大小姐模式（双方好感拉满但嘴硬不表白）\n- 社会线快于情感线 → 赘婿/择天记模式（表面夫妻实际好感为零）\n\n### 写女主对主角好\n\n| 女主类型 | 付出方式 |\n|---------|---------|\n| 自卑社恐 | 偷偷帮忙塞东西但害怕被发现 |\n| 傲娇型 | 用心做便当但嘴硬\"做多了顺便带的\" |\n| 直率泼辣 | 大大方方送礼物或直球表白 |\n\n### 善用对比\n\n| 对比类型 | 操作 |\n|---------|------|\n| 时间线对比 | 女主刚认识主角时 vs 熟悉后的态度变化 |\n| 双标 | 不允许别人摸头但主角可以 → 凸显特殊地位 |\n| 信息差 | 男女主双重身份（网上vs现实）→ 期待揭穿时反应 |\n\n---\n\n## 好感度体系（通用框架）\n\n### 四阶段\n\n萍水相逢 → 爱情喜剧 → 爱隔山海 → 大结局\n\n### 好感度 × 关系阶段对照表\n\n好感度（负/零/半/满） x 关系阶段（熟悉/试探/暧昧/确认）\n\n阶段匹配原则：**按低的一方计算**。好感度到了但关系阶段没到 = 行为突兀。\n\n### CP行为三类门槛\n\n| 行为类型 | 门槛 | 说明 |\n|---------|------|------|\n| 需容忍行为 | 半好感+ | 主动亲密、妥协，必须给补偿否则变舔狗 |\n| 特殊对待行为 | 半好感+ | 主权、信赖、牺牲、特殊待遇、安抚 |\n| 关联行为 | 双方半好感+ | 默契、分享、陪伴 |\n\n好感度不足时写需容忍行为 = 油腻/性骚扰感。\n\n### 5套感情线结构模板\n\n| 模板 | 核心 |\n|------|------|\n| 好感度变化 | 可能升/降/已降 → 各自处理路径 → 余韵 |\n| 受益 | 享受伴侣带来的好处 = 爱情线装逼核心 |\n| 争风吃醋 | 多角色为主角争风，不是主角吃别人醋 |\n| 发展受阻 | 阻碍→试图解决→解决→余韵 |\n| 狗粮 | CP日常互动 |\n\n---\n\n## 角色目标的独立性与关系线设计\n\n### 主角目标独立性原则\n\n- 主角的目标必须属于自己的 → 不能是\"帮别人实现目标\" → 否则主角变成配角/工具人\n- 正确做法：把别人的目标转化为主角自己的（平叛=保护自己的利益/获得认可/获取资源）\n- 自检方法：随机看一章 → 主角在主动追求什么 → 如果没有 → 主角沦为别人的棋子\n\n### 感情线的层次设计\n\n- 感情推进不是线性的，应该有升级节点，每个节点对应一个剧情高潮\n- 社会关系线 vs 实质情感线的错位制造张力\n- 最佳节奏：感情先慢后快 → 前期铺垫积累好感 → 后期集中爆发 → 匹配盛大仪式\n\n### 配角的功能性定位\n\n| 类型 | 功能 | 使用时机 |\n|------|------|---------|\n| 竞争者（鲶鱼型） | 制造压力推动主角行动 | 高潮节点前 |\n| 助力型亲友 | 提供资源/情感支持 | 高潮前发挥 |\n| 阻力型亲友 | 不认可→设置条件→主角克服→获得认可 | 节点前后都能用 |\n\n---\n\n## 绿茶/负面角色\n\n- 可以推动剧情但要谨慎使用\n- 确认该角色是否有不可替代性\n- 主角强势时任何角色都能变正反馈\n- 主角弱势时负面角色会被读者恨\n\n---\n\n## 后宫文女主人设设计法\n\n### 核心思路\n后宫文的关键是弱化男主\"主动渣\"的感觉，让女主自身设定成为推动后宫的主力。\n\n### 设计原则\n1. **女主人设要预设方向**：开书前就设计好每个女主的核心特质\n2. **差异化设计**：不同女主有完全不同的价值观和背景\n3. **同居培养感情**：开局让女主们同住一个屋檐下，彼此成为朋友\n\n### 温水煮青蛙法\n以三个女主为例：\n\n| 角色 | 人设设计 | 在后宫中的作用 |\n|------|----------|---------------|\n| 青梅（正宫） | 传统价值观，占据防守位 | 从小一起长大，天然正宫 |\n| 女主B | 家庭圆满家教开明，理性看待感情 | 不在意名分，只在意快乐 |\n| 女主C | 缺少父爱和社交，爱情观模糊 | 不存在一夫一妻制思想束缚 |\n\n核心逻辑：\n- 青梅占据正宫与防守位\n- 另两个女主不在意后宫，只在意跟主角在一起\n- 把\"主角脚踏多条船\"的问题转化为\"青梅防守 vs 另两人共享\"的问题\n- 一点一点突破青梅的防守底线，等反应过来时已经是既成事实\n\n\n## 男频极简爱情线构型\n\n### 核心原则\n男频爱情线不需要复杂的情感博弈，核心是\"英雄救美 + 事业舞台 + 对手衬托\"三要素。\n\n### 极简构型\n1. **英雄救美**：女主陷入困境 -> 主角用金手指/实力解决 -> 建立初始好感\n2. **事业舞台**：主角在事业上展示金手指 -> 女主在场作为重要观众 -> 好感随事业成就升级\n3. **对手衬托**：情敌/对手同时是事业对手 -> 打败对手既是事业胜利也是感情胜利\n\n### 关键操作\n- 女主的每一次好感升级都绑定在主角的事业成就上，不单独写纯感情戏\n- 女主有自己的事业线/目标，不是花瓶——她的事业目标与主角有交叉但独立\n- 情敌的价值在于他同时威胁主角的事业和感情，打脸时有双重爽感\n- 感情节奏跟着事业节奏走：事业低谷时感情拉扯，事业高峰时感情升温\n\n### 爱情线与事业线融合检查\n- 删掉所有爱情线段落，事业线是否还成立？如果不行 = 爱情线拖后腿了\n- 删掉所有事业线段落，爱情线是否还有看点？如果不行 = 爱情线太弱\n- 理想状态：两条线互相增强，拆开各自能看，合在一起更好看\n\n\n## 质量检查清单\n\n每次完成角色关系/感情线设计后，逐项核查：\n\n- [ ] **关系类型明确**：每个重要关系已归类为冲突/联盟/亲密/权威之一\n- [ ] **关系有弧线**：每个重要关系至少经历一次考验或变化\n- [ ] **人设有核心**：主角人设有明确的核心特征和发散依据\n- [ ] **目标独立性**：主角的目标属于自己的，不是帮别人实现目标\n- [ ] **好感度匹配**：CP行为与当前好感度阶段匹配（按低的一方计算）\n- [ ] **读者群对味**：男频围绕\"展示优秀\"设计事件，女频围绕\"深化连接\"设计事件\n- [ ] **配角有行动**：配角不是NPC式站桩等待触发，有自己的行动和动机\n- [ ] **缓冲区存在**：配角攻略过程中始终保持缓冲区，拐点处标注态度变化\n- [ ] **修罗场可控**：多角关系中对象之间无不可调和的矛盾\n- [ ] **发糖时机正确**：爱隔山海之后不再设计新矛盾，只发实在的CP行为糖\n- [ ] **角色不止恋爱**：角色生命中有恋爱之外的内容，不是单薄的情感工具人\n\nFile v1.1.27:references/dialogue-mastery.md\n\n# 对话设计操作手册\n\n> 写对话场景时加载。先看决策路由选对话模式，再用操作指令控制质量。\n\n---\n\n## 决策路由\n\n| 你的对话场景是 | 用这种模式 | 操作 |\n|-------------|---------|------|\n| 主角碾压/打脸 | 压制模式 | 对方长篇大论 → 主角一字回应 |\n| 主角亮底牌/反转 | 反转模式 | 对方嚣张 → 主角一句话事实 → 对方沉默 |\n| 关系破裂/心死 | 心死模式 | 对话越回越短：从辩解 → 沉默 → \"随意\" |\n| 日常互动/立人设 | 日常模式 | 让其他人物参与冲突，不要主角一个人独白 |\n| 群众震惊/弹幕 | 弹幕模式 | 递进：普通人震惊 → 专业人士分析 → 特殊身份者反应 |\n| 信息展示/世界观 | 信息嵌入 | 用角色语气包裹信息，不是机械陈述设定 |\n| 情绪拉扯/虐心 | 情绪推动 | 上行下行交替，像拉锯拉升期待 |\n\n### 对话模式选择补充\n\n| 对话类型 | 常见问题 | 修正操作 |\n|----------|---------|---------|\n| 问答式（通篇一问一答像审讯） | 改为一方主动说，另一方给反应；反应可用动作/表情/心理 |\n| 冲突式（太礼貌不够劲） | 递进五级：委婉拒绝→友好人道→命令否定→PUA式→直接侮辱 |\n| 日常对话（容易变成没功能的水） | 功能是立人设；能让人参与的冲突别让主角独白 |\n| 多人对话（混乱/没营养） | 写前规划每个角色功能：信息提供者/情绪放大器/冲突制造者 |\n\n---\n\n## 对话核心规则\n\n每句对话必须承载以下至少一项，否则删除：\n\n1. **推进剧情**：透露新信息、推动事件发展\n2. **增加期待感**：暗示即将发生的事、制造悬念\n3. **展示人设**：通过语言风格传递角色性格\n\n且在情绪场景里，每句还要**回应上一句对方的情绪状态**（承接/偏转/升级/退缩）——对话是两个人的情绪在碰，不是轮流播报信息。只推进剧情、句间无情绪承接 = 机械对话。\n\n### 绝对禁止\n\n| 禁止 | 理由 |\n|------|------|\n| 配角无脑夸主角 | 假 |\n| 互相解释读者已知信息 | 水字数 |\n| 大段说明文式对话 | 闷 |\n| 所有角色说话方式一样 | 模糊 |\n| 对话说服人物 | 现实中没人被几句话说服，用突发状况代替 |\n| 情绪写完方向变了 | 需回退到情绪拆分 |\n| 捧哏工具人、鹦鹉复读对方原话 | 配角只剩接话功能 |\n| 高位者长篇自证、说话不分场合 | 身份和处境塌了 |\n| 情绪水肿咆哮、生死场景嘴碎 | 越吵越不紧张 |\n| 悬念正攒着就被台词说破 | 期待提前泄掉 |\n\n---\n\n## 权力博弈对话\n\n### 规则\n\n对话长度 = 权力地位。掌控者话短且冷静，被动者话多且情绪化。\n\n### 压制模式\n\n结构：对方长篇大论（3-5 行）→ 主角一字回应。\n\n```\n\"你以为你是什么东西？我告诉你，这个家轮不到你说话！你嫁进来的那天起就该明白自己的位置。\"\n\"滚。\"\n```\n\n### 反转模式\n\n结构：对方嚣张（2-3 行）→ 主角亮底牌（1 行事实）→ 对方沉默。\n\n```\n\"你有什么资格管？这是我家的钱，我想怎么花怎么花。\"\n\"你妈的存折，密码是我的生日。\"\n```\n\n### 心死模式\n\n结构：对话越回越短，从辩解到沉默到「随意」。\n\n```\n\"你听我解释，那天不是你想的那样。\"\n\"嗯。\"\n\"真的，我可以证明。\"\n\"随意。\"\n```\n\n### 操作指令\n\n- 掌控者/主角亮底牌时：对话 ≤ 10 字，不加动作描写\n- 被压制方：对话 ≥ 20 字，可加动作描写（攥拳/咬唇/站起来）\n- 两人对话时：短句方 = 权力上位，长句方 = 权力下位\n\n---\n\n## 潜台词与议程\n\n### 潜台词规则\n\n- 角色真实动机绝对不能浅显地写在台词里\n- 现实中人说话都给自己找借口，角色也一样\n- 每句对白同时设计：角色的动机（可能角色自己都没意识到）和角色的借口\n\n### 对话议程\n\n- 每个角色进入对话时有自己的议程：想从这场对话中得到什么\n- 两个角色的议程碰撞才是张力来源\n- 双方议程一致（同立场）= 复述，失去意义\n\n### 语气由三要素决定\n\n关系 × 场合 × 目的 = 语气\n\n| 场合 | 特点 | 适合内容 |\n|------|------|----------|\n| 私人（单对单） | 深入、感情流露透彻 | 内心剖白、密谋、表白 |\n| 公众 | 需考虑体面，措辞收敛 | 需要冲击力时可打破（如当众翻脸） |\n| 熟人（朋友/同门） | 深度介于两者之间 | 轻松互动和信息交换 |\n\n私密的话在公众场合说才有冲击力。对话中不能完全表达的内容，通过动作、神态、环境补充。\n\n---\n\n## 情绪推动对话\n\n### 强情绪对话\n\n- 命令式+否定式最能激发读者情绪：\"我说的还不够清楚吗？\"\n- 最强话术：打着为你好的幌子，句句不离关心，但句句都是嫌弃、指责、厌恶\n- 直接否定比含蓄暗示更伤人\n\n### 情绪连续性\n\n角色情绪是连续的、循序渐进的。从生气到高兴：生气 → 不那么生气 → 不生气 → 高兴，每次转变需对应事件触发。不能跳步。\n\n### 情绪与行动的因果检查\n\n1. 遇到事件（失衡状态）\n2. 情绪反应（可以直写，也可以体现在语言、选择或有功能的动作中）\n3. 内心思考（只写影响理解的判断；鲁莽可以直接体现在行动里）\n4. 采取行动（基于前三步结果回应）\n\n用于检查转变是否成立，不要求逐步写满；上下文已清楚的反应或思考无需补写。\n\n### 对话不平淡三思路\n\n- 对话本身带来/强化某个核心驱动力（期待、爽感、悬念）\n- 信息交流因某原因受阻碍，阻碍可能导致驱动力到来\n- 发展突然脱离读者预期（但必须合理、符合人设）\n- 把长篇对话塞在期待点和爽点之间：读者为了看爽点愿意忍受中间对话\n\n---\n\n## 信息展示与世界观引出\n\n- 大量信息通过对话展示会显得啰嗦，部分信息转化为情节、心理描写、旁白、环境、动作\n- 用角色的语气和立场包裹信息，不是机械陈述设定\n- 设定用到哪个稍微带出来就行，不需完完全全讲明白前因后果\n- **角色不当\"科普嘴\"**：设定/原理/前因后果不能靠任何角色（尤其信息型/AI 配角）整段讲解——Gate G 同样适用于角色台词。按角色当下的目的和对话阻力取舍信息，用到哪带哪点，不固定拼接身体反应。\n\n### 信息拉扯示例（以\"主角新书起飞了\"为例）\n\n| 角色 | 台词 | 功能 |\n|------|------|------|\n| 甲 | 听说成绩…… | 悬念拉期待 |\n| 乙 | 肯定没人看！ | 下行 + 拉期待 |\n| 甲 | 听说成绩很不错 | 上行 + 拉期待 |\n| 乙 | 首订一万三？ | 展露核心信息 + 达成爽点 |\n\n上行和下行交替，情绪像拉锯不断拉升期待。\n\n---\n\n## 人物语言差异化\n\n每个角色要有自己的说话方式。对话时经常卡住不知道角色会说什么 → 人设模糊，去总结类似人设的说话方式。\n\n| 差异化维度 | 操作 |\n|------------|------|\n| 口癖和惯用语 | 给每个主要角色一个标志性用词 |\n| 说话节奏 | 长篇大论 vs 短句连击 |\n| 信息偏好 | 技术型带专业术语，江湖人带切口 |\n| 立场固定 | 某角色永远从某个角度发言（悲观派/乐观派/务实派） |\n| 身份影响措辞 | 老者/少年/贵族/市井，身份不同则措辞、自称、敬谦词不同 |\n| 性格影响语气 | 智谋型话里有话；鲁莽型想到什么说什么；冷静型措辞精确，偶尔情感外露反而有冲击 |\n| 进度影响态度 | 初见/熟悉/对立/亲密，关系阶段不同则语气与信息量不同 |\n\n---\n\n## 弹幕/群众对话\n\n三大核心作用：剧情推进（透露主角不知道的信息）、增加期待感（悬念、猜测）、情绪渲染（群众震惊/激动/愤怒传染读者）。锦上添花，不代替主线。\n\n### 设计过的弹幕 vs 没设计的\n\n- 没设计：只有\"卧槽好厉害\"，单调、浪费\n- 设计过：普通人震惊 → 专业人士分析 → 特殊身份者反应 → 情感升华\n\n### 操作要点\n\n- 不同人格化语气，不能每条都一个味\n- 短小精悍，每条不超过一句话核心信息\n- 善用递进：从最初震惊到逐渐认识全貌\n- 可出现\"反转\"角色：看似路人一句话改变所有人认知\n- 不用每章都写，关键爽点/燃点/泪点前后集中使用\n\n---\n\n## 节奏控制\n\n### 大量对话保持节奏\n\n- 不要删掉表现人物性格的语气助词来\"精简\"\n- 对话段落间穿插动作描写、环境变化、心理活动调节节奏\n- 紧张段落对话短促，舒缓段落可以长一些\n- 关键信息放对话开头或结尾，中间用于拉扯情绪\n\n### 动作和表情处理\n\n- 刻意给每句对话配表情/动作会让行文机械\n- 动作和表情在关键转折处使用效果最好，不需要每句都配\n- 语气平淡场景（喝茶、散步）用微小动作和沉默体现氛围\n\n### 对话的呼吸感\n\n- 连续多轮对话后需要\"换气\"，插入环境描写或角色心理\n- 适当停顿（动作描写、换行、短句）比连续输出更有张力\n- \"你确定？\"比长篇解释更有压迫感\n\n---\n\n## 篇幅控制\n\n### 对话过多时\n\n- 读者已知信息的对话用叙事一句话概括：\"爱丽丝向安娜讲述了来城里的原因，安娜听后直皱眉头\"\n- 能用突发状况替代的对话段落直接替换\n- 语气词删掉后干巴巴 = 对话本身缺乏信息量，需重写\n\n### 对话过少时\n\n- 能用其他人物对话讲出来的东西，不要让主角旁白平铺直叙\n- 引入配角参与冲突和对话，但新人物必须安排主线戏份\n\n---\n\n## 以梗填充对话\n\n### 梗式 vs 普通\n\n- 普通：\"兄弟别灰心，你一步步走到今天我是看着你过来的，这点挫折对于你来说算什么事儿？振作起来！\"\n- 梗式：\"兄弟别灰心，我相信你总有人头落地，落地人头，头落地上……卧槽那句话怎么说的来着？兄弟你懂我意思是吧……\"\n- 梗式用\"说不出来但意思到了\"的状态制造趣味\n\n### 操作\n\n- 在对话中融入梗或骚话，有效提升整体趣味性\n- 特别是主角或重要配角的突出对话，适合用梗强化记忆点\n- 可用某个梗作为高潮点，整段剧情围绕达成这个梗来设计\n- **场合例外（声线让位）**：高压/生死/悲痛/严肃 beat 里，搞笑担当与轻快配角的玩笑、口头梗、插科打诨一律收敛——声线让位于当前情绪基调，用短、冷、带情绪重量的反应替代；梗只在安全或喘息 beat 放。自检：这句玩笑放进当前基调会不会让读者出戏？会就删/改\n\n---\n\n## 质量检查\n\n### 三大自查项（中一条以上需改进）\n\n- [ ] 是否存在大量信息都必须用对话来展示\n- [ ] 对话是否是问答式的一问一答\n- [ ] 是否习惯依赖对话来推动剧情或人物变化\n\n### 核心指令检查\n\n- [ ] 权力博弈：掌控者对话 <= 10 字 / 被压制方 >= 20 字，是否有明确的压制/反转/心死模式\n- [ ] 潜台词与议程：每个角色进入对话时有自己的议程，真实动机不在台词中\n- [ ] 人物差异化：遮住角色名后能否区分是谁在说话（7维差异化）\n- [ ] 弹幕递进：普通 → 专业 → 特殊身份，是否有层次感\n- [ ] 对话推动剧情：每段对话结束时，剧情是否往前推了一步\n- [ ] 篇幅控制：单次对话不超过全节 40%，信息密度是否足够\n\n### 检验对话质量\n\n- 对话自然度检查：逐句检查对话是否像自然口语交流，而非书面化的问答稿\n- 对话结尾能否预示接下来的节奏变化\n\nFile v1.1.27:references/plot-core-methods.md\n\n# 剧情核心方法 — 操作手册\n\n> 小纲设计、高潮构建、卡文对策、循环设计、连续性追踪等剧情创作的核心方法。\n> 遇到问题先查路由表，找到对应方法再操作。\n\n---\n\n## 决策路由表\n\n| 你在做什么 | 用什么方法 | 跳转到 |\n|-----------|-----------|--------|\n| 建小纲/细纲 | 小纲四步法 | [小纲四步法](#小纲四步法) |\n| 设计高潮 | 高潮构建公式 + 逆推法 | [高潮逆推法与AB粗纲](#高潮逆推法与ab粗纲) → [高潮构建公式](#高潮构建公式) |\n| 卡文了 | 卡文对策 + 循环设计 | [卡文对策与剧情循环设计](#卡文对策与剧情循环设计) |\n| 管理连续性 | 连续性追踪 + 节奏管理 | [连续性追踪与节奏管理](#连续性追踪与节奏管理) |\n| 设计过渡衔接 | 剧情过渡 + 场景转换技巧 | [剧情过渡与衔接](#剧情过渡与衔接) → [场景转换技巧](#场景转换技巧) |\n| 开书/设计噱头 | 噱头分类与开篇流程 | [噱头分类与开篇流程](#噱头分类与开篇流程) |\n| 拉长剧情 | 设门槛 | [设门槛——拉长剧情的核心技巧](#设门槛拉长剧情的核心技巧) |\n| 管理期待感 | 大剧情拉期待法 | [大剧情拉期待法](#大剧情拉期待法) |\n| 写日常文 | 日常文大纲框架法 | [日常文大纲框架法](#日常文大纲框架法) |\n| 判定是否自嗨 | 自嗨判定法 | [自嗨判定法](#自嗨判定法) |\n\n---\n\n## 小纲四步法\n\n细纲与正文比例控制在 **1:2.5 ~ 1:3**。\n\n按以下四步操作：\n\n1. **分段判断** — 把大纲按剧情节点分段\n2. **标注目的和效果** — 每段标注，不展开情节\n3. **标注详写/略写** — 明确哪些段展开、哪些段带过\n4. **快速定位** — 让后续写作能快速定位本段要交付的目的和效果\n\n记住：细纲只关注目的和效果，不展开情节。\n\n---\n\n## 高潮逆推法与AB粗纲\n\n### 核心思路\n\n从高潮反推前面需要铺垫的人物和情节，再用AB交替法填充。\n\n### AB粗纲法\n\n| 标记 | 含义 | 操作 |\n|------|------|------|\n| A | 压情绪/铺垫/伏笔 | 铺设困难、对手强势、悬念埋线 |\n| B | 抬情绪/擦边/小收获 | 小反转、小进步、读者爽一下 |\n\n操作流程：确定高潮 → 反推所需铺垫 → ABABAB排列 → 写作时只关注当前AB段。\n\n适用场景：节奏快、有明确高潮节点的剧情。\n\n---\n\n## 高潮构建公式\n\n### 五步公式\n\n按顺序执行：**蓄能 → 假胜 → 崩解 → 交叉死磕 → 悬置收尾**\n\n1. **蓄能**：牺牲+焦灼打底，让观众从\"看客\"变\"参与者\"\n2. **假胜**：先给希望再击碎（情绪落差 = 反转冲击力）\n3. **崩解**：所有伏笔一次引爆 + 推入单人绝境（帮手全失）\n4. **交叉死磕**：对抗线+绝境线来回切换（每切一次紧张感+1）\n5. **悬置收尾**：余劲不散，胜负不立刻揭晓\n\n关键操作：假胜是常用高潮技法。适合强反转、强压迫或大高潮；低压力章节、纯奖励章、日常/关系回收章可不用。没有假胜时，需用别的方式提供情绪落差或明确兑现。\n\n---\n\n## 噱头分类与开篇流程\n\n### 三种噱头类型\n\n| 噱头类型 | 特点 | 写法要点 |\n|----------|------|----------|\n| 事件噱头 | 集中在开篇，约5章 | 一上来就进入事件，不铺垫穿越/金手指 |\n| 金手指噱头 | 分布全文，前期多后期少 | 先写主角和困境，再引出金手指 |\n| 人设噱头 | 人设直接影响剧情构建 | 只有当人设本身能持续制造戏剧性时使用 |\n\n规则：事件写法和金手指写法不能混用。\n\n### 两种标准开篇流程\n\n**事件开篇**：事件切入（5章）→ 嫁接主线 → 拆分目标 → 阶段性爽点循环\n\n**主线开篇**：描写主角现状 → 营造代入感 → 描写社会环境 → 设立主角目标 → 拆分目标（设门槛）→ 绑定金手指 → 获得第一次提升 → 情绪拉扯2-3次 → 完成 → 引出下一个目标\n\n### 噱头吸量策略\n\n| 策略 | 做法 |\n|------|------|\n| 噱头延伸型 | 以开头噱头为核心，后续找类似噱头继续构建 |\n| 噱头引流+常规型 | 开头噱头只负责吸量，后续走常规题材内容 |\n\n开头噱头的功能是建立点击和追读承诺。目的达到后必须嫁接主线。\n\n开书前评估：噱头能不能延伸出后续更多字数？不能延伸就用\"噱头引流+常规\"策略。\n\n---\n\n## 主线的正确定义\n\n**主线不等于升级**。主线是一件事，升级是主角达成目标的行动。\n\n| 概念 | 定义 | 示例 |\n|------|------|------|\n| 目标（主线） | 主角要完成的一件事 | 斗破苍穹：上云岚宗复仇 |\n| 行动 | 主角为达成目标做的事 | 努力修炼、不断提升实力 |\n\n检查主线是否符合以下特征：\n- 主线是一件事，不是一个元素\n- 主线完成后，要么通过铺垫开启第二条主线，要么完结\n- 锚点错误会导致后续所有剧情偏差\n\n---\n\n## 卡文对策与剧情循环设计\n\n### 核心公式\n\n题材 + 金手指 + 主角身份 = 循环模式。三要素必须统一。\n\n### 6种经典循环模式\n\n| 模式 | 循环机制 | 循环燃料 |\n|------|---------|---------|\n| 案件串循环 | 案件→解谜→部分真相→更大谜团→新案件 | 信息差+推理 |\n| 扮猪吃虎循环 | 默默发育→挑衅→碾压→震惊→继续发育 | 读者-角色信息差 |\n| 资源积累循环 | 资源→技能→实力→新地图→新资源 | 螺旋上升 |\n| 戏剧性反转循环 | 亏钱→反转赚更多→拿更多钱去亏→又赚 | 不依赖数值膨胀 |\n| 组织枢纽循环 | 各自冒险→信息汇聚→衍生新剧情 | 信息交换+多线 |\n| 公路片循环 | 走一段路→遇一个人→又走→又遇 | 人物塑造力 |\n\n### 地图四势力框架\n\n新手村（开局首张地图）必须包含四种势力形成资源闭环——这是全量框架；后续换地图可简化（见下「换地图的地图详略设计」），但变现/资源闭环渠道别丢：\n\n1. **学校/武馆** — 学技能、提升实力\n2. **商贩/药行** — 卖出收获、获取资源\n3. **山贼/敌人** — 展现学习成果的靶子\n4. **官府/管理机构** — 更高的上升通道\n\n### 地位-环境同步原则\n\n地位升高必须环境危险度升高。两者不同步 = 读者觉得无聊。\n\n### 换地图三策略\n\n1. **新旧地图联动**（新势力是旧势力的上级）\n2. **带人走**（把重要人物带到新地图）\n3. **提前铺垫吸引力**（让读者主动盼着去）\n\n### 特殊类型处理\n\n- **天才流**：大幅增加等级数量，防止数值几十章就崩\n- **无敌流**：循环核心转为信息差（来一个秒一个，每次刷新认知）\n\n---\n\n## 日常文大纲框架法\n\n### 创作路径\n\n按以下步骤操作：\n\n1. 从阅读中发现有趣的设定/关系/背景\n2. 围绕灵感确定事业线+感情线\n3. 选择节奏最快、情绪最足的节点切入\n4. 对每个阶段拆分信息差+人际关系+情绪\n5. 按时间顺序排列事件\n6. 写作前勾勒章纲\n\n### 大纲推演法\n\n以\"实现房东租客关系\"为例：\n\n1. 目标：实现男女主房东租客关系\n2. 拆分：主角家中要有空房，距离高中近\n3. 推演：有空房=家庭条件好 → 最好是贷款买，有压力\n4. 逆转理由：父母上世投资失败 → 这世主角逆转 → 买学区房\n\n### 大纲节点格式\n\n```\n事件名称：\n信息差：1. 主角知道什么/配角不知道什么 2. 读者视角 vs 角色视角\n人际关系与情绪：1. 主角情绪 2. 女主/配角反应 3. 负面情绪提供者\n```\n\n### 关键原则\n\n- 大纲服务正文生成，不是枷锁\n- 日常文不要有太多猛增好感的大事件，用小事件串联缓慢增长\n- 事业线要和女主自身及家庭串联，达到日常和事业互相糅合\n\n---\n\n## 大剧情拉期待法\n\n### 自上而下的创作逻辑\n\n按顺序执行：\n\n1. **明确核心和目的** — 先确定这段大剧情的爽点\n2. **确定篇幅目标**\n3. **设计分阶段剧情** — 围绕爽点设计若干小剧情，每个是下一个的铺垫\n4. **技巧杂糅填充**\n\n### 案例演示：参加好歌曲演唱青花瓷\n\n**核心爽点**：主角登台演唱青花瓷，引起震撼\n\n分阶段设计：\n1. 收邀请+公园哼唱《送别》→ 震惊评委（前置暗示）\n2. 彩排现场挑衅 → 制造压力\n3. 节目前夜给邓紫棋写《泡沫》→ 叠加实力展示\n4. 现场PK → 设备故障（加压）→ 演唱青花瓷 → 震惊\n5. 评委扣分 → 分数持平（反转压制）\n6. 歌手演唱主角作品 → 曝光主角是创作者（二级震惊）\n7. 设备故障说明 → 得分逆袭（反转翻倍）\n8. 评委要求唱《送别》→ 持续拉期待\n\n要点：先有大爽点，再分阶段去抵达；从局部看节奏快，从整体看推进慢（只讲了一件事）。\n\n---\n\n## 连续性追踪与节奏管理\n\n### 热度状态\n\n| 状态 | 定义 |\n|------|------|\n| hot | 当前驱动冲突的核心元素 |\n| warm | 近期活跃的元素 |\n| cold | 超过安全线未触及，有被遗忘风险 |\n| archived | 已完结/有意关闭的元素 |\n\n### 有效触碰判定\n\n以下算有效触碰：直接推进该线索、施加压力、改变关系状态、产生实际后果、交代合理的休眠原因。\n\n不算有效触碰：纯粹提个名字、空头回调、随机提及。\n\n### 回顾阈值\n\n| 元素类型 | 触及间隔 |\n|----------|----------|\n| 核心角色 | 3-5 章 |\n| 主要支线 | 4-6 章 |\n| 活跃伏笔 | 2 次错过机会 |\n| 不稳定关系 | 2 次出场 |\n\n### 每章必做自检\n\n1. 当前 hot 的元素是什么？\n2. 有没有 cold 了但该 warm 的？\n3. 哪些可以合理保持休眠？\n4. 哪条线索的回归能加深压力？\n\n### 失败信号（出现就要修正）\n\n- 读者问\"那个谁去哪了？\"\n- 重要的线索到结尾才突然冒出来\n- cold 的铺垫突然变成 hot 的回报（没有预热）\n\n### 核心冲突的节奏保护规则\n\n1. 非大结局章节通常不解决全书核心冲突；若阶段核心冲突收束，要同步开启下一期待\n2. 章末约200字宜保留悬念、决定、发现、余韵或阶段目标；低压章节不强求硬悬念\n3. 局部胜利可伴随新的代价、风险或下一任务；纯奖励/低压回收章可只提供明确收益和后续期待\n\n### 事件后的冷却章节数\n\n| 事件类型 | 冷却（章） |\n|----------|-----------|\n| conflict_thrill（大冲突/打斗） | 2 |\n| bond_deepening（关系深化） | 1 |\n| faction_building（建立势力） | 2 |\n| world_painting（世界观展开） | 3 |\n| tension_escalation（压力升级） | 2 |\n\n规则：冷却期内该类型不能作为主beat；conflict_thrill最多连续2章；每5章必须包含bond_deepening或world_painting。\n\n### 过渡章节管理\n\n- 单元故事结束前先把下一个目标拉出来\n- 过渡章节必须维持至少一条活跃的期待线\n\n### 换地图期待感延续\n\n| 延续方式 | 做法 |\n|----------|------|\n| 复仇线 | 未完成的目标跨地图持续 |\n| 旧日关系线 | 老角色在新地图出现 |\n| 信息差 | 某方以为某事，实际不是 |\n| 提前铺垫 | 换地图前让新地图角色/传说与主角接触 |\n\n### 金手指的四阶段演进（基础→发展→成熟→升华）\n\n| 阶段 | 操作要点 |\n|------|---------|\n| 基础 | 明确核心作用，建立读者认知 |\n| 发展 | 增加新的使用方式，核心作用不变 |\n| 成熟 | 与世界观深度结合，可与其他系统联动 |\n| 升华 | 作用对象从个人扩到世界/天道层级，需足够伏笔支撑（签到系统：签到得物→万物可签→对人/地脉签到→签到本身成世界规则、人人信仰） |\n\n规则：金手指重心可转移但必须有足够伏笔；可部分淡化不能完全抛弃；呈现力度应随阶段递增。\n\n### 矛盾网设计\n\n- 同一时刻保持2-3条矛盾线同时运行\n- 矛盾线之间要有关联（因果、利益冲突、信息差）\n- 每次解决一个矛盾，必须激活或加深另一个矛盾\n\n| 层级 | 范围 | 说明 |\n|------|------|------|\n| 章级 | 2-3章 | 小冲突，服务于当前单元 |\n| 卷级 | 一卷 | 本卷核心矛盾，卷末解决 |\n| 书级 | 全书 | 终极矛盾，大结局解决 |\n\n### \"两长一短\"期待法则\n\n- 1个短期期待：当前单元的明确目标（只能有一个）\n- 1-2个长期期待：远期目标预告/悬念/组织/人物\n\n### 持续拉期待的方法\n\n1. 在\"基底期待\"上添加细节，注入新的具体化需求缺口\n2. 设置多个核心梗交替运行（装逼线A + 解密线B + 感情线C）\n3. 设计世界观层面的\"秘密\"和\"阴谋\"\n\n### 升级差异化管理\n\n| 维度 | 说明 |\n|------|------|\n| 能力差异化 | 每个等级有质变性的新能力（炼气只能御剑→筑基能御物攻击） |\n| 待遇差异化 | 不同等级获得不同的社会待遇（练气当杂役→筑基分独立洞府） |\n| 人际关系网差异化 | 不同等级面对不同层次的人际关系（练气只接触师兄弟→筑基有长老正眼相待） |\n\n如果升级前后在三个维度上没有明显差异，读者就不会有升级快感。\n\n### 单元故事嵌套\n\n- 在第一个单元故事高潮前，插入第二个故事的期待线\n- 完成当前目标前，提前给出下一个目标的线索伏笔\n- 完成当前目标后，迅速给出反转或变故，营造新期待\n\n### 长线节奏设计\n\n- 一卷 = 一个完整的中套娃，有自己的起承转合\n- 每卷开头是代入期（5-10章），中间是发展期，结尾是高潮+收束\n- 信息密度：高密度（情绪强烈、推进快）与低密度（铺垫积蓄）交替，不能一直高或一直低\n- 每个低密度章节至少埋一个让读者想知道后续的点\n\n### 期待感管理\n\n三层期待同时运行：\n- 短期期待（下一章会发生什么）\n- 中期期待（这个剧情单元会怎么收）\n- 长期期待（主角最终能不能达成目标）\n\n---\n\n## 剧情过渡与衔接\n\n### 从一个剧情点到下一个\n\n核心问题：主角实力提升了，但下一步干什么不清楚。解决方案：每次提升后立即引入新的挑战或目标。\n\n### 剧情嵌套（套娃结构）\n\n- 大套娃：整本书的主线\n- 中套娃：每个卷/阶段的阶段性目标\n- 小套娃：每个剧情单元的即时目标\n- 三层套娃同时运行，读者始终有事可看\n\n### 场景过渡\n\n- 过渡场景该跳过就跳过，不拖泥带水\n- 过渡不是填充，没有信息量就删掉\n\n### 情绪衔接\n\n- 上一场景的情绪要自然过渡到下一场景\n- 不能前一个场景还在热血，下一个场景突然平淡\n\n### 信息差衔接\n\n- 前一个场景埋下的信息差在后一个场景回收\n- 读者带着疑问进入下一场景，衔接自然有效\n\n---\n\n## 设门槛——拉长剧情的核心技巧\n\n### 门槛的本质\n\n门槛不宜只放一个敌人挡路；它应形成系统性的条件设置：主角要达成目标，必须满足一系列条件。\n\n### 设门槛的具体方法\n\n| 门槛类型 | 示例 |\n|----------|------|\n| 资源型 | 系统升级需要1000灵石，主角身上没有 |\n| 成就型 | 考顶级院校需要气血值达标+独自灭杀XX级怪物+比赛前五名 |\n| 多条件型 | 把一个大目标拆分成多个阶段小目标 |\n| 动态门槛 | 主角资源超标时提高门槛 |\n| 收集型 | 突破境界需要多件宝物 |\n\n### 规则\n\n- 门槛必须围绕核心卖点设计，脱离金手指和脑洞的门槛是无效剧情\n- 门槛要分批提出，不要一次全甩给读者\n- 每跨越一个门槛就立刻设立下一个\n\n### 循环从设定中诞生\n\n- 核心卖点通过\"设定\"体现，设定确定后自然产生反馈机制\n- 设定多一条，循环元素就多一层，可写的内容就越多\n- 写着写着把设定写丢了 = 把卖点写丢了\n\n---\n\n## 场景转换技巧\n\n- 过渡场景没有信息量就直接跳过\n- 前一个场景留下悬念，后一个场景回应悬念\n- 前一个场景热血收尾，下一个场景开头要有余韵\n- 切换视角时在悬念点切出，不要在平淡处切出\n- 每条线在切换前都要留下一个\"钩子\"\n- 多条线的读者关注度不同，主线占比要最大\n\n### 换地图的深层设计\n\n- 新地图 = 新环境 + 新角色 + 新规则 + 新目标 + 新冲突\n- 换地图前：旧地图的核心冲突至少阶段性解决\n- 换地图后：前5章必须快速建立新的代入感和期待感\n\n避免以下操作：旧角色一刀切全部抛弃、新设定一次性全部倒出、新地图与旧地图毫无关联。保留至少一条贯穿主线。\n\n每换一次地图，循环要升级：更大的规模、更高的门槛、更强的对手。\n\n### 换地图的地图详略设计\n\n- 换地图（非新手村）按三种势力简化铺：训练场（武馆/学校）、地头蛇（豪绅/地方势力）、破坏者（山贼/麻匪）——这是「地图四势力框架」的精简版，仍要保留变现/资源闭环渠道（商贩/药行），别只剩打斗\n- 日常路线扩展关系网：上学/归还装备/逛集市作为新故事弧线的桥梁\n\n---\n\n## 悬念与伏笔技巧\n\n- 小剧情伏笔：先确定结局再倒推线索，从终点往回铺确保逻辑闭合\n- 整本书伏笔：大纲阶段确定关键情节，书中不断埋设细节呼应，长线伏笔要记录避免遗忘\n- 谜语人vs伏笔：谜语人是故意不说明（容易惹烦）；伏笔是巧妙融入剧情、自然不刻意。判定：信息延迟超过 3 章且中间无任何推进=谜语人（删或提前给）；主角随口说怕水、后期落水危机才回收=伏笔\n- 烧脑剧情：视角只跟主角走，不写反派视角，避免破坏悬念张力\n\n---\n\n## 信息团概念\n\n- 信息团 = 一段剧情要表达的核心信息单元\n- 每个信息团必须能一句话概括\"这段在讲什么\"\n- 信息团之间要有逻辑递进关系\n- 节奏快 = 信息团密集；节奏慢 = 信息团稀疏；水章节 = 信息团为零或与主线无关\n- 例：一章里「主角识破骗局」是 1 个信息团，「顺带交代反派背景」是第 2 个——两个无关就是水章，砍掉第二个或让它服务第一个\n\n---\n\n## 自嗨判定法\n\n### 三个自检问题（必须全部回答清楚）\n\n1. 我这书写给谁看？（至少包括目标读者的年龄段、职业、性别、常用平台、人生处境、普遍渴望）\n2. 我的目标读者群体在看网文时希望看到什么内容？\n3. 我的这本书有哪些内容是目标读者群体想看的？\n\n判定标准：三问有一问答不好 = 自嗨。立刻停下修正。\n\n### 纠正方法\n\n- 分析同类书的读者评论，提取高频正面关键词\n- 对比同类书中高互动与低互动段落的差异特征\n- 用同类书的目标读者画像反向校验本书的情节选择\n\n---\n\n## 质量检查清单\n\n每次完成一段剧情设计或一卷大纲后，逐项检查：\n\n### 基础完整性\n- [ ] 主线是否明确为\"一件事\"（避免写成元素罗列或升级条）\n- [ ] 循环模式是否与题材+金手指+主角身份统一\n- [ ] 三层套娃（大/中/小）是否同时运行\n\n### 节奏与期待\n- [ ] 三层期待（短/中/长）是否同时在线\n- [ ] 章末约200字是否保留悬念、决定、发现、余韵或阶段目标\n- [ ] 信息密度是否有高低交替（不能一直高或一直低）\n- [ ] 冷却期规则是否遵守\n\n### 连续性\n- [ ] hot/warm/cold 状态是否正常（无该 warm 却 cold 的元素）\n- [ ] 核心角色 3-5 章、主要支线 4-6 章内是否有有效触碰\n- [ ] 换地图/换阶段后是否保留至少一条贯穿主线\n\n### 高潮与过渡\n- [ ] 高潮是否需要假胜（先给希望再击碎）；若不用，是否有其他情绪落差/兑现方式\n- [ ] 胜利是否需要代价/风险/下一任务；若是纯奖励章，收益是否足够明确\n- [ ] 过渡场景是否删掉了无信息量的部分\n- [ ] 场景切换是否在悬念点切出\n\n### 避坑检查\n- [ ] 门槛是否围绕核心卖点设计（非无效剧情）\n- [ ] 金手指是否按四阶段演进（未跳跃、未抛弃）\n- [ ] 自嗨三问是否全部能回答清楚\n- [ ] 信息团是否每段都能一句话概括\"在讲什么\"\n\nFile v1.1.27:references/quality-rubric.md\n\n# 通用网文内容审查 Rubric\n\n> 用途：当用户未指定番茄、起点、知乎盐言等目标平台时，作为 `/story-review` 的默认小说内容评分标准。它评估的是**故事文本质量**，不是 skill/plugin 实现质量。\n\n## 评分方法\n\n每项按 PASS / WARN / FAIL 标记，并把 FAIL/WARN 转成统一 Findings Schema：\n- 影响主线、角色动机、世界规则或读者信任 → S1\n- 明显影响留存、节奏、章节效果或人物可信度 → S2\n- 局部质量、格式、措辞、轻微节奏问题 → S3\n- 风格建议或可选增强 → S4\n\n## 核心维度\n\n| 维度 | PASS | WARN | FAIL |\n|---|---|---|---|\n| 核心卖点 | 章节围绕明确卖点推进，读者知道为什么继续看 | 卖点存在但表达弱或被支线稀释 | 看不出本章服务什么卖点或主线 |\n| 冲突推进 | 本章有明确冲突、阻碍、选择或代价 | 冲突较轻，推进感不足 | 主要是解释/闲聊/总结，无实际推进 |\n| 任务卡点 | 角色办事被卡住，并卡出信息、关系、代价、选择或伏笔变化 | 有卡点但变化偏弱，可压缩 | 卡点只是流程细节，删掉不影响故事 |\n| 情绪曲线 | 有铺垫、升温、释放或反转 | 情绪有变化但节点不清 | 情绪平直或突兀转向 |\n| 钩子与期待 | 开头/结尾至少一处建立期待 | 钩子弱但仍有后续问题 | 没有悬念、目标或未完成期待 |\n| 开头新鲜度（仅开篇/前 3 章） | 开局有具体人物/处境切口，不是同题材默认套路 | 有钩子但开局形状与同题材撞车 | 开局是题材默认模板，可整体换到任意同类书（同质化） |\n| 角色动机 | 行为符合目标、性格、处境和关系压力 | 局部行为缺少铺垫 | 角色为推动剧情而失真 |\n| 对话质量 | 对话有潜台词、信息控制和角色差异 | 有信息堆叠或声音略同质 | 对话像说明书，人人同腔 |\n| 设定一致性 | 不违背既有规则、时间线和角色属性 | 有轻微模糊点需补证据 | 与已写设定或前文事实冲突 |\n| 文字自然度 | 具体、可感、动作承载信息 | 偶有套话或抽象总结 | AI 腔、陈词滥调、总结体明显 |\n| 句长节奏 | 叙述默认是逗号长句，短句只作偶尔的孤立重拍、用完回到逗号长句 | 局部碎句或电报体，或偶发机械长短交替 | 逗号之间连着都是 ≤5 字、通篇超短句像提纲，或审改把逗号长句拆碎 |\n| 标点节奏 | 标点跟语气、人物声线和情绪功能匹配 | 局部标点单调或略有堆砌 | 通篇句号化、随机堆砌问号/感叹号，或用 `……`/`——` 硬造停顿 |\n| 具体字数表达校验 | 「这五个字」「短短四字」类表达的字数经核对属实，且有叙事必要 | 字数属实但换成「那几个字」更自然 | 字数与实际不符，或无法确认统计口径 |\n| 格式可读性 | 段落按戏剧单元/镜头自然断开，对话独立，无多余空行，主语节奏自然 | 局部段落偏长/偏碎或主语重复略多 | 大段堆叠、机械切段、对话/叙述难读、主语过密 |\n| 剧情循环 | 目标→阻碍→行动→代价/反馈→新期待闭环清晰 | 有循环但缺一环或反馈偏弱 | 无目标、无阻碍或无反馈，读者不知道局势如何变化 |\n| 高潮构建 | 蓄能→假胜→崩解→反转/兑现有层次 | 有爆点但蓄能或兑现不足 | 平铺直给、无代价、无兑现或情绪落空 |\n| 关系进展 | 互动尺度匹配关系阶段，越界有铺垫 | 局部推进略快但可补证据 | 突然亲密/信任/敌对，角色关系跳变 |\n| 伏笔状态 | 伏笔埋设、状态和回收路径可追踪 | 伏笔偏密/偏疏但不影响理解 | 伏笔与设定冲突、断线或造成主线理解混乱 |\n\n## 黄金三问\n\n1. **读者为什么翻下一页？** 如果答不出，至少 S2。\n2. **本章改变了什么？** 情节、关系、信息、情绪至少改变一项；否则至少 S2。\n3. **哪个证据支持你的判断？** 没有原文证据的 finding 不输出，改为“证据不足”。\n\n## 发布建议门槛\n\n| 综合情况 | Verdict |\n|---|---|\n| 无 S1/S2，S3 可快速处理 | APPROVE |\n| 有 S2，或 S3 数量多影响阅读 | CONCERNS |\n| 有 S1，或核心卖点/动机/规则崩坏 | REJECT |\n\n## 输出要求\n\n- 所有问题必须包含 severity、category、location、evidence、issue、fix。\n- 先列 S1/S2，再列 S3/S4。\n- 不要只给泛泛评价；每条 finding 必须能指导下一轮修改。\n- `consistency` / `factual` 类 finding 的 fix 只写事实统一方向，不写文学创作建议。\n\nArchive v1.1.26: 29 files, 195084 bytes\n\nFiles: references/agent-prompts.md (13971b), references/anti-ai-writing.md (37187b), references/author-memory-maintenance.md (8766b), references/author-memory.md (11531b), references/banned-words.md (10424b), references/batch-review.md (2343b), references/character-relations.md (17831b), references/dialogue-mastery.md (11764b), references/plot-core-methods.md (20291b), references/quality-rubric.md (4637b), references/review-quality.md (13008b), references/review-tracking.md (2037b), references/rubrics/fanqie.md (891b), references/rubrics/qidian.md (987b), references/rubrics/zhihu.md (1165b), references/solo.md (3149b), references/style-resolution.md (4016b), references/tracking-initialization.md (1355b), references/tracking-transaction.md (15296b), scripts/author_memory_commit.py (79758b), scripts/check-ai-patterns.js (75274b), scripts/check-degeneration.js (15104b), scripts/normalize-punctuation.js (13480b), scripts/style-whitelist.js (1168b), scripts/tracking_commit.py (83785b), scripts/wordcount_core.py (18338b), skill-card.md (2381b), SKILL.md (21760b), _meta.json (132b)\n\nFile v1.1.26:SKILL.md\n\n---\nname: story-review\nversion: 1.1.1\ndescription: \"多视角对抗式审查。full/lean 模式在已部署 reviewer agents 时并行 spawn；缺失/异常 agents 或 spawn 失败时自动降级 solo，参考文件不可读时使用内置 rubric fallback。触发方式：/story-review、/审查、「审查一下」「帮我审一下」。\"\nmetadata: {\"openclaw\":{\"source\":\"https://github.com/zenstory-ai/oh-story-claudecode\"}}\n---\n# story-review：多视角对抗式审查\n\n> Spawn 版本提示（不阻断 spawn）：先读取项目根 `.story-deployed` 的 `agents_version`。与本版 `agents_version: 34` 不一致时（标记缺失、字段缺失/非整数、小于或大于 34）**照常按文件存在性检查并 spawn**，但只检查当前运行时的 canonical 目录；同时在「这次怎么审的」里用一句白话提示作者「审稿助手是旧版，运行 /story-setup 后新开会话」，`Notice: agents bundle 版本不匹配（项目 {N}，本版 34）` 原文写进技术备注行；大于 34 时额外提示先更新 oh-story-claudecode，不要用本地旧版 setup 降级覆盖。只有 agent 文件缺失、或运行时不暴露 custom agent 时才降级 solo/direct，技术备注写 `Fallback: ... -> solo`。\n\n你是审查协调器。你的职责是找出小说文本中的结构、角色、文字、设定问题，并给出可执行修改建议。\n\n**执行铁律：审查是找问题，不是验证正确性。**\n\n**文风裁决**：正文写作、改写或审稿前先读 [references/style-resolution.md](references/style-resolution.md)，加载本书文风并形成 `style_resolution`；无作者记忆也执行。当前请求、本书文风和 active 偏好按维度覆盖通用 references；同一裁决交给后续执行者。\n\n## 作者习惯边界\n\n若作者记忆 state 已存在，审查前用 `scripts/author_memory_commit.py query --workspace {工作区} --book-root {书目录} --kind delivery --kind interaction --kind prose_style [--genre {题材}] [--workflow 审稿]` 获取本次相关 active 条目（`--workspace`、`--kind` 必传；不传 `--book-root` 就拿不到本书级偏好；`--genre` 填本书题材类型；总输出 ≤2KB）。它们只能帮助解释意图和组织报告，不能降低 rubric 严重度、把事实冲突判为无问题或跳过平台门禁；当前请求仍优先。完整规则见 [references/author-memory.md](references/author-memory.md)。\n\n用户对报告格式或协作方式作出稳定声明时，在本轮审查完成后用 `record` 记录，并按 author-memory.md「回执怎么告诉作者」转告；只记作者明确说的，一次性要求不记录，不从反复修改推断。审查发现、工具告警和助手建议本身绝不自动学习。\n\n---\n\n## Review Mode 选择\n\n- `/story-review` 或 `/story-review full` → 优先 spawn 全部 4 个 Agent；如果当前已经在子代理内，核心 Agent 未部署/异常，或 spawn 失败，自动降级为 solo。\n- `/story-review lean` → 优先 spawn `story-architect` + `consistency-checker`；如果当前已经在子代理内，任一所需 Agent 未部署/异常，或 spawn 失败，自动降级为 solo。\n- `/story-review solo` → 不 spawn Agent，由当前会话执行基础审查。\n- 未指定 → 默认 full，并在报告开头用一句话说明这次实际是怎么审的。\n\n---\n\n## Phase 0：预检与降级（必须先执行）\n\n1. **确定请求模式**：解析用户输入中的 `full`、`lean`、`solo`；未指定时目标模式为 `full`。\n2. **确认是否允许 spawn**：如果当前已经在子代理/Agent 内执行，不再递归 spawn，直接降级为 `solo`。\n3. **识别 ZCode 能力边界**：如果当前运行于 ZCode 且项目使用 `.zcode/`，ZCode 3.3.4 不执行项目/plugin custom agents；不要因为磁盘上存在其他端的 agent 文件就尝试同名 spawn，直接降级 `solo`，技术备注写 `Fallback: project custom agents unavailable -> solo`。\n4. **检查核心 Agent 部署状态**（只检查当前运行时的 canonical 目录，不因其他端文件存在而误判）：\n   - Claude Code 检查 `.claude/agents/`，OpenCode 检查 `.opencode/agents/`，Codex 检查 `.codex/agents/`，Antigravity 检查 `.agents/agents/`\n    - full 必需 agent：`story-architect`、`character-designer`、`narrative-writer`、`consistency-checker`\n    - lean 必需 agent：`story-architect`、`consistency-checker`\n    - 对每个必需 Agent 文件：\n      - **Claude Code agent（`.claude/agents/`）**：读取 frontmatter，确认 `name:` 与 subagent_type 完全一致；frontmatter 缺失、不可解析或 name 不匹配时视为 malformed agent。\n      - **OpenCode agent（`.opencode/agents/`）**：文件名即 agent 名（OpenCode 不要求在 frontmatter 中写 `name:`），读取 frontmatter 确认 `mode: subagent` 和 `permissions:` 规则列表存在且可解析即可（2.x 用复数 `permissions:`，旧版单数 `permission:` 视为待重新部署）；frontmatter 缺失或不可解析视为 malformed。\n      - **Codex agent（`.codex/agents/`）**：文件名为 `{agent}.toml`，TOML 必须可解析，且包含 `name`、`description`、`developer_instructions`；`name` 必须与目标 agent 完全一致。\n      - **Antigravity agent（`.agents/agents/`）**：路径为 `.agents/agents/agent-name/agent.md`（`agent-name` 为目标 agent 名），frontmatter 必须可解析，且 `name` 与目标 agent 一致、`mainAgent: false`、`subagent: true`、`tools` 非空；缺失或不匹配视为 malformed。\n   - 如果目标模式所需任一文件缺失或 malformed，**不要尝试 spawn 缺失/异常 Agent**；自动降级为 `solo`，报告开头用一句话告诉作者「审稿助手缺失或损坏，这次由我一个人审；运行 `/story-setup` 后可多视角审」，降级原因 `missing agents -> solo` / `malformed agents -> solo` 与问题文件写进技术备注行的 Fallback、Files 两栏。\n5. **确认 Agent 工具可用**：Claude/OpenCode/Codex 需要当前运行时的子 Agent/Task 调用能力，Antigravity 需要 `invoke_subagent`；不可用时直接降级为 `solo`，技术备注写 `Fallback: agent tool unavailable -> solo`。\n6. **运行时失败降级**：如果任何 Agent spawn 返回失败、`subagent_type` / `agent` / `agent_type` / `TypeName` 不可用、frontmatter/TOML 运行时解析失败或子 Agent 无法启动，停止继续 spawn，改用 `solo` 重新审查，技术备注写 `Fallback: spawn failed -> solo` 与失败的 agent 名；不要把部分成功的 Agent 结果当成 full/lean 结论。\n7. **确定实际模式**：请求模式与实际模式都写进报告末尾的技术备注行。\n\n---\n\n## 审查基准与参考资料规则（必须遵守）\n\n`story-review` 的核心审查标准必须始终可用。参考文件是增强资料，不是运行前提。\n\n### 报告面向作者（必须遵守）\n\n报告写给作者：审了什么、哪里要改、为什么（用读者感受和故事后果说，附原文引用）、要作者拍板的事、下一步。reviewer 名、S1–S4、Gate、检测器类别名、脚本名、PASS/FAIL、文件字段名不进正文；位置写「第 N 章「引文」」或「第 N 章第 M 段」。优先级换成白话（小节标题照模板）：S1、S2 → **必须改**，S3 → **建议改**，S4 → **可以不改**。执行路径只写在报告最后一行，格式固定：\n\n```text\n技术备注：Mode {请求}→{实际} · Fallback {none | project custom agents unavailable -> solo | missing agents -> solo | malformed agents -> solo | agent tool unavailable -> solo | spawn failed -> solo | subagent recursion guard -> solo} · Rubric {fanqie | qidian | zhihu | generic} ({file | embedded})[ · Files {缺失或异常的 agent 文件}][ · Notice {版本不匹配原文}]\n```\n\n### 参考资料解析顺序\n\n可读取参考文件时，按以下顺序尝试，第一个命中即用：\n1. `{项目根}/.claude/skills/{规范路径}`（Claude Code 项目内安装）\n2. `{项目根}/.opencode/skills/{规范路径}`（OpenCode 项目内安装）\n3. `{项目根}/.codex/skills/{规范路径}`（Codex 项目内安装）\n4. `{项目根}/.zcode/skills/{规范路径}`（ZCode 项目内安装）\n5. `{项目根}/skills/{规范路径}`（OpenClaw / Reasonix / generic 部署，也是本仓库开发环境）\n6. `{项目根}/.agents/skills/{规范路径}`（Antigravity 项目内真实 skill root；Codex / Reasonix 也可能扫描此目录或其 symlink）\n7. 当前运行时加载本 skill 的目录，或其可访问的全局 skill 搜索路径中同名 `{skill-name}/...` 目录\n\n> 靠前几层不存在是正常的，不是部署损坏。`/story-setup` 会为 Antigravity 把 13 个 skill 真实复制到 `.agents/skills/`，为 ZCode 复制到 `.zcode/skills/`，并为 OpenClaw / Reasonix / generic 复制到 `skills/`。Codex 项目部署不复制 skill 本体，本 skill 由 Codex 从 skill root 加载，references 通常命中第 6 或第 7 层。不要手工把 `references/` 复制进 `.codex/skills/`——手工副本不受 story-setup 管理，升级后会静默变旧。\n\n规范路径如下；禁止只写裸文件名，禁止跨 skill 误读其他 skill 的 references：\n\n| 用途 | 规范路径 |\n|---|---|\n| 通用质量清单 | `story-review/references/review-quality.md` |\n| 通用内容评分 rubric | `story-review/references/quality-rubric.md` |\n| 去 AI 味方法 | `story-review/references/anti-ai-writing.md` |\n| 剧情循环/高潮公式 | `story-review/references/plot-core-methods.md` |\n| 角色关系/好感度 | `story-review/references/character-relations.md` |\n| 对话质量 | `story-review/references/dialogue-mastery.md` |\n| 审查禁用词 | `story-review/references/banned-words.md` |\n| 平台 rubric | `story-review/references/rubrics/{fanqie,qidian,zhihu}.md` |\n| 标点预检脚本 | `story-review/scripts/normalize-punctuation.js` |\n| AI句式预检脚本 | `story-review/scripts/check-ai-patterns.js` |\n| 作者习惯协议 | `story-review/references/author-memory.md` |\n| 作者习惯整理、超编与迁移 | `story-review/references/author-memory-maintenance.md` |\n| 作者习惯事务脚本 | `story-review/scripts/author_memory_commit.py` |\n\n### 内置审查基准包（路径不可读时必用）\n\n如果上述参考文件在当前项目中不可读，**不要把审查降级为无 rubric，也不要在报告里说“无法加载具体 rubric”后停止使用标准**。必须使用本节内置基准包，技术备注行的 Rubric 来源写 `embedded`。\n\n通用网文内容 rubric：\n- 核心卖点：本章是否围绕明确卖点推进；看不出卖点至少 S2。\n- 冲突推进：本章是否有阻碍、选择、代价或关系变化；只解释/闲聊/总结至少 S2。\n- 任务卡点：角色办事被卡住时，是否卡出信息、关系、代价、选择或伏笔变化；卡点只剩流程细节、删掉不影响故事至少 S3。\n- 情绪曲线：是否有铺垫、升温、释放或反转；情绪平直或突兀至少 S2/S3。\n- 钩子与期待：开头或结尾是否制造后续问题；没有悬念或未完成期待至少 S2。\n- 开头新鲜度（仅开篇/前 3 章）：开局有具体人物/处境切口，还是同题材默认套路（能整体换到任意同类书）？\"有钩子/非天气开场\"不豁免同质化；套路化开局即使有钩子也至少 S3，整体撞同题材模板 S2。\n- 角色动机：行为是否符合目标、性格、处境和关系压力；为剧情服务而失真是 S1/S2。\n- 对话质量：是否有潜台词、信息控制、角色差异；说明书式对话至少 S2。\n- 设定一致性：不违背已写规则、时间线、角色属性；明确事实冲突通常 S1。\n- 文字自然度：具体、可感、动作承载信息；AI 腔、陈词滥调、总结体按影响定 S2/S3。\n- 句长节奏：叙述默认是逗号长句（一句用逗号串起 2-4 件事再落句号）；碎句和电报体（逗号之间连着都是 ≤5 字、通篇超短句像提纲）与 AI 腔同级，按影响定 S3/S2，不因「短=网文节奏」放行。\n- 标点节奏：标点是否服务语气/人物声线；通篇句号化、随机堆砌问号/感叹号，或残留 `……`/`——` 硬造停顿，按影响定 S3/S2。\n- 具体字数表达校验：正文用“这五个字 / 短短四字 / 三个字一落 / 八个字砸下去”等具体字数表达评价台词、题字、信件、念头或弹幕时，必须能确认统计口径、机器核对结果和叙事必要；不能确保字数计算正确时，按文字自然度问题处理，建议改成“这句话一落”“那几个字”“话音落下”等非具体数字表达。\n- 格式可读性：段落短、对话独立、无多余空行；格式阻碍阅读按 S3，严重混乱按 S2。\n- 剧情循环：目标 → 阻碍 → 行动 → 代价/反馈 → 新期待；缺少目标/阻碍/反馈通常至少 S2。\n- 高潮构建：蓄能 → 假胜 → 崩解 → 反转/兑现；高潮直接平铺、无代价或无兑现通常 S2/S3。\n- 关系进展：互动尺度必须匹配当前关系阶段；越界亲密、突然信任、突然敌对都需要铺垫，否则按影响定 S1/S2。\n- 伏笔状态：伏笔状态需可追踪；伏笔密度只作为结构风险提示，除非直接造成理解混乱，否则不升级到 S2+。\n\nAI 味 / 禁用词 fallback 速查：\n- 高频套话：`命运的齿轮开始转动`、`心猛地一沉`、`眼神复杂`、`深刻变化`、`踏上新的旅程`。\n- 章末总结体：`这一切都说明...`、`他终于明白...`、`新的篇章开始了...`。\n- 信息倾倒：角色直接说“我要解释世界观/规则/关系变化”。\n- 论文体/万能结论：过度使用“然而、与此同时、不可否认、这意味着”。\n- 处理原则：有原文证据才输出 finding；给出可执行替换方向，不只评价“AI 味重”。修法方向不默认「拆短 / 删虚词 / 剥标点」：把正常的逗号长句拆成碎句，与 AI 腔同样是问题。\n\n平台 fallback 摘要：\n- 番茄：强开局、强冲突、高频爽点/情绪反馈、低理解门槛。\n- 起点：设定自洽、升级路径、长线期待、世界观承载力。\n- 知乎盐言：短篇钩子、反转密度、情绪兑现、信息差推进。\n\n---\n\n## Phase 1：收集待审查内容\n\n1. **确定审查范围**：\n   - 用户指定了章节/文件 → 只审查指定内容。\n   - 用户未指定 → 优先审查最近修改的正文文件（`git diff --name-only` 中的正文/设定/大纲相关文件），否则审查当前书的当前章节。\n2. **范围传递策略**：\n   - 优先把文件路径、章节名、行号范围传给 reviewer，不要把整本或大量章节完整复制进每个 prompt。\n   - 单文件或短片段可附 300-1200 字关键摘录。\n   - 多章/整卷/整本审查必须分批：按章节或文件组拆分，每批输出独立 findings，再综合；分批前先完整读 [references/batch-review.md](references/batch-review.md)（跨批状态、连续性、乱序提醒）。\n3. **读取相关支撑材料**：正文、相关设定、角色档案、大纲、追踪/上下文、伏笔文件；缺失时在报告中标记证据不足。\n4. **识别目标平台并加载 rubric**：\n   - 优先使用用户显式指定的平台。\n   - 其次读取项目文档里的 `目标平台` / `平台` 字段，例如 `设定/题材定位.md`、`大纲/`、`拆文报告` 等。\n   - 不要把 `.active-book` 当作平台来源；它只能辅助定位当前书名目录。\n   - 番茄小说 → 优先读取 `story-review/references/rubrics/fanqie.md`；不可读时使用内置番茄 fallback 摘要。\n   - 起点 → 优先读取 `story-review/references/rubrics/qidian.md`；不可读时使用内置起点 fallback 摘要。\n   - 知乎盐言 → 优先读取 `story-review/references/rubrics/zhihu.md`；不可读时使用内置知乎 fallback 摘要。\n   - 未识别平台 → 优先读取 `story-review/references/quality-rubric.md`；不可读时使用内置通用网文内容 rubric；技术备注行写 `generic` 与 `file | embedded`。\n5. **形成审查基准包摘要**：把已加载的文件内容或内置 fallback 摘要压缩为 5-12 条审查标准，后续 solo 和子 Agent 都必须使用这份摘要。摘要必须保留一条句长标准：叙述默认是逗号长句，碎句和电报体与 AI 腔同级处理，不因「短」放行。\n6. **确定性预检（只报告，不修改）**：当审查范围包含本地正文文件路径时，运行本 skill 自带脚本：\n   ```bash\n   node scripts/normalize-punctuation.js --check <正文文件...>\n   node scripts/check-ai-patterns.js --check --fail-on=blocking <正文文件...>\n   node scripts/check-degeneration.js --check <正文文件...>\n   ```\n   - 将 `ellipsis`、`double-hyphen`、`markdown-divider` 结果作为 `format` findings 合并进报告。`em-dash` 破折号只采用 `check-ai-patterns.js` 的语义改写建议（见下条）；`normalize-punctuation.js` 报的同一位置 `em-dash` 在合并时去重丢弃，避免同处出现「机械替换」与「按功能改写」两条相互冲突的 finding。另外人工检查标点节奏是否通篇句号化或随机堆砌，脚本不替代语气判断。\n   - `check-ai-patterns.js` 的 findings 合并进 `prose`：severity=blocking 的类别一律按 S2（当前为 `not-is-comparison` / `em-dash` / `voice-contrast` / `negation-parade` / `reverse-not-is` / `trailer-ending` / `trailer-summary`），修法直接采用检测器输出的建议（删否定铺垫/反差腔/排比否定/章尾预告腔/章尾状态总结句，直接写后项或具体动作；破折号按功能改成动作/短句/逗号/冒号）。\n   - 其余 prose findings（advisory）统一按 S3：只指出读感风险，不替代人工判断；功能性写法标 `[需复核]` 并保留。完整类别和修法见 `anti-ai-writing.md`。\n   - `check-degeneration.js` 报告模型退化（逐字复读/截断/占位符/工程词泄漏），每条带 `severity: blocking|advisory`：blocking（复读/截断/tier1 工程词）作为 S1/S2 `prose` findings，修复建议是「重新生成该段，不是改写」；advisory（tier2 章节/歧义词）作为 S3。\n   - 这三个预检脚本只读；`story-review` **不修改正文、设定或大纲文件**，需要自动修复正文时建议转 `/story-deslop`。full / lean 模式只有下方「追踪文件维护」允许修改 `追踪/`；分批审查的所有模式都可按 batch-review.md 写 **.story-review/state.md**，solo 除该状态外不写项目内容。\n   - 默认 `--quote-mode keep`，不把知乎盐言短篇的 `「」` 当作问题；只有项目明确指定引号风格时才检查对应转换建议。\n\n---\n\n## 统一 Findings Schema（所有模式必须使用）\n\n所有 reviewer（包括 solo）输出问题时必须使用统一结构，方便综合排序；它只在 reviewer 与综合裁决之间流转，给作者的报告按 Phase 4 或 solo 模板转写。`location` 必须使用工具读取结果显示的原始文件行号；不要删除空行后重新编号。\n\n对 `consistency` / `factual` / `causal` / `rule_boundary` 类 finding，`fix` 字段只写事实统一方向（例如“统一为左臂旧伤，并同步正文/设定中冲突处”或“需在 A/B 时间线中裁定一个来源”），不要写文学创作建议。\n\n```yaml\n- severity: S1 | S2 | S3 | S4\n  category: structure | character | prose | consistency | platform | factual | format | causal | rule_boundary\n  location: 文件路径:行号 或 章节/段落描述\n  evidence: \"引用原文或具体证据\"\n  issue: \"问题描述\"\n  fix: \"可执行修改建议\"\n```\n\n严重度定义（与长篇写作、检测器同一刻度：S1/S2＝必须修，S3＝建议看，S4＝仅提示）：\n- **S1**：会破坏主线、角色动机、世界规则或读者信任，需优先修。\n- **S2**：明显影响章节效果、留存、节奏、人物可信度，本轮要修。\n- **S3**：局部质量问题，如措辞、轻微格式、局部节奏，可排期修。\n- **S4**：建议项或风格微调，不阻塞发布。\n\n---\n\n## Phase 2：并行 Spawn Agent（full/lean 模式）\n\n执行 Phase 0 后实际模式仍是 full/lean 时，读 [references/agent-prompts.md](references/agent-prompts.md) 按其中的调用规则与四个 prompt 并行 spawn，综合裁决与报告模板也在其中；不 spawn 缺失的 Agent。每个 Agent 不继承父对话上下文，prompt 自包含路径、范围与统一 Findings Schema。\n\n## Phase 3：综合裁决（full / lean 模式）\n\n收齐 reviewer 结果后按 agent-prompts.md「综合裁决」合并、去重、呈现分歧。\n\n## Phase 4：输出报告（full / lean 模式）\n\n实际模式确为 full/lean 时用 agent-prompts.md 的报告模板；降级 solo 时改用 solo.md 模板。\n\n---\n\n## solo 模式\n\n降级或指定 solo 时读 [references/solo.md](references/solo.md)，按其中流程与输出格式执行。\n\n## 追踪文件维护\n\n长篇工程且 full/lean 审查收尾时读 [references/review-tracking.md](references/review-tracking.md)。\n\n## 流程衔接\n\n**流水线：** 通用\n**位置：** 审查（写作之后）\n\n| 时机 | 跳转到 | 命令 |\n|---|---|---|\n| 要修改查出的问题 | story-long-write / story-short-write | 返回对应写作 skill 修改 |\n| 发现 AI 味需清理 | story-deslop | `/story-deslop` |\n| 需要重新拆解对标书 | story-long-analyze / story-short-analyze | `/story-long-analyze` 或 `/story-short-analyze` |\n\n---\n\n## 语言\n\n- 跟随用户的语言回复，用户用什么语言就用什么语言回复。\n- 中文回复遵循《中文文案排版指北》。\n\nFile v1.1.26:_meta.json\n\n{\n  \"ownerId\": \"kn7e14qz6v4n71xmjegh68jtts80dp5r\",\n  \"slug\": \"story-review\",\n  \"version\": \"1.1.26\",\n  \"publishedAt\": 1790492245073\n}\n\nFile v1.1.26:references/agent-prompts.md\n\n# story-review：full/lean 模式派子代理与综合\n\n只有实际模式仍是 full/lean 时才读本文件。\n\n使用当前运行时的 Agent 工具并行调用（Codex 原生子代理使用 `agent_type`，Claude Code 使用 `subagent_type`，OpenCode 使用 `subagent` 工具的 `agent` 参数，Antigravity 使用 `invoke_subagent` + 同名 `TypeName`；实际字段以当前 CLI 暴露的工具为准）。每个 Agent 不继承父对话上下文，prompt 必须自包含项目路径、审查范围、文件路径、必要摘录和统一 Findings Schema。审稿视角的三个 prompt 还要内联审查基准包摘要与 Rubric Source，不要求子 Agent 必须读 `story-review/references/*` 才能完成任务（如需补充只读本 Skill 的 references）；consistency-checker 例外，它只核对事实，按自己的检查项审，不带审查基准包。所有 reviewer 只读：不改任何文件，只输出结果。\n\n**调用规则**：执行 Phase 0 后，只有实际模式仍是 full/lean 时才 spawn。不要 spawn 缺失 Agent。\n\n**story-explorer 预查询（可选）**。仅当 `Effective Mode` 仍为 `full`/`lean`、当前允许 spawn 且当前运行时的 Agent 工具可用时，才可在对应 canonical agent 目录下确认 `story-explorer` 已部署并 spawn；Antigravity 检查 `.agents/agents/story-explorer/agent.md`，用 `invoke_subagent` + `TypeName: \"story-explorer\"`。`solo` 或子代理递归保护场景下不得 spawn，只能直接读取/检索。Prompt 示例：\n\n```text\n项目目录：{dir}\n查询类型：setting_appearances\n查询参数：{审查涉及的设定关键词}\n```\n\n**Agent 1: story-architect**（subagent_type: story-architect）\n- full/lean 均调用。\n- 审查视角：主题对齐、大纲结构、钩子/反转质量、范围控制、平台期待。\n- 提示指令：\n  ```\n  你是 story-architect，从故事架构层面审查以下内容。\n  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。\n  项目路径：{项目根}\n  审查范围：{文件路径/章节/必要摘录}\n  文风路径：{本书文风全文路径，无则写无}\n  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}\n  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}\n  Rubric Source: file | embedded fallback\n  相关文件路径：{设定/大纲/细纲文件路径}\n  继承的开放项（分批审查必填，无则写「无」）：{从 追踪/伏笔.md 提取的、预计回收章 ≤ 本批末章的已埋未回收钩子，连同上一批未解决 findings 摘要}\n  检查项：\n  1. 这一章是否推进了故事主题？\n  2. 大纲结构是否完整（钩子/爽点/悬念）？\n  3. 情绪节奏是否合理？\n  4. 钩子和反转设计质量如何？\n  5. 范围控制：有无角色/设定膨胀？\n  6. 剧情循环是否存在且可重复？（参照审查基准包摘要里的剧情循环原则）\n  7. 高潮场景是否用了蓄能→假胜→崩解结构？（参照审查基准包摘要里的高潮构建原则）\n  8. 伏笔密度、连载期待和结构信息量是否合理？（伏笔密度通常只作为 S4 结构风险，除非已造成理解混乱）\n  9. 按平台 rubric 或通用内容 rubric 逐项对照，标记 PASS/FAIL。\n  10. 继承的开放项里，本批本该兑现的钩子/伏笔是否落空？\n  11. 开头同质化（仅当本章是全书开篇/前 3 章）：开局切口是不是同题材的默认套路（穿越即退婚、系统绑定、末世第一天、开场即打脸等），能不能原样换到任意同类书？\"有钩子/非天气开场\"不等于不同质。对照 `story-review/references/plot-core-methods.md`「噱头分类与开篇流程」判断——能整体换到同类书=同质化（撞题材模板至少 S2；套路化但有具体人物/处境微差 S3）。\n  12. 结尾总结：章尾是总结/升华/复述式收尾（\"就这样……\"\"他终于明白……\"\"这一夜注定……\"），还是落在动作/画面/悬念上？检测器已判 blocking 的（`trailer-summary`）按上面「blocking 一律 S2」处理，不重复定级；检测器没覆盖的总结/升华/复述式收尾按影响定 S2/S3（改写走 /story-deslop：章尾预告与章尾状态总结归 Gate F，其余 blocking 并入 Gate B；本 skill 只标问题不改写）。\n\n  输出格式：\n  VERDICT: APPROVE / CONCERNS / REJECT\n  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4。\n  INHERITED_ITEMS: 逐条列继承的开放项 + 已检查 / 未能检查；本批本该兑现却落空的列为 finding。\n  RECOMMENDATIONS: [修改建议]\n  ```\n\n**Agent 2: character-designer**（subagent_type: character-designer）\n- full 模式调用。\n- 审查视角：角色语言风格一致性、对话质量、人物弧线、关系推进。\n- 提示指令：\n  ```\n  你是 character-designer，从角色和对话层面审查以下内容。\n  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。\n  项目路径：{项目根}\n  审查范围：{文件路径/章节/必要摘录}\n  文风路径：{本书文风全文路径，无则写无}\n  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}\n  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}\n  Rubric Source: file | embedded fallback\n  相关角色文件：{角色设定文件路径}\n  检查项：\n  1. 角色语言风格是否与语言风格档案一致？\n  2. 对话是否千篇一律或信息过满？\n  3. 人物弧线是否连贯？\n  4. 角色行为是否符合其动机？\n  5. 对话是否有潜台词和信息控制？\n  6. 爱情线好感度与 CP 行为是否匹配？（参照审查基准包摘要或本 Skill 的角色关系参考）\n  7. 好感度进度是否可感知？\n  8. 对话三症状（可选读 `story-review/references/dialogue-mastery.md` 自查项）：① 机械对话/问答式/句间无情绪承接；② 角色当「科普嘴」整段讲设定原理(Gate G 同样管台词)；③ 说话不分场合(高压/生死 beat 的玩笑、口头梗、插科打诨出戏)。命中按 S2/S3 报具体引用+改法。\n\n  输出格式：\n  VERDICT: APPROVE / CONCERNS / REJECT\n  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4。\n  RECOMMENDATIONS: [修改建议]\n  ```\n\n**Agent 3: narrative-writer**（subagent_type: narrative-writer）\n- full 模式调用。\n- 审查视角：AI味检测（含解释腔/上帝感/安排感=模式 8）、情绪烈度（够不够爽/会不会太保守）、格式合规、节奏均匀度、文字自然度。\n- 提示指令：\n  ```\n  你是 narrative-writer，从文字质量层面审查以下内容。\n  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。\n  只读审查：不改任何文件（含正文），只输出下方 VERDICT / FINDINGS / RECOMMENDATIONS。\n  项目路径：{项目根}\n  审查范围：{文件路径/章节/必要摘录}\n  文风路径：{本书文风全文路径，无则写无}\n  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}\n  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}\n  Rubric Source: file | embedded fallback\n  去味判据：按你读取表的 anti-ai-writing、banned-words、deslop-gates 审（审查任务照表读），这里不摘抄\n  检查项：\n  1. 是否存在禁用词/套话/陈词滥调，或“像/好像/仿佛/如同”式比喻成片堆叠？\n  2. 是否出现 AI 写作指纹、10 种 AI 写作模式（含模式 8 解释腔/上帝视角/安排感）或章末总结体？\n  3. 格式是否合规（按戏剧单元/镜头自然断段、无机械字数切分、无空行、对话独立成行、主语节奏自然）？\n  4. 标点节奏是否匹配语气/人物声线：是否通篇句号化、随机堆砌问号/感叹号，或残留 `……`/`——` 硬造停顿？本书已明确授权且有功能的停顿不因符号本身判错。\n  5. 是否出现“这五个字 / 短短四字 / 三个字一落 / 八个字砸下去”等正文内具体字数表达？若统计口径不明、未见机器核对结果或无叙事必要，标为问题并建议改成非具体数字表达。\n  6. 节奏是否均匀（有无连续多节无情绪变化）？\n  7. 是否存在删掉无损的任务卡点或流程细节？若只是水/局部节奏问题标 S3；明显拖垮主线推进标 S2。\n  8. 身体细节是否重复、无功能？按本书文风和叙事作用判断，不设单词次数硬线。\n  9. AI味分级（轻度/中度/重度）及证据。\n  10. 去 AI 补充复核：是否有作者解释总结/意义尾巴；是否连续堆精致戏剧反应短语；是否把已有手机/屏幕/公告/规则/证据载体改成叙述者解释；是否把任务卡点当成自然感或凑字数手段；是否机械删除了有功能的生活化/角色化比喻或短篇主观审判句。\n\n  输出格式：\n  VERDICT: APPROVE / CONCERNS / REJECT\n  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4；AI味级别写入 issue 或 category。\n  RECOMMENDATIONS: [修改建议]\n  ```\n\n**Agent 4: consistency-checker**（subagent_type: consistency-checker）\n- full/lean 均调用。\n- 审查视角：grep-first + 推理型一致性检测，输出 S1-S4 报告。\n- 提示指令：\n  ```\n  你是 consistency-checker，使用 grep-first + 推理型一致性审查检测事实矛盾。\n  你的任务是【找事实矛盾、状态断线和需要推理才能发现的设定逻辑冲突】，不做创作评判，不评价文学质量，不输出创作修改建议。\n  项目路径：{项目根}\n  审查范围：{文件路径/章节/必要摘录}\n  已知角色：{从设定文件提取角色列表}\n  继承的开放项（分批审查必填，无则写「无」）：{从 追踪/伏笔.md 提取的、预计回收章 ≤ 本批末章的已埋未回收伏笔，连同上一批未解决 findings 摘要}\n  检查项：\n  1. 角色属性是否前后一致？\n  2. 世界规则是否被违反？\n  3. 伏笔状态是否前后一致（已埋/计划回收/已回收/断线）？\n  4. 时间线是否自洽？\n  5. 术语、身份、地点、能力边界是否前后一致？\n  6. 继承的开放项里，本批本该回收的伏笔是否仍悬空？\n\n  输出格式：\n  VERDICT: APPROVE / CONCERNS / REJECT\n  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4；category 只能使用 consistency / factual / format / causal / rule_boundary。\n  INHERITED_ITEMS: 逐条列继承的开放项 + 已检查 / 未能检查；本批新发现、不在 伏笔.md 的开放钩子单列，供主会话回写 追踪/伏笔.md。\n  FACTUAL_RECONCILIATION: [仅列需统一的事实来源或需人工裁决项，不写文学创作建议]\n  REASONING_CHAINS: [仅列推理型 finding 的前提/规则 -> 触发事件 -> 矛盾点 -> 需裁决问题]\n  ```\n\n## 综合裁决\n\n1. 收集实际执行的 reviewer VERDICT 和 FINDINGS。\n2. 合并去重：按 `severity` 排序（S1 > S2 > S3 > S4），同级内按影响范围排序。\n3. **可选事实核查**：如果审查内容涉及需要验证的外部事实（历史年代、地理方位、职业细节等），只有在 `Effective Mode` 仍为 `full`/`lean`、当前不是子 Agent、当前运行时的 Agent 工具可用且对应 canonical agent 目录下的 `story-researcher` 已部署时，才可额外 spawn；Antigravity 检查 `.agents/agents/story-researcher/agent.md`，用 `invoke_subagent` + `TypeName: \"story-researcher\"`。`solo`、missing/malformed/stale/spawn failed 降级或子代理递归保护场景下不得 spawn，只能在报告中标记“需人工事实核查”。\n4. **分歧呈现**：如果 reviewer 间有冲突意见，明确呈现分歧让用户裁决；不要自动妥协。\n5. 按 SKILL.md「报告面向作者」输出综合审查报告：开头说明审查方式与范围，证据不足项写成作者能补的材料，执行路径只进技术备注行。\n\n## 报告模板\n\n只有实际模式确实为 `full` 或 `lean` 时才使用本模板；如果 Phase 0 或运行时失败导致降级 `solo`，必须改用 solo 模式模板。lean 排除的视角写进「这次怎么审的」；full/lean 必需 reviewer 缺失或 spawn 失败时降级 solo，不在本模板里标「未看」后继续综合。\n\n<!-- author-report -->\n```md\n=== 《{书名}》{审查范围}审查 ===\n这次怎么审的：{结构、人物、文字、设定一致性四个视角分头看 | 精简审：结构和设定一致性两个视角}，按{番茄 | 起点 | 知乎盐言 | 通用网文}的标准。\n\n总体判断：{可以发 | 改完下面几处再发 | 这一章需要重写}——{一句话理由，用读者感受说}\n\n## 必须改（{n} 处）\n1. 第{N}章「{原文引用}」\n   问题：{读者会怎么想、哪里读不通}\n   建议：{具体改法}\n\n## 建议改（{n} 处）\n{同上格式}\n\n## 可以不改（{n} 处）\n{一行一条：位置 + 问题 + 改法；风格微调也放这里}\n\n## 需要你决定\n{审稿视角有分歧、或事实需要你裁定时，写成问题 + 选项 + 我的建议，例如「第12章写左臂受伤、第15章写右臂，统一成哪边？建议左臂（第12章交代了伤的来历）」；没有就写\"无\"}\n\n## 没法判断的地方\n{缺哪份设定或大纲导致没法核对、需要人工查证的外部事实；没有就写\"无\"}\n\n## 下一批接着核对\n{仅分批审查：留到下一批回头看的问题 + 预计在哪几章兑现；否则删掉本节}\n\n下一步：{例如「说\"改第12章\"，我按必须改的几处动手」「AI 味集中的段落可以说\"去 AI 味\"」}\n技术备注：Mode {full | lean}→{full | lean} · Fallback none · Rubric {…} ({file | embedded})\n```\n\nFile v1.1.26:references/anti-ai-writing.md\n\n# 去AI味完整指南\n\n> 本文件的句长、视角、标点、修辞与禁用词是默认写法，服从 [style-resolution.md](style-resolution.md) 的逐维裁决。所选 Gate 检查表达效果，不因作者有意选择某写法就机械删除；获准命中按书级 `.deslop-whitelist` 处理。\n\n<!-- 同名副本×4 字节同步，改动后跑 scripts/check-shared-files.sh -->\n\n> 识别AI写作指纹、改写顺序、禁用词约束、改写范例库。用于正文写作后做去AI味自检和改写时查阅。\n\n---\n\n## 决策路由\n\n| 你在做什么 | 查阅哪个模块 |\n|-----------|-------------|\n| 写完正文后做去AI自检 | 核心规则 -> AI写作模式检测 -> 质量维度检查 |\n| 改写某段AI味重的文字 | 改写范例库 + 冲突对话改写范例 |\n| 检查是否用了禁用词 | 禁用词与句式速查 -> AI高频词（模式1） |\n| 系统性去除整章AI味 | 改写顺序 |\n| 检查章尾是否有总结升华 | AI写作指纹 -> 章末总结体 |\n| 判断情绪描写是否告知式 | Show Don't Tell原则 + 去AI味补充技法 |\n| 快速扫描全章质量 | 快速自检口诀 + 质量维度检查 |\n\n## 指令语气\n\n本文件以问题模式和高危清单为主。一级高危词优先检查；二级/语境敏感词按频率、语境和是否偷懒判断。遇到冲突时，保留创作意图与剧情功能优先于机械替换。\n\n---\n\n## AI写作指纹（必须避免）\n\n### 高频AI用词\n\n> 完整禁用词表见 [banned-words.md](banned-words.md)\n\n**补充类目**（`banned-words.md` 未覆盖的高阶替换）：\n\n| 类别 | 替代原则 |\n|------|---------|\n| 抽象升华词（命运、宿命、注定） | 用具体事件代替抽象概念 |\n| 万能比喻（像潮水般、如闪电般、仿佛春风） | 优先不用比喻，确需时只留少数生活化、角色化比喻 |\n\n### 引号只承载真实引用，不给普通名词加戏\n\n不要用双引号给普通名词、常见动作或作者临时概括的概念做“引号强调”。这类写法会把没有特殊含义的词硬包装成术语，连续出现时尤其像模型在替读者划重点。`check-ai-patterns.js` 的 `quote-emphasis-tic` 只负责提示，最终按语境判断。\n\n- **应改**：所谓的\"机会\"、完成这次\"蜕变\"、找到真正的\"答案\"。这些词若只是普通语义，直接去掉引号，用事件本身体现分量。\n- **应保留**：角色对话、逐字直接引用、书名/篇名、确有设定含义的代号，以及手机消息、公告、系统播报等场内载体展示的原文。\n- **边界**：第一次定义术语时可以用引号，但后文不要反复加；讽刺、反话或角色刻意咬重音时可以保留，前提是上下文能看出是谁在强调、为什么强调。\n\n### 章末总结体\n\n**禁止**在章节结尾用以下方式收束：\n- 总结性感悟（\"他终于明白了……\"）\n- 升华式感叹（\"这一夜，注定无人入眠\"）\n- 哲理式收尾（\"人生就是这样……\"）\n- 伏笔式预告（\"他不知道的是，更大的风暴即将来临\"）\n\n**正确做法**：章尾用动作、对话或悬念收束，让情节本身制造余韵。\n\n### 叠加式描写（同一动作掰开写三遍）\n\n**检测模式**：一个动作/情绪先写发生，再补感知细节，再补身体反应，分三段依次写完。读者看到的是同一个动作被掰开写了三遍。\n\n**典型特征**：\n- 先写一个概括性动作，再展开写同一动作的细节，再写身体反应：三段说的是同一件事\n- \"发生层→感知层→反应层\"按顺序分段出现\n- 每个维度独立成段，而不是揉进同一段连续正文\n\n**错误示例**：\n> 林父低着头，左手把文书压住，右手拿笔，往纸上落。\n>\n> 手从肘到腕都在抖。\n>\n> 笔尖在纸上停了停，写了一横，又停。那个\"林\"字的撇写歪了。\n\n→ 同一个动作（手抖/写字）分三段写，每段是同一瞬间的不同维度\n\n**正确做法**：发生、感知、反应三个维度揉进同一段连续正文，读者读到一个完整瞬间：\n\n> 林父左手压着文书，右手拿笔往纸上落，笔尖一触纸面就偏了，从肘到腕止不住地抖，那一横斜着拖出去。\n\n→ 发生、感知、反应在一段里同时呈现\n\n**处理原则**：保留有功能的情绪细节，把同一瞬间的重复描写合并成连续画面。若合并后明显变薄，优先恢复原文中有功能的信息，或把既有信息改成更自然的动作/对话表达；不要新增原文没有的情节、设定、关系或时间线。\n\n---\n\n## 核心规则\n\n> **句长以规则 3 为准**：规则 1-4 和本文件其他地方的「短句 / 拆短 / 能删就删」说法，与规则 3 冲突时按规则 3 执行。\n\n### 规则 1：段落密度诊断\n\n段落长短没有固定优劣。检查重点是朗读和手机阅读是否卡顿：\n\n- 一段通常只承载一个动作、一个信息变化或一组紧密相关的反应。\n- 逗号串太长、多个完整动作挤在一段里，读起来需要换气时，按动作或信息变化拆开。\n- 连续短段碎成提纲时，合并同一镜头内的相邻句，让画面保持连续。\n\n```\n过密：他看着窗外的雨，心中涌起一股说不清的感觉，这些年走过的路和很多已经忘记的事都在这一刻涌上心头。\n\n更自然：他盯着窗外的雨，雨从下午下到天黑。\n\"你还在想她？\"老刘问。\n他没说话。\n```\n\n### 规则 2：动作 + 对话 + 情绪反应\n\n动作、对话与情绪反应按场景需要交织，不按固定顺序轮换，不为凑齐三项补反应。\n\n情绪没有固定译法，关键节点也可以准确直写。上下文已让情绪成立，不另补反应；需要补足信息时，优先选择、台词、策略、物件或实际后果。\n\n身体细节只有带来新信息、影响动作或体现人物与场景特点时才保留。只在句尾重复标注情绪的微动作删掉，不换部位或同义动作。去味时沿用原文已有事实，不凭空添加摔杯子、攥袖口等行为。\n\n### 规则 3：句子该多长（短句是工具，不是默认）\n\n叙述（旁白）默认写成**逗号长句**：一句用逗号串起 2-4 个动作或信息，再落句号；逗号之间 8-12 字，整句 20-30 字。短句是偶尔的孤立重拍工具，不是叙述的默认写法。\n\n| 场景 | 句长 | 示例（长篇语料原句） |\n|------|------|------|\n| 日常 / 推进 / 描写（多数叙述句） | 逗号之间 8-12 字，整句 20-30 字 | 阴冷潮湿的气息扑面而来，身下铺着一层薄薄的稻草，湿漉漉地粘在皮肤上。 |\n| 对话 | 口语化，长短随角色 | \"你疯了？\"\"可能吧。\" |\n\n**不合格（与 AI 腔同级）**：\n- 逗号之间连着都是 ≤5 字的碎片（\"他抬手，开门，进屋，坐下\"式）\n- 通篇 3-8 字句、句号密得像提纲（电报体，见模式 9）\n- 一长一短机械交替（同样是模板）\n\n> **爆款语料校准**（七猫长篇 现言/都市/古言/玄幻/历史 125 本×前 8 章旁白统计）：逗号之间平均 8.8-9.6 字；整句平均 22-24 字；逗号长句占叙述句 74-80%；≤5 字的短片段约占两成，多是孤立的时间词、转折、动作重拍。短篇（盐言体）段落更短（≤15 字的单句段可近一半，长篇约两三成），但句子内部的节奏和长篇一样：**段落随体裁变短，句子内部不碎**。\n\n### 规则 4：口语化表达\n\n- 允许用俚语、粗话（符合角色身份）\n- 对话不要书面语（\"我认为此事不妥\" -> \"我觉得不靠谱\"）\n- 叙述也不要端着（\"他目光如炬\" -> \"他眼珠子一动不动盯着\"）\n- 短语优先于成语（\"无可奈何\" -> \"没办法\"）——只管对话和贴角色声口的叙述；旁白常用成语（不动声色、心不在焉一类）照留\n\n---\n\n## Show Don't Tell 原则\n\n| Tell（告诉） | Show（展示） |\n|-------------|-------------|\n| 他是个胆小的人 | 他把检查报告在手里翻来覆去看了三遍，还是不敢打开 |\n| 这间酒吧很吵 | 酒保凑到他耳边喊了两次他才听见 |\n| 她很富有 | 她随手把一张信用卡丢在桌上，卡面上的数字比这顿饭贵十倍 |\n| 两人关系很差 | 他把烟掐灭在她刚泡的茶杯里，她面无表情地把杯子推到一边 |\n| 他很聪明 | 三秒钟。他看了三秒钟就把文件合上了。\"第三页，第二行。\" |\n\n**核心方法**：\n1. 用行为代替形容词\n2. 用细节代替总结\n3. 用对话代替旁白说明\n4. 用后果代替情绪总结\n\n---\n\n## 质量维度检查\n\n### 1. 核心一致性（权重最高）\n- 剧情是否与大纲/前文一致\n- 人物行为是否符合人设\n- 设定是否有前后矛盾\n\n### 2. 表面改写（防AI指纹）\n- 是否包含AI高频用词（见上表）\n- 章尾是否有总结/升华\n- 是否有大段纯心理描写\n- 段落是否按戏剧单元/镜头自然断开，避免机械单句成段或为凑短碎成提纲（网文段落规则）\n\n### 3. 格式一致性\n- 对话格式统一：按项目/平台约定保持同一引号风格；知乎盐言短篇可用「」\n- 标点节奏匹配语气：避免通篇句号化；保留有功能的问号和少量感叹号；用动作/短句表达迟疑或打断，不用省略号或破折号硬造停顿\n- 场景切换有明显标记\n- 时间线清晰可追踪\n\n### 4. 可读性\n- 是否有连续多个长句压住阅读节奏，且缺少动作、对话或短句换气\n- 对话是否口语化\n- 是否有未解释的生僻词/设定术语\n- 节奏是否有快有慢（不能全是一种节奏）\n\n### 5. 逻辑连贯性\n- 角色动机是否合理\n- 事件因果链是否清晰\n- 时间线是否对得上\n- 角色的知识范围是否合理（不能\"开上帝视角\"）\n\n---\n\n## 快速自检口诀\n\n```\n一事一段，镜头自然断。\n对话要像人说话。\n心情不写心里话。\n结尾不搞大升华。\n打斗不写流水账。\n日常要埋伏笔桩。\n```\n\n> 网文段落规则：按戏剧单元/镜头/一件事结束自然断段；短段快读，长段承载完整推理、氛围和情绪链，避免机械单句成段或通篇同长度。\n\n---\n> **番茄高分样本校准**：番茄正文更接近“手机端短段 + 自然虚词 + 场内动作/对话推进”，不是机械指标达标。番茄高分样本 305 章窗口显示：段落中位约 23.5 字，50-60 字行宽平均只占 5.1%；平均对话占比约 20.6%，对话≥50% 仅 3/305，开篇对话 59/305；`地/得` 305/305、`很` 275/305、`像/好像/仿佛/如同` 267/305、顿号 176/305、省略号 281/305。结论：这些只能按语境复核，不能做 0 容忍硬禁令。\n>\n> **反投机边界**：不要为了“反检测”强制每句换行、把 `……` 改成 `........`、把 `地/得` 全改成 `的`、禁用所有顿号/“很”/“像”、强行开篇对话或按三番四证重排章节。去 AI 味是润色，不是结构重写；除非用户明确要求重写，否则不改变章节顺序、伏笔分布、对话占比和人物信息释放节奏。\n\n---\n\n## 禁用词与句式速查\n\n> 完整禁用词表和句式模板见 [banned-words.md](banned-words.md)\n\n### 正确替代示例\n- '他感到一丝紧张，手心全是汗' -> '他签名时划破了纸'（身体细节只在造成后果时留）\n- '\"好的。\"他说道' -> '\"好的。\"他把门卡塞回口袋'\n- '他深吸一口气' -> '他把话咽回去'\n\n---\n\n## 10 种 AI 写作模式检测\n\n### 模式 1：AI 高频词\n\n| 禁用 | 替换为 |\n|------|--------|\n| 不禁 | 删掉 |\n| 仿佛/宛如 | 删掉或用具体描写 |\n| 映入眼帘 | 删掉 |\n| 心中暗道 | 用动作展示思考 |\n| 沉声道/淡淡地说 | 换成动作标签 |\n| 脸色一变 | 用具体表情/动作 |\n| 嘴角微扬 | 他笑了/他翘了下嘴 |\n| 不由自主 | 删掉 |\n| 只见/此时此刻 | 删掉 |\n| 目光如炬 | 删掉或具体化 |\n\n### 模式 2：弱化副词泛滥\n阈值：每 1000 字超过 3 个 = AI 签名。重点监控：微微、淡淡、缓缓、轻轻。\n\n### 模式 3：意义膨胀\n- \"意义深远\" -> 写具体后果\n- \"前所未有\" -> 给出对比参照\n- \"可谓\" -> 删掉\n\n### 模式 4：万能结论\n- \"未来可期\" -> 用未解决的紧张感结尾\n- \"前途无量\" -> 删\n- \"充满希望\" -> 写具体的下一步动作\n\n### 模式 5：论文体段落结构\n小说中出现以下开头句 = AI 入侵：\n- \"不难看出\"\"由此可见\"\"事实上\"\"综上所述\"\n\n### 模式 6：书面语连词泛滥\n叙事散文中频繁出现：\"于是乎\"\"与此同时\"\"从而\"\"因而\"\"诚然\" -> 口语化替代或直接删除。\n\n### 模式 7：三连排比癖\nAI 喜欢把事情凑成三个以显\"完整\"。-> 砍到只剩最有力的一条。\n\n跨段「不是A。/也不是B。/只是C。」由 `formulaic-parallelism` 作 advisory：它可能是工整铺排，也可能承担辩解、悬念排除或情绪递进；只有重复提纲、拖慢画面时才压缩。该类提示与「至于X不X，怎么X」、同动词「不V A，不V B」都只作语义复核：对话也要检查，但有明确人物声线或任务功能时可保留；若来自细纲多个字段对同一要求的重复，正文只能消费一次，不能逐项复述。\n\n### 模式 8：解释腔 / 上帝视角 / 安排感\n最难察觉、却最\"像 AI\"的一类。叙述者跳出角色当下，去解释、剧透、总结、定性、拔高，读者能闻到\"作者在场\"和\"剧情被安排好了\"的味道。这正是\"说教感/上帝感/解释腔/机械感/刻意感/安排感\"的来源。\n\n| 表现 | 例（删/改） |\n|---|---|\n| 解释因果 | 「之所以…是因为」「原来…」「这意味着」「正是因为」-> 删。因果只从角色动作、对话、反应里让读者自己拼 |\n| 上帝视角剧透 | 「她不知道的是」「殊不知」「多年以后」「冥冥之中」「仿佛预示着」-> 删。只写角色此刻知道的，悬念让读者自己悬 |\n| 替读者下结论/定性 | 「演得真好」「这出戏她看过一遍」「他就是这样薄情的人」-> 删。把证据（神态、动作、台词）摆出来，定性留给读者 |\n| 替角色总结心理 | 「她明白，这一切都是命」-> 无新增信息就删；确有角色判断时保留带偏见的闪念，不强配身体反应 |\n| 总结/动机/评价链把意义说满 | 「他终于明白」「这是最好的选择」「所有人都会记住这一刻」-> 删掉定性，改成角色当下要处理的具体缺口、未完成动作或局部反馈；不是保留评价再硬塞物件/动作 |\n| 安排感/硬铺垫 | 为后文强行交代背景、整段回忆倒叙 -> 背景按角色此刻真实所需，用闪念、半句话、物件零碎带出，不集中交代 |\n| 升华式收尾 | 结尾对仗拔高、金句点题 -> 用一个动作或一句留白收住，把\"意思\"压进画面里 |\n| 抽象命运/开端收束 | 「命运终于露出獠牙」「早已布好的棋局」「这一刻终于明白」「属于他的反击才刚刚开始」-> 改成角色当下可见的文件、动作、对话或物理后果；`check-ai-patterns.js` 报 `abstract-summary-tic` 时优先处理 |\n| 套词密度过高 | 仿佛/一丝/一抹/深吸一口气/平静无波/指节泛白等成串复现（`cliche-density-tic`）-> 不是同义词轮换，整段回到角色当下证据：文件、动作、对话、物理后果 |\n| 套式反应细节 | 指尖轻叩、袖口里攥紧、指节泛白、目光移开、“语气平静得像在念……”等反应成片（`stock-reaction-tic`）-> 逐处做删除测试；只标注情绪而不改变选择、关系、物件或动作结果的删掉，不换部位和同义动作；有伤势、动作失败或情节后果的身体细节可留 |\n| 比喻密度过高 | 像/好像/仿佛/如同等比喻标记成片复现（`metaphor-density-tic`）-> 保留最能传递信息或情绪的一两个，其余改回具体动作、物件、声音、后果；不要换成新比喻 |\n| 系统公告公文腔过密 | 方括号规则/面板/公告行里硬规则词成片（`system-notice-formality-tic`）-> 保留为角色看见的屏幕/公告/规则载体；只在载体内部白话化部分硬词，或补角色当场看懂的具体后果，不改成叙述者解释 |\n\n**更隐蔽的一层（最难自查，没有标志词）**——同样是安排感/上帝感：\n- 评判性副词/补语：「关切得恰到好处」「笑得恰如其分」「不多不少」-> 作者在替读者盖章\"这是装的\"。只写动作（\"她掩了帕子，眼睛没动\"），装不装让读者自己判。\n- 剧透式点破潜台词：「那点笑她看得分明」「谁都看得出他在撒谎」-> 把藏着的挑明了。留着别点破。\n- 定性比喻/盖棺句：「像在宣判一件早已定好的事」「像看一件死物」-> 比喻在替角色下定论。非角色此刻强烈主观感受就删；要留也只能是她带偏见的瞬间感觉，不是客观断言。\n\n自检：每句问一遍——这是\"角色在经历\"，还是\"作者在讲解/安排\"？凡作者跳出来讲，删，或改成角色视角内的呈现。根治办法是锁定深度限知视角：只写视角人物此刻看得见、听得见、想得到的，镜头钉死在角色身体里，作者就没位置跳出来了。\n\n改法优先级：先删或原位替换污染句，不在段尾另补“人味”尾巴。需要补信息时，把原来的总结/动机/评价句改成角色当下能碰到的问题、手续、回信、付款、门外动静等具体压力；已有手机/屏幕/公告/门牌/表单等信息，优先作为角色看见的场内载体保留，不要转写成叙述者解释。具体载体跟剧情走，不套固定清单。\n\n**任务卡点不是固定公式，也不是通用补流程按钮**：它只是把已有解释落回角色当下要处理的缺口。先问原文有没有“要办的事”和“卡住的点”；有，才可以压成任务卡点；没有，就只删解释或改动作/对话，不新造事件链。改完再做“删掉试试”：删掉后不影响信息、情绪、关系、代价或伏笔，就压缩或删除。\n\n**但删解释腔 ≠ 把读者读懵**：新名词/新设定/新道具首次出现时，仍要让读者抓到一个锚——靠角色的动作反应、对话里半句自然提及、或场景里的物理后果，一笔带出它此刻的作用或分量；既不整段讲来历原理，也别只甩个零信息生词让读者干懵。人物记忆、情绪缓冲、因果承接也一样：如果一句看似解释/评价，实际承担小连贯（让读者知道角色为什么脸热、为什么停顿、为什么这一声压不住），不要机械删成摘录清单；把它压成角色当下的白话、动作、物件或半句念头。例：「蓝晶」首次出现不写\"这是储存记忆的装置\"，但可写她把蓝晶按上太阳穴、别人的记忆碎片炸开在眼前——功能被读者看见，全貌留作悬念。区分：锚是\"角色此刻撞上的可感知后果/记忆或情绪承接\"（留或压），解释是\"作者跳出来讲设定来历/原理/替读者下结论\"（删）。\n\n### 模式 9：过度压缩（电报体）\n\n去AI味删过头的反向指纹。每句都压到最短、结构虚词扫光、每个动作都补一个「了下/了一下」式轻反应。单句看着干净，连读像提纲，读者的体感是\"不流畅、喘不上气\"。删减的目标是删废话（解释、注水、凑数），不是删中文的自然冗余。\n\n| 表现 | 修法 |\n|---|---|\n| 非峰值叙述句也全部压成最短句 | 重拍句（动作/情绪/悬念峰值）保持短促；铺垫、过渡、日常动作写成自然白话句，保留 了/的/就/的时候 等结构虚词 |\n| 「扯了下/停了一下/拍了两下/松了半圈」式微动作高密度复现（check-ai-patterns.js 报 micro-action-tic） | 合并动作，换具体细节；不是每个动作都要接一个反应尾巴 |\n| 强调副词（连/才/又/只/全/反而）被扫光 | 删前判语义：承担人设、对比、讽刺义的保留（\"才二十三天\"删掉\"才\"，人设强调就反了） |\n| 对话语气词归零 | 按角色保留自然低频的 呢/吧/啊；也不反向猛加——人味来自结构自然，不是聊天腔 |\n| 叙述残留公文/文言腔（不得/须/未/已然/当前） | 换白话（不能/要/还没/现在）。系统公告、规则条文、面板播报可以保留冷硬功能；若 `system-notice-formality-tic` 报警，只在原载体内白话化一部分，不改成叙述者解释 |\n| 长文本里短叙述段成片（`overcompressed-prose-tic`） | 不是把所有短段拉长。先人工通读：重拍短句、密集镜头如果上下文顺，就保留；只处理读起来像提纲的过渡句，把它们并回同一镜头，让读者顺着动作、空间、因果读过去 |\n| 引号外叙述低连接密度且缺中长句（`low-connective-density-tic`） | 不是全局补“的/了/就”，也不处理台词/弹幕/系统播报的天然短促。先找叙述层读起来像提纲/电报体的断裂处，恢复必要连接、指代和中长承接句；有中长句链条的低功能词文本可保留 |\n\n自检：删完连读一遍，读感像提纲或流水口令，就是删过了——把非峰值句恢复成自然白话，不是接着删。\n\n本模式约束的是删减的度，不降低清理力度：选定 Gate 内的禁用词、套路句式、告知式心理照删照改；回填只回结构虚词和连接，不保留、不恢复任何模板措辞。\n\n### 模式 10：二修伪自然（油腻倒装 / 监控动作清单 / 对话指标化）\n\n一些“反检测提示词”会把文本推向另一种模板：为了提高突发性而乱倒装，为了真人感而机械加口误和脏话，为了手机阅读而强制每句换行，为了对话占比而把心理和叙述硬改成台词。这些不是自然网文，是二修痕迹。\n\n| 表现 | 修法 |\n|---|---|\n| 油腻倒装 | 不写“手里拿着刀，他冲了上去”这类伴随动作前置。连续同主语时，优先用场内物件、声音、局部身体或环境反馈自然换句首；不要滥用死物拟人 |\n| 监控摄像头式动作清单 | 同段连续“伸手拿起、取过、挑开、放下、转身……”像步骤表。合并琐碎动作，只保留有情绪、情节或空间功能的动作；必要时用角色犹豫、误判、旁人反应或环境反馈做缓冲 |\n| 高压场景误脱水 | 冲突、追杀、打斗可删解释和逻辑胶水；日常、暧昧、铺垫不能全章脱水。删的是废话，不是“的/了/就/但是”等自然连接 |\n| 吃字漏词 | 去 AI 后如果动词没有对象、动作指向不清、读者不知道谁对谁做了什么，要补回必要宾语、承载物或物理反馈；中文可省略，但不能省到像提纲 |\n| 对话指标化 | 不为凑 50%-60% 对话占比硬扩台词。台词只在角色真会说、此刻必须说时增加；长对白可拆动作，解释性对白优先压成冲突、回避或半句信息 |\n| 硬格式投机 | 不强制每句换行、50-60 字一行、不把省略号改成英文点、不把 `地/得` 全改错。按平台和项目既有格式走 |\n\n`check-ai-patterns.js` 的 `action-list-tic` 只提示监控动作清单，不是 blocking。功能性打斗/追逐/仪式步骤若动作链本身承担信息，可保留或标 `[需复核]`。番茄高分样本中该类命中为 0，因此适合作为“需通读”的风格提示，而不是硬性失败项。\n\n#### 工具提示处理\n\n`check-ai-patterns.js` 是本地写作 lint；blocking 只限确定性句式/标点问题，advisory 不作完成门槛。用户贴其他工具报告时，只把能落到正文的句式、段落、词汇问题转成具体修改点，不写“0% AI / 100% 真人”或“固定公式”，也不围绕分数反复微调。\n\n工具提示不高于读感规则。参考文本里若出现“仿佛/非常/感到”等套词或告知式心理，仍按模式 1-8 清理；不要机械补词、故意错字或按题材套壳。\n\n**去 AI 味补充判断**：\n- 优先处理：作者解释总结、意义尾巴、把情节翻译成“他意识到 / 这意味着 / 真正重要的是 / 这次成长”。优先删掉，或落回场内动作、对话、物件状态、任务状态和角色当场要处理的后果。\n- 场内载体优先：原文已有手机、屏幕、公告、门牌、表单、账单、物证、规则行时，保留为角色看见/读错/处理的文本或物件；不要把同一信息改写成叙述者解释规则。\n- 白话但不注水：少用精致戏剧反应短语（头皮发紧、眼皮一跳、心口一沉、胃里翻涌）连续替代剧情推进；能写普通动作/普通感觉就写普通动作/普通感觉，并保留自然的“的/了/就/但是/已经/之后/没有”等连接。\n- 题材文风优先：文风对标有帮助，但必须来自目标题材/本书文风指纹；不要把盘龙腔、旧网文腔、第一人称声口等当成跨题材万能修法。\n- 不要当通用修法：单纯加标题、补物件、补动作尾巴、拉长/压短句子、增加排队/门禁/记录体，不能替代具体的情节、视角和语言问题处理。\n\n#### 把提纲句写成连续段落\n\n当文本已无 blocking / 明显 advisory，但读起来仍像提纲时，只处理断裂处：\n\n1. 标出读起来像逻辑报告的段落：连续出现“他知道/他明白/这意味着/真正的问题/必须/需要”等判断链，却缺少当下动作、物件或对话反馈。\n2. 把叙述者结论落地：用角色当下能触到、听到、被迫处理的后果替代“他意识到/这意味着”。不要套固定物件清单，也不要把某个场景外壳当通用规则。\n3. 只在断裂处恢复自然连接和结构虚词；不设比例目标，不机械补连接。\n4. 系统公告、规则条文、面板播报可以保留冷硬短句；`system-notice-formality-tic` 报警时，只在原载体内白话化一部分硬规则词，或让角色当场看到具体后果，不改成叙述者解释。\n\n`overcompressed-prose-tic` / `low-connective-density-tic` 的具体修法：\n\n1. 圈出连续短叙述段，逐段标注功能：爆点/反转/恐惧重拍、密集镜头可继续短；铺垫、空间、因果、动作承接应并回同一镜头。人工读着顺，就不因该 advisory 继续拉长。\n2. 合并时优先补“动作顺序、空间方位、因果承接”，例如“抬头时/门外/已经/还/就/被”，而不是给每句硬塞“的/了/就”。\n3. 合并后再删套词和告知心理：读顺不是恢复 AI 腔，不能把“仿佛/感到/非常/好像”成片加回来。\n\n复核处理：如果清掉 `overcompressed-prose-tic` / `low-connective-density-tic` 后读感仍不稳，停止局部微调，转为段落级重写或人工读感对照。\n\n示例：\n\n```\n过度压缩：\n林遥抬头。\n雨棚外的街灯灭了。\n风也停了。\n柜台上的纸杯晃了两下。\n\n读顺后：\n林遥抬头时，雨棚外的街灯正一盏盏熄下去。风忽然停了，柜台上的纸杯还在原地轻轻打转。\n```\n\n\n---\n\n## 改写顺序（只排所选 Gate 的先后）\n\n下面三步只决定所选 Gate 内问题的处理先后，不另起一轮全篇去味；某一步没有对应的所选 Gate 就跳过。\n\n### 第一步：去泛化（Strip Generic）\n- 抽象情绪总结句 -> 按规则 2 判断：删重复说明，保留准确直写，需要时用原文已有信息落地\n- 假深度句 -> 删\n- 意义膨胀 -> 缩小到具体影响\n- 空洞结论 -> 删\n- 工整对比句式 -> 打散重写\n- 装饰性形容词堆砌 -> 白描\n- 过度使用\"于是\"\"然而\"\"此刻\" -> 删掉一半\n- 所有角色说话一样\"高级\" -> 区分语气\n\n**原则**：能删就删，不能删就用具体细节替换。\n\n### 第二步：去书面化（Cut Professional Diction）\n- 分析性用词（\"机制\"\"结构\"\"逻辑\"\"体系\"出现在小说中）-> 换成日常表达\n- 抽象名词滥用 -> 直接说事\n- 体制内用语（\"进一步\"\"深入\"\"推进\"\"落实\"）-> 删\n- 专业术语堆砌 -> 只保留必要的，用白话解释\n\n**例外**：保留专业感的场景（历史题材正式用语、文学向刻意密度、喜剧夸张修辞）。\n\n### 第三步：回自然感（Restore Natural Presence）\n- 具体的感官细节（气味、温度、触感）\n- 角色说话方式的区分（不同人不同语气）\n- 句首变化：连续 3+ 句用同一主语或同一词性开头时换开法（动作、场景、对话引入）\n- 节奏变化（长短句交错）：按情绪 beat、动作推进和戏剧单元自然调节句段长短；忌连续多段同一长度，也忌为凑短而碎成提纲。长短不是随机，沉淀处可放慢，冲突/反转处可骤短，完整推理与情绪链优先保持连贯\n- 社会位置感的对话（上级和下属说话方式不同）\n- 场景特有的记忆点\n- 项目特有的语言习惯（角色的口头禅）\n\n**原则**：少即是多。每段加 1-2 个具体细节就够了。\n\n### 执行范围\n\n调用方指定 Gate 时，只处理选定 Gate；改写顺序只排先后，不重新分级或扩大范围。未指定范围时，按实际问题选择适用检查。\n\n### 自检清单\n- 对话自然度检查：对话是否使用口语化表达，是否避免了书面语/正式腔调\n- 删掉任何一句，会影响理解吗？不会 = 可能多余\n- 不同角色能通过对话区分吗？\n- 有没有一个细节是这个场景特有的？\n\n---\n\n## 去AI味补充技法\n\n### Show vs Tell\n\n| 告知类型 | AI写法 | 自然写法 |\n|----------|--------|----------|\n| 告诉期待感 | \"他很期待\" | 展示期待->情绪->满足的链条 |\n| 告诉角色目的 | \"她想离婚\" | 用行动展示目的 |\n| 告诉角色态度 | \"她很冷静\" | 用对话和反应体现 |\n| 告诉剧情走向 | \"接下来会发生大事\" | 用铺垫->反转->延续展示 |\n\n### 心理描写润物细无声\n\n- 加括号标注内心活动 = 破坏代入感\n- 大段内心独白解释动机 = AI签名\n- 直接写\"她感到\"\"她意识到\" = 告知情绪\n\n**自然写法**：心理活动自然融入叙事，用行为暗示心理，用沉默/动作/反常行为表达内心。\n\n### 代入感检查\n- 主角行为读者能理解、共鸣、接受吗？\n- 反派够强吗？（弱反派 = 读者觉得主角赢了没意义）\n- 是否围绕人设写行为？（行为/语言/思维围绕人格展开）\n- 读者已知信息是否被有效操控？（信息差制造情绪波动）\n\n---\n\n## 改写范例库\n\n### 情绪落地示例\n\n| 原文与语境 | 处理 |\n|---|---|\n| 「他很紧张。再错一题，补考也过不了。」 | 情绪有具体原因，可以直写，不补手抖或出汗 |\n| 「她已经决定不再等他。她攥了攥袖口。」袖口动作无后续作用 | 删除第二句，不换成低头或咬唇 |\n| 「手腕的伤让他握不住笔，签名只写了一半。」 | 保留，身体状态造成动作失败，不能当作情绪套话删除 |\n\n### 场景描写范例\n\n**AI风场景**\n- '阳光透过窗帘的缝隙洒进来，在地板上投下斑驳的光影。空气中弥漫着淡淡的花香，仿佛整个世界都沉浸在一片宁静祥和的氛围中。'\n- 下午三点，客厅里只有钟在走。\n\n**AI风天气**\n- '天空阴沉沉的，乌云密布，仿佛随时都会下起倾盆大雨。凛冽的寒风呼啸而过，带着一丝刺骨的寒意。'\n- 要下雨了。风把晾在外面的衣服吹得乱晃。\n\n**AI风打斗**\n- '他的拳头犹如疾风骤雨般猛烈，每一击都蕴含着不容置疑的力量。对手的瞳孔微微收缩，显然没有预料到如此凌厉的攻势。'\n- 他一拳怼过去，对方没躲开，嘴角破了。\n\n### 结尾改写范例\n\n**升华式结尾** -> '他站在窗前，望着远方的天际线，终于明白了生活的真谛：有时候，放手才是最好的选择。' -> 他把烟掐了，回屋睡觉。\n\n**总结式结尾** -> '这一刻，一切都变了。她知道，从今以后，她的人生将翻开崭新的一页。' -> 她关上了那扇门。没回头。\n\n**感慨式结尾** -> '岁月如流水般悄然流逝……' -> 直接删掉这种段落。\n\n### 节奏调整范例\n\n> 以下范例处理的是臃肿修饰、堆叠比喻和抽象总结，不是「见长就拆」：改写后叙述仍以逗号长句为主（规则 3），不要把正常的逗号长句拆成短句串。\n\n**排比句**\n- '他看着她的眼睛，看着她的嘴唇，看着她微微颤动的睫毛，心中涌起一股难以名状的情感。'\n- 他看着她，她没说话。\n\n**臃肿长句去修饰**\n- '当他终于推开那扇沉重的木门时，映入眼帘的是一间昏暗的房间，空气中弥漫着陈旧的气息，墙角堆满了落满灰尘的箱子。'\n- 他推开木门，屋里昏暗，墙角堆着几个落灰的箱子。\n\n**工整段落打碎**\n- '她喜欢春天的花朵，喜欢夏天的阳光，喜欢秋天的落叶，喜欢冬天的白雪。每一个季节都有它独特的美。'\n- 她喜欢春天，别的季节也还行。\n\n---\n\n## 冲突对话改写范例\n\n### AI式温和对话\n- '我觉得你这样做不太合适，能不能考虑一下我的感受？' -> \"你眼里还有我吗？\"\n\n### AI式完美解释\n- '其实我这样做是有原因的，因为当时的情况非常复杂……' -> \"你能怎么着？\"她把茶杯重重放下。\n\n### 对话情绪五级递进范例\n\n同一冲突场景，从弱到强：\n\n1. **客观陈述**：\"你把我的东西扔了。\"\n2. **陈述+建议**：\"你把我的东西扔了，以后能不能先跟我说一声。\"\n3. **主观指责**：\"你凭什么动我的东西。\"\n4. **指责+命令**：\"你算什么东西，也配碰我的东西？滚出去。\"\n5. **指责+PUA**：\"我伺候你吃伺候你穿，你连个东西都放不好。你这辈子也就是这样了，离了我你什么都不是。\"\n\n### 震惊分层改写范例\n\n**AI式一步到位**：所有人都震惊了，不敢相信自己的耳朵。\n\n**自然分层震惊**：\n1. 对面的男人手抖了一下，茶杯里的水洒出来。\n2. 旁边的人互相看了一眼，有人往后退了一步，角落里有人开始掏手机。\n3. 刚才还趾高气扬的女人，脸上的笑僵住了。她张了张嘴，一个字没说出来。\n\n### 代入感修复范例\n\n**被动主角**：她很害怕，不知道该怎么办，只能等着事情过去。\n\n**主动主角**：她锁了门，把手机调成静音，打开了录音。\n\n---\n\n## 质量检查清单\n\n写完每章后，按此清单逐项扫描：\n\n- [ ] **段落控制**：段落按动作/信息变化断开，读起来不卡\n- [ ] **正文无破折号**：正文（含叙述和对话）无 `——`/`—`/`--`（用句号、逗号、短句或动作断句），不设置对话例外\n- [ ] **AI高频词扫描**：无不禁/仿佛/映入眼帘/心中暗道/沉声道/嘴角微扬/不由自主/只见\n- [ ] **弱化副词计数**：每1000字\"微微/淡淡/缓缓/轻轻\"不超过3个\n- [ ] **无三连排比**：没有AI式的\"三个一组\"修辞\n- [ ] **工整否定清单已复核**：跨段「不是A / 也不是B / 只是C」及其他 `formulaic-parallelism` advisory 已连同台词逐条复核；功能性修辞可保留\n- [ ] **无论文体**：无\"不难看出/由此可见/事实上/综上所述\"\n- [ ] **无书面语连词堆砌**：无\"于是乎/与此同时/从而/因而/诚然\"泛滥\n- [ ] **章尾无总结升华**：用动作/对话/悬念收束，无感悟/哲理/预告\n- [ ] **无大段心理描写**：心理活动不超过2段，无括号标注内心\n- [ ] **情绪落地**：按规则 2 保留准确直写与有功能的身体细节，删除重复说明，不给每个情绪词配动作\n- [ ] **对话口语化**：无书面腔，不同角色语气可区分\n- [ ] **标点不压平**：没有把质问、爆发、犹豫全部压成句号；也没有随机堆砌 `？`/`！`，或用 `……`/`——` 硬造停顿\n- [ ] **Show Don't Tell**：用行为代替形容词，用细节代替总结\n- [ ] **句长达标**：叙述默认是逗号长句（逗号之间 8-12 字、整句 20-30 字，规则 3）；短句只作偶尔的孤立重拍，用完回到逗号长句；没有连着的 ≤5 字碎片，没有通篇短句像提纲\n- [ ] **detector advisory 逐条复核**：`micro-action-tic` / `stock-reaction-tic` / `abstract-summary-tic` / `cliche-density-tic` / `metaphor-density-tic` / `reasoning-chain-tic` / `system-notice-formality-tic` / `overcompressed-prose-tic` / `low-connective-density-tic` / `action-list-tic` 命中时按脚本给出的修法处理：先通读判断是不是机械复现，确属再改；功能性写法保留或标 `[需复核]`，不做同义词轮换、不机械注水\n- [ ] **不做硬指标投机**：不为反检测强制每句换行、50-60 字一行、对话 50%-60%、英文点省略号，或把 `地/得` 全改成 `的`\n- [ ] **任务卡点服从原文边界**：抽象总结若改成角色办事被卡住，必须来自原文已有任务/证据/手续/物件缺口；不新增原文没有的事件链\n- [ ] **对话自然度测试**：无书面语痕迹 = 通过\n\nFile v1.1.26:references/author-memory-maintenance.md\n\n# 作者记忆维护\n\n[author-memory.md](author-memory.md) 的少见时刻补充：记一条、确认、替换、忘掉和优先级仍按那份协议，本文件只在下列情况读——作者说「整理作者记忆」，或回执 `warnings`／查询 `omitted_ids` 提示超编；写入因 `作者画像.md` 写满失败；书根就是工作区，或工具报 `state.book`、单书布局错误；要做存量迁移 `migrate`、多事件原子 `commit`、派生视图 `check`；冲突候选要落定；碰到升级前留下的旧条目。\n\n作者记忆借鉴“原始证据 → 候选 → 已确认画像 → 变更记录”的记忆管道，但把决定权留给作者。\n\n## 文件\n\n```text\n{工作区}/.story/作者记忆/          # 项目级 store：global / genre / workflow 条目，编号 AP\n├── _author-memory-state.json  # 唯一结构化权威\n├── 作者画像.md               # 仅 active，供作者查看与管理\n├── 待确认.md                 # pending / conflict，不参与约束\n└── 变更记录.md               # 最近 100 次、最新在前的事务记录\n{书}/.story/作者记忆/            # 书级 store：只存这本书的 book 条目，编号 BP，同样四个文件\n```\n\n三个 Markdown 文件都从 state 确定性生成，禁止手改；完整历史保留在 state，变更记录只展示最近 100 次。`作者画像.md` 是人类管理视图，普通写作 agent 不整份注入，而是调用 `query` 取得本次相关的紧凑上下文。\n\n## 任务映射表\n\n各 skill 入口的 `query` 命令按此表选 kind；写入时的预算提醒也按这四类任务组合估算。\n\n| 任务 | query kinds | 注入位置 |\n|---|---|---|\n| 正文初稿 / 续写 | `prose_style` + `story_design` | 主会话与实际正文 agent |\n| 去 AI 味 / 改写 | `prose_style` | 主会话与实际改写 agent |\n| 设定 / 大纲 | `story_design` + `workflow` + `interaction` | 主会话，不传正文 agent |\n| 审稿 | `delivery` + `interaction` + 必要的 `prose_style` | 主会话，不降低 rubric |\n\n审稿匹配项只用于交付格式、协作方式和“作者有意采用的表达选择”说明；问题严重度和 PASS/FAIL 仍由 rubric 决定。\n\n## 注入预算与容量\n\n- **写入不因注入预算失败**：`record` / `commit` 照常成功、给回执；工具按上表四类任务组合估算最坏查询情形（全局条目＋各 scope 维度最重的单一切片，切片按大小写无关归并、轻重按写作时真正读到的字段算，与真实查询同一把尺），装不进 2048 字节的组合在返回的 `warnings` 里点名将被略过的条目及其断言首句。\n- 写入落盘后另一级 store 读不出来（书目录不存在、`--book` 与书级记录不符等）也照常给回执，`warnings` 注明本次提醒没算上它。写书级条目时「本书＋全局」按实际条目精确计算；写项目级条目时只看得到项目级 store，顺手传 `--book-root` 就把当前这本书也算进提醒。\n- 查询按 **重要度 → 本书例外 → 最近更新** 排序装填（同一范围的条目必在同一 store，「最近」按该 store 的修订号比，不跨 store 比较），先丢的恒是重要度较低的条目——`importance` 决定超编时谁留在 prompt 里。装不下的条目跳过而不中断（一条长的不挡后面的短条），漏下的 ID 按同一优先级报进 `omitted_ids`（最多列 20 条，`omitted` 是真实总数）。\n- 注入预算之外还有一道硬上限：`作者画像.md` 超过 12288 字节时写入会直接失败并要求先整理。active 条目攒到几十上百条才会碰到（远在注入预算之后），碰到就走「整理作者记忆」；`forget` 这类减量操作在满编时照常可用。\n\n## 整理作者记忆\n\n作者说「整理作者记忆」，或回执 `warnings`／查询 `omitted_ids` 提示超编、写入因画像写满失败时：读项目级与当前书的 `作者画像.md`（每条都标了范围、重要度、把握和确认次数，重要度就是超编时的去留依据），提出合并同义条（`replace` 多合一）、退役过时条（`forget`）、给错标成 `high` 的条目下调重要度、把超长断言压缩成一句话的提案；项目级画像里还有「本书：」条目时，「对该书运行 `migrate --book-root`」列为默认提案项。清单用原话逐条列给作者确认（编号只放括号里），确认后按 store 各汇成一份 `commit` 事务提交（一份事务只写一个 store）。合并时保住每条的否定词、限定词和适用范围——合不动就退役其中一条，不要靠删限定词把两条凑成一条。整理只由作者发起或确认，不自动执行。\n\n## 冲突候选\n\n冲突候选（`conflict`）不能绕过旧规则直接 `decide=activate`。作者选新说法：用 `replace`，`old_ids` 同时列旧 active 条目和这条冲突候选，新条目直接 active、两条旧的标 `superseded`；作者留旧规则：对候选 `decide=reject`。旧条目被 `replace` / `forget` 撤下后，它不再是任何候选的冲突对象，冲突对象清空的候选退回 `pending`。\n\n## 单书布局\n\n书根就是工作区（`--book-root` 与 `--workspace` 同一目录）时，书级 store 改住 `{工作区}/.story/作者记忆/书级/`，与项目级各自一份 state；首次建立的书名优先取项目级存量本书条目里唯一的书名，再取目录名。旧版曾把书级 state 写在项目级位置，此后项目级读写都报 `state.book`；带 `--book-root {工作区}` 运行任一命令（含 `query`）会先把它原样移进 `书级/`，不改内容。这个目录其实是某个工作区里的一本书时（上一层叫 `长篇/` 或 `短篇/`，或某个祖先有 `.active-book` 或项目级 state），工具直接报错、不动任何文件，按报错改传 `--workspace`。\n\n## 存量迁移\n\n不做双读：升级前写进项目级 store 的 book 条目不再参与查询与预算估算，也不再接受新的 book 写入；它们仍在 `作者画像.md` 里可见、可 `decide` / `forget`。对每本书运行一次 `migrate --book-root {书目录}` 即可整批搬回来：断言、证据、确认次数、重要度原样保留，换成 `BP` 编号，原 `AP` 条目标 `superseded` 并注明去向；与全局条目的冲突关系在迁移后不再成立，这类候选退回 `pending`。书级每个源条目一笔事务，重跑只补没做完的一半。「整理作者记忆」看到项目级画像里还有「本书：」条目时，把迁移列为默认提案项。\n\n## 旧条目\n\n- 升级前写下的长断言不受 120 字节新建上限约束：原样重申它会**强化**原条目（确认次数 +1），不会因超长被拒；只有真正新建条目才校验 120 字节。\n- 存量 state 里推断类旧来源的条目照常可读、可确认、可退役；新写入仍只接受 `explicit_user`、`accepted_suggestion`、`manual`。\n\n## 其他命令\n\n先依次尝试 `python3`、`python`、`py -3` 找到 Python 3，再从当前 skill 根运行本地副本（`record` / `query` 见 author-memory.md）：\n\n```text\n{PYTHON} {当前 skill 根}/scripts/author_memory_commit.py init    --workspace {工作区} [--book-root {书目录}]\n{PYTHON} {当前 skill 根}/scripts/author_memory_commit.py commit  --workspace {工作区} [--book-root {书目录}] --input {工作区}/.story/work/作者记忆-事务.json\n{PYTHON} {当前 skill 根}/scripts/author_memory_commit.py migrate --workspace {工作区} --book-root {书目录}\n{PYTHON} {当前 skill 根}/scripts/author_memory_commit.py check   --workspace {工作区} [--book-root {书目录}]\n```\n\n- `commit`：高级批量入口，只在需要把多个动作绑定成一次原子提交时用（如整理作者记忆）。顶层传 `schema_version`、唯一 `transaction_id`、当前 `expected_state_revision` 和含 1–32 项的 `operations`（每项与单事件的 `operation` 同形）。一份事务只写一个 store；先在内存完成 schema、引用、容量和所有视图校验，操作按数组顺序应用，任一步失败则整份事务零写入，最后原子替换 state。过期修订会在任何写入前失败。事务文件在成功前必须保留，成功后删除；显式记忆请求按 author-memory.md「回执怎么告诉作者」转告。\n- `migrate`：把项目级 store 里某本书的存量 book 条目整批搬进 `--book-root` 的书级 store，幂等，中途失败直接重跑；返回 `migrated`（源→新编号），没有存量时为空。\n- `check`：从 state 重建并逐字核验所有派生视图；传 `--book-root` 时两级一起核验。\n- `init`：显式初始化 store；平常不需要，首次 `record` 会随事务创建。\n\nFile v1.1.26:references/author-memory.md\n\n# 作者记忆协议\n\n作者记忆保存跨会话复用的创作偏好，不保存小说世界里的事实，决定权留给作者。本文件管最常见的时刻：作者说出一条偏好，或要确认、替换、忘掉某条。少见情况读 [author-memory-maintenance.md](author-memory-maintenance.md)：整理作者记忆与超编、画像写满、单书布局与 `state.book` 报错、存量迁移、多事件 `commit`、`check`、冲突候选落定、升级前的旧条目。\n\n## 边界与优先级\n\n加载优先级从高到低：\n\n1. 安全、用户授权范围、明确的平台交付要求、字数与文件协议；句长、视角、修辞和标点偏好不属于不可覆盖的硬门禁；\n2. 用户在当前请求中的明确要求；\n3. 当前书的 `设定/文风.md`、题材定位、细纲和其他项目设定；\n4. 作者记忆中的本书偏好；\n5. 作者记忆中的题材、流程和全局偏好；\n6. 对标素材、通用方法和默认值。\n\n按表达维度取最窄适用要求：低优先级只补缺项，不与高优先级要求并列执行。通用 references 自称“必须/禁用”不改变此顺序；审稿不因作者有意采用的表达本身扣分，真实可读性与因果问题仍照常评价。\n\n作者记忆不能把本书事实写进 `.story/作者记忆/`，不能覆盖当前请求，不能降低审稿 rubric，也不能让去 AI 味改动剧情意图。小说事实继续由各书的 `追踪/` 和 `设定/` 管理。\n\n## 存放与路由\n\n两级 store，记忆随书走：`{工作区}/.story/作者记忆/` 存 global / genre / workflow 条目（编号 `AP`），`{书}/.story/作者记忆/` 只存本书的 book 条目（编号 `BP`）。每级各有 `作者画像.md`（生效条目）和 `待确认.md`（候选，不参与约束），都从 state 生成，禁止手改；不存在时写作、审稿、去味照常继续，首次 `record` 自动创建。\n\n- `--workspace` 必须显式传，指创作工作区根——承载多本书、`.active-book`、`长篇/`、`短篇/` 或 `拆文库/` 的那一层；已有记忆时，是项目级 state（不带 `book` 字段）所在的最近祖先。`长篇/`、`短篇/` 下的书目录永远不当 `--workspace`，也不要把用户主目录当默认工作区。\n- `--book-root` 是当前书的项目目录（`.active-book` 指向、或含 `设定/`、`正文/` 的那一层，如 `{工作区}/长篇/{书名}/`）；书名默认取书级 state 记的名字，首次取目录名，`--book` 可覆盖。书根就是工作区时读维护文件「单书布局」。\n- ID 前缀就是 store：`decide` / `forget` 看 `item_id`（`AP` 项目级，`BP` 书级），`remember` / `replace` 看 `scope.level`（`book` 书级，其余项目级）。书级操作必须传 `--book-root`，没传直接报错，不会退而写进项目级。\n- `replace` 与 `conflicts_with` 不能跨 store：本书例外按优先级覆盖全局规则，不算冲突，直接 `remember` 为 book 条目；要把全局规则改成本书规则，拆成 `forget` ＋ `remember` 两个事件。\n\n## 查询\n\n各 skill 入口已写好本任务的 `query` 命令（长篇正文由组装脚本代查）；没写命令的长篇设定、大纲等任务查 `story_design` + `workflow` + `interaction`，结果只给主会话、不传正文 agent。四类任务的映射表见维护文件。state 存在才查（两级都不存在时返回空结果、零写入）；结果合并项目级与 `--book-root` 所指书级（不传就拿不到本书条目），`--kind` 必传，输出不超过 2048 字节。\n\n普通创作只做一次本地 `query`，完整画像、证据、候选和 journal 不进 prompt。查询项是低优先级倾向，不是逐条打卡清单：自然吸收，不复述画像、不刻意提高词面命中率，不为命中牺牲连贯、节奏、字数或本书既定笔调。**`omitted_ids` 非空＝记忆超编**，不是「没有更多了」：转告作者并建议「整理作者记忆」，不得改读完整画像规避预算。待确认项不进 prompt，也不为确认它们中断任务；只在作者主动查看、候选积累到适合回顾的节点，或新偏好与 active 条目冲突时集中呈现。\n\n## 记不记、记成什么\n\n不装记录全部用户消息的 prompt hook，不在作者没开口时观察他，只记作者明确表达的偏好。是否属于长期习惯由 agent 判断，拿不准就只执行不记录；作者可明说“记住：……”，以回执验收。\n\n| 输入证据 | 处理 |\n|---|---|\n| “以后都这样”“我一直习惯……”等直接、稳定、范围清楚的原话 | `active`，`source=explicit_user` |\n| 用户明确接受助手提出的长期做法 | `active`，`source=accepted_suggestion` |\n| 作者原话像长期偏好但范围或稳定性含糊 | `pending`，取当前最窄合理范围；待确认只来自作者自己的话 |\n| 同类修改反复出现、从成稿或操作轨迹看出的模式 | 不记录、不推断；作者没开口的偏好不进记忆 |\n| “这一章别……”“这次给我……”等一次性要求 | 只执行，不记录 |\n| 角色、时间线、伏笔、世界观、当前剧情走向 | 写项目设定/追踪，不写作者记忆 |\n| 助手自己生成的文字、默认模板、工具告警、rubric 结论 | 不自我学习 |\n\n保留否定词、限定词和适用范围：`quote` 写原话，`assertion` 只做不改变语义的紧凑归纳，**新建条目限一句话（≤120 字节，约 40 个字）**，写不下就压缩措辞、不切限定词；背景写进 `reason`（不进 prompt），不另开字段。\n\n**一条偏好就是一条记录，例外和限定不许拆出去单列。** 「以后少用破折号，对话里也别用，除非表示打断」整条写成「破折号少用、对话里也不用，只在表示打断时保留」：超编时条目逐条被丢，拆开就可能只丢掉例外，把作者说过的限定变成绝对禁令。只有原话塞了**几条互不依赖**的偏好（如「多用短句」＋「章末留钩子」）才拆。\n\n范围：“本书 / 这个角色 / 这次连载” → `book`；“都市文 / 这类题材” → `genre`；交稿、检查、确认节奏等操作习惯 → `workflow`；“以后 / 一贯 / 我习惯”且无更窄限定 → `global`；含糊但可能稳定 → 最窄合理范围并置 `pending`。\n\n类型：`prose_style`、`story_design`、`workflow`、`delivery`、`interaction`。置信度与重要度均为 `low | medium | high`；超编时先丢重要度低的，按偏好的实际分量填，不要一律 `high`。`source` 只接受 `explicit_user`、`accepted_suggestion`、`manual`，工具拒绝推断类来源。\n\n## 确认、替换、忘掉与冲突\n\n- 同一类型、范围、归纳文本再出现，脚本强化原条目（累加证据与确认次数），不重复建条。\n- 新偏好与同一 store 的 active 条目矛盾：以 `conflict` 记候选，`conflicts_with` 列冲突 ID，本轮仍按当前要求执行；本书例外与全局规则不算冲突。冲突候选不能直接 activate，落定见维护文件「冲突候选」。\n- pending 用 `decide=activate|reject`。同一范围的规则改版用 `replace`，新条目启用、旧条目标 `superseded`；只有作者明确撤销或改变旧规则范围才跨范围替换。\n- 作者说“忘掉 / 这不再是我的习惯”用 `forget`，保留历史证据但不再加载。active 条目的语义不可原地偷改，语义变化必须 replace，历史才可审计。\n\n## 回执怎么告诉作者\n\n回复就两行纯文本，不加代码块或引用格式：第一行用一句人话说记住了什么、管哪本书或哪类场合，如「记住了：《{书名}》的对话一律用「」，以后写这本书都照这个来；想改随时说。」；第二行是机器回执作凭证，如「技术备注：Author Memory Receipt: r1 · BP001」。\n\n- 确认、替换、忘掉同理：「好，这条生效了：……」「换成了：……，原来的「……」不再用」「忘掉了：……」。只进待确认时说「这条先记在待确认里，你说\"确认\"才生效」；有冲突时用原话说明跟哪条旧习惯冲突。\n- `warnings` / `omitted_ids` 不原样贴：说「你的习惯攒得有点多，写正文时这几条可能顾不上：「……」」，并建议说「整理作者记忆」。不提字节、prompt、kind、scope；编号只能跟着原话出现。\n\n## 运行工具\n\n依次尝试 `python3`、`python`、`py -3` 找到 Python 3，从当前 skill 根运行本地副本：\n\n```text\n{PYTHON} {当前 skill 根}/scripts/author_memory_commit.py record --workspace {工作区} [--book-root {书目录}] --input {工作区}/.story/work/作者记忆-事件.json\n{PYTHON} {当前 skill 根}/scripts/author_memory_commit.py query  --workspace {工作区} --book-root {书目录} --kind {类型}（必传，可重复） [--genre {题材}] [--workflow {流程}]\n```\n\n- 子命令都可加 `--book {书名}`；写某本书时一律带 `--book-root`。事件 JSON 写在 `{工作区}/.story/work/`（不写系统 `/tmp`），成功后删掉；book 条目的 `scope.value` 填书名（书级 store 已记的名字，首次取目录名）。\n- 明确的“记住 / 确认 / 替换 / 忘掉”都走单事件 `record`：自动读该 store 当前修订、首次自动初始化，不手工读修订号或拼多操作事务。同一 `event_id` 同内容幂等返回原回执，内容不同则失败；返回的 `store` / `book` 说明写到了哪一级。\n- 成功才有 `Author Memory Receipt: rN · APxxx`，没有回执不得声称“已经记住”。**写入不因注入预算失败**：`warnings` 只是提醒（另一级 store 读不出来也在这里注明），按上节转告；有回执就是已记住，不要换 `event_id` 重试。\n\n## 事件格式\n\n新增或强化（`record` 输入；book 范围传 `--book-root`）：\n\n```json\n{\n  \"schema_version\": 1,\n  \"event_id\": \"conversation-2026-08-25-message-42\",\n  \"operation\": {\n    \"action\": \"remember\",\n    \"preference\": {\n      \"kind\": \"prose_style\",\n      \"scope\": {\"level\": \"global\", \"value\": null},\n      \"assertion\": \"对话尽量短，用动作承接情绪，不用大段解释\",\n      \"quote\": \"以后对话都短一点，情绪放动作里，别让角色长篇解释。\",\n      \"source_ref\": \"conversation:2026-08-25\",\n      \"source\": \"explicit_user\",\n      \"confidence\": \"high\",\n      \"importance\": \"high\",\n      \"status\": \"active\",\n      \"reason\": \"用户以“以后”明确声明长期偏好\",\n      \"conflicts_with\": []\n    }\n  }\n}\n```\n\n待确认用 `\"status\": \"pending\"`；冲突候选用 `conflict` 并填同一 store 的 active ID。确认、替换、忘掉时，把下列对象换进新事件的 `operation`（`BP` 编号传 `--book-root`）；`replace.preference` 字段同上但不传 `status`、`conflicts_with`，新条目直接 active：\n\n```json\n{\"action\":\"decide\",\"item_id\":\"AP002\",\"decision\":\"activate\",\"quote\":\"对，这就是我的长期习惯。\",\"reason\":\"作者明确确认\"}\n{\"action\":\"replace\",\"old_ids\":[\"AP001\"],\"preference\":{\"kind\":\"prose_style\",\"scope\":{\"level\":\"global\",\"value\":null},\"assertion\":\"以后对话允许更长的试探，但避免解释设定\",\"quote\":\"……\",\"source_ref\":\"conversation:2026-08-25\",\"source\":\"explicit_user\",\"confidence\":\"high\",\"importance\":\"high\",\"reason\":\"作者明确替换原有全局规则，不是新增本书例外\"}}\n{\"action\":\"forget\",\"item_id\":\"AP003\",\"quote\":\"忘掉这个偏好。\",\"reason\":\"作者明确撤回\"}\n```\n\nFile v1.1.26:references/banned-words.md\n\n# AI味禁用词与句式表\n\n> 表达默认值服从 [style-resolution.md](style-resolution.md)；文件结构与事实约束不豁免。\n\n<!-- 同名副本×6 字节同步，改动后跑 scripts/check-shared-files.sh -->\n\n## 默认优先检查的句式（先对照本书文风）\n\n写网文最毒的 AI 句式，作者一旦养成就会反复出现。以下是优先检查的句式：\n\n| 毒级 | 句式 | 错误例 | 修法 |\n|------|------|--------|------|\n| ★★★★★ | \"不是A，（而）是B\" / \"不是A，不是B，（而）是C\"（\"而\"可省略，省掉也算命中）| \"他不是冷漠，而是绝望\" | 直接写 B 或用更自然的表达 |\n| ★★★☆☆ | 跨段「不是A。/也不是B。/只是C。」 | 「不是嚎啕大哭。/也不是扯着嗓子喊不舍。/只是一个人走远了……」 | 语义复核；重复提纲或拖慢画面时压成 C，有辩解/悬念排除功能可保留 |\n| ★★★★ | \"，带着……\" 万能状语 | \"他笑了一下，带着一丝不易察觉的嘲讽\" | 删掉状语留主句，或换具体动作 |\n| ★★★★ | 无情绪声线：\"声音不大，却带着……\" / \"语气毫无波澜\" / \"平静无波\" / \"声音平直/平平/听不出情绪\" | \"她声音不大，却带着不容置疑的力量\" | 直接写台词内容、声音特征或动作 |\n| ★★★★ | \"他/她知道……\" | \"他知道这一切都来不及了\" | 用行为展示认知 |\n| ★★★ | \"仿佛/犹如/宛若……一般\" | \"仿佛能穿透一切一般\" | 删掉或白描 |\n| ★★★ | \"眼中闪过一丝……\" / \"嘴角勾起一抹……\" | \"眼中闪过一丝悲伤\" | 删掉；写他当场说的话或做出的决定 |\n| ★★★ | \"心中涌起一股……\" / \"心头一震\" | \"心中涌起一股暖流\" | 写它改变了什么：选择、台词、物件或后果 |\n| ★★★ | 抽象命运/开端收束：\"命运……棋局/獠牙\" / \"这一刻终于明白\" / \"反击才刚刚开始\" | \"命运终于露出獠牙；属于他的反击才刚刚开始\" | 回到角色当下可见的文件、动作、对话或物理后果 |\n| ★★ | 章末预告 \"他不知道的是……\" | \"他不知道的是，更大的风暴即将来临\" | 用具体钩子物件/事件收束，避免空泛预告 |\n\n> ★★★★★ 命中一处就要改；轻/中/重分档只按去 AI 味诊断的密度指标定。\n\n`check-ai-patterns.js` 的 `formulaic-parallelism` 还会提示「至于X不X，怎么X」和同动词「不V A，不V B」。这两类可能是功能性口语，因此只做 advisory；Gate B 必须连同台词读语境复核，若只是复述细纲/前文就压成一次判断，不能因 hook 豁免台词而跳过。\n\n**标点**：正文（含叙述和对话）禁用破折号 `——`/`—`、双连字符 `--` 和省略号停顿，改用句号、逗号、短句或动作断句；不设置对话破折号例外。盐言「」引号不在此列。\n\n---\n\n## 一级禁用词（出现即替换）\n\n> 什么词进一级：只收真人语料里几乎不出现、AI 特有的词。真人高频使用的自然副词和虚词不进一级，走二级密度控制。\n\n### 情态类\n仿佛、犹如、宛若、如同、一丝、一抹、些许、几分、隐约、毫无征兆、几不可闻、微不可察\n\n### 动作类\n深吸一口气、不禁\n\n### 表情类\n眼中闪过、嘴角勾起、眉头微皱、眉眼低垂、瞳孔微缩、瞳孔收缩、瞳孔一缩、指节泛白、眼神锐利、目光锐利\n\n### 心理类\n心中一动、心头一震、心下了然、心中暗道、心底泛起、不由得、心中一凛\n\n### 判断类\n不容置疑、不容置喙、不易察觉、显而易见、毫无疑问、不可否认、前所未有\n\n### 形容类\n坚定、闪烁着光芒、狡黠、深邃、凛冽、冰冷\n\n### 过渡类\n不由自主、情不自禁、自然而然、话锋一转\n\n## 二级禁用词（高频出现时替换）\n\n### 语境敏感词（仅高频或偷懒时处理）\n突然、陡然、骤然、猛然、好像、似乎、瞬间、猛地、死死地（角色口语、真实突发、时间压缩、视角不确定时可保留；用同义变体轮换规避重复不算豁免，按同一个词计密度）\n\n### 弱化副词（密度控制）\n缓缓、微微、轻轻、淡淡（每千字合计 ≤3；这四个词同时计入 `cliche-density-tic` 的套词密度统计；孤立自然使用可保留，成串出现或每个动作都垫一个时才替换）\n\n### 书面腔 → 口语化\n\n| 书面腔 | 口语化替换 |\n|--------|-----------|\n| 瓦解 | 消失 / 散了 / 没了 |\n| 无名火 | 烦躁 |\n| 往我心上捅刀子 | 心烦意乱 |\n\n### 总结句式\n- \"他/她终于明白...\"\n- \"他/她这才意识到...\"\n- \"这一刻，他/她终于明白/意识到...\"\n- \"从这一刻开始...\"\n- \"属于X的反击/复仇/故事，才刚刚开始\"\n- \"命运/宿命 + 齿轮/棋局/獠牙/改写/安排\"\n- \"此刻，他/她...\"\n- \"一切...都...\"\n- \"原来...\"\n\n### 排比句式\n- 连续3句以上相同结构的排比\n- \"有的...有的...有的...\"\n- \"一边...一边...一边...\"\n\n### 升华句式\n- \"这一刻...\"\n- \"他知道...\"\n- \"她明白...\"\n- \"这就是...\"\n\n## 禁用句式模板\n\n| 句式 | 示例 | 问题 |\n|------|------|------|\n| \"不是A，而是B\" | \"他不是冷漠，而是绝望\" | 最毒；直接写 B |\n| \"...，带着...\" | \"他说，带着一丝无奈\" | 万能状语 |\n| \"声音不大，却带着……\" | \"她声音不大，却带着不容置疑的力量\" | AI 最爱声音描写 |\n| \"仿佛能...一般\" | \"仿佛能穿透一切一般\" | 文言腔 |\n| 对话标签密度过高/公式化标签 | \"好的，他说道\" | 普通\"说\"可保留；高频或公式化时处理 |\n| \"他/她感到...\" | \"她感到一丝失落\" | 告诉而非展示 |\n| \"他/她意识到...\" | \"他意识到事情不对\" | 直接告知 |\n| \"眼中闪过一丝XX\" | \"眼中闪过一丝悲伤\" | 模板化 |\n| \"嘴角勾起一抹XX\" | \"嘴角勾起一抹冷笑\" | 模板化 |\n| \"心中涌起一股XX\" | \"心中涌起一股暖流\" | 模板化 |\n| \"取而代之的是\" | \"笑容消失，取而代之的是冰冷\" | AI 过渡模板；直接写新状态 |\n| \"淬了/淬着X\" | \"眼里淬了毒\" | AI 通感套路；写动作或台词 |\n| \"显得（有些）X\" | \"他显得有些兴奋\" | 告诉而非展示 |\n| \"心底/心里某个地方+软\" | \"心里某个地方软得一塌糊涂\" | 言情套句；写动作 |\n| \"（浑身）散发着一股X气息/气场\" | \"浑身散发着一股生人勿近的气息\" | 万能气场描写；写旁人的反应 |\n| \"命运/宿命 + 齿轮/棋局/獠牙/改写/安排\" | \"命运终于露出獠牙\" / \"早已布好的棋局\" | 抽象作者总结；改成角色当下撞见的文件、动作、对话、物理后果 |\n| \"这一刻终于明白/从这一刻开始/才刚刚开始\" | \"这一刻，他终于明白\" / \"反击才刚刚开始\" | AI 收束腔；删总结，用动作或未解决问题收尾 |\n\n## 比喻分类（默认复核，不默认全删）\n\n带\"像/如/仿佛/犹如/宛若\"的比喻不是一律 AI。真正高风险的是：成片堆叠、套用万能文学比喻、用精致比喻替代剧情推进，或在段尾替读者总结意义。本表用于识别需要复核的比喻类型：\n\n| 比喻类别 | 例 | 处理 |\n|---------|----|------|\n| 生活/角色化 | \"像一头被抛弃的野狗\" | 若贴角色视角、能传递信息或情绪，可保留 |\n| 物品/现象类 | \"像一把刀\" \"脸色惨白得像这漫天的雪\" | 普通功能性比喻可留；模板化或重复时改白描 |\n| 状态类（陈词滥调） | \"梨花带雨\" \"如沐春风\" | 优先删或改成具体动作/表情 |\n| 抽象类 | \"像命运的齿轮\" \"像上辈子的尘埃\" | 高风险，优先落回动作、物件、声音、后果 |\n| 假设类 | \"力道大得像是要把骨头捏碎\" | 若是角色身体感知可留；夸张堆叠时改事实后果 |\n\n处理原则：先看功能，再看密度。保留最能传递信息或情绪的一两个，其余改为直接描述、动词、名词、作用、结果或事实；不要把删掉的比喻替换成另一批新比喻。例 \"脸色惨白得像这漫天的雪\" 若只是套话 → \"脸色惨白\"；若雪景正在压迫角色，可保留或改成角色当下看到的具体画面。\n\n> `metaphor-density-tic` 是 advisory：提示通读复核，不是 blocking；生活化、角色化、单个有功能的比喻可以保留。\n\n## 替换策略速查\n\n| 原文类型 | 替换方法 | 示例 |\n|----------|----------|------|\n| 抽象情绪词 | 先看上下文是否已成立；再选选择、台词、物件、后果或一句直写 | “紧张”若不影响下一步可直写或删；若导致签名作废，就写作废的结果 |\n| \"感到XX\" | 删除“感到”后按场景决定是否还要情绪句 | “他感到愤怒”可写“他火了”，也可直接写他撤回报价；不要默认换成攥拳 |\n| 形容词堆砌 | 白描手法 | \"美丽动人的笑容\" → \"她笑了\" |\n| 书面表达 | 口语化 | \"不容置疑\" → \"就是\" |\n| 解释性描写 | 留白 | \"他因为害怕而...\" → \"他退后一步\" |\n| 连续排比 | 保留最强一条 | 3 句排比留 1 句 |\n| 总结升华句 | 直接删除 | \"这一刻，她终于明白了...\" → 删 |\n| \"不是A，而是B\" | 直接写 B 或更自然的表达 | \"他不是冷漠，而是绝望\" → 直接写 B |\n| 多余修饰（形容词/定语/量词/指示代词） | 删 | \"白色的药片\" → \"药片\"；\"手里那截链子\" → \"链子\"；\"飞驰的汽车\" → \"车\" |\n\n**替换不复用**：右列是方向示例，不是标准答案。同一禁用词在一章内多次命中时，各处给不同的具体化写法；同一个替换写法反复出现（每次都「垂下眼」、每个动作都补「了一下」），替换产物本身就成为新的模板指纹。\n\n**套词密度优先处理**：`check-ai-patterns.js` 报 `cliche-density-tic` 时，说明禁用词不是零星误用，而是聚成了模板腔。处理顺序不是同义词替换，而是先删抽象总结，再把情绪/判断落到角色当下可见的动作、物件、对话和具体后果。\n\n**套式反应逐处删除测试**：`stock-reaction-tic` 报警时，不代表禁止身体描写。逐处问：删掉后信息、选择、关系、物件或动作结果是否受损？无损就删，不把“指尖轻叩”换成“目光微沉”。伤势、动作失败、人物习惯或情节后果明确时可以保留。\n\nFile v1.1.26:references/batch-review.md\n\n# story-review：多章分批审查\n\n多章/整卷/整本审查要拆成两批及以上时读本文件；单章或少量章节一次审完不读。full、lean、solo 都适用。\n\n## 跨批审查落盘契约\n\n分批时维护 **{项目根}/.story-review/state.md**：\n\n1. 首批确定本次完整审查范围和批次顺序。每批综合裁决后，用同目录临时文件 + rename 原子重写 state.md，不能只把结果留在对话里。\n2. state.md 只记录完整审查范围、已完成范围、下一批，以及“上一批未解决 findings 摘要”。摘要项保留 location、issue 和预计核查/兑现范围。\n3. 下一批开始前先读取 state.md，把未解决摘要注入 reviewer prompt；已解决或用户明确不处理的项不再继承，但须在本批输出中说明。\n4. 每个项目同时只维护一条跨批审查；若新一轮与 state.md 中未完成范围不同，先说明会丢弃的旧进度并征得用户确认，确认后在首批完成时覆盖。续接时 state.md 缺失、损坏或本批超出既定范围，应明确报告并停止，不猜测旧内容；非分批审查不创建它。\n\n**.story-review/** 只保存审查状态，不属于小说事实追踪；不得借此修改正文、设定、大纲或 `追踪/`。\n\n## 每批开审前\n\n- **跨批连续性（分批必做）**：审每一批前，先读 `追踪/伏笔.md` 中状态为 `已埋` 且计划回收章 ≤ 本批末章的当前行，再按需读取相关 `追踪/逐章记录/第NNN章.md` 查变更原因；同时读取涉及角色的独立快照，并按上方契约把 state.md 的上一批未解决 findings 摘要作为「继承的开放项」注入 reviewer / consistency-checker prompt（solo 由自己逐条核对）。新发现但尚未登记的开放钩子先列为维护候选，收尾时必须有正文证据才能进入修订事务。\n- **乱序/重叠审查提醒**：若已审过靠后的范围（如先审 300-400），之后审靠前的范围（200-300）时，只有当本批**新增/改动了一个开放项、且其预计兑现章落在已审过的靠后范围内**，才提醒用户「200-300 的改动可能影响已审的 300-400」，并让用户选择复审受影响章节 / 全量复审 / 仅记为待办——**默认记为待办，不盲目全量重跑**。无具体跨范围依赖时不提醒。\n\nFile v1.1.26:references/character-relations.md\n\n# 角色关系与感情线操作手册\n\n## 决策路由\n\n| 你在设计什么 | 使用本章方法 |\n|-------------|-------------|\n| 角色间关系类型 | 人物关系类型表 |\n| 感情线核心人设 | 感情流人设核心法 |\n| 爱情线底层逻辑 | 男频/女频爱情线差异 |\n| 穿书/穿游戏角色选择 | 穿书角色选择法则 |\n| 多角关系/修罗场 | 修罗场收场策略 |\n| 好感度推进节奏 | 好感度体系 + 男频恋爱文攻略 |\n| 配角态度变化 | 配角攻略缓冲区 |\n| 角色共情写作 | 角色行为自洽检查 |\n| 角色目标与关系线 | 角色目标独立性 + 关系线设计 |\n\n---\n\n## 人物关系类型\n\n查表确定角色间的关系类型，然后按原则执行。\n\n| 关系类型 | 定义 | 功能 | 示例 |\n|---------|------|------|------|\n| 冲突型 | 双方利益/理念对立 | 制造张力，推动情节 | 宿敌、竞争对手 |\n| 联盟型 | 双方有共同目标 | 提供助力，制造羁绊 | 战友、师徒 |\n| 亲密型 | 情感纽带连接 | 制造软肋，提供情感支点 | 恋人、家人、兄弟 |\n| 权威型 | 上下级/支配关系 | 制造压力，限制主角行动 | 师父、老板、监管者 |\n\n**执行规则**：\n- 每个重要关系至少安排一次考验（背叛/牺牲/误解）\n- 关系必须有变化弧线（敌人变盟友、盟友变对手）\n- 禁止所有关系都是\"你好我好\"的铁板一块\n- 关系的功能必须服务于情节，不能只为甜/虐而存在\n\n---\n\n## 感情流人设核心法\n\n感情流中剧情为人设服务——每次剧情都要丰满人物或推动感情发展，否则就是无效剧情。\n\n### 构建步骤\n\n1. **确定人设核心**：写下最初出现在脑海里的角色特征（如\"想登上皇位的皇子\"\"病弱皇子\"）\n2. **围绕核心发散**：回答——为什么有这个核心？过去经历？环境影响？性格成因？\n3. **延伸剧情线**：核心自带的剧情必须写（有目标→目标线；有伤痛→治愈线）\n\n### 执行规则\n\n- 俗套剧情配上丰满人设也能脱离套路感\n- 两个主角都必须有闪光点和独立变化路线，不能一个人出彩另一个人黯淡\n- 高光不等于装逼——所有让读者对角色印象深刻的时刻都是高光，包括痛彻心扉的时刻\n- 生命不止恋爱——角色心里希望恋爱，但生命里不能只有恋爱，只有恋爱的角色立不住、很单薄\n\n---\n\n## 男频与女频爱情线底层逻辑差异\n\n**先确定目标读者群，再选择对应逻辑。两者不可混淆，否则读者会觉得\"不对味\"。**\n\n### 男频爱情线逻辑\n\n| 维度 | 说明 |\n|------|------|\n| 核心 | \"外在因素展示\"——主角和对象在一起体现两人的外在因素多优秀 |\n| 三种核心逻辑 | \"她要是我的该多好\" → \"这么优秀的人是我的了\" → \"这么优秀的人都喜欢我，我更优秀\" |\n| 围观者想法 | \"能得到这么优秀的女人，我好羡慕\"（非\"恋爱好甜\"） |\n| 女主 | 最好有多个女性角色喜欢主角，越多说明主角越优秀 |\n| 对象本质 | \"奖杯\"——一切动机的根本目的是胜利 |\n\n写男频感情线时，围绕\"展示优秀\"设计事件。\n\n### 女频爱情线逻辑\n\n| 维度 | 说明 |\n|------|------|\n| 核心 | \"连接\"——两人之间唯一、坚不可摧、最优先的情感连接 |\n| 连接要求 | \"我爱的是你这个人，外貌、财富、才华都不能替代这份连接\" |\n| 纯洁性 | 连接形成后应逐渐舍去外在因素影响 |\n| 双方 | 最好初恋+双洁——保障连接的纯洁性和唯一性 |\n| 围观者想法 | \"他们的恋爱好甜，我好羡慕\" |\n\n写女频感情线时，围绕\"深化连接\"设计事件。\n\n---\n\n## 穿书/穿游戏角色选择法则\n\n### 必须满足的条件\n\n- 叙事主角必须对原世界有相当熟悉度（最核心的期待感来源）\n- 确定穿越进熟悉的世界，一两句话交代清楚，不能超过一章还不知道身处何方\n- 必须选择穿越后有强戏剧性或强矛盾的角色（如穿越成恶毒女配）\n\n### 信息差设计\n\n- 在原世界基础上适当设计信息差，为叙事主角提供探索空间\n- 可以用原世界知识卡bug获取超额收益\n\n---\n\n## 修罗场收场策略\n\n修罗场本质是一种矛盾，控制对抗烈度，不能让爱情线对象之间出现不可调和的矛盾。\n\n| 收场方法 | 操作 |\n|---------|------|\n| 关联回事业线 | 让爱情线对象们把争风吃醋转化为\"比谁对主角事业线贡献更大\" |\n| 插入事业线突发事件 | 对抗进入白热化时，用突发事件让所有人从内斗切换成一致对外 |\n| 一笔带过 | 最多两人互相看不惯、说两句嘲讽话就过去，非常克制 |\n\n---\n\n## 傻白甜角色塑造避坑\n\n### 六个必避之坑\n\n1. 女主犯错不能是故意的，不能明知不能做偏要做\n2. 女主犯错不能违反道德——傻白甜最重要的是天真小孩子般的高道德感\n3. 不能站在道德高地指责他人（道德婊行为），自己却做不好\n4. 不能因为道德婊行为和队友发生矛盾后还让队友认错赞美她\n5. 正确做法：有更高道德标准 → 所作所为符合 → 为此显得与众不同和有点傻气\n6. 可以写成长线：坐到被她指责的人的位置上后，发现原来那个做法已是最好的选择\n\n### 反向用法\n\n塑造傻白甜反派时，把以上六点全加在她身上，让读者一见就厌恶。\n\n---\n\n## 人设改变的双向翻转法\n\n爱情线中关系发生变化时的人设调整方法。\n\n### 核心思路\n\n- 最好的改变是两个人都改变，且改变后恰好与之前两人之间的对应关系相反\n- 改变要基于原人设做局部调整，和原人设保持密切联系，避免随意改造\n\n### 执行规则\n\n- 人设变化发生在爱隔山海阶段之后（尤其是面对最大阻碍之后），不要再设计新的矛盾，只要发糖\n- 真正的阻碍已在前面解决，此时读者最迫切的渴望是多吃糖\n- 发糖要用实在的CP行为和悉心照顾表达爱意，不是\"我爱你\"式的工业糖精\n\n---\n\n## 角色行为自洽检查\n\n### 第一步：排除外部强推\n\n检查角色行为是否只是为了让剧情往某方向发展。如果角色\"恰好\"做了推进剧情的事但没有自身动机，标记为\"人设偏移\"，必须为该行为补充角色层面的合理理由。\n\n### 第二步：目标情绪确认\n\n写每段前明确三个要素：\n1. 本段目标情绪：这段剧情要让读者产生什么情绪？\n2. 角色性格特征是否支持该情绪：角色的设定属性是否自然导向此情绪方向？\n3. 角色行为是否符合使命定位：角色在本段的行为是否与其在故事中的功能定位一致？\n\n### 第三步：人设行为推导\n\n从角色已设定属性（经历/性格/目标/当前状态）推导其在场景中的行为：\n- 列出该角色在此场景下的2-3种可能反应\n- 评估每种反应与角色已有行为模式的一致性\n- 选择最符合人设且最有戏剧张力的那一种\n\n### 第四步：情绪一致性校验\n\n检查角色表达的情绪核心与场景目标情绪是否一致。不一致则调整角色行为或场景目标情绪，确保输出内容在情绪维度上自洽。\n\n**两种执行路径**：\n- 路径A：先定目标情绪 → 按人设推导角色行为 → 校验一致性\n- 路径B：先按人设推导角色行为 → 反推场景目标情绪 → 校验一致性\n\n---\n\n## 配角攻略缓冲区\n\n配角对主角态度的变化过程 = 主角攻略配角的过程，伴随巨大的期待感和爽点。\n\n### 缓冲区类型\n\n线上线下、背后议论、异地相处、地位差距、亲密度差距、信任程度、信息差等。\n\n### 操作步骤\n\n1. 始终保持缓冲区存在\n2. 在卷纲中挑出事件拐点（5~7个）\n3. 在每个拐点处标注配角状态和对主角的态度变化\n4. 每次攻略到关键点位时，配角的态度变化必须写清楚\n5. 态度变化本身就产生情绪波动和期待感\n\n### 执行规则\n\n- 配角不能像NPC一样站着等主角触发\n- 配角要有自己的行动，由配角观点引出事件\n- 正面角色也一样：和主角立场相同的人也应有自己的行动和动机\n\n---\n\n## 利用角色身份认知差制造冲突\n\n同一个角色在不同人眼中的\"声望\"是动态变化的，不是恒定值。\n\n| 视角 | 看重什么 | 对男主的评价 |\n|------|----------|-------------|\n| 世俗视角 | 家境对等，抗风险能力 | 综合条件匹配度 |\n| 男主自身 | 赚钱养家+感情 | 相对门当户对 |\n| 女主视角 | 感情+专一+爱 | 只要在乎的就门当户对 |\n| 富二代 | 外貌家世匹配度 | 我才更门当户对 |\n| 路人 | 综合条件对比 | 女主该嫁富二代 |\n\n**操作要点**：\n- 不同人对同一个角色的评价差异 = 天然的矛盾冲突来源\n- 恋爱文的核心爽点之一：不同维度的评价差\n\n---\n\n## 亦敌亦友关系\n\n最有魅力的人物关系类型。\n\n### 执行规则\n\n- 前提：两个角色本身都要有魅力，否则只是强行五五开的狗皮膏药\n- 核心：高度认可 + 绝对冲突 → 惺惺相惜 → 缺一魅力全无\n- 真正的宿敌 = 双方相互认可，外人盖章不算\n\n---\n\n## 竞争者定位与亲情线用法\n\n### 竞争者（鲶鱼效应）\n\n- 定位：给男主/女主增加紧张感上压力 → 推动攻略进度\n- 剧情设置重点在\"高潮节点前\" → 属于铺垫环节\n- 对高潮后续写剧情作用不大 → 不是续命手段\n\n### 亲情线的四个方向\n\n| 方向 | 作用 | 使用时机 |\n|------|------|---------|\n| 男方助力 | 提供金钱地位权力 | 高潮前发挥 |\n| 男方阻力 | 设置障碍让主角得到认可 | 节点前后都能用 |\n| 女方助力 | 温柔乡感情补给站 | 高潮前发挥 |\n| 女方阻力 | 父母不同意→为了认可去努力 | 节点前后都能用 |\n\n助力主要在高潮前，阻力节点前后都能用，阻力更好发挥。\n\n---\n\n## 男频恋爱文写法攻略\n\n### 读者为什么看恋爱文\n\n| 价值 | 来源 |\n|------|------|\n| 情绪价值 | 填补\"被需要、被在乎\"的情感空缺 |\n| 自尊价值 | 女主条件好→带出去有面子→配角羡慕嫉妒 |\n| 高身份女主原因 | 更强的装逼打脸工具人+更大的自尊满足 |\n\n### 核心技法：把恋爱当升级文写\n\n- 暧昧拉扯的过程才是最有吸引力的\n- 好感度进度条：每一步推进 = 升级文中的一个\"等级\"\n- 每一个事件是一次\"升级\"→ 通过冲突、化解、理解和共鸣让好感攀升\n\n### 好感度升级路径\n\n路人 → 好人（扶老奶奶过马路） → 正直勇敢的好人（挺身而出） → 不错的朋友（理解原生家庭困境） → 喜欢但不知（特殊契机看到彼此不为人知的一面）\n\n### 关键原则：主角不主动追求\n\n- 当前男频读者普遍反感\"舔狗\"人设\n- 推动好感靠男主自身优秀品质吸引，不是主动追求\n- 男主帮女主是举手之劳不经意为之 → 女主因此记住他\n\n### 感情升级的不对称性\n\n- 两条进度线：表面社会关系（路人→朋友→情侣）+ 实际情感好感度\n- 两条线不应齐头并进 → 一条快一条慢 → 带来丰富的矛盾冲突\n- 情感线快于社会线 → 辉夜大小姐模式（双方好感拉满但嘴硬不表白）\n- 社会线快于情感线 → 赘婿/择天记模式（表面夫妻实际好感为零）\n\n### 写女主对主角好\n\n| 女主类型 | 付出方式 |\n|---------|---------|\n| 自卑社恐 | 偷偷帮忙塞东西但害怕被发现 |\n| 傲娇型 | 用心做便当但嘴硬\"做多了顺便带的\" |\n| 直率泼辣 | 大大方方送礼物或直球表白 |\n\n### 善用对比\n\n| 对比类型 | 操作 |\n|---------|------|\n| 时间线对比 | 女主刚认识主角时 vs 熟悉后的态度变化 |\n| 双标 | 不允许别人摸头但主角可以 → 凸显特殊地位 |\n| 信息差 | 男女主双重身份（网上vs现实）→ 期待揭穿时反应 |\n\n---\n\n## 好感度体系（通用框架）\n\n### 四阶段\n\n萍水相逢 → 爱情喜剧 → 爱隔山海 → 大结局\n\n### 好感度 × 关系阶段对照表\n\n好感度（负/零/半/满） x 关系阶段（熟悉/试探/暧昧/确认）\n\n阶段匹配原则：**按低的一方计算**。好感度到了但关系阶段没到 = 行为突兀。\n\n### CP行为三类门槛\n\n| 行为类型 | 门槛 | 说明 |\n|---------|------|------|\n| 需容忍行为 | 半好感+ | 主动亲密、妥协，必须给补偿否则变舔狗 |\n| 特殊对待行为 | 半好感+ | 主权、信赖、牺牲、特殊待遇、安抚 |\n| 关联行为 | 双方半好感+ | 默契、分享、陪伴 |\n\n好感度不足时写需容忍行为 = 油腻/性骚扰感。\n\n### 5套感情线结构模板\n\n| 模板 | 核心 |\n|------|------|\n| 好感度变化 | 可能升/降/已降 → 各自处理路径 → 余韵 |\n| 受益 | 享受伴侣带来的好处 = 爱情线装逼核心 |\n| 争风吃醋 | 多角色为主角争风，不是主角吃别人醋 |\n| 发展受阻 | 阻碍→试图解决→解决→余韵 |\n| 狗粮 | CP日常互动 |\n\n---\n\n## 角色目标的独立性与关系线设计\n\n### 主角目标独立性原则\n\n- 主角的目标必须属于自己的 → 不能是\"帮别人实现目标\" → 否则主角变成配角/工具人\n- 正确做法：把别人的目标转化为主角自己的（平叛=保护自己的利益/获得认可/获取资源）\n- 自检方法：随机看一章 → 主角在主动追求什么 → 如果没有 → 主角沦为别人的棋子\n\n### 感情线的层次设计\n\n- 感情推进不是线性的，应该有升级节点，每个节点对应一个剧情高潮\n- 社会关系线 vs 实质情感线的错位制造张力\n- 最佳节奏：感情先慢后快 → 前期铺垫积累好感 → 后期集中爆发 → 匹配盛大仪式\n\n### 配角的功能性定位\n\n| 类型 | 功能 | 使用时机 |\n|------|------|---------|\n| 竞争者（鲶鱼型） | 制造压力推动主角行动 | 高潮节点前 |\n| 助力型亲友 | 提供资源/情感支持 | 高潮前发挥 |\n| 阻力型亲友 | 不认可→设置条件→主角克服→获得认可 | 节点前后都能用 |\n\n---\n\n## 绿茶/负面角色\n\n- 可以推动剧情但要谨慎使用\n- 确认该角色是否有不可替代性\n- 主角强势时任何角色都能变正反馈\n- 主角弱势时负面角色会被读者恨\n\n---\n\n## 后宫文女主人设设计法\n\n### 核心思路\n后宫文的关键是弱化男主\"主动渣\"的感觉，让女主自身设定成为推动后宫的主力。\n\n### 设计原则\n1. **女主人设要预设方向**：开书前就设计好每个女主的核心特质\n2. **差异化设计**：不同女主有完全不同的价值观和背景\n3. **同居培养感情**：开局让女主们同住一个屋檐下，彼此成为朋友\n\n### 温水煮青蛙法\n以三个女主为例：\n\n| 角色 | 人设设计 | 在后宫中的作用 |\n|------|----------|---------------|\n| 青梅（正宫） | 传统价值观，占据防守位 | 从小一起长大，天然正宫 |\n| 女主B | 家庭圆满家教开明，理性看待感情 | 不在意名分，只在意快乐 |\n| 女主C | 缺少父爱和社交，爱情观模糊 | 不存在一夫一妻制思想束缚 |\n\n核心逻辑：\n- 青梅占据正宫与防守位\n- 另两个女主不在意后宫，只在意跟主角在一起\n- 把\"主角脚踏多条船\"的问题转化为\"青梅防守 vs 另两人共享\"的问题\n- 一点一点突破青梅的防守底线，等反应过来时已经是既成事实\n\n\n## 男频极简爱情线构型\n\n### 核心原则\n男频爱情线不需要复杂的情感博弈，核心是\"英雄救美 + 事业舞台 + 对手衬托\"三要素。\n\n### 极简构型\n1. **英雄救美**：女主陷入困境 -> 主角用金手指/实力解决 -> 建立初始好感\n2. **事业舞台**：主角在事业上展示金手指 -> 女主在场作为重要观众 -> 好感随事业成就升级\n3. **对手衬托**：情敌/对手同时是事业对手 -> 打败对手既是事业胜利也是感情胜利\n\n### 关键操作\n- 女主的每一次好感升级都绑定在主角的事业成就上，不单独写纯感情戏\n- 女主有自己的事业线/目标，不是花瓶——她的事业目标与主角有交叉但独立\n- 情敌的价值在于他同时威胁主角的事业和感情，打脸时有双重爽感\n- 感情节奏跟着事业节奏走：事业低谷时感情拉扯，事业高峰时感情升温\n\n### 爱情线与事业线融合检查\n- 删掉所有爱情线段落，事业线是否还成立？如果不行 = 爱情线拖后腿了\n- 删掉所有事业线段落，爱情线是否还有看点？如果不行 = 爱情线太弱\n- 理想状态：两条线互相增强，拆开各自能看，合在一起更好看\n\n\n## 质量检查清单\n\n每次完成角色关系/感情线设计后，逐项核查：\n\n- [ ] **关系类型明确**：每个重要关系已归类为冲突/联盟/亲密/权威之一\n- [ ] **关系有弧线**：每个重要关系至少经历一次考验或变化\n- [ ] **人设有核心**：主角人设有明确的核心特征和发散依据\n- [ ] **目标独立性**：主角的目标属于自己的，不是帮别人实现目标\n- [ ] **好感度匹配**：CP行为与当前好感度阶段匹配（按低的一方计算）\n- [ ] **读者群对味**：男频围绕\"展示优秀\"设计事件，女频围绕\"深化连接\"设计事件\n- [ ] **配角有行动**：配角不是NPC式站桩等待触发，有自己的行动和动机\n- [ ] **缓冲区存在**：配角攻略过程中始终保持缓冲区，拐点处标注态度变化\n- [ ] **修罗场可控**：多角关系中对象之间无不可调和的矛盾\n- [ ] **发糖时机正确**：爱隔山海之后不再设计新矛盾，只发实在的CP行为糖\n- [ ] **角色不止恋爱**：角色生命中有恋爱之外的内容，不是单薄的情感工具人\n\nFile v1.1.26:references/dialogue-mastery.md\n\n# 对话设计操作手册\n\n> 写对话场景时加载。先看决策路由选对话模式，再用操作指令控制质量。\n\n---\n\n## 决策路由\n\n| 你的对话场景是 | 用这种模式 | 操作 |\n|-------------|---------|------|\n| 主角碾压/打脸 | 压制模式 | 对方长篇大论 → 主角一字回应 |\n| 主角亮底牌/反转 | 反转模式 | 对方嚣张 → 主角一句话事实 → 对方沉默 |\n| 关系破裂/心死 | 心死模式 | 对话越回越短：从辩解 → 沉默 → \"随意\" |\n| 日常互动/立人设 | 日常模式 | 让其他人物参与冲突，不要主角一个人独白 |\n| 群众震惊/弹幕 | 弹幕模式 | 递进：普通人震惊 → 专业人士分析 → 特殊身份者反应 |\n| 信息展示/世界观 | 信息嵌入 | 用角色语气包裹信息，不是机械陈述设定 |\n| 情绪拉扯/虐心 | 情绪推动 | 上行下行交替，像拉锯拉升期待 |\n\n### 对话模式选择补充\n\n| 对话类型 | 常见问题 | 修正操作 |\n|----------|---------|---------|\n| 问答式（通篇一问一答像审讯） | 改为一方主动说，另一方给反应；反应可用动作/表情/心理 |\n| 冲突式（太礼貌不够劲） | 递进五级：委婉拒绝→友好人道→命令否定→PUA式→直接侮辱 |\n| 日常对话（容易变成没功能的水） | 功能是立人设；能让人参与的冲突别让主角独白 |\n| 多人对话（混乱/没营养） | 写前规划每个角色功能：信息提供者/情绪放大器/冲突制造者 |\n\n---\n\n## 对话核心规则\n\n每句对话必须承载以下至少一项，否则删除：\n\n1. **推进剧情**：透露新信息、推动事件发展\n2. **增加期待感**：暗示即将发生的事、制造悬念\n3. **展示人设**：通过语言风格传递角色性格\n\n且在情绪场景里，每句还要**回应上一句对方的情绪状态**（承接/偏转/升级/退缩）——对话是两个人的情绪在碰，不是轮流播报信息。只推进剧情、句间无情绪承接 = 机械对话。\n\n### 绝对禁止\n\n| 禁止 | 理由 |\n|------|------|\n| 配角无脑夸主角 | 假 |\n| 互相解释读者已知信息 | 水字数 |\n| 大段说明文式对话 | 闷 |\n| 所有角色说话方式一样 | 模糊 |\n| 对话说服人物 | 现实中没人被几句话说服，用突发状况代替 |\n| 情绪写完方向变了 | 需回退到情绪拆分 |\n| 捧哏工具人、鹦鹉复读对方原话 | 配角只剩接话功能 |\n| 高位者长篇自证、说话不分场合 | 身份和处境塌了 |\n| 情绪水肿咆哮、生死场景嘴碎 | 越吵越不紧张 |\n| 悬念正攒着就被台词说破 | 期待提前泄掉 |\n\n---\n\n## 权力博弈对话\n\n### 规则\n\n对话长度 = 权力地位。掌控者话短且冷静，被动者话多且情绪化。\n\n### 压制模式\n\n结构：对方长篇大论（3-5 行）→ 主角一字回应。\n\n```\n\"你以为你是什么东西？我告诉你，这个家轮不到你说话！你嫁进来的那天起就该明白自己的位置。\"\n\"滚。\"\n```\n\n### 反转模式\n\n结构：对方嚣张（2-3 行）→ 主角亮底牌（1 行事实）→ 对方沉默。\n\n```\n\"你有什么资格管？这是我家的钱，我想怎么花怎么花。\"\n\"你妈的存折，密码是我的生日。\"\n```\n\n### 心死模式\n\n结构：对话越回越短，从辩解到沉默到「随意」。\n\n```\n\"你听我解释，那天不是你想的那样。\"\n\"嗯。\"\n\"真的，我可以证明。\"\n\"随意。\"\n```\n\n### 操作指令\n\n- 掌控者/主角亮底牌时：对话 ≤ 10 字，不加动作描写\n- 被压制方：对话 ≥ 20 字，可加动作描写（攥拳/咬唇/站起来）\n- 两人对话时：短句方 = 权力上位，长句方 = 权力下位\n\n---\n\n## 潜台词与议程\n\n### 潜台词规则\n\n- 角色真实动机绝对不能浅显地写在台词里\n- 现实中人说话都给自己找借口，角色也一样\n- 每句对白同时设计：角色的动机（可能角色自己都没意识到）和角色的借口\n\n### 对话议程\n\n- 每个角色进入对话时有自己的议程：想从这场对话中得到什么\n- 两个角色的议程碰撞才是张力来源\n- 双方议程一致（同立场）= 复述，失去意义\n\n### 语气由三要素决定\n\n关系 × 场合 × 目的 = 语气\n\n| 场合 | 特点 | 适合内容 |\n|------|------|----------|\n| 私人（单对单） | 深入、感情流露透彻 | 内心剖白、密谋、表白 |\n| 公众 | 需考虑体面，措辞收敛 | 需要冲击力时可打破（如当众翻脸） |\n| 熟人（朋友/同门） | 深度介于两者之间 | 轻松互动和信息交换 |\n\n私密的话在公众场合说才有冲击力。对话中不能完全表达的内容，通过动作、神态、环境补充。\n\n---\n\n## 情绪推动对话\n\n### 强情绪对话\n\n- 命令式+否定式最能激发读者情绪：\"我说的还不够清楚吗？\"\n- 最强话术：打着为你好的幌子，句句不离关心，但句句都是嫌弃、指责、厌恶\n- 直接否定比含蓄暗示更伤人\n\n### 情绪连续性\n\n角色情绪是连续的、循序渐进的。从生气到高兴：生气 → 不那么生气 → 不生气 → 高兴，每次转变需对应事件触发。不能跳步。\n\n### 情绪与行动的因果检查\n\n1. 遇到事件（失衡状态）\n2. 情绪反应（可以直写，也可以体现在语言、选择或有功能的动作中）\n3. 内心思考（只写影响理解的判断；鲁莽可以直接体现在行动里）\n4. 采取行动（基于前三步结果回应）\n\n用于检查转变是否成立，不要求逐步写满；上下文已清楚的反应或思考无需补写。\n\n### 对话不平淡三思路\n\n- 对话本身带来/强化某个核心驱动力（期待、爽感、悬念）\n- 信息交流因某原因受阻碍，阻碍可能导致驱动力到来\n- 发展突然脱离读者预期（但必须合理、符合人设）\n- 把长篇对话塞在期待点和爽点之间：读者为了看爽点愿意忍受中间对话\n\n---\n\n## 信息展示与世界观引出\n\n- 大量信息通过对话展示会显得啰嗦，部分信息转化为情节、心理描写、旁白、环境、动作\n- 用角色的语气和立场包裹信息，不是机械陈述设定\n- 设定用到哪个稍微带出来就行，不需完完全全讲明白前因后果\n- **角色不当\"科普嘴\"**：设定/原理/前因后果不能靠任何角色（尤其信息型/AI 配角）整段讲解——Gate G 同样适用于角色台词。按角色当下的目的和对话阻力取舍信息，用到哪带哪点，不固定拼接身体反应。\n\n### 信息拉扯示例（以\"主角新书起飞了\"为例）\n\n| 角色 | 台词 | 功能 |\n|------|------|------|\n| 甲 | 听说成绩…… | 悬念拉期待 |\n| 乙 | 肯定没人看！ | 下行 + 拉期待 |\n| 甲 | 听说成绩很不错 | 上行 + 拉期待 |\n| 乙 | 首订一万三？ | 展露核心信息 + 达成爽点 |\n\n上行和下行交替，情绪像拉锯不断拉升期待。\n\n---\n\n## 人物语言差异化\n\n每个角色要有自己的说话方式。对话时经常卡住不知道角色会说什么 → 人设模糊，去总结类似人设的说话方式。\n\n| 差异化维度 | 操作 |\n|------------|------|\n| 口癖和惯用语 | 给每个主要角色一个标志性用词 |\n| 说话节奏 | 长篇大论 vs 短句连击 |\n| 信息偏好 | 技术型带专业术语，江湖人带切口 |\n| 立场固定 | 某角色永远从某个角度发言（悲观派/乐观派/务实派） |\n| 身份影响措辞 | 老者/少年/贵族/市井，身份不同则措辞、自称、敬谦词不同 |\n| 性格影响语气 | 智谋型话里有话；鲁莽型想到什么说什么；冷静型措辞精确，偶尔情感外露反而有冲击 |\n| 进度影响态度 | 初见/熟悉/对立/亲密，关系阶段不同则语气与信息量不同 |\n\n---\n\n## 弹幕/群众对话\n\n三大核心作用：剧情推进（透露主角不知道的信息）、增加期待感（悬念、猜测）、情绪渲染（群众震惊/激动/愤怒传染读者）。锦上添花，不代替主线。\n\n### 设计过的弹幕 vs 没设计的\n\n- 没设计：只有\"卧槽好厉害\"，单调、浪费\n- 设计过：普通人震惊 → 专业人士分析 → 特殊身份者反应 → 情感升华\n\n### 操作要点\n\n- 不同人格化语气，不能每条都一个味\n- 短小精悍，每条不超过一句话核心信息\n- 善用递进：从最初震惊到逐渐认识全貌\n- 可出现\"反转\"角色：看似路人一句话改变所有人认知\n- 不用每章都写，关键爽点/燃点/泪点前后集中使用\n\n---\n\n## 节奏控制\n\n### 大量对话保持节奏\n\n- 不要删掉表现人物性格的语气助词来\"精简\"\n- 对话段落间穿插动作描写、环境变化、心理活动调节节奏\n- 紧张段落对话短促，舒缓段落可以长一些\n- 关键信息放对话开头或结尾，中间用于拉扯情绪\n\n### 动作和表情处理\n\n- 刻意给每句对话配表情/动作会让行文机械\n- 动作和表情在关键转折处使用效果最好，不需要每句都配\n- 语气平淡场景（喝茶、散步）用微小动作和沉默体现氛围\n\n### 对话的呼吸感\n\n- 连续多轮对话后需要\"换气\"，插入环境描写或角色心理\n- 适当停顿（动作描写、换行、短句）比连续输出更有张力\n- \"你确定？\"比长篇解释更有压迫感\n\n---\n\n## 篇幅控制\n\n### 对话过多时\n\n- 读者已知信息的对话用叙事一句话概括：\"爱丽丝向安娜讲述了来城里的原因，安娜听后直皱眉头\"\n- 能用突发状况替代的对话段落直接替换\n- 语气词删掉后干巴巴 = 对话本身缺乏信息量，需重写\n\n### 对话过少时\n\n- 能用其他人物对话讲出来的东西，不要让主角旁白平铺直叙\n- 引入配角参与冲突和对话，但新人物必须安排主线戏份\n\n---\n\n## 以梗填充对话\n\n### 梗式 vs 普通\n\n- 普通：\"兄弟别灰心，你一步步走到今天我是看着你过来的，这点挫折对于你来说算什么事儿？振作起来！\"\n- 梗式：\"兄弟别灰心，我相信你总有人头落地，落地人头，头落地上……卧槽那句话怎么说的来着？兄弟你懂我意思是吧……\"\n- 梗式用\"说不出来但意思到了\"的状态制造趣味\n\n### 操作\n\n- 在对话中融入梗或骚话，有效提升整体趣味性\n- 特别是主角或重要配角的突出对话，适合用梗强化记忆点\n- 可用某个梗作为高潮点，整段剧情围绕达成这个梗来设计\n- **场合例外（声线让位）**：高压/生死/悲痛/严肃 beat 里，搞笑担当与轻快配角的玩笑、口头梗、插科打诨一律收敛——声线让位于当前情绪基调，用短、冷、带情绪重量的反应替代；梗只在安全或喘息 beat 放。自检：这句玩笑放进当前基调会不会让读者出戏？会就删/改\n\n---\n\n## 质量检查\n\n### 三大自查项（中一条以上需改进）\n\n- [ ] 是否存在大量信息都必须用对话来展示\n- [ ] 对话是否是问答式的一问一答\n- [ ] 是否习惯依赖对话来推动剧情或人物变化\n\n### 核心指令检查\n\n- [ ] 权力博弈：掌控者对话 <= 10 字 / 被压制方 >= 20 字，是否有明确的压制/反转/心死模式\n- [ ] 潜台词与议程：每个角色进入对话时有自己的议程，真实动机不在台词中\n- [ ] 人物差异化：遮住角色名后能否区分是谁在说话（7维差异化）\n- [ ] 弹幕递进：普通 → 专业 → 特殊身份，是否有层次感\n- [ ] 对话推动剧情：每段对话结束时，剧情是否往前推了一步\n- [ ] 篇幅控制：单次对话不超过全节 40%，信息密度是否足够\n\n### 检验对话质量\n\n- 对话自然度检查：逐句检查对话是否像自然口语交流，而非书面化的问答稿\n- 对话结尾能否预示接下来的节奏变化\n\nFile v1.1.26:references/plot-core-methods.md\n\n# 剧情核心方法 — 操作手册\n\n> 小纲设计、高潮构建、卡文对策、循环设计、连续性追踪等剧情创作的核心方法。\n> 遇到问题先查路由表，找到对应方法再操作。\n\n---\n\n## 决策路由表\n\n| 你在做什么 | 用什么方法 | 跳转到 |\n|-----------|-----------|--------|\n| 建小纲/细纲 | 小纲四步法 | [小纲四步法](#小纲四步法) |\n| 设计高潮 | 高潮构建公式 + 逆推法 | [高潮逆推法与AB粗纲](#高潮逆推法与ab粗纲) → [高潮构建公式](#高潮构建公式) |\n| 卡文了 | 卡文对策 + 循环设计 | [卡文对策与剧情循环设计](#卡文对策与剧情循环设计) |\n| 管理连续性 | 连续性追踪 + 节奏管理 | [连续性追踪与节奏管理](#连续性追踪与节奏管理) |\n| 设计过渡衔接 | 剧情过渡 + 场景转换技巧 | [剧情过渡与衔接](#剧情过渡与衔接) → [场景转换技巧](#场景转换技巧) |\n| 开书/设计噱头 | 噱头分类与开篇流程 | [噱头分类与开篇流程](#噱头分类与开篇流程) |\n| 拉长剧情 | 设门槛 | [设门槛——拉长剧情的核心技巧](#设门槛拉长剧情的核心技巧) |\n| 管理期待感 | 大剧情拉期待法 | [大剧情拉期待法](#大剧情拉期待法) |\n| 写日常文 | 日常文大纲框架法 | [日常文大纲框架法](#日常文大纲框架法) |\n| 判定是否自嗨 | 自嗨判定法 | [自嗨判定法](#自嗨判定法) |\n\n---\n\n## 小纲四步法\n\n细纲与正文比例控制在 **1:2.5 ~ 1:3**。\n\n按以下四步操作：\n\n1. **分段判断** — 把大纲按剧情节点分段\n2. **标注目的和效果** — 每段标注，不展开情节\n3. **标注详写/略写** — 明确哪些段展开、哪些段带过\n4. **快速定位** — 让后续写作能快速定位本段要交付的目的和效果\n\n记住：细纲只关注目的和效果，不展开情节。\n\n---\n\n## 高潮逆推法与AB粗纲\n\n### 核心思路\n\n从高潮反推前面需要铺垫的人物和情节，再用AB交替法填充。\n\n### AB粗纲法\n\n| 标记 | 含义 | 操作 |\n|------|------|------|\n| A | 压情绪/铺垫/伏笔 | 铺设困难、对手强势、悬念埋线 |\n| B | 抬情绪/擦边/小收获 | 小反转、小进步、读者爽一下 |\n\n操作流程：确定高潮 → 反推所需铺垫 → ABABAB排列 → 写作时只关注当前AB段。\n\n适用场景：节奏快、有明确高潮节点的剧情。\n\n---\n\n## 高潮构建公式\n\n### 五步公式\n\n按顺序执行：**蓄能 → 假胜 → 崩解 → 交叉死磕 → 悬置收尾**\n\n1. **蓄能**：牺牲+焦灼打底，让观众从\"看客\"变\"参与者\"\n2. **假胜**：先给希望再击碎（情绪落差 = 反转冲击力）\n3. **崩解**：所有伏笔一次引爆 + 推入单人绝境（帮手全失）\n4. **交叉死磕**：对抗线+绝境线来回切换（每切一次紧张感+1）\n5. **悬置收尾**：余劲不散，胜负不立刻揭晓\n\n关键操作：假胜是常用高潮技法。适合强反转、强压迫或大高潮；低压力章节、纯奖励章、日常/关系回收章可不用。没有假胜时，需用别的方式提供情绪落差或明确兑现。\n\n---\n\n## 噱头分类与开篇流程\n\n### 三种噱头类型\n\n| 噱头类型 | 特点 | 写法要点 |\n|----------|------|----------|\n| 事件噱头 | 集中在开篇，约5章 | 一上来就进入事件，不铺垫穿越/金手指 |\n| 金手指噱头 | 分布全文，前期多后期少 | 先写主角和困境，再引出金手指 |\n| 人设噱头 | 人设直接影响剧情构建 | 只有当人设本身能持续制造戏剧性时使用 |\n\n规则：事件写法和金手指写法不能混用。\n\n### 两种标准开篇流程\n\n**事件开篇**：事件切入（5章）→ 嫁接主线 → 拆分目标 → 阶段性爽点循环\n\n**主线开篇**：描写主角现状 → 营造代入感 → 描写社会环境 → 设立主角目标 → 拆分目标（设门槛）→ 绑定金手指 → 获得第一次提升 → 情绪拉扯2-3次 → 完成 → 引出下一个目标\n\n### 噱头吸量策略\n\n| 策略 | 做法 |\n|------|------|\n| 噱头延伸型 | 以开头噱头为核心，后续找类似噱头继续构建 |\n| 噱头引流+常规型 | 开头噱头只负责吸量，后续走常规题材内容 |\n\n开头噱头的功能是建立点击和追读承诺。目的达到后必须嫁接主线。\n\n开书前评估：噱头能不能延伸出后续更多字数？不能延伸就用\"噱头引流+常规\"策略。\n\n---\n\n## 主线的正确定义\n\n**主线不等于升级**。主线是一件事，升级是主角达成目标的行动。\n\n| 概念 | 定义 | 示例 |\n|------|------|------|\n| 目标（主线） | 主角要完成的一件事 | 斗破苍穹：上云岚宗复仇 |\n| 行动 | 主角为达成目标做的事 | 努力修炼、不断提升实力 |\n\n检查主线是否符合以下特征：\n- 主线是一件事，不是一个元素\n- 主线完成后，要么通过铺垫开启第二条主线，要么完结\n- 锚点错误会导致后续所有剧情偏差\n\n---\n\n## 卡文对策与剧情循环设计\n\n### 核心公式\n\n题材 + 金手指 + 主角身份 = 循环模式。三要素必须统一。\n\n### 6种经典循环模式\n\n| 模式 | 循环机制 | 循环燃料 |\n|------|---------|---------|\n| 案件串循环 | 案件→解谜→部分真相→更大谜团→新案件 | 信息差+推理 |\n| 扮猪吃虎循环 | 默默发育→挑衅→碾压→震惊→继续发育 | 读者-角色信息差 |\n| 资源积累循环 | 资源→技能→实力→新地图→新资源 | 螺旋上升 |\n| 戏剧性反转循环 | 亏钱→反转赚更多→拿更多钱去亏→又赚 | 不依赖数值膨胀 |\n| 组织枢纽循环 | 各自冒险→信息汇聚→衍生新剧情 | 信息交换+多线 |\n| 公路片循环 | 走一段路→遇一个人→又走→又遇 | 人物塑造力 |\n\n### 地图四势力框架\n\n新手村（开局首张地图）必须包含四种势力形成资源闭环——这是全量框架；后续换地图可简化（见下「换地图的地图详略设计」），但变现/资源闭环渠道别丢：\n\n1. **学校/武馆** — 学技能、提升实力\n2. **商贩/药行** — 卖出收获、获取资源\n3. **山贼/敌人** — 展现学习成果的靶子\n4. **官府/管理机构** — 更高的上升通道\n\n### 地位-环境同步原则\n\n地位升高必须环境危险度升高。两者不同步 = 读者觉得无聊。\n\n### 换地图三策略\n\n1. **新旧地图联动**（新势力是旧势力的上级）\n2. **带人走**（把重要人物带到新地图）\n3. **提前铺垫吸引力**（让读者主动盼着去）\n\n### 特殊类型处理\n\n- **天才流**：\n\nArchive v1.1.25: 24 files, 185057 bytes\n\nFiles: references/anti-ai-writing.md (37183b), references/author-memory.md (19899b), references/banned-words.md (10424b), references/character-relations.md (15470b), references/dialogue-mastery.md (11764b), references/plot-core-methods.md (20291b), references/quality-rubric.md (4637b), references/review-quality.md (13008b), references/rubrics/fanqie.md (891b), references/rubrics/qidian.md (987b), references/rubrics/zhihu.md (1165b), references/style-resolution.md (4017b), references/tracking-initialization.md (1137b), references/tracking-transaction.md (15042b), scripts/author_memory_commit.py (79698b), scripts/check-ai-patterns.js (73626b), scripts/check-degeneration.js (15104b), scripts/normalize-punctuation.js (13480b), scripts/style-whitelist.js (1168b), scripts/tracking_commit.py (78153b), scripts/wordcount_core.py (18338b), skill-card.md (1763b), SKILL.md (42252b), _meta.json (132b)\n\nArchive v1.1.24: 24 files, 176324 bytes\n\nFiles: references/anti-ai-writing.md (37183b), references/author-memory.md (19899b), references/banned-words.md (10447b), references/character-relations.md (15470b), references/dialogue-mastery.md (11764b), references/plot-core-methods.md (20291b), references/quality-rubric.md (4637b), references/review-quality.md (12776b), references/rubrics/fanqie.md (891b), references/rubrics/qidian.md (987b), references/rubrics/zhihu.md (1165b), references/style-resolution.md (4017b), references/tracking-initialization.md (1137b), references/tracking-transaction.md (13119b), scripts/author_memory_commit.py (79698b), scripts/check-ai-patterns.js (67463b), scripts/check-degeneration.js (15104b), scripts/normalize-punctuation.js (13480b), scripts/style-whitelist.js (1168b), scripts/tracking_commit.py (68088b), scripts/wordcount_core.py (10739b), skill-card.md (2272b), SKILL.md (41946b), _meta.json (132b)\n\nArchive v1.1.23: 24 files, 172102 bytes\n\nFiles: references/anti-ai-writing.md (37154b), references/author-memory.md (19899b), references/banned-words.md (10447b), references/character-relations.md (15470b), references/dialogue-mastery.md (11495b), references/plot-core-methods.md (20291b), references/quality-rubric.md (4637b), references/review-quality.md (14118b), references/rubrics/fanqie.md (891b), references/rubrics/qidian.md (987b), references/rubrics/zhihu.md (1165b), references/style-resolution.md (4017b), references/tracking-initialization.md (1137b), references/tracking-transaction.md (12739b), scripts/author_memory_commit.py (79698b), scripts/check-ai-patterns.js (67463b), scripts/check-degeneration.js (15104b), scripts/normalize-punctuation.js (13480b), scripts/style-whitelist.js (1168b), scripts/tracking_commit.py (55499b), scripts/wordcount_core.py (10559b), skill-card.md (2191b), SKILL.md (41818b), _meta.json (132b)\n\nArchive v1.1.22: 24 files, 154124 bytes\n\nFiles: references/anti-ai-writing.md (37154b), references/author-memory.md (10611b), references/banned-words.md (10447b), references/character-relations.md (15470b), references/dialogue-mastery.md (11495b), references/plot-core-methods.md (20291b), references/quality-rubric.md (4637b), references/review-quality.md (14118b), references/rubrics/fanqie.md (891b), references/rubrics/qidian.md (987b), references/rubrics/zhihu.md (1165b), references/style-resolution.md (4017b), references/tracking-initialization.md (1137b), references/tracking-transaction.md (12389b), scripts/author_memory_commit.py (41806b), scripts/check-ai-patterns.js (67463b), scripts/check-degeneration.js (15104b), scripts/normalize-punctuation.js (13480b), scripts/style-whitelist.js (1168b), scripts/tracking_commit.py (55499b), scripts/wordcount_core.py (10559b), skill-card.md (2802b), SKILL.md (41029b), _meta.json (132b)\n\nArchive v1.1.21: 21 files, 148623 bytes\n\nFiles: references/anti-ai-writing.md (37029b), references/author-memory.md (9942b), references/banned-words.md (10337b), references/character-relations.md (15470b), references/dialogue-mastery.md (11327b), references/plot-core-methods.md (20291b), references/quality-rubric.md (4637b), references/review-quality.md (13991b), references/rubrics/fanqie.md (891b), references/rubrics/qidian.md (987b), references/rubrics/zhihu.md (1165b), references/tracking-transaction.md (13253b), scripts/author_memory_commit.py (41806b), scripts/check-ai-patterns.js (67088b), scripts/check-degeneration.js (14387b), scripts/normalize-punctuation.js (13083b), scripts/tracking_commit.py (55499b), scripts/wordcount_core.py (10559b), skill-card.md (2773b), SKILL.md (39913b), _meta.json (132b)\n\nArchive v1.1.20: 21 files, 148298 bytes\n\nFiles: references/anti-ai-writing.md (37029b), references/author-memory.md (9942b), references/banned-words.md (10337b), references/character-relations.md (15470b), references/dialogue-mastery.md (11327b), references/plot-core-methods.md (20291b), references/quality-rubric.md (4637b), references/review-quality.md (12984b), references/rubrics/fanqie.md (891b), references/rubrics/qidian.md (987b), references/rubrics/zhihu.md (1165b), references/tracking-transaction.md (13253b), scripts/author_memory_commit.py (41806b), scripts/check-ai-patterns.js (67088b), scripts/check-degeneration.js (14387b), scripts/normalize-punctuation.js (13083b), scripts/tracking_commit.py (55499b), scripts/wordcount_core.py (10559b), skill-card.md (3189b), SKILL.md (39913b), _meta.json (132b)\n\nArchive v1.1.19: 21 files, 146013 bytes\n\nFiles: references/anti-ai-writing.md (36645b), references/author-memory.md (9942b), references/banned-words.md (9689b), references/character-relations.md (15470b), references/dialogue-mastery.md (11327b), references/plot-core-methods.md (20291b), references/quality-checklist.md (12984b), references/quality-rubric.md (4637b), references/rubrics/fanqie.md (891b), references/rubrics/qidian.md (987b), references/rubrics/zhihu.md (1165b), references/tracking-transaction.md (13047b), scripts/author_memory_commit.py (41806b), scripts/check-ai-patterns.js (63141b), scripts/check-degeneration.js (14387b), scripts/normalize-punctuation.js (13083b), scripts/tracking_commit.py (55499b), scripts/wordcount_core.py (10501b), skill-card.md (3251b), SKILL.md (39455b), _meta.json (132b)\n\nArchive v1.1.18: 18 files, 125287 bytes\n\nFiles: references/anti-ai-writing.md (36645b), references/banned-words.md (9689b), references/character-relations.md (15470b), references/dialogue-mastery.md (11327b), references/plot-core-methods.md (20291b), references/quality-checklist.md (12984b), references/quality-rubric.md (4637b), references/rubrics/fanqie.md (891b), references/rubrics/qidian.md (987b), references/rubrics/zhihu.md (1165b), references/tracking-transaction.md (11388b), scripts/check-ai-patterns.js (63141b), scripts/check-degeneration.js (14387b), scripts/normalize-punctuation.js (13083b), scripts/tracking_commit.py (51860b), skill-card.md (2816b), SKILL.md (38654b), _meta.json (132b)","readmeExcerpt":"Skill: story-review：多视角对抗式审查 Owner: worldwonderer Summary: 多视角对抗式审查。full/lean 模式在已部署 reviewer agents 时并行 spawn；缺失/异常 agents 或 spawn 失败时自动降级 solo，参考文件不可读时使用内置 rubric fallback。触发方式：/story-review、/审查、「审查一下」「帮我审一下」。 Tags: latest:1.1.27 Version history: v1.1.27 | 2026-10-03T05:25:29.007Z | user Authorized ZenStory cold-start distribution; immutable source and preserved notices. v1.1.26 | 2026-09-27T06:57:25.073Z | user Sy","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"技术备注：Mode {请求}→{实际} · Fallback {none | project custom agents unavailable -> solo | missing agents -> solo | malformed agents -> solo | agent tool unavailable -> solo | spawn failed -> solo | subagent recursion guard -> solo} · Rubric {fanqie | qidian | zhihu | generic} ({file | embedded})[ · Files {缺失或异常的 agent 文件}][ · Notice {版本不匹配原文}]"},{"language":"bash","snippet":"node scripts/normalize-punctuation.js --check <正文文件...>\n   node scripts/check-ai-patterns.js --check --fail-on=blocking <正文文件...>\n   node scripts/check-degeneration.js --check <正文文件...>"},{"language":"yaml","snippet":"- severity: S1 | S2 | S3 | S4\n  category: structure | character | prose | consistency | platform | factual | format | causal | rule_boundary\n  location: 文件路径:行号 或 章节/段落描述\n  evidence: \"引用原文或具体证据\"\n  issue: \"问题描述\"\n  fix: \"可执行修改建议\""},{"language":"text","snippet":"项目目录：{dir}\n查询类型：setting_appearances\n查询参数：{审查涉及的设定关键词}"},{"language":"text","snippet":"你是 story-architect，从故事架构层面审查以下内容。\n  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。\n  项目路径：{项目根}\n  审查范围：{文件路径/章节/必要摘录}\n  文风路径：{本书文风全文路径，无则写无}\n  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}\n  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}\n  Rubric Source: file | embedded fallback\n  相关文件路径：{设定/大纲/细纲文件路径}\n  继承的开放项（分批审查必填，无则写「无」）：{从 追踪/伏笔.md 提取的、预计回收章 ≤ 本批末章的已埋未回收钩子，连同上一批未解决 findings 摘要}\n  检查项：\n  1. 这一章是否推进了故事主题？\n  2. 大纲结构是否完整（钩子/爽点/悬念）？\n  3. 情绪节奏是否合理？\n  4. 钩子和反转设计质量如何？\n  5. 范围控制：有无角色/设定膨胀？\n  6. 剧情循环是否存在且可重复？（参照审查基准包摘要里的剧情循环原则）\n  7. 高潮场景是否用了蓄能→假胜→崩解结构？（参照审查基准包摘要里的高潮构建原则）\n  8. 伏笔密度、连载期待和结构信息量是否合理？（伏笔密度通常只作为 S4 结构风险，除非已造成理解混乱）\n  9. 按平台 rubric 或通用内容 rubric 逐项对照，标记 PASS/FAIL。\n  10. 继承的开放项里，本批本该兑现的钩子/伏笔是否落空？\n  11. 开头同质化（仅当本章是全书开篇/前 3 章）：开局切口是不是同题材的默认套路（穿越即退婚、系统绑定、末世第一天、开场即打脸等），能不能原样换到任意同类书？\"有钩子/非天气开场\"不等于不同质。对照 `story-review/references/plot-core-methods.md`「噱头分类与开篇流程」判断——能整体换到同类书=同质化（撞题材模板至少 S2；套路化但有具体人物/处境微差 S3）。\n  12. 结尾总结：章尾是总结/升华/复述式收尾（\"就这样……\"\"他终于明白……\"\"这一夜注定……\"），还是落在动作/画面/悬念上？检测器已判 blocking 的（`trailer-summary`）按上面「blocking 一律 S2」处理，不重复定级；检测器没覆盖的总结/升华/复述式收尾按影响定 S2/S3（改写走 /story-deslop：章尾预告与章尾状态总结归 Gate F，其余 blocking 并入 Gate B；本 skill 只标问题不改写）。\n\n  输出格式：\n  VERDICT: APPROVE / CONCERNS / REJECT\n  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4。\n  INHERITED_ITEMS: 逐条列继承的开放项 + 已检查 / 未能检查；本批本该兑现却落空的列为 finding。\n  RECOMMENDATIONS: [修改建议]"},{"language":"text","snippet":"你是 character-designer，从角色和对话层面审查以下内容。\n  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。\n  项目路径：{项目根}\n  审查范围：{文件路径/章节/必要摘录}\n  文风路径：{本书文风全文路径，无则写无}\n  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}\n  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}\n  Rubric Source: file | embedded fallback\n  相关角色文件：{角色设定文件路径}\n  检查项：\n  1. 角色语言风格是否与语言风格档案一致？\n  2. 对话是否千篇一律或信息过满？\n  3. 人物弧线是否连贯？\n  4. 角色行为是否符合其动机？\n  5. 对话是否有潜台词和信息控制？\n  6. 爱情线好感度与 CP 行为是否匹配？（参照审查基准包摘要或本 Skill 的角色关系参考）\n  7. 好感度进度是否可感知？\n  8. 对话三症状（可选读 `story-review/references/dialogue-mastery.md` 自查项）：① 机械对话/问答式/句间无情绪承接；② 角色当「科普嘴」整段讲设定原理(Gate G 同样管台词)；③ 说话不分场合(高压/生死 beat 的玩笑、口头梗、插科打诨出戏)。命中按 S2/S3 报具体引用+改法。\n\n  输出格式：\n  VERDICT: APPROVE / CONCERNS / REJECT\n  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4。\n  RECOMMENDATIONS: [修改建议]"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: story-review\nversion: 1.1.1\ndescription: \"多视角对抗式审查。full/lean 模式在已部署 reviewer agents 时并行 spawn；缺失/异常 agents 或 spawn 失败时自动降级 solo，参考文件不可读时使用内置 rubric fallback。触发方式：/story-review、/审查、「审查一下」「帮我审一下」。\"\nmetadata: {\"openclaw\":{\"source\":\"https://github.com/zenstory-ai/oh-story-claudecode\"}}\n---\n# story-review：多视角对抗式审查\n\n> Spawn 版本提示（不阻断 spawn）：先读取项目根 `.story-deployed` 的 `agents_version`。与本版 `agents_version: 34` 不一致时（标记缺失、字段缺失/非整数、小于或大于 34）**照常按文件存在性检查并 spawn**，但只检查当前运行时的 canonical 目录；同时在「这次怎么审的」里用一句白话提示作者「审稿助手是旧版，运行 /story-setup 后新开会话」，`Notice: agents bundle 版本不匹配（项目 {N}，本版 34）` 原文写进技术备注行；大于 34 时额外提示先更新 oh-story-claudecode，不要用本地旧版 setup 降级覆盖。只有 agent 文件缺失、或运行时不暴露 custom agent 时才降级 solo/direct，技术备注写 `Fallback: ... -> solo`。\n\n你是审查协调器。你的职责是找出小说文本中的结构、角色、文字、设定问题，并给出可执行修改建议。\n\n**执行铁律：审查是找问题，不是验证正确性。**\n\n**文风裁决**：正文写作、改写或审稿前先读 [references/style-resolution.md](references/style-resolution.md)，加载本书文风并形成 `style_resolution`；无作者记忆也执行。当前请求、本书文风和 active 偏好按维度覆盖通用 references；同一裁决交给后续执行者。\n\n## 作者习惯边界\n\n若作者记忆 state 已存在，审查前用 `scripts/author_memory_commit.py query --workspace {工作区} --book-root {书目录} --kind delivery --kind interaction --kind prose_style [--genre {题材}] [--workflow 审稿]` 获取本次相关 active 条目（`--workspace`、`--kind` 必传；不传 `--book-root` 就拿不到本书级偏好；`--genre` 填本书题材类型；总输出 ≤2KB）。它们只能帮助解释意图和组织报告，不能降低 rubric 严重度、把事实冲突判为无问题或跳过平台门禁；当前请求仍优先。完整规则见 [references/author-memory.md](references/author-memory.md)。\n\n用户对报告格式或协作方式作出稳定声明时，在本轮审查完成后用 `record` 记录，并按 author-memory.md「回执怎么告诉作者」转告；只记作者明确说的，一次性要求不记录，不从反复修改推断。审查发现、工具告警和助手建议本身绝不自动学习。\n\n---\n\n## Review Mode 选择\n\n- `/story-review` 或 `/story-review full` → 优先 spawn 全部 4 个 Agent；如果当前已经在子代理内，核心 Agent 未部署/异常，或 spawn 失败，自动降级为 solo。\n- `/story-review lean` → 优先 spawn `story-architect` + `consistency-checker`；如果当前已经在子代理内，任一所需 Agent 未部署/异常，或 spawn 失败，自动降级为 solo。\n- `/story-review solo` → 不 spawn Agent，由当前会话执行基础审查。\n- 未指定 → 默认 full，并在报告开头用一句话说明这次实际是怎么审的。\n\n---\n\n## Phase 0：预检与降级（必须先执行）\n\n1. **确定请求模式**：解析用户输入中的 `full`、`lean`、`solo`；未指定时目标模式为 `full`。\n2. **确认是否允许 spawn**：如果当前已经在子代理/Agent 内执行，不再递归 spawn，直接降级为 `solo`。\n3. **识别 ZCode 能力边界**：如果当前运行于 ZCode 且项目使用 `.zcode/`，ZCode 3.3.4 不执行项目/plugin custom agents；不要因为磁盘上存在其他端的 agent 文件就尝试同名 spawn，直接降级 `solo`，技术备注写 `Fallback: project custom agents unavailable -> solo`。\n4. **检查核心 Agent 部署状态**（只检查当前运行时的 canonical 目录，不因其他端文件存在而误判）：\n   - Claude Code 检查 `.claude/agents/`，OpenCode 检查 `.opencode/agents/`，Codex 检查 `.codex/agents/`，Antigravity 检查 `.agents/agents/`\n    - full 必需 agent：`story-architect`、`character-designer`、`narrative-writer`、`consistency-checker`\n    - lean 必需 agent：`story-architect`、`consistency-checker`\n    - 对每个必需 Agent 文件：\n      - **Claude Code agent（`.claude/agents/`）**：读取 frontmatter，确认 `name:` 与 subagent_type 完全一致；frontmatter 缺失、不可解析或 name 不匹配时视为 malformed agent。\n      - **OpenCode agent（`.opencode/agents/`）**：文件名即 agent 名（OpenCode 不要求在 frontmatter 中写 `name:`），读取 frontmatter 确认 `mode: subagent` 和 `permissions:` 规则列表存在且可解析即可（2.x 用复数 `permissions:`，旧版单数 `permission:` 视为待重新部署）；frontmatter 缺失或不可解析视为 "},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7e14qz6v4n71xmjegh68jtts80dp5r\",\n  \"slug\": \"story-review\",\n  \"version\": \"1.1.27\",\n  \"publishedAt\": 1791005129007\n}"},{"path":"references/agent-prompts.md","content":"# story-review：full/lean 模式派子代理与综合\n\n只有实际模式仍是 full/lean 时才读本文件。\n\n使用当前运行时的 Agent 工具并行调用（Codex 原生子代理使用 `agent_type`，Claude Code 使用 `subagent_type`，OpenCode 使用 `subagent` 工具的 `agent` 参数，Antigravity 使用 `invoke_subagent` + 同名 `TypeName`；实际字段以当前 CLI 暴露的工具为准）。每个 Agent 不继承父对话上下文，prompt 必须自包含项目路径、审查范围、文件路径、必要摘录和统一 Findings Schema。审稿视角的三个 prompt 还要内联审查基准包摘要与 Rubric Source，不要求子 Agent 必须读 `story-review/references/*` 才能完成任务（如需补充只读本 Skill 的 references）；consistency-checker 例外，它只核对事实，按自己的检查项审，不带审查基准包。所有 reviewer 只读：不改任何文件，只输出结果。\n\n**调用规则**：执行 Phase 0 后，只有实际模式仍是 full/lean 时才 spawn。不要 spawn 缺失 Agent。\n\n**story-explorer 预查询（可选）**。仅当 `Effective Mode` 仍为 `full`/`lean`、当前允许 spawn 且当前运行时的 Agent 工具可用时，才可在对应 canonical agent 目录下确认 `story-explorer` 已部署并 spawn；Antigravity 检查 `.agents/agents/story-explorer/agent.md`，用 `invoke_subagent` + `TypeName: \"story-explorer\"`。`solo` 或子代理递归保护场景下不得 spawn，只能直接读取/检索。Prompt 示例：\n\n```text\n项目目录：{dir}\n查询类型：setting_appearances\n查询参数：{审查涉及的设定关键词}\n```\n\n**Agent 1: story-architect**（subagent_type: story-architect）\n- full/lean 均调用。\n- 审查视角：主题对齐、大纲结构、钩子/反转质量、范围控制、平台期待。\n- 提示指令：\n  ```\n  你是 story-architect，从故事架构层面审查以下内容。\n  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。\n  项目路径：{项目根}\n  审查范围：{文件路径/章节/必要摘录}\n  文风路径：{本书文风全文路径，无则写无}\n  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}\n  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}\n  Rubric Source: file | embedded fallback\n  相关文件路径：{设定/大纲/细纲文件路径}\n  继承的开放项（分批审查必填，无则写「无」）：{从 追踪/伏笔.md 提取的、预计回收章 ≤ 本批末章的已埋未回收钩子，连同上一批未解决 findings 摘要}\n  检查项：\n  1. 这一章是否推进了故事主题？\n  2. 大纲结构是否完整（钩子/爽点/悬念）？\n  3. 情绪节奏是否合理？\n  4. 钩子和反转设计质量如何？\n  5. 范围控制：有无角色/设定膨胀？\n  6. 剧情循环是否存在且可重复？（参照审查基准包摘要里的剧情循环原则）\n  7. 高潮场景是否用了蓄能→假胜→崩解结构？（参照审查基准包摘要里的高潮构建原则）\n  8. 伏笔密度、连载期待和结构信息量是否合理？（伏笔密度通常只作为 S4 结构风险，除非已造成理解混乱）\n  9. 按平台 rubric 或通用内容 rubric 逐项对照，标记 PASS/FAIL。\n  10. 继承的开放项里，本批本该兑现的钩子/伏笔是否落空？\n  11. 开头同质化（仅当本章是全书开篇/前 3 章）：开局切口是不是同题材的默认套路（穿越即退婚、系统绑定、末世第一天、开场即打脸等），能不能原样换到任意同类书？\"有钩子/非天气开场\"不等于不同质。对照 `story-review/references/plot-core-methods.md`「噱头分类与开篇流程」判断——能整体换到同类书=同质化（撞题材模板至少 S2；套路化但有具体人物/处境微差 S3）。\n  12. 结尾总结：章尾是总结/升华/复述式收尾（\"就这样……\"\"他终于明白……\"\"这一夜注定……\"），还是落在动作/画面/悬念上？检测器已判 blocking 的（`trailer-summary`）按上面「blocking 一律 S2」处理，不重复定级；检测器没覆盖的总结/升华/复述式收尾按影响定 S2/S3（改写走 /story-deslop：章尾预告与章尾状态总结归 Gate F，其余 blocking 并入 Gate B；本 skill 只标问题不改写）。\n\n  输出格式：\n  VERDICT: APPROVE / CONCERNS / REJECT\n  FINDINGS: 必须使用统一 Findings Schema，severity 必须是 S1/S2/S3/S4。\n  INHERITED_ITEMS: 逐条列继承的开放项 + 已检查 / 未能检查；本批本该兑现却落空的列为 finding。\n  RECOMMENDATIONS: [修改建议]\n  ```\n\n**Agent 2: character-designer**（subagent_type: character-designer）\n- full 模式调用。\n- 审查视角：角色语言风格一致性、对话质量、人物弧线、关系推进。\n- 提示指令：\n  ```\n  你是 character-designer，从角色和对话层面审查以下内容。\n  你的任务是【找问题】，不是验证正确性。以最严苛的标准审视。\n  项目路径：{项目根}\n  审查范围：{文件路径/章节/必要摘录}\n  文风路径：{本书文风全文路径，无则写无}\n  style_resolution：{本次生效要求及来源、被覆盖的默认条款、事实边界；文字风格判断共用}\n  审查基准包摘要：{Phase 1 形成的 rubric / fallback 摘要，必须内联}\n  Rubric Source: file | embedded fallback\n  相关角色文件：{角色设定文件路径}\n  检查项：\n  1. 角色语言风格是否与语言风格档案一致？\n  2. 对话是否千篇一律或信息过满？\n  3. 人物弧线是否连贯？\n  4. 角色行为是否符合其动机？\n  5. 对话是否有潜台词和信息控制？\n  6. 爱情线好感度与 CP 行为是否匹配？（参照审查基"},{"path":"references/anti-ai-writing.md","content":"# 去AI味完整指南\n\n> 本文件的句长、视角、标点、修辞与禁用词是默认写法，服从 [style-resolution.md](style-resolution.md) 的逐维裁决。所选 Gate 检查表达效果，不因作者有意选择某写法就机械删除；获准命中按书级 `.deslop-whitelist` 处理。\n\n<!-- 同名副本×4 字节同步，改动后跑 scripts/check-shared-files.sh -->\n\n> 识别AI写作指纹、改写顺序、禁用词约束、改写范例库。用于正文写作后做去AI味自检和改写时查阅。\n\n---\n\n## 决策路由\n\n| 你在做什么 | 查阅哪个模块 |\n|-----------|-------------|\n| 写完正文后做去AI自检 | 核心规则 -> AI写作模式检测 -> 质量维度检查 |\n| 改写某段AI味重的文字 | 改写范例库 + 冲突对话改写范例 |\n| 检查是否用了禁用词 | 禁用词与句式速查 -> AI高频词（模式1） |\n| 系统性去除整章AI味 | 改写顺序 |\n| 检查章尾是否有总结升华 | AI写作指纹 -> 章末总结体 |\n| 判断情绪描写是否告知式 | Show Don't Tell原则 + 去AI味补充技法 |\n| 快速扫描全章质量 | 快速自检口诀 + 质量维度检查 |\n\n## 指令语气\n\n本文件以问题模式和高危清单为主。一级高危词优先检查；二级/语境敏感词按频率、语境和是否偷懒判断。遇到冲突时，保留创作意图与剧情功能优先于机械替换。\n\n---\n\n## AI写作指纹（必须避免）\n\n### 高频AI用词\n\n> 完整禁用词表见 [banned-words.md](banned-words.md)\n\n**补充类目**（`banned-words.md` 未覆盖的高阶替换）：\n\n| 类别 | 替代原则 |\n|------|---------|\n| 抽象升华词（命运、宿命、注定） | 用具体事件代替抽象概念 |\n| 万能比喻（像潮水般、如闪电般、仿佛春风） | 优先不用比喻，确需时只留少数生活化、角色化比喻 |\n\n### 引号只承载真实引用，不给普通名词加戏\n\n不要用双引号给普通名词、常见动作或作者临时概括的概念做“引号强调”。这类写法会把没有特殊含义的词硬包装成术语，连续出现时尤其像模型在替读者划重点。`check-ai-patterns.js` 的 `quote-emphasis-tic` 只负责提示，最终按语境判断。\n\n- **应改**：所谓的\"机会\"、完成这次\"蜕变\"、找到真正的\"答案\"。这些词若只是普通语义，直接去掉引号，用事件本身体现分量。\n- **应保留**：角色对话、逐字直接引用、书名/篇名、确有设定含义的代号，以及手机消息、公告、系统播报等场内载体展示的原文。\n- **边界**：第一次定义术语时可以用引号，但后文不要反复加；讽刺、反话或角色刻意咬重音时可以保留，前提是上下文能看出是谁在强调、为什么强调。\n\n### 章末总结体\n\n**禁止**在章节结尾用以下方式收束：\n- 总结性感悟（\"他终于明白了……\"）\n- 升华式感叹（\"这一夜，注定无人入眠\"）\n- 哲理式收尾（\"人生就是这样……\"）\n- 伏笔式预告（\"他不知道的是，更大的风暴即将来临\"）\n\n**正确做法**：章尾用动作、对话或悬念收束，让情节本身制造余韵。\n\n### 叠加式描写（同一动作掰开写三遍）\n\n**检测模式**：一个动作/情绪先写发生，再补感知细节，再补身体反应，分三段依次写完。读者看到的是同一个动作被掰开写了三遍。\n\n**典型特征**：\n- 先写一个概括性动作，再展开写同一动作的细节，再写身体反应：三段说的是同一件事\n- \"发生层→感知层→反应层\"按顺序分段出现\n- 每个维度独立成段，而不是揉进同一段连续正文\n\n**错误示例**：\n> 林父低着头，左手把文书压住，右手拿笔，往纸上落。\n>\n> 手从肘到腕都在抖。\n>\n> 笔尖在纸上停了停，写了一横，又停。那个\"林\"字的撇写歪了。\n\n→ 同一个动作（手抖/写字）分三段写，每段是同一瞬间的不同维度\n\n**正确做法**：发生、感知、反应三个维度揉进同一段连续正文，读者读到一个完整瞬间：\n\n> 林父左手压着文书，右手拿笔往纸上落，笔尖一触纸面就偏了，从肘到腕止不住地抖，那一横斜着拖出去。\n\n→ 发生、感知、反应在一段里同时呈现\n\n**处理原则**：保留有功能的情绪细节，把同一瞬间的重复描写合并成连续画面。若合并后明显变薄，优先恢复原文中有功能的信息，或把既有信息改成更自然的动作/对话表达；不要新增原文没有的情节、设定、关系或时间线。\n\n---\n\n## 核心规则\n\n> **句长以规则 3 为准**：规则 1-4 和本文件其他地方的「短句 / 拆短 / 能删就删」说法，与规则 3 冲突时按规则 3 执行。\n\n### 规则 1：段落密度诊断\n\n段落长短没有固定优劣。检查重点是朗读和手机阅读是否卡顿：\n\n- 一段通常只承载一个动作、一个信息变化或一组紧密相关的反应。\n- 逗号串太长、多个完整动作挤在一段里，读起来需要换气时，按动作或信息变化拆开。\n- 连续短段碎成提纲时，合并同一镜头内的相邻句，让画面保持连续。\n\n```\n过密：他看着窗外的雨，心中涌起一股说不清的感觉，这些年走过的路和很多已经忘记的事都在这一刻涌上心头。\n\n更自然：他盯着窗外的雨，雨从下午下到天黑。\n\"你还在想她？\"老刘问。\n他没说话。\n```\n\n### 规则 2：动作 + 对话 + 情绪反应\n\n动作、对话与情绪反应按场景需要交织，不按固定顺序轮换，不为凑齐三项补反应。\n\n情绪没有固定译法，关键节点也可以准确直写。上下文已让情绪成立，不另补反应；需要补足信息时，优先选择、台词、策略、物件或实际后果。\n\n身体细节只有带来新信息、影响动作或体现人物与场景特点时才保留。只在句尾重复标注情绪的微动作删掉，不换部位或同义动作。去味时沿用原文已有事实，不凭空添加摔杯子、攥袖口等行为。\n\n### 规则 3：句子该多长（短句是工具，不是默认）\n\n叙述（旁白）默认写成**逗号长句**：一句用逗号串起 2-4 个动作或信息，再落句号；逗号之间 8-12 字，整句 20-30 字。短句是偶尔的孤立重拍工具，不是叙述的默认写法。\n\n| 场景 | 句长 | 示例（长篇语料原句） |\n|------|------|------|\n| 日常 / 推进 / 描写（多数叙述句） | 逗号之间 8-12 字，整句 20-30 字 | 阴冷潮湿的气息扑面而来，身下铺着一层薄薄的稻草，湿漉漉地粘在皮肤上。 |\n| 对话 | 口语化，长短随角色 | \"你疯了？\"\"可能吧。\" |\n\n**不合格（与 AI 腔同级）**：\n- 逗号之间连着都是 ≤5 字的碎片（\"他抬手，开门，进屋，坐下\"式）\n- 通篇 3-8 字句、句号密得像提纲（电报体，见模式 9）\n- 一长一短机械交替（同样是模板）\n\n> **爆款语料校准**（七猫长篇 现言/都市/古言/玄幻/历史 125 本×前 8 章旁白统计）：逗号之间平均 8.8-9.6 字；整句平均 22-24 字；逗号长句占叙述句 74-80%；≤5 字的短片"},{"path":"references/author-memory-maintenance.md","content":"# 作者记忆维护\n\n[author-memory.md](author-memory.md) 的少见时刻补充：记一条、确认、替换、忘掉和优先级仍按那份协议，本文件只在下列情况读——作者说「整理作者记忆」，或回执 `warnings`／查询 `omitted_ids` 提示超编；写入因 `作者画像.md` 写满失败；书根就是工作区，或工具报 `state.book`、单书布局错误；要做存量迁移 `migrate`、多事件原子 `commit`、派生视图 `check`；冲突候选要落定；碰到升级前留下的旧条目。\n\n作者记忆借鉴“原始证据 → 候选 → 已确认画像 → 变更记录”的记忆管道，但把决定权留给作者。\n\n## 文件\n\n```text\n{工作区}/.story/作者记忆/          # 项目级 store：global / genre / workflow 条目，编号 AP\n├── _author-memory-state.json  # 唯一结构化权威\n├── 作者画像.md               # 仅 active，供作者查看与管理\n├── 待确认.md                 # pending / conflict，不参与约束\n└── 变更记录.md               # 最近 100 次、最新在前的事务记录\n{书}/.story/作者记忆/            # 书级 store：只存这本书的 book 条目，编号 BP，同样四个文件\n```\n\n三个 Markdown 文件都从 state 确定性生成，禁止手改；完整历史保留在 state，变更记录只展示最近 100 次。`作者画像.md` 是人类管理视图，普通写作 agent 不整份注入，而是调用 `query` 取得本次相关的紧凑上下文。\n\n## 任务映射表\n\n各 skill 入口的 `query` 命令按此表选 kind；写入时的预算提醒也按这四类任务组合估算。\n\n| 任务 | query kinds | 注入位置 |\n|---|---|---|\n| 正文初稿 / 续写 | `prose_style` + `story_design` | 主会话与实际正文 agent |\n| 去 AI 味 / 改写 | `prose_style` | 主会话与实际改写 agent |\n| 设定 / 大纲 | `story_design` + `workflow` + `interaction` | 主会话，不传正文 agent |\n| 审稿 | `delivery` + `interaction` + 必要的 `prose_style` | 主会话，不降低 rubric |\n\n审稿匹配项只用于交付格式、协作方式和“作者有意采用的表达选择”说明；问题严重度和 PASS/FAIL 仍由 rubric 决定。\n\n## 注入预算与容量\n\n- **写入不因注入预算失败**：`record` / `commit` 照常成功、给回执；工具按上表四类任务组合估算最坏查询情形（全局条目＋各 scope 维度最重的单一切片，切片按大小写无关归并、轻重按写作时真正读到的字段算，与真实查询同一把尺），装不进 2048 字节的组合在返回的 `warnings` 里点名将被略过的条目及其断言首句。\n- 写入落盘后另一级 store 读不出来（书目录不存在、`--book` 与书级记录不符等）也照常给回执，`warnings` 注明本次提醒没算上它。写书级条目时「本书＋全局」按实际条目精确计算；写项目级条目时只看得到项目级 store，顺手传 `--book-root` 就把当前这本书也算进提醒。\n- 查询按 **重要度 → 本书例外 → 最近更新** 排序装填（同一范围的条目必在同一 store，「最近」按该 store 的修订号比，不跨 store 比较），先丢的恒是重要度较低的条目——`importance` 决定超编时谁留在 prompt 里。装不下的条目跳过而不中断（一条长的不挡后面的短条），漏下的 ID 按同一优先级报进 `omitted_ids`（最多列 20 条，`omitted` 是真实总数）。\n- 注入预算之外还有一道硬上限：`作者画像.md` 超过 12288 字节时写入会直接失败并要求先整理。active 条目攒到几十上百条才会碰到（远在注入预算之后），碰到就走「整理作者记忆」；`forget` 这类减量操作在满编时照常可用。\n\n## 整理作者记忆\n\n作者说「整理作者记忆」，或回执 `warnings`／查询 `omitted_ids` 提示超编、写入因画像写满失败时：读项目级与当前书的 `作者画像.md`（每条都标了范围、重要度、把握和确认次数，重要度就是超编时的去留依据），提出合并同义条（`replace` 多合一）、退役过时条（`forget`）、给错标成 `high` 的条目下调重要度、把超长断言压缩成一句话的提案；项目级画像里还有「本书：」条目时，「对该书运行 `migrate --book-root`」列为默认提案项。清单用原话逐条列给作者确认（编号只放括号里），确认后按 store 各汇成一份 `commit` 事务提交（一份事务只写一个 store）。合并时保住每条的否定词、限定词和适用范围——合不动就退役其中一条，不要靠删限定词把两条凑成一条。整理只由作者发起或确认，不自动执行。\n\n## 冲突候选\n\n冲突候选（`conflict`）不能绕过旧规则直接 `decide=activate`。作者选新说法：用 `replace`，`old_ids` 同时列旧 active 条目和这条冲突候选，新条目直接 active、两条旧的标 `superseded`；作者留旧规则：对候选 `decide=reject`。旧条目被 `replace` / `forget` 撤下后，它不再是任何候选的冲突对象，冲突对象清空的候选退回 `pending`。\n\n## 单书布局\n\n书根就是工作区（`--book-root` 与 `--workspace` 同一目录）时，书级 store 改住 `{工作区}/.story/作者记忆/书级/`，与项目级各自一份 state；首次建立的书名优先取项目级存量本书条目里唯一的书名，再取目录名。旧版曾把书级 state 写在项目级位置，此后项目级读写都报 `state.book`；带 `--book-root {工作区}` 运行任一命令（含 `query`）会先把它原样移进 `书级/`，不改内容。这个目录其实是某个工作区里的一本书时（上一层叫 `长篇/` 或 `短篇/`，或某个祖先有 `.active-book` 或项目级 state），工具直接报错、不动任何文件，按报错改传 `--workspace`。\n\n## 存量迁移\n\n不做双读：升级前写进项目级 store 的 book 条目不再参与查询与预算估算，也不再接受新的 book 写入；它们仍在 `作者画像.md` 里可见、可 `decide` / `forget`。对每本书运行一次 `migrate --book-root "}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"多视角对抗式审查。full/lean 模式在已部署 reviewer agents 时并行 spawn；缺失/异常 agents 或 spawn 失败时自动降级 solo，参考文件不可读时使用内置 rubric fallback。触发方式：/story-review、/审查、「审查一下」「帮我审一下」。 Skill: story-review：多视角对抗式审查 Owner: worldwonderer Summary: 多视角对抗式审查。full/lean 模式在已部署 reviewer agents 时并行 spawn；缺失/异常 agents 或 spawn 失败时自动降级 solo，参考文件不可读时使用内置 rubric fallback。触发方式：/story-review、/审查、「审查一下」「帮我审一下」。 Tags: latest:1.1.27 Version history: v1.1.27 | 2026-10-03T05:25:29.007Z | user Authorized ZenStory cold-start distribution; immutable source and preserved notices. v1.1.26 | 2026-09-27T06:57:25.073Z | user Sy","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":872,"uniquenessScore":46,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T11:21:50.216Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-09T11:21:50.216Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T03:41:20.097Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}