用华为云码道 CodeArts 智能体完成一次真实的 Web 应用开发：从需求到上线的完整复盘

一、为什么这次改用码道来做

过去一年里，我在小团队里做业务系统的迭代，最耗时的从来不是写代码，而是三件事：把模糊的需求翻译成可执行的模块划分、在存量代码里找到正确的修改点、以及把改动跑通验证。前两件事靠经验，第三件事靠环境。华为云码道（CodeArts）代码智能体切入的正是这三段：它读项目上下文、给结构化改动建议、并能在云端把工程跑起来。

这次我拿一个真实需求做对照实验：给一个已有的商品管理后台补一个"批量改价"的能力。需求不大，但涉及前端表单、后端接口、权限校验和日志，足够覆盖一次完整开发流程。

二、把需求拆成可验证的单元

我没有直接把一句话丢给智能体，而是先自己把需求拆成四段，再逐段交给它：

• 数据层：商品表新增一个改价记录表，字段为商品 ID、原价、新价、操作人、时间戳。
• 接口层：POST /api/products/batch-price，入参为商品 ID 列表与新价格，出参为成功/失败明细。
• 校验层：价格必须为正数、单次批量不超过 200 条、非管理员账号拒绝。
• 可观测性：每次批量改价写一条操作日志，失败原因落到明细里。

这样拆的好处是：每一段都能单独验收，智能体给出的改动也能逐段核对，而不是一口气生成几百行无法审查的代码。

三、让智能体读上下文，而不是猜

把工程挂到码道之后，我先让它做了一件很朴素的事：列出商品模块现有的目录结构、路由注册方式、以及权限中间件的调用位置。这一步的输出直接决定了后面代码风格是否一致。实测下来，它对项目里已有的分层约定识别得比较准，生成的 Controller 会沿用现有的返回体封装，而不是自造一套。

// 生成的接口骨架（示意）
router.post('/api/products/batch-price', requireRole('admin'), async (req, res) => {
  const { ids, price } = req.body;
  if (!Array.isArray(ids) || ids.length === 0 || ids.length > 200) {
    return res.fail('INVALID_BATCH_SIZE');
  }
  if (!(price > 0)) return res.fail('INVALID_PRICE');
  const result = await productService.batchUpdatePrice(ids, price, req.user.id);
  return res.ok(result);
});

四、真正省时间的是验证环节

代码写完只是开始。这次让我改变看法的是它能把环境跑起来：依赖装好、服务起好、接口打通，然后我直接在页面上点了一遍批量改价。以前这一步至少要花二十分钟配环境，现在压缩到几分钟。对于"改完不确定有没有副作用"这类改动，快速验证的价值远高于生成代码本身。

五、踩到的坑与应对

1. 过度生成：第一轮它顺手把无关的查询接口也重构了。解决办法是在提示里明确"只改与本次需求相关的文件"，并要求列出改动清单。
2. 边界条件遗漏：批量改价没考虑商品已下架的情况。这类业务语义智能体猜不到，必须由人补进验收清单。
3. 日志字段命名不一致：它按自己的习惯命名，和存量日志对不上。把现有日志样例贴进上下文后解决。

六、结论

把码道当成"会读项目上下文的结对开发者"来用，收益最明显的是三处：定位修改点、保持代码风格一致、以及快速把环境跑通。它替代不了需求判断和业务边界定义，但能把从"想清楚"到"跑起来"之间的机械劳动压掉一大半。如果你的团队正在做存量系统的持续迭代，值得把它接进日常流程试一轮，重点观察它对你项目既有约定的遵循程度，而不是只看单次生成代码的多少。