现在时间是 01:07，我刚刚提交了 Solitudes （本站博客引擎）的一个大重构，主要更新是重新设计了主题系统，捎带 vibe coding fork 了一个 astro 主题到 Solitudes，主要是利用上这个主题系统，还有 RSS 订阅者计数。

主题系统设计的非常优雅，前后台、i18n、静态资源、模板文件、自定义配置。可以去 repo 里面看下。这个改动是比较大的，先是重构整个主题系统，然后 fork 新主题，最后做 RSS 订阅者计数，放在一年以前是很头疼的，单一个页面的细节也得调半天，现在直接 vibe coding 两天时间，边玩边指挥，就能搞这么大个改动，而且 Solitudes 的改动我根本没用一流模型，一流模型用在哪吒监控上了。

这短短两天时间做了好多事情，

• Solitudes
  • 评论区用户信息输入昵称或邮箱自动加载
  • 主题系统重构 GLM4.7
  • fork astro 主题 GLM4.7 + MiniMax m2.1 + Gemini 3 Flash
  • RSS 订阅计数 GLM4.7 + MiniMax m2.1 + Gemini 3 Flash
  • 小修小改 Gemini 3 Flash
• 哪吒监控
  • 集成 TSDB 提供历史数据 Opus 4.5 thinking

我先用了 GLM 4.7，然后 MiniMax m2.1，然后一直用的是 Gemini 3 Flash。Opus 额度很少感觉只有 1 小时的额度，很快就用没了，就用在刀尖上了。这些都是蹭的免费额度 😂 GLM 和 Gemini Flash 基本上量大管够。

整体体验 Gemini 3 Flash > GLM 4.7 ≈ MiniMax m2.1，Opus 地表 no.1 不用说。

量大管够咋瓢来的呢，阿里 iFlow CLI 转 API 的 GLM + MiniMax 不限量供应，再加 5 个 antigravity 免费号。

平常自己维护的项目正在尝试用 OpenCode 做主力，正在深度体验。团队内还是以 Claude Code 为主。

只要模型达到一定智力就可以干活，并不一定要一流模型才能做事，对于能力比较低的模型可以搭配一些测试工具，使用 TDD 模式开发，已经够用。

放假就是闲的难受，刚好 Copilot 额度刷新了，Vibe Coding 下，舒服 ～

做了两项 Solitudes（本博客引擎）的优化，

• 自动匹配语言发送邮件通知
• 邮件阅读追踪

自动匹配语言我原本只是想着用 Go 的正则简单匹配下，结果 AI 发现还有 UA 数据，顺手就做了个 fallback。现在大家的邮件通知都会是中文的啦，感觉也会减少进入垃圾桶的概率。

至于邮件阅读追踪，这个功能其实是我前几年想做的一个东西，但是那时候起坑了，没啥意思。奶爸的评论的回复按钮左边的 icon 就是 obaby 有没有阅读奶爸这个评论的邮件通知的状态，鼠标移上去可以看到说明。

本质就是放个不可见的图片，只要图片一加载就相当于阅读了，但是有些服务商会代用户去请求，这样可能不准确。或者有人像我一样，默认不加载任何图片，也追踪不到。

所以 AI 又拿出经验来了，做了个 URL 跳转更新状态，如果点击按钮了按钮也会更新状态，哈哈，又是个 fallback。

这博文写完我突然想到评论 ID 前端都可以拿到，可以用来伪造阅读状态，需要进行一个映射用一个没有暴露的秘密发送通知，马上又优化了一下……

• 邮件追踪 token 映射

有点完美主义……每次 Vibe Coding 都感觉很爽。

给老婆买了 Switch 玩，其实我是更倾向于 PlayStation 或者攒个 Steam Station 的，但是我知道我买了肯定吃灰，一个是我没太多时间玩，另一个是我腻的很快，我喜欢几个人一起玩，不喜欢单机/RPG，所以最终选择了 Switch。

推荐几款感觉值得玩的游戏，总共也没买几个游戏。大部分时间还是吃灰，偶尔拿出来维护一下。

派对游戏

1. 「马里奥赛车世界」这个是买机器时候绑定的，也没买方向盘，也挺好玩的，多人赛车游戏，我俩已经全通关了。跑出金牌感觉就没啥意思了，等家人派对时拿出来再玩玩也挺好的。
2. 「大富翁 11」这个是我第二推荐的，这个是概率游戏，特别适合几个人打发时间玩，而且很便宜。
3. 「Nintendo Switch™ Sports」有保龄球、网球、击剑、高尔夫等多种体感游戏，可以两人或多人 PK，又能有点锻炼又能玩，挺有意思。

其他

1. 「双人成行」这个我俩也通关了，前面都挺好的，后面打怪有点累有点乏味。有几个关卡挺刺激的，整体推荐。

有啥好玩的双人/多人游戏，分享一下？

上次买房后一直没买电视，这次买房终于是买了个电视。系统非常非常清爽，打开之后就几个自己安装的应用，没有任何推荐和广告，爱优腾一个没装，装了 BBLL、YouTube 和 yamby。现在看视频体验特别的好。没买电视时 hxd 给了我他的 emby 站点，我还没当回事，更新速度不如欧乐，也不如欧乐方便，直到买了电视我才知道差距，hxd 真香。

自带应用或推荐应用一个别装，自己找资源，比如 emby 分享。最次最次安装一下 TCL 开发的 BrowserHere，宇宙第一的安卓 TV 浏览器，兼容性非常好，可以在线看欧乐和 ikanbot。

如果要看哔哩哔哩，可以安装 BBLL v3.5，支持直播。我是看「七星山荒野求生」下载的，平常很少看，这个客户端很不错可以看直播，可惜老六荒野剪辑的和屎一样，内容又少又慢。

至于 YouTube，刚开始装上以后打开一直提示无法连接网络，我猜是系统根据 package id 做了拦截或者因为缺失谷歌框架的问题，具体我也没细致追究。你可以试试安装「YouTube for Fire TV」，这个我是正常用的，电视版本广告长一些……但也能看。

我现在用的是 yamby，vidhub 也用过几天，后面要求付费就没用了，这两个体验都挺好，vidhub 支持的源多一些，比如 alist 分享出来的 webdev，还有一个网易 爆米花 我并没体验过，vidhub 支持 emby + plex，爆米花和 yamby 应该不支持 plex，自己按需选择体验吧。

其他问题是播放 4k 视频可能会卡，我一般就直接改 1080p 看了，我近视，看不太出区别，后面可能会买个 Apple TV 提升观影体验，短期不会考虑买盒子。

玩域名得好多年头了，从完全不懂域名用 5211314***.***.cn 这种垃圾，到啥比小白买 kupai.us 等「品牌」域名和十几个 LL.gy 幻想暴富，最后玩明白了到玩成本高点的优质域名，我一直在场，今年还注册了 2 个新域名。虽然我不再花大钱了，但偶尔会花些小钱注册个玩玩。

至于当作投资，算了吧，域名已经死了，米表死了一批又一批，玩米的朋友越来越少了。只推荐玩，花小钱办大事。

挑选域名

怎么挑选一个好的域名？我觉得要考虑两点，一是背后注册局的稳定性安全性，二是价格。.com，.net，.org 这种老的传统 gtld 基本上能满足普通人的需求了，如果你想要的词比较热门可以退而求其次选择 .co、.io、.ai 这种比较热门的后缀，至于其他 cctld 自己决定。

作为一个普通人，第一个域名应该怎么选？

个人姓名

比如王小明人生第一个域名可以这么选

