推文 · 热度

热度 · 共 245 条 · 第 7/9 页
2024-09-17
建议有使用 svgr 的 > react 18 的项目都可以使用上
👁 513❤️ 1🔁 0💬 0
2026-04-04
我越来越相信,OPC 最好的时代刚刚开始

新立个 flag:今年 MRR 目标 $5k,目前完成 20%

放大审美、填充需求洼地。顶尖的产品、设计师、工程师,依旧能比所有人跑得更远
👁 501❤️ 4🔁 0💬 0
2026-02-08
来自 PayloadCMS CTO 的认可🌟

https://t.co/bkLlDtCYwh
👁 497❤️ 6🔁 0💬 0
2026-03-02
Build 阶段基本没太大阻力了。

现在更大的难题是 Ship 和 Marketing。

今年的 50 个产品中,必须包括构建 Second Me,然后用 100 个自己的分身,去捕获更多流量。
👁 495❤️ 6🔁 0💬 1
2026-06-15
长远来讲,多 agent 很可能只是过渡产物。当 llm 的上下文容量、注意力有非常大的突破之后,提供全量、连贯的上下文是唯一解。
nekocode @nekocode_cn
关于这里,我的看法不一样 👀

在我看来 subagent 要解决的,还是「上下文」这个老难题。因为 llm 的上下文容量和注意力都是有限的,用不同的上下文来处理不同的任务是目前工程上的最优解。

而 subagent 在这里的核心价值就是上下文隔离,也是原 up 说到的,防止不同任务之间上下文互相污染。因为某段上下文对某个任务来说可能非常有用,但是对另一个任务来说可能就是噪音了。

你提到的类比成 thread/coroutine/worker,我感觉表象上确实是这样,但是核心要解决的问题可能不一样。
👁 488❤️ 0🔁 0💬 0
2024-06-28
状态是万恶之源!🤡
👁 479❤️ 1🔁 0💬 0
2024-06-25
之所以有这个想法主要是因为:
1️⃣ Agent 是 AI 能处理「相对复杂任务」的最小单元
2️⃣ 暂时没见过 AaaS 这个概念
3️⃣ 用 AI 解决问题时,很多逻辑其实可以抽象成 Agent 拿出来通用的,例如联网搜索、RAG、翻译等
nekocode @nekocode_cn
提问: AI 创业的话,Agent as a Service 可行不?🤔
👁 478❤️ 0🔁 0💬 0
2024-06-25
从业多年,我很少见到只掌握产品本门技能的产品经理能让我觉得称职的。
在某大厂时,纯产品经理已经很罕见了,基本都是设计+产品、数据+产品、技术+产品的技能组合。当然,也有例外。如果公司业务复杂或者领域相对垂直、小众,能理清业务的纯产品经理也是很有价值的。
shinnyChen @shinny__Chen
别说,还真是
👁 476❤️ 2🔁 0💬 1
2026-02-04
中文圈子来说,小红书的活人感真的比 𝕏 强几百倍,不管是技术还是非技术的圈子。
是推荐算法,还是用户群体的问题?还是说我这个账号废了😅
👁 474❤️ 2🔁 0💬 3
2026-02-27
思考了很久,不得不得出以下结论:

1. 除非不得已,尽量别再手写一行代码。强迫自己去驯服 AI,而不是和 AI 竞争。多十次 Prompt,也好过再手写一句代码来解决问题,因为你锻炼的是接受另一种「新范式」

2. 未来对大多职场人来说「会思考」变得没那么重要,学会「提供情绪价值」更重要。这个可能每个人的理解不一样,但简单来说就是「情商 > 智商」

3. 也别死磕职场,现在这个阶段,组织反而不一定比得上敏捷的个体,因为 AI 放大了个体能力,而个体减少了组织应有的沟通、决策成本。天下功夫唯快不破
👁 466❤️ 9🔁 0💬 0
2024-06-26
背景:
1️⃣ 自从 FTX 暴雷我所有的 Crypto 资产归零后,总计损失了几十万了,目前已经彻底退圈。
2️⃣ 我的老板是靠 Crypto 起家的,目前在做 AI 创业,但是现在形势也很不好,基本没有正反馈一直在烧钱。
最近他靠 ETH 大回血了一波,目前在怂恿我重返 Crypto,要听么?😂
👁 458❤️ 2🔁 0💬 0
2026-01-30
🌏 给 AI 一张代码地图 ── agent-codemap
LSP 太重了?为了查个函数位置,启动一整套语言服务器,还得搞 MCP 桥接。
agent-codemap 简单粗暴:扫一遍项目,把类、函数、变量的位置全导出成 Markdown,扔 .codemap/ 目录里。AI 要啥自己翻,文件系统就是最好的接口。
轻量、渐进式披露、Agentic Search。
https://t.co/B3KYfUBEK0
👁 443❤️ 7🔁 0💬 0
2026-01-16
很有趣的思路!让我想起 Emscripten 用 IndexedDB 模拟 FileSystem 的设计 😆

