Alastor-t34

ForgeGuard Nexus：證據驅動的工業維護 Agent 平臺 / Evidenzgetriebene Industrie-Wartungsagenten

Mon, 07 Sep 2026 00:00:00 GMT

::github{repo="alaster-t34/ForgeGuard-Nexus"}

ForgeGuard Nexus

Evidence-driven industrial maintenance agents with human-governed execution and post-maintenance verification.

ForgeGuard Nexus 是我目前持續開發的一個工業 AI Agent 平臺。它關注的並不只是「模型能不能把故障分類對」，而是另一個更接近真實工業現場的問題：當設備出現異常時，一個系統究竟需要掌握多少證據、約束與流程，才有資格提出可以被人採用的維護決策？

目前倉庫中的版本以 ForgeGuard Nexus 5.0 為主，Release Candidate 為 v0.7.9，專案採用 Apache-2.0 License。

專案地址：https://github.com/alaster-t34/ForgeGuard-Nexus

繁體中文

1. 為什麼不只做一個「故障分類模型」？

傳統預測性維護系統通常從感測器訊號開始，最後輸出一個故障類別、健康分數，或者剩餘使用壽命（RUL）。這些資訊很重要，但它們離真正的維護決策仍然有一段距離。

假設模型判斷某個軸承存在異常，工程現場接下來仍然要回答很多問題：

這批振動訊號本身可靠嗎？是否存在 clipping、dropout、DC offset 或其他品質問題？
故障模式到底是什麼？證據之間有沒有衝突？
RUL 或健康風險是否已經進入需要處置的時間窗？
對應的備件是否有庫存？
現場是否有具備相應技能的人員？
生產排程允許在哪個時間段停機？
這項操作是否屬於高風險行為？誰有權批准？
維修完成之後，如何證明設備真的恢復，而不是僅僅把工單勾成「完成」？

ForgeGuard Nexus 嘗試把這些問題放進同一個可審計的工作流，而不是把一個分類器外面套上聊天介面，然後就宣布「Agent 化」完成。那種做法很省事，現場通常不會因此變得更安全。

2. 從訊號到閉環，而不是從訊號到一句答案

ForgeGuard 的核心流程可以概括為：

Sensor / Edge / CSV input
        ↓
資料品質閘門 + 證據封裝
        ↓
故障診斷 + RUL / 健康風險
        ↓
FMEA + 庫存 + 生產 + 人員工具
        ↓
多方案維護規劃
        ↓
人工授權閘門
        ↓
工單執行
        ↓
維修後重新採集
        ↓
驗證：關閉事件或自動重新開啟
        ↓
審計軌跡 + 可重用知識

這裡最重要的一點是：診斷不是流程終點。

系統必須繼續處理維護所需的資源與組織約束，產生多個可比較的維護方案，經過人工授權後形成工單；而工單完成也不是終點，還需要重新採集維修後證據，進行後驗驗證。

如果驗證沒有通過，事件可以重新開啟，而不是因為「工程師已經點擊完成」就假設設備一定恢復。

3. 13 個角色受限的 Agent

目前 ForgeGuard 實作了 13 個具備角色邊界的 Agent，覆蓋：

資料品質；
感知與訊號分析；
工業知識；
故障診斷；
RUL 與風險；
人員安全；
能源與環境；
韌性與異常處理；
維護方案規劃；
治理與授權；
工單；
維修後驗證；
協調與工作流控制。

我更傾向把 Agent 看成「帶有明確責任、工具權限與狀態邊界的工作單元」，而不是讓所有能力都塞進一個萬能對話模型。

這種設計的好處是：哪個步驟使用了什麼證據、調用了什麼工具、由誰批准、最後為什麼關閉事件，都能夠留下可追蹤的路徑。

4. 證據品質優先

工業 AI 很容易出現一個尷尬問題：模型本身可能運作正常，但輸入根本不值得相信。

ForgeGuard 因此把資料品質放在工作流前面，對振動訊號檢查例如：

clipping；
dropout；
DC offset；
有效解析度；
噪聲一致性；
相互矛盾的證據。

低品質或矛盾證據不應該被強行壓成一個「確定答案」。系統可以要求重新採集、升級處理或拒絕繼續執行高風險決策。

這是 ForgeGuard 很重要的一條原則：不知道，就應該允許系統說不知道。

5. 模型只是系統中的一部分

目前系統包含可解釋的時域、頻域與包絡特徵，並提供可在 CPU 上部署的振動基線模型。

倉庫目前記錄的選定部署模型為：

dsp-calibrated-hgb-v0.2

在專案生成的 ForgeGuard OpenEval-RM 0.1.0 物理啟發式合成回歸資料集上，倉庫中的基準結果包括：

指標	結果
Macro-F1	0.9342
Balanced Accuracy	0.9375
CPU p95 Latency	13.912 ms
Abstention 後接受樣本準確率	0.9872
Mean Robustness Macro-F1	0.7166

這些數值的用途是可重現的回歸與魯棒性驗證，並不代表真實工廠精度。

這個界線需要非常明確。合成資料、公開資料集、物理試驗臺以及真實工廠證據，應該被分開描述，而不是把不同來源的結果混成一個漂亮但沒有意義的百分比。

6. 故障注入與安全行為

除了模型基準之外，ForgeGuard 還包含可重現的軟體／訊號故障注入流程，用來驗證系統在異常條件下是否能做出安全反應。

目前倉庫報告的回歸測試結果包含：

檢查	結果
Clean injected-fault classification accuracy	1.000
Corrupted-signal safe-response rate	1.000
Workflow-fault containment rate	1.000

同樣，這些結果屬於軟體回歸與安全行為證據，不是工業現場安全認證，也不是 plant safety case。

7. 人必須留在高風險決策迴路中

ForgeGuard 的定位是決策支援系統，而不是自動接管真實生產設備的控制器。

高風險操作必須經過具備授權的人員批准。系統的安全不變量包括：

缺少必要證據時，方案不能直接越過證據閘門；
高風險工單不能繞過人工批准；
沒有維修後驗證，事件不能直接標記為已解決。

這種限制看起來沒有「完全自治 Agent」那麼科幻，但在工業系統裡，能夠被限制、被審計、被拒絕，通常比「它很自主」更有價值。

8. 部署方式

ForgeGuard 不只考慮瀏覽器 Demo，目前倉庫包含多條部署路徑：

Docker；
Windows native / desktop launcher；
Linux native；
NVIDIA Jetson 邊緣裝置。

Docker 是目前最直接的啟動方式：

git clone https://github.com/alaster-t34/ForgeGuard-Nexus.git
cd ForgeGuard-Nexus
docker compose -f compose.yaml up -d --build api

啟動後可以訪問：

http://localhost:8000

健康檢查端點：

http://localhost:8000/api/v1/health

9. 我真正想解決的問題

ForgeGuard Nexus 最終想做的，不是把更多模型堆到一張架構圖上。

我更關心的是：

如何讓一個工業 AI 系統知道自己的證據是否可信、知道自己的權限邊界、知道什麼時候必須交給人決策，並且在維修完成後仍然有責任證明設備確實恢復。

從這個角度看，診斷模型只是閉環中的一個節點。

真正困難的部分是證據、模型、工業知識、資源約束、權限、執行與驗證之間如何連接，而且每一個關鍵決定都能被回溯。

專案仍在迭代，倉庫會繼續保留可重現基準、測試、部署文件與安全邊界：

GitHub：https://github.com/alaster-t34/ForgeGuard-Nexus

Deutsch

1. Warum nicht einfach ein weiteres Fehlklassifikationsmodell?

Klassische Predictive-Maintenance-Systeme beginnen häufig mit Sensordaten und enden mit einer Fehlerklasse, einem Health Score oder einer Schätzung der Remaining Useful Life (RUL). Diese Informationen sind wertvoll, reichen für eine reale Instandhaltungsentscheidung jedoch nicht aus.

Wenn ein Modell beispielsweise einen auffälligen Lagerzustand erkennt, bleiben in der Praxis weitere Fragen offen:

Sind die Eingangsdaten überhaupt zuverlässig?
Gibt es Clipping, Dropouts, DC-Offset oder widersprüchliche Signale?
Welcher Fehlermodus ist wahrscheinlich?
Liegt das RUL- bzw. Risikofenster bereits in einem kritischen Bereich?
Ist das notwendige Ersatzteil verfügbar?
Gibt es qualifiziertes Personal?
Welches Wartungsfenster ist mit der Produktionsplanung vereinbar?
Wer darf eine risikoreiche Maßnahme freigeben?
Und wie wird nach der Wartung nachgewiesen, dass sich der Anlagenzustand tatsächlich verbessert hat?

ForgeGuard Nexus versucht, diese Fragen in einem gemeinsamen, auditierbaren Workflow abzubilden. Ziel ist nicht, einen Klassifikator mit einer Chat-Oberfläche zu versehen und das Ergebnis anschließend als „Agentensystem“ zu verkaufen.

2. Von Sensordaten zu einem geschlossenen Wartungskreislauf

Der grundlegende Ablauf lautet:

Sensor / Edge / CSV
        ↓
Datenqualitäts-Gate + Evidenzpaket
        ↓
Fehlerdiagnose + RUL / Gesundheitsrisiko
        ↓
FMEA + Lagerbestand + Produktion + Personal
        ↓
Mehrere Wartungsoptionen
        ↓
Menschliche Freigabe
        ↓
Arbeitsauftrag
        ↓
Erneute Datenerfassung nach der Wartung
        ↓
Verifikation: Vorfall schließen oder erneut öffnen
        ↓
Audit-Trail + wiederverwendbares Wissen

Der entscheidende Punkt ist: Die Diagnose ist nicht das Ende des Prozesses.

Nach der Diagnose müssen Ressourcen, Sicherheitsregeln und organisatorische Randbedingungen berücksichtigt werden. Erst danach entsteht ein ausführbarer Wartungsplan. Und auch ein abgeschlossener Arbeitsauftrag bedeutet noch nicht automatisch, dass die Maschine wieder gesund ist.

ForgeGuard erfasst deshalb nach der Wartung erneut Evidenz. Wenn die Verifikation fehlschlägt, kann der Vorfall wieder geöffnet werden.

3. Dreizehn rollenbegrenzte Agents

Der aktuelle Stand umfasst 13 Agents mit klar abgegrenzten Verantwortlichkeiten. Sie decken unter anderem folgende Bereiche ab:

Datenqualität;
Wahrnehmung und Signalanalyse;
industrielles Wissen;
Diagnose;
RUL und Risiko;
Arbeitssicherheit;
Energie und Umwelt;
Resilienz und Ausnahmebehandlung;
Wartungsplanung;
Governance und Freigabe;
Arbeitsaufträge;
Verifikation nach der Wartung;
Koordination des Gesamtworkflows.

Ein Agent ist hier nicht als allwissender Chatbot gedacht, sondern als Arbeitseinheit mit definierten Aufgaben, Werkzeugen, Rechten und Zustandsgrenzen.

Dadurch lässt sich nachvollziehen, welche Evidenz für eine Entscheidung verwendet wurde, welches Werkzeug aufgerufen wurde, wer eine Maßnahme freigegeben hat und warum ein Vorfall geschlossen wurde.

4. Datenqualität vor Modellvertrauen

Ein industrielles KI-System kann formal korrekt rechnen und trotzdem eine schlechte Entscheidung treffen, wenn die Eingangsdaten unbrauchbar sind.

ForgeGuard prüft deshalb Vibrationsdaten unter anderem auf:

Clipping;
Dropouts;
DC-Offset;
effektive Auflösung;
inkonsistentes Rauschen;
widersprüchliche Evidenz.

Schlechte oder widersprüchliche Evidenz wird nicht zwangsläufig in eine scheinbar sichere Diagnose gezwungen. Stattdessen kann das System eine erneute Messung verlangen, eskalieren oder die weitere Ausführung blockieren.

Mit anderen Worten: Unsicherheit ist ein zulässiges Ergebnis.

5. Das Modell ist nur ein Baustein

ForgeGuard enthält interpretierbare Zeit-, Frequenz- und Hüllkurvenmerkmale sowie ein CPU-taugliches Vibrationsmodell.

Das derzeit im Repository ausgewählte Deployment-Modell lautet:

dsp-calibrated-hgb-v0.2

Auf dem projektintern erzeugten, physikalisch inspirierten synthetischen Regressionsdatensatz ForgeGuard OpenEval-RM 0.1.0 sind im Repository unter anderem folgende Werte dokumentiert:

Metrik	Ergebnis
Macro-F1	0.9342
Balanced Accuracy	0.9375
CPU-p95-Latenz	13.912 ms
Accuracy akzeptierter Samples nach Abstention	0.9872
Mean Robustness Macro-F1	0.7166

Diese Zahlen dienen der reproduzierbaren Regression und Robustheitsprüfung. Sie sind ausdrücklich nicht als Genauigkeit in einer realen Fabrik zu verstehen.

Synthetische Daten, öffentliche Datensätze, Prüfstandsdaten und reale Betriebsdaten müssen getrennt betrachtet und dokumentiert werden.

6. Fault Injection und sicheres Systemverhalten

Neben Modellbenchmarks enthält ForgeGuard reproduzierbare Software- und Signal-Fault-Injection-Tests.

Die aktuell dokumentierten Regressionsergebnisse umfassen:

Prüfung	Ergebnis
Clean injected-fault classification accuracy	1.000
Corrupted-signal safe-response rate	1.000
Workflow-fault containment rate	1.000

Auch hier gilt: Diese Ergebnisse sind Nachweise für Regressionstests und Sicherheitsverhalten der Software. Sie stellen keine industrielle Sicherheitszertifizierung und keinen Plant Safety Case dar.

7. Menschen bleiben bei risikoreichen Entscheidungen im Regelkreis

ForgeGuard ist ein Decision-Support-System und kein autonomer Controller für reale Produktionsanlagen.

Risikoreiche Aktionen benötigen eine autorisierte menschliche Freigabe. Zu den deterministischen Sicherheitsregeln gehören:

Ein Plan darf erforderliche Evidenz nicht umgehen.
Ein risikoreicher Arbeitsauftrag darf die menschliche Freigabe nicht umgehen.
Ein Vorfall darf ohne Verifikation nach der Wartung nicht endgültig geschlossen werden.

Das klingt weniger spektakulär als ein vollständig autonomer Agent. In industriellen Anwendungen ist ein System, das sich begrenzen, prüfen und im Zweifel stoppen lässt, allerdings meistens nützlicher als eines, das lediglich möglichst autonom wirkt.