1. wangxiaoming.com
2. xiaomingwang.com
3. xiaomingw.com

不要小看自己的姓名域名，我身边被我安利注册域名的，个人姓名域名一般他们都留下来了，至于其它灵机一动注册的域名，大多过期丢掉了，不要搞带什么 ceo、king 之类的沙雕域名。

长尾词

我只说普通人通过注册能够拿到的，是长尾词。如果你想注册一个 qio.ng、或者 qundao.com 这种域名，大概率也是想想了。
长尾词大都是自己灵光一现，也是自己的一部分投射，比如说我今年注册的 2 个域名，

1. infiniteprogress.org 这是因为我看了好多关于影视飓风的内容，并且看到他们官网上面的「无限进步」，感觉马上上来了，一顿研究确定了这个域名。
2. notthegoodguy,com 这是因为我随便逛博客友链的时候，逛了个友链的友链，叫做「绝非善类」，这名字起得好，感觉又来了，一顿问 AI 也确定了这个域名。

这两类是有点价值，成本不高，普通人可以拿住的。别搞续费几千的域名，再好也是负债。

注册域名

等你选好了想要注册的时候，可以到 tld-list.com 或者雇佣了 8 位阿姨更新价格的陶老师的 哪煮米 去找低价注册的地方。
排序的时候可以按照续费价格排序，不要贪图注册那点优惠，省的后面转来转去麻烦。

使用域名

可以做博客，可以做邮箱，推荐看一下我写的「域名 & 邮箱安全最终指南」，我是几年前买的 G Suite，现在已经改名 Workspace，也顺利更换了主域名。这年头写博客的人不多咯 ～

工作第 10 个年头，折腾这么多年了，开始有自己生活了，对于兴趣现在是有点提不起兴趣了。比如今天看到 nametra.de 这个域名市场，有些感慨，江山代有才人出啊，前些年域名行情还可以的时候，什么米表，什么市场，大家都是比较关心的甚至百花齐放。但是因为那时候没有 AI 没有 Vibe Coding，只有少数人有话语权，现在年轻人不用花太多时间就可以拥有自己的域名市场。

搞个专栏发点现在还在玩的东西，看看有没有其他同路中老登。

这里是奶爸的一些经历 ～ 本文最初写自 2020 年 7 月，2025 年进行调整并放到全局底部。

工作经历

先整理下工作项目经历看下有哪些值得去记录一下的，

• Teveu 北京探视科技，16 年 8 月 - 17 年 4 月

  1. 在君正定制的小型安卓开发版，在上面做一些 C/S 的开发，视频录制与同步。
  2. 维护了一个企业网站（PHP），简易表单可提交邮箱。

• M2IT 北京喵萌科技 ｜ 聚力向前（北京）科技有限公司，17 年 4 月 - 19 年 3 月

  1. 刚进公司维护的是公司的 PHP 后端，一个二次元社交 App
  2. 后面转型开始使用 Go，做了一个众包平台，内含 Excel 文件分发收集，任务管理，账单结算及 内部员工之间余额交易（OTC）的功能。
  3. 后面做了一些配套 App（React Native）、terminal 工具等。

• 县人民法院驻场外包，19 年 3 月-19 年 5 月

  1. 智慧法庭、办公系统、瘦终端 维护
  2. 庭审现场保障（给一个涉黑案件在刑事审判庭机房做了直播保障，记忆深刻）

• Bitizen 北京空空科技，19 年 5 月 - 24 年 3 月 产品停摆

  1. DeFi 1.0 19 年 5 月 - 20 年 2 月 多次重构，单体大型合约 到 分体大型合约。
  2. DeFi 2.0 20 年 2 月 - 20 年 6 月 分体大型合约 到 数据逻辑分离及入口逻辑分离的可升级合约。后端也遇到了一些问题，前段沉淀了一些标准。
  3. Crypto Wallet 20 年底 - 24 年 3 月
     1. 先是从 AlphaWallet 上面测试了 MPC 钱包可行性，21 年初开始招 iOS/Android 开发开始基于 AlphaWallet 做 MPC 钱包
     2. 21 年 11 月，我们看了一手 https://www.raywenderlich.com/books/flutter-apprentice 由我打头使用 Flutter 全部重构
     3. 迄今为止我们已经做了 3 年，成为了支持 Bitcoin、Ethereum、ERC4337 的比较完善及领先（功能方面）的钱包

• TODO 耕耘在 BlockChain / AI

*原本这个文章已经写了大半了，结果因为奶爸不小心按了 command + R 全部给冲掉了，然后奶爸痛定思痛，加了 刷新/关闭 页面时的弹窗提醒。—— from 2020

租住经历

• 2016 年
  • 6 月 昌平 平西王府街 三友公寓
  • 8 月 昌平 宏福(修正)大厦对面 武夷公寓
  • 11 月 昌平 生命科学园 恒鑫公寓 501
• 2017 年 11 月 - 2019 年 3 月底 海淀 三义庙社区 14 号楼 302
• 2019 年 3 月底 - 2019 年 4 月底 县里一公寓
• 2019 年 5 月 3 日 - 2020 年 8 月 26 日 海淀 三义庙社区 14 号楼 302
• 2020 年 8 月 - 至今 居家办公 😷
• 2023 年 4 月 买房
• 2025 年 1 月 亏 5w 卖房、第二次买房，3 月-5 月一直盯着装修累的不行。

博客历程

0x0 WAP 自助建站

那个时候是初二初三，手里面只有淘换来的一个二手三星滑盖手机，和一个山寨机。塞班系统的三星手机是奶爸的建站主力，家里面也没有电脑（后面有了但是等待奶爸读大学，家里面才装了宽带），记得很清楚，人生第一个域名是 5211314***.***.cn ，such a GOOD domain name! 😢

当时大部分自助建站平台使用的是 柯林自助建站系统，大部分内容也都是 斯凯 mrp 和什么资源导航之类的。网站已经无迹可寻了，但是柯林还在，掌掌眼吧。

后面自己也买了域名，也搭建了一些 ASP、PHP 的站点，后面也没怎么深入研究。玩心重，小聪明，易满足。

0x1 Lofter.com

奶爸在上大学的时候，是系里面的风云人物，计算机协会技术部部长。带领团队到济南参加比赛，拿了个三等奖回去。那时候涉猎还挺广泛，并且认为 C、Java、PHP、.Net、Android 会是未来技术的发展方向（2016 年）

考古链接：https://niuti.lofter.com/navigation

0x2 Self-hosted Typecho

1. 在大学的时候，niuti.org 这个域名后面搭建了 typecho 博客，用的腾讯云 1 元/月的学生扶持，那个时候网站开始需要备案了。图是没有了，静态资源文件好像没了。
   考古链接：https://web.archive.org/web/20160414001721/http://www.niuti.org/
2. 参加工作后，使用终身学习这个域名搭建了博客，还是 typecho，换过不少主题，也买过一个主题。工作后热衷于收藏域名，先后花了十几万买了很多域名，现在基本都砸手里成传家宝了。后面换成了自己开发的 Solitudes 博客引擎。

0x3 WordPress Mundana

只在 2019 还是 2020 年用了短短几个月，这是个多用户的，因为注册了终身学习这个域名购买了 WowThemes 的 WordPress 主题，这是个多用户的准备请几个好友一起持续写作准备长期使用的，但是烂尾了，人的天性就是懒，长期写博客的人也没几个，我自己用样式也不好看，也不太喜欢 WordPress。没有给到我一种满足和成就感，还是换回了自己的博客引擎。

