About the Opensource

It_is_Sean

TL;DR~
所有使用过该项目的人应当检查自己电脑中是否存在
%USERPROFILE%\.dsh\zju-campus\profile\accounts.json （Windows）
%APPDATA%\CampusAgent\profile\accounts.json (Windows)
~/.dsh/zju-campus/profile/accounts.json（Linux / macOS)
~/Library/Application Support/CampusAgent/profile/accounts.json (macOS)
文件并删除。同时建议修改自己输入过软件的 ZJU 相关服务密码

Agent 的出现大大降低了人们编写代码的门槛。我们也很高兴的看到，很多人能够把自己的想法很快地实现之后，试图将其通过开源的方式和大家分享。抛开 vibe coding 本身的争议不谈，更多人能有对开源社区贡献的意愿固然是好的，而不是像某人一样用 agent 招摇撞骗，声称自己在创业但是网站主页代码和项目一塌糊涂（此处非指原贴主）。

但是 agent 并不像大多数人想像的那样无所不能，笔者在最近看到十大帖子【开源】ZJU All-in-One Assistant：你在浙大能干的事，它都能帮你干 后发现。很多初学者其实并不理解开源一个项目真正要干什么。遂用这个项目的错误稍微介绍一下。

截屏2026-11-03 15.09.30.png

I. 什么是许可证

开源并不是意味着你可以随意使用其他人的代码，许可证（License）便是软件作者与使用者之间签署的法律协议，它 “规定了使用者可以对代码做什么、不能做什么，以及必须承担哪些义务”。不同的许可证有者不同的授权范围，比如：

  • 最宽松的 mit：基本就是”你可以随意使用 MIT 的代码“ （

  • 强传染性的 GPL：如果你在一个项目中使用了 GPL，那么你的项目也要使用 GPL 开源，但是可以商用

  • 还有 Apache 2.0，BSD 等。

许可证是开源中很重要的一环。使用 LGPL 开运的 FFmpeg 就被多个企业的产品使用，其中 LGPL 协议允许企业动态链接项目而不必开源全部代码，但很多企业并没有遵守协议，把 FFmpeg 的代码静态链接到自己的商业软件中，或者修改了 FFmpeg 的底层代码，却拒绝公开修改后的源代码。于是有了著名的 Hall of Shame ( 这是个历史存档）

截屏2026-11-03 15.09.30.png

而关于 8u 的项目，聪明的 claude 大人在项目中大量使用了来自ZJU-Course-Autosign，原许可为 GPL-3.0-only 的代码，但是8u 又把整个项目作为 MIT 协议开源。这是有者明显的协议风险，对原项目作者版权相当严重的不尊重具体可以看到core/zju/lib/xuezai/rollcall.ts等代码的署名

饿啊这里 lz 眼花了，仓库现在的状态确实是 GPL, 只不过项目最初使用 MIT 的行为确实有问题

但是直接如果想要借用他人项目的代码的话，lz 其实用的更多的是 git submodule 而不是复制他人的代码。更方便贡献回原仓库

不过提一嘴，包括 GPL 再内的大多数许可证并没有要求修改的代码一定要贡献给原来的仓库，但确实有部分是需要的。

II. 对你的代码负责

使用 Agent 写的代码并不意味着不会出问题，一个项目的 maintainer 必须对自己的项目负责，这是整个开源社区能够持续发展的重要基础之一（因此现在社区也有观点认为 ai 生成的 pr 版权应该属于 reviewer）。

而对于没有任何代码基础甚至没有任何计算机知识的人，单纯使用 agent 写项目几乎一定会出现安全问题（此处再次点名一个用 agent 招摇撞骗，声称自己在创业但是网站保存用户填写的姓名学号等数据的数据库完全没有加密，同时网站有严重的路径穿透漏洞，是个人就能访问服务器上所有文件的人（code review part II 马上就来））

此处并不是在批判项目作者，有开源的精神固然是好的，但是并不意味着就能很好地去完成一个项目，在上文提到的项目中，笔者简单看了一下数据储存的部分（也是 agent 经常犯错的地方）发现：

  • 用户输入密码之后，你的密码是被软件明文保存在本地的!!

  • 注意这不是你给软件设置的密码，是你提供给软件的，包括 ZJU 统一身份认证，WebVPN，CC98，校园卡查询等所有服务等密码都会被软件保存到本地

  • 所有密码都被明文保存在 profile/accounts.json 中，没有任何意义上的任何加密。

  • 这意味着任何程序都能直接访问这个文件并且读取你的所有 ZJU 相关账号密码, 这是一个很严重的安全漏洞。

  • 但是很神奇的对于你的邮箱密码这个项目反而会加密 – 但是同时你的其他所有密码都已经泄露了

笔者至今不理解为什么要如此处理，严格来说这里只需要保存 cookie 就行了（即使是 cookies 也应该加以保护）。直接储存用户的第三方服务密码简直是木马软件的行为

  • 似乎没找到自动删除日志的地方，日志会不断产生然后一直占用硬盘空间

项目作者声称这一点不能被认为是安全漏洞，这个观点是极其错误的

但是我并不认为明文存储在本地的硬盘 -> 严重安全漏洞。且不说你哪怕加密存储在浏览器的密码不一定有本机明文密码安全…其次你本地本来就存在很多凭据，比如 SSH 私钥，AI auth.json 等凭据，软件读取这个就可以直接抵达你的服务器或者使用你的 ai，所以通常我们并不认为这个属于严重安全漏洞。

  • 首先，明文储存密码就是安全漏洞，所有浏览器在本地储存的密码都是经过加密，题主提到的应当是相当久之前 edge 会在认证之后把所有密码解密加载到内存中，不管微软方面如何辩解，所有稍微有一点技术知识的人都认为这就是漏洞（而且 edge 后来也默默修改了自己的行为）

  • 其次，把 apikey 明文放在环境变量文件中本身也是一个不安全的行为，正确的方式应该是使用系统 Keyring 加密保存然后加载，具体可以参见这篇博客。同时，其实 ssh 的私钥也是应当设置密码的

  • 最后，其实多少可以看出原贴主在一些基础的计算机常识和开发项目的经历有所缺失，犯错是难免的。但是不了解这个安全问题并不等于这不是个问题，出于对项目负责的原则，这个漏洞应当尽快修复

III. 不要重复造轮子

善用搜索是一句老话，但是对开源本身依旧适用。如果别人已经实现了你的 idea，你可以帮他修 issue，提 pr，成为那个项目的 contributor 而不是另起炉灶。如果我们已经有了 ZJU-Assistant，我们就不需要 Awesome-ZJU-Assistant, Tiny-ZJU-Assistant, On-my-ZJU-Assistant, Yet-Another-ZJU-Assistant…

当然如果你想用 rust 重写 ZJU-Assistant-rs 另说（

这一点其实也不仅限于写代码，也是实现任何项目的一大准则。例如如果有人想写一个自己的 blog，相对合理的做法往往是选择一个博客框架并部署（而不是用 agent 从头写一个…)。从头实现一个现代网站的细节和难度是比一般人想象的要高的，如果不注意就会闹出想某人一样的笑话。

