我怎样让 AI 参与这个网站的开发

我确实在用 AI 写这个网站，但不是把一句需求扔进去，然后直接收下整段代码。更常见的情况是：我先说明要改哪一块，让它把相关文件读一遍，再一起把问题缩小。

这个网站已经不只是几张静态页面。前台是 Next.js，内容既有仓库里的 MDX，也有 Supabase 和本地数据存储；图片、音乐等媒体还会走 R2。改动一个看似普通的组件，可能同时碰到服务端渲染、客户端状态和后台数据。如果 AI 没看完整上下文，很容易给出“能编译，但不适合这个项目”的答案。

它最适合帮我做什么

我现在最常让 AI 做三件事。

第一件是找关联代码。比如调整文章可见性时，不能只改文章列表，还要看看详情页、搜索索引、RSS 和站点地图。人工逐个翻当然也可以，但让它先用搜索列出调用关系，会少漏一些入口。

第二件是处理边界清楚的改动。像补一个空状态、统一元数据、给接口加参数校验，这类任务目标明确，也容易通过类型检查和页面结果判断对错。

第三件是复查。代码写完以后，我会让它重新看差异，找有没有把私密内容带进公开接口、有没有破坏移动端、有没有只改了前台却忘了后台。复查不是证明代码正确，只是多一双眼睛。

我不再直接相信“看起来合理”

AI 很擅长补齐一个故事，问题也正在这里。它可能假定项目使用了某个部署平台，可能写出并不存在的配置项，也可能把“准备接入”说成“已经上线”。如果这些内容出现在技术文章里，读起来会很完整，却不是这个网站真实发生过的事。

所以我给自己的规则很简单：涉及项目事实，就回到仓库确认；涉及依赖用法，就看当前版本的文档；涉及性能，就拿实际测量结果说话。没有验证过的数字不写，没有做过的功能也不包装成经验。

代码同样如此。一个修改至少要经过类型检查、代码检查和构建。碰到接口或权限，再补实际请求测试。AI 说“已经修好”不算，命令和页面结果才算。

提示词不是最重要的部分

比起研究一句万能提示词，我更在意给它足够具体的上下文：目标是什么、不能动什么、哪些事实必须保留、最后怎样验收。任务太大时就拆开，让每一步都有清楚的文件范围。

这套方式并不会让开发自动完成，但能把查找、整理和重复劳动压缩掉一些。我仍然需要决定网站要变成什么样，也要为最终留下的代码和文字负责。对我来说，AI 更像一个速度很快、但必须核对的协作者。