一键开通华为云码道 CodeArts 代码智能体Developer Events_Developer Alliance-Huawei Cloud一、为什么这次不从零做 Demo而是让 AI 接手一个已有项目最近体验华为云码道 CodeArts 代码智能体时我没有选择重新生成一个只有几个页面的小 Demo而是把一个已经具备较完整功能的跨端阅读器项目交给了码道。这个阅读器最初使用 HTML、CSS、JavaScript 开发并通过 Capacitor 封装 Android 版本已经具备电子书导入、书架管理、TXT 阅读、PDF 阅读、阅读进度保存、书签笔记、全文搜索、朗读、阅读统计等功能。项目功能已经不少但随着代码逐渐增加也开始出现一些典型的“第二阶段问题”功能能用但体验还有明显的优化空间。例如导入较大的 TXT 文件后内容解析和页面渲染可能出现等待章节较多时跳转后的定位体验还不够顺畅阅读器同时存在 Web 和 Android 两套运行场景修改代码后还需要考虑构建、同步和测试流程。所以这次我给华为云码道的任务不再是简单的“帮我写一个阅读器。”而是先理解一个已有项目再找出真正影响使用体验的问题在不破坏已有功能的前提下进行优化并完成可验证的工程交付。这也是我这次最想测试 CodeArts 代码智能体的地方。二、项目介绍一个可以在浏览器和 Android 上运行的跨端阅读器项目名称暂定ReadFlow / FlowReader 跨端阅读器项目主要面向 TXT、PDF 等本地阅读场景希望做到文件导入后可以直接进入书架管理TXT 自动分析章节阅读位置自动保存支持章节跳转和继续阅读支持书签、笔记和搜索支持 PDF 文件阅读支持朗读支持阅读时间、阅读进度等统计同一套前端代码既可以运行在浏览器也可以通过 Capacitor 打包为 Android 应用。目前项目的核心技术栈为模块技术页面开发HTML / CSS / JavaScriptWeb 运行BrowserAndroid 封装CapacitorTXT 阅读JavaScript 文件解析PDF 阅读PDF 渲染模块数据保存浏览器本地存储版本管理AtomGitAI 辅助开发华为云码道 CodeArts 代码智能体项目优化前的阅读器首页三、这次真正要解决的问题是什么我没有直接让 Agent “自由发挥”而是先把问题拆成了不同优先级。第一阶段并不追求一次重构整个阅读器而是优先解决对实际使用影响最大的部分。3.1 统一项目的构建、同步和测试流程跨端项目和普通网页项目的区别之一是修改前端代码之后往往还需要同步到 Android 工程。如果开发过程中每次都靠手工记住npm run build npx cap sync android很容易出现“网页代码已经是新的但 Android 工程还是旧版本”的情况。因此第一步是希望码道检查项目现有的 package scripts、Capacitor 配置以及测试流程把常用操作统一起来。目标不是做一个很复杂的 CI/CD而是先让项目拥有一个更可靠的开发闭环修改代码 ↓ 执行测试 ↓ 构建 Web ↓ 同步 Android ↓ 运行验证对于 AI 修改已有项目而言这一步非常重要。因为如果没有稳定的验证流程即使 Agent 写出了代码也很难判断它是否影响了项目原本的功能。3.2 大 TXT 文件不应该一次性“全部塞进页面”第二个重点是 TXT 阅读性能。小文件通常感觉不明显但当 TXT 文件达到几 MB、几十 MB甚至包含上千个章节时如果每次进入阅读器都读取完整文件 → 解析完整文本 → 构造大量 DOM → 一次性显示页面压力会快速增加。因此这次优化的核心思路之一是把“整个文件就是一个页面”逐步调整为“文件负责存储章节负责组织当前阅读窗口负责显示”。也就是说即使一本书非常大用户真正需要立即看到的也只是当前章节以及附近少量内容。这样既可以降低页面瞬间需要处理的数据量也为后续继续阅读、章节跳转和搜索定位提供统一的基础。优化前滑动页面效果——会出现加载过慢加载不出来现象3.3 章节跳转不仅要“跳过去”还要保证阅读位置正确阅读器里还有一个很容易被忽略的问题章节列表能点击并不代表章节跳转体验已经完成。例如用户第 15 章阅读到 63% ↓ 退出应用 ↓ 重新进入 ↓ 继续阅读理想状态应该恢复到原来的章节和位置。而如果用户主动从目录进入第 30 章则应该进入第 30 章对应的位置而不是继续使用旧章节的滚动进度。因此这次我希望码道把章节索引当前章节当前阅读位置自动恢复主动章节跳转搜索结果跳转这些原本相对分散的逻辑重新检查一遍。目标不是单独修一个按钮而是让不同入口最终走向相对统一的“阅读定位逻辑”。四、先让华为云码道理解项目而不是立即修改代码进入华为云码道 CodeArts 后我首先关联自己的 AtomGit 项目。第一轮我没有直接要求修改代码而是先让 Agent 做项目分析。提示词的大致思路如下请先分析当前仓库中的跨端阅读器项目暂时不要修改代码。 重点分析 1. 项目的目录结构和技术栈 2. TXT 文件从导入到阅读页面显示的完整数据流 3. TXT 章节解析逻辑 4. 阅读进度保存和恢复逻辑 5. 章节跳转和搜索结果定位逻辑 6. Web 与 Capacitor Android 的构建、同步流程 7. 当前是否存在大文件一次性读取、一次性渲染、 重复解析或不必要 DOM 更新的问题 8. 当前自动化测试覆盖哪些模块。 最后请给出 - 当前架构总结 - 可能的性能瓶颈 - 可以优化但风险较低的部分 - 修改可能影响的文件 - 推荐的实施顺序。 这一轮只分析不修改代码。这里我觉得是整个过程比较重要的一点面对已有项目我更倾向于先让 AI “读懂”然后再让它“动手”。如果一开始只告诉它“帮我优化性能”它很容易修改过多文件甚至改变原来的数据结构。第一次分析仓库后的回复截图五、第二轮把“优化性能”变成可执行任务完成项目分析之后我再给 Agent 下发真正的修改任务。相比一句帮我优化 TXT 阅读。我更希望需求里面同时包含优化对象 不能破坏的功能 验收方法。例如请基于刚才的项目分析对 TXT 阅读链路进行第一阶段优化。 主要目标 1. 优化较大 TXT 文件的读取与渲染过程 2. 避免把整本书内容一次性创建为大量 DOM 3. 优先按章节或阅读窗口加载当前需要显示的内容 4. 保留现有 TXT 自动分章能力 5. 保证章节目录可以正常跳转 6. 保证退出并重新进入后可以恢复阅读章节和进度 7. 搜索结果跳转后应定位到正确章节和内容 8. 不影响 PDF 阅读模块 9. 不删除书签、笔记、朗读、阅读统计等已有能力 10. 尽量保持现有数据格式兼容避免让用户已有阅读记录失效。 同时检查项目现有的构建和测试命令。 修改完成后请 1. 列出实际修改的文件 2. 说明每个文件修改原因 3. 执行能够运行的自动化测试 4. 执行 Web 构建 5. 如果环境允许执行 Capacitor Android 同步 6. 明确说明哪些项目已经自动验证哪些仍需要人工运行验证。 不要因为优化性能而大范围重写无关模块。这一次提示词相比“写一个功能”更长但是对已有工程来说反而更安全。因为我希望 Agent 明确知道优化不是把原代码推倒重来而是在保留行为兼容的前提下减少不必要的工作量。六、码道修改代码后我重点检查了什么AI 完成任务并不等于项目已经完成。我主要从三个方向检查代码。6.1 是否真的减少了不必要的渲染首先检查 TXT 阅读页面。优化前最需要警惕的是container.innerHTML wholeBookContent;这一类把大量文本一次性交给页面的处理方式。更合理的方向是让页面只负责当前需要显示的内容例如function renderCurrentChapter(chapterIndex) { const chapter chapters[chapterIndex]; readerContent.textContent chapter.content; restoreChapterProgress(chapterIndex); }如果章节本身依然特别大还可以进一步拆成阅读窗口。最终项目里到底采用“章节级渲染”还是“窗口级渲染”要根据实际代码结构决定。这里不会为了追求复杂度强行重构。6.2 章节跳转和续读是不是共用了正确的数据另一个检查重点是进度状态是否出现多套来源。例如{ bookId: ..., chapterIndex: 26, progress: 0.63 }重新打开图书时应读取这组状态。但如果用户主动点击目录目录 → 第 38 章系统则需要先切换章节再使用第 38 章自己的初始位置而不是错误恢复第 26 章的滚动坐标。这种问题单独测试某个按钮时不一定能发现但把打开 → 阅读 → 退出 → 重进 → 跳章节 → 搜索 → 再退出串成一个完整流程就容易暴露出来。6.3 修改 Web 代码之后Android 版本是否同步项目还使用 Capacitor 封装 Android所以我同时要求检查跨端同步流程。例如npm run build npx cap sync android后续如果项目脚本已经进行了统一也可以直接使用新的组合命令。这样做的目的是减少一种很常见的问题浏览器里已经修好了但打包出来的 Android 版本还是旧代码。七、实际运行效果不只看 Agent 说“完成”完成代码修改后我会分别进行浏览器端和 Android 端验收。重点测试以下几种场景测试场景验收目标普通 TXT可以正常导入、分章和阅读较大 TXT打开和切换章节过程正常章节跳转点击目录后进入正确章节继续阅读关闭后重新打开恢复原位置搜索定位搜索结果可以进入对应正文书签/笔记原有数据及功能不受影响PDFTXT 优化不影响 PDF 阅读Web浏览器运行正常AndroidCapacitor 同步后运行正常八、优化前后我更关注“用户等待了多久”性能优化如果只写“代码结构更加合理。”其实很难说明效果。所以最终验收时我还准备选择相同 TXT 文件对优化前后的关键过程做一次简单对比。例如记录项目优化前优化后测试 TXT 大小1.15 MB (1,206,396 字节)【相同文件】文件打开耗时快快首次正文显示正常正常章节切换正常正常继续阅读定位会出现失效情况稳定搜索结果跳转无法正确跳转可实现功能即使最后提升并没有想象中夸张只要能够说明修改前后的真实变化以及为什么发生变化这次优化过程就有意义。优化前优化后九、这次使用码道我觉得最有价值的不是“生成代码”体验这种已有项目优化任务后我对 AI 编程智能体的使用方式有了一个比较明显的变化。以前使用 AI 写代码经常是我提一个需求 → AI 输出代码 → 我复制进去 → 报错再继续问而代码智能体面对一个完整仓库时可以变成读取项目 → 理解结构 → 找到相关代码 → 制定修改范围 → 修改多个关联文件 → 执行测试和构建 → 根据结果继续修复 → 提交到仓库对于一个已经有一定代码量的项目我认为后面这种方式更加有价值。尤其是这次我没有把提示词重点放在“请帮我写多少代码。”而是放在“现在的问题是什么、哪些行为不能改变、怎样证明修改是正确的。”这也是我这次使用华为云码道最大的体会之一。十、几个实际开发中的经验1. 第一轮不要急着改代码对于已有仓库可以先让 Agent 分析项目。尤其需要让它找出数据从哪里进入中间经过哪些模块状态保存在哪里哪几个功能依赖同一份数据。理解清楚之后再改风险会小很多。2. 提示词最好写上“不能破坏什么”例如这次明确要求不影响 PDF保留已有阅读记录兼容不删除书签笔记不为了性能优化大规模重写无关代码。这些约束和“要实现什么”同样重要。3. 自动测试和人工验收需要区分即使 Agent 告诉我Test Passed Build Success最终仍然需要把项目实际打开。因为像滚动位置对不对目录跳转是否自然手机页面是否溢出大文件切换有没有明显停顿这些体验问题仅凭构建成功无法完全判断。4. AI 最适合处理“目标明确的工程问题”这次我没有要求一次性“全面优化整个项目”。第一阶段只集中解决构建验证流程 TXT 大文件阅读 章节跳转/续读链路。范围更清楚以后Agent 的修改也更容易检查和回退。十一、下一步还准备继续优化什么这次主要完成第一阶段。后续我还准备继续让码道处理两个方向。一个是文件导入链路进一步检查重复导入、文件指纹、取消导入、失败后的回滚以及异常文件处理。另一个是AI 导读功能完善调用前确认、生成状态、取消操作、内容来源提示以及异常处理避免 AI 功能和基础阅读功能耦合过深。如果后面的效果不错我会继续把这个项目作为一个持续迭代案例而不是只为了挑战做一个一次性的 Demo。十二、项目源码AtomGit 项目仓库ReadFlow:使用华为云码道 CodeArts 从零开发 ReadFlowTXT 分章、续读与 Android 跨端阅读器实战 - AtomGit项目主要技术HTML CSS JavaScript Capacitor Android AtomGit 华为云码道 CodeArts总结这次我尝试的并不是“让 AI 从零生成一个网页”而是让华为云码道进入一个已经存在的项目理解它、修改它、验证它。整个过程可以概括为已有跨端阅读器 ↓ 码道分析仓库和数据流 ↓ 确定大文件和阅读定位问题 ↓ 拆分优化任务 ↓ Agent 修改真实工程 ↓ 自动化测试与构建 ↓ Web Android 实际验收 ↓ 优化前后对比对我来说这种方式比单纯生成一个页面更接近日常开发。AI 写出一段代码并不难。更重要的是它能不能理解一个已经存在的工程找到真正需要修改的位置在尽可能不影响旧功能的前提下完成迭代并留下可以验证的结果。这也是接下来我最想继续测试华为云码道 CodeArts 的方向。