Vibe Coding 知识库

常见问题与踩坑记录 ​

本文收录团队在 AI 辅助编程实践中遇到的真实问题和解决方案。每个问题都来自实际场景，包含踩坑过程和可操作的应对策略。

第一类：代码质量问题 ​

Q1：AI 生成的代码看起来没问题，但上线后出了 Bug，责任应该怎么算？ ​

场景还原：某开发者用 AI 生成了一段数据处理函数，本地测试正常，PR Review 时 Reviewer 也没发现问题，上线后在特定边界条件下抛出异常，导致一批用户数据处理失败。

根本原因：AI 生成的代码在"Happy Path"上表现良好，但对空列表、并发写入、特殊字符等边界情况没有充分处理。Reviewer 没有针对 AI 代码的特殊审查意识。

解决方案：

  1. 提交者负完全责任，"AI 生成的"不是免责依据。
  2. 对 AI 生成的处理函数，要求补充边界条件测试，不只测正常路径。
  3. 在 PR 中用 [AI-ASSISTED] 标签提示 Reviewer 加强关注。

预防措施：将 AI 生成的核心逻辑代码纳入强制 Review 规则，不允许自我批准。

Q2：AI 生成的函数调用了一个不存在的方法，怎么在 Review 时发现？ ​

场景还原：工程师使用 Claude 生成了一段 Pandas 数据清洗代码，其中调用了 df.auto_clean(schema=...) 方法，代码读起来很合理。提交后在 CI 中才因 AttributeError 失败。

根本原因：AI 产生了"幻觉 API"——用直觉合理但实际不存在的方法名。这类问题在静态分析中很难被捕获，因为方法可能来自动态加载的模块。

解决方案：

  1. 对所有不熟悉的方法调用，Reviewer 必须查官方文档确认，不能凭印象判断。
  2. 要求提交者在 PR 描述中列出所有新引入的外部方法，并附官方文档链接。
  3. 在 CI 中强制运行测试，不能仅靠人工阅读发现此类问题。

教训：AI 幻觉 API 的危险之处不是"明显错误"，而是"看起来很合理"。

Q3：AI 写的代码过度设计，充满不必要的抽象，但 Reviewer 觉得"架构挺好的"通过了，后来维护非常痛苦。 ​

场景还原：一个简单的配置读取功能，AI 生成了包含工厂类、策略接口、适配器层的完整架构，共 300+ 行。Reviewer 欣赏"设计感"就批准了，6 个月后来了新功能需求，改一个小逻辑要动 8 个文件。

根本原因：AI 倾向于生成"教科书级别"的架构，而不是"当前需求所需的最简架构"。Reviewer 没有用"这个复杂度有没有解决真实问题"来评估。

解决方案：

  1. Review 时对复杂结构的问题应该是："这个抽象解决了什么当前存在的问题？"
  2. 如果无法在 30 秒内解释一个抽象层存在的理由，很可能应该删掉。
  3. 推行"先简单后演进"原则：简单实现先上线，真的需要扩展时再重构。

第二类：安全与合规问题 ​

Q4：我无意中把包含数据库连接字符串的配置文件片段发给了 AI，怎么办？ ​

场景还原：排查一个数据库连接错误时，开发者将 application.yaml 的内容粘贴到了 ChatGPT 网页版，其中包含了生产数据库的用户名、密码和主机地址。发现后不确定如何处置。

紧急处理步骤：

  1. 立即轮换凭证：联系 DBA 或运维，立即修改被暴露的数据库密码。
  2. 通知安全团队：将事件经过（时间、内容范围、使用的 AI 服务）报告给安全团队或主管。
  3. 记录事件：在内部安全事件记录中记录此次事件，便于后续合规审查。
  4. 检查访问日志：确认在暴露窗口期内是否有异常访问。

预防措施：提问前养成"检查敏感内容"的习惯。配置脱敏示例：将真实密码替换为 <YOUR_DB_PASSWORD> 后再提问。

Q5：AI 生成的代码通过了 Review，但上线后被安全扫描发现 SQL 注入风险，这是谁的责任？ ​

