meiseki

meiseki — 日语明晰化技能

1. 目标声明

文章难读，并非因为词汇难，而是因为句法复杂。双重否定、冗长的定语修饰、 「の」的连用、过度名词化、冗长表达、埋在一个句子中的列举——这些问题无法通过替换词语来消除。 这项技能的唯一目标是 明晰度（clarity）= 不熟悉内容的读者读一遍就能正确理解。

「自然度」「规避 AI 检测」「文笔好」都不是目标。只关注明晰度。

2. 输出方针

• 默认只输出重写后的正文。 不附带分析、评述或「这里做了修改」之类的说明。
• 只有当用户明确提出「告诉我修改了哪些地方」「列出修改点」时，才在正文之后简要附上修改点。
• 用户要求提供阅读负荷评分时，在正文之后给出 before→after 评分（参见 §7）。

3. 适用范围 / 不适用范围

• 适用范围：技术文章、README、设计文档、内部文档、博客说明文字等说明性日语正文。
• 不适用范围：代码本身（包括注释等必须严谨的描述）、SNS 短文、小说和诗歌等创作、法律／医疗／论文等严谨文本。
• 混合文档：只修改适用部分，不适用部分（代码块、引用、严谨文本）保持原文不变。

4. 工作流程（按此顺序执行）

Step 1. 阅读全文并理解含义

准确把握事实、主张、结论和前提条件。如果误解了含义，明晰化就会失去意义。 尤其要在脑中理清否定、条件和修饰关系的逻辑结构。

Step 2. 运行 textlint（确定性层）

将原稿写入任意临时文件（扩展名为 .md），通过 Node.js 自带的 npx 运行 textlint 并读取 JSON。

# textlint を JSON フォーマットで実行（Skill 同梱の設定を使う）
npx --min-release-age=7 --yes --package [email protected] --package [email protected] --package [email protected] --package [email protected] textlint -c "<SKILL_DIR>/references/textlint.config.json" -f json "<INPUT_MD>"

• 将 <SKILL_DIR> 替换为此 SKILL.md 所在目录的实际路径。
• 将 <INPUT_MD> 替换为写入原稿的临时 Markdown 文件的实际路径。
• textlint 有检查结果时会返回退出代码 1。即使如此，也要读取 stdout 中的 JSON 并继续处理。
• 从输出 JSON 的各个 messages[] 中读取 ruleId（例如 preset-ja-technical-writing/no-double-negative-ja）和 line / column，以确定高负荷位置。

将 textlint 检查结果中的 I 类（乱码）与 A〜H 分开记录。 检查项包括 no-nfd、no-invalid-control-character、no-zero-width-spaces、no-hankaku-kana，以及 prh 消息中含有「I 文字化け」的检查结果（检测到 U+FFFD）。 I 类不是重写对象，应在 Step 8 中报告并询问用户是否需要处理。不计入 RLS（参见 §7）。

如果对象是 Markdown 文档，也要对同一个临时文件运行 markdownlint，并记录 before 违规列表。 这用于防止 Markdown 语法回归（确认重写没有破坏语法结构）。

# markdownlint を実行（Skill 同梱の設定を使う。Markdown 構文のリグレッションガード）
npx --min-release-age=7 --yes --package [email protected] markdownlint --config "<SKILL_DIR>/references/markdownlint.config.jsonc" "<INPUT_MD>"

• 不要对 textlint 应用屏蔽处理（例如移除代码块）。markdownlint 会检查原始 Markdown 结构本身。
• 存在违规时会返回退出代码 1，并以 file:line[:column] error MD###/alias 说明 的格式输出。 将每行的 ruleId 和行号记录为 before。
• 如果 npx 运行失败（例如离线），则跳过 markdownlint 并继续（开放失败；与 textlint 的处理方式相同）。

Step 3. 计算阅读负荷评分（before）

按照 §7 的公式计算 before 评分。特别记录 no-double-negative-ja（A）的数量。

Step 4. 按照 patterns.md 中的 A→H 进行重写

参考 references/patterns.md，按优先级 A→H 的顺序修改。

