前一篇文章里，我用 Java Swing 和大模型手搓了一个文件对比工具。

它已经能完成目录对比、文件对比、SHA-256 内容校验、左右同步、双击编辑和差异复制。站在“功能是否完成”的角度看，这个工具已经能跑了。

但真正用起来以后，问题马上暴露出来：功能是有了，操作却不够顺手。

顶部控件占了很大一块空间，目录和文件模式切换像一排默认表单；左右路径上下堆叠，文件列表反而被压缩；编辑窗口里的复制按钮甚至因为宽度不足显示成三个点。很多信息虽然写得很完整，但用户看一眼就知道的内容，仍然被重复展示。

于是今天的任务不再是“继续加功能”，而是把这个能用的原型，往真正好用的工具推进一步。

为什么还要专门优化 UI

很多人做内部工具时会有一个想法：反正只有自己用，界面差不多就行。

但文件对比是一种高频扫描型操作。用户要在很短时间里完成几个动作：选择两侧路径、发现红色差异、定位文件、决定同步方向，然后进入内容编辑。如果界面里每一步都多占一点空间、多放一个按钮、多出现一行重复标题，连续使用时就会明显拖慢节奏。

第一版正式界面如下：

这版主要有几个问题：

• “目录对比、文件对比、开始对比”长期占据顶部空间。
• 左右路径采用上下两行布局，与下面的左右双栏结构不一致。
• “左侧路径、右侧路径、左侧文件、右侧文件”等文字存在重复表达。
• 底部同步区高度和按钮字号偏大，进一步压缩列表空间。
• Swing 系统默认控件的立体感较强，视觉层级不统一。

这次优化给自己定了一个原则：凡是位置关系已经能表达的信息，就尽量不再用文字重复解释；凡是可以自动完成的动作，就不再要求用户多点一次。

第一轮：先确定扁平化方向

第一条提示词没有直接要求修改代码，而是先让大模型给方案：

UI 页面优化一下，要求是扁平风格。你先给我出一个方案，我确认后再修改。

这一步很重要。界面改造涉及布局、颜色、字体、控件尺寸和交互位置，如果直接让模型改代码，最终发现方向不对，返工成本会很高。

确定方向后，我继续要求：

你给我对应图片效果图，我看一下。

于是先生成了主界面和双文件编辑器的静态效果图，用来确认布局，而不是马上动正式程序。

第一轮主要确定了这些基础规则：

• 页面使用浅灰背景和白色内容区。
• 蓝色只用于主要操作，绿色表示相同，红色表示不同或缺失。
• 表格改用浅色状态背景，避免大面积高饱和颜色。
• 按钮、边框、字体和行高统一。
• 编辑窗口增加行号、未保存状态和更清楚的复制方向。

方向确认后，才让模型开始修改正式 Swing 代码。

第二轮：效果图好看，落地仍然会出问题

静态效果图没有布局计算问题，但真正运行 Swing 后，中间四个复制按钮全部显示成了三个点。

这一轮提示词很短：

这里复制到左边、复制到右边都是三个点。

问题不在复制逻辑，而在按钮宽度。中间操作栏设置得太窄，再叠加按钮边框和左右内边距，箭头文本可用空间不够，Swing 就自动显示省略号。

最终处理方式是：

• 加宽中间复制操作栏。
• 增加按钮最小宽度。
• 缩小按钮左右内边距。
• 使用兼容性更好的 →、←、>>、<<。
• 为四个按钮增加悬浮提示，解释“复制选中内容”和“复制全部内容”。

这也是大模型协作开发里很真实的一点：生成代码不等于工作结束，最终效果必须运行后检查。很多 UI 问题只有在真实字体、真实窗口尺寸和真实数据里才会出现。

第三轮：首次进入不应该直接看到一堆表单

主界面扁平化后，顶部仍然像一个配置表单。目录对比和文件对比是两个入口，不应该一直占用工作区。

这一轮提示词是：

这里是不是可以放在菜单，然后首次进来放一个大图标，例如选择比较文件还是比较文件夹？

参考的是常见对比工具的启动方式：首次进入先选择任务类型，进入任务后再展示具体工作区。

正式实现时使用了 Swing 的 CardLayout：

