1. 这不是AI能力的边界，而是人脑不可让渡的决策主权
“用了半年 AI 编程，我总结出 5 类‘别让 AI 碰’的场景”——这句话在技术社区刷屏那天，我正盯着一段由 Copilot 自动生成、语法完美但逻辑完全反向的权限校验代码发呆。它把if user.is_admin()写成了if not user.is_admin()，还顺手删掉了关键的日志埋点。更讽刺的是，这段代码通过了所有单元测试——因为测试用例本身也是 AI 帮我补全的，而测试数据恰好全是 admin 用户。
这半年，我平均每天和 AI 编程工具对话 37 分钟，累计生成/修改代码超 12 万行，覆盖前端组件、后端服务、数据库迁移脚本、CI/CD 配置甚至技术文档。AI 不是替代我，而是放大我：写得更快、查得更广、试得更多。但越深入，越清晰一个事实——AI 编程真正的价值，不在于它能写多少行代码，而在于你敢让它在哪写、不敢让它在哪写。那些“别让 AI 碰”的场景，从来不是技术缺陷的清单，而是工程师职业判断力的锚点地图。
这些场景里，没有一行代码是 AI 写不了的，但每一处都藏着只有人类才能识别的风险权重、上下文灰度和责任归属。比如，当产品需求文档里写着“用户余额不能为负”，AI 会立刻生成if balance < 0: raise InsufficientFundsError；但它不会追问：这个“余额”是账户总余额、可用余额，还是某笔冻结资金的子集？扣款时是否要预留手续费？风控系统是否已同步该状态？这些不是编程问题，是业务契约的翻译问题。AI 擅长解构语法，但无法承担语义责任。
关键词如“AI 编程”“代码生成”“Copilot”“Cursor”“工程决策”“技术债”“生产环境”反复出现在我的日志里，但真正高频出现的，其实是那些被我手动加粗、标红、钉在 IDE 侧边栏的短语：“此处勿交由 AI 补全”“需人工复核业务逻辑链”“状态机转换必须手写”。它们不是对工具的否定，而是对自身专业坐标的确认——就像外科医生不会让机器人决定切哪根血管，哪怕它的机械臂比人手稳十倍。
适合谁读？如果你刚用上 AI 编程工具，正兴奋于效率飙升，这篇能帮你避开前 3 个月最痛的坑；如果你已用了一年，开始怀疑“是不是我太保守”，这里会给你一套可验证的判断框架；如果你是技术负责人，正评估团队接入策略，这些场景就是你制定《AI 编程红线手册》的核心条款。它不教你怎么用 AI，而是告诉你：在哪些地方，关掉 AI，才是最高级的用法。
2. 场景一：核心业务状态机与资金流向的“零容错区”
2.1 为什么状态机是 AI 的“认知盲区”
状态机（State Machine）是业务系统的心脏节律器。从电商订单的“待支付→已支付→发货中→已签收→已完成→已取消”，到金融交易的“挂单→撮合中→部分成交→全部成交→撤单”，每个状态转换都绑定着明确的业务规则、风控策略、审计要求和法律后果。AI 在这里失效，根本原因不在技术，而在建模逻辑的不可压缩性。
AI 训练数据中的状态机，99% 是教学示例：简单、线性、无分支、无并发冲突。但真实业务状态机是网状的。以一个跨境支付状态为例：
- 用户发起付款 → 系统检查 KYC 状态 → 若未完成，进入“KYC 待补充”并暂停；
- 若 KYC 通过，调用银行通道 → 银行返回“处理中” → 此时用户可能取消订单 → 系统需判断银行是否已扣款；
- 若已扣款，状态转为“已扣款-待清算”，需触发退款流程而非简单回滚；
- 若未扣款，状态回退至“待支付”，但需记录取消原因供风控分析。
这个过程涉及至少 4 个异步系统、3 类超时策略、2 种异常分支，且每条路径都有独立的幂等性要求和补偿机制。AI 生成的代码往往只覆盖主干路径（如if bank_response == 'success': goto next_state），却对bank_response == 'timeout'或bank_response == 'partial_success'这类边缘态选择性失明——不是它不懂，是训练数据里这类案例太少，且标注成本太高，模型默认将其归为“低概率噪声”。
提示：状态机代码一旦出错，修复成本呈指数级增长。一个状态跳转错误可能导致数万订单卡在“发货中”，客服热线瞬间瘫痪；资金状态错乱则直接触发监管审计，补救需追溯原始凭证、人工对账、出具法律声明。
2.2 实操中如何守住这条红线
我的做法是建立“三不原则”：
- 不自动生成状态定义：所有状态枚举（如
OrderStatus.PENDING_PAYMENT,OrderStatus.CANCELLED_BY_USER）必须手写，并附带中文注释说明业务含义、触发条件、下游影响。AI 可以辅助补全注释，但枚举值本身禁止生成。 - 不信任自动状态转换逻辑：
transition_to()方法的主体逻辑必须手写。AI 只能用于生成“转换前校验”或“转换后通知”的模板代码（如send_notification('order_status_changed', order_id)），且需人工确认事件名、参数结构是否匹配领域事件规范。 - 不绕过状态变更审计日志：每次状态变更必须写入独立审计表，包含
from_state,to_state,trigger_event,operator_id,ip_address,trace_id。AI 生成的日志代码常漏掉trace_id或混淆operator_id（把系统服务 ID 当作操作人 ID），必须逐字段核对。
去年我们上线新支付通道时，AI 基于旧通道代码生成了状态转换逻辑，漏掉了“银行回调超时后自动降级为失败”的分支。上线 2 小时后，37 笔交易卡在“处理中”，财务无法确认资金是否到账。回滚后，我重写了整个状态机模块，用有限状态机 DSL（如 XState）定义状态图，再手写转换逻辑。虽然多花了 1.5 天，但后续 6 个月零状态相关故障。
注意：不要用“AI 辅助审查”代替人工审查。我试过让 Claude 分析状态机代码，它能指出明显语法错误，但对“用户取消时若银行已扣款，应走退款而非回滚”这种业务规则冲突完全无感。它的审查本质是模式匹配，而业务规则是语义推理。
2.3 一个血泪案例：资金流水的“幽灵负数”
最危险的，是资金类状态机。我们曾有个“钱包余额变更”服务，AI 根据历史代码生成了如下逻辑：
def update_balance(user_id, amount): # AI 生成：先查再改 current = db.query("SELECT balance FROM wallet WHERE user_id = ?", user_id) new_balance = current.balance + amount if new_balance < 0: raise ValueError("Balance cannot be negative") db.execute("UPDATE wallet SET balance = ? WHERE user_id = ?", new_balance, user_id)表面看天衣无缝。但并发场景下，两个请求同时读到current.balance = 100，各自加-80，都算出new_balance = 20 > 0，然后都执行 UPDATE。结果余额变成20，而非正确的100 + (-80) + (-80) = -60（此时应拒绝第二笔）。真正的正确解法是使用数据库原子操作：
UPDATE wallet SET balance = balance + ? WHERE user_id = ? AND balance + ? >= 0;AI 生成的代码永远无法自发引入这种底层数据库语义，因为它没见过足够多的“高并发资金扣减失败”的真实报错日志。它只会复刻教科书式的“先读后写”范式，而这正是生产环境最致命的陷阱。
3. 场景二：安全敏感配置与密钥管理的“物理隔离带”
3.1 AI 的“记忆”是把双刃剑：它记得太多，也忘了太多
AI 编程工具最大的便利，是它能“记住”你项目里的命名风格、常用库、配置结构。但这也恰恰是它在安全配置上最危险的特质——它会把你不小心输入过的密钥、token、内部 API 地址，当作“上下文常识”反复复用。我们团队曾发生过一次惊险事件：一位工程师在调试时，为快速测试，把开发环境的 AWS Access Key 直接粘贴进 Cursor 的聊天框问“怎么连 S3”，AI 不仅给出了代码，还在后续几次代码补全中，自动将该 Key 填入新写的 Lambda 函数配置里。
这不是 AI 的恶意，而是其架构的必然。主流 AI 编程工具（Copilot、CodeWhisperer、Tabnine）均采用“上下文窗口+向量检索”机制。当你输入一段含密钥的代码，模型会将其编码为向量存入当前会话的上下文缓存。当它预测下一行代码时，会优先匹配相似上下文，于是密钥就作为“高相关性 token”被召回。更可怕的是，某些工具的本地缓存未加密，重启 IDE 后密钥依然存在。
提示：密钥泄露的后果不是“可能被黑”，而是“必然被扫”。公开网络上的密钥扫描机器人（如 TruffleHog、GitGuardian）每分钟爬取数万仓库，匹配正则后 5 秒内即可验证有效性。一个泄露的云服务 Key，平均 17 分钟内就会被用于挖矿或勒索。
3.2 安全配置的“四不碰”铁律
我给自己立下死规矩，凡涉及以下四类配置，AI 必须关闭：
- 不碰硬编码密钥：任何
API_KEY = "xxx"、DB_PASSWORD = "123"形式，AI 一律禁用。必须用环境变量（os.getenv("DB_PASSWORD")）或密钥管理服务（AWS Secrets Manager、HashiCorp Vault）。 - 不碰 TLS/SSL 证书路径：AI 常生成
cert_path="/etc/ssl/certs/myapp.crt"，但生产环境证书路径由运维统一管理，且需定期轮换。AI 生成的绝对路径会导致部署失败。 - 不碰权限策略声明：如 AWS IAM Policy、Kubernetes RBAC YAML。AI 会基于常见模板生成宽泛权限（如
"Action": ["*"]），而最小权限原则要求精确到s3:GetObject和指定 Bucket ARN。 - 不碰密码学原语参数：如 JWT 的
algorithm、AES 的mode和padding。AI 可能推荐已淘汰的HS256（若密钥泄露则全盘崩溃）或不安全的ECB模式，而正确选择需结合合规要求（如 PCI DSS 强制要求 AES-256-GCM）。
实操中，我用 IDE 插件（如 HashiCorp Vault Helper）在输入os.getenv(时自动提示环境变量名，替代 AI 补全。对于 IAM Policy，我坚持用 Terraform 模块化定义，AI 只能生成模块调用代码，策略体本身锁定为手动编写。
3.3 密钥轮换：AI 的“时间盲区”
另一个隐形雷区是密钥轮换（Key Rotation）。AI 生成的代码永远假设密钥是静态的。但合规要求（如 SOC2、GDPR）规定：云服务密钥必须每 90 天轮换，数据库密码每 180 天轮换。这意味着你的代码必须支持“双密钥并行”：新请求用新密钥，旧请求兼容旧密钥，直到所有客户端升级完毕。
AI 无法理解这种时间维度的过渡状态。它生成的鉴权逻辑永远是“用当前密钥验证”，而真实方案需要：
- 从密钥管理服务拉取“当前有效密钥列表”（含创建时间、过期时间、是否主密钥）；
- 验证时遍历列表，用每个密钥尝试解密，成功即返回对应密钥 ID；
- 记录每次验证使用的密钥 ID，用于审计和淘汰策略。
这个逻辑需要精确的时间比较、列表遍历和状态标记，AI 生成的代码要么漏掉遍历（只试第一个密钥），要么搞错时间比较逻辑（用datetime.now() > expire_time而非datetime.now() < expire_time）。去年我们因未实现双密钥，导致一次密钥轮换后，3 个遗留系统持续报错 47 小时。
注意：不要相信“AI 生成的密钥管理库”。我试过让 AI 推荐 Python 密钥管理方案，它列出了
cryptography库，但给出的示例代码用Fernet.generate_key()生成密钥后直接print(key)—— 这等于把密钥明文打在日志里。真正的密钥管理，是“不生成、不存储、不打印”，只调用托管服务 API。
4. 场景三：第三方 SDK 集成与协议握手的“语义鸿沟”
4.1 AI 看不见的“协议心跳”：SDK 版本与服务端的隐式契约
集成 Stripe、Twilio、SendGrid 等第三方 SDK 时，AI 的最大幻觉是：“只要代码能跑通，就代表集成正确。”它不知道，这些 SDK 与服务端之间存在大量未写入文档的“隐式契约”（Implicit Contract）。比如：
- Stripe SDK v5.x 要求
payment_method_types数组必须按特定顺序排列（['card', 'sofort']有效，['sofort', 'card']在德国地区会静默失败）； - Twilio 的
Messages.create()方法，若from号码未在控制台启用 MMS 功能，发送彩信会返回21612错误，但 SDK 默认不抛出异常，只返回status='queued'； - SendGrid 的
mail.send()，若content_type设为'text/plain'但邮件体含 HTML 标签，服务端会静默截断内容，而非报错。
AI 生成的代码，永远基于 SDK 文档的“理想路径”编写。它看不到服务端的地域策略、灰度发布、AB 测试开关，更无法感知 SDK 版本与服务端 API 版本的兼容矩阵。我们曾因 AI 自动升级 Stripe SDK 到 v6，而服务端尚未开启 v6 支持，导致所有支付请求返回400 Bad Request，错误信息却是Invalid request: No such payment_intent—— 因为 v6 默认启用了新的 PaymentIntent 结构，而旧版服务端只认 Charge。
提示：第三方集成不是“写代码”，而是“谈协议”。每一次
pip install stripe，你都在和 Stripe 签一份动态更新的电子合同。AI 不是律师，它只负责抄写合同文本，不负责解释条款变更。
4.2 “握手代码”的手工必做清单
我给所有第三方集成定下“握手五步法”，AI 只能参与第 1 步（生成基础调用），其余必须手写：
- 生成基础调用：AI 写
stripe.PaymentIntent.create(...)，没问题； - 注入版本锁：手动在
requirements.txt中锁定stripe==5.4.0，并备注# 服务端 2024-Q2 兼容版本，升级前需联系 Stripe 支持确认； - 添加协议校验：在调用前插入校验逻辑，如
if not stripe.api_version.startswith('2023-'): raise RuntimeError("SDK version mismatch")； - 捕获静默失败：重写异常处理，不依赖 SDK 默认行为。例如 Twilio，必须显式检查
message.status in ['failed', 'undelivered']并记录完整响应体； - 埋点协议指标：为每次调用添加监控标签，如
stripe_api_version,region,response_code，而非只记success/fail。
去年对接一个国内短信平台时，AI 生成的代码用requests.post(url, json=payload)发送，看似简洁。但该平台要求：
- 请求头必须含
X-Request-ID: uuid4()； - 响应体必须解析
data.code == 0才算成功； - 失败时
data.msg含中文错误码（如“签名错误”），需映射为英文日志。
AI 生成的代码全漏了。我花 3 小时手写适配层，封装了SmsClient类，强制校验所有协议要素。上线后，监控显示 12% 的请求因签名头缺失被拒，若用 AI 默认代码，这些错误会淹没在HTTP 400日志里，无人知晓。
4.3 Webhook 验证：AI 的“加密盲区”
Webhook 是第三方服务回调你服务器的入口，也是最易被 AI 带偏的场景。AI 会生成类似这样的验证代码：
# AI 生成：用请求体 + secret 计算 HMAC signature = hmac.new( key=SECRET.encode(), msg=request.body, digestmod=hashlib.sha256 ).hexdigest() if signature != request.headers.get('X-Signature'): return HttpResponseForbidden()问题在于：不同平台的签名算法千差万别。Stripe 用v1=前缀 + 时间戳拼接；GitHub 用sha256=+body；Slack 用v0=+timestamp:body。AI 不知道你要对接的是哪家，它只是随机选一个“看起来合理”的方案。更致命的是，它不处理时钟漂移——Stripe 要求时间戳误差 < 5 分钟，AI 生成的代码从不校验timestampe字段。
我的做法是：为每个 Webhook 创建独立验证模块，硬编码平台规则。例如 Stripe Webhook 验证：
def verify_stripe_webhook(payload, sig_header, secret): try: # Stripe 要求：提取 t=12345,v1=xxx,v0=yyy timestamp, signatures = parse_signature_header(sig_header) # 验证时间戳（防重放） if abs(time.time() - timestamp) > 300: raise ValueError("Timestamp too old") # 构造待签名字符串：t=12345\npayload signed_payload = f"t={timestamp}\n{payload.decode()}" expected_sig = hmac.new( secret.encode(), signed_payload.encode(), hashlib.sha256 ).hexdigest() # 比较 v1 签名 return any( hmac.compare_digest(expected_sig, s) for s in signatures.get('v1', []) ) except Exception as e: logger.error(f"Webhook verification failed: {e}") return False这段代码里，parse_signature_header、时间戳校验、signed_payload格式，全是平台强约束，AI 无法泛化。它只能复制粘贴，而复制粘贴的代价，是线上被伪造 Webhook 注入恶意指令。
5. 场景四：性能敏感路径与资源边界的“确定性战场”
5.1 AI 的“概率性输出”撞上“确定性需求”
性能优化是工程中最反直觉的领域之一：90% 的性能问题，不来自算法复杂度，而来自资源边界的误判。AI 编程在此彻底失效，因为它的输出本质是概率分布——它说“大概率用 Redis 缓存”，但不说“缓存键必须带租户 ID 前缀，否则多租户场景下会击穿”；它说“建议用连接池”，但不说“PostgreSQL 连接池大小应设为 CPU 核数 × 2，而非内存大小 ÷ 10MB”。
AI 不理解“确定性”（Determinism）：一个函数在相同输入下必须产生相同输出、相同耗时、相同资源占用。而它的生成逻辑是“找最像的样本”，样本里可能有time.sleep(0.1)这样的调试残留，AI 会当成正常逻辑照搬。
我们曾有个实时报价服务，AI 生成的代码在计算价格时调用了外部汇率 API。测试环境一切正常，上线后 P99 延迟从 120ms 暴涨到 2.3s。排查发现，AI 把一个用于本地模拟的mock_exchange_rate()函数，误认为是生产调用，而该函数内部有time.sleep(1)。更讽刺的是，这个sleep是我上周调试时加的，AI 从我的 Git 历史里学到了它。
提示：性能路径不是“写得快”，而是“跑得稳”。AI 擅长前者，人类必须守护后者。每一次
for item in large_list:，你都要问：这个large_list最大多少？内存能否承受？GC 压力多大？AI 永远回答不了。
5.2 性能关键路径的“三不原则”
我在性能敏感模块（如订单创建、支付结算、实时消息推送）执行严格“三不”：
- 不接受 AI 生成的循环体：所有
for/while循环内部逻辑必须手写。AI 常在循环内做重复初始化（如每次循环都json.loads(config)），或漏掉提前退出（break/return），导致 O(n²) 复杂度。我要求循环体必须有明确的 Big-O 注释，如# O(1) per iteration, total O(n)。 - 不信任 AI 的缓存策略：AI 会建议
@lru_cache(maxsize=128)，但不告诉你maxsize=128在高并发下会导致缓存雪崩。正确做法是：用分布式缓存（Redis），键名强制包含业务维度（如price:usd:product_123:tenant_a），并设置EXPIRE时间，而非依赖内存缓存。 - 不使用 AI 推荐的“高性能库”：AI 常推荐
ujson替代json，orjson替代ujson。但orjson不支持default参数，无法序列化datetime对象；ujson在处理超大 JSON 时内存泄漏。我的规则是：除非压测证明提升 > 15%，否则用标准库。因为标准库的稳定性，比 5% 的速度提升重要百倍。
去年重构搜索服务时，AI 推荐用Elasticsearch的script_score实现动态权重，声称“性能提升 30%”。我手写对比测试：在 1000 万商品数据集上，script_scoreP95 延迟 420ms，而预计算权重存入_source的方案仅 87ms。AI 的“30%”是基于它训练数据里某个小规模测试，而我的数据是真实的业务规模。
5.3 资源边界的“手工刻度尺”
真正的性能瓶颈，往往藏在资源边界。AI 无法告诉你：
- 一个 HTTP 连接池，最大连接数设多少？答案是：
min(可用文件描述符数 / 2, 服务实例数 × 10)； - 一个 Kafka 消费者组，
max.poll.records设多少？答案是：吞吐量目标 ÷ (单条消息处理耗时 × 0.8)； - 一个数据库查询，
LIMIT设多少？答案是：前端展示页大小 × 3（防滚动加载时翻页错乱）。
这些数字不是魔法，而是用压测工具（如 k6、JMeter）在真实流量模型下跑出来的。AI 可以生成压测脚本，但无法解读结果。我坚持用“手工刻度尺”：每次上线新功能，必做三件事：
- 基线测量：用
ab -n 1000 -c 100 http://localhost:8000/api/order测出当前 P99 延迟； - 边界探测：逐步增加并发数（
-c 200,-c 500），记录错误率突增点； - 资源监控：用
htop、iotop、netstat观察 CPU、内存、IO、连接数变化，找到第一个触顶的资源。
这个过程 AI 无法替代。它可能说“CPU 使用率 85%”，但不会告诉你“这是 Redis 连接数打满导致的上下文切换风暴”。只有盯着vmstat 1的cs（context switch）列从 1000 跳到 15000，你才明白问题在哪。
6. 场景五：法律合规与审计留痕的“责任不可分割区”
6.1 AI 无法签署的“数字指纹”
当代码涉及 GDPR、CCPA、PCI DSS、等保 2.0 等合规要求时，“谁写的代码”不再是个技术问题，而是法律责任问题。AI 生成的代码，天然缺乏“数字指纹”——它没有作者、没有修改时间、没有变更理由。而审计要求每行关键代码必须可追溯：谁在何时，因何原因，做了何种修改。
最典型的例子是“用户数据删除”。GDPR 要求“被遗忘权”：用户注销时，必须删除其所有个人数据（姓名、邮箱、地址、设备 ID、浏览记录）。AI 生成的删除逻辑往往是：
def delete_user_data(user_id): db.execute("DELETE FROM users WHERE id = ?", user_id) db.execute("DELETE FROM addresses WHERE user_id = ?", user_id) # ... 其他表但它漏掉了：
- 软删除标记：合规要求保留删除记录供审计，而非物理删除。正确做法是
UPDATE users SET deleted_at = NOW(), status = 'deleted' WHERE id = ?； - 跨系统同步：用户数据可能散落在 CRM、BI、邮件平台。AI 生成的代码只管数据库，不管其他系统；
- 日志留痕：必须记录
user_id,operator_id,deletion_reason（如GDPR_REQUEST），且日志不可篡改。
去年我们收到一份 GDPR 删除请求，AI 生成的脚本执行后，审计方发现 CRM 系统仍有该用户邮箱。原因是脚本没调用 CRM API。补救时，我们不得不手动导出 CRM 数据、用哈希比对、逐条删除——耗时 17 小时，而合规时限是 72 小时。
提示：合规代码不是“能运行”，而是“能举证”。每一行代码，都必须回答三个问题：它满足哪条法规条款？证据存在哪里？如何验证它被执行？
6.2 审计留痕的“四必录”规范
我为所有合规相关代码制定“四必录”：
- 必录操作主体：
operator_id不能是system，必须是触发操作的真实员工 ID 或自动化任务 ID（如gdpr_cleanup_job_v2）； - 必录操作依据：
request_id必须关联原始合规请求（如 GDPR 工单号GDPR-2024-0876）； - 必录数据范围：
affected_tables字段必须列出所有被操作的表/系统，如["users", "addresses", "crm_contacts", "mailchimp_lists"]； - 必录验证结果：执行后必须调用
verify_deletion(user_id)，并记录verified_count和failed_items。
这些字段，AI 无法自主生成。它可能写出log.info(f"Deleted user {user_id}")，但不会加上request_id和affected_tables。我用自定义日志装饰器强制注入：
def audit_log(operation: str): def decorator(func): @functools.wraps(func) def wrapper(*args, **kwargs): # 从 kwargs 或上下文提取必要字段 request_id = kwargs.get('request_id') or get_current_request_id() operator_id = kwargs.get('operator_id') or get_current_user_id() # 执行前日志 audit_logger.info( f"{operation}_start", extra={ "request_id": request_id, "operator_id": operator_id, "args": str(args), "kwargs": {k: v for k, v in kwargs.items() if k != 'request_id'} } ) result = func(*args, **kwargs) # 执行后日志（含验证结果） audit_logger.info( f"{operation}_end", extra={"result": result, "request_id": request_id} ) return result return wrapper return decorator这个装饰器，AI 可以生成骨架，但extra字段的每一个键值对，都必须根据具体合规条款手工填充。因为request_id的格式、operator_id的来源、affected_tables的枚举，全由法务和审计团队定义，AI 不在那个会议桌上。
6.3 “不可否认性”的手工防线
最后，也是最根本的一条：所有涉及法律效力的代码，必须有不可否认性（Non-repudiation）。这意味着：
- 代码提交必须用个人 GPG 密钥签名；
- 生产部署必须经双人审批（
Approver A+Approver B），且审批记录不可删除； - 关键操作（如数据删除、权限变更）必须触发二次确认（如短信验证码、硬件令牌）。
AI 生成的代码，永远无法提供这种“不可否认性”。它可能写出send_sms_verification(code)，但不会集成 YubiKey 的 FIDO2 认证流程。去年我们上线新权限系统时，AI 生成的管理员后台，允许单人点击“重置所有用户密码”。我强制加入require_mfa_for_privileged_action()中间件，并将该操作日志同步至区块链存证服务。审计时，这成了我们合规性的核心证据。
注意：不要用“AI 生成的合规检查清单”代替人工审查。我试过让 AI 列出 GDPR 数据删除要点，它给了 12 条，但漏掉了最关键的“必须通知数据接收方（如 CRM 服务商）同步删除”。这条来自欧盟 EDPB 的官方指南，AI 的训练数据里没有。
7. 这半年，我真正学会的不是“用 AI”，而是“不用 AI”
半年 AI 编程之旅的终点，不是效率的巅峰，而是判断力的觉醒。我渐渐明白，那些“别让 AI 碰”的场景，不是技术的禁区，而是工程师职业尊严的界碑。AI 可以写一万行 CRUD 代码，但写不出一行“当用户余额不足时，应优先扣除优惠券而非现金”的业务逻辑——因为那需要理解公司当季的营销战略、财务的现金流压力、法务的合同条款，以及产品经理凌晨三点发来的微信语音里带着哭腔的“求求了，这个必须今天上线”。
我现在的开发流是：用 AI 扫描所有“可标准化”的部分——生成单元测试桩、补全日志字段、转换 DTO 对象、整理 API 文档。然后，亲手握住键盘，在状态机、密钥管理、协议集成、性能边界、合规留痕这五个战场上，一寸寸夯实代码的地基。每一次手动敲下if balance + amount < 0:，每一次在.env文件里写DB_PASSWORD=${DB_PASSWORD}而非硬编码，每一次为 Webhook 验证写满 37 行带时间戳校验的代码，都是对“工程师”这个词的重新确认。
AI 不是来取代我们的，它是来帮我们回答那个终极问题的：“你，到底是一个写代码的人，还是一个解决问题的人？”
这半年，我终于敢说：我选后者。