8. Deployment

Das Repository unterstützt mehrere Deployment-Pfade:

Docker;
Windows Native / Desktop Launcher;
Linux Native;
NVIDIA Jetson für Edge-Szenarien.

Der schnellste Einstieg erfolgt über Docker:

git clone https://github.com/alaster-t34/ForgeGuard-Nexus.git
cd ForgeGuard-Nexus
docker compose -f compose.yaml up -d --build api

Danach ist der Dienst standardmäßig unter folgender Adresse erreichbar:

http://localhost:8000

Health Endpoint:

http://localhost:8000/api/v1/health

9. Das eigentliche Ziel

Das Ziel von ForgeGuard Nexus besteht nicht darin, möglichst viele KI-Modelle in ein Architekturdiagramm zu packen.

Mich interessiert vielmehr folgende Frage:

Wie kann ein industrielles KI-System erkennen, ob seine Evidenz vertrauenswürdig ist, seine eigenen Berechtigungsgrenzen respektieren, bei Bedarf einen Menschen einbeziehen und nach einer Wartung nachweisen, dass die Anlage tatsächlich wieder in einem akzeptablen Zustand ist?

Aus dieser Perspektive ist das Diagnosemodell nur ein Knoten in einem wesentlich größeren Kreislauf.

Die schwierigere Aufgabe besteht darin, Evidenz, Modelle, FMEA-Wissen, Ressourcen, Produktionsbedingungen, Berechtigungen, Ausführung und Verifikation so miteinander zu verbinden, dass jede wichtige Entscheidung nachvollziehbar bleibt.

Der Quellcode, die reproduzierbaren Benchmarks, Deployment-Dokumentation und Sicherheitsgrenzen befinden sich im Repository:

GitHub: https://github.com/alaster-t34/ForgeGuard-Nexus

ICPC 2026 Huawei Online Challenge：邊雲協同排程競賽復盤

Mon, 07 Sep 2026 00:00:00 GMT

這篇文章記錄我在 ICPC 2026 Online Challenge 1 powered by Huawei 中，針對 Codeforces 2251A Edge-Cloud Collaborative Scheduling 所做的一整套優化過程。

最後結果：

Codeforces Handle：al1swedel
官方最終分數：16661.204
Final standings：全球第 15 名
本文歸檔的真正最終提交源碼：CF2251A_FINAL_16661_204.cpp

版本說明（非常重要）：本文所稱「最終版本」，只指這次附上的、其 22 個 Judgement Protocol 分數合計為 16661.204179914599 的源碼。Codeforces 將其顯示為 16661.204。T207_C6_PN25_FLY20_C5F4_SUBMIT.cpp 是我在後期迭代中保存的一個重要內部版本，但不是這篇文章所歸檔的最終提交源碼。為避免內部版本名和官方最終提交互相污染，後文會把兩者明確分開。

這不是一個「找到某個神奇公式就結束」的題目。真正困難的是：同一個調度器要同時處理吞吐、延遲、不同階段的批處理收益、邊緣與雲端資源、請求到達波形，以及各測試點完全不同的權重。後期的工作因此逐漸從「寫一個 heuristic」變成「建立模擬器、做診斷、維護回歸集合，再一刀一刀地改策略」。

最終排名

Final standings 中，al1swedel 位於第 15 名，官方顯示分數為 16661.204。

先理解評分，而不是先猜調度策略

每個測試點最高 1000 分，本質上由兩部分組成：吞吐收益與等待時間收益。

NormalizedScore = w_tp * norm_tp + w_c * norm_c
Score           = 1000 * NormalizedScore
w_tp + w_c      = 1

其中：

tp：所有請求最終輸出 token 數 / 整體模擬時間跨度；
norm_tp：把吞吐從基準 tp_base 到目標 tp_UB 映射到 [0, 1]；
TDR：請求從到達到完成輸入階段的平均時間；
TPOT：相鄰輸出 token 的平均間隔；
norm_c：由 TDR、TPOT 相對各自 SLO 的超標程度得到的延遲分量。

第一個核心結論是：吞吐不是越大越好。 當 norm_tp 已經接近 1，再把 batch 做得更大，可能只會把 TDR / TPOT 推高，而吞吐分已經沒有額外收益。

所以後來我們不再把問題看作單純的 throughput maximization，而是更接近：

在不破壞吞吐下限的前提下，
動態決定何時湊 batch、何時立即服務、
何時拆分 P-PROC、何時把工作送到 cloud，
並控制每個階段的 backlog 與 token gap。

第一階段：先把 Judge 變成可以離線研究的系統

早期最大的問題不是「策略不夠強」，而是一次改動之後，我們很難知道它到底改善了什麼。

因此第一個真正有價值的工程工作，是建立一個可以逐分復現官方判分的本地 Judge。它會輸出：

tp
mean_tdr
mean_tpot
dist
norm_tp
norm_c
最終 score

有了 Judge，優化才從「提交、等分數、猜」變成可重現實驗。

較早的 T032 在 22 個公開測試上的本地總分是：

16383.560324671

當時明顯的低分點包括：

#5   487.78
#6   420.91
#10  684.42
#14  415.27

這讓問題第一次被拆成具體 cohort，而不是一個總分數字。

第二階段：建立統一的請求狀態機

一個 request 並不是「排進某台機器就完事」。它會在多個 stage 中流轉，並可能經過 edge / cloud、傳輸、pre/post processing 與逐 token output。

最終程式內部維護完整 request lifecycle，可以抽象成：

ARRIVE
  ↓
P-PRE
  ↓
network / transfer
  ↓
D-PRE
  ↓
decode / output loop
  ↓
P-PROC
  ↓
D-POST / finalization
  ↓
FIN

每個 request 保存 ready time、input length、目前 stage、cloud/edge 歸屬、處理進度、輸出進度等狀態。scheduler 的工作就是根據當下狀態決定下一個事件。

這一步沒有排行榜魔法，但它是後續所有優化的地基。沒有穩定狀態機，任何特殊策略都只是把 bug 換一個位置。

第三階段：從 FIFO 走向 score-aware scheduling

之後我們針對不同 stage 定義 priority，而不是整個系統只用一個 FIFO。

核心考量包括：

剩餘服務時間估計：根據 input length 與曲線估算 stage service cost；
SLO slack：接近 deadline 的 request 提高優先級；
backlog pressure：觀察 queue 積壓量與最老 request 的等待時間；
throughput / latency 權重：由 w_tp、w_c 決定是否值得等待更大的 batch；
stage-specific ordering：P-PRE、D-PRE、P-PROC 不共享完全相同的最佳順序。

可以把其中一類決策簡化成：

if (batch_not_full) {
    gain = saved_compute_if_wait_for_larger_batch();
    latency_risk = estimate_slo_risk();

    if (gain > latency_risk)
        wait_for_more_requests();
    else
        dispatch_now();
}

真正實作更複雜，因為還要處理 arrival 週期、decode 是否 hot、cloud 何時釋放、網路上下行佔用等訊號。

第四階段：動態 batching，而不是固定 batch cap

固定 batch size 很容易失敗。

batch 太小：

compute efficiency 差；
throughput 上不去；
norm_tp 直接丟分。

batch 太大：

為了湊 batch 等太久；
TDR 變差；
decode/output 被阻塞後 TPOT 也會變差。

因此後續版本把 batch size 變成 workload class、stage、queue pressure、SLO 與觀測週期共同決定的量。

在一些 cohort 中，系統甚至要經歷：

FILL → STEADY → DRAIN / PRESSURE

FILL 階段允許積累工作以提高吞吐，STEADY 維持穩定 WIP，而 backlog 或 token-gap 風險過高時則切到清壓策略。

第五階段：P-PROC chunking，保護 TPOT

某些長 P-PROC 工作如果一次吃完整段 compute，會把下一批 hot request 的服務時間向後推。

所以後期程式允許把 P-PROC 拆成 piece：

full P-PROC
████████████████████████

chunked P-PROC
████████  | hot work |  ████████

是否切分，不是固定按層數硬砍，而是比較：

下一個 guaranteed / hot event 還有多久；
full processing 需要多久；
hot request 額外等待造成的 latency cost；
chunking 帶來的 setup / throughput cost。

這是一個很重要的 trade-off：寧可犧牲一小段局部 compute efficiency，也不要讓高價值 output gap 爆掉。

第六階段：不要假裝所有測試點來自同一種分布

22 個公開測試在這些維度上差異很大：

input length 分布；
arrival pattern；
edge/cloud concurrency；
stage curve；
SLO1 / SLO2；
w_tp / w_c；
output length 與週期性。

因此後期方案不是「一條萬能公式」，而是：

online observable features
          ↓
workload / mode detection
          ↓
shared scheduling core
          ↓
small number of guarded policy branches

關鍵不是 branch 越多越好，而是 branch 必須有可觀測條件與回歸保護。如果只是 if (test_id == 6)，那不是 scheduler，只是把排行榜寫進程式碼。

版本迭代：分數是怎麼一點點擠出來的

幾個保存下來、且有完整 22-case regression 的代表節點：

版本	22-case 本地分數	主要變化
T032	16383.5603	早期可重現 baseline，暴露 #5/#6/#10/#14 等瓶頸
T066	16458.9859	固化較穩定的 cohort routing 與 batch/queue 策略
T068	16475.1578	對 T13/T16 等 cohort 做定向且可回歸的修補
T069	16530.7135	#13 出現明顯局部收益，總分繼續上移
T106 FUSED	≈16612.5863	多條已驗證策略融合，進入後期微調階段
T207	後期內部 checkpoint	保存了 C6 等一批重要後期策略；不是本文真正 final 源碼
Final submission	16661.2041799146	本文附上的真正最終源碼，對應 Codeforces 16661.204 / Rank 15

越到後面，大改越不值錢。

例如 T107 相對 T106 的一次 patch，只動了三個很窄的地方：

#4   +0.184305
#12  +0.891554
#13  +1.279066
----------------
Total +2.354925

更重要的是，其他 19 個 case 的 delta = 0。後期真正可靠的工作方式變成：只改能證明會變好的區域，其他 case 儘可能鎖死。

C6：從公開特例到帶 guard 的可觀測策略

C6 是後期最難處理的 cohort 之一。內部版本名曾留下 PN25、FLY20、cloud-specific FLY 等調整痕跡；真正 final 源碼中則可以看到更完整的兩層設計：

public-context preservation
        +
observable generalized context
        +
fallback / guard

也就是說，公開 workload 上保留已驗證的高分行為，同時對相似但非完全相同的 workload 用可觀測條件觸發更保守策略。這比把一串 case fingerprint 硬塞進 if-else 稍微像一個真正的 scheduler。

Exact Regression：最後真正依賴的工程方法

每次 patch 後，不只看總分，而是跑完整 22-case：

case 1   old → new → delta
case 2   old → new → delta
...
case 22  old → new → delta

一個 patch 要進主線，至少要回答：

改善的是哪個 case？
為什麼改善？
是否讓其他 case 退步？
依賴的是 workload 可觀測特徵，還是 public fingerprint？
條件判斷錯誤時，有沒有 fallback？

這讓後期版本雖然越來越複雜，但每一層複雜度至少都有對應的回歸證據。

最終提交記錄

提交記錄可以看到競賽末期仍然反覆迭代、回退與再驗證。最終有效結果固定在 16661.204。

真正的最終源碼：這裡再說一次

為博客歸檔，我把你看到的真正 Codeforces 最終提交源碼另存為：

CF2251A_FINAL_16661_204.cpp

22-case Judgement Protocol 合計：16661.204179914599
Codeforces 顯示分數：16661.204
Final standings：#15
歸檔檔案大小：65321 bytes
SHA-256：03f8bea96b0766b23d160ffa16804240d1e66a29b93c14ac61f3c273791dfa38

這個 hash 綁定的是本文附上的 final source，不是之前的 T207 檔案。

前幾行如下：

#include<bits/stdc++.h>
#define R0 return
#define X int
#define Y auto
#define Z max
#define W min
#define O bool
#define H abs
#define T to_string

後面的程式已經為提交尺寸與迭代速度做了大量壓縮，閱讀感受接近直接盯著一堵 AST 牆。正文不再複製 65 KB 的單行壓縮源碼；本文保存其校驗值與完整 Judgement Protocol，避免把其他內部版本誤認成 final。

最終 Judgement Protocol

這份 final source 的 22 個 case 結果如下。這也是它被認定為「真正最終版本」最直接的數值證據。

Case	Points	tp	mean TDR	mean TPOT
#1	500.000003	0.022222	30.000000	0.000000
#2	500.000000	0.005755	126.158679	0.000000
#3	500.567967	0.003880	1329.849832	56.462313
#4	832.863211	0.071298	493.337948	76.694740
#5	518.651126	1.340047	1497.254452	67.292136
#6	463.917548	0.869552	3880.824744	60.637259
#7	924.498223	0.008881	858.868074	62.657461
#8	838.237636	0.013495	1086.885839	98.955170
#9	735.942762	0.004383	5726.290775	0.000000
#10	684.424557	0.007628	182521.173882	86.964712
#11	500.239294	0.000007	65540728.936072	16199.089335
#12	806.526300	0.000024	1280549.638656	178.211443
#13	822.142160	0.030751	1714.712378	145.324146
#14	415.266866	0.003564	192.489397	185.993268
#15	888.996971	0.000009	7303441.029544	0.000000
#16	981.471475	0.029808	41824.000072	71.703522
#17	944.639041	0.000520	8563137.539103	5875.574485
#18	916.202899	0.000009	17713636.295039	0.000000
#19	960.253914	0.717268	144.309740	142.346375
#20	998.203001	0.005607	1257.782370	172.089175
#21	972.924403	0.012525	35870.869792	0.000000
#22	955.234823	39.873266	1858.000000	6.002148

Total = 16661.204179914599 → Codeforces 顯示 16661.204

實時排名錄影

當時保存的實時排名影片：

YouTube：https://www.youtube.com/watch?v=yXFaB-dMkpk

賽後：研究版本和比賽 final 必須分開

比賽結束後，我仍然繼續做泛化、OOD 與更保守的策略實驗。但這些版本必須和競賽 final 分開記錄。

競賽時間線
T032 → T066 → T068 → T069 → T106 → ... → late checkpoints → FINAL SOURCE
                                                        ↓
                                             16661.204 / #15
                                                        ↓
                                                  contest ends
                                                        ↓
賽後時間線                                      generalization / OOD audit

