这段时间我一直被“写推文”这件事烦着灵感来了没时间时间来了没灵感好不容易挤出一段话又得复制到X推特网页端点个发布还要纠结半天配图有没有、链接放哪里、话题标签怎么排。于是我想清楚了一件事——与其每天手动作业不如把这条链路打包成一个Claude Skills让AI不只是“给建议”而是把“生成内容到调API发布”整套动作都接过去。我从0到1搓出了这个技能现在只要给一个主题它就能自动生成推文并发出去全程基本不需要我再碰发布页面。这篇教程我尽量写完整Skills的文件结构、提示词设计、X平台API接入、定时自动发布、常见问题全部摊开讲。适合会用Python、但还没碰过平台技能扩展开发的朋友照着一路做下去差不多半天就能跑通。1. 为什么非要搓一个“自动发推”的技能而不是多开几个对话窗口1.1 真正的负担不在“写”而在“写完到发出去”之间刚开始我也天真地以为AI写作已经这么成熟了想一段推文还不简单直接在对话里说“帮我写一条关于AI绘画的推文”就行。实际上偶尔一两条确实没问题但每天都要更新账号内容的人会发现真正的耗时点根本不是生成文案这件事而是那套重复劳动内容生成以后要自己检查长度、加话题标签、调整语气再打开X网页版或手机App粘贴排版检查有没有漏掉链接最后才敢点发布。这个过程一天重复三五次心情很快就没了。所以我的核心目标不是“让AI内容更强”而是“把发布推文这个动作本身自动化”。内容可以慢慢调但步骤必须能一键跑完。想清楚这一点后我决定做的东西不是普通的聊天prompt而是一个可复用的技能包以后不管谁来问只要输入主题系统就按固定流程把草稿、导出、发布整串动作执行完。1.2 为什么选Skills而不是直接写脚本完事其实这个需求用纯脚本也能做写一个Python程序从命令行接收主题组合一批模板句子再调用接口发出去。但只写脚本有几个很现实的问题。第一模板生成的文案像复读机没有语义理解能力稍微换个不常见的话题内容就变得莫名其妙。第二每次想调整语气、换角度、模仿新风格都要去改代码模板维护成本很高。Skills的价值在于把“模型的理解能力”和“脚本的执行能力”拼到一起。模型负责动脑子脚本负责动手。我只需要在这个技能包中定义清楚什么场景触发、按什么顺序执行、调用哪个脚本之后模型会在合适的时候主动把脚本捡起来用。这比纯脚本灵活得多也比每次面对空对话窗口从头交代上下文靠谱得多。1.3 动手之前我确认了三件最基础的事我不是那种“想到就干、干到一半发现平台没开权限”的人所以开工前先把前提条件列了一下。一是确认目标账号是否有开发者权限至少能创建应用并且拿到读写权限二是本地得有能跑Python脚本的环境最好已经装过 requests 这类常用库三是想清楚发推文的用途纯个人分享和营销运营的玩法完全不同这会影响提示词风格和发布频率。这三件事都确认没问题之后我才开始搭目录、写SKILL.md。如果你打算照做也先把这三个前提过一遍免得后面做到API接入那一步才发现账号权限不够又要回头去申请。2. Skills到底是什么先搞清楚这把“螺丝刀”的结构2.1 一个最小可用的Skill由哪几个文件组成在我动手之前我对Skills的第一印象是“大概是个配置文件”。等我拆开看过之后发现事情没那么神秘核心其实就是三块东西一份说明文档、一个或多个可执行脚本、一些辅助资源。说明文档是入口通常命名为 SKILL.md里面写清楚这个技能叫什么、解决什么问题、在什么场景下被触发、具体操作步骤是什么。脚本用来完成实际动作比如生成草稿、调用发布接口。辅助资源可以是示例模板、参考推文、常用话题清单等模型会根据任务内容自行参考。这三个部分不是随便堆在一起而是有组织方式的。我给自己的技能建了一个目录结构大约长这样skill-x-auto-poster/ ├── SKILL.md ├── scripts/ │ ├── generate_draft.py │ └── publish_tweet.py ├── templates/ │ └── tweet_style.md └── assets/ └── examples.mdSKILL.md 在最外层跟 scripts、templates 平级。scripts 里放可执行脚本templates 里放提示词模板和风格参考assets 里放一些辅助数据。这样做的好处是模型发现技能后能很快定位到该看什么文件不会在几十个文件夹里迷路。2.2 SKILL.md 是怎么“告诉”模型该什么时候出手的SKILL.md 很像一份给“新员工”看的操作手册。文件的顶部通常需要填一组元信息包括技能名称和描述。这个描述非常重要因为模型在处理用户请求时会先根据描述判断当前这个任务匹配不匹配该技能。描述写得太宽模型什么任务都可能会尝试调用导致误触发写得太窄模型又识别不出来技能形同虚设。我最初写的版本一直没被触发后来才发现是描述不够准确。我用了“和使用者互动”这种模糊说法模型根本不知道该技能是干嘛的。改成“当用户要求生成或发布X平台推文、处理推特内容更新时使用”之后情况立刻就好了。原理不复杂描述就是给模型看的“检索标签”把触发场景描述得越具体、越贴近用户真实表达命中率越高。2.3 它和普通API封装或者插件的区别在哪里有些人会问既然最后还是调用脚本那为什么不直接做一个API服务我个人的理解是API服务解决的是“系统之间怎么通信”的问题而Skill解决的是“模型在对话中如何自主决定使用什么工具”的问题。前者你把一切流程写死后者你把判断权交给模型让模型根据上下文动态决定要不要调用脚本、调用哪个脚本、传什么参数。这带来一个明显好处交互方式变得非常自然。我不需要记住命令行参数只要说“帮我发一条关于远程工作的推文”模型就会拆解需求、套用模板、生成内容再决定调用发布脚本。整套流程对我来说只有一句话剩下的全部在技能内部完成。这种体验是传统脚本封装很难给的。3. 动手搭骨架环境准备、目录结构与第一版SKILL.md3.1 本地环境依赖清单我建议先列一个最小的环境清单避免中途手忙脚乱。我自己的电脑上是这样一套组合依赖用途备注Python 3.10脚本运行环境3.8应该也能跑但3.10更省心requests、requests_oauthlib调用X平台发布接口OAuth签名时用到python-dotenv管理本地密钥避免密钥写死在脚本里支持加载Skills的客户端环境验证技能触发和调用逻辑不一定需要GUI命令行方式也行如果你不打算本地跑定时任务只是想验证技能能不能用那 Python 环境和 requests 库就够了。密钥管理很重要千万别偷懒后面我会专门讲。3.2 目录这样建后面扩展最舒服我一开始文件的命名很随意后来吃了亏才整理成上面那个结构。核心建议就一条把“生成草稿”和“发布推文”拆成两个独立脚本。为什么因为日常调试时你大概率只想先生成一条内容看看效果并不想真的把它发出去。两个脚本分开以后我可以单独跑生成脚本做内容调试等文案满意了再单独跑发布脚本。混在一起的话每次调试都会发一条测试推文账号很容易被弄成“垃圾内容账号”。另外templates 目录里我放了一份 tweet_style.md里面记录了目标账号常用的口吻、常用话题标签、典型句式。模型生成推文前会参考这份文件这比把风格要求堆在提示词里干净得多。3.3 第一版 SKILL.md 这样写基本能跑我参考了常见的技能包写法写出来的第一版 SKILL.md 大概长这样--- name: x-auto-poster description: 当用户要求生成、编辑、发布X平台推文或想自动更新自己的社交账号内容时使用。 --- # X自动发推技能 ## 使用场景 - 用户给出一个话题、一段想法或一篇长文希望浓缩成推文。 - 用户希望按固定时间或固定频率发布内容。 - 用户希望自动把生成的草稿发布到X平台。 ## 工作流程 1. 先读取 templates/tweet_style.md了解目标账号的语感和风格。 2. 根据用户的输入主题在草稿中生成至少3条候选推文。 3. 将候选推文展示给用户确认除非用户明确表示不需要确认。 4. 调用 scripts/publish_tweet.py 发布确认后的推文。 ## 注意事项 - 推文长度不能超过280个字符。 - 不要在一条推文里堆超过3个话题标签。 - 发布前必须再次检查文案中是否有明显事实错误。这个版本的流程是“先给候选再确认再发布”。为什么不上来就全自动因为早期调试阶段模型的输出风格还不稳定你让它直接发出去风险很大。等观察一段时间确定内容风格没问题了再把“是否需要确认”这个节点改成默认跳过。3.4 第一轮验证先分别跑脚本再整链路测我已经把目录结构和SKILL.md写好了接下来要验证两件事脚本本身有没有bugSKILL.md能不能被模型正确识别。验证方法很简单第一步手动跑发布脚本。python scripts/publish_tweet.py --text 这是一条测试推文这能确认API密钥、权限、网络连通性都没问题。第二步回到对话环境向模型发出一个自然语言请求比如“用这个技能写一条关于效率工具的推文草稿”看看模型会不会主动去读templates里那份风格文件而不是凭空发挥。如果模型完全无视技能说明SKILL.md的描述和写法有问题如果模型能正确提到要调用哪个脚本就说明技能已经被识别到了。我当时的测试结果很典型第一条自然语言请求模型写出来的文案确实像样结构完整也有话题标签但风格完全不对——它用了非常正式的书面语一看就不是社交平台原生内容。这说明脚本没问题问题出在提示词模板和风格参考文件写得太笼统。于是我把工作重心转到了提示词设计上。4. 让AI写出“有网感”的推文提示词模板是这样反复调出来的4.1 为什么通用prompt写不出平台原生内容直接让模型“写一条不错的推文”十次有八次会得到一段规规矩矩、放在官网新闻稿里都毫无违和感的文字。原因是模型在没有明确约束时会倾向于输出四平八稳的“标准答案”结构完整、语法正确、语气中性。但X平台上的好内容恰恰相反口语化、有棱角、像真人在说话甚至允许有一点不完整句子。所以问题的本质不是模型不会写而是你没有给它“平台内容风格约束”。这就像让一个写惯了公文的人去发朋友圈他不一定写不好只是没人告诉他该用什么调子。Skills里的提示词模板正好用来做这件事。4.2 我最终沉淀下来的提示词模板结构经过几轮测试我把模板固定成以下几个字段每次生成推文时按这个结构填空字段作用示例内容主题推文要表达的核心信息远程办公的三种状态切换目标读者写给谁看的自由职业者、远程工作者语气风格口语/专业/幽默/犀利轻快但不轻浮调用动作希望读者做什么评论区聊聊你的状态切换方法字数上限硬性卡点不超过260字符话题标签关键流量词#远程办公 #效率对应的提示词模板我放在 templates 里大概是这样一段你是目标账号的资深运营编辑。现在需要为以下主题生成一条X平台推文。 主题{topic} 目标读者{audience} 语气风格{tone} 推文要求 - 口语化表达像真人分享不要新闻稿腔。 - 最多2个话题标签。 - 全文不超过260字符。 - 结尾自然引导互动不要生硬喊“点赞收藏”。 参考templates/tweet_style.md中的历史风格先列出3条候选每条控制在1-2句话有独立角度。这里最关键的是“像真人分享”和“不要生硬喊点赞收藏”这两句。我试过没有这两句的版本模型写出来的内容要么过于热情要么过于机械“自然引导互动”这句加上以后效果明显改善。4.3 实测反馈什么样的内容会被一眼识破调试过程中我积累了几个很典型的反面案例。第一种是空泛金句型比如“效率不是做更多事而是做最重要的事”听起来没毛病但没有信息增量放在任何账号上都可以等于没说。第二种是术语堆砌型把所有流行概念都塞进去读起来像机翻论文。第三种是过度互动型每条都要“评论区告诉我你怎么看”看多了像营销号。针对这三种问题我调整模板时加入了一条硬性要求内容里必须包含一个具体细节或一个明确观点不许写正确的废话。少一点空话多一点“我就是这么干的效果如下”式的表达内容质感提升非常明显。这个过程只能靠反复测试没有捷径。我建议你也像我一样把每次生成失败的类型记录下来再反哺给提示词模板。5. 打通“写”到“发”的最后一公里X平台API接入5.1 权限申请先确认账号有“写”的能力发布脚本本身不难写难的是账号权限。X平台的API接入和其他开放平台大同小异你需要先拥有开发者账号然后创建一个应用申请到读、写权限拿到几组密钥。这里最容易踩的坑是权限等级。开发者在申请的时候默认可能是只读权限你调用发布接口时会一直报权限错误。所以在创建应用的时候就要把权限选到“读写”Save之后还要重新生成一遍密钥因为权限变更之前生成的密钥未必会同步更新。申请通过之后你会得到四样东西API Key、API Secret、Access Token、Access Token Secret。这四样好好收着别发给任何人。5.2 发布脚本一次完整的v2接口调用我用的发布脚本逻辑很简单接收文本参数加上OAuth签名POST到发布接口。核心代码差不多是这样import os import requests from requests_oauthlib import OAuth1 API_KEY os.getenv(X_API_KEY) API_SECRET os.getenv(X_API_SECRET) ACCESS_TOKEN os.getenv(X_ACCESS_TOKEN) ACCESS_TOKEN_SECRET os.getenv(X_ACCESS_TOKEN_SECRET) X_API_BASE os.getenv(X_API_BASE, https://api.x.com/2/tweets) def post_tweet(text: str): auth OAuth1(API_KEY, API_SECRET, ACCESS_TOKEN, ACCESS_TOKEN_SECRET) payload {text: text} resp requests.post(X_API_BASE, jsonpayload, authauth) if resp.status_code 201: return resp.json().get(data, {}).get(id) else: raise RuntimeError(f发布失败: {resp.status_code} {resp.text}) if __name__ __main__: import argparse parser argparse.ArgumentParser() parser.add_argument(--text, requiredTrue) args parser.parse_args() tweet_id post_tweet(args.text) print(f发布成功推文ID: {tweet_id})代码里所有密钥都是从环境变量读取的脚本本身不保存任何敏感信息。这是安全基线不是可选项。413、401、403这些状态码我后面会专门整理一个排查表你遇到的时候可以对照着看。5.3 密钥安全差点把Token写进SKILL.md的那次教训前面提到我用 .env 管理密钥这里多说几句。第一次写发布脚本时我真的图省事把某个密钥直接写死在脚本里了想着“反正本地跑没关系”。后来要把这个技能分享给别人参考时才意识到这会造成多大风险——一旦文件外传等于直接把账号管理权拱手送人。所以现在我的规矩是所有密钥一律放 .env 文件脚本里只使用os.getenv()读取.env 和 .gitignore 要把 env 文件排除掉SKILL.md 和模板里绝对不能出现密钥明文。这个习惯一旦养成后续无论做多少自动化项目都受益。5.4 发一条真测试推文看到返回ID才算通写完全套代码之后我先用一条“测试推文”验证链路python scripts/publish_tweet.py --text 测试自动化发布稍后删除。脚本运行成功后控制台会打印一个推文ID。然后可以登录账号手动删除这条测试内容。看到返回ID的那一刻说明整个技术链路已经通了模型生成内容、脚本接收参数、API完成发布。后面要做的就只剩下把模型输出和脚本调用串成一条完整的自动链路。6. 端到端联调从一句“发条推文”到推文自动落地6.1 一次完整调用的流程拆解链路打通之后一次完整的调用大概是这样走的。用户说“整理一篇关于时间管理工具的推文”模型先判断这属于技能的使用范围于是读取 SKILL.md接着读取 templates/tweet_style.md 学习账号风格然后根据模板生成内容。如果配置为需要确认模型会把内容先展示出来如果确认通过或配置为自动发布模型就把文本传给 publish_tweet.py脚本完成接口调用最后把推文链接或ID返回给对话。这个流程在对话里看起来只是几句话背后其实涉及文件读取、模板块、脚本执行、网络请求好几个环节。任何一个环节出问题表现都会像技能“不听话”。所以我用了一个笨办法定位问题手动一步步执行看问题出在哪一层。6.2 定时自动化让系统每天自己发推要让整个系统“全自动”还需要一个定时触发机制。最轻量的方式是使用系统自带的计划任务。我实际用的是 cron配置大概长这样0 9 * * * cd /path/to/skill-x-auto-poster python scripts/scheduled_post.py --topic 今日AI资讯整理 logs/poster.log 21这里的scheduled_post.py是一个调度脚本它和对话环境无关直接读取当天想发的话题调用生成脚本再把内容交给发布脚本。如果某些内容需要模型参与生成调度脚本也可以先调用对应的模型API拿到结果再发布。定时任务引出一个新的问题时区。cron默认按服务器本地时间跑你得先确认机器时区是不是自己想要的时区别让每天九点的发出时间变成凌晨三点。6.3 异常处理限流、重复发布、凭据失效的兜底方案自动发布最怕的就是出问题还没有提示。我在这套流程里加了几层基本的保护。第一层是限流处理如果接口返回429或者超时脚本就等一段时间再重试而不是立刻报错退出。第二层是防重复发布本地维护一个 last_post.json 文件记录最近一次发布的内容如果定时任务被误触发或者不小心重复运行脚本会拒绝再次发布相同内容。{ last_text: 测试自动化发布稍后删除。, last_time: 2025-01-12T09:00:00, last_tweet_id: 123456789 }第三层是凭据失效检测401状态码基本说明密钥有问题这种情况脚本会把连带内容写到一份待审核队列里而不是卡死或者无限重试。有了这三层保护就算某个环节出错也能保证不会把账号刷爆或者发出一堆重复内容。7. 我踩过的坑以及这套方案还能往哪个方向长7.1 三个最痛的教训先帮你避开第一个坑就是SKILL.md描述写得太模糊导致模型经常不触发技能。这个问题排查起来非常费时间因为表面上一切正常没有报错但结果就是模型完全不按技能走。最后我只能逐字读描述把它改得和用户日常表达高度一致触发率才稳定下来。第二个坑是密钥差点外泄这个前面讲过了就不再重复但值得再强调一遍密钥永远不要写进任何会被分享、上传、备份的文件里。第三个坑是定时任务时区错乱我一开始没注意机器时区导致推文全部在凌晨发布账号粉丝在那个时间段活跃度很低内容效果差很多。调整时区后发布数据立刻恢复正常。下面这张表是我后来整理的常见问题排查表直接对着看能省很多时间现象可能原因排查方向401 Unauthorized密钥错误或权限不足重新生成密钥确认读写权限403 Forbidden无发布权限检查开发者应用权限设置429 Too Many Requests触发限流放慢频率加退避重试201但未出现推文发布的是草稿或时间线延迟检查账号时间线稍等刷新模型不触发SkillSKILL.md描述不精确把描述改成贴近用户表达的话定时任务不运行时区/路径/环境变量问题检查cron日志改用绝对路径7.2 这套方案的适用边界别盲目指望全自动必须说清楚这套“全自动发推”方案并不是所有场景都适合。对我这种个人账号、垂直领域内容、需要持续但有节奏产出的人来说它确实帮了大忙。但如果你运营的是品牌官方账号或者内容涉及公关、法律、医疗等高风险领域我不建议全程无人审核。平台对机器化发布内容也有一定的风控机制过于高频或模板痕迹过重的发布行为可能影响账号正常使用。我这里做了一个很务实的取舍生成环节完全自动发布环节默认仍然有人工确认。只有在某个固定专题、已经连续验证了一个月、内容风格也稳定之后我才敢让它跳过确认直接发。全自动和可控之间平衡点要靠自己把控。7.3 后续的几个扩展方向我觉得很值得试这套技能包的扩展空间其实很大。我下一步准备做三件事一是接入RSS订阅源让脚本自动抓取几个固定网站的更新摘要作为“今日主题”直接喂给生成脚本这样连选题都不用手动设了二是通过X平台的公开数据分析不同话题标签下的互动量把表现好的话题自动沉淀成模板参考反哺给提示词三是把发布范围从单条推文扩展到多平台内容矩阵同样的文案改成不同平台的语感风格再分发。做完这套之后我一个很深的体会是工具能替你省掉八成重复动作但剩下两成判断比如什么内容值得发、以什么频率发还是得自己来。第一次跑通全自动发布那个晚上我盯着准备发出的那条推文看了十分钟才舍得让它真的发出去。现在我已经习惯睡前把第二天的选题丢进去醒来再看结果。最后分享一个小技巧新技能上线头两周建议先发到测试账号或者至少保持二次确认发布稳定后再切换到正式账号。别一上来就对着主账号全自动给彼此一点磨合期。 
长河君 · 2026/10/17 7:30:39 · 阅读 1.2k 用Claude Skills打造X平台自动发推机器人：从提示词到API接入全指南
这段时间我一直被“写推文”这件事烦着灵感来了没时间时间来了没灵感好不容易挤出一段话又得复制到X推特网页端点个发布还要纠结半天配图有没有、链接放哪里、话题标签怎么排。于是我想清楚了一件事——与其每天手动作业不如把这条链路打包成一个Claude Skills让AI不只是“给建议”而是把“生成内容到调API发布”整套动作都接过去。我从0到1搓出了这个技能现在只要给一个主题它就能自动生成推文并发出去全程基本不需要我再碰发布页面。这篇教程我尽量写完整Skills的文件结构、提示词设计、X平台API接入、定时自动发布、常见问题全部摊开讲。适合会用Python、但还没碰过平台技能扩展开发的朋友照着一路做下去差不多半天就能跑通。1. 为什么非要搓一个“自动发推”的技能而不是多开几个对话窗口1.1 真正的负担不在“写”而在“写完到发出去”之间刚开始我也天真地以为AI写作已经这么成熟了想一段推文还不简单直接在对话里说“帮我写一条关于AI绘画的推文”就行。实际上偶尔一两条确实没问题但每天都要更新账号内容的人会发现真正的耗时点根本不是生成文案这件事而是那套重复劳动内容生成以后要自己检查长度、加话题标签、调整语气再打开X网页版或手机App粘贴排版检查有没有漏掉链接最后才敢点发布。这个过程一天重复三五次心情很快就没了。所以我的核心目标不是“让AI内容更强”而是“把发布推文这个动作本身自动化”。内容可以慢慢调但步骤必须能一键跑完。想清楚这一点后我决定做的东西不是普通的聊天prompt而是一个可复用的技能包以后不管谁来问只要输入主题系统就按固定流程把草稿、导出、发布整串动作执行完。1.2 为什么选Skills而不是直接写脚本完事其实这个需求用纯脚本也能做写一个Python程序从命令行接收主题组合一批模板句子再调用接口发出去。但只写脚本有几个很现实的问题。第一模板生成的文案像复读机没有语义理解能力稍微换个不常见的话题内容就变得莫名其妙。第二每次想调整语气、换角度、模仿新风格都要去改代码模板维护成本很高。Skills的价值在于把“模型的理解能力”和“脚本的执行能力”拼到一起。模型负责动脑子脚本负责动手。我只需要在这个技能包中定义清楚什么场景触发、按什么顺序执行、调用哪个脚本之后模型会在合适的时候主动把脚本捡起来用。这比纯脚本灵活得多也比每次面对空对话窗口从头交代上下文靠谱得多。1.3 动手之前我确认了三件最基础的事我不是那种“想到就干、干到一半发现平台没开权限”的人所以开工前先把前提条件列了一下。一是确认目标账号是否有开发者权限至少能创建应用并且拿到读写权限二是本地得有能跑Python脚本的环境最好已经装过 requests 这类常用库三是想清楚发推文的用途纯个人分享和营销运营的玩法完全不同这会影响提示词风格和发布频率。这三件事都确认没问题之后我才开始搭目录、写SKILL.md。如果你打算照做也先把这三个前提过一遍免得后面做到API接入那一步才发现账号权限不够又要回头去申请。2. Skills到底是什么先搞清楚这把“螺丝刀”的结构2.1 一个最小可用的Skill由哪几个文件组成在我动手之前我对Skills的第一印象是“大概是个配置文件”。等我拆开看过之后发现事情没那么神秘核心其实就是三块东西一份说明文档、一个或多个可执行脚本、一些辅助资源。说明文档是入口通常命名为 SKILL.md里面写清楚这个技能叫什么、解决什么问题、在什么场景下被触发、具体操作步骤是什么。脚本用来完成实际动作比如生成草稿、调用发布接口。辅助资源可以是示例模板、参考推文、常用话题清单等模型会根据任务内容自行参考。这三个部分不是随便堆在一起而是有组织方式的。我给自己的技能建了一个目录结构大约长这样skill-x-auto-poster/ ├── SKILL.md ├── scripts/ │ ├── generate_draft.py │ └── publish_tweet.py ├── templates/ │ └── tweet_style.md └── assets/ └── examples.mdSKILL.md 在最外层跟 scripts、templates 平级。scripts 里放可执行脚本templates 里放提示词模板和风格参考assets 里放一些辅助数据。这样做的好处是模型发现技能后能很快定位到该看什么文件不会在几十个文件夹里迷路。2.2 SKILL.md 是怎么“告诉”模型该什么时候出手的SKILL.md 很像一份给“新员工”看的操作手册。文件的顶部通常需要填一组元信息包括技能名称和描述。这个描述非常重要因为模型在处理用户请求时会先根据描述判断当前这个任务匹配不匹配该技能。描述写得太宽模型什么任务都可能会尝试调用导致误触发写得太窄模型又识别不出来技能形同虚设。我最初写的版本一直没被触发后来才发现是描述不够准确。我用了“和使用者互动”这种模糊说法模型根本不知道该技能是干嘛的。改成“当用户要求生成或发布X平台推文、处理推特内容更新时使用”之后情况立刻就好了。原理不复杂描述就是给模型看的“检索标签”把触发场景描述得越具体、越贴近用户真实表达命中率越高。2.3 它和普通API封装或者插件的区别在哪里有些人会问既然最后还是调用脚本那为什么不直接做一个API服务我个人的理解是API服务解决的是“系统之间怎么通信”的问题而Skill解决的是“模型在对话中如何自主决定使用什么工具”的问题。前者你把一切流程写死后者你把判断权交给模型让模型根据上下文动态决定要不要调用脚本、调用哪个脚本、传什么参数。这带来一个明显好处交互方式变得非常自然。我不需要记住命令行参数只要说“帮我发一条关于远程工作的推文”模型就会拆解需求、套用模板、生成内容再决定调用发布脚本。整套流程对我来说只有一句话剩下的全部在技能内部完成。这种体验是传统脚本封装很难给的。3. 动手搭骨架环境准备、目录结构与第一版SKILL.md3.1 本地环境依赖清单我建议先列一个最小的环境清单避免中途手忙脚乱。我自己的电脑上是这样一套组合依赖用途备注Python 3.10脚本运行环境3.8应该也能跑但3.10更省心requests、requests_oauthlib调用X平台发布接口OAuth签名时用到python-dotenv管理本地密钥避免密钥写死在脚本里支持加载Skills的客户端环境验证技能触发和调用逻辑不一定需要GUI命令行方式也行如果你不打算本地跑定时任务只是想验证技能能不能用那 Python 环境和 requests 库就够了。密钥管理很重要千万别偷懒后面我会专门讲。3.2 目录这样建后面扩展最舒服我一开始文件的命名很随意后来吃了亏才整理成上面那个结构。核心建议就一条把“生成草稿”和“发布推文”拆成两个独立脚本。为什么因为日常调试时你大概率只想先生成一条内容看看效果并不想真的把它发出去。两个脚本分开以后我可以单独跑生成脚本做内容调试等文案满意了再单独跑发布脚本。混在一起的话每次调试都会发一条测试推文账号很容易被弄成“垃圾内容账号”。另外templates 目录里我放了一份 tweet_style.md里面记录了目标账号常用的口吻、常用话题标签、典型句式。模型生成推文前会参考这份文件这比把风格要求堆在提示词里干净得多。3.3 第一版 SKILL.md 这样写基本能跑我参考了常见的技能包写法写出来的第一版 SKILL.md 大概长这样--- name: x-auto-poster description: 当用户要求生成、编辑、发布X平台推文或想自动更新自己的社交账号内容时使用。 --- # X自动发推技能 ## 使用场景 - 用户给出一个话题、一段想法或一篇长文希望浓缩成推文。 - 用户希望按固定时间或固定频率发布内容。 - 用户希望自动把生成的草稿发布到X平台。 ## 工作流程 1. 先读取 templates/tweet_style.md了解目标账号的语感和风格。 2. 根据用户的输入主题在草稿中生成至少3条候选推文。 3. 将候选推文展示给用户确认除非用户明确表示不需要确认。 4. 调用 scripts/publish_tweet.py 发布确认后的推文。 ## 注意事项 - 推文长度不能超过280个字符。 - 不要在一条推文里堆超过3个话题标签。 - 发布前必须再次检查文案中是否有明显事实错误。这个版本的流程是“先给候选再确认再发布”。为什么不上来就全自动因为早期调试阶段模型的输出风格还不稳定你让它直接发出去风险很大。等观察一段时间确定内容风格没问题了再把“是否需要确认”这个节点改成默认跳过。3.4 第一轮验证先分别跑脚本再整链路测我已经把目录结构和SKILL.md写好了接下来要验证两件事脚本本身有没有bugSKILL.md能不能被模型正确识别。验证方法很简单第一步手动跑发布脚本。python scripts/publish_tweet.py --text 这是一条测试推文这能确认API密钥、权限、网络连通性都没问题。第二步回到对话环境向模型发出一个自然语言请求比如“用这个技能写一条关于效率工具的推文草稿”看看模型会不会主动去读templates里那份风格文件而不是凭空发挥。如果模型完全无视技能说明SKILL.md的描述和写法有问题如果模型能正确提到要调用哪个脚本就说明技能已经被识别到了。我当时的测试结果很典型第一条自然语言请求模型写出来的文案确实像样结构完整也有话题标签但风格完全不对——它用了非常正式的书面语一看就不是社交平台原生内容。这说明脚本没问题问题出在提示词模板和风格参考文件写得太笼统。于是我把工作重心转到了提示词设计上。4. 让AI写出“有网感”的推文提示词模板是这样反复调出来的4.1 为什么通用prompt写不出平台原生内容直接让模型“写一条不错的推文”十次有八次会得到一段规规矩矩、放在官网新闻稿里都毫无违和感的文字。原因是模型在没有明确约束时会倾向于输出四平八稳的“标准答案”结构完整、语法正确、语气中性。但X平台上的好内容恰恰相反口语化、有棱角、像真人在说话甚至允许有一点不完整句子。所以问题的本质不是模型不会写而是你没有给它“平台内容风格约束”。这就像让一个写惯了公文的人去发朋友圈他不一定写不好只是没人告诉他该用什么调子。Skills里的提示词模板正好用来做这件事。4.2 我最终沉淀下来的提示词模板结构经过几轮测试我把模板固定成以下几个字段每次生成推文时按这个结构填空字段作用示例内容主题推文要表达的核心信息远程办公的三种状态切换目标读者写给谁看的自由职业者、远程工作者语气风格口语/专业/幽默/犀利轻快但不轻浮调用动作希望读者做什么评论区聊聊你的状态切换方法字数上限硬性卡点不超过260字符话题标签关键流量词#远程办公 #效率对应的提示词模板我放在 templates 里大概是这样一段你是目标账号的资深运营编辑。现在需要为以下主题生成一条X平台推文。 主题{topic} 目标读者{audience} 语气风格{tone} 推文要求 - 口语化表达像真人分享不要新闻稿腔。 - 最多2个话题标签。 - 全文不超过260字符。 - 结尾自然引导互动不要生硬喊“点赞收藏”。 参考templates/tweet_style.md中的历史风格先列出3条候选每条控制在1-2句话有独立角度。这里最关键的是“像真人分享”和“不要生硬喊点赞收藏”这两句。我试过没有这两句的版本模型写出来的内容要么过于热情要么过于机械“自然引导互动”这句加上以后效果明显改善。4.3 实测反馈什么样的内容会被一眼识破调试过程中我积累了几个很典型的反面案例。第一种是空泛金句型比如“效率不是做更多事而是做最重要的事”听起来没毛病但没有信息增量放在任何账号上都可以等于没说。第二种是术语堆砌型把所有流行概念都塞进去读起来像机翻论文。第三种是过度互动型每条都要“评论区告诉我你怎么看”看多了像营销号。针对这三种问题我调整模板时加入了一条硬性要求内容里必须包含一个具体细节或一个明确观点不许写正确的废话。少一点空话多一点“我就是这么干的效果如下”式的表达内容质感提升非常明显。这个过程只能靠反复测试没有捷径。我建议你也像我一样把每次生成失败的类型记录下来再反哺给提示词模板。5. 打通“写”到“发”的最后一公里X平台API接入5.1 权限申请先确认账号有“写”的能力发布脚本本身不难写难的是账号权限。X平台的API接入和其他开放平台大同小异你需要先拥有开发者账号然后创建一个应用申请到读、写权限拿到几组密钥。这里最容易踩的坑是权限等级。开发者在申请的时候默认可能是只读权限你调用发布接口时会一直报权限错误。所以在创建应用的时候就要把权限选到“读写”Save之后还要重新生成一遍密钥因为权限变更之前生成的密钥未必会同步更新。申请通过之后你会得到四样东西API Key、API Secret、Access Token、Access Token Secret。这四样好好收着别发给任何人。5.2 发布脚本一次完整的v2接口调用我用的发布脚本逻辑很简单接收文本参数加上OAuth签名POST到发布接口。核心代码差不多是这样import os import requests from requests_oauthlib import OAuth1 API_KEY os.getenv(X_API_KEY) API_SECRET os.getenv(X_API_SECRET) ACCESS_TOKEN os.getenv(X_ACCESS_TOKEN) ACCESS_TOKEN_SECRET os.getenv(X_ACCESS_TOKEN_SECRET) X_API_BASE os.getenv(X_API_BASE, https://api.x.com/2/tweets) def post_tweet(text: str): auth OAuth1(API_KEY, API_SECRET, ACCESS_TOKEN, ACCESS_TOKEN_SECRET) payload {text: text} resp requests.post(X_API_BASE, jsonpayload, authauth) if resp.status_code 201: return resp.json().get(data, {}).get(id) else: raise RuntimeError(f发布失败: {resp.status_code} {resp.text}) if __name__ __main__: import argparse parser argparse.ArgumentParser() parser.add_argument(--text, requiredTrue) args parser.parse_args() tweet_id post_tweet(args.text) print(f发布成功推文ID: {tweet_id})代码里所有密钥都是从环境变量读取的脚本本身不保存任何敏感信息。这是安全基线不是可选项。413、401、403这些状态码我后面会专门整理一个排查表你遇到的时候可以对照着看。5.3 密钥安全差点把Token写进SKILL.md的那次教训前面提到我用 .env 管理密钥这里多说几句。第一次写发布脚本时我真的图省事把某个密钥直接写死在脚本里了想着“反正本地跑没关系”。后来要把这个技能分享给别人参考时才意识到这会造成多大风险——一旦文件外传等于直接把账号管理权拱手送人。所以现在我的规矩是所有密钥一律放 .env 文件脚本里只使用os.getenv()读取.env 和 .gitignore 要把 env 文件排除掉SKILL.md 和模板里绝对不能出现密钥明文。这个习惯一旦养成后续无论做多少自动化项目都受益。5.4 发一条真测试推文看到返回ID才算通写完全套代码之后我先用一条“测试推文”验证链路python scripts/publish_tweet.py --text 测试自动化发布稍后删除。脚本运行成功后控制台会打印一个推文ID。然后可以登录账号手动删除这条测试内容。看到返回ID的那一刻说明整个技术链路已经通了模型生成内容、脚本接收参数、API完成发布。后面要做的就只剩下把模型输出和脚本调用串成一条完整的自动链路。6. 端到端联调从一句“发条推文”到推文自动落地6.1 一次完整调用的流程拆解链路打通之后一次完整的调用大概是这样走的。用户说“整理一篇关于时间管理工具的推文”模型先判断这属于技能的使用范围于是读取 SKILL.md接着读取 templates/tweet_style.md 学习账号风格然后根据模板生成内容。如果配置为需要确认模型会把内容先展示出来如果确认通过或配置为自动发布模型就把文本传给 publish_tweet.py脚本完成接口调用最后把推文链接或ID返回给对话。这个流程在对话里看起来只是几句话背后其实涉及文件读取、模板块、脚本执行、网络请求好几个环节。任何一个环节出问题表现都会像技能“不听话”。所以我用了一个笨办法定位问题手动一步步执行看问题出在哪一层。6.2 定时自动化让系统每天自己发推要让整个系统“全自动”还需要一个定时触发机制。最轻量的方式是使用系统自带的计划任务。我实际用的是 cron配置大概长这样0 9 * * * cd /path/to/skill-x-auto-poster python scripts/scheduled_post.py --topic 今日AI资讯整理 logs/poster.log 21这里的scheduled_post.py是一个调度脚本它和对话环境无关直接读取当天想发的话题调用生成脚本再把内容交给发布脚本。如果某些内容需要模型参与生成调度脚本也可以先调用对应的模型API拿到结果再发布。定时任务引出一个新的问题时区。cron默认按服务器本地时间跑你得先确认机器时区是不是自己想要的时区别让每天九点的发出时间变成凌晨三点。6.3 异常处理限流、重复发布、凭据失效的兜底方案自动发布最怕的就是出问题还没有提示。我在这套流程里加了几层基本的保护。第一层是限流处理如果接口返回429或者超时脚本就等一段时间再重试而不是立刻报错退出。第二层是防重复发布本地维护一个 last_post.json 文件记录最近一次发布的内容如果定时任务被误触发或者不小心重复运行脚本会拒绝再次发布相同内容。{ last_text: 测试自动化发布稍后删除。, last_time: 2025-01-12T09:00:00, last_tweet_id: 123456789 }第三层是凭据失效检测401状态码基本说明密钥有问题这种情况脚本会把连带内容写到一份待审核队列里而不是卡死或者无限重试。有了这三层保护就算某个环节出错也能保证不会把账号刷爆或者发出一堆重复内容。7. 我踩过的坑以及这套方案还能往哪个方向长7.1 三个最痛的教训先帮你避开第一个坑就是SKILL.md描述写得太模糊导致模型经常不触发技能。这个问题排查起来非常费时间因为表面上一切正常没有报错但结果就是模型完全不按技能走。最后我只能逐字读描述把它改得和用户日常表达高度一致触发率才稳定下来。第二个坑是密钥差点外泄这个前面讲过了就不再重复但值得再强调一遍密钥永远不要写进任何会被分享、上传、备份的文件里。第三个坑是定时任务时区错乱我一开始没注意机器时区导致推文全部在凌晨发布账号粉丝在那个时间段活跃度很低内容效果差很多。调整时区后发布数据立刻恢复正常。下面这张表是我后来整理的常见问题排查表直接对着看能省很多时间现象可能原因排查方向401 Unauthorized密钥错误或权限不足重新生成密钥确认读写权限403 Forbidden无发布权限检查开发者应用权限设置429 Too Many Requests触发限流放慢频率加退避重试201但未出现推文发布的是草稿或时间线延迟检查账号时间线稍等刷新模型不触发SkillSKILL.md描述不精确把描述改成贴近用户表达的话定时任务不运行时区/路径/环境变量问题检查cron日志改用绝对路径7.2 这套方案的适用边界别盲目指望全自动必须说清楚这套“全自动发推”方案并不是所有场景都适合。对我这种个人账号、垂直领域内容、需要持续但有节奏产出的人来说它确实帮了大忙。但如果你运营的是品牌官方账号或者内容涉及公关、法律、医疗等高风险领域我不建议全程无人审核。平台对机器化发布内容也有一定的风控机制过于高频或模板痕迹过重的发布行为可能影响账号正常使用。我这里做了一个很务实的取舍生成环节完全自动发布环节默认仍然有人工确认。只有在某个固定专题、已经连续验证了一个月、内容风格也稳定之后我才敢让它跳过确认直接发。全自动和可控之间平衡点要靠自己把控。7.3 后续的几个扩展方向我觉得很值得试这套技能包的扩展空间其实很大。我下一步准备做三件事一是接入RSS订阅源让脚本自动抓取几个固定网站的更新摘要作为“今日主题”直接喂给生成脚本这样连选题都不用手动设了二是通过X平台的公开数据分析不同话题标签下的互动量把表现好的话题自动沉淀成模板参考反哺给提示词三是把发布范围从单条推文扩展到多平台内容矩阵同样的文案改成不同平台的语感风格再分发。做完这套之后我一个很深的体会是工具能替你省掉八成重复动作但剩下两成判断比如什么内容值得发、以什么频率发还是得自己来。第一次跑通全自动发布那个晚上我盯着准备发出的那条推文看了十分钟才舍得让它真的发出去。现在我已经习惯睡前把第二天的选题丢进去醒来再看结果。最后分享一个小技巧新技能上线头两周建议先发到测试账号或者至少保持二次确认发布稳定后再切换到正式账号。别一上来就对着主账号全自动给彼此一点磨合期。