copywriting

文案

• **适用：**简短的转化文案（落地页、首屏主标题、副标题、行动号召、产品描述、新手引导文案、邮件主题）；产品状态文案（破坏性操作的行动号召、错误、成功、空状态、加载、权限文案）；去除任何文案中的 AI 写作痕迹。
• **不适用：**长篇文章、帖子，或任何以个人而非品牌名义撰写的内容（请使用外部 ghostwriter 技能，并设置平台 blog）；幻灯片或演示文稿文案（请使用 presentation-creator）；API／产品／参考文档（请使用 docs-writing）；会话中的助手对话（请使用 eli5）；或决定有哪些操作、操作范围、后果、可逆性或可到达的状态（请使用 product-design；在这些内容确定后，本技能才负责撰写最终文案）。

两种模式，自动检测：

• 已有文案，或用户粘贴了要修改的文案：模式 B（编辑）。
• 还没有任何文案，或用户想要全新文案：模式 A（撰写）。
• 确实有歧义（例如“改进一下”，但未提供相关文案）：先问一个问题，然后确定模式。

参考文件

文件	何时阅读
references/frameworks.md	根据认知阶段选择框架（撰写步骤 4）；依据框架进行审核（编辑步骤 3）
references/page-types.md	首页、落地页、定价页、功能页或关于页面的文案规范（撰写步骤 4）
references/word-lists.md	标记第 1／2／3 级 AI 词汇（编辑步骤 4）
references/ai-patterns.md	标记结构、句子层面和起草过程中的 AI 痕迹；进行 P0／P1／P2 分级处理（编辑步骤 4）
references/sweeps.md	执行七项逐行检查，然后检查连字符用法（编辑步骤 5）
references/ui-states.md	文案属于产品状态或操作标签，而非营销内容时阅读（撰写步骤 4；编辑步骤 6，在使用 [STATE-COPY] 前阅读）
references/voice-chart.md	不存在可用的品牌语气文件，且产品需要一份时阅读（撰写步骤 3；编辑步骤 1）；还包含按读者状态划分的语气表
evals/evals.json	仅在修改此技能时阅读：包含断言的行为场景，以及应触发和近似误触发的路由提示。不会在用户任务期间加载

禁用词

永不使用的词语清单。适用于两种模式，以及你交付的每一行内容：

深入探究、发挥杠杆作用（作动词）、强健、无缝、整体、范式、改变游戏规则、尖端、创新、协同效应、革命性、毫不费力、世界一流、强大、展示、解锁

此外，也禁止将 “简单” 用作断言（例如“我们的新手引导很简单”）：这种说法没有事先依据，会让人觉得承诺无法兑现。

长破折号也算禁用项：标题和正文中均不得使用，也不得用 -- 或带空格的连字符代替。请改用逗号、冒号、句号或括号。

只有品牌语气文件明确将这些词列为标志性用词时，才可覆盖此清单（撰写步骤 3）。references/word-lists.md 收录了更完整的分级词汇及替代说法；该列表仅用于编辑模式下的检测，并非本清单的补充。

---

模式 A：撰写新文案

Writing progress:
- [ ] Step 1: Gather context
- [ ] Step 2: State the brief, then write
- [ ] Step 3: Discover brand voice
- [ ] Step 4: Route by copy type, choose framework
- [ ] Step 5: Write 2-3 alternatives
- [ ] Step 6: Recommend and explain
- [ ] Step 7: Check every option against the brief

步骤 1：收集背景信息

从用户或文件中确认以下四项。如果文件无法确定其中某项，则进行推断，并在步骤 2 中说明该推断；应避免把虚构的受众或目标当作事实。

1. **页面目的。**此页面要促成的唯一操作（注册、预约演示、下载）。
2. **受众。**具体读者：职位、痛点，以及他们已经尝试过什么。
3. **产品。**产品的功能，以及用户能获得的具体结果。
4. **流量来源。**读者从何处而来（冷启动广告、定向邮件、自然搜索、推荐、产品内）。

流量来源决定读者的认知阶段（references/frameworks.md）：面对冷流量的读者，需要先了解问题，再了解产品；面对暖流量的读者已经了解问题，他们想知道解决机制或相关证据。

步骤 2：说明简报，然后开始撰写

