ระบบคิวงานอัตโนมัติ: ให้ Claude Code ทำงานเองทุก 90 นาที ด้วย CSV ไฟล์เดียว

คำถามที่ผมโดนถามบ่อยที่สุดเวลาเล่าว่าใช้ Claude Code ทำงานสาย data คือ "แล้วต้องนั่งเฝ้าพิมพ์ทีละคำสั่งตลอดเลยเหรอ" คำตอบคือไม่ — เพราะงานซ้ำ ๆ ที่มีขั้นตอนชัด (ทำข่าว, สรุปเอกสาร, รัน QC, เติม backlog) ผมยกให้ Claude ทำเองเป็นชุด โดยมีตัวรันหยิบคำสั่งจากไฟล์ CSV ทีละบรรทัด รันจบแล้วพักตามเวลาที่ตั้ง แล้วหยิบบรรทัดถัดไป บทความนี้ผมจะเปิดโครงสร้างจริงที่ผมใช้ — ระบบเดียวกับที่ผลิตข่าวและบทความบนเว็บนี้ทุกวัน — ให้คุณก็อปไปตั้งต้นเองได้เลย

1. หัวใจของระบบ: หนึ่งคำสั่ง = หนึ่งบรรทัดใน CSV

ไอเดียมันเรียบง่ายมากตามสไตล์ที่ผมชอบ (ไม่ซับซ้อน ทำซ้ำได้): เก็บ "งานที่จะให้ Claude ทำ" ไว้ในไฟล์ session_prompts.csv ที่มีแค่ 3 คอลัมน์

id,prompt_message,wait_minutes
3025,"OBJ: [NEWSROOM-NEWS] ผลิตข่าว 1 ชิ้น
CONTEXT: ทำตาม SOP docs/newsroom-sop.md ครบทุก STEP; verify ทุก fact ก่อนเขียน
RULE: ยึด SOP เข้ม; ทุกตัวเลขต้องมี quote รองรับ
DONE: Create 'SESSION_COMPLETED.txt'.",90
3026,"OBJ: [QC] รัน qc_output.py กับงานใน scratch วันนี้ แล้วสรุปคะแนน
CONTEXT: อ่าน threshold จาก config; งานต่ำกว่าเกณฑ์ให้ mark ไว้
RULE: Code ONLY
DONE: Create 'SESSION_COMPLETED.txt'.",90

แต่ละบรรทัดคือหนึ่ง session ที่ Claude จะเปิดขึ้นมาทำจนจบ wait_minutes คือเวลาพักหลังงานเสร็จก่อนเริ่มงานถัดไป — ผมตั้งไว้ที่ 90 นาที เพื่อให้จังหวะการทำงานสม่ำเสมอตลอดวันและไม่ชนกัน ตัวรันจะวนหยิบบรรทัดถัดไปเรื่อย ๆ เอง

ทำไมมันเวิร์ก: เพราะคุณแยก "งานคืออะไร" (ข้อมูลใน CSV) ออกจาก "ตัวรัน" (โค้ดที่วนลูป) พอแยกสองอย่างนี้ได้ การเพิ่มงานก็แค่เพิ่มบรรทัด ไม่ต้องแตะโค้ด และไฟล์ CSV ก็ถูก version control ตรวจย้อนได้ว่าสั่งอะไรไปเมื่อไหร่

2. โครงสร้าง prompt แบบ OBJ / CONTEXT / RULE / DONE

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

• OBJ — เป้าหมายหนึ่งประโยค ขึ้นต้นด้วย tag ประเภทงานในวงเล็บเหลี่ยม เช่น [NEWSROOM-NEWS] เพื่อให้ filter/นับงานแต่ละชนิดได้ง่าย
• CONTEXT — ชี้ไปที่ไฟล์/SOP ที่ต้องอ่าน ไม่ใช่ก็อปเนื้อหายาว ๆ มาแปะ (ประหยัด token — ดูเรื่องการจัดงบ token)
• RULE — เส้นห้ามที่เด็ดขาด เช่น "Code ONLY" หรือข้อกำกับด้านกฎหมาย/ความปลอดภัย
• DONE — เงื่อนไข "เสร็จ" ที่ตรวจได้ด้วยเครื่อง ผมใช้ให้สร้างไฟล์สัญญาณ SESSION_COMPLETED.txt เพราะตัวรันเช็คไฟล์นี้เพื่อรู้ว่างานจบจริง ไม่ใช่แค่ Claude พิมพ์ว่า "เสร็จแล้ว"

ทำไมมันเวิร์ก: สี่บล็อกนี้บังคับให้ "นิยามความเสร็จ" อยู่ในคำสั่งตั้งแต่แรก ซึ่งเป็นหลักเดียวกับที่ผมใช้ตอนทำ model validation ในแบงก์ — ถ้าไม่นิยาม success criteria ก่อนเริ่ม คุณจะไม่มีทางรู้ว่างานผ่านหรือไม่ผ่าน DONE ที่ตรวจด้วยเครื่องได้ คือสิ่งที่เปลี่ยน "AI ที่ดูเหมือนทำงาน" ให้เป็น "AI ที่ทำงานเสร็จจริง"

3. ตัวรันวนลูป — เล็กแต่ครบ

ตัวรันไม่ต้องหวือหวา หน้าที่มันมีแค่ไม่กี่อย่าง และนี่คือ logic แกนที่ผมใช้จริง (เขียนเป็นซูโดโค้ดให้เห็นภาพ)

