让 AI 输出更可靠：界面设计、可视化学习与项目规则

Fri, 23 Oct 2026 02:20:00 +0800

让 AI 做一个页面，第一版能跑，却总觉得哪里不对。让它解释一个原理，文字读起来很顺，合上以后又说不清。给项目写了很多规则，下一次修改仍然会引入另一套组件，或者漏掉关键检查。

最近读到四条分享，分别谈界面间距、用画布学习 Transformer、前端依赖约束，以及如何编写 CLAUDE.md。它们的主题不同，但放在一起，可以得到一个值得实践的方向：先把要求变成具体的关系和约束，再检查实际结果，最后保留有效经验。

这是我对四条内容的综合理解，不是四位作者共同提出的框架。下面先概括原帖，再说明哪些经验可以落地、哪些表述需要修正。

四条分享分别解决什么问题

来源	原帖的主要意思	我会怎样使用
Michael Filipiuk：界面间距	页面让人觉得不协调时，可以先检查 spacing	先检查分组、对齐和留白，再调整装饰
纳米AI：用 Claude Design 学习	用画布把 Transformer 的概念组织成连续的解释步骤	用图建立关系，再用计算和自测检验理解
卡比卡比：前端提示词	复用成熟组件，统一设计语言，限制重复依赖	明确现有技术栈、复用入口和新增依赖条件
Vince：CLAUDE.md 的八条经验	精简规则、明确禁区、按需读取文档，并积累经验	保留稳定约束，把检查接入已有工具

本文依据可读取的原帖正文及 Vince 长文中的代码示例整理；没有把附带视频或画布演示当成经过复现实验的效果证明。文中的提示词和流程是进一步整理的建议。

界面不协调，先看元素之间的关系

Michael 的提醒很适合作为排查入口，但不能把所有视觉问题都归因于间距。文字层级、颜色对比、信息密度和交互逻辑同样可能出问题。

间距容易被忽略，是因为它看起来只是几个 CSS 数值，实际上会影响用户如何理解关系。标签离哪个输入框更近，两个按钮是否属于同一组，哪个区域是主内容，都可以通过距离表达。

假设一个表单中，标签与输入框相隔很远，相邻字段却挤在一起。用户需要额外判断每个标签对应谁。即使按钮、边框和配色都来自成熟组件库，页面仍然可能显得混乱。

我会按三个层次检查：

组件内部：标签与输入框、图标与文字、标题与说明之间是否形成清晰关系。
组件之间：同组内容是否靠近，不同组之间是否有足够区分。
页面整体：容器边距、内容宽度和操作区位置是否一致。

Carbon 等设计系统用 spacing token 管理间距，让组件和页面布局共享一套尺度。值得借鉴的是这种一致性，而不是照搬某个像素数。Carbon spacing 文档

例如，一个新项目可以先试用 4 / 8 / 12 / 16 / 24 / 32 这组候选尺度，再按实际布局调整。已有项目则应优先沿用现有 token。窄屏、长标题和错误提示都可能暴露例外，不能为了数字整齐牺牲可读性。

给 AI 的要求也可以从“做得高级一点”改成：

先阅读现有页面与样式变量，复用当前设计语言。
检查标签和输入框、同组字段、不同分区之间的距离。
相同语义的区域使用一致间距，新增数值需要说明用途。
在窄屏、长文本、空数据和错误提示下检查布局。
完成后说明调整了哪些关系，并给出可以复核的页面结果。

这种要求让视觉反馈更具体。下一轮可以讨论某组字段是否应该靠近，而不是继续追加“更精致”“更有质感”。

画布适合建立理解，还需要一次独立检验

纳米AI 的帖子描述了一次学习尝试：让 Claude Design 把 Transformer 的解释组织到画布上，从 RNN 的瓶颈串到注意力和整体架构。作者提到生成了 21 个步骤，这是个人体验，不能据此保证相同提示总能得到正确或同样完整的结果。

Claude Design 的官方介绍也强调从描述生成视觉初稿，再通过画布进行修改。本文关注的是这种“把解释展开并迭代”的方式，不依赖特定菜单入口或套餐。Claude Design 产品介绍

画图特别适合暴露文字容易掩盖的问题：箭头指向哪里，数据有没有经过某一步，同一个符号前后是否改变含义，概念之间到底是因果关系还是分类关系。

以注意力为例，可以要求画出输入如何得到 Q、K、V，匹配分数经过什么处理，又怎样用于组合 V。但还应要求模型标注维度、说明示意图的简化，并区分原始 Transformer 与后续架构变体。完整图也不能因为篇幅有限就悄悄省掉前馈网络、残差连接等关键部分。Transformer 原论文

一个更适合学习的请求是：

把这个概念画成分步图，标注每一步的输入、输出与关键假设。
先用一个小例子贯穿，不要一开始堆满术语。
数值示例应能手工复算；注明哪些细节被简化。
列出容易混淆的关系，并给出原始论文或官方资料链接。
最后给我三道换一个场景也能回答的问题，先不要展示答案。

真正的验收是：关掉图以后，能否重新解释关系、计算一个小例子，并指出图的适用边界。画面流畅只是帮助理解的条件，不能替代正确性检查。

想继续学习具体架构，可以看已有的神经网络架构图解；学习路线、检验标准和反馈方法则放在自学 Prompt 笔记里。这里不再重复展开完整推导。

指定组件和依赖，是在减少无谓选择

卡比卡比的帖子列举了 shadcn/ui、Lucide、Motion、react-resizable-panels、dnd-kit 和 Zustand 等选项。更值得保留的经验是：同类能力有明确来源，生成页面时就更容易保持一致。

