开发者常常先解释产品怎么运行，却没有先说它能带来什么。本文帮你把已确认的产品事实改写成清楚的标题候选，再测试目标用户能不能看懂完整首屏。
写标题前，先回答四个问题：
| 信息 | 需要回答的问题 |
|---|---|
| 目标用户 | 谁会反复遇到这个问题？ |
| 想要的结果 | 用户最终要得到什么具体结果？ |
| 当前阻力 |
| 他们现在要忍受什么缓慢、脆弱、昂贵或重复的流程？ |
| 已确认的依据 | 关于安装、性能、隐私、兼容性或所有权，你能如实说什么？ |
可以先用这个结构整理思路：
Eren
学习闭环标题假设 = 想要的结果 + 必要的使用场景 - 当前阻力
这只是起草工具，不是通用定律。H1 不需要塞进所有信息。目标用户可能已经能从页面上下文看出来；产品机制和事实依据则可以放在副标题或事实说明里。
标题的任务很简单：让合适的人愿意继续往下看。
选择公式时，要看产品特点和访客已经了解多少。不要强行把所有产品套进同一个句式。
| 类型 | 公式 | 适用情况 | 示例 |
|---|---|---|---|
| 1. 去掉已知麻烦 | [完成任务]，无需[痛苦的替代做法] | 用户已经知道原来的做法很麻烦 | 验证数据库恢复，无需维护自定义恢复脚本。 |
| 2. 把输入变成结果 | 把[原始输入]变成[可用输出] | 产品有清楚的输入和输出 | 把 Stripe Webhook 事件变成可对账的流水。 |
| 3. 说清专用定位 | 面向[特定用户或环境]的专用[品类] | 聚焦的小范围确实是差异点 | 面向单容器家庭服务器的运行监控工具。 |
| 4. 替代脆弱流程 | 别再[脆弱流程]。[得到结果]。 | 用户熟悉这个问题，而且后果明显 | 别再手动清理生产日志。导出前先移除密钥。 |
| 5. 划分人机工作 | 你负责[高价值工作]，我们处理[重复的系统工作] | 用户需要自动化，但不想失去控制 | 你来写查询，我们处理连接池、缓存和故障切换。 |
这些公式只负责帮你产出草稿。它们不能证明文案里的主张是真的，也不能保证文案有说服力。
假设有一款开源 CLI 工具。它会在预发布环境的日志上传到对象存储前，先移除其中的密钥。
这个例子只使用以下已经确认的产品事实：
这些事实就是文案边界。我们不能凭空加入速度、识别准确率、合规性或“零配置”等说法。
一个异步令牌检查代理，使用正则表达式和基于熵的密钥分类。
这句话介绍了内部实现，却没有直接说明用户要完成什么任务、在什么环境使用，以及最后能得到什么结果。
| 信息 | 本例答案 |
|---|---|
| 目标用户 | 维护容器化预发布环境的开发者 |
| 想要的结果 | 上传可用日志，同时避免暴露常见凭据 |
| 当前阻力 | 维护自定义脱敏规则，或逐条人工检查日志 |
| 已确认的依据 | 本地 Go 二进制文件、标准输入输出流程、MIT License |
公式 1：去掉已知麻烦
把预发布日志发送到对象存储，同时避免暴露 API Key 或数据库凭据。
这个版本先说操作结果和风险。它更适合已经担心日志泄露密钥的访客。
公式 4：替代脆弱流程
别再维护日志清理脚本。导出前自动移除常见密钥。
这个版本先说旧做法。它更适合正在维护脆弱正则规则的访客。
公式 3：说清专用定位
面向容器化预发布环境的本地日志脱敏 CLI。
这个版本吸引力稍弱，但品类很清楚。它更适合正在比较日志脱敏工具的人。
现在还不能诚实地选出“赢家”。三个版本分别假设访客已经知道不同的信息，也在意不同的问题。
上面的每一句都能追溯到已确认的信息。能否追溯，比听起来是否厉害更重要。
下面这段 Prompt 可以生成英文候选文案。它会限制模型只使用你提供的事实，不把信息空缺补成营销承诺。
你正在帮助一位技术创始人起草英文落地页首屏文案。
只能使用下面已经确认的产品信息。不要推断或编造性能、隐私、
合规、客户、价格、集成或安装方面的主张。
产品信息：
- 产品名称：[名称]
- 目标用户：[准确的角色或使用环境]
- 要完成的任务：[用户想得到的具体结果]
- 当前替代做法或阻力：[用户现在怎么做]
- 产品机制：[用户要安装、连接或提供什么]
- 已确认的安装事实：[只写已确认的信息]
- 已确认的依据或差异点：[只写已确认的信息]
- 主要转化动作：[下载、查看演示、开始试用等]
可用标题公式：
1. [完成任务] without [痛苦的替代做法]
2. Turn [原始输入] into [可用输出]
3. The focused [品类] for [特定用户或环境]
4. Stop [脆弱流程]. [得到结果].
5. You [高价值工作]. We handle [重复的系统工作].
要求：
1. 选择最符合产品事实的三个公式。
2. 说明每个公式为什么合适。
3. 使用主动、具体、容易理解的英文。
4. 不要使用 effortless、seamless、next-gen、all-in-one、
supercharge、unleash 或 revolutionary。
5. 如果某项有用的主张没有事实支持，写 Missing evidence，
不要替产品补全这项主张。
6. 产品信息没有提供时，不要添加数字、时限、安全、隐私或合规承诺。
请用英文输出。每个公式使用以下结构：
### Pattern [编号]: [名称]
- Reason for selection:
- H1 headline:
- Sub-headline:
- Primary CTA:
- Proof line，或 No verified proof provided:
- Key audience assumption:
- What could be misunderstood:
- Test hypothesis:
最后用表格比较各候选版本更重视哪一项：
- 结果是否清楚；
- 受众是否具体；
- 是否能让用户认出当前麻烦；
- 品类是否清楚。
Prompt 不能替你验证定位。它的作用，是生成边界明确、方便审核、也值得测试的候选版本。
5 秒测试用来观察用户短暂看过页面后记住了什么、理解了什么。常见做法是展示页面 5 秒，然后隐藏页面并提问。具体流程可参考 Lyssna 的 5 秒测试说明。
测试完整首屏，不要只展示标题。找目标用户看过页面后，问四个问题：
记录参与者自己的用词。如果多人出现同一种误解，就修改造成误解的文案。如果答案很分散，而参与者并不属于目标用户，先改进招募条件，不要急着再次重写标题。
5 秒测试只能检查第一印象、理解和记忆，不能证明标题会提高注册或收入。等两个版本都能准确说明产品后，再在相近的流量和转化条件下比较。
清楚的文案不是终点。它只是一个可以被目标用户检验的产品说明。
准备公开测试定位时，可以先比较 Product Hunt、Reddit 和 Hacker News 的特点和风险。
Tomako 是面向软件开发者的 Always-On AI CMO。核心原则很简单：市场工作要基于真实的产品信息，并且在公开前可以由人审核。如果你想建立稳定的发布习惯，也可以参考独立开发者的每日 30 分钟营销流程。
