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-apiVS 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): PromiseCodeContext { 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.executeCommandvscode.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): PromiseGitBlameInfo[] { const git simpleGit(root); const blame await git.raw([blame, -L, ${selection.start.line1},${selection.end.line1}, --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): Promisestring { 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 关注响应速度与稳定性缓存对相同的代码选择可以缓存LLM的响应结果避免重复调用产生不必要的成本和延迟。超时与降级设置LLM调用的超时时间如10秒。如果超时或失败可以降级为只显示Git blame信息和简单的本地分析保证工具的基本可用性。错误处理妥善处理所有可能的错误网络错误、Git仓库不存在、API密钥无效等并给出友好的用户提示。5.3.4 收集早期用户反馈将原型分享给一两个同事或朋友试用。重点关注解释的准确性他们觉得解释靠谱吗有没有明显的“幻觉”信息的实用性提供的Git历史和上下文信息对他们理解代码有帮助吗交互体验触发方式命令、右键菜单是否自然结果展示是否清晰易读 根据反馈快速迭代调整提示词、上下文收集的范围和UI呈现方式。构建这样一个原型即使功能有限也能让你深刻理解TARS所涉及的技术挑战和用户体验的精妙之处。它不仅仅是一个工具更是一种全新的、以“理解”而非“生成”为中心的开发者与代码互动范式的开端。
