一个没有常识、活在自己世界中的中二病人（话痨）的自留地。
该频道不专注于 Daily 或 News，而是一个记录我当前关注和思考内容的地方。
1. 随机事项：每月为自己安排一些有趣的活动。（大概率🐦🤣）
2. 同步内容：我会收集在其他平台上发布的内容。
3. 私人笔记：没经大脑的学习笔记以及一些个人随想。
4. ACG 内容：浓度高的部份还是挪到 另外一个频道 @tomoko_acg。
5. 内容转发：在这个频道上转发的内容并不必然代表我个人的立场。
该频道不专注于 Daily 或 News，而是一个记录我当前关注和思考内容的地方。
1. 随机事项：每月为自己安排一些有趣的活动。（大概率🐦🤣）
2. 同步内容：我会收集在其他平台上发布的内容。
3. 私人笔记：没经大脑的学习笔记以及一些个人随想。
4. ACG 内容：浓度高的部份还是挪到 另外一个频道 @tomoko_acg。
5. 内容转发：在这个频道上转发的内容并不必然代表我个人的立场。
如果一个 UI 设计师订阅了 Claude Code ，那能做什么？
Black Souls II ing
我梦中的浴室就是有浴缸的，然后每天泡澡看一集新番。
PS. 上一年看的动画，一个手掌就能数清楚～
PS. 上一年看的动画，一个手掌就能数清楚～
第一次坐地铁下班🕰
这张图表确实令人印象深刻。我只是没有意识到 Stack Overflow（SO）的衰落会是如此彻底。这让我感到震惊，其程度不亚于《大英百科全书》在维基百科发布仅9年后就停止销售印刷版，但衰落的速度甚至更快。
我已经拟定了一份草稿，请你务必进行词藻优化，去除所有符号和表情符号，永远不要出现“不是....，而是”的句式。不要出现破折号。不要过于结构化，只有这样才具有真人感。
一定要避免这种：AI生成概率高的特征，如下：
语言高度结构化和模板化，格式机械，缺乏个人语境和人类情绪表达的细节。
高度结构化，语言模板化明显，机械的分条论述，缺乏个人语境和人类评论典型的情感细节。
喜欢用“不是……而是……”的句型，而且反复出现；
喜欢用各种自以为幽默的比喻，而且喜欢加引号
喜欢用emoji或者序号（1.2.3.4……）来开头
喜欢不停的用破折号
一定要避免这种：AI生成概率高的特征，如下：
语言高度结构化和模板化，格式机械，缺乏个人语境和人类情绪表达的细节。
高度结构化，语言模板化明显，机械的分条论述，缺乏个人语境和人类评论典型的情感细节。
喜欢用“不是……而是……”的句型，而且反复出现；
喜欢用各种自以为幽默的比喻，而且喜欢加引号
喜欢用emoji或者序号（1.2.3.4……）来开头
喜欢不停的用破折号
🔖 2025: The year in LLMs #pinboard #llm
完美总结 2025 年 LLM 领域的变化
https://simonwillison.net/2025/Dec/31/the-year-in-llms/
完美总结 2025 年 LLM 领域的变化
https://simonwillison.net/2025/Dec/31/the-year-in-llms/
【原创曲】ウィマーマ・サーガ（羽衣妈妈·物语）⧸ しぐれうい(9) vs. しぐれうい (16)【IOSYS（まろん&D.watt）】
【剧情背景】@時雨羽衣Official:
曾几何时，人类被血雨吞噬，为求救赎渴望回归母胎。
那份祈祷所唤醒的是——“创造神羽衣妈妈”。
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) 様
ーーーーーーーーー
发布视频
历史排行榜第10位
播放量:95.33万 弹幕:4290 评论:6255
点赞:9.56万 投币:2.42万 收藏:4.76万 转发:1.97万
发布日期:2026-01-04 12:17:17
如果你能用“预知未来”的方式玩游戏，会是什么样？（武士零）〖游戏不止〗
本期讲述游戏《武士零》（Katana ZERO）的剧情，玩法，以及结局。@森纳映画:
发布视频
播放量:126.03万 弹幕:3659 评论:1651
点赞:6.72万 投币:1.83万 收藏:1.27万 转发:2780
发布日期:2021-01-16 10:46:57
https://www.zhihu.com/question/498191369/answer/1907405427714560765
提到顶级软件工程实践中的各种 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
🔖 Stack Overflow 2025 年度报告：写代码如果不值钱了，我们该去哪？ | 宝玉的分享 #pinboard #2025 #Software
https://baoyu.io/blog/stack-overflow-2025-report-future-coding
https://baoyu.io/blog/stack-overflow-2025-report-future-coding
