这几天看到太多
太多高德地图的软文
别的不说，阿里的执行力还是拉满了

最喜欢开发说的一句话：你不用管

怎么判断一个英文网站是不是中国人做的？
你就看他接下来10天更新频率是否跟之前一样。
如果大幅度降低更新频率的，大概率是中国人做的。

雷兄表示，自己的小米已经遥遥领苹果，但小米兄自己都是用苹果手机 ⋯⋯

https://mp.weixin.qq.com/s/c5pwiQQqBc9cJzkiHXtkHg

这应该是全网最快更新深度解读的文章。

Anthropic 深夜突然发布 Claude 4.5。

但我读完技术报告和实测后只有一个想法：Claude4.5让我们实现真正“一人公司”的时代，又向前迈出了决定性的一步。

它的编程和自主干活的能力，真的太顶了。

压力给到了Gemini和GPT（据我实测，Gemini3不如Claude4.5）

PS：本帖发布的时候，Gemini的API刚刚挂了，是不是在紧急回炉啊bro🤣

开始搬运小红书的劳动成果到网易小蜜蜂。
作为创作者和产品运营，开始逐渐理解为什么平台需要虚拟用户/机器人账号了，促活。

http://indiehackers.com/products

#高质量外链分享
分享一个超高质量的外链分享

著名社区Indiehackers出的产品launchpad，免费提交，很简单，填下网站信息即可

关于拍照。苹果直出确实很忠于现实，但为什么人们依然会选择调色（滤镜）呢？除了好看，另一个很重要的因素也许是——情绪表达。色彩是情感表达的重要方式，参考电影。

淘宝店开店3个月
白嫖党也是被我遇上了
被气的一晚上没睡好

越来越早……

📈 把网站当成一本书 & 内容产品来做增长的 SEO for AI Website · User Growth Playbook
🙏 因上努力，果上随缘，希望我自己能坚持玩玩写全...
《SEO 相关杂文》自认为最佳到最杂 👇

https://bysocket.com/seo/

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

前情提要，在本系列的第一篇里，我着重提到「组件化思维」以及软件工程的一些基本概念，对于正在尝试 Vibe Coding 的编程小白来说，是必须掌握的思考方式与技能。

这种思维方式与技能，在掌握了之后，当程序运行时遇到 bug，就不会直接把报错复制粘贴过去，而是可以迅速猜到问题产生的地方，从而提高与大模型的沟通效率，也能够节约 token。

良好的结构，是软件开发中立于不败之地的重要前提。

那么问题来了，什么是良好的软件结构？良好的软件结构有什么特点？如何了解自己手上开发的软件是否具备良好的结构？如何学习，让自己具备这种良好软件结构的嗅觉？

*数据流清晰，符合单一原则*

程序它有两个口，一个是入口，一个是出口。入口输入的是数据，出口输出的也是数据。程序的目的，就是为了处理数据，不管是处理 1+1 = 2，还是把字体改为加粗，都是对输入的数据进行处理，然后再输出。

所以，良好的软件结构，在处理数据的时候，会非常清晰，这中间数据从组件 A 到组件 B，再到组件 C，这是一条清晰的路线，不会中间打岔。

每个组件的职责也很清晰，从哪里获得数据，如何处理，输出什么结果——不过一个优秀的组件通常职责是单一的，它只解决一种，甚至是一个问题，绝不大包大揽。

当然对于编程小白而言，直接观察数据的流动是有点难的，因为极大的可能，是连数据的类型都不懂。

我一开始也这样，好像「鬼打墙」一样，同一个 bug 反复出现。当时我完全不懂数据类型，但是我用另外一个方法，让我掌握了数据的流动，那就是观察函数之间的相互调用。

调用这个词看上去很专业，其实理解并不难，就是你复制了一个函数名，然后，在 VSCode 里面全局搜索一遍，看看这个函数名是否会出现其它的函数里。如果出现了，那么证明了这个函数被其它函数调用。

这是一个最简单的方法，让你在完全不具备编程概念，去了解程序里数据流动的一个方法。另外就是，揣摩函数名的意思，LLM 给函数命名一般都很直白，尽管有时候显得啰嗦。

总之，不管是不是编程小白，都不可避免要阅读代码。如果想提高自己的问题解决能力，那就养成习惯，不要一出现问题就马上问 LLM，而是应该先阅读问题产生的代码，看看问题发生的地方。

*以终为始的思考方式*

我不知道你身边是否有那种朋友，他们思维逻辑很清晰，而且总能快人一步发现问题，解决问题的能力也非常强。我身边挺多这种朋友的，经过观察，他们通常都喜欢用「以终为始」的方式去思考问题。

「以终为始」就是，以最终目标出发点，一步步倒推，一直倒推到开始的第一步为止。这种思考通常比较消耗精力，但是只要习惯了，这种思考上的消耗就没什么大不了的。

