สิ่งเหล่านี้คือแบตช์สำหรับงานบรรณาธิการ ไม่ใช่การรับประกันเกี่ยวกับจำนวนหน้าสูงสุดที่ API request จะรับได้ ตรวจสอบข้อจำกัดของบัญชีปัจจุบันก่อนเลือกขนาดของคำขอ

ขั้นตอนที่ 2: ทำให้งานนำร่องเป็นตัวแทนของงานจริง

ควรมีภาพมุมกว้างเพื่อปูฉาก ภาพใบหน้าระยะใกล้ การโต้ตอบกับพร็อพ การแลกเปลี่ยนระหว่างสองตัวละคร และจังหวะเปิดไปหน้าถัดไปอยู่ในสามหน้าแรกที่ใดที่หนึ่ง หน้าพอร์ตเทรตที่เกือบเหมือนกันสามหน้าจะไม่เผยให้เห็นปัญหาที่ยากที่สุดของหนังสือ

ภาพประกอบนี้แสดงโครงสร้างการอนุมัติ ไม่ใช่ภาพหน้าจอของคอมิกที่สร้างครบสี่สิบหน้า

ตรวจทานงานนำร่องทั้งในด้านความชัดเจนของเรื่องและคุณภาพของภาพ ตรวจสอบว่าเข็มทิศยังดูจดจำได้ ตัวละครไม่เพี้ยนไปตามระยะกล้อง และบทสนทนาสามารถวางได้โดยไม่บังมือหรือใบหน้า บันทึกเวอร์ชันอ้างอิงและเวอร์ชันสคริปต์ที่ได้รับอนุมัติไว้ก่อนขยายการผลิต

หากงานนำร่องล้มเหลว ให้บันทึกสาเหตุและอัปเดตบรีฟที่ใช้ร่วมกัน การแก้คำสั่งร่วมกันตั้งแต่ช่วงงานนำร่องจะช่วยจำกัดจำนวนหน้าถัดไปที่อาจสืบทอดปัญหาเดียวกัน

ขั้นตอนที่ 3: ใช้คำขอที่มีการบันทึกไว้ และเก็บ job ID ไว้

เอกสาร Comic API ปัจจุบันรองรับการป้อนข้อมูลหลายหน้าผ่านออบเจ็กต์ pagination แบบซ้อน ตัวอย่างต่อไปนี้เป็นตัวอย่างรูปแบบคำขอ ไม่ใช่คำขอที่บทความนี้ได้ดำเนินการจริง:

{
  "prompt": "Create the first three pages of Station Compass from the approved panel script.",
  "preset": "japanese_manga",
  "pagination": {
    "totalPages": 3,
    "panelsPerPage": 4
  }
}

อย่าใช้โหมด pagination นี้ร่วมกับ fixPanelNum เก็บ API token เป็นความลับ จัดเก็บ generation ID ที่ระบบส่งกลับมา จากนั้นดึงสถานะและแอสเซ็ตโดยใช้ status endpoint ตามที่ระบุไว้ในเอกสาร บันทึก usage ที่ระบบส่งกลับมาจริงแทนการประมาณราคากลางต่อหน้าที่ใช้ได้ในทุกกรณี

สำหรับแต่ละ job ที่ส่งไป ให้เก็บอินพุตและรีสปอนส์ไว้คู่กัน เมื่อรีสปอนส์ล่าช้า ให้ตรวจสอบ job ที่มีอยู่ก่อนจะส่งคำขอใหม่ ปฏิบัติตามพฤติกรรม idempotency ตามเอกสาร การเปลี่ยน retry key อาจสร้าง job แยกและเกิดค่าใช้จ่ายเพิ่มเติมได้

ขั้นตอนที่ 4: แยกความสำเร็จทางเทคนิคออกจากการอนุมัติทางบรรณาธิการ

job อาจเสร็จสมบูรณ์แล้ว ในขณะที่หน้ายังมีจังหวะเนื้อหาที่ขาดหาย โค้ตที่ไม่ถูกต้อง หรือพื้นที่บอลลูนคำพูดที่อ่านไม่ได้ ให้แยกสถานะการสร้างและสถานะทางบรรณาธิการไว้คนละฟิลด์

page_id,batch,script_version,reference_version,job_id,review_state,export_version
P001,pilot,v03,mira-v02,record-returned-id,approved,v01
P002,pilot,v03,mira-v02,record-returned-id,repair-required,
P003,pilot,v03,mira-v02,record-returned-id,awaiting-review,

