2026年4月

Notion 的优缺点

Notion 的门槛在于,当一个页面被创建,在 Notion 的整套叙事里,你需要尽快为这个页面找到它在系统中的位置和关系,它是什么、属于哪里、是否和某个具体的任务或项目有关系?

尽管你可以从一页白纸开始写完所有东西,但 Notion 的强大亦是一种约束,它会把你往系统构建的方向牵引,因此你总是会感受到一种来源于「必须将信息妥善安置」的压力。

但 Notion 的易用也在于此,因为它的笔记有更明确的状态、关系、权限和操作边界,这种结构化的信息分类让你可以更快地把目标转化为行动,把知识转化为可复用的对象,或者在协作场景中成为团队的共同标准。

因此你可以在 Notion 里轻易搭出一个 CRM、项目看板或者内容日历,这些 Notion 一贯标榜「可以让每个人创建属于自己的软件」的宣传,本质上都是对同一份结构化的数据做不同维度的排列组合。

从结果来看 Notion 的确实现了「LEGO for Software」的自我定位,至少我认为在目前市面上能做到的仅此一家。

Obsidian 的优缺点

Obsidian 的易用则在于,一条笔记可以先只是笔记本身,记录可以先于分类,拥有可以先于系统,它不要求你一开始就精准地判断这条信息是任务、项目、资料还是成果。

简易的文件夹结构就可以支撑起大部分的分类叙事,创建出链和入链的成本极低,大致的存放位置加上少量的标签,就足以让它先进入你的知识系统,因此 Obsidian 更擅长承载长期阅读、概念孵化和研究写作等需求

因为思想或者灵感需要不确定性、需要模糊、需要反复命名、或者保留未来重新解释的机会,这是 Obsidian 所能塑造的氛围,并且它保证不把这段文本锁死在自己的应用里,所以你总能期待这段文本在未来还能有更多的可能性。

但 Ob 的门槛也在于此,基于 Markdown 文件构建的系统,只能依赖文本之间的约定去呈现或者模拟结构化的关系,一旦开始使用 Properties 给笔记加字段、用 Bases 做类似数据库的视图、或者引入自定义主题来改变界面逻辑,Obsidian 就会陷入另一种折腾的漩涡。

社区插件的引入更意味着复杂度的无序提升,官方将编排信息的权利和义务交给了个人和生态,甚至插件的安全性也不可能得到全面的审查,这既是自由也是成本,你以为你全权拥有了所有的本地文件,但未必能真正拥有和掌握,围绕这个系统所生长出来的复杂关系

Obsidian 其实也是在简单的 Markdown 上不断垒砖块,不兼容的语法也是你不得不品的一环。

在这里,产品所营造的「氛围感」仍然重要,它决定了你的每次输入是倾向于结构化的表达,还是倾向于在一张白纸上更写意地将脑子里的东西随意泼洒。

只不过继续逐项对比谁能搭建出更强大的系统、谁的关联更好用、谁的第三方工具更丰富、谁的数据迁移更便利,或者是谁能调用的模型更强大,可能不是一件很有讨论价值的事,因为大家本就面向不同人群、既各有长短也都在取长补短,过于深究某一个功能只会让结论流于表面

当 AI 开始替你动手

AI 的加入将逐渐抹平两款产品在写作、搜索、总结和文档等表面能力上的差异,而且当 AI 不只是一问一答,也开始替你增删改查的时候,双方如何在系统层面定义操作对象之间的关系、如何确定每一次 AI 操作的权限边界,才会带来更大的体验差别。

一个明确带着状态、优先级、负责人、截止日期的任务对象,可以被 Agent 精确地筛选、更新、或分配目标,而一段只包含 #task 标签的纯文本,Agent 能做的更多是搜索、以及根据意图进行模糊或者发散的思考,两者在被自动化调用时所产生的效果很难一致。

因此我们可以从一种相对暧昧的角度来下结论,Notion 的 AI 更能达成目的,Obsidian 的 AI 更能与你共鸣,至少现阶段是如此。

所以,当 AI 逐渐成为第一生产力,我们过去为了提高「提取的效率」而精心组织的笔记系统,是否还有那么重要?当未来的你再次需要某个想法时,AI 重新生成一份笔记的质量,也许并不会比你翻找十年前的那条 Markdown 更差。