通常，在开发一个软件之前，我们在一步步倒推的时候，就能够摸出一个清晰的数据路线。我的习惯是，一边倒推一边用执笔写写画画，帮助自己思考。这时候，我会在草稿纸上列出这一次开发想达到的目标，然后我会往下列一个个要达到这个步骤。

实际上，这些步骤，就是我在第一篇里提到的「组件」。第一个步骤要完成什么，然后才能让第二个步骤处理什么，以此类推，很快你得到了一张路线图，也同时得到了一个软件结构图。

而在这个过程中， 如果你发现哪里步骤不清晰，哪里步骤有问题，那都是不好的结构，只要你逐步修正，一个良好的结构就会自然浮出水面。

从任务执行的角度来看待程序，它就是一系列经过设计的，达到目的之前需要完成的步骤。

*多参考优秀项目*

这里涉及一个人的「品位」。大家也知道，「品味」是一种微妙的感觉，你说不出是为什么，但就是「真 TMD 的好！」

如果想让自己在 Vibe Coding 的时候，培养对软件工程的品味，不必每一次都和神出鬼没的 bug 玩捉迷藏，我们可以直接参考优秀的项目，看看它们是怎么做的。

我说的参考，不是打开一个 Github 仓库，然后看看里面的分别有什么文件就算完事了，而是要深入到代码层。就好像我刚才说的， 直接全局检索函数名，然后看看它都出现在哪里。

而且现在有 LLM 以及 DeepWiki 还有 zread 等工具，都可以直接解读一个 Github 仓库里的代码之间的关系和结构。

不过我还推荐我的做法，直接将一个仓库 Clone 到硬盘，然后启动 Gemini CLI，输入一句：这个项目是干什么的？它的结构是什么？

然后，你就等着这位赛博菩萨吭哧吭哧地帮你整理出一个优秀的文档来，这个项目是干嘛的， 有什么组件，每个组件是干嘛的，罗列得很清楚。然后按照这份地图，打开对应的文件，参观里面的代码，看看别人是怎么写的。

多读代码，多读别人的，多读自己的，然后对比一下。书读多了，其义自现。

只做你专属的 biz card ！名牌来了！

nano 垫图，加下面 prompt 即可，还可以随意改颜色各种：

name 改成 CoderJeffLee
title 改成 Growth Indie Hacker
email 改成 xxx
link 改成 xxx

终于看了原文，听完一周之后再看一遍这种方式真的很好。读完觉得怎么会有morality如此完备之人…既沉着又热情，务实又浪漫。也许最好的科研者都如此，As 李飞飞。

也让我想到今天在《拯救大兵瑞恩》那篇文章里读到“狙击手最重要的素质是冷静”，那么喜欢这个行业的人也差不多，also a war。他是提出别再打榜了的那个人。

有趣的是忽略了environment的偏误和当初ImageNet时何其相似？

另外也读了一下The Second Half原文，尽管原文多了一些展开的技术解释，但我觉得整体并不如这篇采访有深度。核心技术思考如“通用”和“环境”、“reward”都讲到了，并且文章中更深刻。惊喜是觉得姚对于人类社会经济、组织结构，有许多敏锐的思考。

做产品，如果一味听从用户建议，结果就是死路一条。

今年陆续做了一些产品，有些反馈还可以。

不少用户在使用过程中，会提出自己的一些建议。

今天就想聊聊用户自己提的需求，哪些用户需求要满足，哪些用户需求不能满足。

首先是一个大宗旨，用户提的需求是很有参考意义的，但是不能一味去满足，不要因为用户提了需求，就打断了自己的迭代节奏。

其实这个表面上看是需求的取舍，本质上是对用户群体的取舍。

一款产品不可能做到满足所有用户的需求，如果能做到，那这个产品一定活不下来。

其实有两个极端的例子：

MIUI最初确实听从用户建议，所以用户也非常乐意在论坛里提出自己的想法，官方响应用户建议很快。

但是后来越来越臃肿，导致现在的口碑很差，甚至有点反噬了。

微信则是另一个极端，不管用户骂成什么样，都不改，但是不妨碍大家都还是用微信。

所以这里一定是有一个界限的，什么情况下应该听用户的，什么情况下不应该听用户的。

我个人总结了3个标准，当然只是现在一点浅显的看法，未来可能会变：

第一个标准：是否符合产品的核心定位。

如果一个需求和你的产品定位、愿景、长期方向高度契合，那就值得优先考虑。

否则，哪怕用户提得再多、声音再大，也不要轻易动摇。

否则产品容易变得四不像，既无法满足核心用户，也留不住泛用户。

第二个标准：需求的普适性和代表性。

有些用户的反馈其实非常个性化，只是为了解决自己的某个特殊场景。

这类需求要谨慎评估。

第三个标准：实现成本和收益比。

有的需求听起来很棒，甚至你自己也心动，但如果实现起来需要投入大量资源，就可以先加到 Todo List 里。

所以本质上来说，做产品不是无条件迎合，而是找到属于你的那部分用户，把产品打磨得更极致、更有辨识度。

用户的建议一定要听，但不能全听，更不能一听就做。