1. 一次颠覆直觉的AI实验：廉价模型如何写出更优的PR描述

最近我在为一个新功能分支撰写Pull Request描述时，做了一个有点反直觉的对比测试。我把同一个功能分支的代码变更，分别喂给了Anthropic家最便宜、最小的模型Claude Haiku 4.5，和他们家更强大、更贵的Claude Sonnet 4.6。结果你可能猜不到： Haiku 4.5写出来的PR描述，在盲评中击败了Sonnet 4.6 。

这听起来有点违背常识，对吧？毕竟Sonnet是定位更高阶的模型，理论上拥有更强的推理和编码能力。我最初也以为这会是场毫无悬念的碾压局。但结果恰恰相反，而原因完全不在模型本身。关键在于我“喂”给它们的东西不一样。这个实验让我彻底想明白了一件事：在利用AI辅助编码的日常里，我们可能过分迷信了“模型能力”，而严重低估了“上下文质量”的决定性作用。这就像你让一位米其林三星主厨用隔夜的剩菜和模糊的食谱照片做菜，而让一位普通厨师用最新鲜的、分门别类处理好的顶级食材操作，结果可想而知。

这次测试的核心，是评估AI在“代码变更理解与沟通”这个具体场景下的表现。无论你是独立开发者，还是团队中的技术骨干，清晰、准确的PR描述都能极大提升代码审查效率、减少沟通成本，并为未来的维护留下宝贵线索。但手动写PR又是个繁琐活儿，尤其是面对一个包含多个提交、涉及多个文件修改的复杂功能时。AI辅助看起来是个完美的解决方案，可为什么有时候它写出来的东西会让人觉得“差点意思”，甚至包含事实性错误？问题很可能就出在你给它的“信息饲料”上。

2. 实验设计：一场“不公平”的对比

为了让这个对比尽可能客观，我设计了一个简单的三组对照实验，并引入了第三方“裁判”来消除我的主观偏见。

2.1 测试对象与裁判机制

我选择的功能分支是为我的项目 HiveTrail Mesh 添加“Git工具”作为第四种数据源类型。这个改动涉及服务层、API层、测试文件等多个模块的修改，是一个典型的中等复杂度功能开发。

为了绝对客观，我没有自己给这些AI生成的PR描述打分。相反，我把三份完全匿名的输出（抹去了所有模型和上下文的标识）交给了 Google Gemini 3 Pro ，并给它设定了一个明确的评审角色：“请你从一名资深开发者和产品经理的双重角度，评估这份PR描述的清晰度、准确性、完整性和可读性。”Gemini的评估完全基于内容本身，它不知道哪份出自哪个模型。最终，我完全认同它的判断。

2.2 三组不同的“信息饲料”

这才是实验的关键。我并不是简单地把同一个提示词丢给两个模型，而是模拟了两种截然不同的“信息获取”工作流。

第一组：Claude Code (Sonnet 4.6) 的“标准工作流” 这模拟了大多数AI编程助手（如GitHub Copilot Chat、Cursor等）在帮你写PR描述时的典型行为。当你发出指令后，工具会在后台自动运行一些Git命令来获取变更摘要，然后把这些摘要塞进上下文窗口，让模型基于此生成描述。 具体来说，Claude Code运行了：

git log main..HEAD --oneline
git diff main...HEAD --stat

如果你不常摆弄Git，我解释一下这两个命令输出的是什么：

• git log --oneline ：输出从 main 分支分叉点到当前 HEAD 之间所有提交的 简略哈希值和提交信息标题 。仅此而已，没有提交信息的正文，没有具体的代码差异，更没有文件内容。
• git diff --stat ：输出一个 变更统计摘要 ，显示哪些文件被修改了，以及每个文件增加(+)和删除(-)的行数概览。同样，不包含任何一行实际的代码内容。

这个会话总共消耗了大约61K tokens，花费$0.12，耗时25秒左右。模型拿到手的，是一份极度精简的、高度概括的“目录”和“变更统计表”。

第二组 & 第三组：“富营养化”的完整上下文 对于另外两组测试，我彻底抛弃了让AI工具自己收集信息的模式。我手动（实际上是借助工具）准备了一份完整的“PR简报”。这份简报是一个 380KB的结构化XML文件 ，里面包含了：

• 每个被修改文件的完整内容 （前后对比版本）。
• 每个文件的统一差异对比 。
• 每个提交的完整元数据 （作者、时间戳、完整的提交信息）。
• 结构化的提交日志 。
• 甚至还有对未提交变更的警告 。

这份文件就像一个为AI量身定制的“案件卷宗”，把这次代码变更的所有原始证据都整理好了。当我把这份文件连同简单的提示词（“请为这个分支撰写PR标题和描述”）一起喂给模型时，Haiku 4.5和Sonnet 4.6看到的上下文大小是 106,120 tokens 。

看到区别了吗？这不是简单的“token数量”的差异，而是 信息密度和原始性 的天壤之别。一组是让模型看着“目录”和“统计表”去脑补和重构整个故事；另一组是直接把“原始档案、证人证言和现场照片”拍在它面前。

