- 场景描述：[图片][图片]在使用智能体执行小程序代码重构任务（提取封装重复代码、删除冗余、添加注释并生成新文件夹）时，发现生成的 NewWebXCX 文件夹中，仅保留了 images/icon/ 和 images/pic/ 的目录结构，但原项目 webXCX 中的图片文件并未被实际复制到新目录中。 这导致重构后的项目在运行时，所有图标和图片资源都无法正常加载，小程序页面出现加载失败的报错。虽然目录结构被正确创建，但缺少实际的图片文件，需要手动复制资源才能恢复功能，影响了重构任务的完整性和可用性。建议方案：在智能体的代码重构流程中，增加对静态资源文件（如图片、字体等）的识别规则，不仅要迁移目录结构，还要完整复制目录下的所有文件，确保 images/icon/、images/pic/ 等目录中的图片能被完整迁移到新文件夹。 场景描述：[图片][图片]在使用智能体执行小程序代码重构任务（提取封装重复代码、删除冗余、添加注释并生成新文件夹）时，发现生成的 NewWebXCX 文件夹中，仅保留了 images/icon/ 和 images/pic/ 的目录结构，但原项目 webXCX 中的图片文件并未被实际复制到新目录中。 这导致重构后的项目在运行时，所有图标和图片资源都无法正常加载，小程序页面出现加载失败的报错。虽然目录结构被正确创建，但缺少实际的图片文件，需要手动复制资源才能恢复功能，影响了重构任务的完整性和可用性。建议方案：在智能体的代码重构流程中，增加对静态资源文件（如图片、字体等）的识别规则，不仅要迁移目录结构，还要完整复制目录下的所有文件，确保 images/icon/、images/pic/ 等目录中的图片能被完整迁移到新文件夹。
- 场景描述：我给CodeArts代码智能体输入一段需求，代码生成速度感觉很慢，相比Trae、Qoder等能明显感觉到代码生成速度慢很多 建议方案：请显示token速率和token消耗情况 场景描述：我给CodeArts代码智能体输入一段需求，代码生成速度感觉很慢，相比Trae、Qoder等能明显感觉到代码生成速度慢很多 建议方案：请显示token速率和token消耗情况
- [图片]场景描述：作为一名小程序开发者，我在使用智能体处理代码重构任务（提取封装重复代码、删除冗余、添加注释并生成新文件夹）时，遇到了以下问题： 等待体验模糊：任务运行时，仅显示 “Working on it, please wait...”，没有任何预估完成时间，我无法判断需要等待多久，也不敢离开当前页面去处理其他任务。任务运行不灵活：一旦切换到其他任务栏目或关闭对话窗口，当前的代码处理任务可能会中断，导致之前的等待时间白费，只能全程停留在当前页面等待。多任务并行受阻：在等待长任务完成期间，无法启动新的开发任务，严重影响了开发效率。建议方案：增加任务耗时预估 在任务启动时，基于代码量和历史处理数据，给出预估完成时间（如 “预计需要 3-5 分钟”），让开发者可以合理安排后续工作。支持后台持续运行 确保任务在切换到其他对话、标签页或最小化窗口时仍能在后台正常执行，不会因界面切换而中断。任务完成通知提醒 当任务完成时，通过 VS Code 通知栏或弹窗发送提醒，方便开发者及时查看结果，无需一直等待。多任务并行处理 允许在当前任务后台运行的同时，发起新的对话或任务，提升工具的使用效率。 [图片]场景描述：作为一名小程序开发者，我在使用智能体处理代码重构任务（提取封装重复代码、删除冗余、添加注释并生成新文件夹）时，遇到了以下问题： 等待体验模糊：任务运行时，仅显示 “Working on it, please wait...”，没有任何预估完成时间，我无法判断需要等待多久，也不敢离开当前页面去处理其他任务。任务运行不灵活：一旦切换到其他任务栏目或关闭对话窗口，当前的代码处理任务可能会中断，导致之前的等待时间白费，只能全程停留在当前页面等待。多任务并行受阻：在等待长任务完成期间，无法启动新的开发任务，严重影响了开发效率。建议方案：增加任务耗时预估 在任务启动时，基于代码量和历史处理数据，给出预估完成时间（如 “预计需要 3-5 分钟”），让开发者可以合理安排后续工作。支持后台持续运行 确保任务在切换到其他对话、标签页或最小化窗口时仍能在后台正常执行，不会因界面切换而中断。任务完成通知提醒 当任务完成时，通过 VS Code 通知栏或弹窗发送提醒，方便开发者及时查看结果，无需一直等待。多任务并行处理 允许在当前任务后台运行的同时，发起新的对话或任务，提升工具的使用效率。
- [图片]场景描述：作为一名日常使用 VS Code 的前端开发者，我在使用 CodeArts Doer for Coding 插件时遇到了明显的效率问题： 布局冲突：插件默认固定在左侧活动栏，与我常用的 “文件资源管理器” 位置重叠。每次需要在 AI 对话和查看项目目录之间切换时，都要频繁点击活动栏图标，打断了开发思路。空间利用低效：当同时打开插件和文件资源管理器时，左侧会被两个面板占据，压缩了编辑器的可用空间，影响代码编写体验。多任务切换繁琐：在编写代码时，需要频繁在 AI 对话、文件目录、终端之间来回切换，操作步骤多，降低了开发效率。 建议方案：支持多区域挂载 允许插件在 VS Code 的多个区域显示，如右侧活动栏、底部面板或侧边悬浮窗口，避免与文件资源管理器等核心工具冲突。增加面板悬浮 / 拖拽能力 让插件面板可以从活动栏中拖拽出来，悬浮在编辑器任意位置，或与其他面板（如终端、输出）进行分栏组合，提升空间利用率。记忆布局偏好 支持保存用户的面板位置设置，下次打开时自动恢复到习惯的布局，减少重复调整的操作。 [图片]场景描述：作为一名日常使用 VS Code 的前端开发者，我在使用 CodeArts Doer for Coding 插件时遇到了明显的效率问题： 布局冲突：插件默认固定在左侧活动栏，与我常用的 “文件资源管理器” 位置重叠。每次需要在 AI 对话和查看项目目录之间切换时，都要频繁点击活动栏图标，打断了开发思路。空间利用低效：当同时打开插件和文件资源管理器时，左侧会被两个面板占据，压缩了编辑器的可用空间，影响代码编写体验。多任务切换繁琐：在编写代码时，需要频繁在 AI 对话、文件目录、终端之间来回切换，操作步骤多，降低了开发效率。 建议方案：支持多区域挂载 允许插件在 VS Code 的多个区域显示，如右侧活动栏、底部面板或侧边悬浮窗口，避免与文件资源管理器等核心工具冲突。增加面板悬浮 / 拖拽能力 让插件面板可以从活动栏中拖拽出来，悬浮在编辑器任意位置，或与其他面板（如终端、输出）进行分栏组合，提升空间利用率。记忆布局偏好 支持保存用户的面板位置设置，下次打开时自动恢复到习惯的布局，减少重复调整的操作。
- 场景描述：作为一名前端开发者，我在使用 CodeArts Doer for Coding 生成项目时，遇到了交互逻辑上的困扰： 需求预判偏差：当我输入 “帮我在我的资源管理器 demo 目录中生成一个 todoList 项目” 时，工具直接默认生成了 HTML+CSS+JavaScript 的前端项目，但我的实际需求是生成一个基于 Vue3+TypeScript 的工程化项目，导致生成的代码完全无法复用。缺少灵活选择：工具没有提供技术栈、框架或项目类型的确认环节，无法满足不同场景下的开发需求，增加了重复沟通和返工的成本。效率降低：需要重新描述完整需求（如 “帮我生成一个 Vue3+TS 版本的 todoList”），打断了开发思路，影响了 AI 辅助开发的流畅性。建议方案：增加需求澄清环节 当用户输入生成项目类的指令（如 “生成 todoList 项目”）时，自动触发追问，优先确认技术栈 / 框架（例如：“请问你希望使用什么语言 / 框架来生成这个 todoList 项目？比如 Vue3、React、原生 JS 等”）。支持多场景适配 针对常见的项目生成需求，提供选项式选择（如 “前端项目 / 后端项目 / 全栈项目”、“框架选择”），减少用户的描述成本。保留默认兜底逻辑 如果用户未明确指定技术栈，再默认生成原生前端版本，兼顾灵活性和效率。 场景描述：作为一名前端开发者，我在使用 CodeArts Doer for Coding 生成项目时，遇到了交互逻辑上的困扰： 需求预判偏差：当我输入 “帮我在我的资源管理器 demo 目录中生成一个 todoList 项目” 时，工具直接默认生成了 HTML+CSS+JavaScript 的前端项目，但我的实际需求是生成一个基于 Vue3+TypeScript 的工程化项目，导致生成的代码完全无法复用。缺少灵活选择：工具没有提供技术栈、框架或项目类型的确认环节，无法满足不同场景下的开发需求，增加了重复沟通和返工的成本。效率降低：需要重新描述完整需求（如 “帮我生成一个 Vue3+TS 版本的 todoList”），打断了开发思路，影响了 AI 辅助开发的流畅性。建议方案：增加需求澄清环节 当用户输入生成项目类的指令（如 “生成 todoList 项目”）时，自动触发追问，优先确认技术栈 / 框架（例如：“请问你希望使用什么语言 / 框架来生成这个 todoList 项目？比如 Vue3、React、原生 JS 等”）。支持多场景适配 针对常见的项目生成需求，提供选项式选择（如 “前端项目 / 后端项目 / 全栈项目”、“框架选择”），减少用户的描述成本。保留默认兜底逻辑 如果用户未明确指定技术栈，再默认生成原生前端版本，兼顾灵活性和效率。
- 场景描述：作为一名小程序前端开发者，我日常依赖微信开发者工具进行开发，但在使用 CodeArts Doer for Coding 智能体时遇到了明显的效率瓶颈： 开发环境割裂：需要在微信开发者工具和 VS Code 之间频繁切换，一边写小程序页面，一边要切到另一个工具里用 AI 生成代码、排查问题，打断了开发思路。代码复用繁琐：用 AI 生成的小程序组件或工具函数，需要手动复制粘贴到微信开发者工具中，无法直接同步，容易出现格式错乱或遗漏。调试体验不连贯：在调试小程序前端代码时，无法直接在当前开发工具内调用 AI 来分析报错、优化代码，需要切换工具重新描述问题，增加了沟通成本。建议方案：开发微信开发者工具专属插件 推出适配微信开发者工具的 CodeArts Doer for Coding 插件，让我们能在熟悉的小程序开发环境中直接使用 AI 能力，无需切换工具。深度适配小程序开发场景 内置小程序专属的代码生成模板（如自定义组件、页面生命周期函数、云开发接口调用），支持根据微信小程序语法规则生成可直接运行的代码。增强代码辅助能力 支持在开发工具内直接选中代码块，调用 AI 进行优化、注释生成和错误排查，提升代码质量和调试效率。实现无缝同步 让 AI 生成的代码可以一键插入到当前编辑的小程序文件中，减少复制粘贴的繁琐步骤，保证代码格式的一致性。 场景描述：作为一名小程序前端开发者，我日常依赖微信开发者工具进行开发，但在使用 CodeArts Doer for Coding 智能体时遇到了明显的效率瓶颈： 开发环境割裂：需要在微信开发者工具和 VS Code 之间频繁切换，一边写小程序页面，一边要切到另一个工具里用 AI 生成代码、排查问题，打断了开发思路。代码复用繁琐：用 AI 生成的小程序组件或工具函数，需要手动复制粘贴到微信开发者工具中，无法直接同步，容易出现格式错乱或遗漏。调试体验不连贯：在调试小程序前端代码时，无法直接在当前开发工具内调用 AI 来分析报错、优化代码，需要切换工具重新描述问题，增加了沟通成本。建议方案：开发微信开发者工具专属插件 推出适配微信开发者工具的 CodeArts Doer for Coding 插件，让我们能在熟悉的小程序开发环境中直接使用 AI 能力，无需切换工具。深度适配小程序开发场景 内置小程序专属的代码生成模板（如自定义组件、页面生命周期函数、云开发接口调用），支持根据微信小程序语法规则生成可直接运行的代码。增强代码辅助能力 支持在开发工具内直接选中代码块，调用 AI 进行优化、注释生成和错误排查，提升代码质量和调试效率。实现无缝同步 让 AI 生成的代码可以一键插入到当前编辑的小程序文件中，减少复制粘贴的繁琐步骤，保证代码格式的一致性。
- 场景描述：侧边栏的文字有时候有点小，特别是放到某些15.6寸的1920*1080分辨率的屏幕上，上面的文字就太小了[图片][图片] 场景描述：侧边栏的文字有时候有点小，特别是放到某些15.6寸的1920*1080分辨率的屏幕上，上面的文字就太小了[图片][图片]
- 场景描述：在编辑区粘贴长文本时，比如一段复制的skill提示词，会原封不动地粘贴进来，内容较长时，容易导致和手工输入的文本混杂在一起，难以区分。[图片]建议方案：建议采用其他相同产品的方案，用【Pasted XX lines】进行长文本粘贴替换，优化其显示，有效提升使用体验。[图片] 场景描述：在编辑区粘贴长文本时，比如一段复制的skill提示词，会原封不动地粘贴进来，内容较长时，容易导致和手工输入的文本混杂在一起，难以区分。[图片]建议方案：建议采用其他相同产品的方案，用【Pasted XX lines】进行长文本粘贴替换，优化其显示，有效提升使用体验。[图片]
-
【产品缺陷】处理效率随着对话长度的增加而降低 预审不通过场景描述：我对一个项目的处理越到后面智能体越卡，半天说不完一句整话。可能是因为这段对话持续太长了，占用了内存之类的，因为这时我切换到另一对话处理同一个项目就不卡了。建议方案：望改进。 场景描述：我对一个项目的处理越到后面智能体越卡，半天说不完一句整话。可能是因为这段对话持续太长了，占用了内存之类的，因为这时我切换到另一对话处理同一个项目就不卡了。建议方案：望改进。
- 场景描述：当前的智能补全功能看起来是直接与 LLM 进行单点交互的，主要依赖当前文件或有限上下文来生成补全内容。在实际开发中，如果我在 admin.py 里编写代码，并且引用了 models.py 中定义的模型类或字段：当智能补全没有读取或感知到 models.py 的内容时给出的字段、属性或方法补全往往是基于推测的“猜想结果”补全质量明显不稳定，容易出现不存在的字段或命名偏差一个对照现象是：如果我手动把 models.py 中的相关代码复制过来，作为注释或参考放在当前文件前部，智能补全的准确度和完整性就会显著提升，说明补全效果高度依赖可见上下文。[图片][图片] 建议方案：建议在智能补全机制中，引入更大范围的上下文感知能力，而不仅限于当前文件，例如：支持将 Context 扩展到项目内的其他相关文件（如自动关联 models.py、serializers.py 等）在补全时基于项目级语义索引或依赖关系分析，而不是只依赖当前可见文本当检测到跨文件引用（如 from models import XXX）时，自动将对应定义纳入补全上下文减少用户手动复制代码作为注释参考的“曲线救国”操作目标是让智能补全从“基于猜测的语言续写”，升级为“理解项目结构的代码协作者”，在真实工程场景中提供更可靠、更工程化的补全体验。最后就是现在的自动补全只要一打开，输入代码的时候编译器（我目前使用的是Pycharm）就会疯狂掉帧，特别影响体验，还有默认快捷键设置成Tap其实是不合理的，会和调整缩进冲突。 场景描述：当前的智能补全功能看起来是直接与 LLM 进行单点交互的，主要依赖当前文件或有限上下文来生成补全内容。在实际开发中，如果我在 admin.py 里编写代码，并且引用了 models.py 中定义的模型类或字段：当智能补全没有读取或感知到 models.py 的内容时给出的字段、属性或方法补全往往是基于推测的“猜想结果”补全质量明显不稳定，容易出现不存在的字段或命名偏差一个对照现象是：如果我手动把 models.py 中的相关代码复制过来，作为注释或参考放在当前文件前部，智能补全的准确度和完整性就会显著提升，说明补全效果高度依赖可见上下文。[图片][图片] 建议方案：建议在智能补全机制中，引入更大范围的上下文感知能力，而不仅限于当前文件，例如：支持将 Context 扩展到项目内的其他相关文件（如自动关联 models.py、serializers.py 等）在补全时基于项目级语义索引或依赖关系分析，而不是只依赖当前可见文本当检测到跨文件引用（如 from models import XXX）时，自动将对应定义纳入补全上下文减少用户手动复制代码作为注释参考的“曲线救国”操作目标是让智能补全从“基于猜测的语言续写”，升级为“理解项目结构的代码协作者”，在真实工程场景中提供更可靠、更工程化的补全体验。最后就是现在的自动补全只要一打开，输入代码的时候编译器（我目前使用的是Pycharm）就会疯狂掉帧，特别影响体验，还有默认快捷键设置成Tap其实是不合理的，会和调整缩进冲突。
- 场景描述：[图片]点击某条历史对话，跳出的是其中某一句话，不是该条对话的最后一句，而且还莫名其妙报错，不止一次，至少有三次以上，几乎每次都这样。建议方案：希望修复。 场景描述：[图片]点击某条历史对话，跳出的是其中某一句话，不是该条对话的最后一句，而且还莫名其妙报错，不止一次，至少有三次以上，几乎每次都这样。建议方案：希望修复。
- 场景描述：点击某条历史对话时既没有动效又没有进度条，让人不知道有没有点到，也不知道记录多久能被打开。[图片]建议方案：添加一个点击效果或加一个进度条，如“正在加载...99%”，用于加载特别长的对话记录。 场景描述：点击某条历史对话时既没有动效又没有进度条，让人不知道有没有点到，也不知道记录多久能被打开。[图片]建议方案：添加一个点击效果或加一个进度条，如“正在加载...99%”，用于加载特别长的对话记录。
- 场景描述：配置 SDK 的路径，点击左下角齿轮图标，选择设置选项，在搜索栏输入 cangjie, 然后选择侧边栏的 Cangjie Language Support 选项[图片]但如上图所示，我并没有看到“Cangjie Language Support”字样的选项。[图片] 场景描述：配置 SDK 的路径，点击左下角齿轮图标，选择设置选项，在搜索栏输入 cangjie, 然后选择侧边栏的 Cangjie Language Support 选项[图片]但如上图所示，我并没有看到“Cangjie Language Support”字样的选项。[图片]
- 场景描述：用智能体创建一个原创小程序时，一次提出了多条修改需求，原文如图：[图片]，大概15Min后对话一片空白，忘记截图了，不知道是不是因为一次的代码修改量多大，该程序的.js脚本代码行数上万（40244行），一次增删的行数大概上千行（往大了估算的），但这并不是很复杂的需求，这样就死机不太应该。建议方案：望修复。 场景描述：用智能体创建一个原创小程序时，一次提出了多条修改需求，原文如图：[图片]，大概15Min后对话一片空白，忘记截图了，不知道是不是因为一次的代码修改量多大，该程序的.js脚本代码行数上万（40244行），一次增删的行数大概上千行（往大了估算的），但这并不是很复杂的需求，这样就死机不太应该。建议方案：望修复。
-
【用户体验】打字卡顿 已实现场景描述：打字打一半突然卡住，任何操作都做不了，只能exit。用的微软输入法，其他应用都无异常，刚开始使用智能体也无异常，不知道是因为代码太长了还是怎么回事，我大概对初始程序提了六、七次修改需求。[图片] 建议方案：希望修复。 场景描述：打字打一半突然卡住，任何操作都做不了，只能exit。用的微软输入法，其他应用都无异常，刚开始使用智能体也无异常，不知道是因为代码太长了还是怎么回事，我大概对初始程序提了六、七次修改需求。[图片] 建议方案：希望修复。
上滑加载中
推荐直播
-
用码道，让你的AI作品三步上朋友圈2026/08/04 周二 19:00-20:00
林华鼎-华为云AI开发者运营负责人
从入门 · 到做AI应用 · 到企业级开发。不教编程，只教用AI · 零代码、有产出、能带走、可炫耀 · 每课人人动手实操
回顾中 -
华为云码道Agent集成与鸿蒙实战2026/08/11 周二 19:00-21:00
王一男-华为云码道产品规划专家；李炎-华为云码道产品专家；彭江敏-华为云鸿蒙端云一体化开发专家
本次直播带你解读华为云码道7月份产品新特性、新功能。更有专家演示码道Agent Space × 钉钉机器集成实战，从0到1打通消息通道；码道鸿蒙端云一体化实战，快速搭建员工签到系统。
回顾中 -
基于华为云码道，构建你的定制化AI搭子2026/08/14 周五 09:00-11:30
明亮-华为云开发者发展与支持部部长
本期直播将向您全面介绍华为云码道产品，并基于码道手把手教你部署自己的定制化AI陪伴搭子。
回顾中
热门标签