《从补全到智能体：我在华为云码道 CodeArts 上重构 AI 辅助开发工作流的实践复盘》
标题：从补全到智能体：我在华为云码道 CodeArts 上重构 AI 辅助开发工作流的实践复盘
摘要（发布时可直接使用）：代码补全用了两年，接受率不低，整体效率却提升有限。问题不在模型，而在用法——补全只解决了"打字慢"，而开发者真正耗时的是理解需求、检索上下文、跨文件改动和验证结果。这篇文章复盘了我把工作流从"补全"迁移到"智能体"的完整过程：需求怎么描述、模式怎么选、上下文怎么喂、代码怎么审，以及哪些任务仍然不该交给 AI。
建议标签：AI 编程、代码智能体、CodeArts、大模型应用、研发效率
从补全到智能体：我在华为云码道 CodeArts 上重构 AI 辅助开发工作流的实践复盘
一个不太舒服的结论
我先用代码补全工具用了差不多两年。单看接受率，数字不难看，Tab 按得很勤。但有一天我认真统计了一个工作周的时间分布，发现补全真正省下的，只有"把脑子里的代码敲出来"那部分——而这部分在一个普通开发日里占比并不高。
更多的时间花在哪了？读需求文档、在几十个文件里找上下文、把一个改动同步到前后端五个文件、写完之后跑测试、看日志、修边角问题。这些活补全工具一件都接不住。
结论有点不舒服：补全优化的是打字速度，而我的瓶颈从来不是打字。
后来我开始把任务整个交给智能体（Agent）去做，工作方式才真正变了。这篇文章以华为云码道 CodeArts 代码智能体（下文简称"码道"）为主要工具，复盘这半年摸索出来的一套流程。选它不是因为它有多神，而是它的功能设计比较完整，智能体模式、沙箱、检查点、多智能体协作都有，适合讲清楚"智能体时代的开发工作流"这件事。
补全和智能体，差的不是模型强弱
先说认知层面的差别，这比任何技巧都重要。
补全的工作方式是：盯着光标附近若干行上下文，预测接下来的几行代码。它的知识边界就是编辑器里那一小块视野。
智能体的工作方式是：接一个任务，自己规划步骤，自己检索代码库，跨文件修改，执行命令验证，最后把结果交回来。以码道的智能体模式为例，官方文档里对它的定位是"理解开发者复杂需求并自主规划执行路径"，落到实际体验上就是四件事：
- 把自然语言需求转成结构化的任务列表，并随执行进度实时更新；
- 跨文件编写和修改代码，而不是只管当前文件；
- 自主调用代码搜索、文件读取、Shell 命令等工具，让生成的代码能对接项目现有的逻辑和依赖；
- 在关键步骤停下来等人确认。
一句话总结：补全是一个更快的键盘，智能体是一个能接活的初级同事。 你不会给键盘写需求文档，但你会给同事写。所以用智能体的第一课，是学会"派活"。
实战：给现有项目加一个数据导出功能
下面用一个真实场景串起整个流程：给一个已有的 Web 管理系统加"数据导出"功能。这类任务要动后端接口、改前端交互、处理错误分支，跨多个文件，正好能检验智能体的成色。
第一步：把需求写成"派给同事的活"
我最初的需求描述是这样的：
给列表页加个导出功能。
结果生成的代码完全没法用：导出全表、没有分页边界、格式随机、直接把逻辑怼在组件里。怪模型吗？不怪。这个描述本身就没法执行。
后来我改成这样：
给用户管理列表页增加数据导出功能，要求：
- 导出当前筛选条件下的数据，支持 CSV 格式
- 数据量超过 1 万行时改为异步任务，完成后通知下载
- 后端逻辑按现有的 Controller-Service-Repository 分层组织，参考报表模块的写法
- 前端入口放在列表工具栏，与现有按钮风格一致
- 需要处理失败场景，给出可读的错误提示
产出的代码基本可以直接进评审。差异不在模型能力，在于第二段描述里有边界、格式、约束和参考实现。
如果你暂时不知道怎么把模糊想法写清楚，码道的输入框旁边有个"优化输入内容"功能，会把口语化的问题改写成结构化的描述，改得不好也可以撤销。对刚上手的人挺友好，但我建议把它当学习工具——看多了结构化描述长什么样，自己写的能力才是自己的。
第二步：选对模式——别拿氛围编程干规范的活
码道的智能体提供了两种开发模式，我用下来体会很不一样：
氛围编程（Vibe-Coding）：边聊边做，即时验证。适合需求还处在"我自己也没想清楚"的阶段，比如快速出一个原型看效果、试探某个技术方案的可行性。这个时候快速迭代比严谨规划值钱。
规范开发（Spec-Driven）：按"需求规格设计 → 实现方案创建 → 编码任务规划 → 任务执行"的固定流程走，每一步的产物（需求文档、设计文档、任务清单）都可以审查、拒绝、修改，通过后才进入下一步。
导出功能这个例子，我一开始用氛围编程，聊到第三轮发现 AI 每轮理解的需求都不太一样，改来改去在原地打转。换成规范开发模式后，先生成的需求规格文档就把它对"异步导出"边界的理解写了出来，我发现它理解错了一个细节，直接拒绝那份文档让它重写——错误在需求阶段就被拦住了，而不是写完三百行代码之后。
规范开发还支持用斜杠命令手动分步推进：/sdd-new 生成需求规格（spec.md），/sdd-design 生成设计文档（design.md），/sdd-tasks 生成任务清单（tasks.md），/sdd-apply 按清单逐项执行。这些文件就落在项目目录的 .codeartsdoer/specs/ 下面，可以人工修改后再让智能体继续。团队协作时这个流程特别有用——评审 spec.md 比评审代码便宜多了。
我的选择标准很简单：需求模糊、要快速试错，用氛围编程；需求清晰、要可验证的交付，用规范开发。 大部分正经的功能开发属于后者。
第三步：上下文管理——产出质量取决于它"看见"了什么
智能体再强，也只能基于它能看到的信息干活。这几件事值得花时间做：
先建代码库索引。 码道支持为项目构建索引，提升 AI 在代码库中的检索速度和准确度。在一个几十万行的仓库里，有没有索引，检索结果的靠谱程度差别明显。我的习惯是接手项目第一件事就是建索引，还可以配置忽略文件，把含敏感信息的文件排除在索引之外。
用添加上下文，而不是用文字转述。 需求里提到"参考报表模块的写法"，与其花两百字描述报表模块长什么样，不如直接把那个文件夹作为上下文加进对话。码道支持的上下文类型很全：文件、文件夹、Symbol、Git 记录、终端输出、Problems 报错信息、知识库。其中我最常用的是两个：把 Problems（报错信息） 直接丢进对话，比复述"报了个奇怪的错"有效十倍；把 Git 记录 加进来，让智能体知道这段代码最近的演变。
把团队私有知识放进知识库。 智能体没读过你们公司的接口规范和业务术语表，回答容易"正确但不符合内部约定"。码道的知识库支持上传企业内部文档和技术资料，作为问答的上下文参考。团队级的口径统一，靠这个比靠每个人各自往对话里贴文档靠谱。
第四步：审查和兜底——AI 写的代码也是"别人的代码"
这一点我想强调得再狠一点：从智能体手里接过来的代码，要按"外部提交的代码"的标准来审，而不是按"我写的代码"的标准。
码道在这个环节的设计值得单独说：
Diff 视图逐文件审。 所有变更以差异视图呈现，新增行绿色、删除行红色，可以逐文件接受或拒绝，也可以全部接受/全部拒绝。我审 AI 代码的顺序是：先看数据流向，再看错误处理，最后看风格——前两个是模型容易出错且代价高的地方。
沙箱默认开启。 智能体执行终端命令默认在沙箱环境里跑，文件系统和网络访问都受限，被拦截的高风险命令会在对话流里提示，经我二次确认后才会在沙箱外执行。刚用智能体那阵子我对"AI 执行 Shell 命令"很警惕，沙箱模式算是把这个顾虑的门槛降下来了。对特别敏感的项目，还可以手动改成"每个命令都要确认"的手动模式。
检查点兜底。 每次 AI 编辑前，系统会自动保存当前代码与对话状态的快照，改坏了可以回退。这直接改变了我的行为——以前对大改动很保守，现在敢让智能体放开改，反正有快照，试错的成本变成了几次点击。
单元测试智能体收尾。 码道内置了一个专门的 developer-test-agent，指令里带上关键词就能调用，比如"使用 developer-test-agent 为 ExportService.java 的 buildCsv 方法生成单元测试"。它不止生成用例，还会自动识别并修复用例的编译错误，对 Java、Go、Python、TypeScript 这些主流语言适配较好。我的固定流程是：功能代码合入前，先让它跑一轮测试生成，再人工过一遍用例的断言逻辑。
进阶：把重复的判断沉淀下来
流程跑顺之后，下一层优化是减少"每次都要交代一遍"的东西。
规则（Rule）：把团队编码规范写成规则，智能体生成代码时自动遵循。命名规范、分层约定、禁止的写法，这些以前靠 Code Review 人肉拦截的问题，前置到了生成阶段。
技能（Skill）：把某一类任务的解法（比如"我们项目怎么做灰度发布"、“排查这类内存问题的固定套路”）封装成可复用的模块，智能体按需加载。本质上是把个人或团队的经验变成了可复用的资产。
团队模板：码道 Agent Space 里有个 Agent Team 模式，用"Leader 智能编排 + Teammate 自主执行"的架构跑多智能体协作——Leader 把复杂任务拆成子任务，动态创建多个专业 Agent 分头执行，成员之间可以双向通信，任务池共享、自主认领，整个过程有可视化视图能看清依赖关系和每个节点的进度。一次跑完之后，用 /save-team 团队名 就能把这次的角色配置和场景封装成模板。下次再来一个同类型任务，一句"使用 xxx-team 创建 xxx"就能按同样的分工方式开工。
这套东西用久了，会有一个有意思的转变：你维护的不再只是代码，还有一套"如何与 AI 协作"的配置资产。 后者决定了前者未来的生产效率。
边界：哪些活我不交给智能体
说完了好处，必须说清楚边界，否则这篇文章就是软文了。
适合交出去的：边界清晰的功能开发（像导出功能这种需求能写明白的）、样板代码和脚手架、单元测试生成、文档整理（码道的 CodebaseWiki 能给项目生成结构化文档并随代码改动持续更新，读老项目时很好用）、还有非编码的研发事务——需求梳理、周报、技术方案初稿，码道 Agent Space 的"研发办公"场景就是干这个的。
不适合交出去的：需求本身还没想清楚的任务（智能体无法替你做产品决策）；核心算法的创造性设计（它可以当讨论伙伴，但设计责任在人）；对正确性极度敏感又难以验证的改动（比如涉及资金的安全关键路径）；以及一切你无法判断对错的领域——AI 会自信地给出错误答案，而无法识别错误的人会把它合入主干。
还有几条实际踩坑换来的经验：接受全部输出之前先跑一遍完整测试，AI 声称的"已完成"以测试通过为准；大仓库别跳过索引直接开干，检索不准会一路错下去；长会话注意上下文用量，码道能看到本轮会话的上下文使用率，接近上限时新开会话比死撑更干净。
写在最后
回看这半年，我最大的变化不是写得更快了，而是角色变了：以前我是打字的人，现在我是需求的定义者、结果的审查者和协作流程的设计者。打字的活交给谁都能干，后面三件事才仍然是开发者的核心价值。
工具还会继续变，但有一件事大概不会变：能清楚地定义问题、并能对结果做出可靠判断的人，在任何工具时代都是稀缺的。 智能体把这个差距拉大了，而不是缩小了——它让会派活的人如虎添翼，也让不会派活的人产出更多需要返工的代码。
从补全切到智能体，与其说是换工具，不如说是补上"如何与一个不知疲倦但需要明确指令的协作者共事"这一课。这门课，越早上越好。
相关官方文档（感兴趣可以深入阅读）：
- 点赞
- 收藏
- 关注作者
评论（0）