3. 输出质量的天壤之别：细节决定成败

当Gemini作为盲审裁判对比这三份输出时，质量的差距在三个关键维度上暴露无遗。这些差距完美解释了为什么“信息饲料”的质量如此致命。

3.1 产品上下文：让所有人都能看懂

在Claude Code（基于摘要）生成的描述中，它多次提到了“the Stack”（技术栈）。对于一个正在这个代码库中工作的开发者来说，这当然心知肚明。但是，对于一个刚加入团队的新同事，或者一个来自其他部门需要进行业务评审的产品经理，这个词就变成了一个需要猜测的“黑话”。PR描述的一个核心价值就是降低沟通门槛，而这种依赖隐含知识的表述违背了这一原则。

反观Haiku（基于完整上下文）生成的版本，开篇第一句就是：“在HiveTrail Mesh中引入Git工具作为第四种源类型，与Notion、本地文件和上下文块并列。”它陈述了同一个事实，但用了任何读者（无论是现在还是六个月后查看提交历史的人）都能立即理解的、自包含的语言。 完整上下文让模型“看到”了项目中其他源类型的定义和引用，从而能准确地构建出完整的业务图景，而不是吐出内部术语。

3.2 工作流准确性：魔鬼藏在实现里

这是一个更微妙但更致命的错误。Claude Code的描述中将新增的“Commit Brief”功能描述为“扫描单个提交”。这听起来似乎合理，但 完全错了 。

因为我“看到”了完整的代码实现（而模型没有），我知道“Commit Brief”的实际功能是：扫描 未提交的变更 ——包括已暂存、未暂存甚至未跟踪的文件——来帮助你为 尚未提交 的工作撰写提交信息。这是一个旨在改进提交前工作流的工具，而不是分析历史提交的工具。

这个错误的根源在于， git log --oneline 只显示了提交历史。模型基于“这个分支有一系列提交，并且新增了一个叫Commit Brief的功能”这个信息，做出了一个看似合理但完全错误的推断。它没有“看到”这个功能的具体代码逻辑，不知道它操作的对象是工作区而非版本库。 一个差异统计摘要永远无法提供这种语义上的精确性，任何基于摘要进行推理的模型也都不可能凭空猜对。

3.3 测试证据：从“相信我”到“看这里”

在描述测试覆盖时，两者的对比堪称经典。

• Claude Code版本写道：“在 tests/services/test_git_service.py 中提供了完整的pytest覆盖。”
• Haiku版本写道：“在 test_git_service.py 中新增了41个测试，覆盖了解析、预检查、扫描、默认检查、保存合并和XML生成。总计199个测试全部通过。”

Gemini在评审时精准地评论道：前者是一个“Trust me”（请相信我）式的断言；而后者是“brings the receipts”（拿出了收据/证据）。为什么？因为完整上下文包含了测试文件本身。Haiku模型“读”到了测试类、测试方法的名称和数量，因此它能进行具体的枚举和总结。而Claude Code只从 git diff --stat 里知道这个测试文件被修改了，行数增加了，至于里面具体有什么，它一无所知，只能进行笼统的、保险性的陈述。

这不是模型智能的差距。这纯粹是信息输入质量的差距。一个没有看过考卷的学生，怎么能准确描述出考题的难度和分布呢？

4. 最终排名与经济性启示

盲审结束后，Gemini对三份输出进行了排名：

1. 第一名：完整上下文 + Sonnet 4.6 。最强的整体结构，最佳的设计决策阐述。这符合预期，最强的模型配以最全的信息，表现最好。
2. 第二名：完整上下文 + Haiku 4.5 。优秀的Markdown格式化，极高的可浏览性，对Bug修复部分有清晰的区分。
3. 第三名：Claude Code + Sonnet 4.6 。测试计划部分写得不错，但格式平淡，整体上下文物料有限。

这个排名揭示了一个关键结论： 配备完整上下文的廉价模型（Haiku），其输出质量超过了配备贫瘠上下文的高级模型（Sonnet）。 模型层级的影响，被上下文质量的影响彻底碾压了。

由此引出了一个极其有趣的经济性启示。Haiku的价格远低于Sonnet。在这个实验中，由于提示词缓存吸收了绝大部分的输入token成本，使用Haiku进行生成的那一步，成本几乎可以忽略不计（几分钱甚至更少）。这意味着，你完全可以通过 改变喂给模型的信息质量，而非支付更多钱升级模型 ，来获得一份接近资深开发者水平的PR描述。

注意 ：这里说的“成本”主要指API调用中生成token的成本。为模型准备高质量的上下文本身可能需要一些计算开销（例如生成结构化差异），但这通常是一次性的、可优化的前置步骤。一旦拥有高质量的上下文，你可以用它反复生成或迭代PR描述，而每次生成的边际成本极低。

5. 问题根源与解决方案：解耦上下文组装与文本生成

那么，为什么像Claude Code这样优秀的工具会提供“贫瘠”的上下文呢？这并非设计缺陷，而是一个合理的工程权衡。

