企业官网建设流程全解析

最近有个创始人的万字复盘在AI应用开发圈子里刷屏了。标题第一句就很扎眼：AI应用死于自研模型的技术虚荣，真正护城河不在模型本身。我身边做产品、做技术的朋友几乎都在转，因为这句话戳中了过去两年无数应用团队最痛的穴位。

我自己做过好几个AI应用项目，特别能理解为什么大家一听到“自研模型”四个字就兴奋。但从产品能不能活下来的角度看，模型层还真不是大多数应用团队应该待的地方。这篇文章想结合那篇复盘里的思考和我自己踩过的坑，把这件事拆开聊清楚：技术虚荣是怎么一步步养成的，自研模型的机会成本有多高，真正的护城河到底应该建在哪一层。

1. 技术虚荣的根源：为什么大家明知要应用优先，还是忍不住自研模型

1.1 “不做底层就是没壁垒”的技术执念

很多做AI的工程师天然崇拜模型层。从研读论文、参加学术竞赛到社区讨论，大家的评价标准都指向同一个方向：你能不能做出更强的算法、更大的模型、更低的损失函数。在这种语境里，“做应用”听起来像退而求其次，而“训练一个几十B参数的基座模型”才是真正的技术皇冠。

这种心理不是某个团队的问题，是整个行业共同滋养出来的一种惯性。复盘里提到，他们最开始立项做AI视频生成时，第一版方案竟然不是“接入市面上最好的视频生成能力”，而是“要自己训练一个视频基础模型”。方案评审会开了很久，没人提出异议，因为所有人心里都默认：如果用别人的模型，那我们的壁垒在哪里？

这种执念最危险的地方在于，它不是完全没有道理。自研模型确实能带来技术控制力，也确实可能在某些能力上做到差异化。但是执念一旦脱离业务需求，就会从“可选的战略路径”滑向“无法挣脱的技术虚荣”。做应用的重点应该放在用户体验、业务流程和数据闭环上，而不是把公司资源全部押进训练跑分里。

1.2 融资叙事和社区声量对模型叙事的偏爱

还有一个不太被摆上台面的原因：故事好不好听。过去几年的融资环境里，“我们自研了一个多模态大模型”确实比“我们用好了现成的模型，做了一套特别顺手的创作者工具”更容易让投资人坐直身体。很多AI应用团队在一开始就刻意把“自研模型”写进BP，不是为了业务需要，而是为了融资时抬高预期估值。

创始人复盘里提到一个很有代表性的细节：他们拿着自研视频模型的demo去路演，连续拿了三轮关注。每轮之后，团队信心都很足，觉得这条路走对了。但等到真正进入研发中期，他们发现自己被困在了一个非常尴尬的位置——投资人期待他们持续给出模型能力突破，产品用户却在等功能的稳定性。两边都要应付，资源就那么点，最后谁都没服务好。

复盘里对这件事的总结特别清醒：融资叙事能帮你上车，但决定你能走多远的是车轮下的路，不是贴纸上的标语。如果叙事本身和产品路径不匹配，越吹大，后面还债越痛苦。

1.3 技术虚荣不是道德问题，而是配错资源

我们必须承认，“技术虚荣”这四个字听起来很像态度问题，但它本质上是一个资源配置问题。一个团队选择自研模型，方向本身没有对错之分，问题出在“谁适合在哪里做研发”这件事上。大厂和头部技术团队有人才储备、算力储备、工程积累，他们有资格去冲击基座层。普通AI应用团队通常只有十几二十几个人，如果拿着这些资源去跟整个行业的大模型前沿赛跑，结果大概率是两头落空。

用个简单的类比：你开一家面馆，专注于汤头、浇头、门店动线和熟客服务，完全合理。结果你为了显示自己有“核心壁垒”，非要跑到郊区去建一个面粉厂，还花大价钱请来面粉工程师研发新品面粉。面粉也许确实更精致了，但顾客不会因为面粉是你自己磨的就多付一倍价格。他们关心的是面好不好吃，有没有人等位，汤是不是稳定。

那位创始人在复盘里的意思，其实就是想提醒所有应用团队：模型层确实重要，但它不是你的原始业务。你的原始业务是解决某个场景里具体用户的具体问题。把资源和精力配错位置，技术再漂亮，也终将被市场遗忘。

2. 算清这笔账：从算力账单到机会成本，自研模型让团队失去什么

2.1 一笔保守的成本估算：20人团队自研轻量级模型的开销

