我知道骂百度已经成了政治正确，不过有一说一，它家最近新出的PaddleOCR还是可以用一下的。

每天3000页的免费额度，足够扫描好多本电子书了。

于是，我vibe code了一个开源小工具，打包了PaddleOCR的API，然后在代码层面做了一些工程化的优化处理，确保扫描版的PDF文件能够转化成排版优雅的Epub格式电子书，去除PDF文件中不必要的页眉，页脚，页码等杂乱元素的同时，最大程度保留原书内的插图，表格等内容。

既然工具是vibe code出来的，那么它的使用也是vibe code友好的：你只需提前去百度AI Studio申请一个API Key，准备好你要转换的扫描版PDF文件，然后把我这个github repo链接丢给你的AI Agent，让它帮你操作就好啦。

百度家的羊毛，不薅白不薅！

Github Repo地址：

https://github.com/jarodise/pdf2epub-paddle

看完昨天@潘乱 @rosicky311_明浩 @阑夕ོ @一泽Eze 对元宝、千问和豆包的讨论，信息量很大，很多洞察非常透彻，值得反复回味。从大家的讨论里，我想到一个可能谈论得比较少的视角。

我们在分析时，无形中都在用同一把标尺去衡量它们：看看谁的增长更可预测，谁的生态协同更有效率，谁的商业模式更清晰。这套源于过去成功经验的标尺当然有用，它清晰地定义了什么是“好公司”。但我最近在观察行业里其他一些案例时，也在思考另一个问题：当我们只用这一把标尺时，会不会反而看不清一些正在发生的、本质不同的事情？

如果暂时放下这把标尺，看看别处正在发生的事情，可能会发现一些不一样的逻辑。

比如 xAI。它呈现出的状态和我们熟悉的传统科技公司有很大不同。在那里，工程师的工作价值被直接换算成明确的经济数字。驱动团队的常常是一个具体到极致的物理目标，有时甚至附带一个像“赢一辆赛博皮卡”这样直接的赌注。为了实现目标，他们可以重新解释甚至绕过常规规则。他们的思考尺度也很大，其蓝图甚至包含将全球范围内闲置的机器算力连接起来。这看起来不像在单单经营业务，更像是在运行一台为单一技术目标而组装的高精度机器，所有与最终目标无关的环节都被视为需要清除的障碍。

再看 Anthropic 和它的 Claude Code。这个产品的走红，背后是另一套完全不同的思路。它最初的火爆不在于多么宏大的叙事，而是用一种非常具体的方式，解决了一群核心生产者（也就是开发者自己）最切实的效率痛点。有意思的是，它本身就是被自己的工程师团队深度使用和塑造出来的工具，开发者和用户几乎是同一群人。这种“自己做的饭自己先吃透”的模式，让它的迭代紧紧扣住了真实的工作流。它追求的不是功能的复杂堆积，反而因为架构上的清晰和简洁，让开发者觉得可靠、可调试。最终，是无数个“这个功能帮我节省了十个小时”的真实故事，让它获得了爆发性的口碑。

这么一看就很有意思了。一边是 xAI 代表的“极限突破”逻辑，为了终极目标可以重新定义路径和规则。另一边是 Anthropic 代表的 “深度自洽”逻辑，它不追逐外部定义的赛道，而是让产品从核心生产者的真实工作场景中自然生长并完成闭环。它们暗示了一种新的可能：AI推动的进化方向或许不止是“更好的公司”，更大概率是“公司的某种新形态”。这两种组织形态都和那种追求均衡、可控和规模化的经典“商业公司”不太一样。

问题可能就出在这里。当一家成熟的大公司，试图用管理成熟业务的方法，去孵化或容纳一个遵循“极限突破”或“深度自洽”逻辑的项目时，那种不适感几乎是与生俱来的。用规划产品的流程去管理一场技术极限挑战赛，或是用市场占有率指标去衡量一个从内部工作习惯里自热生长出来的工具，便会立刻产生排异反应。这不仅仅是战略的兼容性问题，更像是一场 “组织免疫系统”对新基因的本能排斥。

所以接下来的关键可能不在于哪家的模型更强，反而是哪家的组织“兼容性”更好。哪家能在自己庞大的体系里真正留出空间，让一个只为解决纯粹技术问题而存在的“异类”团队活下去？哪家能允许一个产品像 Claude Code 那样，先是为了彻底改变内部少数人的工作方式而诞生，而非满足一个预设的商业蓝图？这考验的不仅是战略，更是组织架构能否容忍一场“可控的失控”。

从这个视角去看，元宝、千问、豆包在探索中遇到的各种具体困境，或许都是这种深层冲突在不同局部的体现。而 xAI 和 Anthropic 这样的存在就像是在提出一个根本性问题：当 AI 不再仅仅是一个需要被商业化的新技术，开始催生新的工作方式和组织逻辑时，我们过去所依赖的关于“公司”和“成功”的所有经验和尺度，是不是也应该被重新审视了？

