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

从最开始的文件和目录对比，到后来的 SHA-256 校验、左右同步、双击编辑、扁平化 UI、目录折叠、一键刷新，再到刚完成的过滤和排除规则，工具的功能一直在增加。

表面上看，项目进展很快。每次发现一个问题，给大模型一句提示词，很快就能看到新的界面和代码。

但做到第 4 期后，我开始意识到一个问题：这个项目一直在解决眼前问题，却没有一份真正的开发计划。

我知道还有文本差异算法、编码识别、扫描性能、同步安全和发布打包需要优化，但它们只是散落在每篇文章结尾的“下一步计划”里。哪个先做、做到什么程度、如何验收、会不会影响现有功能，都没有系统整理。

所以第 5 期没有马上继续写代码，而是先停下来，补一份开发计划。

为什么做到一半才想起做计划

原因其实很简单：前期没有规划好。

刚开始做这个工具时，目标只有一句话：市面上好用的文件对比工具很多要收费，现在有了大模型，能不能直接手搓一个自己用？

当时最重要的是让它先跑起来。因此需求也非常直接：

• 支持选择文件或目录。
• 使用文件 Hash 对比内容。
• 支持左右同步。
• 双击文件可以编辑。

第一版完成后，我就开始根据实际使用截图继续修改。按钮显示三个点，就修按钮宽度；顶部控件太占空间，就重新布局；文件太多，就增加目录折叠；目录变化不能更新，就增加刷新；无效文件太多，就增加过滤规则。

这些修改都是真实需求，也确实让工具越来越好用。但问题在于，开发顺序完全由最近一次使用中最显眼的问题决定。

今天看到 UI 不顺手，就改 UI；明天发现目录太长，就改目录树；后天发现 .git 扫描太慢，就做过滤。每个问题都解决了，但项目始终没有形成清晰的主线。

没有计划会带来什么问题

1. 最新问题总会抢走最高优先级

没有优先级时，哪个问题刚刚出现在截图里，哪个问题就最紧急。

这会导致一些容易看见、容易修改的问题不断被解决，而真正影响核心体验的问题反而被推迟。

当前最明显的例子就是文本内容对比。编辑器已经有行号、红色高亮、左右滚动和复制按钮，但差异判断仍然主要按相同行号进行。文件中间插入一行后，后面的内容可能全部标红。

这个问题在第 2 期就已经写进“下一步计划”，到第 4 期仍然没有真正开始。

2. 功能增加了，架构不一定跟得上

大模型很擅长在现有代码上快速增加一个按钮、一个弹窗或一个判断条件。

但如果每次只围绕当前功能追加代码，项目很容易变成“哪里需要就在哪里加一点”。等到要改核心能力时，才发现 UI、数据模型和操作逻辑已经绑在一起。

例如下一步要实现“每一处差异直接向左或向右”，就不能只在中间再加几个按钮。它需要先有可靠的差异块模型，知道哪几行属于同一个新增、删除或修改块，再把箭头与对应差异位置绑定。

这已经不是简单的 UI 修改，而是编辑器核心模型的升级。

3. 做完了也不知道算不算完成

没有验收标准时，“支持差异复制”可以有很多解释。

当前版本也可以复制差异：先选中文本，再点击固定的 → 或 ←。从功能清单看，这一项已经完成；但从真实体验看，它并不顺手，而且用户必须自己判断左右应该选择哪些文本。

如果需求只写“优化差异复制”，大模型很可能只是换按钮位置或增加快捷键。只有提前写清楚验收标准，才能判断功能是否真正达到目标。

为什么现在是补计划的合适时机

计划并不是越早写越好。

第一版还没有运行时，我其实不知道自己最常用的流程，也很难预判 Swing 界面会出现哪些具体问题。过早写一份很完整的计划，可能只是凭空想象。

现在工具已经连续使用和修改了四轮，基础能力已经相对稳定：

• 文件和目录可以正常对比。
• 目录树、刷新、过滤和同步流程已经形成。
• 编辑器的主要问题已经通过实际操作暴露出来。
• 后续需求不再只是零散想法，而是能按照影响范围分组。

