logo
DocsUpdatesBlogDownload Studio
Asset HubLogin

OOMOL 官网叙述框架优化方案

目标：参考 Pencil 的叙述逻辑，重组 OOMOL 首页的信息架构，让首页不只是“展示功能”，而是形成一条完整的说服链：定义新品类 -> 打掉旧流程 -> 解释机制 -> 证明价值 -> 清除采用阻力 -> 承接转化。

一句话结论​

当前 OOMOL 首页的内容方向基本是对的，但叙述顺序还不够强。

现在更像：

  • 我们是什么
  • 我们有这些能力
  • 我们还有这些沉淀价值

优化后应该变成：

  • 旧方式为什么低效
  • OOMOL 提供了什么新的交付路径
  • 这条路径为什么成立
  • 它已经如何真实工作
  • 你应该怎么开始用
  • 用了以后如何持续沉淀团队资产

当前首页的主要问题​

1. 首屏信息正确，但主张不够聚焦​

当前首屏已经有一条主线：

  • 函数即交付
  • Code -> Validate -> Ship
  • 不学新 DSL
  • 本地先跑通
  • 直接发成服务

问题不在内容错，而在首屏一次性塞入的信息太多，用户第一眼不容易抓到最核心的主张。

首页首屏应该优先让用户记住一句话，而不是同时理解全部机制。

2. 缺少对旧流程的正面拆解​

Pencil 很强的一点，是会明确点出旧流程的问题，比如 No more design handoffs。

OOMOL 当前首页在表达“新方案”，但没有足够锋利地拆掉旧方案。

而 OOMOL 实际上是有明确对立面的：

  • 写完函数后还要重搭后端
  • 本地开发和发布环境断裂
  • 为 API、MCP、任务重复包装实现
  • 交付完成后能力无法沉淀成资产

这些都应该被清楚说出来。

3. 机制层没有足够早地出现​

用户在看到“函数即交付”后，会立刻问：

  • 为什么可以直接交付
  • 你们到底是代码编辑器、工作流工具还是部署平台
  • 这和普通脚本开发、Serverless、工作流平台的区别是什么

这些问题不能等到用户自己猜。

首页应该尽早解释 OOMOL 的成立机制：

  • 在真实工程里写函数
  • Agent 帮你生成和补全
  • 用内置容器在本地验证
  • 再把同一份实现发布为 API / MCP / 自动化任务
  • 通过 Studio / Headless / Cloud 承接不同部署方式

4. Proof 段落方向对，但信任感还不够纯​

当前 ProofLayer 的方向是对的，但里面混入了占位内容和内部说明感文案，会削弱真实案例本身的可信度。

首页中的 proof 一定要“只讲已经成立的事实”，不能夹杂“以后还可以补什么”。

5. 部署模式是关键阻力清除段，但目前没进入首页主线​

Studio / Headless / Cloud 其实是很重要的一段，因为它回答的是：

  • 我到底该怎么开始
  • 团队怎么接住
  • 私有化和正式上线怎么处理

这属于采用阻力清除段，应该进入首页主线。

6. 资产沉淀段出现得略早​

CommunityShare 这段表达的是长期价值，适合放在“用户已经相信产品可用”之后，而不是在说服链中段过早出现。

参考 Pencil 后，适合 OOMOL 的首页叙述主线​

首页建议重组为 7 屏。

第一屏：定义新品类 + 给出结果承诺​

目标​

让用户 3 秒内知道 OOMOL 是什么，以及为什么值得继续往下看。

应该回答的问题​

  • OOMOL 是什么
  • 它和普通开发/工作流/部署平台的差异是什么
  • 最终结果是什么

建议标题方向​

主标题保留现有表达：

  • 函数即交付

建议副标题方向​

  • 让 Agent 帮你生成和补全函数，用内置容器在本地先跑通，再把同一份实现直接交付成 API、MCP 工具或自动化任务。

CTA​

  • 主 CTA：下载 OOMOL Studio
  • 次 CTA：查看真实案例 / 查看如何交付

当前模块处理建议​

  • 保留 src/components/HomepageFirstScreen/index.tsx
  • 保留 函数即交付 作为主标题
  • 强化 Code -> Validate -> Ship，不要只放在截图 caption
  • 精简首屏描述，不要一次把所有卖点展开

这一屏最重要的原则​

首屏不是解释全部，而是让用户记住一句话：

函数即交付。

第二屏：打掉旧流程​

目标​

建立迁移动机，让用户意识到自己现在的流程本身就有问题。

