wvvb/网站文案撰写

网站文案撰写 是做什么的？

网站应让正确的人识别出自己的处境，理解产品的功用，并知道下一步该做什么。

原则： 从访问者的现实出发向外撰写，而非从产品的功能列表向内构建。文案听起来必须像一个了解业务的人，而不是像一个解释营销如何运作的营销人员。

这是一项写作与信息设计技能，而非人工智能检测器或僵化的转换公式。不要为了提高“人性化”听感而牺牲真实性、可访问性或精确性。

证据标签

版本 1.1。 标签仅出现在效果声明上：即声称某些东西能提升识别度、理解度、信任度或转化率的表述。义务和工作流程步骤不参与分级。

• [E] 经过验证的直接证据：测量所述效果的同行评审研究或文档化测试，包含效应量和限制条件。
• [P] 合理的实践：在没有针对该受众的直接测量证据时仍有用的做法。
• [S] 编辑风格偏好。风格项在 references/evidence.md 中进行分级；它们不会在本技能中内联标记。

本技能中的任何规则对于着陆页转化而言都不是 [E] 级。请将转化建议视为需要在实际站点上测试的假设，且若无测量结果，切勿承诺提升效果。此处未标记标签的有效性声明均为 [P] 级建议性实践；义务和工作流程步骤不参与分级。完整的逐项分类、来源及候选实验见 references/evidence.md。

不可协商的规则

1. 以相关性为先。 提出目标访问者能识别的具体问题、任务或结果。尽快让访问者明白所提供的内容。 [P]
2. 解释因果关系。 展示产品实际如何帮助解决问题。不要用承诺代替机制。 [P]
3. 听起来自然。 优先使用日常语言、具体名词和普通动词。对于技术受众，保持技术准确性。
4. 在草拟的网站文案中不要使用 em 破折号或 en 破折号。 用句号、逗号、冒号或自然改写替代。引用源材料时保留原文标点。如果用户明确要求不同样式，则遵循要求。
5. 不制造情感。 不要编造痛苦、紧迫感、恐惧、统计数据、社会证明、结果或功能。
6. 不强加模板。 不要给每个网站都套用相同的问题/激化/解决方案/功能/证言/CTA 流程。根据访问者决策所需选择章节。
7. 不要为了重写而重写。 如果原文更清晰，就保留它。做出能提升理解的最小改动。

确定访问者需要理解什么

在编辑前，检查用户提供的材料：实时页面、截图、当前文案、简报或源代码。确定：

• 受众： 谁需要这个？使用可识别的角色或场景，而非“每个人”。
• 触发因素： 什么事件让他们现在寻求帮助？
• 任务： 他们试图完成什么？
• 障碍： 为什么当前方法失败或需要太多努力？
• 成本： 障碍对他们实际意味着什么？时间损失、未解答的问题、困惑、风险或金钱。只包含上下文中支持的后果。
• 期望的变化： 什么能让他们接下来的一个小时、一天或工作流程变得更好？
• 产品机制： 产品如何具体促成这种变化？
• 证据： 哪些是已展示、记录或验证的？
• 行动： 他们实际上可以点击、尝试、请求或阅读什么？

保持事实与假设之间的清晰区分。如果细节缺失，使用保守的语言，并在对用户的解释中标出实质性假设。不要编造具体的客户或工作流程。

构建内部问题模型

将其用作推理辅助工具，切勿作为发布文本：

处于[真实情况]的某人试图[任务]，但[障碍]。他们想要[结果]。产品通过[具体机制]提供帮助。

然后将其提炼为一个可识别的时刻。时刻比抽象类别更重要。

• 抽象：“财务团队需要简化的对账流程。”
• 具体：“付款总额与您的交易记录不匹配。”
• 抽象：“改进分布式部署的可观测性。”
• 具体：“部署失败了。您正在搜索三个服务来查找错误。”

一个好的标题可以以问题开头，也可以以期望的结果开头。选择最能快速告诉目标访问者“这是给我的”的方式。如果受众已经明确知道自己想要什么，那么以问题开头的标题未必最好。

构建信息

在内部思考以下要点。不要将它们打印成六个相同的网站章节。

