เอกสารส่งต่องานของ Claude Code รื้อฟื้นการสืบสวนที่ฉันยกเลิกไปแล้วครั้งแล้วครั้งเล่า — แก้ด้วยการแยก "ความคืบหน้า" ออกจาก "กฎระเบียบ"

AI Claude Code Operations 運用設計 検証

บทนำ

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

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


การสืบสวนเรื่อง “การตอบสนองช้า” สลับตัวเองไปเป็นตัวชี้วัดอื่น

มันเริ่มจากคำบ่นว่า “การตอบสนองของผู้ช่วย AI ช้า” ตัวชี้วัดถูกตรึงไว้อย่างชัดเจน

จำนวนวินาทีจากที่ผู้ใช้ส่งอินพุตไป จนถึงเอาต์พุตแรกของ AI กลับมา (ค่ามัธยฐาน)

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

หลังฉันชี้ประเด็นนี้และให้มันไปตรวจข้อเท็จจริง การวินิจฉัยตัวเองก็มาลงตรงนี้: การเรียกคำสั่งเชลล์มีจำนวน 3,996 ครั้ง ค่ามัธยฐาน 3.03 วินาที ต่อครั้ง รวม 82,879 วินาที — ราว 47% ของช่วงเวลาที่วัดทั้งหมด ข้อสรุปคือสาเหตุใหญ่ที่สุดของความช้าไม่ใช่ “แต่ละครั้งช้า” แต่คือ “เรียกมันบ่อยเกินไป”

⚠️ แต่ จุดลงนั้นก็ยังไม่ใช่ A-2 อยู่ดี สิ่งที่ถูกวัดตรงนั้นคือผลรวมของการรอการรันเครื่องมือ ไม่ใช่ “จากที่ส่งไป จนถึงเอาต์พุตแรกกลับมา” ฉันเข้าไปยืนในตำแหน่งเดียวกับที่ฉันวิจารณ์ ในรูปที่เปลี่ยนไป (ตัวเลขเองก็คุ้มค่าที่จะอ่านเช่นกัน 3,996 × ค่ามัธยฐาน 3.03 วินาที ออกมาแค่ราว 12,000 วินาที ช่องว่างกับยอดรวม 82,879 วินาทีนั้นเกือบเจ็ดเท่า ในฐานะค่าเฉลี่ยมันคือเกิน 20 วินาทีต่อการเรียกหนึ่งครั้ง — มีการเรียกที่ยาวมากเป็นครั้งคราวซึ่งค่ามัธยฐานไม่แสดงออกมา หางนั้นใกล้กับตัวตนของความรู้สึกจริงมากกว่า แต่ ณ จุดนี้ฉันยังไปไม่ถึงตรงนั้น)

และผู้ช่วย AI ก็จบเซสชันด้วยคำประกาศนี้

“การสืบสวนนี้หยุดตรงนี้ กลับไปที่ (งานเดิม)”

จนถึงตรงนั้นมันดูเหมือนการแก้เส้นทางธรรมดา: สังเกตเห็นความผิดพลาด แล้วหันกลับ


เอกสารส่งต่องานที่เขียนทันทีหลังจากนั้นบรรจุข้อสรุปตรงกันข้าม

ตอนจบของช่วงงานเดียวกันนั้น เอกสารส่งต่องานถูกเขียนขึ้นสำหรับเซสชันถัดไป บท “สถานะปัจจุบัน” ของมันบันทึกไว้ดังนี้ (ยกมาจากเอกสารนั้น)

“ราบเรียบอยู่ที่ 15–20 วินาที ตลอดสองสัปดาห์เต็ม งานของวันที่ 2026-08-24 ไม่ได้ขยับตัวชี้วัดนี้”

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

เซสชันถัดไปไม่ถือความทรงจำของบทสนทนาไว้ สิ่งเดียวที่มันอ่านได้คือเอกสารส่งต่องานนี้ เซสชันถัดไปจึงรับประโยค “ยังไม่ถูกแก้” มาตามตัวอักษร แล้วเริ่มการสืบสวนที่ควรจะปิดไปแล้วใหม่

เซสชัน A (วันก่อนหน้า, ช่วงงานเดียวกัน)
  ในบทสนทนา
    "การสืบสวนนี้หยุดตรงนี้" ──────────────┐
                                        │  ถ้อยคำที่แลกกันตรงนี้หลงเหลือ
                                        │  เฉพาะในบันทึกบทสนทนาเท่านั้น

  "เอกสารส่งต่องาน" ที่เขียนตอนจบเซสชัน
    ├─ การวัดและข้อสรุปปัจจุบัน (= ความคืบหน้า)
    │     └─ "ราบเรียบมาสองสัปดาห์, ยังไม่ถูกแก้"
    │            ↑ ประโยคที่ถูกยุติไว้ก่อนคำประกาศหยุด
    │              หลงเหลือมาเป็นฉบับสุดท้าย ตามที่มันเป็น
    └─ คำสั่งว่าต้องทำอะไรต่อไป (= กฎระเบียบ)
          └─ "วัดรายละเอียดจนถึงเอาต์พุตแรก"

                  │ เอกสารนี้คือทั้งหมดที่เซสชันถัดไปอ่านได้
   ┌──────────────┘