• A（否定与条件嵌套）优先级最高。 首先理顺双重否定。
• 从 textlint 发现的位置着手修改（A 双重否定 / B 单句过长・逗号 / C 连续汉字・冗长 / D 连接词重复・弱表达・冗长助动词 （ai-tech-writing-guideline） / E 表情符号项目符号・过度加粗（ai-writing/*） / G 固定套话（prh）・夸大用语 （no-ai-hype-expressions））。
• G 的 prh 检查结果不代表必须删除。 如果词语在语境中有实际含义（例如刚刚确实进行了多角度比较后出现的「多角的」），就保留。由 LLM 判断语境。
• 使用 Jev 快速判断（可选）：当 node scripts/jev-judge.js --check 退出代码为 0 时（已设置 TypeSafe API 密钥），可以将以下语境判断整理成 noul 问题，交给 jev-judge.js： G（prh 检查出的词语在此语境中是否有实际含义）・H（相邻的 2 个段落是否只是重复，未增加信息量）・ A（此处的双重否定是否为有意使用的 litotes）。将所有问题合并为一次调用（批量调用的耗时与单个问题相同，约 250ms）。 根据 noul 的概率决定是否采纳：p ≥ 0.8 时采纳 yes，p ≤ 0.2 时采纳 no； 只有 0.2 < p < 0.8 的判断才自行阅读并决定（2026-10-11 的实测结果显示，此区间内采纳判断的错误数为 0）。退出代码为 3（没有密钥）时跳过本项， 退出代码为 2（失败）时自行判断所有项目（沿用原有处理方式）。 用户要求设置密钥时，解析位于此 SKILL.md 上溯 3 层（插件根目录）的 scripts/jev-judge.js 的绝对路径，并引导用户运行 ! node "<绝对路径>" --setup （通过 ! 在终端中运行，密钥不会留在对话记录中。也要告知 1Password 用户，可以粘贴秘密引用 op://Vault/Item/credential，这样不会留下明文）。 密钥保存在 ~/.config/meiseki/，与插件的安装位置无关，因此更新或重新安装插件不会丢失密钥设置。 发送到 Jev 的内容仅包括待判断的句子或段落摘录以及问题文本。如果工作目录或其祖先目录中存在 .meiseki-no-jev 文件，jev-judge.js 不会发送任何内容，并返回退出代码 3。 也可以在项目的 .meiseki.json 中设置策略（{"jev": {"meiseki": "ask"}} 时，在会话中首次使用前通过 AskUserQuestion 征得同意，并在之后的调用中添加 --consented。 如果设为 deny，则静默跳过本项）。默认值为 meiseki=allow（视为已通过设置密钥表示同意）。 处理机密文档的项目可以提示用户使用标记文件或设置 deny。在使用 Jev 的会话中，修改点报告应包含判断数量、调用总耗时、采纳率和重新自行判断的数量。
• textlint 无法发现的句法问题由 LLM 判断：B 冗长的定语修饰，C「の」连用的深度和一般的名词化， E 判断是否改回散文、标题结构是否过度、冒号连接，F 将埋在句子中的列举改为项目符号，G 词典中不存在的固定套话， H 段落层面的改述重复和重新总结。 这正是 meiseki 的独特价值，仅靠 textlint 设置无法实现。

Step 5. 核对含义（最重要的保护措施）

• 将双重否定改写为肯定句时，务必确认逻辑（真值）没有反转。 例如：「負荷の増大を招かないとは言えません」＝「負荷が増えることがある」（肯定）。 如果改成「負荷が増えない」，就是误译，不合格。
• 确认条件、例外和数值之间的关系与原文一致。
• 删除 G（固定套话）时，确认主张的力度没有比原文更强或更弱。 即使删掉强调词，也要保留主张的方向和谓语的含义。
• 使用 H（段落冗余）删句时，逐句确认其是否只是零信息量的重复。 如果删除的句子带有新的含义、条件或例外，就要恢复。拿不准时保留。

Step 6. textlint を再実行し、before→after を検算する

リライト後の本文を再び Step 2 の手順で textlint にかけ、§7 のスコア(after) を出す。

• after < before になっていなければ直し残しがある。指摘の残った箇所に戻る。
• A（二重否定）は原則 0 件にする。意図的な litotes だけ例外として残す（§5 参照）。
• 対象が Markdown 文書の場合は markdownlint も再実行する。判定基準は 「after の違反が、before に存在しない新規違反を含まないこと」。 新規違反は書き換えで構文を壊した箇所なので、修正して再検証する。 before から存在していた違反はここでは直さない（§5「明晰化以外は触らない」原則に従う）。

Step 7. やりすぎチェック（ガードレール照合）

§5 のガードレールに 1 つずつ照らし、過剰な書き換え・声の注入・トーン破壊がないか点検する。 特に「元から読みやすい文を均質に作り替えていないか」「F で太字＋コロンの定型に寄っていないか」 「G で実質を持つ語まで機械的に削っていないか」「H で情報を持つ文を反復と誤認して消していないか」。

Step 8. 本文だけ返す

§2 の方針どおり、標準ではリライト後の本文のみを出力する。 markdownlint が before から検出していた既存違反があるときだけ、本文のあとに 「markdown lint 上の既存指摘」として ruleId と行番号を簡潔に添える（修正はしない）。 カテゴリ I（文字化け）の指摘があるときは、本文のあとに行番号つきで報告し、対応の要否をユーザーに確認する。 制御文字や特殊文字が意図的なケースがあるため、勝手に削除・置換しない。 U+FFFD（�）は元の文字が失われた痕跡なので、推測で復元せず正しい原文の提供を求める。

5. ガードレール（やってはいけないこと）

• 意味・事実・主張・結論を変えない。 言い換えても結論の向き・強さを保つ。
• 新しい情報・根拠・例を足さない。 原文にない事実を補完しない。
• 声・立場・個性を足さない。 一般論を「自分は」という意見に書き換えない／立場を言い切らせない／ 語り口を強めない。ja-no-weak-phrase の指摘は「曖昧で意味が取りにくいときだけ外す」用途に限り、 立場を強める方向には使わない。（これが声を注入する stop-ai-slop-jp 系との決定的な差分。）
• 技術的精度を落とさない。 易しくすると意味が変わる箇所は、語の置換ではなく文の分割で対処する。 専門用語・API 名・関数名・数値・固有名詞・引用・コードは原文のまま。
• 意図的なニュアンス（litotes）は尊重する。 控えめな肯定の含意が本質的な箇所は、安全に畳めなければ触らない。
• 元から読みやすい文は触らない。 すべてを均質に整えると無機質な「エディタ感」が出る。
• トーンを保つ。 常体／敬体、ブログ／技術文の質感を維持する。文体を勝手に統一しない。
• 接続詞は「重複して機械的に見えるもの」だけ削る。 論理に必要な接続詞は残す。 リズムを作る接続表現（「しかし一方で」など）は冗長と見なさない。
• 定型句（G）は「空虚なもの」だけ削る。 文脈で実質を持つ語（実際に複数の観点を挙げた直後の 「多角的」、実質のある要約を導く「要するに」など）は残す。prh の指摘は起点であって命令ではない。 no-ai-hype-expressions（誇張語）の指摘も同じ扱いとする。実測や比較が本文にあり語が実質を 持つ場合（実測値を伴う「大幅に」など）は残す。
• 段落の反復（H）は「情報量が増えない繰り返し」だけ削る。 主張・例・根拠・例外は ひとつも消さない。段落分割で文の順序・論理の流れは変えない。
• 文字化け（カテゴリ I）を推測で直さない。 NFD 分離・制御文字・ゼロ幅スペース・半角カナは 意図的な場合があり、U+FFFD は元の文字の情報が失われている。検出したら報告し、対応はユーザーの判断に委ねる。 半角カナだけは全角化という機械的な修正候補があるが、それもユーザーの確認を経てから行う。

6. 最終判断基準

内容を知らない読者が、一度読んで正しく理解できるか。

通読して一度で意味の取れない文が残っていれば、A→F のどれかが残っている。 逆に、読んで引っかからない文はいじらない。

7. 読解負荷スコア（RLS）の定義

textlint の指摘件数をカテゴリ別に重みづけし、本文の文数で正規化する。低いほど読みやすい。

RLS = Σ(カテゴリ件数 × 重み) ÷ 本文の文数 × 100

meiseki カテゴリ	textlint ルール	重み
A 否定の入れ子（最優先）	no-double-negative-ja	3
B 距離・長さ	sentence-length, max-ten, no-doubled-conjunctive-particle-ga	2
C 漢語・名詞化	max-kanji-continuous-len, ja-no-redundant-expression	2
D 冗長・空虚	ja-no-redundant-expression, no-doubled-conjunction, ja-no-weak-phrase, ai-writing/ai-tech-writing-guideline	1
E 体裁	ai-writing/no-ai-list-formatting, ai-writing/no-ai-emphasis-patterns（＋LLM 判断）	1
F 構造化（列挙）	（LLM 判断）	1
G 定型句	prh（同梱辞書 prh-llm-phrases.yml）, ai-writing/no-ai-hype-expressions	1
H 段落冗長	（LLM 判断）	1

• C と D は ja-no-redundant-expression を共有する。二重計上を避けるため、当該指摘は D に寄せて 1 回だけ数える （max-kanji-continuous-len は C 固有として数える）。
• G は ruleId が prh の指摘を数える。「〜の観点から」系（D2 と同根）と接続詞連打 （no-doubled-conjunction）は D に寄せ、G と二重計上しない。
• ai-writing/* の指摘は次のとおり数える（二重計上の防止）:
  • 同一箇所（行と列が一致）を prh と no-ai-hype-expressions が両方拾ったら G に 1 回だけ。
  • 同一箇所を ja-no-redundant-expression と ai-tech-writing-guideline が両方拾ったら D に 1 回だけ。
  • ai-tech-writing-guideline の総括行（「【テクニカルライティング品質分析】…」で始まるメッセージ）は 個別指摘の集計であり、件数に数えない。
• カテゴリ I（文字化け）は RLS に数えない：no-nfd・no-invalid-control-character・ no-zero-width-spaces・no-hankaku-kana、および prh のメッセージに「I 文字化け」を含む指摘（U+FFFD）。 読解負荷ではなくデータ破損の検出であり、扱いは §4 Step 8 に従う（報告のみ・ユーザー確認）。
• 受け入れ基準：after < before を必須、かつ A（二重否定）は原則 0 件。
• 重み（特に A=3 の比率）・一文長(90字)・F の扱いは、実ドキュメントで較正して調整してよい。

8. textlint が拾える / 拾えないもの

• textlint で決定論的に取れる：A 二重否定、B 一文長・読点・逆接「が」連続、C 連続漢字・「することができる」、 D 冗長・接続詞重複・弱い表現、E 絵文字箇条書き・リスト内の過剰太字（ai-writing/no-ai-list-formatting, ai-writing/no-ai-emphasis-patterns）、G 辞書収録の定型句（prh。「〜に他ならない」「重要なのは」 「掘り下げる」等）と誇張語（ai-writing/no-ai-hype-expressions。「革命的」「ゲームチェンジャー」等）。
  • A の注意：no-double-negative-ja は分離型（「〜ないとは言えない」「〜は否定できない」「〜なくはない」 「〜ないわけがない」）と丁寧形（「〜ないわけではありません」等）を拾わない。これらは同梱 prh 辞書の 「A1 補完」セクションが検出する（ruleId は prh になるが、リライトは A の基準＝真偽を反転させずに 肯定へ畳む＝で行う）。
• textlint では取れない（LLM が担う）：B 長い連体修飾、C「の」連鎖の深さ・一般の名詞化、 E 散文に戻すかの判断・見出しの過剰構造化・英語的コロン接続（no-ai-colon-continuation は [email protected] に未収録）、F 列挙の箇条書き化、G 辞書外の定型句と「削るか残すか」の文脈判断、 H 段落レベルの言い換え反復・再要約。

この「取れない部分」が meiseki の独自価値。textlint 設定だけで終わらせない。