Mu Tian从接到华为CodeArts Doer内测邀请那天起，我一直在琢磨一个问题：一个号称“会思考的代码智能体”，到底比普通的AI代码补全工具强在哪？光聊天可证明不了什么，得拿真实课题去压榨它。当时手头正好有个需求——做一个百度智能体搜索结果获取工具，接口逻辑不算复杂但细节多，还要应对页面结构变化、限流、数据截断这些实际工程问题。我决定把整个开发周期交给CodeArts Doer，从建仓、写代码到补测试全走它。这篇文章就记录这次完整的实测：我是怎么把模糊需求拆给智能体，它在开发中替我做了哪些决策，又在哪里翻了车，最终的代码和测试结果如何。无论你是想评估类似工具的技术人，还是准备用AI写工具脚本的测试开发，这篇都有可参考的地方。
1. 选型与需求界定：为什么挑这个任务来考验代码智能体
1.1 任务背景：百度智能体搜索结果获取工具是什么，能做什么
先说清楚这个工具本身。百度智能体开放平台上有不少搜索、问答、知识检索类的能力封装，调用方通过HTTP接口传入查询关键词，拿到智能体对结果的分析、汇总或网页链接列表。我的目标非常具体：写一个Python命令行工具，输入一个搜索词，工具自动调用百度智能体提供的搜索接口，把返回结果里的标题、摘要、来源链接、发布时间四项核心字段提取出来，输出为结构化的JSON或Markdown文件，同时支持多个关键词批量跑。就这么个东西，说难不难，但涉及网络请求、鉴权参数拼接、HTML/JSON解析、异常重试、结果落盘、命令行参数解析，整条链路拉下来，足够考验一个AI写代码的水平，而且它的正确性是可以被明确检验的，适合拿来和智能体配合开发并测试验证。
这个任务为什么不找现成的爬虫框架直接写？因为我想评估的不是爬虫效率，而是对话驱动的开发体验：需求有歧义时智能体会不会追问，面对陌生的接口文档它读到什么程度，写的代码在真实网络环境下能不能一次跑通。换成别的项目，可能会因为坑太深或环境复杂，导致我根本分不清是代码问题还是智能体理解问题。这个工具项目复杂度适中、验收标准清晰，是对代码智能体非常理想的中等难度试金石。
1.2 为什么核心变量是“交互方式”而不是“生成代码”
普通AI编程助手大家用得多了，基本都是：人写注释，AI补函数；人写个函数名，AI补实现。但CodeArts Doer的定位不一样，它在设计上强调的是“把开发任务交出去”，不是补全某个片段，而是理解整个任务目标，自己拆步骤、写代码、甚至跑测试。我选这个任务，测试的核心变量就是交互方式。
这意味着我不写“请帮我写一个def get_result(url)函数”这种细粒度指令，而是给一个完整的任务描述，让它自己设计接口交互方案、自己决定解析策略、自己考虑异常处理。如果它只会机械地把我的要求翻译成代码，那称不上“智能体”。如果它能主动问清楚参数格式、鉴权方式、输出格式，甚至反过来建议我调整设计，那才说明它确实理解了任务本身。这一点是整个体验过程中最值得观察的维度，也是后续所有操作的基础。
在实际开始之前，我花了一点时间做了个简单的评估表，用来记录每个关键节点的表现：
| 评估维度 | 具体观察点 | 我的预期表现 |
|---|---|---|
| 需求理解 | 能否准确提取关键词、输出格式、调用方式等约束 | 能主动确认而非默认 |
| 拆解能力 | 能否将任务拆成可执行的小步骤 | 按模块拆分并标注依赖关系 |
| 代码质量 | 变量命名、函数复用、错误处理是否专业 | 接近中级工程师水平 |
| 测试意识 | 是否主动写测试用例，覆盖正常和异常路径 | 至少要覆盖超时、空结果、字段缺失 |
| 交付效率 | 从任务下达到可运行脚本的时间 | 半小时内 |
这张表后面会多次用到。先把目标和验收标准定清楚，再去用智能体，才不会出现“生成了一大堆代码但根本不知道跑没跑对”的情况。这是这次体验的一个基本方法：定义一个能衡量的任务，再让AI去完成它，最后根据结果打分，而不是凭感觉给结论。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 需求拆解与会话策略：怎样把模糊目标喂给CodeArts Doer
2.1 用“项目说明书”而非“聊天”来启动智能体
很多人用AI写代码最大的问题是：提示词太短太模糊。你说“帮我写个百度搜索工具”，可能得到的是一坨能编但跑不起来、甚至思想完全跑偏的代码。我在用CodeArts Doer之前做了一件事：把需求写成一页纸的“项目说明书”，把角色、目标、输入输出、约束全部列清楚。这不是浪费时间，而是把模糊目标变清晰的关键一步。
我的做法是分段进入：第一轮只给背景和目标，看它是否理解方向；第二轮给出输出格式和字段定义；第三轮才放接口文档。分段的目的是给智能体消化和回问空间，一次性塞太多信息，它容易抓不住重点。其中最关键的一句描述是：
需求：开发一个百度智能体搜索结果获取工具。输入一个search_keyword，调用百度智能体开放平台的搜索相关接口，将返回结果中用户可见的title、snippet、source_url、publish_time提取出来，最终输出为JSON文件。如果某个字段缺失，用null填充，不要把整条记录丢弃。运行环境为Python 3.10，项目目录结构自拟，需要提供requirements.txt和简短的README。
这比直接说“写爬虫”强太多了。明确写了字段缺失时不要丢弃记录，是因为很多AI代码喜欢在异常分支省事，结果一条坏数据就导致整个任务失败。这种需求层面上的细节，如果不说清楚，后期处理起来很头疼。我建议所有类似的工具项目，在启动对话之前都先花十五分钟把自己的“项目说明书”写出来，用词越具体，智能体的幻觉越少。
2.2 为什么需要主动向智能体“交代”运行环境和外部依赖
有一类问题即使你很详细地描述需求，AI仍然默认踩坑：运行环境。很多AI写的Python代码默认你用的是Python 3.8或者某个最新版本，但实际部署环境可能老旧或受限。我在需求里明确标注了Python 3.10，同时在requirements.txt的要求上让它自己列，没有替它决定用哪个HTTP库。
结果它选了requests，理由是通用性好、文档全、协程改造空间大，这与我预期一致。但从这个交互细节里能看出，CodeArts Doer确实会就工具选型给出说明，不是硬编码一个库名。更值得注意的是，它在首次生成的代码里就包含了requirements.txt，而不是等我追问，说明它在拆解任务时有一个