这时候补计划，不是为了让项目看起来更正式，而是为了避免继续被问题推着走。

我给大模型的提示词

这次提示词非常直接：

形成一个计划文档，之后按照计划开发吧。

在计划文档中加一个：对比实际文件时，在每个不同地方增加向左、向右，而不是选中之后再向左、向右同步。

这里不再要求大模型马上实现功能，而是先把需求放回整个项目里，判断它应该排在什么位置、会影响哪些模块、怎样验收。

大模型分析当前代码后，把这个需求放到了 P0 第一优先级。

P0：每处差异直接向左或向右

当前编辑器的效果如下：

中间有四个固定按钮：复制选中内容到右侧、复制选中内容到左侧、全部覆盖右侧、全部覆盖左侧。

问题是局部操作必须先选择文字。用户需要自己完成三件事：

1. 判断哪些行属于同一处差异。
2. 在来源侧准确选择内容。
3. 再点击正确方向的按钮。

新的目标是让程序先识别连续差异块，然后在每一处差异旁直接显示一组 ←、→：

• →：让右侧当前差异块与左侧一致。
• ←：让左侧当前差异块与右侧一致。

不再要求用户选择文本。

三种差异必须有统一语义

计划中专门明确了三类情况：

差异类型	点击 →	点击 ←
左右都有内容但不同	用左侧块替换右侧块	用右侧块替换左侧块
只有左侧有内容	向右侧插入左侧块	删除左侧块
只有右侧有内容	删除右侧块	向左侧插入右侧块

这个定义很重要。

如果右侧是空的，点击 ← 实际不是“复制”，而是删除左侧内容，使左侧与右侧保持一致。计划要求这类按钮必须使用明确的悬浮提示，多行删除时还要增加确认，避免方向看懂了，结果却理解错了。

不只是增加箭头按钮

为了实现每处差异操作，计划拆出了几个独立职责：

• DiffEngine：输入左右文本，计算有序差异块。
• DiffHunk：记录差异类型和左右起止行。
• HunkApplyService：把指定差异应用到左侧或右侧。
• DiffEditorModel：维护文本、差异列表和修改状态。
• DiffActionRail：在每个可见差异旁绘制操作按钮。

同时还需要增加上一个差异、下一个差异、当前序号和剩余差异数量。

点击某个箭头后，程序只修改对应差异块，重新计算差异，把视图保持在原位置附近，并允许使用 Ctrl+Z 撤销。只有点击保存后才真正写入磁盘。

这就是计划带来的第一个变化：需求不再停留在“加两个箭头”，而是被拆成数据模型、交互、风险和验收标准。

P0 到 P3：终于有了清晰方向

完整路线被分成四个优先级：

P0：差异块级双向操作

这是下一阶段唯一优先处理的核心功能。先解决文本差异不准确、局部复制依赖手动选择的问题。

P1：编码保真与同步安全

文本编辑器需要识别 UTF-8、GBK、UTF-16 等常见编码，保存时保持原编码和换行方式。

同步前增加变更预览，明确哪些文件会新增或覆盖，并考虑备份和失败恢复。

P2：扫描性能与规则预设

增加扫描进度、取消按钮、受控并行 Hash 和增量结果展示。

把刚完成的过滤规则保存下来，并提供 Java、前端和通用项目预设。

P3：设置保存与发布

保存窗口尺寸、最近路径和用户偏好，增加版本信息，并制作不依赖开发环境的运行包。

现在再问“下一步应该做什么”，答案不再取决于今天又发现了哪个小问题，而是先完成 P0，再进入 P1。

计划最有用的不是任务列表

很多开发计划最后会变成一张永远不更新的功能清单。

这次我更看重的是计划里固定下来的开发节奏：

UI 方案 → 确认交互 → 正式实现 → 自动测试 → 运行验证 → 更新文档

前几次 UI 修改已经证明，直接改代码的返工成本很高。先看效果图，可以提前发现按钮位置、空间占用和交互语义问题。

