企业官网建设流程全解析

本篇以 yomiyasu 仓库评测语料库中的一份真实样例——数据库定期维护通知的改写前后文本（tests/corpus/yomiyasu_rewritten/04_slack_announce_sonnet_default.md）——为主轴，逐段拆解该 Agent Skill 如何把 LLM 生成的日语"通知文体"改写为自然、可读、立场清晰的日语。读完本文，你将掌握 yomiyasu 对"お知らせ（決まり）"类文档的核心改写手法：主述明确化、段落重组、装飾記号排除、文末与立场统一，并学会用仓库自带的 yomiyasu_lint.py 与 yomiyasu_diff.py 验证改写结果。

一、这份文档在语料库中的定位

仓库的tests/corpus/下按五类分组保存了同一批写作场景的多个变体，文件名规则为序号_场景_模型_语气：

04_slack_announce_sonnet_default.md属于"04 号场景：Slack 频道维护通知"，由 Claude Sonnet 以 default（默认）语气生成。关联文档是其中的yomiyasu_rewritten 版本，即 yomiyasu 的最终输出；同场景还保留了 raw_ai 原文、blacklist_ai 变体 以及带_bl后缀的改写变体，便于三方对照。全部评测汇总记录在 tests/corpus/benchmark_results.json 中。

二、改写后的完整文本（关联文档全文）

关联文档的正文如下，这是一份典型的"決まり／お知らせ"立场文档——由基础设施团队向频道读者发布维护安排与行动请求：

【重要】データベース定期メンテナンスに伴うサービス一時停止のお知らせ インフラチームは今週末にデータベースの定期メンテナンスを実施し、作業中は本番サービスを一時停止します。業務に影響がある方はご確認ください。 日時は10月4日（日）02:00から06:00までの予定です。作業が早く終われば、停止時間は短くなります。 対象は本番環境の全サービスで、管理画面とAPIも含みます。停止中はログインとデータの参照、更新ができません。ステージング環境は通常どおり使えます。 作業内容は、ストレージの最適化、インデックスの再構築、マイナーバージョンの適用です。データを削除したり移行したりする作業はありません。 次の3点をお願いします。停止時間帯に予定しているバッチ処理やデプロイは、前後の日程へ移してください。お客様への案内が必要な場合は、カスタマーサポートチームへ事前に共有してください。未保存のデータが残らないよう、10月3日（土）中に入力内容を保存してください。 インフラチームは、作業の開始時と完了時にこのチャンネルへ投稿します。復旧後に不具合を見つけた場合は、このスレッドに返信するか、#infra-supportへ連絡してください。作業が想定より長引く場合も、このチャンネルで随時お知らせします。 ご不便をおかけしますが、ご協力をお願いします。 インフラチーム

这份文本在信息上与 AI 原文完全同构：维护主体（インフラチーム）、时间（10月4日02:00〜06:00）、对象范围（本番全服务）、作业内容（存储优化/索引重建/小版本）、三点请求、通知渠道与联系方式、署名。没有任何新增事实，也没有删减必要信息——这正是 yomiyasu 的"情報の不増補"原则（见 SKILL.md 第 1 节）。

三、逐段对比：从 AI 原文到改写后

将关联文档与其 AI 原文（tests/corpus/raw_ai/04_slack_announce_sonnet_default.md）逐段对照，可以看到改写并非"换词"，而是发生在主述结构、段落组织与文末立场层面。

3.1 开头：补主语、理顺因果

AI 原文：

今週末にデータベースの定期メンテナンスを実施します。作業中は本番サービスを一時停止するため、業務への影響がある方はご確認ください。

yomiyasu 改写：

インフラチームは今週末にデータベースの定期メンテナンスを実施し、作業中は本番サービスを一時停止します。業務に影響がある方はご確認ください。

这里做了两处关键调整：

