从“代码补全”到“项目接管”：我的华为代码智能体真实使用体验

最近一段时间，我把华为代码智能体真正放进了一个实际的软件工程项目里使用。

不是让它写几个 Demo，也不是单纯体验“AI 自动补全代码”，而是直接让它面对一个已经存在大量历史代码、前后端模块、算法求解器、测试、数据文件以及工程文档的复杂项目。

这次体验之后，我对“代码智能体”这件事有了一个比较明显的认识：

真正有价值的代码智能体，不应该只是帮开发者多写几行代码，而应该逐渐具备理解项目、分析项目、执行任务、验证结果以及持续维护工程状态的能力。

下面分享一下我的实际使用体验。

---

一、我的使用场景并不简单

我目前主要将华为代码智能体用于一个“揭榜挂帅”项目的开发。

项目本身包含前端、后端、算法、数据、地图可视化以及多个智能体模块，工程规模已经明显超过普通课程作业或者单页面 Web 项目。

整个项目中包括：

• Vue 前端；

• Node.js / Express 后端；

• Python 优化算法；

• Gurobi 求解器；

• 洪涝场景数据；

• 设施选址算法；

• 卡车—无人机协同配送；

• 多个 Agent 模块；

• 单元测试与 E2E 测试；

• Docker 部署配置；

• 大量已有代码和历史实现。

这类项目最大的难点，其实已经不是：

“这段代码怎么写？”

而是：

“当前项目到底是什么状态？”

例如：

哪些代码是真正在使用的？

哪些页面已经废弃？

哪些算法只是接口，哪些算法真的运行了？

数据来自哪里？

前端展示的数据究竟是后端真实返回，还是写死的模拟数据？

已有功能能不能运行？

测试到底覆盖了什么？

现在应该继续开发，还是先修复已有架构问题？

这些问题如果没有解决，AI 写代码越快，项目反而越容易失控。

因此，我对华为代码智能体的使用方式，也逐渐从最开始的“让 AI 帮我开发功能”，变成了：

让 AI 先理解工程，再接管工程任务。

---

二、第一感受：最有价值的能力其实不是“写代码”

刚开始使用代码智能体时，很容易把注意力放在代码生成速度上。

例如：

“帮我写一个接口。”

“帮我生成一个 Vue 组件。”

“帮我修改这个函数。”

这类任务当然可以完成，而且效率确实比纯手工开发高很多。

但真正使用一段时间以后，我发现，代码生成本身反而只是最基础的一层能力。

我认为更重要的是下面几件事情：

1. 阅读整个项目

面对一个陌生仓库，传统开发者首先需要花大量时间阅读：

• README；

• package.json；

• 项目目录；

• 路由；

• API；

• 数据模型；

• 配置；

• 测试；

• Git 状态。

代码智能体最大的优势之一，就是可以快速完成这一轮“项目摸底”。

尤其是对于已经开发了一段时间的项目，这一点非常重要。

很多时候，我甚至已经记不清某个功能究竟在哪里实现了。

这时候，与其自己在几十个目录中搜索，不如直接让智能体分析：

当前系统中和某个功能有关的文件有哪些？

然后让它继续追踪调用链。

从“找代码”变成“理解代码”，效率提升非常明显。

---

三、第二个明显优势：适合做工程级排查

这也是我目前认为代码智能体最值得深入挖掘的地方。

以前使用 AI 编程工具，我经常采用这样的模式：

出现一个问题 → 把代码贴给 AI → AI 修改代码。

这种方式处理小项目没有问题。

但复杂工程中的问题往往不是单个文件造成的。

比如一个页面数据不对，真正的问题可能出现在：

前端组件
↓
Pinia Store
↓
API 请求
↓
Express Route
↓
Service
↓
共享数据模型
↓
Python 算法
↓
JSON 数据文件

如果只看其中一个文件，很容易出现一种情况：

局部修好了，整体却错了。

我后来开始改变使用方式。

与其直接告诉智能体“修改这里”，不如先要求它：

1. 查找相关实现；

2. 梳理调用链；

3. 找到数据来源；

4. 检查测试；

5. 判断问题属于前端、后端还是算法；

6. 最后才允许修改代码。

这种模式明显更加稳定。

我甚至开始要求智能体先进行一次完整的“项目体检”。

包括：

• Git 状态；

• 目录结构；

• 前端架构；

• 后端 API；

• 数据来源；

• 算法实现；

• Agent 能力；

• 测试情况；

• Docker；

• 安全问题；

• 历史代码；

• 当前运行状态。

做到这里以后，代码智能体的角色已经不太像“代码生成工具”，而更像一个：

工程审计 Agent。

---

