Boris Cherny 那句话说出口的时候我第一反应是“又来一个 AI 吹鼓手”。但等我真把 Claude 用在生产环境、被它写的代码坑过几次、也亲眼见过它写出让我汗颜的抽象设计之后我改变判断了他说得不仅不夸张反而可能是未来两三年内所有工程团队都必须正面回答的问题。先交代一下背景Boris Cherny 是 TypeScript 手册的作者长期在一线写代码、带团队也是 AI 编程工具的深度使用者。他的核心观点是如果我们要把 Claude 生成的代码合入生产分支那这些代码应该满足比人类同事提交的代码更高的标准——因为 AI 生成代码的成本趋近于零如果不加筛选地全盘接受劣质代码就会以远超以往的速率涌入代码库。仔细想想这句话其实是把“AI 编程”从炒作拉回了工程现实门槛降低了但验收门槛必须同步提高。本文结合我这段时间在生产项目里使用 Claude Code 的实际体验聊聊“更高标准”到底意味着什么、怎么通过工具链和流程去实现以及普通开发者如何不变成 AI 代码的“人肉确认按钮”。如果你正在用或打算用 Claude 写生产代码这篇内容应该能帮你少走不少弯路。1. “比人类更高标准”的真正含义不缺代码缺的是可靠过去十年我们讨论“代码质量”默认的上下文是代码由人编写人有成本、有疲劳、有状态波动所以质量管理的重点往往放在“减少人的失误”和“提升人的输出下限”上。但 Claude 这类模型出现之后游戏规则变了。1.1 人类代码的“容忍空间”来自哪里人类写代码一天能稳定产出几百行高质量逻辑已经是相当好的状态。哪怕这笔代码存在设计瑕疵它也是经过思考、花费心力产出的团队在上线前会做 Review、测试。这个过程天然过滤掉了一部分问题也天然容忍了一部分问题——因为“重写成本”很高很多瑕疵只要不影响核心功能就会被带着上线留到后续重构。这就是人对代码的“容忍空间”不是质量达标而是“可接受瑕疵”的阈值比较高。1.2 AI 代码的成本结构完全不同Claude 生成一段代码成本趋近于零而且速度极快。这带来一个反直觉的结果AI 代码如果质量只是“和人类差不多”那它给项目带来的总质量其实是下降的。为什么因为数量。一个开发者一天写 200 行代码Review 一遍是可控的但如果 Claude 一天帮你生成 2000 行而质量还是“普通人类工程师”的水平那这 2000 行里的瑕疵数量就会成倍增长Review 成本会爆炸代码库熵增会加速最终你省下的编码时间会全部赔进 Debug 和返工里。Boris Cherny 说的“更高标准”本质是在数量激增的前提下用更严格的验收标准来对冲 AI 的高产出。换句话说Claude 写一万行平庸代码不如它写一千行接近完美的代码。前者让项目加速腐烂后者才是生产级工具该有的样子。1.3 生产代码的“标准”具体指什么在生产环境里我们对 AI 生成代码的验收标准应该是一份显式的质量清单而不是一句模糊的“能不能跑”。我根据自己的实践整理了一份可执行的“AI 代码生产准入标准”类型安全TypeScript 项目必须开启 strict 模式AI 生成的 any、类型断言必须有明确理由。错误处理外部调用必须处理失败路径不能只写 happy path。可维护性函数有明确边界、命名自解释、逻辑拆分合理。可测试性核心逻辑应该是纯函数副作用被隔离方便写单测。无死代码AI 特别喜欢生成“看似合理但从未被调用”的工具函数必须在合入前清理。安全与性能涉及用户输入必须做校验不能出现明显的 N1 查询、内存泄漏等低级问题。注意上面这些标准并不是新东西但过去它们是“软性期望”现在必须变成“硬性门槛”。因为 AI 没有自尊心不会因为被拒绝而沮丧我们可以毫无心理负担地让它改到符合标准为止。2. 想用高标准约束 Claude先把 Claude Code 跑起来标准定得再高工具跑不起来也是空谈。目前把 Claude 接入生产工作流最主流的方式就是Claude Code——Anthropic 官方的命令行编程代理能直接在终端、编辑器里和你协作读写项目文件、执行命令、运行测试。从安装到配置这一节我把完整链路和过程中最容易翻车的点都捋一遍。2.1 安装前的环境准备我在 Windows、macOS、Linux 三套环境上都装过 Claude Code整体感受是macOS 和 Linux 最顺滑Windows 需要额外注意一个坑——虚拟化平台必须开启。安装之前先确认环境满足以下条件Node.js 18 以上推荐 20 LTS自带 npm。能正常访问 Anthropic 的 API 服务这里指的是使用官方 API 的网络连通性具体网络配置按你自己环境来。Windows 建议用 PowerShell 7 或 Windows Terminal。用 npm 全局安装npm install -g anthropic-ai/claude-code安装完成后验证版本claude --version如果看到版本号说明安装成功。接下来在项目目录里启动cd your-project claude首次启动会自动完成认证流程需要你的 Anthropic API Key 或者订阅账号的授权。2.2 Windows 上的经典报错与解法在 Windows 上很多朋友会遇到这个报错Claudes workspace requires the Virtual Machine Platform on Windows. Please enable it.这个错误的意思是Claude Code 的工作区依赖 Windows 的虚拟机平台Virtual Machine Platform功能但你的系统默认没有启用。修复步骤如下以管理员身份打开 PowerShell。执行Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform重启电脑。再次运行claude。这里顺便说一句为什么 Claude Code 在 Windows 上依赖虚拟化功能主要是因为它在本地需要跑一些隔离的环境来执行代码和沙箱操作跟 WSL2 的底层机制类似。如果你之前用 WSL2 出现“请启用虚拟机平台”的提示那这两个属于同源问题。2.3 在 VS Code 里配置 Claude Code很多人习惯在 VS Code 里写代码Claude Code 也支持这种用法。最直接的方式是把 Claude Code 作为终端工具在 VS Code 内部运行——底部打开终端切到项目目录跑claude就行了。想要体验更好我建议做两件事第一安装官方扩展。在 VS Code 扩展市场里搜索 “Claude Code”安装 Anthropic 官方出品的扩展。装好后你可以直接在侧边栏跟 Claude 对话它能看到你当前打开的文件和目录结构上下文理解比纯终端模式友好很多。第二配置工作区信任。这是最容易被忽略的一步。Claude Code 要读写文件、执行命令VS Code 会弹窗询问是否信任该工作区。必须选“是”否则 Claude 只能看不能改等于半残状态。我在实际使用中的配置项大致如下.vscode/settings.json或全局配置均可{ claude-code.enable: true, claude-code.defaultModel: claude-sonnet-4-20250514, claude-code.terminalMode: true }具体字段名会随版本迭代变化以你安装的扩展说明为准。核心思路是让 Claude Code 能读能写但保留你在 VS Code 里的最终控制权。2.4 下载与版本更新容易被忽视的细节Claude Code 的下载安装走的是 npm 包分发因此npm的镜像源配置会对下载体验产生直接影响。如果你的网络环境访问默认 npm 源比较吃力可以换成国内镜像npm config set registry https://registry.npmmirror.com日常使用中版本更新也很频繁建议隔一段时间执行一次npm update -g anthropic-ai/claude-code个人建议没必要追每一个小版本但大版本升级时务必行为变更日志CHANGELOG。Claude Code 迭代节奏很快某些配置项和默认行为会变例如模型切换语法、权限模型等升级后原本可用的流程可能就废了。3. 让 Claude 写出“生产级代码”的核心方法上下文、规范与迭代工具装好了接下来的问题是怎么让 Claude 输出的质量真正达到 Boris Cherny 说的“更高标准”实操中我发现Claude Code 的能力底线很高但如果你的输入是模糊的、上下文是不完整的、规范是缺失的它输出的就是“看起来能用但经不起推敲”的代码。想要高质量输出必须在三个层面下功夫。3.1 上下文就是一切把项目规范“喂”给 Claude很多人用 Claude 写代码直接在对话框里说“帮我写一个用户登录接口”然后就等着看结果。这个用法放在 Demo 阶段没问题但用在生产环境就太草率了——因为 Claude 不知道你的项目结构、不知道你的错误处理约定、不知道你的命名风格、不知道你的目录分层逻辑。解决这个问题最有效的方式是在项目根目录创建一份CLAUDE.md文件把项目的“元知识”写进去。Claude Code 启动时会自动读取这份文件把它作为理解项目的核心上下文。我现在的CLAUDE.md大致包含这些板块# 项目概览 - 项目名称、技术栈、核心业务逻辑一句话说明 # 代码规范 - TypeScript strict 模式禁止 any - 函数必须显式声明返回类型 - 组件命名使用 PascalCase工具函数使用 camelCase - 所有外部 API 调用必须 try/catch 并返回 Result 类型 # 目录结构 - src/modules 下按业务模块划分 - 每个模块包含 model/service/controller/validator 四层 # 测试要求 - 核心业务逻辑必须附带单元测试 - 测试命名格式: should_xxx_when_yyy # 注意事项 - 不要修改 src/shared 下的公共类型 - 数据库迁移必须生成独立的 SQL 文件不允许在代码中隐式修改表结构有了这份文件之后Claude 的输出质量提升是肉眼可见的。它不再凭空猜测而是会主动遵循你定义的规范来生成代码。不需要你每次重复“用严格模式”“错误处理要完整”它自己就知道该怎么做。3.2 精确的 Prompt 不是“请写一个 XXX”而是“给它一个任务简报”你可能看过很多教程说“Prompt 要详细”但没告诉你详细到什么程度。我的经验是生产级 Prompt 至少要包含以下信息目标这段代码要解决什么问题。约束必须遵守哪些规范、不能使用哪些依赖。验收条件代码合并前必须满足哪些标准。参考代码如果有类似实现贴上作为风格参考让代码风格和上下文一致。举个例子一个不好的 Prompt帮我写一个获取用户订单列表的 API一个好的 Prompt用 Claude Code 的交互式输入或者claude -p带参数模式在 src/modules/order/service.ts 中实现 getOrdersByUser 函数 功能根据 userId 分页查询订单列表按创建时间倒序。 约束 - 使用 Prisma 访问数据库禁止 raw query - 返回类型必须是 { items: Order[], total: number } - 每个订单必须附带关联的 orderItems 和 paymentStatus - 用户不存在时返回业务错误码 ORDER_USER_NOT_FOUND 验收条件 - 包含输入校验page 最小为 1pageSize 最大为 100 - 编写对应的单元测试覆盖正常分页、空列表、用户不存在三个场景 - 不修改现有表结构和 Prisma schema在实际使用中这么写 Prompt 看起来“麻烦”但 Claude 返回的初版代码质量会高出几个等级。因为它有足够的信息去做出正确决策——从“猜一个实现”变成了“按照需求规格执行”。3.3 迭代式生成把“一次写完”改成“边审边改”还有一个操作习惯上的转变。过去我们写完代码才 Review现在用 Claude 写代码Review 应该提前到生成过程中。我发现 Claude Code 支持多轮对话每一轮你都可以要求它解释代码、指出潜在问题、给出修改方案。正确的做法不是让它一口气甩给你几百行代码而是分步骤推进先让 Claude 给出技术方案和文件调整清单。确认方案后再逐文件生成代码。每个文件生成后立刻 Review有疑问当场追问。这套流程下Claude 输出的代码会带有非常清晰的“设计意图”——因为方案是你俩一起敲定的它知道自己为什么这么写。后续的维护者甚至几周后的你自己也能顺着这个思路读懂代码逻辑。4. 实战中 Claude 最容易“降级”的地方四个典型陷阱Boris Cherny 提出“更高标准”还有一个隐含前提Claude 生成高质量代码不是常态而是需要刻意引导的结果。以下是四个我在这段时间反复踩到、也反复向团队强调的典型问题。4.1 类型安全的“虚假繁荣”any 和类型断言满天飞TypeScript 项目是最容易看出 AI 代码质量的地方。Claude 在面对复杂的类型推导时经常会“偷懒”**: 一个复杂的 API 响应它可能直接定义成any或者用一个as SomeType草草了事。表面上代码能跑类型检查也通过但一进生产就变形。最好的应对方法是在CLAUDE.md和 Prompt 里明确禁止无理由的any并且在 CI 里加上 ESLint 规则typescript-eslint/no-explicit-any设置为 error让它从机制上过不了关。4.2 错误处理只写“快乐路径”让我印象最深的一次是让 Claude 写一个支付回调处理函数。它把正常流程写得行云流水但对重复回调、签名校验失败、数据库写入冲突这三个关键异常场景只留了 console.log 和 return。这在 Demo 环境没什么问题但生产环境里这就是事故隐患。现在的解决方式是Prompt 里明确要求“覆盖至少三个错误路径”同时在 Review 时把“异常路径覆盖率”作为重点检查项。4.3 逻辑“过度设计”或“设计不足”Claude 有一个特点是它倾向于在代码里堆砌设计模式——抽象类、工厂、依赖注入全部给你安排上。如果是几十行的小功能这就是严重的过度设计增加理解成本。反过来面对大规模重构任务时Claude 又容易视野过窄只看到局部做出来的设计撑不起未来三个月的演进需求。我的处理方法是在 Prompt 里显式声明代码风格——“优先简单直接的实现不要引入不必要的抽象”。如果任务复杂度高我会先让 Claude 输出技术设计文档评审通过后再进入编码阶段。4.4 对“上下文”的遗忘一致性被破坏Claude Code 带着上下文工作但在超长对话里它也会出现“忘了前面约定”的情况。例如项目约定所有外部服务调用都要经过services/目录封装但 Claude 在后半段生成代码时可能直接在新代码里裸调fetch()。它不是故意违规是对话太长后注意力被稀释了。应对措施把项目规范写进CLAUDE.md这样即使对话进行到几十轮之后Claude 每次行动前仍然会参考这份文件。另外重要约束我会在关键 Prompt 中重复强调不嫌啰嗦。5. 从“能跑”到“达标”用工程化手段把 AI 产出锁进高水位判断 Claude 代码达不达标不能靠感觉要把标准“工程化”——让工具和流程替你把关。5.1 把响应标准写进 REAMDE人类和 AI 都按同一套规矩来我现在的做法是在CLAUDE.md之外额外维护一份AI_CODING_STANDARDS.md专门描述 AI 生成代码时的硬性要求。内容包含类型安全规则、禁止使用的不安全 API、错误处理最低要求、测试覆盖的最低标准、代码风格指南、性能约束等。这份文档有双重作用第一给 Claude 看每次会话启动时它会自动加载第二给人类 Review 者看作为审查清单使用。5.2 代码审查机制升级人是质量的最后防线Claude 生成代码后Review 流程不能省但方式可以更聪明。我现在对 AI 代码的审查分为三层第一层AI 自检。要求 Claude 代码完成后执行一遍tsc --noEmit、eslint、prettier --check自己先跑完静态检查把问题改完再交上来。第二层关键点人工复审。我重点看三处错误处理是否完整、边界条件是否覆盖、类型安全是否达标。这三处只要没问题代码大概率可以合入。第三层测试验证。要求 Claude 补齐单元测试并跑通全部测试用例。如果逻辑复杂到无法写单测那大概率是设计有问题应该回头改代码而不是跳过测试。5.3 让 Claude 自己“解释代码”保底手段还有一个让我 Recommended 给所有团队使用的小技巧让 Claude Code 为每个核心模块生成简短的 README 说明解释它写了什么、为什么这样写、潜在风险点是什么。这不是写给机器看的是写给未来的维护者看的。当 AI 生成的代码在半年后出现问题时这些文档能省掉大量考古式排查的时间。claude -p 请为 src/modules/payment/service.ts 生成一份代码说明文档解释主要函数职责、调用关系、错误处理策略和已知限制直接输出 Markdown 格式你会发现这个简单动作能让 AI 生成代码的“可维护性”提升一个层级——因为它强迫 Claude 重新审视自己的代码而且输出文档时它经常会主动补上一些你没问、但对维护很有价值的注释和提醒。5.4 建立“AI 代码不合格”的反馈闭环最后也是最重要的一点当 Claude 生成代码不达标时不要默默自己改掉。把拒绝意见和修改要求明确反馈给它让它基于 Review 反馈重新迭代。Claude Code 支持多轮对话这意味着你可以把 Review 意见作为新的输入要求它修改这段代码有两个问题 1. 错误处理没有覆盖第三方服务超时的场景请补充超时重试逻辑。 2. 类型定义里出现了 any请根据 API 文档补齐具体类型。 请直接输出修改后的完整代码不要输出解释。这就形成了一个“生成 - 审查 - 反馈 - 再生成”的高质量闭环。每一次 Review 反馈都在微调 Claude 的输出分布让它逐步逼近项目的真实标准。用这种方式代码质量上限是被持续推高的。6. 顺着这个思路再往前一步AI 时代的“技术债管理官”聊到这儿我想把视线拉远一点。Boris Cherny 那句“更高标准”不仅是对 Claude 说的也是对所有开发者说的。它提醒我们注意一个严酷的现实AI 大大降低了生成代码的边际成本但没有降低代码维护的长期成本。过去代码是稀缺资源所以“写出代码”本身就自带价值。现在代码正在变成“廉价资源”真正值钱的能力变成了判断力、设计能力和提需求的能力。这就带来一个角色层面的转变**每个使用 Claude 的开发者事实上都在同时扮演程序员和技术债管理官。**你不仅要对“这段代码怎么实现”负责更要对“这段代码该不该进代码库”“进了之后未来三年会不会爆炸”负责。技术债不再是某个季度末存量的清算问题而是每一轮 Claude 对话的增量问题。你今天放过的任何“以及格线水平”的 AI 代码都会滚成明天的维护包袱。所以高标准的本质其实不是对 AI 苛刻而是对未来的自己负责。我在团队里推过一个内部口号“AI 可以把代码门槛降为零但我们的工程门槛不能降为负。”每一个允许合入生产分支的 AI 代码都要默认被当作最严格 Review 的对象——因为它的克隆速度太快了一个坏味道可能在代码库里瞬间复制出上百份。这条标准也反过来帮你省心当你习惯了用高标准去要求和筛选 Claude 的输出你会发现自己整体代码库的质量、稳定性和可维护性都在悄悄变好。AI 高产出的洪水经过高标准这道堤坝的过滤最终浇灌出来的反而是更健康的工程土壤。