让ai使劲折腾的blog代码

从 AI 结对编程到架构重构：我用 Gemini 写博客网站踩过的坑与安全防御指南

作为一个独立开发者/站长，借力 AI 提升开发效率已经成为日常。在搭建和维护我的博客网站（号卡领域）的过程中，Gemini 一直扮演着我的“全栈技术助手”角色。

然而，依赖 AI 写代码并不是一帆风顺的。从简单的样式适配到复杂的逻辑拆分，我经历了不少代码 Bug 的折磨，甚至为了重构体验付出了“全部重写”的代价。今天就来聊聊我在 AI 辅助编程过程中的实战经验、踩坑记录，以及后续的代码优化与安全防护策略。

一、 AI 编程的“翻车”现场与排坑实录

在让 Gemini 帮我生成或优化网站功能时，我遇到了几类非常典型的 Bug，总结下来主要有以下几点：

1. 暗黑模式（Dark Mode）样式适配失效

问题现象：在给网站全局加深色模式时，发现头部导航（header.php）正常切换了，但“关于本站”等特定页面的文字颜色却没有跟着适配，导致深色背景下文字变成“黑字黑底”，无法阅读。

排查与解决：Gemini 在最初给出的 CSS 中使用了局部类名，而忽视了全局选择器的覆盖权重（CSS Specificity）。最后通过统一在 body.dark-mode 下重新定义全局变量（CSS Variables），并将公共样式的继承关系重新理顺，才解决了多页面样式脱节的问题。

2. 国际化/多语言下拉框逻辑冲突

问题现象：网站增加多语言切换时，原本希望下拉框默认显示“Languages”字样，但切换语言后页面语言要设为“简体中文”。Gemini 给出的方案容易将  的 selected 属性和当前实际语言绑定死，导致下拉框一刷新就显示“简体中文”，丢失了默认的标题感。

排查与解决：通过把默认占位符（Placeholder / Default Option）与真正的语言切换逻辑分离，在前端 JS 中控制 select.selectedIndex = 0，后台再通过 Session/Cookie 维持用户的实际语言偏好，成功恢复了默认显示“Languages”的效果。

3. 数据防丢失机制中的“弹窗轰炸”

问题现象：为了防止误触丢失未保存的文章，我让 Gemini 写一段“用户在富文本框键入字符后，点击其他页面弹出离开提醒”的逻辑。一开始 AI 生成的代码监听了全局 beforeunload 或点击事件，导致用户即便没改内容、或者点击富文本自身的工具栏时，也会频繁触发弹窗警告。

排查与解决：通过引入脏数据标记（isDirty Flag），只有当编辑器内容发生真实变更（input / change 事件）且目标路由发生变更时才触发拦截；并在提交成功后手动清空 isDirty 标记。

二、 终极代价：无法修复的 Bug 与“全量重写”

在开发过程中，最让人头疼的不是某个具体的语法错误，而是架构层面的“泥潭”。

在网站运行一段时间后，我发现后台管理核心文件 admin.php 变得异常庞大。 Gemini 在帮我不断叠加功能（文章管理、分类管理、评论审核、系统设置等）时，把所有的增删改查逻辑、路由判断、甚至 HTML 渲染全塞进了这一个文件里。

遇到的瓶颈：

代码极其臃肿：单文件突破上千行，逻辑互相交织。

修改“牵一发动全身”：改动一下评论管理的逻辑，竟然意外破坏了文章发布的拦截。

AI 提示词失效：由于上下文太长，每次把整个 admin.php 扔给 Gemini 时，它开始出现“幻觉”，经常遗漏之前的关键逻辑，导致越修 Bug 越多。

解决方案：果断切断，独立分离与全量重写

当修补成本已经高于重构成本时，我决定停止在旧代码上贴补丁。

拆分功能模块：让 Gemini 协助我将评论管理模块（Comment Management）彻底从 admin.php 中剥离出来，重新生成独立的文件/路由（如 admin-comments.php 或 API 接口）。

模块化重构：重新设计后台逻辑，采用 MVC 或标准的 API + 前端渲染架构，将业务逻辑（PHP）、数据持久层（SQL）和视图层（HTML/JS）解耦。

感悟：AI 擅长写孤立的函数，但缺乏长远的系统架构眼光。当代码结构崩溃时，重构/重写比盲目让 AI 排错更加高效。

三、 如何优雅地优化 AI 生成的代码

经历了重写之后，我也总结了一套如何规范和优化 Gemini 输出代码的方法：

坚持单一职责原则（SRP）：

不要向 AI 提“帮我写一个功能齐全的后台”这种宏大需求。拆解为：“帮我写一个独立的评论列表获取函数”、“帮我写一个评论删除的 API Endpoint”。

提取公共组件与 CSS 变量：

把 Header、Footer、侧边栏独立为模版组件（如 header.php）；样式统一引入 CSS 自定义属性（--bg-color, --text-color），方便暗黑模式全站无缝响应。

前端状态与 DOM 操作分离：

在处理复杂的表单保存、弹窗提示逻辑时，优先维护 JS 中的数据状态，而非频繁通过 DOM 节点去判断用户输入了什么。

四、 为个人网站加入坚固的安全防护

AI 生成的代码往往优先考虑“功能实现”，在安全防御上容易留有盲区。以下是我在重构过程中重点加入的安全防护措施：

1. 防范 XSS（跨站脚本攻击）

场景：评论区、文章富文本框。

防御措施：所有用户输入的评论内容在渲染到页面前，必须进行转义处理（如 PHP 的 htmlspecialchars()）；针对富文本编辑器，采用严格的白名单过滤库（如 HTMLPurifier），防止恶意脚本被注入。

2. 防范 CSRF（跨站请求伪造）

场景：后台敏感操作（删除文章、批量审核评论、保存设置）。

防御措施：在所有表单提交和 AJAX 请求中加入动态生成的 CSRF Token。后台在处理 admin-comments.php 的删除或更新请求时，先验证 Token 是否匹配。

3. SQL 注入防护（SQL Injection）

场景：数据库查询与交互。

防御措施：全面废弃传统的字符串拼接 SQL 语句，强制使用 PDO 或 MySQLi 的预编译语句（Prepared Statements）绑定参数。

4. 频率限制与暴力破解防护（Rate Limiting）

场景：后台登录接口、评论提交接口。

防御措施：对评论提交加入 IP 限制和时间间隔校验（例如同一 IP 1分钟内只能发帖1次），增加轻量级的验证码机制，防止垃圾评论脚本轰炸。

五、 结语

Gemini 是一个极其强大的编程杠杆，它能将我们的想法快速变成代码。但AI 是执行者，开发者才是架构师与安全官。

面对臃肿的代码，敢于打破重构；面对生成的代码，保持审慎的态度去进行安全校验与优化——这或许就是我们在 AI 时代与大模型协作的最优解。希望这次的踩坑与重构经验，能为各位独立站长和开发者提供一些有价值的参考！