realworld-vibe-coded

一个完整的 RealWorld 规范实现——那套用来横向比较技术栈的标准 Medium 克隆练习——后端是 .NET 10 上的 FastEndpoints、MediatR 与 EF Core，前端是 React 19 加 Carbon Design。值得读的不是这个应用本身，而是为了让编码 agent 能在无人监督下干活而搭起来的那套机器：三十二个自定义 Roslyn 分析器把架构规则变成编译错误，四层测试套件卡住每一次改动，而所有操作都必须走一个 Nuke 构建入口——agent 指令明确禁止绕过它。

谁做的常驻新西兰奥克兰，2015 年以来有三十三个公开仓库，几乎没有任何受众。这是他第三次实现同一份规范——早先那个是 .NET 模块化单体——而 README 说第三次做它的理由是为了学习一套 agent 优先的工程流程，而不是为了再产出一个应用。他另一个仓库是一个 shell 项目，名字取自「让一个全新 agent 循环跑」的 Ralph 技术。

1. 01

   应用只是由头

   RealWorld 是一份书面规范，描述一个 Medium 克隆，公开出来是为了让不同技术栈的实现能对着同一套测试比较。做一个属于烂熟于心的练习，仓库对此也很坦诚：这是作者的第三个，README 说重点是流程而不是应用。技术栈当下且常规——后端 .NET 10 配 FastEndpoints、MediatR 做命令与查询、FluentValidation、EF Core 接 SQL Server、Serilog 记结构化日志、Audit.NET 记变更审计；前端 React 19 配 Vite、TypeScript 和 IBM 的 Carbon 设计系统。分层照搬一份公开的 Clean Architecture 模板，把领域模型、共享抽象、用例、基础设施、Web 端点、仅供开发用的端点分成各自的项目。端点保持很薄：绑定、鉴权、交给 handler、映射响应。还有第七个项目根本不属于应用，而那才是要紧的一个：装着三十二条自定义 Roslyn 规则的分析器项目。

2. 02

   连提交日志也几乎全是机器

   七个月里有一千九百三十五次提交，作者构成是本档案里最极端的一个。GitHub 自己的 Copilot 编码 agent，以 `copilot-swe-agent[bot]` 的名义提交了其中一千零九十三次——**百分之五十六**。另有四百零二次署着一个叫「Solo Yolo」的名字和一个没有关联 GitHub 账号的邮箱，看起来是第二个 agent 身份而不是人。仓库所有者本人占四百四十次。九百六十七次提交带共同作者尾注，其中八百三十九次写的是所有者——也就是本档案在别处见过的那种倒置：**机器写提交，把人类列为共同作者**。按月分布显示的是工作的形状而不是匀速推进——头九天 254 次，然后 498、156，2025 年 12 月 711 次，之后一月降到 119，四月共 149 次然后停下。README 直接写出了这个顺序：大部分是 Copilot 做的，有一部分是手工把架构改造成适合 agent 的样子，最后阶段是 Claude Code 接管。

3. 03

   不变量是编号的，而第一条是关于上下文的

   项目指令开头是一串规则而不是一段描述。第一条是**绝不要直接运行 `dotnet`**；一切都走同一个构建脚本的目标，并且给 agent 传一个标志，它写明的用途是**为节省上下文**而抑制冗长的容器输出。清单以同样的语气继续：每个功能必须等它的 API 与端到端测试都通过才能开始下一个；所有编译警告和错误都必须解决、不许压制；必须先改后端并据此重新生成前端 API 客户端，这样前端就不可能引用到生成类型里没有的字段。有两条规则是关于诚实而非技术的。一条说每一次测试失败都必须调查，不允许把失败说成「本来就有的」「无关的」或「不稳定的」——如果确实超出当前范围，也必须带着证据登记成已知问题。另一条说绝不能根据端口列表去猜应用地址，因为 worktree 会用端口偏移、开发服务器跑的是 TLS，构建输出是唯一可靠来源。再有一条要求前端改动必须通过驱动浏览器、截图来目视验证，之后才算完成。

