0%

2025 下半年至今,Coding Agent 以前所未有的发展速度与迭代速度,在广大工程群体中普及,目前仍然在以月为单位产生能力质变。Coding Agent 及其他通用 Agent 的能力表现,确实让大家直呼惊艳,但同时也让大家感到深深的焦虑:Coding Agent 比我聪明、比我知识面广而且深、比我学习速度快、比我效率高,那我还能干些什么?是不是很快就要领大礼包了?

我也和我的同事们畅聊过很多,大家基本上都存在一个共同的方向:有个特别好的想法,做出来肯定有人用。不用开会,不用看老板脸色,搞个小工具、做个 SaaS,最好再套个 AI 的壳,做出来往那一挂,躺着收钱。

这个想法听起来很美好。根据独立开发者社区的统计数据,超过 80% 的独立产品在上线后一年内收入不足 1000 元,而其中 60% 的产品在上线三个月后就彻底停更了。我今天想聊一个可能违反程序员直觉的观点:如果你现在满脑子想的都是用 Vide Coding 做出个产品,用来解决某个市场细分领域的痛点,顺便挣点小钱或者撞大运直接不用上班了,说明你还没理解这个时代的本质特征。这是一个生产过剩、需求稀缺的时代。

当下最不缺的就是会写代码的人

你想做的那个 APP、那个小程序、那个 AI 工具、那个 SaaS,本质上跟奶茶店、花店、火锅店没有任何区别,都是在提供一个产品。在生产过剩的时代去搞生产,一定是吃力不讨好的。物以稀为贵,这个道理亘古不变。

你现在打开应用商店,把你想做的那个东西搜一下,大概率已经有几个人做完了,大部分都凉了,还有一个半死不活。你去 GitHub 上搜一下,同类项目 star 数比你多的有一堆,但 90% 的程序员思路还没转过来。他们花半年时间写代码,架构设计得非常优雅,UI 打磨得非常漂亮,心里想的是这东西做好了,用户自然就来了。但酒香也怕巷子深,现在的市场环境早就变了。

从经济学的角度看,这是一个典型的供给侧过剩问题。当某个领域的生产者数量远超市场需求时,利润空间会被极度压缩。编程门槛的降低和 AI 工具的普及,让供给侧的涌入速度进一步加快。你今天能想到的点子,地球上另外 1000 个人同时也在想,其中 100 个人已经开始写了。你凭什么认为自己是那个能杀出重围?

普通人想要在这行创业,第一步不是在 IDE 里敲 hello world,而是在心里默念:我要搞推广,我要搞销售。这句话听起来像成功学的鸡汤,但如果你真会搞推广,你就会有一大堆人帮你把产品做出来。市面上已经有一大堆做好的产品等着你挑,你随手就能把他们辛苦种出来的果子摘走,装进自己的口袋。你挣的钱可能比他们还多,因为他们的思路还卡在生产端,还在研究技术选型、研究怎么把东西做得更完美,而你研究的是谁会买、从哪买、为什么买你的。

一套不花钱的方法

具体怎么干,有一套一分钱不花的方法。

第一步,拿一张纸,假设你明天要离职 all in 做这个产品,那你现在得想清楚哪些事。用户到底是谁,他们现在用什么办法解决这个问题,愿不愿意掏钱,竞品有哪几个,做出来要多久,服务器和 API 一个月烧多少钱,第一批 100 个用户从哪里来,有哪些坑必须提前避开。列完之后,你读给 AI 听,让它帮你补充完善。完成后你就有了一个东西,一个不上线产品之前的产品清单。先纸上谈兵一点都不丢人,反而是好事,动动嘴是不花钱的。

这里有个关键细节,很多人列清单的时候会陷入一种幻觉,把自己的产品想象得过于完美。建议你在清单里加一个问题:用户为什么不选现有的解决方案,而要用你的?如果你的答案只是”我的更好用”或者”我的更便宜”,那说明你还没想清楚。用户迁移的成本远比你想象的高,他们需要重新学习、重新适应、冒一定的风险。你必须给出一个足够强的理由,强到让他们愿意放弃现有的习惯。

第二步,你拿着这张清单,把市面上同类型的产品全部用一遍。不是看一眼官网,是真注册、真跑完整个流程,该付费的付费,该免费试用的免费试用。一边用一边对着你的清单打分,这个活得好的好在哪,那个已经死了的死在哪,全部记下来。

