EpiLang：专为批量书名生成而设计的极简领域特定语言-北京尧图网络

最近在帮某内容团队做书目策划时遇到了一个很现实的问题一次要提交三百多个待定标题描述方向、受众人群、情绪基调各不相同。负责命名的同事白天查资料、晚上开会讨论三天下来人累得够呛标题质量却越来越飘。有人建议直接用大模型批量生成我们试了一轮发现结果完全不可控——想要的冷冽感它会突然蹦出个温暖治愈要求控制在十个字以内时它照样输出十六字的句子而且每次跑出来的结果还不一样。面对批量、稳定、有约束这三个要求通用工具就是使不上劲。后来我花了几个晚上设计了一种专用于生成书名的极简编程语言EpiLang取的是 Epic Title Language 的意思也就是极致标题语言。它的语法只保留五个语句能做的事情也只有一件——按照你给定的词库、句式骨架、长度和排除规则批量产出符合要求的书名候选。如果你也在做内容策划、独立编辑、账号命名这类需要大量标题候选的工作这篇文章讲清楚我为什么要做这门小语言、它的核心语法是什么、解释器怎么实现以及实测下来有哪些值得注意的坑。1. 为什么我会认真对待给书名生成做一门语言这个想法1.1 批量命名场景的真实痛点书名生成这件事听起来像是灵感驱动实际上批量场景下完全不是。真正的问题是不能接受一次给你二十个标题里面只有两三个能用剩下的要么跑题、要么矫情、要么看一眼就没记忆点。更要命的是团队里每个人对好名字的标准不同评审会上经常为了一个词争论半天。我统计过一轮真实需求发现大致可以拆成三类第一类是同一个主题下需要出多个书名测试不同风格方向第二类是已经定下核心词需要围绕这个词做句式变体第三类是明确要规避某些已经被用滥的词。这三类需求的共性是可枚举、可重复、需要强约束。而这恰恰是程序擅长的事情。1.2 通用工具为什么在这里不够用我先试过大模型提示词比如请围绕孤独与远行生成二十个书名每个不超过十个字避免出现治愈。共性问题有两个一是约束不可靠你说不超过十个字它偶尔还是会给来个十四字的二是不可复现同样的提示词换一天跑出来完全是另一批结果连上一次那版我挺喜欢的这种微调都做不了。再想用通用编程语言硬写。用 Python 当然能做字符串拼接、随机抽样、按长度过滤写起来都不难。但它本质上只是一次性脚本词库换一批要改代码骨架换一批要改代码想让不懂编程的编辑同事也参与进来调整风格更是难上加难。问题从来不是写不出这段脚本而是这个过程中积累的命名经验没有变成可以被复用的资产。1.3 极简语言的核心价值在于把经验固化下来当你反复跟朋友解释书名最好控制在6到14个字不要用逆袭治愈成长这种词主语加动作加场景的搭配最容易出效果——这些话本质上就是规则。规则积累得多了把它们写进一个可以反复执行、共享给团队的语言里这就是 EpiLang 的起点。我更愿意把它看作是一种领域特定语言。它的全部价值不在流程复杂度而在表达方式贴近书名生成这个具体问题。编辑器打开一个只有二十行的 .epi 文件任何人都能看出哪一行是词库、哪一行是骨架、哪一行在过滤俗词不需要懂软件工程也能调整生成方向。这种门槛极低、边界极清晰的设计才是极小语言该有的样子。2. 设计边界一门只做书名生成的语言该怎么取舍2.1 保留五个语句砍掉一切不必要的EpiLang 目前只有五个保留语句词库、骨架、节奏、过滤、生成。很多人第一次看到会觉得这也太少了但我刻意这样就够了。词库负责提供原料骨架负责决定句式节奏负责任长度控制过滤负责任排除干扰生成负责任批量产出。简洁到这个程度好处体现在使用成本上——不用查文档不用被编程概念劝退。我为这个设计划定的第一条边界就是不做赋值语句不做变量计算不做条件分支。因为书名生成任务里根本不需要这些。一个词库定义就是把哪些词当作同类的池子一张骨架表达式就是从哪些池子里各取一个填进模板。把这些用最直白的中文表达出来比任何高级特性都更有价值。2.2 语法总览与最小可行示例放一个完整的 EpiLang 最小示例在这里一眼就能看出它的表达风格词库物象: 列车, 灯塔, 风筝, 旧铁轨词库情绪: 孤独, 渴望, 沉默骨架基础: {情绪}与{物象}的{物象} 节奏: 6-12 过滤: 不含孤独的生成 10代码读起来就像一段简短的文字描述。词库物象定义了一组可选的词骨架里的{情绪}和{物象}表示两个插槽运行时从对应词库里各取一个词填进去组合出一条书名候选。节奏限制总长度过滤排除不希望出现的组合生成 10让解释器输出十条结果。这就是 EpiLang 的全部。你不需要学习循环、条件、函数这些概念只需要理解词库是原料、骨架是非式、过滤是禁区、生成是开关这一个心智模型。能把门槛压到这个程度是在设计边界阶段就反复割舍的结果。2.3 为什么不用现成的通用编程语言或现成脚本有人会问这种东西做成一个 Python 库不也一样吗表面上看是一样的但差别藏在谁来写、怎么改、怎么流传上。Python 库要求每个使用者都多少会点编程会在命令行装依赖、会读报错信息。EpiLang 的目标用户是内容编辑、策划、文案这类非技术角色因此语法必须像填写一张设计好的表格那样自然。另一个理由是可读文本就是配置文件本身。EpiLang 源文件可以直接上传到团队的共享空间谁都能打开看谁都能改一行词库然后重新运行。它不需要工程化的配置与代码分离因为源文件本身就既是代码又是配置。对一个小团队的书目生成流程来说这种透明性比什么抽象设计都管用。2.4 边界清晰让出问题变成好定位极简语法还有一层不太容易察觉的好处错误定位非常快。由于语句类型少、嵌套不存在文件里任何一行有问题解释器可以直接告诉你第3行词库缺少变量名或第5行骨架引用了不存在的词库。使用者不需要经历这个报错到底是因为循环还是因为函数参数这类灵魂拷问。在实际使用时团队里完全不懂编程的同事也能根据报错信息自己修复。一次他们在某个词库末尾多写了一个中文逗号解释器提示后对方自己发消息来说弄明白了是符号写错。这在我以前维护的任何真正编程语言里都没见过。3. EpiLang核心语法词库、骨架、节奏、过滤、生成3.1 词库声明词汇必须分类不允许混用词库是 EpiLang 的原料仓库。声明语法是词库名称: 词1, 词2, 词3其中名称建议用能表达语义的中文词比如人物场景情绪动作。我的第一条规则是词汇必须按语义分类不允许把动词、名词、形容词塞进同一个池子。当时有个失误值得说一下。最早的一版设计里我确实允许一个词库随便放结果实际生成经常出现病句比如用我像一条鱼在孤独这种逻辑不通的短语。问题根源在于名词词库和动词词库混在一起后骨架无法区分从池子里取出的词应该承担什么成分。后来我强制词库归类并在骨架中给每个插槽标注语义期望虽然没有语法级校验但运行时会做一次词性标注提醒效果立刻不一样。词库的另一个关键细节是数量级建议。单一词库放三到十五个词最佳太少会显得机械太多会让组合空间失控具体原因在后面的组合爆炸部分展开。3.2 骨架模板占位符、自由文本与拼接约束骨架是 EpiLang 最核心的表达。声明语法是骨架名称: 模板表达式模板里用{词库名称}引用词库其余的中文符号原样保留。比如骨架悬疑: {人物}消失后的第{数字}天运行时就可能填充成守夜人消失后的第七天。骨架设计上有一条重要约束一张骨架里的插槽不超过三个。这不是技术限制而是审美经验。两到三个变量组合出的句子基本还能保持自然语感一旦超过三个多个随机词叠在一起很容易生成出铁锈味的旅人在钟楼与旧皮箱之间喘息这类信息过载的句子。如果确需更长的句式我更建议拆成主副骨架两级由主骨架引用副骨架的结果而不是在一个模板里堆更多插槽。骨架还可以做纯文本拼接。骨架直白: 被遗忘的{事物}这种单插槽模板实际生产场景中反而最常用因为单插槽可控性最强输出质量最稳定。多插槽模板通常更适合实验风格时快速试探。3.3 节奏约束从字符数到听觉节奏节奏语句用于控制输出书名的整体长度。语法是节奏: 最小长度-最大长度单位是字符数。经过大量书名样本统计我推荐默认值 6-14。低于六个字信息承载量明显不足高于十四个字记忆成本陡增也很难在实体书的封面排版上呈现。撇开字符数这些数据不谈节奏约束更本质的作用是筛选听觉节奏。读上去别扭的组合往往在长度分布上就有问题。比如列车与灯塔五个字干净利落一辆旧列车与一座沉默灯塔十三个字能撑出画面感但列车、灯塔和被风化的旧铁轨之间的空旷感二十一个字就像一段碎碎念。我曾经把上限放宽到二十尝试过结果近五分之一的生成结果都像没有标点的短句完全没有书名感。后来索性在语法上追加了规则——节奏的上限不能超过二十强制不走极端。这种代用户决策的限制恰恰是 DSL 区别于通用语言的价值。3.4 过滤规则把不该出现的词挡在门外过滤语句是 EpiLang防止输出翻车的关键。目前支持两类过滤关键词过滤和结构过滤。关键词过滤的写法很简单比如过滤: 不含治愈过滤: 不含逆袭, 告别结构过滤则提供不重复、末尾不落的、不出现相同首字这类规则。表面上看这些都是小事它们决定了生成结果的专业度。那个末尾不落的规则是从中文书名审美出发的以的结尾的标题容易显得像散文句子缺乏利落感。过滤规则的执行顺序在实现上也有讲究。我的处理是先做长度过滤再做关键词过滤最后做结构过滤。先用低成本条件把明显不合格的大批候选淘汰掉再处理需要逐字扫描的规则整体性能是最优的。3.5 生成指令与随机种子让批量输出可复现生成语句负责控制运行结果写法是生成数量比如生成 30。解释器拿到词库、骨架、节奏、过滤这些定义后会按规则产生 30 条候选。我额外设计了一个很有用的附加语句随机种子。学过编程的朋友对随机种子都不陌生但我要强调的是在内容生成场景它带来的体验变化是质的飞跃。以前用大模型生成同一批需求两次结果差异很大想复现某个还挺好的书名状态根本不可能。EpiLang 支持随机种子后只要固定种子值无论运行多少遍生成的候选集完全相同。这给团队带来了一个从前不敢想的操作方式开评审会时把几种种子编号贴在会上大家说用种子 7 再跑一稿几分钟就能回到同一条生成路线。完整展示一个标准的 EpiLang 源文件总结构一眼就能看懂# 这是 EpiLang 示例脚本词库人物: 守夜人, 邮差, 旅人, 少年词库地点: 河岸, 废站, 山海, 钟楼词库事物: 手电筒, 旧皮箱, 白衬衫, 火炉骨架相遇: {人物}在{地点}遇到了{事物} 骨架离去: {人物}与{事物}一起离开了{地点} 节奏: 6-15 过滤: 不含少年, 不含守夜人的过滤: 不重复随机种子 7 生成 12结合运行结果看这套语法已经可以支撑实际生产需求了。每条语句不过几行但组合起来能完成从人设思路到最终候选列表的全流程。4. 解释器实现两百行Python如何跑通一个极小语言4.1 解析策略按行识别不做复杂文法EpiLang 解释器在实现上刻意不去走词法分析抽象语法树这种编译器课路线。对于这五个语句的极简语法按行解析已经是最高性价比的办法。每读入一行文本先去掉空行和注释然后根据行首关键词分派到对应处理函数。词法单元用re正则来切割中文关键词直接参与匹配也完全没问题。核心结构是这个样子代码有简化:import re, random, itertools class EpiLang: def __init__(self): self.vocab {} self.frames [] self.filters [] self.rhythm (6, 14) self.seed None def feed_line(self, line): line line.strip() if not line or line.startswith(#): return if line.startswith(词库 ): _, name, values self._parse_vocab(line) self.vocab[name] values elif line.startswith(骨架 ): self.frames.append(self._parse_frame(line)) elif line.startswith(节奏): self.rhythm self._parse_rhythm(line) elif line.startswith(过滤): self.filters.append(self._parse_filter(line)) elif line.startswith(随机种子): self.seed int(self._split_colon(line)[1].strip()) elif line.startswith(生成): self.output_count int(self._split_colon(line)[1].strip())也有人问过为什么选择 Python 而不是其他语言。原因很简单团队里做内容支持的人多多少少都能读一点 Python中文语法又与 Python 字符串处理天然契合。将来如果要扩展解释器招一个普通脚本开发者就能上手。4.2 组合引擎插槽展开背后的组合逻辑组合引擎是解释器里最有意思的部分。逻辑上每个骨架定义了一个插槽列表比如{人物}在{地点}遇到了{事物}对应三个插槽。运行时对变量列表做笛卡尔积再按模板格式化就得到候选书名。代码示意def expand_frame(self, frame): slot_lists [self.vocab[slot] for slot in frame.slots] for combo in itertools.product(*slot_lists): yield frame.template.format(*combo)笛卡尔积能保证覆盖所有显式组合这正是我需要穷举候选时的核心能力。可它也带来一个问题组合爆炸。三个词库各十个词理论上每个骨架要生成一千条候选如果再有十个骨架总量就是一万条其中真正值得读的可能只有一小部分。针对这个问题我在实现中加入了组合截断的策略每个骨架参与组合的词汇量上限默认为 8超出部分随机抽样。这样既保留了穷举的公平性又把每个骨架的候选量控制在一个可读范围内。实践中这个参数很值得调组合上限调太低会损失好词搭配调太高则噪音过多。4.3 过滤器执行顺序与去重逻辑过滤部分的工程细节要处理两个问题执行顺序和去重。原有实现是按用户书写顺序逐条过滤的后来改成固定排序——长度过滤、关键词过滤、结构过滤。原因前面提过先做低成本的粗筛吞吐量会高一个数量级。去重时分两级。第一级是完全一致的字面去重直接靠set就能实现。第二级更有价值是首字相同且结尾相同的相似去重。比如列车与旅人和列车与归人这种高度相似的标题一起出现在候选列表里会浪费掉评审注意力。处理方式是预判后缀是否一致如果一致则只保留一条除非生成总数不足需要补量。代码上类似这样def dedupe(results): seen, kept set(), [] for title in results: key (title[0], title[-1]) if key in seen: continue seen.add(key) kept.append(title) return kept实际运行下来这个简单规则对候选列表的可读性提升非常明显原本二十条里可能出现三组长得差不多的句子现在输出更分散风格覆盖更广。4.4 预留扩展接口别把小语言做死EpiLang 解释器虽然很小我仍然预留了三个扩展点自定义函数、外部词库文件、JSON 导出。自定义函数允许用户在源文件里写函数押韵: ...来计算某个词的押韵词列表我可以把内部词汇表通过开放接口暴露出来。外部词库文件则解决词库太大不好维护的问题可以让词库声明分布在多个文件里用一行引入词库文件语句组合。这些扩展接口的设计原则是核心语言保持五个语句不变新增能力一律以插件形式出现。就好比一个只卖基础款写字台的工作室桌面抽屉这种需求靠加装组件实现而不是把写字台本体重造成全屋定制。5. 实测三十组词库能产出什么水平的书名5.1 一次完整的构建过程我用一个实际的模拟需求来展示全流程。假设有个成长类散文选题要求书名让人感觉安静、带一点时间感同时不要出现少年乡愁这类被用滥的词。我需要先制定词库再设计骨架再定规则。词库设计如下词库时间: 晚风, 黎明, 旧年, 潮汐, 晨光词库人物: 守夜人, 旅人, 嘿, 写信人, 养花人词库地点: 河岸, 山海, 长廊, 街角, 旧钟楼词库事物: 手写笔记, 旧皮箱, 白衬衫, 火炉, 玻璃瓶骨架组合A: {时间}经过的{地点} 骨架组合B: {人物}在{地点}拾起{事物} 骨架组合C: 写给{时间}的{人物} 节奏: 6-13 过滤: 不含少年过滤: 不含乡愁过滤: 不重复随机种子 20240501 生成 20整套词库加起来正好三十个词不算多但覆盖时间、人物、地点、事物四个维度。5.2 输出结果示例与观察在固定种子下解释器返回的候选列表中有一部分输出效果很好例如潮汐经过的旧钟楼写信人在长廊拾起玻璃瓶写给晚风的养花人旧年经过的街角睡在河岸拾起火炉这五个句子都有画面感长度适中时间感和安静感基本传递出来了。另一些输出就相对平淡比如晨光经过的山海和养花人在山海拾起手写笔记本身没毛病但记忆点不够强。二十条候选里能直接用的约三到五条需要微调的有七八条完全不能用的通常不超过三条。我对这个中奖率比较满意。它的意义在于同一套规则跑十次产出水平始终稳定在这个区间不会出现一次超常发挥、一次全线崩盘的情况。对策划团队来说这种稳定性更利于排期和预期管理。5.3 实测中反复踩到的三个坑第一个坑是词性不分离。最早期版本里我曾把山海旧钟楼写信人混在同一个词库骨架里又要求在{地点}拾起{事物}结果生成出旅人在写信人拾起旧皮箱这种病句。强制按人物、地点、事物拆库后此问题基本消失。第二个坑是骨架过短或过长。单插槽骨架像{事物}本身信息量不足三插槽以上又容易堆出碎句。实际操作中我把骨架长度控制在两到三个插槽效果最为稳定。陈词滥调不是来自词汇本身而是模板信息密度过低。第三个坑是组合爆炸和随机抽样之间的平衡。早期我用上限 20 跑五十条生成发现候选列表大量重复因为组合空间里有大量同义近义词替代随机抽样覆盖不够均匀。后来调整为上限 8搭配去重规则均匀度和新鲜度就恢复正常了。5.4 人类筛选与机器生成的分工EpiLang 生成的书名近九成不会直接被采用。它的定位不是替代人工命名而是把人工命名的筛选范围从零扩到三四十条。真正的编辑工作发生在拿到候选列表之后调整词序、替换个别词汇、把潮汐经过的旧钟楼改成潮汐经过旧钟楼这类细节打磨。我是这样看待机器的角色的组合能力交给代码审美判断交给人。EpiLang 负责不遗漏那些人类灵感盲区中的组合人类负责从候选列表中找出真正有生命力的那一个。两者分工明确合作起来很舒服。6. EpiLang 留下哪些可扩展的接口6.1 词库外部化与团队协作使用一段时间后最先扩展的是词库管理。最初的词库写在单个文件里随着主题变多变得臃肿。现在 EpiLang 支持单独维护若干扩展词库文件比如都市词库.epi、悬疑词库.epi、随笔词库.epi主文件只需要声明引用。团队里负责文案的同事维护对应领域的词库其他人完全不影响。共享机制也很自然词库就是文本放进同步盘或代码仓库都行。多个成员可以同时编辑不同领域的词库最后按主题合并。这个能力相当于命名知识的版本管理每次评审后如果某批筛选结果不错可以反推是哪组词库贡献的然后固定下来。6.2 从经验中归纳骨架与词汇由于 EpiLang 把生成过程完全记录在文本文件里我便开始统计哪些骨架的采用率更高哪些词经常出现在最终入选名单。汇总几次实测数据后发现带时间词开头的骨架很容易出效果例如{时间}经过的{地点}而带抽象情绪词的骨架反而命中率偏低比如{情绪}与{物象}。基于这类统计我打算做一个小工具输入一份被采用书名清单自动生成对应的新骨架模板。本质上是把人工筛选的结果反向回写进词库和骨架方案形成一条正向循环。这个方向还没完全跑通但原理已经验证过了。6.3 接入内容工作流的几种思路EpiLang 的解释器最后以命令行工具的形式封装可以直接在终端里执行epilang 书名方案.epi把结果输出成文本或 JSON。这意味着它可以嵌入内容生产流水线策划提交词库系统自动生成候选后接协作平台由人筛选通过的书名再回流到数据库。相比一个单一功能的网页工具命令行方案虽然看起来土但它让整个工作流保持透明和可审计。每次生成的结果都带固定的种子编号、词库版本、骨架列表出了任何风格问题都能回溯到具体某个词或某条规则而不是面对一个黑盒。6.4 个人体会小语言的价值不在功能强大而在判断一致做了 EpiLang 之后我对编程语言这个概念的理解变了很多。以前觉得语言越强大越好能处理的问题越多越好。现在觉得一门语言最重要的不是覆盖面而是判断一致。它认定书名应该在 6 到 14 个字之间就绝不会给你 25 个字的句子它认定不该出现治愈就绝不会在任何随机种子下跑出这个词。哪怕以后这个语言只被一个小圈子的人使用我也认为它完成了真正的目标把一组不确定的、依赖个人状态的瞬间灵感转化成一个确定性的、任何人都能运行的流程。对做内容的人来说这比单纯拥有更多创意更实用。

EpiLang：专为批量书名生成而设计的极简领域特定语言

相关推荐

gcc/g++/cmake工具链安装、验证与排错全指南

AI智能体循环工程-第7章第6节-验证工程-失败信息工程报错就是给模型的提示词

open-code-review：基于Git Diff与LLM Agent的自动化代码评审实践

更多资讯

开放式代码评审：从理念到落地的高效工程实践

SAP物料编号范围配置原理与实战避坑指南

diagram-design：从规范到组件，搭建统一图表设计体系

数码管识别为何不用OCR？OpenCV+轻量CNN实战方案

Docker入门实战：从镜像容器到Compose编排，解决环境一致性问题

DeskcommCRM实战：销售自动化配置、数据清洗与团队落地全记录

今日更新

悟空开源无代码平台实战：从实体建模到应用设计避坑指南

基于.NET9的多租户权限系统：数据权限与动态API落地实践

场地预约小程序毕设实战：SSM+微信小程序+MySQL数据库设计到避坑

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？