1. 补主语：句首补上「インフラチームは」。AI 原文通篇省略动作主体，日语虽常省主语，但在公告类文书中"谁执行维护"是核心信息。SKILL.md「主語と目的語の明確化」一节规定：从原文与上下文能确定的主体，应在必要位置明示。通知末尾的署名「インフラチーム」为补足提供了原文依据，不属于凭空创作。
2. 因果句改为并列顺接：原文「実施します。…一時停止するため、…ご確認ください」用「ため」把"结果"与"请求"硬绑在一起，读来有把读者行动归因于维护动作的拧巴感。改写为「実施し、…一時停止します」——先述事实（决まり/予定），再独立提出「業務に影響がある方はご確認ください」的请求，两句各司其职。这符合 SKILL.md「文の働き（説明・依頼・予定）を区別し、働きに合わない文末だけを直す」的规则。

3.2 时间表达：去装饰、统一格式

AI 原文：日時は10月4日(日)【02:00〜06:00】の予定です。

改写后：日時は10月4日（日）02:00から06:00までの予定です。

三处细节对应 SKILL.md「装飾記号の排除と太字の表示」与「文長と読点の調整」：

• 半角括号(日)统一为全角（日），消除混排；
• 删除【02:00〜06:00】这类装饰性方括号——它不承载额外信息，属于 LLM 常见的强调式排版；
• 〜改为02:00から06:00まで的自然叙述，让"起止时间"以普通人写公告的方式表达，而不是保留表格符号残留。

3.3 请求部分：消解"予告句"、箇条書き转地の文

AI 原文：

お願いしたいことは3点あります。 ・停止時間帯に予定しているバッチ処理やデプロイは、前後の日程へ移してください。 ・お客様への案内が必要な場合は、カスタマーサポートチームへ事前に共有してください。 ・作業前に未保存のデータが残らないよう、10月3日(土)中に入力内容の保存を済ませてください。

改写后：

次の3点をお願いします。停止時間帯に予定しているバッチ処理やデプロイは、前後の日程へ移してください。お客様への案内が必要な場合は、カスタマーサポートチームへ事前に共有してください。未保存のデータが残らないよう、10月3日（土）中に入力内容を保存してください。

这是全文改写力度最大的一处，同时体现了三条规则：

1. 「予告だけの文」的消解：「お願いしたいことは3点あります」是一句不携带内容的空壳预告（SKILL.md「段落と文の論理構造」第 2 条明确要求处理这类句子）。改写为「次の3点をお願いします」——预告与请求合并为一句，而"3点"的权重（数量提示）保留在述语「お願いします」中，读者依然知道接下来是三件事。
2. 箇条書き → 地の文：三个・项目被转为连续的三句地の文。SKILL.md 规定，只有"並列関係が明確で読みやすい箇条書き"才保留；这里三项请求逻辑并列，但总量仅三句，转成地の文后以「〜してください」统一收束，不破坏并列关系，同时消除了 LLM 高频的"列表化"痕迹。三条请求的语气（依頼）原样保留，没有把「してください」换成别的语气——这正是「言い切りの強さ」保持的体现。
3. 动词直接化：「入力内容の保存を済ませてください」→「入力内容を保存してください」。SKILL.md「主語と目的語の明確化」指出，动作名词化加「〜を行う」式表达不如「对象+动词」直接自然；这里同理，「保存を済ませる」回退为动词「保存する」，动作与对象直接相接。同时「作業前に」被删除——这个时间限定已由前段"停止時間帯"的语境涵盖，属于冗余修饰的清理，而非信息削减。

3.4 后半段：条件句补主语、空白整理

AI 原文：

作業の開始時と完了時は、このチャンネルに投稿します。復旧後に不具合を見つけた場合は、このスレッドに返信するか、#infra-support へ連絡してください。想定より長引く場合も、このチャンネルで随時お知らせします。

改写后：

インフラチームは、作業の開始時と完了時にこのチャンネルへ投稿します。復旧後に不具合を見つけた場合は、このスレッドに返信するか、#infra-supportへ連絡してください。作業が想定より長引く場合も、このチャンネルで随時お知らせします。

