把一次返工变成可复用经验

一个案例值得保存，不是因为过程很长，而是它能让下次遇到同类问题时少走一步弯路。保留“为什么第一次没做对”，通常比保存完整聊天更有用。

用本站的对齐问题写一张案例卡

以下内容来自本站调整过程的整理；它不是完整操作日志：

# Header 一致，仍不等于页面一致
 
触发条件
用户要求切换首页、笔记和工具时 Header 不变。
 
第一次验收遗漏
只比较不同路由的 Header，没有比较 Header 与正文边界。
 
后续反馈
笔记、工具的正文仍与 Header 错位；首页 Footer 也不一致。
 
修正判断
水平布局：公共组件与页面外容器共享宽度和横向留白。
垂直布局：检查根布局与首页特例，而不是继续调整 Footer 偏移。
 
代码入口
globals.css 的共享容器；layout.tsx 的主内容 flex 布局。
 
仍需区分
文章内部阅读列可以更窄。
长页面与短页面的 Footer 不要求固定在同一 y 坐标。
 
可复用结论
公共布局改动必须跨消费者检查，不能只验证被截图的组件。

相比“以后要整体考虑设计”，这张卡明确了错误发生在哪个验收关系上，也保留了反例，避免结论被滥用。

事实、假设与经验不要混写

“CSS 中存在两套容器宽度”需要代码支持；“用户觉得不协调是因为这两套宽度”还需要页面观察；“以后优先共享外容器规则”则是从案例得出的工程建议。

如果没有保存改前截图或命令结果，就直接写缺口。不能凭记忆补一个“性能提升 30%”或“测试全部通过”，让案例看起来更完整。

沉淀到哪里，取决于下一次怎么用

想避免的重复问题	合适的产物
每次都忘记项目特殊约定	一条短项目规则，指向权威位置
某个确定性条件反复回归	测试或构建校验
同类任务每次都要做相同调查	可复用 Skill
只是当前版本的偶发环境错误	任务记录，暂不升级为规则
涉及权限或数据损失	实际权限限制与审批流程，不只写经验

不要机械规定“发生三次才能写 Skill”。高损失且清楚可测的错误，第一次就值得加检查；偶发的、还没看清原因的问题，出现多次也不适合立即固化流程。

保留一个“不要照用”的例子

“所有页面共享外容器”不应变成“所有页面内部排版完全相同”。笔记有目录和正文，工具有分类与卡片；内部结构不同是有意义的。

因此，一条方法最好同时有：

正例：导航、正文外框和 Footer 的水平边界。
反例：正文阅读列、弹窗或单个工具卡片。
失效条件：设计明确要求某个页面使用全宽布局时，需要重新评估。

这能帮助未来的你判断适用范围，而不是照抄旧方案。

让记录保持可用

完成一次返工后，先写短卡片；定期只整理那些仍会影响决策的条目。相同主题合并到一个权威位置，已失效的标注被哪次决定替代。

案例可以直接放在对应知识文章中，不需要为了每次经历新建一个独立栏目。读者在学习“怎样验证”时看到相应案例，比先浏览一大份流水账更容易用起来。