豆包重构函数逻辑错误修复：提示词优化技巧
豆包在重构函数时出现逻辑错误，根源通常不在模型能力，而在于提示词未能锁定关键约束——它不清楚哪些变量不可变动、哪些分支必须保留、哪些副作用必须延续。
明确划定不可触碰的逻辑边界
提示词开头第一句直接写明：【禁止改动：checkAuth()调用位置、error.code === 403后的跳转路径、所有try-catch外层的return false】。这条指令比笼统的“保持原有逻辑”更具约束力，因为豆包会默认未声明的代码段属于可优化范围。
遗漏这句，它可能将原本兜底的return false替换成throw new Error()，直接导致上游调用方崩溃。
用具体输入输出样例锁定行为预期
方法一：提供最小可复现case
输入：{user: {id: 123, role: 'guest'}, action: 'delete'} → 当前返回false，重构后仍必须返回false，且不触发API调用。
方法二：标注关键中间态
// 重构前第7行：if (!user || user.role === 'guest') return false;
→ 这行判断必须保留，且必须在fetchData()之前执行。
强制要求保留副作用链条
第一步：指出副作用节点
当前函数内有3处副作用：localStorage.setItem('lastAction', action)、console.warn()、调用trackEvent()。
第二步：声明依赖顺序
【trackEvent()必须在localStorage赋值之后、console.warn()之前执行】。不明确顺序，豆包可能重排语句，造成埋点丢失用户行为上下文。
第三步：禁止封装副作用
不允许把console.warn()包装进新函数或三元表达式，必须保持原调用形式——否则日志系统无法按固定格式解析。
让豆包自行验证重构结果
在提示词末尾追加一句：
“重构完成后，逐行对照原始代码，标出所有新增/删除/移动的非空行，并说明每处变更是否影响以下任一行为：① 403响应处理 ② guest角色拦截 ③ localStorage写入时机”。
这一步强制它主动对齐边界，而非凭印象“感觉差不多”。