与 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 试图走捷径（修改测试而非修改代码）时，导航员需要明确纠正方向。
这些改变让速度提升的同时保证了代码质量，实现了真正的效率提升------迭代次数更少，过程中更有把握，严重的设计问题在早期就得到了重视。