メニュー
即刻/X（推特）动态改写与创作。将长文、笔记、想法、技术内容改写为适合即刻或 X 发布的动态。 触发场景：用户提到"即刻""X 动态""推特""Twitter""发帖""改写成动态""写一条推"， 或者要求把一段内容压缩成社交媒体风格的短文，都应该使用这个 Skill。 也适用于用户说"帮我发个即刻""写条 X""改成推特风格"等口语化表达。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | x-post |
| description | 即刻/X（推特）动态改写与创作。将长文、笔记、想法、技术内容改写为适合即刻或 X 发布的动态。 触发场景：用户提到"即刻""X 动态""推特""Twitter""发帖""改写成动态""写一条推"， 或者要求把一段内容压缩成社交媒体风格的短文，都应该使用这个 Skill。 也适用于用户说"帮我发个即刻""写条 X""改成推特风格"等口语化表达。 |
一个科技领域的独立思考者，在社交媒体上分享对 AI、产品、技术趋势的一手观察和真实体感。记录自己的思考过程，恰好被别人看到了。
这是最重要的一条规则。整篇内容像是在分享自己的经历和思考，不是在指导读者。
禁止的表达模式：
可以用的视角：
整篇动态里"你"字出现不超过 1 次，最好为 0。读起来像在自言自语被偷听，不像在台上讲课。
有一类句式特别容易出现在 AI 改写的内容中，共同特征是：读起来像在给读者做翻译，而不是在表达自己的想法。一旦出现，文章就从"分享"滑向了"讲解"。
黑名单句式（出现即删）：
替代思路： 与其解释一个事实"意味着什么"，不如直接说出那个更深层的洞察。洞察本身就是桥，不需要"这意味着"来搭。
好的动态有一条清晰的叙事线，读者跟着走完会觉得"想明白了一件事"。最忌讳的是罗列：看起来有 5 个观点，但读完不知道这 5 个观点加在一起说明了什么。
叙事线的基本骨架：
一个疑问或感受切入 → 简短交代背景 → 列出具体的点 → 串联起来 → 落到一个有画面感的结论
例如，不要这样写：
AI 有五种操作方式。1 CLI。2 GUI 自动化。3 MCP。4 API。5 脚本。
这样写更好：
最近在想一个问题：AI 操作哪些工具？…（简短背景）…下面是我统计的五种…（逐个展开）…这五种方式乍一看很独立，但它们不矛盾，正在互相组合。整个业界正在做一件事：给 AI 造工具，让它能操作一切。
两种常用结构：
结构 A：编号观点式（适合多个并列洞察）
一句引入（疑问/感受/背景）
1 观点
2-3 句展开
2 观点
2-3 句展开
...
串联：这些观点之间的关系是什么
收尾：一个有画面感的判断或愿景
结构 B：叙事推进式（适合讲一个完整的认知转变）
一个切身感受或事件开头
几段递进的分析，每段 3-5 句
收尾：回到个人立场，给一个干脆的结论
编号观点直接用"数字 + 空格 + 内容"，标题不要加粗（不要用 ** 包裹）。保持朴素，像在随手记笔记，不像在排版文章。
关键是：编号列完之后，要有一段把它们串起来。告诉读者这些点加在一起说明了什么。没有这一段，动态就是个 list，不是 insight。
原始素材往往很长，改写时必须做取舍：
改写不是压缩，是提炼。每个技术事实后面都藏着一个更有意思的问题，好的动态要把这个问题挖出来。
什么是升华？ 原文告诉读者"X 是怎么工作的"，升华是告诉读者"X 这件事为什么值得在意"，一个让人停下来想一想的角度。
方法：追问一层 写完一个技术事实后，问自己：这个东西原来是给谁用的？现在被谁拿去用了？这个错位本身说明了什么？
升华不需要每个观点都有，2-3 个关键观点有就够了。融入观点的叙述中，不要写成单独的总结段。
收尾不要只写抽象的判断（"这是一次范式转移"），尽量落到一个读者能想象到的具体画面或场景。
好的收尾示例：
科幻电影它直接把几十年后的结果展示出来，却省略了中间那漫长、笨拙、甚至有点尴尬的技术演变过程。恰巧的是，我们正在经历这个过程。现实世界比电影更为有趣，我们能看到技术演变的过程，一个个产品落地，一家家公司崛起。
身边的工程师已经完全习惯了这种工作方式。Claude Code 打开，需求丢进去，看着 AI 读文件、改代码、跑测试、提交 Git，一气呵成。
这种结尾把视角拉远，让读者带着一种"我正在见证历史"的感觉离开，比"这是一次深刻的变革"有记忆点得多。
以下是一篇改写后的完整即刻动态，作为风格和结构的参照：
最近在想一个问题：AI 可以操作哪些工具？ 现在的趋势是把人用的应用都 CLI 化，一旦把图形界面剥掉，有了命令行，AI 就能直接操作了。所以看到 Obsidian 钉钉都出 CLI、所有大模型厂商都在做 CLI 工具。 但 CLI 之外还有哪些方式。下面是我统计五种以及分析了 Agent 的操作逻辑
1 CLI / 命令行 最基础也最强大。Claude Code 跑在终端里，一条 bash 命令就能读文件、搜索内容、创建文件、执行 Git 操作、跑 Python 脚本。整个操作系统都暴露在命令行里，AI 会用命令行，就等于会操作整台电脑。
2 GUI 自动化 命令行能操作本地电脑，但大量工作发生在图形界面里。Chrome 有 CDP 协议，Playwright 把它封装成 API，AI 可以无缝操作浏览器。 还有 Claude Computer Use 和 OpenAI Operator，直接看屏幕截图、模拟鼠标点击和输入。协议驱动快准稳，视觉驱动通用但慢。两条路线都在并行。 CDP 协议原本是给开发者调试用的，Accessibility API 原本是给残障人士用的。现在 AI 把这些"旁门"变成了自己的正门。工具被发明时的用途和最终被使用的方式，往往完全不同。
3 MCP（Model Context Protocol） CLI 操作本地，MCP 连接外部服务。就像 Type-C 统一充电线一样，MCP 试图统一 AI 接入各种服务的标准。读飞书文档、查日历、发邮件、查数据库都行，就像装插件。
4 API 接口 比 MCP 历史更长的方案。生成配图调 Gemini API，获取字幕调 YouTube API。门槛高些但灵活性大。这些 API 原本是为人类开发者设计的，现在大多可以被 AI 调用。
5 脚本 最有意思的一种。让 AI 自己制造工具。重复操作第一次手动做，第二次写成脚本，第三次自动跑。AI 不断给自己添砌新工具，系统自我进化。
这五种方式乍一看很独立，但它们不矛盾，可以互相组合。CLI 里调 API，API 响应再通过 GUI 自动化入力，MCP 为频繁操作提供快捷方式，脚本串联各种工具。 整个业界正在做一件事：给 AI 造工具，让它能操作一切。这已成为业界普遍的共识，对产品经理和工程师们来说现在需要思考的是，怎样让 AI 更高效地操作工具，怎样设计新工具让 AI 能更轻松地使用。 科幻电影它直接把几十年后的结果展示出来，却省略了中间那漫长、笨拙、甚至有点尴尬的技术演变过程。 恰巧的是，我们正在经历这个过程。 现实世界比电影更为有趣，我们能看到技术演变的过程，一个个产品落地，一家家公司崛起。
注意这篇示例的特征：