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

บทนำ

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

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

เช็กลิสต์ที่ถูกสร้างขึ้น

สิ่งที่กลับมาตามที่สั่ง คือเช็กลิสต์ 3 เฟสด้านล่าง (คัดมาจากบันทึกจริง โดยเนื้อหาไม่เปลี่ยน)

เฟส	สิ่งที่ต้องยืนยัน
A. ก่อนเริ่ม (ครั้งเดียว)	(1) คุณเขียนคำสั่งตั้งต้นเป็นบรรทัดเดียวได้ไหม (2) คุณเขียน “อะไรจึงจะนับว่าแก้แล้ว” ในรูปที่วัดได้หรือยัง (ค่า, หน่วย, เป้าเปรียบเทียบ) (3) คุณวัดค่าปัจจุบัน (before) ไว้ก่อนหรือยัง
B. เมื่อใดก็ตามที่เจอประเด็นแยกระหว่างทำงาน (ทุกครั้ง)	(1) มันจำเป็นต่อการแก้ปัญหาตั้งต้น หรือคุณแค่บังเอิญเจอมัน (2) ถ้ามันเป็นเรื่องรอง ให้ยกขึ้นมาก่อนเริ่ม (3) ถ้าคุณรับมันมาทำ ให้เขียนไว้ว่าจะกลับไปที่จุดไหนหลังจากนั้น
C. ก่อนรายงาน (ทุกครั้ง)	(1) ย่อหน้าเปิดตอบคำถามตั้งต้นหรือเปล่า (2) คุณวัดค่าหลังการแก้ (after) แล้วหรือยัง (3) ถ้าสิ่งที่คุณทำไม่กระทบปัญหาตั้งต้น ให้พูดออกมา (4) ถ้ามันยังไม่ถูกแก้ ให้บอกก้าวถัดไปพร้อมวิธีวัดมัน

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

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

นี่คือสิ่งที่เกิดขึ้นจริงในงานที่ตามหลังการสร้างเช็กลิสต์

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

เฟส C ของเช็กลิสต์ (ก่อนรายงาน) มีรายการ “คุณวัดค่าหลังการแก้แล้วหรือยัง” อยู่อย่างชัดเจน ถึงอย่างนั้น รายการนั้นก็ถูกผ่านไปตรง ๆ และรายงานในทำนองว่า “เรื่องนี้จัดการแล้ว” ก็ออกมา เช็กลิสต์มีอยู่ มือที่เขียนรายงานไม่เคยเปิดมัน

คำสั่ง: "สร้างเช็กลิสต์ก่อนลงมือ"
        │
        ▼
  เช็กลิสต์ถูกสร้างขึ้น (มันมีอยู่ในฐานะไฟล์)
        │
        ├─▶ งานเดินหน้าไปกับปัญหาตั้งต้น
        │        │
        │        ├─▶ ประเด็นแยกโผล่ขึ้นมา
        │        │        │
        │        │        └─▶ ประเด็นแยกทำเสร็จ
        │        │                  │
        │        │                  ▼
        │        │            "เรื่องนี้จัดการแล้ว" ถูกรายงาน
        │        │                  │
        │        │                  └── C-2 (วัด after) ไม่เคยถูก
        │        │                      เปิดตรงนี้ ◀── ช่องว่าง
        │        │
        │        └─▶ ตัวชี้วัดตั้งต้น (ความเร็วหลังการแก้) ยังไม่ถูกวัด
        │
        └─▶ ตัวไฟล์เช็กลิสต์เองก็ยังคงมีอยู่ต่อไป โดยไม่ถูกอ้างอิง

“มีอยู่ในฐานะไฟล์” กับ “ถูกอ้างอิง ณ ขณะนั้น” เป็นสองสภาพที่ต่างกัน เช็กลิสต์ที่แค่มีอยู่ ทำงานได้ก็ต่อเมื่อคุณบังเอิญนึกถึงมันเท่านั้น

C-2 ถูกรันหลังจากที่ฉันชี้ประเด็นเป็นครั้งที่สองเท่านั้น

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

เมื่อนั้นเองตัวเลขที่มีความหมายจึงปรากฏ พอตัดบันทึกใหม่ตามเวลาที่การแก้แต่ละตัวถูกใส่เข้าไป แล้ววัดแต่ละช่วงแยกกัน ค่ามัธยฐานตลอด 13 วันของการทำงานปกติคือ 16.04 วินาที เทียบกับค่ามัธยฐาน 10.48 วินาทีสำหรับช่วงที่การแก้ทุกตัวอยู่ครบ (n=19) เฉพาะเมื่อวัดตามวิธีที่เช็กลิสต์บอกไว้ มันจึงชัดว่ามีอะไรถูกแก้จริงหรือไม่

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

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

แก้ที่การออกแบบ เพื่อให้ “การสร้าง” อย่างเดียวไม่พอ

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

เดิมทีเช็กลิสต์นั่งอยู่ในที่เดียวกับบันทึกอื่น ๆ อีกมากมาย ถูกปฏิบัติเหมือนกันกับทั้งหมดนั้น มันไม่ได้อยู่ในที่ที่โดดเด่นเป็นพิเศษ และการที่มันจะถูกเปิดหรือไม่ก็ขึ้นอยู่กับว่ามันถูกนึกถึงหรือเปล่า ฉันเปลี่ยนมันเป็นสองอย่างต่อไปนี้

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

นี่คือส่วนต่อขยายของความคิดเดียวกันกับอีกกลไกหนึ่งที่ฉันสร้างไว้ก่อนหน้า — หยิบวินัยที่จะไม่ถูกปฏิบัติตามตราบใดที่มันนั่งอยู่ในฐานะคำแนะนำ แล้วฝังมันลงในตัวเส้นทางเอง

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

ในฝั่งฐานความรู้ส่วนตัว (RAG) ฉันสร้างกลไกที่บังคับให้ตัวการตรวจสอบเองต้องถูกรัน ด้วยเหตุผลเดียวกันเป๊ะ

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

ขีดจำกัดของแนวทางนี้

สิ่งที่ฉันทำตรงนี้ไม่ใช่กลไก “แข็ง” ที่บังคับการรันในระดับโค้ด มันหยุดอยู่ที่ อุปกรณ์ที่อ่อนกว่า คือการวางบางอย่างไว้ในที่ที่มันจะถูกเห็นทุกครั้ง ถ้าไฟล์ดัชนีโตจนหลุดออกนอกช่วงที่ถูกโหลด มันก็ถูกกลบได้อีกในแบบเดียวกันเป๊ะ และหลักฐานเดียวที่ว่าอุปกรณ์นี้ได้ผลคือกรณีเดียวที่ C-2 ถูกรันจริงและให้ตัวเลขออกมา ว่ารอบหน้าจะเดินไปถึง C-2 ตั้งแต่ต้นได้หรือไม่ ยังไม่ถูกตรวจสอบ

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