TARS：基于思维理论的IDE智能代码理解代理设计与实现-平芜编程栈

1. 项目概述：当IDE插件拥有“读心术”

最近在IDE插件社区里，一个名为TARS的项目引起了我的注意。它的全称是“A Theory-of-Mind Agent for Personalized In-IDE Code Comprehension”，直译过来就是“一个用于个性化IDE内代码理解的思维理论代理”。初看这个标题，你可能会觉得它充满了学术气息，甚至有点“玄乎”。但简单来说，TARS试图解决一个我们每个开发者都深有体会的痛点：当你在IDE里阅读一段复杂、陌生或历史遗留代码时，你不仅想知道“这段代码在做什么”，更想知道“当初写这段代码的人到底在想什么”。

传统的代码理解工具，无论是基础的语法高亮、跳转定义，还是更高级的基于LLM的代码解释插件，它们提供的都是一种“客观”的、基于代码文本本身的分析。它们能告诉你这个函数调用了哪些API，这个变量是什么类型，甚至用自然语言概括一下函数功能。但这远远不够。代码是开发者思维的具象化产物，里面充满了个人风格、临时决策、妥协方案和未言明的上下文。比如，为什么这里要用一个看似低效的双重循环？为什么这个配置项被硬编码而不是从配置文件读取？为什么这个异常被捕获后只是简单记录日志而没有向上抛出？这些问题的答案，往往藏在代码作者的“心智模型”里。

TARS项目的核心野心，就是让AI代理具备这种“思维理论”能力，在IDE这个我们最熟悉的主场，为我们提供一种高度个性化、上下文感知的代码理解辅助。它不再满足于做一个被动的“代码翻译机”，而是想成为一个能洞察意图、理解背景、甚至能预测开发者下一步行动的“编程伙伴”。结合网络上的热议，无论是关于LLM Agent的演进、Visual Studio Code插件的深度定制，还是对更智能编程环境的普遍渴望，都指向了同一个方向：工具正在从“增强体力”向“增强脑力”演进。TARS正是这个趋势下一个非常前沿和具体的探索。

接下来，我将结合对这类系统设计的理解，为你深度拆解TARS背后的设计思路、关键技术挑战、可能的实现方案，以及它对我们日常开发工作流的潜在影响。无论你是想了解下一代开发工具的趋势，还是有意自己动手构建类似的智能体，相信这些内容都能给你带来启发。

2. 核心设计思路与架构猜想

要构建一个具备“思维理论”的IDE代理，我们不能只把它看作一个加强版的代码补全工具。它的设计必须围绕“个性化”和“心智建模”这两个核心展开。以下是我基于现有技术路径对其架构的拆解与推演。

2.1 什么是“思维理论”在编程中的体现？

“思维理论”原本是一个心理学概念，指个体理解自己以及他人的心理状态，并据此预测和解释行为的能力。映射到编程领域，一个具备ToM能力的代理需要能够：

推断开发者的知识状态：代理需要知道当前开发者对这块代码库的熟悉程度。是新接手项目的成员，还是原作者？这决定了解释的深度和起点。
理解开发者的意图和目标：当开发者的光标停留在一行代码上，或选中一个代码块时，他的意图是什么？是想修复一个bug，添加新功能，还是仅仅在理解逻辑？不同的意图需要不同侧重的解释。
构建代码作者的心智模型：这是最核心也最困难的部分。代理需要从代码的“遗迹”中，反向构建出作者当时的决策上下文：他面临的约束（时间、性能、依赖）、他的假设、他权衡后的取舍，甚至他可能忽略的边界情况。

因此，TARS的输入绝不仅仅是当前聚焦的代码片段。它应该是一个多模态、多来源的上下文感知系统。

2.2 个性化代码上下文的构建与融合

一个有效的个性化理解代理，其根基在于一个无比丰富的上下文系统。我认为TARS的上下文层至少需要整合以下几个维度：

2.2.1 静态代码上下文这是最基础的一层，包括：

语法树：提供代码的结构化表示。
项目文件树：了解当前文件在项目中的位置和依赖关系。
版本控制历史：从Git等工具中提取当前文件的修改历史、提交信息、代码作者。这是挖掘“意图”的金矿。例如，结合提交信息“PERF: optimize data fetching with cache”和对应的代码差异，代理就能理解某段缓存引入代码的性能优化初衷。
项目文档与注释：README、API文档、代码中的注释（尤其是TODO、FIXME、HACK等特殊标记）是直接的意图说明。

