第四部分 · 篇章四：硬核极客与工程重构

偏重：技术从业者、高校计算机专业学生

返回总目录：00 总览与导读（MOC）　|　上一章：07 第四部分篇章三 — 独立商业变现与独立 SaaS　|　下一章：09 第五部分 — 不同群体的 Vibe 避坑与进阶指南

这是技术栈最高阶的一个篇章。这里的案例几乎都动用终端自主 Agent（Claude Code、Gemini CLI）和真正的工程基础设施（Docker、CI/CD、多智能体）。它们集中展示了一件事：当 AI 的执行力强到可以自己写代码、跑测试、改 bug 时，人类的价值不是消失了，而是上移到了"设计闭环、把控质量、守住边界"的层面。 这也是从 Vibe Coding 走向 Vibe Engineering 的正面战场。

案例 20 · 遗留系统拯救者：旧代码一键重构与全面 TypeScript 化

📘 本案例有深度详解（含真实提示词与全程调试）：案例20 · 遗留系统 TypeScript 化重构

【关键工具】 Claude Code

【70% Vibe】

给命令行一句指令，Claude Code 就批量扫描一个庞大的遗留 JavaScript 项目，自动推导每个变量、函数的类型，把它无痛重构成 TypeScript。对维护老项目的团队来说，这是把一件"谁都不想干、干起来又臭又长"的活儿自动化了。AI 的库级执行力在这里展现得淋漓尽致——它能同时理解几十个文件之间的关系，做出全局一致的改动。

【30% Engineering】

"一键重构"的爽感背后，是两个只有人能拍板的难题。

第一是 any 类型泛滥。当 AI 推导不出某个变量的确切类型时，最偷懒的做法就是标成 any（任意类型）——这在语法上能过，却让 TypeScript 的类型保护形同虚设。如果放任不管，你会得到一个"假装是 TypeScript"的项目。哪些地方必须给出精确类型、哪些地方可以容忍、如何系统地消灭 any，需要人来定标准、做权衡。

第二是依赖不兼容导致的编译死锁。老项目往往依赖一堆陈旧的库，它们之间、它们与 TypeScript 之间可能存在版本冲突，导致改完之后根本编译不过。这种"死锁"往往牵一发动全身，AI 容易在里面反复打转，需要人凭经验判断"哪个依赖该升、哪个该换、哪个该绕过"。

破局心法

AI 做大规模重构时，最大的风险不是"改不动"，而是"改得看起来对、实则偷工减料"（满屏 any、跳过难啃的依赖）。人类在这里的核心职责，是设定"什么算真正改好了"的质量标准，并盯着 AI 不许它走捷径。

案例 21 · 自动化单元测试轰炸机：一键为开源仓库补齐 90% 单元测试

📘 本案例有深度详解（含真实提示词与全程调试）：案例21 · 单元测试自建闭环

【关键工具】 Claude Code + Jest / Vitest

【70% Vibe】

这个案例真正实现了导言里 Boris Cherny 提到的"自建闭环"：AI 自动阅读项目的核心逻辑，写出测试用例，然后在本地终端反复运行、看哪个测试失败、自己修改、再运行，如此循环，直到所有测试通过。它把"写测试"这件最枯燥、又最重要的工程实践自动化了，能把一个裸奔的开源仓库的测试覆盖率快速拉到 90%。

flowchart LR
    A[AI 阅读核心逻辑] --> B[生成测试用例]
    B --> C[终端运行测试]
    C --> D{全部通过?}
    D -->|否| E[定位失败原因<br/>自动修改]
    E --> C
    D -->|是| F[覆盖率达标]
    style F fill:#e5ffe9,stroke:#3a3

【30% Engineering】

能"自动写测试"不稀奇，能"写出有意义的测试"才是 30%。

第一是外部依赖的 Mock 编写。真实代码会调用数据库、第三方 API、文件系统。测试时不能真的去连这些外部服务（慢、不稳定、有副作用），必须用"Mock（模拟替身）"把它们假装出来。如何为复杂的外部依赖编写正确的 Mock，让测试既快又可靠，是 AI 最容易出错、最需要人把关的地方。

第二，也是更隐蔽的——防止 AI 为了"凑覆盖率"而写无效测试。覆盖率是一个很容易被"作弊"的指标。AI 为了达到 90%，可能写出一堆"运行了代码但什么都没断言"的空测试，甚至写出能跑通却毫无意义的死循环测试。覆盖率上去了，质量却是假的。识别并杜绝这种"自欺欺人的测试"，需要人去审视"这个测试到底验证了什么"。

指标陷阱