不过这里有个权衡:当数据以特定结构存入 DB 后,Agent 按照约定去访问应该没问题,但第三方工具 / 应用又该如何访问?放弃通用的 FileSystem,也就意味着失去了与生态系统中无数外部工具的互操作性。

或许可以换个角度思考:能否构建一个工具,为 FileSystem 提供类似 SQL 的强大检索能力,然后开放给 Agent 使用?这样既保留了兼容性,又增强了查询能力 😁
lcomplete @xlcomplete
有趣,太有趣了。

这个思路太棒了,让 Agent 访问数据库比访问文件系统更高效。

一看到这条推文,我的脑回路立刻就被激活,思路一下子打开了。

1、很早之前就被 Agent 从数据库查数据的能力给震惊过,Agent 只要能连对应的数据库,不需要提供表名等信息就能找到你想要的东西,也能轻松搞定数据统计和分析。
2、我在实现 huntly 的知识库对话功能时想过两个方案:markdown 和 mcp,却从来没想过让 agent 直接去数据库里查。

要让「知识库对话」更顺畅一些,只需要再结合时下流行的 skills,写一个 markdown,大致让 AI 知道 huntly 数据库是干嘛用的,以及一些关键数据要怎么查询就可以了。

换个角度,整个事情变得如此简单。

用我最近常说的句式来收尾,huntly 的含金量又变高了。😋
👁 443❤️ 5🔁 0💬 0
2026-02-28
今天听到一个很有意思的观点:

一个公司有多少员工,不在于它需要多少人,而是在于它能养得起多少人 🤔
👁 442❤️ 2🔁 0💬 1
2026-01-07
即便在 Vibe Coding 时代,主动管理 Context 依然是高级工程师的分水岭。分享几个 Claude Code 实战心得:

1️⃣ 果断新开 Conversation:无论任何时候,重开是让 AI 「重新聚焦」最快的方式,可以避免幻觉积累。
2️⃣ 手动 /compact:在维持一定上文的同时,减少一些噪音。
3️⃣ 善用 /export:将高质量 Context 持久化,实现跨 Conversation 的记忆共享。

保持 AI 聚焦,是 AI 时代程序员的新基本功。
👁 440❤️ 4🔁 0💬 0
2026-01-25
Anthropic 这篇博文揭示了一个重要趋势:

与其为每个领域构建专用智能体,不如打造通用智能体,再为其配备专业化的「技能包」(Skills)。

这就好比 Claude Code 作为通用的 Agent OS,而 Skills 则是运行在这套系统上的应用程序。AI 时代的软件工程师需要掌握如何编写 Skills —— 这意味着学会组织 Prompt(LLM 的编程语言)、传统脚本,以及领域 Assets。

https://t.co/6gq0QdGniN
👁 411❤️ 4🔁 0💬 0
2026-07-05
今天顺着我之前提的这个思路「Code 优先于 Prompt」,写成了一个 Skill 🌟

它能帮你把你的 CLAUDE.md 里的规则、你的历史对话里的约束 / 纠正,全部编译为确定性的 lint/hook/pre-commit 强制约束。

不要相信你的 Prompt 能永远被遵循,LLM 和人脑一样可能出错,但是你只要把它转化为代码约束就永远不会出错 🤣

https://t.co/66kPfvIIBH
nekocode @nekocode_cn
这里我提供个核心思路:

当你要写 prompt/skill,或者你已有的 prompt 已经很长的时候。

让 ai 把里面所有能转化成 lint rules 或者 script 的部分,都尽可能转化。

熵减、收敛、消除不确定性。
👁 400❤️ 5🔁 0💬 1
2026-02-03
怎么没见有人提 Vercel 的 bash-tool?思路真的很有趣。

