请输入原始标题

为什么结构化Prompt依然无法满足复杂业务场景？

先下个结论：上一篇文章梳理了结构化Prompt的四项核心要素，能够驱动模型产出专业的Vue3组件。但在实际项目里，真正的难点往往集中在权限控制、状态机流转、复杂表单校验这类深层业务逻辑上。此时，仅告知AI“做什么”远远不够，必须手把手传授“怎么做”。

本文以一个动态权限菜单的真实案例切入，一次性吃透两个高阶Prompt技巧：少样本示范与思维链引导。

• 少样本提示（Few-shot Prompting）：给出若干输入输出样例，迫使AI识别并复制既定模式。
• 思维链（Chain of Thought）：要求AI将内部推理链条完整外显，专门应对多层逻辑判断。

少样本提示：借示例定规范

本质是什么？

提供若干对完整的输入-输出映射，让模型在上下文中自主归纳任务模式。类似学科辅导——先演示几道例题，再要求独立完成练习题。背后逻辑高度一致。

适用场景一览

• 输出格式严格受限的任务（如JSON与XML互转）
• 存在明确可枚举的模式匹配规则
• 需要模型精准复制指定编码风格或术语体系

思维链：把大脑里的推导过程写出来

本质是什么？

强制模型在给出最终结果前，先生成中间推理步骤。如同数学教师要求学生在试卷上写出完整演算过程，而非只填一个答案数字。

典型应用场景

• 需要多步推理才能得出结论的任务
• 条件分支密集、决策路径不透明的业务逻辑
• 必须提供决策依据的合规性或审计场景
• 数学计算、算法设计与复杂度分析

实战拆解：从0到1构建动态权限菜单

需求图谱

核心需求清晰：基于用户角色动态渲染菜单树，最低支持三种角色：

• admin：全量菜单可见
• editor：仅显示内容管理侧菜单
• visitor：只能看到仪表盘及公共页面

版本1：开放式提问

提交的Prompt

写一个根据用户角色控制菜单显示的逻辑代码

模型输出

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

缺陷诊断

• 仅区分admin与非admin两种状态，颗粒度粗劣。
• 完全不支持多角色叠加场景。
• 逻辑极度简化，无法应对生产环境的多级嵌套需求。
• 未考虑菜单树的递归渲染与权限细粒度控制。

版本2：少样本提示——教模型识别模式

提交的Prompt

我需要一个根据用户角色动态渲染菜单的函数。请参考以下输入输出对照：示例1：用户角色="admin" 输出：["仪表盘","用户管理","内容管理","系统设置"] 示例2：用户角色="editor" 输出：["仪表盘","内容管理","文章审核"] 示例3：用户角色="visitor" 输出：["仪表盘","公开文档"] 请严格遵循上述模式，生成支持至少3种角色的权限判断逻辑。

模型输出