0x4 Solitudes

终身学习经历了 lifelonglearning.cc -> lifelonglearni.ng -> lifelonglearn.ing 域名的质量步步在提升，我也在不断进步。

欢迎使用我的 开源博客系统，2025 年 vibe coding redesign 了一下，整个 2025 感觉是一个飞跃，AI 编程在这一年里面突飞猛进，这个博客系统开发完 7 年了，现在优化后的样式看起来还能再战 7 年。

优化博客上头了，一点两点三点，时间就这样过去了，GitHub 的 Task 真的蛮舒服的，一边听相声一边 Vibe coding。

好久没写博客了，7 月份跟着装修完很累，又在上海呆了段时间，回来闲下来后发了个牢骚一直停到了现在，平时比较忙，除了干活就是陪媳妇看剧打游戏了，玩个手机都是奢侈，可以说是过上正常生活了，这才是正常的生活，忙忙碌碌，没啥时间。以前的时候漂泊在外打工，除了坐班工作，吃外卖，根本没啥事，闲的很，所以又搞开源又搞搞这搞搞那的，现在基本没什么时间关注自己的情绪。

我感觉在咱们这，不论什么行业不讲标准只讲良心……因为没什么规范可言。我这个房子装修时重新改了水，现在浴室里固定管子钉子全都生锈了。就算是恒洁的卫浴，装了三个钉子也生锈一个。厨房悍高的台盆还是奸商给我装的库存货搭配两个「纯铜阀门」的三无阀门。当时也没那精力研究和较真，太累了，什么不干坐工地一天都能把人急死。

好了，闲篇儿聊完了。先聊点正事最后聊聊 AI。

智能合约管理

简单来说就是要做可升级用多签钱包（MPC）管理，至于防黑天鹅（暂停、紧急提现）根据业务来看，一般来说是给非技术人员能够作为 backup 快速处理意外用的。

EVM

一般采用 UUPS Upgradable 或者 DiamondCut 架构或者有些业务场景会用到 Beacon 架构，升级权限交由团队管理的多签钱包（MPC），这里坑比较少，市面上例子非常多了，相关文档开发工具也比较成熟，只提关键词吧。

Tron

像 ZKsync 和 Tron 都是比较特殊的 EVM 链，为啥单单拿出 Tron 来说，因为 Tron 更加特殊一点 😂，他的 gas 模型比较特殊。如果你们准备赞助 transaction，就用一个公共的 deployer 部署你们的合约，方便统一进行赞助。

Solana

Solana 原生可升级，通过 BPFLoader 来执行升级，关键的方法就两个，一个 setAuthority，一个 upgrade，关键角色是 program 的 upgrade authority。这个 upgrade authority 是可以交给多签钱包管理的，前端构造一个升级交易就好了。

这里肯定不能这么简单，我要额外提一点就是自定义升级控制，比如说 30 天内是 A 可以控制升级，超过 30 天改为 B 可以控制升级该怎么做？答案是将 upgrade authority 交给 PDA，在 program 内部控制 PDA 调用升级，我用实操经验告诉你这是可行的，我就不手把手教你了，快十二点了我要睡觉了 😂，给你个小提示，可以在 Anchor.toml 里面定义创世数据，将 program 设置为可升级来编写测试用例进行测试。

Sui (move)

Sui 和 Aptos 算是将 move 魔改成了两个派系，Sui 的设计是非常好的，你写过他们两个平台的合约你就知道。Aptos 链的版本就比较混乱，像是农耕时代的产物。Sui 的链式调用和所有权都非常清晰，符合直觉，反观 Aptos 则是一团乱麻，如果 Sui 实现了忽略定义动态调用其他合约，它的开发体验一定不输 EVM 和 Solana。

Sui 管理是有一个 UpgradeCap 的 object，在部署时会交给 deployer。同样你可以把这个 Cap 转给团队的多签。我在这里还是问你，怎么自定义升级控制，你可以看官网文档的 Upgrade Policy 部分。将 Cap 作为 shared object，通过你合约的方法吐出 upgrade ticket 进行升级，小提示是你可以额外加测试框架比如 jest 运行一个 local node 来测试升级，sui move test 只测试升级外的业务。

Ton

Ton 这个链设计的太差劲，一个交易的多个消息可能在任意地方出错。还没真正做过合约，但是对他的交易构造和数据解析比较熟悉了，所以这里没什么指南了，只有一些心得。Ton 每个钱包都是合约，合约的实现是你自己选的甚至可以自定义，v3/v4/v5，第一笔交易需要 init，init 后你的使用其实就是调用你自己钱包合约的方法，不说了，没啥意思。

AI 漫谈

说起 AI 来我有点兴奋了，从 GitHub 给开源贡献者发 Copilot 开始我就在用 AI，因为之前大模型能力和 IDE 支持都不太行，也就一直在作为自动补全使用。慢慢大模型能力上来了，IDE 的花活更多了，事情就不一样了。我一直在用 Cursor，短暂的用过一个月 Claude Max Plan $100，Claude 是最舒服最牛逼的，Cursor 也不差。AI 写的又好又快，调调细节，来回几轮后就是很好的产出。

我曾经用一个下午时间通过 Claude 实现了一个 meme 发射平台包括合约、前端、简易后端（每个代币都是固定开头），你只要知道该怎么做作起来很快，现在完全看不到新牛马的未来，已经不是一行一行码字的时代了。

也是没想到，我已经经历第二次买房了，还是第一次买的那种两层的联排。上上周末终于搬进了新家，从 1 月份买下来，到 3 月份过完年他们搬家清房，再经历几个月的装修。经过了半年时间才住进来，真的累，身体也累心也累，就算是搬进来两周了，也感觉没有休息过来。先重新刷了墙，然后做了点饰面，感觉不健康又花钱拆除，两份钱打水飘。在宜家选的家具，都是自己拼装，没有买安装服务，说明书还不错，就是太繁琐了，刨花板的破柜子质量也一般，经常会拧裂，搬来当天买了树新风的空气净化器带除甲醛的。

搬家和重新整理东西，太累了，真的是再也不想买房了。劝后来的小朋友，能租就租，千万别买，买也得找个 5 线城市买个联排，楼房真的太吵了，上下左右都是噪音源，别人不变精神病自己也要变神经了。这个房子 184 平，除去物业费，夏天电费估计一月 500，冬季取暖费 4700，家具电器折旧，房子折旧。买了房修缮房子就是自己的事情了，各种隐形成本很多，没有租房省心，租房最多损失些押金，搬进来前租了一年房只损失了 90 押金。

搬进来两周了，住着还算可以，这里平常安静得很，也是因为隔壁孩子都大了，没有小孩。现在办公环境很舒适，次卧现在作为我的办公室，有空调，平常就是开着空气净化器开着空调，因为有 WFH benefit，我就买了显示器和支架、买了 Magic Keyboard 和 Magic Mouse，因为第一份工作用的 iMac 所以我对 Magic Mouse 是比较熟悉的，也比较适应使用。

提到第一份工作又想起从前了，第一份工作在西二旗，后厂村那边的中关村领创空间，是个共享办公室，我和老板一人一个工位，中午一起去后面地震局食堂吃饭。待到后面他没再租了，他在沙河高教园金融街那边租了房子我就转去那边办公，办公环境是真差劲，中午得一块走两公里吃饭。再后面要降薪我就直接交接了下撤了，当时在他租的房子里录视频交接我的工作，那会 iMac 录的人声特别不错，播放出来老板也以为不是我的声音哈哈。

