AI编程05-提示词优化技巧：从弱提示到强提示，让AI生成代码质量提升300%

你写的提示词是不是经常让AI"自由发挥"到离谱？一个模糊的"帮我写个登录功能"，AI可能给你返回一个漏洞百出的玩具代码。但当你掌握提示词工程的核心技巧后，同样的AI，代码质量能提升300%以上。本文将系统性地拆解从弱提示到强提示的进化路径，给你一套可直接落地的最佳实践。

一、弱提示 vs 强提示：差距比你想象的大

1.1 什么是弱提示？

弱提示就像你跟一个实习生说："去把那个东西处理一下。"没有上下文、没有标准、没有约束，结果完全看运气。

弱提示示例：

帮我写一个用户登录功能

AI返回（弱提示结果）：

// 弱提示生成的代码 - 问题重重 function login(username, password) { if (username === "admin" && password === "123456") { return "登录成功"; } return "登录失败"; }

问题分析：

• • ❌ 明文存储密码，安全隐患巨大
• • ❌ 没有输入验证，SQL注入风险
• • ❌ 没有错误处理，用户体验差
• • ❌ 没有日志记录，无法审计
• • ❌ 硬编码凭据，维护困难

1.2 什么是强提示？

强提示则像一份完整的PRD（产品需求文档）：角色明确、背景清晰、任务具体、约束严格、示例到位。

强提示示例：

【角色】你是一位有10年经验的后端安全工程师，精通Node.js和身份认证系统设计。 【背景】我们正在开发一个企业级SaaS平台，需要实现安全的用户登录API。 【任务】编写一个符合OWASP安全标准的用户登录接口，要求： 1. 使用bcrypt进行密码哈希验证 2. 实现速率限制防止暴力破解 3. 返回JWT token用于后续认证 4. 记录安全审计日志 【约束】 - 使用Express.js框架 - 必须处理SQL注入、XSS等常见攻击 - 错误信息不能暴露敏感信息 - 代码需包含完整的JSDoc注释 【示例】输入验证应该像这样： const { body, validationResult } = require('express-validator');

AI返回（强提示结果）：

