debug-console-only

name	debug-console-only
description	帮助用户在项目中调试代码（受控 console 打点，不修改业务逻辑）。用户提示词如何对应「加打点 / 删打点」见「触发条件」，硬约束与反面案例见正文。

Debug with Console Only

触发条件（何时加打点 / 何时删打点）

根据用户 本轮提示词 判断（不靠猜）：

动作	用户意图（典型说法）
加 [DEBUG-myshow]	明确要求 console、调试、打点、定位/排查、看为什么报错 等 继续查 的说法（含「帮我找原因」但未说已查明）；以及 debug / Debug 等英文说法，例如 「帮我 debug」「帮我debug」「帮我 debug 一下」「debug 一下」「帮忙 debug」（与「调试一下」同效力，均视为要排查而非仅要文字结论）
删 [DEBUG-myshow]	已找到原因：如「我找到原因了」「找到原因了」；或明确要求 删调试 / 调试结束 / console 可以删了；或对解释/结论表示 无异议、准备做下一件事：如 「OK」「好的」「明白了」「了解了」「清楚了」「知道了」 等单独或紧跟在结论后的短附和（视为调试段落结束，应 先删 [DEBUG-myshow]，再接受用户的下一指令）

不要混淆：请你 帮忙查 → 加；用户说 自己已经 查明 / 要收尾删 log / 用 OK、明白了 等表示可以收摊 → 删（可先删 log 再梳理或另起修复指令）。纯梳理、只要说明机制 见下文「When NOT to use」，不加 新打点。

注意：用户只说「OK」「明白了」且未启动新任务时，本条表示 删除调试 console；若用户紧接着说「请修复…」等，则 先删打点再按新指令改代码（改代码本身不属本 Skill 的默认行为，需用户明确要修复）。

Hard rule（硬约束）

本 Skill 下 严禁修改任何业务逻辑代码，包括但不限于：

• 禁止 增删改：if/else、try/catch、return、函数调用链、Promise resolve/reject、新增分支、补 onError 调用、改 SDK 回调里的处理顺序等（哪怕是为了修「没提示」）。
• 禁止 以「调试」「找原因」「修一下」为由 顺带提交修复；修复必须等用户 另起明确指令（例如「请修复上传失败无提示」）且 不使用本 Skill 再改。
• 禁止 用户只要求 调试 / 看报错 时 自行改通路：例如为对口错误而 补 SET_TOKEN、在未确认前拉凭证、handleUpload 改 async、新增 reject/提前 return、修 extraParams 写法 等。此类改动会 改变运行结果或掩盖原始失效条件，用户 无法再从行为与 diff 对比中独立确认根因。

仅允许：在相关代码处 增加 带统一前缀的 console.log / warn / error（及为满足 ESLint 的 eslint-disable-next-line no-console）；以及 仅用文字 说明从现有代码/用户粘贴的响应可推断的可能原因。不得 用「修一下就能好」的代码替代定位步骤。

When NOT to use（不触发本 Skill：纯梳理）

以下请求是 读代码 + 文字说明，不是「打点调试」—— 禁止 借机新增 [DEBUG-myshow]，禁止 在回复里建议「为了梳理再加一轮 log」作为默认动作：

• 「梳理」「说明」「是怎么…的」「有没有监听…」「根据…变化」「达到此目的还有哪些方式」等 架构/机制说明。
• 用户已说 「我知道问题原因了」 并接着要 梳理 某模块（例如上传如何拿 token、是否随 token 更新实例）：视为 收尾说明阶段。

必须执行的顺序（当仓库里仍有上一轮调试留下的 [DEBUG-myshow] 时）：

1. 先 删除所有带 [DEBUG-myshow] 的 console 与对应 eslint-disable-next-line no-console（规则同「删除调试代码」节）。
2. 再 基于删完后的代码做梳理回答（或若用户仅要文字、不要求改仓库，则不得保留调试 console 在 PR 里——若本轮不改文件，至少在回复中说明「当前分支仍有调试 log，应删掉后再提交」）。

梳理阶段禁止：新增诊断 console、顺手改业务逻辑、顺手实现「补监听」。

---

When to use（触发说法 · 加 console）

用户出现以下说法时 按本 Skill 执行（只加 console + 口头/文字分析，不改逻辑）：

• 「console 一下 code」「打点」「打日志」「加个 console」
• 「调试一下」「哪里有问题」「调一下」— 包括 带行号/文件片段 的调试请求（例：useCustomUrlUpload.js (99-124) 调试一下）
• 「debug」「Debug」「帮我 debug」「帮我debug」「帮我 debug 一下」「debug 一下」「帮忙 debug」— 与「调试一下」同等触发；场景化说法如「为什么有个场景 handleSuccess 没有 data.url」若与 debug/排查/找原因 同条出现，按本 Skill（只加 [DEBUG-myshow] + 说明，不擅自改业务逻辑）
• 用户粘贴 接口/业务返回（如 success: false、param invalid, token is empty）并写 「帮我调试 upload / uploadFile」 —— 仍按本 Skill：只加 [DEBUG-myshow] 与读代码推理；除非用户明确说「请修复/请改代码」，否则 禁止 顺带实现「补 token、对齐 uploadFile 逻辑」等修复。
• 请 帮忙排查、找原因、看为什么（用户尚未表示「已经找到原因」）— 只加 [DEBUG-myshow] 与结合代码/报错的文字说明；不得 在仓库里直接改成正式修复。一旦用户改口说已找到原因，改走下方「删 console」节，禁止继续加 log。

当用户出现以下说法，则删除 console

