尧图网页设计 
如何接入 CI 自动拦截 AI 味yomiyasu --strict 模式 3 步配置指南【免费下载链接】yomiyasuAI生成の日本語を自然な日本語へ推敲するAgent Skill / Agent Skill for Refining AI-Generated Japanese into Natural Japanese项目地址: https://gitcode.com/gh_mirrors/yo/yomiyasuyomiyasu 是一个把 AI 生成的日语改写为自然日语的 Agent Skill随项目内置了静态检查脚本 yomiyasu_lint.py。加上--strict参数后只要文章里出现一处AI 味比如静かに壊れる这类比喻动词、表情符号、文末冒号、过密加粗脚本就会返回退出码 1让 CI 流水线直接红灯、阻止合并——相当于给文档质量装了一道自动拦截的闸门。本文面向新手不要求你了解正则表达式只需 3 步就能把AI 味检查挂进 CI读懂检查规则 → 本地跑一次 strict → 接入 CI。全程只需要 Python 3没有任何第三方依赖。为什么要在 CI 里拦截AI 味如今 PR 描述、故障报告、技术文档的下草稿几乎都交给 AI但生成出来的日语往往带着明显的机器痕迹比喻动词データが静かに壊れる時間[をに]溶かす装饰性符号表情符号、句末挂冒号格式膨胀每句话都加粗、列表占比超过 25%节奏重复连续 3 句以上用同一个句尾比如连用です靠人眼审查这些细节很容易漏掉靠 AI 自查又存在给自己打分偏高的倾向。yomiyasu 的思路是让一台确定性的打分机站在 CI 门口不合格就不放行。--strict模式就是这道闸门的开关有警告 → 退出码 1 → CI 失败 → PR 无法合并。快速上手yomiyasu_lint.py 与 --strict 模式检查脚本位于仓库的 scripts/yomiyasu_lint.py只使用 Python 标准库安装 Python 3 即可运行。两种用法# 普通模式输出报告退出码始终为 0 python3 scripts/yomiyasu_lint.py docs/guide.md # strict 模式只要出现 warn/error 级别发现退出码就是 1CI / Git 钩子专用 python3 scripts/yomiyasu_lint.py docs/guide.md --strict退出码速查表退出码含义CI 中的效果0无 warn/error 级别发现✅ 绿灯允许合并1发现至少 1 条警告或错误 红灯拦截合并2文件打不开等运行错误 红灯脚本自身问题另外还有一个--json参数可以把报告输出为 JSON方便在 CI 日志里做进一步解析或归档。strict 模式实际输出长什么样用仓库自带的 AI 原始语料 tests/corpus/raw_ai/01_tech_arch_sonnet_default.md 试跑报告会形如下面这样节选 AIっぽさ 検査レポート (スコア: 85/100) ・文字数: 1420 | 行数: 85 ・太字頻度: 1,000字あたり 3.2 個 (推奨: 2.0以下 / 警告: 3.0超) ・箇条書き比率: 28.4% (推奨: 15%以下 / 警告: 25%超) ------------------------------------------------------------ [NOTICE] 3 件の改善推奨箇所が見つかりました。 L12 [WARN] 比喩動詞「壊れる」が検出されました。... L18 [WARN] 絵文字が検出されました。...末尾的[PASS]才是绿灯。评分采用 100 分起扣分制warn/error 每条 -5 分info 每条 -2 分分数只是参考真正决定 CI 成败的是 warn/error 条数——这正是 strict 模式卡口的实现方式scripts/yomiyasu_lint.py。哪些检查会被 strict 卡住规则级别说明slop_vocabularywarn手触り解像度正本等 AI 高频词词表见 references/slop-catalog.mdmetaphor_verbwarn壊れる溶かす潰す等比喻动词emoji_prohibitedwarn任意表情符号trailing_colonwarn行尾冒号或 :excess_bold/excess_listwarn加粗超 3 处/千字符或列表行占比超 25%sentence_end_repetitionwarn同一句尾连续 3 句以上unnatural_halfwidth_spacewarn日文中夹杂英文单词时的多余半角空格bold_not_renderederror加粗写法在 GitHub 上会渲染失败的情况negative_parallelisminfoAではなくB句式——只提示不拦截一个对新手很友好的设计info级别的提示不会让 strict 失败。也就是说AではなくB这种承担语义的否定句式只会被标注、不会被强制改写CI 不会过于严苛。第 3 步把 --strict 挂进 CI 流水线以下用 GitHub Actions 的 workflow 文件为例核心思路只有两行检出代码 → 跑--strict。# .github/workflows/doc-lint.yml name: doc-lint on: pull_request: paths: - docs/** jobs: yomiyasu-lint: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Check AI-slop (strict) run: | python3 scripts/yomiyasu_lint.py docs/api-guide.md --strict配置要点只触发文档变更paths: [docs/**]让代码 PR 不跑检查省时且减少噪音多文件批量检查把单文件换成find docs -name *.md -exec python3 scripts/yomiyasu_lint.py {} --strict \;任一文件失败整体红灯只查本次改动进阶先git diff --name-only origin/main...HEAD -- *.md拿到变更文件清单再逐个检查避免历史遗留问题挡住新 PR不想等 CI 跑完才发现问题的话同一命令还能配进 Git 的 pre-commit 钩子本地提交时先过一遍CI 只是第二道保险python3 $(git rev-parse --show-toplevel)/scripts/yomiyasu_lint.py 变更的文档.md --strict完整的 workflow 模板、钩子写法与批量检查技巧可以结合 README.md 的付属ツール一节参考。新手避坑清单警告是复审线索不是死刑判决。脚本自己也声明词表命中可能是正当的专业用法比如物理意义上的壊れる。先看报告里的行号L12、L18确认是真 AI 味再改别为了消警告而把技术含义写歪。改文比改规则优先。想长期豁免某个词可以 fork 后在 scripts/yomiyasu_lint.py 的SLOP_WORDS词表第 34~45 行里调整但先把警告逐条看完通常改写文章本身就够用了。--strict和 Git 钩子是原生支持的组合。README 中对该参数的官方说明就是警告があれば終了コード1を返す厳格モードCIやGitフック用README.md 第 213 行附近可以放心用于生产流程。想留档检查报告加--json输出 JSON配合tee写入 CI artifact方便团队回溯每次评分。AI 改写 lint 校验是闭环先用 yomiyasu 技能把初稿改写为自然日语技能本体见 SKILL.md再用--strict做机器复核比单靠任何一边都可靠。仓库里 tests/corpus/yomiyasu_rewritten/ 下就有改写前后对照语料可以用来体会AI 味具体差在哪。小结步骤命令/动作作用1. 本地试跑python3 scripts/yomiyasu_lint.py docs/guide.md看报告、熟悉规则2. 加严格开关追加--strict有警告即退出码 13. 挂进 CIworkflow 中执行上一步命令PR 红灯拦截 AI 味整套机制不依赖任何第三方库、不需要额外服务一条命令就能从人工盯稿升级为机器拦截。把--strict挂上之后团队里任何一篇带着 AI 味混进主干的文档都会在合并之前被挡下来。【免费下载链接】yomiyasuAI生成の日本語を自然な日本語へ推敲するAgent Skill / Agent Skill for Refining AI-Generated Japanese into Natural Japanese项目地址: https://gitcode.com/gh_mirrors/yo/yomiyasu创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何接入 CI 自动拦截 AI 味：yomiyasu --strict 模式 3 步配置指南
如何接入 CI 自动拦截 AI 味yomiyasu --strict 模式 3 步配置指南【免费下载链接】yomiyasuAI生成の日本語を自然な日本語へ推敲するAgent Skill / Agent Skill for Refining AI-Generated Japanese into Natural Japanese项目地址: https://gitcode.com/gh_mirrors/yo/yomiyasuyomiyasu 是一个把 AI 生成的日语改写为自然日语的 Agent Skill随项目内置了静态检查脚本 yomiyasu_lint.py。加上--strict参数后只要文章里出现一处AI 味比如静かに壊れる这类比喻动词、表情符号、文末冒号、过密加粗脚本就会返回退出码 1让 CI 流水线直接红灯、阻止合并——相当于给文档质量装了一道自动拦截的闸门。本文面向新手不要求你了解正则表达式只需 3 步就能把AI 味检查挂进 CI读懂检查规则 → 本地跑一次 strict → 接入 CI。全程只需要 Python 3没有任何第三方依赖。为什么要在 CI 里拦截AI 味如今 PR 描述、故障报告、技术文档的下草稿几乎都交给 AI但生成出来的日语往往带着明显的机器痕迹比喻动词データが静かに壊れる時間[をに]溶かす装饰性符号表情符号、句末挂冒号格式膨胀每句话都加粗、列表占比超过 25%节奏重复连续 3 句以上用同一个句尾比如连用です靠人眼审查这些细节很容易漏掉靠 AI 自查又存在给自己打分偏高的倾向。yomiyasu 的思路是让一台确定性的打分机站在 CI 门口不合格就不放行。--strict模式就是这道闸门的开关有警告 → 退出码 1 → CI 失败 → PR 无法合并。快速上手yomiyasu_lint.py 与 --strict 模式检查脚本位于仓库的 scripts/yomiyasu_lint.py只使用 Python 标准库安装 Python 3 即可运行。两种用法# 普通模式输出报告退出码始终为 0 python3 scripts/yomiyasu_lint.py docs/guide.md # strict 模式只要出现 warn/error 级别发现退出码就是 1CI / Git 钩子专用 python3 scripts/yomiyasu_lint.py docs/guide.md --strict退出码速查表退出码含义CI 中的效果0无 warn/error 级别发现✅ 绿灯允许合并1发现至少 1 条警告或错误 红灯拦截合并2文件打不开等运行错误 红灯脚本自身问题另外还有一个--json参数可以把报告输出为 JSON方便在 CI 日志里做进一步解析或归档。strict 模式实际输出长什么样用仓库自带的 AI 原始语料 tests/corpus/raw_ai/01_tech_arch_sonnet_default.md 试跑报告会形如下面这样节选 AIっぽさ 検査レポート (スコア: 85/100) ・文字数: 1420 | 行数: 85 ・太字頻度: 1,000字あたり 3.2 個 (推奨: 2.0以下 / 警告: 3.0超) ・箇条書き比率: 28.4% (推奨: 15%以下 / 警告: 25%超) ------------------------------------------------------------ [NOTICE] 3 件の改善推奨箇所が見つかりました。 L12 [WARN] 比喩動詞「壊れる」が検出されました。... L18 [WARN] 絵文字が検出されました。...末尾的[PASS]才是绿灯。评分采用 100 分起扣分制warn/error 每条 -5 分info 每条 -2 分分数只是参考真正决定 CI 成败的是 warn/error 条数——这正是 strict 模式卡口的实现方式scripts/yomiyasu_lint.py。哪些检查会被 strict 卡住规则级别说明slop_vocabularywarn手触り解像度正本等 AI 高频词词表见 references/slop-catalog.mdmetaphor_verbwarn壊れる溶かす潰す等比喻动词emoji_prohibitedwarn任意表情符号trailing_colonwarn行尾冒号或 :excess_bold/excess_listwarn加粗超 3 处/千字符或列表行占比超 25%sentence_end_repetitionwarn同一句尾连续 3 句以上unnatural_halfwidth_spacewarn日文中夹杂英文单词时的多余半角空格bold_not_renderederror加粗写法在 GitHub 上会渲染失败的情况negative_parallelisminfoAではなくB句式——只提示不拦截一个对新手很友好的设计info级别的提示不会让 strict 失败。也就是说AではなくB这种承担语义的否定句式只会被标注、不会被强制改写CI 不会过于严苛。第 3 步把 --strict 挂进 CI 流水线以下用 GitHub Actions 的 workflow 文件为例核心思路只有两行检出代码 → 跑--strict。# .github/workflows/doc-lint.yml name: doc-lint on: pull_request: paths: - docs/** jobs: yomiyasu-lint: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Check AI-slop (strict) run: | python3 scripts/yomiyasu_lint.py docs/api-guide.md --strict配置要点只触发文档变更paths: [docs/**]让代码 PR 不跑检查省时且减少噪音多文件批量检查把单文件换成find docs -name *.md -exec python3 scripts/yomiyasu_lint.py {} --strict \;任一文件失败整体红灯只查本次改动进阶先git diff --name-only origin/main...HEAD -- *.md拿到变更文件清单再逐个检查避免历史遗留问题挡住新 PR不想等 CI 跑完才发现问题的话同一命令还能配进 Git 的 pre-commit 钩子本地提交时先过一遍CI 只是第二道保险python3 $(git rev-parse --show-toplevel)/scripts/yomiyasu_lint.py 变更的文档.md --strict完整的 workflow 模板、钩子写法与批量检查技巧可以结合 README.md 的付属ツール一节参考。新手避坑清单警告是复审线索不是死刑判决。脚本自己也声明词表命中可能是正当的专业用法比如物理意义上的壊れる。先看报告里的行号L12、L18确认是真 AI 味再改别为了消警告而把技术含义写歪。改文比改规则优先。想长期豁免某个词可以 fork 后在 scripts/yomiyasu_lint.py 的SLOP_WORDS词表第 34~45 行里调整但先把警告逐条看完通常改写文章本身就够用了。--strict和 Git 钩子是原生支持的组合。README 中对该参数的官方说明就是警告があれば終了コード1を返す厳格モードCIやGitフック用README.md 第 213 行附近可以放心用于生产流程。想留档检查报告加--json输出 JSON配合tee写入 CI artifact方便团队回溯每次评分。AI 改写 lint 校验是闭环先用 yomiyasu 技能把初稿改写为自然日语技能本体见 SKILL.md再用--strict做机器复核比单靠任何一边都可靠。仓库里 tests/corpus/yomiyasu_rewritten/ 下就有改写前后对照语料可以用来体会AI 味具体差在哪。小结步骤命令/动作作用1. 本地试跑python3 scripts/yomiyasu_lint.py docs/guide.md看报告、熟悉规则2. 加严格开关追加--strict有警告即退出码 13. 挂进 CIworkflow 中执行上一步命令PR 红灯拦截 AI 味整套机制不依赖任何第三方库、不需要额外服务一条命令就能从人工盯稿升级为机器拦截。把--strict挂上之后团队里任何一篇带着 AI 味混进主干的文档都会在合并之前被挡下来。【免费下载链接】yomiyasuAI生成の日本語を自然な日本語へ推敲するAgent Skill / Agent Skill for Refining AI-Generated Japanese into Natural Japanese项目地址: https://gitcode.com/gh_mirrors/yo/yomiyasu创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考