Cursor写开源项目文案提示词怎么按平台语气调整

为同一款开源项目写介绍文案，需要适配GitHub README、Dev.to技术博客和Twitter/X短文案三种平台，但很多人在实际操作中会发现，直接让AI输出“写三版项目介绍”的结果往往不理想——语调雷同、长度失衡、技术密度完全错位。GitHub需要模块化的结构加可点击的链接，Dev.to要带个人叙事和踩坑细节，Twitter则必须用动词开头、省略主语、埋下钩子。下面讲讲具体怎么拆解。

GitHub README 版：突出结构化与可操作性

方法很简单。打开项目根目录下的 README.md 文件，将光标定位在 `## Features` 标题下方的空白行。然后输入提示词：

“你是一名开源项目维护者，正在为 GitHub 页面撰写 README。请严格按以下输出：

；功能点数量控制在 5 条以内；所有链接使用相对路径（如 ./docs/installation.md）；禁用‘非常’‘超级’等副词。”

接着按 Cmd+K（macOS）或 Ctrl+K（Windows/Linux）触发 AI，等待生成结果直接插入就行。这样一来，功能点清晰、可操作性极强，读者一眼就能看到关键。

Dev.to 博客版：注入真实开发节奏与情绪颗粒度

有两种方法能让 Dev.to 的文案更有温度。

在 Dev.to 编辑器中新建草稿，输入：“我在把项目从 Vite 迁移到 Turbopack 时卡了整整两天，直到发现 config.resolve.alias 的路径解析规则变了 —— 请基于这个真实卡点，写一篇面向中级前端的 Dev.to 博客导语，要求：① 开头用‘上周五下午 3:17’这类具体时间戳；② 第二句必须出现一个失败命令（如 ‘turbopack dev’ 报错）；③ 第三句用‘后来我……’引出解决方案；④ 全文不超过 120 字，不加标题。”

操作的诀窍是直接把光标放在编辑器第一行就敲，AI 会自动继承你输入时的急迫感。这样生成的导语真实感很强，读者会立刻被带入场景。

复制一条真实 issue 的标题，比如“#428 SSR hydration mismatch on mobile Safari”。然后在提示词里写：“把这条 issue 改写成 Dev.to 博客正文中的一个技术反思段落，语气像同事下班后在 Slack 里吐槽，用‘我们试了 A、B、C，最后发现是 X 没配对’结构，保留 issue 编号但不加链接。”

这种方法能直接利用已有的问题，让内容更有深度，也更容易引发共鸣。

Twitter/X 版：压缩到动词驱动的单行信息流

打开 Twitter 编辑框，输入提示词：“你正在为开源项目发推，目标是让开发者一眼想点进链接。请生成一条纯文本推文：

；内容聚焦一个具体变更（如‘迁移到 Bun 0.8.0 后冷启动快 3.2 倍’）；禁止出现‘我们’‘团队’等人称主语。”

需要特别警惕的是，如果 AI 输出里出现“点击了解详情”，立刻删掉。Twitter 用户不会点这种话术，他们只对“动词+数字+emoji”的组合感兴趣。