• 首句补主语「インフラチームは」：通知中"谁在开始/完成时投稿"由签名可确定，补上后动作主体清晰；「に投稿します」→「へ投稿します」的助词微调让"去向"更明确。
• 「想定より長引く場合も」补上「作業が」：让条件的主语显式化，读者不必回读上一句才能推断"什么会变长"。这对应 SKILL.md「修飾・条件・並列の関係」——条件句的挂靠对象必须能一眼追踪。
• #infra-support へ去掉半角空格：SKILL.md 规定"英单词或数值前后的空白，仅在元格式/指定风格要求时保留"，此处空格的删除不是机械规则，而是因为#infra-support是频道标识符，与后文的「へ」之间无需空格。

3.5 一处容易被忽略的严谨化

AI 原文：停止中はログインやデータの参照、更新ができません。

改写后：停止中はログインとデータの参照、更新ができません。

助词や（列举中的一部分）改为と（全部列举）。原文用「や」会让人以为"登录和数据操作只是不可用功能中的一部分"，而实际公告要表达的是"登录、数据参照、更新全部不可用"。改成「と」后，列举范围精确闭合，避免读者误读存在其他可用操作——这是 SKILL.md「操作と結果の対応」的典型应用：哪些操作在什么条件下不可用，必须能让读者区分清楚。

同样严谨化的还有作业内容说明：原文「データの削除や移行はありません」有歧义（是"没有数据"还是"没有删除/迁移操作"？），改写为「データを削除したり移行したりする作業はありません」，用动词明确"不存在的是哪种作业"，消除了名词化造成的指代模糊。

四、改写背后的规则体系：这份样例对应了 SKILL.md 的哪些条款

关联文档不是孤立的"范文"，而是 SKILL.md 规则的执行产物。它涉及的条款可以归纳为四组：

1. 意味の保持（最优先规则）：改写前后，主张（何时停、停什么、做什么、读者要做什么）、比重（三点请求的并列关系）、言い切りの強さ（「予定です」「できます」「してください」的强弱均未改变）、文の働き（事实说明用「〜します」，请求用「〜してください」）全部保持一致。SKILL.md 明确"其他原则只在不动这四点的范围内适用"。
2. 文書の立場と文末：本文属于"決まり"立场（向读者传达规则/安排的公告，动作主体是遵循指示的读者与制定方略的写手）。改写遵循该节要点：書き手側的予定与实动作（「インフラチームは…投稿します」）保留「〜します」；对读者的请求保持「〜してください」，没有把请求弱化为「〜しましょう」或强化为义务表达。
3. 段落と文の論理構造：原文的三条请求以箇条書き承载，改写后转为地の文并在开头用「次の3点をお願いします」承接——既消除了无内容的预告句，也保持了"3点"的数量提示；同时「作業前に」这类可由语境推断的冗余被清理。
4. 装飾記号の排除：【02:00〜06:00】的装饰方括号与〜范围记号被替换为自然叙述；半角括号统一为全角；#infra-support前后的多余空格被整理。

若要进一步阅读，仓库还提供了更细的规则语料：references/slop-catalog.md（AI 特有语汇/构式目录）、references/domains/business.md（业务文书的领域特化规则）以及 references/gemini-syntax.md（构文转换原则）。

五、用仓库自带工具验证改写结果

SKILL.md 的 Step 3 / Step 4 规定，改写后应运行两个静态检查工具（均为 Python 标准库实现，无需第三方依赖）：

5.1 yomiyasu_lint.py：AI 臭与格式静态检查

python3 scripts/yomiyasu_lint.py tests/corpus/yomiyasu_rewritten/04_slack_announce_sonnet_default.md

该脚本（源码见 scripts/yomiyasu_lint.py）从 markdown_visibility.py 解析 Markdown 结构后，检查：AI 特有的比喩動詞、过度的太字/箇条書き、絵文字、文末コロン、同一文末连发，以及bold_not_rendered（按 GFM 与 CommonMark 规则模拟 ** 是否能正确渲染为太字）。输出如：

============================================================ AIっぽさ 検査レポート (スコア: 100/100) ============================================================ ・文字数: 574 | 行数: 9 ・太字頻度: 1,000字あたり 0.0 個 (推奨: 2.0以下 / 警告: 3.0超) ・箇条書き比率: 0.0% (推奨: 15%以下 / 警告: 25%超) ------------------------------------------------------------ [PASS] 設定された検査ルールによる指摘はありません。

