2026-08-29

v 友们，我在湖北的一个小县城买了一套房子，一直没住，所以我也没交物业费，然后物业起诉我了，九月十号开庭，但是还没开庭，我有一笔定期存在银行里，然后法院直接给我冻结了，这合法吗？没有任何通知我，直接冻结我的钱，关键是还没开庭呢。

孙割是顶级掠食者，他说的每句话做的每件事前，都是计算好了成本和收益的。
孙割说的每一千个字，最多只有 2 个字是真的.
这次小作文，唯一能证实的就是：
孙割花钱 P 了景田几次。
什么白月光/老照片这些话你真的能信孙割？
现在的孙割，要的是话题是流量，几千万对他来说就是炒作成本。
孙割要的是：
巨大的话题流量继续红+再拉一波盘割一次+感受到川普家族对他的威胁需要热度保命+给自己立一个痴情种人设+等着傻子们帮他冲+最好几千万还能要回来白嫖
你看，再割一波+热度保命 才是最重要的，白嫖都是排最后的。顶级掠食者是我全都要。
能将人性随意玩弄操控的，上一个集大成者还是 PDD 黄峥吧。
一个是随意全球收割韭菜，一个是靠拿捏人性扭转中国电商生态格局。

之前交易都没关注过，感觉比例还是挺高的

纯软件很难建立起优势了，包括个人和企业

面试的时候还会问八股文吗？是不是更看重学历背景了？性格好，擅于言辞的人是不是更容易面试成功？

在本文中，「生产力」的定义是：单位时间内产出的商品数量。

生产力的提高，意味着一个工人在一定时间内可产出更多商品。

推论：生产力的提高不是工作岗位增加的直接原因。

推理过程很简单：

原来 1 个工人在 1 小时内产出 10 件商品。生产力提高后，1 个工人在 1 个小时内产出 100 件商品。也就是说，如果原来需要 10 个工人，则现在只需要 1 个工人。显然，工作岗位并未因生产力的提高而增加，反而减少。

但是，为什么随着生产力的提高，全社会的工作岗位明显增加呢？这是一个错误认知。两个事件先后发生，不代表二者有因果关系。

工作岗位的增加，是因为需求增加。假设全社会从需要 10 件商品变成需要 100 件商品，那么即使生产力保持不变，工作岗位也会增加。

单位时间的生产力	需求	工作岗位
1 个工人产出 1 件商品	10 件商品	10 个工人
1 个工人产出 1 件商品	100 件商品	100 个工人
1 个工人产出 10 件商品	100 件商品	10 个工人
1 个工人产出 5 件商品	100 件商品	20 个工人

如上表所示，即使生产力保持不变，只要需求增加，工作岗位就会增加。只有当生产力的提升速度追不上需求的增速，工作岗位才会增加。仔细观察上表的数字变化，不难发现，需求的增加才是工作岗位增加的直接原因。

生产力的提升不会直接增加工作岗位，且如果生产力的提升速度能追上、甚至超过需求的增速时，还会导致工作岗位减少，那么为什么人类的生产力不断高速提升，工作岗位依然能不断增加呢？

真相只有一个：生产力的增速，追不上需求的增速。

这很自然会产生下一个问题，人类的需求的增速为什么那么快？

三个主要原因：1.人口，2.欲望，3.社交压力。

全球人口的增加有目共睹，而每增加一个人，衣食住行的需求自然增加。

人的欲望也没有止境，从一条村需要一台固定电话，到每个家庭需要一台固定电话，到每个人需要一台诺基亚，到每个人需要一台最新款的智能手机，再到一部分人有了智能手机还不够还要充电宝、还要 iPad 、还要笔记本电脑、还要台式机和大屏幕、还要人体工学座椅…… 衣食住行和娱乐等等，各方面也类似，欲望的增长非常可观。

社交压力也很好理解，如果你的朋友都爱买电子产品、爱看演唱会、爱旅游、爱摄影、爱打游戏、爱美食…… 你不消费就无法融入社会，无法交朋友。排除少数特殊案例，多数人都是群居动物，人在江湖身不由己，社交压力对消费的促进作用也非常巨大。

综上所述，我有一个大胆的猜想：人类需求的增速，永远大于生产力的提升速度。

就算 AI 继续发展，仍然追不上人类需求的增速。而我们一开始就已经论证了工作岗位增加的真正原因就是需求的增加。由此得证：AI 的发展不会导致社会总体工作岗位减少。

网站是https://stock-island.com/ 做这个 App 的原因其实挺简单的。 我平时工作的时候，偶尔会想快速看一眼自己关注的股票。以前一般是掏出手机看，或者打开同花顺、券商客户端之类的 App 。 但为了确认一个价格，专门拿出手机有点打断工作。电脑上的券商客户端功能又比较重，打开后整个界面都是行情和交易内容，旁边的同事一眼就能看出来你正在关注股票。 所以我当时想，能不能做一个存在感低一点的行情工具：平时不用打开完整窗口，需要的时候只看一眼，看完继续工作。 一开始也考虑过放在菜单栏里，不过我的菜单栏本身已经有很多图标了。东西一多，不仅显得拥挤，每次还要找到图标再点开，感觉并没有方便多少。 看到了 vibeisland.app 这个项目后，给了我灵感。哈哈哈哈～～ 目前上架了海外地区，国内需要备案，太麻烦了，暂时没准备上架。 感兴趣的朋友可以给我留言，可以给 App 促销代码

