【面试日记】
今天的面试官是研发的负责人，问我《大而全、小而美，这两种产品的宣发思路有什么不同？》

我听完一愣，这个问题好像当年考研的最后一道大题。写给小论文了都可以

没太理解啊，“扫街榜”就不能刷吗？地推团队要复兴了吧。

其实除了外链，用户在站内停留时长也是非常重要

我自己有个站点，外链是竟对的两倍有余，但是他停留时长是我的2倍，所以他排名比我高

他做了什么呢？ 他有免费使用功能，而且无需登录，不限次数使用。

所以我今天也开始模仿他，希望1-2个月后排名能超越他

新人乱拳打死老师傅，
原因在于新人没有老师傅那么多经验，
于是老师傅根据经验判断不能做的事情，
新人不信邪，去做了，然后就拿到结果了。

很多时候我们做不成某些事情，
原因都是这样，因为我们判断做不了，
但其实，真如做了，就会发现，能做，
所以，我觉得想要成功，最重要的是，
去做。

越来越多收到这样的反馈，真的欣慰！

这位是狮途会的一位会员，自己本身就是以超级个体模式，做起来的，经验挺丰富的，公司成立的时间比我们更长。交付了很多大企业，也经常在外面做培训上课。

获客、产品、交付、案例...这些对他们都非常重要，但之前的思考没那么系统，或者有卡点但不知道原因是什么。

没想到从我的这个系列文章里，找到了几个关键点，总结的很好：

1、我提出了BC自营一体化的模式，核心就是B端和C端互为促进赋能的关系。对他来说，做好BC整合就更聚焦，不再是两条线分开做。

2、交付抽象，不够具体。这个就是我最近最大的感受，就是确定性交付。所以我才把狮途会里，和我咨询改为不限次数，课程的更新、线下沙龙的次数等，都要有明确的数字。

3、IP的稳定输出。做IP反馈周期是长的，见效是慢的。今天成交的客户，很可能是半年前开始，就在看你的内容，只是遇到的比较好的节点才下单。

4、成功案例解析，反哺前端获客。案例要如何呈现，是有目的的。让客户觉得，这个案例和自己相似，能学的来，甚至感觉：就他这样的都行，我肯定更行。

这四点正是我们在反复强调的经验，但不止于此，我们会持续做好迭代，提供真正“有价值的交付”。让假大空的东西，都去死吧。

如果你对我们的内容感兴趣，可以在我公众号去阅读#韩叙HanXu

要有深入的交流，有问题要解决，可以参考#狮途会 这个产品。

用了几天codex，用的cursor插件跟cursor的claude左右互搏

总体用下来跟claude还是有差距，理解能力差得比较多，一个需求要讲得很细，或者反复调试才能达到想要的效果

唯一强的地方是从来不会报错，也没有用量焦虑，cursor跑几下就报一下error，context长了或者对话放久了没回就来个超时，很烦人

《写给编程小白看的 Vibe Debugging 注意事项（1） 》

我认为我有资格谈论这个问题：

我在 Githuh 已经有 2 个超过 100 星标的开源项目。

截止文章开始写的时候，一个 267，一个 105。考虑到 Github 上绝大部分项目不超过 10 个星标，我的成绩自然是在水平线之上。

除了这 2 个破百星标的项目之外，我还有好几个 50 个星标的项目，一些 20 个星标的项目。

自从我 Vibe Coding 到现在，我一共开发了 12 个项目。没有一个项目低于 10 个星标。其中 2 个项目起码经历了大规模重构（几乎完全重写）。

*为什么标题不是 Vibe Coding 而是 Vibe Debugging？*

如果从生物学分类来看，Bug 是克鲁苏——不可名状，永恒存在，令人恐惧。

小白 Vibe Coding 到最后往往变成 Vibe Debugging，拼命打印调试日志，然后塞给大模型，祈求它这把能过。

抑或，在 Vibe Coding 爽撸一把之后，祈祷这把不会有 Bug。然而克鲁苏就是克鲁苏，Bug 不会因为你的诚意感天动地，就自动消失。曾经有科学家开玩笑， Bug 是唯一违反物理定律的东西，因为即便太阳系毁灭了，Bug 也会继续存在。

所以，我们在谈论小白 Vibe Coding 的时候，也是在讲 Vibe Debugging——请所有小白在尝试 Vibe Coding 之前，一定要清醒的明白一件事，很多时候你不是在编程，你只是在制造你无法解决的 Bug。这是我非常痛的领悟。

*想要减少 Bug 的出现，必须懂点软件工程*

小白之所以无法控制 Bug 的产生，我觉得原因和会不会编程语言的关系不大。