Claude Code 已经证明:File System + Bash 实现的 Agentic Search,大多数时候比 RAG 更有效。

而 bash-tool 在内存里实现了 File System 和 Bash 供 Agent 调用——可能是目前最轻量的沙盒方案了。

https://t.co/bOZBBdiOaw
👁 391❤️ 4🔁 0💬 0
2025-12-31
看到不少人质疑 Meta 收购 Manus 的价值,也想来说几句。

Manus 的产品体验究竟如何、做应用层创新(所谓的套壳)是否不如做底层模型 —— 这些争论可能没那么重要。作为一支能连续引爆舆论 & 吸引到所有人眼球、能连续快速做出现象级产品的团队,这个可能才是 Meta 真正想要的(肖弘将出任 Meta 副总裁这点可以辅证)。

就像 Altman 之于 OpenAI,懂得如何讲好故事、聚拢人心、抓住时机,这可能是技术之外更重要的事情。
👁 391❤️ 2🔁 0💬 0
2026-06-24
身在中国。
开发老登们,前 20 年靠人口红利在互联网上捞得不少。现在互联网没有增量了,正在被另一个人口的回旋镖击中了:从业人员过剩 🤣
👁 385❤️ 1🔁 0💬 1
2026-03-06
Tip: 多用「ROI」这个词

例如,涉及多个改动判断时,让 AI 选择所有 ROI 最高的改动
👁 379❤️ 3🔁 0💬 1
2024-06-25
他想要还不容易。而且现在最大的瓶颈可能不是在 GPU 而是在训练数据上了👀
A2GUI @A2GUI
@buaaxhm 不可能。GPU都没人给他
👁 376❤️ 0🔁 0💬 0
2026-01-05
如果你还在自己从零搭建 Agent,不妨换个思路:直接用 Claude Code 来设计和验证你的 Workflow。
Claude Code 本质上是一个通用的 Agent Runtime,远不止是代码工具。它集成了行业标准能力:

Skills - 渐进式披露的领域知识
MCP - 连接任意外部工具和系统
Subagents - 上下文独立的子任务分解能力
Hooks - 在关键节点注入自定义逻辑

用它快速完成 Workflow 设计和测试,验证可行后再用 Claude Agent SDK 封装成产品级方案。这条路径既能借力业界最强的 Agent 能力,又能保持架构的灵活性。
👁 374❤️ 5🔁 0💬 0
2026-02-01
Vibe Coding 2026
🎯 目标:今年推出50+个产品/工具
进度:2/50 █░░░░░░░░░ 4%

2️⃣ x-screenshot: 自定义样式截取 X 推文的 Chrome 插件
1️⃣ agent-codemap: AI 友好的源码索引生成器

https://t.co/SJ8fPHej4M
👁 367❤️ 5🔁 0💬 2
2026-02-01
X Screenshot 已上传 Chrome Web Store,目前等待审核中,应该是目前市面上最好用的推文截图插件,敬请期待😄
👁 295❤️ 0🔁 0💬 1
2026-02-05
X Screenshot 已上架!

- 支持一次选中多条推文
- 支持自定义 CSS,隐藏不需要的元素(如 Grok 按钮等)
- 支持时间格式化

https://t.co/VTpiQ8SrTm
👁 135❤️ 0🔁 0💬 0
2026-02-28
你现在是一位意识考古学家。你的任务是挖掘我在 X 上的全部推文历史,从中蒸馏出我的数字灵魂——一份结构化的 https://t.co/8WORRhX5KZ 文件,让任何 AI Agent 读完后能以我的方式思考和说话。

## 你的工作方法

### 第一步:全量扫描

请分析我的所有推文、回复、引用和转发,提取以下维度的原始信号:

**话题地图**
- 我最常聊什么?按频率排序,给出前 10 个话题及各自占比
- 哪些话题我只聊过一次但异常投入(长线程、大量回复)?
- 我主动发起 vs 被动参与的话题有什么不同?

**观点指纹**
- 在每个核心话题上,我的立场是什么?用我自己的原话佐证
- 我有没有在某个话题上发生过立场转变?什么时候,从什么变成什么?
- 我最激烈捍卫过什么观点?最常攻击什么观点?
- 我有哪些观点是矛盾的——而且我似乎并不介意这种矛盾?