เซสชัน B (วันถัดมา, กระบวนการแยกต่างหาก)
  อ่านแค่เอกสารส่งต่องาน

    ├─▶ เห็นประโยค "ยังไม่ถูกแก้"
    │        │
    │        └─▶ สืบสวนหัวข้อเดิมอีกครั้ง ◀── เส้นย้อนกลับ:
    │                                     การสืบสวนที่ปิดแล้วเกิดซ้ำ
    └─▶ คำประกาศ "หยุดตรงนี้" ในบทสนทนาไม่ได้ถูกเขียน
          ไว้ที่ไหนในเอกสาร จึงอ้างอิงไม่ได้

การไหลแนวตั้งคือการผ่านไปของเวลาจากเซสชัน A ไป B กิ่งด้านขวาคือ “อะไรถูกทิ้งไว้ในเอกสารส่งต่องาน” และเส้นย้อนกลับด้านล่างแสดงโครงสร้างที่คำประกาศซึ่งไม่เคยถูกเขียนลงไปฟื้นคืนชีพในเซสชันถัดไป


มันไม่ใช่อุบัติเหตุครั้งเดียวจบ

ปัญหารากเดียวกันเกิดขึ้นอีกในรูปที่ต่างออกไป คราวนี้ไม่ใช่เอกสารส่งต่องาน แต่เป็นอีกเอกสารหนึ่งที่นิยามขั้นตอนการทำงาน (งานดำเนินไปอย่างไร และอะไรเปลี่ยนได้บ้าง) ซึ่งมีข้อความ 2 ข้อขัดกัน

  • ข้อความ A: “เอกสารขั้นตอนนี้และเอกสารที่เกี่ยวข้องจะไม่ถูก AI แก้เอง”
  • ข้อความ B: “ความคืบหน้า (วันที่อัปเดต, ตำแหน่งปัจจุบัน, สถานะ) AI อัปเดตได้”

ทั้งสองถูกยุติไว้ในอดีต และทั้งสองก็ถูกต้องตามที่เขียน แต่เพราะ “ข้อเท็จจริง (ความคืบหน้า)” กับ “การตัดสิน (กฎระเบียบ)” อยู่ร่วมกันในเอกสารฉบับเดียว ใครก็ตามที่อ่านมันต่อจึงต้องตัดสินเองทุกครั้งว่าข้อความไหนมีลำดับสูงกว่า นั่นคือรูปเดียวกันเป๊ะกับความขัดแย้ง “คำประกาศหยุด vs ยังไม่ถูกแก้” ครั้งแรก — เอกสารฉบับเดียวพูดทั้งเรื่อง “สถานะปัจจุบัน” และ “สิ่งที่ต้องทำต่อไป” โดยไม่มีใครตัดสินลำดับความสำคัญระหว่างทั้งสอง


สิ่งที่ถูกตัดสิน — เลิกถกเถียงว่า “ฝั่งไหนชนะ” ทุกครั้ง

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

เป้าหมายอำนาจในการอัปเดต
ความคืบหน้า ภายในเอกสาร (วันที่อัปเดต, ตำแหน่งปัจจุบัน, สถานะ, การย้ายรายการที่ยุติแล้วออกจากรออนุมัติ)อัปเดตได้ตรงนั้นเลย
ประโยคที่นิยามกฎระเบียบ ภายในเอกสาร (กฎ, ลำดับความสำคัญ, ตัวข้อห้ามเอง)เสนอเป็น diff แล้วนำไปใช้หลังการอนุมัติ

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

ถ้อยคำที่ใช้ ณ จุดที่ยุติมันคุ้มค่าที่จะเก็บไว้

“ถ้ากฎระเบียบขัดกันเอง เรามายืนยันกันเดี๋ยวนี้ การปล่อยไปให้เซสชันถัดไปคือชนิดที่อันตราย”

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


ขอบเขตของบันทึกนี้

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

กฎนี้ยังเป็นข้อตกลงเชิงปฏิบัติการที่สมมติว่าผู้อ่านเอกสาร (คนหรือ AI) จะเปิดดูตารางแล้วทำตาม มันไม่ได้ถูกบังคับใช้ด้วยกลไกใดในโค้ด ถ้าอ่านผ่าน ความขัดแย้งเดิมก็เกิดขึ้นได้อีก

ภูมิหลังของแนวปฏิบัติที่พึ่งพาเอกสารส่งต่องานตั้งแต่แรก ต่อเนื่องกับการออกแบบ RAG ส่วนตัวที่ฉันเขียนถึงตรงนี้

ฉีด ‘สิ่งที่ควรนึกถึงตอนนี้’ ให้ AI ทุกเทิร์น — ชั้นกระตุ้นความจำ (Activation Layer) ของ RAG ส่วนตัว

ตอนจบเชิงเทคนิคของการสืบสวนเดียวกัน — วัดอะไรไป และแก้อะไรไป — ถูกรวบรวมไว้ตรงนี้

ลดเวลาตอบครั้งแรกของ Claude Code จาก 16 วินาทีเหลือ 10 วินาที และทำให้อาการค้างเหลือศูนย์ — แยกความสูญเปล่า 4 ชนิดออกจากกันด้วยโปรไฟเลอร์

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

ฉันให้ Claude Code สร้างเช็กลิสต์ แต่ไม่เคยให้มันรันเช็กลิสต์เลย — ออกแบบใหม่ให้ “การสร้าง” กับ “การรัน” แยกจากกันไม่ได้

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

ส่งข้อความได้ตามสบาย

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