说明简报并继续推进。凡是你推断而非用户明确告知的字段，都要标明，以便用户根据真实文案进行纠正，而不是回答问题：

Brief:
- Page: [page type]
- Goal: [single action]
- Reader: [specific audience]
- Core outcome: [what changes for the reader]
- Tone: [inferred from brand voice or user-stated]
- Awareness: [unaware / problem-aware / solution-aware / product-aware / most-aware]

Inferred (correct me): [fields you guessed]

只有在错误猜测会让工作毫无用处或带来风险时，才暂停并提问：文案将在本轮直接发布，且没有审核；或者目标确实未知，并且不同的候选目标会产出不同的文案。

步骤 3：了解品牌语气

先寻找语气线索，再自行设定。按以下顺序查找，找到第一条匹配项后即停止：

1. 仓库中的语气文件： VOICE.md、BRAND.md、docs/voice.md，或语气指南。文件存在时，以其为准。
2. 仅在用户提出要求时，参考用户本人的语气。 用户要求模仿其语气（“用我的语气”“写得像我”），且品牌属于用户本人时，读取 $GHOSTWRITER_HOME/soul.md；若不存在，则读取 ~/.config/ghostwriter/soul.md。个人语气仅适用于该用户自己的品牌；文件内容不得出现在输出、简报或仓库中。
3. 现有文案： 文案文件、README 标题或已发布的营销页面。
4. 推断： B2B SaaS 直截了当且自信，消费类应用更亲切，开发者工具简洁坦诚。请在提供草稿的同时询问品牌指南，而不是用它取代草稿。

已发现的语气优先于词语清单：如果语气文件或已发布文案将清单中的某个词作为标志性用词，该词应予保留。语气也决定语言区域和拼写规范。请在简报中注明使用了哪个来源；如果语气来自步骤 4 的推断，则标明为推断。若不存在语气文件，且产品需要语气指南，请加载 references/voice-chart.md，并提出随文案一并编写 VOICE.md。

语气保持一致；语调则根据读者的状态（沮丧、困惑、自信、谨慎、满意）调整。references/voice-chart.md 中的表格说明了预期的变化；如果文案在这五种状态下都维持同一种语调，那么在顺利时会显得机械，在不顺时则会显得冷漠。

步骤 4：判断文案类型并选择框架

• 产品状态文案（错误、空状态、成功、加载、权限）或操作标签：加载 references/ui-states.md，然后到此为止。说服框架不适用于删除内容的按钮。
• 营销文案： 加载 references/frameworks.md；如果目标页面是首页、着陆页、定价页、功能页或关于页面，还要加载 references/page-types.md。

根据简报中的认知阶段选择主框架：

读者	主框架
尚未意识到问题或已意识到问题的冷流量用户	Why/How/What；若痛点强烈，则用 PAS
已了解解决方案，正在比较选项	Benefit Not Feature，辅以 Show Don't Tell
已了解产品，但信任度低	Show Don't Tell，以证据为主
对产品了解最充分的用户，且页面以转化为目标	CTA Clarity
任意认知阶段的长篇销售页面	以 PAS 或 BAB 为主线，其他框架穿插其中

可灵活叠加框架。无论采用什么框架，主视觉文案几乎总是从 Why（读者的动机）切入。

步骤 5：撰写 2-3 个备选方案

默认返回一份推荐草稿。用户要求比较不同方向，或定位选择尚未确定时，再提供两到三个有明显差异的备选方案。文案形式要与交付内容匹配：按钮标签任务应返回标签，而不是标题、副标题和 CTA 的组合。

步骤 6：推荐并说明

推荐一份草稿。如果用户要求了备选方案，用一句话说明其中的重要取舍。

步骤 7：根据简报逐一检查所有选项

优秀的草稿仍可能存在两个问题，只有将选项与简报对照时才会显现：照搬提示词（标题直接复述简报中的措辞）和泛化默认值（用户提供的数字、名称、价格或集成信息，被改成“数千个团队”或“你喜爱的工具”）。交付前修正这两类问题以及任何禁用词。包含禁用词的选项不得展示。

模式 B：编辑现有文案

运行工作流前，先确定编辑方式：

