ASYA MUN：让每场模联能够有属于自己的信息平台
借着一个外面随便 Vibe Coding 的项目谈了一些对商业化、生成式软件工程（Vibe Coding）的看法。原载于微信公众号（见文末）。
1 动机
这是一套面向模拟联合国危机联动委员会的推演系统。我们将之命名为ASYA 系统（Asymmetric SYnergy Automation System，非对称联动自动化系统）。
如果只用一段话来定义它，那么：ASYA MUN 不是一个临时拼接出来的线上表单，也不是一个只负责收发消息的网页工具。它是一套围绕模拟联合国危机联动而精心设计的信息系统。它的目标很明确——用技术手段降低偶然复杂性，让危机联动会场不再那么“处处是场外危机”。什么是场外危机？比如说学团不小心把给A代表团的信息发给了B代表团的群（显然是因为，代表会有十几个微信/QQ群，IPC人直接麻掉，很难管理）；再比如会次次元的时间轴流动计算错误，导致出现了“超时空战士”的推演...
总之，从学团的角度来看，模联的危机联动确实有很多“体力活”。因此我们开发了ASYA。当前版本已经具备从会议创建、用户与角色管理，到会议次元时间、回合推进、公开消息、非对称消息、代表指令、代表状态、公告图片、用户组、审计日志和系统后台的一整套核心链路。
它是整场会议里最核心的几类工作：
- 会议如何创建和配置；
- 不同角色如何在同一个信息流中有不同权限；
- 会议次元时间如何自动计算；
- 回合如何发布、暂停、恢复与切换；
- 公开消息与非对称消息如何统一管理；
- 代表如何提交指令，学团如何审核和反馈；
- 代表状态（如军队算子位置）如何记录、更新和展示；
- 后台如何完成权限控制、批量操作与审计追踪。
在产品结构上，ASYA 已经形成了一套比较清晰的双端视角。
对代表来说，它是进入会议、查看进程、接收消息、提交指令、查看个人状态的使用端。
对学团和管理员来说，它是组织会议、推进时间、管理回合、分发消息、审核指令、维护状态、配置会场和追踪操作的管理端。
这两端不是彼此割裂的，它们共享同一套会场数据和规则体系。这也是 ASYA 和很多“把若干工具拼在一起”式方案（事实上我见到了很多最不一样的地方。
2 功能
一、会议与用户体系
系统已经支持会议创建、会议信息编辑、会议状态管理，以及用户和会议之间的关联配置。
在角色层面，当前版本已经区分系统管理员、学团指导、学团成员和代表等不同角色，并基于角色提供差异化的功能权限。管理员侧已经具备注册开关控制、批量注册、用户管理、会议管理等完整能力，适合真实会场在筹备阶段快速完成初始化。自然地，代表也肯定是看不到其他代表的非对称消息，也无权访问学团的界面，以此实现了真正的非对称消息。
二、时间轴与回合系统
时间管理一直是危机联动系统里最难做对、也最难做清楚的部分之一。ASYA 当前版本已经把会议次元时间、时间流速、时间跳跃、时间锚点和回合管理做成了独立模块。在系统里，学团可以推进会议次元时间、调整流速、执行时间跳跃，也可以发布回合、暂停回合、恢复回合、设置下一回合、切换当前回合和修改剩余时间。对于代表端来说，当前会议次元时间和当前回合状态也都已经有独立展示。
这让会议节奏不再需要通过微信群里吼一嗓子，或是依靠口头通知维持，而是成为系统中可见、可控制的一部分。
三、消息系统
消息模块是 ASYA 目前已经相当完整的一部分。当前版本支持公开消息与非对称消息的创建、编辑、查看和管理，也支持标题、摘要、正文、附件、发布时间、接收范围等字段配置。非对称消息不仅支持指定单个接收者，也支持结合用户组、延迟分钟数和可读时间做更细的分发控制。对代表来说，系统已经区分全局消息与“我的非对称消息”；对学团来说，系统已经具备会议内非对称消息分页查看、筛选和统一管理能力。
四、消息系统
代表指令的提交与审核，是 ASYA 当前版本另一条已经比较成熟的主链路。
代表端已经支持指令提交、分页查看、状态筛选、关键词查询和详情查看；学团端已经支持指令管理、按状态与类型筛选、按代表和用户组查询、查看详情、批改审核，以及会议级的“暂停 / 恢复指令提交”控制。
3 后记之端
实际上，后面的这部分文章纯粹是看某个"大创项目"不爽；I‘m totally mad with AI slop with no taste.
另一方面，也是我对26年这个节点，AI Coding能如何赋能非技术背景的同学的一些观点，以及个人对技术的一些价值观。
这篇文章不是为了列 ASYA 有多少功能，也不是为了做一次版本更新说明。功能介绍已经可以写在 README、更新日志和部署文档里。这里更想谈的是：
- 作为学生，关于 AI Coding 的一些想法；
- 为什么我要把 ASYA 设计成现在这样，为什么在 AI 工具链越来越强的今天，产品本身反而更需要清晰的价值判断；
- 为什么我希望 ASYA可以被每场会议独立部署；
全文结构大概是个人的黑历史、AI 与软件工程、“做出来”并不稀缺、商业化 vs. 主权个人四个方面。
4 黑历史
如果把时间稍微往前拨一点，大概在 2023 年左右，我对 AI 编程工具的印象还主要停留在“更聪明的代码补全”上。
那时候的 AI 辅助开发，更多是在 IDE 里补出这一行的代码、补一个函数、补一段重复逻辑。它确实有用，但在我的体感里，它还没有真正改变软件开发这件事本身。对我来说，它更像是一个高级自动补全工具：提高效率，减少重复劳动，但开发者仍然是代码的主要书写者。
后来很长一段时间，我主要使用Copilot。Copilot 给我的感觉，是它开始从“补全代码”逐渐变成“参与编码”。它不只是补变量名、补循环，而是能根据上下文生成一段逻辑、一个组件、一个接口调用，甚至一个测试用例。
但即便如此，在那个阶段，我仍然会把自己理解为代码的主要书写者。
我对AI的认知，还是一个如Copilot产品名所述的那样：程序员知道要写什么，它帮程序员把其中一部分更快地落下来。
真正的变化，大概发生在去年年底之后。一方面，Coding Agent的迅速发展确实出乎了我的意料；另一方面，正好和人聊天聊到了 ASYA 面向的业务场景，所以打算试试水。
ASYA 是我第一个基本可以称得上纯 Vibe 的项目。我开始明显脱离过去那种AI 辅助写代码的模式，转向更接近今天所谓 Vibe Coding 的开发方式。我不再只让 AI 补一段代码，而是开始让它承担更大范围的实现工作：大规模生成模块、搭建页面、补齐接口、整理数据结构、写数据库迁移、调整样式、解释报错、修复 bug、重构工程。
但 ASYA 并非是 AI 自己想出来的。ASYA 的技术方案、产品方向、业务架构和核心抽象，仍然是我自己决定的。比如为什么怎么区分代表端、学团端和管理端；为什么要面向危机联动系统为核心业务；为什么要采用 Docker 部署；这些都不是 AI 替我决定的。
更现实地说，我本来也不是以 Web 全栈开发作为主要职业规划的人。我的主要兴趣和能力方向一直更偏向 C++、游戏开发、图形渲染和工具链等等。相比之下，Kotlin、SpringBoot、React / Next.js，对我来说并不是最熟悉、也不是未来最核心的技术方向。
所以 ASYA 对我来说，很大程度上也是一次借助 AI 工具链完成跨领域开发的实践。如果没有今天的大语言模型和开发工具，我当然也可以慢慢学、慢慢写，但很难以这样的速度把一个完整系统推进到现在的状态。
这件事本身很有所谓宏大叙事落在一个个体上的感觉。也正是在做 ASYA 的过程中，我第一次非常强烈地感受到：我写的代码变少了，但我需要做的判断变多了。
5 生成式软件工程
ASYA 的开发经历让我越来越相信一件事：AI 时代并不是让开发者变得不重要，而是让开发者的重要性发生了转移。
过去，很多时候我们会把会不会写代码看作软件开发的核心门槛，那个时候一个功能能不能做出来，一个页面能不能写出来，一个接口能不能跑通，往往本身就是很大的挑战。
我以前其实也很认同这种判断。在很长一段时间里，我对某种“古法编程”抱有相当强的崇敬：那种一个人坐在电脑前，靠纯粹的技术能力、工程经验和代码掌控力，把复杂系统一点点写出来的开发者形象，对我曾经有很强的吸引力。
某种程度上，我也曾经喜欢那种技术至上主义者的姿态：觉得真正重要的是代码，是底层能力，是实现细节；至于游戏策划、产品经理、需求分析、用户体验这些东西，好像都是更虚无缥缈，“是个人都能干”的部分。
现在回头看，这种想法当然很幼稚，但它并不罕见。
很多刚开始写代码的人，大概都会经历一个阶段：觉得会写代码就是最硬的能力，觉得能把东西做出来就已经赢了一半，觉得产品和策划只是提需求的人，而真正创造东西的是工程师。但随着软件工程专业课的学习，以及自己真正开始做项目，我慢慢意识到，软件开发并不是单纯的代码生产活动。编码只是整个软件工程生产的一小部分。完善的需求分析、详细的设计对于传统模式的软件开发而言，甚至比编码还要重要。对于敏捷开发模式，与客户面对面、响应变化与需求也需要一种专业化的产品能力。代码当然重要——没有代码，系统不会运行，功能不会存在，架构也只是图纸。但代码并不是产品的全部，甚至很多时候，代码只是某种产品判断、业务建模和工程取舍之后的结果。如果一个人只会写代码，但不知道自己在解决什么问题，那么 AI 会很快追上他，甚至在很多具体实现上超过他；但如果一个人能够理解业务、拆解复杂性、建立模型、判断取舍，并且有足够的工程能力去审查和驾驭 AI 生成的结果，那么 AI 反而会放大他的能力。
这也是我对 Vibe Coding 态度变化的原因：我并不反对 Vibe Coding。AI 能够让更多不会写代码，但是很有产品想法的人完成产品的设计与搭建，长远来看这必然是一件促进产出的事情。ASYA 本身就是 Vibe Coding 时代的产物。我真正反对的是没有判断力的 Vibe Coding：把 AI 生成的一堆页面误认为产品，把一组功能名误认为系统，把漂亮文案误认为业务理解，把组件堆叠误认为设计。
不过，我对 ASYA 系统有一个很自傲的论断：不是所有线下流程都值得被搬进一个新系统里，但是 ASYA 面向的业务流程是有必要信息化的。
拿参与过的某些会议举例。某些会议的报名、收集学测阶段是一个极其苦力活的工作——有些会还是纯电子邮件形式处理报名，这就导致，有的代表会反复发好几次邮件，有的代表的邮件命名完全不符合要求，学团和组委要去一直翻邮箱再登记到自己的表格里面......这些当然都是会议中真实存在的工作。
但真实存在，不等于天然应该被产品化；能被做成页面，也不等于这个页面真的创造了新的价值。比如报名这件事，本质上通常就是信息采集、表单填写、结果汇总和后续筛选。WPS 表单、腾讯文档、问卷星，已经能以很低的学习成本完成这件事。它们有现成的填写入口、表格视图、导出能力和协作习惯。
我很喜欢我的一位老师写的一段对“优秀毕业设计”的判断。他大意是说，一个系统不能只是前端表单和数据库字段一一对应。“整个系统使用起来如同填写一张Excel表格然后存在网盘里，就仅仅是把信息存储下来，然后读取出来，这居然就叫作一个“系统”了？！......而现实生活中之所以采用软件系统来管理信息而非像很久很久以前雇佣专人来整理档案的方式的愿意无非两点，一是缩短信息传递的链条，二是加快信息处理的速度。本科毕业设计的系统通常不具有很大的用户规模，因此谈不上缩短信息传递链条。因此，如果你的系统类似于Excel表+网盘，那么你并没有加快信息的处理速度——甚至还不如用人管纸质档案来得方便。”
真正有价值的工程系统，其数据在被输入、存储、读取和展示的过程中，应该经历足够多的业务计算、状态变化、规则处理和流程控制。只有这样，系统才真正承担了复杂业务，而不只是换了一种方式保存信息。我并不是说报名、文件整理、会议主持这些功能不能做。它们当然可以做，良好的会议主持UI可以提供比旧有产品更好的UX，报名系统也可以在某些规模足够大、流程足够复杂、定制化的会议中产生价值。
但如果它们只是被当成“平台完整性”的证明，被写进“会前、会中、会后”的功能清单里，那我会觉得这更像是会务流程的搬运，而不是业务问题的解决。在很多场景下，它甚至可能更麻烦：用户要注册新账号，组织者要学习新后台，数据要被放进一个新的平台**，原来简单直接的表单协作反而被包装成了一套看起来更“产品化”的流程。
真正值得系统化的，应该是那些原有工具很难处理的部分——下面的这些问题，列出来本身就是有价值的，仔细想想技术上并不很难实现（在这里十分感谢ASYA系统最初的用户，为ASYA的需求设计给了很大的帮助）。
比如危机联动中的非对称消息。它不是“发一条通知”这么简单，而是涉及谁能看到、什么时候能看到、是否延迟可见、是否按用户组分发、是否和会议进程有关。
比如会议次元时间。它不是“日程表”这么简单，而是涉及时间流速、时间跳跃、时间锚点、回合状态和代表端展示。
比如代表指令。它不是“交一份文件”这么简单，涉而是推演过程中的核心输入，涉及提交、审核、批改、反馈、状态变化和后续影响。
比如代表状态。它不是“个人资料字段”这么简单，其中涉及到动态配置、可扩展性的问题，也是会议世界的一部分，可能承载军队算子、资源、位置、属性和推演结果。
这些事情用在线文档、群聊当然也能勉强做，但它们会制造大量人工处理成本，也会带来信息错发、时间错算、状态混乱和责任难以追踪的问题。ASYA 想做的，不是把所有会务杂项都收进一个系统里，而是优先处理那些真正需要被系统承接的联动复杂性。换句话说，我并不认为“把报名从腾讯文档搬进自己的平台”本身有什么特别值得炫耀的地方。我更关心的是：一个系统有没有进入业务深处，有没有缩短信息传递链条，有没有加快信息处理速度，有没有减少真实错误，有没有把原本只能靠人肉维护的复杂关系，变成稳定的系统能力。
这些东西不是靠堆页面解决的。一个产品不是页面的集合，也不是功能点的堆叠；产品的核心，仍然是对问题的理解、对业务的建模、对复杂性的取舍，以及对用户真实处境的尊重。
AI 可以帮人生成很多页面，但它不会自动知道这些页面为什么存在。
AI 可以帮人堆出很多功能，但它不会自动知道哪些是真需求，哪些是伪需求。
AI 可以根据一句“一站式会议平台”生成一套看起来很完整的模块，但它不会天然理解一场会议真正复杂的地方在哪里。
AI 可以把界面做得很热闹，但它不会自动拥有 taste。
所以，在 AI 时代，“做出来”本身正在变得越来越不稀缺。真正重要的问题变成了：你是否真的理解你要做的东西。
你是在面向真需求，做真产品，还是因为别人有所以我们也要有，在搞“信创”或者“自主研发”？ 你是在把可以用腾讯文档解决的业务流程复杂化，还是在重新建模这个流程？你是在用 AI 放大开发者的判断力，还是在用 AI 掩盖开发者没有判断？
6 集中化 vs. 主权个人
我本人并不反对商业化。软件开发需要时间，服务器需要成本，维护需要精力，一个系统如果真的被长期使用，也必然需要某种可持续的支持方式。把一个产品做成商业服务，本身并没有问题。
我预想的开源项目的商业化途径，就是面向懒得自己部署服务器、买域名的人，向他们提供一些技术服务。对于有能力的人，那么寥寥数行命令和配置文件即可无成本私有化部署 ASYA。这些需求是真实存在的，类似于 Gitea 等等开源项目的商业模式。
我在意的是另一件事：当一个集中化的系统从“工具”变成“生意”之后，它和使用者之间的关系会发生变化。
当一个产品以中心化平台的方式运行时，它天然会追求更多会议接入同一个入口，更多数据沉淀在同一个系统里，更多流程被统一到同一套规则下，即互联网企业会谈的私域流量。这样做在商业上很好理解：平台需要规模，需要留存，需要可管理的客户关系，也需要把不同会议纳入同一个服务框架。
但对会议来说，这未必永远是好事。尤其是危机联动会议。每一场联动会议都有自己的设定、规则、节奏、信息结构和推演方式。它最有价值的地方，往往不是它和其他会议一样，而是它能够成为它自己。
如果一场会议想使用一个系统，却必须先去联系某个平台方，等待沟通、接入、授权和安排；如果它的数据、规则、流程和使用方式都被放在一个中心化服务里；如果它不能真正掌握自己的部署、自己的数据库、自己的版本和自己的运行环境......
那么它当然也可以说自己完成了“数字化”。但这种数字化，并不一定增加了会议的自主性。更麻烦的是，这会让学团的可控权限转移给一个外部不可信实体。
这也是我为什么会把 ASYA 设计成可以 Docker 部署的系统。对我来说，Docker 部署不是一个单纯的技术卖点，而是一种产品立场。
它意味着一场会议可以拥有自己的系统实例，自己的服务器，自己的域名，自己的数据库，自己的配置和自己的数据。它不必天然成为某个中心化平台上的一个项目，也不必为了使用系统而进入某个商业机构的服务流程。
我一直比较认同主权个人的观念。放在软件产品里，它并不一定意味着每个人都要完全脱离社会、脱离协作、脱离服务。它更像是在说：个体、小团队和小共同体应该尽可能保有对自己工具、数据和组织方式的控制权。
学团和会议设计也是一种小共同体。
一场联动会议有自己的学团、代表、规则、叙事和推演世界。它不应该只是某个大平台里的一个会议条目，也不应该只能在别人规定好的结构里运行。好的工具应该增强这种小共同体的能力，而不是把它重新纳入某个中心化系统。
所以 ASYA 选择了有限制的开源：除商业竞品外的任何人都可以 Fork 改造它的业务流程，建设一个完整的会议生态。
所以，ASYA 并不排斥托管服务，也不排斥未来有人需要更省心的部署方式。真正的问题不在于是否收费，而在于收费之后，产品是否仍然尊重使用者的主权。我希望 ASYA 可以被部署，可以被迁移，可以被检查，可以被修改，也可以在每一场会议自己的环境中运行。它首先服务的是具体的会议，而不是抽象的平台规模。
这背后是一种很朴素的判断：好的工具应该增加人的主权，而不是制造新的依赖。
7 附录
这篇文章不是产品说明书，这只是一次个人的技术实践复盘。如果言辞有些犀利，那么可能是写作时辅助润色的 AI 干的——毕竟这只是我个人在公众号上的碎碎念。
ASYA 并不完美，比如之前有什么一个小时就登陆退出一次、没消息提醒、然后各种奇怪的交互体验......但它至少是一个诚实的系统。
有一件事让我觉得既有趣又遗憾：在 AI 工具链如此发达的今天，我作为一个并不怎么混圈的小资历，似乎比市面上一些大张旗鼓的商业会议更深地触及了危机联动会议的真实痛点。这件事本身就应该早就由其他人做了。
这并非因为我的代码写得多好，而是因为在做出来已经不再稀缺的时代，太多人失去了对业务本身的判断力。他们热衷于用 AI 生产代码，却忘了用脑子去理解会议。
为了促进社区发展，ASYA 项目已开放源代码，开源仓库如下：https://www.github.com/Stanley-233/asya-mun
当前项目采用 PolyForm Shield 1.0.0 许可证发布。你可以在许可证允许的范围内阅读、学习、修改并在非竞争性场景下使用本项目。欢迎为本项目提交 Issue & PR！但是，如果你的使用场景涉及提供与 ASYA 竞争的产品或服务 时，尤其是商业性用户（但不意味着免费产品不构成竞争，详见许可证），则需要联系开发者获取额外授权。
原文：