- 场景描述：不是公测早就结束了吗，现在只有免费500万/月，这不是虚假宣传吗 建议方案：去掉过时的banner[图片] 场景描述：不是公测早就结束了吗，现在只有免费500万/月，这不是虚假宣传吗 建议方案：去掉过时的banner[图片]
- 描述问题 (Description) 独立进程加载修改后的 vod_tools_impl.py,同时 /usr/local/bin/gitcode-issue 已被临时改名。若本 issue 创建成功,证明创建链路完全不依赖 wrapper。 复现步骤 (To Reproduce) 独立进程加载修改后的 vod_tools_impl.py,同时 /usr/local/bin/gitcode-issue 已被临时改名。若本 issue 创建成功,证明创建链路完全不依赖 wrapper 预期行为 (Expected behavior) 成功,证明创建链路完全不依赖 wrapper。 声音来源(Voice Source) CLI 描述问题 (Description) 独立进程加载修改后的 vod_tools_impl.py,同时 /usr/local/bin/gitcode-issue 已被临时改名。若本 issue 创建成功,证明创建链路完全不依赖 wrapper。 复现步骤 (To Reproduce) 独立进程加载修改后的 vod_tools_impl.py,同时 /usr/local/bin/gitcode-issue 已被临时改名。若本 issue 创建成功,证明创建链路完全不依赖 wrapper 预期行为 (Expected behavior) 成功,证明创建链路完全不依赖 wrapper。 声音来源(Voice Source) CLI
- 描述问题 (Description) 在使用VOD反馈收集技能时，需要通过AtomGit-GO进行二维码扫描授权登录。当前二维码以ASCII形式在终端展示，在部分终端环境下识别率不高，建议同时提供URL链接作为备选扫码方式。整体流程可以走通，但首次登录的引导说明可以更清晰一些。 复现步骤 (To Reproduce) 用户尝试提交一条VOD反馈，触发deliver流程时返回need_login，进入二维码扫描授权流程 预期行为 (Expected behavior) 二维码清晰可扫，或提供更友好的备选登录方式，首次登录引导更加明确 声音来源 (Voice Source) VOD-Collector, vod-collector 描述问题 (Description) 在使用VOD反馈收集技能时，需要通过AtomGit-GO进行二维码扫描授权登录。当前二维码以ASCII形式在终端展示，在部分终端环境下识别率不高，建议同时提供URL链接作为备选扫码方式。整体流程可以走通，但首次登录的引导说明可以更清晰一些。 复现步骤 (To Reproduce) 用户尝试提交一条VOD反馈，触发deliver流程时返回need_login，进入二维码扫描授权流程 预期行为 (Expected behavior) 二维码清晰可扫，或提供更友好的备选登录方式，首次登录引导更加明确 声音来源 (Voice Source) VOD-Collector, vod-collector
- 来源: GitCode Issue #208 by 吕军涛 (https://gitcode.com/developer-skill/vod-skill/issues/208)功能建议 问题描述 AgentArts（智果）智能体平台的 MCP（Model Context Protocol）数量特别少，可用的 MCP 连接器覆盖面不足，限制了智能体与外部系统的集成能力。 当前状况 AgentArts 平台内置的 MCP 数量很少 常见的第三方服务（如 GitCode、GitHub、Jira、数据库、监控系统等）缺少对应的 MCP 连接器 用户需要自行开发或寻找 MCP Server，增加了使用门槛 期望行为 希望 AgentArts 能增加更多内置 MCP 连接器，覆盖常见场景，例如： 代码托管平台：GitCode、GitHub、GitLab 项目管理：Jira、飞书项目、Notion 数据库：MySQL、PostgreSQL、Redis、Elasticsearch 云服务：OBS、ECS、RDS、VPC 等华为云服务 监控运维：Prometheus、Grafana、CloudWatch 文档处理：飞书文档、Confluence、Wiki 消息通知：飞书、钉钉、企业微信、Slack CI/CD：Jenkins、GitLab CI、CodeArts 流水线 AI/ML：ModelArts、HuggingFace、OpenAI 影响分析 MCP 数量少导致： 智能体无法方便地调用外部工具和系统 用户需要自行开发 MCP Server，技术门槛高 与竞品（如 Claude MCP 生态、OpenAI Function Calling 生态）相比竞争力不足 限制了 AgentArts 在复杂业务场景中的应用 与行业对比 当前行业趋势是 MCP 协议生态快速扩展，各大厂商都在积极丰富 MCP 连接器库。AgentArts 作为 Agent 运行时平台，MCP 生态的丰富程度直接影响其竞争力。 环境信息 产品：华为云 AgentArts（智果）智能体平台 提交人：吕军涛（songspace） 提交时间：2026-07-06 来源: GitCode Issue #208 by 吕军涛 (https://gitcode.com/developer-skill/vod-skill/issues/208)功能建议 问题描述 AgentArts（智果）智能体平台的 MCP（Model Context Protocol）数量特别少，可用的 MCP 连接器覆盖面不足，限制了智能体与外部系统的集成能力。 当前状况 AgentArts 平台内置的 MCP 数量很少 常见的第三方服务（如 GitCode、GitHub、Jira、数据库、监控系统等）缺少对应的 MCP 连接器 用户需要自行开发或寻找 MCP Server，增加了使用门槛 期望行为 希望 AgentArts 能增加更多内置 MCP 连接器，覆盖常见场景，例如： 代码托管平台：GitCode、GitHub、GitLab 项目管理：Jira、飞书项目、Notion 数据库：MySQL、PostgreSQL、Redis、Elasticsearch 云服务：OBS、ECS、RDS、VPC 等华为云服务 监控运维：Prometheus、Grafana、CloudWatch 文档处理：飞书文档、Confluence、Wiki 消息通知：飞书、钉钉、企业微信、Slack CI/CD：Jenkins、GitLab CI、CodeArts 流水线 AI/ML：ModelArts、HuggingFace、OpenAI 影响分析 MCP 数量少导致： 智能体无法方便地调用外部工具和系统 用户需要自行开发 MCP Server，技术门槛高 与竞品（如 Claude MCP 生态、OpenAI Function Calling 生态）相比竞争力不足 限制了 AgentArts 在复杂业务场景中的应用 与行业对比 当前行业趋势是 MCP 协议生态快速扩展，各大厂商都在积极丰富 MCP 连接器库。AgentArts 作为 Agent 运行时平台，MCP 生态的丰富程度直接影响其竞争力。 环境信息 产品：华为云 AgentArts（智果）智能体平台 提交人：吕军涛（songspace） 提交时间：2026-07-06
-
【产品缺陷】代码的历史提交记录 预审不通过场景描述：代码历史提交记录页面。页面没法下滑。。。 建议方案： 场景描述：代码历史提交记录页面。页面没法下滑。。。 建议方案：
- 场景描述：在华为云上做代码管理，但是工作量需要汇总至内部cde平台，统计个人代码量，何时可以打通 建议方案：如有成熟方案请告知 场景描述：在华为云上做代码管理，但是工作量需要汇总至内部cde平台，统计个人代码量，何时可以打通 建议方案：如有成熟方案请告知
-
【产品缺陷】流水线角色权限设置保存无效 预审不通过场景描述：修改流水线角色权限，点击保存无效 建议方案：优化 场景描述：修改流水线角色权限，点击保存无效 建议方案：优化
- 场景描述：代码打Tag时会触发流水线，流水线目前可以填3个参数 分支、tag以及描述。分支及tag可以通过【系统预定义参数】获取，描述无法获取。流水线触发后希望能使用webhook，通知tag的描述信息。 建议方案：在系统预定义参数中添加描述信息。 [图片][图片] 场景描述：代码打Tag时会触发流水线，流水线目前可以填3个参数 分支、tag以及描述。分支及tag可以通过【系统预定义参数】获取，描述无法获取。流水线触发后希望能使用webhook，通知tag的描述信息。 建议方案：在系统预定义参数中添加描述信息。 [图片][图片]
-
【功能建议】如何两个员工通过fork协作 预审不通过场景描述：如何两个员工通过fork协作 建议方案： 场景描述：如何两个员工通过fork协作 建议方案：
-
【功能建议】CodeArts代码托管 预审不通过场景描 建议方案： 场景描 建议方案：
- A分支向B分支提交mr，B分支后面更新过，但是这个mr没有更新，且没有冲突提醒。Patch1.2分支上的package.json version 已经是1.2.2了。但是这个评审显示的Patch1.2分支仍然是1.2.1，不仅没有更新也没有冲突提醒，这个功能可以正常使用吗？ [图片]同一时间同一个分支的代码展示不一致[图片] A分支向B分支提交mr，B分支后面更新过，但是这个mr没有更新，且没有冲突提醒。Patch1.2分支上的package.json version 已经是1.2.2了。但是这个评审显示的Patch1.2分支仍然是1.2.1，不仅没有更新也没有冲突提醒，这个功能可以正常使用吗？ [图片]同一时间同一个分支的代码展示不一致[图片]
- 场景描述： [图片] 建议方案： 场景描述： [图片] 建议方案：
- 场景描述：在codeArts代码评审的时候，有评审意见，想看评审意见对应的代码，无法查看，一直显示操作失败，影响使用[图片]图片如下，有评审意见想看在哪一行，根本点不开，一致显示操作失败。[图片]建议方案： 可以正常查看评审意见，可以正常使用页面的功能。 场景描述：在codeArts代码评审的时候，有评审意见，想看评审意见对应的代码，无法查看，一直显示操作失败，影响使用[图片]图片如下，有评审意见想看在哪一行，根本点不开，一致显示操作失败。[图片]建议方案： 可以正常查看评审意见，可以正常使用页面的功能。
- API: GetAllRepositoryByProjectId; 产品: CodeHub; 问题描述: page_index传入100以上无返回结果 API: GetAllRepositoryByProjectId; 产品: CodeHub; 问题描述: page_index传入100以上无返回结果
-
【功能建议】codeart定位不明确 预审不通过尊敬的 CodeArts 开发团队：您好！作为一名长期使用 Visual Studio Code 的开发者，我近期尝试使用了华为推出的 CodeArts IDE（以下简称 CodeArt），在此过程中感受到该工具在功能设计和用户体验上与 VSCode 的原生理念存在较大差异。希望能通过以下几点反馈，协助贵团队更好地打磨产品、理解用户、提升体验。一、理念背离：从“极简”到“繁重”的转变VSCode 一直秉持着 “Do less is more” 的设计理念，核心思想是：少即是多，保留最小必要集，将自由度和可扩展性交还给开发者。这种极简、灵活、模块化的方式恰好满足了广大开发者个性化、快速迭代的工作习惯。而 CodeArt 在架构和交互层面，借鉴了大量 JetBrains 系 IDE 的设计思路，呈现出一种高度集成、厚重、臃肿的体验，这种思路虽然适合部分偏向全家桶式开发的用户，但对于习惯轻量级 VSCode 工作流的开发者来说，使用体验并不友好。具体体现如下：强依赖 CodeArts 生态：许多功能过于依赖平台自身服务，缺乏独立性。界面臃肿，启动缓慢：大量预置插件和窗口堆叠，违背了 VSCode 一贯“启动快、用多少装多少”的哲学。无法自由裁剪功能：插件预装且部分无法卸载，违背了 VSCode 灵活裁剪、自定义的设计初衷。代码智能提示干扰过重：如同 JetBrains 系过度提示一样，反而影响思考流程，降低效率。二、目标用户理解不足CodeArt 的定位应当是提升国产 IDE 的竞争力，但其当前表现却在“看齐 JetBrains”与“照搬 VSCode”之间徘徊，缺乏对目标用户的深入调研和理解。JetBrains 用户会觉得不如原版稳定、生态不如；VSCode 用户则会觉得臃肿、控制感缺失、不灵活；新用户则被复杂的界面和生态限制劝退。如果不能聚焦目标用户画像并为其提供定制化、差异化的核心价值，CodeArt 难以在竞争激烈的 IDE 市场中立足。三、建议与改进方向为使 CodeArt 更贴近开发者真实需求，建议从以下几个方向思考和优化：回归轻量化本质保持 VSCode 的极简哲学，避免“集成一切”，让开发者自由选择所需功能。加强插件生态兼容性尽量与 VSCode 原生插件生态保持兼容，不重复造轮子，也避免做“阉割版”替代。提供“精简模式”或“原生模式”对喜欢原生 VSCode 的用户提供“干净启动”选项，减少无用干扰和预装插件。更开放的用户参与机制建议通过 GitHub、调研问卷或社区机制，倾听用户声音，收集真实反馈并迭代。明确定位：服务谁、解决什么问题是为 DevOps 提供深度整合？还是为国产云平台做入口？界定清晰、设计才能不跑偏。鸿蒙端尽快整改，交由上游vscode团队进行统一维护鸿蒙端希望能将java等组件作为单独的包剥离，不要一起分发总之，我们十分支持华为发展国产开发工具的努力，也相信 CodeArt 拥有成为优秀国产 IDE 的潜力。但前提是：必须走一条属于自己的路，而非盲目集成、模仿或取悦所有人。希望这份建议能为您团队提供参考。期待 CodeArt 在未来的版本中，更加理解并尊重开发者的选择。此致敬礼！一位长期 VSCode 使用者2025年7月9日 尊敬的 CodeArts 开发团队：您好！作为一名长期使用 Visual Studio Code 的开发者，我近期尝试使用了华为推出的 CodeArts IDE（以下简称 CodeArt），在此过程中感受到该工具在功能设计和用户体验上与 VSCode 的原生理念存在较大差异。希望能通过以下几点反馈，协助贵团队更好地打磨产品、理解用户、提升体验。一、理念背离：从“极简”到“繁重”的转变VSCode 一直秉持着 “Do less is more” 的设计理念，核心思想是：少即是多，保留最小必要集，将自由度和可扩展性交还给开发者。这种极简、灵活、模块化的方式恰好满足了广大开发者个性化、快速迭代的工作习惯。而 CodeArt 在架构和交互层面，借鉴了大量 JetBrains 系 IDE 的设计思路，呈现出一种高度集成、厚重、臃肿的体验，这种思路虽然适合部分偏向全家桶式开发的用户，但对于习惯轻量级 VSCode 工作流的开发者来说，使用体验并不友好。具体体现如下：强依赖 CodeArts 生态：许多功能过于依赖平台自身服务，缺乏独立性。界面臃肿，启动缓慢：大量预置插件和窗口堆叠，违背了 VSCode 一贯“启动快、用多少装多少”的哲学。无法自由裁剪功能：插件预装且部分无法卸载，违背了 VSCode 灵活裁剪、自定义的设计初衷。代码智能提示干扰过重：如同 JetBrains 系过度提示一样，反而影响思考流程，降低效率。二、目标用户理解不足CodeArt 的定位应当是提升国产 IDE 的竞争力，但其当前表现却在“看齐 JetBrains”与“照搬 VSCode”之间徘徊，缺乏对目标用户的深入调研和理解。JetBrains 用户会觉得不如原版稳定、生态不如；VSCode 用户则会觉得臃肿、控制感缺失、不灵活；新用户则被复杂的界面和生态限制劝退。如果不能聚焦目标用户画像并为其提供定制化、差异化的核心价值，CodeArt 难以在竞争激烈的 IDE 市场中立足。三、建议与改进方向为使 CodeArt 更贴近开发者真实需求，建议从以下几个方向思考和优化：回归轻量化本质保持 VSCode 的极简哲学，避免“集成一切”，让开发者自由选择所需功能。加强插件生态兼容性尽量与 VSCode 原生插件生态保持兼容，不重复造轮子，也避免做“阉割版”替代。提供“精简模式”或“原生模式”对喜欢原生 VSCode 的用户提供“干净启动”选项，减少无用干扰和预装插件。更开放的用户参与机制建议通过 GitHub、调研问卷或社区机制，倾听用户声音，收集真实反馈并迭代。明确定位：服务谁、解决什么问题是为 DevOps 提供深度整合？还是为国产云平台做入口？界定清晰、设计才能不跑偏。鸿蒙端尽快整改，交由上游vscode团队进行统一维护鸿蒙端希望能将java等组件作为单独的包剥离，不要一起分发总之，我们十分支持华为发展国产开发工具的努力，也相信 CodeArt 拥有成为优秀国产 IDE 的潜力。但前提是：必须走一条属于自己的路，而非盲目集成、模仿或取悦所有人。希望这份建议能为您团队提供参考。期待 CodeArt 在未来的版本中，更加理解并尊重开发者的选择。此致敬礼！一位长期 VSCode 使用者2025年7月9日
上滑加载中
推荐直播
-
用码道，让你的AI作品三步上朋友圈2026/08/04 周二 19:00-20:00
林华鼎-华为云AI开发者运营负责人
从入门 · 到做AI应用 · 到企业级开发。不教编程，只教用AI · 零代码、有产出、能带走、可炫耀 · 每课人人动手实操
回顾中 -
华为云码道Agent集成与鸿蒙实战2026/08/11 周二 19:00-21:00
王一男-华为云码道产品规划专家；李炎-华为云码道产品专家；彭江敏-华为云鸿蒙端云一体化开发专家
本次直播带你解读华为云码道7月份产品新特性、新功能。更有专家演示码道Agent Space × 钉钉机器集成实战，从0到1打通消息通道；码道鸿蒙端云一体化实战，快速搭建员工签到系统。
回顾中
热门标签