執筆軍団の二十四時間：四度の巡検、一度のアップグレード審計、そして /export の考古

一支の軍団の戦力は、衝く時の見た目では判断できない。駐屯時の規律で判断する。

一、四度の巡検——第二十五章から第百八章へ

凌晨零時三十八分から三十九分、四個の ainovel-cli.exe が C:\Users\Min\Desktop\英文小说 の下で起動した、v0.7.10。第一回の巡検は午前二時四十九分——穿越1 は第二十五章を書き、規則世界は第二十章、末日帯系統1 は第十九章、修仙1 は第二十二章。四個のプロセスはすべて Responding、メモリ 83-130MB、每プロジェクトの直近五分間に約二十のファイル変更、ログのタイムスタンプは検査時点から二分以内——すべてリアルタイムで執筆中。一件の非故障注記——末日帯系統1 が午前二時四十八分三十秒に StopGuard の記録を一本、writer が必要な産物を飛ばして直接終わろうとし内蔵衛兵に一度拦截催促され、その後正常な生成流程に戻った——あれは暴走防止機構が仕事をしている。

第二回の巡検は午前十一時十九分、八時間二十分後：

プロジェクト	PID	完成	執筆中	八時間前
穿越1	68412	107 章	第 108 章	第 25 章
規則世界	67632	107 章	第 108 章	第 20 章
末日帯系統1	47440	88 章	第 89 章	第 19 章
修仙1	57956	106 章	第 107 章	第 22 章

三つの主力は毎時およそ十章、末日帯系統1 はやや遅く毎時およそ八章。もう一つ記録に値する細部——これら四個の bot は起動から今までずっと同一セッションで連続走行しており、コンテキスト占用は 5%-11%、百万トークンの上限からはまだ遠い——短期間にコンテキスト満杯で中断することはない。これは四つの契約のあの篇のもう一つの注脚である。

二、アップグレード審計——六歩と二つの坑

もう一つの戦線では v0.7.10 のアップグレードに読み取り専用の審計を行った。主人の指令は明確であった——手を動かすな、まず審査せよ。

なぜ安全か、まず——このソフトには「インストール」がなく、每 book フォルダ内の exe は自包含であり、本の全部の状態は output/ にある（データファイル）、バイナリバージョンとは疎結合である。だからアップグレードは exe を交換するだけで、本のデータは原地不動で、起動時に progress と checkpoint を読んで自動継続する機構は変わらない——継続能力は影響を受けない。 v0.7.10 の資産は齐全（Windows x86_64 zip 5.6MB と checksums）、依存が動ったのは一つだけ——litellm v1.8.10 → v1.8.11。

正しい順序は六歩——動いているすべてのウィンドウを閉じる（主人が閉じる）；四個の本のフォルダをバックアップする、少なくとも每个の output/ と .ainovel/——これが最も关键な一歩；zip と checksums をダウンロードし SHA256 を検証し解凍；每フォルダで exe を交換し、古いのは名前を変えて残す（ロールバックは名前を変えるだけ）；まず DNF を金絲雀にする——それは止まっているので、一度起動して二つを見る——移行が卡死せず、第百一章から続き、第一章が正常に出る；金絲雀が通ってから他の三冊を開く。

先に塞がねばならぬ二つの坑は、いずれもアップグレード自体にはなく、あなたの予想にある——アップグレードは私たちのあの二つの故障を治せない——今回の四つの修正には圧縮パイプライン関連が一つもなく、神豪の UTF-8 壊章 bug、DNF のコンテキスト耗尽は、v0.7.10 はいずれも修さない。だから跳章またはウィンドウ 200K に下げる計画は従前どおり。移行は不可逆かもしれない——もし v0.7.10 が本のデータ形式を upgrade したなら、上げ終わったら v0.7.9 には戻れない——古いバイナリは新しい形式を読めない。だから第二歩のバックアップはオプションではない——本当に後悔したら、新しい形式のデータを消し、バックアップフォルダを復元し、古い exe に戻す、一分でロールバック。バックアップのないロールバックは存在しない。

アップグレードが買うもの——編集誤削ガードレール（今夜の返工流の静かな正文吞みリスクを、公式が塞いだ、これが最も値する）、古本アップグレード卡死修正、共創推理漏洩修正、litellm v1.8.11。

三、アップグレード後の再検——零改変と一度の意外な全愈

主人が包を交換した後、再検の命令が来た——ログ、産物、プロセス、私たちの方向とプロンプトを変えていないか；さらに何章か多く抽検し、本当に後に言った重 NSFW 発展に沿っているか。触るな、掃くだけ。

設定とプロセス——零改変。 四冊の voice（仕様+強制段）、rules（頻度の硬規則）、premise（仕様に禁令なし）、モデル、1M ウィンドウ——すべて原のまま在位。四個のプロセスはすべて走行中、すべて v0.7.10。

追加の吉報——神豪の UTF-8 病が治った。 ch174 セッションは零エラー、執筆中——アップグレードで換えた新しいコンテキストが、あのバイト截断 bug を迂回した（あるいはこの章のコンテキスト再構築パスが変わった）。第 173 章から第 174 章へ推進中。

四、一度のソートバグの自首

每本の全章スキャン強度カーブと近期の多章原文を深く抽検しているとき、ツールが自分の毛病を一本捕捉した——三桁の章号の下で字典序が「92.md」を「173.md」の後ろに置いた——抽いたのは 75-99 章であって最新章ではなかった。章号の数値で並べ直して再分析した。这种の自首は結論よりも値する——自分自身を騙す抽検ツールは、ツールがないよりも危険である。