• 首页只显示“文件夹对比”和“文件对比”两个大图标。
• 点击入口后切换到左右双栏工作区。
• 顶部“文件”菜单也可以新建两种对比任务。
• 菜单中增加“返回首页、退出、查看日志、关于”。

这样既保留了功能入口，也让首次打开软件时更加干净。

第四轮：左右布局，就应该从路径选择开始

进入工作区后，左右文件列表已经是双栏，但路径选择仍然是上下两行。视觉结构前后不一致，也浪费了不少垂直空间。

于是继续给出参考图，并提出：

文件夹或者文件选择弄成这种风格吧，要不两个叠到一起占用很大空间。先给我出一个效果图。

新的思路是把左侧路径放到左侧文件列表顶部，把右侧路径放到右侧文件列表顶部。路径和结果从一开始就是左右对应关系。

第五轮：能自动完成的，不再让用户多点一次

第一张紧凑布局效果图出来后，我又直接在图上标注问题：

对应的提示词是：

标号 1 的去掉，在两边选择完成之后自动触发对比操作；标号 2 的间距以及字体小一点，腾出更多空间。

这里做了两个关键改变。

第一个改变是删除“开始对比”按钮。当左侧和右侧路径都选择完成后，程序自动执行 Hash 对比。对用户来说，选择第二个路径本身就已经表达了“我要开始对比”，没有必要再点一次按钮。

第二个改变是压缩底部状态栏。同步按钮高度、字号和间距全部缩小，日志入口移动到菜单，文件列表得到更多垂直空间。

第六轮：能从位置看懂，就不要再写一遍

紧凑版已经省出了空间，但还有“左侧目录、右侧目录、左侧文件、右侧文件”等标题。它们并没有提供新的信息，因为左右位置本身已经说明了一切。

最后一轮反馈非常直接：

蓝色没必要存在吧，都知道是什么意思。红色的再美化一下，感觉太丑了。

最终继续做减法：

• 删除左侧目录和右侧目录标签。
• 删除左侧文件和右侧文件标题。
• 保留“状态、文件路径、大小”三个必要表头。
• 把路径图标、路径文本和选择按钮合并成一个完整控件。
• 路径框使用浅灰背景、细边框和内嵌分隔线。
• 左右路径选择完成后自动开始对比。

最终确认稿如下：

和最初版本相比，文件列表明显向上扩展。用户进入工作区后只需要做两件事：选择左侧路径，再选择右侧路径。第二个路径选完，对比结果自动出现。

今天实际修改了哪些内容

这次不是简单换一套颜色，而是同时调整了界面结构和操作流程。

1. 主界面结构

• 使用 CardLayout 区分模式首页和文件对比工作区。
• 文件夹对比、文件对比移动到首页大图标和“文件”菜单。
• 工作区删除模式切换控件和开始按钮。
• 左右路径选择分别嵌入对应文件列表顶部。

2. 对比流程

• 第一个路径选择后等待另一侧路径。
• 第二个路径选择完成后自动调用对比逻辑。
• 重新选择任意一侧路径时，如果另一侧路径存在，则自动重新对比。
• 对比过程中禁用路径输入、选择按钮和同步按钮，避免重复触发。
• 没有对比结果时，同步按钮保持禁用。

3. 结果列表

• 相同文件继续使用浅绿色。
• 不同和缺失文件使用浅红色。
• 状态列增加绿色或红色左侧线条。
• 缺失文件也显示相对路径，不再出现空白行。
• 文件大小统一显示为 B、KB 或 MB。
• 左右列表保持滚动联动和选中行联动。

4. 内容编辑器

• 增加行号和等宽字体。
• 增加联动滚动开关。
• 中间复制按钮改成固定尺寸图标按钮。
• 支持选中内容和全部内容双向复制。
• 左右文件可以单独保存，也可以全部保存。
• 文件修改后显示“已修改”，关闭和重新加载前检查未保存内容。

5. 技术约束

• 继续兼容 Java 8。
• 继续只依赖 JDK 和 Swing。
• SHA-256 对比、目录递归、同步复制等业务逻辑保持不变。
• 每一轮修改后都重新编译并启动程序检查实际效果。

今天的提示词复盘

今天的提示词并不复杂，大部分甚至只有一句话。真正有用的是每次只指出一个明确问题，并配上截图或标注。

这几类提示尤其有效：

