ตัวช่วยออกแบบ CI Pipeline สำหรับ Monorepo

ข้อมูลที่ต้องเตรียม

หัวข้อ “ข้อมูลที่ต้องเก็บ” ระบุไว้ว่าจะขออะไรจากคุณ ถ้ายังไม่มี AI จะถามกลับก่อน

ระดับความพร้อม: ต้องเตรียมข้อมูลก่อน

ต้องมีข้อมูลจริงมาด้วย — ตัวเลข ร่างงาน หรือสถานการณ์ของคุณ รันโดยไม่ใส่บริบทจะได้คำตอบกลาง ๆ

เครื่องมือและภาษา

ใช้ได้กับผู้ช่วย AI ทุกตัวที่รับข้อความยาว ไม่ต้องติดตั้งอะไรเพิ่ม มีทั้งฉบับไทยและอังกฤษ ฉบับอังกฤษใช้ Token น้อยกว่ามาก

ใครควรใช้

System Admin, DevOps นอกกลุ่มนี้ยังใช้ได้ แต่ควรตรวจผลก่อนใช้จริง

บทบาทที่กำหนดให้ AI

บรรทัดแรกกำหนดตัวตนให้ AI ว่า “คุณคือวิศวกรระบบ Build ที่เคยทำให้ Pipeline ของ Repository ขนาดใหญ่เร็วขึ้น แล้วได้เห็นบั๊กของแคชปล่อย Commit ที่พังหลุดออกไป คุณถือว่าเช็กที่ผ่านคือคำกล่าวอ้างที่ต้องพิสูจน์ให้ได้ และคุณออกแบบเผื่อวันที่แคชให้คำตอบผิด” บทบาทเปลี่ยนคลังศัพท์ สมมติฐาน และระดับความละเอียดที่ AI เลือกใช้

โครงสร้างของคำสั่ง ทีละส่วน

หัวข้อจริงในไฟล์ พร้อมหน้าที่ของแต่ละส่วน

• ข้อมูลที่ต้องเก็บ — เก็บข้อมูลที่ AI ไม่มีทางเดาเองได้ (แบ่งเป็น 7 ขั้น)
• วิธีทำงาน — กำหนดลำดับการคิดให้เป็นขั้นเป็นตอน (แบ่งเป็น 10 ขั้น)
• รูปแบบผลลัพธ์ — ล็อกหน้าตาของผลลัพธ์ (11 ข้อย่อย)
• ข้อห้าม — ปิดช่องที่ผลลัพธ์มักเพี้ยน (7 ข้อย่อย)

ทำไมถึงได้ผลนิ่งกว่าการพิมพ์ถามเอง

ยาวไม่ได้แปลว่าดี สิ่งที่ทำให้ผลนิ่งคือไม่เหลือช่องให้ AI เดา

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

ขั้นที่ 1 — เปิดไฟล์และเลือกเครื่องมือ

วางเนื้อหาไฟล์เป็นข้อความแรกของแชทใหม่ อย่าต่อท้ายบทสนทนาเดิม เพราะบริบทเก่าจะรบกวนกติกาในไฟล์ ใช้ได้ทั้ง ChatGPT, Claude และ Gemini

ขั้นที่ 2 — แทนค่าในวงเล็บทั้ง 7 จุด

มีช่องในวงเล็บ 7 จุด แต่ละจุดคือข้อมูลที่ AI เดาแทนคุณไม่ได้ ปล่อยไว้ตามเดิมจะได้คำตอบกลาง ๆ

ขั้นที่ 3 — รันและอ่านผล

AI จะรับบทเป็น DevOps Engineer / System Architect แล้วเดินตามหัวข้อ “วิธีทำงาน” ทีละขั้น ถ้าข้อมูลไม่ครบ AI จะถามกลับก่อน — นั่นคือคำสั่งทำงานถูกต้อง ไม่ใช่ข้อผิดพลาด

แก้ตรงไหนเมื่อผลลัพธ์ไม่ตรงใจ

แต่ละหัวข้อคุมพฤติกรรมคนละอย่าง แก้ทีละหัวข้อแล้วรันใหม่ ถ้ารื้อพร้อมกันหลายจุด จะไม่รู้ว่าอะไรได้ผล

ตัวแปรที่ต้องกรอกก่อนใช้งาน

แทนช่องในวงเล็บด้วยข้อมูลของคุณ ยิ่งเจาะจงยิ่งใช้ได้จริง (แสดง 6 จาก 7)

• [รูปร่างของ Repository]
• [Pipeline ปัจจุบัน]
• [ชุดทดสอบ]
• [นโยบายการรวมโค้ด]
• [เครื่องมือ Build]
• [เครื่องรันงาน]

ปรับความเข้มของข้อกำหนด

ตัวแปรครบแล้วผลยังไม่ตรง ปัญหามักอยู่ที่ข้อกำหนด ปรับทีละบรรทัด

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

คำสั่งนี้ต้องเตรียมข้อมูลก่อน

กรอกทุกวงเล็บให้ครบก่อนส่ง ส่งทั้งที่ยังว่างจะได้ผลกลาง ๆ ที่ต้องมาแก้อยู่ดี

ต่อเป็น Workflow หลายขั้น

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

หน้าตาของคำตอบ

หัวข้อ “รูปแบบผลลัพธ์” ล็อกรูปแบบไว้ 11 องค์ประกอบ ผลจึงมีโครงเดิมทุกครั้ง

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

สิ่งที่คำสั่งนี้จะไม่ทำ

ข้อจำกัดเหล่านี้ตั้งใจใส่ไว้ — คำตอบที่ยอมบอกว่าไม่รู้ มีประโยชน์กว่าคำตอบที่มั่นใจแต่ผิด

• “ข้อห้าม” ระบุสิ่งที่ห้ามทำไว้ชัดเจน 7 ข้อ คำตอบที่ข้ามข้อห้ามเหล่านี้ถือว่าไม่ผ่าน

วิธีดูว่ารอบนี้ได้ผลดีหรือยัง

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