1. 当 Redis 之父说“写代码不再必须”我们在争论什么Redis 作者 antirez 那篇《不要被反AI的炒作所蒙蔽》发出来之后我身边做后端的朋友几乎都在转。核心观点其实不复杂他一个写了半辈子 C 语言的老派系统程序员公开承认大模型已经能在几乎没有人工干预的情况下完成中等规模项目手敲代码在大多数场景下已经不再“理性”。这话从定义过一代基础设施的人嘴里说出来分量确实不一样。但真正让评论区炸锅的是另一条声音有人从 GPT-3.5 一路用到最新模型每次 AI 写完都要重写 70%架构不行、细节不行、根本没法交付。说这话的人有 15 年 Java、Spring、React、遗留系统和硬件接口经验不是新手。于是争论迅速从“AI 行不行”滑向“程序员到底在为谁写代码”。我自己的判断是两边说的其实不是同一件事。antirez 讲的是“生成代码”这件事的边际成本已经趋近于零而反对者讲的是“交付工程”的合格线并没有因为生成变快而降低。这两件事同时为真。问题在于大多数人把“AI 能写”直接等同于“AI 写的能直接用”中间缺了一道审查和验证的工序。这篇就围绕这个缺口来写。我会把 antirez 提到的几类任务拆开看哪些 AI 生成代码可以直接进仓库哪些必须重写以及一套我自己在用的 AI 代码审查清单和验证动作。场景很具体你手上有一个大模型生成的补丁或者模块你要在半小时内判断它是能合并、要改还是直接扔掉重写。先给结论判断标准不是代码“像不像人写的”而是它有没有可验证的行为边界。antirez 举的纯 C 实现 BERT 推理库那个例子之所以能 5 分钟出 700 行还和 PyTorch 输出一致是因为 embedding 推理有明确的数值对照物。而“重构一个遗留系统的架构”没有对照物所以 70% 重写是正常的。搞清楚你面对的任务属于哪一类比争论 AI 行不行有用得多。2. 用 TaoToken 搭一个可复现的 AI 代码审查环境要判断 AI 生成代码能不能用前提是你能稳定地复现它的输出、稳定地跑验证。如果每次调用模型的结果都不一样、或者环境三天两头连不上审查就无从谈起。所以第二步先把环境固定下来。我用的方式是走 TaoToken 的 API 接入。它的官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 注意 API 地址后面不加 UTM 参数。它的作用是提供一个统一的模型调用入口让你在同一个 Base URL 下切换不同模型来做交叉验证——这一点对代码审查特别重要因为单一模型的输出有系统性偏好换一个模型复跑同一段提示词能快速暴露那些“看起来对但其实靠猜”的代码。具体操作上你需要先拿到 API Key。进入控制台页面 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 在 API Keys 管理里创建一个新 Key。创建时建议按用途命名比如code-review-bot方便后面区分是哪个项目在调用。Key 只在创建时完整显示一次复制后立刻存到本地环境变量里不要写进代码仓库。拿到 Key 之后我建议先不要急着写审查脚本而是去模型对话页面 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 手动跑几轮。把你手头一段 AI 生成的代码贴进去用同一套提示词问它“这段代码在什么输入下会失败”观察不同模型的回答差异。这一步的目的是建立你对模型能力的直觉哪些模型在边界条件上更谨慎哪些模型倾向于说“没问题”。如果你打算长期做代码审查而不是一次性试试那 Coding Plan 会更划算入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。它适合那种每天都要跑几十次审查请求的场景。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 里面有各语言 SDK 的调用示例建议先过一遍再动手。这里要提醒一点TaoToken 是模型调用入口不是代码编辑器也不是版本控制工具。它的价值在于让你用统一的接口做多模型交叉验证而不是替你写代码。审查这件事的主体仍然是你模型只是提供第二意见。3. 可复制的审查配置把判断标准写进 settings环境有了接下来把审查标准固化下来。我试过纯靠脑子记“要看边界、要看错误处理”结果每次审查标准都在漂移。后来改成把清单写进配置文件每次审查按文件走一致性好了很多。下面这份 JSON 是我在用的审查配置你可以直接复制到项目根目录的.ai-review.json里。它定义了三个等级block表示必须重写warn表示需要人工确认pass表示可以直接合并。{ review_profile: ai-generated-code-v1, base_url: https://taotoken.net/api, model_id: claude-sonnet-4-20250514, checks: [ { id: boundary-input, level: block, description: 检查空输入、超长输入、非法字符输入下的行为, action: 对每个公开函数构造至少 3 组边界输入并实际执行 }, { id: error-path, level: block, description: 检查错误分支是否被吞掉或只打日志不返回, action: 搜索 catch/except 块确认每个都有明确的向上传递或降级策略 }, { id: concurrency, level: warn, description: 检查共享状态是否有锁或原子操作保护, action: 标记所有可变全局变量和静态字段人工确认并发安全性 }, { id: dependency, level: warn, description: 检查是否引入了未在依赖清单中声明的库, action: 对比 import 语句与 package.json / requirements.txt }, { id: test-coverage, level: pass, description: 检查是否附带可运行的测试用例, action: 运行测试确认覆盖了主路径和至少一个错误路径 } ], rewrite_threshold: 2 }rewrite_threshold这个字段的意思是如果一段代码触发了 2 个及以上block级别的检查项就直接重写不要试图修补。这是我踩过的坑——修补 AI 生成的架构性问题花的时间往往比重写还多而且修完还是带着原来的设计缺陷。如果你用的是 Claude Code 或者类似的命令行工具可以把这份配置转成 TOML 格式放在项目里[review] profile ai-generated-code-v1 base_url https://taotoken.net/api model_id claude-sonnet-4-20250514 rewrite_threshold 2 [[review.checks]] id boundary-input level block action 对每个公开函数构造至少 3 组边界输入并实际执行 [[review.checks]] id error-path level block action 搜索 catch/except 块确认每个都有明确的向上传递或降级策略这里必须写全三件套Base URL 是https://taotoken.net/apiKey 是你从控制台创建的那串字符Model ID 按你实际用的填。三个缺一个都跑不起来。很多人卡在 401 就是因为 Key 没设对或者 Base URL 多加了斜杠。配置写完之后审查动作就变成了机械执行把 AI 生成的代码贴进对话让模型按这份清单逐项检查然后你自己跑一遍边界输入。模型负责找可疑点你负责确认。这个分工比让模型直接说“能不能用”靠谱得多。4. 验证请求跑一遍就知道是能合并还是要重写配置就位后用一段真实的 AI 生成代码走一遍完整流程。我拿一段常见的场景举例让模型写一个解析配置文件的函数输入是 JSON 字符串输出是配置对象。先构造请求。如果你用 curl命令大概是这样curl https://taotoken.net/api/v1/messages \ -H Content-Type: application/json \ -H x-api-key: $TAOTOKEN_API_KEY \ -H anthropic-version: 2023-06-01 \ -d { model: claude-sonnet-4-20250514, max_tokens: 2048, messages: [ { role: user, content: 按以下清单审查这段代码逐项给出 block/warn/pass 判定\n\n清单\n1. 边界输入空字符串、超长字符串、非法 JSON\n2. 错误路径解析失败时是否抛出明确异常\n3. 并发是否有共享可变状态\n4. 依赖是否引入未声明库\n5. 测试是否附带可运行测试\n\n代码\npython\nimport json\n\ndef parse_config(raw):\n data json.loads(raw)\n return data.get(\config\, {})\n } ] }注意x-api-key从环境变量读不要硬编码。跑完之后你会拿到一份逐项判定。以这段代码为例模型大概率会给出边界输入 block空字符串会直接抛 JSONDecodeError 且没有包装、错误路径 block异常直接冒泡调用方无法区分是格式错误还是其他问题、并发 pass、依赖 pass、测试 block没有测试。三个 block超过rewrite_threshold的 2按配置应该直接重写。重写后的版本大概长这样import json class ConfigParseError(Exception): pass def parse_config(raw): if not isinstance(raw, str) or not raw.strip(): raise ConfigParseError(config input is empty or not a string) try: data json.loads(raw) except json.JSONDecodeError as e: raise ConfigParseError(finvalid json: {e.msg} at line {e.lineno}) from e if not isinstance(data, dict): raise ConfigParseError(config root must be an object) return data.get(config, {})重写版把空输入、非法 JSON、根节点类型都做了显式处理异常类型统一调用方可以精确捕获。然后补一个测试import pytest from config_parser import parse_config, ConfigParseError def test_empty_input(): with pytest.raises(ConfigParseError): parse_config() def test_invalid_json(): with pytest.raises(ConfigParseError): parse_config({not json}) def test_valid_config(): assert parse_config({config: {a: 1}}) {a: 1}跑pytest -q三个用例全过这段代码才算进入可合并状态。整个过程从审查到验证大概十分钟比事后在线上发现空配置导致服务起不来要划算得多。这里的关键动作是不要只看模型说“这段代码没问题”一定要自己跑边界输入。模型说 pass 不等于真的 pass它只是没在训练分布里见过这个失败模式。你的测试用例才是最终裁判。5. 常见报错排查401、local proxy failed 和 choices 读取失败接入和验证过程中有几类报错几乎每个人都会遇到。我把它们和对应的处理方式列出来你对照着看。第一类是 401。报错信息通常是{error:{type:authentication_error,message:invalid x-api-key}}。原因基本是三个Key 没设进环境变量、Key 复制时带了空格、或者请求头字段名写错了。Anthropic 风格的接口用x-api-keyOpenAI 风格的接口用Authorization: Bearer两者不能混。排查方式是先echo $TAOTOKEN_API_KEY确认变量有值再用curl -v看请求头实际发出去的是什么。如果 Key 本身没问题但还是 401去控制台确认这个 Key 有没有被禁用或者额度耗尽。第二类是local proxy failed或者连接超时。这类报错通常出现在你本地配了某些网络工具的情况下。处理方式是检查你的 HTTP_PROXY / HTTPS_PROXY 环境变量如果指向了一个不可用的本地端口请求就会在到达 TaoToken 之前失败。临时清掉这两个变量再试unset HTTP_PROXY HTTPS_PROXY。如果清了之后能通说明问题在本地网络配置不在 API 本身。第三类是读取choices字段失败报错类似KeyError: choices或者response.choices is undefined。这是因为不同模型提供商的响应结构不一样。OpenAI 风格返回choices[0].message.contentAnthropic 风格返回content[0].text。如果你用同一段解析代码去处理两种响应必然有一边报错。解决方式是在解析前先判断响应结构def extract_text(resp): if choices in resp: return resp[choices][0][message][content] if content in resp: return resp[content][0][text] raise ValueError(funknown response shape: {list(resp.keys())})第四类是 OAuth 相关的报错比如OAuth token expired或者invalid_grant。这类一般出现在你用某些命令行工具做交互式登录的场景。处理方式是重新走一遍授权流程或者改用 API Key 方式接入。如果你在用 Claude Code 这类工具检查它的配置文件里 Base URL 和 Key 是否指向了正确的入口。配置文件通常在~/.claude/settings.json或者项目级的.claude/settings.json里面要有完整的 Base URL、Key 和 Model ID 三项。第五类是模型返回了内容但格式不对比如你要求 JSON 输出它返回了带 markdown 代码块的文本。这不是报错但会让下游解析失败。处理方式是在提示词里明确“只输出 JSON不要包裹代码块”或者在解析前先剥掉json和。更稳的做法是用支持结构化输出的接口参数具体看你调用的模型是否支持。把这五类记住基本能覆盖 90% 的接入问题。剩下的 10% 去看接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 里面有更细的错误码说明。6. 把审查清单变成日常动作回到 antirez 那篇文章。他说“写代码本身已经不再是必须的”这句话如果只理解到“让 AI 写就行”那 70% 重写的抱怨会一直存在。但如果理解成“生成变便宜了所以审查和验证必须变贵”整个事情就顺了。我现在的做法是任何 AI 生成的代码进仓库之前必须过一遍第 3 节那份清单触发两个以上 block 就重写不修补。边界输入必须实际跑不能只看模型说没问题。测试用例必须能独立运行不能依赖模型描述的“应该能过”。这套动作做熟之后审查一段几百行的代码大概五到十分钟。相比重写 70% 的时间这个投入是值得的。而且随着你积累的边界用例越来越多模型生成的代码质量也会因为提示词里带了这些约束而提升——它知道你会检查空输入就会主动处理空输入。如果你还没开始做代码审查建议从今天手头一段 AI 生成的代码开始按第 3 节的配置建一个.ai-review.json跑一遍第 4 节的验证请求。跑完你会对“哪些能直接用、哪些必须重写”有一个具体的判断而不是停留在争论层面。需要 API Key 的话去 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 创建接入细节看 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。想先手动试试模型对代码的判断力去 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 贴一段代码问它边界条件。长期做审查的话Coding Plan 在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后说一个我自己的习惯每次重写 AI 代码之后把重写的原因记一行在提交信息里。攒上几十条之后你会发现重写的原因高度集中在边界处理和错误路径上架构问题反而很少。这意味着你可以在提示词里提前把这些约束写进去让模型第一遍就少犯这类错。审查清单不是用来否定 AI 的是用来把它的输出收敛到可交付标准的。