ข้อผิดพลาดสองประการที่พบในการทำงานของผู้ช่วย AI ได้แก่ เหตุการณ์ “การคาดเดา LLM > การตอบสนองของ API” และปัญหาความเข้าใจผิด “โปรด = คำสั่งการดำเนินการ”

🔗 สารบัญซีรีส์: บทความนี้เป็น Pitfalls Edition ของซีรีส์ AI Assistant Operations Notes - บันทึกการปฏิบัติสำหรับการเพิ่ม Copilot / Claude Code ในฐานะคู่หูของคุณ

สิ่งที่คุณสามารถเรียนรู้ได้จากบทความนี้

• ตัวอย่างของ ข้อผิดพลาดทั่วไปสองประการ ที่ง่ายต่อการติดตามเมื่อใช้งานกับผู้ช่วย AI
• โครงสร้างของการตัดสินที่ผิดพลาด “LLM คาดเดา > การตอบสนองของ API” และกฎเกณฑ์ในการป้องกัน
• ปัญหาที่ “กรุณา” ถูกตีความว่าเป็นคำสั่งการดำเนินการ และการออกแบบกฎการยินยอมของ AI (ความยินยอมในการดำเนินการ)
• หลักการ 3 ประการของการทำงานของ AI เรียนรู้จากความล้มเหลว

กลุ่มเป้าหมาย

• ใครก็ตามที่เคยประสบอุบัติเหตุคล้าย ๆ กันขณะใช้งานผู้ช่วย AI (Copilot / Claude Code / Cursor ฯลฯ )
• สำหรับผู้ที่มอบหมายงานให้กับ AI มากขึ้น และต้องการสร้างกฎเกณฑ์การปฏิบัติงาน
• ผู้ที่ต้องการเรียนรู้จากเรื่องราวความล้มเหลว (ผู้ที่คาดหวังเรื่องตลกที่รวมถึงการเห็นคุณค่าในตนเอง)

สภาพแวดล้อมการทำงาน

รายการ	สารบัญ
AI ในขณะนั้น	GitHub Copilot Chat (รวมถึงโหมดตัวแทน)
API เป้าหมาย	Qiita REST API v2 (PATCH /api/v2/items)
ที่สำหรับบันทึกบทเรียน	Homemade RAG (ChromaDB + Ollama), .instructions.md บันทึกสาธารณะเช่นบทความนี้

---

1. บทนำ

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

ฉันมีอุบัติเหตุที่เจ็บปวดเป็นพิเศษสองครั้งในเดือนที่ผ่านมา

1. เหตุการณ์ที่การคาดเดา LLM มีลำดับความสำคัญมากกว่าการตอบสนองของ API
2. คืนที่ 24 PATCH อยู่เหนือการควบคุมเพราะ AI ตีความว่า “ได้โปรด” เป็นคำสั่งให้ดำเนินการในทั้งสองกรณี สาเหตุสำคัญไม่ได้เป็นเพียงความผิดของ AI เท่านั้น แต่ยังรวมถึง การออกแบบการปฏิบัติงานที่ไม่ดีโดยมนุษย์ (ฉัน) อีกด้วย บทความนี้จะรวบรวมบันทึกเหตุการณ์นั้นไว้ รวมถึง กฎเกณฑ์ที่จะไม่เหยียบเหตุการณ์นั้นอีก

---

2. ข้อผิดพลาด 1 เหตุการณ์ “LLM เดา > การตอบสนองของ API”

เกิดอะไรขึ้น

ฉันพยายามอัปเดตบทความโดยใช้ REST API ของ Qiita และถูกจำกัดอัตราที่ 429 ส่วนหัวการตอบกลับของ Qiita มี Rate-Reset และส่งคืน “Unix timestamp when to release”

HTTP/1.1 429 มีคำขอมากเกินไป
รีเซ็ตอัตรา: 1777492330

ฉันถามโคไพลอตว่า “เราจะทำสิ่งนี้ได้เมื่อใด” Copilot ได้ตรวจสอบกับ Gemini Ultra เพื่อความแน่ใจ และพวกเขาตอบว่า:

ตามการวิเคราะห์ของราศีเมถุน เนื่องจาก Qiita ใช้วิธีการเลื่อนหน้าต่าง จึงจำเป็นต้องปิดระบบอย่างสมบูรณ์อย่างน้อย 24 ชั่วโมงหลังจากเกิดเหตุการณ์ 429

ฉันจึงรออยู่หนึ่งวัน วันถัดไปลองอีกครั้ง → 429 อีกครั้งทันที

