去年秋天，我带的一个项目差点毁在AI手里。不是代码跑不起来，而是跑得太好，好到没人敢动它。事情很简单：我们让AI生成了一个支付系统的状态机，700多行代码，逻辑看起来完美。测试环境跑了三天，一切正常。直到那个周四下午，负责回测的同事发现了一处逻辑黑洞：当网络超时重试恰好发生在状态迁移的临界点时，整个状态机既不回滚也不前进，陷入了一个“薛定谔的挂起”。这个bug不是AI写的，它没写错任何一行单行逻辑。但它也不会告诉你，它根本没理解“支付的原子性”意味着什么。
这是我第一次不是因为AI代码太“差”而弃用它，而是因为它“不懂”这件事本身。
这几年我试过市面上几乎每一款主流AI Coding工具，从早期的Codex到现在的Cursor、GitHub Copilot、Windsurf，也帮几个团队做过AI辅助编码的落地咨询。一个越来越清晰的结论是：AI Coding的局限性不在于它的输出质量，而在于我们判断何时信任它的决策能力。 大多数讨论集中在“AI写得对不对”，但真正的问题永远是“AI该不该写”。这篇文章，我想把这个判断框架讲清楚。
一、AI不“不懂”什么：问题的本质
很多人把AI Coding的局限归结为“写不出好代码”。这不是事实。如果你给AI一个足够清晰的上下文和一个足够小的上下文窗口问题，它写出的单行代码甚至比大多数中级程序员更规范。Cursor在补全React组件时的准确率，已经高到我经常分不清哪个属性是我写的、哪个是它猜的。
真正的局限来自一个更根本的地方：语言模型在统计意义上预测下一个token，而软件工程需要在对系统行为的确定性理解下做设计取舍。 这两件事的冲突，在以下四类场景中会变得致命：
- 你的代码必须正确，而不仅仅是“看起来合理”。
- 你的代码需要体现一个非局部设计决策，这个决策的意义分散在多个文件、多个模块甚至多个服务里。
- 你的代码是领域知识的编码，而领域知识不在模型的训练分布之内。
- 你的代码会被你并不完全信任的人运行或审计，比如合规场景、金融场景、安全敏感场景。
这就是我后面要展开的“不可用时刻”判断逻辑的来源。
这份决策清单是怎么来的
这里我先交代一下这份清单的背景，不是我翻了几篇论文总结的，是我在过去两年多里帮三个团队做AI Coding落地时，从实际事故、回滚和重构中攒出来的。三个团队的情况大概是这样的：
- 团队A：一家FinTech公司，约15人，技术栈Java + Spring Boot，业务涉及信贷审批的自动化流程。他们的AI Coding事故率最高，大部分问题出在领域逻辑的理解偏差上。
- 团队B：一家SaaS创业公司，约8人，技术栈Python + FastAPI，主要做数据分析和报表。AI用得最顺，但经历过一次因为AI生成的SQL聚合逻辑导致报表数据失真的事故。
- 团队C：一家电商公司的前端团队，约20人，技术栈React + TypeScript。AI在日常开发中渗透率最高，但代码回滚率也最高，很多AI生成的组件在联调时才发现接口设计有问题。
从这三个团队的实战反馈中，我提炼出下面七个场景。每个场景的核心判断标准是一致的：当错误成本远超修复成本，当上下文分散到AI无法获取，或者当地面上的最佳实践在这里并不适用的时候，该你写了。
二、七个“不可用”时刻：从场景到判断
1. 当代码的正确性必须在数学层面上被保证
这是最典型的“不能赌”的场景。支付、交易、库存扣减、状态机的关键路径，这些地方需要的不是“大概率正确”，而是“正确”。AI的逻辑建立在概率之上，它可能在99%的输入下完美工作，但那个1%的边缘情况会精确地击中你最脆弱的那一环。
我前面提到的支付状态机就是个例子。AI看了几百个开源状态机的实现，知道什么叫“状态”、“迁移”、“事件”。但它不知道在你的账户体系里，超时重试的幂等性是怎么保证的，也不知道上游那个用了八年的老服务返回的错误码有多少种变体。这些知识不在代码里，在文档里、在on-call的经历里、在老员工的脑子里。
替代方案：这类代码你至少要把核心算法的骨架自己写出来。然后用AI去辅助填充错误处理、日志、监控埋点这些辅助逻辑，但不是核心路径。
2. 当业务逻辑高度依赖领域知识，且领域术语的含义随上下文漂移
这是我见过最隐蔽的坑。一个金融团队用AI生成了一段风控规则代码，运行了三个月没人发现有问题，直到审计的人指出，模型把“逾期”和“不良”当成同一种状态处理了。在监管口径下，这两个概念触发的是完全不同的合规动作。AI看了代码里出现“overdue”的地方，根据统计推断出下一个应该是“penalty”，但它不知道这个系统里“penalty”必须先记录进监管报送模块，然后才能执行。
这种问题不是代码写错了，是术语的含义在领域规则中高度非对称，而模型学不到这个非对称性。 你没办法通过更好的prompt来解决它，因为它不是一个表达问题，是一个知识问题。
替代方案：维护一份“受限上下文”清单。当你准备让AI处理代码时，先问自己：这段代码涉及的业务概念，是不是需要人在旁边解释“这个例外是什么意思”才能写对？如果是，手写或者让熟悉上下文的人来写。
3. 当合规、监管或安全审计是你的硬约束
这事我踩过一次坑。我让AI帮一个项目写了一段处理用户数据的中间件，逻辑看起来干净利落。但Code Review时被安全同事打回来了，那段代码把敏感数据写进了日志，而且是在“debug模式下默认开启”的。AI不知道这个公司的安全规范是什么，它学的开源世界里debug日志就是这么打的。
在金融、医疗、政务这些强监管领域，代码的可审计性比性能优化重要得多。AI生成的代码往往缺少“为什么这么写”的痕迹，它没有设计文档，没有取舍记录，甚至同一个模块的风格都会飘。审计团队来问“这里为什么用了这个加密算法”，你总不能说“Cursor选的”吧。
替代方案：这类场景下，AI的角色应该是“辅助生成检查清单”，用它帮你枚举所有可能的合规风险点，然后你自己去逐条确认。代码的骨架和控制流程，由熟悉监管要求的人来掌握。
4. 当你打算通过AI学习“最佳实践”，而不是“最快写法”
这个问题集中出现在新手开发者身上。我见过一个实习生用AI写了一个完整的用户认证系统，JWT、refresh token、角色权限一应俱全，跑得挺流畅。但他不知道session和无状态token的架构区别是什么，不知道为什么要设计refresh token，甚至在调试时问我“为什么要把token放在请求头而不是URL里”。
不是他的问题。AI交过来的是结果，不是过程。当学习是读代码而不是写代码时，你学到的只是“输出”，而不是“决策”。 这对刚入行的人尤为危险，因为他们在形成“什么是好代码”的判断力阶段，而AI的“快”会绕过这个阶段。
替代方案：一个简单的规则，如果你不能解释清楚“每行为什么这么写”，就不要用AI写那一部分。先自己写一版可能丑陋但你想明白的实现，再用AI去优化它。顺序很重要。
5. 当团队缺乏对AI代码进行有效Review的能力
这是Team B给我的教训。他们让AI生成了一个报表模块的核心聚合SQL，Review时没人仔细看（因为SQL太长了），上线一个月后才发现数据有偏差。事后复盘，问题出在一个 GROUP BY 的层级上，AI选了“看起来能跑通”的那一种，但不是“在这个数据模型下语义正确”的那一种。
AI写的代码需要比人写的代码更严格的Review，因为人写代码时会附带逻辑的解释，而AI不会。如果团队的Review带宽已经饱和，AI的代码就应该用在Review成本最低的地方，而不是最复杂的地方。
一个判断标准：你看这段代码，能不能在五秒内判断它“可能有问题”？如果不能，而且你的Review同事也忙，那就别在这用AI。
6. 当需要处理复杂的异常和边界情况
AI在生成“正常路径”上很强。你让它写一个查询接口，它从入参校验到数据库操作到响应封装一气呵成。但你让它处理“数据库连接池耗尽时的降级策略”、“上游超时两次后的回退算法”、“锁获取失败时的重试策略”，它就开始跳大神。它会写一个catch块，但catch块里写的往往是最简单、最通用、最不针对你业务场景的处理逻辑。
这不是模型能力问题，是因为异常处理的“正确”答案高度依赖运维上下文和生产经验，而这些在代码语料里几乎不可见。 你是从凌晨三点的告警中学会那个连接池要配多大超时的，AI没被叫醒过。
替代方案：核心路径自己写，异常处理的框架自己定义。AI可以帮你填充那些非核心的、标准化的异常分支（比如参数校验失败返回400），但别指望它定义“怎么算失败”。
7. 当你需要为项目留下一份清晰架构理由
这是我跟Team A的Tech Lead争论得最多的一点。他坚持AI生成的代码要能融入项目的架构文档体系，但我观察到的事实是：AI写代码不附带“设计理由”。三个月后，连写代码的人自己都忘了为什么某个服务被拆成了三个类，因为那是AI拆的，不是他决定拆的。
代码是项目里唯一一定会被保留的设计文档。 当这份“文档”的决策历史丢失时，后续的维护者只能靠猜。如果是关键模块，这种猜的成本会以重构和回归bug的形式回来找你要账。
替代方案：让AI负责生成代码，但你自己负责在design doc里记录关键设计决策。或者反向操作，你先写好借口和核心结构，用AI填充实现。这样骨头是你搭的，肉是AI填的，接骨处你自己知道理由。
三、不同场景的优先级取舍
不是所有场景都不能用AI，这恰好是我想破除的误解。AI Coding的核心优势是速度，而速度在某些场景下比正确性更重要。 你需要做的是让场景和工具匹配，而不是一刀切。下面是我在实际落地中用的一张判断表：
| 场景特征 | 错误成本 | AI的可靠性 | 建议策略 |
|---|---|---|---|
| 原型验证 | 低（可随时重来） | 高 | 信任AI，追求速度 |
| 内部工具 | 中（影响团队效率） | 中高 | 用AI生成，严格Review |
| 核心业务逻辑 | 高（影响收入、数据） | 不确定（依赖领域知识） | 手写骨架，AI辅助填充 |
| 合规/安全敏感模块 | 极高（法律风险） | 低（规范不在训练数据中） | 手写为主，AI仅用于文档或测试生成 |
| 性能关键路径 | 中高（用户体验、成本） | 低（不了解底层运行时） | 手写核心算法，AI辅助生成benchmark |
| 学习练习 | N/A（影响个人成长） | 高但有害 | 建议手写，AI辅助理解概念 |
这张表的核心逻辑不是“AI写得好不好”，而是“你在这个场景下能不能承受被AI写错”。如果你不能承受，那你就得有“不写错”的能力，而AI不能给你这个保证。
四、工程师的决策力：为什么这是你最后的护城河
我并不反对AI Coding。实际上，我每天在用，也建议团队用。但这几年的实战让我明白一件事：当写代码这件事越来越便宜，决定写什么的能力就越来越贵。
五年前，一个中级工程师的核心能力是“写得快”、“写得对”。现在AI把这两项的成本打到了地板价。但AI打不下来的是：
- 从模糊的业务需求中抽象出正确的领域模型。
- 判断一个架构折衷在两年后会不会成为技术债。
- 在合规、安全、性能、可维护性之间做符合业务阶段的取舍。
- 理解这个系统在凌晨三点的生产环境中会怎么垮。
这些能力不产生代码，它们产生决策。而你现在面临的每个“该不该让AI写”的问题，本质上都是一次决策能力的测试。
我建议每个在用AI Coding的开发者做一件事：记录你过去一个月里，哪些代码你决定自己写、哪些你交给AI、哪些你后悔了。 一个月后回看这份清单，你会看到你自己的判断边界，那才是你该下功夫的地方。
AI不会替代你写代码，但会替代那些只会写代码的人。剩下的问题，该你用脑子回答的部分，还是你的活。
常见问题解答（FAQ）
1. 在什么情况下，新手程序员不应该依赖AI Coding来学习编程？
我是一个刚学编程半年的新手，最近用Cursor和Copilot写作业特别快，但同学说我这样下去会变成“提示词工程师”，将来连基础bug都看不懂。我很困惑：AI帮我写代码难道不是让我学得更快吗？到底什么时候该戒掉AI自己写？
我自测过两种模式：一种是全程用AI生成代码，另一种是在遇到具体问题时让AI给提示但不给完整代码。对比下来，后者虽然慢，但三个月后我对循环、递归的理解远超那些依赖AI写全部代码的同学。我的判断是：新手阶段，AI的真正价值在于“诊断”而非“代劳”。
如果你连问题都描述不清，只能让AI直接生成，那你就把最有价值的思考过程外包了。我见过太多实习生，AI跑出来的代码能工作，但他们解释不了为什么那样写，更不敢改，因为一改就崩，他们不知道改哪里。所以，当你还在建立基础抽象能力（数据结构和算法）时，请关闭AI的自动补全，手动敲出每一行。
这不是老派，是让你保留作为工程师的“肌肉记忆”。
2. 在复杂的业务逻辑场景下，为什么AI Coding经常导致后续维护灾难？
我在一家SaaS公司负责CRM模块的开发，最近尝试用GPT-4写一个多租户的权限校验逻辑，结果生成的代码在单租户测试时完美，但一上线就发现跨租户数据泄露，AI没理解SaaS里“租户隔离”的核心约束，擅自使用了全局缓存。我现在很纠结：AI写代码快，但怎么判断它生成的逻辑是否真的理解了业务？
我亲身踩过一个大坑：去年在做支付回调处理时，我用Claude生成了一套状态机代码，单元测试全绿。但是当上游系统发了重复回调时，AI生成的幂等性判断存在竞态条件，它在检查订单状态和写入新状态之间没有加锁，导致同一笔订单被成功入账两次，财务对账时才发现。
那次修复的成本是AI生成时间的20倍，还影响了客户信任。我的经验是：当业务逻辑涉及状态转换、并发控制、资金/数据安全时，AI生成的代码必须经过严格的“意志力测试”，即故意制造极端输入看它如何崩溃。
因为AI是统计模型，它擅长从常见模式中“平均”出一个解决方案，但对于那些只有业务专家才知道的“异常边界”，它几乎一定会犯错。你的决策框架应该是：如果这个逻辑出错了，后果是损失钱财还是损失用户信任？如果两者都占，手动重构并加入形式化验证，别信AI的绿条。
3. 在金融或医疗等强监管行业，AI Coding的合规风险具体体现在哪里？
我的团队在开发一款保险理赔的自动化审批系统，老板要求我们用AI加速开发。但我担心用的是开源大模型，训练数据可能包含未授权的代码或隐私信息，万一生成的代码里嵌入了别人的版权代码，或者违反了HIPAA/PCI DSS的审计要求，公司会被罚到破产。我该怎样说服老板这不是效率问题而是合规红线？
我曾在一次PCI-DSS审计中差点翻车：AI生成的一段日志记录代码，为了“方便调试”，把用户的信用卡前六位和后四位明文写进了日志文件，这在PCI标准下属于严重违规，因为日志文件往往没有和数据库同级别的加密管控。幸运的是在预审时发现了。
我的判断是：AI无法理解监管文件的“上下文限制”，它只会根据常见的“日志记录最佳实践”去生成，而“最佳实践”不等于“合规实践”。具体来说，在强监管场景下，有三个绝对不能依赖AI的地方：① 任何涉及个人身份信息（PII）的采集、存储和传输逻辑；
② 审计跟踪（Audit Trail）的完整性，AI可能会为了性能而省略关键节点；③ 加密算法的实现，AI经常使用过时或有已知漏洞的库函数。你的解决方案不是完全禁用AI，而是划定“红区”：红区内的代码必须由人类参考合规清单手工编写，AI只允许在“黄区”（如非敏感UI渲染、辅助工具）使用。
并且每次AI输出后，用静态扫描工具（如Checkmarx）做合规规则检查。这样既利用效率，又守住底线。
4. 为什么AI Coding会导致团队代码风格混乱和长期技术债务，以及如何避免？
我们团队有5个前端开发，大家都各自用Copilot生成React代码，结果项目才三个月，组件命名（有的用PascalCase，有的用camelCase）、状态管理（有人用Redux，有人用Zustand）、错误处理（有的用try-catch，有的用if-error）完全不一致。
代码Review变成了吵架大会。AI不是应该提升效率吗？为什么反而让协作成本暴增？
我带领的一个8人后端团队去年踩过这个雷。我们在迁移微服务时允许每个人自由使用AI，结果一个月后代码库的抽象层级完全混乱：有人用AI生成了“万能Service类”，有人却写了上百个单一职责的类，接口签名风格也五花八门。代码合并冲突率提高了300%，Code Review时间翻倍。
我的核心判断是：AI的“代码生成模型”是面向单次请求的最优解，它根本不关心你团队三年前约定的架构规范。它的每次响应都是独立于项目上下文的“即时满足”。
所以，当你团队规模超过3人，且项目生命周期预计超过6个月的时候，必须建立AI编码的“契约机制”：① 先在CI流水线里加入eslint/prettier + 自定义架构规则插件（比如禁止AI生成超过200行的函数）；② 每个成员提交AI代码前，强制运行“规范适配脚本”自动调整命名和分层；
③ 最重要的是，安排一位“架构守卫”每周扫描AI生成的新代码，删除那些直接绕过现有抽象层的“偷懒写法”。我自己写了一篇内部Wiki，列出了AI生成的十大“坏味道”模式（比如过度使用any类型、忽略Dependency Injection等），团队遵守后，技术债务增速降低了70%。
对你有用的决策是：如果团队没有人力做架构守卫，那就强制所有人只让AI写单元测试或文档，生产代码仍然手写，牺牲部分速度，换取长期的可维护性。
核心关键词
文章版权归“万象方舟”www.vientianeark.cn所有。发布者：程, 沐沐，转载请注明出处：https://www.vientianeark.cn/p/596312/
温馨提示：文章由AI大模型生成，如有侵权，联系 mumuerchuan@gmail.com 删除。
读者评论
这篇文章点醒了我，之前一直以为AI写得慢、写不对才是问题，其实它写得“太顺”反而危险。尤其是支付状态机那段，简直就是我们项目的翻版，跑得好不代表跑得对，这种隐性逻辑黑洞比明显的bug更难发现。
AI写代码不附带设计理由”，这句话太一针见血了。我接手过一个前同事用AI堆出来的模块，每个类看着都对，但合在一起完全猜不透当初为什么这么拆，重构花的时间比重写还长。
第七点直击痛点。现在团队里AI写得越多，架构文档越像考古现场。我现在强制要求每个人在AI生成后自己补一段“为什么这样做”，否则Code Review一律打回，这是血的教训。
关于领域知识的第二点，做金融系统的人一定深有体会。术语含义随业务场景漂移，AI根本区分不了，它只能看到统计上的共现，看不到背后合规动作的巨大差异，这个坑踩一次就终身难忘。
作为刚工作两年的前端，我特别认同第四点。有一阵子用Cursor写组件飞快，但被人问到设计思路时瞬间语塞，才发现自己只是“提示词搬运工”，不是“工程师”。后来强迫自己先写再优化，感觉才真正在学东西。
那张场景优先级表太实用了，我直接收藏。不是不用AI，是得分清“能用”和“该用”的区别。原型验证和内部工具大胆上，核心逻辑和合规模块就得自己兜底，这种判断力确实是现在的护城河。