logo
DocsUpdatesBlogDownload Studio
Asset HubLogin

OOMOL 首页逐屏文案初稿

目标：把首页叙述优化方案进一步落成可直接使用的中文文案初稿。重点不是最终字句，而是先把每一屏“该说什么、按什么顺序说、说到什么力度”定下来。

适用范围：中文首页主线文案。默认对应桌面端首页，不含导航、页脚和下载页细节。

总体文案原则​

首页要让用户顺着理解这条链路​

旧流程有断层 -> OOMOL 把断层接起来 -> 这条路径为什么成立 -> 它已经真实工作 -> 我可以怎么开始用

语气建议​

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

首页里尽量反复强化的关键词​

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

第一屏：定义新品类​

这一屏的任务​

让用户第一眼知道：

  • OOMOL 是什么
  • 最终结果是什么
  • 为什么它和普通开发工具不一样

固定主标题​

函数即交付

建议副标题​

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

建议标签 / kicker​

AI-Native Function-to-Service

如果想更少术语，也可以改成：

For developers who ship functions

建议价值短标签​

  • 不学新 DSL
  • 本地先跑通
  • 直接发成服务

建议主 CTA​

下载 OOMOL Studio

建议次 CTA​

  • 查看真实案例
  • 看看怎么交付

建议截图说明​

Code -> Validate -> Ship

文案备注​

这一屏不要把所有产品形态、资产沉淀、社区能力全塞进去。只做一件事：

让“函数即交付”这句话被立刻理解。

对应组件​

  • src/components/HomepageFirstScreen/index.tsx

第二屏：旧流程的问题​

这一屏的任务​

告诉用户，问题不在“函数难写”，而在“函数写完之后，交付流程断了”。

建议标题​

代码不是阻碍，部署、运维和迭代成本才是

建议副标题​

开发者总是希望将精力集中于通过技术创造出更便利高效的产品，而不是浪费大量时间在重复的标准流程工作里。

建议三条问题卡片​

卡片 1​

标题：

写完函数，还要再搭一套后端

说明：

实现已经有了，但为了对外提供 API 或任务能力，还要重新封装接口、部署流程和运行方式。

卡片 2​

标题：

本地能跑，不等于交付能跑

说明：

开发环境、依赖环境和发布环境脱节，问题往往不是代码本身，而是它换了地方就不成立。

卡片 3​

标题：

同一份能力，被重复包装很多次

说明：

为了 API、MCP 工具和自动化任务，团队经常围着同一份实现反复改造，交付成本被重复放大。

文案备注​

这一屏要有一点“拆旧世界”的力量，不能太温和。它承担的是让用户产生迁移动机。

对应组件建议​

  • 新增首页模块

第三屏：解释 OOMOL 为什么成立​

这一屏的任务​

把“函数即交付”从一句口号变成一个用户听得懂的机制。

建议标题​

OOMOL 不是换一种 DSL，而是把交付接回真实工程

建议副标题​

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

建议四个机制点​

机制点 1​

标题：

继续写真实代码

说明：

不用先适应平台语法，也不用为了接入系统重写工程结构。

机制点 2​

标题：

让 Agent 补全实现

说明：

Agent 帮你生成和补全函数，减少样板劳动，但结果仍然留在真实工程里。

机制点 3​

标题：

先在本地闭环验证

说明：

用内置容器跑通依赖、环境和调试，把不确定性尽量留在上线前解决。

机制点 4​

标题：

同一份实现走向多个出口

说明：

API、MCP 工具和自动化任务，不该各自再做一遍，它们应该来自同一份已经跑通的能力。

对应组件建议​

  • 由 src/components/HomepageCoreFeatures/index.tsx 改造承接

第四屏：三步工作流​

这一屏的任务​

让用户知道，这不是概念，而是一条可以照着做的路径。

建议标题​

Code -> Validate -> Ship

建议副标题​

先把能力做出来，在本地跑通，再把同一份实现直接交付出去。

Step 1​

标题：

01｜写函数：在真实工程里把能力做出来

说明：

不用先学新 DSL，也不用先适应平台。继续写真实函数和项目代码，复用已有库、脚本和工程结构，让 Agent 帮你补全实现。

强调句：

先把能力做出来，再考虑它跑在哪。

Step 2​

标题：

02｜本地验证：交付前先把结果跑通

说明：

用内置容器把依赖、日志、输入输出和运行环境先在本地闭环，尽量把问题留在交付前解决。

强调句：

先把不确定性解决在本地。

Step 3​

标题：

03｜发布成服务：同一份实现直接上线

说明：

不用再拆第二套后端，也不用为了交付重写一遍。已经跑通的函数，可以直接发成 API、MCP 工具或自动化任务。

强调句：

函数写完，交付就该顺着发生。

