我变成了 AI 的打字猴子——以及我为什么写了一个禁止 AI 写代码的工具
我变成了 AI 的打字猴子——以及我为什么写了一个禁止 AI 写代码的工具
当 AI 替我写代码时，我以为自己变成了 10x 工程师。实际上，我变成了一只会按 Tab 的猴子，面对崩溃堆栈时连自己的代码都读不懂。
那个死锁
凌晨一点半。产线停了四十分钟。
不是设备故障——是产线追踪系统卡死了。PLC 信号正常，OPC UA 订阅正常，传感器数据一直在采集，但数据到不了 SQL Server。操作工手动抄了四十分钟的生产批号。
代码是我写的——不，是 AI 写的，我按的 Tab。
这是一个典型的工业数据管道：C# 后台服务，System.Threading.Channels 做生产者-消费者，OPC UA SDK 的回调线程里 Write 到 Channel，一个后台 Task 从 Channel Read 出来批量 SqlBulkCopy。架构看起来合理。代码看起来体面。Channel.CreateBounded<SensorRecord>(10000)，有背压。await 都用对了。CancellationToken 都传了。
测试环境跑了两周没问题。用 BenchmarkDotNet 压了 50 万条也没有丢数据。
然后投产第三周，夜班操作工按了急停按钮。
急停触发了几百个传感器在五秒内同时上报状态变化。OPC SDK 的回调线程瞬间灌入 Channel。Channel 满了。回调线程——它是 OPC SDK 内部的单线程事件循环——在 WaitToWriteAsync 上阻塞了。但 AI 在错误处理里加了一个 try-catch，catch 分支里写了一句 _logger.LogWarning("Channel full, retrying...")，然后同步重试。同步重试。在 OPC SDK 的回调线程上。
回调线程堵住了。OPC SDK 的 KeepAlive 超时。OPC UA 会话断开。Channel 的 Consumer 端还在等数据——但 Producer 端已经跟着 OPC 会话一起死了。Consumer 端没有超时机制，永远在 WaitToReadAsync。
死锁。
我盯着 dump 看了两个小时才理清这条因果链。AI 不知道 OPC SDK 的回调线程是什么。它不知道 WaitToWriteAsync 在那个线程上意味着什么。它只是看到一个 Channel、一个 await、一个它认为"完善"的错误处理——然后拼出了一段所有工具都检查通过的代码。
AI 不理解系统中的每一个组件有它自己的执行模型。 它理解 C# 的语法。它不理解 OPC UA 会话的生命周期、急停事件的物理含义、凌晨三点一个人值班的车间里"系统卡死"意味着什么。
它只是把 token 组合成了看起来像异步管道的形状。
我不是在写代码，我是在按 Tab
这就是过去一年我和 AI 的真实关系。
它生成一段 C#。Channel<SensorRecord>，IAsyncEnumerable<T>，await foreach——语法糖拉满。我扫一眼。它继续生成。CancellationToken 到处都传了，IDisposable 用 await using 包了。像是在 InfoQ 上读过文章的人写的。我按 Tab。
C++ 底层通信模块也一样。智能指针，RAII，std::lock_guard。Clang-Tidy 绿了。我按 Tab。
我变成了打字猴子。AI 喂我 token，我吞下去，产出一个又一个提交。代码仓库在膨胀。同事扫一眼说"Looks fine."
但我不知道那些代码到底做了什么。
不是"不完全理解"——是完全不理解。我没有在写代码。我在对着一份我既没有设计也没有推敲的文本按确认键。
代码不再从我手里流过
比 Bug 更让我不安的，是某种更根本的东西消失了。
以前写代码，一个函数从空白的编辑器里长出来：先写签名，再搭骨架，然后填充逻辑，最后处理错误路径。手指在键盘上，脑子在数据流上。写完一段，退后一步看整体比例——这里太长了，拆出去。那里太紧了，松一松。代码在我手里被反复拿捏、折叠、抛光。它不是一次性写对的，但它是我的。每一行我都知道为什么在那里，每一个判断我都亲自做过。
这种感觉很难描述。有点像木工刨木头——刨花卷起来，你能感觉到刀锋吃进木纹的深浅。写代码也有"手感"。你知道一个 if 放这里是对的，因为你对这个函数的气息有感觉。那个感觉来自于你亲手把每一个变量、每一个分支、每一个异常路径都想过一遍。
Tab 把这个感觉杀死了。
AI 吐出来的代码读起来没问题。但它没有重量。你不知道为什么那个 try-catch 放在那里——是你刻意设计的防御层，还是 AI 的模板惯性？你不知道那个 Channel.CreateBounded(10000) 里的 10000 是怎么来的——是你算过内存预算的结果，还是一个随机采样？每一行都可能是深思熟虑的，也可能是随机生成的——而你分不清。
这种感觉很微妙，但很重要。就像你开了十年的手动挡突然换成了自动驾驶——车还在走，但你不知道轮子现在在干嘛。
代码不再从我手里流过。它从 AI 的模型参数里流出来，经过我的 Tab 键，直接落进了仓库。
我失去了对代码的掌控感。而掌控感是工程师对自己的代码最基本的心理所有权。没有它，我只是一个按 Tab 的操作员。
AI 代码的三个致命问题
一、语法正确，行为错误
C# 不是你语法写对了就能跑的。AI 能写出漂亮的 Channel<SensorRecord> 管道，但它不知道 OPC SDK 的回调在哪个线程上执行。它不知道 WaitToWriteAsync 在那个线程上阻塞意味着什么。它不知道产线急停按钮按下去之后，几百个传感器会在五秒内同时上报——这不是"高并发"，这是物理世界的级联事件。
C++ 也是。AI 能写出 std::lock_guard<std::mutex>。但它不知道你的图像采集线程和 PLC 状态轮询线程之间有一个隐式的顺序依赖——采集必须先初始化，轮询必须在采集之后开始。AI 给每个资源加了锁，代码不会 data race。但当初始化顺序被现场工程师改了配置之后，系统静默地处理了空帧——一个月后质检发现漏检了三千个零件。
语法正确。行为正确？AI 不关心行为。它只关心 token。
二、出了事你只能自己扛
AI 写的代码不出问题时——谢天谢地，99% 的时间不出问题。
但工业环境和互联网不一样。工业环境里你面对的不是"用户看到 500 错误"——你面对的是产线停了，夜班操作工在等，车间主任在打电话，你的手机在响。
而那个 Bug 在三周前就埋下了。在一个 PR 里。AI 写的。你按的 Tab。
你翻出 dump 文件。你二分 git blame。你找到那个 commit。你点进去看——你不认识这些代码。你没有写过它们。你没有设计过它们。你甚至不记得这个 PR 的 Context。
现在你要在一段不是由你设计的代码里、在一个不是你设计的架构里、定位一个跨线程的时序 Bug。OT 环境中没有热更新，没有 feature flag，没有灰度——你要么在停机窗口里修好它，要么让产线停到天亮。
排查时间变成了——理解一个陌生人的设计意图，加上定位 Bug 本身。前者比后者长五倍。
三、它没让我更快
有句话我憋了很久：AI 在工业软件开发中没有让我更快。
写一个 CRUD 的 MES 工单页面？快。生成一个 Modbus TCP 协议解析？还行——反正有现成的库，AI 帮你拼一下参数。
但设计一个产线数据采集管道——要考虑 OPC UA 会话管理、PLC 通信超时重试、Channel 背压时的降级策略、断网缓存、与 MES 数据库的事务边界——在这些场景里，AI 的效率是负的。
它花 15 秒生成 200 行 C#。你花三个小时理解那 200 行：哪些 Task 在哪个线程上跑？Channel 的 Bounded 容量在生产峰值下够不够？背压策略是丢数据还是阻塞——如果阻塞，阻塞在哪个线程上？OPC 回调线程堵住了会话会不会断开？
然后你删掉 120 行重写。
如果你自己先想清楚：画一张数据流图，定义清楚线程模型和背压策略，设计好断网恢复的状态机，然后再动手——你会写 60 行。第一次就对。
AI 省下来的打字时间，被理解它的代码和修复它埋的雷的时间，连本带利地吃了回去。 在 C++ 里，利息高利贷级别——因为你不仅要理解逻辑，还要理解内存。
问题不是 AI，是我们用错了
我说这些不是要骂 AI。Claude 在不写代码的时候是个非常好的思考伙伴。它能和你在同一层抽象上讨论问题，能列出 trade-off，能指出你遗漏的边界条件。
问题是我们跳过了思考，直接让它写代码。
因为我们想快点看到东西在跑。因为"思考"没有可见的产出，而"代码行数"有。因为按 Tab 比想清楚容易得多。
而 AI 工具的设计者强化了这个错误。每一个 AI 编程工具都在告诉你：说你要什么，我来写。设计？不需要。接口？不需要。ownership 语义？不需要。你要的只是更多的代码。
不。我要的不是更多的代码。我要的是更好的代码。更好的代码来自更好的决策。更好的决策来自更深入的思考。
软件工程是设计活动
这是我从多年开发生涯里学到的最重要的一件事——
写代码不是软件工程。设计才是。
工业环境是最诚实的裁判。你面对的不是"用户投诉多不多"——你面对的是产线停不停。物理设备不会原谅你的并发 Bug。PLC 不会因为你用的是最新 C# 版本就对你网开一面。OPC UA 会话断了就是断了。
所以在工业软件里，想清楚再写不是一种方法论偏好。是生存本能。
先画数据流。先定义线程模型。先理清组件的生命周期和依赖顺序。先在纸上把急停按钮按下之后的级联状态变迁走一遍。然后才打开 IDE。
这也是我所有可靠代码的来源——不是更快的打字，不是更聪明的 AI prompt。是更好的设计。
AI 应该服务这个过程。不是一个替你写代码的打字机。是一个帮你思考的搭档。
转机来自一个叫 Superpowers 的开源项目。
当我在设计一个设备通信中间件——管理 PLC、扫码枪和视觉相机的连接。它问了我 9 轮。有一个瞬间——
"如果网络闪断导致 OPC UA 会话断开，你的重连逻辑会重建 Subscription。但重建 Subscription 期间新产生的 PLC 事件——你是丢掉了，还是 OPC 服务器会帮你缓存？"
"OPC UA 服务器有重传队列，应该不会丢。"
"队列多大？如果断线持续了 30 秒，队列溢出之后的行为是什么——丢最老的还是拒绝新的？你的系统能接受哪种行为？"
它是一套给 Claude Code 用的 Skills——不是让 AI 替你写代码，而是给 AI 装上结构化的思考协议。比如"写之前先 brainstorm"、"实现之前先写计划"、"提交之前先验证"——每一个 Skill 不是一个功能，是一个强制性的工作流。AI 不能跳过步骤，不能偷懒，不能在你没确认的情况下擅自写代码。
这个逻辑击中了我。
我想要的不是一个更聪明的代码生成器。我想要的是一个设计搭档——在我动手之前，系统地和我不厌其烦地过每一个边界维度。线程模型。资源生命周期。异常路径。背压策略。断线恢复。急停行为。问那些我自己容易漏掉的问题。挑战那些我自己懒得深想的假设。
所以我照着 Superpowers 的 Skill 结构，写了一个专注于工程设计的版本。它不写代码——写代码是我的事。它只做一件事：帮我在写之前把问题想透。
如果你也有类似的感受——SKILL在 GitHub 上。
结语
我用 C++ 写设备驱动和视觉算法。用 C# 写产线调度和数据管道。我享受把一个物理系统正确地建模成软件的过程——信号进来，数据流动，设备响应，产线运转。
我不需要一个 AI 替我做这件事。
我需要一个搭档——在我上线之前问我"OPC UA 的 KeepAlive 超时设了多少"，在遗漏急停路径时提醒我，在我选错了线程模型时说"OPC SDK 的回调线程是什么——你确定要在这上面阻塞吗"。
我需要的是更好的设计。不是更多的代码。
因为代码可以把产线跑起来。设计可以保证它在凌晨一点半急停按钮按下去之后，还能正确地停，正确地恢复，正确地活过来。
好的代码不是写出来的。是想出来的。
产线不停，设计先行。
浙公网安备 33010602011771号