这些名称是原帖中的例子，不是一份所有项目都应安装的清单。已有 Vue 项目不能因为提示词里写了 React 生态组件，就顺手引入另一套技术栈；一个简单表单也没有必要提前装上拖拽和复杂动画依赖。

我更倾向于先问三个问题：项目已经有什么？这次缺少什么？新增以后由谁维护？

需要约束的内容	比较含糊的写法	更容易执行的写法
组件	使用成熟方案	先检查项目现有表单、弹窗和表格封装
视觉	风格统一	复用主题变量、间距尺度及现有图标来源
状态	状态管理合理	共享状态沿用当前方案，局部状态留在组件内
依赖	不要乱装库	新增前说明现有能力缺口和重复依赖情况
验收	页面可以使用	检查提交、失败恢复、权限及窄屏操作

shadcn/ui 强调开放的组件代码与可组合方式，这有利于按项目需要修改。不过，代码进入项目以后，相应的维护和升级也需要有人负责。shadcn/ui 官方介绍

首轮生成得更整齐是有价值的，但一次生成的演示页仍需经过真实数据、交互和构建检查，才能判断是否适合交付。

把稳定约束留下来，让下一次不必重讲

前面几节的要求，如果每次都重新输入，很容易遗漏。Vince 的文章建议把稳定约定放进 CLAUDE.md，精简常驻内容、写清限制、指向详细文档，并把重复错误转化成经验。这些方向值得采用，但有几处需要校正。

200 行是建议，不是 CLAUDE.md 的硬上限。 官方建议文件尽量短，并给出少于 200 行的目标；不要把它理解为第 201 行开始失效。用 @ 导入拆分文件也不会自动减少上下文，因为导入内容仍会展开加载。官方指令文件说明

规则文件可以指路，但要说清触发条件。 仅列出十几个文档路径，仍然要靠模型猜测何时读取。写成“修改回调处理前，先读异步协议和重复事件测试”，更接近实际工作。

Hook 不会因为写进 Markdown 就自动生效。 原文的 .claude/hooks/pre-tool-use.json 示例不能直接当作标准项目配置使用。项目级 Hook 通常注册在 .claude/settings.json；编辑后的格式化应匹配 PostToolUse。文件路径应从实际事件输入获取，不能假定存在 ${CLAUDE_FILES}。只匹配 Edit|Write 也覆盖不了 Bash 写文件。官方 Hook 参考

因此，规则、Hook、测试和 CI 要分别承担自己的职责。已有项目如果配置了提交检查和构建验证，应优先接入这些入口，而不是再建立一套没人维护的脚本。

对 AGENTS.md 或 CLAUDE.md，我会采用下面的内容分配；具体文件的加载方式仍需按所用工具确认：

放在哪里	放什么	避免什么
根规则文件	项目定位、关键边界、文档读取条件、验证入口	大段历史、重复规则和任务流水账
模块说明	局部接口、状态约束、已知陷阱	把所有调用方都应知道的红线藏在深层目录
专题文档	当前设计、协议、迁移范围和决策依据	混淆已实现能力与未来草案
任务记录	当前进度、未验证假设、阻塞原因	把一次推测提升为长期规则
自动检查	格式、静态检查、行为测试和构建	把“测试执行过”误认为“所有风险已覆盖”

长期记忆的分类与维护已经在Magpie 自动维护流程中讨论。这里沿用同一个原则：经验需要来源和适用范围，也需要纠正与删除；没有必要仅为了“记忆”再造一个与现有文档重复的事实源。

一份小型项目约定可以怎样写

下面是根据上述讨论整理的模板，路径和命令都是示例，使用前应替换为仓库真实入口。它适合帮助确定内容结构，不是可以直接安装的工具配置。

# 项目协作约定

## 开始任务
- 先阅读目标实现、直接调用方、相关测试与配置。
- 复用已有组件、依赖和模块边界；不顺手重构无关部分。
- 缺失信息影响正确性时说明；低风险且可逆的选择可合理假设。

## 按任务读取
- 修改界面：先读 docs/ui.md，查看相似页面和主题变量。
- 修改 API：先读 docs/api.md，核对调用方和兼容行为。
- 修改异步流程：先读 docs/async.md，核对重复、超时和取消语义。
- 文档若标为草案，不把目标设计当成当前事实。

## 界面与依赖
- 同类组件沿用现有实现，相同语义使用一致间距。
- 新增依赖前说明缺口，检查是否已有相同能力。
- 检查窄屏、长文本、空数据、加载和失败状态。

## 验证与交付
- 运行本次行为对应的测试，以及受影响的静态检查和构建。
- 用实际命令替换这里的验证描述，并记录结果。
- 区分已验证、未验证和环境阻塞，不把推测写成结论。
- 反复出现且已确认的问题，更新对应规则或自动检查。

不用一次把所有规定写齐。先选择一个经常返工的页面或模块，把最常见的两三个问题改写成可以检查的规则，然后观察下一次任务是否减少了同类错误。

从一轮具体修改开始

假设要给现有后台增加一个查询页，我会这样组织一次任务：

读取相似页面、组件封装、API 和主题变量，确定可以复用的部分。
用简图列出筛选、结果、详情和错误状态，先确认信息关系。
沿用现有组件和依赖，调整布局中的分组、间距与操作层级。
用长文本、空结果、请求失败和窄屏检查页面，再运行对应测试与构建。
只把这次验证过、未来仍有价值的约束写回项目文档。

这轮工作的完成标准应落在结果上：页面是否清楚、解释是否能复算、代码是否遵守项目契约、检查是否真正执行。四条分享提供了不同入口，最终都需要回到这些可以观察的证据。

工程实践 on Ricardo