华为云码道 CodeArts 实战：为 CodeGuard 增加 ZIP 扫描，从开发到 PR 交付

一键开通华为云华为云码道CodeArts智能体：https://developer.huaweicloud.com/codeartsco.html?source=dmzntgwatomgit1&sourcead=dmzntgwatomgithd

一、这次我想解决什么问题

这次体验华为云码道 CodeArts，我选择在已有项目上增加一项具体功能，而不是重新生成一个演示页面。

我的项目叫“码安检 CodeGuard”，定位是浏览器本地运行的项目发布前预检工具。它通过规则匹配，检查疑似硬编码凭据、危险代码写法、调试输出、未完成标记，以及 README、开源协议和依赖清单等项目文件是否存在，并生成 HTML 报告。

原项目已经支持选择文件夹扫描。这次新增的需求是：直接选择或拖入 ZIP 压缩包，不需要先手动解压，就能完成检查。

本文主要记录使用华为云码道开发 ZIP 功能、根据审查意见修复问题，再到本地验收和创建 PR 的过程。原项目并非全部由码道从零生成，过程中也使用了其他 AI 工具辅助审查。

项目仓库：

https://atomgit.com/maaath/codeguard

二、先让Agent了解项目，再提出需求

关联 AtomGit 仓库后，我先让码道读取 README、页面代码和样式文件，说明技术架构、扫描流程及功能边界，暂时不修改代码。

这样做是为了让后续修改建立在现有功能之上。尤其是文件夹和 ZIP 两种入口，应当复用同一套扫描规则、评分和报告逻辑，避免以后改了一边、漏掉另一边。

确认分析后，我再给出实现要求，主要包括：

• 保留文件夹扫描，新增独立 ZIP 选择入口和拖拽支持；
• 文件读取、解压和扫描在浏览器本地完成；
• 过滤依赖目录、构建产物及非目标文件；
• 设置压缩包大小、条目数量、扫描数量和解压输出限制；
• 更新说明文档，保留可复现测试；
• 未经确认，不自动推送或部署。

相比只说“帮我支持 ZIP”，把限制和验收方法一起写出来，更容易判断最后交付的功能是否符合预期。

三、功能实现后，还需要检查边界

本次修改把共用扫描逻辑抽到 lib/scanner.ts，ZIP 解析和解压逻辑放在 lib/zip.ts，页面负责文件选择、调用扫描及结果展示。

但“能读取一个正常 ZIP”并不代表工作已经结束。后续审查发现，有几个容易被忽略的问题。

1. 文件数量限制不能只放在扫描阶段

早期实现先解压目标文件，再取前 600 个进行扫描。虽然最终扫描数量符合上限，但后面的文件仍然消耗了解压资源，甚至可能触发累计输出限制。

修复后，600 个目标文件的限制提前到解压阶段，超出数量的文件不再继续解压，并在结果中保留跳过数量和提示。

2. 普通大文件不应让整个项目扫描失败

文件夹扫描会跳过超大文件，而 ZIP 扫描早期遇到超大文件时会中止整个任务，两种入口的行为不一致。

调整后，普通超大文件被跳过，其余文件继续扫描。同时保留实际解压输出检查，避免只信任压缩包里声明的文件大小。

3. 被丢弃的解压输出也要计入预算

另一个细节是累计字节的统计顺序。某个输出块触发单文件超限后，即使被丢弃，它也已经产生，不能因此不计入累计预算。

最终修复将累计输出检查放在单文件超限处理之前，并补充“声明大小很小、实际解压内容超限”的测试样本。

这里的限制是在输出块回调中检查的，不能把“50MB 阈值”理解为浏览器总内存绝不会超过 50MB，也不能据此宣称已经防御所有恶意压缩包。

这几轮修改让我体会到：功能正常运行和边界处理正确，是两件都需要验证的事。AI 给出实现后，还需要检查限制究竟在哪里生效、异常发生后是否真的停止相应处理。

四、区分自动化验证和我自己的验收

码道最终返回的验证总结显示：10 组自动化测试通过，类型检查、ESLint 和构建也通过，对应提交为 c16c0e8。

这些属于 Agent 环境中报告的执行结果，不是我在 Windows 上亲自重跑了全部测试。

为了确认实际使用流程，我又把功能分支克隆到自己的 Windows 电脑。本地 Node 版本为 v24.16.0，安装依赖后生成测试 ZIP，再启动开发预览。