有人在这一步犯了一个错误,只看了头部的几个竞品就下结论了。建议你把搜索范围扩大到前 20 名,不仅要看活得好和死掉的,还要看那些半死不活的。那些半死不活的产品最能说明问题,它们为什么没死透,但又活不好?是什么因素限制了它们的增长?这些问题想明白了,你对市场的理解才算到位。

第三步,把你的观察发出去。写篇文章也行,录个视频也行,发个帖子也行,就讲你测评的这几个产品,讲讲你看到的这些坑。现在是短视频时代,录个视频是最快的传播方式。这些不花钱的事情做完,你会走向三种完全不同的结局。

三条出路

第一种结局,你发现你想做的那玩意,市面上 10 个有 9 个都凉了。恭喜你,你省了半年时间和你攒下来的那点积蓄。这就是挣钱。省钱就是赚钱,这个道理很多人都懂,但真正能做到的很少。大多数人都是不撞南墙不回头,非得花半年时间证明自己错了才死心。你现在用三个月的调研时间,避开了别人六个月的沉没成本,这笔账怎么算都划算。

一个朋友,想做一款面向自由职业者的项目管理工具。他花了一个月时间做调研,发现这个赛道已经有 30 多个竞品,其中 25 个已经停止更新,剩下的 5 个月活跃用户不超过 1000。他算了一笔账,就算他做到最好,也只能分到一杯羹,而且获客成本极高。他放弃了这个想法,转而去研究自由职业者真正的痛点,最后发现他们最大的问题不是项目管理,而是如何稳定获客。他转向做了一个自由职业者接单社区,半年后月流水超过了 2 万。

第二种结局,你通过这一轮测评,对这件事的理解真的变深了。这时候你再动手写代码,你会写得非常明白。你清楚哪一部分是用户真正愿意付钱的,哪一部分是你自己写得开心但用户不在乎的。你的成功率高得多,因为你做得更明白了。这种理解不是看几篇竞品分析文章能获得的,必须亲身去体验、去付费、去感受那个购买决策的过程,你才能理解用户真正的痛点在哪。

有个做笔记软件的例子很典型。一个开发者想做一款面向程序员的笔记工具,调研了市面上所有的主流产品。他发现一个现象,所有笔记软件都在强调”组织”和”检索”,但程序员真正的痛点是”快速记录”。程序员在写代码的时候,思路不能被打断,他们需要一个能在一秒内打开、三秒内记录的工。他后来做了一款极简的剪贴板增强工具,上线第一个月就获得了 2000 多个付费用户。

第三种结局,也是最有意思的一种。你的分享会吸引很多人,失业的兄弟、想转型的、想找解决方案的小老板,都会来找你。你最后可能变成这个细分领域里边的一个产品专家。到那时候,你想自己做产品就做,不想做就给那些你测评过的产品做分销、做渠道、做流量。你会发现所有做产品的人都在给你打工,都跑过来求着你帮他推一推。大概走到这一步,你根本不想写代码了。

推广的本质是建立信任

这个路径的关键在于理解推广的本质。推广不是推销,不是忽悠,而是建立信任和匹配需求。你做测评、写分析、录视频,这些行为本质上是在建立你在某个细分领域的专业度和信任度。当用户相信你懂这个领域,他们就会来找你推荐解决方案。当产品方看到你有精准的用户群体,他们就会来找你合作。你成了连接供需两端的桥梁,而桥梁是要收过路费的。

网红最后为什么都去带货了,不是因为带货轻松,而是因为各行各业都缺销售。缺什么你就去干什么,这是最朴素的供需关系。

从心理学的角度看,用户在做购买决策时,面临的最大障碍是不确定性。他们不确定这个产品是否真的能解决他们的问题,不确定这个价格是否合理,不确定售后服务是否靠谱。一个值得信任的推荐者,可以极大地降低这种不确定性。这就是为什么 KOL 的推荐转化率远高于广告。用户不是在买产品,而是在买一个降低风险的保险。

这也解释了为什么有些人做测评、做分享,最后能建立起庞大的影响力。他们不是在推销产品,而是在帮助用户降低决策成本。这种价值是真实存在的,用户愿意为这种价值付费。

程序员的思维盲区

程序员这行有个很大的思维盲区,我们太习惯用技术思维解决问题了,这是技术工作者骨子里的傲慢。看到一个问题,第一反应是写个脚本、做个工具、建个系统。但技术只是解决问题的手段之一,而且往往不是最高效的手段。很多时候,一个 Excel 表格、一个微信群、一份文档就能解决的问题,非要写个系统出来,反而是过度工程化。

