AI编程常见问题：10个让你脱困的解法
AI编程常见问题的10大场景逐一解码：你看到了什么、底层实际发生了什么、确切的解法，以及能让你从卡住的状态中脱困的那条提示词，非技术创始人也能照做。
当你在用AI构建时卡住了，那几乎总是AI编程常见问题之一，而几乎不会是全新的问题。同样的十种场景，涵盖了非技术创始人几乎每一次“我完全不知道接下来该怎么办”的时刻——而且每一种都有已知的原因和已知的解法。脱困不是英雄行为。它是模式匹配。
这是我从为AI Product Builder课程学员整理的二十种卡住场景清单中精选出的前十——那些一再出现的。在表格里找到你的症状，弄清楚实际发生了什么，应用解法。如果你还没学会读浏览器控制台里的错误信息，请先学这个——它能把下面每一种场景从谜团变成诊断。
你为什么会卡住（以及为什么从来不是随机的）
每个卡住的场景都有三种根源之一。要么是你的环境漂移了（数据库与代码不同步、缺了某项设置、缓存过期），要么是你的代码有具体缺陷（拼写错误、缺少检查、导入错误），要么是你的数据不是你以为的那样（被过滤掉了、在错误的账户里、被标记为停用）。AI生成的代码还多了一层变数：代码本身往往能跑——坏的是围绕它的那些假设。
这就是为什么“再试一次”很少奏效，也是为什么系统化胜过慌乱。匹配症状，检查根源，应用解法。
AI编程常见问题：10个最常见的场景，逐一解码
| 你看到的 | 实际发生的 | 解法 |
|---|---|---|
| 400 Bad Request，“column does not exist” | 代码期待一个从未创建的数据库列——代码与数据库不同步 | 应用你待执行的数据库迁移，然后在Supabase控制台查看该表，确认该列存在 |
| 数据存在却不显示 | 数据被过滤掉了：停用标记、草稿状态，或者它属于另一个账户 | 在数据库控制台检查该行——查看is_active这类标记，以及它所属的账户 |
| 401 Unauthorized | 你的会话已过期，或者你被登出了 | 登出再重新登录；如果仍然如此，清除浏览器中该网站的数据，重新登录 |
| 403 Forbidden或406 Not Acceptable | 你已登录，但数据库安全规则（RLS）阻止了该操作 | 在Supabase控制台检查你的用户角色和该表上的安全策略 |
| 重复键冲突 | 你在创建一个名称或地址已存在的东西——这些必须唯一 | 换一个不同的值，或者更新现有记录，而不是创建新的 |
| Cannot read property of undefined | 代码在数据从数据库到达之前就运行了 | 让AI在使用数据之前加一个加载检查 |
| Module not found | 导入路径拼写错误、文件不存在，或某个包从未安装 | 检查路径的确切拼写和大小写；运行安装命令；重启开发服务器 |
| 部署时构建失败 | 本地忽略的类型错误，或托管平台上缺少设置（环境变量） | 先在你的机器上运行构建，看到真实的错误；把每个环境变量复制到托管平台的控制台 |
| 已部署，但网站显示旧版本 | 你的浏览器或CDN在提供旧站点的缓存副本 | 强制刷新（Cmd + Shift + R）；在隐私窗口中测试；清除缓存后重新部署 |
| 改了代码，毫无反应 | 开发服务器没在运行、文件没保存，或者你改错了文件 | 检查终端是否在运行服务器，保存文件，强制刷新——然后确认你改的是错误实际指向的那个文件 |
三个问题，其实是同一个问题
再看看第二、三、四行。“数据不显示”“401”和“403”感觉像三场不同的灾难，但它们是同一个家族：身份与权限。数据库总是问同样的三个问题——你是谁，你属于哪个账户，你被允许这样做吗？任何一个答案出错，你就会得到这三种症状之一。
所以按这个顺序调试。第一：我真的登录了吗？第二：这些数据在我的账户里吗，还是我用另一个邮箱创建的？第三：这张表上的安全策略允许我的角色这样做吗？十次有九次，你根本走不到第三个问题。
在你的机器上能用，在生产环境里就坏
最打击士气的场景值得单独一节：本地一切正常，你部署了，线上网站却坏了。并没有什么“出错”——本地和生产只是不同的环境。不同的设置、不同的数据库、不同的构建模式。检查清单：
- 先查环境变量。你的代码读取的每一项设置，都必须存在于托管平台的控制台里，而不只是在你的机器上。这个原因比其他所有原因加起来还常见。
- 检查你指向的是哪个数据库。你的线上应用必须使用生产数据库地址，而不是开发用的那个。
- 阅读部署日志。你的托管平台会记录在你机器上从未出现的错误。
- 像生产环境一样在本地构建。在你的机器上运行生产构建命令——如果在那里失败了，你不用再走一轮部署就找到了你的缺陷。
让你脱困的提示词
当表格解决不了问题时，要正确地把问题交给AI。含糊的请求只会得到含糊的猜测——而爱猜的AI可能让事情更糟，正如我在AI如何破坏你的代码库中展示的。脱困提示词有四个部分：
我卡在了[你当时想做的事]。我期望的是：[预期结果]。实际发生的是：[确切症状]。完整的错误信息：[粘贴它，带上文件和行号]。我已经尝试过的：[你的清单]。在提出修复方案之前，先诊断最可能的原因。
最后一句很关键。强制先诊断，能阻止AI朝你的代码库乱开修复——这相当于医生没检查就开药的调试版本。还有一个习惯，能让本文一半的情况永远不会发生在你身上：每次实验之前都提交可用的代码，这样“一切本来都好好的，现在坏了”总有一条一个命令就能退出的路。
本书The Solopreneur RevolutionLuis Gonçalves 讲述如何在不辞职的情况下用 AI 打造独立创业者事业。获取本书 →常见问题
每当我卡住时，应该先做什么？
打开浏览器控制台，读实际的错误——这里教你30秒读懂任何错误。然后查看运行开发服务器的终端。在这两个地方之间，真正的原因几乎总是已经为你写下来了；关键的技能是先看再猜。
昨天一切还好，我什么都没改。发生了什么？
有东西变了——只是你没注意到。常见的嫌疑：你拉取了新代码却没更新依赖或数据库、合并出了问题，或者某个文件被意外还原。问问你的版本控制，自上次可用状态以来变了什么，然后从那里恢复。这就是为什么经常提交可用的代码，是软件世界里最便宜的保险。
我什么时候该停止调试，向AI求助？
在一轮系统化的排查之后：读过控制台、把症状与常见场景匹配过、尝试过一次修复。如果仍未解决，就用上面的脱困提示词粘贴完整的背景——错误、预期、你试过的方法。二十分钟固执的独自瞎猜，抵不上两分钟准备充分的提问。
这些问题是否说明我不该在没有开发人员的情况下做产品？
不是——地球上每个开发人员都会遇到这些完全相同的场景；他们只是见得够多，认得出这些模式。这种识别能力几周就能学会，而不是几年。上面这十行，就是日常调试中“多年经验”的大部分含义。
你到底被困得有多深？
完成职场窒息指数——这项免费测评告诉你是否已准备好成为独立创业者。