跳转到内容
API 入口

产品工作

用 AI 写原型文案

用 AI 写原型文案指南说明如何根据用户任务、界面状态、语气与操作后果生成按钮、提示、空状态和确认文案,并通过状态矩阵与复核清单保持一致。

预计阅读
3 分钟
首次发布
最近更新

用 AI 写原型文案,应该从用户此刻要完成的任务、系统真实状态和下一步动作出发。AI 能生成多种表达和检查一致性,但不知道操作后果、权限与技术限制;按钮、提示和承诺必须由产品、设计与研发确认。

项目 说明
阅读时间 约 7 分钟
适合人群 产品经理、交互设计师、内容设计师、运营和前端开发者
核心产出 按钮、字段说明、空状态、确认提示、成功反馈和恢复文案
使用前提 有用户任务、界面状态、业务规则、术语表和语气边界
不适合 用文案掩盖产品缺陷、承诺未确认结果,或生成操纵性表达

界面文案无法修复错误的信息架构、缺失恢复动作或不公平默认值。若用户必须猜下一步,先调整流程;若操作不可逆,先提供保护机制,再优化文字。法律、隐私、付费和数据删除文案需按组织流程审校。

文案位置 要回答 常见风险
按钮 点击会发生什么 用“确定”“提交”隐藏后果
字段说明 填什么、为何需要 索取超出任务所需信息
空状态 为什么为空、能做什么 只有装饰性口号
错误状态 发生什么、如何恢复 归责用户或暴露内部错误
确认提示 影响范围、是否可撤销 用恐吓语气推动操作
  1. 写任务句:说明用户是谁、当前状态、目标动作和操作后果。
  2. 建立状态矩阵:列默认、加载、空、成功、失败、无权限、部分完成和不可用状态。
  3. 准备术语与语气:固定对象名称、动词、称呼和禁用词,避免同一概念多种叫法。
  4. 让 AI 生成候选:要求每个版本说明适用状态与取舍,不只追求“更吸引人”。
  5. 在界面中检查:核对长度、层级、读屏顺序、移动端换行和按钮与实际动作一致性。
  6. 跨角色复核:产品确认规则,研发确认状态,设计确认层级,内容负责人确认一致性。

以下对象和规则均为教学假设,不代表真实产品能力。

任务:用户要删除一个共享模板。
规则:删除后无法恢复;不会删除用该模板创建的既有项目;只有所有者可操作。
界面:确认对话框,需要标题、说明、取消和主操作按钮。
语气:中性、直接,不制造紧迫感。
元素 文案草案 依据
标题 删除共享模板? 直接说明对象和动作
说明 删除后无法恢复。已用此模板创建的项目不会被删除。 说明不可逆性和影响边界
取消按钮 保留模板 比“取消”更明确结果
主按钮 删除模板 与实际动作一致
无权限提示 只有模板所有者可以删除。你可以联系所有者处理。 说明原因和下一步
处理中:正在删除模板…(主按钮禁用,避免重复操作)
成功:模板已删除。(返回模板列表)
失败:暂时无法删除模板。请保留当前页面后重试;如问题持续,联系支持。

失败提示中的恢复方式仍需研发确认。如果失败可能由权限变化导致,应显示更准确状态,不应一律写成“网络问题”。

检查项 复核问题 合格信号
准确 文案是否与真实状态和后果一致? 不承诺未确认结果
可行动 用户是否知道下一步? 错误和空状态有可执行动作
一致 术语和动词是否全流程统一? 按钮、标题、帮助文档同名
可访问 不依赖颜色、位置或图标才能理解? 文字能独立说明状态
伦理 是否利用羞辱、恐惧或误导推动选择? 两种选择后果清楚且平衡
  • 把所有按钮都写成“确定”,用户不知道会保存、发送还是删除。
  • 用“出错了”结束,没有恢复动作或数据保留说明。
  • AI 生成友好语气,却加入未经确认的“马上完成”“绝不会丢失”。
  • 空状态写长口号,真正的开始入口被藏在后面。
  • 原型、产品和帮助中心使用不同对象名称。

按钮文案应该用动词还是名词?

Section titled “按钮文案应该用动词还是名词?”

优先使用能说明结果的动作短语,例如“保存草稿”“发送邀请”。具体长度与界面空间需要一起检查。

可以发现术语差异并生成候选,但需要可靠的文案清单、状态上下文和人工复核,不能只做全局替换。

只解释用户需要知道且可行动的原因,不暴露内部实现、安全细节或无法确认的推测。

把文案放进真实界面和任务中观察用户能否预测操作后果与恢复方式,而不是单独询问“喜欢哪句话”。

原型文案是产品行为的一部分。先确认任务、状态和后果,再让 AI 生成与检查表达;清楚和诚实比“更有吸引力”重要。