应该回答的问题​

  • 为什么需要 OOMOL
  • 现在的开发交付方式到底卡在哪

推荐表达方向​

  • 不要写完函数后，再重搭一套后端
  • 不要在本地跑得动，发布后又重来一遍
  • 不要为了 API、MCP、自动化任务重复包装三次

建议标题方向​

  • 代码不是阻碍，部署、运维和迭代成本才是
  • 开发和交付之间，不该隔着第二套系统

建议内容结构​

可以用 3 个短卡片或 3 个短句，直接拆掉旧流程：

  • 写完函数，还要再搭部署和接口层
  • 本地环境与发布环境不一致
  • 能力上线后无法沉淀为团队资产

当前模块处理建议​

  • 这是当前首页缺失的一屏
  • 建议新增，不要拿现有功能模块硬替代

为什么这一屏重要​

没有这一屏，用户会觉得 OOMOL 只是“另一种工具”。 有了这一屏，用户才会觉得 OOMOL 是在消除一类系统性摩擦。

第三屏：解释 OOMOL 的成立机制​

目标​

把“函数即交付”从口号变成用户可理解的工作机制。

应该回答的问题​

  • 为什么你们能做到直接交付
  • OOMOL 到底是怎么工作的

建议标题方向​

  • 不是换一种 DSL，而是把交付接回真实工程
  • 同一份实现，从代码到交付不再断开

建议副标题方向​

  • 你继续写真实函数和项目代码，Agent 帮你补全实现，内置容器帮你本地验证，再由 OOMOL 把同一份能力发布到不同交付出口。

推荐拆成四个机制点​

  • 真实工程代码
  • Agent 辅助生成和补全
  • 本地容器闭环验证
  • 同一份实现走向 API / MCP / 任务

当前模块处理建议​

  • 这一屏可以由现有 src/components/HomepageCoreFeatures/index.tsx 改造承担
  • 但标题和副标题不能只写“从函数生成到服务交付”
  • 要更明确强调“为什么这条链路成立”

第四屏：用三步工作流证明这条路径可执行​

目标​

把抽象机制落实为一个清晰、可信、可预期的操作路径。

应该回答的问题​

  • 用户实际会怎么用
  • 这是不是一条可执行的流程

推荐三步结构​

  1. 写函数
  2. 本地验证
  3. 发布成服务

建议标题方向​

  • Code -> Validate -> Ship
  • 从实现到上线，不再切换系统

每一步的表达重点​

第一步：写函数​

  • 写真实代码，不学新 DSL
  • 复用已有库、脚本和工程结构
  • Agent 帮你完成函数实现

第二步：本地验证​

  • 用内置容器跑通依赖和环境
  • 在交付前验证输入输出和日志
  • 尽量把不确定性留在本地解决

第三步：发布成服务​

  • 同一份实现直接发成 API
  • 同一份实现直接发成 MCP 工具
  • 同一份实现直接发成自动化任务

当前模块处理建议​

  • 继续使用 src/components/HomepageCoreFeatures/index.tsx
  • 这是当前首页中最接近成熟叙述的一段，建议保留并上提权重

第五屏：只放真实 Proof​

目标​

建立信任，让用户知道这不是概念，不是演示，而是已经上线运行的路径。

应该回答的问题​

  • 这东西真的已经跑起来了吗
  • 有真实结果吗

建议标题方向​

  • 不是概念，而是已经上线的交付结果
  • 这条路径已经真实工作

内容建议​

优先只保留真实案例：

  • pdf.oomol.com

建议把案例说得更具体：

  • 这是一个什么站点
  • 站点背后哪些能力由 OOMOL 提供
  • OOMOL 在这里替代掉了什么传统流程

不建议出现的内容​

  • 占位场景
  • “后续可以补更多案例”
  • 内部说明感文案

当前模块处理建议​

  • 改造 src/components/HomepageProofLayer/index.tsx
  • 删除 note
  • 删除占位 case
  • 让整段更像 proof，不像 roadmap

第六屏：清除采用阻力，解释怎么落地​

目标​

告诉用户：你不需要一次性接受全部，只要选适合自己的落地方式。

应该回答的问题​

  • 我应该从哪种产品形态开始
  • 团队、私有化、生产环境怎么处理

建议标题方向​

  • 从本地起步，到正式交付，都有对应落地方式
  • 3 种形态，一条交付路径

推荐结构​

  • Studio：个人开发、本地验证、快速起步
  • Headless：团队部署、私有化、容器化运行
  • Cloud：快速上线、减少运维心智负担