1. 识别： 访问者已经体验过或可以想象到的真实场景。
2. 重要性： 什么仍未解决、困难、昂贵或不确定。通常一个具体后果就足够了。
3. 缓解： 什么变得可能或更简单。
4. 机制： 产品如何帮助访问者实现这一目标。
5. 可信度： 一个真实的例子、演示、能力、限制或来源，能赢得信任。
6. 下一步行动： 一个目标与承诺相符的 CTA。

第一屏通常应提供识别、解决方案和可信机制，无需访问者滚动。不要把半页篇幅花在渲染一个访问者已经理解的问题上。

撰写英雄区

• 标题： 一句关于访问者任务、问题或期望结果的清晰思路。具体优于巧妙。
• 副标题： 用一两句自然的句子说明它帮助谁以及如何工作。移除任何不会改变读者理解的词语。
• CTA： 一个真实操作，如“查看示例”、“阅读文档”、“尝试演示”或“联系维护者”，仅当该操作存在时使用。
• 视觉： 如果存在或被要求，优先使用真实工作流程、界面状态或前后数据对比，而非抽象的装饰性隐喻。

标题和副标题应各司其职。不要用不同的话重复三次相同的承诺。

将解决方案解释为原因，而非口号

对于每个重要功能，推理过程如下：

它做什么 -> 访客有什么变化 -> 为什么重要 -> 什么支持这一说法。

示例：

• 能力：在客户基础设施上对 Parquet、JSON 和 CSV 运行生成的 SQL。
• 变化：客户可以调查这些文件，而无需将其内容发送给托管的分析提供商。
• 意义：他们的数据保留在他们自己运营的基础设施内。
• 范围：这并不能证明整个系统没有安全风险。

在英雄区使用该链条中最相关的部分。根据需要将其他部分放在演示、工作流程章节、常见问题解答或文档中。

让文案听起来像人写的

听起来像人写的文案通常更具体、更不追求对称、更不急于自我解释。它感觉像是经过编辑的，而非一次性生成的。

优先使用

• 具体场景而非分类标签。
• 熟悉措辞而非概念术语。
• 仅对该受众和产品有意义的细节。
• 直接描述而非空洞的兴奋。
• 不同的句子节奏，有助于读者理解想法。
• 能阐明主张的有用示例。
• 诚实的限制、实际的权衡以及精确的技术术语（当这些能建立信任时）。
• 遵循实际思路的自然过渡，而非预制连接短语。

移除或重写

• 营销填充词： “解锁”、“赋能”、“无缝”、“前沿”、“颠覆性”、“下一代”、“革新”、“使能够”等词语，当它们取代意义时。
• 虚假对比： “这不仅仅是 X。这是 Y。”“停止做 X。开始做 Y。”“X 的未来已经到来。”仅当以正常语言解释实际差异时才使用对比。
• 结构声明： “在本节中，我们将探讨……”“让我们开始吧。”“这就是为什么这很重要。”不要告诉访问者你将要解释某事；直接解释它。
• 重复性陈述： 标题、副标题、三个功能卡片和结尾段落都做出相同的声明。
• 完美对称的章节： 三个卡片使用相同的语法模式、相同的字数以及一个整齐的总结，只是为了完成布局。
• 过度解释的意义： “这使企业能够掌控自己的成功。”如果后果显而易见，就停下笔。
• 空洞的情感语言： “告别难题”或“再也不用担心”，却没有具体理由。
• 勉强的对话技巧： 重复的反问句、虚假的轶事、勉强的幽默、过多的缩略语和人为的脆弱。
• 听起来不自然的句法美化： 密集的名词短语、形容词串以及用标点符号代替清晰句子的做法。

不要将词语黑名单作为你的编辑策略。 一个词语在合适的上下文中可以是恰当的。上述标点要求是一个项目风格规则；更深层的任务是修正思想、结构和证据。一个仅仅去掉破折号并将“利用”替换为“使用”的文案作者并没有解决问题。

在两个层面进行编辑

结构层面：