因此，未来的较量可能不仅限于战略上的果断，更要看谁敢于付出必要的代价，完成一场针对自身组织基因的可控编辑，从而为全新的想象力和可能性腾出空间。

求一个产品负责人，武汉，15-20K

AI时代下，一切的形式都没有意义，如果您很NB，可远程、可兼职，而您就是买了一张彩票而已

叮咚买菜的创始人梁昌霖，是中国创业者中少数具有军人背景的。当年考大学时，他进入一所军校，学习电子对抗，大学毕业后继续在部队服役。

2002年，梁昌霖从部队退役。

梁昌霖的偶像是同为军人出身的任正非，他对《新民晚报》的记者说：“任正非退伍后，43岁才开始创业，不惑之年始见春，一手把一个小公司变成了世界瞩目的科技巨头。

我可以用自己的努力来证明，咱当兵的人，到哪里都能做出一番事业来。”

叮咚买菜的团队中有200多名退役军人，公司的8名核心骨干中有4名是当过军人。

文 | 《沸腾新十年》

万即：有云厂商或提供这类服务的朋友吗？支持自动化部署 “云主机”，场景是：用户使用我们的产品会在云端开个云主机（7×24 小时那种，不是 8 小时就失效了），但现在各大云厂商提供的是 k8s 或 docker， 部署不是自动化的

三只羊拿下无语哥全球运营权，三只羊无语哥公司估值9.75亿美元。

以前在团队里做产品研发协作，我其实一直想推两件事：
- 测试优先（把不确定性前置）
- 可发版的独立模块迭代优先（让交付变得可控）

核心目的很简单：把「需求理解不清晰、实现效果不可控」这种坑，尽量前置到需求讨论和技术方案阶段解决掉。

但现实是：对齐成本太高、太消耗精力。让大家从 0 写文档、补流程、写验收标准，往往既痛苦又写不全。过程文档留得少，经验也很难沉淀——每次都像重新来一遍。最后只能作罢。

直到最近自己开始 vibe coding，手搓一个可发布的小产品，开发工作流才第一次变得异常清晰：需求澄清 → 分步迭代方案 → 交付物定义 → 回归 → 发版门槛

这一整套，不再是“理想”，而是可以很轻量地执行。
原因也很简单：AI 天生适合干那些“琐碎但关键”的事---写规格、补边界、列验收点、补回归用例、补变更记录……

人只需要做高价值部分：讨论、提意见、给上下文、做选择、做最终验收。

所以我逐渐冒出一个暴论
：
vibe coding 时代，如果研发协作还停留在：产品经理拆需求 + 复杂评审同步上下文 + 研发主要让 AI 写代码。那团队效率可能还不如一个人单干。

因为真正的瓶颈不在“写代码”，而在“上下文对齐”和“交付可控”。

当下团队要交付的，也许不该只停留在模块级代码，而应该是：在架构拆清楚之后，每个人都能独自交付可上线的产品功能（feature）。

只有这样，才算团队效率真的上来了。

也许一个简单的衡量指标就是：能不能做到每天至少上线一个稳定feature？ 🤔

1. SaaS 被杀掉的是功能部分的溢价，堆功能并不能带来价值，入口将不会是一个个 admin，而是这次新增到业务流里的一个更轻的载体，它叫 All-in-one Chatbot

2. 之前做 SaaS 产研常挂在嘴边的一句话是：前端个性化，后端标准化。这次是：前端变薄，后端变厚。看看 Claude 就知道了，前端一个输入框，后端从一开始的 connectors，到前段时间的 skills，再到近期的 plugins

3. AI Agent 的瓶颈不在模型，运行环境才是核心，准确说，从正确的地方拿正确的数据才是核心，面向企业场景的 AI Agent，day one 就要把精力花在 integrations 上，integrations 是 must-have 啊兄弟们！

4. 过去 SaaS（至少在北美）的 vertical 造成的后遗症是企业越大数据越分散，之前 grammarly CEO 在 podcast 里分享整家公司共订阅了 972 个 SaaS 工具，很早前听 Notion 的朋友说他们也买了 300+ SaaS，今天的 Agent 天然是跨系统的，如果要解决真问题还必须得跨系统行动，“哪个系统拥有哪类上下文” 是 agent 执行环境的基建

4. 有些 SaaS 会死掉，有些 SaaS 会演变成带 API 的状态机，特么的 AI Agent 原是个筛选器（但我的 shopify 为什么跌 😅）

#一张截图价值3000亿美金 😂

#出海运营秘籍👉@yunying23

团队小伙伴最近在搞视频号，被这个平台的带货转化率有点吃惊。