以下命令需要按顺序执行。克隆前应确认当前目录下没有同名项目文件夹：

git clone --branch feature/zip-scan --single-branch https://atomgit.com/maaath/codeguard.git codeguard-zip-test
cd codeguard-zip-test
npm ci
node scripts/verify-zip/gen-fixtures.mjs
npm run dev

测试 ZIP 生成在系统临时目录的 codeguard-verify-fixtures 文件夹中。可以另开一个 PowerShell 窗口，执行下面的命令打开：

explorer.exe "$env:TEMP\codeguard-verify-fixtures"

生成测试数据时，终端提示没有系统 zip 命令，因此跳过了加密 ZIP 样本。这不影响下面几项操作，但也意味着我没有在本地手动验收加密 ZIP 场景。

启动成功后，我打开终端显示的本地预览地址进行测试。需要注意，Agent 运行环境里的 localhost 并不等于自己电脑的 localhost。由于此次远端环境没有提供我能访问的预览入口，所以最终采用了本地运行方式。

浏览器手动验收结果

验收项目	实际结果
选择 project.zip	11 个文件，扫描 8 个、跳过 3 个，综合评分 62
拖入同一个 project.zip	与选择文件方式的结果一致
导出 HTML 报告	下载成功，能打开，项目名、评分和问题清单正常
readmeplusbig.zip	扫描 README，跳过 2MB 文本文件
many700.zip	扫描 600 个、跳过 100 个，并出现扫描上限提示

正常测试样本中故意放入了模拟凭据、调试输出和 TODO 等内容，所以出现风险提示是预期结果，并不表示运行 CodeGuard 的网站本身存在这些漏洞。

点击“导出报告”后，我实际打开了下载的 HTML 文件，确认项目名、62 分评分、扫描数量、中文路径和问题清单能够正常显示。

对于 many700.zip，页面显示共 700 个文件，实际分析 600 个、跳过 100 个。它验证的是扫描数量边界，而不是扫描速度或安全检测准确率。

五、通过功能分支和 PR 保留交付记录

开发完成后，我让码道将相关源码、依赖配置、README 和测试脚本提交到 feature/zip-scan 分支，再创建目标分支为 main 的 PR。

后续修复继续推送到同一个 PR，便于查看修改过程，而不是每次重新创建一份交付记录。

本次功能通过 AtomGit PR #1 交付。源分支为 feature/zip-scan，目标分支为 main，截至本文记录时保持开启、尚未合并。

截至本文记录时，PR 保持开启，尚未合并；本次 ZIP 功能也尚未部署到原线上网站。本文展示的功能验收来自本地预览。

因此，复现本文功能时，需要注意选择 feature/zip-scan 分支，而不是默认认为 main 已包含全部修改。本文记录的验收版本为 c16c0e8。

六、我的使用体验

我对华为云码道还不算熟悉。这次使用下来，比较直接的感受是模型切换方便。前期使用 DeepSeek-V4-Pro，额度用完后切换到 GLM-5.2，继续处理同一项任务。切换后，我仍然会补充当前进度和剩余问题，避免重复开发。

不太顺畅的地方是，有时候任务会中断，或者界面显示完成，却没有明确的最终回复。我需要继续追问修改内容、测试结果，以及是否已经提交和推送。

这也让我意识到，“任务完成”不等于“功能验收通过”。 本次成果来自多轮需求明确、代码修改、辅助审查和实际测试，而不是一次提示就生成了没有问题的代码。

亲自运行项目也很有必要。只有实际选择 ZIP、拖入文件、下载并打开报告后，才能确认这些操作在自己的环境里确实能完成，而不是只停留在代码说明或聊天回复中。

对我来说，CodeGuard 适合作为课程作业或个人项目发布前的辅助检查工具。它依赖规则匹配，可能存在误报和漏报，也没有进行完整的依赖漏洞检测，不能替代专业安全审计。

这次最大的收获，是走完了从需求到 PR 的开发流程。模型可以帮助编写和修改代码，但需求是否明确、测试是否覆盖实际场景、功能是否值得交付，仍然需要自己参与判断。

本项目目前提供源码及本地运行方式，暂未提供公开在线演示。ZIP 扫描功能位于 feature/zip-scan 分支，本文验收版本为 c16c0e8，读者可按文中步骤在本地运行。