• 读者的实际问题是否可见，还是页面在谈论自己？
• 每个章节是否教了新的内容或消除了一个真正的反对意见？
• 产品是否在访问者失去兴趣之前出现？
• 论证是否仅仅是线性的，因为模型默认使用了模板？
• 是否存在不必要的总结、重复的阶段标签或夸大的新旧对比叙事？
• 内容是否遵循这个特定访问者决策的方式，而非通用的销售漏斗？

句子层面：

• 一个懂行的人会真的把这个句子说给另一个人听吗？
• 是否有更具体的名词或动词？
• 能不能删掉这个句子而不损失任何事实信息？
• 这个句子是否试图给人留下深刻印象，而非解释某事？
• 事实是否准确，好处是否经得起推敲？
• 在草拟的文案中是否有 em 破折号或 en 破折号？移除它们。

以访问者而非作者的身份阅读结果。如果听起来像排练好的推销，那就简化思路，而不是添加更多“人性化”的技巧。

负责任地运用心理学

将有心理学价值的原则用作诊断视角，而非操纵他人的借口。以下每条原则均为 [P] 级。

• 识别： 当人们能够识别被描述的情景时，他们会参与其中。 [P]
• 认知流畅性： 具体的语言和连贯的路径会减少认知负担。 [P]
• 信息线索： 标题和 CTA 应准确预测下一步内容。 [P]
• 控制感： 人们想知道他们可以检查、更改、保留或撤销什么。 [P]
• 信任： 证据、实际机制和公开承认的限制可能比宏大的声明更有用。 [P]
• 动机： 文案应与访问者想要实现的目标相连接，而不是制造不安全感或压力。 [P]

避免虚假稀缺性、虚假社会证明、编造的成本节省、无支持的性能比较、操纵性默认选项或暗示性保证。

页面架构视情况而定

不要为开发者 CLI、财务运营产品和消费者工具生成相同的着陆页。

对于专家或开发者受众： 通常以实际任务或技术成果作为开头。尽早展示命令、界面、示例、架构细节或文档链接。避免过度解释一个熟悉的问题。

对于运营类买家： 以一个可识别的事件或责任作为开头。解释他们可以调查、预防或完成什么，然后展示工作流程和限制条件。

对于不熟悉的类别： 尽早定义产品，将其锚定在一个已知场景中，并展示某人将如何实际使用它。新颖性本身并非价值主张。

对于单一功能或已明确的页面： 进行精确的修改。不要附加一个冗长的问题故事。

每个章节必须通过回答一个真实问题或反对意见来赢得其位置。如果不能，就移除它。

示例：Queryance

弱的、以功能为先的版本

面向财务运营的开源分析。将自然语言转换为 SQL，并在您的基础设施上对 Parquet、JSON 和 CSV 文件执行。

这首先描述了机制。它让访问者自己去琢磨关心的理由。

人性问题版本

找出你的付款金额为什么不匹配。

Queryance 帮助 SaaS 财务团队调查他们的记录差异。提出一个问题，审查 SQL，并在您自己的基础设施上针对 Parquet、JSON 或 CSV 文件运行它。

CTA： 联系维护者

第一句话命名了一个实际任务。第二句话解释了产品是为谁服务以及如何工作。仅当存在联系维护者的实际方式时，CTA 才合适。

一个过于卖力的版本

还在财务混乱中挣扎吗？

别再浪费时间在过时的电子表格上了。利用下一代智能财务运营，轻松实现对账。

这虚构了情绪，依赖行业陈词滥调，并且从未解释机制。它比好版本短，但信息量更少。

这些示例是起点，而非强制模式。如果真实客户使用不同的语言，在验证他们的意思后，优先使用他们的语言。

执行模式

遵循用户请求的范围。

审计

提供最关键的 3 到 5 个具体文案或层级问题。引用相关文本，描述访问者会误解或遗漏什么，并推荐有针对性的修复。识别已经有效的部分。不要无测量数据就声称转化率提升。

重写

为请求的章节提供可直接使用的文案，使用站点现有的品牌语调和风格指南。

创建

为缺失的网站页面或部分生成原创文案。

风格检查

根据上述编辑指南检查文案。提供结构性建议和句子层面反馈。