闲聊下 review 吧，年底或年中 review，感觉效果有限，对一些人是不公平的。假设你在年初做了些成果，帮了一些人。在年中时候这些东西就淡化了，成果可能已经变成平淡日常，帮了别人别人也都忘了。人只能记得别人近期对自己的帮助，在写 review 时可能不会记起来了。

最后说一下「终身学习」，这也是我的博客域名，我对她的理解是「永远接受学习，不需要见什么学什么，世界上的知识那么多，哪学的过来呀」。

5 月份线下见到很多人，输入了很多新东西，认识了老张，这里比较深了不是合同外人道。

最近进行了大量 Solana 智能合约开发，积累了一些经验，分享给大家。

小提示 Tips

CPI 调用

在进行 CPI 调用时可能会遇到 account infos 超出数量限制的问题，可以在 CPI 调用之前对 account infos 进行去重合并 AccountMeta 数据，instruction 的 accounts 还是传原始数量的 accounts，因为 CPI 调用的 keys 限制只针对于 account infos，去重后一般不会超限。

Out of memory

Solana VM 堆内存限制 32K，栈内存限制 4K。

当执行期间 program 报错 out of memory 一般是栈内存溢出，这种错误可以给你的 context 里面的 account 数据放到 box 里面讲内存转移到堆中，或者使用 anchor 0.31.0 开始有的 LazyAccount 来加载 account。

错误信息中含内存地址 0xfffff 之类的报错一般是堆内存溢出，这种错误只能重构合约，比如说你有个超大 account 需要加载，放到堆里也放不下，可以用 zero_copy 方案重构下。

可以着重注意用到 vec 的地方，可以确定长度的 vec 在初始化时就分配长度，避免 2 倍扩容。

PDA

PDA 是十分灵活的，任何属于当前 program 的 PDA 都可以在 program 内作为 signer 进行 CPI 调用。这里有一个特殊的点就是假设你需要通过 SystemProgram 通过代码而不是 anchor 来创建和初始化账户，你可将 pda 作为 new_account 并作为 signer 调用 SystemProgram::CreateAccount，而不是必须使用 anchor 来创建 PDA。

安全检查 Security Checklist

realloc 陷阱

PDA 账户每次增长的空间只能在 10240 内，我们在 realloc PDA 账户时可以从 10240 扩容到 20480，然后从 20480 扩容到 30720，这没关系，咱们的数据不会出现问题。但是不要忽略一点，如果账户被缩小呢？realloc 可以直接从 30720 降到 100，PDA 中储存的数据就会被回收，造成安全问题。所以在使用外部传入的 realloc::size 时务必小心。

bump 陷阱

同样的 seeds 可以通过不同的 bump 创建出多个相同 seed 的账户，比如说 seed seed = ["nonce_used", order_id, [args.bump]] 可以通过计算出多个 seed 相同但是 bump 不同的账户来，如果你的合约中用的是外部传入的 bump 会导致你的一些以来这个 account 的逻辑有安全风险。在使用外部传入 bump 时务必小心。尽量不要外部传入 bump，除了每次运行时计算还可以使用自己存到合约中的通过 Pubkey::find_program_address 生成的 bump 来优化 gas。

writable 陷阱

即便你在合约里面没有将 account 标记为 account(mut) 但是在交易构造时传递的 AccountMeta 是可写的，且你的账户的 owner 是 signer，你的账户就会在执行时可写，所以如有必要检查你的 account 在 CPI 调用前后的变化。

职场 9 年，自己也有些固步自封了，多少思维有点固化，这是人性使然。如果一个人能长期拿捏工作且思维没有一点僵化与偏见，真的很佩服。排斥没见过的东西，真的很可怕。希望我尽量保持空杯心态不断进步。

所有 case 按照时间顺序倒序排列，Think Growth。

100 不断进步

其他就是些小的技巧啦，比如说在写 SQL 时，注意幂等 update t set a = 1 where a != 1 这种的小细节。或者啥巧妙的 design pattern 的运用。

5 逆向思维

经常锻炼自己的逆向思维形成肌肉记忆，在做 Solana 合约时遇到 PDA 账户大小的问题，包括怎么一步步的创建一个 10mb 大小的 PDA 账户。在这个过程中我只是一步步解决了怎么逐步创建大账户的问题，遇到和解决了很多的限制。唯独没有逆向思考一下能否将一个大账户改为小账户，会发生什么。结果被审计查出来高危 bug。

因为在向前的过程中耗费了太多力气，忘记了如何向后。

4 追寻本质

在做 Solana 合约时，有个 cpi invoke accounts 数量限制，我已经黔驴技穷了，试过了所有想到的方法，已经放弃思考了。结果优秀的同事找了 cpi 调用相关的测试用例，拉下来 solana 源码，通过跑测试搞清楚了这个限制的作用范围。他给我一说我立马发现了问题，马上解决了这个技术上的卡点。

这个同事大大震惊了我，我在反思我为何会这样，我为啥没有想到去看测试用例，如果再了解具体的功能或者功能的上下限时可以看相关功能的测试代码。

4.1 基础知识

关于 Solana 内存优化，Solana 执行时很容易超出内存限制，vec(rust)，slice(go) 在扩容时都有翻倍的策略，这点我就没注意到，还是被同事 点出来的……

3 信息获取

就信息获取这方面有两次被震惊

3.1 官方文档

还是 Solana 需求，最近 Solana 需求做的多。有个需求需要验证链下签名，使用 Ed25519 或者 ECDSA 来做。然后我就开始 Google 「solana ed25519 verify」看了一些几个问答和一个 GitHub 的 demo。结果同事直接找到了官方的 Native Program Ed25519Program，震惊到了，比我找到有效信息的速度快多了。

后面我在复盘过程中感觉以后了解什么东西第一步先到官网，我通过 Solana 网站的 「Ask AI」中输入「ed25519 verify」第一篇就是同事发的文档链接。

3.2 单纯震惊

我们准备在 Solana 合约中使用 ECDSA 验签，我还没开始研究。同事直接甩给我了解决方案 https://docs.rs/solana-secp256k1-recover 我简单看了下回了句「OK，就是不知道这个库有没有经过审计」，结果同事说这好像是官方的，我点进去看了下 repo 确认是官方的。

单纯震惊于他并不没在 Solana 上花太多时间，却对这个不常见的技术点上手的如此快，很快找到了可靠的解决方案。

2 一知半解

有些文档真的是写的差劲，或者找起来费劲。比如说 Solana AddressLookupTable 相关的内容，我现在已经对 AddressLookupTable 十分了解了，但是在最开始开发 Solana 时，我对 AddressLookupTable 真是完全摸不着头脑，我也没有去操作去试，一味的翻来覆去的看文档，结果还是一知半解。

直到我自己创建了 AddressLookupTable、解析了 AddressLookupTable 的 data 和完全了解了 Version0 Transaction 结构之后我才完全了解这个东西。

有些同事是真的 有点东西的，我自己很多入门的知识也是从同事的代码、博客中学来的，他们的博文写的是真的好，直观又完整。

了解一些技术的原理一是看自己熟悉的语言的实现，二是要完全理解它，比如说了解交易结构，把交易打成 hex 字符串逐字节解析它的内容。

1 相信本质，谁也不轻信

接手了点 SpringBoot 的一点后端业务的一个小的接口，设计一个 DB 表创建记录，记录用户条款已读状态。因为我之前一直做 Go、PHP 没有 Spring 框架的 ORM 的使用经验，不知道它背后会做到什么程度。还跟同事确认了过一些锁、唯一索引问题。结果出现了一个用户一个条款存在多条记录的问题，最后我背的锅。我其实从原理上就感觉这个同事说的有问题，这么做可能会出问题，但是当时由于相信他没有坚持去确认……