这段的真正作用​

它不是“产品目录”，而是“采用阻力清除器”。

它在告诉用户：

  • 你可以先小范围试
  • 团队有接住方案
  • 正式上线也有承接方式

当前模块处理建议​

  • 把 src/components/HomepageProductComparison/index.tsx 接回首页主线
  • 文案语气从“选产品”改成“选落地方式”

第七屏：交付之后，还能继续复用​

目标​

把 OOMOL 从“上线工具”提升为“团队能力资产系统”。

应该回答的问题​

  • 为什么这不是一次性交付工具
  • 上线后还能留下什么长期价值

建议标题方向​

  • 交付之后，还能继续复用
  • 一次上线，变成下一次开发的起点

推荐表达重点​

  • 安装现成能力
  • 建立团队能力目录
  • 基于已交付能力继续组合更大的服务

当前模块处理建议​

  • 保留 src/components/HomepageCommunityShare/index.tsx
  • 但应后移到部署模式之后

为什么放在这里更顺​

因为用户先要相信：

  • 能做出来
  • 能跑通
  • 能上线

然后才会关心：

  • 能不能沉淀为资产

第八屏：收尾 CTA​

目标​

承接已经被说服的用户，给出清晰的下一步。

建议标题方向​

  • 从下一个函数开始交付
  • 下载 OOMOL Studio，把函数做成服务

建议副标题方向​

  • 让 Agent 帮你把函数做出来，在本地跑通，再直接发成服务。

当前模块处理建议​

  • 保留 src/components/GetStartedPrompt/index.tsx
  • CTA 尽量只保留一个主动作，不要在结尾增加太多分叉

建议的首页最终顺序​

建议首页调整为：

  1. 首屏：定义新品类 + 结果承诺
  2. 旧流程的问题：为什么需要 OOMOL
  3. 成立机制：为什么 OOMOL 这条路径成立
  4. 三步工作流：Code -> Validate -> Ship
  5. 真实 Proof：已经上线的结果
  6. 部署模式：Studio / Headless / Cloud
  7. 资产沉淀：交付之后继续复用
  8. 收尾 CTA：下载开始

现有模块的去留建议​

建议保留并重写定位​

  • src/components/HomepageFirstScreen/index.tsx
  • src/components/HomepageCoreFeatures/index.tsx
  • src/components/HomepageProofLayer/index.tsx
  • src/components/HomepageCommunityShare/index.tsx
  • src/components/GetStartedPrompt/index.tsx
  • src/components/HomepageProductComparison/index.tsx

建议不上首页主线​

  • src/components/HomepageLifecycle/index.tsx

原因：

  • 和 CoreFeatures 叙述重复
  • 更像使用流程说明，而不是首页说服链中的关键节点
  • 会分散首页主叙述

暂不建议放回首页的模块​

  • src/components/HomePageBuiltInLLM/index.tsx
  • src/components/HomepageDownloads/index.tsx
  • src/components/HomePagePricing/index.tsx
  • src/components/HomepageStarter/index.tsx

原因：

  • 会打断首页主叙述
  • 当前更适合放到对应产品页或下载页
  • 价格不应该过早干扰对“新品类”的理解

推荐的首页文案策略​

应该多用的表达​

  • 真实工程
  • 同一份实现
  • 本地先跑通
  • 直接交付
  • API / MCP / 自动化任务
  • 不重搭后端
  • 交付之后继续沉淀

应该少用的表达​

  • 过于抽象的平台大词
  • 不解释机制的 AI 口号
  • 纯“功能列表式”堆叠
  • 内部说明感文案

文案语气建议​

OOMOL 首页最适合的语气不是“未来感 AI 平台”，而是：

  • 工程化
  • 克制
  • 清楚
  • 结果导向

也就是让用户感觉：

这是一套认真处理开发到交付断层的系统，而不是一个概念包装。

后续最适合继续做的两步​

第一步​

基于这份叙述方案，重写首页每一屏的标题、副标题和按钮文案。

第二步​

在文案确定后，再调整组件顺序和版面层级，让视觉跟着叙述走，而不是反过来用视觉拼叙述。

一句话总结​

参考 Pencil 后，OOMOL 首页最重要的优化方向不是“更像 AI 产品”，而是“更像一条可信的开发交付新路径”。

首页应该让用户顺着理解：

旧流程有断层 -> OOMOL 把断层接起来 -> 这条路径已经成立 -> 我可以从适合自己的方式开始用