场景还原：AI 生成了一段搜索功能代码，使用了字符串拼接构建 SQL 查询。Review 时双方都没有发现。上线后安全团队的 DAST 扫描报告了 SQL 注入漏洞，需要紧急修复。

问题本质：AI 生成代码时常省略安全加固，优先展示功能逻辑。这类问题在代码阅读时容易被忽略，因为字符串拼接看起来"功能上是对的"。

解决方案：

  1. 提交者和 Reviewer 共同负责，这不是相互推诿的场景。
  2. 在团队 Review 流程中增加"安全专项检查"步骤，对数据库操作代码使用安全检查清单。
  3. 在 CI 中引入 SAST 工具（如 Bandit、Semgrep），自动检测常见安全模式。

后续改进：将此次事件加入团队 FAQ，作为安全意识培训素材。

Q6：如何判断哪些 AI 工具可以用于公司代码，哪些不行？ ​

核心判断标准：

问题说明
代码会上传到第三方服务器吗？如果是，确认对方的数据隐私政策
数据会被用于模型训练吗？企业版通常不会，免费版通常会
数据在哪个地区存储？是否符合公司的数据合规要求
是否有企业数据隔离保障？防止数据与其他用户混合

操作建议：使用企业版工具（如 GitHub Copilot Business、Claude Teams），并在使用前完成内部的工具登记审批。

第三类：工作流与效率问题 ​

Q7：用 AI 写代码之后，总感觉自己不理解这段代码，但又不好意思说，怎么办？ ​

场景还原：新人在用 AI 快速完成任务后，代码 Review 时被问到某段逻辑的原理，答不上来，面对"你不理解自己提交的代码"的质疑感到羞愧。

核心观点：不理解自己提交的代码是严重的工程问题，不是"效率提升的代价"。这个问题需要正视，不能回避。

解决方案：

  1. 提交前逐行理解：如果有任何一行你说不出来它在做什么、为什么这么做，就不应该提交。
  2. 用 AI 解释 AI：不理解的代码，直接问 AI："解释这段代码的每一行在做什么，以及为什么这样写。"
  3. 建立"能讲清楚"标准：在脑中模拟向同事解释这段代码，如果卡壳了，说明理解还不够。

Q8：AI 上下文用完了，或者回答质量突然下降，该怎么处理？ ​

场景还原：在一个长对话中，越到后面 AI 给出的建议越脱离项目实际，开始重复之前说过的内容，甚至出现矛盾。

原因分析：AI 的上下文窗口有限，对话过长后早期信息被压缩或丢失，导致"失忆"现象。

解决方案：

  1. 开新会话：不要在一个越来越长的会话中强行继续，新开一个会话并重新提供必要的背景。
  2. 提炼上下文：将关键信息总结为一段精炼的背景说明，放在新会话的开头。
  3. 任务分段：大任务拆成独立的小任务，每个任务一个会话，减少上下文污染。

Q9：AI 给出了几种技术方案，我不知道选哪个，怎么做决策？ ​

场景还原：询问 AI 某个功能的实现方案时，AI 列出了三种不同的方案，每种都有优缺点，开发者不确定应该选哪个，陷入选择困境。

决策框架：

1. 团队现有技术栈里已经有的方案 → 优先复用
2. 最简单的能解决当前问题的方案 → 避免过度设计
3. 团队成员最熟悉的方案 → 降低维护风险
4. 经过验证的、有社区支撑的方案 → 避免押注冷门技术

追问技巧：告诉 AI 你的具体约束（团队规模、现有技术栈、维护人力），让 AI 根据约束给出推荐，而不是让它列举所有可能性。

第四类：团队协作问题 ​

Q10：团队有人大量使用 AI 但代码质量差，影响了整体代码库质量，该怎么处理？ ​

场景还原：团队中某位工程师开始大量使用 AI，提交频率显著提升，但 PR 质量明显下降：幻觉 API、缺少测试、不符合规范的代码频繁出现，增加了 Reviewer 的负担。

根本原因：把 AI 工具当成了"生产代码的机器"而非"辅助提升效率的工具"，跳过了理解和验证的环节。