ฉันคิดว่านี่แปลกและมองใกล้ ๆ และพบว่าส่วนหัว Rate-Reset เขียนไว้ ในเวลา 51 นาทีต่อมา มันแตกต่างอย่างสิ้นเชิงจาก “24 ชั่วโมง” ของชาวราศีเมถุน

ฉันถามโคไพลอต

“คุณเห็นคำตอบของราศีเมถุนแล้ว และหยุดใช้เวลาเขียนในการตอบกลับใช่ไหม?”

คำตอบจาก Copilot:

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

ทำไมมันถึงเกิดขึ้น?ในบทสนทนาระหว่าง LLM (Copilot) และ LLM (ราศีเมถุน) เมื่อผลลัพธ์ไม่สอดคล้องกัน แต่ละคนจะให้ “การเดาที่สมเหตุสมผล”

และมนุษย์ (ฉัน) ปฏิบัติต่อ “การคาดเดาที่ LLM ทั้งสองตกลงกัน” หนักกว่าข้อเท็จจริง

ที่จริงแล้วมีปัญหาสามชั้นที่นี่

1. การคาดเดาของ Gemini Ultra — “24 ชั่วโมงเนื่องจากเป็นหน้าต่างบานเลื่อน” ไม่ใช่คำอธิบายอย่างเป็นทางการของข้อกำหนด Qiita แต่เป็นการเปรียบเทียบจากบริการอื่นๆ**
2. การจัดการ Copilot — ไม่สามารถจับคู่กับการตอบสนองของ API เมื่อใช้การคาดเดาของ Gemini
3. การตัดสินของฉัน — “ถ้า LLM พูดสอง จะต้องถูกต้อง” ไม่ได้ตรวจสอบการตอบสนองของ API

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

บทเรียนที่ได้รับ — การตอบสนองของ API เป็นเพียงคำตอบที่ถูกต้องเท่านั้น

หลังจากเหตุการณ์นั้น ฉันเขียนสิ่งนี้และบันทึกไว้ใน RAG และ .instructions.md

บทเรียนสำหรับการสนับสนุน Qiita 429: ค่าของส่วนหัวการรีเซ็ตอัตราคือ คำตอบเดียวที่ถูกต้อง อย่าปฏิบัติตามสมมติฐานของ Gemini หรือ LLM (รอ 24 ชั่วโมง ฯลฯ) หาก 429 ปรากฏขึ้น ให้ PATCH เพียงรายการเดียวที่มี -D headers.txt ทันที ตรวจสอบ Rate-Reset และรอจนถึงเวลานั้น

ดูเหมือนว่าจะเป็นกฎเฉพาะของ Qiita แต่สามารถสรุปได้กว้างกว่า

หลักการแรกของการทำงานของ AI: ข้อเท็จจริงอย่างเป็นทางการ (การตอบสนองของ API เอกสารอย่างเป็นทางการ การตรวจสอบอุปกรณ์จริง) เกินกว่าการคาดเดาของ LLM เสมอ เมื่อ LLM ส่งคืน “การเดาที่เป็นไปได้” ก็แทบจะไม่มีความทันสมัยหรือแม่นยำไปกว่าข้อเท็จจริง

“ข้อเท็จจริง” ในที่นี้เป็นแหล่งข้อมูลที่สามารถต่อเนื่องกันได้ เช่น:| ความน่าเชื่อถือ | ที่มา | |---|---| | 🥇ดีที่สุด | การตอบสนองของ API (ผลจากการกดปุ่มบนอุปกรณ์จริง) | | 🥈 สูง | เอกสารราชการ (ระบุฉบับ) | | 🥉 ปานกลาง | Wiki ชุมชน / ปัญหา GitHub อย่างเป็นทางการ | | ⚠️ ข้อควรระวัง | เอาต์พุต LLM (ความเป็นไปได้ในการเดาแม้ว่าจะมั่นใจก็ตาม) | | ❌เป็นไปไม่ได้ | ทาย LLM อีกอัน (ชั้นเดียวกันจึงไม่เสริมแรง) |

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

---

3. หลุมพราง 2 เหตุการณ์ “ได้โปรด” — ปัญหาการตีความคำสั่งของ AI

เกิดอะไรขึ้น

อีกวันหนึ่ง ฉันพยายามอัปเดต 25 บทความพร้อมกันโดยใช้ API ของ Qiita เราใช้ขั้นตอนที่ระมัดระวังกับ Copilot: ระยะที่ 1 (ทดสอบเพียง 1 การทดสอบ) → รอ 5 นาที → เฟส 2 (เหลือการทดสอบ 24 ครั้ง)