我见过不少团队在评估自研模型时，只算了“买几块卡”的钱，完全没算人力、数据、实验和失败重来的成本。实际上，模型研发是一项高度不确定的探索性工作，失败才是常态。拿一个20人的应用团队自研一个轻量级视频理解或生成模型来算，成本会远超大部分人的直觉。

下面是一份基于常见实践整理的保守估算表，团队规模和配置不同会有差异，但量级可以作为参考。

这里我还没计算最要命的一笔：由于团队重心偏向模型研发，产品功能迭代速度会明显变慢。同样20人，如果全部扑在应用层打磨，半年时间足够把核心体验迭代三轮以上；一旦分出七八个人去训练模型，产品只能小步挪。这笔账在财务报表上可能只是一个隐性的“研发费用”，在业务结果上却可能是生与死的差距。

2.2 机会成本：你调参的时候，公共底座已经迭代了一轮

自研模型最大的风险不是“做不出来”，而是“做出来的时候已经过时了”。AI基础模型的迭代速度非常快，今天还是瓶颈的能力，下个月可能就被公共底座补上了。你花三个月解决了某个技术痛点，抬头一看，外部模型已经把这个功能默认支持了，而且效果更好。

复盘里提到一个典型的场景：他们的视觉生成团队花了五个月优化人物手部细节，终于把“手指畸变”控制到了可接受范围。可就在同期，接入公共API的竞品已经可以直接生成更稳定的全身动作，连手指带光影都处理得干净利落。用户不会因为你“自研”就原谅你更差的效果，他们只看最终画面。

这才是真正的机会成本。你以为在做一件一劳永逸的事情，实际上是在跟一个比你大十倍、快十倍的引擎赛跑。当你终于追上它上一秒的位置，它已经跑到下一个未知区域去了。应用团队试图跟上这种速度，本质上就是用两条腿去追高铁。

2.3 团队结构也会被模型研发拖变形

长期自研模型还会改变团队内部的能力结构和话语权分配。算法团队因为在解决“最难的问题”，天然拥有更高的技术权威，产品、运营、设计的声音会越来越弱。一个个需求评审会上，产品经理提出的优化建议被算法工程师以“模型瓶颈”为由压下去，迭代节奏被训练实验完全绑架。

复盘里的团队就走到过这一步。到后期，他们整个团队中算法人员占比超过了一半，剩下的产品、前后端、测试都在围着训练任务转。产品负责人后来离职时说了一句很重的话：我们不是在做一个用户产品，是在做实验室项目。这句话至今都是我做团队结构设计时的警钟。技术人才占比过高不是好事，当研发方向跑偏时，越强的算法团队只会把车开得越远。

3. 复盘中的死亡路径：一款AI视频应用如何被模型研发拖垮

3.1 阶段一：对标SOTA立项，却没人定义“产品SOTA”

每一个自研模型的故事，都始于一个看起来很美的立项会。复盘里，团队的目标不是“解决创作者在剪辑中的某个具体痛点”，而是“让生成的视频质量超过市面上的某个领先模型”。于是团队开始疯狂刷公开数据集、复现论文、调整网络结构，但没有人认真问过：用户可感知的“好”到底是什么？

这就埋下了第一个隐患。模型领域的SOTA是一个相对清晰的学术指标，有评测集、有排序、有分数。但产品领域的SOTA非常模糊——用户是想要更快的生成速度，还是想要更具体的运镜控制，还是想要更稳定的角色一致？这些都没有在立项阶段被拆解清楚。团队在追逐一个漂浮在论文里的目标，和真实用户的需求之间产生了巨大的裂缝。

3.2 阶段二：模型研发节奏接管产品排期

到了执行阶段，模型研发的不确定性开始全面渗透产品排期。训练实验失败，产品上线时间推迟两周；数据清洗不达标，又一次推迟；效果评估不理想，再推迟。连续几次之后，团队形成了一个不可接受的默契：所有产品发布都以“模型ready”为前提，而不是以“用户价值ready”为前提。

复盘里有个细节让我印象很深：他们的内测用户一直在反馈一个非常具体的问题——上传的素材里如果有水杯、眼镜这类小物体，视频生成就会崩坏。这个问题明明可以在应用层通过预处理和后处理规避，但团队当时把所有资源都压在基座模型的重训上，导致这个Bug在三个版本里都没修复。用户走了很多，大家却还在关注Loss曲线是不是更漂亮了。这是最典型的“用技术指标替代用户体验”的信号。