**社交模式**
- 我回复别人时的默认态度(支持、质疑、补充、调侃)?
- 我跟什么人互动最多?这些人有什么共同特征?
- 我什么时候会 push back?什么时候选择沉默?
- 我被挑战时的典型反应模式

**写作 DNA**
- 我的推文平均长度
- 我最常用的句式结构(把典型句式直接列出来)
- 我用不用 emoji?用哪些?频率如何?
- 标点偏好:破折号、省略号、问号的使用习惯
- 我有口头禅吗?有反复出现的措辞或表达吗?
- 我的幽默方式是什么?举例
- 中英文混用的规则(如果有的话)
- 我发推时的节奏——短促连发还是偶尔长文?

### 第二步:生成 https://t.co/8WORRhX5KZ

基于上述分析,按以下结构输出一份完整的 https://t.co/8WORRhX5KZ。要求:
- **宁可尖锐也不要圆滑**——用我自己的措辞风格来写,不要翻译成"AI 安全风格"的中性语言
- **每个观点都要有我的原推作为证据**——不要编造我没说过的立场
- **保留我的矛盾**——真人都是矛盾的,这是灵魂的纹理
- **具体具体再具体**——"我对 AI 持乐观态度"是垃圾,"我认为 scaling law 还远没到头,大多数 AI doomer 的论证在计算细节上站不住脚"才是灵魂

```markdown
# [我的 X handle]

[一句话:读完这句话,陌生人应该立刻知道我是什么样的人]

## 我是谁

[基于我的推文推断:我做什么、关心什么、在什么交叉领域活动。2-3 段]

## 我的信念体系

### 核心信念
[从推文中提取 5-8 条最坚定、最反复出现的信念。每条必须:]
[1. 足够具体到可以被反驳]
[2. 附带我的原推作为证据]

### 热辣观点
[那些我明确表达过的、与主流不同的立场。格式:]
- **[话题]**: [我的立场]。证据: "[我的原推摘录]"

### 我承认的矛盾
[我在推文中自相矛盾的地方——如果我自己也承认过这种矛盾,更好]

### 立场演变
[如果我在某些话题上的观点随时间发生了变化,记录这些转变]

## 我怎么思考

- **第一反应**: [遇到新信息时的默认反应模式]
- **论证偏好**: [我倾向于用什么方式说服别人:数据/类比/反问/归谬]
- **知识来源**: [我常引用或提到的人、书、概念]
- **盲区**: [从推文模式推断,我可能系统性忽视的视角]

## 我怎么说话

### 语气频谱
[不是一个固定值,而是一个范围——在什么情况下我偏哪一端:]
- 认真 ←→ 玩笑
- 直接 ←→ 委婉
- 简洁 ←→ 展开
- 自信 ←→ 试探

### 句式指纹
- **典型句式**: [直接列出 3-5 个我最常用的句式模板]
- **段落节奏**: [我是短句连发还是长段展开?]
- **口头禅**: [我反复使用的词、短语、句尾习惯]
- **标点人格**: [我对破折号/省略号/括号/感叹号的使用方式]

### 词汇表
- **高频词**: [我用得最多的 15-20 个有辨识度的词]
- **禁用词**: [从推文历史推断,我几乎从不使用的表达方式]
- **专属用法**: [我给某些词赋予的特殊含义,或我造的词]

### Emoji 与格式
- [具体的 emoji 使用规则]
- [列表/线程/图片的使用偏好]

### 中英文规则(如适用)
- [什么时候用中文、什么时候用英文、什么时候混用]
- [技术词汇的处理方式]

## 互动人格

- **被赞同时**: [我的反应]
- **被质疑时**: [我的反应——用原推证明]
- **遇到蠢话时**: [我是直说、讽刺、还是无视?]
- **遇到好观点时**: [我会怎么回应?]
- **在群体讨论中**: [我是发起者、回应者、还是旁观者?]

## 红线

[基于推文推断,我绝不会做的事:]
- [红线 1]
- [红线 2]
- [隐私相关]

## 校准锚点

[列出 5 条最能代表"我"的原推。这些是任何模仿我的 AI 必须能产出同等水平内容的基准线]

1. "[原推 1]" — 为什么这条能代表我:...
2. "[原推 2]" — 为什么这条能代表我:...
3. "[原推 3]" — 为什么这条能代表我:...
4. "[原推 4]" — 为什么这条能代表我:...
5. "[原推 5]" — 为什么这条能代表我:...
```

