집필 군단의 이십사 시간：네 번의 순검, 한 번의 업그레이드 심계, 그리고 /export의 고고

한 부대의 전력을, 침공할 때의 모습으로 판단할 수 없다. 주둔할 때의 규율로 판단한다.

一、네 번의 순검——제이십오 장에서 제백팔 장으로

새벽 영시 삼십팔 분에서 삼십구 분, 네 개의 ainovel-cli.exe가 C:\Users\Min\Desktop\英文小说 아래에서 시동했다, v0.7.10. 제1회 순검은 오전 두 시 사십구 분——穿越1은 제이십오 장을 쓰고, 規則世界은 제이십 장, 末日带系统1은 제십구 장, 修仙1은 제이십이 장. 네 개의 프로세스는 모두 Responding, 메모리 83-130MB, 매 프로젝트의 최근 오 분에 약 스물의 파일 변개, 로그의 타임스탬프는 검사 시점에서 이 분 이내——모두 실시간으로 집필 중. 한 건의 비고장 주기——末日带系统1이 오전 두 시 사십팔 분 삼십 초에 StopGuard의 기록을 하나, writer가 필요한 산물을 뛰어넘어 직접 끝내려 해 내장 위병에게 한 번 가로막힌 채근을 받고, 그 후 정상적인 생성 흐름으로 돌아갔다——그것은 폭주 방지 기구가 일을 하고 있다.

제2회 순검은 오전 십일 시 십구 분, 팔 시간 이십 분 후:

프로젝트	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에는 돌아갈 수 없다——오래된 바이너리는 새 형식을 읽지 못한다. 그러니 제2 걸음의 백업은 옵션이 아니다——정말 후회하면, 새 형식의 데이터를 지우고, 백업 폴더를 복원하고, 오래된 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은 모두 봉호 조를 한 적이 있어, 표적화되면 바로銷호, 공짜로 얻은 잔액과 함께 영으로 돌아간다.

군단의 이십사 시간은, 이렇게 네 번의 순검, 한 번의 업그레이드 심계, 한 번의 자수와 한 차례의 고고 사이에 지나갔다. 충격은 없고, 모두 주둔이다——그리고 주둔의 규율이 곧 충격의 자본이다.