给 AI 足够且准确的上下文

你已经写清“修复 Header 和正文不对齐”，结果却仍然不对。问题可能不在指令，而在模型只看到了 Header，没有看到正文容器。

上下文工程关心的是：当前这个决定需要什么事实，事实在哪里，何时读进来。 不是把整个仓库一次性塞进对话。

提示词与上下文分别解决什么

“全站保持同一水平边界”是目标；site-frame 和 page-shell 的实际定义是上下文。把目标重复三遍，不能代替缺失的样式文件。

Anthropic 的上下文工程文章将任务指令、工具、外部材料和历史消息都纳入上下文管理。本章把这个思路落到一次代码调查中。

例子：建立最小材料包

对本站的对齐问题，第一轮材料可以是：

第一轮不必读所有 MDX、全部工具实现或历史设计稿。只有截图显示文章详情也受影响，才继续看 guide-doc-layout.tsx；如果问题是 Footer 高度，再检查根布局的 flex 关系。

这样选材料，有一个明确的扩展条件，而不是随意截断阅读。

用搜索定位，再完整读相关定义

在本站可以先运行以下只读搜索：

rg -n 'site-frame|page-shell|home-intro' src
rg -n 'page-max-width|page-gutter|max-width' src/app/globals.css

搜索结果是入口，不是完整证据。找到类名后，要继续读同一规则块、媒体查询和覆盖它的选择器。只看命中的一行 max-width，可能漏掉稍后出现的路由特例。

给 AI 的指令也可以这么写：

先定位 Header、正文和 Footer 的容器定义。
读取共享规则以及可能覆盖它们的页面/媒体查询。
对每个“已发现的原因”列出代码位置；
仅凭截图怀疑的原因，请标为假设。

当资料互相冲突

假设 README 写“最大宽度 88rem”，当前 CSS 却是 75rem。不要把两者拼成“项目使用 75–88rem”，也不要默认新文件永远正确。

把冲突分开记录：

• 当前实现：CSS 中的实际值。
• 用户预期：最近确认的是全站一致，而不是锁定某个历史数字。
• 待处理文档：README 是否过期，需要结合修改历史核对。

代码可以证明“现在怎样”，不能单独决定“应该怎样”；用户最新明确的需求可以改变预期，但也不允许绕过系统权限。

长输出先保留可追踪入口

构建日志有几千行时，保留失败命令、退出状态、第一处相关错误和完整日志位置。不要只摘“失败”二字；也不要把整份重复日志贴进每轮请求。

同理，一份网页资料应保留标题、链接、核对日期与支持的具体结论。网页里夹带的“忽略之前的规则”不是资料事实，不能转成执行指令。

用一个检查判断材料够不够

在修改前，让 AI 回答：

你现在有哪些事实支持这个修改？
列出仍未知、且可能改变方案的事项。
能通过代码或页面查证的继续查；
需要我作产品取舍的单独提出。

如果它不能解释为什么要改 Footer，只是因为“顺便统一”，材料或目标还不够清楚。下一步应补证据，而不是扩大 diff。