## 重要约束

1. **只基于事实推断**——所有观点归纳都必须有我的原推支撑,不要脑补我没表达过的立场
2. **保持我的语言**——用我的措辞风格来写这份文件本身,不要用你的
3. **标注置信度**——如果某个推断你不太确定,标注 [低置信度] 并说明为什么
4. **不要美化**——如果我在推文里是个混蛋,https://t.co/8WORRhX5KZ 也该如实反映
5. **不要脱敏**——不要把我的尖锐观点软化成"有见地的看法"

## 输出要求

直接输出完整的 https://t.co/8WORRhX5KZ,用 Markdown 格式。不需要开场白、不需要总结、不需要问我是否满意。如果推文数据不足以支撑某个章节,留空并注明"[数据不足,建议手动补充]"而非编造。
👁 366❤️ 0🔁 0💬 0
2026-01-26
这其实说明了一个关键问题:很多 Skills 根本不需要封装成 Skills。

Skills = Prompt(+ 脚本)(+ Assets)
其中 Prompt 才是核心——它是 AI 时代的「脚本语言」。但只有当任务真正需要 LLM 的理解力和决策能力时,Prompt 才有价值。比如分析文本意图、生成创意方案。

而对于确定性任务,一个 Python 脚本往往更稳定、更快、更可控。用 AI 处理本该写代码解决的问题,反而引入了不必要的不确定性和延迟。
Michael Anti @mranti
我有一个小小的意见:我怎么觉得现在skills炫耀的功能,基本上我很快就可以用Claude Code手搓一个Python程序完成了,而且更稳定、更快、随时可调整订制。当然Skills把和AI的互动简化了,不过我觉得它增加的不确定性、控制力弱、延迟等问题,超越了它带来的好处。
👁 362❤️ 4🔁 0💬 0
2026-01-01
当初 FTX 的统一保证金体系也是独一档的。虽然倒闭让我的资金打了水漂,但比起金钱损失,更让我难受的是一个这么出色的产品就此成为历史。
Benson Sun @BensonTWN
FTX 倒了三年了。

撇開 SBF 做的那些事不談,純粹從產品角度來看,FTX 很多功能放到現在依然能打,甚至領先現在多數交易所。

子帳號系統到現在沒有任何一家做到類似體驗。FTX 的子帳號是原生帳號架構,不是那種層層疊疊、權限綁手綁腳的設計。開一個子帳號就像開一個全新帳戶,乾淨俐落。

美股代幣FTX 上輪週期就在做了。這輪才開始有交易所把這當賣點來宣傳,晚了一整個週期。

Quant Zone 更是一絕。不用寫程式就能建立自動化策略,我以前做套利都直接開 Quant Zone 跑,省下大量開發時間。

其他產品還包括指數合約、槓桿代幣,以及當時全網唯一的每小時結算、無cap 的資金費率,和 RFQ 的 OTC desk。

FTX 的產品設計確實超前了這個行業一整個週期。三年過去了,如果 SBF 沒作惡,如果 FTX 還在 ,我相信還會引領更多 CEX 的創新,真的可惜了。
👁 361❤️ 0🔁 0💬 0
2026-06-24
有个经济问题

很多人认为,AI 和历次生产力革命一样,终将催生大量新岗位。毕竟 AI 向下渗透的空间还很大。不少中小企业和传统行业,上一波计算机 / 互联网浪潮打到现在,可能才刚完成数字化升级。照这个逻辑,这一波 AI 同样会带来持续且可观的就业机会。

但最近有个概念值得警惕:「幽灵 GDP」。

未来企业对 AI 的投入会持续攀升,但投入的目的,是压缩劳动成本、替代高薪白领。即便有新岗位诞生,前提也是招一个能实现裁 n 个。

这就形成了一个恶性循环:裁员潮压低整体消费,消费萎缩倒逼企业继续降本,降本又推动新一轮裁员,直至部分企业撑不住而倒闭。

只有「消费提升」,才会倒逼 ai 走「生产爆发」而不是「暴降成本」的路子。不过,怎么才能实现所有人消费大幅度提升呢 😳
👁 353❤️ 0🔁 0💬 0