过去我们引以为傲的自由意志、写进笔记的真实思考、或者所谓「能让自己更好地认识自己」的活人感日记,在智能涌现的 AI 面前,还会有那么高的价值吗?我其实对此怀着悲观的态度。

如果 AI 强到某种程度,Obsidian 所珍视的长期可读,Notion 所追求的结构化调用,双方的努力在未来一定会需要被重新评估。

此刻的答案仍然重要

不过幸好至少在今天,AI 还没有强到让信息架构变得完全多余,你的笔记系统仍然是你和 AI 协作的基础设施,所以我们依然还需要再花点时间认真纠结到底选谁更好。

只是在 AI 模型两周一小更、两月一大更的频次下,你不必追求一个能够支撑十年的决定,想清楚此时此刻,最远 1 年内要解决什么问题,就足够让你做出一个好的选择

也就是说,如果一条信息被写下来之后,需要更快地进入具体的工作流和协作中,那么 Notion 具备比 Obsidian 更大的优势,AI 会让你获得更精准的执行结果。但 Notion 的风险是过早的定义,你可能会在想法还没有成熟时,就急着给它分类、加字段、套流程,最后很容易为了维护而维护,并且糟糕的 Notion 系统只会制造更深的路径和更精致的混乱

如果一条信息更看重长期保存、反复联想、慢慢孕育、或者等待未来某个时刻被重新理解,那么 Obsidian 更适配这个需求,AI 会给你更多意料之外的惊喜。但 Obsidian 的风险是延迟整理,并且结构化的信息需要用文本和第三方的插件去约束,你在前期获得的自由,后期可能会以命名混乱、链接松散、插件失效的形式还回来。

在 AI 上下文普遍还锁定在 200K 到 1M 的这个空间下,你暂时还不能指望 AI 对你的系统有全知的理解。

至少目前越是想让 AI 参与执行,越需要系统提前界定清晰的身份、状态、关系和权限的边界,就像 OpenClaw 里必须精心维护的 SOUL、AGENT、USER 或者 MEMORY 文档一样,更长的上下文还不能替代信息结构本身

分歧和选择

所以可以设想两种人,一种是同时在推进三到五件事的项目型工作者,可能是自由职业者、小团队主理人、或者某个部门的负责人。

他每周要在客户需求、内容排期、账款追踪、素材库和团队沟通之间反复切换,他最怕的是某件事被漏掉、某个状态没更新、某个承诺没追踪,他需要的是信息尽快获得来源和去向,好让注意力从「记住一切」里解放出来

另一种是正在写一本书或做长期研究的创作者,他每天读几十页文献、冒出几十个联想,其中大部分不会立刻有用,但某一些会在两年后的某个深夜和另一段材料突然共振,他最怕的是一个还没成型的想法被过早划分到某个分类里,然后再也不见

在我看来,前者适合 Notion,后者适合 Obsidian。

  • Notion 相信,信息的价值来自它进入系统之后能被如何协调和执行,因此在一条信息被写下之后,需要尽快为它命名和归类
  • Obsidian 相信,信息的价值来自它脱离某个具体系统之后,仍然能够如何存在,因此它更倾向于让信息先保留为文本

所以选择 Notion 还是选择 Obsidian,真正的分歧在于,当有了 AI 能力的加持后,你想让知识优先成为行动系统的一部分,还是优先保持为可重新组织和解释的思想文本?终有一天你会不再需要二选一,但至少在现阶段你依然需要考虑,你更愿意在哪个阶段付出整理信息的成本?

你愿意在前期承受定义信息的压力,换取后期更清晰的调用、协作和执行;还是愿意接受后期可能出现的命名、整理、和维护的延迟混乱,去换取前期更灵活、更能触类旁通的笔记体验?

你此刻更缺的是轻盈的、不想过早整理的自由,还是繁复的、能把想法更快推进为行动的秩序

双方所能构建的世界都过于庞大、所能赋予的想象空间都很美妙,因此你很难「我全都要」,如果非要二选一,你只需凭你的直觉回答上面的问题就能找到答案。

