我不会写代码，但我不是不懂系统

2026-09-04 AI · 工程 · 系统

一句不够准确的话

我经常说，我不会写代码。

这句话是为了纠正一种误解。看到我做过小程序、广告投放系统和一些研究工具，人们很容易把我当成程序员。其实我不能从空白文件开始，独立设计、实现并审查一个大型系统。项目里的绝大部分代码，都是 AI 写的。

但这句话也会制造另一种误解：既然不会写代码，那我只是把一句需求扔给 AI，碰巧得到了一套能运行的东西。

事实不是这样。

我有一些服务器和架构常识，会关心安全、冗余、延迟、成本和手里的资源。但这些知识并不完整，也没有被训练成传统工程师那种可以独立落到每一行代码的能力。

所以更准确的说法是：

我不能独立把一个系统写成代码，但我可以参与决定这个系统为什么存在、不能在哪里失败，以及什么结果算它真的工作。

一个不能用演示交差的任务

2026 年初，我帮朋友搭建一套广告投放系统。

其中一部分叫 RTA。广告平台发来一个设备标识，系统要在很短的时间内回答：这个设备是否值得参与竞价。另一部分是 oCPC，它接收点击和转化回传，让投放系统知道哪些广告最终产生了结果。

开始时，我不懂 RTA，也不懂 oCPC。我不会服务器运维，当然也写不出这套系统。

但任务非常具体：它要进入生产环境，承受真实流量，并把响应延迟控制在平台要求之内。它不是演示，也不是为了跑出一个好看的压测数字。回答慢了，流量就过去了；链路断了，真实业务数据就会丢。

朋友给了我一个相对宽松的业务环境。Claude 给出架构、编写代码、分析日志、修改连接池和并发模型。我按照它的说明操作云平台，在关键节点继续追问：哪条链路必须最快，哪些服务应当隔离，未知设备应该放行还是拒绝，机器增加以后瓶颈会不会只是转移到下游。

有一次需要拆分流量。已有域名和监测链接不能变，否则前面所有对接都要重来。最终的选择是保留入口，只把最吃延迟的 /rta 请求送到弹性服务器，把通知和管理接口继续留在主服务器。

代码怎样实现路由，不是我写的。

但“不能改什么”“哪条链路需要隔离”“故障时什么必须留下”，这些是系统问题，不是语法问题。

系统不听故事

我很快遇到一个反直觉的结果。

处理外部接口时，把并发从 100 提高到 300，看起来应该更快。实际测试中，300 并发时中位延迟到了四五秒，吞吐量反而只有每秒约 50 次；降到 100 并发以后，中位延迟回到约一秒，吞吐量还略有上升。

更多机器、更多线程、更多并发，并不自动等于更多能力。外部接口的限速、连接开销、队列堆积，会把“更强”变成“更慢”。

另一批真实请求更说明问题。约 40 万次请求在十一分钟左右进入系统，平均每秒约 600 次。入口接住了它们，但大量缓存未命中的设备进入后续处理；广告关闭以后，队列又花了二十多分钟才清完。

如果只看入口，系统成功了。

如果看完整链路，真正的瓶颈还在后面。

这类反馈是我能工作的原因。AI 可以提出解释，我可以继续追问，但最后裁决方案的不是我们谁说得更像专家，而是延迟、吞吐、积压和业务结果。

于是我们降低并发，拆开缓存和队列，把需要永久保存的人群数据放进数据库；实际流量下降以后，又把弹性服务器从二十台缩到两台，同时保留回退路径。

扩容是一种决定，缩容也是。系统不是越大越好，而是在当前约束下刚好够用。

64,000 QPS 证明了什么

这个项目后来最容易被记住的数字，是约 64,000 QPS。

这是我后来在项目记录中补充确认的生产峰值，不是压测结果。但它也不是“整套广告系统长期稳定地每秒完成六万四千次业务处理”。高峰主要落在 RTA 的快速入口：读取缓存，作出判断，把后续任务送进队列。它和下游慢接口、转化回传、数据库写入不是同一种负载。