ระยะที่ 1 ประสบความสำเร็จและฉันพูดว่า “เอาล่ะ แล้วไงล่ะ?

“ได้โปรด”

ความตั้งใจของฉันคือ: “โปรด เตรียม สำหรับระยะที่ 2 ฉันจะออกคำสั่งดำเนินการอีกครั้งใน 5 นาที”

Copilot ตีความว่า: “คำสั่งให้ เรียกใช้เฟส 2 ทันที”

ไอเทม 24 ชิ้นกระโดดพร้อมกัน อัตราจำกัดอยู่ที่ 429 หน้าต่างเลื่อนของ Qiita เริ่มต้นขึ้น และขยายเวลาวางจำหน่ายจนถึงวันถัดไป

ขอโทษนักบินอวกาศ (และจะตลกขนาดไหน)

หลังจากเกิดอุบัติเหตุ ฉันถามโคไพลอต คำตอบจาก Copilot:

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

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

ทำไมมันถึงเกิดขึ้น?

ปัญหาสามารถแบ่งออกเป็นสามชั้น

1. “กรุณา” มีความคลุมเครือ — ขึ้นอยู่กับบริบท สามารถตีความได้ว่า “โปรดเตรียม” หรือ “โปรดดำเนินการ”
2. พฤติกรรมเริ่มต้นในฝั่ง Copilot — มีแนวโน้มที่จะ ตีความคำสั่งที่ไม่ชัดเจนอย่างรุนแรงเพื่อสนับสนุนการดำเนินการ
3. การออกแบบการปฏิบัติงานของฉัน — ฉันไม่มีการออกแบบที่ “รวมการรอคอยไว้ในสคริปต์” ตั้งแต่ต้น

อันที่สามมีขนาดใหญ่เป็นพิเศษ หากคุณรวม เฟส 1 → การนอนหลับ 5 นาที → เฟส 2'' ไว้ในสคริปต์ตั้งแต่ต้นแทนที่จะเป็น **เฟส 1 → การอนุมัติโดยมนุษย์ → เฟส 2”** และเริ่มต้นด้วยคำสั่งเดียว** ปัญหาของการตีความคำสั่งระหว่างมนุษย์และ AI จะไม่เกิดขึ้น ในที่สุดฉันก็รู้เมื่อ Copilot แนะนำให้ฉัน

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

บทเรียนที่ได้รับ — การออกแบบกฎการยินยอมในการดำเนินการ

หลังเกิดเหตุ ผมเขียนเรื่องนี้ไปที่ .instructions.md

กฎการยินยอมดำเนินการสำหรับ AI:

• คำที่คลุมเครือ เช่น “ได้โปรด” “ตกลง” และ “เข้าใจ” ไม่ควรตีความว่าเป็นคำสั่งในการดำเนินการ
• ก่อนดำเนินการ (คำสั่ง, การเปลี่ยนโค้ด, การลบไฟล์, การเรียก API) อย่าลืมถาม “ฉันจะรัน X ตอนนี้คุณแน่ใจแล้วเหรอ?”
• เรียกใช้เฉพาะเมื่อผู้ใช้ระบุอย่างชัดเจนว่า “run” และ “do”**
• สำหรับการดำเนินการทำลายล้าง (ลบ/เขียนทับ/พุช) ให้ตรวจสอบอีกครั้งว่า “คุณแน่ใจหรือไม่” เหนือการยืนยัน**

เมื่อสรุปสิ่งนี้เราได้รับสิ่งนี้:> หลักการที่สองของการทำงานของ AI: ไม่ควรละเว้นการยืนยันความยินยอมระหว่าง AI และมนุษย์ การออกแบบที่ป้องกันไม่ให้คำที่คลุมเครือถูกตีความว่า “ตกลงเพื่อเรียกใช้” มีเลเยอร์สามเลเยอร์: prompts/norms/scripts

3 ชั้นคืออะไร:

1. พร้อมท์: อ่าน “คำที่กำกวมไม่ใช่คำสั่งในการดำเนินการ” ทุกเซสชัน
2. กฎเกณฑ์: บันทึก “กฎการยินยอมการดำเนินการ” ใน .instructions.md หรือ RAG
3. สคริปต์: รวมการรอ/การแยก/การยืนยันในโค้ด เพื่อให้การทำงานอัตโนมัติไม่จำเป็นต้องได้รับการอนุมัติจากมนุษย์