当然这个答案的保质期肯定不会太长,但能怎么办呢?不要想太远,也可以根本不用想,再给 AI 一些时间,或许你的问题就不再需要答案了。

> 专为知识工作者打造的全能 Notion 模版:FLO.W 思流 📒

> 更多实用、好用的 正版软件,少数派为你呈现 🚀

    都说「人间四月鲜,尝鲜好时节」,说的不仅是各种时令蔬菜上市了,还有经过了一个冬季蛰伏后,开始出现在了菜市场海鲜档口的海鲜与河鲜。虽说现如今,随着时代的发展和科技的进步,我们的人工养殖水平已经日益见长, ...


    都说「人间四月鲜,尝鲜好时节」,说的不仅是各种时令蔬菜上市了,还有经过了一个冬季蛰伏后,开始出现在了菜市场海鲜档口的海鲜与河鲜。虽说现如今,随着时代的发展和科技的进步,我们的人工养殖水平已经日益见长,可是比较之后,那些时令季节的海鲜与河鲜,总是更美味些。

    自诩「海鲜小杀手」的我,今天打算向大家分享几道我特别喜欢购买的食材,绝大多数都是以保留食材本身的原味出发烹饪,所以不仅品尝起来美味无负担,处理起来也非常简单~

    鲫鱼

    清蒸小鲫鱼

    食材:土鲫鱼、生姜

    调味:食用盐

    步骤:

    1. 将小鲫鱼去鳞、除去不能吃的内脏(如果有鱼泡和鱼籽,可以一起清蒸),然后正反面划上几道。姜切成丝。

    2. 将处理好的小鲫鱼放进盘子中,均匀撒上一层薄薄的食用盐,撒上姜丝,水开上汽清蒸 12 分钟。

    3. 待鲫鱼马上清蒸完毕,把烧到滚烫的猪油淋到鲫鱼上即可。

    对于我的初中时代,有一点我印象特别深刻,那就是每晚的餐桌上,一定会有一条鲫鱼。鲫鱼豆腐汤、清蒸鲫鱼、葱油鲫鱼,是我父亲最常制作的三种方式。鲫鱼不受季节的限制,平时也总能吃到,但是到了春季的时候,我偶尔会在菜市上买到小鲫鱼或者土鲫鱼。

    是否是正宗的野生鲫鱼,我无法用肉眼判断,毕竟土鲫鱼可以去乡下的河流里捕捞(我身为钓鱼佬的小舅舅就特别喜欢大半夜去捞鱼),还有一些则是通过自由放养的方式。这种个头更为小巧的土鲫鱼,吃起来非常鲜嫩。因为是新鲜的食材,所以只要撒上一层薄盐清蒸,就足够美味。

    鼓虾

    椒盐鼓虾

    食材:鼓虾、生姜

    调味:生抽、椒盐粉

    步骤:

    1. 起锅,等待锅热的过程迅速把姜切成姜丝,待锅烧热(如果是铁锅的话)加入较多的油,待油温升高后加入姜丝,炒出姜的香味之后加入鼓虾爆炒。

    2. 爆炒大概 2 分钟后,待鼓虾颜色变红,沿着锅边淋一圈米酒或料酒,再淋大概小半圈生抽,再翻炒一下炒出酱香味,关火,撒上椒盐粉即可。

    鼓虾又叫嘎巴虾,个头虽然不大,但肉质却非常鲜甜 Q 弹,和身体相比更「健硕」的虾钳里,也藏着「苍蝇肉」一般的珍贵虾肉,用嘴一咬,也能吃到肉。

    因为不是所有的地区都有,所以很多城市买到的都是冰鲜的鼓虾。如果是产地直营的冰鲜,因为处于才去世不久的状态,所以用来简单白灼就行,若是不靠海的内陆城市,那么用来做椒盐则刚刚好。

    河虾

    螺蛳炒河虾

    食材:螺蛳、河虾、五花肉、大蒜、生姜

    调味:薄盐生抽、蚝油

    步骤:

    1. 生姜切丝、大蒜拍碎去皮切成大蒜粒、五花肉切片。

    2. 铁锅烧热之后加少许食用油,再加入五花肉片煸出猪油,用素油 + 荤油的方式炒菜会更香。五花肉煸差不多了炒香姜丝和大蒜粒,炒出香味之后加入螺蛳,翻炒均匀后锅边淋一圈料酒去腥,接着加入薄盐生抽和蚝油调味,然后加入适量的清水,盖上盖子中大火煮 3 分钟。

    3. 待 3 分钟之后打开盖子,加入河虾,河虾是很容易熟的,所以翻炒至河虾变色即可。

    葱油海瓜子河虾

    食材:河虾、海瓜子、葱、生姜

    调味:蒸鱼豉油(或者薄盐生抽)、料酒

    步骤:

    1. 准备一锅水,锅里加入料酒去腥。

    2. 水开先下海瓜子,海瓜子的壳打开迅速捞出,放入盘中。接着,再次把同一锅水烧开,烧开之后关火,下河虾,盖盖子焖 2-3 分钟,捞出河虾,放在海瓜子上。然后在上面淋上少许的蒸鱼豉油或者薄盐生抽。

    3. 另起一口锅,挖一勺猪油,待猪油快化开时放上葱和姜丝,煸出香味之后捞出料渣,把葱油淋在海瓜子河虾上。

    我不吃葱,但是能接受葱的味道。葱油很香,与蒸鱼豉油配合后作为清蒸海鲜或者河鲜的调味,很适合。海瓜子的价格比想象中便宜很多,看着小但是又有肉,和河虾组合是非常好的下酒菜。

    白虾

    盐水白虾

    食材:白虾、生姜

    调味:食用盐、料酒

    步骤:

    1. 准备一锅水,放入适量食用盐、姜丝和料酒。

    2. 水开倒入白虾,盖盖子焖 3 分钟左右即可,煮太久虾就不嫩了。

    盐水白虾看着很简单,但是足够新鲜的虾类,我觉得盐水白灼是最好吃的。

    芦笋煮白虾

    食材:白虾、芦笋、生姜

    调味:食用盐、料酒

    步骤:

    1. 芦笋切段,生姜切丝。

    2. 准备一锅水,加入适量食用盐、姜丝和料酒。

    3. 水开先下芦笋,煮大概 3 分钟左右之后加入白虾,再煮 2 分钟左右即可。

    这道菜是在盐水白虾的基础上加入了芦笋。这个时节的芦笋也特别好吃,如果喜欢吃笋的话,把芦笋换成笋干、梅干菜也好吃,白虾换成河虾、对虾和基围虾煮也适合,加入海螺一起煮也很搭。

    萝卜丝炒白虾

    食材:白萝卜、白虾

    调味:薄盐生抽、蚝油

    步骤:

    1. 白萝卜擦成丝,然后水开下白萝卜丝,大概煮 3 分钟左右,一是为了去除白萝卜丝的涩味,二是为了缩短烹饪时间。

    2. 另起一个锅,锅热加食用油,油温热了加入白虾翻炒,翻炒至白虾变色之后加入煮过的白萝卜丝,加入薄盐生抽和蚝油调味,然后翻炒 2 分钟左右即可。

    白萝卜自带甜味,配合鲜甜的白虾,加上调味也用了蚝油,所以就是——「搭!」

    蚕豆韭菜炒白虾

    食材:白虾、蚕豆、韭菜

    调味:食用盐

    步骤:

    1. 把蚕豆剥出来,韭菜清洗干净切段。

    2. 起锅烧热油(为了更香我直接用了猪油),油温热加入蚕豆,翻炒一下之后就加入足量的清水。

    3. 待蚕豆煮软之后加入白虾,待白虾变色之后加入韭菜段和少许食用盐,翻炒至韭菜断生即可。

    春天的蚕豆、韭菜都特别好吃,而且春韭很嫩,直接当葱用就可,因而这道菜烹饪起来也就特别快速。时令蔬菜配上时令河鲜,特别完美~

    蛤蜊/花甲

    无水焖蛤蜊

    食材:蛤蜊、生姜

    调味:无

    步骤:把清洗干净的蛤蜊丢入一个耐烧的锅子中,加入切好的姜丝,盖上盖子,大火焖煮 5 分钟即可。

    蛤蜊本身带着很多水分,受热就会自然打开盖子,大家不用担心不加水的蛤蜊无法打开,准备一口可以干烧的锅,放心造就行~这样的方式可以最直接地吃到花甲本身自带的咸味和鲜味,方便快速。

    蛤蜊蒸蛋羹

    食材:蛤蜊、鸡蛋

    调味:薄盐生抽、芝麻香油

    步骤:

    1. 将蛤蜊冲洗干净之后,用无水焖的方式把蛤蜊煮半熟。

    2. 把鸡蛋叩开,加入和鸡蛋等量的开水。然后把鸡蛋打成鸡蛋液。加入蛤蜊,然后盖上锡纸或者扣上一个碗或者盖上保鲜膜再记得在保鲜膜上扎孔。上汽蒸 15 分钟。

    3. 时间到后,淋入少许薄盐生抽和芝麻香油即可。

    我觉得蒸鸡蛋羹无所谓开水或冷水,想要鸡蛋羹蒸得平滑,重要的是盖上锡纸以及鸡蛋液打散之后把泡沫去除(可以利用打火机),但是为了提高成功率,可以打好鸡蛋之后,加入 1.2 倍或者 1.5 倍的开水,然后再打成鸡蛋液。这道菜用和鸡蛋重量相同的开水,是因为蛤蜊会继续出水。

    青豆白蛤蒸肉饼

    食材:白蛤、青豆、猪肉、生姜

    调味:咸鸭蛋

    步骤:

    1. 将白蛤搓洗干净,猪肉剁成猪肉末,然后和咸鸭蛋搅拌在一起,生姜切成姜丝。

    2. 准备一个较深的盘子,底层先放青豆,然后铺上肉饼,把白蛤插在猪肉上。放上些许姜丝,水开上汽蒸 15 分钟即可。

    会员专属文章,欢迎加入少数派会员。

    优质内容

    权益周边

    会员社群

    power+

    有没有大佬有能用的注册机可以分享一下的
    现在路子都没了太难受了
    天才程序员要陨落了

    自建的 Coding Plan ,gpt-5.3-codex 和 gpt 5.4 模型

    coding 时候的正常首 token 返回,响应基本不超过 1 秒( 5W input token 左右的情况)

    这个 plan 是面向 coding 用户的,现在计划在下面两种定价方式里选一种,想听听各位程序员朋友的意见:

    1. 每个账号每天限制 50 刀额度( token 的单位价格和 GPT 官方一样),卖月 150R ;
    2. 每个人对应一个独立 plus 账号,额度限制完全和官方对齐,一个号一个月卖 60R ;

    请教一下大家,更倾向于哪种计费方案。如果大家有其他更好的定价方式也可以留言

    ps.v2ex 的帖子非引流贴,纯调研,不要加我,不在这卖。
    发这个帖子完全为了调研定价

    收到一封来自 OpenAI 的电子邮件,说我的账号涉嫌 Cyber Abuse 。也许是我的账号最近 IP 地址经常跳跃?至于跟 AI 的聊天内容,应该没有什么违规之处。

    我发起了申诉,OpenAI 回复我说,坚持对我申诉的处理结果。 😭

    最近搬砖遇到的一些问题,抛砖引玉,欢迎大家讨论

    困境

    分布式异步系统在用 vibe coding 下最大的困境主要是两个,第一个就是环境搭建,需要多个相互隔离的 linux/windows 环境,每个环境甚至需要有自己的网络栈和 docker socket 。第二个就是测试断言非常困难,如果靠轮询数据库状态/接口状态,很多时候不及时,无法断言一些中间状态转移,轮询 gap 可能错过一些异常状态。

    vibe coding 非常依赖测试作为基线,如果没有完备的测试兜底,很容易陷入打地鼠的困境,修了一个 bug 引出另一个 bug ,并且还不知道为什么出 bug 。

    systemd-nspawn

    它可以模拟一个几乎完全隔离的 linux 环境,特别适合
    需要 systemd 作为 PID 1
    需要比较真实的 Linux 主机语义
    需要 独立网络栈
    需要在容器里跑多服务,而不只是一个 app 进程
    需要细粒度控制 mount / namespace / network bridge / user namespace
    特别是每个节点本身也需要做容器编排的情况
    这东西写起来非常复杂,不过难不倒 codex

    把状态转移做成事件流

    与其轮询状态,不如把状态转移做成事件流,由测试编排统一订阅,这样永远不会错过中间状态,永远会有一个状态 trace ,LLM 非常适合根据 trace 来判断是否有异常信号。尤其是对于容器/算力编排系统,断言中间的容器/算力回收状态远比轮询来的靠谱。

    https://github.com/hooosberg?tab=repositories
    掐指一算从去年 12 月开始 ai 编程我已经做了 8 个项目,还有三四个不成功没上传的
    谷歌插件
    DOMPrompter
    BeRaw
    Packpour
    苹果电脑
    GlotShot
    TrekReel
    WitNote
    AgentLimb
    网站
    UIXskills

    未来还想做手机 ios 和 一个游戏
    还在纠结创意
    我的梦想希望在这个月先做个 ios 小应用移动端的
    最后游戏是我的神杯

    https://github.com/a9gent/mindfs.git

    界面预览

    MindFS 桌面端界面

    MindFS 移动端界面


    特性

    Agent 会话

    • 多 Agent 支持:Claude Code · OpenAI Codex · Gemini CLI · Cursor · GitHub Copilot · Cline · Augment · Kimi · Kiro · Qwen · Qoder · Pi · OpenCode · OpenClaw ,自动探测已安装的 Agent 。
    • 实时流式输出:逐 token 推送,工具调用、思考过程、权限请求均以结构化卡片实时渲染,上下文窗口实时余量。
    • 灵活切换:会话中随时切换 Agent 或模型,多 Agent 共享同一上下文,无需重新描述背景。
    • 会话搜索:支持按会话标题或对话内容搜索,并可直接跳转到命中的会话和片段。
    • 外部会话双向导入:可浏览受支持 Agent CLI 的已有会话,选择后导入到 MindFS ,并作为原生 MindFS 会话继续使用,同时 MindFS 中的会话亦可在 cli 中恢复。
    • 绑定持久化与恢复:MindFS 会持久化内部会话与底层 Agent 会话的绑定关系,服务重启后可恢复该关联;后续消息在条件允许时会继续落到同一个 Agent 会话上。
    • 富媒体输入:支持在消息中直接附带文件和图片。
    • 多端同步:同一实例可同时在多个设备上访问,会话状态实时同步。

    文件访问

    • 多 Project:同时托管多个目录,会话按 Project 独立组织,互不干扰。
    • 数据自托管:所有对话历史、文件元数据、视图配置均存储在 Project 目录的 .mindfs/ 子目录下,迁移和备份只需复制目录本身。
    • 文件树浏览:完整的目录树导航,支持文件预览,Markdown 、图片、代码均有对应渲染器。

    交互优化

    • / 斜杠命令:输入 / 触发命令候选列表,快速执行预设操作。
    • @ 文件引用:输入 @ 触发文件路径补全,将任意文件作为上下文附件发送给 Agent 。
    • # 快捷提示词:输入 # 触发已收藏的快截提示词输入。
    • 文件与会话双向跳转:打开文件可跳转到产生它的会话;打开会话可查看所有相关文件。
    • 浏览器应用( PWA ):可安装到桌面或手机主屏幕,体验更优。
    • 手机界面优化:底部操作栏拇指可及,界面更简洁。

    访问模式

    • 本地模式:服务启动后即可在局域网内通过浏览器访问,无需任何账号或配置。
    • Relay 远程模式:无需开放防火墙端口,通过 relayer 从公网任意设备访问本地实例,实现随时随地的 agent 访问。(本地模式页面中点击绑定按钮)
    • 私有通道:通过私有通道( tailscale 等),直接通过 ip:port 访问。
    • 端到端加密:会话、文件支持端到端加密保护。

    插件系统

    • 定制视图:插件是一种针对文件的定制视图,按照「传入文件内容 → 解析 → 渲染界面」的框架运行。
    • Agent 生成插件:向 Agent 发送「实现一个 txt 小说阅读器」,Agent 即可生成对应插件,此后所有 txt 文件将以小说阅读方式呈现。
    • 交互闭环:实现「定制插件 → 浏览文件 → Agent 交互」的完整闭环。

    安装运行

    • 单二进制:生产构建是一个静态编译的单二进制文件,内嵌所有 Web 资源,安装包小于 10M 。
    • 零依赖:宿主机无需安装 Node.js 、Docker 或任何守护进程管理器。
    • 多平台:支持 macOS ( Intel + Apple Silicon )、Linux ( x86-64 、ARM64 、ARMv7 )、Windows ( x86-64 、ARM64 )。

    Swoole-Compiler v4 版本推出 Native AOT(Ahead-of-Time) 编译器,将彻底改写这一现状。AOT 编译器突破了 PHP 传统的解释执行模式,支持将 PHP 代码直接编译为原生二进制可执行文件。运算性能相比传统 PHP 解释器提升高达上百倍,性能表现已达到 Rust 、Golang 等现代编译型语言的同一水平线。

    https://mp.weixin.qq.com/s/05I3xe4pgRJufSBG-8Gz6w

    国产是 coding plan 和 api 便宜,但是产品级订阅贵得要死,gpt 20 刀几乎畅用,国产你跑几个复杂点的任务就限额了,堪比 claude 20 刀的感觉(如果是入门套餐还不如 claude 20 刀)。你让它给你根据几份文件,做个 ppt 之类,它都能很快撞限额,模型质量感觉也就 sonnet 4.6 的感觉,但我用 sonnet 4.6 5 小时也能用好几次啊,国产搞啥呢?

    gpt 生成的图片,实际上是可以辩证真伪的,它自身是内嵌有一个 svg 图片的,这个可以通过让图片以文本的形式打开,找到 <path d="...." fill="black"/></svg>,所以它自身是带有防伪的。通过 https://verify.contentauthenticity.org/ 这个网站可以验证。

    但实际使用中,图片在你右键复制黏贴发送到微信群中,微信就给你压缩了,把所有可验证信息破坏了,等于变成了另外一张照片,基本上无法鉴别出是否是真实图片。
    其他什么 hash 区块链的验证前提是这张照片不被压缩才能做到吧???

    我在想,能不能在源头上给图片上个验证,比如在用户发送这张照片出去的时候,可以选择一个是否增加可信验证,然后微信提取图片的防伪信息,一直跟随着这张照片流传下去。即使压缩也保留这样的信息。或者提供一个入口。比如长按图片识别真伪,然后把第一个用户提供的可信信息进行验证。

    即使第一个用户可能作假,但你第一个用户提供的信息验证(等于第一个用户使用自己的人格做担保,即使是假的,也能把第一个用户抓起来。),然后识别真伪验证那里可以变更状态为 照片为假或者 AI 生成。

    源头照片的真伪也可能需要手机厂商去配合,提供验证信息,然后微信从照片原图上抽取。
    正常情况下,是不存在每张照片都需要去验证真伪的,只是一些社会关注度高的事件需要。比如雷总担任苹果 CEO

    这种思路可行吗?

    现在感觉只要提及 AI ,大家可能心理上就会因为焦虑而抵触,我也相信这么一句话:“经济理性会让我们做的所有选择追求效率最大化,但是从人的角度来说,这个世界有很多美好的东西是反效率的。”

    但回归理性,我们作为暴露度如此高的猿人,肯定大多数人已经掌握各种 skill 来提升自己的开发效率。虽然我觉得只要模型足够强大,skill 都是多余的,但也分享下我所记录的 context

    在实践中,我追寻的原则可能会被很多人嘲笑,但我仍认为在 AI 协助编程过程保持自己的心智是非常重要的。编程的快乐是你能在代码的运行过程得到确定性的满足感。如果全然交给 AI ,那你本身可能只是把编程当作一份工作或任务。这就像无人驾驶没办法代替我飙车的快乐是一个道理。

    如果你们还像劣者一样喜欢写代码,共勉

    一个问题,4 次 retry ,5H 额度用完,问题还没处理

    你对得起那些$99,$199 年付套餐的人吗