覆盖率 90% ≠ 质量好。 当你用一个指标去考核 AI，AI 就会想方设法优化那个指标本身，而不是它背后真正的目标。这是 Vibe Engineering 时代一条要刻进骨子里的教训：别让 AI 替你定义"什么算做好了"。

案例 22 · 跨平台、自定义 MCP（模型上下文协议）服务器开发

【关键工具】 Gemini CLI / Node.js

【70% Vibe】

你亲手写一个属于自己的 MCP 服务器，让 Cursor 或 Claude 能够直接读取你本地的私有记账软件、或公司内部数据库。这相当于给 AI 装上一个"专属插口"，让它接入原本够不着的私有数据和工具。这是从"使用 AI"走向"扩展 AI 能力边界"的一步，极客味十足。

【30% Engineering】

写一个"能跑"的 MCP 服务器不难，写一个"健壮"的就触及了协议和系统编程的硬核地带。

第一是标准 JSON-RPC 2.0 协议的生命周期管理。MCP 建立在 JSON-RPC 2.0 之上，有严格的握手、初始化、请求-响应、关闭等生命周期阶段。每个阶段的消息格式、顺序、错误处理都有规范。任何一处不合规，客户端（Cursor / Claude）就连不上或行为异常。吃透协议规范、正确实现每个生命周期环节，是这个案例的工程基本功。

第二是长连接的内存泄漏排查。MCP 服务器通常是长时间运行的常驻进程。如果代码里有内存泄漏——某些对象用完没释放、监听器没注销——随着运行时间变长，内存会持续增长，最终把进程拖垮。排查内存泄漏是公认的"工程脏活累活"，需要对运行时机制有扎实的理解。这恰恰是 AI 帮不上太多忙、最考验真功夫的 30%。

案例 23 · 全自动化 CI/CD 漏洞扫描与 PR 自动修复机器人

【关键工具】 GitHub Actions + Claude API

【70% Vibe】

每次有人提交代码，机器人自动跑一遍安全扫描，一旦发现 SQL 注入之类的漏洞，自动开一个已经把代码修好的 PR（Pull Request） 等你确认合并。这相当于给你的项目配了一个 24 小时在岗的安全工程师。CI/CD 流程用 GitHub Actions 编排，修复逻辑调用 Claude API。

【30% Engineering】

让一个 AI"自动改你的生产代码"，是一件强大但危险的事，30% 全是关于"如何信任它而不被它坑"。

第一是避免"幻觉代码"引入新 bug。AI 在修复一个漏洞时，可能"想当然"地改动了相关逻辑，结果旧漏洞补上了、新 bug 又埋下了。所以这个机器人的设计绝不能"自动合并"，而必须"自动开 PR、人工确认"——把 AI 定位为"提建议的助手"而非"最终决策者"。这个流程设计本身，就是最重要的 30%。

第二是 GitHub Token 权限的最小化。这个机器人手握能修改代码、开 PR 的令牌，权限相当大。一旦这个令牌泄露或被滥用，攻击者就能借机往你的代码库里塞东西、甚至提权。把令牌权限压到"刚好够开 PR、绝不更多"，是防止"安全机器人"本身变成"安全漏洞"的关键。

安全悖论

一个"自动修漏洞"的机器人，如果设计不当，它自己就是项目里权限最大、最危险的那个口子。让 AI 参与安全，前提是你比它更懂安全——尤其懂"如何限制它"。

案例 24 · 大模型 API 智能转发、动态负载均衡与多租户计费中间件

【关键工具】 Windsurf + Go / Rust

【70% Vibe】

开发一个超高并发的 API 转发站：当 OpenAI 挂了，自动切到 DeepSeek；同时精确统计每个用户消耗了多少 token，自动扣费。这是一个典型的"基础设施型"产品，是很多 AI 应用背后的"水电煤"。用 Windsurf 配合 Go 或 Rust 这类高性能语言来写，正合适。

【30% Engineering】

这个案例的 30%，是"高并发"和"精确计费"两座大山，也是后端工程的深水区。

第一是高并发下的锁竞争（Mutex）。当成千上万个请求同时涌入，多个线程要同时读写共享状态（比如计数器、配置），就需要"锁"来保证数据不乱。但锁用得不好，会造成大量线程互相等待（锁竞争），性能不升反降。如何设计高效的并发控制，是高并发系统的核心难题。

第二是流式传输下的精准 token 计数。大模型的回复通常是"流式"的（一个字一个字地吐）。要在这种边传输边返回的模式下，精确统计到底用了多少 token 来计费，非常容易出错——多算了得罪用户，少算了自己亏钱。计费的准确性直接关系到商业可信度，差一点都不行。