2.2.2 动态交互上下文这层信息让代理变得“活”起来，真正与开发者当前的工作流同步：

IDE状态：当前打开的文件、光标位置、选中的文本、打开的文件标签页、集成终端中的命令和输出。
开发者行为序列：最近浏览过的文件、编辑操作（增删改查）、搜索查询、调试器断点设置。这些行为序列是推断开发者当前探索目标和遇到困难的关键线索。
运行时信息：如果项目正在调试或运行，代理可以接入调试器API，获取变量实时状态、调用堆栈、日志输出，将静态代码与动态行为联系起来。

2.2.3 开发者画像上下文这是实现“个性化”的核心。它需要长期、渐进地学习：

技术栈偏好：开发者惯用的框架、库、设计模式。例如，当他看到一段RxJS代码时，代理的解释可以默认使用Observable、Operator等术语。
知识水平与盲区：通过分析开发者过去的提问（对代理或同事）、常查阅的文档、容易出错的代码模式，构建其知识图谱。对于他熟悉的概念，解释可以简略；对于盲区，则需要提供更基础、更详细的说明。
任务背景：如果开发者连接了任务管理工具，代理可以获取当前JIRA Ticket或GitHub Issue的描述，从而明确本次编码活动的业务目标和具体需求。

实操心得：上下文融合的挑战将这么多异构的上下文源融合成一个连贯的“情境”，是工程上的巨大挑战。一个常见的策略是采用“向量化+检索增强”的管道。将所有上下文信息（代码、提交信息、文档片段、对话历史）转化为嵌入向量，存入向量数据库。当需要理解当前代码时，将当前代码片段作为查询，从向量库中检索最相关的历史上下文片段，与当前代码一并送给LLM进行分析。这比试图将整个项目历史全部塞进LLM上下文要可行得多。

2.3 基于LLM的推理与交互引擎

有了丰富的上下文，下一步就是需要一个强大的“大脑”来处理它们。大型语言模型无疑是这个引擎的核心。

2.3.1 智能体的推理流程设计TARS的推理可能不是一个简单的单次问答，而是一个多步骤的推理链：

情境感知：收集并整合上述所有相关上下文。
意图识别：基于开发者当前行为（如光标停留、代码选中、最近的错误）和任务背景，推测其最可能的意图（“理解原理”、“定位bug”、“寻找复用点”）。
心智模型模拟：针对要理解的代码，结合代码作者的历史提交风格、当时的项目状态（通过Git历史还原）、以及常见的工程权衡，尝试推演作者当时的决策逻辑。“他为什么这么做？有没有更优解？当时的限制是什么？”
个性化表达生成：根据开发者的画像，将推理结果用最合适的方式表达出来。对于新手，可能需要比喻和分步解释；对于专家，可能只需要点出关键的设计决策和潜在的陷阱。

2.3.2 提示工程与工具调用要让LLM完成如此复杂的推理，精妙的提示工程至关重要。提示词需要清晰定义代理的角色、可用的工具（如读取文件、查询Git、执行搜索）以及输出的格式。例如，可以设计这样的提示结构：

你是一个经验丰富的编程助手，具备洞察代码作者意图的能力。你的任务是帮助开发者理解以下代码。 ## 可用工具 - `get_git_blame(line_range)`: 获取指定代码行的作者和提交信息。 - `search_related_commits(keywords)`: 在Git历史中搜索相关提交。 - `get_project_doc()`: 获取项目文档摘要。 ... ## 当前上下文 - 开发者档案：{开发者技能偏好} - 当前任务：{关联的JIRA issue摘要} - 近期行为：{最近浏览的文件列表} ## 目标代码 {用户选中的代码段} 请按以下步骤分析： 1. 首先，使用工具查明这段代码的来历和修改历史。 2. 结合历史，推断作者编写时的主要考虑因素和可能面临的约束。 3. 从“代码在做什么”和“作者为什么这么做”两个层面进行解释。 4. 根据开发者的背景，给出是否建议修改以及如何修改的意见。

2.3.3 交互模式：从问答到伴随TARS的交互不应局限于一个聊天框。它应该深度融入IDE：