rows = read_csv("session_prompts.csv")     # id, prompt_message, wait_minutes
state = load_state()                        # จำว่าทำถึงบรรทัดไหนแล้ว (resume ได้)

for row in rows[state["cursor"]:]:
    delete_if_exists("SESSION_COMPLETED.txt")          # ล้างสัญญาณเก่า
    run(["claude", "--print", "--dangerously-skip-permissions"],
        input=row["prompt_message"])                    # เปิด session ทำงานจนจบ
    wait_for_file("SESSION_COMPLETED.txt", timeout=...)  # fail-safe: รอสัญญาณเสร็จจริง
    state["cursor"] += 1; save_state(state)             # เดินหน้า + จำไว้
    sleep(row["wait_minutes"] * 60)                      # พักก่อนงานถัดไป

สามจุดที่ทำให้มันไม่พังกลางทาง: (1) state file จำ cursor ไว้ รีบูตแล้วรันต่อจากเดิมได้ ไม่เริ่มใหม่ทั้งหมด (2) done-gate ด้วยไฟล์สัญญาณ ถ้า session ไหนไม่สร้าง SESSION_COMPLETED.txt ตัวรันรู้ว่ามีปัญหา ไม่ใช่เดินหน้ามั่ว ๆ (3) --dangerously-skip-permissions ให้รันไม่สะดุด permission prompt (ใช้เฉพาะใน sandbox ที่คุมขอบเขตไฟล์ไว้แล้วเท่านั้น อย่าใช้บนเครื่องงานหลักที่มีข้อมูลสำคัญ)

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

4. ทำไมต้องเป็น 90 นาที ไม่ใช่รันรัว ๆ

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

ที่สำคัญกว่าคือมันบังคับ "cadence" — ผมออกแบบให้ระบบผลิตคอนเทนต์ราว 4 ชิ้นต่อวันแบบสม่ำเสมอ แทนที่จะถล่มทีเดียว 20 ชิ้นแล้วเงียบไปสามวัน ความสม่ำเสมอสำคัญกว่าความเร็วสำหรับงานที่ต้องรักษาคุณภาพ และการเว้นช่วงยังช่วยคุมการใช้งานให้อยู่ในกรอบที่วางไว้ ไม่เบิร์นทรัพยากรเกินจำเป็น

ทำไมมันเวิร์ก: การตั้งจังหวะไม่ใช่การทำให้ช้าลง แต่เป็นการทำให้ "ตรวจสอบได้" งานที่ทยอยออกมาเป็นจังหวะ คุณคุมคุณภาพทีละชิ้นได้ ต่างจากงานที่ถล่มออกมาพร้อมกันจนตรวจไม่ทัน — นี่คือหลัก risk เดิม ๆ ที่ว่า throughput ที่คุมไม่ได้ ไม่ใช่ throughput ที่ดี

5. จุดที่ต้องมีก่อนปล่อยให้มันทำงานเอง

ก่อนจะปล่อยคิวรันข้ามคืน ผมมีเช็คลิสต์กันพลาดที่ไม่ยอมข้าม เพราะ "อัตโนมัติที่ไม่มีเบรก" คือหายนะ

• ทุกงานต้องมี DONE ที่ตรวจด้วยเครื่องได้ — ไม่มีสัญญาณเสร็จ = ตัวรันไม่มีทางรู้ว่างานสำเร็จ
• งานเขียน/เผยแพร่ต้องผ่าน gate คุณภาพก่อนออก — ผมต่อระบบตรวจงาน AI (QC)และการให้ AI วิจารณ์แผนตัวเองก่อน commitไว้ในบางงาน เพื่อไม่ให้ของคุณภาพต่ำหลุดออกไป
• จำกัดขอบเขตไฟล์และสิทธิ์ — รันในพื้นที่ที่คุมได้ ไม่ให้แตะของสำคัญ
• มี log ที่ย้อนดูได้ — งานไหนทำเมื่อไหร่ ผลเป็นอย่างไร ต้องตรวจย้อนได้เสมอ

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

ภาพรวม

ระบบคิวงานอัตโนมัติของผมไม่มีอะไรลึกลับ — CSV หนึ่งไฟล์เก็บงาน, prompt สี่บล็อกที่นิยามความเสร็จได้, และตัวรันเล็ก ๆ ที่รู้จักรอสัญญาณเสร็จและรีสตาร์ทได้ สามชิ้นนี้เปลี่ยน Claude Code จาก "ผู้ช่วยที่ต้องนั่งเฝ้า" เป็น "คนงานที่ทำงานเป็นกะ" ให้คุณ

สิ่งที่ผมย่อไว้ในบทความนี้คือแกน ส่วนระบบเต็มที่ผมใช้จริง — ตัว dispatch ที่เลือกโมเดลตามงาน, ตัวเติมคิวอัตโนมัติเมื่องานใกล้หมด, การจัดงบ token ต่อ session, และ QC pipeline ที่ต่อเข้าไปในแต่ละงาน — ผมประกอบเป็น workspace ที่ก็อปไปตั้งต้นได้ทั้งก้อน พร้อมลำดับการตั้งค่าและ edge case ที่เจอมาจริง อยู่ในคอร์ส Claude Code ถ้าอยากได้ทั้งระบบไม่ใช่แค่โครง

เนื้อหานี้เพื่อการศึกษา คุณควรทดสอบระบบอัตโนมัติในพื้นที่ที่คุมขอบเขตได้ก่อนใช้กับงานจริงเสมอ