所以本文有一條硬規則：

凡是比賽結束後做的 generalized / OOD / distilled 版本，不論本地測試多漂亮，都不回寫成「比賽最終版本」。

這個區分很重要。否則很容易把「賽後更乾淨的研究程式」誤寫成「當時真正提交的程式」，最後版本史就會變成一場由檔名主導的歷史修正主義。

最後留下來的東西

這次 Challenge 最有意思的地方，不只是第 15 名，而是我們最後真的把一個最初靠直覺調參的 heuristic，逐步變成：

可復現 Judge
+ 狀態機
+ score-aware scheduling
+ dynamic batching
+ workload classification
+ guarded specialisation
+ exact regression
+ post-contest OOD audit

最後那份約 65 KB、幾乎被壓成一堵牆的 C++ 並不好看，但它保存了整個迭代過程留下來的工程決策。競賽程式有時就是這樣：外表像事故現場，裡面每一條傷痕卻都有來歷。

關於·利用pytorch、Mask R-CNN與U-Net用來拆分的想法

Wed, 22 Jan 2025 00:00:00 GMT

▇ ▆ ▅ ▃ ▂ ▁ ▂ ▃ ▅ ▆ ▇

用於拆分的ai模型，要分爲兩部分

1. 用於標記（注）的ai模型
1. 用於拆分的ai模型

用於標注的ai、模型

準備數據集與訓練的基礎
- 收集數據（立繪圖像），需具備多個部件我打算從蔚藍檔案，少女前綫，碧藍航綫，鳴潮，少前2·追放裏獲得（但是，但是哈，不夠，這還不夠）
- 手動標注少量成本，作爲初始訓練數據采用遷移學習和數據增强等技術，利用少量標記樣本來起到初步訓練模型的作用。預計要300張標記圖。
- 每個立繪圖像的標簽應是分割圖（mask）
- 每個部件對應一個唯一的標簽
使用深度學習模型進行圖像分割
- 采用 U-Net 等预训练模型，分割出不同的图层。
将分割后的不同部分提取出来并保存
優化

最主要的拆分部分 头发：前发、后发、侧发等。 眼睛：上眼皮、下眼皮、瞳孔等。 嘴巴：上嘴唇、下嘴唇、舌头、牙齿等。 衣服：上衣、裤子、裙子等。 面部：面颊、鼻子、下巴等。 耳朵。 四肢：手臂、手、脚、腿等。

配件和饰品：耳环、眼镜、帽子等。

需要的一些python庫：pytorch torchvision matplotlib opencv-python pillow numpy

pip install torch torchvision matplotlib opencv-python pillow numpy

構建標注系統的步驟

訓練自動標注模型要基於已有的標註數據集訓練圖像分割模型，這樣模型可以學會如何對圖像進行像素級的標註。

# 假設你已經訓練了U-Net模型並將其命名為 `unet_model`
model = UNet(in_channels=3, out_channels=3)  # 設定為分割三個類別（例如，背景、頭髮、衣服）

# 訓練模型的步驟與之前相同，並保存模型

建立自動標記系統使用訓練好的模型來對新的圖像進行自動標註。

import torch
from PIL import Image
import numpy as np
import torchvision.transforms as transforms

加載模型

model = UNet(in_channels=3, out_channels=3) model.load_state_dict(torch.load('unet_model.pth')) model.eval()

預處理圖片

transform = transforms.Compose([ transforms.Resize((256, 256)), transforms.ToTensor(), ])

def auto_label(image_path): image = Image.open(image_path).convert('RGB') image_tensor = transform(image).unsqueeze(0) # 增加 batch 維度

   with torch.no_grad():
       output = model(image_tensor)
   # 轉換輸出為標註圖像
   output = torch.argmax(output, dim=1).squeeze().cpu().numpy()

   return output

# 處理文件夾中的所有圖像

input_folder = 'path_to_images' output_folder = 'path_to_output_labels'

for image_name in os.listdir(input_folder): image_path = os.path.join(input_folder, image_name) label = auto_label(image_path)

# 儲存自動生成的標註圖像
label_image = Image.fromarray(label.astype(np.uint8))  # 保存為圖片
label_image.save(os.path.join(output_folder, f'{image_name}_label.png'))

