重做个人主页：把规则写给 AI 看

背景：和 AI 协作，规则是记忆外置

我在前面发布了《重做个人主页：先回答放什么》、《重做个人主页：建站的技术决策》、《重做个人主页：静态站的 SEO 基建》三篇文章，分别解决了我的新主页怎么设计、怎么实现，以及怎么让搜索引擎正确理解它的问题。

但还有一个问题没有解决：当下一次打开 AI 会话时，它还知道为什么当初要这样做吗？

这次重做主页几乎全程和 AI 协作。过程中我越来越确定，真正值得留下来的不是某一次对话里的提示词，而是那些经过返工、验证和修正之后，仍然值得让下一个会话遵守的规则。

所以这篇是整个系列的收尾：聊聊为什么规则文件其实是“记忆外置”，哪些规则值得留下，规则为什么也会过期，以及最后整理出的 10 条可以直接拿去用的协作纪律。这篇只讲可迁移的部分，站内特设已滤掉，每条带验证证据。

在谈每条规则之前，先看这套规则挂在哪条链上——它们不是散装纪律，而是一个完整的开发工作流：

先看全貌：一条链，四道关，一份规则

1. 设计系统定长相——分三层各司其职，而不是“读一份设计稿”。约束写在规则文档里：token 名、字体、断点、禁用清单，AI 每次会话从这里取；实现落在样式文件里：真正的 CSS 变量，构建时只读这一处；当初的方案定稿进存档：改版时才翻，不参与构建也不参与每次会话。

   设计稿不是执行依据，是档案。视觉一致靠的是“一个事实源 + 一组约束”：样式只读一处定义，页面消费变量不写死数值；规则管“不许违反什么”，存档管“当初为什么这么定”。分层的意义在于——改样式只改一处，改规则只改文档，改方案只动存档，三者互不污染。

2. 单一事实源定数据。样式只在全局样式文件、配置只在配置层、内容只在内容集合、文案只在 i18n——同一维度不复制第二份。开关即契约：功能开关的所有消费面统一受控。

3. 本地闸门定能不能发。构建全绿（构建红 = 不许交付）+ 交付清单全过——明暗双主题、五档断点、开关开/关分别验证、图片不 404、外部接口三态、SEO 产物检查——本地全过才允许提交。

4. 生产终点定对不对。真实域名、HTTPS、CDN、Googlebot 视角的抓取、外部服务的真实连接，本地模拟不了的在这里兜底。发布动作在开发者手里，AI 不自动推送。

5. 规则文件把整条链写下来。每道关的约束写进一个规则文档，开发与 AI 都读它；交付清单是验收入口，内容侧由一套自审规则把关（比如写后的真诚度审阅），存证/交接/范围保证规则跨会话一致。

四道关换成你的项目，例子跟着换、骨架不变：设计约束（你的设计 token / 组件规范）、数据组织（你的配置 / 内容 / 文案分层）、构建验证（你的构建加检查清单）、生产部署（你的上线流程）。

后面五条规则、保质期和三条补充，分别守着这五道关的某一环——读到每条时，可以回看它挂在哪一道关。

一句话：本地解决能不能发，生产解决发了对不对，规则解决这套怎么写、谁来守、跨会话能不能续上。

规则一：开关即契约

新增功能先查是否已有启用开关；已有开关时，所有用到这个功能的地方统一受控——路由、导航、编号、sitemap、RSS，关闭后不留死链。没有开关的功能不强行补。

验证：周刊 RSS 随开关闭环、导航项随开关动态过滤，联动在功能引入时一次完成，没有“功能关了页面还活着”的残留。

为什么科学：开关定义“功能要不要装”，联动面定义“关了之后全站长什么样”——每加一个用到该功能的地方，都过一遍开关。

规则二：配置零逻辑，类型外置

配置里只允许写数据和开关，禁止逻辑编排、渲染处理、地址拼装；类型的定义放在独立文件里，配置只管引用。

验证：一次重命名牵扯十几个文件，零功能变化、零回归——改命名只动数据与导入，渲染逻辑从来没在配置里待过。

为什么科学：分层的承受力取决于最容易被改的文件里有没有逻辑。配置是用户天天摸的文件，它只存数据，改配置的人永远不用担心改坏渲染算法。

规则三：编号与 URL 是显式契约

会被多个页面用到的标识，由工具函数自动生成，禁止手写；URL 由 slug（网址里的英文标识）显式决定，漏写直接构建报错。

验证：板块编号单一编号源生成、九个页面共用、随开关自动顺延；slug 必填后 URL 契约显式化。

为什么科学：会被多个页面用到的标识，让它“被生成”而不是“被填写”——生成制消灭手动同步，必填校验把遗漏挡在构建期而不是上线后。

规则四：外部服务版本锚点

外部 API（程序接口）依赖记录版本号，兼容修复后同步校正；有条件时构建期校验服务版本。