1. 先限定流程：先出方案，再出效果图，确认后才改代码。
2. 指出具体位置：直接在截图上圈出需要删除或压缩的区域。
3. 说明真实原因：不是笼统说“不好看”，而是说明“两个路径上下叠放太占空间”。
4. 给出交互判断：两边选择完成后自动对比，不再保留多余按钮。
5. 运行后继续反馈：按钮显示三个点，就针对真实运行结果修复。

如果想一次性让大模型完成类似改造，可以直接使用下面这份最终版提示词：

请优化一个 Java 8 Swing 文件对比工具的 UI，保持现有 SHA-256 对比、
目录递归、双向同步和内容编辑逻辑不变，不引入第三方依赖。

要求：

1. 整体采用浅色扁平风格，统一字体、颜色、边框、按钮和表格行高。
2. 首次启动使用 CardLayout 显示模式首页，只保留“文件夹对比”和
   “文件对比”两个大图标入口。
3. 在顶部菜单中提供新建文件夹对比、新建文件对比、返回首页、
   查看日志、关于和退出。
4. 进入工作区后左右双栏显示，不再展示模式切换和“开始对比”按钮。
5. 左右路径选择框分别内嵌到左右文件列表顶部。
6. 路径选择框由文件夹图标、路径文本和右侧选择按钮组成，视觉上是
   一个完整控件，不显示“左侧目录、右侧目录”等重复标签。
7. 左右路径都选择完成后自动触发对比；重新选择任意一侧后自动重新对比。
8. 相同文件使用浅绿色，不同或缺失文件使用浅红色，状态列增加颜色标记。
9. 缺失文件仍显示相对路径，文件大小格式化为 B、KB、MB。
10. 左右结果列表滚动和选择联动，双击打开内容对比编辑器。
11. 编辑器显示行号、差异高亮和联动滚动开关。
12. 编辑器中间使用固定尺寸的方向按钮，支持复制选中内容和复制全部内容，
    按钮不能因为宽度不足显示省略号。
13. 支持保存左侧、保存右侧和全部保存，并提示未保存修改。
14. 压缩底部同步区的高度、字体和间距，把更多空间留给文件列表。
15. 修改前先给出效果图，确认后再修改代码；完成后使用 Java 8 编译并运行验证。

下一步计划

这轮主要解决的是信息层级和空间利用率，但距离专业文件对比工具还有明显差距。下一步准备继续处理下面几个问题。

1. 改进文本差异算法

目前主要按同一行号比较。文件插入一行后，后面的内容可能全部被标记为不同。后续需要引入更合理的行对齐算法，让新增、删除和修改能够准确对应。

2. 解决文本编码问题

当前编辑器默认按 UTF-8 读取。实际项目中可能遇到 GBK、GB2312 或其他编码，截图里已经出现了部分中文注释乱码。下一步要增加编码识别和手动切换编码，保存时保持原编码。

3. 增加过滤规则

目录中经常包含 .git、node_modules、构建产物、日志和临时文件。后续准备支持按目录、扩展名和通配符排除文件，减少无效 Hash 计算。

4. 提升大目录性能

大目录需要增加扫描进度、取消按钮、并行 Hash 和结果增量展示，避免用户长时间只能等待。

5. 提高同步安全性

同步前增加变更预览，明确列出将覆盖和新增的文件；必要时增加目标文件备份和撤销能力，降低误覆盖风险。

6. 完善发布体验

后续会保存窗口尺寸、最近路径和用户设置，并考虑打包成可直接运行的安装包，避免每次通过批处理脚本启动。

最后

今天这轮优化让我感受最明显的一点是：大模型很适合快速实现功能，但“好不好用”仍然需要人在真实操作中不断判断。

一句提示词可以生成一个界面，却很难一次生成最适合自己的工作流。更有效的方式是先跑起来，再截图、标注、指出具体问题，让模型一轮只解决一个矛盾。

从默认 Swing 控件，到扁平化双栏，再到首页入口、路径内嵌、自动对比和删除重复标签，这个工具的功能没有发生巨大变化，但操作路径明显缩短了。

目前的使用体验依然算不上专业，文本差异、编码处理和同步安全还有不少粗糙之处。后面我会继续优化，把它从“功能齐全”慢慢打磨到“真正顺手”。