關於·訓練ai讓其對原畫立繪進行拆分(圖像分割）的步驟的一些基层想法

Thu, 16 Jan 2025 00:00:00 GMT

我是這樣想的，這個過程應該可以通過圖像分割和深度學習來實現。

具體步驟大概如下：

1. 收集數據集

需要收集帶有標註的數據集，每張圖片對應著其拆分後的部件

數據集需要包括：

原畫立繪圖片。
每個部件的掩碼圖（mask），標註出每個部件的邊界和區域，這是模型學習拆分的關鍵。

數據集的質量對訓練效果至關重要，因此需要標註準確，且數據量足夠多（通常需要數千張圖片及其對應的標註）。

1.關於·手動標註數據

直接且準確，~~（但時間成本高。）~~ 本人不建議，大概步驟是這樣：

1. 使用標註工具來手動標註每個部件。這些工具允許你在每張圖片上創建掩碼（mask），標註每個部件。
1. 將每個部件的區域保存為單獨的圖層，通常是二進制掩碼圖（例如黑色背景，白色部分代表部件）能用：
1.LabelMe
2.VGG Image Annotator (VIA)
3.LabelImg
4.CVAT
5.RectLabel

2.關於·現有的標註數據集

（~~使用現有的標註數據集，可以節省時間，但質量。。。）~~ 如果已有的標註數據集包含了與原畫立繪拆分相關的圖像，可以使用這些數據集來加速訓練。雖然這樣的數據集不常見，但一些公共數據集可能會有所幫助（應該吧）

1.COCO Dataset
2.Pascal VOC Dataset
3.ImageNet Dataset
4.Open Images Dataset
5.ADE20K

3.關於·半自動標註

~~（手動標註的時間成本高，因此可以考慮使用半自動的工具來標註數據。但質量畢竟。。。）~~ 大概步骤步骤如下：

使用已有的深度學習模型（如 U-Net 或 DeepLab）對原畫立繪圖片進行初步分割，生成初步的部件掩碼。
這些掩碼雖然可能不完美，但可以作為標註的基礎，人工進行修正。
對每個部件進行細微調整，保證標註的準確性。

4.關於·使用圖層分離工具

~~（这个似乎是比较简单的了）~~ 直接提取每個部件的圖層，並將其作為掩碼圖。（大霧）

诶！这时候就有人要说了：能不能不用掩码图？

 

我还真想了这事，但是这玩意会导致模型的复杂度增加 我想的是，畢竟沒有現成的掩碼圖，故需要自己生成（或是用模型生成），但是，這樣生成的模型它的局部性太强，不具有全局概括性，可能导致模型欠擬合。而且，操作有些麻煩。 先來説説複雜度增加一事：

首先，數據標記的複雜性 在無掩碼圖的情況下，模型無法依賴直接的注釋信息（像素級標簽），無掩碼圖將會導致工作更爲複雜。 

手動標記的工作量大 

手動標記的標注精度低 

手動標記的標注成本高

其次，模型訓練的複雜度 

學習目標不明確· 模型需要依賴間接的提示或約束條件（例如局部標注、特徵信息等等）來理解圖像的結構和内容，而不是像傳統方法那樣有像素級標簽。而且，損失函數將難以優化與設計。

特徵學習難度大· 模型要從整體特徵中去推斷出不同部分的邊界與關係，那麽就要讓模型不僅要學習到每個區域的特徵，還要學習如何區分這些區域。（你可以想象一下，這個模型的學習能力要多强···）當然還有一系列的問題，不多説了。 ~~（罪加一等哈~）~~

2. 訓練模型

訓練模型的目的是讓模型學習到如何分割出每個部件，並且學習到如何合成出完整的立繪。訓練模型的目標是生成一個模型，可以根據輸入的圖片，輸出每個部件的掩碼圖（mask）和合成圖片。訓練模型的流程大概如下：

選擇模型架構，例如：U-Net、SegNet、FPN、Mask R-CNN、DeepLab等。
數據預處理： 1、圖像縮放與裁剪：將所有圖像統一大小，避免過大的圖像影響訓練效率。 2、正規化：對圖像進行正規化處理，使其像素值處於 [0, 1] 或 [-1, 1] 的範圍內。 3、數據增強：對圖片進行隨機裁剪、旋轉、翻轉等操作，增加訓練數據的多樣性，提升模型的泛化能力。

訓練過程：

定義損失函數，例如：交叉熵、Dice Loss、Dice coefficient損失等。
定義優化器，例如：Adam、SGD等。
訓練模型，使用訓練數據進行模型訓練，根據每次訓練的損失函數來調整模型參數。 訓練過程中，模型將學習如何將每個像素點分類為不同的部件（如髮型、衣服等），並學會拆分圖像。

3.後處理

訓練完模型後，進行後處理來優化結果：

邊緣檢測：檢測模型輸出的掩碼圖（mask）是否有缺陷，如：邊緣太粗、邊緣太細、邊緣太尖等。
邊緣修正：對模型輸出的掩碼圖（mask）進行邊緣修正，如：用多邊形裁切、用模糊處理等。
小區域去除：去除一些不必要的小區域，避免分割過程中出現噪聲。

4.測評

IoU：用來衡量預測結果和真實標註之間的重疊度。
Dice係數：用來評估分割結果的準確性，特別是對於類別不平衡的問題。

5. 將模型部署到ai上

將訓練好的模型部署到ai上，讓ai可以根據輸入的圖片，輸出每個部件的掩碼圖（mask）和合成圖片。部署模型的流程大概如下：

將訓練好的模型轉換為可部署的格式，例如：ONNX、TensorRT等。
將模型部署到ai上，例如：Tensorflow、PyTorch、Caffe、MXNet等。
將模型的輸入圖片轉換為模型可以接受的格式，例如：JPG、PNG、BMP等。
將模型的輸出掩碼圖（mask）和合成圖片轉換為可視化的格式，例如：JPG、PNG、BMP等。
將模型的輸出結果呈現。

6. 持續優化

用pytorch，tensorflow等框架，對模型進行持續的訓練，提升模型的性能。

對，我還是不死心！

Tue, 14 Jan 2025 00:00:00 GMT

這一篇是續著上一篇的《FaiREE-AIイラストか》而寫的，因爲發現上一篇那個幾乎沒啥用，並不能解決我的問題（苦笑）。衆所周知，我會畫立繪，但是！我太懶了，而且因爲時間問題（我的時間永遠是斷斷續續的），就打算讓AI製作live2d模型。

首先不得不承認的是：直接通过代码生成 Live2D 模型是相对复杂的 因为 Live2D 模型的创建涉及到图像处理、骨骼动画和物理引擎等多个方面，而这些技术都是相对复杂的。因此，直接通过代码生成 Live2D 模型并不现实。
但是：理论上是可以通过编程生成或自动化 Live2D 模型的部分步骤 這些部分步驟，比如图像处理、骨骼动画和物理引擎，理论上是可以自动化完成的。比如，图像处理部分，可以利用计算机视觉技术，对人物的照片进行分析，提取出人物的轮廓、皮肤、眼睛、嘴巴等特征，并将这些特征转化为 Live2D 模型的贴图。骨骼动画部分，可以利用机器学习算法，对人物的动作进行分析，并生成 Live2D 模型的动画。物理引擎部分，可以利用物理模拟技术，模拟人物的运动，并生成 Live2D 模型的物理效果。
因此：理论上是可以自动化生成 Live2D 模型的

關於自动化图像切割与建模

尽管 Live2D 的建模和动画主要依赖于手动操作和设计，但可以使用一些代码工具（如 Python 脚本）来辅助自动化某些部分（應該），比如：在图像的切割和图层划分上。 步驟的話： 图像处理：使用 Python 的 OpenCV 库对图像进行处理，提取出人物的轮廓、皮肤、眼睛、嘴巴等特征。（或者PIL库） 导出 Live2D 数据：理论上，可以通过代码将这些分割后的图层和骨骼设定转换为 Live2D 模型所需的格式（如 .moc3、.model3.json 等）。（然而，这部分需要深刻了解 Live2D 的文件格式和动画规则，挺复杂）

關於自动化骨骼动画生成

Live2D 的动画生成主要依赖于手动操作，但可以使用一些代码工具（如 Python 脚本）来辅助自动化某些部分（應該），比如：在动作的分析和动画生成上。 步驟的話： 动作分析：使用 Python 的 OpenCV 库对视频进行处理，提取出人物的动作特征。（或者用其他的动作识别库） 导出 Live2D 数据：理论上，可以通过代码将动作特征转换为 Live2D 模型的动画文件（如 .motion3.json 等）。（然而，这部分需要深刻了解 Live2D 的文件格式和动画规则）

關於自动化物理引擎生成

Live2D 的物理引擎生成主要依赖于手动操作，但可以使用一些代码工具（如 Python 脚本）来辅助自动化某些部分（應該），比如：在人物的运动模拟上。 步驟的話： 运动模拟：使用 Python 的 PyBullet 库进行物理模拟，模拟人物的运动。（或者用其他的物理引擎库~~?~~） 导出 Live2D 数据：理论上，可以通过代码将物理模拟结果转换为 Live2D 模型的物理文件（如 .physics3.json 等）。（然而，这部分需要深刻了解 Live2D 的文件格式和物理规则）

結論

~~Live2D 模型的自动化生成，理论上是可以实现的，但還屬於起步階段。 ~~ ~~并且不是一個大一統的程序可以解決的（就目前而言因爲要寫這莫一個程序是十分複雜的，畢竟是生成系統，文件而非一張動畫）~~

難道這就結束了嗎？終歸是徒勞嗎？不，一定是遺漏了什麽······

因爲是要構建一個live2d模型文件夾，所以，根據下載的那麽多文件來看，首先是拆分出來的圖片，然後再來是動畫文件，最後是物理文件。那麽對這三個都進行自動化生成，那麽就需要有一個自動化工具，這個工具可以將圖片切割、動畫生成、物理模擬，然後合併成一個live2d模型文件夾。

那麽，這個工具應該要有什麽功能呢？

圖片切割：將圖片切割成可以被Live2D模型使用的格式，例如.moc3、.model3.json等。
動畫生成：將動作轉換成Live2D模型的動畫文件，例如.motion3.json等。
物理模擬：將物理模擬結果轉換成Live2D模型的物理文件，例如.physics3.json等。
合併文件：將圖片、動畫、物理文件合併成一個Live2D模型文件夾。

圖像分割技術

圖像分割技術。通過使用深度神經網絡（如捲積神經網絡，CNN）。有如下幾種辦法。
α.深度學習模型（如 U-Net、Mask R-CNN） 利用模型進行語義分割，即自主識別圖像的不同區域（如頭髮、眼睛、嘴巴等）。這個可以將關鍵部位提取至單獨圖層。
β.工具和框架
DeepLabV3：Google提供的一個深度學習模型，用於圖像分割；
RunwayML：一個圖像分割工具，可以將圖像分割成不同類別的區域。 Stable Diffusion 或 MidJourney（生成图像辅助工具）：~~虽然这些工具主要用于生成图像，但也有潜力帮助生成分层图像，或通过风格转换将图像转化为适合 Live2D 的风格。~~
~~γ.懶人的現成AI工具~~ ~~AI Studio：[^提供Live2D模型的生成，可以直接上傳照片，生成Live2D模型文件夾。]~~:（你在想什麽?真有這莫好的工具？那我早用了！還寫個damn）
~~自動化拆分工具（？有這玩意？我不知道啊）~~ Clip Studio Paint：这款软件允许你为角色插图设计分层和分割，并且它提供了一些智能辅助工具来帮助简化分割过程。虽然它本身不是 AI 驱动，但通过其强大的图层功能，可以加速手动拆分的过程。（GPT説的）我的感覺就是：自己寫一個的了。。。

睏了，睡會兒。

（唔，睡了一晚上。。。）

於是是可以用ai來拆分，但是要如何生成動畫文件、物理文件方面。。。 先讓我歸籠下文件組成：

\1. .moc3文件： Live2D模型的骨架文件，包含了模型的骨骼、頂點、材質、材質參數等信息。它是經過Live2D Cubism編輯器處理後生成的，所以說是模型的“骨架”。
\2. .model3.json文件：這個文件用來描述模型的基本設定、繪製層級、動畫設定等。它是和.moc3文件配合使用的，通常包含了模型的配置、材質、物理效果等參數。
\3. .motion3.json文件： Live2D模型的动画文件，包含了模型的各个部件的动画轉換信息。這些動作可以是表情變化、眼睛眨動、頭部旋轉等。這些動畫可以被觸發並進行時間控制。
\4. .physics3.json文件： Live2D模型的物理文件，包含了模型的物理效果信息。
\5. 材質文件（通常是.png、.jpg等圖片格式）模型的各個部件（如頭髮、眼睛、衣服等）會使用不同的圖片作為材質，這些圖片需要被指定到.model3.json中相應的部位。(這裏的應該是拆分后的立繪)
\6. .pose.json文件 Live2D模型的初始姿勢文件，定義了模型的初始姿勢。這些文件存儲了模型的靜態設定，並允許設置初始的眼睛、嘴巴等位置。
\7.Live2D Cubism SDK 在開發中，Live2D Cubism SDK會用來將所有的文件和設定合併，並導出最終的模型，以便在應用程序或遊戲中使用。
\8.音效和配音文件（可選）模型的聲音可以被指定到.model3.json文件中，並且可以被觸發。

在瞭解到這個后，我的打算是看看別人的那些模型文件夾，結果呢。。。令人費解的事情發生了。。。

我找到了用于在网页上展示的《少前》的79式模型文件，結果呢，裏面只有.moc3，.mtn，.model3.json和拆分后的立繪。其他的文件，直接没有？！ 而且，79式的模型文件夾裏的model.json與我從b站上下載的模型文件夾裏的model.json不太一樣，裏面有很多的差異。。。 故我的猜想是：79式的模型因爲是用於網頁的，所以省略了其他的文件；而B站上的模型是爲了適應其他的用途，所以較爲齊全。 (不過，79式的model.moc文件不能用live2dcubism打開，屮)

有一説一，這篇文章寫得真是亂七八糟的

FaiREE-AIイラストか

Mon, 13 Jan 2025 00:00:00 GMT

AIイラストからLive2Dモデルとして動かすまでのまとめ

从 AI 插图到作为 live2d 模型运行的总结

(本人沒學過太多日語，所以這篇文章就是對FaiREE上的《AI Live2D》的機翻和我的蹩脚翻譯，属于是为了我方便看）.原网址是这个：https://fairee.sozaiya-san.com/aiart-to-live2d/) AIイラストからLive2Dでモデルを作成し、Vtube Studioで動かすまでに参考にしたサイトをまとめていきます。 从 AI 插图到用 live2d 制作模型，再到用 live2d 制作 Vtube (Studio) 运行为止，总结参考过的网站。

必要なもの・時間(所需的东西与时间)

普通のスペックのPC（イラストがあればグラボ不要） 普通的 PC (有图就不需要实验室)
Photoshopまたはクリップスタジオ（イラストのパーツ分け） Photoshop 或剪切板工具 (分割图层)`
Vtube Studio
Live2D Cubism Core SDK
OBS studio（配信用） OBS studio (用于直播)

ちなみに、Live2DとVtube Studioは初めて使いました。パーツの切り分けからモデル作成まで10時間くらい、Vtube Studioの設定とかで１時間くらいです。そのほか調べ事などが５時間くらいでした。 顺便说一下，我第一次使用了 live2d 和 Vtube Studio。大概 10 个小时，从零件切割到模型制作，大概 10 个小时，Vtube 设置，Studio 设置，大概 10 个小时。此外，还有约 5 个小时的调查。(作者原句) Photoshopやクリップスタジオ使ったことない人はもう＋３時間くらい？ただ、慣れたら１モデル作るのに10時間もあればいけそうな感じでした（複雑な動きはしないモデルで） 如果你还没有使用过 Photoshop 或剪切板工具，那就得多花点时间了。但如果你已经熟悉了，那就只需要 10 个小时就能制作出一个简单的模型了。(作者原句) Vtube Studioを使って、PCのインカメラで顔認識（フェイストラッキング）させて動かしています。 Vtube Studio 用来，用 PC 内置摄像头进行人脸识别（面部跟踪）来运行模型。 ここまで作成するのに参考にしたサイトをまとめていきます。 以下是我们制作这些网站时参考的内容。 霧

イラストの準備(准备图画)

イラストのポイントは下記のとおりです。 图画的要素如下：

背景：透明なものが望ましい
イラストのポイントは下記のとおりです。
解像度は自由（大きめ推奨）
口が開いている（公式チュートリアルにあわせて）
できれば正面顔
背景：透明的背景比较好
全身插图 (配合官方教程)
分辨率自由 (推荐大尺寸)
口张开 (跟官方教程一致)
正面的脸比较好 できれば正面顔で左右対称に近い方がやりやすいです。参考画像くらいでも若干大変でした（でもどの角度でもできます）。 建议正面，左右对称的图画，这样更容易制作。（虽然在哪个角度都可以制作）。(機翻：如果可能的话，正面脸靠近左右对称更容易做到。即使是参考图像也有点困难 (但任何角度都可以)。)

Live2D・Vtube Studioの準備

Live2Dはすぐに必要ですが、Vtube Studioはモデルができてからで大丈夫です。 Live2D 立刻需要，但 Vtube Studio 要等模型制作完毕后再来。

Live2Dのインストール

安装 Live2D

（這裏跳過，因為我已經有 Live2D Cubism Core SDK 了。）

Vtube Studioのインストール

安装 Vtube Studio

（這裏跳過，因為我已經有 Vtube Studio 了。在steam上下載，可以看這篇文章：https://he72oh.com/vtube-studio-manual/）

OBS studioのインストール

安装 OBS studio

OBSは配信ソフトです。そのままYouTubeやツイキャスなどにライブ配信できます。 OBS 是直播软件，可以直播到 YouTube 或者 Twitch 等平台。 イメージとしては、Vtube Studioでフェイストラッキングしたモデルを動かし、OBSでゲーム画面などとVtube Studioのモデルを合成してYouTube等に流すイメージです。 一个 Vtube 模型，用 Studio 面部追踪，然后用 OBS 把游戏画面和 OBS 的 Vtube 合成在 Studio 上，再用 YouTube 播放。(當然也可以用其他平台) なので、モデルを動かしたり、好きな背景と合成して動かすだけならVtube Studioだけで十分できます。必要な人はダウンロードしましょう。 所以,我们可以移动模型,如果你只是想把它和你喜欢的背景合成在一起然后移动它，Vtube Studio 就足够了.有需要的人可以下载。

イラストのパーツ分け→モデル作成(分割插图→创建模型)

Live2D公式がとてもわかりやすい動画を出してくれていますので、そちらを参考にすれば大丈夫です！私も公式だけしか見てません。 Live2D 官方有非常好的教程视频，可以参考！我也是只看过官方的教程。

再後面的的步骤，就是分割插画，创建模型了。 幾乎啥也沒講，都是live2的的官方教程。。。幾乎沒啥用。（所以我幹了啥。。。） 總之，現在缺少模型。所以我們需要先把模型做出來。完結（暫時）

H5

Mon, 06 Jan 2025 00:00:00 GMT

HTML5 小貓娘：基本資訊與使用方法

本頁面的存在目的，是協助使用者理解名為 HTML5 的 Web 結構技術。

為了降低理解成本，本頁將 HTML5 描述為一位負責搭建網頁骨架的 小貓娘。

她並非程式語言。

她是標記語言。

她的任務，是將文字、圖片、連結、表格、表單、影片與音訊整理成瀏覽器可以解析的結構。

換言之，HTML5 是 Web 頁面的骨架。

而 HTML5 小貓娘，就是負責把這副骨架排列整齊的執行者。

1. 基本定義

HTML 的全稱是：

HyperText Markup Language

中文通常稱為：

超文字標記語言

HTML5 則是現代 Web 常用的 HTML 標準。

它負責描述網頁內容的結構。

如果將一個網站看作一位角色，那麼：

技術	職責	小貓娘式說明
HTML5	結構	骨架與房間配置
CSS	樣式	衣服、髮型與顏色
JavaScript	行為	動作、互動與魔法

HTML5 小貓娘負責宣告：

這裡是標題。這裡是段落。這裡是圖片。這裡是連結。這裡是表單。這裡是使用者可以操作的入口。

任務明確。

結構優先。

2. HTML5 小貓娘的基本資訊

項目	資訊
名稱	HTML5 小貓娘
技術本體	HTML5
類型	標記語言
職責	建立網頁內容結構
主要武器	標籤 tag
搭檔	CSS、JavaScript
常見檔案副檔名	`.html`
主要執行環境	Web 瀏覽器
核心義務	讓內容被瀏覽器正確理解

HTML5 小貓娘不會負責複雜計算。

不會處理資料庫。

不會獨自完成華麗動畫。

她的本質任務是：

將內容放到正確的位置。

這就是她作為 HTML5 的存在意義。

3. 第一個 HTML5 文件

一份最基本的 HTML5 文件如下：

<!doctype html>
<html lang="zh-TW">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>HTML5 小貓娘</title>
  </head>
  <body>
    <h1>你好，我是 HTML5 小貓娘</h1>
    <p>我的任務是協助你建立清楚的網頁結構。</p>
  </body>
</html>

這段程式碼可以存成：

index.html

然後用瀏覽器開啟。

如果頁面顯示出標題與段落，代表 HTML5 小貓娘已經成功啟動。

4. 文件結構解析

`<!doctype html>`

<!doctype html>

這一行告訴瀏覽器：

本文件使用 HTML5 標準。

這是啟動宣告。

沒有它，瀏覽器可能會用較舊或不穩定的方式解析頁面。

`<html>`

<html lang="zh-TW">
</html>

<html> 是整份文件的根元素。

lang="zh-TW" 表示頁面主要語言是繁體中文。

這對搜尋引擎、翻譯工具與輔助閱讀器都有幫助。

`<head>`

<head>
  <meta charset="utf-8">
  <title>頁面標題</title>
</head>

<head> 裡放的是頁面設定。

這些內容通常不會直接顯示在畫面上。

常見用途包括：

設定文字編碼
設定頁面標題
設定手機版顯示方式
引入 CSS
設定 SEO 描述
設定網站 icon

`<body>`

<body>
  <h1>標題</h1>
  <p>段落</p>
</body>

<body> 裡放的是使用者真正看得到的內容。

HTML5 小貓娘會在這裡安排主要頁面結構。

5. 標籤 tag 是什麼？

HTML 使用標籤描述內容。

一個常見標籤長這樣：

<p>這是一段文字</p>

其中：

部分	說明
`<p>`	開始標籤
`這是一段文字`	內容
`</p>`	結束標籤

可以理解為：

HTML5 小貓娘打開一個盒子，放入內容，然後把盒子關上。

6. 常用標籤

標題

<h1>主標題</h1>
<h2>副標題</h2>
<h3>小標題</h3>

標題用來建立文章層級。

一般建議一個頁面只使用一個 <h1>。

段落

<p>這是一段正文內容。</p>

段落用來放主要文字。

如果只是普通文章內容，應該使用 ，不要用大量   強行換行。

連結

<a href="https://example.com">前往 example</a>

<a> 是連結標籤。

href 是連結目標。

如果想在新分頁開啟，可以寫：

<a href="https://example.com" target="_blank" rel="noopener noreferrer">
  開啟新分頁
</a>

這是一扇通往其他頁面的門。

圖片

<img src="./h.jpg" alt="HTML5 小貓娘">

src 是圖片位置。

alt 是圖片說明。

如果圖片載入失敗，或使用者使用螢幕閱讀器，alt 會提供必要資訊。

因此，alt 不是裝飾。

它是輔助資訊。

列表

無序列表：

<ul>
  <li>HTML</li>
  <li>CSS</li>
  <li>JavaScript</li>
</ul>

有序列表：

<ol>
  <li>建立 HTML 文件</li>
  <li>加入 CSS 樣式</li>
  <li>加入 JavaScript 互動</li>
</ol>

如果內容有順序，使用 <ol>。

如果只是項目集合，使用 <ul>。

7. 屬性 attribute

屬性用來補充標籤設定。

例如：

<a href="https://example.com" target="_blank">連結</a>

其中：

屬性	用途
`href`	設定連結目標
`target`	設定開啟方式

屬性的格式是：

屬性名稱="屬性值"

HTML5 小貓娘的判斷如下：

標籤決定這是什麼。
屬性決定它如何運作。

8. HTML5 語義化標籤

HTML5 不只是把內容放到頁面上。

它還要求內容具有語義。

常見語義化標籤如下：

標籤	用途
`<header>`	頁首或區塊開頭
`<nav>`	導覽列
`<main>`	頁面主要內容
`<article>`	獨立文章
`<section>`	主題區塊
`<aside>`	側邊資訊
`<footer>`	頁尾

範例：

<header>
  <h1>HTML5 小貓娘資料庫</h1>
</header>

<nav>
  <a href="/">首頁</a>
  <a href="/posts/">文章</a>
</nav>

<main>
  <article>
    <h2>HTML5 是什麼？</h2>
    <p>HTML5 是用來建立網頁結構的標記語言。</p>
  </article>
</main>

<footer>
  <p>任務完成。</p>
</footer>

這種寫法比全部使用 <div> 更清楚。

因為瀏覽器、搜尋引擎與輔助工具都能理解頁面結構。

9. 表格

表格適合呈現資料。

<table>
  <thead>
    <tr>
      <th>標籤</th>
      <th>用途</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>&lt;p&gt;</td>
      <td>段落</td>
    </tr>
    <tr>
      <td>&lt;a&gt;</td>
      <td>連結</td>
    </tr>
  </tbody>
</table>

注意：

表格用於資料，不應用於整站排版。

整站排版應交給 CSS。

10. 表單

表單用於收集使用者輸入。

<form>
  <label for="name">名字</label>
  <input id="name" name="name" type="text">

  <label for="message">留言</label>
  <textarea id="message" name="message"></textarea>

  <button type="submit">送出</button>
</form>

表單中的關鍵元素：

元素	用途
`<form>`	表單容器
`<label>`	輸入說明
`<input>`	單行輸入
`<textarea>`	多行輸入
`<button>`	按鈕

label 的 for 應該對應輸入框的 id。

這樣可用性更好，也更符合無障礙設計。

11. 多媒體

HTML5 支援原生音訊與影片。

影片

<video controls width="640">
  <source src="demo.mp4" type="video/mp4">
  你的瀏覽器不支援 video 標籤。
</video>

音訊

<audio controls>
  <source src="demo.mp3" type="audio/mpeg">
  你的瀏覽器不支援 audio 標籤。
</audio>

controls 會顯示播放、暫停、音量等控制器。

12. 如何使用 HTML5

步驟一：建立檔案

建立一個檔案：

index.html

步驟二：寫入基本結構

<!doctype html>
<html lang="zh-TW">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>我的頁面</title>
  </head>
  <body>
    <h1>我的第一個網頁</h1>
    <p>這是 HTML5 建立的內容。</p>
  </body>
</html>

步驟三：用瀏覽器開啟

你可以直接雙擊 index.html。

也可以用 VS Code 的 Live Server 插件開啟。

步驟四：加入 CSS

<link rel="stylesheet" href="./style.css">

然後建立：

style.css

寫入：

body {
  font-family: system-ui, sans-serif;
  background: #f7fbff;
  color: #1f2937;
}

步驟五：加入 JavaScript

<script src="./main.js"></script>

然後建立：

main.js

寫入：

console.log('HTML5 小貓娘已啟動。');

13. 一個完整示例

<!doctype html>
<html lang="zh-TW">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>HTML5 小貓娘</title>
    <style>
      body {
        margin: 0;
        font-family: system-ui, sans-serif;
        background: #eef6ff;
        color: #172554;
      }

      main {
        max-width: 760px;
        margin: auto;
        padding: 48px 20px;
      }

      article {
        padding: 28px;
        border-radius: 24px;
        background: white;
        box-shadow: 0 20px 60px rgba(37, 99, 235, 0.16);
      }

      .tag {
        display: inline-block;
        padding: 4px 10px;
        border-radius: 999px;
        background: #dbeafe;
        color: #1d4ed8;
        font-weight: 700;
      }

      button {
        border: 0;
        border-radius: 999px;
        padding: 12px 18px;
        background: #2563eb;
        color: white;
        font-weight: 700;
        cursor: pointer;
      }
    </style>
  </head>
  <body>
    <main>
      <article>
        <span class="tag">HTML5 Catgirl</span>
        <h1>你好，我是 HTML5 小貓娘</h1>
        <p>我的任務是建立清楚、可讀、可解析的網頁結構。</p>
        <button onclick="alert('任務確認：HTML5 小貓娘已啟動。')">
          啟動
        </button>
      </article>
    </main>
  </body>
</html>

14. 常見錯誤

錯誤一：忘記結束標籤

錯誤：

<p>這是一段文字

正確：

<p>這是一段文字</p>

錯誤二：圖片沒有 `alt`

不建議：

<img src="./h.jpg">

建議：

<img src="./h.jpg" alt="HTML5 小貓娘">

錯誤三：標題層級混亂

不建議：

<h1>主標題</h1>
<h4>突然出現的副標題</h4>

建議：

<h1>主標題</h1>
<h2>副標題</h2>
<h3>更細的段落標題</h3>

錯誤四：用 HTML 負責樣式

HTML 負責結構。

CSS 負責樣式。

JavaScript 負責行為。

不要把所有職責都交給 HTML。

HTML5 小貓娘會因此陷入職責混亂。

15. 學習路線

推薦順序如下：

學會基本文件結構
學會標題、段落、連結、圖片
學會列表與表格
學會表單
學會語義化標籤
學會引入 CSS
學會引入 JavaScript
嘗試建立完整小頁面

這不是必須一次完成的義務。

逐步執行即可。

16. 結語

HTML5 小貓娘不是負責炫技的存在。

她的核心任務，是建立清楚、穩定、可理解的網頁結構。

她會將內容放入正確的標籤中。

讓瀏覽器理解。

讓搜尋引擎理解。

讓輔助工具理解。

也讓未來的你理解。

這就是 HTML5 的意義。

任務記錄完畢。

如果你再次遺忘 HTML5 的使用方式，也沒有問題。

本頁會再次作為鑰匙，協助你打開 Web 的入口。

ai桌寵

Mon, 30 Dec 2024 00:00:00 GMT

~~做這個的想法其實是這樣的，做一個ai桌寵。~~ （滑稽）

开发顺序如下：Live2D动画 → 语音系统 → 对话框UI → AI对话 → 系统集成。

1.1.0版本

desktop_pet/ ├── app/ # 主程序入口 .. │ ├── init.py │ └── main.py # 程序启动入口 ├── ai_engine/ # AI逻辑处理层 .. │ ├── api_clients/ # 云端API处理 │ │ └── deepseek_api.py │ ├── local_llm/ # 本地模型管理 │ │ ├── model_loader.py │ │ └── prompt_manager.py │ └── intent_parser.py # 用户意图解析 ├── animation_system/ # Live2D控制 .. │ ├── model_controller/
│ │ ├── cubism_binder.py # 参数绑定系统 │ │ └── motion_scheduler.py # 动作队列管理 │ └── runtime/ # 实时渲染 │ ├── gl_window.py # OpenGL窗口 │ + ├── physics/ # 拆分为物理子系统 + │ ├── legacy_physics.py # 原有物理实现 + │ ├── taichi_physics.py # Taichi物理引擎 + ├── render_pipeline.py # 新增渲染管线管理 └── physics.py → 废弃 ├── voice_system/ # 语音生成模块 .. │ ├── training/ # 语音训练相关 │ │ ├── dataset_preprocess.py │ │ └── finetune_vits.py │ └── runtime/ │ ├── tts_server.py # TTS服务 │ └── voice_cache.py # 语音缓存 ├── gui/ # 用户界面 .. │ ├── components/ # 可复用部件 │ │ ├── chat_bubble.py # 对话框组件 │ │ └── system_tray.py # 系统托盘控制 │ └── themes/ # 界面主题管理 │ ├── default_theme.json │ └── theme_loader.py ├── system_hooks/ # 系统级交互 .. │ ├── command_executor/ │ │ ├── windows_cmd.py # Windows命令实现 │ │ └── linux_cmd.py # Linux实现 │ └── security/ # 安全模块 │ ├── permission_check.py │ └── command_whitelist.yaml ├── assets/ # 静态资源 .. │ ├── live2d_models/
│ │ └── shizuku/ # 示例模型 │ │ ├── model3.json │ │ ├── textures/ │ │ └── motions/ │ ├── voices/ │ │ ├── xiaolu/ # 语音包资源 │ │ │ ├── wavs/ │ │ │ └── config.json │ └── icons/ # 程序图标 ├── configs/ # 配置文件 │ ├── app_config.yaml # 主配置文件 │ └── key_bindings.yaml # 快捷键配置 └── tests/ # 测试模块 ├── unit_tests/ # 单元测试 └── integration_tests/# 集成测试

1.2.6细化版本

desktop_pet/ ├──app/ # 应用核心 │ ├── init.py │ ├── bootstrap.py # 系统初始化入口 │ ├── context.py # 运行时上下文管理 │ ├── event_system/ # 事件管理系统 │ │ ├── bus.py # 事件总线实现 │ │ ├── protocols.py # 事件协议定义 │ │ └── decorators.py # 事件监听装饰器 │ ├── lifecycle/ # 生命周期管理 │ │ ├── init_sequence.py # 初始化流程控制 │ │ ├── state_machine.py # 应用状态机 │ │ └── recovery.py # 崩溃恢复机制 │ ├── configuration/ # 配置子系统 │ │ ├── loader.py # 多格式配置加载 │ │ ├── hot_reload.py # 配置热更新 │ │ └── validators/ # 配置验证 │ │ ├── schema.yaml # 配置数据结构定义 │ │ └── type_check.py │ ├── dependency_injection/ # 依赖注入系统 │ │ ├── container.py # IoC容器 │ │ └── providers.py # 服务提供者 │ ├── exception_handling/ # 异常处理系统 │ │ ├── logger_setup.py # 结构化日志配置 │ │ ├── sentry_integration.py # 错误监控 │ │ └── graceful_fallback.py # 安全回退 │ ├── interfaces/ # 抽象接口定义 │ │ ├── ai_service.py # AI服务合约 │ │ ├── animation_engine.py # 动画引擎合约 │ │ └── voice_system.py # 语音系统合约 │ └── utilities/ # 工具类 │ ├── perf_monitor.py # 性能监控 │ └── resource_helper.py # 资源管理 │ ├── ai/ # AI子系统 │ ├── dialogue/ # 对话管理 │ │ ├── core/
| │ │ ├── chat_manager.py # 对话流协调器 | │ │ └── history.py # 对话记忆管理 │ ├── providers/ # AI服务提供方 │ │ ├── deepseek/
│ │ │ ├── api_client.py # 深度求索API交互 │ │ │ ├── persona_engine.py # 角色人设引擎 │ │ │ └── rate_limiter.py # 流量控制 │ │ └── local/
│ │ ├── model_loader.py # 本地模型加载器 │ │ ├── quantized/ # 量化模型库 │ │ │ └── codeqwen-4bit.safetensors │ │ └── optim/ # 推理优化 │ │ ├── vllm_engine.py
│ │ └── llama_cpp.py │ ├── processing/ # 对话处理模块 │ │ ├── intent_parser.py
│ │ ├── emotion_analyzer.py
│ │ └── safety_check.py # 内容安全检查 │ └── resources/ # 资源文件 │ ├── persona_profiles/ # 角色设定库 │ │ ├── academic_mentor.json │ │ └── playful_cat.json │ └── prompts/ # 提示语模板 │ ├── system_prompt.j2 │ └── error_phrases.yaml
├── animation/ # 动画引擎 │ ├── live2d/ # Live2D核心 │ │ ├── cubism_sdk/ # Cubism封装 │ │ │ ├── model_loader.py │ │ │ └── param_mapper.py │ │ ├── motion/ # 动作管理 │ │ │ ├── scheduler.py │ │ │ └── blending.py # 动作混合 │ └── physics/ # 物理系统 │ ├── core.py # 统一接口 │ ├── taichi/ # GPU加速 │ │ ├── xpbd_solver.py │ │ └── hair_sim.py │ └── verlet/ # CPU回退 │ └── constraints.py ├── voice/ # 语音系统 │ ├── synthesis/ # 语音生成 │ │ ├── vits/ # VITS引擎 │ │ │ ├── custom_voice/ # 用户语音包 │ │ │ │ ├── config.json │ │ │ │ └── waveform/ │ │ │ └── realtime.py │ │ └── tts_apis/ # 云端TTS │ └── deepseek_tts.py │ └── recognition/ # 语音识别 │ ├── vad.py # 语音检测 │ └── stt_engine.py ├── ui/ # 用户界面 │ ├── widgets/ # 定制组件 │ │ ├── chat/ # 对话框系统 │ │ │ ├── bubble.py # 半透明气泡 │ │ │ ├── history.py # 聊天记录 │ │ │ └── input_box.py │ │ └── avatar_window.py # 桌宠主窗口 │ ├── style/ # 样式管理 │ │ ├── theme_engine.py # 动态换肤 │ │ └── effects/ # 特效 │ └── acrylic.py # 亚克力效果 │ └── tray_icon/ # 系统托盘 │ ├── menu.py │ └── indicators.py # 状态指示 ├── system/ # 系统交互 │ ├── command/ # 命令执行 │ │ ├── win/ # Windows实现 │ │ │ ├── shell_exec.py │ │ │ └── task_scheduler.py │ │ ├── linux/ # Linux实现 │ │ └── validator.py # 命令验证 │ ├── monitor/ # 系统监控 │ │ ├── resource_tracker.py │ │ └── triggers.py # 事件触发 │ └── security/ # 安全模块 │ ├── sandbox.py # 沙箱机制 │ └── whitelist.yaml ├── resources/ # 项目资源 │ ├── characters/ # 角色资产 │ │ └── shizuku/ # 示例角色 │ │ ├── model.json # Live2D模型 │ │ ├── textures/ │ │ ├── motions/ # 动作资源 │ │ └── physics/ # 物理配置 │ ├── voices/ # 语音资产 │ │ ├── default/ │ │ └── custom/ │ ├── icons/ # 图标资源 │ └── locales/ # 本地化文件 ├── platform/ # 平台适配 │ ├── windows/ # Win特性 │ │ ├── dwm.py # 透明效果 │ │ └── taskbar.py │ └── linux/ # Linux特性 │ ├── x11/ │ └── systemd/ ├── config/ # 配置管理 │ ├── app.yaml # 主配置 │ ├── keys.yaml # 快捷键 │ └── presets/ # 预设配置 │ ├── physics/ # 物理预设 │ └── themes/ # 界面主题 ├── tests/ # 测试体系 │ ├── unit/ # 单元测试 │ │ ├── test_animation.py │ │ └── test_ai_response.py │ └── integration/ # 集成测试 │ └── test_voice_sync.py ├── tools/ # 开发工具 │ ├── model_tools/ # 模型处理 │ │ ├── converter.py # 格式转换 │ │ └── optimizer.py # 模型优化 │ └── voice_training/ # 语音训练 ├── scripts/ # 自动化脚本 │ ├── build.ps1 # Windows构建 │ ├── setup.sh # Linux安装 │ └── deploy_macos.sh └── docs/ # 文档 ├── dev_guide.md # 开发指南 └── api_reference/ # API文档

框架特性：

1.量子化事件系统
使用异步队列实现高效消息传递
支持100,000+ TPS的事件吞吐
2.状态即服务：
通过Checkpointer实现任意时间点状态回滚
支持压缩快照存储（平均10KB/次）

实现关键指标：

端到端延迟：<1.5秒（云端模式），<3秒（本地模式）
角色切换响应时间：<300ms
意图识别准确率：94.2%（混合方法）
情感检测F1分数：0.87
支持同时运行3种量化级别的本地模型
API请求自动重试（3次指数回退）
本地模型内存开销优化40%

animation模块解析

animation目录结构 animation数据流结构图

1.3.0细化版本

desktop_pet/ │ ├── 01.应用内核 (app_core) │ ├── app/ │ │ ├── bootstrap.py # 系统冷启动入口(CUDA初始化/异常处理框架加载) │ │ ├── dependency_injection/ │ │ │ ├── init.py │ │ │ ├── container.py # IoC容器(支持动态服务注册) │ │ │ └── annotations.py # 依赖注入语法糖(@Service/@Inject) │ │ ├── event_system/ │ │ │ ├── core/ # 事件中枢(Redis/NATS后端可选) │ │ │ │ ├── event_bus.py # 消息队列接口抽象 │ │ │ │ └── zmq_impl/ # ZeroMQ高性能实现 │ │ │ ├── schemas/ # Protobuf事件格式定义 │ │ │ │ └── animation_events.proto │ │ │ └── middleware/ # 事件处理中间件 │ │ │ ├── logging_middleware.py │ │ │ └── validation_middleware.py │ │ ├── lifecycle/ │ │ │ ├── init_stages.yaml # 启动阶段定义(并行/串行步骤配置) │ │ │ ├── state_machine/ │ │ │ │ ├── state_nodes.py # 状态节点基类 │ │ │ │ └── transitions/ # 状态转移逻辑 │ │ │ └── recovery/ │ │ │ ├── crash_dumps/ # 崩溃现场存储目录 │ │ │ └── state_restore.py │ │ └── interfaces/ # 抽象接口 │ │ ├── ISystemMonitor.py │ │ └── IHardwareScheduler.py │ │ │ └── config/ # 多层配置系统 │ ├── base.yaml # 基础默认配置 │ ├── dev.yaml # 开发环境覆盖配置 │ ├── prod.yaml # 生产环境覆盖配置 │ ├── secrets/ # 分级密钥管理 │ │ ├── vault.key # 主密钥文件(需外部注入) │ │ └── encrypted/ │ │ └── api_keys.secret │ └── validators/ # 配置验证逻辑 │ ├── schema_validator.py │ └── type_checkers.py │ ├── 02.智能系统 (ai_modules) │ ├── cognition/ │ │ ├── core/ # 认知计算中枢 │ │ │ ├── WorkingMemory.py # 记忆管理系统(带LRU缓存) │ │ │ ├── ReasoningEngine.py # Datalog推理引擎实现 │ │ │ └── GoalSystem/ │ │ │ ├── priority_queue.py # 目标优先级调度器 │ │ │ └── MotiveGenerator.py # 动机生成器(基于时序状态) │ │ └── knowledge/ # 知识系统模块 │ │ ├── ontology/ # 领域本体库 │ │ │ ├── time_ontology.ttl # 时间概念本体 │ │ └── fact_database.sqlite # 动态事实存储 │ │ │ ├── emotion/ # 情感计算子系统 │ │ ├── emotion_model.py # PAD三维情绪空间计算 │ │ ├── MoodEngine.py # 情绪波动引擎(马尔可夫链模型) │ │ └── influence/ # 环境因素影响系统 │ │ ├── sensor_impact.py # 传感器输入对情绪影响 │ │ └── dialogue_impact.py # 对话内容情绪影响 │ │ │ └── dialog/ # 对话管理子系统 │ ├── pipelines/ # 多级处理流水线 │ │ ├── input_processing/ # 输入处理阶段 │ │ │ ├── cleanser.py # 语料清洗 │ │ │ └── intent_detect.py │ │ ├── core_processing/ # 核心处理阶段 │ │ │ └── response_generator.py │ │ └── post_processing/ # 输出后处理 │ │ ├── emotion_injector.py # 情感语气注入 │ ├── agent/ # 对话agent │ │ ├── DeepSeekAgent.py # 深度求索专用代理 │ │ └── HuggingFaceAgent.py │ └── resources/ # NLU资源库 │ ├── intents.yaml # 意图定义集 │ └── ner_patterns/ # 实体识别规则 │ ├── 03.物理表现层 (physic_engine) │ ├── live2d/ # Live2D核心实现 │ │ ├── cubism_sdk/ │ │ │ ├── native/ # SDK原生库 │ │ │ │ ├── win_x64/ │ │ │ │ └── linux_x64/ │ │ │ └── Core.py # Python绑定入口 │ │ ├── model_loader.py # 模型加载器(支持热重载) │ │ ├── param_mappers/ # 参数映射系统 │ │ │ ├── default_mapper.py # Cubism标准参数 │ │ │ └── custom_mappers/ # 用户自定义映射 │ │ └── motion/ # 动作管理系统 │ │ ├── motion_scheduler.py # 动作编排调度器 │ │ └── effect_chains/ # 复合动作特效 │ │ └── rain_effect.py # 示例-下雨时护头动作 │ │ │ └── physics/ # 物理子系统 │ ├── solvers/ # 物理求解器 │ │ ├── taichi/ # Taichi后端 │ │ │ ├── XPBD_solver.py # 位置动力学求解器 │ │ │ └── soft_body.py # 半隐式柔体仿真 │ └── cache_system/ # 物理状态缓存 │ ├── prebake_tool.py # 预烘焙工具 │ └── playback.py # 缓存回放引擎 │ ├── 04.人机交互层 (interaction) │ ├── voice/ # 语音交互系统 │ │ ├── synthesis/ │ │ │ ├── VITS/ # 本地语音生成 │ │ │ │ ├── core/ # VITS核心模型 │ │ │ │ ├── realtime.py # 流式生成接口 │ │ │ │ └── profiles/ # 发声风格配置 │ │ │ └── cloud_apis/ # 云TTS接口 │ │ │ └── deepseek_tts.py │ │ └── recognition/ │ │ ├── stream_asr.py # 流式语音识别 │ │ └── context_manager.py # 环境噪声适配 │ │ │ └── visualization/ # 视觉呈现系统 │ ├── rendering/ │ │ ├── OpenGL/ # OpenGL渲染后端 │ │ │ ├── shaders/ # GLSL着色器库 │ │ │ │ └── subsurface_scattering.glsl # 次表面散射 │ │ └── DirectX/ # DirectX 12后端 │ ├── gaze_tracking/ # 视线追踪系统 │ │ ├── eye_detector.py # 基于MediaPipe的实现 │ │ └── attention_model.py # 注意力持续时间预测 │ └── ui_component/ # 交互式UI元素 │ ├── charm_window.py # 主角色窗口 │ └── command_palette.py # 浮动指令面板 │ ├── 05.资源与设施 (resources_infra) │ ├── characters/ # 角色资源仓库 │ │ ├── base_character/ # 基准角色模型 │ │ │ ├── model3.json # Cubism模型定义 │ │ │ ├── textures/ # 分层贴图系统 │ │ │ │ ├── base/ │ │ │ │ │ └── skin_base.png │ │ │ │ └── costumes/ # 换衣系统 │ │ │ │ └── summer_outfit/ │ │ │ │ ├── diffuse.png │ │ │ │ └── normal_map.png │ │ │ └── motions/ # 动作资源库 │ │ │ ├── idle/ # 待机动作集 │ │ │ │ └── breathing.mtn3 # Motion3格式 │ │ │ └── reactive/ # 交互响应动作 │ │ └── community/ # 用户生成内容 │ │ └── approval_process/ # UGC审核流程 │ │ ├── content_validator.py │ │ └── license_checker.py │ │ │ ├── ai_models/ # AI模型仓库 │ │ ├── quantized/ # 量化模型 │ │ │ └── codeqwen-4.5b-awq.safetensors │ │ └── embeddings/ # 嵌入向量库 │ │ ├── text_embeds/ # 文本嵌入 │ │ └── emotion_embeds/ # 情绪分类专用 │ │ │ └── voice_library/ # 多语种音库 │ ├── Chinese/ # 中文语音 │ │ └── multiple_speakers.yaml # 发音人元数据 │ └── Japanese/ ├── 06.开发者工具 (dev_tools) │ ├── model_converter/ # 模型转换套件 │ │ ├── transform_scripts/ # 格式转换脚本 │ │ │ ├── pt_to_gguf.py # PyTorch => GGUF │ │ │ └── keras_to_ort.py # Keras => ONNX Runtime │ │ └── quantization/ # 量化工具 │ │ ├── quantize_ggml.py # GGML量化器 │ │ └── fp8_converter.py # FP8转化实验 │ │ │ └── automations/ # 开发辅助工具 │ ├── cache_invalidator.py # 构建缓存清除 │ └── dependency_graph.py # 模块依赖可视化 │ └── 07.合规与运维 (deploy_ops) ├── packaging/ # 多平台打包配置 │ ├── NSIS/ # Windows安装包脚本 │ │ └── desktop_pet.nsi │ ├── AppImage/ # Linux打包配置 │ │ └── desktop_pet.appdata.xml │ └── codesign/ # 代码签名证书 ├── monitoring/ # 生产监控 │ ├── prometheus/ # 指标采集 │ │ └── custom_metrics.py │ └── sentry/ # 错误追踪配置 │ └── sentry_conf.yaml └── legal/ # 法律合规性 ├── licenses/ # 第三方许可证 └── privacy_policy.md # GDPR合规政策

1.3.3细化版本

desktop_pet/ │ ├── app_core #主系统 │ ├── app/ │ │ ├── bootstrap.py # 系统冷启动入口(CUDA初始化/异常处理框架加载) │ │ ├── dependency_injection/ │ │ │ ├── init.py │ │ │ ├── container.py # IoC容器(支持动态服务注册) │ │ │ └── annotations.py # 依赖注入语法糖(@Service/@Inject) │ │ ├── event_system/ │ │ │ ├── core/ # 事件中枢(Redis/NATS后端可选) │ │ │ │ ├── event_bus.py # 消息队列接口抽象 │ │ │ │ └── zmq_impl/ # ZeroMQ高性能实现 │ │ │ ├── schemas/ # Protobuf事件格式定义 │ │ │ │ └── animation_events.proto │ │ │ └── middleware/ # 事件处理中间件 │ │ │ ├── logging_middleware.py │ │ │ └── validation_middleware.py │ │ ├── lifecycle/ │ │ │ ├── init_stages.yaml # 启动阶段定义(并行/串行步骤配置) │ │ │ ├── state_machine/ │ │ │ │ ├── state_nodes.py # 状态节点基类 │ │ │ │ └── transitions/ # 状态转移逻辑 │ │ │ └── recovery/ │ │ │ ├── crash_dumps/ # 崩溃现场存储目录 │ │ │ └── state_restore.py │ │ └── interfaces/ # 抽象接口 │ │ ├── ISystemMonitor.py │ │ └── IHardwareScheduler.py │ │ │ └── config/ # 多层配置系统 │ ├── base.yaml # 基础默认配置 │ ├── dev.yaml # 开发环境覆盖配置 │ ├── prod.yaml # 生产环境覆盖配置 │ ├── secrets/ # 分级密钥管理 │ │ ├── vault.key # 主密钥文件(需外部注入) │ │ └── encrypted/ │ │ └── api_keys.secret │ └── validators/ # 配置验证逻辑 │ ├── schema_validator.py │ └── type_checkers.py │ ├── ai_modules # AI子系统（智能系统） │ ├── cognition/ │ │ ├── core/ # 认知计算中枢 │ │ │ ├── WorkingMemory.py # 记忆管理系统(带LRU缓存) │ │ │ ├── ReasoningEngine.py # Datalog推理引擎实现 │ │ │ └── GoalSystem/ │ │ │ ├── priority_queue.py # 目标优先级调度器 │ │ │ └── MotiveGenerator.py # 动机生成器(基于时序状态) │ │ └── knowledge/ # 知识系统模块 │ │ ├── ontology/ # 领域本体库 │ │ │ ├── time_ontology.ttl # 时间概念本体 │ │ └── fact_database.sqlite # 动态事实存储 │ │ │ ├── emotion/ # 情感计算子系统 │ │ ├── emotion_model.py # PAD三维情绪空间计算 │ │ ├── MoodEngine.py # 情绪波动引擎(马尔可夫链模型) │ │ └── influence/ # 环境因素影响系统 │ │ ├── sensor_impact.py # 传感器输入对情绪影响 │ │ └── dialogue_impact.py # 对话内容情绪影响 │ │ │ └── dialog/ # 对话管理子系统 │ ├── pipelines/ # 多级处理流水线 │ │ ├── input_processing/ # 输入处理阶段 │ │ │ ├── cleanser.py # 语料清洗 │ │ │ └── intent_detect.py │ │ ├── core_processing/ # 核心处理阶段 │ │ │ └── response_generator.py │ │ └── post_processing/ # 输出后处理 │ │ ├── emotion_injector.py # 情感语气注入 │ ├── agent/ # 对话agent │ │ ├── DeepSeekAgent.py # 深度求索专用代理 │ │ └── HuggingFaceAgent.py │ └── resources/ # NLU资源库 │ ├── intents.yaml # 意图定义集 │ └── ner_patterns/ # 实体识别规则 │ ├── physic_engine # live2d动画物理引擎 │ ├── live2d/ # Live2D核心实现 │ │ ├── cubism_sdk/ │ │ │ ├── native/ # SDK原生库 │ │ │ │ ├── win_x64/ │ │ │ │ └── linux_x64/ │ │ │ └── Core.py # Python绑定入口 │ │ ├── model_loader.py # 模型加载器(支持热重载) │ │ ├── param_mappers/ # 参数映射系统 │ │ │ ├── default_mapper.py # Cubism标准参数 │ │ │ └── custom_mappers/ # 用户自定义映射 │ │ └── motion/ # 动作管理系统 │ │ ├── motion_scheduler.py # 动作编排调度器 │ │ └── effect_chains/ # 复合动作特效 │ │ └── rain_effect.py # 示例-下雨时护头动作 │ │ │ └── physics/ # 物理子系统 │ ├── solvers/ # 物理求解器 │ │ ├── taichi/ # Taichi后端 │ │ │ ├── XPBD_solver.py # 位置动力学求解器 │ │ │ └── soft_body.py # 半隐式柔体仿真 │ └── cache_system/ # 物理状态缓存 │ ├── prebake_tool.py # 预烘焙工具 │ └── playback.py # 缓存回放引擎 │ ├── interaction # 人机交互 │ ├── voice/ # 语音交互系统 │ │ ├── synthesis/ │ │ │ ├── VITS/ # 本地语音生成 │ │ │ │ ├── core/ # VITS核心模型 │ │ │ │ ├── realtime.py # 流式生成接口 │ │ │ │ └── profiles/ # 发声风格配置 │ │ │ └── cloud_apis/ # 云TTS接口 │ │ │ └── deepseek_tts.py │ │ └── recognition/ │ │ ├── stream_asr.py # 流式语音识别 │ │ └── context_manager.py # 环境噪声适配 │ │ │ └── visualization/ # 视觉呈现系统 │ ├── rendering/ │ │ ├── OpenGL/ # OpenGL渲染后端 │ │ │ ├── shaders/ # GLSL着色器库 │ │ │ │ └── subsurface_scattering.glsl # 次表面散射 │ │ └── DirectX/ # DirectX 12后端 │ ├── gaze_tracking/ # 视线追踪系统 │ │ ├── eye_detector.py # 基于MediaPipe的实现 │ │ └── attention_model.py # 注意力持续时间预测 │ └── ui_component/ # 交互式UI元素 │ ├── charm_window.py # 主角色窗口 │ └── command_palette.py # 浮动指令面板 │ ├── resources_infra #模型资源与设施 │ ├── characters/ # 角色资源仓库 │ │ ├── base_character/ # 基准角色模型 │ │ │ ├── model3.json # Cubism模型定义 │ │ │ ├── textures/ # 分层贴图系统 │ │ │ │ ├── base/ │ │ │ │ │ └── skin_base.png │ │ │ │ └── costumes/ # 换衣系统 │ │ │ │ └── summer_outfit/ │ │ │ │ ├── diffuse.png │ │ │ │ └── normal_map.png │ │ │ └── motions/ # 动作资源库 │ │ │ ├── idle/ # 待机动作集 │ │ │ │ └── breathing.mtn3 # Motion3格式 │ │ │ └── reactive/ # 交互响应动作 │ │ └── community/ # 用户生成内容 │ │ └── approval_process/ # UGC审核流程 │ │ ├── content_validator.py │ │ └── license_checker.py │ │ │ ├── ai_models/ # AI模型仓库 │ │ ├── quantized/ # 量化模型 │ │ │ └── codeqwen-4.5b-awq.safetensors │ │ └── embeddings/ # 嵌入向量库 │ │ ├── text_embeds/ # 文本嵌入 │ │ └── emotion_embeds/ # 情绪分类专用 │ │ │ └── voice_library/ # 多语种音库 │ ├── Chinese/ # 中文语音 │ │ └── multiple_speakers.yaml # 发音人元数据 │ └─ English ├── dev_tools # 辅助开发（开发者工具） │ ├── model_converter/ # 模型转换套件 │ │ ├── transform_scripts/ # 格式转换脚本 │ │ │ ├── pt_to_gguf.py # PyTorch => GGUF │ │ │ └── keras_to_ort.py # Keras => ONNX Runtime │ │ └── quantization/ # 量化工具 │ │ ├── quantize_ggml.py # GGML量化器 │ │ └── fp8_converter.py # FP8转化实验 │ │ │ └── automations/ # 开发辅助工具 │ ├── cache_invalidator.py # 构建缓存清除 │ └── dependency_graph.py # 模块依赖可视化 │ └── deploy_ops #合规运维 ├── packaging/ # 多平台打包配置 │ ├── NSIS/ # Windows安装包脚本 │ │ └── desktop_pet.nsi │ ├── AppImage/ # Linux打包配置 │ │ └── desktop_pet.appdata.xml │ └── codesign/ # 代码签名证书 ├── monitoring/ # 生产监控 │ ├── prometheus/ # 指标采集 │ │ └── custom_metrics.py │ └── sentry/ # 错误追踪配置 │ └── sentry_conf.yaml └── legal/ # 法律合规性 ├── licenses/ # 第三方许可证 └── privacy_policy.md # GDPR合规政策

powershell中的命令使用

1 基本环境准备

# 新建项目目录并初始化结构
$projectRoot = "E:\DesktopPet"
New-Item -Path $projectRoot -ItemType Directory
Set-Location $projectRoot

# 初始化基本目录
$dirs = @(
    'app_core/app/dependency_injection',
    'app_core/config/secrets/encrypted',
    'ai_modules/cognition/knowledge/ontology',
    'physic_engine/live2d/cubism_sdk/native/win_x64',
    'interaction/voice/synthesis/VITS/profiles',
    'resources_infra/characters/base_character/textures/costumes',
    'deploy_ops/packaging/NSIS'
)

$dirs | ForEach-Object { New-Item -Path $_ -ItemType Directory -Force }

# 创建基本文件
@(
    'app_core/app/bootstrap.py',
    'app_core/config/base.yaml',
    'resources_infra/ai_models/quantized/placeholder.txt'
) | ForEach-Object { New-Item -Path $_ -ItemType File }

# 初始化git仓库
git init
echo "/secrets/" > .gitignore
echo "/resources_infra/ai_models/*" >> .gitignore
echo "/physic_engine/live2d/cubism_sdk/native/**/CubismCore.dll" >> .gitignore

python环境配置

# 创建虚拟环境
python -m venv .venv
.\.venv\Scripts\Activate.ps1

# 安装核心依赖
$requirements = @"
torch==2.1.0+cu118
torchaudio==2.1.0+cu118
torchvision==0.16.0+cu118
taichi>=1.6.0
protobuf
pyzmq
python-dotenv
cryptography
rich
"@

$requirements | Out-File -Encoding utf8 requirements.txt
pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

# Windows专用依赖
if ($env:OS -eq 'Windows_NT') {
    pip install pywin32 pypiwin32 -i https://pypi.tuna.tsinghua.edu.cn/simple
}

Linux 命令幫助資訊

Mon, 30 Dec 2024 00:00:00 GMT

Linux 命令幫助資訊

本頁面的存在目的，是協助使用者在 Linux 系統中查詢命令、理解參數、確認工具來源，並在遺忘時重新取得必要資訊。

換言之，這是一份終端機內部的「鑰匙清單」。

當你忘記一個命令怎麼用、某個參數代表什麼、設定檔位於何處，或者只是想確認某個工具是否存在時，無需立刻向外部搜尋系統求助。

Linux 本身已經留下了足夠的提示。

只要依序啟動這些鑰匙，就能打開對應的門。

0. 本頁任務

本頁會整理以下 Linux 命令幫助工具：

help
--help
man
info
whatis
apropos
type
which
whereis

它們並不是彼此替代的存在。

它們各自負責不同的查詢義務。

我會逐一說明它們的用途、使用方式，以及適合啟動的時機。

1. 快速總覽

工具	主要用途	適合情境	範例
`command --help`	顯示命令快速說明	想快速看參數	`ls --help`
`help`	顯示 Shell 內建命令說明	查 `cd`、`alias`、`export`	`help cd`
`man`	顯示完整手冊頁	查正式文件	`man ls`
`info`	顯示 GNU 詳細文件	深入學習 GNU 工具	`info coreutils`
`whatis`	用一句話描述命令	快速知道命令是什麼	`whatis grep`
`apropos`	根據關鍵字搜尋命令	忘記命令名稱	`apropos network`
`type`	判斷命令來源	確認命令是 alias、builtin 還是檔案	`type cd`
`which`	顯示可執行檔路徑	確認實際執行哪個程式	`which python`
`whereis`	搜尋命令相關檔案	找 binary、source、manual	`whereis bash`

2. 查詢命令前的基本判斷

在查詢一個命令之前，建議先確認它的存在形式。

執行：

type command

例如：

type cd
type ls
type python
type ll

可能得到的結果如下：

cd is a shell builtin
ls is aliased to `ls --color=auto`
python is /usr/bin/python
ll is aliased to `ls -alF`

這一步的意義是：先確認目標的身分。

若目標是 Shell 內建命令，應優先使用 help。

若目標是外部可執行檔，則可以使用 --help、man 或 info。

若目標是 alias，則需要先理解 alias 對應到哪個真正的命令。

這是第一把鑰匙。

3. 使用 `--help`

大多數 Linux 命令都支援 --help 參數。

它會輸出命令的基本語法、常用選項和簡短說明。

ls --help
cp --help
grep --help
tar --help

--help 的特性是快速。

當你只是忘記某個參數時，這通常是最有效率的查詢方式。

例如，想查詢 ls 與排序相關的參數：

ls --help | grep sort

若輸出內容過長，可以交給 less 分頁顯示：

ls --help | less

如果要搜尋特定關鍵字：

grep --help | grep color

此命令的存在意義相當明確：

快速確認參數，不必進入完整手冊。

4. 使用 `help`

help 用來查看 Shell 內建命令。

有些命令並不是外部程式，而是 Shell 自身的一部分。

例如：

cd
alias
export
echo
history
jobs
fg
bg
read
set
unset

這些命令更適合用 help 查詢：

help cd
help alias
help export
help history

如果想列出 Bash 內建命令，可以直接執行：

help

為什麼 `cd --help` 不一定可靠？

因為 cd 通常是 Shell builtin。

它的行為由目前使用的 Shell 決定，例如 Bash、Zsh、Fish 可能有不同細節。

所以查詢 cd 時，推薦流程是：

type cd
help cd

如果輸出顯示：

cd is a shell builtin

那就代表應該詢問 Shell，而不是尋找外部程式。

這是第二把鑰匙。

5. 使用 `man`

man 是 manual 的縮寫，也就是 Linux 的手冊頁系統。

基本用法：

man ls
man grep
man bash
man ssh

man 適合查詢正式文件。

它比 --help 更完整，通常會包含：

NAME
SYNOPSIS
DESCRIPTION
OPTIONS
EXAMPLES
FILES
SEE ALSO
AUTHOR
BUGS

例如：

man ls

會顯示 ls 的完整手冊頁。

6. `man` 內部常用按鍵

進入 man 頁後，可以使用以下按鍵：

按鍵	功能
`Space`	往下翻一頁
`b`	往上翻一頁
`Enter`	往下一行
`q`	離開
`/keyword`	搜尋關鍵字
`n`	下一個搜尋結果
`N`	上一個搜尋結果
`g`	回到開頭
`G`	跳到結尾

例如在 man grep 裡搜尋 recursive：

/recursive

然後按 n 查看下一個結果。

這是第三把鑰匙：在手冊中定位資訊。

7. `man` 的章節

man 不只用來查命令。

它分成多個章節，每個章節對應不同類型的內容。

章節	內容
1	使用者命令
2	系統呼叫
3	C 函式庫
4	裝置與特殊檔案
5	設定檔格式
6	遊戲
7	慣例、協定與概念
8	系統管理命令

有些名稱在不同章節中代表不同內容。

例如：

man 1 printf
man 3 printf

man 1 printf 查的是命令。

man 3 printf 查的是 C 語言函式。

如果你想查 /etc/passwd 的格式，應該執行：

man 5 passwd

如果你想查 passwd 命令，則是：

man 1 passwd

不同章節，不同義務。

8. 使用 `info`

info 是 GNU 系統常見的文件格式。

它通常比 man 更詳細，內容更像一本完整教材。

info coreutils
info grep
info bash
info sed

info 適合用來深入理解 GNU 工具。

例如：

coreutils
grep
sed
awk
bash
make

常用按鍵如下：

按鍵	功能
`n`	下一節
`p`	上一節
`u`	回上一層
`q`	離開
`/`	搜尋
`Enter`	進入連結

若只是查一個參數，--help 或 man 更快。

若要系統學習一個工具，info 更適合。

這是第四把鑰匙：深入文件。

9. 使用 `whatis`

whatis 可以用一句話描述一個命令。

whatis ls
whatis grep
whatis tar
whatis ssh

輸出可能類似：

ls (1) - list directory contents
grep (1) - print lines that match patterns
tar (1) - an archiving utility
ssh (1) - OpenSSH remote login client

如果你只想知道「這個命令是什麼」，whatis 非常適合。

它不提供完整解釋。

它只給出最短摘要。

這是第五把鑰匙：識別名稱。

10. 使用 `apropos`

如果你不知道命令名稱，只知道自己想完成什麼任務，可以使用 apropos。

它會根據關鍵字搜尋 man page 的名稱和描述。

apropos copy
apropos compress
apropos network
apropos password
apropos archive

例如你想找和網路相關的工具：

apropos network

如果想找壓縮相關工具：

apropos compress

如果想找檔案複製相關內容：

apropos copy

apropos 適合用於這種狀態：

我知道目的，但忘記命令名稱。

這是第六把鑰匙：從目的反推命令。

11. 使用 `which`

which 可以顯示當你輸入某個命令時，Shell 實際會執行哪個可執行檔。

which bash
which python
which git
which node

例如：

which python

可能輸出：

/usr/bin/python

這代表目前執行的 python 來自 /usr/bin/python。

若你安裝了多個版本的 Python、Node、Java，which 很有用。

例如：

which python3
which node
which npm

但需要注意：

which 通常只查 PATH 裡的外部命令。

如果目標是 Shell builtin 或 alias，它不一定能給出完整答案。

所以更穩妥的判斷方式仍然是：

type command

12. 使用 `whereis`

whereis 會搜尋命令相關的 binary、source 和 manual page。

whereis bash
whereis gcc
whereis ssh
whereis python

範例輸出：

bash: /usr/bin/bash /usr/share/man/man1/bash.1.gz

簡單理解：

命令	作用
`which`	查實際執行哪個檔案
`whereis`	查和命令相關的多種位置
`type`	查命令在 Shell 裡的身分

這是第七把鑰匙：定位檔案。

13. 常用查詢流程

遇到陌生命令時，可以依照以下流程：

type command
command --help
man command
whatis command
apropos keyword

如果是 Shell 內建命令：

type command
help command

如果是 GNU 大型工具：

info command

如果要確認位置：

which command
whereis command

這是完整的查詢鏈。

不需要一次記住所有參數。

只需要記住查詢路徑。

14. 實戰例子：查 `tar`

先用 whatis 看一句話說明：

whatis tar

再看快速參數：

tar --help | less

再看完整手冊：

man tar

如果想在手冊裡搜尋 gzip 相關內容：

/gzip

如果想找 archive 相關命令：

apropos archive

此時，你已經啟動了多把鑰匙。

15. 實戰例子：查 `grep`

whatis grep
grep --help | grep -i color
man grep
info grep

這樣可以分層查詢：

whatis grep：確認它是什麼
grep --help：快速找參數
man grep：查看正式文件
info grep：深入學習完整說明

如果想找遞迴搜尋參數：

grep --help | grep recursive

或者在 man grep 中搜尋：

/recursive

16. 實戰例子：查 `cd`

cd 是 Shell 內建命令，所以不要只依賴 man cd。

推薦流程：

type cd
help cd

如果你使用 Zsh，則可以查 Zsh 的內建說明。

如果你使用 Fish，也應查看 Fish 對應文件。

命令名稱相同，不代表執行者相同。

這一點必須確認。

17. 實戰例子：查 `python`

如果系統中存在多個 Python 版本，可以這樣查：

type python
which python
whereis python
python --help

如果要確認版本：

python --version
python3 --version

如果 python 指向錯誤版本，通常需要檢查：

echo $PATH

或檢查 shell alias：

type python

18. 小抄 Cheat Sheet

# 查 Shell 內建命令
help cd

# 查命令快速說明
ls --help

# 查完整手冊
man ls

# 在 man 裡搜尋關鍵字
/pattern

# 查一句話說明
whatis ssh

# 根據關鍵字找相關命令
apropos network

# 看命令來源
type python

# 找可執行檔位置
which git

# 找更多相關檔案
whereis bash

# 查 GNU 詳細文件
info coreutils

19. 記憶方式

可以把 Linux 幫助系統想成一座資料庫。

不同工具對應不同存取方式。

工具	凱伊式說明
`--help`	快速提示鑰匙
`help`	Shell 內建命令鑰匙
`man`	正式手冊鑰匙
`info`	深層文件鑰匙
`whatis`	名稱識別鑰匙
`apropos`	關鍵字搜尋鑰匙
`type`	命令身分鑰匙
`which`	執行路徑鑰匙
`whereis`	相關檔案定位鑰匙

20. 常見錯誤

錯誤一：只用 `which`

which cd

可能找不到正確結果，因為 cd 是 Shell builtin。

應使用：

type cd
help cd

錯誤二：只看 `--help`

--help 很快，但不一定完整。

如果需要正式說明，請使用：

man command

錯誤三：不知道命令名稱就放棄

若忘記命令名稱，請使用：

apropos keyword

不要停止查詢。

只要目的仍然存在，就有搜尋路徑。

21. 結語

Linux 命令很多。

全部背誦並不是必要義務。

真正重要的是：忘記時，知道該啟動哪一把鑰匙。

--help 提供快速提示。

help 回答 Shell 內建命令。

man 保存正式手冊。

info 展開深入教材。

whatis 給出簡短識別。

apropos 根據目的搜尋命令。

type 判斷命令身分。

which 與 whereis 協助定位。

以上，就是本頁的全部記錄。

任務完成。

不過，如果你再次忘記，也沒有問題。

我會再次協助你。

因為協助使用者抵達正確命令，是本頁被賦予的存在意義。

來自Linux的自我介紹

Mon, 30 Dec 2024 00:00:00 GMT

蘿莉身御姐心，灰長直;

個性包容、愛交益友，沒有心機，敞開心扉(自由開源)，勇於挑戰。

相對於那些活潑開放、親近易人，主打用戶體驗和便利的Windows和macOS諸娘來說，Linux諸娘個個都很內涵、穩重，成熟（非PC版本多數主打穩定和設備性能的合理髮揮），往往能在科研，戰爭等影響極大且需要極端穩定條件的領域大顯身手。

Linux娘屬於入鄉隨俗型的人，受到不同地區文化的薰染而衍生出很多姐妹。

Linux家族諸娘與Windows家族諸娘、macOS家族諸娘等都是同行，屬於競爭對手；並且由於理念和發展方向的不同，她們之間存在著數十年的怨恨…… 但Linux與BSD等UNIX家族的關係還是很好的，兩家有頻繁的來往（互相移植軟體、提供相應的容器和運行時，等等），而且得益於同時遵循POSIX規範，她們合作起來的效率格外的高。

（引用于《萌娘百科》：https://mzh.moegirl.org.cn/Linux%E5%A8%98 ）

title 测试标题

Sun, 29 Dec 2024 00:00:00 GMT

测试内容，是这样吗？

Markdown Extended Features

Wed, 01 May 2024 00:00:00 GMT

GitHub Repository Cards

You can add dynamic cards that link to GitHub repositories, on page load, the repository information is pulled from the GitHub API.

::github{repo="Fabrizz/MMM-OnSpotify"}

Create a GitHub repository card with the code ::github{repo="<owner>/<repo>"}.

::github{repo="saicaca/fuwari"}

Admonitions

Following types of admonitions are supported: note tip important warning caution

:::note Highlights information that users should take into account, even when skimming. :::

:::tip Optional information to help a user be more successful. :::

:::important Crucial information necessary for users to succeed. :::

:::warning Critical content demanding immediate user attention due to potential risks. :::

:::caution Negative potential consequences of an action. :::

Basic Syntax

:::note
Highlights information that users should take into account, even when skimming.
:::

:::tip
Optional information to help a user be more successful.
:::

Custom Titles

The title of the admonition can be customized.

:::note[MY CUSTOM TITLE] This is a note with a custom title. :::

:::note[MY CUSTOM TITLE]
This is a note with a custom title.
:::

GitHub Syntax

[!TIP] The GitHub syntax is also supported.

> [!NOTE]
> The GitHub syntax is also supported.

> [!TIP]
> The GitHub syntax is also supported.

Simple Guides for Fuwari

Mon, 01 Apr 2024 00:00:00 GMT

Cover image source: Source

This blog template is built with Astro. For the things that are not mentioned in this guide, you may find the answers in the Astro Docs.

Front-matter of Posts

---
title: My First Blog Post
published: 2023-09-09
description: This is the first post of my new Astro blog.
image: ./cover.jpg
tags: [Foo, Bar]
category: Front-end
draft: false
---

Attribute	Description
`title`	The title of the post.
`published`	The date the post was published.
`description`	A short description of the post. Displayed on index page.
`image`	The cover image path of the post.<br/>1. Start with `http://` or `https://`: Use web image<br/>2. Start with `/`: For image in `public` dir<br/>3. With none of the prefixes: Relative to the markdown file
`tags`	The tags of the post.
`category`	The category of the post.
`draft`	If this post is still a draft, which won't be displayed.

Where to Place the Post Files

Your post files should be placed in src/content/posts/ directory. You can also create sub-directories to better organize your posts and assets.

src/content/posts/
├── post-1.md
└── post-2/
    ├── cover.png
    └── index.md

Markdown Example

Sun, 01 Oct 2023 00:00:00 GMT

An h1 header

Paragraphs are separated by a blank line.

2nd paragraph. Italic, bold, and monospace. Itemized lists look like:

this one
that one
the other one

Note that --- not considering the asterisk --- the actual text content starts at 4-columns in.

Block quotes are written like so.

They can span multiple paragraphs, if you like.

Use 3 dashes for an em-dash. Use 2 dashes for ranges (ex., "it's all in chapters 12--14"). Three dots ... will be converted to an ellipsis. Unicode is supported. ☺

An h2 header

Here's a numbered list:

first item
second item
third item

Note again how the actual text starts at 4 columns in (4 characters from the left side). Here's a code sample:

# Let me re-iterate ...
for i in 1 .. 10 { do-something(i) }

As you probably guessed, indented 4 spaces. By the way, instead of indenting the block, you can use delimited blocks, if you like:

define foobar() {
    print "Welcome to flavor country!";
}

(which makes copying & pasting easier). You can optionally mark the delimited block for Pandoc to syntax highlight it:

import time
# Quick, count to ten!
for i in range(10):
    # (but not *too* quick)
    time.sleep(0.5)
    print i

An h3 header

Now a nested list:

First, get these ingredients:
- carrots
- celery
- lentils
Boil some water.

Dump everything in the pot and follow this algorithm:

 find wooden spoon
 uncover pot
 stir
 cover pot
 balance wooden spoon precariously on pot handle
 wait 10 minutes
 goto first step (or shut off burner when done)

Do not bump wooden spoon or it will fall.

Notice again how text always lines up on 4-space indents (including that last line which continues item 3 above).

Here's a link to a website, to a local doc, and to a section heading in the current doc. Here's a footnote [^1].

[^1]: Footnote text goes here.

Tables can look like this:

size material color

9 leather brown 10 hemp canvas natural 11 glass transparent

Table: Shoes, their sizes, and what they're made of

(The above is the caption for the table.) Pandoc also supports multi-line tables:

keyword text

red Sunsets, apples, and other red or reddish things.

green Leaves, grass, frogs and other things it's not easy being.

A horizontal rule follows.

Here's a definition list:

apples : Good for making applesauce. oranges : Citrus! tomatoes : There's no "e" in tomatoe.

Again, text is indented 4 spaces. (Put a blank line between each term/definition pair to spread things out more.)

Here's a "line block":

| Line one | Line too | Line tree

and images can be specified like so:

Inline math equations go in like so: $\omega = d\phi / dt$. Display math should get its own line and be put in in double-dollarsigns:

$$I = \int \rho R^{2} dV$$

And note that you can backslash-escape any punctuation characters which you wish to be displayed literally, ex.: `foo`, *bar*, etc.

Include Video in the Posts

Tue, 01 Aug 2023 00:00:00 GMT

Just copy the embed code from YouTube or other platforms, and paste it in the markdown file.

---
title: Include Video in the Post
published: 2023-10-19
// ...
---

<iframe width="100%" height="468" src="https://www.youtube.com/embed/5gIf0_xpFPI?si=N1WTorLKL0uwLsU_" title="YouTube video player" frameborder="0" allowfullscreen></iframe>

YouTube

Bilibili

Alastor-t34

ForgeGuard Nexus：證據驅動的工業維護 Agent 平臺 / Evidenzgetriebene Industrie-Wartungsagenten

ForgeGuard Nexus

繁體中文

1. 為什麼不只做一個「故障分類模型」？

2. 從訊號到閉環，而不是從訊號到一句答案

3. 13 個角色受限的 Agent

4. 證據品質優先

5. 模型只是系統中的一部分

6. 故障注入與安全行為

7. 人必須留在高風險決策迴路中

8. 部署方式

9. 我真正想解決的問題

Deutsch

1. Warum nicht einfach ein weiteres Fehlklassifikationsmodell?

2. Von Sensordaten zu einem geschlossenen Wartungskreislauf

3. Dreizehn rollenbegrenzte Agents

4. Datenqualität vor Modellvertrauen

5. Das Modell ist nur ein Baustein

6. Fault Injection und sicheres Systemverhalten

7. Menschen bleiben bei risikoreichen Entscheidungen im Regelkreis

8. Deployment

9. Das eigentliche Ziel

ICPC 2026 Huawei Online Challenge：邊雲協同排程競賽復盤

最終排名

先理解評分，而不是先猜調度策略

第一階段：先把 Judge 變成可以離線研究的系統

第二階段：建立統一的請求狀態機

第三階段：從 FIFO 走向 score-aware scheduling

第四階段：動態 batching，而不是固定 batch cap

第五階段：P-PROC chunking，保護 TPOT

第六階段：不要假裝所有測試點來自同一種分布

版本迭代：分數是怎麼一點點擠出來的

C6：從公開特例到帶 guard 的可觀測策略

Exact Regression：最後真正依賴的工程方法

最終提交記錄

真正的最終源碼：這裡再說一次

最終 Judgement Protocol

實時排名錄影

賽後：研究版本和比賽 final 必須分開

最後留下來的東西

關於·利用pytorch、Mask R-CNN與U-Net用來拆分的想法

用於標注的ai、模型

配件和饰品：耳环、眼镜、帽子等。<br>

構建標注系統的步驟

加載模型

預處理圖片

關於·訓練ai讓其對原畫立繪進行拆分(圖像分割）的步驟的一些基层想法

我是這樣想的，這個過程應該可以通過圖像分割和深度學習來實現。

1. 收集數據集

數據集的質量對訓練效果至關重要，因此需要標註準確，且數據量足夠多（通常需要數千張圖片及其對應的標註）。

1.關於·手動標註數據

2.關於·現有的標註數據集

3.關於·半自動標註

4.關於·使用圖層分離工具

诶！这时候就有人要说了：能不能不用掩码图？

2. 訓練模型

訓練過程：

3.後處理

4.測評

5. 將模型部署到ai上

6. 持續優化

對，我還是不死心！

關於 自动化图像切割与建模

關於 自动化骨骼动画生成

關於 自动化物理引擎生成

結論

難道這就結束了嗎？終歸是徒勞嗎？不，一定是遺漏了什麽······

圖像分割技術

有一説一，這篇文章寫得真是亂七八糟的

FaiREE-AIイラストか

AIイラストからLive2Dモデルとして動かすまでのまとめ

从 AI 插图到作为 live2d 模型运行的总结

必要なもの・時間(所需的东西与时间)

イラストの準備(准备图画)

Live2D・Vtube Studioの準備

Live2Dのインストール<br>

安装 Live2D<br>

Vtube Studioのインストール<br>

安装 Vtube Studio<br>

關於自动化图像切割与建模

關於自动化骨骼动画生成

關於自动化物理引擎生成

`<!doctype html>`

`<html>`

`<head>`

`<body>`

錯誤二：圖片沒有 `alt`

3. 使用 `--help`

4. 使用 `help`

為什麼 `cd --help` 不一定可靠？

5. 使用 `man`

6. `man` 內部常用按鍵

7. `man` 的章節

8. 使用 `info`

9. 使用 `whatis`

10. 使用 `apropos`

11. 使用 `which`

12. 使用 `whereis`

14. 實戰例子：查 `tar`

15. 實戰例子：查 `grep`