结果后面出了这个问题被吊起来打。

0 再合上游我是狗

这是我加入团队不久第一次被坑，刚加入团队在做一些前端的事情，前端 mono repo 的 master 分支经常 force push，导致我的分支在不断 rebase，写三天代码 rebase 两天，经过两次这种事之后我只通过无冲突 pull request merge 后拉 master 代码，尽量避免开发过程中拉 master 新代码。

2024 年的年终总结终于来了，大年初三。根据惯例和发小深谈一下，二十九回家上坟那天着急去找他聊天喝两杯茶然后就要走了他改天再到我家找我，发小刚从这里离开，原本约的昨天，昨天有事来了半小时匆忙走了，又改约的今天，他家族联系还比较密切事情比较多。今天晚上过来的，还带了个西瓜，去年到家里也是带了东西。他的博客有一整年没更新了，还挺可惜，现在他有在聊的对象，今年也拿了年终奖，没喝上酒原本还准备罚他三杯。今年也是发生了好多事情，我想一下怎么捋一捋。

年初，记得是上个春节后老大说公司有点变化，项目准备停掉了。然后陆陆续续准备项目进入维护状态，准备面试。现在之前的公司已经解散了，项目也停掉了，我也开启了新的职业生涯，还在 crypto 行业，很庆幸能在这个行业深耕。之前只是在 EVM 链和 BTC 上面耕耘，这一年里对 Solana、Ton 也有了比较深的了解，SUI 也有了些许了解。在自己 小房子 里过着简单的生活。

到年中 6 月份时因为噪音问题在对峙时被邻居从旁冲过来打了一拳，后面边工作边跟进这个事情，我太阳穴那里也肿了 2 周。消肿之后我就找中介把房子火速卖掉了，带着家具家电。我想的是近期不会再买房了，因为一般高层楼房太吵，和之前一样的联排也怕又很吵，我就想近几年一直租房，等过几年再看下自己发展。然后租了一年房子住着，过了整整 4 个月，10 月份派出所那边终于把 案件 处理完了，中间来来回回跑过多次派出所，基本上每星期都要打次电话督促处理，最终把他送进去 3 天，我也松了口气。

国庆去了趟河南，人生第一次在「胡麻地」买了个猫山王。去了「只有河南」，剧场也很不错，里面大剧场也可以看了粮仓那个剧，圆形剧场我以为是荧幕结果是人在巷道里面表演的，效果真不错。前面麦地的超远距离投影也很牛逼，就是晚上散场不好打车，有拼车就赶紧上别纠结。

回家后还是消不了气，我就开始准备诉讼，找家里亲戚请教，弄了份资料去立案了，法院那边也不顺利，如果不是家里亲戚打招呼都不直接让你在线缴费，实际上他们随便操作下你就能在线缴费，但是就选择更麻烦的方式。也是等了 1 个月，紧接着去了西安，穿了汉服去了长安街，去了回民街，城墙早市，吃了好多东西。回来都 12 月了才开庭，结果 胜诉 拿到赔偿。这下是真释怀了，前后派出所 + 法院折腾了 6 个月我也累了。

接着就是准备结婚和订团去泰国，结婚的事情真是太多了，丈母娘那边一直要求买房，我就是不想买，没满意的房子，差点都聊崩了。订宴会厅、婚纱照、准备礼盒、订烟酒水、订婚车、安排朋友、通知亲戚、送礼、彩排、布置婚房、安排座位。跟丈母娘周旋，让丈母娘满意，结一次婚扒层皮。

期间我的开源项目 哪吒监控进入 v1.0 并捐赠给了社区 转出了我的个人账户，7k star 还是舍不得的，但是咱就是这么洒脱，一点不墨迹转给组织了。

接下来我 又买房了，说来也巧，结婚前 2 周突然看到一个边户联排，面积也挺大 184 平之前那个是 129 平，马上联系中介去看了下，立马谈价就定下来了，结婚前 1 周火速办完手续过户了，这下丈母娘家啥毛病挑不出来了。关于这个房子后面额外再做分享。结婚前天晚上我是真烦透了，直接撂挑子让家里人去走婚车路线布置婚房和处理一些习俗的东西了，我跟远道来的朋友吃饭唱歌去了。第二天 5 点多起来到丈母娘家，接亲然后到宴会厅办仪式拍照，百十个人安排座位也是大事情，不提前计划好到时候都麻爪。

结婚第二天马上飞去泰国，泰国时间凌晨 3 点到的曼谷，睡了几个小时后开始逛，我们相当于提前一天到自由行，逛了周边的商场和夜市，多亏对象有想法，在小红书上面找了找附近玩的吃的地方，我是懒的不行，吃了个米其林鱼粥很不错。第二天开始就集结开始跟团了，时间短任务重还是跟团方便些，我之前来过一次清迈但是也没怎么坐过公共交通，也没信心自由行能安排好就直接报了个团。跟团曼谷看了郑王庙、大皇宫又大巴去了芭提雅邮轮表演、住泳池酒店、成人秀、泰拳表演 播求有到擂台露面打招呼。后面就去了山体大金佛，然后去了个靶场打了 110 发，打了 4 种枪，打的胳膊都被枪托打青了。在 21 航站楼又吃了俩米其林一个很普通另一个很咸，后面几天有很多购物行程，虽然不强迫但是多少也花钱。加上吃喝、玩飞伞潜水的项目，带了几千基本都花光了，算上团费比预想的花的多。

回来之后就准备过年了，过年这几天是我工作以来感觉最放松的一年。家人一起打麻将打到 3 点，也没什么工作的事情需要考虑，之前过年总会想着工作的事，总会想着来年怎么办，总感觉有些事情没了结，今年玩这么疯好像内心有个结打开了，通透了。

有些亲友会偶尔情绪不稳定，深夜 EMO 睡不着觉，或者胡思乱想，我会开导专注的做事，找一个需要做或想做的事，自己的工作或爱好，一旦把事做好，有想要不断精进的事，有知道自己不足的地方，就会专注在那里。自然而然找到自我屏蔽掉一些身外的事物。我有自己想做的事，对自己有标准，对什么传统习俗的和其他人的看法之类的都不太关注。

明年要找人做硬装软装了，给明年留四个大字吧：把事做好。

看到这个博主（明月已经不困了）是在某 tube 的某事录频道，一个片段，就感觉她的思考很有深度，不是一般人，又在信息流看到他在平台开账号了，直接关注一波，结果真是大开眼界，宝藏博主，思考有深度，知识面比较广。

今天给 nezha 加 oauth2 绑定功能，完了随便翻翻视频看到第一个推荐是这个视频，进去看了下，真牛逼 👍 财务自由了开始做视频。还是在一个行业的，我自惭形秽。看了那么多书，我不如她。多多学习。

https://www.youtube.com/watch?v=y_-Zuau9IOs

还是之前房子那个事情，虽然用了四个月把他送进去了但是我也打了三天消炎针，受了三天罪。实在是忍不了，最后把他起诉了，起诉时什么信息都没有只有姓名和住址。民事诉讼法规定只要提供的信息足以使对方与他人相区别就能立案，实际操作中没有身份证号是没发立案的。然后我又回到派出所作为被侵害人去要的对方的行政处罚决定书副本，才拿到对方身份证号立案。

起诉时需要写诉状，可以用微信公众号在线立案，有模板。

