cursor使用记录
·
生成设计图
请从产品经理和设计师的角度，用HTML设计一个番茄工作法iOS应用原型图。注意，你需要在一页完成所有必要的界面原型，设计应精美、完整，包含所有状态和交互细节，可使用开源图标库丰富视觉元素，并能直接供开发团队参考实现。
如果生成不完整，就让AI继续生成, 需要检查是否有重复部分
生成代码
可以使用chrome插件，把原型图做完整的截图，然后创建项目，chat中选择截图，输入：根据原型图完成App所有功能的开发
cursor添加MCP
https://github.com/modelcontextprotocol/servers 一些可用资源
我们现在添加一个文件系统mcp，从官方复制配置过来
{
"mcpServers": {
"filesystem": {
"command": "cmd", //win特有，官方给的是mac的
"args": [
"/c", //win
"npx", //win
"-y",
"@modelcontextprotocol/server-filesystem",
"D:\\whb\\github"
]
}
}
}
对于python开发的mcp，以时间为例，查看官方说明
pip install mcp-server-time 安装服务
配置：
{
"mcpServers": {
"time": {
"command": "python",
"args": ["-m", "mcp_server_time", "--local-timezone=Asia/Shanghai"]
}
}
}
还有常用的：https://github.com/grab/cursor-talk-to-figma-mcp
Skill
个人感觉cursor的skill是规则，类似于rule
比如：文档生成器，你可以添加skill，让ai帮你生成，他会让你选择生成规则，生成时机，使用时机，影响范围
只需要在项目根目录新建.cursor/skills/auto-doc-generator/SKILL.md，把下面这份内容复制到 SKILL.md 即可。
--- name: auto-doc-generator description: 自动从代码和项目结构生成 API 文档、README 与架构设计说明，并帮助撰写与改动相关的提交/PR 文档。用于用户显式请求文档生成，或在编写提交说明、PR 描述时需要自动补全文档的场景。 --- # 自动文档生成器 ## 使用场景 在以下场景优先使用本 Skill： 1. 用户要求生成或完善文档： - API 文档、接口说明、模块说明 - README、使用说明、快速开始 - 架构/设计文档（模块关系、数据流、调用流程） 2. 用户在写提交信息或 PR 描述时，希望自动生成： - 变更摘要 - 影响范围与风险 - 需要更新/新增的文档片段 **默认输出语言：中文。** 如用户明确要求英文或双语，再切换对应语言或补充英文版本。 --- ## 通用工作流程 1. **识别文档类型与读者** - 明确当前要生成的是： - API 文档 / 接口说明 - README / 使用文档 - 架构/设计文档 - 提交信息 / PR 描述 / 变更说明 - 判断目标读者：普通使用者、项目开发者、Reviewer，选择合适的技术深度与术语。 2. **收集上下文** - 使用 `Read` / `Grep` / `SemanticSearch` 等工具，优先从以下来源提取信息： - 相关代码文件及其注释（尤其是公共接口、导出符号） - 现有的 README、架构文档、设计说明 - Git diff / 提交记录（用于生成变更说明与 PR 描述） - 如信息不足且存在多种合理解释，**先在文档中标记假设**，而不是编造细节。 3. **提取结构化信息** - 梳理出： - 核心模块/组件及其职责 - 关键对外接口（函数、类、API 路由、配置项） - 主要数据结构与重要字段含义 - 关键流程（初始化、请求处理、任务执行等） - 对于改动相关文档，识别： - 新增/修改/删除了什么能力 - 兼容性影响和潜在风险 - 对使用方式的变化（如配置项变更、API 形参变更） 4. **按目标类型组织文档结构** - 使用下面各章节的模板和结构规范组织内容。 - 所有标题、列表及代码示例统一采用 Markdown 格式，便于直接保存到项目中。 5. **审查与压缩** - 优先保证： - 正确性 > 覆盖面 > 文艺性 - 删除明显冗余、重复表述，避免将实现细节无脑拷贝到文档中。 - 对关键约束、注意事项、Breaking Changes 使用加粗或小节单独强调。 --- ## API / 接口文档生成 ### 目标 为函数、类、模块、HTTP API 或公共导出接口生成**清晰、可快速查阅**的说明文档。 ### 步骤 1. **定位公共接口** - 优先关注： - 导出的函数与类 - 对外暴露的模块入口 - HTTP 接口路由、RPC 方法、事件名称 - 忽略明显的内部辅助工具，除非它们被广泛复用并需要单独说明。 2. **为每个接口提取关键信息** - 功能概述：一句话说明接口做什么、解决什么问题。 - 输入： - 参数名、类型、是否必填 - 关键取值范围或约束 - 输出： - 返回值类型与含义 - 可能抛出的异常或错误码 - 侧重点： - 幂等性、性能特性 - 与其他接口的依赖关系（如必须先调用哪个接口） 3. **生成标准化 API 文档块** 对每个接口，使用如下模板输出（中文）： ### 接口：`<接口名>` **功能**：简要说明接口的用途和场景。 **参数** - `name` (`string`，必填)：说明参数含义及约束。 - `age` (`number`，可选，默认 18)：说明默认值和范围。 **返回值** - `User`：返回的对象或结果结构说明。 **可能的错误** - `InvalidArgument`：当 `age` 小于 0 时抛出。 - `NotFound`：指定用户不存在时返回。 **使用示例** // 示例代码（如能从项目中提取则优先复用） ```
如果觉得文档不够详细，还可以让AI继续完善文档:
--- name: auto-doc-generator description: 自动从代码和项目结构生成 API 文档、README 与架构设计说明，并帮助撰写与改动相关的提交/PR 文档。用于用户显式请求文档生成，或在编写提交说明、PR 描述时需要自动补全文档的场景。 --- # 自动文档生成器 ## 快速上手 1. 确认用户要生成的文档类型（API 文档 / README / 架构文档 / 提交说明等），以及主要读者（使用者、开发者、Reviewer）。 2. 使用 `Read` / `Grep` / `SemanticSearch` / Git 相关工具，收集与该文档最相关的代码文件、现有文档和变更记录。 3. 按本 Skill 后续各小节的模板组织内容，默认用中文输出，必要时在关键段落补充英文或双语说明。 **默认输出语言：中文。** 如用户明确要求英文或双语，再切换对应语言或补充英文版本。 --- ## 使用场景 在以下场景优先使用本 Skill： 1. 用户要求生成或完善文档： - API 文档、接口说明、模块说明 - README、使用说明、快速开始 - 架构/设计文档（模块关系、数据流、调用流程） 2. 用户在写提交信息或 PR 描述时，希望自动生成： - 变更摘要 - 影响范围与风险 - 需要更新/新增的文档片段 3. 用户对“这段代码/这个模块”的用途感到困惑，希望产出说明性文档，而不仅是解释。 --- ## 通用工作流程 1. **识别文档类型与读者** - 明确当前要生成的是： - API 文档 / 接口说明 - README / 使用文档 - 架构/设计文档 - 提交信息 / PR 描述 / 变更说明 - 判断目标读者：普通使用者、项目开发者、Reviewer，选择合适的技术深度与术语。 2. **收集上下文** - 使用 `Read` / `Grep` / `SemanticSearch` 等工具，优先从以下来源提取信息： - 相关代码文件及其注释（尤其是公共接口、导出符号） - 现有的 README、架构文档、设计说明 - Git diff / 提交记录（用于生成变更说明与 PR 描述） - 如信息不足且存在多种合理解释，**先在文档中标记假设**，而不是编造细节。 3. **提取结构化信息** - 梳理出： - 核心模块/组件及其职责 - 关键对外接口（函数、类、API 路由、配置项） - 主要数据结构与重要字段含义 - 关键流程（初始化、请求处理、任务执行等） - 对于改动相关文档，识别： - 新增/修改/删除了什么能力 - 兼容性影响和潜在风险 - 对使用方式的变化（如配置项变更、API 形参变更） 4. **按目标类型组织文档结构** - 使用下面各章节的模板和结构规范组织内容。 - 所有标题、列表及代码示例统一采用 Markdown 格式，便于直接保存到项目中。 5. **审查与压缩** - 优先保证： - 正确性 > 覆盖面 > 文艺性 - 删除明显冗余、重复表述，避免将实现细节无脑拷贝到文档中。 - 对关键约束、注意事项、Breaking Changes 使用加粗或小节单独强调。 --- ## API / 接口文档生成 ### 目标 为函数、类、模块、HTTP API 或公共导出接口生成**清晰、可快速查阅**的说明文档。 ### 步骤 1. **定位公共接口** - 优先关注： - 导出的函数与类 - 对外暴露的模块入口 - HTTP 接口路由、RPC 方法、事件名称 - 忽略明显的内部辅助工具，除非它们被广泛复用并需要单独说明。 2. **为每个接口提取关键信息** - 功能概述：一句话说明接口做什么、解决什么问题。 - 输入： - 参数名、类型、是否必填 - 关键取值范围或约束 - 输出： - 返回值类型与含义 - 可能抛出的异常或错误码 - 侧重点： - 幂等性、性能特性 - 与其他接口的依赖关系（如必须先调用哪个接口） 3. **生成标准化 API 文档块** 对每个接口，使用如下模板输出（中文）： ```markdown ### 接口：`<接口名>` **功能**：简要说明接口的用途和场景。 **参数** - `name` (`string`，必填)：说明参数含义及约束。 - `age` (`number`，可选，默认 18)：说明默认值和范围。 **返回值** - `User`：返回的对象或结果结构说明。 **可能的错误** - `InvalidArgument`：当 `age` 小于 0 时抛出。 - `NotFound`：指定用户不存在时返回。 **使用示例** ```ts // 示例代码（如能从项目中提取则优先复用） ``` ``` --- ## README / 使用文档生成 ### 目标 为项目或子模块生成**面向用户/使用者**的入口文档，帮助快速上手。 ### 建议结构 生成 README 时，优先按如下结构组织内容（可根据项目实际裁剪）： ```markdown # 项目名称 ## 简介 用 1–3 句话说明项目做什么、适用场景和核心价值。 ## 特性 - 特性 1：一句话描述 - 特性 2：一句话描述 ## 安装 - 依赖环境（Node/Java/Python 版本等） - 安装步骤（命令行示例） ## 快速开始 1. 步骤 1：… 2. 步骤 2：… 3. 步骤 3：… ## 使用示例 - 基本用法代码示例 - 常见配置示例 ## 配置说明 - 关键配置项列表及含义 - 默认值与建议值 ## 常见问题 - 问：… - 答：… ## 许可证 简要说明 License。 ``` 在生成内容时： - 尽量从代码与现有脚本中提取**真实命令**与配置示例。 - 避免描述实现细节，聚焦“如何用”和“需要注意什么”。 --- ## 架构 / 设计文档生成 ### 目标 帮助读者理解系统结构、模块边界、数据流与关键设计决策。 ### 步骤 1. **识别模块与层次** - 根据目录结构、命名和依赖关系，梳理： - 核心模块/子系统 - 每个模块的职责与输入/输出 - 简要说明模块间的依赖方向和调用关系。 2. **梳理关键流程** - 关注典型场景： - 启动/初始化流程 - 请求处理链路（从入口到持久化/响应） - 任务/定时任务执行流程 - 用列表或时序描述“谁调用谁”、“数据如何流转”。 3. **输出架构文档结构** 推荐结构： ```markdown # 架构设计 ## 总体概览 用一段话说明系统整体结构和设计目标。 ## 模块划分 ### 模块 A - 职责：… - 依赖：依赖哪些模块或外部系统 - 对外暴露：主要接口或事件 ### 模块 B - … ## 关键流程 ### 流程 1：<场景名称> 1. 客户端发起 … 2. 网关/入口模块 … 3. 业务模块 … 4. 持久化/缓存层 … ## 数据模型 - 重要实体及字段说明 - 关键约束（唯一性、索引、外键/关联关系） ## 关键设计决策 - 选型原因（如使用某个中间件/框架的理由） - 为扩展性、性能、可靠性做的权衡 ``` --- ## 提交信息 / PR 描述 / 变更文档 ### 目标 基于代码变更，自动生成**结构化的变更说明**，方便 Reviewer 与后续追溯。 ### 步骤 1. **分析变更** - 查看本次改动涉及的： - 模块/文件列表 - 新增/删除/修改的主要功能 - 对外接口是否发生变化（参数、返回值、行为） - 识别是否存在： - Breaking Changes - 数据迁移/配置变更 2. **生成结构化说明** 推荐 PR 描述/变更文档模板： ```markdown ## 变更摘要 - 简要列出 2–5 条本次改动的核心点。 ## 详细说明 - 功能 1：做了什么、为什么需要 - 功能 2：… ## 兼容性 / 风险 - 是否有不兼容变更？ - 潜在风险点（性能、稳定性等） ## 测试情况 - [ ] 单元测试 - [ ] 集成测试 - [ ] 手动验证：简单说明场景 ## 文档更新 - 本次是否已更新 README/API 文档/架构文档？ - 如未更新且有必要，应在此提醒。 ``` --- ## 风格与注意事项 - **语言**：默认使用简体中文，如用户要求英文或双语则在同一结构下补充英文版。 - **真实性优先**：所有示例代码、命令和配置尽量来源于真实项目；如需假设，需在文档中明确标注。 - **适度抽象**：文档描述应高于代码实现细节一层，避免逐行翻译代码。 - **可维护性**：优先生成易于后续增删修改的结构化文档（标题 + 列表 + 小节），而非长篇大段散文。 --- ## 示例对话 - **示例 1：生成 API 文档** - 用户：帮我为这个模块生成接口文档。 - 行为：分析导出函数/类，按“API / 接口文档生成”的模板生成说明。 - **示例 2：生成 PR 描述** - 用户：根据现在的改动，帮我写一个详细的 PR 描述。 - 行为：对比当前变更，提取核心改动点，按“提交信息 / PR 描述 / 变更文档”的模板输出。 - **示例 3：完善 README** - 用户：这个子模块缺 README，帮我写一个。 - 行为：根据模块代码和现有脚本，生成包含简介、安装、快速开始和使用示例的 README 结构。
对比codebuddy
目前codebuddy的功能几乎可以和cursor完全对应，配置mcp和skill也一样(可以直接复制过来用)，自测生成文档和代码效果也差不多，使用习惯和快捷方式都类似，而且所有功能都是免费的
另外一个就是cline插件+mcp，也和cursor类似
更多推荐
22
0- 0
已为社区贡献3条内容
所有评论(0)