行内注释：像Ghost Text一样，在代码行旁以淡色字体显示推测的作者意图或复杂逻辑的解释。
代码透镜：在函数上方提供增强信息，如“此函数在近3个月被修改过5次，主要与性能优化相关”。
智能诊断：不仅报告语法错误，还能指出“逻辑异味”，比如“这里的异常处理方式与项目其他地方的约定不一致，可能源于某次紧急修复（参见提交abc123）”。
主动问答：当检测到开发者在某段代码前停留时间过长，或反复修改同一区域失败时，可以主动弹出提示：“看起来你在理解这个状态管理逻辑时遇到了困难？需要我结合Redux作者的原始讨论来帮你梳理一下吗？”

3. 关键技术组件与实现难点

将上述架构落地，需要攻克一系列技术难点。这里我们深入几个核心组件的实现逻辑。

3.1 高精度代码上下文提取器

上下文的质量直接决定理解的上限。一个健壮的提取器需要处理多种情况：

3.1.1 基于语言服务器协议的静态分析TARS很可能重度依赖LSP来获取精准的代码信息。通过IDE内置或自建的LSP客户端，可以获取：

符号定义与引用：快速跳转，理解代码关联。
语法树：通过textDocument/documentSymbol和textDocument/syntaxTree等请求，获得代码的完整结构。
类型信息：对于TypeScript、Java等强类型语言，类型信息是理解代码契约的关键。

3.1.2 Git历史挖掘与“考古学”这是构建“心智模型”的关键数据源。简单的git blame不够，需要更深入的分析：

# 示例：获取一段代码的详细演变历史 git log -L 10,20:path/to/file.java --oneline git show <commit_hash> --stat # 查看该次提交的完整变更上下文

需要编写脚本，将代码片段映射到具体的提交，提取提交信息、差异，并尝试关联相关的Issue编号。难点在于处理代码重构（重命名、移动文件）后历史跟踪的中断，这可能需要借助git log --follow和启发式算法进行匹配。

3.1.3 运行时状态挂钩对于动态理解，需要与调试器交互。例如，在VS Code中，可以通过Debug Adapter Protocol定制调试会话，在断点处捕获变量快照、调用栈，并将这些信息与静态代码关联存储。

注意事项：性能与隐私平衡实时提取和分析大量上下文（尤其是全项目范围的Git历史和文件索引）会带来性能开销。一个可行的策略是分层加载和增量索引：对当前打开的文件和直接依赖进行深度实时分析；对整个项目建立异步的增量索引，在后台运行。同时，所有涉及开发者行为数据的收集必须明确告知、征得同意，并提供清晰的隐私控制选项，数据最好能本地处理。

3.2 面向开发者画像的增量学习模型

“个性化”不是静态配置，而是需要持续学习的。这里可能不涉及训练一个庞大的神经网络，而是更巧妙地构建和更新用户画像。

3.2.1 画像数据结构可以设计一个本地的、结构化的开发者档案文件：

