#自媒体运营频道 #@yunying23
小红书这个平台的审核为什么会这么恶心呢？前年曾经玩过两个月小红书，我当时发现自己发的帖子基本上10条有8条是被限流的，而只要不被限流的内容基本互动数据都非常好。
被限流的原因就是个黑盒，有时候换几个关键词重发就可以解除，有时候就是一些莫名其妙的原因。比如说前年发过一条分析茶百道招股书的帖子，后来发现和茶百道相关的内容当时都被小红书限流了，原因是因为有加盟商在闹事…
这样的事情经历多了就会特别恼火，原本只是想在发点有意思的东西玩玩，但接二连三的限流让我彻底断绝了发帖的欲望。真的很好奇小红书在这方面到底是怎么想的，有没有朋友可以说说？
小红书这个平台的审核为什么会这么恶心呢？前年曾经玩过两个月小红书，我当时发现自己发的帖子基本上10条有8条是被限流的，而只要不被限流的内容基本互动数据都非常好。
被限流的原因就是个黑盒，有时候换几个关键词重发就可以解除，有时候就是一些莫名其妙的原因。比如说前年发过一条分析茶百道招股书的帖子，后来发现和茶百道相关的内容当时都被小红书限流了，原因是因为有加盟商在闹事…
这样的事情经历多了就会特别恼火，原本只是想在发点有意思的东西玩玩，但接二连三的限流让我彻底断绝了发帖的欲望。真的很好奇小红书在这方面到底是怎么想的，有没有朋友可以说说？
如果你在使用Next.js 框架，刚好还在用 Better Auth 对接登录，也要使用 Stripe 支付，那推荐看看 Better Auth 提供的Stripe 插件，地址：https://www.better-auth.com/docs/plugins/stripe 。可以一次性集成网站中核心的登录&支付，极大降低开发工作量。
并且官方还有 demo，提供完整的登录、支付、管理后台源码，还有线上体验地址：https://demo.better-auth.com/。源码地址：https://github.com/better-auth/better-auth/tree/main/demo/nextjs
作为曾经使用过 Nuxt 开发的人来说，由衷的感慨使用 Next.js 的便利性，很多插件、模板等都会有 Next.js 版本，开发效率++
并且官方还有 demo，提供完整的登录、支付、管理后台源码，还有线上体验地址：https://demo.better-auth.com/。源码地址：https://github.com/better-auth/better-auth/tree/main/demo/nextjs
作为曾经使用过 Nuxt 开发的人来说，由衷的感慨使用 Next.js 的便利性，很多插件、模板等都会有 Next.js 版本，开发效率++
浅谈这段时间开发 AI Agent 的局限性和难点
1：LLM + Tools 局限性：
- 常见场景：Chatbot 为主的（FuntionCall、MCP）
- 局限性：长链路的延迟和幻觉、多步骤的模型注意力有限、上下文受限、工具规模管理问题、Tools 与模型相互弱化。缺少记忆、规划、流程管理的能力，Agent 状态持久化开发成本高，单次 LLM 处理能力有限，多轮对话上下文太高
2：LLM + Tools + Memory（代表 langchainJS）
- 场景：存储用户对话和个人偏好、以及使用习惯等等个性化场景，成为用户的第二分身。
- 局限性：见第 1 点，缺少复杂流程链路的管理，比如某个节点出现问题、中断、循环问题（比如生成代码）、hunman介入，无法从原来的位置恢复，分支逻辑等等
3：LLM + Tools + Memory + workflow（代表 langgraphJS）
- 场景：类似于 Manus、Genspark 代表等等 Planing Agent
- 局限性：对上下文要求高，需要训练小模型，大量的工具维护与开发，对资源需求很高、还要设计复杂的 AgentState，需要贯穿整条workflow，可能还涉及子图，前后端协议
4：LLM + Tools + Memory + workflow + Protocol（Google Adk + A2A协议）
- 场景：富文本信息流（AI 每条消息可能有长文本、视频、图像、文件等）类似于 Manus、Genspark 信息流。
- 局限性：需要对接与设计 Agent 2 Agent 之间和 富文本 UI 的数据协议，特别是数据流的前后端的时序处理（细节特别多），复杂度和开发成本高，需要训练更多的数据来提升增强每一个环节的效果。
我个人认为第 4 点的难点在于对于复杂业务系统的实现，常见的是代码生成。需要具备指定场景的项目经验，构建架构和模板项目提供样板支撑，才能保证每次生成的效果非常好。且每次涉及Bug调整和修改都有可能进入死循环（参照 cursor / cline）
抛砖引玉，有限的经验分享
1：LLM + Tools 局限性：
- 常见场景：Chatbot 为主的（FuntionCall、MCP）
- 局限性：长链路的延迟和幻觉、多步骤的模型注意力有限、上下文受限、工具规模管理问题、Tools 与模型相互弱化。缺少记忆、规划、流程管理的能力，Agent 状态持久化开发成本高，单次 LLM 处理能力有限，多轮对话上下文太高
2：LLM + Tools + Memory（代表 langchainJS）
- 场景：存储用户对话和个人偏好、以及使用习惯等等个性化场景，成为用户的第二分身。
- 局限性：见第 1 点，缺少复杂流程链路的管理，比如某个节点出现问题、中断、循环问题（比如生成代码）、hunman介入，无法从原来的位置恢复，分支逻辑等等
3：LLM + Tools + Memory + workflow（代表 langgraphJS）
- 场景：类似于 Manus、Genspark 代表等等 Planing Agent
- 局限性：对上下文要求高，需要训练小模型，大量的工具维护与开发，对资源需求很高、还要设计复杂的 AgentState，需要贯穿整条workflow，可能还涉及子图，前后端协议
4：LLM + Tools + Memory + workflow + Protocol（Google Adk + A2A协议）
- 场景：富文本信息流（AI 每条消息可能有长文本、视频、图像、文件等）类似于 Manus、Genspark 信息流。
- 局限性：需要对接与设计 Agent 2 Agent 之间和 富文本 UI 的数据协议，特别是数据流的前后端的时序处理（细节特别多），复杂度和开发成本高，需要训练更多的数据来提升增强每一个环节的效果。
我个人认为第 4 点的难点在于对于复杂业务系统的实现，常见的是代码生成。需要具备指定场景的项目经验，构建架构和模板项目提供样板支撑，才能保证每次生成的效果非常好。且每次涉及Bug调整和修改都有可能进入死循环（参照 cursor / cline）
抛砖引玉，有限的经验分享
❤1
To C 产品，终究是用产品挣得用户心智；To B 产品，才需要持续不断地“搞定人”。
如果你做的是 To C 产品，且职位没到中管（什么是中管，阿里P10、字节4-2、腾讯总监、百度M3a）就有大量所谓搞定人的事，而不是做用户喜爱的产品、打磨好的用户体验、尝试优秀的技术选型和探索最强模型的能力边界，就足以证明，所在的组织已经在下坡路上了。
你要做的就是低功耗的提升自己，保护好自己的下属们，不要陷入到天天搞定人的深渊里。
爱搞定人，就别干互联网了。
互联网行业就是热爱极致的疯子们创造的。
他们最讨厌的事，就是需要搞定人才能苟活的平庸。
如果你做的是 To C 产品，且职位没到中管（什么是中管，阿里P10、字节4-2、腾讯总监、百度M3a）就有大量所谓搞定人的事，而不是做用户喜爱的产品、打磨好的用户体验、尝试优秀的技术选型和探索最强模型的能力边界，就足以证明，所在的组织已经在下坡路上了。
你要做的就是低功耗的提升自己，保护好自己的下属们，不要陷入到天天搞定人的深渊里。
爱搞定人，就别干互联网了。
互联网行业就是热爱极致的疯子们创造的。
他们最讨厌的事，就是需要搞定人才能苟活的平庸。
过去决定不了现在，是现在决定过去，你对过去的解读，这是你个人过去的唯一定义权。
你看待过去的角度和态度，才决定了真实的过去是什么。
钢炼的爱德华有卖过惨吗？火影的鸣人是不是应该比任何人都应该黑化？
现实中也一样，很多人有所谓痛苦的过去，依然坚定自己是一个成年人，努力成为自己想成为的人，对自己负责。
而不是张嘴就是原生家庭，童年教育，成长经历。
离开深渊的方式，只有往前走，一条路。
你看待过去的角度和态度，才决定了真实的过去是什么。
钢炼的爱德华有卖过惨吗？火影的鸣人是不是应该比任何人都应该黑化？
现实中也一样，很多人有所谓痛苦的过去，依然坚定自己是一个成年人，努力成为自己想成为的人，对自己负责。
而不是张嘴就是原生家庭，童年教育，成长经历。
离开深渊的方式，只有往前走，一条路。
Shunyu Yao 的那篇《AI 的下半场》放在窗口一周了，刚刚读完…
我理解他核心想表达的意思是：AI 的上半场比拼的是模型与算法（谁能把 ImageNet、MMLU、HumanEval 的分数再抬 2 %，谁就是论文第一作者），下半场我们应该回到产品经理式的思维，该让 AI 去解决谁的、什么真实痛点，再倒推“怎样衡量真正的进步”
如果说上半场的 AI 是 Researcher 和 Engineer 驱动，下半场的 AI 可能就要看各位 PM 的了：如何连接效用与技术
但对 PM 的要求可能会比以往更高，比如能把宏大战略拆成“当下 AI 真能做、做了真有用”的最小切片，并用可量化的技术债清单驱动团队迭代
所以首先应该判断一个需求需要几级 AI 能力（L1-L5），再和团队讨论：我们今天稳定可落到哪一级，差的那几级成本多大，而不是得出粗暴的结论，能做和不能做
不过这个时候提出下半场，是不是说明沿着过去的技术路线收益真的放缓了啊 🤣
—————
题外话：之前大家以为 OpenAI 会一味追求 RL（强化学习），看 Shunyu 的分享看来人家很清楚 Pre-training 的 scaling law
"It turned out the most important part of RL might not even be the RL algorithm or environment, but the priors, which can be obtained in a way totally unrelated from RL.
事实证明，强化学习中最重要的部分可能甚至不是强化学习算法或环境，而是先验知识，而这些知识可以通过与强化学习完全无关的方式获得。"
我理解他核心想表达的意思是：AI 的上半场比拼的是模型与算法（谁能把 ImageNet、MMLU、HumanEval 的分数再抬 2 %，谁就是论文第一作者），下半场我们应该回到产品经理式的思维，该让 AI 去解决谁的、什么真实痛点，再倒推“怎样衡量真正的进步”
如果说上半场的 AI 是 Researcher 和 Engineer 驱动，下半场的 AI 可能就要看各位 PM 的了：如何连接效用与技术
但对 PM 的要求可能会比以往更高，比如能把宏大战略拆成“当下 AI 真能做、做了真有用”的最小切片，并用可量化的技术债清单驱动团队迭代
所以首先应该判断一个需求需要几级 AI 能力（L1-L5），再和团队讨论：我们今天稳定可落到哪一级，差的那几级成本多大，而不是得出粗暴的结论，能做和不能做
不过这个时候提出下半场，是不是说明沿着过去的技术路线收益真的放缓了啊 🤣
—————
题外话：之前大家以为 OpenAI 会一味追求 RL（强化学习），看 Shunyu 的分享看来人家很清楚 Pre-training 的 scaling law
"It turned out the most important part of RL might not even be the RL algorithm or environment, but the priors, which can be obtained in a way totally unrelated from RL.
事实证明，强化学习中最重要的部分可能甚至不是强化学习算法或环境，而是先验知识，而这些知识可以通过与强化学习完全无关的方式获得。"