使用 AI 编码助手时，开发者可能遇到一种细碎返工：功能基本正确，界面却多出解释性文案；修复缺陷时，AI 又容易给出临时补丁。掘金上的一篇文章把这两类问题概括为“AI 写页面像说明书，修 Bug 像贴膏药”，并提出通过 AGENTS.md 给编码 Agent 设定项目规则。文章引用了 X 用户 @luinlee 分享的两条英文提示词，建议写入项目上下文，约束 AI 的界面生成和问题修复方式。
页面不是说明书：让布局承担解释
文章提到的第一类问题，是 AI 会把开发说明、校验逻辑和交互提示直接写成用户可见文案。例如邮箱输入框下写“请在此输入您的邮箱地址”，保存按钮旁写“点击后将保存当前信息”。这些文案单独看没有明显语病，但与标题、字段名、按钮文字重复，会让页面显得啰嗦。
对应规则是：“Avoid unnecessary secondary labels and descriptions. Let the layout do the explaining.” 中文可译为：“避免不必要的次级标签和描述，让布局本身解释界面。”重点在“不必要”。在个人资料表单示例中，AI 可能围绕昵称、邮箱和保存按钮补充一圈解释；删减后，应先保留核心控件，再检查是否缺少必要信息。
文章给出的判断标准是：这句话能帮助用户做决定、避免出错，还是只在重复眼前的控件？如果昵称只能填 2～20 个字符，输入前应让用户知道；邮箱格式错误时，报错要告诉用户如何修改；涉及费用、公开范围、不可撤销操作的信息，也不能为了简洁而藏起来。
- 不要只留 placeholder，字段标签、必要控件名称和可访问名称仍需保留。
- 如果表单必须靠大段文字说明，优先检查字段分组、按钮名称、间距和信息层级。
作者提醒，文中案例是为解释规则设计的示例，实际效果仍需在项目中验证。
修 Bug 要找根因：避免用补丁遮住症状
第二类问题出现在 AI 修 Bug 时。文章引用的另一句规则是：“Fix a bug at its cause, reasoning from first principles and established best practice. Do not patch over the symptom.” 意思是：“结合第一性原理和成熟实践，从根因修复 Bug，避免只遮住表面症状。”
作者举例：点击保存后，列表偶尔还显示旧昵称。AI 可能先加一个 500 毫秒延时，再刷新列表。表面看问题缓解，但为什么是 500 毫秒、网络慢时是否有效，并没有解释。文章给出的一个假设是，saveProfile 没有返回请求的 Promise，外层 await 没有等到保存完成。此时修复点应落在异步调用链上，让函数返回请求，并在保存成功后再刷新列表。
真实项目也可能存在其他原因：缓存没有失效、旧请求覆盖新请求，或者后端数据存在可见性延迟。文章强调，要先找到证据，再选择对应修复，不能看到“不更新”就认定某一原因。所谓“第一性原理”，可以落到具体问题：数据保存在哪里？谁在等待它？列表读取的是什么数据？哪一步偏离了预期？
这条规则也不等同于大规模重构。根因修复有时只有一行改动，但好的修复应让原来的失败场景通过，并能说明为什么有效。
AGENTS.md：把反复提醒沉淀为项目规则
AGENTS.md 用来给编码 Agent 提供项目上下文和工作约定。文章建议，如果项目已有该文件，可以把两条规则合并进去，并按工具支持方式确认其如何读取。规则可按“界面文案”和“Bug 修复”两个小节写入，直接附上英文原文。
这种做法的价值，在于把开发者反复提醒的话变成项目自身的约定。写入规则文件后，这些要求有机会成为 Agent 默认读取的上下文。文章也指出，写进文件并不代表每次都会执行到位。开发者仍可以要求 AI 修改页面时检查“哪些说明在重复控件”，修复 Bug 时交代“问题在哪产生，改动为什么有效”。
对 AI 编程落地而言，这类细节反映出工具使用方式正在从单条提示词转向项目内规则。编码助手能否进入真实开发流程，不只看它能否生成代码，也要看它是否能遵守界面规范、工程习惯和团队约定。两条短规则本身很小，但它们把“提醒模型”的工作前移到了项目配置中。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/gei-ai-bian-ma-zhu-shou-li-gui-ju-yong-agents-md-guan-zhu
