AI编程工具效果分层：公开代码多则强， niche平台则弱

大多数关于"我如何使用 AI 编程工具"的文章都出自某个人——他整天泡在同一个 Web 框架里。这是个形成观点的合理起点，但它掩盖了我认为最有趣的事情：这些工具并非在所有场景下都一样好用，而且质量下降的方向非常可预测。

我的工作周不像一个框架那样整洁。在短短几天内，我可能会同时接触 Fortell AI 体育科技平台的 Unity 项目、Tested Media 公司 CallSetter AI 产品的 Retell 语音代理后端 n8n 工作流。在那之前还有 Geonode 公司运行在 Windows、Android 和 iOS 上的 C# SDK，以及 ARCortex 的 AR 工作。我每天工作日都在所有这些项目里用 Claude Code 和 Cursor。

在如此多样的技术栈中工作，让我总结出一条比"永远用它"或"永远别信它"都更实用的规则：

AI 编程工具在有大量一致公开代码、且能快速验证结果的地方表现出色。随着你深入专有平台 API、编辑器自有文件格式、以及唯一真正的测试就是"有人拿着真机站在那里"的系统，AI 的表现就会变差。

所以答案因层次而异。以下是我的分类方式。

它真正发挥作用的地方

把书面规格变成接线完成的首版

我最明显的胜仗是在 Fortell AI 构建和测试语音代理的流水线，我在《How I use Claude Code and Comet to build and test AI voice agents in a day》里写过。重要的不是提示词，而是规格文档。一旦需要捕获的字段、代理可调用的工具和升级规则都被清晰地写下来，Claude Code 就能一次性生成函数定义、n8n webhook 骨架和测试场景。

这可以推广。模糊的需求得到一个看起来合理但实际的猜测；精确的需求得到接近我本来会手写的内容，而且更快。大多数技巧其实在规格文档里。

存在于文件中的配置

任何声明式的、被提交到 git 的东西都很适合：工作流定义、CI YAML、环境模板、从 GraphQL schema 生成的类型、从厂商仪表板导出的语音代理配置。这些有明确的结构、明确的 diff，通常还有校验器。文件里的配置是工具可以读取、修改和解释的配置，也是审查者可以 diff 的配置。只存在于 Web 仪表板里的配置对两者都不可见。

读我没写过的代码库

作为_fractional CTO_，我经常接手别人写的代码。以前头几天都得手工追踪数据流。现在我让工具来做映射：一个值在哪里写入，哪些页面读取它，什么调用了这个端点。

我仍然会对照代码验证这个地图，因为一个自信满满的错误架构答案比没有答案更糟。但作为快速定位的手段，这是我找到的最大的时间节省，而且风险最低，因为工具说的任何东西都不会直接上线。

我本来会跳过的测试

针对纯逻辑的单元测试、fixtures、边界情况输入、语音代理的冻结回归场景。错误的测试通常会大声失败，这使得测试成为生成式友好的东西。真正的收益是经济性的：枯燥的测试套件变得足够便宜，以至于真的会被写出来。

它需要被严加看管的地方

这是我见过最自信的胡说八道的领域。在一个 React Native VPN 应用里，真正的行为存在于 Android 的 VpnService 和 iOS 的 Network Extensions 中，有权限、独立的进程和因操作系统及版本而异的后台规则（我在《A React Native VPN Is Two Programs, and Only One of Them Is JavaScript》里详细讲了那个分叉）。

AI 工具会欣然产出一个不存在的方法、一个两个版本前就被废弃的权限流程，或者一个只在真机上应用被切入后台十分钟后才失败的生命周期假设。这些没有一个会在编译时以显而易见的方式失败。有些直到用户提交工单才会暴露。

我仍然在这里使用工具，但把它当作快速阅读文档的助手，然后自己检查，绝不会不加信任地接受它生成的代码。Geonode 的跨平台 C# 网络核心也一样：共享逻辑适合生成，平台特定的边缘情况不行。

编辑器拥有的任何东西

Unity 把场景和预制体序列化为 YAML，看起来完全像是 AI 可以编辑的文本。实际上那些文件充满了编辑器管理的对象 ID 和引用，一个语法正确的手动编辑可能悄悄破坏一个你只在运行时才会注意到的引用。

所以我画的线是关于文件格式的所有权，而不是关于某个模型。我让工具写 C# 脚本、编辑器工具和构建脚本。我不让它编辑 Unity 编辑器拥有的东西。如果人类不应该手动编辑一个文件，模型也不应该。

视觉和空间相关的工作

在 AR 里，"能用吗"往往意味着"当你站在那里拿着手机时，它和现实世界对齐了吗"。没有任何编程工具能看到这一点。坐标数学可以生成，但一个锚点在真机上是否漂移了半米，这是现场测试，不是代码审查。

它完全不碰的地方

有些事我不委托给 AI，无论工具变得多好：

生产环境的电话号码、短信以及任何与真实客户通信的东西。配置错误的呼叫转移或发给真实潜在客户的测试短信是无法撤回的。

金钱和患者数据。支付流程、定价逻辑、任何接近临床工作或医院语音代理的东西。这些的审查负担是全面的，因此生成所节省的时间接近于零。

密钥。客户的 API 密钥、keystore 和凭证绝不放进提示词。这些工具会读取仓库和终端里的内容，所以密钥要放在环境变量和 CI 密钥库中，而不是放在工具会打开的文件里。

Reversing 成本高昂的决策。选语音平台、数据模型、哪个系统是真相来源、医疗代理何时转接给人类。工具可以列出选项。选择权和责任是我的，这也是客户为 CTO 付钱的主要理由。

我真正遵守的工作规则

规格优先，提示词第二。 如果我写不出"完成是什么样"，工具也写不出来。

把每个生成的变更当作一个刚入职的初级工程师写的来审查。 读 diff、运行它、检查边界。如果我不会让人合并它，我也不会让模型合并它。

保持循环小。 一次一个专注的变更，验证完毕，再来下一个。大量未审查的批次是自信错误藏身的地方。

把项目规则放进仓库。 一个简短的上下文文件，写明技术栈、约定和绝对不能碰的东西，能省下大量错误的猜测，它也是下一个真人的入职文档。

在真实目标上验证。 真机、真实的测试电话、staging 环境部署。"能编译"不等于"能运行"，而这个差距在工具最弱的地方恰恰最大。

把外部文本当作不可信输入。 一个读取网页或 issue 文本的编程代理可能被引导去做你没让它做的事，这和我写语音代理时说的《Nobody Hacked It. The Lookup Tool Just Took a Phone Number.》是同一种失败。权限保持收紧。

这如何改变了我思考的方式

诚实的版本是：AI 工具让我在项目中从来不是难点的部分更快——接线、样板代码、配置、测试脚手架、读陌生的代码。那些时间回过头来投入到真正决定产品是否成功的部分：架构、边缘情况、平台特定行为，以及关于客户真正需要什么的对话。

它们替代不了的是那个知道为什么 Unity 引用会坏、为什么 iOS 扩展在后台被杀死、为什么语音代理应该转接电话而不是接听的人。恰恰相反，它们提升了那种知识的价值，因为它们会产生大量看似合理的输出，而必须有人知道哪些是错的。

所有规则的根本只有一句：工具写作，我负责。

我很想知道其他人把线画在哪里。如果你工作的技术栈不主要是 Web，你最先停止信任哪一层？

Originally published on nabeelbaghoor.com.