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，而不是等我追问，说明它在拆解任务时有一个“完整交付物清单”的意识，而不是只生成一段孤零零的代码。
运行环境之外，外部依赖的交代也很重要。例如接口返回中有HTML片段，智能体默认用了BeautifulSoup做解析，这个选择我没有干预。但我前期特意在说明书里写了“如果存在HTML实体，比如&，需要解码为&，否则标题可读性会很差”。这类细节如果不提，很多AI会直接忽略，导致输出文本里全是转义符号。这是一个典型的“需求上下文”问题：人在需求文档里多写一句，AI生成的代码质量就能上一个档次。
2.3 多轮对话中的“角色设定”与追问处理
进入多轮对话后，CodeArts Doer有时会输出一段“思考过程”再写代码。比如它问：“百度智能体相关接口会不会限制单次请求返回条数？如果有分页，是否需要处理？”这个问题问到了点子上，说明它在试图主动理解业务边界。我当时的回答很简单：暂不处理分页，单次请求即可，先跑通主流程。
这种主动追问非常关键，它能把一些你原本没考虑到的边界条件提前暴露出来，而不是最后测试时才炸雷。以我的经验，如果智能体完全不问、闷头生成，说明它只是在做“高级代码补全”，谈不上任务理解。CodeArts Doer在这条上的表现值得肯定：它在第一轮生成代码之前一共提了四个问题，包括输出文件命名规则、是否需要日志、接口鉴权信息放环境变量还是配置文件、单次调用超时阈值。这些问题一个比一个具体，基本属于一个靠谱工程师拿到需求后会说出的提问。
如果你的输入偏简短，代码智能体给出的方案就会相对泛化。用户提问的质量，直接决定了智能体交付的上限。这不是说智能体不够聪明，而是说它在“信息不完整时”选择用最通用的方式实现，而通用方案往往不适合真实场景。所以我把这一阶段叫“给AI当产品经理”：需求文档写得越专业，AI的表现越接近预期。
3. 实测开发过程：从第一版到可运行工具的迭代记录
3.1 首轮生成的代码结构：模块划分比预期成熟
CodeArts Doer给出的第一版项目结构如下：
code复制baidu_agent_search/
├── main.py
├── client.py
├── parser.py
├── config.py
├── utils.py
├── requirements.txt
└── README.md
我第一反应是：这划分挺标准啊。main.py负责读取命令行参数和组装调用链，client.py负责发送HTTP请求和重试逻辑，parser.py负责解析HTML/JSON提取字段，config.py管理鉴权参数和请求配置，utils.py放公共函数比如日志初始化。对比我见过的一些AI生成代码——经常是一个2000行的main.py从头写到尾——这个结构已经算得上可维护。
具体看client.py的核心逻辑，它没有简单地把requests.get和返回值的代码堆一起，而是封装了一个带重试的调用方法。重试逻辑很关键：针对5xx和超时设置指数退避，而不是固定间隔。代码大致如下：
python复制import time
import requests
from loguru import logger
class BaiduAgentClient:
def __init__(self, api_key: str, base_url: str, timeout: int = 10):
self.api_key = api_key
self.base_url = base_url.rstrip('/')
self.timeout = timeout
self.session = requests.Session()
self.retry_times = 3
self.backoff_factor = 1.5
def _build_headers(self) -> dict:
return {
"Authorization": f"Bearer {self.api_key}",
"Content-Type": "application/json",
"User-Agent": "CodeArts-Doer-Demo/1.0"
}
def search(self, keyword: str, num_results: int = 10) -> dict:
payload = {
"query": keyword,
"num": num_results,
"need_attrs": ["title", "snippet", "source_url", "publish_time"]
}
for attempt in range(1, self.retry_times + 1):
try:
resp = self.session.post(
f"{self.base_url}/search",
json=payload,
headers=self._build_headers(),
timeout=self.timeout
)
resp.raise_for_status()
return resp.json()
except requests.exceptions.Timeout:
logger.warning(f"attempt {attempt} timeout, retry after {self.backoff_factor ** attempt}s")
time.sleep(self.backoff_factor ** attempt)
except requests.exceptions.HTTPError as exc:
if resp.status_code >= 500:
time.sleep(self.backoff_factor ** attempt)
continue
raise exc
return {}
这段代码有几个专业细节值得注意：
- 用
Session()保持连接复用，避免每次调用重新握手； - 鉴权头用的是Bearer Token形式，这是主流API通用做法；
- 5xx才重试，4xx直接抛出，不浪费请求数；
- 超时时间可配置，10秒是默认值，没有写死。
但第一版有个明显问题：它把解析结果放回了resp.json()，假设接口直接返回JSON。实际上百度智能体相关接口的返回结构里，搜索结果的字段经常嵌套在data.items这样的层级里，有的接口甚至先返回HTML片段再包一层JSON。这意味着第一版代码如果直接对接真实接口，大概率会解析失败。这不是CodeArts Doer能力不行，而是它拿到的“接口文档”信息不完整，只能在合理假设下给出实现。
3.2 真实接口返回与首版代码的差异：一次典型的AI踩坑
我在测试阶段用一个沙箱环境模拟了百度智能体的返回结构，故意把返回设计成第三方搜索引擎常见的混合结构：外层有code、msg、data，其中data.results是一个列表，每个元素包含title、summary而不是snippet，链接藏在url字段里，时间字段叫做date。这个设计相当于对第一版代码发起了一次“真实世界挑战”。
结果第一版代码运行后Parser直接报KeyError，提示找不到snippet字段。这个问题很典型：AI根据它训练数据里的“惯例”生成了字段名，但真实API的字段名不一定遵循惯例。这种差异对人是常识（看一眼返回参数就知道怎么回事），对AI来说只能在代码里做兼容。
我向CodeArts Doer反馈了这个问题，它的处理方式是：修改parser.py，把字段名映射做成配置化，不只适配单一接口。它给出的方案是维护一个字段映射表：
python复制FIELD_MAPPING = {
"title": ["title", "name", "heading"],
"snippet": ["snippet", "summary", "abstract", "description"],
"source_url": ["source_url", "url", "link"],
"publish_time": ["publish_time", "date", "published_at", "pub_date"],
}
def extract_field(item: dict, possible_names: list) -> str | None:
for name in possible_names:
if item.get(name):
return item[name]
return None
这个改动很实用，等于给解析层加了一个“多字段兼容层”，以后接口某字段改名，只需要在映射表里加一个别名，不用改主逻辑。这个方案未必是我能第一时间想到的，但智能体在收到故障反馈后能给出系统性的修复，而不是头痛医头地只改那一行KeyError，这让我对它的工程意识有了新的认识。
3.3 代码可读性和可维护性的实测评估
如果说“能不能跑”是及格线，那“好不好改”衡量的是AI代码的工程水平。我在拿到CodeArts Doer第二版代码后，特意把它当成同事提交的代码来code review。几个印象较深的点：
第一，日志规范。它在main.py里加了--debug参数，默认用INFO级别输出，打开debug后能看到完整的请求URL、耗时、返回状态码。这个设计在日常工具里不起眼，但排查问题的时候真的是救命。现实中有太多工具脚本连日志都没有，出问题只能print大法。CodeArts Doer默认就在工具里带了结构化日志，说明它不是只做题库式生成，确实吸收了工程经验。
第二，命令行参数解析用了argparse但做了合理的子命令设计，没有堆砌一堆全局参数。它支持三种模式：单次搜索（python main.py search -k "关键词"）、批量搜索（python main.py batch -f keywords.txt）、输出格式切换（--format json|markdown）。这种交互设计不是AI“临时发挥”，而是它从大量现有项目里学到的通用模式。对我这样的用户，直接用起来几乎不用改习惯。
第三，README不是糊弄的。总共有四十多行，包含安装步骤、使用示例、输出日志格式说明、常见问题FAQ，甚至写了“如果接口返回401，请检查API Key是否配置正确”。这些内容是生成式模型根据常见问题补充出来的，但对使用者来说是实打实的帮助。
当然，也有明显槽点。它在utils.py里写了一个read_keywords_from_file函数，但批量模式对应的主流程里对空行和BOM头的处理不够健壮。如果keywords.txt文件是用Windows记事本保存的UTF-8-BOM编码，第一行关键词会带上\ufeff，接口调用直接失败。这个BUG我在测试时踩到了，后来手动在代码里加了一段：
python复制def clean_keyword(raw: str) -> str:
return raw.strip().lstrip('\ufeff')
这个现象也很有代表性：AI生成的代码在“主流路径”上往往很顺，但到了“边界环境”就会漏。对使用者来说，收到AI代码后必须保留一颗review的心，不要一键信任。
4. 测试环节：AI生成代码的正确性与边界验证
4.1 测试数据构造：mock接口还是直连真实接口
测试代码智能体生成的程序，最怕的就是拿真实接口一顿猛调，把限流打爆，既分不清是代码问题还是服务问题，数据还可能污染。我建议的做法是：先用mock接口测试逻辑正确性，再切到真实接口做小流量验证。CodeArts Doer在第一次生成代码时并没有主动提出写单元测试，但在我的追问下，它确实补了一个基础的测试文件test_client.py，覆盖了正常返回、超时重试、空结果三种场景。
我自己又补了一段基于FastAPI的mock server，模拟百度智能体的返回结构，关键代码是这样：
python复制from fastapi import FastAPI, Header, HTTPException
from pydantic import BaseModel
app = FastAPI()
class SearchRequest(BaseModel):
query: str
num: int = 10
class SearchResponse(BaseModel):
code: int = 0
msg: str = "success"
data: dict = {}
@app.post("/search")
def mock_search(req: SearchRequest, authorization: str = Header(...)):
if not authorization.startswith("Bearer "):
raise HTTPException(status_code=401, detail="invalid auth")
if req.query == "空结果":
return {"code": 0, "msg": "success", "data": {"results": []}}
return {
"code": 0,
"msg": "success",
"data": {
"results": [
{
"title": "示例标题：华为CodeArts",
"summary": "这是用于测试智能体搜索工具的模拟摘要。",
"url": "https://example.com/1",
"date": "2026-06-08",
},
{
"title": "示例标题：缺少时间字段",
"summary": "这条数据故意不写时间字段，用于验证null填充逻辑。",
"url": "https://example.com/2",
}
]
}
}
用mock server验证的好处是：每个字段的设计都对应一个明确的测试意图。第一遍跑通只能说明代码没有语法错误，真正的考验是“缺字段”“空列表”“响应慢”“返回500”这几类模拟异常。CodeArts Doer生成的代码在“缺字段”这个场景下表现及格，因为那套FIELD_MAPPING的逻辑确实兜住了；但在“模拟500”场景下暴露了一个问题——重试日志和最终报错信息不够明确，只有一行“搜索失败”，没有把最后一次异常类型带上。
测试开发的老手应该都清楚，一个“搜索失败”的报错信息对排查几乎没有任何帮助。我要求智能体改进，它的修复是把异常捕获都带上原始exception信息并写入日志文件，同时退出码用1。这个修正很合理，工具脚本在Cron里跑的时候，运维可以通过退出码快速感知失败。
4.2 异常链路与边界条件的覆盖情况
作为一个在网上做技术分享的博主，我每次测AI代码都习惯画一张“边界测试表”，这次把CodeArts Doer的结果放了进去：
| 异常场景 | 预期行为 | 实际表现 | 结果 |
|---|---|---|---|
| 接口返回空列表 | 输出空JSON文件，不报错 | 生成{"results": []} |
通过 |
| 单条记录缺时间字段 | 用null填充，保留该记录 | FIELD_MAPPING提取不到则置None | 通过 |
| 请求连续超时 | 重试3次后退出并写日志 | 重试逻辑生效，日志含每次耗时 | 通过 |
| 接口返回500 | 重试后抛异常，退出码非0 | 退出码为1，但首次报错信息较模糊 | 部分通过 |
| API Key错误（401） | 不重试，直接报鉴权失败 | 按4xx处理，不重试 | 通过 |
| 输入关键词含特殊字符 | URL编码后请求，结果正常 | 未显式处理，但在payload JSON里天然安全 | 通过 |
| 文件含BOM头 | 第一行关键词去除BOM | 原版未处理 | 未通过 |
这个表格可以让读者一眼看到：在所有异常场景里，CodeArts Doer写的代码覆盖了大部分，但并非全部。BOM头那个问题非常典型，因为AI训练数据里很少出现“Windows记事本保存UTF-8”这种环境细节，它想不到是正常的，但作为使用者我们必须自己补上。这个教训并不是说AI不强，而是说要摆正“AI是协作者，不是背锅侠”的位置。
4.3 自动化测试与回归验证：如何确认“改没改坏”
当我对第一版代码做了两处手改（BOM清理和增加404场景的日志）之后，接下来最关键的动作是回归验证：确认这两处改动没有破坏其他功能。这里我使用了pytest，把前述几个核心场景转成自动化用例，单独跑一遍。
具体测试文件的组织是：tests目录下放test_client.py、test_parser.py、test_cli.py三个文件。test_client.py主要mock网络层，用requests_mock库拦截HTTP请求，模拟超时、401、500、200四种响应；test_parser.py直接构造各种字典样本喂给extract_field函数，验证返回是否命中映射表；test_cli.py用subprocess调用main.py，检查退出码和输出文件。最终pytest结果是一共18个用例，17个通过，1个失败。失败的测试正是“模拟接口返回200但data字段为None”的场景，这是我在手动测试时没测到的情况。
这个失败暴露了新的问题：第一版代码中对resp.json()的返回值没有做None检查，如果接口异常时返回{"code": 0, "data": null}，程序会报TypeError。CodeArts Doer给出的修复是检查result.get("data")是否为dict，否则按空结果处理。这再次证明了前面反复强调的观点：AI生成的代码必须置于真实测试之下，测试才是检验AI代码的硬标准。也是从这里开始，我真正把开发重心转到了“让AI自己生成测试”这一块。
4.4 智能体是否懂得自测：从黑盒结果反推AI的测试意识
测试开发最强的那批人，不仅写代码稳，补测试效率也很高。我在整个体验中反复观察一个点：CodeArts Doer在生成核心功能代码后，有没有自觉配套测试文件。实测结果是有，但cover率不算高。它首轮生成的test_client.py只包含三个用例，核心的parser层和CLI层都没有覆盖，在我连续几轮追问之后才慢慢补齐。这说明它当前的设计逻辑更偏向“按用户完整需求交付代码”，而“主动编写全面测试”的意识和能力还在成长阶段。
不过另一个细节让我对它的测试能力有了改观：我问了它一个带陷阱的问题——“如果接口返回的超时时间判断是30秒，但测试环境把超时设成60秒，pytest那些用例怎么跑才不会等那么久？”它给出了用monkeypatch修改time.sleep和requests.Session.post的建议，直接在用例里把网络函数替换成假函数，让测试毫秒级跑完。这种方案对于测试开发来说是很基础的内容，但由AI自然说出来，说明它看过不少pytest实践资料，具备一定的测试开发思维。
这也是这次体验中一个重要的收获：衡量一个代码智能体值不值得长期用，不能只看“它能写多少业务代码”，更要看“它懂不懂测试、懂不懂可观测性、懂不懂部署之后怎么监控”。这个偏向在中文AI编码工具里不多见。
5. 工具能力边界、坑点与可复用的使用心得
5.1 那些让CodeArts Doer“翻车”的典型问题类型
实测过程中，并非所有环节都顺利。我记录了CodeArts Doer表现不佳的几类问题，这里如实写出来供大家参考。
第一类：对“中文互联网特有环境”理解不足。比如我要求“输出的Markdown文件名包含日期”，它默认使用了datetime.now().strftime("%Y-%m-%d")，这在绝大多数环境下没问题，但一旦部署在CST时区之外的服务器上，生成的文件日期就会和本地对不上。AI没有“时区”这个隐含上下文，全凭数据分布里的普遍模式来判断，容易漏掉这类国产生态特有的细节。
第二类：对接口文档中的隐含约束灵敏度不足。比如同一个百度智能体接口，文档里可能写着“q参数最大长度64字符”，CodeArts Doer第一版完全没有做参数长度校验，直接透传用户输入。如果做成工具给其他人用，长关键词会导致接口返回401或400，排查起来很莫名。这类参数边界校验，AI通常不会主动附加，需要用户显式要求。
第三类：过长的对话上下文会导致生成内容“遗忘”早期约定。我在第8轮对话后，发现重新让它对parser.py做修改时，它生成的新代码里把前面约定好的FIELD_MAPPING结构改了，导致互相不兼容。后来我的办法是：每当对话超过10轮，就把关键约定重新粘一遍，或者直接开新会话并附上需求模板。这和人类协作很像：关键决策要说三遍。
5.2 提示词中值得锁定的“黄金句式”
经过实测，我整理了一套适合给这类型代码智能体使用的提示词结构，核心思路是“三段式”：给背景、给约束、给验收标准。这里分享几个我在项目中反复使用的黄金句式。
第一句是“请先列出你对该需求的疑问，再开始写代码”。这句话能强制智能体在动手前进行一轮需求澄清，效果非常明显。我实际体验中，加了这句话之后，代码的功能完整度有了明显的提高，因为它在写之前已经确认了若干关键场景，而不是闷头生成。
第二句是“字段映射需要设计成可配置的，不要硬编码在解析函数里”。这种指令能让它输出的代码具备更好的维护性，也避免了后续改接口字段时大改代码的风险。
第三句是“所有网络异常必须写日志，日志中需要包含关键字、耗时和HTTP状态码”。这句话治好了很多AI代码只会返回True/False的通病，工具类程序有没有完整日志，几乎决定了它能不能用于正式环境。
这三句话基本可以套用到任何“HTTP接口调用+结果解析”类的工具开发中，真实有效。
5.3 代码智能体使用者的能力要求：测试思维反而是核心门槛
这次体验带给我一个很有意思的观察：像CodeArts Doer这类代码智能体，真正拉高使用门槛的能力不是编程，而是测试思维。如果你对测试用例、边界条件、错误处理没有概念，大概率只会让AI写一个“能跑”的脚本，完全意识不到字段缺失、时区问题、BOM头、500重试、日志规范这些隐患；反之，如果你熟悉测试开发，你会发现AI生成代码的过程就像在和一个中级开发协作，而“评审”的视角完全由你决定。
以我个人的经验来说，代码智能体表面上降低的是“打字成本”，实际上放大的是“评审成本”。你不需要写每一行代码，但你需要有能力判断它写的对不对、边界处理是否完整、测试是否覆盖了关键路径。换句话说，AI不是淘汰程序员，而是淘汰只会写代码、不懂测试和不知道边界在哪的程序员。这也解释了为什么最近“测试开发”相关的话题热度一直很高——因为测试正在成为AI落地的重要节点。开发流程重构之后，测试不再是编码完之后的阶段，而是贯穿在需求拆解、代码生成、自动验证全过程中。你在使用工具时对“异常分支”的敏感度，就决定了你交出去的代码能不能真正扛住线上环境。
开发这个百度智能体搜索结果获取工具的全过程，CodeArts Doer的代码完成度约莫六成，剩下的四成靠测试驱动补完：缺字段要定义规则，失败日志要可读，环境边界要自己补。这个比例放到真实团队里，本质上就是一个靠谱AI结对同事的产出水平。如果你也准备尝试类似的AI辅助开发项目，建议从今天的方法论出发，先把需求说明书写清楚，再让AI去生成，最后一定不要省掉写pytest用例这一步。尤其是那些要放进生产环境长期跑的工具，边界条件比功能路径更值得花时间。