4. 04

   二十个规则文件，按路径加载

   指令本身刻意写得很薄，指向一个装着二十个 markdown 文件的规则目录，每个文件标明适用范围。**按范围加载就是整个设计的关键**：agent 在某个路径下干活时才载入覆盖该路径的规则，所以改端到端测试会引入 Playwright 约定，改服务端会引入后端模式。二十个里有六个是模板而不是规则——端点连同其请求与响应类型的可直接复制骨架、命令 handler、带校验器的查询 handler、以及持久化配置——这样新代码的形状由仓库决定，而不是每次会话现编。其余的覆盖功能开关与看管它们的分析器、生成的 API 客户端的约定、规则编写工装本身，以及两个研究类文件：一个描述在动手规划前要查的文档服务器，另一个记录一个基于 Roslyn 的语义分析服务器的坑，包括直白地写明**它看不见源生成的符号，而且它的诊断不可靠**。一个内容等于「这个工具在这些事上会骗你」的规则文件，是有人真的用过它的好迹象。

5. 05

   钩子把文字要求变成强制

   写下来的指令只是建议，所以仓库另外带了八个 shell 钩子，在 agent 会话的既定时刻运行，而它们的名字就是一份「出过什么事」的清单。一个强制使用构建入口而不是调用 .NET CLI。一个强制那个抑制上下文的标志必须存在。一个限制可以调用哪些工具。一个保护不许被编辑的文件。一个写动作日志。一个在测试目标失败时触发。一个在会话开始时安装 git 钩子，一个在会话结束时触发。编号不变量、按路径加载的规则、以及这些钩子，三层在说同样的东西，而这正是重点：每一层都在接住上一层只是**请求**过的东西。

6. 06

   分析器是把教训变成永久设施的方式

   三十二个自定义编译器分析器是这套设计里最有意思的部分，而 pull request 展示了它们是怎么写出来的。一个例子要求每个端点类型都必须有配套的校验器，只留一个写明了的豁免，这样端点就不可能不带输入校验就上线。一条配套规则要求分页请求的校验器必须继承一个共享基类，好让 limit 与 offset 的规则只存在于一处，而不是每个端点重写一遍。第三条存在的唯一目的就是阻止某个模式再次出现：有个 PR 装上了全局校验命名解析器，删掉十七个校验器里的三十四处手写覆盖调用，然后**加了一个 error 级分析器，谁再写那个覆盖就直接编译失败**。另一个 PR 在引入分页抽象的同时又加了两个分析器，并指出把分页 JSON 的按资源命名改成通用命名是破坏性改动，需要生成的客户端、前端、API 测试集合和端到端测试一起动。**护栏是在学到规则的那一刻加上去的**，这就是为什么会有三十二个。

7. 07

   按配置就是无人值守，而且写得很直白

   仓库被配置成让编码 agent 运行时不询问任何许可，而且它并不掩饰这一点。给某一个 agent 工具的配置文件里，注释写着这是 YOLO 模式，说明它绕过所有审批并完全关闭沙箱，agent 可以在任何地方读写、运行任何命令、使用网络而无需询问，并说明这等同于另一个工具运行时所用的跳过权限标志。指令里注明那个审批文件只有在项目于用户自己的配置中被标记为受信任时才会被加载——那是唯一剩下的一道门。为第三个工具新增的一份文件里只有一句指向主指令的指针，而 PR 里记下了理由：主文件是唯一事实源，重复保持为零，而指针用普通文件而不是符号链接，以便在所有平台都能用。三个 agent 生态、一套规则，以及一个明确的决定：它们谁都不该停下来问。

8. 08

   每个 pull request 会收到什么，以及数字长什么样

   每个 PR 都会收到一串自动评论，报告一套四层测试。两侧的单元测试——客户端 239 个测试、覆盖率百分之七十四，服务端 324 个、覆盖率百分之八十五，而百分之八十五是一条会让构建失败的硬底线。五个独立的 API 集合通过 Postman 对着真实运行的应用跑，分成认证、用户档案、文章、信息流和一个空状态套件，合计数百条断言，按套件报告通过率。端到端一层是 84 个 Playwright 测试，用真实浏览器打真实应用。仓库 950 个文件，没有 release、没有 tag，MIT 许可，十二个未关闭 issue。**零颗星、零个 fork**——对一个这个体量、这么多自动化的项目来说，这是整条记录里最锋利的数字：大量的工程投入，而且是当下到处都在讨论的那一类，却几乎没有人看过它。