1. 这个Skill到底解决了什么问题先说说我为什么要熬这个通宵。做内容的人都有一个共同的痛点标题决定生死。你花六个小时写的稿子如果标题不行打开率可能连基准线的三分之一都不到。我自己的号做过测试同一篇文章换两个标题阅读量能差出八倍。这不是玄学这是实打实的数字。但问题在于人脑不是标题机器。你连续写二十个标题之后判断力会断崖式下降看什么都觉得“还行”实际上已经麻木了。市面上有各种标题生成工具我也试过不少但用下来总有几个绕不过去的坎要么是套模板套得太死出来的东西一股营销号味儿要么是通用大模型直接生成缺乏对平台调性和受众心理的针对性要么就是需要付费、需要联网、需要把内容上传到别人的服务器。所以我决定自己做一个。核心思路很简单把标题创作的方法论拆解成可复用的规则再让Agent按照这些规则去执行。这就是title-craft这个Skill的由来。它不是一个独立的App也不是一个网页工具。它是一个Agent Skill——你可以理解为给AI Agent装上的一个“专业技能包”。装上之后你的Agent就具备了系统化产出标题的能力而不是每次都要你从头写提示词。适合谁来用三类人一是做自媒体、公众号、小红书、短视频的内容创作者二是做增长、运营、市场的人需要批量产出标题做A/B测试三是对Agent开发感兴趣、想了解Skill机制的技术同学。不管你是哪一类只要你有“需要大量好标题”这个需求这个Skill就能帮上忙。开源地址在GitHub上搜title-craft就能找到。下面我把整个设计思路、实现细节、踩过的坑全部拆开来讲。2. 为什么选择Skill而不是独立工具2.1 Skill和Agent的关系用一句话说清楚很多人搞不清楚Skill和Agent的区别。我打个比方Agent是一个刚入职的实习生脑子好使、学习能力强但不知道你们公司的具体规矩和流程。Skill就是一本员工手册告诉他“我们公司写标题要遵循这五条原则、要避开这三个雷区、要按这个格式输出”。没有Skill的Agent你每次都得口头交代一遍要求而且每次交代的可能还不一样输出质量忽高忽低。有了SkillAgent就按照固定的专业流程来干活稳定性完全不是一个级别。从技术角度看Skill本质上是一组结构化的指令和知识注入到Agent的上下文里让它在特定任务上的表现从“通用”变成“专业”。它不改变模型本身但改变了模型在这个任务上的行为模式。2.2 为什么不做成独立工具我一开始也想过做成一个网页工具输入关键词就出标题。但很快否掉了这个方案原因有三个。第一标题创作不是孤立任务。你写标题的时候往往需要结合文章内容、目标平台、受众画像、当前热点。独立工具没法获取这些上下文只能让你手动输入体验很割裂。而Skill是跑在Agent里的Agent本身就能读你的文章、查你的资料、理解你的需求标题生成只是整个工作流中的一环。第二独立工具的维护成本太高。你要做前端、做后端、做用户系统、做API调用管理光是这些基础设施就能耗掉大半精力真正花在标题算法上的时间反而少了。Skill不需要这些它就是一个Markdown文件加几个辅助脚本维护成本几乎为零。第三Skill的可组合性更强。你可以把title-craft和其他Skill串联使用比如先用一个Skill做选题分析再用title-craft生成标题最后用一个Skill做合规检查。这种组合能力是独立工具给不了的。提示如果你也在考虑做类似的东西我的建议是优先做Skill而不是独立工具。除非你的需求非常标准化、用户完全不需要上下文否则Skill的投入产出比高得多。2.3 技术选型为什么用Markdown加脚本Skill的核心文件是一个Markdown格式的指令文档。为什么不用JSON或者YAML因为Markdown对模型最友好。大模型在训练时见过海量的Markdown文档对这种格式的理解能力最强。你用JSON写指令模型也能读但效果就是不如Markdown自然。辅助脚本我用的是Python主要做两件事一是标题的批量评分和排序二是从外部源拉取热词数据。脚本不复杂加起来不到三百行但省了很多手动操作的时间。整个项目的文件结构大概是这样的title-craft/ ├── SKILL.md # 核心指令文档 ├── scripts/ │ ├── score.py # 标题评分脚本 │ └── fetch_trends.py # 热词获取脚本 ├── examples/ │ └── samples.md # 示例标题库 └── README.md # 使用说明SKILL.md是整个Skill的灵魂里面定义了标题创作的方法论、输出格式、约束条件。下面我会详细拆解这个文件的设计逻辑。3. 标题创作方法论的核心拆解3.1 标题的本质是什么在写Skill之前我花了大概两周时间把自己过去三年写过的所有爆款标题和扑街标题拉出来做对比分析。样本量大概两千多条覆盖公众号、小红书、知乎、短视频平台。分析下来一个好标题本质上要同时满足三个条件引发好奇、传递价值、降低理解成本。这三个条件缺一不可。只有好奇没有价值那是标题党用户点进来会觉得被骗只有价值没有好奇用户根本不会点两个都有但理解成本太高用户看不懂也不会点。所以title-craft的核心逻辑就是围绕这三个维度来设计的。每生成一个标题都会从这三个维度去评估和优化。3.2 三个维度的具体拆解引发好奇这个维度我拆成了四种手法悬念式、冲突式、反常识式、数字式。悬念式就是留一个信息缺口让用户想补全冲突式是制造认知矛盾比如“越努力越穷”这种反常识式是打破用户的固有认知数字式是用具体数字增加可信度和冲击力。传递价值拆成了三种实用价值、情绪价值、社交价值。实用价值是告诉用户“看了能学到什么”情绪价值是让用户产生共鸣或者情绪波动社交价值是让用户觉得“转发这个显得我有品位/有见识”。降低理解成本拆成了两个原则一是用具体代替抽象二是用短句代替长句。具体的东西比抽象的东西好理解“月薪三千”比“收入不高”好理解得多。短句比长句好理解这个不用多解释。3.3 评分机制的设计有了这三个维度评分机制就顺理成章了。每个维度满分十分总分三十分。但三个维度的权重不一样好奇的权重最高因为它是决定用户是否点击的第一道门槛。具体权重分配是好奇占百分之四十价值占百分之三十五理解成本占百分之二十五。这个比例是我根据实际数据反复调整出来的不一定适合所有人但作为一个起点是合理的。评分脚本的逻辑不复杂就是用关键词匹配加规则判断。比如检测到疑问句、省略号、数字好奇分就加检测到“教你”“方法”“步骤”价值分就加检测到句子长度超过二十五个字理解成本分就扣。注意评分脚本只是辅助工具不能完全替代人的判断。它的作用是帮你快速筛掉明显不合格的标题而不是帮你选出最好的标题。最终决策还是要靠人。3.4 约束条件的设定Skill里还定义了一组约束条件用来防止Agent生成违规或者低质的标题。这些约束包括不生成虚假承诺、不生成低俗内容、不生成与内容不符的标题、不生成超过三十个字的标题。这些约束看起来简单但实际运行中非常关键。没有约束的Agent在追求“好奇分”的时候很容易跑偏生成一些擦边球的标题。加上约束之后它会在规则范围内寻找最优解而不是无底线地博眼球。4. 实操过程从零到一搭建这个Skill4.1 第一步定义Skill的输入输出任何Skill开发的第一步都是明确输入和输出。title-craft的输入包括文章内容或主题描述、目标平台、目标受众、可选的参考热词。输出是一组标题每个标题附带评分和推荐理由。输入输出的定义看起来简单但这里有一个关键决策要不要让Agent自动判断目标平台和受众。我最后的决定是让用户显式指定因为不同平台的标题风格差异太大了。公众号偏深度和情绪小红书偏种草和口语化知乎偏专业和理性。让Agent自动判断容易出错不如让用户直接说。4.2 第二步编写SKILL.md的核心指令SKILL.md的编写是整个项目中最耗时的部分。我改了大概十几个版本每一版都拿实际案例去测试看输出质量有没有提升。核心指令的结构是这样的先定义角色和任务然后给出方法论框架接着是输出格式要求最后是约束条件和示例。这个顺序很重要模型是先理解角色再学习方法再知道怎么输出最后被约束。角色定义我写的是“你是一个资深内容创作者擅长为不同平台撰写高点击率的标题。你理解用户心理知道什么样的标题能引发好奇、传递价值、降低理解成本。”方法论部分就是前面说的三个维度加评分机制。输出格式我要求Agent输出一个表格包含标题、好奇分、价值分、理解分、总分、推荐理由。这样用户一眼就能看出哪个标题最好以及为什么好。4.3 第三步写评分脚本评分脚本用Python写核心是一个函数接收标题字符串返回三个维度的分数。实现方式主要是正则匹配加规则判断。import re def score_title(title): curiosity 5 # 基础分 value 5 clarity 5 # 好奇分疑问句、省略号、数字、冲突词 if re.search(r[?], title): curiosity 2 if ... in title or … in title: curiosity 1 if re.search(r\d, title): curiosity 1 if any(w in title for w in [竟然, 居然, 没想到, 原来]): curiosity 2 # 价值分实用词、情绪词 if any(w in title for w in [方法, 步骤, 教你, 如何, 怎么]): value 2 if any(w in title for w in [终于, 彻底, 一次搞定]): value 1 # 理解分句子长度、生僻词 if len(title) 25: clarity - 2 if len(title) 10: clarity - 1 # 归一化到0-10 curiosity max(0, min(10, curiosity)) value max(0, min(10, value)) clarity max(0, min(10, clarity)) total curiosity * 0.4 value * 0.35 clarity * 0.25 return curiosity, value, clarity, round(total, 1)这个脚本很简单但实际用下来效果不错。它最大的价值是快速过滤。你生成五十个标题脚本一跑低于二十分的直接扔掉剩下的再人工看效率提升非常明显。4.4 第四步热词获取脚本热词获取脚本的作用是从公开的热搜榜和趋势数据中拉取当前热门词汇供Agent在生成标题时参考。这个脚本我用的是公开的API接口不涉及任何敏感数据。import requests def fetch_trends(): # 这里用的是一个公开的趋势数据接口 url https://api.example.com/trends resp requests.get(url, timeout10) if resp.status_code 200: data resp.json() return [item[keyword] for item in data[:20]] return []这个脚本的实用性在于它让标题生成不再是闭门造车。Agent可以结合当前的热词来创作标题的时效性会强很多。比如最近“Agent”这个词很热Agent就会在合适的场景下把这个词融入标题。提示热词获取脚本需要联网如果你在离线环境使用可以跳过这一步手动输入几个热词也行。Skill本身不依赖这个脚本它只是一个增强功能。4.5 第五步测试和迭代Skill写完之后我拿一百篇历史文章做了回测。具体做法是把文章内容输入Agent让它生成十个标题然后和实际发布的标题做对比看Agent生成的标题里有没有比实际标题更好的。结果比我预期的好。一百篇文章里有二十三篇Agent生成的标题在评分上超过了实际标题。我又人工看了这二十三个标题其中大概有十个确实比原标题好可以直接用。这个命中率对于一个刚做出来的Skill来说我已经很满意了。迭代过程中最大的调整是约束条件的松紧度。一开始约束太松Agent生成了一些擦边球标题后来约束太紧Agent又变得过于保守标题都很平庸。最后我找到了一个平衡点在“不虚假、不低俗、不超长”这三条硬约束下给Agent最大的创作自由。5. 常见问题与排查技巧5.1 Agent不按格式输出怎么办这是最常见的问题。你明明在SKILL.md里写了要输出表格但Agent就是给你输出一段文字。原因通常是格式要求写得不够明确或者示例不够清楚。我的解决方法是在SKILL.md里放一个完整的输出示例把表格的每一列都填上真实数据。模型看到示例之后模仿的准确率会大幅提升。另外在指令里用“必须”“务必”这样的强约束词也比“建议”“最好”有效得多。5.2 生成的标题同质化严重如果你发现Agent生成的十个标题看起来都差不多那说明你的方法论框架太窄了。我的做法是在Skill里加入“多样性指令”要求Agent在生成标题时至少覆盖三种不同的手法。比如前三个用悬念式中间三个用数字式最后四个用冲突式。另外你可以在输入里给Agent一些“反面示例”告诉它“不要生成这样的标题”。负面约束有时候比正面引导更有效。5.3 评分脚本和Agent评分不一致这个问题我也遇到过。评分脚本给某个标题打了高分但Agent在推荐理由里说这个标题不好。原因是两者的判断逻辑不一样脚本是规则匹配Agent是语义理解。我的处理方式是以Agent的判断为主脚本为辅。脚本的作用是快速过滤明显不合格的标题而不是做最终决策。如果你发现脚本经常和Agent判断不一致那就调整脚本的规则让它更宽松一些只过滤掉那些确实很差的标题。5.4 热词融入得太生硬Agent有时候会把热词硬塞进标题里读起来很别扭。比如“Agent”这个词很热Agent就生成“Agent教你写标题”这就很生硬。解决方法是在Skill里加一条规则热词只能在语义通顺的前提下使用如果热词和主题不相关宁可不用。另外可以给Agent几个正面和反面的示例让它理解什么叫“自然融入”。5.5 常见问题速查表问题可能原因解决方法不按格式输出格式要求不明确加入完整输出示例使用强约束词标题同质化方法论框架太窄加入多样性指令要求覆盖多种手法评分不一致脚本和Agent逻辑不同以Agent为主脚本只做粗筛热词生硬缺乏融入规则加入“语义通顺优先”规则和示例生成速度慢输入内容太长精简输入只给核心信息标题太保守约束条件太紧放宽非核心约束保留硬约束6. 一些实操心得和避坑经验6.1 不要追求一步到位我见过很多人做Skill一上来就想做一个完美的版本结果改了两个月还没发布。我的建议是先做一个能用的版本哪怕只有三条规则先跑起来然后在实际使用中迭代。title-craft的第一版只有五百字功能很简陋但它能跑通整个流程。后面的十几版都是在实际使用中发现问题、解决问题。6.2 示例比规则更重要在写SKILL.md的过程中我发现一个规律给三个好示例比写三百字规则更有效。模型的学习方式和人不一样它更擅长从示例中归纳规律而不是从规则中演绎。所以我在Skill里放了大量的示例正面示例和反面示例都有。6.3 保持Skill的单一职责title-craft只做一件事生成标题。它不做选题分析不做内容创作不做合规检查。这些功能可以由其他Skill来完成。保持单一职责的好处是每个Skill都很轻量组合起来却很强大。如果你把所有功能都塞进一个Skill它会变得臃肿维护起来也很痛苦。6.4 版本管理很重要Skill的迭代频率很高没有版本管理你会疯掉。我用的是最朴素的方法每次修改都在文件头部加一个版本号和修改说明。比如“v1.3 调整了好奇分的权重从0.35改为0.4”。这样你随时可以回滚到之前的版本也可以清楚地看到每次修改的效果。6.5 开源之后的一些体会这个Skill开源之后收到了不少反馈。有人提了很好的建议比如加入多语言支持、加入行业垂直模板。也有人报告了bug比如在某些Agent框架下格式会乱掉。这些反馈让我意识到开源不仅仅是把代码放出去更是一个持续维护和迭代的过程。我现在每周会花大概两个小时处理issue和PR这个投入是值得的。因为别人的使用场景和你不一样他们会发现你根本想不到的问题。这些问题反过来会让Skill变得更好。提示如果你也想开源自己的Skill我的建议是先写好README把使用方法和限制条件说清楚。不要让别人猜怎么用那会浪费双方的时间。6.6 关于Agent框架的兼容性title-craft在设计上是框架无关的理论上可以在任何支持Skill机制的Agent框架上运行。但实际测试下来不同框架对Skill的支持程度不一样。有的框架对Markdown指令的解析更准确有的框架对脚本调用的支持更好。我的做法是在README里列出经过测试的框架和版本并说明已知的兼容性问题。这样用户在使用之前就能知道自己的环境是否合适避免踩坑。7. 后续可以怎么扩展这个Skill目前只覆盖了标题生成这一个环节但内容创作的链条很长前面有选题、后面有摘要、有开头、有结尾。每一个环节都可以做成独立的Skill然后串联起来。我下一步的计划是做一个“选题分析Skill”输入一个领域和几个关键词输出一组有潜力的选题方向。然后再做一个“摘要生成Skill”输入文章内容输出适合不同平台的摘要。这三个Skill串起来就是一个完整的内容创作辅助流水线。另外我也在考虑加入更多的行业模板。不同行业的标题风格差异很大科技类偏理性情感类偏共鸣财经类偏数据。如果Skill能识别行业并自动切换风格实用性会更强。不过这些都是后话。先把当前这个版本打磨好比什么都重要。我在实际使用中最大的体会是工具的价值不在于功能多而在于能不能真正融入你的工作流。title-craft现在已经成了我每天写稿的固定环节打开Agent输入主题三十秒出十个标题挑一个最好的继续写正文。这个流程跑顺了之后效率提升是实实在在的。