/** * 用户登录接口 - 符合OWASP安全标准 * @param {Object} req - Express请求对象 * @param {Object} res - Express响应对象 * @returns {Promise<void>} */ const login = async (req, res) => { try { // 输入验证 const errors = validationResult(req); if (!errors.isEmpty()) { return res.status(400).json({ error: '输入参数不合法', code: 'INVALID_INPUT' }); } const { username, password } = req.body; // 查询用户（使用参数化查询防SQL注入） const user = await db.query( 'SELECT id, username, password_hash FROM users WHERE username = ?', [username] ); if (!user || !(await bcrypt.compare(password, user.password_hash))) { // 统一错误信息，防止用户枚举 await auditLog.record('LOGIN_FAILED', { username, ip: req.ip }); return res.status(401).json({ error: '用户名或密码错误', code: 'AUTH_FAILED' }); } // 生成JWT const token = jwt.sign( { userId: user.id, username: user.username }, process.env.JWT_SECRET, { expiresIn: '2h', issuer: 'saas-platform' } ); await auditLog.record('LOGIN_SUCCESS', { userId: user.id, ip: req.ip }); res.json({ success: true, token, expiresIn: 7200 }); } catch (error) { logger.error('Login error:', error); res.status(500).json({ error: '服务器内部错误', code: 'INTERNAL_ERROR' }); } };

1.3 对比总结

二、提示词结构模板：RBTC框架

经过数百次实战，我提炼出一个通用模板——RBTC框架：

┌─────────────────────────────────────────────────────────┐ │ RBTC 提示词框架 │ ├─────────────────────────────────────────────────────────┤ │ R - Role（角色） → 你是谁？ │ │ B - Background（背景） → 在什么场景下？ │ │ T - Task（任务） → 具体要做什么？ │ │ C - Constraint（约束） → 有什么限制条件？ │ │ E - Example（示例） → 给参考样例（可选但强烈推荐） │ └─────────────────────────────────────────────────────────┘

2.1 角色（Role）：定义AI的专业身份

类比：就像去医院看病，你会挂专家号而不是普通号。给AI设定专业角色，能激活其对应的知识领域。

技巧：

• • 具体化：不说"程序员"，说"有5年微服务架构经验的Java工程师"
• • 领域化：加上"精通Spring Cloud、熟悉分布式事务"
• • 场景化：补充"在电商高并发场景下有实战经验"

2.2 背景（Background）：提供上下文信息

类比：就像给下属布置任务，你需要说明项目背景、业务目标、技术栈现状。

关键要素：

• • 项目类型（SaaS/电商/金融/游戏）
• • 技术栈（Vue3 + TypeScript + Vite）
• • 约束条件（需要兼容IE11、性能要求QPS>1000）
• • 已有代码风格（参考项目代码规范）

2.3 任务（Task）：明确具体目标

类比：好的任务描述是SMART原则的——具体、可衡量、可达成、相关、有时限。

技巧：

• • 使用动词开头："编写"、"重构"、"优化"、"解释"
• • 分解步骤：1. 先做X 2. 再做Y 3. 最后Z
• • 明确输出格式："以Markdown表格形式返回"

2.4 约束（Constraint）：设定边界条件

类比：就像建筑设计规范，约束条件决定了代码的质量底线。

常见约束类型：

• • 性能约束：时间复杂度O(n)、内存占用<100MB
• • 安全约束：防SQL注入、XSS过滤、敏感信息脱敏
• • 代码规范：遵循Airbnb ESLint、必须有单元测试
• • 兼容性：支持Node 14+、Chrome 80+

2.5 示例（Example）：用Few-shot引导

类比：就像教小孩认字，给一个"苹果"的例子，他就能认出"香蕉"。

Few-shot设计原则：

• • 输入-输出对要完整
• • 覆盖边界情况
• • 展示期望的代码风格

三、上下文注入技巧：让AI"看懂"你的代码库

3.1 为什么需要上下文注入？

AI没有记忆，每次对话都是独立的。如果你正在维护一个大型项目，需要让AI理解：

• • 项目的目录结构
• • 已有的工具函数
• • 统一的错误处理模式
• • 特定的命名规范

3.2 上下文注入的三种方式

方式一：文件摘要注入

【项目结构】 src/ ├── utils/ │ ├── request.ts # 基于axios的HTTP封装，统一错误处理 │ └── storage.ts # localStorage封装，支持过期时间 ├── components/ │ └── FormModal/ # 统一的表单弹窗组件 └── hooks/ └── useAuth.ts # 权限验证Hook 【相关代码片段】 // request.ts 的核心逻辑： export const request = axios.create({ baseURL: import.meta.env.VITE_API_URL, timeout: 10000 }); request.interceptors.response.use( (res) => res.data, (err) => { if (err.response?.status === 401) { // 统一处理登录过期 window.location.href = '/login'; } return Promise.reject(err); } );

方式二：类型定义注入

【类型定义】 interface User { id: string; username: string; role: 'admin' | 'editor' | 'viewer'; createdAt: Date; } 【API响应格式】 interface ApiResponse<T> { code: number; data: T; message: string; }

方式三：风格指南注入

【代码风格要求】 1. 使用函数式组件 + Hooks 2. 异步操作使用async/await，不用.then() 3. 错误处理使用try-catch，错误信息用message.error()提示 4. 组件props需要定义TypeScript接口

3.3 上下文长度管理

当项目很大时，直接粘贴全部代码会超出token限制。技巧：

• • 只提供相关模块的代码
• • 使用"相关文件摘要"代替全文
• • 让AI先问你需要哪些上下文

四、Few-shot示例设计：用例子教会AI

4.1 Few-shot的威力

研究表明，提供2-3个高质量示例，能让AI的输出质量提升50%以上。

4.2 设计有效示例的要点

示例1：代码重构任务

【任务】将回调式代码重构为async/await 【示例1 - 输入】 getUserData(userId, (err, user) => { if (err) return handleError(err); getOrders(user.id, (err, orders) => { if (err) return handleError(err); console.log(orders); }); }); 【示例1 - 输出】 try { const user = await getUserData(userId); const orders = await getOrders(user.id); console.log(orders); } catch (error) { handleError(error); }

示例2：API设计任务

【示例2 - 输入】 需要设计一个分页查询接口 【示例2 - 输出】 GET /api/users?page=1&size=20&sort=createdAt:desc 响应格式： { "data": [...], "pagination": { "page": 1, "size": 20, "total": 100, "totalPages": 5 } }

4.3 反例：糟糕的Few-shot设计

❌问题示例：

示例1：写一个排序函数 示例2：写一个搜索功能

问题：没有展示输入输出，AI不知道你想要什么风格。

✅改进后：

【示例1】 输入：数组 [3, 1, 4, 1, 5] 输出：排序后的数组 [1, 1, 3, 4, 5] 代码风格：使用快速排序，时间复杂度O(n log n)

五、常见反模式：这些坑别再踩了

反模式1：过度模糊的指令

❌错误："帮我优化这段代码"

✅正确："这段代码在处理10万条数据时性能较差，请优化时间复杂度，目标是从O(n²)降到O(n log n)"

反模式2：缺少约束边界

❌错误："写一个文件上传功能"

✅正确："写一个文件上传功能，要求：支持jpg/png，单文件最大5MB，使用阿里云OSS，前端用React+Ant Design"

反模式3：一次要求太多

❌错误："帮我设计数据库表结构、写后端API、做前端页面，还要写测试用例"

✅正确：分步骤："第一步，设计用户模块的数据库表结构..."

反模式4：不给反馈循环

❌错误：AI输出不对，直接放弃或重新提问

✅正确："这部分很好，但第3行的错误处理需要改进，应该..."

反模式5：忽视安全约束

❌错误：任何涉及用户输入的场景都不提安全要求

✅正确：始终加上："注意防范SQL注入和XSS攻击"

六、实战案例：完整提示词拆解

场景：开发一个带权限控制的文件上传组件

完整提示词：

【角色】你是一位资深前端工程师，精通React、TypeScript和前端安全，有丰富的大型企业级项目经验。 【背景】我们正在开发一个文档管理系统，需要实现一个安全的文件上传组件。项目使用React 18 + Ant Design 5 + TypeScript。 【任务】编写一个FileUploader组件，要求： 1. 支持拖拽上传和点击上传两种方式 2. 显示上传进度和状态 3. 实现文件类型和白名单校验 4. 集成权限控制（只有admin和editor可以上传） 5. 上传前显示文件预览（图片） 【约束】 - 使用Ant Design的Upload组件作为基础 - 文件大小限制：图片≤5MB，文档≤20MB - 支持的格式：jpg/png/pdf/docx - 必须使用TypeScript，定义完整的Props接口 - 错误处理要友好，使用Ant Design的message组件 - 代码需要包含JSDoc注释 【示例】权限检查逻辑参考： const usePermission = () => { const { user } = useAuth(); return { canUpload: user?.role === 'admin' || user?.role === 'editor' }; }; 【输出要求】 1. 完整的组件代码 2. 使用示例 3. 必要的类型定义

AI输出质量评估：

• • ✅ 类型定义完整
• • ✅ 安全校验到位
• • ✅ 错误处理完善
• • ✅ 代码风格统一
• • ✅ 可直接用于生产

七、总结：提示词优化的核心心法

┌────────────────────────────────────────────────────────────┐ │ 提示词优化心法 │ ├────────────────────────────────────────────────────────────┤ │ 1. 具体 > 模糊 → 给明确的指令，不要假设AI懂你 │ │ 2. 约束 > 自由 → 设定边界，AI在框架内发挥 │ │ 3. 示例 > 描述 → 用Few-shot展示期望输出 │ │ 4. 迭代 > 一次性 → 多轮对话逐步优化 │ │ 5. 上下文 > 孤立 → 给足背景，AI才能精准输出 │ └────────────────────────────────────────────────────────────┘

记住：提示词工程不是玄学，而是一门可以通过练习掌握的技能。从今天开始，用RBTC框架重构你的提示词，你会发现AI的代码质量真的有质的飞跃。

【源码获取】

本文所有代码示例已整理到GitHub仓库：
👉 https://github.com/yourname/ai-prompt-engineering

包含：

• • 完整的c提示词模
• • 10+个实战案例
• • 常见场景的提示词库

【思考题】

1. 1. 你现在的提示词习惯是什么？对照RBTC框架，缺少了哪些要素？
2. 2. 找一个你最近让AI写的代码，尝试用强提示重新生成，对比质量差异
3. 3. 设计一个适合你项目的"风格指南"提示词片段，方便复用

【系列文章预告】

《AI编程与Vibecoding》系列持续更新中：

• • ✅ 主题1：AI编程入门：从Copilot到Cursor的进化之路
• • ✅ 主题2：Vibecoding实战：用AI 3天完成MVP开发
• • ✅ 主题3：代码审查自动化：让AI当你的CR助手
• • ✅ 主题4：AI辅助调试：从报错信息到解决方案
• • ✅主题5：提示词优化技巧（本文）
• • 📅 主题6：AI生成代码的安全隐患与防范
• • 📅 主题7：构建个人AI编程工作流
• • 📅 主题8：AI时代的程序员核心竞争力

关注专栏，第一时间获取更新！

💡作者的话：提示词优化是一个持续迭代的过程。不要期望一次就能写出完美的提示词，多尝试、多对比、多总结，你会找到最适合自己的风格。

本文首发于CSDN，转载请注明出处。