实战：把个人表达沉淀为 AI Agent Skills，建立不靠复制粘贴的跨平台内容工作流
技术团队做内容时，最耗时间的往往不是「让模型写一段文字」，而是反复补齐上下文：这篇文章面向谁、哪些观点不能说得太满、LinkedIn 和 X 分别该怎样组织、怎样把一篇长文拆成一周的发布计划。把同一段文案机械地贴到多个平台，通常既不符合平台格式，也会丢掉自己的表达习惯。
Social media skills for AI Agents 提供了一个值得借鉴的解决方式：不是另做一个内容 SaaS，而是把这套流程写成可安装的 Agent Skills。项目采用 MIT 许可证，当前包含 13 个面向社交内容的技能；它们不要求连接社交账号或调用平台 API，重点是把「上下文—草拟—校验」变成可复用的本地工作流。
这类项目属于自动化工作流与个人生产力题材。它尤其适合已有 Claude Code 或兼容 Skills 的 Agent 环境、同时需要稳定输出技术内容的开发者或小团队。
先解决根本问题：不要每次都重新解释你是谁
许多人给 AI 的提示词很长，却缺少一个可持续更新的「内容配置层」。一次写得不错，不代表下次还会保留同样的受众边界、语气和选题支柱。
Social Skills 的起点是 social-context。按照项目说明，运行初始化后，它会在不超过十个问题的访谈中收集受众、发布平台、内容支柱、表达偏好与不愿发布的内容，并生成 social-context.md。其他技能读取这份文件，而不是要求用户在每次任务里重新粘贴背景。
另一个基础技能是 voice：它要求提供 3 到 10 个真实写作样本，分析句长、节奏、词汇、标点、开头、结尾和幽默风格。这里的边界很重要：它是在归纳用户给出的样本，不是声称能凭空「模仿真人」。发布前仍然应由作者检查观点和措辞。
安装：先让 Agent 找到正确的 Skills 目录
项目 README 给出的基础安装命令如下：
npx skills add inklate/social-skills
如果在非交互式环境中由 Agent 执行，项目特别提示：安装结果可能只落在 .agents/skills/，而 Claude Code 不会读取这个位置。此时应显式指定 Agent：
npx skills add inklate/social-skills -a claude-code
也可以只安装跨平台改写技能，减少不需要的上下文：
npx skills add inklate/social-skills --skill cross-post
对使用 Claude Code 插件机制的场景，README 还给出了一条可自动更新的插件路径：
/plugin marketplace add inklate/social-skills /plugin install social-skills@inklate
安装后，不要急着让 Agent 连续生成十篇帖子。先按 README 的建议说出「set up my social context」，完成内容上下文。建议把生成的 social-context.md 纳入个人知识库或仓库，并像维护项目配置一样在目标受众、产品定位发生变化时更新它。
把一篇技术文章拆成可审查的流水线
13 个技能并不是 13 个彼此割裂的提示词。可以按下面的顺序组织一次发布，而每一步都保留人工审查点。
| 阶段 | 可用技能 | 产物与人工检查点 |
| — | — | — |
| 建立约束 | social-context、voice | 内容边界与表达样本；确认不会暴露客户信息、未公开路线图或敏感数据 |
| 找切入点 | hooks | 为一个主题给出八个评分的开头选项；人工选择，不把评分当成真实性判断 |
| 平台化草拟 | linkedin-post、x-thread、carousel | LinkedIn 文案、带字符数提示的 X 线程、或轮播图逐页脚本 |
| 长文再利用 | repurpose、cross-post | 从文章、视频转录或演讲中抽取观点，生成多个平台的草稿 |
| 计划与发布前检查 | content-calendar、post-check | 两周内容计划与平台约束检查；最后仍由人确认链接、事实和 CTA |
其中 cross-post 的价值不在于「一键全平台发送」。它的目标是为 LinkedIn、X、Instagram、Facebook、Threads、Bluesky 和 Mastodon 分别生成更贴近平台的草稿，调整语气、长度、结构、标签和格式。因此，正确用法是把它作为改写层，而不是自动发布器。
一个适合技术博客的最小实践
假设团队刚写完一篇关于数据库迁移事故复盘的长文。与其要求 Agent「把文章推广到所有平台」，不如给出清晰的任务边界：原文链接、可公开的三条结论、不能披露的字段，以及希望读者采取的下一步行动。
第一步，用 repurpose 从长文中抽取可独立理解的观点；第二步，让 hooks 为最值得讨论的一点提出不同开场；第三步，为 LinkedIn 和 X 分别生成草稿；最后用 post-check 检查目标平台的约束。对技术内容来说，人工审核至少要覆盖三项：数字和结论能否回到原文验证、代码或命令是否会误导读者、外链是否指向稳定的一手资料。
这种分层比「一次性生成最终稿」更可靠。因为你可以在每个中间产物处否决不合适的表述，而不是等到发布前面对一大段混杂了事实、营销语和格式问题的文本。
它不替你完成的事
Skills 能沉淀流程，但不会自动获得平台权限，也不能替你判断一条结论是否适合公开。项目 README 明确定位为不需要账号、不需要 API 的内容技能集合；因此，实际发帖、读取私信或分析平台实时数据并不在它的承诺范围内。
另外，voice 依赖写作样本，social-context 依赖访谈回答。输入含糊时，输出只会更像「通用 AI 文案」。对于技术读者，宁可把工作流设计成「Agent 先出草稿，人确认事实和立场，再手动发布」，也不要把高频产出误当成内容质量。
结语
Social Skills 的启发不只是社交媒体写作。它展示了一种通用方法：把高频、可描述、需要稳定上下文的个人流程拆成 Skills；用一份共享上下文减少重复提示；再把生成、检查和最终决策分开。无论是写技术周报、维护开源项目更新，还是把长文改编为多种渠道的草稿，这种「可组合、可审查」的自动化都比孤立的万能提示词更容易长期维护。
相关链接