WaytoAGI用户8021
🧯 Debug 调试提示词库
输入“/”快速插入内容
🧯 Debug 调试提示词库
🧯 Debug 调试提示词库
用户80212025年10月16日修改
📌 使用说明（强烈建议先读）
•
先让 AI 解释问题与原因，再让它动手修改。
•
一次只改一件事：小步快跑。
•
任何「重要或脆弱模块」，在提示里反复强调不要改动无关部分。
•
出现「修了这个又坏那个」的循环，试试回滚 + 渐进式实现。
🚀 高阶调试提示（通用起手式）
1）请先给出「读-only」分析，不要立刻改代码
代码块
请以“只读分析”的方式帮我调试，暂时不要改代码：
1) 用通俗语言解释这个问题/报错的含义与可能原因。
2) 列出最有可能的 3 个根因，按概率从高到低排序。
3) 给出“最小验证步骤”（我该在哪看日志、加哪一行打印、点哪一步复现）。
4) 提供一个“最小改动”的修复建议（不要动无关部分）。
5) 告诉我修复后需要怎么自测（用例/步骤/预期结果）。
问题背景（如有日志/截图可贴在这里）：
2）先确认现状与已尝试方案，避免走老路
代码块
请先梳理我们“已经尝试过的解决方案/修改点”，并说明各自结果与失败原因。
在此基础上，给出一个与上次不同的新路径（更小改动、更安全的方案），并解释为什么这次可行。
🩺 项目体检 / 全量审查（Codebase Audit）
3）结构与健康检查（不动代码）
代码块
请对整个项目做一次“结构健康检查”，只读分析，不要改代码：
- 哪些文件/逻辑的归属不合理？（指出具体文件与建议归位）
- 数据层 / 业务逻辑 / UI 展示是否清晰分层？哪里耦合严重？
- 哪些部分过于复杂或不符合常见最佳实践？
- 列出一个从“高优先级到低优先级”的整改清单，每条包含：目标、影响范围、预计风险、验证方式。
输出为清单与执行顺序建议。
🧊 脆弱区域的「安全修改指南」
4）在敏感模块动刀前的安全框架
代码块
接下来要修改的是“高风险/核心功能”，请以“极度谨慎”的方式执行：
- 修改前：先全面梳理相关依赖、输入输出、受影响页面/接口。
- 修改中：禁止改动与本任务无关的任何文件/组件；若有不确定，请先发“计划说明”，得到确认后再继续。
- 修改后：提供详细自测清单（含回归点）。
具体任务：
在保留原有邮箱密码登录的前提下，新增 Google OAuth 登录，不得破坏现有流程。
⚡ 性能排查（变“快”的方法）
5）性能体检（只读分析→优化建议）
代码块
应用功能正常，但感觉有点“卡/慢”。请只读分析并给出优化建议：
- 是否存在重复/不必要的网络或数据库请求？
- 哪些页面或组件高频重复渲染？是否能缓存/懒加载/拆分？
- 资源是否过大（图片/脚本包体）？是否需要压缩或分包？
- 给出“按性价比排序”的优化方案清单：每条包含“改动点、预期收益、验证指标与验证方法”。
不要改代码，先出报告与行动清单。