对应组件​

  • src/components/HomepageCoreFeatures/index.tsx

第五屏：真实 Proof​

这一屏的任务​

告诉用户，这条路径已经在真实场景中成立。

建议标题​

不是概念，而是已经上线的交付结果

建议副标题​

OOMOL 不只是帮你把函数做出来，而是已经把同一份能力真实地接到了对外服务。

建议信号卡片​

信号 1​

标签：

交付路径

值：

函数 -> 本地验证 -> 服务

说明：

先把函数做出来，在本地跑通，再把同一份实现发出去，而不是在多个系统之间反复搬运。

信号 2​

标签：

交付形态

值：

API / MCP / 自动化

说明：

同一份能力可以直接走向接口、Agent 工具或任务执行，不需要为了不同出口重写实现。

信号 3​

标签：

交付沉淀

值：

安装 / 管理 / 继续组合

说明：

一次交付不该只是上线结束，而应该继续沉淀为团队后续可复用的服务资产。

建议案例卡片​

案例标题：

pdf.oomol.com

案例说明：

这个站点面向用户提供多种 PDF 工具，而这些工具背后的后端能力不是额外再搭一套服务，而是直接由 OOMOL 的函数服务对外提供。函数写完，服务就能真实上线。

案例 CTA：

打开 pdf.oomol.com

文案备注​

这一屏只保留真实案例。不要混入“占位场景”“后续可补案例”“内部说明”。

对应组件​

  • src/components/HomepageProofLayer/index.tsx

第六屏：部署方式，清除采用阻力​

这一屏的任务​

告诉用户，不需要一次性接受全部，只要从适合自己的方式开始。

建议标题​

从本地起步，到正式交付，都有对应落地方式

建议副标题​

3 种形态，一条交付路径。你可以先在本地跑通，也可以把同样的能力接到团队部署和正式上线。

卡片 1​

标题：

Studio

标签：

本地开发与快速起步

说明：

适合个人开发、函数调试和本地验证。先把能力做出来、跑通，再决定是否继续交付。

卡片 2​

标题：

Headless

标签：

团队部署与私有化运行

说明：

适合容器化部署、私有云环境和更高可控性的团队场景，让 OOMOL 能接入已有基础设施。

卡片 3​

标题：

Cloud

标签：

快速上线与低运维心智

说明：

适合希望把已经跑通的函数尽快正式交付的团队，用更低的部署和运维成本进入生产。

文案备注​

这一屏不要做成“产品目录”，而要做成“我该怎么开始”的回答。

对应组件​

  • src/components/HomepageProductComparison/index.tsx

第七屏：交付之后继续沉淀​

这一屏的任务​

把 OOMOL 从一次性交付工具，提升为团队能力资产系统。

建议标题​

交付之后，还能继续复用

建议副标题​

重要的不只是这次上线，而是把这次交付留下来，让团队下次开发还能直接复用和扩展。

卡片 1​

标题：

安装现成能力

说明：

把已经交付过的函数能力装进团队环境，不再每次从零重写。

卡片 2​

标题：

形成团队能力目录

说明：

让团队知道哪些能力已经存在、谁在维护、应该怎么调用。

卡片 3​

标题：

继续拼成更大的服务

说明：

基于已经交付的函数继续扩展，让每次上线都变成服务资产的一部分。

对应组件​

  • src/components/HomepageCommunityShare/index.tsx

第八屏：收尾 CTA​

这一屏的任务​

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

建议标题​

从下一个函数开始交付

建议副标题​

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

建议 CTA​

下载 OOMOL Studio

可选辅助文案​

从本地开始，不必先重构整套交付流程。

对应组件​

  • src/components/GetStartedPrompt/index.tsx

首页模块顺序建议​

建议首页最终顺序如下：

  1. 首屏：定义新品类
  2. 旧流程的问题
  3. 成立机制
  4. 三步工作流
  5. 真实 Proof
  6. 部署方式
  7. 资产沉淀
  8. 收尾 CTA

当前组件映射建议​

保留​

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

新增​

  • 旧流程问题段

暂不上首页主线​

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

可直接替换的关键句​

如果要先快速试文案，可以优先替换这几句：

Hero 主标题​

函数即交付

Hero 副标题​

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

第二屏标题​

代码不是阻碍，部署、运维和迭代成本才是

机制屏标题​

OOMOL 不是换一种 DSL，而是把交付接回真实工程

Workflow 标题​

Code -> Validate -> Ship

Proof 标题​

不是概念，而是已经上线的交付结果

部署屏标题​

从本地起步，到正式交付，都有对应落地方式

收尾 CTA 标题​

从下一个函数开始交付

一句话总结​

这版首页文案初稿的核心，不是把 OOMOL 写成“功能更多的平台”，而是把它写成：

一条把函数从真实工程直接带到交付结果的新路径。