在 Emacs 里建座城市，这事听起来像是技术极客的冷笑话，但有人真的做了。2026 年 2 月，开发者 vkazanov 在 GitHub 上扔了个叫 ElCity 的小项目——一个用 Emacs Lisp 写的《模拟城市》克隆品，还顺手登上了 Hacker News。评论区里老炮们一边调侃「接下来要在 Emacs 里打台球了」，一边认真讨论起架构设计，气氛颇为诡异。

一、在文本编辑器里造城是什么体验？

ElCity 的核心玩法极度复古：纯 ASCII 界面，回合制，用键盘铺路、建厂、划区。按 n 进入下一回合，资金收入简单粗暴——人口除以 2，再加上商业和工业等级。居民楼（R）、办公楼（C）、工厂（I）想升级必须同时满足两个条件：接通电、有道路通向市政厅。断电或断路就降级，最高 3 级。整个模拟逻辑被刻意简化，作者 vkazanov 在 Hacker News 上承认，「玩法太简陋，需要真正懂这类玩具的人给点意见」。

但界面简陋不等于技术简陋。README 里贴出的截图显示，终端版和图形版都能跑，彩色方块和文字标注齐飞。make run 一键启动，M-x elcity-start 直接在 Emacs 里开玩。代码结构干净得像教科书：核心模拟纯函数式，UI 渲染和输入处理单独拎出来，中间用 DSL（领域特定语言）定义地块类型。这种「函数式核心 / 命令式外壳」的架构，成了项目最大的技术卖点。

二、当 Lisp 遇见「函数式核心 / 命令式外壳」

「函数式核心 / 命令式外壳」（Functional Core, Imperative Shell）这词听着唬人，思想却挺质朴：把业务逻辑写成纯函数——无状态、无副效应、像数学公式那样干净；所有脏活（IO、用户输入、界面渲染）全扔到外壳层去处理。作者 vkazanov 直言，这么做的直接好处是「调试轻松、测试容易、undo 实现起来像喝水」。

在 Hacker News 评论区，有位叫 zackmorris 的老哥展开长篇大论，把这模式拔高到「编程的未来」。他打了个比方：纯函数部分像电子表格，输入输出一目了然；外壳像批处理脚本，只管跟现实世界打交道。这种架构下，代码能当静态图来分析，优化和并行化都容易。反观我们日常写的命令式代码，得一行行追踪执行路径，跟跑调试器似的，根本没法静态分析。这话虽有些理想主义，但正中 ElCity 的设计初衷——作者就是想验证，在 Emacs Lisp 这种「看似不适合」的语言里，能不能把架构玩得转。

答案是可以。代码里 elcity-core.el 全是纯函数，状态转移一目了然；elcity-ui.el 管渲染和按键，脏活归它。地块定义用 DSL 描述，想加新建筑？改几行配置就行。作者后来补充，这种设计还有个意想不到的好处：纯函数的输入输出描述特别规整，喂给 LLM 做扩展时，上下文窗口完全够用。

三、AI 当助手，开发者当导演

这个项目最坦诚的一点，是作者不避讳用 AI。有人在评论区质疑某张截图「像是 LLM 生成的」，vkazanov 大方承认：确实用了 gptel 当顾问，还配了自定义工具。他直言「强烈推荐」这种工作流。这在 Hacker News 上引发一小波伦理讨论——有人觉得用 AI 辅助的东西不好意思发 Show HN，感觉「没亲手写代码就不配署名」。

作者回应得干脆：LLM 只是工具，创意和决策还是人的。这话在评论区得到不少支持。另一位开发者 Keyframe 分享了自己的 AI 游戏项目，坦言「作为老程序员，不咋摸代码却拿出成品，感觉怪怪的」。yuppiepuppie 则鼓励：AI 时代，展示成果没毛病。毕竟，当代码生成成了新常态，开发者的角色更像导演：设计架构、写提示、做取舍，而不是逐行敲字母。

