让 AI 写出自然日语的技巧

语法虽然正确，但读起来让人疲惫。读到一半就想打瞌睡。在第一行你就意识到：“啊，这是 AI 写的。”

让 AI 用日语写作时那种独特的违和感，至今仍是许多人面临的难题。很多人通过实验，开发出了消除这种不适感的技能和系统。

在本文中，我将总结通过日常写作和社区成果验证的实用见解，并从以下四个维度进行梳理：

• 模型选择：为什么选择合适的模型比优化框架（harness）更重要
• 推荐写作流程：五步法，旨在降低读者的认知负荷并营造句子的节奏感
• 推荐技能：前辈们提供的必备工具，用于控制句子长度并防止读者迷失方向
• 实际写作环境：突破“增加规则反而带回 AI 味”这一瓶颈的仓库结构

首先，我要明确指出：“模型选择” 比提示词或钩子（hooks/harnesses）更有效。

截至 2026 年，在日语写作方面，Gemini 3.8 Flash 遥遥领先，其次是 Kimi K3。Claude 曾因文笔自然备受赞誉，但由于其针对编码的专业化调整，如今变得明显生硬且棱角分明。ChatGPT 依然表现平平，段落长度过于均匀，结构像教科书一样刻板，留下了最明显的 AI 痕迹。

然而，仅依赖模型的原始输出会导致句子节奏同质化，并将认知负担转嫁给读者。我们需要流程和系统来发挥模型固有的优势。

推荐写作流程

结合当前的知识，我们现在应该采取的写作流程可以概括为这五个步骤。

1[步骤 1] 信息筛选与删减（摒弃不必要的善意）
2   ↓
3[步骤 2] 设计读者的心理地图（全局顺序与连接）
4   ↓
5[步骤 3] 设计语调与变化（有意分配热度/重点）
6   ↓
7[步骤 4] 分离写作与机械检查（通过 PostToolUse Hook 拒绝违规）
8   ↓
9[步骤 5] 人类打磨最后 10%（记录差异以反馈至规则中）

步骤 1. 写作前的信息筛选与“删减”

AI 文本难以阅读的最大原因是“转嫁认知负荷”（Tsubota-san / @tsubotax）。它将前提、补充说明和预防性的安抚塞进单个句子中。铁律是：在让 AI 写作之前，先删减那些不用于指导“对方下一步行动”的信息。

• 在前两行确定“这是写给谁看的，需要做出什么决定”
• 每个段落只分配一个角色，例如“选项差异”、“决策材料”或“验证方法”，并丢弃不符合任何角色的段落
• 删除所有不影响决策的括号内补充说明

步骤 2. 不破坏读者“心理地图”的全局设计

正如 Keiichiro Shikano (@golden_lucky) 所指出的，文本崩溃源于“直到读下去才清楚意图的伏击”或“缺乏与前一段落的连接”。要为读者准备好路径，以免他们迷路。

• 首次引入概念时，按顺序排列，使读者只需顺次阅读即可识别类型和角色
• 在引入新信息之前，先在读者脑海中铺设接收该信息的路径
• 始终在标题后紧跟一句连接上一段落的句子

步骤 3. 有意嵌入“偏差（变化）”

AI 倾向于以相同的温度讨论所有话题，但人情味的本质在于“偏差”（Natsu-san / @art_reflection）。对有趣的话题要痴迷地详述，而对前提则一笔带过。在结构阶段有意分配热度强度。

步骤 4. 分离写作与机械检查

你在提示词中列出的禁令越多，模型就越畏缩，句子也越短。让它自由书写，然后在文件输出后立即通过 Hook 进行机械检查。如果违反规定，不要仅仅替换单词——要求它重写包含问题的整个句子。 分离写作与检查是保持节奏的关键。

步骤 5. 人类打磨最后 10%

不要指望仅靠 AI 就能达到 100 分。将 90% 的骨架留给 AI，让人类调整剩余 10% 的呼吸感和质感。记录这些修正，并将其反馈到未来的提示词或检查规则中。

推荐技能

我还介绍了一些源自社区的必备工具和技能，它们能提高日语文档的质量，这也是我目前正在使用的。