四、我认为非常重要的一点：不要一上来就让 AI 重构

这是我实际使用过程中踩过之后越来越重视的一点。

AI 很擅长发现代码“不够优雅”。

然后给出的解决方案往往是：

“建议重新设计。”

“建议统一架构。”

“建议重构。”

“建议抽象。”

如果是一个新项目，这没有太大问题。

但是对于已经有大量功能的工程，直接重构非常危险。

因为一个文件看起来可能“过时”，但实际上仍然有某个页面依赖它。

一个目录看起来像“旧代码”，但可能仍然承担数据加载功能。

一个接口看起来可以删除，但某个 E2E 测试仍然使用它。

所以我后来给智能体设置了一个非常明确的原则：

保留 > 修复 > 封装 > 迁移 > 局部替换 > 重写。

换句话说：

重写永远是最后一个选择。

而且在没有建立当前项目基线之前，不允许进行大规模架构调整。

这个原则对代码智能体尤其重要。

因为 AI 的代码生成能力越强，“推倒重来”的诱惑就越大。

但软件工程真正需要的，并不是不断生产新代码，而是保护已经验证过的成果。

---

五、使用体验中让我比较满意的一点：可以连续执行一组工程任务

传统 AI 对话往往是一问一答。

代码智能体则更适合：

给目标，让它连续完成若干步骤。

例如我会给它这样的任务：

先检查 Git 状态。

然后分析目录。

然后找到当前生产入口。

然后检查 API。

然后检查测试。

然后整理问题。

最后生成审计文档。

这种连续操作对复杂项目特别有用。

因为开发过程中大量时间实际上消耗在：

• 打开文件；

• 搜索文件；

• 查引用；

• 执行命令；

• 查看输出；

• 再决定下一步。

如果这些操作全部手工完成，开发者很容易被大量上下文切换打断。

而代码智能体可以把其中很多机械工作串起来。

这也是我觉得 Agent 和普通代码补全工具最大的区别之一：

补全工具提高的是一次输入的效率，而 Agent 提高的是一整条工作流的效率。

---

六、但是，“让它一直写”并不是最好的使用方式

代码智能体越强，我反而越觉得“任务约束”非常重要。

如果只告诉它：

“继续优化项目。”

这个指令实际上非常危险。

因为“优化”没有边界。

它可能：

• 修改架构；

• 更换实现；

• 新增依赖；

• 删除旧逻辑；

• 重写组件；

• 修改测试；

• 改变接口。

最后项目确实发生了很多变化，但你很难判断这些变化是不是必要的。

所以我现在越来越倾向于使用“工程契约”。

例如明确规定：

允许做什么

• 阅读；

• 搜索；

• 分析；

• 执行测试；

• 修复确认的问题；

• 增加必要测试；

• 更新文档。

不允许做什么

• 删除历史代码；

• 擅自重写已有模块；

• Git reset；

• Git clean；

• 覆盖未提交修改；

• 降低测试标准；

• 为了让页面好看而伪造数据。

这样智能体执行任务时，稳定性明显更高。

某种程度上，使用 Agent 和带一个新开发者很像。

能力固然重要，但更重要的是：

任务边界必须清楚。

---

七、复杂项目里，“真实性”比“效果好看”更加重要

这是我这次项目中非常关注的一件事情。

例如做一个应急决策系统，前端地图上可以展示：

• 仓库；

• 救援车辆；

• 无人机；

• 洪水；

• 需求点；

• 配送路线；

• 物资状态。

如果只是为了演示效果，生成一些随机数据其实很简单。

但这样很容易出现一个严重问题：

界面看起来非常高级，但背后的算法并没有真正运行。

所以我给项目增加了非常严格的数据来源意识。

例如数据需要区分：

• 实测数据；

• 工程数据；

• 算法计算结果；

• 模拟数据；

• 规则生成数据；

• 缺失数据。

前端也不能自己“编造”一个算法结果。

必须尽可能展示后端真正返回的结果。

在这个过程中，代码智能体有一个非常适合的用途：

追踪数据 provenance，也就是数据来源。

它可以从前端一路追到 API，再追到算法和数据文件。

这一点对于科研项目、比赛项目和工程项目都非常重要。

---

八、代码智能体并不能替代架构判断

使用下来，我也发现了一个非常明显的问题。

AI 可以：

• 快速阅读代码；

• 搜索调用关系；

• 生成实现；

• 执行测试；

• 修改文件。

但是一些关键决策仍然需要人来判断。

例如：

到底应该保留 Cesium 还是迁移到 OpenLayers？

某个旧模块究竟属于技术债，还是应该继续维护？

某个算法当前精度已经足够，还是需要进一步优化？

当前阶段最重要的是展示效果、工程稳定性还是算法创新？

