CodeArts 代码智能体是华为云提供的 AI 编码助手，定位在「项目级」：它回答的是这个功能在现有工程里怎么落地，不是下一行该写什么。这个定位决定了它的上限取决于项目有多规整，也决定了它给出的每一段代码都要经人过手。
项目级和行级补全的分界
行级补全解决局部问题，上下文一两屏，改的是当前函数里的几行；项目级智能体解决跨文件问题，要理解调用链、数据流向和既有约定。判断标准很实用：改动是否跨越三个以上文件，是就走项目级，否则交给补全，后者的等待成本更低。
两者混用常见的后果是风格不一致。补全出来的代码贴着当前文件写，项目级生成的代码按它理解的规范写，同一批改动里出现两种写法，评审时先被挑出来的就是这个。
先给它三样材料
目录树、技术栈与版本约束、代码规范。目录树给两层到三层就够，让它知道模块边界；技术栈要写清框架和版本，因为同一个写法在不同版本里可能不成立；规范写命名、分层、异常处理和日志约定，这几项决定了生成代码能不能直接进主干。
有 README 就先让它读，没有就花十分钟补一份。这一步的回报很直接：同样一句需求，给不给项目材料，生成结果的可用率差得很远。规范文档和接口约定放在共享知识库里，团队里谁问都不用重复解释一遍。
需求拆成可验收的小步
| 任务类型 | 怎么提 | 验收标准 |
|---|---|---|
| 新增接口 | 给出入参、出参、错误码和涉及的既有服务 | 接口能跑通，异常分支有返回 |
| 改造旧逻辑 | 先说清现在的行为，再说要变成什么 | 旧用例全过，新增用例覆盖改动点 |
| 补单元测试 | 指定被测函数和要覆盖的分支 | 覆盖率确有提升，断言不能只判非空 |
| 排查报错 | 贴完整堆栈和复现步骤 | 能指出出错文件与行，且解释得通 |
这张表的用法是：提需求前先对号入座，把「验收标准」那一列写进提示词。写不出验收标准的任务，通常说明需求本身还没想清楚。多轮对话里需求会被改来改去，参考改编现成提示词的做法，把变更追加在原文后面而不是重写，前后能对得上。
老项目靠问答读码
接手陌生项目时，省时间的问法有三类：这个模块的入口在哪、这个函数被谁调用、这份配置从哪里读进来。让它给出文件路径和大致位置，然后自己去编辑器里点开核对。它给的位置可能差几行，但方向通常对，这已经省掉大量全局搜索。
追问要顺着调用链走。从入口问到出口，一层一层收，比一次性问「这个项目是干什么的」有用。后者得到的是一段概述，前者得到的是一张你能自己验证的路径图。同一需求的多轮对话容易散，用会话记录管理的办法把每轮结论落下来，回头能查。
生成代码的审查顺序
先看改动范围有没有超出预期，多改的文件往往藏着你没要求的行为变化；再看边界条件，空值、超时、并发、重复提交这四项最容易漏；再看有没有引入新依赖，一个日志库也可能带进一串传递依赖；最后跑测试，测试不过就不要往下改。
涉及核心逻辑的改动要小步验证，一次只改一个可回滚的点。让它直接动生产分支是最省事也最危险的做法，这条线不该越。
什么情况下它会失灵
项目没有统一分层、命名随意时，它给出的建议会偏离你的实际结构；大量使用反射、动态调用或元编程的代码，调用链推断容易断；内部框架和私有 SDK 它没见过，容易编出不存在的接口，这类错误最难发现，因为方法名看起来很像真的；跨仓库依赖拿不到上下文，只能猜。
还有个代价常被忽略：上下文越长，它对早期信息的注意力越弱。项目很大时，把关键约定放在提示词开头，比放在结尾更稳。
提需求前自查四项
- 改动范围：涉及哪几个文件、哪几个模块
- 不变的部分：哪些行为必须保持原样
- 验收方式：跑哪个测试、看哪个返回值
- 回滚点：出问题时撤到哪一步
三个补充问题
生成的代码风格和团队不一致怎么办？把两三个有代表性的文件贴给它当样例，明确「按这个文件的命名和分层写」。样例比规则描述有效，规则它容易理解偏，样例不会。
能不能让它一次改完整个需求？需求越大，返工越贵。按「能独立跑通」的最小单元切，每切一次提交一次，出问题能精准回退。一次改十个文件，出了问题只能整体丢弃。
新人该不该直接用它读老项目？可以用，但要配一条规矩：它指出的每个位置都去编辑器里点开确认。直接抄它的结论，会把它的误读当成项目事实，这种错误往后很难纠正。
