提示模式备忘

把提示当成「给同事的 brief」：背景 + 约束 + 输入 + 期望输出。比在聊天里零碎追问更省 token，也更少跑偏。整体编码协作节奏见 编码协作工作流。

一条合格提示通常包含什么

1. 角色与目标（可选）：例如「你是熟悉 Vue 3 + TypeScript 的前端」——只在栈生疏或约束多时写。
2. 背景：要解决的用户问题或要修的现象；涉及哪个模块/路由/接口。
3. 硬约束：不能改的 API、禁止新依赖、必须兼容的环境、代码风格指令。
4. 你提供的材料：相关文件片段、@ 引用路径、日志、接口契约、复现步骤。
5. 期望输出格式：分步骤说明、只要 diff、只要函数签名、只要伪代码等。

约束怎么写才管用

• 具体：「遵循本项目 ESLint」优于「写干净点」；「不要改 public API」优于「小心点」。
• 边界：列出明确不做的需求（out of scope），减少 AI 自作主张加功能。
• 栈与版本：例如 Node 22、VuePress 2、包管理用 pnpm——避免过时代码建议。

上下文：贴什么最有效

• 错误排查：完整报错栈、失败命令、相关文件路径；能复现的最小步骤。
• 改逻辑：当前行为 vs 期望行为；若有测试，贴失败用例输出。
• 读代码：说明你已经看过的入口文件，避免 AI 从头猜项目结构。

在 Cursor 等 IDE 里，用 @ 精确带上文件/符号，比整仓粘贴更稳。

输出格式：减少来回改

按需选用一种，并在提示里写死：

• Plan：只列 numbered steps，不改代码。
• Patch 心态：「只改列出的文件，其它不要动」。
• 讲解：「用中文解释这段代码在干什么，不修改源码」。
• 接口先行：「先给 TypeScript 类型与函数签名，再实现」。

若输出太长，要求对方 先给目录/文件清单，再分文件展开。

可复制骨架示例

下列把括号内容换成你的实际情况即可。

实现小功能

目标：（用户能……）
约束：（技术栈 / 不引新依赖 / 需兼容……）
相关代码：（@路径 或 粘贴关键片段）
验收：（1. … 2. …）
请先给出改动计划（步骤 + 将修改的文件名），确认后再生成补丁。

修 Bug

现象：（期望 vs 实际）
复现：（步骤或最小仓库说明）
环境：（OS / Node / 分支）
日志：（粘贴完整报错）
请先分析可能原因（列假设），再给出最小修复；不要改动无关文件。

读代码 / 审查

我关注的点：（性能 / 安全 / 与某需求是否匹配）
范围：（@文件 或 目录）
请指出风险点与设计取舍，不要直接改写；若建议修改，分条说明理由。

与 Cursor 模式搭配

何时用 Ask、Plan、Agent、Debug，以及权限差异，见 Cursor 使用完全指南。一般说来：要方案用 Plan，要解释用 Ask，要批量改再用 Agent，有栈和日志先走 Debug。