-
【功能建议】如何两个员工通过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日
- 场景描述：代码评审里有评审意见，想查看这个评审意见的文件变更。文件变更明明是A文件，跳转过去展示的页面是B文件的。[图片]点击文件变更后，跳转到文件变更页面。明明评审意见是A文件的，跳转过去url也是A文件的，但是页面内容展示的是B文件的？url是A文件的，评审意见是A文件的[图片]但是页面展示的是B文件，完全不一致。不确定到底评审的文件是哪个文件。[图片] 建议方案：代码评审对某个文件有评审意见的时候，点击文件对比查看跳转时可以跳转到正确的位置。评审的文件和跳转的文件需要是一致的。不一致的话这个功能有和没有没什么区别。 场景描述：代码评审里有评审意见，想查看这个评审意见的文件变更。文件变更明明是A文件，跳转过去展示的页面是B文件的。[图片]点击文件变更后，跳转到文件变更页面。明明评审意见是A文件的，跳转过去url也是A文件的，但是页面内容展示的是B文件的？url是A文件的，评审意见是A文件的[图片]但是页面展示的是B文件，完全不一致。不确定到底评审的文件是哪个文件。[图片] 建议方案：代码评审对某个文件有评审意见的时候，点击文件对比查看跳转时可以跳转到正确的位置。评审的文件和跳转的文件需要是一致的。不一致的话这个功能有和没有没什么区别。
- 场景描述：直接在详情页填写检视意见时，不能设置选择检视意见级别。只能默认为建议级别。[图片] 建议方案：增加设置/修改检视意见级别功能。 场景描述：直接在详情页填写检视意见时，不能设置选择检视意见级别。只能默认为建议级别。[图片] 建议方案：增加设置/修改检视意见级别功能。
- 场景描述：打开代码托管，我就一个项目，结果加载了10秒，这个速度应该要进行优化一下[图片][图片][图片] 建议方案： 场景描述：打开代码托管，我就一个项目，结果加载了10秒，这个速度应该要进行优化一下[图片][图片][图片] 建议方案：
- 场景描述：Want to allow only fast forward merge request.Set and submited Fast-forward in merge request settingsOn merge request, merge commit was created. 建议方案：When Fast-forward is chosen no merge commit should be created. 场景描述：Want to allow only fast forward merge request.Set and submited Fast-forward in merge request settingsOn merge request, merge commit was created. 建议方案：When Fast-forward is chosen no merge commit should be created.
- 场景描述：Push new branch from console.Get hook message containing ```remote: Start Git Hooks Checking [PASSED] remote: remote: To create a merge request for <branch_name>, visit: remote: https:://devcloud-g.ru-northwest-201-dev.huaweicloud.com/codehub/...```建议方案：Should be ```remote: Start Git Hooks Checking [PASSED] remote: remote: To create a merge request for <branch_name>, visit: remote: https://devcloud-g.ru-northwest-201-dev.huaweicloud.com/codehub/...```Please replace `https:://` with correct `https://` in hook. 场景描述：Push new branch from console.Get hook message containing ```remote: Start Git Hooks Checking [PASSED] remote: remote: To create a merge request for <branch_name>, visit: remote: https:://devcloud-g.ru-northwest-201-dev.huaweicloud.com/codehub/...```建议方案：Should be ```remote: Start Git Hooks Checking [PASSED] remote: remote: To create a merge request for <branch_name>, visit: remote: https://devcloud-g.ru-northwest-201-dev.huaweicloud.com/codehub/...```Please replace `https:://` with correct `https://` in hook.
- 场景描述： 代码评审的时候，查看评审的时候展示很不好用，还不如本地查看diff。 明明已经删掉了一个文件，但是diff功能的展示有歧义，看起来像没删除一样。改动是删掉了整个文件，但是这里的展示表达出的意思是这个文件还在，只是删掉了整个文件的内容。 这个diff的设计让我们的代码评审变得举步维艰。 具体看附件。 建议方案： diff功能不是只看代码内容的变更吧？文件的变更也要可视化的吧，这个diff设计成这样根本不好用啊。 左侧文件树给出更明确的ui展示。比如文件删掉就是划掉或者背景色变红，文件新增是绿色，只改动了内容没有动文件就保持现状就好。好用的竞品有很多，可以多学学，哪怕参考一下也行 场景描述： 代码评审的时候，查看评审的时候展示很不好用，还不如本地查看diff。 明明已经删掉了一个文件，但是diff功能的展示有歧义，看起来像没删除一样。改动是删掉了整个文件，但是这里的展示表达出的意思是这个文件还在，只是删掉了整个文件的内容。 这个diff的设计让我们的代码评审变得举步维艰。 具体看附件。 建议方案： diff功能不是只看代码内容的变更吧？文件的变更也要可视化的吧，这个diff设计成这样根本不好用啊。 左侧文件树给出更明确的ui展示。比如文件删掉就是划掉或者背景色变红，文件新增是绿色，只改动了内容没有动文件就保持现状就好。好用的竞品有很多，可以多学学，哪怕参考一下也行
- 场景描述： 代码托管服务是否支持集成到VSC的gitlab workflow插件 我这边提示 [图片] 建议方案： 场景描述： 代码托管服务是否支持集成到VSC的gitlab workflow插件 我这边提示 [图片] 建议方案：
- 场景描述：在项目外的更多按钮展开的下拉框，建议要添加一个“删除项目”的功能 这个非常合理的建议。因为既然从外侧可以“移动分组”，那直接删除这个项目也很合理 而现在的方案是必须进到项目里面，才能删除。 打个比方，如果说项目是桌面上的一个文件夹，那么我们在外面可以将这个文件夹拖动到其他文件夹（分组），是不是也应该右键可以直接删除 [图片] 建议方案： 场景描述：在项目外的更多按钮展开的下拉框，建议要添加一个“删除项目”的功能 这个非常合理的建议。因为既然从外侧可以“移动分组”，那直接删除这个项目也很合理 而现在的方案是必须进到项目里面，才能删除。 打个比方，如果说项目是桌面上的一个文件夹，那么我们在外面可以将这个文件夹拖动到其他文件夹（分组），是不是也应该右键可以直接删除 [图片] 建议方案：
上滑加载中
推荐直播
-
HDC深度解读系列 - Serverless与MCP融合创新，构建AI应用全新智能中枢2025/08/20 周三 16:30-18:00
张昆鹏 HCDG北京核心组代表
HDC2025期间，华为云展示了Serverless与MCP融合创新的解决方案，本期访谈直播，由华为云开发者专家(HCDE)兼华为云开发者社区组织HCDG北京核心组代表张鹏先生主持，华为云PaaS服务产品部 Serverless总监Ewen为大家深度解读华为云Serverless与MCP如何融合构建AI应用全新智能中枢
回顾中 -
关于RISC-V生态发展的思考2025/09/02 周二 17:00-18:00
中国科学院计算技术研究所副所长包云岗教授
中科院包云岗老师将在本次直播中，探讨处理器生态的关键要素及其联系，分享过去几年推动RISC-V生态建设实践过程中的经验与教训。
回顾中 -
一键搞定华为云万级资源，3步轻松管理企业成本2025/09/09 周二 15:00-16:00
阿言 华为云交易产品经理
本直播重点介绍如何一键续费万级资源，3步轻松管理成本，帮助提升日常管理效率！
回顾中
热门标签