Was macht jlc-cli?
Durch geschäftliche CLI-Operationen mit der JLC China-Website interagieren. Dies ist ein inoffizielles Community-Projekt ohne offizielle Unterstützung von JLC. Der normale Arbeitsablauf erfolgt über Befehle; nur wenn ein Befehl eine Übernahme anfordert, wird die beibehaltene CDP-Seite manipuliert.
Installationsprüfung
Vor der Ausführung eines Geschäftsbefehls führen Sie zuerst jlc-cli --version und danach jlc-cli --help aus. Die Installation dieser Fertigkeit installiert nicht automatisch die CLI.
Wenn der Befehl nicht gefunden wird (command not found / nicht erkannt), teilen Sie dem Benutzer mit, dass die CLI noch nicht installiert oder nicht im PATH enthalten ist, und verweisen Sie auf das Projekt-Repository mit Installationsanleitung. Das Tool ist derzeit nicht auf npm veröffentlicht; installieren Sie kein gleichnamiges Drittanbieter-Paket. Nach Vorbereitung von Node.js 22.12 oder höher, npm, Git und Google Chrome kann es aus dem Quellcode installiert werden:
git clone https://github.com/TXyy2023/jlc-cli.git
cd jlc-cli
npm ci
npm run build
npm pack
npm install -g ./jlc-com-cli-1.0.0-dev.1.tgz
jlc-cli --version
jlc-cli --help
Der Paketname entspricht der aktuellen Entwicklungsversion; bei Versionsänderungen den tatsächlichen, von npm pack erzeugten Dateinamen verwenden. Wenn das Quellverzeichnis bereits vorhanden ist, überprüfen Sie den Pfad und überschreiben Sie nicht das vorhandene Verzeichnis. Nach der Installation die Version und Hilfe erneut prüfen, bevor Sie die ursprüngliche Aufgabe fortsetzen. Wenn der Befehl vorhanden ist, aber nicht startet, geben Sie den tatsächlichen Fehler an und überprüfen Sie Node.js-Version & PATH – behandeln Sie einen gescheiterten Start nicht als fehlende Installation und installieren Sie nicht blind neu.
Erste Schritte
Nach der Installationsprüfung führen Sie jlc-cli browser doctor --json aus, um die Browserverfügbarkeit zu überprüfen. jlc-cli skill path gibt die mit dieser CLI ausgelieferte Skill zurück; bevorzugen Sie die Dokumentation der gleichen Version.
Bei der ersten Verwendung präsentieren Sie dem Menschen den von jlc-cli init --json zurückgegebenen Initialisierungsumfang und führen erst nach expliziter Zustimmung jlc-cli init --accept --confirmed-by human aus. Oder der Mensch kann init interaktiv ausführen. Anschließend konfigurieren Sie den Browser, initiieren die Anmeldung und überprüfen den auth status; zeigen Sie dem Menschen bei QR-Code den zurückgegebenen aktuellen QR-Code an. Die Anmeldung gilt erst mit dem Ergebnis der Kontostatusprüfung als abgeschlossen, nicht allein durch Seitenwechsel oder Scan-Aktion. Nach Abschluss kann jlc-cli account show --json für eine Abfrage verwendet werden.
Der aktuelle Workflow verwendet explizit jlc-cli browser configure --clear-endpoint --engine chrome. Der Standard-Obscura-Laufzeitmodus ist getestet, aber die aktuelle echte Kundenzentrum-SPA und das Login-iFrame haben noch Kompatibilitätsprobleme; die Verbindungsfähigkeit der Laufzeit nicht als Geschäftsbereitschaft ausgeben und nicht behaupten, der Browser sei automatisch gewechselt. Bevor die CLI eine eigene Sitzungswechsel-Engine hat, stoppen Sie die Sitzung; Details siehe Browser- und Login-Befehle.
Geschäftsübersicht
| Anforderung | Befehlsgruppe und Referenz |
|---|---|
| Installationserkennung, Initialisierung, Browser, Kontokonfiguration, Multi-Login-Methoden, QR-Code, Erfolgs-Callback | Befehle und Login |
| Upload/Parse/Vorschau, Parameter, Angebot, Prüfung und Auftragserstellung | PCB-Workflow |
| PCB/FPC-Aufträge, Guthabenzahlungen, Jia Xiaozhi | Aufträge und Zahlungen |
| JSON-Status, Exit-Codes, Aufgabenbeobachtung, CDP-Übernahme, unbekannte Ergebnisse | Ergebnisse und Wiederherstellung |
Entscheidungsgrenzen (müssen eingehalten werden)
- default: Nicht vom Benutzer festgelegte Produktionsparameter müssen abgefragt werden. Website-Vorauswahl, letzte Konfiguration und Parsing-Fakten werden nicht automatisch zur Benutzerauswahl. auto: Erst mit der Absicht des Benutzers, dass der Agent bei der Auswahl hilft, dann entsprechend dessen Einschränkungen vorschlagen und ausfüllen; Begründung angeben, bei Konflikten nachfragen. Der Modus-Flag selbst ist keine Autorisierung.
- Nach dem Setzen der Parameter die tatsächlich wirksamen Werte auslesen. Bei Änderungen oder Zurücksetzungen durch die Website die Abweichung melden; nicht akzeptieren, dass Ersatzwerte den Workflow fortsetzen dürfen.
- Upload, Vorschau und Angebot autorisieren nicht automatisch die Auftragserstellung. Wenn der Benutzer die Auftragserstellung autorisiert hat, zuerst die Zusammenfassung prüfen, dann explizit absenden – das Angebot nicht als Auftrag oder Zahlung betrachten.
- Jede Guthabenzahlung erfordert eine menschliche Bestätigung des aktuellen Kontos, Auftrags, Betrags und Zahlungsmethode. Nur wenn diese Zusammenfassung tatsächlich explizit vom Menschen zugestimmt wurde, darf
--human-confirmedübergeben werden; keine gefälschte Bestätigung oder Änderung der lokalen Bestätigungsaufzeichnungen. Die CLI prüft Bindung, Gültigkeit und Einmalnutzung; das Flag selbst beweist keine Gesprächstatsache. Initialisierung, auto und Übernahme ersetzen keine Zahlungsbestätigung. - Bei unbekanntem Ergebnis zuerst die ursprüngliche Aufgabe und den Auftrag überprüfen, nicht erneut einreichen oder zahlen. Die Zuordnung von Aufgabe, Datei, Kontokonfiguration und Seite beibehalten; Übernahme erweitert keine bestehende Geschäftsautorisierung.
Nur die tatsächlich überprüften Ergebnisse von Befehlen melden. QR-Code-Zustellung, Login-Abschluss, Parse-Abschluss, Auftragserstellung und Bezahlt sind unterschiedliche Status. Fehlende Felder nicht erfinden; von der Website ausgeblendete Informationen nicht ergänzen. Die verfügbaren Fähigkeiten und tatsächlichen Akzeptanzgrenzen richten sich nach der aktuellen CLI-Hilfe und den Projektabnahmeprotokollen.