IV. 关于一些疑问

“这个标题过于夸大了。。。。。”

首先标题有点夸大结果，目前确实没有真实泄露的事件（但是存在泄露的风险），此处应当道歉。

“我只知道我的 claude 和 codex 都是本地明文存储 API key 的，lz 标题党并不可取。”

lz 依旧需要强调，我对这个项目实现方式主要的质疑在于他储存的是第三方服务的密码，这里的第三方服务密码是你自己设置的，所有浙大的网站和服务密码，而不是软件自己生成的某个临时凭据。目前有很多的第三方服务授权的方法，最安全的是官方授权的 oauth，对于没法和官方合作的项目，也有浏览器登陆后调取临时授权 token 的方法，而不是直接储存用户的密码随时帮用户登陆。

其次，即使是 apikey 之类的凭据，明文储存仍然不是最好的做法。从OpenAI 和 Anthropic 自己的 guide 都说明了明文储存设置了金额上限的，有限期有限的，可以随时撤销的 apikey 依旧有风险，更何况直接储存第三方服务的密码呢

“…如果说 AI 出现后涌现了很多的 vibecoding 项目，那么或许也出现了专门针对 ai 项目“审核”的群体，尤其配上这样的标题”

开源的意义就是让所有人审核你的源代码，开发者的相互审核是开源社区信任的基础。AI 反而加大了审核代码的压力，正在摧毁这种信任。再退一步说，项目使用的 GPL 许可证就允许了任何人“授予用户研究、修改和再分发代码的自由”。如果一个人不希望被人评价他的项目，那他为什么要做开源呢

阅读别人的代码并不比编写一个新的项目更简单，特别是分析一个完全 ai 生成的项目。lz 在上一篇文章出于 yq 的一些行为因此语言相对比较尖锐，但是在这里 lz 是反复强调就事论事分析，花了相当时间分析阅读源代码并敲了科普文章，却被攻击为“某些群体”，确实有些失落。

有人用 openclaw 的成功反驳我的观点，但是 “一个开源项目是否能延续的决定性因素不仅在于作者本身，更在于社区的评价和更多人的参与” ，那么一个文档混乱，充斥着动辄上万行的上帝对象，无用脚本，多余的 smoke test 的代码仓库，他的实现如何让社区评价？他的代码又如何让社区参与？

没有人能写出完美的工程实现。tscoding 直播的时候也有犯蠢的时候。但是选择直接开源一个质量如此低下的代码仓库相当于把压力全部转交给审核代码的人和提交 pr 的人，这恰恰是不对自己的代码负责的体现。这种项目的泛滥是对开源社区的极大打击。最直接的后果就是开发者之间的信任开始消失了。

clangd 现在基本是只接受自己人或者企业提供的 pr 了，这在之前是不可想象的

诚然，Openclaw 本身是个好的工程点子，但是综上我认为（也是普遍认为的），openclaw 的仓库并不是一个好的开源项目。群众的 AI 的狂热需求和盲目追逐中，这些理智的声音很难被人听到。

TBC…

代码规范，如何管理 pr 等等

All in all

再次声明，写这个 blog 的目的不是在批判项目作者，而是希望 8u 能先对开源本身有了解之后再去参与或者开发一个项目，一切对项目的批判请都局限于项目本身。Agent 的能力让现在很多人忽略了基础知识的重要，从而使得部分人让 Agent 的错误成为自己的谬误。

同时建议曾经使用过这个项目的同学尽快清理自己电脑上对应的accounts.json文件并及时修改已经被泄露的密码。不要把网络安全当作玩笑。最后，希望更多的人能了解到什么是开源，一起负责任地参与社区的建设。