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

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

1. 随机事项:每月为自己安排一些有趣的活动。(大概率🐦🤣
2. 同步内容:我会收集在其他平台上发布的内容。
3. 私人笔记:没经大脑的学习笔记以及一些个人随想。
4. ACG 内容:浓度高的部份还是挪到 另外一个频道 @tomoko_acg
5. 内容转发:在这个频道上转发的内容并不必然代表我个人的立场。
🔖 Deep Dive into LLMs like ChatGPT - YouTube #pinboard #llm

最近终于抽空看完了这 3.5 小时的视频,虽说是一年前的视频,但这些内容都完全没有过时。

我觉得软件开发者都应该全程无加速看完。因为用 AI 开发时会踩到不少坑,虽然不必钻 AI 底层原理,但根据「抽象泄漏定律」,了解必要的原理能让我们更懂 AI(比如能预判什么事是在「强 AI 所难」)。

目前为止对大模型原理的最佳介绍,这就是世界级专家的水平,知道介绍什么,知道在什么抽象层次介绍, 不会让不懂的人陷入毫无意义的细节,对重要概念的理解又不会缺失,实在是太精彩了。


https://www.youtube.com/watch?v=7xTGNNLPyMI&t=3s
Agent Teams 的生产流水线~

Agent-area 已完成 Pages 7-9 (tasks 9.A-11.F),正在空闲。让我看看它是否卡在了什么地方,然后推动它继续。


#llm
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
🔖 Vibe engineering #pinboard #llm

当 AI 承担了 90% 的 "打字" 工作后,剩下的 10% 人类工作(架构设计、代码审查、质量把控、问责)反而变得更重要、更难、要求更高。

我也逐渐理解 HA reviewer 那边为什么设置这么多道机器人 check,linter 都基本开满,每一个都是为了减少 reviewer 的负担

https://simonwillison.net/2025/Oct/7/vibe-engineering/
🔖 AI 对这段代码的工作原理有深入的理解 | AI has a deep understanding of how this code works | Hacker News #pinboard #llm

关于「情绪超级稳定的社群 Reviewer 遇到热情的外行用户在 LLM 的协助下给你创建了一个 13K 行的 PR 」时产生出来的化学反应。真让人哭笑不得😂

想想我 HA 插件的 4000 行代码,我给的预期是半年分 20 个 PR 来提交,真的是… (但凡有一行代码 Reviewer 有点疑惑都要解释半天什么的)

感觉是一个非常里程碑的事件,而且类似事情估计还会越来越多,甚至各种各样的场景下都会发生。LLM 不会带来平权是真的,能力不足的话,甚至没法意识到「这是一件很糟糕的事情」。

不过这句评论也是够灵魂拷问的:

If a manager says they provided oversight of their developer employees, and the code was not as good as the manager thought, would you say "the manager has had their brain broken by the existence of employees"?

如果一位经理声称他们监督了开发员工的工作,而代码质量并不像经理所想的那样好,你会说 "这位经理因为员工的存在而脑子坏了" 吗?


https://news.ycombinator.com/item?id=46039274
🔖 一个半月高强度 Claude Code 使用后感受 | OneV's Den #pinboard #llm #claude

一般不是非常确定的需求我也是更倾向于「小步迭代」的方案,不然「放飞自我」之后的代码要 review 到吐。


我见过的使用方式大致分两派。一派是 “小步快跑”:每次只让 AI 完成一个小功能,验证没问题后再进行下一步。另一派是 “一步到位”:直接把整个需求扔给 AI,让它一次性生成所有代码。更极端的,还有人会开启 --dangerously-skip-permissions 模式(也就是所谓的 yolo 模式),让 AI 可以不经确认就执行任何操作。


感觉可以作为简单的安利文,身边太多朋友都是那种「啊,这个要钱啊,那就不用了。等有需要再开」。What can I say ?

四舍五入,我去建一个 skill 仓库趴。

https://onevcat.com/2025/08/claude-code/
🔖 借助 Skills 提升前端设计 | Claude | 宝玉的分享 #pinboard #llm

你可能注意到了,如果你让一个大语言模型 (LLM) 随便搭个网页(行话叫“落地页”),它十有八九会给你一套“标配”:Inter 字体、白底配紫色渐变,外加一点点可有可无的动画。


https://baoyu.io/translations/improving-frontend-design-through-skills 借助 Skills 提升前端设计 | Claude
 
 
Back to Top