跳转到主要内容
01·10 SAT 4 posts
如果一个 UI 设计师订阅了 Claude Code ,那能做什么?
MCP 已经过气了, 现在是 Skill + CLI 的时代。 Make CLI Great Again ! #暴论
01·09 FRI 1 posts
我梦中的浴室就是有浴缸的,然后每天泡澡看一集新番。 PS. 上一年看的动画,一个手掌就能数清楚~
01·07 WED 2 posts
第一次坐地铁下班🕰
图片来源 这张图表确实令人印象深刻
图片来源
这张图表确实令人印象深刻。我只是没有意识到 Stack Overflow(SO)的衰落会是如此彻底。这让我感到震惊,其程度不亚于《大英百科全书》在维基百科发布仅9年后就停止销售印刷版,但衰落的速度甚至更快。
01·06 TUE 3 posts
@LOTU$
我已经拟定了一份草稿,请你务必进行词藻优化,去除所有符号和表情符号,永远不要出现“不是....,而是”的句式。不要出现破折号。不要过于结构化,只有这样才具有真人感。 一定要避免这种: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
01·05 MON 1 posts
01·04 SUN 1 posts
01·03 SAT 1 posts
01·02 FRI 1 posts
12·31 WED 4 posts
12·30 TUE 3 posts
SOP 在 Vibe Engineering 时代的必然性提到顶级软件工程实践中的各种 SOP,如「100% 测试覆盖率」「语义化类型名称」「代码风格统一」「MAX Linter」「静态类型检查」「PRD/设计文档/TDD」「持续集成/部署」
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
🔖 Stack Overflow 2025 年度报告:写代码如果不值钱了,我们该去哪? | 宝玉的分享 #pinboard #2025 #Software https://baoyu.io/blog/stack-overflow-2025-report-future-coding
2025 年是真正意义上独居的第一年,没有邻居,没有室友。独自一人的夜晚或是梦中,就会想起学生时代的那些不能再回去的种种,还有逐渐老去的家人。 在床上一旦闭上眼睛就会感受到那种「世界一起都与你无关」的剥离感。究竟有多少个夜晚都是靠着漫画看到筋疲力尽然后晕厥过去的? #life
12·29 MON 3 posts
笑死,我电脑内存是 16g #apple
笑死,我电脑内存是 16g #apple
🔖 E210|日本 “失去的 30 年”,炼成了中国餐厅排队王? - 硅谷 101 | 小宇宙 - 听播客,上小宇宙 #pinboard #life 真的诶,昨天去寿司郎,晚上九点钟才能吃得上,排队排到头晕目眩了。下次有朋友过来 4 点钟就要去拿票了( https://www.xiaoyuzhoufm.com/episode/68f8822f86851368eb3026b4
12·28 SUN 2 posts
今年不写年终总结。不是没什么可写,反而是能写的实在太多,肯定刹不了车。 况且我觉得明年对我非常重要,索性直接写明年的 Blueprint 吧。(确定不是🐦清单?
2025 年是我出生至今最愉快的一年
That is all.
12·27 SAT 1 posts
12·26 FRI 2 posts
🔖 Vibe engineering #pinboard #llm 当 AI 承担了 90% 的 "打字" 工作后,剩下的 10% 人类工作(架构设计、代码审查、质量把控、问责)反而变得更重要、更难、要求更高。 我也逐渐理解 HA reviewer 那边为什么设置这么多道机器人 check,linter 都基本开满,每一个都是为了减少 reviewer 的负担 https://simonwillison.net/2025/Oct/7/vibe-engineering/
12·25 THU 3 posts
玩过BLACKSOULS BLACKSOULS -黒の童話と五魔姫 -评分: ★★★★☆标签: 日本 猎奇 致郁备注: 7/10 燃尽了,一天没出门的周日
玩过BLACKSOULS BLACKSOULS -黒の童話と五魔姫 - 评分: ★★★★☆ 标签: 日本 猎奇 致郁 备注: 7/10 燃尽了,一天没出门的周日。 在 BLACK SOULS 亲手将所有女主做成童话书过了 C 结局之后,准备继续真结局。才发现真结局不需要这么残忍,以至于现在被迫着要跟某人手牵手去打真结局的 BOSS。 这种事情不要啊。 http://www.douban.com/game/35087787/
12·24 WED 2 posts
最近在好好上班,所以什么都没想叻。
12·22 MON 1 posts
12·19 FRI 2 posts
Codex is so so good at finding bugs and little inconsistencies. Where Claude Code is good at "raw coding"
感觉 Claude Code 写新功能,然后 Cursor 的 Agent Review + GPT 5.2 检查代码是最佳搭配
12·17 WED 1 posts
今年我的年度游戏是 《Elin》今年我的年度游戏是 《Elin》今年我的年度游戏是 《Elin》今年我的年度游戏是 《Elin》今年我的年度游戏是 《Elin》
今年我的年度游戏是 《Elin》。 真的无法想象,作为一个上班族是如何在两个月时间玩 260 小时游戏的。 那两个月什么都没想,全天都在想着 伊尔瓦大陆 (Irva),肯定帮我省了很多钱~ source #steam #elin
12·16 TUE 2 posts
@とある科学の⑨ | 散装懒鬼
Anthropic公司最近干了一件挺事,他们把研究对象对准了自己,调查了132位公司内部工程师和研究人员,做了53次深度访谈。 目的就是为了想搞清楚一个问题:AI到底是怎么改变他们自己工作的? 这个视角很特别。 因为他们的今天,可能就是很多行业的明天。 这份报告读完,我感受到的不是恐慌,而是一种很复杂的情绪。 从数据上来看,一年前,这些工程师在日常工作中使用Claude的比例是28%,觉得效率提升了20%左右。 现在,使用比例到了59%,效率提升感知涨到了50%。 相当于一年时间,两个指标都翻了一倍多。 但有趣的是效率提升的具体表现。 你以为是同样的活儿干得更快了对吧?不完全是。 调查发现,在各类任务上,时间节省其实没那么夸张,但产出量的增加非常明显。 而且27%的Claude辅助工作,是那些一直想做但优先级不够高的事情。 比如给代码写更完善的文档,比如做一些提升工作体验的小工具,比如重构那些虽然能跑但结构很烂的代码。 但人人都在变成全栈,代价是什么? 一个后端工程师描述了他用Claude做UI的经历。 他说设计师看到成品的时候惊了,问他这是你做的? 他回答说不是,是Claude做的,我只是指挥了一下。 这听起来很美好,每个人都变成了多面手,原来不敢碰的东西现在敢碰了。 但报告里有一个词让我印象很深:skill atrophy,技能萎缩。 一位工程师说,他以前自己去调试一个难题,虽然花时间,但会顺便读很多文档和代码。 这些东西当时看起来跟问题没关系,但其实你一直在构建对整个系统的理解。 现在Claude直接帮你定位问题了,这种附带学习就没了。 有些困难是学习过程中必须经历的,绕过它你虽然省了时间,但也错过了真正的成长。 这里有一个很微妙的矛盾。 现在的AI还不能完全信任,你需要监督它的输出,尤其是在重要的工作上。 但监督AI的能力,恰恰来自于你自己动手干活积累的经验。 一位安全工程师举了个例子,Claude给出的某个方案看起来很聪明,但他一眼就看出这是那种聪明过头的危险方案,是资深人士才能识别的陷阱。 他说这种判断力,只有做过很多年才有。 如果新人从一开始就依赖AI,他们怎么培养这种判断力? 报告里把这叫做paradox of supervision,监督悖论。 你越用AI,你监督AI的能力可能越弱。但你越不用AI,你的效率又跟不上。 这个困境目前没有标准答案,有些工程师的应对策略是刻意练习。 就算知道Claude能搞定,偶尔也强迫自己不用它,保持手感。 报告的结尾,抛出了一个有意思的视角。 软件工程一直在朝更高抽象层次发展。 最早的程序员要手动管理内存,要写汇编语言,甚至要用物理开关输入指令,后来有了高级语言,很多底层操作自动化了。 一位员工建议想当工程师的人:学会让AI写代码,然后把精力放在更高层面的概念和模式上。 这个建议有道理,但也有人指出,每一次抽象层级的提升都有代价。 当大家都用高级语言之后,大多数程序员就不再深入理解内存管理了。这种丢失的知识,有时候在关键时刻会变成问题。 读完这份报告,我总结了几条对普通人有用的insight: 1、效率提升的红利期是真实的,但那些被省下来的时间,要有意识地投入到AI还做不好的事情上。比如建立人际关系,比如发展判断力,比如理解系统的底层逻辑。 2、刻意保持一些不用AI的练习,因为你需要保持监督AI的能力。 3、重新思考工作的意义。如果你的满足感来自于亲手完成某件事,那要想清楚这种满足感以后从哪里来。如果你的满足感来自于结果和影响力,那AI其实是你的加速器。 4、关注人的连接。技术在让协作变得更高效的同时,也在稀释那些低效但有温度的交流。这部分不会自动补回来,需要你主动去维护。 Anthropic这份报告的价值不在于给出答案,而在于它呈现了一种真实的复杂性。 这群站在AI前沿的人,他们既兴奋又焦虑,既享受效率又担心失去什么。他们没有确定的未来图景,只有一种共识:要保持适应能力。 https://web.okjike.com/u/9ca2b1fd-086e-4fbe-a1f8-b641f8f4b9d1/post/6937c2d9b756b2fd2ad2a853