惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园 - 【当耐特】
Stack Overflow Blog
Stack Overflow Blog
V
Visual Studio Blog
小众软件
小众软件
The Cloudflare Blog
T
Tailwind CSS Blog
Apple Machine Learning Research
Apple Machine Learning Research
爱范儿
爱范儿
美团技术团队
WordPress大学
WordPress大学
罗磊的独立博客
Microsoft Azure Blog
Microsoft Azure Blog
A
About on SuperTechFans
Last Week in AI
Last Week in AI
月光博客
月光博客
博客园 - Franky
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
G
Google Developers Blog
GbyAI
GbyAI
B
Blog
大猫的无限游戏
大猫的无限游戏
博客园 - 聂微东
Hugging Face - Blog
Hugging Face - Blog
博客园 - 叶小钗

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
做AI系统别为了技术概念把架构做重 – 人人都是产品经理,
鸣老师 · 2026-04-22 · via 人人都是产品经理

在AI系统设计中,简单往往比复杂更有效。本文通过多模态文件处理和短视频脚本优化两个实战案例,揭示了过度设计的陷阱——从图片解析的RAG化到脚本生成的架构膨胀,作者用亲身经历告诉你:满足核心需求的轻量方案,往往比追求技术概念的复杂系统更实用。

「本来我们想做的事情比较简单,对AI很友好,现在又好像变得很复杂。」

这是我最近在做AI Agent内容生产系统时的真实感受。

一开始想的很简单,做着做着就想加东西,然后发现架构越来越重。

今天聊聊怎么避免把简单的系统做复杂。

先说多模态文件处理这个问题。

我们在做的系统需要处理用户上传的文档,文档里可能有图片。

第一次调用模型解析图片内容没问题,但如果后续需要检索整个文件,就会重复解析图片。

重复解析带来不必要的消耗。

我最开始想的方案是做预处理。

提前对文档里的图片做解析,把解析结果按等级存在meta信息里。

后续需要使用时直接调取预解析结果,避免二次解析。

听起来挺合理的对吧。

但讨论着讨论着方案就膨胀了。

有人提出可以让AI自行对文档切块,不需要提前手动切分。

图片也可以做embedding后和文本一起检索。

听起来更智能了。

但这个方案延伸后会变成每个文件夹每个文档都单独做RAG。

会非常依赖向量数据库,让整个文件系统变重。

这就偏向传统RAG的架构了,偏离了原本做轻量AI友好型文件系统的初衷。

全量RAG化还会带来其他问题。

请求队列管理变复杂,内容更新顺序监测难以实现。

对比RagFlow,提前分目录再做RAG的粒度更细,但整体架构还是过度设计。

最后我们决定回到原点,只做图片预处理这个轻量方案。

不是所有场景都需要全量RAG。

再说脚本优化的事。

我最近在想怎么让AI生成更好的短视频脚本。

当前脚本结构已经合格了,但有些话术是过去在用的,现在已经不用了,关键词需要随时间更新。

还有过度润色的问题,有时候为了抓注意力盲目追求口语化,反而不自然。

脚本的核心难点在于平衡。

怎么在开头抓住注意力,同时在过程中不断设置刺激点。

两秒一个刺激点或者五秒一个刺激点,这个节奏很难把握。

我测试了一些方法,发现从提示词层面优化效果比改架构要好。

不需要做复杂的系统改造,调好提示词就够了。

做AI系统最大的教训就是。

简单够用比什么都重要。

不要为了凑技术概念把架构做重。

预解析meta信息可以满足基础多模态需求,不需要上全量RAG。

脚本优化从提示词入手,不需要做复杂的生成系统。

在满足功能需求的前提下,尽量维持架构简洁。

为边缘需求做过度设计只会拖慢进度。

以上,既然看到这里了,如果觉得不错,随手点个赞、在看、转发三连吧,如果想第一时间收到推送,也可以给我个星标⭐~

谢谢你看我的文章,我们,下次再见。

/ 作者:鸣老师

本文由 @鸣老师 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议