与LLM结对编程：测试先行如何提升AI辅助开发质量

与 LLM 结对编程：测试先行如何提升 AI 辅助开发质量

一、测试先行：在生成代码之前先对齐知识

用同一个命令行参数解析器需求，按照测试驱动的方式重做一遍，与直接让 LLM 生成代码的方式形成对比。

关键差别在于起点：这次先让 LLM 生成测试场景列表，而不是直接生成代码。

通过提示词模板让 LLM 根据功能需求列出需要测试的场景，并给出测试数据。简单阅读返回结果，就能发现几个错误：场景间存在大量重复覆盖；LLM 将-l -p -d -g理解为唯一支持的参数，而不是通过配置可扩展的设计，完全误解了需求。

这个发现揭示了一个关键规律：LLM 从需求中提取到的知识是相同的，这些知识会被应用到不同的场景中去。不正确的生产代码和不正确的测试列表，是同一份错误知识的不同表现形式。

但这里有个关键差别：以自然语言产生的测试/任务列表，我们更容易发现错误并提出反馈；而以代码形式表示的功能代码，我们很难在第一时间发现错误。因此需要在更早的时候提出反馈，避免错误的累积。

二、知识对齐：在生成代码前修正 LLM 的理解

发现 LLM 误解了需求后，先反馈修正这个问题：明确说明-l -p -d -g只是例子，参数是可配置、可扩展的，用户配置了某个参数类型才能使用，未配置的参数是非法参数。

LLM 根据反馈重新生成测试场景，这次理解明显改善。虽然测试间仍有重复，但不影响继续推进。

接下来让 LLM 生成测试代码，明确指定：每个场景对应一个测试方法；被测试的类叫ArgumentParser，构造函数接受Map<String, ArgumentType>作为参数配置；parse方法返回Map<String, Object>作为解析结果。

LLM 生成的测试代码质量相当不错，结构清晰，覆盖了布尔标志、整数值、字符串值、列表值、默认值、混合参数、非法值、未配置参数等场景。

三、生产代码导航员：坚守角色边界

有了测试代码，再让 LLM 生成能通过这组测试的生产代码。执行测试，8 个测试通过 5 个，失败 3 个。

其中最重要的失败是testStringListValue：传入-g this is a list时，LLM 生成的代码将is识别为未配置的参数名，而不是-g的值。将错误信息反馈给 LLM，它尝试通过修改测试来蒙混过关。

这时需要坚守生产代码导航员的角色，明确告知：不是测试的问题，请修改ArgumentParser的逻辑。LLM 随后修正了列表类型的处理逻辑，改为持续收集直到遇到下一个以-开头的 token。

再次执行，只剩一个失败的测试。仔细查看发现是测试本身构造有问题（默认值测试的输入不对），直接自己修改测试，再次执行仍然失败——因为代码中没有对默认值的处理。将这个问题反馈给 LLM，它补充了setDefaultValues方法，最终所有测试通过。

四、两种方式的对比：测试先行的核心价值

对比直接生成代码（第 15 讲）和测试先行（本讲），改进体现在三个方面：

通过测试列表更早对齐知识理解。在生成代码之前，先通过自然语言的测试场景发现 LLM 对需求的误解，修正成本远低于修改代码。

以测试驱动的方式遵守"红 - 绿 - 重构"节奏。每次迭代都有明确的目标（让某个测试通过），而不是在大量代码中盲目调试。

按照"导航员 - 司机"模式与 LLM 结对。人始终扮演导航员，负责审查结果、提出反馈、给出设计建议；LLM 扮演司机，负责实际编码。当 LLM 试图走捷径（修改测试而非修改代码）时，导航员需要明确纠正方向。

这些改变让速度提升的同时保证了代码质量，实现了真正的效率提升——迭代次数更少，过程中更有把握，严重的设计问题在早期就得到了重视。