支持--strict（有警告则退出码 1，可接入 CI/预提交钩子）与--json两种模式。

5.2 yomiyasu_diff.py：改写前后的语义差分检查

python3 scripts/yomiyasu_diff.py \ tests/corpus/raw_ai/04_slack_announce_sonnet_default.md \ tests/corpus/yomiyasu_rewritten/04_slack_announce_sonnet_default.md \ --stance=決まり

脚本实现见 scripts/yomiyasu_diff.py，它把改写前后的文本做六类对比：言い回し种类的增减（依頼/勧誘/義務/評価/可能等，通过MARKERS正则表统计）、新增/消失的词汇、箇条書き→地の文等结构变化、文头接续词与"予告だけの文"、文末种类与文档立场的一致性（按勧め/決まり/説明三种立场分别设旗标）、太字渲染问题。--stance=決まり时，脚本会专门检查：决まり类文档中是否混入了勧め（〜ましょう）或評価（〜が重要です）文末。

对该样例，原文与改写后均为敬体统一、无勧誘/評価混入，脚本给出的检查点主要落在"请求句均为依頼「〜してください」、实动作说明均为「〜します」"这一正当分布上。需要强调的是，diff 脚本输出的是复核候选而非裁决——它提示"哪些地方需要人确认"，不能自动判定语义等价；最终判断仍须回到 SKILL.md Step 4 的人工通读。

六、评测数据：静态满分不等于无需改写

查看 tests/corpus/benchmark_results.json 中该场景的评测记录，会发现一个值得注意的事实：

也就是说，这份 AI 原文在静态 lint 指标上已经是 100 分——它没有比喩動詞、没有过度的太字/箇条書き、没有絵文字。而 yomiyasu 依然对其进行了全面改写。这恰恰印证了项目设计文档 README.md 与 evals/comparison_benchmark.md 反复强调的立场：

静的検査で指摘がないことも、意味の保持・読みやすさの確認は区別してください。（静态检查无指摘，不等于已确认意义保持与可读性。）

AI 臭不止于"禁止词命中"。这份样例的 AI 痕迹藏在主述省略、空壳预告句、装饰方括号、名词化动作、条件句主语缺省这些语义与结构层面，而 lint 脚本只能捕捉表层的正则命中。这也是 yomiyasu 与"禁止语替换"路线的根本区别——后者（对应语料库blacklist_ai目录）只做表层替换，无法处理这类结构性不自然。

七、如何在仓库中复现与本场景联动

• 通读规则：从 SKILL.md 开始（唯一规则入口），配合 references/domains/business.md 的業務文書领域规则，即可复现本文档的改写判断依据。
• 复现改写：把 tests/corpus/raw_ai/04_slack_announce_sonnet_default.md 的文本交给已安装 yomiyasu 的编码 Agent（安装方式见 README.md 的npx skills add nanaism/yomiyasu），并在提示中注明"社内 Slack へのお知らせとして読みやすくして"即可。
• 验证输出：依次运行上文yomiyasu_lint.py与yomiyasu_diff.py --stance=決まり，再对照关联文档的人工终稿，观察改写思路的异同。
• 参考同类：同目录下04_slack_announce_sonnet_casual.md、04_slack_announce_sonnet_formal.md及其_bl变体展示了同一场景在不同语气下的改写差异，可作为批量比对素材。

结语

一份 15 行的 Slack 维护通知，在 yomiyasu 的改写中经历了主语补全、空壳预告句消解、箇条書き转地の文、装饰符号清除、助词精确化、条件句主语显式化六类手术，而信息量与请求强度分毫未动。这份样例的价值在于它示范了 yomiyasu 最核心的方法论：AI 生成日语的"不自然"主要不在词汇而在结构，改写的边界由"意味の保持"与"情報の不増補"两条铁律划定，一切技巧都在此范围内生效。配合 yomiyasu_lint.py 与 yomiyasu_diff.py 的静态验证，这份工作流可以完整复制到任何"社内公告/维护通知"类日语文书的推敲中。