现在整体的组织可能跟之前有个特别大的一个区别。

首先后台可能backend没有那么重，因为在上一个时代已经被做得足够好了。它的所有的可伸缩性和所有的高并发都能够很好的handle 。然后另外一个方面在于说是在前端可能很复杂的GUI也已经不太适合这个时代，因为用户的路径是很自由的，所以说更多的可能是简单的GUI 但是更多的配合CUI的方式。给用户更多自由度的探索。

然后关键的可能在于AI这一层，AI这一层可能要分为三层，是一个最简单的一个结构。最底下的这一层在于说是怎么样把索引，怎么样把memory 怎么样把agent memory这东西能够建好，使得说一方面整个系统是能够越用越好，另外一方面在于说用户越用越好，用户有很强的个性化。中间这一层需要去构建的是一套很健壮的agent架构，这个就有点像原来的 back end 那一端，但是现在的这一端主要去做的事情都是在于说是怎么样管理agent的runtime 怎么样去释放agent 怎么样去管理虚拟机。怎么样去把agent之间的context能够更好地传输，去做中间这一个多agent架构的一个更健壮的一个体系。最上面的这一层则是在于build更多的工具，build更多的agent 和skill 让整体中间那一层可以选择的agent和工具更多，从而使得整个生态和整个产品是具有一定的网络效应。因为工具越多，就可以通过更多的工具的组合来实现更多的功能。所以在这一层里面是具有很强的网络效应的。然后纵向还有一个拉穿三层的这样一个组织，也就是所谓的算法层，我姑且这样子命名。那么这一层衡量的分别是三层的输出结果和质量。因为还是希望说有一个跨整个AI平台的三层的这样的一个组织。能够把三层对应输出的效果，然后能够拉齐到一个比较好的一个高度，并且说是从全局贯穿的来看。

很有意思的一个点在于说是产品经理在这里面的角色是什么？会发现说产品经理可能可以在三个维度，包括说是在CUI的维度，都有一定的作用，但是一定不是纯产品的作用。产品经理可能既偏评测，也偏产品，也偏整体一定的开发。因为跟开发的沟通方式已经不仅仅只有文档，可能更多的是以代码，以 claud.md 的方式去进行沟通。而评测其实也不仅仅是说我去做一个Benchmark来做评测，更多的在于说是去定义到底什么东西是可以被验收的结果，这一个需求什么标准是可被验收的，什么是好的，并且说这个需求所约定的范围和环境，它可以用到的环境内的所谓的维度和资源（数据）到底是什么？可能产品经理需要跟研发，更多的是约束的是这些事情，而不是传统的user journey。因为user journey是不可被预测的，在更多时候，而且我们也不应该去更多的规定所谓的用户user journey 那么这个情况下，PM应该去设计的是可被自由探索的范围空间和对自由探索后结果的健壮性。

skills 教程不需要看其他的，把宝玉大佬的这个 github 仓库中的用起来，你就超越了 95% 的人

https://github.com/JimLiu/baoyu-skills/tree/main

红墨 - 基于 Nano Banana Pro🍌 的一站式小红书图文生成器
后端用Python，前端是Vue，AI核心是Gemini（负责写文案）和Nano Banana Pro（负责出图）。你只需要输入一个主题，它就能全自动生成6-9页的内容大纲，然后并行生成所有图片（只要你的API扛得住）。
https://github.com/HisMax/RedInk

@https1024

我知道骂百度已经成了政治正确，不过有一说一，它家最近新出的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，可远程、可兼职，而您就是买了一张彩票而已