建议大家遇到类似事情，一定要做好准备记录下必要信息。后面报案审核后先进入调节流程，虽然我选的不接受调解。调解时因为没有对方手机号只是走了下流程，调解员说你这个没有手机号没法调解等着立案吧，等快到调解结束期时才通知开庭，法官助理通知到那写了个申请书申请法院到派出所调取案件相关的记录。这个过程不需要自己去调取。

开庭前需要打印相关证据，做证据目录。一二三四五列出来，每个证据想要证明什么，注意证据的三性，真实性、合法性和关联性。你当庭质证时也可以根据这三性质证。

当然我最终也没走到庭审流程，今天是「开庭/调解」，听法官的话，拿钱调解了，拿了医药费对方承担诉讼费。原本想体验一下这个体制，体验下完整流程，但是嫌麻烦没坚持住。对方态度挺好，道歉了。调解完一起在法院门口聊了会天，抽了支烟。感觉他还是挺真诚的。

事情算是全部结束了，调解协议双方就此事停止追究，放弃诉讼。折腾这么久，松了口气，不知道啥感觉。

OCBC 关户是近期经历的一个大无语事件，账户和卡在收到邮件那一刻起就不能入金了，一点准备都没有，还说几天后才限制入金，实际上收到邮件已经毙了。SGD 还好，还能直接转出，在 GSA 里面还有刚好价值 98 SGD 的 USD，没法 convert 到 SGD 转出，也没法再转入了。

但是如果你申请过 360 debit card，还有一个妙招，可以绑定这个卡到 Apple Pay 或从网站上消费，比如我续费了两个贵点的域名就花掉了。SGD 也直接转出了，以后跟 OCBC 就没关联了。不过有些买了定期理财把 OCBC 当稳定账户用的兄弟就遭殃了，现在处理起来有点麻烦。我当时也想冲的，但是最后忘记因为啥没冲了，可能是金额也可能是没看懂他们的说明，也可能是太麻烦，反正是因此躲过了一劫。

另外一件事就是拥有了美区 PayPal，一般来说美区 PayPal 是很难申请的，因为我一直都信用良好规范使用，注册 Oracle 也都是一把过，所以我开始是想直接试一下，注销了国区账户到美区重新注册，因为 GV 收不到验证码直接用 —+86 和身份证一把梭注册下来。结果是想得太简单了，ID 验证后给我送回了国区，我直接注销再想办法。

经过一些检索发现很多地方都提到在给公益网站捐赠时，付款的登录表单那里注册成功几率会高一些。于是我抱着试试看的心态也去 donate，第一次注册失败后没注意点击直接付款就捐出去了，只好又捐赠一次。一次 1 USD，结果真的神了，第二次注册时用 GV 也成功收到了验证码。

然后等被要求提交 passport，上传之后扫了脸现在账户还在（自 12 月 15 日存活到现在），也没其他强制提示。我准备用来给 Oracle 付款，续费域名之类的，不会收款，隔段时间找自己喜欢的开源项目或公益服务捐个几刀。

从 10 月 19 号写下第一行重构代码到现在，历经不到 2 个月时间，哪吒监控进入到内部测试阶段，v1 相较 v0 有很多优化，丢了历史包袱轻装上阵。

v1 开发过程中间有过停滞，有些人加入又离开，也有些人话说完就失联了，同样有些人一直在但是没有参与开发。这些都无可厚非，他们与我一样都没有从中获得什么利益。但是从 v0 到 v1 仍然有很多朋友切实的在为爱发电。

4 年前我一腔热血开始了这个项目，从 监控 到 报警 到 计划任务 到 webssh 到 内网穿透 一点一点做了些 实用 又 有趣 的功能。4 年后激情退却只是做了点开荒的工作，大部分工作都不是由我贡献，我退下来了还有人接棒，这个社区会继续壮大发展下去。我已将这个项目和它的收获的 7k star 捐赠给社区转移到 nezhahq 组织账户去掉我的个人标签，大家给贡献者们点点 follow，给他们的项目点点 star。

v0 用户须知

v1 版本跟 v0 版本不兼容，不能无缝升级，现存用户需要做下面两个操作避免 v1 发布后自动更新导致功能异常。

• 将你的 docker-compose.yml 中的 nezha docker 版本 tag 从 latest 改为固定在 v0.20.13
• 将你的全部 agent 禁用自动更新或更新到 v0.20.5 (一个 v0 的 final 版本)

v1 版本在内测结束开始公测时会替换掉原本的发布渠道，所以在此之前请完成上面操作

v1 和 v0 主要区别

前后端分离 是 v1 和 v0 的一大区别，v0 版本我是用了一直用的 Semantic-UI 做的 Go 模板，那时我其他小项目有做前后端分离，但是哪吒监控因为懒就采用了模板方案，这是一个非常大的弊端，不利于定制。虽然可以切换模板，但还局限性还是很大。v1 版本完全改成前后端分离并且将前台和后台分成两个前端项目方便用户只定制前台模板，后台工作比较多，前台基本接一下 3、5 个 API 就搞定了。

可以预见的是 v1 的主题一定会全面开花，定制前台主题非常简单，只有几个 API。

自动添加 Agent / 一机多装 v0 版本需要手动创建后安装，很多几十几百台的大户都提到希望能够自动添加，前段时间也有人 PR 了添加 Agent 的 API 来实现这个需求。但是在 v1 中 agent 安装时只需要一个固定的 dashboard 密钥，不需要一机一码手动修改，启动后会自动创建到 dashboard。

本地账户 v0 版本因为省事只用 oauth2 登录，有 oauth2 供应商为我们保障安全就没有做本地账户，5 年来没有一例因为哪吒面板被黑的事件 😎。v1 版本使用本地账户，通过一个简易的内置 WAF 来防范暴力破解（需要配置 Real IP header），安全性未降，便利性提升。

gRPC / Web 端口合并，因为在最初版本没有做合并已经散歩的很广了，不好再变，所以一直等到不兼容的 v1 到来才有机会重构这部分设计。

v0 核心贡献者

（排序不分先后）

• cantoblanco aka 白歌 wiki 主要贡献者，nezha.wiki 持有人。
• AkkiaS7 做了 V0 API 及很多其他小特性，group SPAM AI 守护神。
• nap0o aka 德 🐔 社 做了 server-status 官方主题并且积极更新聆听社区声音。
• uubulb aka Uub 做了 Web 文件管理器及很多其他小特性和很多 agent、script 相关的工作。
• Erope aka 火柴 做了早期很多 script 工作及其他 dashboard 开发，group rank bot。
• dysf888 aka 黑歌 做了一些 dashboard 开发，得意之作 fake-nezha-agent。
• JackieSung 第一个社区真正自己设计开发的主题 DayNight。
• 还有很多 Contributors 没有一一列举

v1 核心贡献者

（排序不分先后）

• uubulb aka Uub 做了几乎 v1 API、管理后台前端的所有工作。
• hamster1963 aka 仓鼠 将自己的 v0 的用户前端 port 到了 v1 作为 v1 官方默认前端。
• AkkiaS7 alpha 内测阶段 agent 二进制提供、教程引导。
• Colinwood 管理后台前端 i18n。
• cantoblanco aka 白歌 v1 wiki 主要贡献者。

很多人说哪吒监控有这样那样的问题，在有限资源下做选择、做出这些功能、拿到 7k star 已经证明我优秀的产品经理的属性 🤡 。如果资源宽裕情况下，想法还有很多，v1 只是其中一个。

为什么一直没做历史记录？

