一个没有常识、活在自己世界中的中二病人(话痨)的自留地。

该频道不专注于 Daily 或 News,而是一个记录我当前关注和思考内容的地方。

1. 随机事项:每月为自己安排一些有趣的活动。(大概率🐦🤣
2. 同步内容:我会收集在其他平台上发布的内容。
3. 私人笔记:没经大脑的学习笔记以及一些个人随想。
4. ACG 内容:浓度高的部份还是挪到 另外一个频道 @tomoko_acg
5. 内容转发:在这个频道上转发的内容并不必然代表我个人的立场。
我梦中的浴室就是有浴缸的,然后每天泡澡看一集新番。

PS. 上一年看的动画,一个手掌就能数清楚~
第一次坐地铁下班🕰
图片来源
这张图表确实令人印象深刻。我只是没有意识到 Stack Overflow(SO)的衰落会是如此彻底。这让我感到震惊,其程度不亚于《大英百科全书》在维基百科发布仅9年后就停止销售印刷版,但衰落的速度甚至更快。
我已经拟定了一份草稿,请你务必进行词藻优化,去除所有符号和表情符号,永远不要出现“不是....,而是”的句式。不要出现破折号。不要过于结构化,只有这样才具有真人感。
一定要避免这种:AI生成概率高的特征,如下:
语言高度结构化和模板化,格式机械,缺乏个人语境和人类情绪表达的细节。
高度结构化,语言模板化明显,机械的分条论述,缺乏个人语境和人类评论典型的情感细节。
喜欢用“不是……而是……”的句型,而且反复出现;
喜欢用各种自以为幽默的比喻,而且喜欢加引号
喜欢用emoji或者序号(1.2.3.4……)来开头
喜欢不停的用破折号
【原创曲】ウィマーマ・サーガ(羽衣妈妈·物语)⧸ しぐれうい(9) vs. しぐれうい (16)【IOSYS(まろん&D.watt)】
【剧情背景】
曾几何时,人类被血雨吞噬,为求救赎渴望回归母胎。
那份祈祷所唤醒的是——“创造神羽衣妈妈”。

16岁的“现世羽衣”是严厉拒人于外的审判者。
9岁的“无垢萝莉羽衣”以甜美的幻惑引导众生。

渴望重获新生之人啊,跪拜吧。
从那小小的摇篮之中,崭新的世界即将苏醒。
没错,开启这篇故事的——正是你。

ーーーーーーーーー

Vocal:しぐれうい(9) vs. しぐれうい (16)

Words & Vocal Direction:まろん(IOSYS)様
https://x.com/maron47

Music & Arrange & MIX:D.watt(IOSYS)様
https://x.com/wattchan

Illust & Animation:ががめ 様
https://x.com/utsugame

Illust:なな 様
https://x.com/Nana_yume87

Movie & Word design:お菊 様
https://x.com/__lizel

Music Director:保坂拓也(More Than Words)様
Recording Engineer:丸岡詩織 様
Mastering Engineer:吉良武男 (TEMAS) 様
ーーーーーーーーー
@時雨羽衣Official:
发布视频
历史排行榜第10位
播放量:95.33万 弹幕:4290 评论:6255
点赞:9.56万 投币:2.42万 收藏:4.76万 转发:1.97万
发布日期:2026-01-04 12:17:17
Media is too big
VIEW IN TELEGRAM
如果你能用“预知未来”的方式玩游戏,会是什么样?(武士零)〖游戏不止〗
本期讲述游戏《武士零》(Katana ZERO)的剧情,玩法,以及结局。
@森纳映画:
发布视频
播放量:126.03万 弹幕:3659 评论:1651
点赞:6.72万 投币:1.83万 收藏:1.27万 转发:2780
发布日期:2021-01-16 10:46:57
Media is too big
VIEW IN TELEGRAM
是不是可以改名叫摸鱼子了。

source #wakatime
为什么所有的人际关系里,只要我不主动就没有人主动找我? - oxyden的回答 - 知乎
https://www.zhihu.com/question/498191369/answer/1907405427714560765
SOP 在 Vibe Engineering 时代的必然性

提到顶级软件工程实践中的各种 SOP,如「100% 测试覆盖率」「语义化类型名称」「代码风格统一」「MAX Linter」「静态类型检查」「PRD/设计文档/TDD」「持续集成/部署」。

在以前的话,总感觉这些对于小团队的需求有「大炮打小蚊子」的嫌疑,想起前司 BOSS 说这些不过是「自欺欺人的减慢速度的玩意」。只是今年在 给 LLM 擦了一年的屁股后 ,我已经意识到不得不那么做了。以前可能会说「这个流程要放到大公司的团队才管用」,但现在,很自然地就在小团队、甚至是个人开发也很有必然性了。

以前写这些 SOP,最大的问题是人很难遵守。Deadline 一紧,代码风格就先放一放;Review 一忙,测试覆盖就睁一只眼闭一只眼;这个项目的实现方案很可能下个月就会弃用了,用半个月来探索「如何正确地搭建项目」不是浪费时间吗?更别提各种 CICD 的 WorkFlow 校验和严格 TDD、PRD 了;MAX Linter更是让人痛苦得没脾气。

但现在再不定好这些 SOP,你可能会得到:每一轮提问都是全新的代码风格、充满 debug 遗留下来的 log 语句、每一轮都要不断强调的设计思路、一不小心写出来的 shit 被无限放大、实际上不能 work 的代码、以及完全没有必要的冗余流程。

以前小团队靠「默契」「脑子里的规矩」就够了,但 LLM 不吃这套。如果你不把规范写下来,你就要无限重复。这就是为什么 SOP 变得必要了。不是为了「流程正规化」,而是为了让 LLM 每次都能正确地工作,也为了在代码量暴增时减轻 review 负担。(与 HA 的超繁琐 PR 流程达成和解)

正如 Simon Willison 在 Vibe Engineering 中提到的: 「 顶级工程实践在 LLM 时代会获得更大的回报 (LLMs actively reward existing top tier software engineering practices)」

PS. 最近有在给公司内部写一个 AI Programming 方面的 PPT,中间我觉得最为重要的一页就是讲到 Context Engineering 之后的「Proposal <-> Apply 循环最终提炼成 Skill」。我今天才发现,这 Skill 不就是传统意义上的 SOP 么,本质上就是把踩过的坑固化成规范,让下次不用再踩。

#llm
2025 年是真正意义上独居的第一年,没有邻居,没有室友。独自一人的夜晚或是梦中,就会想起学生时代的那些不能再回去的种种,还有逐渐老去的家人。

在床上一旦闭上眼睛就会感受到那种「世界一起都与你无关」的剥离感。究竟有多少个夜晚都是靠着漫画看到筋疲力尽然后晕厥过去的?

#life
笑死,我电脑内存是 16g #apple
Tomoko RD
今年其实不只在用 Spotify 🙂 #Spotify
网易云音乐的总结也出来了,看得出来,今年没有看两部新番
Back to Top