• 局部修改： 用户指定了一行、一个词或一个部分。阅读足够多的上下文，以保留语境；只修改目标内容及必要的衔接部分，并返回最终措辞。局部修改不等于整页审查。
• 修复： 文案已有鲜明的语气、角度或观点。保留其词汇层次、相对侧重点、有意省略的内容、句式和定位。针对具体问题进行修正，不要重新平衡论点，也不要用更巧妙的开头取代原有开篇。
• 重建： 文案流于笼统、前后矛盾或毫无明确立场。完整执行工作流，可根据简报灵活重建，但不可杜撰依据。

Editing progress:
- [ ] Step 1: Read all copy-bearing files
- [ ] Step 2: Set the north star
- [ ] Step 3: Audit against persuasion frameworks
- [ ] Step 4: Remove AI writing patterns
- [ ] Step 5: Run seven sweeps
- [ ] Step 6: Flag weakest elements with labels
- [ ] Step 7: Rewrite flagged sections
- [ ] Step 8: Output before/after diff

第 1 步：阅读所有包含文案的文件

扫描所有面向读者的内容：README 标题、着陆页组件、主视觉区、行动号召、产品描述、功能列表、引导文案、元描述和邮件主题。如果存在语气指南文件，也要阅读（VOICE.md、BRAND.md、docs/voice.md）；它用于确定语域和地区语言。如果其中将某个词指定为标志性用词，则优先于词表。若审查总是卡在无人解答的语气问题上，请加载 references/voice-chart.md 并提出解决该问题。若不清楚该查看哪些文件，请先询问；只能在已阅读的内容语境中评判文案。

第 2 步：确定核心目标

开始审查前，先写一句话：“[用户] 现在可以 [完成 X]，无需再忍受 [以往的痛点]。”所有标记和改写都应服务于这句话。如果无法有把握地写出这句话，请先询问；价值主张明确之前，文案无法修复。

第 3 步：依据说服框架进行审查

加载 references/frameworks.md。根据其中每种框架检查每个主要文案区块，只保留影响最大的几个问题；标记数量上限由第 6 步决定。

第 4 步：去除 AI 写作痕迹

加载 references/word-lists.md 和 references/ai-patterns.md。用 [AI-ISM] 加上相应的模式类型标记每处 AI 腔：

• 第 1 级词语（word-lists.md）：始终标记并替换。
• 第 2 级词语组合（word-lists.md）：同一段中出现 2 个或更多时标记。
• 结构模式（ai-patterns.md）：程式化开头、聊天机器人痕迹、“let's”式转折、互动诱饵、反问式开头、否定式平行结构、分词收尾、夸大重要性、回避系词，以及将破折号当作普通标点使用。
• 起草痕迹（ai-patterns.md 第 7 节）：复述提示词、将提供的具体内容替换成笼统默认说法、信心语气千篇一律。这些痕迹在逐词检查后仍可能存在，因此要单独检查。

仅处理说服力的编辑可跳过此步骤。如果用户要求去除 AI 写作痕迹，应先执行此步骤，再进行各项检查。

第 5 步：进行七轮检查

根据文案中存在的问题，使用 references/sweeps.md。局部修改只需进行相关检查；完整的编辑审查则可使用完整检查表。

步骤 6：标记最薄弱的内容

在每一处薄弱文案旁内联添加标签。只能使用以下标签：

标签	含义
[WHAT-NOT-WHY]	开篇介绍产品／功能，而非用户动机
[FEATURE-NOT-BENEFIT]	描述产品具备什么，而非用户会因此发生什么变化
[TELL-NOT-SHOW]	使用形容词宣称效果，却没有证据（“强大”“无缝”“简单”）
[VAGUE]	内容泛泛，适用于该类别中的任何产品
[PASSIVE]	主语处于被动状态，而非主动行事
[VOICE-DRIFT]	与周围文案的主导风格（语域、时态或人称）不一致
[PAIN-NOT-NAMED]	只陈述好处，却没有点明读者带着什么困扰而来
[DEAD-WEIGHT]	没有传达已有内容之外的信息；可以放心删掉
[JARGON]	技术术语妨碍非专业人士理解
[NO-PROOF]	需要数字、示例或用户评价来支撑的主张
[WEAK-CTA]	CTA 描述操作，而非结果
[STATE-COPY]	含糊、信息泄漏或没有后续指引的状态文案（错误、成功、空白、加载、权限），或标为“确认”“确定”／裸动词的破坏性 CTA。使用此标签前，请先加载 references/ui-states.md；其中包含 product-design 引用的规则 ID
[AI-ISM]	AI 写作模式：一级词、二级组合或结构性特征