因为感觉 sqlite 做这个有点普通，如果用专业时序数据库那干脆全套用时序数据库得了，完全没必要用哪吒，哪吒监控主打一个轻量

如果那天心血来潮要自己做一个简易 tsdb 或爆改一个 embedded tsdb，历史记录应该就上线了

这几年因为哪吒监控还结识了一个线下朋友 Frank，来自台湾，线下一起喝咖啡聊了半天，遗憾是没一起吃饭，联系还没断，等去上海会约一下。akkia 和 火柴也面基过，因为我已经不在那个城市就没能一起。

开源不易，希望大家用的开心 ～

奶爸的不动产 🏠 相关博文。

憋了 4 个月了，事情没结束我也不想说。整个过程有点煎熬，这 4 个月里我打了几十个电话给派出所来催进度，给人的感觉就是效率很低，但是通过在处警室呆了挺长时间来看基本上每个案子都是这么处理，那估计也算正常状态。
第一次遇到这种烂事，第一次报警，一年时间里买房又卖房，这几个月对我来说真是一段深刻的体验。

报警

先说一下整体的时间线吧。

时间	事件
06-02	因琐事与邻居一家在门口争吵，然后被男邻居从右后方偷袭一电炮，报警
06-04	到派出所录了口供，但是网上查询没有立案处理结果是「自行调解」
06-05	联系中介准备卖房
06-18	签合同过户卖房
06-27	网上立案
……	经历四个月，多次去派出所
10-14	办结

男邻居在我面朝南的时候，从右后方走过来偷袭我，一拳给我打懵了，他手骨骨折，不知道是被我倒下时手握的还是打那一拳的时候被硌断的。虽然我没有还手，但是因为他骨折也造成了后面流程拖沓迟迟不能结案。
当天我等了有一个小时 JC 抵达现场，如果是有啥紧急事件，第一时间还是要跑，等到 JC 来到人都凉了。来了之后执法记录仪记录人员伤势、记录在场人的基本信息，然后直接走了，他们警情特别多，基本不能当场拷贝监控固定证据，我当时第一时间去物业将证据固定，然后去的医院。
如果没有将证据留存，可能比较难立案，在网上立案之前如果我有一点不坚持这事也就不了了之了。
后面问隔几天就打电话问一下，每次打电话或者每次去派出所都会被当成犯人一样把时间地点事件从头问一遍。期间有被要求去补充过证据，因为对方对他手骨骨折的事情咬住不放，警方需要证据判定双方责任。让我补充证据证明他的骨折与我无关我没有跟他互殴，如果你也遇到类似的事，且没有监控证明，你们双方都有伤，不调解的话结局可能是判定互殴，两个行政拘留。
今天办结了，早上过去领导就说带他们两个去体检，我们往上报（派出所无权处罚，上报到公安局定结果），出了结果该处罚谁就处罚谁，到这了我这个受害人都不明确，然后搭上警车跟邻居一起去医院做了个免费全身体检，一点毛病没有。
折腾到中午出了结果，我事实不清不予处罚在处警室等着，邻居事情多一点行政拘留 3 天，一直在小房间单独对线，快下班了才弄完。然后我就被采集指纹掌纹虹膜血样步态身高体重左中右拍照，像美剧似的，整个信息都记录了一下，隐私为 0 了。是的，不予处罚的人也要采集。
原本是想结案后继续民事诉讼再继续搞他，但是亲戚的意见是证据不够扎实，成本也比较高，时间比较长，建议我就此打住。这办案的 4 个月办的够够的，我也累了，我在派出所看着他坐上进拘留所的警车，他是两个孩子的爹，他姐姐问警官要不要买衣服能不能买吃的之类的。他的话我看上车时候也有点迷茫。到此为止吧。

卖房

这个房子 抛开噪音来说挺好的，格局很好，2 层每层都有卫生间，房间布局也很合理，层高很高比一般楼房要高出 1/3，采光也很好，我们在院子里搞了几次烧烤，院子里有颗葡萄树，闻着是甜的，但是因为果太小基本都裂了，没有尝过。
但是卖房的想法我早都有，因为无休止的噪音，只是这个事件让我下定了决心。小城市基本都是朝九晚五的工作，也有很多半天的工作，甚至很多都是不坐班的工作，也有很多小店主企业主。所以他们在家里的时间很多，居住场所比较稳定的家庭一般都有孩子，所有的楼房、联排的别墅每天都有人来会拉动桌子，来回跑，蹦蹦跳跳，除了独栋房屋都不清净，而我又最喜欢清静。
房子就两个属性，一个金融属性一个居住属性。我认为已经没有金融属性了， 房市已经横盘，没啥好升值的，持有一个房子三天两头修个水龙头，通通下水口，杀杀虫 尤其这种落在地面上的房子娥蠓真的很严重，夏天我得每 2 周就喷一次拜耳，对我来说居住的属性也可以去掉了，所以我火速谈火速过户出手了这套房产。

卖房交钥匙那天，最后转了一圈，看着家具家电，看着角角落落，能够回想起当初看上这套房的感觉，感觉之前的各种设想都没了，还是很心酸的。

买房一定慎重，能不买就不买，我现在是租的顶楼的房子，一般来说还是挺安静的。住在非顶的朋友们心疼你们一秒钟。没房的时候总觉得买房怎么样怎么样，买完了也就那样吧，除了日常要维护还要忍受噪音，慎重吧。
现在没车没房一身轻松，想去哪就去哪，想干啥就干啥。

眨眼间加入现在团队已近 5 年，很喜欢之前 on-site 的时候大家中午下午一起去技术交易大厦地下餐厅和小店吃饭的日子。加入团队的第二年就开始远程，到现在，其实些许有些遗憾，大家面对面的时间也没多久就进入远程工作了，但是我也喜欢当下的远程的办公方式，随时都可以跟家人一起吃饭。

在公司团队建设过程中发现了一些问题，主动制定了一些配合 GitHub 的工作流程。分享给大家，欢迎一起讨论优化。本文全部基于最大程度的利用 GitHub 来工作来写，能不用第三方服务就不用第三方服务。也会涉及一些其他的东西，比如管理内部 Web 服务。

为什么将 GitHub 作为大本营 all in GitHub？
对团队整体的技术沉淀很有帮助，无论是 feature 还是 bug，通过代码的 commit 关闭 issue 就可以使代码与 issue 建立连接，将每部分代码与最初的问题或需求关联起来，无论多久，再回头看下 commit 信息和 issue 都知道这个 commit 解决了什么问题。
其次所有数据都在一个平台利于维护，互相关联，谁能保证几年后多个平台的内容都不丢且还能好好关联在一起？

人员管理 Teams

这里说的是 GitHub 组织的 Teams 设置，建立一个 All 的 Team，把所有人拉进去，这一个操作是为了给全体人员一个基本的权限，以区别内部及外部人员。比如说临时需要一个外部人员加入 GitHub 做些什么，就不需要每个需要保护仓库都要设置他不能访问。

在组织设置中将成员权限默认为无权限，这个操作是保护所有的仓库，没有特别指定权限就无法访问所有仓库，在接下来的操作中进行不同岗位的权限隔离。直接拿我司的 GitHub 设计来说吧，都是我一手设计的。

其他安全设置

• 通过 repo ruleset / org ruleset 禁止删除主分支和主分支 force push

Teams 结构示例