这些问题不是单纯依靠“读取代码”就能解决的。

它们涉及：

• 项目目标；

• 时间；

• 比赛要求；

• 答辩要求；

• 团队能力；

• 开发成本。

因此我现在更倾向于一种模式：

人负责目标与决策，Agent 负责调查、执行和验证。

我认为这可能也是目前比较合理的人机协作方式。

---

九、我现在常用的工作模式

经过一段时间使用，我目前比较推荐下面这种流程。

第一步：先调查

不要修改代码。

先让智能体回答：

• 当前有什么？

• 当前入口是什么？

• 哪些代码还在使用？

• 有哪些风险？

• 测试情况怎么样？

第二步：建立基线

把当前状态写成文档。

例如：

• 当前项目基线；

• 活跃代码边界；

• 数据来源清单；

• 算法能力矩阵；

• 测试基线；

• 风险清单。

第三步：拆任务

把大目标拆成一个个可以验收的任务。

例如不要写：

“完善协同配送。”

而应该写：

“确认无人机与设施之间的归属约束是否已经进入求解模型，并增加对应测试。”

任务越明确，Agent 表现通常越稳定。

第四步：执行

让智能体修改代码。

第五步：验证

每次修改以后要求执行：

• 类型检查；

• 单元测试；

• E2E；

• API 测试；

• 必要的运行验证。

第六步：记录状态

完成以后更新工程文档。

记录：

• 做了什么；

• 修改了什么；

• 测试结果；

• 还有什么问题；

• 下一步是什么。

这样下一次继续使用 Agent 时，不需要重新解释整个项目。

---

十、目前我觉得仍然存在几个明显问题

华为代码智能体让我看到了 Agent 式开发的效率，但距离真正的“无人值守软件工程”仍然存在距离。

第一，上下文管理仍然非常关键

项目越来越大以后，一个 Agent 不可能永远记住所有信息。

如果没有工程文档，运行几轮以后很容易重复调查。

因此 README、架构文档、执行看板、handoff 文档的重要性反而提高了。

AI 时代不是“不需要文档”。

恰恰相反：

因为 Agent 需要上下文，所以高质量工程文档变得更加重要。

第二，长任务容易发生目标漂移

刚开始可能只是修一个问题。

执行十几个步骤以后，Agent 可能逐渐开始“顺便优化”其他东西。

因此长任务需要非常明确的边界和验收条件。

第三，不能只看它说“完成了”

这是我认为最重要的一点。

Agent 告诉你：

“已经修复。”

并不意味着真的修复。

真正可信的是：

• 测试通过；

• 构建通过；

• 接口返回正确；

• 页面可以运行；

• 算法能够执行。

所以应该尽量把：

“AI 说完成了”

变成：

“工程证据证明完成了”。

---

十一、它对我的开发方式产生了什么变化？

最大的变化不是写代码变快了。

而是我开始把整个软件开发过程拆成两类工作。

第一类是：

决策型工作。

例如：

• 项目应该往哪里发展；

• 哪些功能最重要；

• 哪些技术债值得现在处理；

• 哪些算法需要提升。

第二类是：

执行型工作。

例如：

• 搜索代码；

• 整理接口；

• 修改实现；

• 写测试；

• 运行测试；

• 更新文档；

• 检查依赖。

代码智能体正在大量接管第二类工作。

这样人可以把更多精力放在第一类工作上。

我认为这才是 AI 编程真正有意义的地方。

---

十二、总结：代码智能体的终点不是“帮你写代码”

如果只是把代码智能体当作一个更高级的自动补全工具，其实有点浪费。

我这段时间最大的感受是：

代码智能体真正的价值，是从 Coding Assistant 向 Engineering Agent 转变。

它不应该只会回答：

“这段代码应该怎么写？”

更应该能够回答：

“这个项目现在是什么状态？”

“问题到底在哪里？”

“哪些东西不能动？”

“应该先做什么？”

“修改以后有没有证据证明它真的工作？”

当它能够完成：

读取 → 理解 → 分析 → 规划 → 修改 → 测试 → 验证 → 记录

这样一个完整闭环时，它才真正开始成为“智能体”。

目前华为代码智能体已经让我明显感受到这种开发方式的变化。

当然，它还远没有达到完全自主开发的程度。

但对于复杂工程来说，我已经越来越少把它当成“自动写代码的软件”，而是开始把它当成一个需要规则、文档、权限边界和验收机制的工程协作者。

未来的软件开发，很可能不会是：

程序员和 AI 谁取代谁。

而是：

谁能够更好地组织 AI 完成工程任务。

我认为，这可能才是代码智能体时代真正值得学习的一项能力。