更新一下进度,给等上架的朋友一个交代。

这个 app 从 8 月 12 号第一次提审到现在,经历了三轮:

第一轮:Guideline 1.2(用户生成内容)拒审。 理由是论坛类 app 必须有内容治理。于是我加了一整套:首次启动条款确认、每条话题和回复都可举报、可屏蔽用户和关键词,举报会在 24 小时内核实处理。8 月 26 号重新提交。

第二轮:2.1 信息问询。 问 Personal Access Token 在哪创建、要不要付费、解锁什么内容——本质是怀疑绕内购。我如实回复:token 在 v2ex.com 设置里免费创建,纯认证用途,app 免费、无广告、无内购。当天重新排队。

第三轮:昨天深夜等来结果,4.3(a) Spam 。 大意是这个 app 和商店里已有的 app 概念雷同、只有细微差别。翻译一下:已经有别的 V2EX 客户端了,你这个算垃圾应用。

说实话有点哭笑不得。代码是我从零一行行写的,SwiftUI + iOS 26 原生 Liquid Glass,整个仓库公开在 GitHub,不收一分钱。TestFlight 里 78 位朋友在用,是大家催上架我才去提审的,结果折腾三轮,得到一个 "spam"。

今天已经提交申诉,开源仓库和 TestFlight 的数据都摆给他们了,也表了态:如果 App Store 真容不下,那就算了。

所以这是最后一次尝试:申诉过了就上架;再不过,项目就留在开源社区,GitHub 继续更新,不再折腾审核了。

感谢每一位测试和催更的朋友。

仓库:https://github.com/xinghelee/v2ex

在被苹果审核教育一番之后以及 V 友的邀请之下做了安卓版本

1. Kotlin + Jetpack Compose 全原生构建
2. 凭据加密存储（ Android Keystore + EncryptedSharedPreferences ）
3. 支持折叠屏，内外屏无缝切换
4. 站内完成全部互动 —— 回复、发帖、收藏，@ 补全、通知直达
5. 分享为卡片 —— 一键生成带二维码的话题图片卡

GitHub：https://github.com/xinghelee/v2ex-android

GitHub：https://github.com/xinghelee/v2ex-android

如题

之前一直用 claude code ，但是集团排查禁止使用了，只能寻找国内平替，目前看了 qoder cli 和 codebuddy cli ，感觉两者都没有太明显的优劣势。有用过的同学说说体验么？

ps：公司不给 codeplan ，但是给了些 ds 的额度，所以只能选择接 ds 进行使用。主要考虑 Java 软件开发方向。 平时用的 IDEA 比较多，目前不太想直接从 IDEA 转到他们的 IDE 版，所以还是优先考虑 CLI 版本

今天公司想新采购一些数据库和服务器。于是去找了各个代理或者阿里云售前。

其中一个报价大概在 7-8 折， 但是另外一个报价惊呆我了

只有 2 折多一点

不过说的是必须先关联他们的企业，后期交易自行在后台操作，不再经过他们

想问下这种异常低的价格，然后又说在阿里云官方后台操作的 ，有什么坑么？ （当然大概率不会选择这个，因为便宜的不太正常）

配合 AI 使用，AI debug 经常要重启硬件。所以需要搞一个支持命令行操作开和关的电源，市面上有吗？

之前主要是使用 PHP/Python 做业务系统开发, 比较习惯 Doctrine, Eloquent, SQLAlchemy 这类 ORM 的模式

Load Entity
    ↓
修改对象属性
    ↓
ORM 检测变更
    ↓
只 UPDATE 发生变化的字段

比如:

$order = Order::find(1);
$order->paid($time);
$order->save();

$order = $entityManager->find(Order::class, 1);
$order->paid($time);
$entityManager->flush();

业务代码只需要表达业务数据变成了什么样, 至于那些字段有变化, 最终那些数据被保存到数据库中, 是由 ORM 的 dirty tracking/Unit of Work 负责.

但是最近再写 Go 的时候, 感觉主流的方式更偏向于显式更新

db.Update(ctx, id, map[string]any{
    "paid_at": "xxxx",
    "paid": 1,
})

或者

db.Model(&order).Update(ctx, id, Order{
    PaidAt: "xxxx",
    Paid: 1,
})

简单的场景来说, 还比较清晰, 那么对一个比较复杂的场景来说, 变化的字段比较多的时候, 而且想实现类型安全的时候是不是不太容易.

目前我使用的几种方案:

1. 每次都全量更新, 不管更新了几个字段, 每次都全部刷新到数据库里
2. 业务层面整理好需要更新的字段,通过 map[string]any 方式更新

我想听听大家的意见, 跟大家学习学习

https://pollen-robotics.com/microduck/

看着挺有意思，想买一个玩玩，有没有团的（本人没有海外购物的经验）？