高质量 Prompt 模板
高质量 Prompt 模板
在日常开发里，用固定的模板可以快速复制出稳定的结果。下面给出 3 个常用模式，直接套用即可。
任务+背景+约束+输出+验收
[任务] 帮我实现一个登录表单的前端校验逻辑
[背景] 使用 React + TypeScript，已有组件 Form 和 Input，可复用 hooks/useToast
[约束] 不要引入新依赖；失败时返回具体字段的错误信息
[输出] 完整代码块，包含类型定义；附上 2 个输入输出示例
[验收] 代码需通过 ESLint；说明哪些边界情况被覆盖
适用于绝大多数功能开发。关键是把“项目现状”和“验收标准”写清楚。
角色 + 步骤 + 检查表
你是一名代码审查助手，请按以下步骤输出：
1) 阅读 @pages/login.tsx 与 @components/Form.tsx
2) 找出可优化的可访问性问题
3) 输出修复方案的 patch（使用 Markdown 代码块），随后列出检查表
检查表：可键盘操作、字段有 label、错误信息可被屏幕阅读器读取
适合重构/Review/可访问性等需要列表化检查的任务。
Diff/Patch 指令
请生成针对 @components/Button.tsx 的 patch：
- 把 primary 按钮的背景色改为 #0f172a，hover 时加阴影
- 保持 props 不变，避免破坏现有用法
- 输出 unified diff，不要包含无关文件
在已有代码基础上做小改动时，用 patch 能减少误伤和无关变更。
练习
- 任选一个模式，在 Cursor 里对当前项目跑一遍，看看 AI 是否遵守格式。
- 调整“约束”“验收”字段，观察输出变化，积累最适合自己的模板库。
📚 相关资源
❓ 常见问题
关于本章主题最常被搜索的问题，点击展开答案
「任务+背景+约束+输出+验收」5 段式模板适合哪种场景？
适合绝大多数功能开发任务 —— 写新组件、加 form 校验、写 utility、对接 API。关键是把"项目现状"（已有的 Form / Input / hooks）和"验收"（通过 ESLint、覆盖空输入边界）写清楚。这两块缺了，AI 就只能产出泛化代码。模板看似啰嗦，但比"帮我写个登录校验"省 3 轮返工。
「角色 + 步骤 + 检查表」模板特别适合哪类工作？
适合 review、重构、可访问性审查这类需要列表化检查的任务。例：让 AI 当 code reviewer，先读 @pages/login.tsx + @components/Form.tsx，再找可访问性问题，最后输出 patch + 检查表（可键盘操作 / 字段有 label / 错误信息屏幕阅读器可读）。检查表这一段是关键 —— 把验收标准前置，AI 输出会自动对齐。
什么时候应该让 AI 输出 unified diff 而不是完整代码？
已有代码上做小改动时。例：给 @components/Button.tsx 改 primary 配色为 #0f172a + 加 hover 阴影，要求 props 不变。让 AI 出 patch 而不是整个文件，能避免它顺手把无关 import、无关样式、注释都改一遍 —— 那种"全文件改写"经常带来 30+ 行无关 diff，PR 评审最痛。
怎么把好用的 prompt 沉淀成自己的模板库？
三步走：(1) 每次跑出满意结果立刻存到本地文件（prompts/ 目录或 Notion 都行），不要靠记忆；(2) 标注适用场景 —— 这条是给 React 组件用的、那条是 PR review 专用；(3) 用变量占位 ——「[文件名]」「[stack]」「[验收]」之类，下次用直接替换。3 个月后你的模板库就是真正拉开同事差距的资产。
AI 没有按要求的格式（unified diff / 表格 / 检查表）输出怎么办？
直接回一句"重新输出，必须是 unified diff 格式，不要包含无关文件" —— 不要重新解释整个 task。AI 偶尔会忽略格式约束，特别是上下文长的时候。第二次重复格式要求几乎都能拿到合规输出。如果连续 2 次还不行，把格式约束移到 prompt 最末尾（last instruction wins），通常立刻见效。