跳转到主要内容
01·10SAT4 posts
如果一个 UI 设计师订阅了 Claude Code ,那能做什么?
MCP 已经过气了, 现在是 Skill + CLI 的时代。 Make CLI Great Again ! #暴论
01·09FRI1 posts
我梦中的浴室就是有浴缸的,然后每天泡澡看一集新番。 PS. 上一年看的动画,一个手掌就能数清楚~
01·07WED2 posts
第一次坐地铁下班🕰
图片来源 这张图表确实令人印象深刻
图片来源
这张图表确实令人印象深刻。我只是没有意识到 Stack Overflow(SO)的衰落会是如此彻底。这让我感到震惊,其程度不亚于《大英百科全书》在维基百科发布仅9年后就停止销售印刷版,但衰落的速度甚至更快。
01·06TUE3 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·05MON1 posts
01·04SUN1 posts
01·03SAT1 posts
01·02FRI1 posts
12·31WED4 posts
12·30TUE3 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·29MON3 posts
笑死,我电脑内存是 16g #apple
笑死,我电脑内存是 16g #apple
🔖 E210|日本 “失去的 30 年”,炼成了中国餐厅排队王? - 硅谷 101 | 小宇宙 - 听播客,上小宇宙 #pinboard #life 真的诶,昨天去寿司郎,晚上九点钟才能吃得上,排队排到头晕目眩了。下次有朋友过来 4 点钟就要去拿票了( https://www.xiaoyuzhoufm.com/episode/68f8822f86851368eb3026b4
12·28SUN2 posts
今年不写年终总结。不是没什么可写,反而是能写的实在太多,肯定刹不了车。 况且我觉得明年对我非常重要,索性直接写明年的 Blueprint 吧。(确定不是🐦清单?)
2025 年是我出生至今最愉快的一年
That is all.
12·27SAT1 posts
12·26FRI2 posts
🔖 Vibe engineering #pinboard #llm 当 AI 承担了 90% 的 "打字" 工作后,剩下的 10% 人类工作(架构设计、代码审查、质量把控、问责)反而变得更重要、更难、要求更高。 我也逐渐理解 HA reviewer 那边为什么设置这么多道机器人 check,linter 都基本开满,每一个都是为了减少 reviewer 的负担 https://simonwillison.net/2025/Oct/7/vibe-engineering/
12·25THU3 posts
玩过BLACKSOULS BLACKSOULS -黒の童話と五魔姫 -评分: ★★★★☆标签: 日本 猎奇 致郁备注: 7/10 燃尽了,一天没出门的周日
玩过BLACKSOULS BLACKSOULS -黒の童話と五魔姫 - 评分: ★★★★☆ 标签: 日本 猎奇 致郁 备注: 7/10 燃尽了,一天没出门的周日。 在 BLACK SOULS 亲手将所有女主做成童话书过了 C 结局之后,准备继续真结局。才发现真结局不需要这么残忍,以至于现在被迫着要跟某人手牵手去打真结局的 BOSS。 这种事情不要啊。 http://www.douban.com/game/35087787/
12·24WED2 posts
最近在好好上班,所以什么都没想叻。
12·22MON1 posts
12·19FRI2 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·17WED1 posts
今年我的年度游戏是 《Elin》今年我的年度游戏是 《Elin》今年我的年度游戏是 《Elin》今年我的年度游戏是 《Elin》今年我的年度游戏是 《Elin》
今年我的年度游戏是 《Elin》。 真的无法想象,作为一个上班族是如何在两个月时间玩 260 小时游戏的。 那两个月什么都没想,全天都在想着 伊尔瓦大陆 (Irva),肯定帮我省了很多钱~ source #steam #elin
12·16TUE2 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