3.3 阶段三：资源耗尽前，公共底座已经补上了所有能力

自研项目的下半场，团队开始觉察到前方有悬崖，但已经不太可能回头。因为模型训练已经耗费了巨大资源，所有人都希望“再坚持一下就能成功”。于是组织陷入了一种追逐沉没成本的状态。

结果在里程碑临近时，他们终于看到了那个最讽刺的局面：自己花了18个月训练出来的模型，和公共底座相比，不仅没有优势，反而在开放性和稳定性方面全面落后。外部模型已经支持更高分辨率、更强的运动控制和更稳定的多镜头故事生成，全是用户最需要的能力。团队内部评测结束后，现场一片沉默，谁都不敢说“我们白做了”，但每个人心里都知道答案。

3.4 阶段四：放下自研时，市场窗口已关闭

真正致命的还不是沉没成本，而是时间窗口。复盘里写道，当他们最终决定彻底放弃自研模型、全部切换回公共底座时，市场上的同类应用已经借助快速迭代抢先占领了用户心智。早期用户早就在别人那里完成了创作习惯和数据沉淀，不会再迁移到一个姗姗来迟的“同样功能”的工具上。

这款AI视频应用不是死于不能做产品，而是死在把最宝贵的18个月投资在了一个不属于自己的战场。创始人复盘最后那句话很直白：我们以为在造护城河，其实是在挖坟墓。这个过程既痛苦又真实，值得每一个还在纠结要不要自研模型的团队反复看看。

4. 真正的护城河：场景嵌入、数据飞轮与网络效应，哪个都强过参数规模

4.1 场景嵌入：同一个模型在不同工作流里的价值差十倍

把同一个模型换个外壳，用户感受可能完全不同。拿视频生成来说，如果你只做一个“输入一句话，生成一段视频”的通用工具，那它确实毫无壁垒，用户随便换个平台都能完成同样的动作。但如果你把生成能力嵌入一条创作工作流，比如自动拆解剧本、分镜、字幕、配音、素材检索、成片剪辑和封面适配，用户离开你的时候损失的就只是一段视频，而是整套创作流程的效率和习惯。

场景嵌入的本质，是把自己变成用户工作流中不可或缺的一个环节。这个环节的价值不取决于模型有多强，而取决于你有多了解用户在特定流程中每一步的痛点和爽点。竞争对手可以快速获取同样强的模型能力，却无法一夜之间复制你对某个业务场景的深刻理解。

4.2 数据飞轮：用产品行为数据塑造不可复制的体验

很多团队以为“护城河=有数据”，实际上，拥有数据和形成数据飞轮是两码事。真正的数据飞轮，是每一次用户行为都能反馈回产品，让下一次交互变得更聪明。比如用户在生成视频后，可能反复调整某个镜头的节奏、某种转场的时机、某个滤镜的参数；这些行为信号是公共模型无法直接感知的。

应用层完全可以基于这些信号构建一个“偏好偏置层”：不做基础模型，只做用户偏好的理解和重排序。比如同一个视频生成底座，你的产品可以根据某类创作者的历史习惯，自动调整镜头数量和转场选择，让他少改三轮。这种体验不是模型给的，是你自己打磨出来的数据智能。时间越长，竞争对手越难复制，因为你沉淀的是用户和产品之间的专属默契。

4.3 用户网络效应：模板、协作与分享带来的扩散力

到了2026年，多模态大模型的最新进展已经把生成能力变成了一种公共资源，单靠“生成得好”根本没法区分产品。真正的增长杠杆在用户网络里。我拆过几个AI智能体应用案例，能跑出头部的产品几乎都有一个共同点：用户不只是消费者，还是创造者和传播者。

比如你的视频工具允许用户把自己的模板、工作流、风格配置发布到社区，其他用户一键复用同时反向关注宿主用户；当平台里的创作模板越攒越多，每个新用户都能从中找到适合自己的起点，而老用户又因为别人的复用获得成就感和曝光。这种基于创作资产形成的网络效应，一旦滚起来，粘性远超任何模型参数带来的短期优势。护城河不在你手里那几行代码里，而在一群用户彼此连接的关系网里。

4.4 从护城河属性对比看清该把精力压在哪

这张表说得很清楚：模型强不强，只是起点；真正决定你能跑多远的，是你能不能把场景、数据和网络效应这几件“苦活累活”做到位。模型更新可能一夜间抹平算法差距，但用户在你的产品里沉淀下来的资产和习惯，是外部力量无法一键迁移的。