natural-japanese (@techtalkjp**

基于“AI 味更多体现在节奏而非词汇上”这一洞察而诞生的 Agent Skill (GitHub Repo / Explanation Article)。它基于人类和 AI 文本的实测语料库，机械地检测句子长度的变化（burstiness），摒弃了诸如“缺乏名词结尾”或“句首重复较少”等传统假设。

https://x.com/techtalkjp/status/2076808889371443679

japanese-tech-writing (@golden_lucky**

从商业书籍编辑视角提炼而成的 Prompt 技能 (Gist / Blog Post)。它消除了 LLM 那种夸大立场却不增加论点的语气，例如 handle directly、dig deeper 或 nothing less than ~，并规范顺序和主语位置，以便读者能顺次理解。

https://x.com/golden_lucky/status/2066751852088336698

Hooks × lint with good patterns (@yugen_matuni**

一种利用 AI 编码工具的 Hook 功能（PostToolUse）在文件写入后立即进行检查的系统。对于 NG 表达，它会返回具体的修正模式（good），如“真正价值在于~”，同时提示重写整个句子。

https://x.com/yugen_matuni/status/2088251220452679951

我的写作环境

在我的写作仓库中，我经历过这样的失败：“规则加得越多，句子越萎缩，AI 味又回来了。” 添加惯例导致 AI 退缩到安全、简短的句子中。

由此，我得出了设计原则：“不要减少规则，而是分离它们的位置。”

1[整体写作流程]
2
3[输入] style-guide / voice-samples / edit-patterns（仅判断标准）
4     ↓
5[执行写作] writer (Gemini 3.8 Flash)
6     ↓
7[自动检查] PostToolUse Hook (通过 detect-ai-smell.js 拒绝)
8     ↓
9[质量评估] reviewer (基于 rubric.md 的客观评估)
10     ↓
11[最终润色] 人工调整 & 发布 (将差异反馈至规则)

1kgsi-note-documents_v2/
2├── CLAUDE.md              # 操作策略、写作模式、Agent 权限
3├── GOVERNANCE.md          # 参考材料的大小限制、三个存储位置
4├── style-guide.md         # 小木曾的写作风格（仅判断描述，最多 4,500 字符）
5├── references/
6│   ├── voice-samples.md   # 风格样本（按功能划分的段落摘录）
7│   ├── edit-patterns.md   # 人工修正台账（前→后）
8│   └── rubric.md          # Reviewer 评估标准（距离基准）
9├── human-bench/           # 5 篇过去的人类撰写文章（writer 不读取；机器检查的阈值）
10├── scripts/
11│   ├── detect-ai-smell.js # 机器检查关卡（正则表达式、密度检查，附带 'good' 模式）
12│   ├── clean-japanese-spacing.js # 自动移除日文/西文之间的半角空格
13│   └── hooks/             # PostToolUse Hooks 等脚本
14├── editor/                # 本地笔记式预览 & 修订编辑器
15└── note/                  # 文章正文（最终草稿）

这是我自定义本地编辑器 (note-editor) 的界面。左侧的编辑会即时反映到中央相当于 Note 生产环境的预览中，并且可以从右侧窗格对选定范围进行部分 AI 修订。

自定义编辑器。通过 /note-editor 命令启动

三个存储位置与权限分离

1. 内化层（writer 读取）：style-guide.md、voice-samples.md。仅简要描述 writer 的判断标准（最多 4,500 字符）。
2. 机器层（Hook 自动扫描）：scripts/detect-ai-smell.js。无字符限制。汇总可通过正则表达式检测的禁令和修正策略（good）。
3. 判断层（reviewer 读取）：references/rubric.md。由独立的 Agent 根据目标评估完成稿的距离。

为了防止膨胀，当指南超过限制的 80% 时，我们会删除与新添加规则数量相等的旧规则。

实际文件摘录

以下是从实际运行文件中摘录的核心部分。

`GOVERNANCE.md`（位置与限制管理原则）

1如果 writer 和 reviewer 读取的材料膨胀，句子为了遵循规则而萎缩，AI 味就会回归。
2在此环境中，原则是“规则不是被减少，而是被重新安置”，并为每个位置设定限制。
3
4[三个存储位置]
5- 内化层（writer 读取）：style-guide.md, voice-samples.md, edit-patterns.md
6  → 保持精简。仅包含判断描述。不要清单化
7- 机器层（Hook 自动扫描）：scripts/detect-ai-smell.js 中的检查项
8  → 无限制。所有可用正则表达式编写的禁令都放在这里
9- 判断层（reviewer 读取）：references/rubric.md, references/voice-samples.md
10  → 距离标准是摘录。仅在混淆时每种类型提供一个模板

`scripts/detect-ai-smell.js`（机器检查与 'good' 对比）

1// detect-ai-smell.js 摘录
2const CHECKS = [
3  {
4    name: "回避性表达 / 模棱两可的态度",
5    patterns: [/一概には言え|メリットもデメリットも|一長一短|状況によります|と言えるでしょう|と考えられます/g],
6    limit: 1,
7    gate: true,
8    good: "明确站队并坚定陈述，紧接着放一句证据。不要以呈现双方观点作为结尾",
9  },
10  {
11    name: "预告式开场白 '重要的是...'",
12    patterns: [/重要なのは|大事なのは/g],
13    limit: 1,
14    gate: true,
15    good: "直接写出内容而不做预告。'重要的是 X' → 'X 是事实。因为 ~'",
16  },
17  {
18    name: "抽象对比的招牌",
19    patterns: [/という構図です|デザイン思考/g],
20    limit: 1,
21    gate: true,
22    good: "将对比写成谁做了什么的行为。'A 和 B 的结构' → 'A 做了~。B 没有做~'",
23  },
24];

`style-guide.md`（给 writer 的前提指令）

1本指南不是检查清单。如果你在写作时自问“我是否违反了规则？”，AI 味就会回归。
2当我写文章时，这些作为内化的前提运作。
3
4开始前，请口头阐述以下几点：
51. 我现在是以谁的身份写作（例如，实践中接触 AI 的设计师）
62. 我在写关于什么反应的内容（预期 → 现实 → 差距）
73. 我将如何收尾（留下未解决的问题还是断言立场并结束）
84. 语调设计。哪些部分要强调，哪些部分一笔带过

结论

无论框架多么精巧，或者选择的模型多么优秀，如果人类作者内心没有“原始的特定性”，文本就无法立足。

AI 吐出陈词滥调，是因为人类没有提供诸如“他们经历了什么以及感觉哪里不对”这样的素材。抽象的指令只能产生抽象的陈词滥调。

“当我实际接触它时，发现它比预期的更简单，令人失望”

“深夜 Pull Request 通过时，我感到一丝宽慰”

只有当存在有血有肉的观察、数字和专有名词的种子时，Gemini 3.8 Flash 的表现力和基于 Hook 的自动检查才能真正大放异彩。

AI 写作不是懒惰的自动化，而是一种编辑尝试，旨在高效地将你自己的违和感传达给读者。试着从回顾你刚刚写下的那一行开始吧。

注：本文本身即是基于文中所述的写作环境撰写的。