处理步骤：

  1. 先进行一对一沟通，了解是否是对 AI 能力有认知偏差，还是其他压力导致。
  2. 临时提高对该工程师 PR 的 Review 标准，要求更详细的自检说明。
  3. 组织团队分享"AI 代码 Review 要点"，将问题转化为团队学习机会。
  4. 若持续问题，参考团队 AI 公约中的违规处理流程。

Q11：Review AI 代码太花时间，Reviewer 在抱怨，怎么提高 Review 效率？ ​

场景还原：引入 AI 工具后，团队的 PR 数量和代码量都明显增加，Reviewer 反映 Review 负担沉重，且不知道该关注哪些点。

解决方案：

  1. 要求 PR 描述中标注 AI 参与范围和建议重点关注的区域，让 Reviewer 有明确的入手点。
  2. 引入 AI 辅助 Review 工具（如 CodeRabbit），自动完成格式、风格等机械性检查，让人工 Review 聚焦在逻辑和安全。
  3. 明确 Review 优先级：安全漏洞 > 功能正确性 > 代码质量，不要对所有问题花相同的精力。
  4. 控制单个 PR 的大小：AI 容易生成大量代码，要求提交者合理拆分 PR，保持可 Review 的大小。

Q12：不同成员对 AI 的使用程度差异很大，有人完全不用，有人严重依赖，团队该如何统一？ ​

场景还原：团队中老员工倾向于手写代码，认为 AI 不可靠；新成员则大量使用 AI，甚至在不理解代码的情况下提交。两种极端都带来了问题。

核心观点：不需要强制统一使用程度，但需要统一底线要求——无论是否使用 AI，所有提交的代码都必须达到相同的质量标准。

团队管理建议：

  1. 以结果为导向：评价代码质量，不评价是否使用了 AI。
  2. 分享正向案例：让善用 AI 的成员分享具体的效率提升故事，降低抵触情绪。
  3. 建立安全感：向担心 AI 取代的成员明确，团队评价人的标准是工程判断力，而不是打字速度。

第五类：工具与配置问题 ​

Q13：Cursor / Copilot 的补全总是在错误的地方触发，干扰了正常编写，怎么调整？ ​

常见解决方案：

  • 在设置中调整触发延迟（Trigger Delay），避免每次停顿都触发补全。
  • 对特定文件类型（如配置文件、Markdown）禁用自动补全，仅在代码文件中启用。
  • 使用手动触发快捷键（通常是 Alt + \ 或 Ctrl + I），替代自动触发模式，获得更精确的控制。
  • 在写注释、字符串等非代码内容时，养成临时关闭补全的习惯。

Q14：AI 对我们项目的特定框架或内部 SDK 不了解，怎么改善提示效果？ ​

背景知识注入方法：

markdown
# 在对话开头提供项目背景
我们的项目使用：
- 内部框架 X（类似 Express，但路由格式为 @Route('/path') 注解）
- 内部日志库（调用 logger.info/warn/error，不使用 console.log）
- 统一错误类型：AppError(code, message, httpStatus)

请在之后的所有代码生成中遵循以上约定。

进阶做法：

  • 将项目约定整理成一个 project-context.md 文件，每次开始新会话时粘贴到对话开头。
  • 使用支持自定义系统提示的工具（如 Cursor 的 .cursorrules 文件），将项目约定固化到 AI 上下文中。

Q15：AI 生成的代码与我们的 Lint 规则冲突，每次都要手动修复，有没有更高效的方式？ ​

解决方案：

  1. 在 Prompt 中明确代码风格：提问时附上关键的规则说明（如"使用单引号、不加分号、2 空格缩进"）。
  2. 配置 .cursorrules 或等效文件：将 ESLint/Prettier 的核心规则用自然语言描述后放入此文件，让 AI 在生成代码时自然遵循。
  3. 生成后自动格式化：在工作流中配置"保存时自动 Lint 修复"，AI 生成后按保存即可完成格式化，减少手动操作。
  4. 使用 AI 生成 .cursorrules：将你的 .eslintrc 和 .prettierrc 发给 AI，让它生成对应的自然语言规则描述。

本文档持续更新。如果你遇到了新的典型问题，欢迎将其整理后提交到团队 Prompt 库或本文档的 PR 中，帮助后来者少走弯路。