{ "developer_id": "user_123", "technical_stack": { "proficient": ["React", "TypeScript", "Node.js"], "familiar": ["Python", "Docker"], "learning": ["Rust", "Terraform"] }, "interaction_history": [ { "timestamp": "2024-05-20T10:00:00Z", "code_context": "useState hook", "query": "如何优化大量useState的性能？", "response_feedback": "helpful" // 或 “not_helpful” } ], "project_specific_knowledge": { "project_a": { "familiar_modules": ["src/utils/auth.js", "src/components/Button"], "authored_components": ["src/hooks/useCustomFetch.js"] } }, "inferred_style_preferences": { "explanation_depth": "detailed", // 或 “concise” "prefers_examples": true, "prefers_diagrams": false } }

3.2.2 学习机制

显式反馈：提供“解释是否有用”的点赞/点踩按钮，直接收集反馈。
隐式学习：通过行为分析。例如，如果开发者在得到解释后很快跳转到相关文档或定义，可能意味着解释不够清晰；如果解释后他立即开始流畅地编辑代码，则意味着解释有效。
会话记忆：在单个IDE会话中，记住之前讨论过的概念，避免重复解释，并在后续解释中引用之前达成的共识。

3.3 针对代码理解的LLM提示工程优化

直接让通用LLM理解代码和意图效果有限，需要针对性的优化。

3.3.1 分阶段提示策略将复杂的代码理解任务分解：

摘要阶段：先让LLM用一句话概括选中代码的核心功能。
溯源阶段：结合Git工具调用结果，让LLM分析代码的演变历程和关键修改点。
推理阶段：基于摘要和溯源，回答“为什么”的问题，推测设计决策。
个性化应答阶段：根据开发者画像，将前三阶段的结果整合成最终回复。

3.3.2 提供“思维链”示例在系统提示中提供少量、高质量的示例，示范如何一步步分析代码意图。例如：

用户代码：`const data = await fetch(url).then(r => r.json()).catch(e => ({ error: e.message }));` 分析步骤： 1. 功能摘要：这是一个使用fetch API获取JSON数据并处理潜在错误的异步操作。 2. 可能意图：作者希望用一个简洁的链式调用处理网络请求和错误，避免冗长的try-catch。 3. 决策推理：使用.then().catch()而非async/await，可能是为了代码风格统一（项目其他部分也多用Promise链），或是在箭头函数中保持简洁。将错误包装为对象{error: ...}，意味着调用者期望统一的数据结构，无论成功失败。 4. 潜在问题：这种写法无法区分网络错误和JSON解析错误。如果上游期望更详细的错误类型，这里可能丢失信息。

通过提供这样的示例，可以引导LLM模仿这种结构化的推理过程。

3.3.3 处理长上下文与信息过载即使有检索增强，有时仍需向LLM输入较长的代码文件。需要使用代码分块、层次化摘要和关键信息提取技术。例如，先让LLM分析一个文件的函数/类列表并总结其职责，在需要深入某个函数时，再传入该函数的详细代码及其调用关系。

4. 潜在应用场景与价值展望

这样一个深度集成的“思维理论”代理，其应用场景远不止于回答“这段代码什么意思”。它将重塑我们与代码库交互的方式。

4.1 核心应用场景深度解析

4.1.1 高效接手遗留项目与代码评审对于新加入的开发者，TARS可以成为“项目原住民向导”。当你打开一个陌生文件，它可以自动生成一份“游览指南”：

“这个Service类最初由Alice在2022年重构，目的是解耦业务逻辑。核心模式是‘策略模式’，但注意_cache这个成员变量是Bob后来加的，没有很好地处理并发，在update()方法里有个已知的竞态条件（见Issue #45）。”
在代码评审时，它不仅能指出风格问题，还能结合提交历史评论：“这个PR中修改的数据库连接池配置，与三个月前David因内存泄漏问题回滚的修改（提交xyz789）非常相似，建议确认此次修改是否已解决了当时的溢出问题。”

4.1.2 深度调试与根因分析当程序出现bug时，TARS可以将静态代码、运行时错误堆栈、相关代码的修改历史以及日志信息进行关联分析。

场景：应用抛出“空指针异常”。
传统方式：查看堆栈，定位到出错行，检查变量。
TARS增强：它会提示：“异常发生在UserProcessor.process()的第45行。input参数为空。这个process方法在上周被Charlie修改过（提交def456），修改目的是‘优化输入验证’。但查看差异发现，原来的非空检查if(input != null)被误删了。建议恢复该检查或查看调用方为何传入了空值。”

4.1.3 个性化学习与知识传承TARS可以成为团队内部的“知识沉淀加速器”。

对个人：当你频繁查询某个第三方库的特定用法时，TARS可以判断这是你的知识盲区，并适时建议：“看起来你在多次尝试使用lodash的groupBy函数。项目里utils/collection.js中有一个封装好的safeGroupBy函数，处理了边缘情况，并且Alice在代码评审中称赞过其健壮性。要不要看看那个实现？”
对团队：当团队最佳实践发生变更时（例如，从旧的状态管理方式迁移到新的），TARS可以在开发者编写旧模式代码时，主动提示新的模式范例和迁移指南，确保知识同步。

4.1.4 设计意图追溯与架构守护在重构或扩展系统时，理解原始设计意图至关重要。TARS可以回答高层次的设计问题：

“为什么我们这个微服务之间采用异步消息通信而不是直接HTTP调用？”
TARS可能回答：“根据2023年初的架构决策文档（docs/ADR-001-async-messaging.md）以及当时的主要开发者Eve在Slack上的讨论记录，选择异步消息是为了解耦服务、提高系统整体吞吐量，并允许单个服务暂时故障而不影响全局。但文档也提到了后续监控复杂性的挑战。”

4.2 面临的挑战与局限性

尽管前景诱人，但构建TARS这样的系统面临诸多严峻挑战：

4.2.1 技术挑战

LLM的幻觉与不确定性：LLM在推理代码意图时可能“自信地”给出错误或编造的历史原因。如何提高其推理的准确性和可信度？可能需要引入置信度评分和多源验证机制（例如，要求关键推断必须能从Git历史或文档中找到至少一个佐证）。
上下文管理的复杂性：如何高效、实时地管理海量、多源的上下文信息，并精准检索出相关片段，是一个巨大的系统工程问题。
性能与响应延迟：复杂的推理和上下文检索不能在IDE中造成明显的卡顿。所有操作必须在数百毫秒内完成，这对算法和工程优化提出了极高要求。

4.2.2 用户体验与伦理挑战

信息过载与干扰：代理如果过于“热心”，频繁弹出提示，会严重干扰开发者的心流。必须设计极其智能、非侵入式的触发和交互机制，例如只在显式请求或检测到明显困惑时（如长时间无操作、反复报错）才介入。
隐私与数据安全：代理需要访问代码历史、开发者行为等敏感数据。必须确保所有数据在用户可控范围内（优先本地处理），传输加密，并提供清晰的数据使用政策。对于企业环境，可能需要支持完全离线部署。
对开发者技能的长期影响：过度依赖这样的智能代理，是否会削弱开发者深入理解系统、独立调试和批判性思考的能力？这是一个需要长期观察的教育学和认知科学问题。工具的设计应秉持“辅助而非替代”的原则。

4.3 开源生态与集成展望

TARS的理想形态可能不是一个封闭的单一插件，而是一个开放的平台或协议。

插件化架构：核心是一个“上下文管理引擎”和“推理协调器”，而代码提取器（支持不同语言）、版本控制适配器（Git, SVN）、LLM后端（OpenAI, Claude, 本地模型）都以插件形式存在。
与现有工具链集成：它可以成为连接现有强大工具（如Sourcegraph for code search, Sentry for error tracking, Linear/Jira for task management）的智能中间层，统一它们的上下文，提供综合洞察。
社区共享心智模型：也许未来，开发者可以为流行的开源库（如React, Spring）贡献“公共心智模型”包，包含常见的模式、最佳实践和设计决策解读，新人在使用这些库时能直接获得高质量的意图理解。

5. 构建简易原型的实践思路

如果你对TARS的概念感兴趣，想亲手搭建一个最小可行原型来验证核心想法，以下是一个基于VS Code扩展和现有云LLM API的实践路线图。

5.1 技术选型与基础环境搭建

5.1.1 开发框架

IDE选择：毫无疑问从VS Code扩展开始，因为它拥有最活跃的插件生态和清晰的API文档。
扩展开发：使用VS Code官方提供的yo code脚手架生成器，快速创建一个TypeScript或JavaScript项目。这是最标准的起点。
LLM后端：初期为快速验证，建议使用提供强大代码理解能力的云API，如OpenAI的GPT-4 Turbo或Anthropic的Claude 3。它们对代码的语义理解、推理和指令跟随能力目前处于领先。后期可以考虑集成本地模型（如CodeLlama）以降低成本和保护隐私。

5.1.2 核心依赖库

@vscode/vscode-api：VS Code扩展API。
langchain或llamaindex：用于构建基于LLM的应用，它们提供了便捷的提示模板、链式调用和检索增强生成工具。对于原型，llamaindex的索引和检索能力可能更直接。
simple-git：一个优秀的Node.js库，用于在扩展中执行Git操作，获取blame、log、diff等信息。
向量数据库（可选）：如果要做复杂的上下文检索，可以集成ChromaDB（轻量级，易于嵌入）或LanceDB。原型初期也可以先用简单的文本相似度匹配（如cosine-similarity库）来验证概念。

5.2 实现核心功能模块

5.2.1 上下文收集器创建一个ContextCollector类，负责在用户选中代码或触发命令时，收集相关信息。

class ContextCollector { async collectForSelection(editor: vscode.TextEditor): Promise<CodeContext> { const selection = editor.selection; const selectedText = editor.document.getText(selection); const uri = editor.document.uri; const workspaceRoot = vscode.workspace.workspaceFolders?.[0].uri.fsPath; // 1. 获取Git信息 const gitInfo = await this.getGitBlameInfo(workspaceRoot, uri.fsPath, selection); // 2. 获取符号信息（通过VS Code API） const symbols = await vscode.commands.executeCommand<vscode.DocumentSymbol[]>( 'vscode.executeDocumentSymbolProvider', uri ); // 3. 获取项目文件树摘要（简化：列出同级目录文件） const siblingFiles = await this.getSiblingFiles(uri); // 4. 获取开发者最近的行为（简化：最近打开的文件） const recentFiles = this.getRecentFilesHistory(); return { selectedCode: selectedText, git: gitInfo, symbols: symbols.filter(s => this.intersects(s.range, selection)), fileContext: { siblings: siblingFiles }, developerContext: { recentFiles } }; } private async getGitBlameInfo(root: string, filePath: string, selection: vscode.Selection): Promise<GitBlameInfo[]> { const git = simpleGit(root); const blame = await git.raw(['blame', '-L', `${selection.start.line+1},${selection.end.line+1}`, '--porcelain', filePath]); // 解析blame输出，提取每行的提交hash、作者、日期、摘要 return this.parsePorcelainBlame(blame); } }

5.2.2 提示词组装与LLM调用设计一个提示词模板，将收集到的上下文结构化地填充进去。

const PROMPT_TEMPLATE = ` 你是一个资深编程助手，擅长理解代码背后的意图。 ## 开发者背景 开发者最近关注过这些文件：{recentFiles}。他可能正在处理与这些模块相关的任务。 ## 代码变更历史 以下是选中代码行的Git提交历史： {gitHistory} ## 当前代码及上下文 选中的代码位于文件 {fileName} 中。 相关的代码结构包括：{symbolsInfo}。 ## 需要理解的代码片段 \`\`\` {selectedCode} \`\`\` 请从以下角度进行分析： 1. **功能摘要**：这段代码的核心作用是什么？ 2. **意图推理**：结合Git历史，推测作者当时为何这样写？可能考虑了哪些因素（如性能、可读性、兼容性、紧急修复）？ 3. **潜在问题与建议**：以当前眼光看，这段代码是否存在隐患、可以改进的地方？对于{recentFiles}中反映的开发者当前任务，这段代码有何关联或启示？ 请用清晰、平实的语言回答，避免过度技术术语堆砌。 `; async function analyzeWithLLM(context: CodeContext): Promise<string> { const prompt = fillPromptTemplate(PROMPT_TEMPLATE, context); // 使用LangChain或直接调用API const llm = new OpenAI({ apiKey: process.env.OPENAI_API_KEY, modelName: 'gpt-4-turbo' }); const response = await llm.call(prompt); return response; }

5.2.3 扩展激活与UI展示在extension.ts的activate函数中注册命令和事件监听。

export function activate(context: vscode.ExtensionContext) { // 注册一个命令，通过右键菜单或快捷键触发 let disposable = vscode.commands.registerCommand('tars.explainCode', async () => { const editor = vscode.window.activeTextEditor; if (!editor) { vscode.window.showWarningMessage('请先打开一个代码文件并选中一些文本。'); return; } // 显示进度提示 await vscode.window.withProgress({ location: vscode.ProgressLocation.Notification, title: "TARS正在思考代码意图...", cancellable: false }, async (progress) => { const codeContext = await contextCollector.collectForSelection(editor); const analysis = await analyzeWithLLM(codeContext); // 将结果输出到一个新的Webview面板或侧边栏 const panel = vscode.window.createWebviewPanel( 'tarsAnalysis', 'TARS代码分析', vscode.ViewColumn.Beside, { enableScripts: true } ); panel.webview.html = getWebviewContent(analysis); }); }); context.subscriptions.push(disposable); // （可选）注册代码透镜提供者，在代码上方显示简要提示 const lensProvider = new TarsCodeLensProvider(); vscode.languages.registerCodeLensProvider('*', lensProvider); }

5.3 原型阶段的注意事项与调试技巧

5.3.1 从微小场景开始不要试图一开始就构建全功能的“思维理论”代理。选择一个极其具体、高价值的场景入手。例如：

场景：解释“为什么这个函数参数被标记为@deprecated”。
实现：收集该函数的Git历史，找到添加@deprecated标签的提交，提取提交信息，并查找后续使用了新替代方案的代码示例。让LLM基于这些信息生成解释。
价值：这个场景小到可以快速实现，但又能直观展示“结合历史理解代码”的核心价值。

5.3.2 精心设计测试用例准备一些包含明确“意图痕迹”的代码片段进行测试。例如：

一段包含// TODO: Refactor this after library X version 2.0 is stable注释的代码。
一段性能优化代码，其Git提交信息是“PERF: reduce memory allocation in hot path”。
一段看似奇怪的错误处理，其提交信息是“HACK: workaround for API bug in service Y, see ticket Z”。验证你的原型是否能正确关联代码与这些历史上下文，并生成合理的解释。

5.3.3 关注响应速度与稳定性