永无岛
使用说明
每条提示词的格式：
场景：用在什么时候。 效果：会得到什么。 提示词：完整可复制内容（用
<占位符>标出你需要替换的部分）。 小贴士：进一步调优的方向。
建议：把这一份附录复制成一个 Notepad（参考 第六章），命名为 "prompt-library"，需要时在 Composer 里 @Notepad prompt-library 调用。
一、代码理解类（1-5）
提示词 1：项目快速摸底
场景：拿到一个陌生项目，不知道入口、不知道架构。 效果：5 分钟弄清楚这个项目是干什么的、由什么组成。
我是这个项目的新手，请帮我快速理解它。
请按下面顺序回答：
1. 这是什么类型的项目（前端 / 后端 / 全栈 / CLI / 移动）？技术栈是什么？
2. 入口文件在哪？启动命令是什么？
3. 主要目录的职责（5 行内说完）。
4. 核心数据流是怎么样的（用户操作 → 哪个文件 → 哪个文件 → 数据库）？
5. 如果我要加一个"用户登录"功能，应该在哪几个文件做改动？
请只读 README、package.json、入口文件、主要目录的少数文件，不要把整个项目扫一遍。
小贴士：复杂项目可以让 AI 输出 Mermaid 流程图。
提示词 2：代码段解释
场景：你看不懂一段代码，想知道它在干什么。 效果：得到一段中文白话解释 + 关键概念说明。
@Code 请把这段代码用中文解释给一个完全不懂编程的人听。
要求：
- 用比喻 / 现实例子，不用术语。
- 解释代码"在做什么"，而不是"怎么做"。
- 如果有"为什么"（为什么这么写、有什么取舍），简单说一下。
- 不超过 200 字。
小贴士：换一个观众："请解释给一个会 Python 但不会 JavaScript 的人听"。
提示词 3：找 bug 思路
场景：报错了，但不知道哪里错。 效果：得到一份"可能原因清单 + 排查步骤"。
@File <报错文件>
我遇到这个错误：
<把完整错误堆栈粘贴在这里>
请按下面格式回答：
1. 这个错误是什么意思（一句话）。
2. 最可能的 3 个原因（按概率排序）。
3. 每个原因对应的"如何确认"步骤（具体跑什么命令、看什么文件）。
4. 修复建议（不要直接改代码，先告诉我方案）。
不要假设，多用 "如果...则..." 句式。
小贴士：加上 @Web <错误关键字>，让 AI 现场搜社区方案。
提示词 4：性能审计
场景：网页 / 工具运行变慢。 效果：得到一份"慢点清单 + 优化建议"。
@File <慢的代码文件>
请帮我审一下这个文件的性能问题。
请只列出"很可能造成明显慢"的问题，不要列"代码风格"问题：
- 不必要的重渲染（针对 React / Vue）
- 在循环里跑昂贵操作
- 同步阻塞主线程
- 大对象在内存中保留
- 没有缓存的重复计算
- 数据库 N+1 查询
每条问题：行号 + 一句话说明 + 一句话改法。
小贴士：让 AI 跑 Lighthouse / 性能 profile，参考结果再来优化。
提示词 5：安全审查
场景：上线前 / 处理用户数据时。 效果：得到一份安全问题清单。
@File <文件>
请扮演一个安全工程师，审一遍这段代码。
重点找：
1. SQL 注入、XSS、CSRF
2. 密码 / 密钥 / token 硬编码
3. 不安全的 deserialize
4. 没有 rate limit 的接口
5. 用户输入没验证就用
6. 敏感数据明文存储 / 日志输出
7. 不安全的依赖版本
每个问题：严重度（高 / 中 / 低）+ 一句话说明 + 修复方向。
如果没问题，明确说"未发现明显安全问题"。
二、写代码类（6-10）
提示词 6：从需求生成代码
场景：心里有个想法，需要 AI 把它变成代码。 效果：得到符合所有约束的可运行代码。
我要做一个 <什么>，下面是详细需求。
【目标】
<一句话目标>
【输入】
<用户提供什么 / 系统接收什么>
【输出】
<用户看到什么 / 系统返回什么>
【功能列表】
1. ...
2. ...
3. ...
【技术约束】
- 框架：<React / Next.js / 纯 HTML>
- 不引入新依赖
- 中文界面
- 风格参考 <Linear / Stripe / 某网站>
【上下文】
<相关现有文件 / 相关文档 @File @Folder @Web>
请：
1. 先列方案（≤ 5 步）
2. 等我说"开始"
3. 然后按方案动手，每完成一步告诉我
小贴士：<...> 都换成你的具体内容。每加一行约束，输出质量提升 10%。
提示词 7：参考已有代码风格写新代码
场景：项目已经有某种代码风格，你想新代码也这样。 效果：新代码无缝融入现有项目。
@File <参考文件>
@File <你想新建 / 修改的文件>
请新建一个 <要做的事> 模块，要求：
- 完全照 <参考文件> 的风格、命名、注释、错误处理。
- 文件名 <文件名>。
- 不引入新依赖。
- 写完跑一下 lint，确保通过。
提示词 8：把需求拆成 PR
场景：一个大需求，要拆成多个小 PR 渐进上线。 效果：得到一份"PR 拆分计划"。
我要实现这个需求：<完整需求>。
我希望拆成多个小 PR，每个 PR：
- 改动 ≤ 5 个文件
- 一个 PR 一个独立的"用户可见的小价值"
- 不依赖未合并的 PR（每个独立可上线）
请按下面格式输出：
PR 1：<标题>
- 价值：<用户能感知的好处>
- 改动：<文件清单>
- 风险：<可能出问题的点>
- 估时：<人时>
PR 2：...
提示词 9：测试覆盖
场景：新写完代码，想加测试。 效果：得到一组测试，覆盖正常 / 边界 / 错误路径。
@File <代码文件>
请为这个文件写完整测试，要求：
- 测试框架：<vitest / jest / pytest>
- 文件位置：tests/<对应路径>.test.ts
- 覆盖：正常路径、3 个边界条件、3 个错误路径
- 给每个测试一句中文注释说明测什么
- 写完跑一遍，确保全部通过
- 如果发现源代码有 bug，告诉我，但不要直接改
输出后告诉我：
- 测试覆盖率多少
- 还有哪些场景值得加测试
提示词 10：i18n 国际化
场景：把项目从单语言扩展成多语言。 效果：得到一份完整 i18n 改造方案 + 代码。
@Folder src/
请帮我给这个项目加 i18n 多语言支持，目标语言：
- 简体中文（默认）
- 英语
要求：
1. 用 <next-intl / react-intl / 你推荐的方案>
2. 提取所有"用户可见文本"到 locale 文件
3. 不动代码逻辑，只动文本
4. 默认语言中文，URL 不带前缀；英文 URL 加 /en 前缀
5. 顶部加语言切换器（中 / EN）
6. 改完跑测试
先列方案：
- 装哪些依赖
- 在哪里建 locale 文件
- 改哪些核心文件
- 中间会有什么风险
三、Refactor / 重构类（11-15）
提示词 11：通用重构
@File <代码文件>
请重构这段代码。目标：
- 可读性优先
- 减少嵌套
- 拆出小函数
- 命名更清晰
- 不改变外部行为
约束：
- 保持所有 export 接口签名不变
- 保持所有现有测试能跑通
先列出"打算怎么重构"的清单（≤ 5 项），等我说"开始"。
提示词 12：改命名
@File <文件>
现在这个变量 / 函数命名不好。请帮我提 3 个候选命名（A / B / C），分别说明：
- 含义最准的（A）
- 最简短的（B）
- 业界最常见的（C）
我决定后再统一改全文件。
提示词 13：拆超大文件
@File <超过 500 行的大文件>
这个文件太大了，难维护。请帮我拆分。
要求：
1. 先分析它有哪几个"内聚的功能模块"。
2. 给一个拆分方案：拆成几个小文件、每个叫什么名、负责什么。
3. 等我同意后，按方案拆，确保所有 import / export 正确。
4. 拆完不破坏现有功能（跑一遍测试）。
如果你发现"其实文件该这么大，拆了反而难懂"，明确告诉我"不建议拆"+ 原因。
提示词 14：从框架 A 迁到框架 B
@File <文件>
@Folder <相关文件夹>
请帮我把这一块从 <Vue 2> 迁移到 <Vue 3>。
要求：
1. 先列差异点（最多 10 条）。
2. 列改动文件清单。
3. 列可能的"破坏性变更"。
4. 等我同意后开始迁。
5. 一边迁一边告诉我进度。
6. 迁完跑测试，确保功能不变。
如果发现某处"无法直接迁"，停下来告诉我，给 2 个方案。
提示词 15：依赖升级
@File package.json
请帮我升级所有依赖到最新版本。
要求：
1. 先 npm outdated 看现状。
2. 分类列出："小版本升级（安全）" / "主版本升级（要看 changelog）" / "已废弃要换替代"。
3. 先升所有"小版本"，跑测试确保通过。
4. 主版本升级一个一个来，每升一个跑一次测试。
5. 已废弃的告诉我替代方案，让我决定。
每一步都告诉我进度，不要静默操作。
四、文档与写作类（16-20）
提示词 16：写 README
@Folder <项目根目录>
@File package.json
@File <主入口文件>
请帮我给这个项目写一份 README.md。
结构：
1. 项目名 + 一句话定位（吸引人）
2. 截图占位（我后面自己加）
3. 它能解决什么问题（2-3 条）
4. 它适合谁用（1-2 条）
5. 安装方式（一段命令）
6. 快速开始（3 步以内）
7. 主要功能列表
8. 技术栈
9. 贡献指南（一段）
10. 协议
要求：
- 中文，少术语，多比喻。
- 不要说"基于最新的现代化技术"这种空话。
- 不要堆 emoji。
提示词 17：API 文档
@File <API 路由 / 控制器文件>
请帮我为这些 API 写文档。每个 endpoint 包含：
- 方法 + 路径
- 一句话说明
- 入参（位置：URL / Query / Body / Header）
- 字段名 / 类型 / 必填 / 说明 / 示例
- 出参
- 字段名 / 类型 / 说明 / 示例
- 错误码（每个都给一个示例响应）
- curl 调用示例
输出 markdown，结构紧凑，方便复制到 Notion / Confluence。
提示词 18：Changelog
@Git 看最近的提交记录。
请生成一份 v<版本号> 的 changelog，结构：
# v1.2.0（2026-04-19）
## 🎯 新功能
- ...
- ...
## 🐛 修复
- ...
## 🏎 性能
- ...
## 🔧 改进
- ...
## ⚠️ 破坏性变更
- ...
要求：
- 每条 ≤ 30 字，写"用户能感知到什么"，不要写"内部实现"。
- 重要项标注 PR 编号 #123。
- 没有的分类直接省略。
提示词 19：博客文章
请按下面要求写一篇博客文章。
【主题】
<比如"我用 Cursor 一个月做了 3 个小工具的复盘">
【目标读者】
<比如"独立开发者、想做副业的上班族">
【字数】
<比如"1500-2000 字">
【结构】
- 引子（一个反差强烈的开头，拉读者进来）
- 正文（3-5 个小节，每节有小标题）
- 结尾（一个让人收藏 / 转发的金句）
【风格】
- 第一人称，像和朋友聊天
- 短句多、长句少
- 不堆术语
- 加 1-2 个真实数字 / 截图占位
- 最后留一个互动问题
【约束】
- 不许用"在这个时代"、"让我们"、"comprehensive"
- 不许堆 emoji
提示词 20：邮件 / 信息
请帮我写一封邮件 / 一段信息。
【场景】
<给客户 / 给老板 / 给同事>
【目标】
<你希望对方做什么 / 知道什么>
【背景】
<对方知道什么 / 不知道什么>
【约束】
- 字数 <50 / 100 / 200> 字以内
- 语气 <正式 / 友好 / 紧急>
- 称呼 <张总 / 老王 / Hi 张三>
请给 3 个版本：保守、平衡、有点小巧思。
五、Agent 与多步工作流（21-25）
提示词 21：从 Issue 到 PR
@github 找 issue #<number>。
请按下面流程做：
1. 读 issue 完整描述（包括评论）。
2. 在 worktree fix-issue-<number> 里 checkout 一个新分支。
3. 复现 issue 描述的问题（写一个最小化测试）。
4. 修复代码。
5. 跑测试确认通过。
6. commit + push。
7. 开 PR：
- 标题："fix: <一句话总结>"
- body：包含 "Fixes #<number>"、改动概要、测试方法
- 标签：bug / fixed-in-v1.x
整个过程在 Cloud Agent 跑，不要占我本地资源。
提示词 22：每周自动化任务
我希望每周一早上 9 点跑一次"项目体检"，请帮我配置 Background Agent。
任务清单：
1. 跑 npm outdated，把"主版本落后 ≥ 1"的开成 issue（一个依赖一个 issue）。
2. 跑 npm audit，发现高危漏洞自动开 issue。
3. 跑 lint + test，挂了就开 issue 标 "ci-failure"。
4. 跑 lighthouse 主页，得分降 10 分以上开 issue 标 "perf-regression"。
5. 跑完汇总一份"周一健康报告"评论到一个固定 issue（pinned）。
请把这些写到 .cursor/background.yaml 里。
提示词 23：用 Best-of-N 重构
/best-of-n 3
@File <难重构的复杂文件>
请用 3 个不同的策略重构这个文件：
- composer-2：保守版（最少改动）
- claude-4.6-sonnet：标准版（合理拆分）
- gpt-5.4-medium：激进版（最大化可读性 / 模块化）
每份给我一份"改动 diff 摘要"和"我为什么这么做"。
我会挑一个使用。
提示词 24：从 Figma 到代码
@figma <Figma 链接>
@File <相关项目目录>
请把这个 Figma 设计稿实现成 React 组件。
要求：
- 像素级一致（颜色 / 间距 / 字号）
- 用 TailwindCSS
- 复用项目里已有的 <Button / Input / Card> 组件（看 components/ 目录）
- 响应式（手机 + PC）
- 加 hover / focus / disabled 状态
- 写完用内置浏览器自己看一眼，对比 Figma，找差异自己改
如果某个细节 Figma 没标清楚（比如圆角、阴影），用项目现有风格的合理默认值。
提示词 25：自动 Code Review
/review
请扮演一位严格的高级工程师，审这次的改动。
按下面 4 个维度：
【正确性】
- 有明显 bug 吗？
- 边界条件考虑了吗？
- 错误处理完整吗？
【可读性】
- 命名清晰吗？
- 函数太长吗？
- 注释是否多余 / 缺失？
【性能】
- 有明显性能隐患吗？
【安全】
- 有安全问题吗？
每条问题：
- 文件 + 行号
- 严重度（必须修 / 建议修 / 可忽略）
- 一句话说明
- 一句话改法（不要直接改代码）
最后给一个总评：可合并 / 需修改后再看 / 拒绝。
六、生活 + 工作快用（26-30）
提示词 26：会议纪要清洗
我有一段会议转写，请帮我整理成纪要。
转写：
<把转写文本粘贴在这里>
请按下面格式输出：
# <日期> <主题> 纪要
## 与会
<推断出与会者列表>
## 决议
- ...
- ...
## 待办
- [ ] @<人> <事>（截止 <日期>）
## 风险
- ...
## 后续讨论
- ...
要求：
- 中文
- 不超过原文 1/4 长度
- 决议 / 待办 / 风险一个不漏
提示词 27：周报生成
本周我做了下面这些事，帮我整理成 5 段式周报：
<把流水账写在这里：周一干了什么、周二干了什么...>
格式：
# 周报 <YYYY-WW>
## 一周完成
- ...
## 进行中
- ...
## 下周计划
- ...
## 风险与问题
- ...
## 数据指标
- ...（如果原文里有数字就提取，没有就省略）
要求：
- 中文，简洁，每条 ≤ 30 字
- 突出"用户 / 业务感知"，不要堆"内部技术细节"
- 长度控制在 600 字以内
提示词 28：把"长说明"变成"操作步骤"
我把一段冗长的说明文档贴在下面：
<贴文档>
请帮我转成"我跟着做就能完成"的操作步骤：
1. ...（具体动作）
2. ...
3. ...
要求：
- 每步只做一件事
- 每步以动词开头（"打开"、"点击"、"输入"...）
- 包含"在哪里点"、"输入什么"
- 总步数 ≤ 10
- 跳过原文中的"为什么这么做"、"背景介绍"
提示词 29：把代码 / 数据可视化
我有下面这份数据：
<csv / json / 表格>
请帮我做一个网页可视化：
- 单文件 index.html（HTML + 内联 CSS + 内联 JS）
- 不引入任何外部库（自己用 SVG 画图）
- 包含：
- 顶部一个数字大字摘要
- 中间一张主图（饼 / 柱 / 折线，你判断哪种最合适）
- 底部一份原始数据表格
中文界面、简洁风格。
提示词 30：让 AI 自我改进
回头看一下你刚才给的回答 / 写的代码。
请：
1. 列出至少 3 个你觉得做得不够好的地方。
2. 每个不好的地方说明：为什么不够好。
3. 如何改进：给一个具体方案。
4. 等我说"按你说的改"，再动手。
你要扮演一个挑剔的 reviewer，不要只夸自己。
小贴士：这条提示词能让 AI 输出质量提升 30-50%。养成"每次大任务后追问一次"的习惯。
综合贴士
贴士 1：用 Notepad 收纳
把你最爱的几条 +1 一起放进 .cursor/notepads/prompt-library.md，需要时 @Notepad prompt-library。
贴士 2：先用再改
不要追求"完美提示词"。先复制粘贴用一次，看 AI 输出再调。
贴士 3：每条都写"约束"
写不写"约束"是普通提示词和高质量提示词的最大差。
贴士 4：让 AI 反过来给提示词
有时候你不知道怎么问，可以反过来：
我想让你帮我做 <事>。
请你帮我设计一份"完美的提示词"——告诉你什么背景、什么约束、什么输出格式、什么参考。
我看完会用这份提示词重新和你对话。
AI 会给你一份模板，你按模板填。
贴士 5：分享你的提示词
好提示词很贵——一旦你磨出一条，分享给团队 / 网友。社区会还你 10 倍价值。