游乐游手机版
首页/AI教程/文章详情

请提供原始文章标题,以便进行SEO优化重写。

时间:2026-05-28 21:34
为什么结构化Prompt有时依然难以获得理想效果?先说结论:上一篇文章中,我们探讨了结构化Prompt的四大核心要素,能够生成专业级别的Vue3组件。然而在实际开发场景里,真正令人困扰的往往是那些更为复杂的业务逻辑——例如权限控制、状态机转换、复杂表单验证……此时,仅仅告诉AI“做什么”显然不足,你

为什么结构化Prompt有时依然难以获得理想效果?

先说结论:上一篇文章中,我们探讨了结构化Prompt的四大核心要素,能够生成专业级别的Vue3组件。然而在实际开发场景里,真正令人困扰的往往是那些更为复杂的业务逻辑——例如权限控制、状态机转换、复杂表单验证……此时,仅仅告诉AI“做什么”显然不足,你还必须引导它“怎么做”。

Prompt工程进阶:少样本与思维链

在本篇文章中,我们将从一个动态权限菜单的实战案例入手,系统掌握两大硬核Prompt技巧:少样本提示与思维链。

  • 少样本提示(Few-shot Prompting):通过给出若干示例,让AI学会模仿与泛化。
  • 思维链(Chain of Thought):引导AI将推理过程清晰展示,专治复杂逻辑难题。

少样本提示:为AI提供“模仿样本”

什么是少样本提示?

核心理念非常直观:借助输入输出的实例,让AI领悟任务的模式与规律。就像教孩子解题,先示范几道例题,再让他们独立完成练习,原理完全一致。

适用场景

  • 需要特定输出格式的任务
  • 存在明确模式匹配逻辑的场景
  • 希望AI模仿特定风格或规范

思维链:让AI“展示解题思路”

什么是思维链?

思维链的核心思路更加直接:引导AI呈现中间推理步骤,而非直接给出最终答案。这好比数学老师要求学生写出完整推导过程,而不是仅仅提交一个结果。

适用场景

  • 多步骤推理任务
  • 条件判断高度复杂的逻辑
  • 需要解释决策依据的场景
  • 数学计算、算法设计等领域

实战案例:动态权限菜单的Prompt演进历程

需求描述

需求非常清晰:依据用户权限动态展示菜单,至少支持3种角色:

  • admin:可查看全部菜单
  • editor:仅看到内容管理相关菜单
  • visitor:只能访问仪表盘与公开页面

版本1:直接提问(开放式)

我的Prompt

帮我写一个根据权限显示菜单的逻辑

AI输出

function getMenus(role) { if (role === 'admin') { return ['仪表盘', '用户管理', '内容管理', '设置'] } else { return ['仪表盘'] } }

问题分析

  • 仅区分了admin与非admin,缺乏精细度。
  • 未考虑多角色场景。
  • 逻辑过于简单,无法满足真实业务需求。
  • 没有处理嵌套菜单等复杂结构。

版本2:少样本提示(让AI学会模式)

我的Prompt

我需要一个根据用户权限动态显示菜单的函数。请参考以下输入输出示例,生成类似的权限判断逻辑:示例1:输入:用户角色 = "admin" 输出:["仪表盘", "用户管理", "内容管理", "系统设置"] 示例2:输入:用户角色 = "editor" 输出:["仪表盘", "内容管理", "文章审核"] 示例3:输入:用户角色 = "visitor" 输出:["仪表盘", "公开文档"] 请根据以上模式,生成一个支持更多角色的权限菜单函数,并确保覆盖至少3种角色。

AI输出