ElCity 的提交历史也印证了这点：2 月 5 日一天内连续提交，README 和截图迅速补齐，典型的小步快跑、快速迭代模式。AI 助攻让原型开发快得不像话，但核心设计——地块 DSL 怎么定、模拟逻辑怎么拆——显然还是人类拍板。

四、Emacs 社区的「神圣」与「世俗」之争

只要有 Emacs 的地方，就少不了原教旨主义者和实用主义者的嘴仗。这次也没例外。

有人提议：「把核心逻辑从 Emacs 解耦吧，别绑那么死。」作者立刻回怼：这项目就是为了「全在 Emacs 里」，搞成客户端 / 服务器架构那完全是另一个故事。另一位用户 brimtown 建议打包成独立程序，「别让 Emacs 成为门槛」。但 Lars Brinkhoff 浇了盆冷水：Emacs Lisp 跑在别的 Lisp 方言上？别想了，90% 兼容容易，真跑复杂项目门儿都没有。Guile 号称支持 Emacs Lisp，但「读了文档我反而更不信了」。

这场争论触及 Emacs 文化的深层矛盾：是把 Emacs 当终极平台，万物生于斯长于斯；还是当工具，随时想拔腿就跑？作者显然选了前者——「完全在 Emacs 里」就是目标本身。评论区里有人玩梗：「RMS（Richard Stallman）终于能在 Emacs 里玩 SimCity 了」，还有人建议加地震效果，让 Emacs 窗口跟着震动。这些调侃背后，是对 Emacs 生态那种「一切都在编辑器里解决」的狂热认同。

帖子最终收获了 88 个星标和零个 watch，Fork 数只有 1。数据不算爆炸，但讨论质量挺高。就像所有好玩具，它存在的意义不在于多完美，而在于启发了多少思考。

五、延伸联想：文本界面游戏与架构思想

ElCity 不是第一个在 Emacs 里扎根的游戏。评论区有人提到 Emacs 自带的彩色方块库，Tetris 就用它实现。还有人甩出链接，列举 Emacs 内置的各种小游戏——从贪吃蛇到五子棋，应有尽有。这提醒我们：终端游戏从未死去，只是换了个阵地。在图形界面统治的时代，ASCII 游戏反而成了程序员审美的最后堡垒，轻量、透明、可 hack。

至于 FCIS 架构，虽然 ElCity 是个小玩具，却意外成了验证思想的绝佳样本。函数式编程在工业界一直叫好不叫座，问题不出在理念，而出在「怎么跟现实世界打交道」。ElCity 的解法很 pragmatic：把所有副作用推给外壳，核心保持纯粹。这让人联想到 React 的「纯组件 + 副作用钩子」，或者 Elm 的「Model-Update-View」结构。思想是相通的，只是落地方式不同。

AI 辅助开发这块，ElCity 也算个微型案例。当 LLM 能读懂你定义的 DSL 和纯函数接口，代码生成就从「写一堆烂代码」变成了「填充架构空缺」。这对个人开发者是福音——用 AI 快速验证想法，把精力留给真正需要人类判断的架构设计。当然，前提是你得像 vkazanov 那样，先把框架想得明明白白。

六、结语：玩具的价值

ElCity 大概率不会成为下一个《城市：天际线》，它的模拟深度连 30 年前的《模拟城市》初代都比不上。但这不是重点。作者花一周时间，在所有人都觉得「离谱」的平台（Emacs）上，验证了一种被低估的架构思想，还顺便实践了 AI 辅助开发的新工作流。评论区里有人建议改名 ElCiudad（西班牙语「城市」），有人畅想「ElPresidente」（《海岛大亨》克隆），这些玩笑恰恰说明：玩具的价值不在于多复杂，而在于它点燃的想象力。

下次当你在 Emacs 里敲代码时，不妨想象一下：这行代码背后，是不是也能塞个小小的模拟世界？在技术日趋复杂的今天，花一周时间做点「无用但有趣」的东西，或许正是对抗倦怠的最好方式。