AI写UI文案，应先知道按钮会做什么、提示在什么状态出现、哪些承诺不能说，再生成候选。把文案放进带编号的字符串表，逐条检查业务含义、变量和长度，最后回填界面；“更短、更亲切”本身不能保证用户点对操作。
以一个线下开放日的候补流程为例：名额已满时可以加入候补，有空位后会收到通知，但不会自动报名成功。可以用墨刀AI客户端整理界面文案与业务规则，让AI按同一规则生成按钮、状态说明和错误提示，再由产品与设计选择。
先把文案槽位连到状态和动作
下面的流程是自拟练习。用户尚未候补时，可以提交候补；服务器确认加入后，页面显示“已加入候补”；用户可以退出；请求超时但结果未知时，先查看当前候补状态。退出后原候补顺序不保留，重新加入按新的提交时间排序。这些都是本例的业务约定，并非所有活动都应这样设计。
把每处文字当成一个有上下文的槽位，记录稳定ID、触发条件、组件、原意和下一步动作。按钮最多6个可见字符是本项目的初始限制，提示区域允许换行；如果说明不下关键后果，应调整布局，而不是删掉后果。
| 字符串ID | 何时出现 | 必须表达的意思 | 呈现限制 |
|---|---|---|---|
| waitlist.join | 名额已满，尚未候补 | 加入候补列表，不能承诺取得名额 | 按钮，最多6字 |
| waitlist.joined | 服务器明确确认加入 | 候补成功，报名尚未完成 | 状态文字，最多8字 |
| waitlist.leave | 已经候补 | 退出候补 | 按钮，最多6字 |
| waitlist.unknown | 提交后结果无法确定 | 当前结果未知，先查看状态 | 说明可换行，附查看入口 |
| waitlist.event | 候补详情页 | 指明对应活动，保留{event_name} | 允许多行，不截去识别信息 |
这一步也能暴露缺少的业务规则。如果没人知道“退出是否影响顺序”，先补规则，不要让AI选一个听起来更友好的答案。已有组件却还没确定提示载体时，可先参考Toast、横幅与通知中心的选择方法；载体确定后再写适合该位置的文字。
让AI在同一语义内生成候选
把规则和槽位一起提供，再限定可变与不可变的部分。可变化的是措辞、句子顺序和语气；不可变化的是动作对象、成功条件、退出后果、变量名称和系统实际提供的恢复路径。
为线下开放日候补流程生成简体中文UI文案。语气平实、清楚，不使用“抢占、秒到、保证成功”。按字符串ID输出两个候选，并解释候选差异；如果没有有意义的第二种写法，可以只给一个。按钮最多6个可见字符。加入候补不等于报名成功，收到空位通知后仍需确认。请求结果未知时不能写提交失败或鼓励反复提交。保留{event_name}原样；发现规则缺口时单列问题，不补造答案。
设计工具已经把文案改写、缩短作为独立任务，例如Figma的AI文本改写说明。但缩短文字解决的是表达长度，业务语义仍需人来判断。不要把任何工具给出的“优化建议”直接当作正确版本。
按钮先选对动作，再讨论语气
对于加入候补按钮，“立即报名”“抢占名额”“加入候补”都是4个字，只有最后一个符合本例的实际结果。“立即报名”会让人以为点击后已获得参加资格；“抢占名额”还暗示速度决定结果，而当前根本没有可分配名额。
另一个候选“申请候补”容易让人联想到审核流程。如果本例提交后直接进入候补列表，没有审核步骤，用“加入候补”更准确。选词的依据是系统行为，而不是哪个按钮听起来更积极。
退出确认框可以使用以下组合：
- 标题：退出候补？
- 说明：退出后不保留当前顺序。重新加入时，将按新的提交时间排序。
- 主要操作：确认退出。
- 保留当前状态：继续候补。
这里不使用“是／否”，也不把返回按钮写成“取消退出”，减少连续否定带来的理解负担。按钮文字、视觉强调和实际执行的动作要一致；如果主按钮写“继续候补”却执行退出，再清晰的文案也救不了交互错误。
错误提示区分“失败”和“结果未知”
请求超时可能发生在服务器已经成功处理之后。因此，本例在尚未查明结果时使用“未能确认结果，请查看候补状态”，按钮为“查看状态”。它告诉用户当前掌握的信息，也提供了系统确实具备的下一步。
只有服务端明确拒绝，并知道原因时，才使用对应失败文案。例如活动已经关闭候补，可写“本场活动已关闭候补”，并提供返回活动详情的路径。若只是网络连接断开，不要替服务端断言“候补失败”，更不要许诺“您的信息已保存”。
Microsoft的错误提示原则强调说明发生了什么、对用户有什么影响以及能采取什么动作。本例采用这些信息原则，不照搬桌面系统的控件命名。对用户没有帮助的内部错误栈不必放进正文；支持人员需要的错误编号可以放在适当的详情位置。
字符数、占位符和视觉宽度要分别检查
把最终候选保存成机器可读的字符串表，有利于检查键名和变量。比如：
{
"waitlist.join": "加入候补",
"waitlist.joined": "已加入候补",
"waitlist.leave": "退出候补",
"waitlist.confirm_leave": "确认退出",
"waitlist.keep": "继续候补",
"waitlist.check": "查看状态",
"waitlist.unknown": "未能确认结果，请查看候补状态。",
"waitlist.event": "活动：{event_name}"
}先检查字符串ID是否遗漏或重复，再检查 {event_name} 是否仍然完整。AI把它改为 {活动名称}、删掉花括号，或直接替换成一个示例名称，都可能让程序无法正确插入数据。变量本身不能为了“读起来更自然”随意改名。
其次明确计数口径。对本例不含表情符号的简体中文按钮，可以按Unicode码点计数，标点也计入。JavaScript里 Array.from(text).length 能按码点计数；它并不等于所有语言中的可见字形数量，也不等于实际占用的像素宽度。本例不把emoji或组合字符纳入这套简单计数。
动态值要替换后再看。用“开放日”和“智能制造与城市更新跨学科实验室年度开放日”分别替换 {event_name}，观察长标题是否遮住退出操作，以及换行后能否继续读到所属场次。不能只验证短示例，也不能把代码中的变量名长度当成最终显示长度。
把文案放回整段流程，检查前后是否一致
设计稿中至少放入四种状态：可加入、正在提交、已经候补、结果未知。逐次读出用户看到的文字，再说明下一步会发生什么。如果提交中的按钮仍可连续触发，或者已经候补页还写“报名成功”，需要同时调整状态与文案。
同一词语要保持同一含义：本例“候补”始终指等待空位通知；“报名成功”只在用户后续取得并确认名额时使用。列表、详情、邮件通知与退出确认框不应各自换一种叫法。需要解释术语时，在第一次出现的说明里讲清楚，而不是每个按钮都扩成一句长话。
回填后分别检查窄屏、放大文字和长活动名称。重点看信息是否被裁切、按钮是否仍能辨认、关键否定词是否换行到难以发现的位置。达到字符上限不等于布局合格；反过来，布局空间不足也不构成删除“不会自动报名”等关键限制的理由。
交接的是字符串和规则，不是一页好听的句子
最终交付表保留字符串ID、采用文案、触发条件、变量、布局约束和确认人。若拒绝某个候选会影响后续协作，简短记录原因，例如“立即报名：误导用户已经获得名额”。下一次改规则时，研发能按ID找到受影响的提示，设计也知道哪些词不能单独润色。
先完成一个流程，再把通过讨论的语气与词语沉淀为团队约定。需要了解如何组织本地规则与输出文件，可以参考墨刀AI客户端使用指南。AI擅长提供表达选择，最终选择应让用户准确预期点击后的结果。
