这个市场里太多赌徒了。
但也正是有这些赌徒的献身，才让那些有耐心的人能赚到更多的💸
但也正是有这些赌徒的献身，才让那些有耐心的人能赚到更多的💸
👁 1,759❤️ 8🔁 0💬 5
热度 · 共 248 条 · 第 4/9 页
😆 笑死，确实是相互糊弄
比较搞笑的是，出文档的人可能自己都没完整理解、甚至没阅读完整个文档，拿出来开会讨论的时候各种出岔子
比较搞笑的是，出文档的人可能自己都没完整理解、甚至没阅读完整个文档，拿出来开会讨论的时候各种出岔子
plantegg @plantegg有了 AI 之后，飞书文档承受了从来没有过的压力：
1）新文档生成速度直线上升
2）读写比例达到新低，也就是架构估计得重构了
以前大家都知道一般读写比例是 95:5，现在估计接近 50:50 了
这些文档大家也没真的去看，在各个会议上，在 CEO CTO CXO 以及各级工程师之间一视同仁地互相糊弄
👁 1,738❤️ 2🔁 0💬 0
一点心得，harness engineering 的本质是「熵减」。
而代码优于 prompt 约束，尽量把所有流程、约束，收敛到更稳定、有序的代码层去实现。
这也是 skills（agent 时代的 app）原生支持 scripts 的核心逻辑所在。
而代码优于 prompt 约束，尽量把所有流程、约束，收敛到更稳定、有序的代码层去实现。
这也是 skills（agent 时代的 app）原生支持 scripts 的核心逻辑所在。
👁 1,706❤️ 7🔁 0💬 0
ai 时代最好的编程语言可能是 rust 👀
写起来限制越多、编译器越严格越好。因为 rust 已经帮你做了很多检查工作，ai 写出坏代码的概率会小很多
同理，把很多类似的麻烦抛给 ai 可能会带来非常高的回报：
1. 各种代码检查 / lint 开得越严越好
2. 必须 tdd，测试覆盖率越高越好
3. fp（函数式编程）、immutable 强制用起来
4. 每个代码文件强制 n 行，多了就必须得拆
5. monorepo 强制用起来，所有代码按 project 这个 scope 来拆分
6...
所有的这些，施加在 human 的身上可能是枷锁、痛苦。但是 ai 是个无情的机器，让它来做反而可能事半功倍
写起来限制越多、编译器越严格越好。因为 rust 已经帮你做了很多检查工作，ai 写出坏代码的概率会小很多
同理，把很多类似的麻烦抛给 ai 可能会带来非常高的回报：
1. 各种代码检查 / lint 开得越严越好
2. 必须 tdd，测试覆盖率越高越好
3. fp（函数式编程）、immutable 强制用起来
4. 每个代码文件强制 n 行，多了就必须得拆
5. monorepo 强制用起来，所有代码按 project 这个 scope 来拆分
6...
所有的这些，施加在 human 的身上可能是枷锁、痛苦。但是 ai 是个无情的机器，让它来做反而可能事半功倍
👁 1,658❤️ 4🔁 0💬 3
我给我们部门搭建的这套 Web Codebase，我真的太特么喜欢了😆甚至让我有种喜欢上上班的错觉哈哈。
很多最新 / 最佳实践，核心代码有单元测试，Storybook，很多自动化工具，太多太多让我开发起来觉得快乐的地方了😆
很多最新 / 最佳实践，核心代码有单元测试，Storybook，很多自动化工具，太多太多让我开发起来觉得快乐的地方了😆
👁 1,655❤️ 8🔁 0💬 2
- 框架: Next.js 15 (App Router), React 19
- 样式 & 组件: Tailwind CSS, Radix UI, Shadcn UI, Storybook
- 数据请求: tanstack/react-query - 状态分享: nekocode/use-shared-state
- 国际化: next-intl + Smartling
1. 我们和设计师约定了色板统一在 Figma 上维护，设计稿用到的所有颜色必须在色板里，然后我这边写了一个脚本来读取 Figma Styles，并且生成对应的 CSS 和 Tailwind 配置
2. 我们的所有「基础组件」都基于 Headless 的理念来写，大部分来自 Radix，还有部分是我们自己维护。核心理念是只关注 DOM 逻辑、无任何样式、一个组件只对应一个 DOM 元素（由上层自由组装）。并且每个组件都有 Storybook 演示
3. 我们所有资源文件的引入都走 import（我们 public 文件夹下没任何文件），这样打包时能给所有资源文件名加上 hash。然后我们在 CI 打包时，会把所有静态资源（包括 JS）都 upload 到云储存桶上（里面也会有之前打包上传的资源），最终通过 CDN 下发给用户。这样能保证用户请求命中老的 HTML 时也能正常访问
待续
- 样式 & 组件: Tailwind CSS, Radix UI, Shadcn UI, Storybook
- 数据请求: tanstack/react-query - 状态分享: nekocode/use-shared-state
- 国际化: next-intl + Smartling
1. 我们和设计师约定了色板统一在 Figma 上维护，设计稿用到的所有颜色必须在色板里，然后我这边写了一个脚本来读取 Figma Styles，并且生成对应的 CSS 和 Tailwind 配置
2. 我们的所有「基础组件」都基于 Headless 的理念来写，大部分来自 Radix，还有部分是我们自己维护。核心理念是只关注 DOM 逻辑、无任何样式、一个组件只对应一个 DOM 元素（由上层自由组装）。并且每个组件都有 Storybook 演示
3. 我们所有资源文件的引入都走 import（我们 public 文件夹下没任何文件），这样打包时能给所有资源文件名加上 hash。然后我们在 CI 打包时，会把所有静态资源（包括 JS）都 upload 到云储存桶上（里面也会有之前打包上传的资源），最终通过 CDN 下发给用户。这样能保证用户请求命中老的 HTML 时也能正常访问
待续
👁 813❤️ 7🔁 0💬 0
本来想维护下 https://t.co/MYHte01pbp 这个项目，把依赖都升级下的。
结果发现 pixi.js 的 7 -> 8 这个升级有太多 breaking changes 了，之前处理 6 -> 7 升级时也是一堆 breaking changes。
说实话，按照这个库当前的接口设计，我感觉后续还会有不少 breaking changes，好多设计依然很别扭。
设计基础库时，api 的设计太考验开发者的编程内功了。一套好的 api 应该做到每次在内部实现有大的改动时，接口只有增量更新，或者只有少量的破坏改动。
结果发现 pixi.js 的 7 -> 8 这个升级有太多 breaking changes 了，之前处理 6 -> 7 升级时也是一堆 breaking changes。
说实话，按照这个库当前的接口设计，我感觉后续还会有不少 breaking changes，好多设计依然很别扭。
设计基础库时，api 的设计太考验开发者的编程内功了。一套好的 api 应该做到每次在内部实现有大的改动时，接口只有增量更新，或者只有少量的破坏改动。
👁 1,618❤️ 7🔁 0💬 1
来看看这次更新破坏性有多强：https://t.co/nVdUK0xhe5
按图上的数据除去 package-lock.json 的改动的话，总共还有五六百行代码的改动😅要不是有点洁癖，还真懒得管它了
年后要找工作了，这几天打算重新整一下个人主页🤔打算用 next.js 再做个外框，然后把这个 pixi game 嵌入到里面😏
按图上的数据除去 package-lock.json 的改动的话，总共还有五六百行代码的改动😅要不是有点洁癖，还真懒得管它了
年后要找工作了，这几天打算重新整一下个人主页🤔打算用 next.js 再做个外框，然后把这个 pixi game 嵌入到里面😏
👁 1,084❤️ 1🔁 0💬 0
让我想起我的一个前同事，在他的个人项目里用到我们内部的某个 token，然后还 push 到 github public repo 幸好最后被我发现的事 😅
我甚至最开始还不知道他的 github id，是收到风险预警 email 后再在 github 上搜这个 token 文本才找到他并确认的。
我甚至最开始还不知道他的 github id，是收到风险预警 email 后再在 github 上搜这个 token 文本才找到他并确认的。
Ruifeng @liruifengvvant、@rspack/core、@rspack/cli 被盗号者注入恶意脚本，请升级到 vant 4.9.15、@rspack/core 1.1.8 、@rspack/cli 1.1.8
https://t.co/EU715y7zVz
https://t.co/KntX26q96S
👁 1,572❤️ 5🔁 0💬 0
「最终，一切取决于品味」
只要涉及到创造的领域其实就离不开艺术和品味，「苹果团队里有音乐家、诗人、艺术家、动物学家、历史学家，同时他们也是顶尖的计算机学家」。在代码工程领域里，不同地区 / 文化、不同性格 / 背景的工程师也许「品味」差距很大。
每一个细微的决策、设计上的差距，在累积到一个新的量级 / 诞生出一个「产品」时，也会产生出翻天覆地的变化。
只要涉及到创造的领域其实就离不开艺术和品味，「苹果团队里有音乐家、诗人、艺术家、动物学家、历史学家，同时他们也是顶尖的计算机学家」。在代码工程领域里，不同地区 / 文化、不同性格 / 背景的工程师也许「品味」差距很大。
每一个细微的决策、设计上的差距，在累积到一个新的量级 / 诞生出一个「产品」时，也会产生出翻天覆地的变化。
👁 1,569❤️ 3🔁 0💬 0
做了个东西：SeqLog — Apple 原生的 Logseq 替代品。
SwiftUI + Rust FFI，没有 Electron，没有 300MB 运行时，没有云。
- 不做数据库（.md 就是真相）
- 不做索引（ripgrep 够快，VS Code 同款引擎）
- 不做云（你自己选 iCloud/Git/Dropbox）
- 不做 Electron（SwiftUI 原生）
SwiftUI + Rust FFI，没有 Electron，没有 300MB 运行时，没有云。
- 不做数据库（.md 就是真相）
- 不做索引（ripgrep 够快，VS Code 同款引擎）
- 不做云（你自己选 iCloud/Git/Dropbox）
- 不做 Electron（SwiftUI 原生）
👁 1,557❤️ 16🔁 0💬 1
灵感 & 基因来源：Logseq + VS Code
不到 5MB 的大小，Apple Native，无 DB 无索引（抛弃 Logseq 路线），多 Tab，斜杠命令面板
对我来说简直太完美了！
不到 5MB 的大小，Apple Native，无 DB 无索引（抛弃 Logseq 路线），多 Tab，斜杠命令面板
对我来说简直太完美了！
👁 609❤️ 0🔁 0💬 0
看看过去 24 小时里暴跌行情 📉 我们资金曲线的表现 👀
👁 1,513❤️ 9🔁 0💬 1
交易起来 💸💸💸
👁 1,490❤️ 4🔁 0💬 1
100% 同意。但是现实是大多数的利益分配者不会愿意多付这 100% 的支出。
贪婪和压榨是资本的天性。
贪婪和压榨是资本的天性。
Yishi @ohyishi聪明的人沟通起来就是爽，你刚说完30%的需求，他就能 get 到120%，多出来的那20%是超额执行，考虑了各种边缘情况和向后兼容，考虑得比你还周全。
不聪明的人，你完整交代100%的需求，他只能做到30%，多不了一点，只管上线，脏活全丢给 qa。然后你被逼着不停拉会，非常疲惫。
不要为了省那20%预算招不聪明的人，应该花200%的钱招聪明的人。
👁 1,470❤️ 5🔁 0💬 0
以我的经验，目前最好用的查询索引是维护一个全局的 FILETREE.md：项目文件树，每个文件一句话描述
less is more。信息量/上下文不是越多越好，信息越多注意力越容易被分散，这里的权衡很重要，也是大多数新手容易犯错的地方。
less is more。信息量/上下文不是越多越好，信息越多注意力越容易被分散，这里的权衡很重要，也是大多数新手容易犯错的地方。
Yufan Sheng @syhily不知道是不是我的使用姿势不正确，推油大吹特吹的 CodeGraph 在我这使用效果相当一般。还不如 Agent 自己去 Grep。
👁 1,467❤️ 8🔁 1💬 2
GM🌞
休假结束，今天开始上班🧑💻
休假结束，今天开始上班🧑💻
👁 1,407❤️ 5🔁 0💬 0
你如果在用 SDD，那我不建议你把 Spec 持久化。因为 Spec 会漂移！
代码在变，Spec 却不一定跟着更新。过时的 Spec 不是文档，是噪音，是幻觉的温床
真正的「唯一真相来源」应该只有一个：代码本身
又或许你更需要的是 Plan Mode，或者一个全局唯一的 Spec: ARCHITECTURE.md
代码在变，Spec 却不一定跟着更新。过时的 Spec 不是文档，是噪音，是幻觉的温床
真正的「唯一真相来源」应该只有一个：代码本身
又或许你更需要的是 Plan Mode，或者一个全局唯一的 Spec: ARCHITECTURE.md
👁 1,347❤️ 5🔁 0💬 0
今天详细看了下 apollo 对 react suspense 支持，发现支持得真棒👍准备在小破站把 suspense 用起来了，把 loading 和 error 的渲染剥离出去，「别 catch 了，直接往上 throw 吧」👀
https://t.co/bv3wUPRTAF
https://t.co/bv3wUPRTAF
👁 1,236❤️ 3🔁 0💬 0
😎 用 grafana 搭建的量化表现面板。
🆒🆒🆒💵💵💵
🆒🆒🆒💵💵💵
👁 1,228❤️ 9🔁 0💬 0
强烈推荐下 react-scan 这个新工具。react 生态下终于有一款简单方便的杀手级 profiling 工具了！
Aiden Bai @aidenybaigithub, please fix your React re-renders.
literally every time i scroll it renders 100× https://t.co/7dKd5lWrZt
👁 1,222❤️ 9🔁 1💬 0
有个一劳永逸的办法：
1. 给 Agent 提供的所有 API Key 都使用 Placeholder
2. 代理本机所有网络，拦截对应请求替换 Placeholder 为真实密钥
如果 Agent 允许跑在 Docker 内的话，那网络代理更方便了
1. 给 Agent 提供的所有 API Key 都使用 Placeholder
2. 代理本机所有网络，拦截对应请求替换 Placeholder 为真实密钥
如果 Agent 允许跑在 Docker 内的话，那网络代理更方便了
Lyric🌀 @lyricwai效果如图，它自己去 https://t.co/DkYrGAJL2n 生成了 PDF，没问我要 APIKey，也没有把 APIKey 暴露到 prompt
👁 1,219❤️ 1🔁 0💬 1
最近在公司里开始搞 flutter 和 hybrid 相关的事。
五年前我是 all in flutter 的态度，但现在看法不太一样。flutter 真的很先进，而且 dart 是专门为 ui 领域设计的语言，整套技术在平衡性上是顶尖的。在某种意义上我甚至觉得它们有点要搞 better browser 的意思。
但是 flutter 永远达不到 browser 的地位，连 android 自身都没深度集成 runtime 进去，更别说其他操作系统了。只要没法像 web 那套一样成为事实标准，那么 flutter 和系统原生层的 gap 就会一直很难处理。这个担子太重了（自己处理渲染，担子远比 bridge 到原生重），我很怀疑 google 还会不会一直投入进去。
所以我基于市场判断的预测是 flutter 未来可能会没落。但是我感觉无论如何，至少它的很多设计、实现，甚至精神理念应该会对其他的 ui 构建系统带去不少影响（据说 flutter 的工程总监已加入 apple 了）。
如果你问我现在的选择，我会更支持原生 /+bridge (例如 rn)，或者 web 这两个方案。除了 web 这个事实标准敢自己处理渲染层外，其他自己处理渲染的 ui 框架我都不太看好。
五年前我是 all in flutter 的态度，但现在看法不太一样。flutter 真的很先进，而且 dart 是专门为 ui 领域设计的语言，整套技术在平衡性上是顶尖的。在某种意义上我甚至觉得它们有点要搞 better browser 的意思。
但是 flutter 永远达不到 browser 的地位，连 android 自身都没深度集成 runtime 进去，更别说其他操作系统了。只要没法像 web 那套一样成为事实标准，那么 flutter 和系统原生层的 gap 就会一直很难处理。这个担子太重了（自己处理渲染，担子远比 bridge 到原生重），我很怀疑 google 还会不会一直投入进去。
所以我基于市场判断的预测是 flutter 未来可能会没落。但是我感觉无论如何，至少它的很多设计、实现，甚至精神理念应该会对其他的 ui 构建系统带去不少影响（据说 flutter 的工程总监已加入 apple 了）。
如果你问我现在的选择，我会更支持原生 /+bridge (例如 rn)，或者 web 这两个方案。除了 web 这个事实标准敢自己处理渲染层外，其他自己处理渲染的 ui 框架我都不太看好。
👁 1,213❤️ 2🔁 0💬 3
当然不看好归不看好，在公司里还是得听上层们的决策 hhh
不过最近公司新来了个 leader，道听途说，后续跨平台这块应该会换成 rn 了🤔
不过最近公司新来了个 leader，道听途说，后续跨平台这块应该会换成 rn 了🤔
👁 515❤️ 0🔁 0💬 0
一个震惊的现实：
我发现很多工程师（甚至有月薪达到 30k 的），对代码的运行效率没概念。
举个例子，一段看似有很多计算的代码，没深入思考就认为瓶颈在 cpu 就要求升级设备，而现实是计算步骤中会不断把结果写入到数据库，瓶颈完全在 io 上，其实优化下代码就能极大的提升效率。
不得不问，有多少人对「计算密集」和「io 密集」这两个有很明确的概念的？又有多少人对性能 profile 和优化有经验的？🤔
我发现很多工程师（甚至有月薪达到 30k 的），对代码的运行效率没概念。
举个例子，一段看似有很多计算的代码，没深入思考就认为瓶颈在 cpu 就要求升级设备，而现实是计算步骤中会不断把结果写入到数据库，瓶颈完全在 io 上，其实优化下代码就能极大的提升效率。
不得不问，有多少人对「计算密集」和「io 密集」这两个有很明确的概念的？又有多少人对性能 profile 和优化有经验的？🤔
👁 1,191❤️ 9🔁 0💬 3
GUI IS BULLSHIT!
就算强如 Claude Opus 4.6，在 Vibe coding GUI 项目时（尤其是非 Web 栈），在稍微复杂的交互场景下，总容易会有 Bug 或细节问题，很容易让细节狂魔抓狂。
反观非 GUI 项目，Vibe coding 简直行云流水，身心愉悦。
看来文本喂出来的模型，终究是个半瞎 🤔
就算强如 Claude Opus 4.6，在 Vibe coding GUI 项目时（尤其是非 Web 栈），在稍微复杂的交互场景下，总容易会有 Bug 或细节问题，很容易让细节狂魔抓狂。
反观非 GUI 项目，Vibe coding 简直行云流水，身心愉悦。
看来文本喂出来的模型，终究是个半瞎 🤔
👁 1,156❤️ 2🔁 0💬 1
使用 Git Worktree 的两个场景：
1. 同一个需求，多路并发：
开多个 Worktree 同时跑多个 Agent，最后择优 Merge。
Worktree 的核心优势是能提供干净隔离的工作目录。这样 Agent 可以不只是 Plan，而是可以有执行。Plan 优秀 ≠ 执行优秀。
2. 不同需求，并行开发：
同样开多个 Worktree 并行跑 Agent，但拆需求时要意识到要让改动的交集尽量少一些。
Merge 时如果遇到冲突，不要手动硬解，再开一个独立 Agent 来处理。它能通过冲突点和 Diff 获得一个混合视角，重新审视所有改动，往往比人肉 Resolve 更周全。
1. 同一个需求，多路并发：
开多个 Worktree 同时跑多个 Agent，最后择优 Merge。
Worktree 的核心优势是能提供干净隔离的工作目录。这样 Agent 可以不只是 Plan，而是可以有执行。Plan 优秀 ≠ 执行优秀。
2. 不同需求，并行开发：
同样开多个 Worktree 并行跑 Agent，但拆需求时要意识到要让改动的交集尽量少一些。
Merge 时如果遇到冲突，不要手动硬解，再开一个独立 Agent 来处理。它能通过冲突点和 Diff 获得一个混合视角，重新审视所有改动，往往比人肉 Resolve 更周全。
nekocode @nekocode_cnGit Worktree 绝对是驾驭 Coding Agent 最需要的功能之一：
快速 Fork 出多个隔离、干净的工作目录，让多个 / 不同的 Agent 并行探索不同方案，最后再 Merge 回主分支 —— 有冲突？也交给 Agent 处理就行。
这绝对是 Coding Agent 的并发放大器！
现在不少 GUI / IDE 已经支持 Worktree 管理，但如果你是 CLI 原教旨主义者，强烈推荐 agent-worktree，在保留 Coding Agent CLI 100% 原生能力的同时，补齐了 Worktree 管理能力。
👁 1,094❤️ 6🔁 2💬 1
过去：雇佣多个开发者，各自在独立设备上并行迭代
AI 时代：启动多个 Coding Agent，在单台设备上通过多个 Worktree 并行迭代
AI 时代：启动多个 Coding Agent，在单台设备上通过多个 Worktree 并行迭代
👁 212❤️ 0🔁 0💬 0
最近在看老板花了几个 w 报的 quant 课程给的代码，一个感想：「搞科研的和搞代码的真的是两拨人」。代码乱、抽象差、工程性差、运行效率差 🫠
要不信的话，你去看看 quant 或最近热门的 ai 领域的开源项目，其实挺多都是代码质量一般的。而且有很多 poc 还都只是停留在 jupyter notebook 阶段。
当然，这种现象非常合理，毕竟术业有专攻。能跨领域本身就已经是稀缺人才了。
要不信的话，你去看看 quant 或最近热门的 ai 领域的开源项目，其实挺多都是代码质量一般的。而且有很多 poc 还都只是停留在 jupyter notebook 阶段。
当然，这种现象非常合理，毕竟术业有专攻。能跨领域本身就已经是稀缺人才了。
👁 1,092❤️ 6🔁 0💬 0