｜- All 全体内部人员都在这个组里面，这是最基本的权限控制
   ｜- QA 测试岗位人员（目前产品岗也放在这里）
   ｜- iOS 维护 iOS 平台代码的人员
   ｜- Android 维护 Android 平台代码的人员
   ｜- Operation 运营岗位人员
   ｜- Backend 后端岗位人员
｜- Audit 外部提供审计服务的人员

「All」 下面的子 Team 会继承 All 分组的权限，「Audit」 Team 是外部人员分组，默认对所有仓库无读写权限，这样可以在有外部审计需求时单独对要审计的仓库给予「Audit」Team 读或写的权限。

仓库结构示例

｜- [company_name]-issues 给「All」小组读写权限，这是整个公司的中转站，公司内所有产品的 issue 都在这里处理，所有内部人员都可以创建、评论及修改，开发可以通过 commit message 中使用 「close [组织名]/[company_name]#[issue_id]」在对应仓库进行开发时自动更新 issue 状态
｜- [product_name]-iOS 给「iOS」小组读写权限，因为所有仓库默认权限为无权限，所以除「iOS」小组内成员之外，其他所有人都无法看到或编辑这个仓库，是非常好的权限隔离
｜- [product_name]-Android 给「Android」小组读写权限，同上

[company_name]-issues 这个仓库给了「All」读写权限，是整个公司所有人员的信息中转站，这样测试人员可以在这个仓库提交公司内所有产品的 bug，产品可以在这提所有需求开发的 issue。

开发小组继承了「All」小组的权限，所以他们可以在需求开发结束后或者 bug 修复后的 pull request 里面跨仓库关闭 issue，这样就实现了联动、闭环。如果你的开发人员不知道如何跨仓库联动 issue，参考这个文档 https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue

这样设计即针对人员隔离了代码仓库，又兼备了相互联动的能力。

内部 Web 服务

比如我们公司有内部 yapi 在线 API 文档、一些内部的管理后台。

此时可以通过 Cloudflare Zero Trust 结合 GitHub Oauth2 保护公司内部 Web 服务，所有内部服务的服务器不提供公开访问，在 Cloudflare Zero Trust 中创建应用将 Web 服务通过 Cloudflare 转发出来，设置鉴权方式为 GitHub 登录，且只有公司组织的人才能登录，这样就保护了公司内部的 Web 服务。

这样在有 人员离职 时也非常好处理，直接在 GitHub 处将人员移除，公司内部的 Web 服务自然就无法再访问了。

内部密码管理

一定要使用如 Bitwarden 类的密码管理软件的 Team 功能，且与公司有关的所有账户都要使用公司提供的邮箱及其他信息注册。避免有人员离职密码遗失或泄漏产生负面影响。

GitHub 协同工作流 v2

这是我写在公司 [company_name]-issues README 中的内容。

设计规范

制作索引（Storybook/Components）

整个产品内的配色、字体、组件都要有一个集合，所有 UI 的组成部分都源自这个集合，不能展示相同内容在一个产品中有各种各样的展示方式。

• 配色列表：颜色、适用场景
• 字体列表：大小、字重、适用场景
• 组件列表：像 Web 开发的组件库的文档一样，有一个组件列表，产品内所有界面的 Button、弹窗提醒 等的体验都应该是一致的

设计师的每个界面的每一部分都要源自最基本的 配色列表、字体列表、组件列表，不能随心所欲这里这个字号字重那里哪个字号字重，这个背景这个颜色，那个背景又不知道什么颜色。

配合开发

设计师要引导开发进行组件化，在代码中同样要将 配色列表、字体列表、组件列表 实现出来。使产品的界面相关代码灵活可读易维护。

需求管理

• 需求池 https://github.com/[company_name]/[company_name]-issues/issues?q=is%3Aopen+is%3Aissue+no%3Amilestone：这是未设置 milestone 的 issue 列表，从这个列表追踪尚未排期的需求。
• 遗留 Issue https://github.com/[company_name]/[company_name]-issues/issues?q=is%3Aissue+is%3Aopen+milestone%3A*+sort%3Aupdated-desc 可能存在 milestone 已结束，issue 验收没跟上后期又打开的情况，如果未更新 milestone 可能会被遗忘，从这里看是否存在仍开启的结束的 milestone 的 issue

#1 创建 Issue

1. 创建 Issue（每个 issue 代表着一个 feature 或 bug）
2. 关联 Project（每个 project 代表公司内每个产品）
3. *关联 Milestone 排期（每个 milestone 就是每个产品的每个版本计划）不是必要操作，不关联 milestone 视同进入需求池

#2 添加 Label

一个 issue 由 3 类标签标记，一种是基本标签，说明这个 issue 的基本性质，是一个新需求还是老需求优化还是一个 bug；一种是优先级标签，说明开发安排优先级；还有就是验收标签，说明在这个 issue 关闭时有哪些人员需要对其负责；如需添加新的 label 类型，联系 @naiba

基本标签

• 新增的 功能/UI 需求 feature
• 已实现的旧 UI/代码 优化：improve
• 已实现的旧 UI/代码 出现问题：bug

优先级

• 优先级：P0 > P1 > P2 > P3
  • P0 最高优先级：程序无法正常运行或程序无法跑通-无法正常启动、异常退出、crash、资源不足、死循环、崩溃或严重资源不足
  • P1 高优先级：核心功能无法完成、功能报错、数据错误等，但不会影响程序运行
  • P2 中优先级：一般功能性 Bug，产品中的不符合产品需求或用户使用的缺陷
  • P3 低优先级：操作不方便，布局不合理等一类的易用性相关的缺陷

Close 后负责人

• test/validation/pending 测试
• ui/validation/pending UI

#3 分配 Issue

注意事项

避免打扰 在被 assign 能立马能处理这个 issue 时在 assign 给相关人，避免太多邮件打扰别人

避免冲突 避免多个需求同一时间改动同一部分代码出现冲突，解决冲突可能很耗时

避免失控 避免启动依赖尚未完成的需求的新需求的开发，慢就是快

分配流程

1. 在需求准备好后再 assign 给工程师

2. 设置验收责任人

   1. 涉及 UI 改动，需要在 issue 中与 设计师 关联（或本身就由其创建）
   2. 设计逻辑改动，需要在 issue 中与 测试工程师 关联（或本身就由其创建）
   3. 比如 @ 一下，或者一并 assign，以方便在完成需求由相关负责人来验收

#4 进入开发

此部分为工程师接到 issue 后执行的操作。

1. 预估开发周期，在 Issue 界面右侧边栏修改 Start、End 时间

2. 开发结束时使用 commit 信息关闭 Issue，格式如下 https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue

   做了哪些改动
   [空一行]
   fix BitizenWallet/bitizen-wallet-issues#issue编号
   

血泪经验

• 非必要在 checkout 需求分支后不要 merge 上游改动，避免上游 force push 导致的历史断层，rebase 起来是灾难。
• 不要相信其他人的代码，从根上确认前人的工具类符合你想要的逻辑。

#5 结果验收

• test/validation/pending 由测试工程师测试
• ui/validation/pending 由 UI 测试
• 测试完成后将对应的 (test/ui)/validation/pending 改成 (test/ui)/validation/passed
• 如果发现问题未完全解决直接 reopen，开发重新解决

每个 issue 从开启到关闭都有人负责，凡事有交代，件件有着落，事事有回音。

#6 进入下一个 milestone

• 整理分配给具体工程师头上已完成未分配的需求
• 取消已分配未开始的需求的分配，要在下一个 milestone 重新安排任务（可能有更紧急的任务进来，要留出人手）
• 回到 #1

大道至简，减轻所有人的负担，精益自己的工作流程。