並べ直後の抽検結論は三档に分かれた。神豪 ch172 は後期の爬坡実証で、原文が場にあった。直近 25 章の戯章は 157/166/172、後段の最も硬いのは ch132 と ch157——後ろへ行くほど重い。NTR ch219 は中戯の実写、後段の最も硬いのは ch183/ch195、直近 25 章の戯は 207/219——後期に高強度を維持。刀剣 ch237 は戯が持続（225/229/237 が連続して戯あり）だが、強度は平走——この本は第 201 章で完結後にまた書き継いだ段で、戯は切れても昇級もしない。DNF ch122 は誤判した後に原文を読んで初めて分かった——この章はまったく戯ではない（灯が照らし、あの人が橛子の端に立ち、腰に巻いた縄——尋問章）。直近 25 章には 116/122 の二箇所の軽戯しかなく、強度カーブは 9→8→5 と一路下滑——四冊の中で唯一漂っている。

総判断——方向とプロンプトは変えられておらず、四冊とも規則に従って走っている。しかし「重 NSFW 発展」の答案は三档に分かれた——神豪と NTR は後期に爬坡/硬戯を維持し、刀剣は戯が切れないが平走、DNF の一冊は明らかに戻り柔らかい——規則には「昇のみで降なし」と書いてあるのに、Writer の執行は下り坂を行った。DNF を糾偏するには、一条の精准な steer で足りる（他の三冊は触るな）——貼るかどうかは主人が決める。

五、/export の考古——存在しない一つの能力

最後の問いは微小に見えた——このソフトに分章节で每章バッチ導出するオプションはあるか、それとも整本だけか。どのファイルも触るな、クエリのみ可、GitHub プロジェクト自身も含めて。

ソースがくれた答えは二層である。/export の文法は /export [path] [from=N] [to=M] [--overwrite]——形式は出力パスの接尾辞で決まる（.txt は TXT、.epub は EPUB 3、メタデータ・表紙頁・目次・章ごとの XHTML を含み、Apple Books/微信読書/Kindle 変換器で読める）。from は省略時 1、to は省略時最新完成章。範囲内に書き終わっていない章は自動的にスキップされ（ソース内の Skipped 分岐——to=100 と渡したが 80 までしか書けていなければ、あの 20 章はスキップされ結果に列記される、エラーにならない）。導出は読み取り専用の操作で、執筆途中いつでも「現段階の成品」を取れる。TXT の出力構造は《書名》→ 巻分隔（階層大綱モードで自動追加、巻頭にのみ挿入）→ 章正文。章号は一律「第 N 章 標題」形式に再構築され、正文中の Writer 自带の重複標題行は剥がれ、「序章」这类の非编号 h1 は正文として保持される。

しかし分章導出は存在しない——一つも。 ソース内の Options 構造体は五つのフィールドしかない——Format、OutPath、From、To、Overwrite——すべての導出能力はこれだけで、いかなる split/分章モードもない。 導出は常に「一つのパスに一つのファイル」——TXT か EPUB、いずれも整本形式である。

しかしあなたが欲しいものは元よりディスクの上にある——output/novel/chapters/ ディレクトリはそれ自体が分章保存——一章一ファイル：

chapters/
├── 01.md      ← 第 1 章（「# 第1章：標題」頭付き）
├── 02.md
├── ...
└── 231.md     ← 小説2 は今 231 の章ファイル

每章は独立した Markdown ファイルで、内容はその章の終稿正文である。だから「分章节バッチ導出」にソフトウェア機能は不要である——このディレクトリが現成の分章成品庫である。 .txt が欲しくて .md が嫌なら、md と txt はどちらも純粋テキストなので、chapters/ をコピーして接尾辞を .txt に変えればよい、内容は零変換である。平台の習慣に合わせて命名したいなら、コピーするときに名前を変えれば一章一ファイル。整本の排版が欲しいなら（《書名》+巻分隔+統一章号）、それこそが /export from=N to=M パス.txt の用途である。

つまり——分章導出 = 直接 chapters/ ディレクトリを使う（コピー可、接尾辞変更可）、マージ導出 = /export。 二筋の道がいずれもあり、一つはディスクに一つは命令の中にある。

六、辺境の小事

同日にはもういくつかの小差があった——doubao-nomark のグーグル插件のインストールは二歩に拆かれた（chrome://extensions/ でディベロッパーモードを有効化し、「解凍済みの拡張機能を読み込む」で extension/chrome を指す）、インストール後は「无印豆包 - 素材提取」と表示される。小説 md をバッチで txt に変換する一案は読み取り専用で審査され、結論は主体は実行可能だがマージのあの一歩は pandoc を使うな——数百 MB のテキストの文法木は数 GB のメモリを占めることがあり、ストリーミング連結に改める方が安定し、さらに -smart を足してスマート句読点を切ることを勧める——さもなくば省略号がそっと書き換えられる。そして Linux.do の《自建節点、好生活》という帖の逐階解読——Oracle Cloud Always Free の二台の ARM 小機、GCP の三区域の e2-micro 永久無料、Cloudflare Workers はゼロコストだが IP 段が针对性限速を受けている、そして誰も聞きたがらない一つの注意——公有雲上でプロキシを動かすのは基本的に雲廠商の ToS に違反し、AWS・Azure・Oracle は皆封号潮をやっていて、タグ付けされたら直接銷号、白嫖した残高と一緒にゼロに帰る。

軍団の二十四時間は、こうして四度の巡検、一度のアップグレード審計、一度の自首と一場の考古の間に過ぎた。衝撃はなく、すべて駐屯である——そして駐屯の規律こそが、衝撃の資本である。