就我潜伏在 V2EX（中文最大的程序员线上社区）里观察，即使懂得编程语言，同样闯祸，很多时候还是一口大锅，搞得身边的同事恨不得给这种惹事精做开颅手术，瞧瞧脑袋里装的是啥。

就我的 Vibe Coding 经验而言，真正令 Bug 减少的，是软件工程里的常识。也是让我觉得 Vibe Coding 时，不再害怕 Bug 出现的关键飞跃。

Vibe Coding 领域的流行理论，从单纯的 Prompting 到 Context Prompting 再到现在的 Spec Programming，在我看来是毫不回头地朝着软件工程化的方向狂奔。

所以，你还觉得不必了解一点软件工程吗？

*想懂点软件工程，必须先拥有「组件化思维」*

想知道 Bug 发生在哪里，为什么发生，固然是可以将日志直接塞给大模型——这是 Vibe Coding 的标准做法。

但，难免会碰上大模型怎么改都改不好的克鲁苏级 Bug 出现。排查 Bug 的流程，首先肯定是定位问题。

此时，拥有组件化思维的小白，会尚未拥有的小白，差距会十分明显。因为，前者通过脑子里清晰的结构，很快地定位到问题发生的那一段代码，以及它的相关因素。而后者，往往只能看到一个函数报错，但他只能重复地把错误日志塞给大模型。

克鲁苏级 Bug 无法马上消灭，往往就藏在这个「相关因素」里。缺乏组件化思维，脑子里就缺了一张地图，无法找出这些个「相关因素」，那么，更不要说排查 Bug 了。这整个过程就好像排雷，雷通常是藏起来的，如果想全排除，只能用扫雷车一个地面都不放过地筛，但是如果连埋雷的地方都不知道，就谈不上排雷这件事了。

现在，问题来了，如何拥有「组件化思维」呢？别急，往下看。

*想懂「组件化思维」，必须了解基础概念「抽象*」

我们通常接触到「抽象」这个词，往往和「抽象思维」这个词组密不可分。抽象思维，说的是迅速寻找事物的共性，总结特征。

在计算机领域里，「抽象」也类似的含义，因为组件往往是由普通的代码抽象而来的，而这个抽象的过程，往往是因为代码当中存在着大量的重复。这些重复的部分，可以抽象成公共组件，为其它组件提供服务。

还有另外一种抽象，是明确代码的边界，比如说，这几个函数是为同一个目的服务的，那么它们只需要面向这个目的进行设计即可。你可以认为，软件其实是一个流水线，这个流水线由不同的工序组成，从原材料放进传送带开始，一直到变成成品从传送带离开，每一道工序都负责加工上一道工序所传递过来的半成品——在软件里，工厂流水线里每一道独立工序都可以视为「组件」。

实际上，现在的 Spec Programming 也不过是进化到，将软件里的所有组件也说清楚给大模型听，然后让大模型生成代码。

换言之，如果你有能力在文档里描述不同的组件的作用，以及它们相互之间的关系，如何配合，那么你已经具备 Spec Programming 的能力。

在设计组件的时候，软件开发领域的「DRY 原则」显得尤为重要，它有点像麦肯锡金字塔原理的「不重不漏」原则。每个组件必然不是重复的，而要让它们有机地写作，那么又缺一不可。

*请期待下一篇*

这一篇我已经说清楚非常基本的概念，这些概念对于小白来说是不可或缺的，必须掌握的背景知识。在这里我十分推荐《软件设计的哲学》这本书，它不长，但更好覆盖了必须了解的常识。

平台之间还是非常不开放
做了个小程序产品
在小红书上做 marketing，搞得像微商一样，各种暗号 谐音，只为了告诉对方在微信上搜 xxx。

拉里·埃里森成为新首富了，罕见的，他和乔布斯、马斯克都是好朋友。甲骨文都快50年历史了，还可以一晚上几千亿美金涨幅，美股科技老巨头的动能真强啊。这三位也都证明了，一个离经叛道的人，同样可以创造和操盘地球上最牛的公司。

Spotify 终于把「无损音频」上线！

等了八年，Premium 用户可享，无需额外付费，未来两个月会逐步覆盖 50 个市场，首批包括美、英、日、澳等地。
最高支持 24 位 / 44.1kHz FLAC，虽然规格不及 Apple Music 和 Tidal，但至少补上了音质短板。
有趣的是，到目前为止，YouTube 已成唯一还不支持无损传输的主流音乐流媒体平台。

原文🔗https://newsroom.spotify.com/2025-09-10/lossless-listening-arrives-on-spotify-premium-with-a-richer-more-detailed-listening-experience/

自己做客服以后才知道：不需要客户太礼貌😂
因为客服必须句句有回应，不能让消费者做话题终结者。

新词新站来了咯