Sol/Terra/Luna三分支实现Issue-12代码质量对比
速览
帖子记录了在Exp/5.6-sol、luna、terra三个分支上实现同一issue（迁移图表回避及E2E验收）的代码质量对比。通过Grok-4.5和GPT-5.6评价，Sol在可读性、简洁性和可维护性上最佳，Luna功能与测试最完整但复杂度高，Terra存在缺陷。反映了AI辅助编程中不同实现路径的质量差异。
AI 深度解读
背景
这是一篇来自 LINUX DO · AI 社区的实操分享，作者在同一个 issue（issue-12）上，使用三个不同的 AI 模型（或实现路线：sol、terra、luna）的“High 模式”进行代码生成与端到端测试验证，并记录了各自的耗时、费用以及最终代码质量。两个外部评价模型——grok-4.5 和 gpt-5.6——被用来对三个分支的 src 代码质量和 tests 质量做独立打分与比较。整个实验旨在探索不同 AI 辅助生成方案在真实工程任务中的效率与产出质量差异。
核心内容
实验设置
作者事先通过 grill-me-withdocs 工具生成了 PRD（产品需求文档），并拆解为多个 issues。本次测试针对同一个 issue（issue-12），提示词保持一致：
$implement xxx/xxx/issue-12-xxxx.md,
并附加了明确的约束：要求实现参考旧仓库中的真实例子和端到端测试，在新仓库中生成对应的端到端测试，并将测试结果输出到指定路径 /tmp/pdfocr_api-rewrite/issue-12_e2e.md。
执行记录
作者为每个方案创建了独立的工作树和分支：
| 分支 | 耗时 | 费用 | 备注 |
|------|------|------|------|
| exp/5.6-sol | 10 分钟（首次）+ 26 分钟（重试） | $2.57（首次）+ $8.54（重试） | 首次中断且实现有严重问题，重试后完成 |
| exp/5.6-luna | 37 分钟 | $2.86 | 一次成功 |
| exp/5.6-terra | 33 分钟 | $5.67 | 一次成功 |
三个分支的最新 commit 均实现了同一份 PRD（docs/prds/mineru-rewrite/issue-12-migrate-bp-chart-workaround-and-e2e-acceptance.md 及父 PRD docs/mineru_rewrite_prd.md），并且各自 commit 中新增的 E2E 测试均通过。
grok-4.5 评价
按维度比较：
- 可读性：sol 最好；terra 单文件易读但路径分叉多；luna 最长、概念最多。
- 简洁性：terra 表面代码最短，但包含死代码和重复解析，抵消优势；sol 实质最简；luna 最冗重。
- 可维护性：sol（复用细节、小 diff、可观测 metadata）> terra > luna（域模型/依赖扩张）。
- 测试完整性：sol ≈ luna（luna 多测回退，sol 多测门控与跳过）> terra。
- 无意义测试：三者均无明显空转断言；terra 有误导性测试名，sol 有两个相近的 ambiguous 用例属轻微冗余；luna 的调用序列断言偏白盒，但对应其复杂度不算灌水。
总体结论：三个实现都能通过验收；论长期合入质量，sol 最值得作为主线；luna 可作为需要 PDF recrop 兜底时的参考实现；terra 的 canonicalize/bare-context 切断可借鉴，但解析复用与 E2E matcher 需要修复。
gpt-5.6 评价
综合评分（10 分制）：
| 分支 | src 质量 | tests 质量 | 评价 | |------|----------|------------|------| | sol | 8.4/10 | 8.2/10 | 简洁、保守、模块边界最好 | | luna | 7.6/10 | 8.8/10 | 恢复链和测试最完整，但偏重 | | terra| 5.8/10 | 6.4/10 | 存在错误分支和测试 oracle 漏洞 |
最终排名：sol > luna > terra。
关键要点
- sol 方案在代码质量和可维护性上表现最优，grok-4.5 和 gpt-5.6 均给出最高评价，尽管其执行过程因中断和严重问题需要重试，但重试后的最终产出质量最高。
- luna 方案的测试最完整（gpt-5.6 给出 tests 质量 8.8/10），但代码复杂度明显更高，可读性和可维护性低于 sol。
- terra 方案费用最高（$5.67）但代码质量最差，存在死代码、重复解析、误导性测试名和测试 oracle 漏洞，gpt-5.6 的 src 评分仅 5.8/10。
- 费用与质量不成正比：sol 最终费用（$2.57 + $8.54 = $11.11）最高，但质量最好；terra 费用第二高，质量最差；luna 费用最低（$2.86）且质量中等。
- 两次评价模型结论一致：sol 综合最佳，luna 次之，terra 垫底。
- 端到端测试均为必选要求，三个分支均通过各自新增的 E2E 测试，但测试的可信度存在差异（terra 的测试被指出有漏洞）。
意义与影响
该实验展示了在 AI 辅助代码生成场景下，不同模型/提示策略对同一工程需求的输出存在显著差异，且这种差异不仅体现在执行耗时和费用上，更体现在最终代码质量和测试可靠性上。关键影响包括：
- 为 AI 辅助编程的模型选型提供了实证：某些模型（如 sol）可能在第一次尝试时失败率高，但重试后产出质量极高；而另一些（如 terra）虽然一次通过，但代码质量不足，长期维护风险大。
- 费用不是质量的决定因素：高费用不一定带来高质量，低费用也可能产出中等质量（如 luna），这提示开发者在成本控制与质量追求之间需要综合权衡。
- 测试完整性需要独立评估：表面上三个分支都通过了 E2E 测试，但 terra 的测试存在 oracle 漏洞，说明仅凭测试通过率不能代表测试质量。
- 可复现的对比方法具有参考价值：作者使用标准化的提示词、相同的问题、独立的 git worktree 分支以及客观评价模型（grok-4.5、gpt-5.6），形成了一套可重复的 AI 代码生成评测流程，可供社区借鉴。