因此从 P0 开始，每个阶段都必须先出 UI 方案；确认后再实现；完成后不仅要编译通过，还要有自动测试、真实窗口检查和文档更新。

只有同时满足这些条件，计划中的状态才能从“待开发”改成“已完成”。

大模型为什么更需要开发计划

大模型的优势是执行速度快。需求足够明确时，它可以很快阅读代码、提出方案、修改文件、编译和测试。

但速度快也有一个问题：方向不清楚时，它同样会很快地把项目带向一个并不重要的目标。

每次对话里的最新要求天然拥有最高权重。如果没有项目级计划，大模型会认真完成眼前任务，却不会自动替你判断这是不是当前最值得做的事情。

开发计划相当于给协作增加了一层长期上下文：

• 当前版本已经有什么。
• 哪些问题是真正的核心问题。
• 下一阶段只解决什么。
• 哪些内容明确暂时不做。
• 怎样才算完成。
• 完成后应该更新哪些文档和测试。

这样给大模型的提示词可以更短，但方向反而更稳定。

例如计划完成后，我只问了一句：

按照开发计划，目前应该完善什么功能？

答案非常明确：先完成 P0 差异块级双向操作，不先去做编码、打包或新的过滤选项。

一份可复用的最终提示词

如果你也在用大模型边做边改一个项目，可以直接使用下面这份提示词整理开发计划：

请阅读当前项目代码、README、已有测试和历史开发记录，整理一份独立的后续开发计划。

要求：

1. 先总结当前已经完成的功能和真实存在的不足，不要只根据最初需求推测。
2. 把零散的 TODO 和文章中的“下一步计划”合并，删除重复项。
3. 按 P0、P1、P2、P3 排优先级，每个阶段只保留边界清楚的目标。
4. P0 必须解决当前最影响核心使用流程的问题，不能优先做包装性功能。
5. 对每个阶段写清目标、交互、数据模型、技术方案、风险、测试和验收标准。
6. 明确哪些操作会覆盖、插入或删除内容，并说明撤销和未保存处理。
7. 固定开发流程：先出 UI 方案图，确认后实现，再执行自动测试、运行验证和文档更新。
8. 保留当前技术兼容要求；引入第三方依赖时检查运行环境、许可证和离线发布方式。
9. 为核心功能列出边界测试，包括空文件、文件开头结尾、重复内容、编码和换行符。
10. 生成 Markdown 计划文档，并在 README 中增加入口。

本项目还需要加入以下高优先级需求：
文件内容对比时，每一处连续差异旁直接显示向左、向右按钮，让用户无需选择文本
即可把当前差异块应用到另一侧。必须覆盖修改、仅左侧、仅右侧三种情况，并明确
插入、替换和删除语义。

本次只制定计划，不修改正式业务代码。计划确认后再按优先级逐项开发。

下一步

计划已经明确，接下来不再继续增加零散功能。

第一步是为 P0 文件编辑器制作 UI 效果图，重点确认：

• 每处差异的 ←、→ 放在哪里。
• 仅单侧有内容时，删除操作怎样提示。
• 多个差异块滚动后，按钮怎样跟随。
• 最小窗口下按钮、文本和行号是否重叠。
• 全文件覆盖按钮移动到哪里。

UI 确认后，再引入可靠的行差异算法，建立 DiffHunk 模型，最后实现差异块级双向操作。

最后

前期没有规划好，并不代表前面做的事情没有价值。

如果没有前四轮真实使用，我也很难一开始就知道目录折叠、刷新、过滤和差异块操作哪个更重要。问题不在于第一天没有写一份完整路线图，而在于项目已经跨过原型阶段后，仍然只靠临时反馈继续前进。

现在补计划，是因为工具已经从“能不能做出来”进入了“怎样才能真正好用”的阶段。

大模型可以让实现速度变快，但速度不能代替方向。前四期我更多是在学会怎样让它完成一次修改；从这一期开始，我需要先决定项目要去哪里，再让它按计划把每一步做好。

计划当然还会调整，但至少下一次打开代码时，我不会再从最新的一张截图开始猜今天该做什么。