Codex文案机械因默认“功能优先”，需用四段式提示词（Goal+Context+Constraints+Done when）锚定语气，配合/plan模式梳理风格锚点、分层注入语气信号，并通过朗读、锚点对照、替换压测三步验证顺滑度。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Codex生成的文案常被反馈为机械、刻板、缺乏人味，尤其在按钮文案、提示语、错误信息等轻量文本场景中尤为明显——这不是模型能力不足，而是它默认按“功能准确优先”原则输出，不主动模拟语气、节奏和语境温度。
用四段式提示词锚定语气风格
不要只说“把这句话改得自然一点”。Codex不会凭空理解“自然”指什么。必须用 Goal + Context + Constraints + Done when 明确交付标准。
Goal：将登录页按钮文案从“提交”改为更友好、有行动感的表达；
Context：该按钮位于 src/pages/LoginPage.tsx 的表单底部，当前是 ；
Constraints：保持 JSX 结构不变，仅替换字符串；不添加注释；不改动 onClick 逻辑；
Done when：输出文案带轻微口语节奏（如“马上登录”“这就进去”），避免“请”“敬请”“谨此”等书面套语，且长度控制在4字以内。
这一步必须写全四要素，否则 Codex 会默认走技术文档风格，生成“确认提交”“执行登录操作”这类反人类表达。
启用 /plan 模式预判语气适配点
当文案涉及多处上下文联动（比如按钮文案要和 nearby 的提示语、错误提示、成功弹窗保持语气一致），别急着让它改，先开 /plan：
先不要修改代码。请阅读项目中所有用户可见文案文件（重点关注 src/locales/zh-CN.json、src/components/ui/Toast.tsx、src/pages/LoginPage.tsx），梳理出当前项目高频使用的语气特征：是偏简洁指令型（“继续”“跳过”“重试”），还是带温度的陪伴型（“再试一次吧”“我们帮你重置”）？找出3个最典型的句子作为风格锚点。
【注意：如果项目没用 i18n，它可能直接扫描 JSX 字符串，导致漏掉部分文案；务必确认 locale 文件是否存在】
等它列出风格锚点后，你再指定：“请按‘陪伴型’风格重写登录按钮文案，参考句式‘再试一次吧’的停顿和主语隐含逻辑。”
分层注入语气信号
方法一：前置语气指令
在提示词最开头加一句不可省略的引导语：“请以一线产品运营同事的口吻输出，带0.3分调侃感，但不过度活泼。” 这比后期润色更高效——Codex 会在 token 生成初期就调用对应语义向量。
方法二：约束词替代法
不写“要自然”，而写“禁用以下词：敬请、烦请、特此、谨此、予以、加以、进行、完成”；同时要求“必须包含以下任一元素：语气助词（吧/啦/哦）、动词前置（‘来试试’‘点这里’）、主语省略（‘好了’‘搞定’）”。
方法三：温度值微调（仅限 CLI 或插件高级模式）
在 Codex CLI 中运行时，追加参数 --temperature 0.75。低于 0.6 容易死板，高于 0.8 可能失控跑偏，0.7～0.75 是轻量文案的黄金区间。
验证是否真“顺滑”的三步检查
第一步：读出来。把生成文案单独复制到备忘录，用手机朗读功能播放。卡顿、倒装、拗口的地方就是硬伤。
第二步：对照锚点句。把它和你之前选定的3个风格锚点句并排放，看节奏单位（2+2、3+1、4字整句）、主语显隐、助词使用是否趋同。
第三步：人工替换压测。把生成文案中的关键词替换成近义词（如“马上”→“立刻”→“这就”），看哪一版读起来呼吸最顺——Codex 本身不评估“顺”，但你能。
