华为云 CodeArts 代码智能体上手三周：我的六条真实用法

开头先说结论

三周下来最大的感受是：这类代码智能体的效果，八成取决于你给它的上下文和任务切分，两成才是模型本身。同样的需求，换一种组织方式去问，产出质量能差一倍。下面六条是我反复验证后固定下来的做法。

一、先把项目约定写进 AGENTS.md

接手一个新仓库最大的浪费，是让它每次从零猜你的代码风格：目录怎么分层、异常怎么抛、日志用什么封装、提交信息什么格式。把这些写进仓库根目录的约定文件，一次写、长期生效。

我一般会写四块：技术栈与版本、目录职责、错误处理和日志规范、禁止事项（比如禁止直接改生成文件）。写完之后的第一个变化是，它不再自作主张引入新依赖。

二、用小步任务替代大 Prompt

反面案例：把“实现一个完整的用户模块，包含注册、登录、权限、审计日志”丢给它，结果它一次性生成七八个文件，跑不起来，改起来比重写还累。

正面做法是把它拆成能独立验证的小步：先只要数据模型和迁移脚本，跑通再要接口，接口跑通再要权限校验。每步都能立刻验证，出错时定位范围也小。

三、先让它写测试，再让它写实现

顺序颠倒一下收益很明显。先让它基于需求写测试用例，你人工过一遍用例是否覆盖了边界（空值、并发、权限不足），确认后再让它写实现跑绿。这样做的好处是需求歧义在写测试阶段就暴露了，而不是等实现完才发现理解偏了。

四、跨文件改动前先要影响面分析

让它直接改公共方法是最容易出事的地方。我的习惯是先问一句：如果修改这个方法签名，会影响哪些调用方，请列出文件与行号。拿到清单后人工判断范围，再让它动手。这一步几乎不花时间，但拦住过好几次线上事故。

五、长会话要及时 fork

一个会话里堆了太多历史，后面它给出的方案会越来越“保守”，甚至开始复述早期被否掉的思路。判断信号是：它开始重复解释已经确认过的背景。这时候应该把当前结论整理成一段摘要，开新会话继续，把摘要作为新上下文。压缩对话适合任务还没收敛时；已经收敛就直接 fork 出新任务。

六、重复操作固化成 Skill

团队里有些动作每周都要做：生成一份接口变更说明、按模板补一版发布记录、跑一遍静态检查和单测。把这些流程写成可复用的指令集，就不用每次重新描述一遍要求，产出格式也稳定。

小结

把它当成一位需要明确 brief 的新同事，而不是一个许愿池，效果会稳定很多：上下文给足、任务切小、验证前置、改动有边界。这四点做到了，日常编码效率的提升是实打实的。