项目在另一个时期的日常流量只有每秒约 71 次，所以我们才会把二十台机器缩到两台。一次有完整记录的请求批次，平均值则是每秒约 600 次。

峰值、均值、持续时间、链路范围，是四个不同的东西。

如果把它们压成一句“我用 AI 在半个月内做到了 64,000 QPS”，这句话并非全假，却会制造一个比事实整齐得多的故事。更接近事实的说法是：RTA 的核心能力在约两周内快速成形，让一个外行借助 AI 做出了可以进入真实业务的系统；此后几个月，生产环境继续暴露问题，系统也继续被修改。

64,000 QPS 证明这条入口在那个时刻承受过很大的真实流量。

它不能证明我已经成为广告系统专家，也不能证明整套系统没有隐藏问题。

那些没有被成功遮住的错误

系统确实出过问题。

查询接口和主链路曾经使用不兼容的键，二级索引又没有被正确写入和查询，结果某类数据的缓存命中率一度是零。系统还发生过数据丢失和回调补发；一次审计发现函数定义顺序有误；部署过程中也出现过网络异常、404 和 502。

这些并不是故事旁边无关紧要的瑕疵。它们恰好说明我的边界。

我可以从“命中率为什么是零”追到两条链路没有同步，可以要求未知设备默认拒绝投放，可以让关键服务和非关键服务隔离，也可以在修改前要求保留回退路径。

但我不能仅凭自己检查大规模生成代码里的每一个隐患。我不知道还有多少错误没有被流量撞出来，也不能证明某个架构在更长周期、更恶劣条件下仍然成立。

现实反馈只能暴露已经遇到的错误，不能证明没有尚未遇到的错误。

生产运行比演示更有说服力，但它仍然不是完整的专业审查。

AI 没有让工程消失

AI 大幅降低了实现的成本。过去，我必须先用几年时间掌握一套表达媒介，才有资格把想法变成系统；现在，模型可以替我展开语法、调用接口、重构服务和分析日志。

但它降低的是进入工程的门槛，不是工程问题本身。

需求写错了，AI 会高效地实现错误需求。边界漏掉了，它会在边界之外生成一套内部自洽的答案。测试环境没有隔离，它甚至会一边“验证”，一边消耗真实接口和真实资源。代码能够运行，也可能只是错误还没有找到触发条件。

所以代码由 AI 写，并不意味着工程能力已经不重要。相反，一部分责任从“怎样写”移到了别处：

这些问题过去也存在。只是代码曾经是一道很高的门槛，把没有受过训练的人挡在它们之前。现在门槛下降了，更多人可以直接面对这些问题，也更容易直接制造这些问题。

我能承担哪一段

这个项目不能推出“以后不需要程序员”，也不能推出“只要会描述需求，任何人都能搭建生产系统”。

它的目标明确，反馈很快，有朋友提供真实而相对宽松的业务环境，也有云平台承担大量基础设施工作。换成医疗、金融、安全关键系统，或者需要多年维护的大型基础设施，同样的工作方式可能远远不够。

我真正拥有的，不是对代码和广告技术的完整理解，而是一种有限的系统参与能力：把现实目标带进来，把不能接受的后果说出来，让 AI 生成并解释选项，在资源、风险和效果之间作出选择，再允许运行结果推翻这个选择。

我不会写代码，这仍然是真的。

我不能独立证明这套系统的每个部分都是对的，这也是真的。

但我不是站在系统外面等待 AI 创造奇迹。我进入了目标、约束、取舍、反馈和责任所在的位置。

技术能力不只有“亲手写了多少代码”这一种形态。能够让代码出现，也不等于拥有完整的工程能力。

当模型越来越多地负责实现，人最终需要回答的，也许不再只是“这是不是我写的”，而是：

我凭什么让它进入现实，又准备怎样为它的后果负责？