共计 10282 个字符，预计需要花费 26 分钟才能阅读完成。
采访嘉宾 | 夏振华
编辑 | Tina
策划 | QCon 全球软件开发大会
当前，AI 编程工具呈现出迅猛发展的态势。以 Claude Code 和 Cursor 为代表的国外产品，凭借其创新的架构与交互方式迅速崭露头角；而 Cline、Replit、AmpCode 等也在积极测试新的形态。与此同时，国内厂商也在加紧布局，力求打造具备本土特色与国际竞争力的 AI 编程工具。
尽管过去一年，Agent 的能力有了显著提升，逐步从“辅助”角色转变为能够独立完成复杂任务的工具，但“上下文”问题依然是实现实用化过程中的一大难题。在开发实践中，面对庞大的代码量、复杂的模块结构，以及分散的上下文，开发者常常需要耗费大量时间进行信息检索、理解与修改。此外，文档与代码长久不同步、知识传递效率低下，以及重复编码任务占比过高，成为了制约研发效率的核心障碍。
正如 Andrej Karpathy 所言，LLM 更像一种“新操作系统”：模型相当于 CPU，上下文窗口则像 RAM，容量有限、取舍至关重要。“上下文工程”的任务就是将正确的信息填充到这块“工作内存”中，以支持后续的推理。谁能把合适的信息放入窗口，谁就更有可能在真实的工程中实现稳定的交付。
为了应对这一“上下文”的瓶颈，阿里推出了首个 Agentic 编程平台 Qoder。该平台被定位为一个面向全球市场的“创新验证平台”，像是探索前沿技术的“先锋队”。阿里表示，Qoder 能够一次性检索 10 万个代码文件，并将电商网站的前后端开发时间从数天缩短至十分钟左右。它结合了全球顶尖大模型的能力与 Agent，能够对大规模代码进行深度语义检索和持续的上下文理解，将复杂且多阶段的开发任务拆解，并由智能体逐步完成，力求通过“仓库级理解 + 任务化执行”来应对真实工程中的复杂性。
这一“重理解”的路径能否在全球市场中站稳脚跟？带着对架构哲学、技术取舍以及定位和价格等关键问题的关注，我们对 Qoder 团队的工程师夏振华进行了深入采访，围绕这三条主线展开了详细解析。
采访嘉宾：
夏振华，Qoder 团队的工程师，负责基于 LLM 的 Agentic Coding 产品的设计与研发工作。此前在蚂蚁金服和阿里云积累了多年软件研发工具链的架构设计和研发经验。目前专注于 AI Agent 技术在软件开发领域的创新应用，致力于通过 Context Engineering、Multi-Agent 系统及 Agentic RAG 等前沿技术提升开发者在日常编程及复杂任务中的体验和效果。
他将在 10 月 23 日至 25 日的 QCon 全球软件开发大会上海站发表题为“为 Coding Agent 构建智能上下文：Qoder 的 Context Engineering 实践”的演讲。
Qoder 的定位与定价
InfoQ：在开发者圈中，AI 编程工具常常被放在一起进行比较，比如 Cursor 和 Claude Code。外界甚至将 Qoder 称作“阿里版 Claude Code”或“阿里版 Cursor”。你们对这种说法有何看法？既然已经有了 Cursor 和 Claude Code，开发者或企业为什么还需要 Qoder？在这个“工具谱系”中，Qoder 应该处于何种位置？它的独特价值和差异化优势又在哪里？
夏振华：Claude Code 是一款非常出色的产品，它在 CLI 环境中率先探索并开创了 AI 编程的新方式，使得命令行这一经典的程序员交互界面焕发了新的活力。
相比之下，Qoder 不仅限于 CLI，而是一个完整的 Agentic Coding 平台，既包括 IDE 集成版本，也涵盖 CLI 工具，能够满足不同开发场景和用户偏好的需求。我们的核心优势在于工程级感知与持久记忆，能够全面理解和索引整个代码仓库的结构与历史，不仅限于单个文件的操作，而是支持跨文件、跨模块的深度语义检索、分析与修改。这种能力确保了在复杂、多轮迭代的项目中保持上下文的一致性和长期的可靠性，更加贴近真实的工程环境。
在模型层面，Qoder 支持模型的自动路由，使得不同任务能够由最合适的模型无缝切换执行，开发者无需手动选择或理解模型差异，从而减轻认知负担并提升效率。同时，我们具备任务拆解与规划能力，能够将复杂的长程任务分解为可执行的子任务，进行有序调度与跟踪，实现更完整、高质量的任务交付。
因此，Qoder 在 AI 编程工具生态中，不仅是代码生成或补全的助手，而是一个面向整个工程周期的智能研发伙伴，适用于从 vibe Coding 到日常编码，再到复杂系统构建的全链路场景。自 8 月 21 日全球首发以来，Qoder 已吸引了数十万开发者，验证了其 PMF 的成功！
InfoQ：Claude Code 和 Cursor 都曾面临推理成本和定价争议。从用户体验的角度看，Qoder 的 Credits 消耗规律并未完全公开透明。有开发者认为，根据看板数据和实际使用经验，Credits 的计费方式并非简单以调用次数计算，而更像是基于 token 消耗后进行的归一化处理。您能否具体介绍一下 Qoder 的 Credits 定价逻辑？在不同场景（如大文件检索、复杂任务、多代理并行）下，Credits 的消耗方式有何不同？
夏振华：Qoder 的 Credits 计费并非基于简单的提问次数或模型调用次数，而是依据实际的 token 消耗进行统一换算与结算。这种方式能够更准确地反映任务的真实计算量，同时避免用户在复杂任务或长上下文情况下遭受不公平的计费。我们始终为订阅用户提供全球顶尖的编程模型，确保用户获得行业领先的上下文工程能力和推理效果。
此外，我们还通过技术升级不断优化，比如提升工程检索的准确率、智能体工具的并行化优化、上下文智能压缩等能力，力求在保证效果的基础上持续降低单任务的 token 消耗，让开发者感受到我们的 Credits 用起来更加耐用。
在 Qoder 刚发布的公测期，确实收到了一些用户关于 Credits 消耗较快的反馈，我们对此十分重视，通过持续技术优化，当前最新版 Qoder 的整体耐用度相比公测期提升了 15%。
关于不同场景的 Credits 消耗，场景越复杂、处理的上下文越大、迭代步骤越多，所消耗的 token 也会随之增加，Credits 的使用量也会相应增高。我们会在 Qoder 社区开设相关专栏，分享一些使用技巧和经验，以便为大家提供参考。
InfoQ：最近有用户在 Claude Code 上使用 200 美元的包月订阅消耗出了价值 5 万美元的 token，迫使官方不得不限速。由此引发了关注：在 Qoder 的包月订阅中，是否对每月的 token 使用设定了限流或速率控制机制？你们如何平衡用户希望长时间运行代理与平台需要控制资源成本之间的矛盾？
夏振华：Qoder 为每个订阅版本设定了固定额度的 Credits，系统会根据任务的实际 token 消耗进行折算和扣减。当额度用尽后，用户将自动降级至基础模型，依然可以使用，以满足持续运行的需求，同时有效防止单一用户极端占用资源的情况。
在平衡用户长时间运行代理与平台资源成本方面，Qoder 一方面通过技术优化不断降低模型的推理成本；另一方面也鼓励开发者在提交任务时明确表达需求，减少无效调用和重复推理，从而实现资源的高效利用并保持稳定可控的用户体验。
InfoQ：自 Qoder 上线以来，用户增长情况如何？主要的增长动力来自个人开发者，还是更多来自团队和企业用户？在你们看来，下一个阶段的用户增长将依赖于哪些关键因素？
夏振华：Qoder 上线以来，用户增长速度相当迅猛。虽然具体数据无法透露，但从活跃度和使用广度来看，早期阶段的增长主要来自于对新技术和新产品充满好奇的个人开发者，尤其是海外开发者，他们乐于在日常编码、学习和探索中尝试 Qoder，并形成了良好的口碑传播。最近我们对部分订阅用户进行的调研显示，超过 40% 的用户是通过同事或朋友的推荐使用 Qoder，这让我们感到非常惊喜，口碑效应无疑胜过一切。随着用户规模的不断扩大，以及工具在复杂工程场景中的能力得到验证，团队和企业客户的比例也在不断提升，近期 Qoder Team 版也将上线。
下一个阶段的用户增长，关键在于持续提升产品的竞争力，构建更强大、具备差异化、引领市场方向的核心能力，并切实解决开发者在真实场景中的实际问题。
面向全球的技术筹码：
技术路线与差异化
InfoQ：Qoder 在设计上的核心理念是什么？它是如何做到既降低新手的上手门槛，又能满足百万行级项目的复杂需求？
夏振华：我们的设计理念是面向真实软件的智能开发，让 AI 能真正深入理解工程，参与创造，从而构建出更高质量的产品。所谓真实软件，意味着我们的目标不仅是实现演示级的小功能，而是面向长期维护、迭代与交付的真实工程。无论是几百行的原型，还是几十万行的企业代码库，Qoder 都能够融入整体架构，理解全局上下文并稳定地输出结果。
Qoder 的底层能力是高度内化的。它在后台具备工程级感知、持久记忆和任务拆解等复杂机制，能够在面对百万行级的大型代码仓库时自动“唤醒”这些能力，帮助开发者进行跨文件、跨模块的分析、检索、规划和交付复杂任务。
而对于新手而言，他们无需理解这些复杂过程。Qoder 会通过自然语言交互、即时反馈和简洁的界面，将这些高级能力隐藏在流畅的体验背后，使任何人都能轻松上手，迅速获得有价值的结果。
InfoQ：市面上的 AI 编程工具日益增多，但许多开发者觉得它们在功能和体验上差异不大，尤其是在上下文管理等关键能力上，大家的方案看起来相似，容易造成“同质化”。在您看来，团队在选择 AI 编程工具时，是否已经形成了清晰的判断标准？
夏振华：在当前市场上，AI编程工具的功能确实呈现出某种程度的相似性，例如代码自动补全和Agent模式的开发任务，因此人们容易产生“同质化”的印象。然而，实际应用中，这些功能的实现方法、扩展能力、与工程环境的结合深度，以及适用于不同规模和复杂性项目的效果，往往存在显著差异。因此，团队在挑选工具时必须特别关注这些因素。最终，企业会在效果、性价比及安全合规等维度进行综合考量。Qoder正是围绕这些关键因素进行了深入投资，为企业和开发者提供值得信赖的智能研发支持。
除了基本的Agent模式外，Qoder还推出了两个独特的功能：Repo Wiki和Quest模式，这两个功能在开发者社区中获得了积极的反馈。Repo Wiki能够自动生成项目知识库，尤其在大型代码仓库中，寻找功能实现变得尤为便利。此功能有效解决了技术文档更新滞后的难题，使新加入的团队成员能够迅速熟悉项目。
而Quest模式则是Qoder的一大亮点。Quest代表探索，是Qoder向自主编程迈出的重要一步。它主要针对复杂或耗时的开发任务，在编写详细的规范后，系统会自动规划、撰写并生成报告，多个任务可以同时并行进行，开发者只需审核它的计划。Quest上线后短短两个月，Cursor也迅速推出了Plan模式，这在某种程度上表明大家都看到了这一方向的正确性。
InfoQ：在讨论AI编程工具时，常提到“外壳”（harness），即在代理或模型外部附加的一些功能，比如优化提示词。你们是如何判断哪些能力应该直接内置在CLI中，成为Qoder的“默认体验”，而哪些则应由用户或外部工具实现呢？
夏振华：我们的取舍标准相当简单：重点在于让开发者在真实的工程环境中高效且稳妥地完成任务。默认内置的功能是跨项目通用且与正确性紧密相关的能力，包括对代码工程的全面理解（如项目结构、依赖关系、构建与测试）、持续的任务级记忆与知识沉淀，以及精细化的上下文组织和“最小必要上下文”分发，这些确保了代理始终在正确的约束和单一事实源下运行。
而企业外部系统与知识库的集成（如私有规范、流程、审批、资产库等）、个性化能力和自定义策略则由用户或外部工具自行实现。
Qoder CLI在前几天全面上线，基于全球顶尖的编程模型进行了大量的工程设计，全面提升了Agent的能力。Qoder CLI内置了轻量级的Agent框架，该框架能够高效运行在普通笔记本电脑和云端沙箱实例上，满足不同场景的开发需求。测试结果表明，Qoder CLI在空闲状态下的内存消耗比同类工具低70%，常见命令的响应时间也低于200毫秒。
Qoder CLI还内置了Quest模式（自主编程）和CodeReview能力，开发者无需深度介入，即可轻松实现以规范驱动的任务委派，允许AI自主完成开发任务。同时，用户可在命令行终端进行代码审查，快速扫描项目中的关键更改点并提供审查建议，代码审查的耗时减少了50%，而代码质量提升了一倍。
InfoQ：Claude Code的产品负责人曾强调，他们故意保持产品的简单和通用，避免在模型外堆叠过多的脚手架，因为模型能力在迅速提升，复杂结构可能成为束缚。你们在Qoder的设计中，如何判断哪些功能可以依赖模型本身的能力完成，哪些则需要工程手段来补充？
夏振华：我们的判断原则是保持Agent架构尽量简单，避免复杂的工作流程，将推理、反思和迭代尽量交给模型，以最大化模型升级带来的收益。
在一些涉及工具调用的输出质量、上下文组织与切分、记忆与状态管理、容错性与可观测性，以及外部数据与环境集成的可靠性与边界问题，则通过工程手段进行补充。
关于检索与上下文工程
InfoQ：长链式代理任务往往会消耗大量的token。Qoder在设计时是如何看待并优化这一问题的？你们会考虑哪些具体的手段？
夏振华：针对长链式代理任务，Qoder会在规划与执行阶段首先生成结构化方案，明确步骤与依赖，减少无序调用并防止偏离主线。同时，依托强大的工程检索能力，仅召回相关的代码片段，从而显著降低上下文的占用；在工具调用上实现并行化，以缩短链路并减少消耗；结合精细的上下文组合，只引入必要信息，并通过裁剪压缩策略去除冗余数据，生成摘要，避免窗口被占满，在确保任务质量的同时显著提升性价比。
InfoQ：今年大家普遍提到“代理之年”，但在实际应用中，复杂任务往往会引发数十次甚至上百次工具调用，导致上下文爆炸：一方面迅速填满窗口，另一方面还会出现“上下文腐烂”导致的性能退化。Qoder在设计时是如何解决这种“工具调用密集带来的上下文爆炸”问题的？在确保任务完成的同时，如何平衡窗口上限、性能退化与成本控制？
夏振华：在有限的上下文长度下，我们通过Context Edit能力和长期记忆机制，保留任务主线所需的关键信息，同时清理无关或过期内容，避免窗口被无效历史信息填充；结合工程级压缩与模型端摘要，将必要信息以更紧凑的形式保留，降低token占用的同时确保可用性。此外，在实际工程应用中，还需要结合不同模型的prompt cache，决定压缩策略和触发时机，以避免无谓的上下文调整带来的额外成本开销。
InfoQ：你们提到过“通过技术升级与手工压缩上下文的结合，Credits的耐用度将提升50%”。总结与压缩并不是一件简单的任务，需要非常谨慎以避免信息丢失。Qoder在上下文压缩时，如何确保意图不会被淡化、关键指令不会丢失呢？
夏振华：在进行上下文压缩时，Qoder通过精细化总结与关键代码的保留，确保在压缩后仍能维持任务主线和用户意图。我们结构化提炼任务目标、技术概念、文件摘要、问题修复记录及待办列表，并结合近期的代码改动，以使模型在精简上下文的同时保持连续性和高性能，避免偏离或丢失核心信息。需要注意的是，压缩本质上是一种有损处理，可能会出现压缩后效果变差的情况，这一点需要保持一定的心理预期。
InfoQ：在代码检索方面，有的团队选择“重型RAG管道”，例如Windsurf的分块、向量检索和重排；也有像Claude Code一样采取“代理式检索”，完全不建立索引，Cline甚至直言“不能再用2023年的办法解决今天的问题”。Qoder在实践中更倾向于哪种路线？你们如何看待“何时该建立索引，何时简单探查即可”的取舍标准？
夏振华：在Qoder的实践中，我们更倾向于构建完整的工程检索引擎，而不是完全依赖代理式的grep检索。这样可以在源代码规模较大、文件分布复杂时，通过分块、向量检索和结果重排有效提高检索的精准度和召回率，从而减少多轮模型调用，提高整体效率并优化运行成本。
对于“何时该建立索引，何时简单grep即可”的取舍标准，我们主要基于以下几点：
• 代码库规模与结构：当代码库超过一定体量、文件结构层次深且跨模块引用频繁时，建立索引能显著减少检索时间并提高相关性；而在小型项目或结构较为集中的场景中，轻量级的grep就已足够。
• 成本控制：建立索引会产生初始计算和存储开销，但长期使用中可显著降低模型调用次数和API消耗；尽管简单grep在初始没有索引成本，但在重复场景中总的调用费用可能更高。
综合而言，我们会在大型、复杂、高频的检索场景中优先使用索引，而在小型或一次性探索任务中则采用grep，这样既能保证性能，又能合理控制成本。
InfoQ：我们注意到许多厂商正在引入缓存机制，比如OpenAI的Responses API会自动缓存对话历史，Anthropic过去需要显式header来启用，现在也实现了自动化，Gemini也支持隐式缓存。缓存确实能显著降低延迟和成本，但并不能解决长上下文带来的“上下文腐烂”和性能下降问题。在Qoder的上下文工程实践中，你们如何理解缓存的价值和局限？是否会将缓存与压缩、检索等手段结合起来，以优化整体体验？
夏振华：在Qoder的上下文工程实践中，我们将缓存视为降低成本、提升性能的关键能力之一。其价值主要体现在高命中率带来的延迟降低和推理费用优化，尤其是在Agent场景中，这种高频、前序请求的重复情况，可以显著减少模型的计算开销。
然而，长期保留大量原始prompt虽然便于复用，但也可能导致上下文长度的增加，从而引发“上下文腐烂”，影响输出质量，因此必须谨慎权衡。
为此，我们会将缓存与压缩、检索增强等策略结合使用：当判断平台的缓存机制可能失效，或上下文接近模型的上限时，我们会主动优化上下文结构，提取关键信息并替换冗余内容，从而在保证命中率的同时减轻性能衰减，确保整体体验的稳定与优质。
多代理与单代理
InfoQ：在业界对多代理的看法并不一致。Cognition认为不应设立子代理，因为子代理之间的沟通效果较差；而Anthropic则强调多代理的优势。Qoder在设计时如何看待这一分歧？若设计多个代理，如何处理这些代理之间的数据、记忆和上下文割裂问题？在选择最优解、减少合并冲突、降低开发者认知负荷方面，你们是否探索过新的机制？
夏振华：关于模型能力的提升，许多观点也随之变化。例如，Devon对多代理的看法也在不断演变。Qoder在这方面的探索实践已经持续了一年多，从去年的时候开始，我们就尝试通过多代理的串联合作来完成研发任务，通过任务拆解来解决当时模型能力不足的问题。随着模型能力的进步，我们的主要架构逐渐转向基于单代理的工具调用自主迭代循环来完成任务。
目前，我们正在进行多种形式的智能代理探索，包括主从代理的组合方式，以解决上下文隔离和信息共享等问题。整体而言，项目仍处于探索阶段，后续的进展会及时与大家分享。我们的核心思路是，子代理仅需获取必要的最小输入，并以结构化的关键摘要形式进行信息回传，由主代理进行信息聚合和决策，这有助于减少上下文的割裂以及主代理的负担。
InfoQ：在社区中，常常有人对Claude Code 提出批评，认为它难以实现真正的“全自动长跑”，代理运行一段时间后总需要人工确认。Qoder是否考虑支持这种24小时不间断的运行模式？如果支持，你们将如何在用户体验与安全性之间进行权衡？
夏振华：Qoder的Quest模式是专为长时间运行的研发任务设计的。该模式采用基于规范驱动的开发方法，使得代理能够将用户需求自动转化为详尽的设计规范，并在此基础上自主完成开发、测试、重构及Bug修复等步骤，从而实现端到端的自动化研发流程。
借助于远程云端的运行能力，Quest模式能够在安全的云沙箱环境中持续执行任务，无需依赖本地环境。用户在执行过程中可随时中断或调整任务，这样既能保证长时间的稳定运行，也能有效降低安全风险。
InfoQ：许多团队在将代理迁移至云端时，会面临一个重大挑战：如何复刻开发者本地的环境？直接“克隆”本地开发环境往往过于复杂且个性化，难以实现。因此，大家开始转向容器和沙箱，以在更标准化的环境中运行代理。Qoder在云端代理的设计上是否也遭遇了类似的挑战？是否有值得分享的“黑科技”？
夏振华：确实如此，复制云端的本地环境是个不小的难题。在Qoder的Quest模式中，我们通过用户自定义的Dockerfile作为基础环境来解决这个问题，系统会先进行验证和构建，然后在每次任务执行之前根据相应的提交记录进行检出，并运行用户提供的安装和初始化脚本，确保每次执行都是可重复和可隔离的。
评测方法与“榜单偏差”的纠正
InfoQ：Qoder是如何收集和利用用户反馈的？在阿里及企业客户中分别采用了怎样的机制？你们在评测（evals）方面更注重什么？是端到端的触发型评测，还是能力型评测？
夏振华：关于用户反馈的收集与利用，Qoder遵循用户授权或主动提供的原则，确保符合相关隐私条款和企业的安全规范。无论是阿里内部团队还是企业客户，都可以通过IDE内置反馈入口、官方邮件或论坛提交意见和问题。对于阿里内部团队，我们建立了更为实时的沟通机制，例如通过钉钉协作群，促进研发、测试与业务团队提前体验新版本，以便在真实工程场景中迅速反馈问题并推动迭代优化。
在评测方面，我们涵盖了主要的研发场景，包括前端、后端和客户端开发等，以及主流编程语言的多种任务类型——从Bug修复、需求实现到代码重构和结构优化等。我们关注整体的端到端效果，评估任务从触发到交付的全过程质量，同时也重视核心能力的精准评测，例如代码生成质量和检索准确性。在此基础上，我们还会进一步分析过程中的成本消耗和执行效率，以确保整体表现既高效又稳定。
InfoQ：我们了解到市面上的编程工具都声称自己在开放基准测试中表现最佳，但这些基准往往无法涵盖企业真实的复杂场景，如超大规模的单体仓库、成百上千个微服务以及大规模迁移和依赖升级。Qoder在评估和优化时，如何避免只在“排行榜”上好看，而是能够真正解决企业开发中的难题？
夏振华：确实，这些开放基准测试通常难以覆盖企业真实复杂工程中的研发场景。因此，我们建立了自己的评测集，覆盖的维度比开放基准测试更加广泛，包括前端、后端和客户端等不同研发场景和多种任务类型——从Bug修复到需求实现，再到代码重构、架构优化和跨服务依赖调整等。与许多工具仅在有限样例中“跑分”不同，Qoder的评测环境更贴近企业真实的研发项目。
InfoQ：在探索模型边界时，有人提出要“推模型一把”，看看它是否能展现出新的能力。结合你们的经验，当模型未达预期时，如何快速判断原因是提示词设计不当、模型选型问题，还是模型本身的能力瓶颈？
夏振华：我们通常会先用一组简单可控的基准任务来建立下限。如果通过改写提示词或微调工具可以显著提升效果，通常说明问题出在提示词设计不当或与该模型的适配性。相同的prompt和评测数据下横向替换不同模型时，如果表现差异明显，则是模型选型的问题；如果各模型均以类似方式失败，并且引入few-shot或思维链也未能明显改善，则可能是模型能力的瓶颈。
另一个可以参考的点是查看厂商是否提供基于模型的开源产品或官方最佳实践。如果经过调整后仍无法达标，可能更倾向于模型能力的瓶颈。
实践方法与路线图
InfoQ：最后能否分享一些Qoder的使用技巧？
夏振华：首先，任务描述一定要尽量一次性说明清楚，技术栈、功能细节和规范要求都尽量完整，否则反复补充和询问不仅浪费时间，还会增加成本并影响整体效果。
其次，可以在项目中添加一个规则文件，明确代码风格、文件结构及规范要求，这样Qoder生成的内容会更符合项目标准。
此外，Qoder具备智能记忆功能，关键的业务规则或曾经遇到的问题我会主动让其记录下来，例如API的认证方式，这样在以后的使用中就无需反复强调。
会话管理同样重要，进行与当前任务无关的编码工作时，最好新建一个独立会话。如果某个会话的历史上下文过长且不相关，可以主动触发压缩，仅保留核心信息，这样后续的响应会更快速且准确。
版本控制也极为重要，我会及时提交（commit）每个功能模块，以便在出现问题时能迅速回退。
InfoQ：展望未来，Qoder最希望成为怎样的产品？如果一定要与Cursor、Claude Code和Lovable进行对比，你们最想在技术层面超越的“关键点”是什么？
夏振华：我们的目标是成为面向真实工程的Agentic Coding Platform，不仅仅是“会写代码”，而是能够实现从需求到可合并PR的全流程执行者，深入理解代码仓库、做出系统级设计决策，并产出高质量、易于维护的变更代码——“Think deeper, Build better”。
声明：本文为InfoQ整理，不代表平台观点，未经许可禁止转载。
今日好文推荐
活动推荐