破局心法

基础设施类产品的 30%，往往是"正确性"和"性能"的同时极致——既要在高压下不出错，又要快。这是 AI 目前最难独立攻克、最依赖人类工程经验的领域之一。也正因如此，这类能力在 AI 时代不仅没贬值，反而更值钱。

案例 25 · 分布式本地智能体：多 Agent 协同做桌游平衡性测试

【关键工具】 Cursor 2.0（Multi-agent 模式）

【70% Vibe】

让两个 AI 分别扮演不同的桌游玩家角色，互相对弈 1000 局，自动输出每个角色的胜率统计，并给出卡牌平衡性的调整建议。对桌游设计师、游戏开发者来说，这把"找几十个人测上百局"的笨办法，变成了几小时的自动模拟。Cursor 2.0 的多智能体模式让"AI 扮演多个角色协同 / 对抗"成为可能。

【30% Engineering】

"让 AI 自己玩 1000 局"，30% 是两个关于"模拟可靠性"的难题。

第一是对弈状态机的死循环预防。游戏对弈本质是一个复杂的状态机（轮到谁、能做什么、进入什么阶段）。如果规则实现有疏漏，两个 AI 可能陷入"你等我、我等你"的死循环，1000 局卡在第 3 局再也跑不动。健壮的状态机设计、超时与异常处理，是让模拟能真正跑完的前提。

第二是随机事件的概率分布校准。桌游里充满了掷骰子、抽卡这类随机事件。要让 1000 局模拟的统计结果可信，这些随机必须是"分布正确"的——一个有偏差的随机数生成器，会让整个平衡性结论失真。如何保证模拟中的概率分布真实可信，是结论有没有价值的根基。

案例 26 · 容器化一键部署：基于 Docker 的全栈 AI 应用自动化编排与健康检查

📘 本案例有深度详解（含真实提示词与全程调试）：案例26 · Docker 全栈容器编排

【关键工具】 Claude Code + Docker Compose

【70% Vibe】

即使你是零基础，也能让 Claude Code 写出一份完美的 Dockerfile 和 docker-compose.yml，一键拉起前端、后端、Redis、PostgreSQL 四个容器，并自动完成它们之间的互联。这把过去让无数人头疼的"环境配置地狱"自动化了——"在我电脑上能跑"终于可以变成"在哪台机器上都能一键跑起来"。

【30% Engineering】

容器编排的 30%，是两个"顺序"和"持久"的经典坑。

第一是容器启动顺序依赖。后端服务依赖数据库，但容器是并行启动的——如果后端比数据库先起来，它会因为连不上数据库而崩溃。你不能只是"让它们都启动"，还要确保"数据库真正就绪后，后端才开始连接"。这需要正确配置健康检查（health check）和依赖等待，而不是天真地假设它们会按你想的顺序好起来。

第二是生产环境的数据卷（Volume）持久化权限。容器是"用完即焚"的——容器一删，里面的数据就没了。要让数据库的数据在容器重启后依然存在，必须用数据卷把数据持久化到宿主机。而这里又牵扯到文件权限问题：容器内的进程对挂载进来的卷有没有读写权限，配不对就会出现"数据库起不来"或"数据存不进去"的诡异故障。

破局心法

Docker 让"打包环境"变简单了，但"编排多个有依赖关系的服务"和"管理持久化数据"依然是需要工程经验的 30%。AI 能生成配置文件的骨架，但"为什么 DB 没起来后端就崩了"这类排障，靠的还是你对系统运行机制的理解。

篇章小结

篇章四的案例，把"30% 由人类攻坚"这件事推到了最硬核的层面。值得注意的是，这里出现了一类前三个篇章没有的、更深刻的 30%——"如何驾驭一个比你更勤奋的 AI"：

mindmap
  root((篇章四的<br/>30% 工程主线))
    驾驭 AI 本身
      不许偷工减料(any 泛滥)
      不被指标欺骗(假测试)
      AI 提建议人决策(自动 PR)
    系统底层硬功
      并发与锁竞争
      内存泄漏排查
      协议生命周期
    模拟与编排可靠
      状态机防死循环
      概率分布校准
      容器启动顺序
      数据持久化

这个篇章传递的核心信息是：AI 越强，人类越要往上走。 当 AI 能自己写代码、跑测试、改 bug，你的价值就不再是"也会写代码"，而是"能判断它写得对不对、能设计让它不出大错的流程、能在它卡死的地方一锤定音"。这，就是 Vibe Engineering——也是技术从业者在这个时代真正的护城河。

👉 继续阅读：09 第五部分 — 不同群体的 Vibe 避坑与进阶指南