一个 nginx 工程师接手 AI 写的软件

十篇技术文章，三十多次提交。该停下来看看了。 做了什么 回头看，做的事情只有一件：一层一层地把复杂度放到它该在的地方。 骨架先理（第二篇）——命名、文件前缀、构建分离。看起来琐碎，但它定义了项目的身份

架构的手法不需要很多。真正有用的，一个就够——反复用。 这一篇做一件事：把 fetch 的复杂度从事件循环里搬回 fetch 自己手里。拆一个 529 行的文件，搬一堆不该在 loop 里的逻辑，切断

代码能跑，测试能过，功能正常——但总觉得哪里不对劲。 每次有这种感觉，深入去看，根源都一样：某个领域概念应该存在于代码中，但没有。 不是功能缺失——功能都在。是概念缺失——代码不知道自己在操作什么。

前几篇从底往上清理了三层。engine 有 js_engine.h，conn 有 js_conn.h，buffer 有 js_buf.h，timer 有 js_timer.h——每个模块都有自己的头文

前两篇打磨了引擎层——js_epoll_poll() 封装了事件分发，js_engine_t 组装了 epoll 和定时器。引擎层现在很干净。 但往上看一层，我发现了一个不对劲的东西。 连接结构体里有

上一篇把事件引擎封装成了一行 js_epoll_poll(100)。这一篇引入 jsbench 最核心的结构：工作引擎。 最终的结果是：一个叫 js_engine_t 的结构体——每个线程一个，同时拥

AI 写代码像盖楼。前几层盖得又快又稳——函数命名、逻辑实现、测试覆盖，都不错。但楼越往上，问题就来了。高层靠的不是砖头砌得多快，而是图纸画得对不对。图纸就是架构。 事件引擎是 jsbench 的地基

前几篇一直在修问题、改代码。这篇停下来想想：到底什么是好的架构。 如果让我用一句话回答"架构是什么"，我的理解是：架构是管理复杂度的方式。 管理复杂度 一个系统要做的事有多复杂，它就有多复杂——这是客

上一篇说到代码组织——文件命名、前缀风格、构建分离。那些是架构的骨架。但骨架搭好之后，真正考验架构的，是它能不能支撑住功能的演进。 这一篇，我用一个具体的问题来讲架构改进：fetch() 不支持并发。

上一篇说过，jsbench 的第一版基本是 AI 写的。能跑，测试也过了。"Make it work"，AI 已经做到了。 但 "make it right" 呢？这正是我接下来要做的事——重构架构。

压测工具这个东西，做后端的都用过。但你有没有发现一个尴尬的现状？ wrk，性能顶级，但脚本用 Lua。想做个"先登录拿 token 再压接口"的场景？写到你怀疑人生。 k6，JS 脚本，功能齐全。但装