AI 编程
Cursor 编程提示词：写规格，不要许愿
一套规格驱动的方法，让 Cursor 等 AI 编程助手生成更安全、更容易审查的代码改动。
2026-06-23 · 7 分钟阅读 · PromptSmith
为什么一句话编程需求容易跑偏
“加一个登录功能”对熟悉仓库的人似乎很清楚，但 AI 助手仍要猜框架、身份提供商、会话模型、存储层、受保护路由、失败行为和迁移约束。
每一次猜测都会增加“看起来合理、实际不兼容”的概率。好的编程提示词应像一份小型 Issue 规格：明确改动边界，也明确验收改动所需的证据。
先描述仓库，再描述任务
先给出限制实现方式的事实：语言与框架版本、包管理器、相关目录、持久化层，以及必须复用的现有模式。
- 运行时和框架版本。
- 本次改动涉及的文件或模块。
- 应复用的工具、API 和代码规范。
- 禁止修改的文件、依赖和公共接口。
仓库上下文
这是一个使用 TypeScript、Upstash Redis 和服务端签名会话的 Next.js App Router 项目。鉴权工具位于 lib/auth.ts。不要引入 ORM、第二套存储或新的鉴权框架。
用验收标准定义行为
实现指令告诉助手要写什么；验收标准告诉它最终必须满足什么。优先描述可观察行为：响应状态、UI 状态、持久化结果、无障碍行为和测试结果。
- 正常路径的 given/when/then 行为。
- 预期的校验与错误状态。
- 权限规则与数据归属。
- 性能、无障碍或兼容性约束。
- 必须通过的测试和命令。
要求先检查，再编辑
在成熟代码库中，助手选择实现前应先查看相邻文件。要求它识别当前模式、说明假设，并在某个决定会实质改变架构时先提问。
这样能减少一种常见失败：新代码局部看起来没问题，却重复了已有抽象或违反仓库规则。
安全执行指令
编辑前先检查现有会话创建逻辑、API 错误工具和账号页。复用既有模式，保留无关的工作区改动。实现后运行相关单元测试、lint 和生产构建；无法执行的检查要明确说明。
让改动易于审查
要求“最小且完整的改动”，而不是“最少代码行”。完整改动可能包含代码、测试、文档和迁移处理，但不应顺手做无关清理。
高风险工作可以拆成检查、计划、实现和验证四阶段。涉及迁移、替换依赖、权限变化或破坏性命令时，应先审查计划。
- 明确列出不在本次范围内的工作。
- 需要时要求向后兼容。
- 要求测试在修复前失败、修复后通过。
- 交付时简要列出改动文件和剩余风险。