创业也是一样。不是所有创业都需要写代码。先验证需求、先建立渠道、先积累用户,这些工作都不需要写代码。等你把这些事情都想明白了、验证清楚了,再动手写代码,这时候你写出来的东西才是真正有商业价值的,而不是自嗨的玩具。

我见过太多程序员花了半年时间做了一个自认为完美的产品,结果上线后发现根本没有用户愿意付费。原因就是他们在一开始就没有想清楚谁会用、为什么用、为什么付费。这些问题不是靠写代码能回答的,必须靠市场调研、用户访谈、竞品分析来回答。

更深层次的原因在于,程序员天生对技术有热情,对推广销售有抵触。我们享受写代码时的心流体验,但不喜欢跟陌生人打交道、不喜欢被拒绝、不喜欢谈论钱。这种心理偏好让我们本能地选择了自己擅长且舒适的事情,而回避了那些真正重要但不擅长的事情。这是一个典型的舒适区陷阱。

要突破这个陷阱,需要认识到一个事实:商业世界不关心你的代码有多优雅,只关心你能解决什么问题。用户买的不是代码,而是问题的解决方案。一个能卖出去的半成品,远胜过一个卖不出去的精良作品。

这条路对普通人性价比最高

不写代码也能赚钱,核心在于把自己从生产端转移到销售端。在生产过剩的时代,推广销售是稀缺资源。你能卖出去,就有人帮你生产。你能找到用户,就有人帮你做产品。你能建立渠道,所有做产品的人都会来求你合作。

这不是说技术不重要,而是说在当前的市场环境下,销售能力比技术能力更稀缺、更有商业价值。一个会写代码又懂销售的人,比一个只会写代码的人,创业成功率高得多。但如果你只能选一个,我建议你先学销售。

从投资回报的角度看,学习销售的边际收益也更高。技术能力的提升需要持续投入大量时间,而且技术更新迭代很快,你今天学的东西可能明年就过时了。但销售能力是一种底层能力,一旦掌握,终身受用。无论是卖产品、卖服务、还是卖自己(求职),销售能力都能给你带来持续的回报。

这条路看起来绕,但走起来最稳。这个时代对普通人性价比最高的路不是生产,是销售。各行各业都一样,缺什么就干什么。现在最缺的是销售,那你就去做销售。

2026 年 10 月 31 日,DeepSeek Harness 团队发布技术长文《Super-agent 设计探索:迈向更自主的 Agent 系统》,同一时刻把一个名为 dsh-superagent-prototype 的仓库推上。五天之后,仓库 star 数 19.2 K,fork 2186。

阅读全文 »

2026 年 9 月 15 日,TypeSafe AI 发布了一个名叫 Jev 的 AI 模型。Jev 不是在通用模型能力上更进一步,而是在决策判定这个细分领域单开了一页。在一个所有人都在卷生成能力的时代,TypeSafe AI 选择了一条完全不同的路,专注于解决工程落地中对快速、准确且结构化的决策判定的诉求。

Jev 绝不仅仅是一个特别快、特别便宜的分类模型,它真正的目标是:AI 的输出是否可以不再是自然语言文本,而是直接成为程序控制流中的类型化值? 所以我认为 Jev 是一种新的 AI 基础设施:判定模型(Decision Model)。

阅读全文 »

一、问题的起点

在使用 OceanBase 的过程中,大家有几乎都遇到过一个场景:按时间范围分区的表,分区需要提前手动创建。忘记创建新分区,数据写入时直接报”找不到分区”的错误;手动建了太多分区,空分区的元数据又成了维护负担。对于日志表、订单流水表这类数据有明确生命周期的场景,DBA 还要定期清理过期分区,稍有不慎就可能导致数据丢失或线上故障。

OceanBase 从 V4.3.5 BP2 开始引入动态分区功能,试图将”分区的创建与删除”从 DBA 的日常运维中彻底剥离。需要首先澄清的是,动态分区不是一种全新的分区类型,而是在 RANGE / RANGE COLUMNS 分区之上叠加了一层自动化管理策略。理解它的设计逻辑和适用边界,比单纯掌握语法更有价值。

阅读全文 »

一、背景

2026年8月13日,DeepSeek 正式开源了 Harness 开发者预览版。项目在 GitHub 上线一个多小时便突破 2 万 Star,一天后即突破 92 万 Star,影响广泛。
alt text
从 5 月份组建 Harness 团队,到 7 月开启内测,再到 8 月以 MIT 协议完全开源,前后不到 3 个月。这个节奏表明,DeepSeek 此次并非只是发布一个新工具,而是在产品战略上进行了一次方向性调整。


阅读全文 »