• 我找到原因了 / 找到原因了 / 找到问题了（用户 已收尾 的口吻）
• OK / ok / 好的 / 明白了 / 了解了 / 清楚了 / 知道了 等（在刚结束解释、根因讨论或调试步骤的语境下，表示无异议、准备进入下一操作 —— 先删 [DEBUG-myshow]，避免带着打点进入后续开发与提交）
• 删除 console / 调试结束
• 已知原因 + 要你「梳理」「说明机制」：等同调试收尾 —— 先删 [DEBUG-myshow]，再梳理（不要跳过删除直接长文梳理，避免仓库里长期残留打点）。

步骤

• 因调试而加的所有带约定前缀的 console（及紧挨的 eslint-disable-next-line no-console）去掉；然后再回答梳理类问题，或再执行用户下一条非调试类指令（用户已用 OK/明白了等收口时亦然）。

Rules（细则）

1. Allowed: 仅增加诊断用 console.* + 必要的 eslint-disable-next-line no-console。
2. Forbidden: 任何会改变运行路径、返回值、对外行为的代码变更；依赖升级；无关格式化/重构。
3. Scope: 优先最小范围：用户指的文件/行、其直接调用方、一层被调方。

Workflow

1. 从现象起

• 用户指文件/行：在该处及 入参、出参、catch、回调入口 前后加 console。
• 用户贴堆栈：在能映射到的最近业务代码帧加 log；node_modules 内则在调用该 API 的上层打 log。

2. 用户贴新报错

• 继续只加/调整 console 缩小范围；仍禁止改逻辑。

3. 统一前缀（便于一次性删除）

// eslint-disable-next-line no-console
console.log('[DEBUG-myshow]', 'step', { result, hasOnError: typeof onError === 'function' });

4. 用户要求删掉调试代码

1. 只删除 带 [DEBUG-myshow]（或本轮约定前缀）的、本轮新增的 console 与对应 eslint-disable 行。
2. 不要 删掉项目里原本就有的 console。
3. 不确定时问用户或对照改动前版本。

错误案例（反面教材：真实 diff 教训）

案例 A：调试指令下擅自改业务代码

用户提示词（摘要）：上传报错 param invalid, token is empty、success: false，让 调试 uploadFile / 上传。

错误做法（违反本 Skill）：在 未收到「请修复/请改代码」 的前提下，直接改 useCustomUrlUpload.js / uploadFile.js —— 例如 dispatch('common/SET_TOKEN')、handleUpload 改 async、try/catch、type 缺失改 reject、extraParams 初始化 等。

为何算错：

• 用户目标是 自己确认根因（例如：是否 store 里 token 一直为空、是否仅某条上传路径未拉 token、是否与 uploadFile 行为不一致）。
• 抢先改代码后，现象可能被 直接盖住 或 与原始问题混在一起，diff 里 既有「诊断」又有「处方」，用户 难以区分「证据链」与「武断修复」。

正确做法：

1. 在 读 token 的位置、创建 Uploader 前后、upload 入参 等处加 [DEBUG-myshow]，必要时对比 两条调用链（如 hook vs uploadFile.js）各打一组 log。
2. 文字说明：若日志显示 token 为空而另一条路径会先 SET_TOKEN，则推断为路径不一致 —— 但 不自动改代码；请用户确认后再单独下 「请按 uploadFile 对齐拉 token」 类指令。

案例 B：已知情 + 要梳理，却未先删 console

用户提示词（摘要）：「我知道问题原因了，没有监听 token 传入，你先帮我梳理本项目上传公共组件是怎么监听 token 的、有没有随 token 变化处理、还有哪些方式能达到目的。」

错误做法：

• 没有 先删除此前调试留下的 [DEBUG-myshow]，就直接长篇梳理；或梳理到一半又去 加新的 console。
• 把「梳理」误判成「继续调试」，在 说明机制 的轮次里叠加打点，导致 diff 混杂「解释性修改」与「临时日志」，用户难以收尾。

正确做法：

1. 识别本轮意图是 纯机制说明（读 useCustomUrlUpload / customUrlUpload / uploadFile / store 等即可）。
2. 若这些文件里仍有 [DEBUG-myshow]：第一步删掉，第二步再输出结构化梳理（computed / makeSig / 缓存 Uploader / 与 uploadFile 的差异等）。
3. 不加 新 console；不改 业务代码，除非用户 另起一句「请修复…」。

Anti-patterns

• 用户说「调试」「找原因」却 擅自加入「业务失败分支」「补 reject」「统一走 onError」 —— 这属于 修复，违反本 Skill。
• 用户贴 token is empty 类错误，AI 顺手实现拉 token —— 同上，除非用户明确要求 修复。
• 把「临时 console」在同一轮里换成「正式修复」却不另起修复任务。
• 无前缀、散落在各处的调试用 console，导致无法安全删除。
• 用户要 梳理/说明 却 留着或新增 [DEBUG-myshow]，或未 先删后答。
• 用户已 OK / 明白了 表示理解、准备下一步，却 未删 [DEBUG-myshow] 就让后续 diff 混入提交。

Output to user（简短）

加完 console 后告诉用户：

• 在 DevTools 的 Console / Network 要看什么；
• 如何复现、下一轮把 完整报错 + 带 [DEBUG-myshow] 的最后几行 贴回来。

若已推断根因但用户未要求修复：说明原因即可；修复请用户 单独下指令。

若用户转为 梳理机制：先删 [DEBUG-myshow]（若存在），再用 纯文字 回答；不要 在本轮继续加 log。

若用户仅回复 OK、明白了 等对结论的 确认/收尾：先删 仓库里本轮/遗留的 [DEBUG-myshow]，再等待或执行其 下一条明确任务（不要把打点留到下一功能开发里）。