/** * 根据用户角色获取可见菜单 * @param {string} role - 用户角色 * @returns {string[]} 菜单数组 */ function getMenusByRole(role) { // 权限菜单映射表 const roleMenus = { admin: ['仪表盘', '用户管理', '内容管理', '系统设置', '日志审计', '权限配置'], editor: ['仪表盘', '内容管理', '文章审核', '分类管理', '标签管理'], visitor: ['仪表盘', '公开文档', '帮助中心'], analyst: ['仪表盘', '数据报表', '用户分析', '流量统计'], maintainer: ['仪表盘', '系统监控', '性能优化', '错误日志'] } // 返回对应角色的菜单,如果角色不存在则返回空数组 return roleMenus[role] || [] } // 测试 console.log('admin:', getMenusByRole('admin')) console.log('editor:', getMenusByRole('editor')) console.log('visitor:', getMenusByRole('visitor')) console.log('analyst:', getMenusByRole('analyst'))

进步

  • 通过示例使AI理解了输入输出的映射关系。
  • 自动扩展至5种角色,覆盖面更广。
  • 代码结构清晰,便于后期维护。

不足

  • 菜单采用硬编码扁平数组,无法支持嵌套结构。
  • 未考虑权限组合场景(例如用户同时拥有多个角色)。
  • 缺乏对菜单项权限的细粒度控制。

版本3:思维链(让AI展示推理过程)

我的Prompt

我需要一个复杂的动态权限菜单系统,支持嵌套菜单和细粒度权限控制。请先列出你的思考步骤,然后生成代码。需求:1. 菜单可以有多级嵌套 2. 每个菜单项可以单独配置所需权限 3. 支持用户拥有多个角色 4. 需要根据用户的所有角色计算最终可见菜单 请按照以下步骤思考:第一步:分析如何设计菜单数据结构 第二步:考虑多角色权限的合并策略(并集?交集?) 第三步:设计递归遍历菜单树的函数 第四步:处理边界情况(空权限、角色不存在等) 第五步:生成最终的TypeScript代码

AI输出

第一步思考:菜单数据结构设计

我需要设计一个支持嵌套的菜单结构,每个菜单项包含:- name: 显示名称 - path: 路由路径 - icon: 图标 - children: 子菜单 - permissions: 所需权限数组(满足任一即可)

第二步思考:多角色权限合并策略

用户可能有多个角色,如 ['admin', 'editor'] 策略:取所有角色权限的并集 原因:用户拥有多个角色时,应该拥有所有角色的权限总和

第三步思考:递归遍历算法

需要深度遍历菜单树 对每个菜单项检查权限 如果某个菜单项没有权限且没有可见的子菜单,则隐藏

第四步思考:边界情况处理

- 权限配置为空:表示公开菜单,所有人可见 - 角色不存在:视为无权限 - 空菜单树:返回空数组

最终代码输出

/** * 动态权限菜单系统 * 支持多级嵌套、多角色、细粒度权限控制 */ // ==================== 类型定义 ==================== /** 菜单项接口 */ interface MenuItem { /** 菜单名称 */ name: string; /** 路由路径 */ path: string; /** 图标名称(可选) */ icon?: string; /** 子菜单 */ children?: MenuItem[]; /** 所需权限列表(满足任一即可),为空表示公开 */ permissions?: string[]; } /** 用户角色接口 */ interface UserRole { /** 角色ID */ id: string; /** 角色名称 */ name: string; /** 角色拥有的权限列表 */ permissions: string[]; } /** 用户信息接口 */ interface User { /** 用户ID */ id: string; /** 用户名 */ name: string; /** 用户拥有的角色ID列表 */ roleIds: string[]; } // ==================== 权限计算函数 ==================== /** * 第一步:获取用户的所有权限(多角色并集) * @param user 用户信息 * @param roles 所有角色的定义 * @returns 用户拥有的所有权限数组(去重) */ function getUserPermissions(user: User, roles: Map): string[] { // 边界情况:用户没有角色 if (!user.roleIds || user.roleIds.length === 0) { return []; } // 收集用户所有角色的权限 const permissionsSet = new Set(); user.roleIds.forEach(roleId => { const role = roles.get(roleId); if (role && role.permissions) { role.permissions.forEach(perm => permissionsSet.add(perm)); } }); return Array.from(permissionsSet); } /** * 第二步:检查菜单项对当前用户是否可见 * @param menuItem 菜单项 * @param userPermissions 用户权限列表 * @returns 是否可见 */ function isMenuItemVisible(menuItem: MenuItem, userPermissions: string[]): boolean { // 情况1:没有权限要求 -> 公开菜单,所有人都可见 if (!menuItem.permissions || menuItem.permissions.length === 0) { return true; } // 情况2:有权限要求 -> 检查用户是否拥有任一所需权限 return menuItem.permissions.some(perm => userPermissions.includes(perm)); } /** * 第三步:递归过滤菜单树 * @param menus 原始菜单树 * @param userPermissions 用户权限列表 * @returns 过滤后的可见菜单树 */ function filterMenusByPermissions(menus: MenuItem[], userPermissions: string[]): MenuItem[] { // 边界情况:空菜单 if (!menus || menus.length === 0) { return []; } const result: MenuItem[] = []; for (const menu of menus) { // 先检查当前菜单项是否可见 const visible = isMenuItemVisible(menu, userPermissions); // 如果有子菜单,递归处理子菜单 let filteredChildren: MenuItem[] | undefined; if (menu.children && menu.children.length > 0) { filteredChildren = filterMenusByPermissions(menu.children, userPermissions); } // 判断当前菜单项是否应该保留: // 1. 菜单本身可见 // 2. 或者有可见的子菜单(即使自身不可见,但子菜单可见时,应该保留作为父级导航) const hasVisibleChildren = filteredChildren && filteredChildren.length > 0; if (visible || hasVisibleChildren) { // 创建新的菜单项(避免修改原始数据) const filteredMenu: MenuItem = { name: menu.name, path: menu.path, icon: menu.icon }; // 如果有可见的子菜单,添加到结果中 if (hasVisibleChildren) { filteredMenu.children = filteredChildren; } result.push(filteredMenu); } } return result; } /** * 第四步:主函数 - 获取用户的可见菜单 * @param user 用户信息 * @param allMenus 完整的菜单树 * @param allRoles 所有角色的定义 * @returns 该用户可见的菜单树 */ function getUserMenus(user: User, allMenus: MenuItem[], allRoles: Map): MenuItem[] { // 边界情况处理 if (!user || !allMenus || !allRoles) { console.warn('参数不完整,返回空菜单'); return []; } // 第一步:获取用户的所有权限 const userPermissions = getUserPermissions(user, allRoles); // 第二步:根据权限过滤菜单 const visibleMenus = filterMenusByPermissions(allMenus, userPermissions); return visibleMenus; } // ==================== 使用示例 ==================== // 定义所有角色 const roles = new Map([ ['admin', { id: 'admin', name: '管理员', permissions: ['user:view', 'user:edit', 'content:view', 'content:edit', 'system:config'] }], ['editor', { id: 'editor', name: '编辑', permissions: ['content:view', 'content:edit', 'content:audit'] }], ['visitor', { id: 'visitor', name: '访客', permissions: ['public:view'] }] ]); // 定义完整的菜单树 const allMenus: MenuItem[] = [ { name: '仪表盘', path: '/dashboard', icon: 'dashboard', permissions: [] // 公开菜单 }, { name: '用户管理', path: '/users', icon: 'user', permissions: ['user:view'], children: [ { name: '用户列表', path: '/users/list', permissions: ['user:view'] }, { name: '新增用户', path: '/users/add', permissions: ['user:edit'] }, { name: '权限配置', path: '/users/permissions', permissions: ['system:config'] } ] }, { name: '内容管理', path: '/content', icon: 'document', permissions: ['content:view'], children: [ { name: '文章列表', path: '/content/articles', permissions: ['content:view'] }, { name: '发布文章', path: '/content/publish', permissions: ['content:edit'] }, { name: '文章审核', path: '/content/audit', permissions: ['content:audit'] } ] }, { name: '系统设置', path: '/settings', icon: 'setting', permissions: ['system:config'], children: [ { name: '基本设置', path: '/settings/basic', permissions: ['system:config'] }, { name: '安全设置', path: '/settings/security', permissions: ['system:config'] } ] } ]; // 测试不同角色的用户 const testUsers: User[] = [ { id: '1', name: '管理员', roleIds: ['admin'] }, { id: '2', name: '编辑', roleIds: ['editor'] }, { id: '3', name: '访客', roleIds: ['visitor'] }, { id: '4', name: '编辑兼访客', roleIds: ['editor', 'visitor'] // 多角色 } ]; // 执行测试 testUsers.forEach(user => { console.log(`\n========== ${user.name} 的可见菜单 ==========`); const visibleMenus = getUserMenus(user, allMenus, roles); console.log(JSON.stringify(visibleMenus, null, 2)); });

少样本 vs 思维链:对比与选型指南

通过上述实战案例,我们可以清晰看出两种提示技术的适用场景差异。下面整理了一张对比表格,方便大家快速参考:

场景类型 典型示例 适用原因
少样本提示
格式转换 JSON转XML,Markdown转HTML 示例能直观展示映射关系
模式识别 根据若干例子总结规律 AI能迅速捕捉共同模式
风格模仿 模仿特定代码风格 示例提供了风格参考
简单分类 将文本划分到不同类别 示例明确了分类标准
思维链
复杂推理 权限判断的多步骤逻辑 需要逐步分析条件
算法设计 递归遍历菜单树 需要展示算法思路
数学计算 复杂公式推导 需要展示计算过程
决策解释 为何某个菜单项被隐藏 需要说明判断依据
边界处理 空权限、多角色等特殊情况 需要全面考虑各类场景

组合使用的最佳实践

在实际应用中,少样本提示与思维链并非互斥,而是可以有机结合。以下是一个通用的组合模板:

我需要一个[复杂功能]。第一步:请参考以下示例理解需求(少样本):示例1:输入A -> 输出X 示例2:输入B -> 输出Y 第二步:请按照以下步骤思考(思维链):1. 分析... 2. 设计... 3. 实现... 4. 处理边界... 第三步:生成完整的代码

如何写出高质量的思维链Prompt

要撰写出高质量的思维链Prompt,以下几个技巧值得重点关注:

技巧1:引导AI分步思考
请按以下步骤思考:1. 先分析数据结构设计 2. 再考虑算法逻辑 3. 然后处理边界情况 4. 最后生成代码

技巧2:要求展示中间结果
在每个思考步骤后,输出当前步骤的结论或伪代码

技巧3:指定思考深度
请深入思考以下细节:- 多角色权限冲突如何解决?- 菜单树深度超过3层怎么办?- 性能优化考虑?

技巧4:要求对比不同方案
请对比两种权限合并策略(并集vs交集)的优缺点,然后选择最优方案

结语

你在实际工作中曾遇到过哪些适合用思维链解决的复杂问题?是否尝试过让AI解释它的推理过程?欢迎在评论区留言交流讨论。

来源:https://juejin.cn/post/7618146400048414762
上一篇AI小助手改变你生活的智能伙伴推荐指南 下一篇零基础龙虾安装教程:快马AI辅助,新手轻松上手
本站内容用于信息整理与展示,如有侵权或内容问题请及时联系处理。

相关推荐

补充同频道和同主题内容,方便继续浏览更多相关内容。

同类最新

继续查看同栏目最近更新的文章。

更多
Stable Diffusion WebUI本地模型下载配置与性能优化指南
AI教程 · 2026-07-04

Stable Diffusion WebUI本地模型下载配置与性能优化指南

StableDiffusionWebUI适合在个人电脑上运行本地绘图模型,关键在于准备显卡环境、正确下载模型、放入对应目录,并通过分辨率、采样器、显存参数等设置提升生成效率与稳定性。

Stable Diffusion WebUI插件安装配置教程:浏览器、编辑器或扩展市场
AI教程 · 2026-07-04

Stable Diffusion WebUI插件安装配置教程:浏览器、编辑器或扩展市场

StableDiffusionWebUI插件可增强模型管理、提示词、图像处理与工作流效率。安装前需确认版本、环境和来源,按内置扩展页、网址安装或本地导入完成配置,并做好备份与兼容性检查。

Stable Diffusion WebUI Docker一键部署:镜像拉取端口映射数据目录配置
AI教程 · 2026-07-04

Stable Diffusion WebUI Docker一键部署:镜像拉取端口映射数据目录配置

使用Docker部署StableDiffusionWebUI可降低环境配置难度,重点在于选择镜像、映射7860端口、挂载模型与输出目录,并提前确认显卡驱动、存储空间和访问权限。

Stable Diffusion WebUI API Key 获取与配置教程:账号注册与国内网络设置
AI教程 · 2026-07-04

Stable Diffusion WebUI API Key 获取与配置教程:账号注册与国内网络设置

围绕StableDiffusionWebUI的APIKey配置,说明账号注册、密钥获取、本地接口认证、国内网络访问设置、验证方法与安全注意事项,适合AI绘画工具初次部署和团队接入使用。

Stable Diffusion WebUI Linux服务器部署完整教程:从环境准备到后台运行
AI教程 · 2026-07-04

Stable Diffusion WebUI Linux服务器部署完整教程:从环境准备到后台运行

StableDiffusionWebUI在Linux服务器部署需先确认GPU、驱动、Python与依赖环境,再拉取项目、配置模型和启动参数。后台运行建议使用tmux、nohup或systemd,并做好访问鉴权、端口限制、资源监控与模型来源校验。