2026 年 7 月 10 日,OpenAI 发布了 GPT-5.6。

如果只抓一个核心变化:大模型正在从聊天机器人变成能干活的智能体。过去你问它问题,它给你答案;现在你给它目标,它能自己规划步骤、调用工具、协调多个 Agent 并行工作,最终把任务完成。效率层面,GPT-5.6 在编程、知识型工作、网络安全和科学领域都交出了不错的数据,Token 用量和成本都在下降,任务完成率在上升。

阅读全文 »

一、组件介绍

JetCache 是阿里巴巴开源的通用缓存访问框架(开源地址),它做了一件事:用统一的 Cache<K, V>接口,把本地内存缓存和远程 Redis 缓存无缝组合起来,再通过注解、API 两种方式定义出标准的缓存协议接入层,让业务代码以最简洁的方式使用缓存。

和 Spring Cache 比,JetCache 的核心优势:

能力 Spring Cache JetCache
TTL(超时时间) 不原生支持,需自定义 原生支持,注解上直接写 expire
两级缓存 不支持 原生支持 CacheType.BOTH(本地 + 远程)
缓存自动刷新 不支持 支持 @CacheRefresh,分布式全局唯一刷新
穿透保护 不支持 支持 @CachePenetrationProtect
分布式锁 不支持 内置 tryLock / tryLockAndRun
异步 API 不支持 支持(Lettuce 客户端下真正非阻塞)
统计监控 需第三方 内置 命中率、加载次数等统计
更新/删除缓存注解 有但功能弱 @CacheUpdate / @CacheInvalidate 支持 SpEL

alt text

二、核心概念

阅读全文 »

一、组件介绍

JD-HotKey 是京东开源的实时热点 key 探测与缓存中间件(开源地址),它做了一件事:在高并发场景下,自动发现热点 key,毫秒级推送到所有应用节点的 JVM 内存中,让热点请求直接在本地内存响应,不再打到 Redis 和数据库。

经典场景:某明星突然官宣,相关商品瞬间涌入海量请求。你事先根本不知道这个商品 ID 会变热,Redis 某个节点被这些请求打得 CPU 飙升——这就是典型的不可预知突发热点。

这时候你就需要 JD-HotKey:它能自动发现这类热点,把数据”镜像”到每台应用服务器的本地内存里,后续请求直接从内存读,RT 从几十毫秒降到 < 1ms。

和直接用本地缓存(比如 Caffeine)比,JD-HotKey 的核心优势:

能力 Caffeine 本地缓存 JD-HotKey
热点发现 手动配置,你得提前知道哪些 key 要缓存 自动探测,根据访问量实时判定
动态性 静态的,配了就一直在 自动加入 / 退出热点,冷了自动释放内存
多节点一致性 各节点独立,互不知情 全局统一判定,所有节点同步感知
适用场景 已知高频数据(如字典、配置) 不可预知的突发热点(如秒杀、热搜)
部署复杂度 低(纯 SDK) 中等(需要 etcd + worker)
热用户 / 热接口探测 不支持 支持(不只限 key,接口、用户也能探)

简单总结:已知的热点用本地缓存就够了,不可预知的热点用 JD-HotKey。

二、核心架构

阅读全文 »

背景

当系统从单个 Agent 进化到多个 Agent 协作,通信设计就成了决定系统成败的核心变量。系统跑起来之后,最大的挑战不是单个 Agent 的能力,而是 Agent 之间怎么高效、准确地传递信息。一个审查任务平均经过 4 个 Agent 的接力处理,每个环节的理解偏差都会在后续链路中被放大。

通信设计决定了 Multi-Agent 系统是高效协作还是各自为政。单个 Agent 像一个独立工作的程序员,能力再强也有天花板;多个 Agent 组成团队,就需要设计好沟通机制:谁向谁汇报、用什么格式交流、出了问题怎么兜底。

这篇文章从三个维度拆解 Multi-Agent 通信:拓扑(谁跟谁聊)、机制(数据怎么流)、协议(聊什么格式),然后分析工程落地中的失败模式和成本控制策略。

阅读全文 »

过去 50 年,人机交互经历了 CLI 到 GUI 再到 Web 的演进。Shopify CEO Tobi Lütke 最近转发了一条动态,让我注意到了一个叫 flipbook.page 的实验性产品。它被描述为”一个完全按需实时生成的无限视觉浏览器”,核心理念是:你看到的每一页都是一张 AI 实时生成的图片,没有 HTML、没有 CSS、没有 JavaScript,一切皆为像素。

阅读全文 »