ใช้การตัดสินใจที่ชัดเจน เช่น awaiting-review, repair-required และ approved กำหนดผู้รับผิดชอบและเหตุผลให้กับทุกการปฏิเสธ เก็บไฟล์ที่ได้รับอนุมัติก่อนหน้าไว้จนกว่าไฟล์ทดแทนจะผ่านการตรวจทาน

เมื่อจบแต่ละแบตช์ ให้ตรวจดูการเชื่อมต่อเข้าสู่แบตช์ถัดไป พาเนลสุดท้ายที่ถูกต้องและพาเนลแรกที่ถูกต้องอาจยังไม่สอดคล้องกันในเรื่องตำแหน่งที่ตัวละครยืนอยู่หรือมือข้างใดถือพร็อพ

ขั้นตอนที่ 5: ซ่อมเฉพาะพาเนลที่ได้รับผลกระทบ

สมมติว่า P017 มีหนึ่งพาเนลที่ Mira ใส่โค้ตสีแดง ให้บันทึกข้อบกพร่องเฉพาะจุดนั้น แทนที่จะปฏิเสธทุกภาพในแบตช์

API มีการระบุคำขออัปเดตพาเนลบน generation ที่มีอยู่แล้ว ดัชนีหน้าและดัชนีพาเนลเริ่มจากศูนย์ ให้แมปดัชนีเหล่านั้นจากผลลัพธ์ของ job จริง P017 ในหนังสือของคุณไม่ได้เท่ากับ page index 16 โดยอัตโนมัติในทุกแบตช์

ใช้บรีฟการซ่อมแซมประมาณนี้:

Restore Mira's teal coat and copper bob in this panel.
Preserve the camera, station, compass, pose and other characters.
Do not revise the surrounding panels.

หลังซ่อมแซมแล้ว ให้ตรวจทานพาเนลที่อยู่ติดกัน และรีเฟรชเฉพาะไฟล์ส่งออกที่ใช้หน้าซึ่งถูกเปลี่ยนแปลง คู่มือตรวจสอบผลกระทบจากการเปลี่ยน reference ครอบคลุมการเปลี่ยนแปลงการพึ่งพาในวงกว้างมากขึ้น

ขั้นตอนที่ 6: ตรวจสอบสมุดบันทึก 40 หน้าก่อนส่งออก

ตรวจสอบความไม่ซ้ำกัน ความครบถ้วนของหน้า การอนุมัติ และเวอร์ชันส่งออกปัจจุบัน การตรวจสอบการวางแผนแบบง่าย ๆ ในเครื่องสามารถจับบันทึกที่หายไปได้ก่อนที่ใครจะประกอบหนังสือ:

expected = {f"P{i:03d}" for i in range(1, 41)}
actual = [row["page_id"] for row in pages]
assert len(actual) == len(set(actual)), "Duplicate page ID"
assert set(actual) == expected, "Missing or unexpected page"
assert all(row["review_state"] == "approved" for row in pages)
assert all(row["export_version"] for row in pages)

ในแบบฝึกหัดการวางแผนในเครื่องที่มาพร้อมกัน มีหน้าหนึ่งที่ยังไม่ได้รับอนุมัติโดยตั้งใจ ซึ่งจะบล็อกการส่งออกจนกว่าบันทึกการตรวจทานจะได้รับการแก้ไข สิ่งนี้ใช้เพื่อทดสอบกฎของสมุดบันทึก ไม่ใช่คุณภาพภาพของหน้าคอมิกทั้งสี่สิบหน้า บรรณาธิการยังคงต้องอ่านหนังสือทั้งเล่ม

คุณควรติดตามเวลาและเครดิตอะไรบ้าง?

ติดตามการสร้าง การตรวจทาน การซ่อมแซม การลงตัวอักษร การประกอบ และการอ่านรอบสุดท้ายแยกจากกัน บันทึก usage จริงที่ระบบส่งกลับมาสำหรับแต่ละ job และวัดเวลาการตรวจทานโดยมนุษย์ด้วยขอบเขตเดียวกันในแต่ละแบตช์

ใช้โครงสร้างงบประมาณนี้:

Total production cost = pilot + accepted batches + repairs + export work
Total elapsed time = generation waits + review + repair + assembly

อย่านำภาพพาเนลที่ดูดีเพียงหนึ่งภาพไปคาดการณ์ทั้งเล่ม การประเมินจากงานนำร่องที่มีประโยชน์ควรรวมผลลัพธ์ที่ถูกปฏิเสธและงานเก็บรายละเอียดด้วย

เช็กลิสต์ก่อนเผยแพร่