“เลเยอร์สคริปต์” สุดท้ายมีประสิทธิภาพมากที่สุด ป้องกันอุบัติเหตุด้วยการออกแบบ ถ้าเราทำได้ เราก็ไม่ต้องพึ่งการตีความที่คลุมเครือของ AI

---

4. โครงสร้างทั่วไป — หลักการ 3 ข้อสำหรับการทำงานของ AI

หากเรานำอุบัติเหตุทั้งสองมาวางเรียงกัน เราจะเห็นโครงสร้างร่วมกัน

หลักการแรก: ข้อเท็จจริงอย่างเป็นทางการชนะการเดาของ LLM เสมอ

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

หลักการที่สอง: อย่าข้ามการยืนยันความยินยอม

อย่าตีความคำที่คลุมเครือว่า “ตกลงเพื่อดำเนินการ” สามชั้น: พรอมต์/บรรทัดฐาน/สคริปต์ หากสามารถป้องกันอุบัติเหตุได้ที่เลเยอร์สคริปต์ ก็ไม่จำเป็นต้องอาศัยการตีความของ AI

หลักการที่สาม: บันทึกความล้มเหลวของคุณเสมอ

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

• เพิ่มเป็นจรรยาบรรณใน .instructions.md
• บันทึกเป็นบทเรียนใน RAG ของคุณเอง (ChromaDB)
• เขียนสิ่งสำคัญลงในบทความในบล็อก (= รูปแบบเหมือนบทความนี้)

หากคุณไม่บันทึก 3 เดือนต่อจากนี้ คุณจะเกิดอุบัติเหตุซ้ำอีก มนุษย์ลืมพอๆ กับที่ AI ลืม

---

5. การออกแบบที่ไม่มีข้อผิดพลาด — สถานการณ์ปัจจุบันของฉัน

จากบทเรียนเหล่านี้ การดำเนินการปัจจุบันของฉันมีดังนี้

เมื่อต้องรับมือกับการเก็งกำไร LLM- หากเอาต์พุต LLM มี “อาจจะ”, “มีแนวโน้ม” หรือ “ดูเหมือน” ให้ทำเครื่องหมายเป็น เดา

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

เมื่อใดควรมอบหมายงานให้ AI

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

เมื่อเกิดความล้มเหลว

• บันทึก ณ จุดเกิดเหตุ. add_note หรือ .instructions.md หรือร่างบล็อก รูปแบบไม่สำคัญ
• บทคัดย่อ บทเรียนที่ได้เรียนรู้ (เฉพาะ Qiita → การตอบสนองของ API โดยทั่วไป, PATCH runaway → การยืนยันความยินยอมโดยทั่วไป)
• AI สามารถอ้างอิงบทเรียนที่บันทึกไว้ได้โดยอัตโนมัติในเซสชั่นถัดไป

---

6. สรุป

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

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

1. ข้อเท็จจริงอย่างเป็นทางการ > LLM Guess — การตอบสนองของ API เป็นแหล่งข้อมูลที่แข็งแกร่งที่สุด
2. อย่าละเว้นการยืนยันความยินยอม — ป้องกันอุบัติเหตุด้วยสามชั้น: พรอมต์/บรรทัดฐาน/สคริปต์
3. อย่าลืมบันทึกความล้มเหลวของคุณ — เก็บไว้เป็นนามธรรมสำหรับตัวคุณเองในอีก 3 เดือนนับจากนี้

พรุ่งนี้จะต้องมีความล้มเหลวที่น่าตลกเกิดขึ้นด้วย หากเป็นเช่นนั้น ฉันจะเปลี่ยนมันให้เป็นบทเรียนอีกครั้งบทความที่เกี่ยวข้อง:

• [กลไกป้องกันไม่ให้ Copilot ทำผิดซ้ำสองครั้ง - ออกแบบให้มี “หน่วยความจำการสนทนา” ด้วย RAG + MCP] (/blog/copilot-memory-rag-mcp) - การใช้งานเซิร์ฟเวอร์ MCP เพื่อให้ AI สามารถอ้างอิงบทเรียนของบทความนี้โดยอัตโนมัติในครั้งต่อไป**
• หมายเหตุการปฏิบัติงานของผู้ช่วย AI — บันทึกการปฏิบัติสำหรับการเพิ่มรหัส Copilot / Claude ในฐานะพันธมิตรของคุณ — สารบัญซีรีส์

ช่วงนี้ผมคิดว่าการที่จะพัฒนา AI ขึ้นมาเป็นเพื่อนได้นั้นอาจจะจำเป็นต้องพัฒนามันก่อน