120 条案例的提示词不到 200 字符，其中七成是原帖自己就没写

Alpha Lay · 2026-09-26

案例库里有一批「提示词特别短」的记录。我们本来打算把它们当噪声剔除，先查了一遍来源，结果发现它们揭示的是发布者的行为，不是我们的采集问题。

数据是怎么来的

pc 字段是案例提示词的字符数。1,274 条里，120 条（9.4%）不到 200 字符，中位数 97 字符。

作为对照：全库提示词长度中位数是 1,563 字符。这一批只有它的十六分之一。

看这 120 条的来源类型（prov）：

来源类型	条数	占比
creator-verbatim（原发布者原文照录）	69	57.5%
beatapi_indexed_prompt_with_webm	18	15.0%
official_or_official_index_prompt	12	10.0%
indexed_from_awesome_minimax_h3_prompts	10	8.3%
source_page_public_prompt	4	3.3%

接近六成的短提示词来自「原帖本来就是这么写的」。

这很关键——它排除了一种可能：这不是我们抓取时截断了内容，而是发布者自己在帖子里就没写详细提示词。

69 条（57.5%）托管在同一个 Railway 项目上，与 creator-verbatim 的数量完全吻合。这两条线索指向同一件事：它们大多来自同一个采集批次，而那批数据是直接照录原帖的。

这类案例的时长中位数是 13.7 秒，低于全库的 15.2 秒（这一点在提示词长度那篇里有完整的分档表）。

合理的解释是：短提示词往往对应单一动作、单一主体的内容——「一个人在健身」「一段舞蹈」，几句话能说清，也不需要跑满默认时长。而需要长提示词的内容（动作物理、科幻）本身就是多步骤的。

pc 的最短值是 4 字符。

4 个字符不可能是一段有意义的提示词——它更可能是字段切分错误（例如把某个标识串误当成提示词），或者是极短的原帖文字被当成了提示词。

我们没有把它剔除，因为剔除标准无法统一（多少字符算「无效」没有客观依据）。但读者应该知道：

如果你在照着公开案例学写法：遇到提示词特别短的案例，先看它是不是「原帖照录」。原帖只有一句标题的情况在公开案例里真实存在——这类记录不能当范本。

如果你在做案例索引：这条经验值得记下——「字段缺失」和「字段短」是两种不同的诊断。前者是你的问题，后者可能是上游的问题。先把来源类型拉出来看，再决定要不要清洗；我们差点把 120 条有信息量的记录当成噪声删掉。

如果你在发布自己的案例：把提示词写完整是对自己有利的动作。数据显示，原帖不写提示词的案例，在索引项目里只能以「标题」形式存在，而依据标题的分类准确度很低（见标注依据那篇）。

「不到 200 字符」这个阈值是人为的：换一个阈值（比如 300 或 150），条数会变化，但来源集中这个结论方向不变。
pc 与 title 是两个不同字段：本文没有把「标题短」当成「提示词短」。上文表格里的案例名是标题，仅用于示意，不代表 pc 字段的内容。
57.5% 来自单一来源：这削弱了「社区普遍不写提示词」的外推能力。本文只主张「存在这样一批记录，且它们是原帖原样」。
无法区分「发布者没写」与「发布者写了但没说这是提示词」：后者会被我们记成短提示词。
全部数字基于 1,274 条索引记录。

案例详情里可以查看提示词与其长度：https://cases.aishifu.shop/