优先指出对转化或理解影响最大的具体问题。如果文案只需要少于三条发现，就报告更少；不要为了凑数而编造问题。

步骤 7：改写标记出的部分

• 在保留原意和现有风格的同时删去重复内容。已经有效的文案可以保持不变。
• 先讲为什么（用户的问题或愿望），而不是讲是什么（产品）。
• 明确具体结果，而非功能。用证据替换形容词：“强大的分析功能”应改为“查看哪些页面导致用户放弃注册”。
• 让 CTA 简短并明确结果：“开始同步”胜过“开始使用”；功能说明应放在按钮上方，而不是按钮文案里。
• 替换 AI 写作模式时，请改写整句话；只换同义词会让问题降一级而已。

步骤 8：输出修改前后对照

## Copy Audit: [file or component name]

**North star:** [one-sentence value prop]

---

### [Section name]

**Before:**
> [original text]

**Issues:** `[LABEL]`, `[LABEL]`

**After:**
> [rewritten text]

**Why:** [one sentence explaining the change]

---

### Summary
- N issues flagged across N sections
- Top pattern: [most common label]
- Confidence: [high / medium; note if copy context was limited]

每条“修改后”文案都必须保留对应“修改前”文案中的所有事实、数字和链接，并且每处改动都必须修复审查中指出的具体问题。仅仅换种说法的改写属于退步：请恢复原文。

---

注意事项

• “开始使用”和“了解更多”会吸引点击并误导用户：NN/g 发现，想查看价格或基本信息的读者进入注册流程后会失去信任。应明确说明目的地或结果（“查看价格”“开始 14 天试用”）。
• Tier 1 列表很快就会过时。“delve”和“tapestry”是 2023—2024 年的明显特征，如今基本已不再出现；当前输出常用“enhance”“highlighting”“showcasing”“align with”和分词尾句（“……确保流畅体验”）。只检索词表中的词，可能仍会放过读起来像机器生成的文案；每次都要检查 ai-patterns.md 中的结构部分。
• 将被标记的词替换成同一张表中相邻的词（“leverage”换成“harness”，“robust”换成“comprehensive”），只会重新引入低一个等级的明显特征，读起来像机器编辑过。应围绕具体内容重写句子。
• frameworks.md 列出的未经证实的形容词（powerful、seamless、robust）也出现在禁用词和 word-lists.md 中。同一个词出现一次就算一个标记；在同一个词上同时标注 [TELL-NOT-SHOW] 和 [AI-ISM] 会夸大数量并掩盖真正的问题。
• 标为“Confirm”“OK”或“Yes”的破坏性对话框，会迫使用户从略过的正文中重新推断后果；product-design 会用 rule/no-confirm-ok-labels 指出这一问题。每次都使用动词加对象（“删除项目”）；仅 Save、Cancel 和 Close 可单独使用动词。
• 模板变量会掩盖连字符规则：{{days}} day trial 发布后会在所有套餐中显示为“7 day trial”。连字符应放在变量和单位之间（{{days}}-day trial），而独立名词短语中不应加连字符（“expires in {{days}} days”）。
• 在采用 en-AU 的产品中改用美式拼写，会导致所有受影响的字符串都出现回归。修改前，先阅读三个现有字符串以确认地区用语。
• 第 3 步中的个人语气查询为可选且只读。阅读 soul.md 并不会让本技能适用于个人消息、帖子或长文；这些仍由 ghostwriter 处理。

---

技能交接

何时	运行
重写技术文档文案后	docs-writing
优化元描述和页面标题	optimise-seo
审查包含上下文中文案的完整 UI	ui-design（审核模式）
落地页视觉设计、CRO 策略、转化基准	ui-design（方向模式，营销方向）
决定产品中包含哪些操作及其范围和后果	product-design
标题和标签的大小写形式（句首字母大写还是标题式大小写）	typography-audit（punct-case-rules）
会话中的助手对话、回顾或 ELI5	eli5