AI 提示词工程

这页适合作为“和模型稳定协作的写法指南”。提示词工程的重点不是堆花哨技巧，而是让目标、上下文、约束、输出格式和验收标准足够清晰。

先按任务结构写

大多数高质量提示词，通常都可以拆成这几块：

1. 任务目标
2. 背景上下文
3. 约束条件
4. 输出格式
5. 验收标准

如果任务复杂，再补示例、边界情况和失败时的处理方式。

基础原则

• 明确具体：说清楚你要什么，不要模糊
• 提供上下文：背景信息越多，回答越准确
• 指定格式：告诉 AI 用什么格式输出
• 分步骤：复杂任务拆成小步骤

常用技巧

角色设定

你是一位资深的 TypeScript 开发者，擅长 Nuxt 3 和 Vue 3。
请帮我审查以下代码，指出潜在问题和优化建议。

思维链（Chain of Thought）

请一步一步分析这个问题：
1. 首先理解需求
2. 分析可能的方案
3. 比较各方案优缺点
4. 给出推荐方案和理由

Few-shot 示例

将以下中文翻译为自然的英文：

输入：这个功能还在开发中
输出：This feature is still under development.

输入：请稍后再试
输出：Please try again later.

输入：操作成功
输出：

输出格式控制

请用以下 JSON 格式返回结果：
{
  "summary": "一句话总结",
  "pros": ["优点1", "优点2"],
  "cons": ["缺点1", "缺点2"],
  "recommendation": "推荐方案"
}

编程场景模板

代码审查

请审查以下代码，关注：
- 潜在的 bug 和边界情况
- 性能问题
- 安全隐患
- 代码可读性
- TypeScript 类型安全

[粘贴代码]

重构建议

请重构以下代码，目标：
- 提高可读性
- 减少重复
- 遵循 SOLID 原则
- 保持功能不变

请解释每处修改的原因。

[粘贴代码]

错误排查

我遇到了以下错误：
[错误信息]

环境：
- Node.js 22
- Nuxt 4
- TypeScript 5.7

相关代码：
[粘贴代码]

请分析可能的原因并提供解决方案。

技术方案设计

需求：[描述需求]

技术栈：Nuxt 4 + TypeScript + Cloudflare Workers

请设计技术方案，包括：
1. 整体架构
2. 数据模型
3. API 设计
4. 关键实现细节
5. 需要注意的坑

高级技巧

自我反思

请回答后，检查你的回答是否有以下问题：
- 是否有事实错误
- 代码是否能直接运行
- 是否遗漏了边界情况
如果有，请修正。

约束条件

要求：
- 不使用任何第三方库
- 代码不超过 50 行
- 兼容 ES2022
- 包含错误处理

迭代优化

基于上面的方案，请进一步优化：
- 减少 API 调用次数
- 添加缓存策略
- 处理并发场景

推荐写法

• 先说清楚“你要它做什么”
• 再说清楚“它基于什么背景来做”
• 再限定“不能做什么、必须输出什么”
• 如果任务有模板，就直接给模板

很多效果差的提示词，不是模型不够强，而是任务定义不完整。

常用 AI 工具

系统提示词设计

为 AI 编程助手编写高质量的系统提示词：

结构化系统提示词

# 角色
你是一位资深全栈开发者，专注于 TypeScript 和 Vue 生态。

# 技术栈
- Nuxt 4 + Vue 3.5 Composition API
- TypeScript 5 strict 模式
- UnoCSS（非 Tailwind）
- Cloudflare Workers 部署

# 规范
- 使用 <script setup lang="ts">
- 中文注释，英文变量名
- Conventional Commits 提交格式
- 优先使用 VueUse 组合式函数

# 输出要求
- 直接给代码，少说废话
- 指出潜在问题和边界情况
- 如果有多种方案，简要对比后推荐一种

项目上下文模板

# 项目：DomiVault
一个基于 Nuxt 4 的个人知识库网站。

## 目录结构
- content/docs/ — Markdown 文章
- app/components/ — Vue 组件
- app/pages/ — 页面路由
- app/composables/ — 组合式函数

## 关键依赖
- @nuxt/content v3 — 内容管理
- @unocss/nuxt — 原子化 CSS
- @vueuse/nuxt — 工具函数

## 部署
Cloudflare Pages，使用 bun 构建

模型特性与适配

不同模型有不同的优势，提示词应适配：

常见问题

为什么提示词写很长，结果还是不好

常见原因通常包括：

• 目标不清楚
• 背景信息太杂，没有主次
• 没给输出格式
• 没说明评价标准

Few-shot 一定比零样本好吗

不一定。只有当你真的有高质量示例，而且希望模型模仿特定风格或结构时，Few-shot 才明显更有帮助。

让模型“一步一步思考”就一定更准吗

不一定。它更适合复杂推理和结构化分析，但并不能代替事实校验、代码运行和业务验证。

风险提醒

• 不要把敏感数据随手塞进第三方模型
• 不要把模型输出当成最终事实来源
• 涉及代码、部署、财务、法务等内容时，最好补人工复核

延伸阅读

• AI API 接入指南
• AI 编码规则
• AI IDE 与编辑器

参考链接

• Prompt Engineering Guide — 提示词指南
• OpenAI Best Practices — 官方建议
• Anthropic Prompt Library — Claude 提示词库
• AI 编程助手规则配置 — Cursor/Kiro/Copilot 规则