Claude Code是一个 通用型编码助手 ，它的设计目标是在数百种不同的任务（代码解释、调试、生成、重构等）中，在速度、成本和交互性之间取得平衡。对于每一个PR描述请求，如果都去运行完整的、包含文件内容的差异对比，将会非常缓慢且昂贵，并且在大多数简单的代码变更场景下是“杀鸡用牛刀”。因此，它选择了提供轻量级摘要的策略，这对于一个需要快速响应的通用工具来说是合理的。

但问题在于，PR描述的质量，与模型能“看到”的变更细节量直接成正比。 一个差异统计能告诉你“什么”改变了，但它无法告诉你“为什么”改变、各个部分在架构上如何衔接、处理了哪些边界情况，或者测试覆盖的具体范围。当你要求模型基于差异统计来撰写PR时，你实质上是在要求它根据一张“缩略图”来重构一幅“高清全景图”。

解决方案其实很清晰： 将“上下文组装”与“文本生成”这两个步骤解耦。

停止让你的通用AI编码助手来决定哪些上下文是重要的。你应该自己（或使用专门工具）来组装高质量的上下文，然后将这个“信息包”交给你想用的任何模型去生成文本。

具体到操作上，就像本次实验所做的：我为这个功能分支准备的“PR简报”是一个380KB的结构化XML文件。我把它直接拖进Claude的网页聊天界面，选择Haiku 4.5模型，附上一句简单的提示词，就得到了在三人评测中排名第二的高质量输出。生成步骤的成本几乎为零，而质量全部来自于精心准备的上下文。

5.1 如何实践：工具与工作流建议

对于开发者个人或团队，可以这样落地：

1. 识别高质量上下文的要素 ：你需要的不只是 git diff 。至少应包括：

   • 文件级完整对比 ：关键文件修改前后的完整内容，而不仅仅是差异行。
   • 结构化提交历史 ：包含完整提交信息（标题和正文）和作者/时间元数据。
   • 测试文件内容 ：让模型能看到新增了哪些具体的测试用例。
   • 相关配置文件变更 ：如 package.json , docker-compose.yml 等，这些往往体现了依赖或环境的变化。

2. 利用或构建上下文组装工具 ：

   • 专用工具 ：像实验中使用的 HiveTrail Mesh 这类工具，就是专门为生成这种“PR简报”而设计的。它能从本地Git仓库生成包含文件内容、差异、元数据的结构化文档（如XML），并允许你通过勾选来控制包含或排除哪些文件、提交。
   • 自定义脚本 ：你可以编写自己的Shell或Python脚本，组合使用 git show , git diff --unified , git log --pretty=format 等命令，输出一份结构化的Markdown或JSON文档。
   • IDE插件增强 ：探索你的IDE中是否有插件能提供更丰富的“变更预览”或“提交打包”功能，并尝试将其输出提供给AI。

3. 建立新的工作流 ：

   • 前置步骤 ：在请求AI撰写PR描述前，先运行你的上下文组装工具/脚本，生成一个“变更报告”文件。
   • 模型选择 ：将这个文件作为附件或粘贴进你选择的AI聊天界面（Claude Web, ChatGPT, Gemini等）。此时，你可以根据需求自由选择模型。对于追求性价比的日常PR，Haiku或GPT-3.5 Turbo可能就足够了；对于极其复杂或重要的架构变更，再考虑使用Sonnet或GPT-4。
   • 提示词优化 ：你的提示词可以变得更简单、更聚焦于“如何表达”，而不是“理解什么”。例如：“基于附上的完整变更报告，撰写一份面向技术评审和产品经理的PR描述，需清晰说明改动动机、实现方案、测试覆盖和需要注意的边界情况。”

6. 一个值得自省的问题

最后，给你自己提一个问题：去看看你常用的AI编程工具，在生成上一次PR描述时， 它实际在后台运行了哪些Git命令？ 大多数工具都有日志功能可以查看。

如果你自己都不愿意仅仅根据那些命令的输出（几行提交标题和一堆 +/- 符号）来手动撰写一份PR描述——如果你觉得你需要打开几个关键文件、仔细阅读差异、检查测试覆盖才能动笔——那么，你就是在要求AI模型去做一件你自己都不愿意做的事，而且给它的信息比你自己动手时拥有的还要少。

你为模型层级支付的费用，无法改变它进行推理所依据的原始材料的质量。 能改变这一切的，是上下文。

这个实验让我深刻意识到，在AI辅助开发的浪潮中，我们往往热衷于追逐更强大的模型，却忽略了最基础的数据准备环节。就像烹饪，顶级食材往往只需要简单的烹饪。为AI准备好一份详尽、结构化的“代码变更卷宗”，或许比你纠结于用哪个型号的“厨具”（模型）更能决定最终“菜品”（PR描述）的质量。对于真正重视的项目，不妨重新审视一下你的AI工作流，从改善“信息投喂”开始，这可能是提升产出质量最具性价比的一步。