• มี ID หน้าของเนื้อเรื่องครบสี่สิบหน้าที่ไม่ซ้ำกันตามลำดับที่ต้องการ
• ทุกหน้ามีการอนุมัติทางบรรณาธิการและเวอร์ชันส่งออกปัจจุบัน
• สามารถตรวจสอบย้อนหลัง reference ของตัวละคร สถานที่ และพร็อพได้
• บทสนทนาและเครดิตได้รับการพิสูจน์อักษรแล้ว
• ขอบเขตของหน้าและการเปลี่ยนฉากอ่านต่อเนื่องกันได้
• ไฟล์สามารถเปิดใหม่บนอุปกรณ์อื่นได้โดยไม่มีแอสเซ็ตหาย
• ปก ภาพขนาดย่อ และภาพครอปสำหรับโปรโมตใช้เวอร์ชันที่ได้รับอนุมัติแล้ว

เริ่มจากบรีฟสามหน้าใน Comic API ขยายต่อเมื่อคุณสามารถอธิบายได้ว่าทำไมหน้าชุดนั้นจึงผ่านเกณฑ์ สำหรับความต้องการด้านการผลิตระดับทีม เส้นทาง enterprise สามารถช่วยกำหนดขอบเขตการเชื่อมต่อได้

FAQ

ฉันสามารถขอทั้งสี่สิบหน้าพร้อมกันได้ไหม?

ใช้ API ปัจจุบันและข้อจำกัดของบัญชีเพื่อพิจารณาว่ารับได้แค่ไหน ขนาดแบตช์ทางบรรณาธิการก็ควรสะท้อนด้วยว่าทีมของคุณสามารถตรวจสอบได้มากเพียงใดก่อนเดินหน้าต่อ

job ของ API ที่เสร็จสมบูรณ์หมายความว่าหน้าได้รับอนุมัติแล้วหรือไม่?

ไม่ การเสร็จสมบูรณ์เป็นสถานะทางเทคนิค การอนุมัติต้องอาศัยการตรวจทานผลลัพธ์เทียบกับบรีฟ

พาเนลที่ล้มเหลวควรกระตุ้นให้รันแบตช์ทั้งหมดใหม่หรือไม่?

อันดับแรกให้ระบุสาเหตุ ข้อบกพร่องเฉพาะจุดมักซ่อมแซมเป็นรายพาเนลได้ แต่หากเป็นปัญหาใน reference หรือสคริปต์ที่ใช้ร่วมกัน อาจส่งผลต่อหลายหน้าและควรกระตุ้นให้มีการตรวจสอบผลกระทบ

เอกสารผลิตภัณฑ์ได้รับการตรวจทานเมื่อวันที่ 2 พฤศจิกายน 2026 ภาพประกอบและสมุดบันทึกการวางแผนเป็นตัวอย่างเพื่อการสอน ไม่มีการอ้างเบนช์มาร์กด้านความเร็วหรือค่าใช้จ่ายสำหรับงานสี่สิบหน้า

บล็อกก่อนหน้า

เช็กลิสต์การส่งต่องานจากสตอรีบอร์ดเป็นวิดีโอ: ช็อต เวลา เสียง และความต่อเนื่อง

เปลี่ยนเฟรมสตอรีบอร์ดที่อนุมัติแล้วให้เป็นแพ็กเกจส่งต่องานวิดีโอที่ชัดเจน ด้วยรหัสช็อตที่คงที่ การกำ

Jay

1 พฤศจิกายน 2026

วิธีทำโลคัลไลซ์คอมิกโดยไม่ต้องวาดงานอาร์ตใหม่

คงงานอาร์ตคอมิกที่อนุมัติแล้วไว้ พร้อมแปลบทสนทนา สร้างเลเยอร์ตัวอักษรที่แก้ไขได้ ตรวจสอบลำดับการอ่าน

Jay

31 ตุลาคม 2026

เวิร์กโฟลว์การผลิตคอมิกแบบแบตช์: ร่าง อนุมัติ ซ่อมแซม และส่งออก 40 หน้า

วางแผนคอมิก AI 40 หน้าด้วยงานนำร่อง แบตช์ที่ตรวจทานได้ สมุดบันทึกหน้า การซ่อมแซมแบบเลือกเฉพาะ และการ

Jay

30 ตุลาคม 2026

เวิร์กโฟลว์การใส่ตัวอักษรในคอมิก: แยกงานภาพ ฟองคำพูด และงานแปลออกจากกัน

เวิร์กโฟลว์การใส่ตัวอักษรในคอมิกอย่างเป็นระบบจะแยกภาพสะอาด ฟองคำพูด SFX และงานแปลออกจากกัน พร้อมการท

Jay

28 ตุลาคม 2026