验证：构建期校验版本号，接口变更在发布前暴露而不是上线后被用户发现。外部服务的 API 是“看不见的依赖”——你天天用到它，却注意不到它，最容易在没人提醒时悄悄变掉。把版本号写进配置并构建期校验，等于给这段看不见的依赖上了护栏。

规则五：一次提交一个逻辑，失败要大声

一次提交只含一个逻辑改动，提交信息说明改了什么、为什么；修复与功能同批次时，说明它属于哪个；跳过的测试、未复现的问题显式记录，不假装完成。

验证：整个开发周期提交都只对应一件事，回退一个提交不牵连无关改动；一个未复现的导航闪烁问题提交里写明“未复现，跳过”，而不是“已修复”。

为什么科学：提交粒度决定返工成本——单逻辑提交让“为什么这么改”可追溯；显式记录未完成项，是防止“完成了”变成“以为完成了”的办法。

规则的保质期

把规则写进文件解决“AI 记不住”，但带来第二个问题：规则是阶段性正确的。它诞生于某个阶段的某个坑，选型被推翻后，规则就成了过时说明书——AI 照着它写出来的就是过期实现。

真实例子：开关策略最早写“给功能补开关”，实践里发现强行补是错的，表述校正为“不强行补”；三起技术选型被推翻（公式渲染移除、懒加载回退原生、字体三档切换），文档和规则里的旧表述必须同步清理，不然下一个会话照旧实现写代码。

什么时候清：技术选型变更或回退时（代码改完顺手核对规则文档，别让已删除的实现留在规则里）；阶段切换时（功能定稿后，为过渡期定的临时约束可以摘除）；规则被反复违反却没人纠正时（变相说明它不适用）。怎么清：修正或删除也是单逻辑提交，写明为什么过时；规则文档、配套文档、代码注释三处同步，不许留一处旧表述。

三条补充：存证、交接、范围

• 存证优先，推测与事实分开放：对外产出（复盘、教程、提交说明）中项目相关的描述必须可追溯（提交记录/当前代码），找不到来源改写或删除；推测可以写，但要标明是推测。写这些复盘文章时，两处差点把推测写成事实（一个 bug 被归因到没有证据的诱因、一条历史顺序写反），靠可追溯要求都在成稿前修正。文档里的假事实会被下一个会话当真。
• 会话结束留状态：分支、未提交改动、进行中的事、待决策点记到固定位置；下个会话先读再动。规则文件管“规矩”，管不了“现在在哪”。
• 扩大范围前先确认：主动扩任务范围前列代价确认；只做被要求的，不顺着惯性多做。

提示词：可直接抄的 10 条

以下可直接粘贴进你的规则文件或会话级系统提示词：

# AI 协作开发纪律
1. 开关即契约：新增功能先查是否已有 enabled 开关；已有则所有消费面统一受控（路由/导航/编号/SEO/sitemap），关闭不留死链。新增开关前列出联动面与降级态。
2. 配置零逻辑：配置只存数据与开关，不写 fetch/渲染/URL 拼装；契约与编排放 utils，interface 外置独立类型文件，配置只 import type。
3. 编号与 URL 是契约：被多页消费的编号由工具函数生成，禁止手写；URL 由 slug 字段显式决定，schema 校验必填。
4. 版本锚点：外部 API 依赖记录版本号，兼容修复后同步校正；有条件时构建期校验服务版本。
5. 提交粒度：一次提交一个逻辑改动，提交信息写明改了什么、为什么；修复与功能同批次时说明归属。
6. 失败要大声：跳过的测试、未复现的问题、临时的降级，全部显式记录，不假装完成。
7. 规则有生命周期：技术选型变更、阶段切换后，核对规则文档中过时的条目立即修正或删除，提交写明原因；规则是写给下一个会话的 AI 看的，别让它照着过时实现写代码。
8. 存证优先：对外产出（复盘/教程/分享/提交说明）中项目相关的描述必须可追溯（git/代码），推测与事实分开标明；找不到来源的改写或删除——文档里的假事实会被下一个会话当真。
9. 状态交接：会话结束记录动态状态（分支、未提交改动、进行中任务、待决策点）到固定位置；下个会话先读状态再动手，不从头摸。
10. 范围确认：主动扩大任务范围前先列出代价并确认；只做被要求的，不顺着惯性多做。

用法：整段放规则文件，或作会话开启时的系统提示词。规则的价值不在字数，在被迭代验证——写的时候只留“删了会出事”的，过时的那天按同样标准删。

最后

和 AI 协作开发，规则文件是把项目经验跨会话传下去的载体。写什么、什么时候清、怎么说给 AI 听——这三件事比规则文件本身更重要。到这里，重做主页的四篇走完了：先想清楚为什么做，再落成技术决策，补齐 SEO 基建，最后让纪律把这些经验带进下一个项目。我希望它们也能帮你少走几趟返工。