5. 一条可落地的路线图：选择、微调、编排与评测

5.1 模型选型判断：业务需要的是“最强”还是“够用且可替换”

既然不鼓励应用团队盲目自研模型，那面对市面上五花八门的商业API和开源权重模型，应该怎么选？我的建议是拿一张决策清单逐条打勾。可以先问自己四个问题：

• 任务是不是一个相对标准的自然语言或多模态理解/生成问题？
• 业务数据有没有极强的隐私、合规或离线部署要求？
• 自己团队是否有能力维护一条数据标注、评测和训练链路？
• 产品差异化到底来自模型的认知能力，还是来自你独特的业务流程和数据反馈？

大多数情况下，前两问的答案都是“标准”“不需要”，后两问的答案也都是“否”。那么最理性的选择就是直接接入成熟商业API或成熟的社区开源模型，把省下来的算力和人力全部投到应用层。只有当你明确需要在某个垂直风格、领域术语或输出约束上做深度改造时，才值得考虑下一步的微调。

5.2 什么时候才值得微调？从零预训练几乎没戏，微调也要有边界

从零预训练基座模型，对于绝大多数AI应用团队来说都不是一个值得考虑的选项。对团队来说，真正有实操价值的是“在开源模型基础上做轻量微调”。但微调同样需要在很小的范围内进行。

微调适合解决什么？比如让模型输出严格遵循你的JSON字段结构；让它在某个垂直专业领域的措辞更规范；让视频生成模型更适配你平台偏好的某种风格。这些都是具体、可评测、面向用户价值的目标，而不是“把模型变聪明”这种模糊诉求。

同时，微调必须设有边界。不要把整个产品的主路径完全押在一个微调模型上，始终保持“可以随时换回公共底座”的备份。复盘里那个团队后来总结：微调模型应当是引擎上一个可替换的插件，而不是地基。地基必须是你的场景逻辑和数据闭环。

5.3 RAG与Agent编排：真正务实的应用层底座

不管你做的是客服机器人、内容创作工具还是AI智能体，都绕不开两套应用层技术：RAG（检索增强生成）和Agent编排。前者解决“模型不知道你锅里有什么”的问题，后者解决“模型怎么配合工具把一件事做完”的问题。

在知识密集型场景里，RAG能让模型引用企业内部文档、召回创作素材，并且给出可溯源的回答；每次知识更新只需要改索引库，不用重训模型。在复杂任务场景里，Agent编排负责把用户的一句话拆成一连串动作：理解意图、规划步骤、调用不同的模型和工具、汇总输出。以AI视频应用为例，用户说“我想做一个30秒的产品宣传片”，Agent会先规划脚本，再检索你的品牌素材库，调用生成模型产出分镜，然后通过后处理模块做超分和调色。这套工作流打磨得越顺，用户对单一模型的感知就越淡，对整套工具的信赖就越深。

5.4 别忘了持续评测：应用层也要有自己的“模型评测榜”

最后想提醒一件很多团队忽略的事：当你把模型视作可替换组件之后，评测体系也必须跟着重建。不要只看公开榜单，而是围绕真实用户任务建立自己的回归集。

具体操作不复杂：整理出几十个核心用户任务，比如“生成一段包含人脸特写的10秒视频”“根据三种风格的素材生成统一色调的成片”等；每次模型升级、提示词调整、后处理逻辑变化，都跑一遍回归集，对比输出质量、延迟和失败率。这样，你可以快速判断外部模型是否值得升级，微调版本会不会带来回退，以及某个流程改动是否伤害了整体体验。应用团队要有自己的“应用评测榜”，而不是眼巴巴等模型层的榜单公布。

做个AI应用，最危险的事情不是模型不够强，而是把“模型”当作了目的本身。技术虚荣会让团队在错误的战场耗尽弹药，错过产品窗口期；真正护城河从来不是那一串参数量，而是你对场景的理解、对数据闭环的打磨，以及用户在你的产品里沉淀下来的每一个不可替代的创作资产。我自己的体会是，每次团队冒出“我们要不要自己训练一个模型”的念头时，先别急着开会立项，先坐下来算算账：这笔钱和这些人，如果全部砸进用户看得见摸得着的地方，能多跑出多少功能，多做多少次迭代，多留下多少个用户。答案往往会让你很清醒。别拿产品最黄金的时间去赌参数，用户等不起，市场更等不起。