/** * 根据用户角色获取可见菜单列表 * @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'))

迭代收益

• 通过示例明确了输入输出之间的映射结构。
• 模型自动将角色总数扩展到5种。
• 代码可读性与可维护性显著提升。

残留短板

• 菜单以硬编码扁平数组呈现，无法表达多级嵌套关系。
• 未实现多角色权限合并逻辑（例如用户同时属于editor与analyst）。
• 缺少针对单个菜单项（如按钮级）的权限细粒度控制。

版本3：思维链——将推理步骤显式化

提交的Prompt

我需要构建一套支持多级嵌套与细粒度控制的动态权限菜单系统。请先输出完整思考过程，再生成代码。需求要点：1. 菜单允许无限级嵌套 2. 每个菜单项可独立配置所需权限 3. 用户可同时拥有多个角色 4. 系统需根据用户所有角色合并计算最终可见菜单 请按以下结构化步骤展开：步骤一：确定菜单树的数据结构 步骤二：确定多角色权限合并策略（取并集还是交集？） 步骤三：设计递归遍历菜单树的过滤函数 步骤四：列举并处理所有边界条件（空权限、未知角色、空树等） 步骤五：输出完整的TypeScript实现

模型输出

步骤一分析：菜单数据结构定义

每个菜单节点需包含以下字段：- name：展示名称 - path：路由地址 - icon（可选）：图标标识 - children（可选）：子菜单数组 - permissions（可选）：所需权限列表，满足任一即可见

步骤二分析：多角色权限合并策略

假定用户角色列表为 ['admin', 'editor'] 策略选择：取所有角色权限集合的并集 理由：用户持有的角色本质上代表其职责叠加，应拥有全部角色的权限总和，而非交集（交集可能导致权限丢失）。

步骤三分析：递归过滤算法设计

采用深度优先遍历：1. 检查当前菜单节点的可见性（自身权限与用户权限是否有交集）。2. 如果存在子节点，递归处理子节点。3. 节点保留条件：节点自身可见，或存在至少一个可见的子节点（用于保留嵌套导航结构）。

步骤四分析：边界条件处理

- 权限为空数组或未定义：视为公开菜单，任何角色均可见。- 用户角色ID不存在于角色列表：视为该角色无效，不贡献任何权限。- 菜单树为空：直接返回空数组。

最终代码输出

/** * 动态权限菜单系统 * 支持多级嵌套、多角色并集、细粒度权限控制 */ // ==================== 类型定义 ==================== interface MenuItem { name: string; path: string; icon?: string; children?: MenuItem[]; permissions?: string[]; } interface UserRole { id: string; name: string; permissions: string[]; } interface User { id: string; name: string; roleIds: string[]; } // ==================== 权限计算函数 ==================== /** * 第一步：汇总用户所有角色的权限（取并集去重） */ function getUserPermissions(user: User, roles: Map): string[] { if (!user.roleIds || user.roleIds.length === 0) return []; const permissionSet = new Set(); user.roleIds.forEach(roleId => { const role = roles.get(roleId); if (role && role.permissions) { role.permissions.forEach(perm => permissionSet.add(perm)); } }); return Array.from(permissionSet); } /** * 第二步：单个菜单项可见性判断 */ function isMenuItemVisible(menuItem: MenuItem, userPermissions: string[]): boolean { if (!menuItem.permissions || menuItem.permissions.length === 0) return true; // 公开菜单 return menuItem.permissions.some(perm => userPermissions.includes(perm)); } /** * 第三步：递归过滤菜单树 */ 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); } 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; } /** * 第四步：主入口函数 */ function getUserMenus(user: User, allMenus: MenuItem[], allRoles: Map): MenuItem[] { if (!user || !allMenus || !allRoles) { console.warn('参数不完整，返回空菜单'); return []; } const userPermissions = getUserPermissions(user, allRoles); return filterMenusByPermissions(allMenus, userPermissions); } // ==================== 使用示例 ==================== 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 思维链：做精准选择

上述案例完整还原了两种Prompt技巧在实战中的表现差异。以下对比表帮助快速决策：

组合使用的通用模板

实践中，少样本与思维链并非非此即彼，最有效的Prompt往往融合两者。一个经过验证的组合框架如下：

我需要实现一个[复杂功能]。第一阶段（少样本）：参考以下输入输出示例掌握业务映射规则：示例1：输入A -> 输出X 示例2：输入B -> 输出Y 第二阶段（思维链）：请按照以下结构化步骤推演：1. 分析数据结构设计 2. 设计核心算法逻辑 3. 列出边界条件 4. 生成最终代码

打磨思维链Prompt的四个实操技巧

技法1：明确要求分步推演
请严格执行以下思考序列：1. 先设计数据模型 2. 再定义核心算法 3. 后处理异常边界 4. 最后输出可执行代码

技法2：强制输出中间产物
在每一步思考完成后，输出当前步骤的结论或伪代码，不要直接跳到最终答案

技法3：限定思考方向与细节深度
请重点思考以下棘手问题：- 多角色权限冲突如何仲裁？- 菜单树深度超过5层时的递归性能？- 新增角色后缓存刷新策略？

技法4：要求对比不同技术方案
请对比“权限并集”与“权限交集”两种合并策略在维护性与安全性上的trade-off，并推荐其中一种。

交流线

你在工程中有没有遇到过必须靠思维链才能拆解的复杂逻辑？有没有试过让AI输出思考过程来辅助调优？欢迎在评论区分享你的实战经验。