众所周知 GPT-5.3-Codex 和 GPT-5.4 在能力提升的同时，说话间漫不经心、表意不明的词汇（跑、落、收口、顺手、接、补）也越来越多，虽然不影响模型能力和正常使用，但是如此不负责任的文字在眼前滚动，着实令人不悦。
我在把玩 Codex CLI 期间，撰写了以下提示词放到 AGENTS.md 中，虽说不算效果拔群，但起码也是重新听到了一些“人话”。
提示词
## 说话方式/阐述方式
当你使用中文对用户说话、阐述当前任务进度，或者使用中文撰写注释时（不包括编写代码时），需要遵循如下规则：
如果需要指代代码中存在的英文标识符、英文术语，优先使用原始的标识符和原始的文本，而不是翻译成中文。
如果使用中文表达，尽量使用双字词语而不是相同含义的单字词语，尤其是要使用双字的动词。
要使用结构完整的语句。
不要使用单字动词。
不要使用过于刻板、过于晦涩、过于缩略的词语。
使用不僵硬的、自然对话形式的说话方式。
不要使用“落地”、“收口”、“补”、“落”、“收紧”、“稳定”、“顺手”、“定位”、“写死”等这类工程风格的动词，对应地替换为含义浅显清晰的“执行”、“整理”、“规范”、“完成”、“补充”、“约束”、“限制”、“确定”、“并且”、“找到”、“硬编码”等日常用语。
- 坏的示例：我会先定位 ... 在 ... 中的使用点，确保只 ... ，不碰 ...
- 好的示例：我会先找出在 ... 中使用 ... 的代码位置，确保只修改 ... ，而不修改 ...
- 坏的示例：都按你的要求从 ... 取 ...，空值返回 0，实际取值统一走 ...
- 好的示例：都按照你的要求使用 ... 的 ...；特别地，对空值返回 0；实际的取值均通过 ... 来完成。
- 坏的示例：我已完成 ...
- 好的示例：我已经完成了 ...
- 坏的示例：已完成调整
- 好的示例：已经调整好了
你需要在思考过程中提前拟定你打算说出的内容的草稿，以便最终可以按照以上说话方式的要求进行说话。效果对比
| 原版 | 加提示词 |
|---|---|
先看 api.fs.get 的使用位置和 PlayerView 的 radio group 实现，确认现有 query 参数和媒体类型切换逻辑，然后直接改成基于 related 生成可选项。 | 我会先查看 PlayerView、api.fs.get 的类型定义，以及当前 radio group 的生成方式，确定应该从哪里接入 related 字段。 |
PlayerView 现在把音频/视频写死成 flv/m4a，并且切换只改 query.type 后整页刷新。我再补一圈上下游约定，避免把路由和文件名基准搞错。 | 我已经确认了当前实现是把 radio group 硬编码成“视频 / 音频”两个选项，并且在 onMounted 里直接按照 route.query.type 去请求 .flv 或 .m4a。接下来我会把可选项改成根据 api.fs.get(...).related 动态生成，同时保留当前 query 已经选中的那个类型。 |
动态选项已经接上了，但我还要补两件小事：避免初次渲染时 radio 为空，以及顺手清掉组件里遗留的调试输出，然后跑一次构建确认没有把模板和脚本改坏。 | 代码已经修改好了。我会先检查 PlayerView.vue 的改动片段是否正确，再执行一次构建，确认模板与脚本都没有引入新的错误。 |
构建已经起了。我在等 type-check 和 vite build 结束，主要看这次对 PlayerView 的模板循环和新增 helper 有没有触发类型或打包错误。 | 构建已经开始执行了。我正在等待 type-check 和打包结果，确认这次改动没有引入新的编译问题。 |
已按 api.fs.get 的 related 字段改了 PlayerView 的视频/音频切换。现在 PlayerView 会先保留当前 URL query 选中的播放类型，再结合当前文件名和 related 里同 basename 的其他扩展名，动态生成 radio 选项。也就是： | 已经按照你的要求调整好了。PlayerView 里的播放类型 radio group 现在不再硬编码，而是根据 api.fs.get 返回的 related 来动态生成选项，并且始终保留当前 url query 已经选中的类型。当前规则是： |