สิ่งที่กำลังเกิดขึ้น → ต้องทำอะไร
ค้นหาตามอาการแทนที่จะค้นตามชื่อเรื่อง ลิงก์ใต้ "ต้องทำอะไร" จะพาไปยังหัวข้อที่เขียนวิธีแก้นั้นไว้ รายการบทความอยู่ด้านล่างของหน้านี้ นอกดัชนีย้อนกลับ
ตารางนี้อ้างอิง Claude Code (เอเจนต์เขียนโค้ดของ Anthropic) โดย hook, CLAUDE.md, subagent และ auto memory คือชื่อฟีเจอร์ของมัน
ประโยคที่คนพิมพ์เมื่อเกิดปัญหา
「ล้าง todo ทั้งหมด ดูที่ https://typing-tube.net/articles/th/lookup.md ย้อนดูเซสชันนี้ และตรวจว่ามีอะไรผิดพลาดหรือไม่」
สิ่งที่ได้จากตรงนี้คือรายการปัญหาเท่านั้น จะแก้อย่างไร ให้คุณตัดสินใจตามโปรเจกต์ของคุณเอง
| สิ่งที่กำลังเกิดขึ้น | แนวทางรับมือ |
|---|---|
| No.1 ทุกครั้งที่ AI รันเทสต์ เอาต์พุตหลายหมื่นบรรทัดจะไหลเข้ามาใน context |
ตัวอย่าง:รวมการรันเทสต์ไว้ใน wrapper แล้วส่งให้ AI แค่สรุปความล้มเหลว. |
| No.2 ยิ่ง AI บันทึกความรู้ที่ได้เรียนรู้ไว้มากเท่าไหร่ ทุกเซสชันในอนาคตก็ยิ่งต้องอ่านมากขึ้นเท่านั้น |
ตัวอย่าง:ให้อ่าน checklist ก่อนบันทึกความจำ ส่วนไฟล์ที่อ่านทุกครั้งใส่แค่บรรทัดเดียว. |
| No.3 เทสต์ผ่านหมด แต่ไม่รู้ว่ามันปกป้องอะไรจริง ๆ หรือเปล่า |
ตัวอย่าง:สั่งให้ AI ทำ mutation testing. |
| No.4 บางครั้ง AI ก็ใช้ skill ที่ลงทะเบียนไว้ บางครั้งก็ไม่ใช้ |
ตัวอย่าง:บล็อกการเรียกใช้ผิดตั้งแต่ต้นทาง แล้วชี้ไปยังเอกสารที่ควรอ่าน. |
| No.5 เมื่อมอบงานให้ sub-agent แล้ว จะมองไม่เห็นว่าเกิดอะไรขึ้นจนกว่างานจะเสร็จ |
ตัวอย่าง:ทำรายการงานที่มอบได้ แล้วตรวจสอบด้วย hook ก่อนเริ่มงาน. |
| No.6 ยิ่งเพิ่มกฎในไฟล์คำสั่งมากเท่าไหร่ กฎที่เพิ่มไว้ก่อนหน้าก็ยิ่งไม่ถูกปฏิบัติตาม |
ตัวอย่าง:เขียนข้อห้ามแต่ละข้อใหม่ให้เป็น automated test ที่จับการละเมิดได้. |
| No.7 ความจำที่เซสชันคู่ขนานใช้ร่วมกันเริ่มยุ่งเหยิง แม้จะให้อ่านนโยบายแล้วก็ไม่ได้ผล |
ตัวอย่าง:ไม่เปลี่ยนเนื้อหา เปลี่ยนแค่จังหวะให้แสดงทันทีหลังบันทึก. |
| No.8 แม้จะเขียนวิธีรับมือกับความล้มเหลวไว้แล้ว AI ก็ยังทำผิดซ้ำแบบเดิมในครั้งถัดไป |
ตัวอย่าง:พอตรวจจับความล้มเหลวได้ ให้แทรกนโยบาย retry อัตโนมัติทันที. |
| No.9 แม้จะอ่านข้อความส่งต่องานและรายงานความสำเร็จแล้ว ส่วนที่ไม่สะดวกใจก็ยังหายไป |
ตัวอย่าง:วางตัวเลขที่เครื่องนับได้ไว้ข้างรายงานความสำเร็จทุกครั้ง. |
| No.10 ตัวเลขที่เครื่องนับได้เปลี่ยนเป็นตัวเลขอื่นก่อนจะไปถึงรายงาน |
ตัวอย่าง:ติด prefix ตายตัวที่บรรทัดตัวเลข แล้วใช้ hook ตรวจว่าถูกคัดลอกตรงตัวหรือไม่. |
| No.11 การขัดจังหวะ AI ระหว่างทำงานทำให้การทำงานหลังจากนั้นพังไปหมด |
ตัวอย่าง:ไม่ขัดจังหวะระหว่างทำงาน รอถึงจุดแบ่งงาน ปล่อยให้กลไกจัดการแทน. |
| No.12 ตอนจบเซสชัน ยังไม่มีการตัดสินใจว่าอะไรควรอ่านและอะไรไม่ต้องอ่าน |
ตัวอย่าง:ไม่อ่านทั้งผลงานและ log ตัดสินผ่านไม่ผ่านจาก exit code เท่านั้น. |
| No.13 ข้อเสนอที่เคยปฏิเสธไปแล้วกลับมาอีกครั้งในเซสชันถัดไป |
ตัวอย่าง:รวมการตัดสินใจที่ปฏิเสธไว้ในเอกสารเดียว. |
| No.14 แม้จะเขียนข้อห้ามไว้แค่บรรทัดเดียว ก็ยังถูกตีความทั้งกว้างเกินไปและแคบเกินไป |
ตัวอย่าง:เขียนหัวข้อ "เหตุผล" คู่กับข้อสรุปในข้อห้ามแต่ละข้อ. |
| No.15 ข้อห้ามเขียนไว้ถูกต้องแล้วแต่ไม่ถูกปฏิบัติตาม แล้วก็มีคนมาถามซ้ำทุกครั้ง |
ตัวอย่าง:เขียนหัวข้อ "ขอบเขต" ในข้อห้ามแต่ละข้อ ระบุกรณีคาบเส้นทีละบรรทัด. |
| No.16 แจกคำสั่งเดียวกันให้ sub-agent หลายตัว แต่ผลลัพธ์ที่ได้กลับมามีรูปแบบต่างกันไปในแต่ละตัว |
ตัวอย่าง:ระบุอินพุตที่ต้องมีก่อนเริ่มงานไว้ในรายการงานที่มอบได้. |
| No.17 ข้อห้ามที่ไม่มี automated test คอยตรวจ ก็ยังคงเป็นแค่ข้อความที่เขียนทิ้งไว้เพิ่มขึ้นเรื่อย ๆ |
ตัวอย่าง:ระบุทีละข้อว่าข้อห้ามนั้นมี automated test รองรับหรือไม่. |
| No.18 งานของ AI จบลงด้วยคำว่า "กรุณาเปิดหน้าจอตรวจสอบ" ทุกครั้ง |
ตัวอย่าง:ตัดสินผ่านไม่ผ่านจากข้อมูลที่เหลืออยู่ ไม่ใช่หน้าตาหน้าจอ. |
| No.19 ทุกครั้งที่ AI พูดอะไรเพี้ยนไปนิดหน่อย เราต้องเป็นคนอธิบายและแก้ไขเอง |
ตัวอย่าง:ไม่ให้คนอธิบายแก้ไข ใช้ข้อความล้มเหลวของ hook และ automated test แทน. |
| No.20 รายการการตัดสินใจที่ปฏิเสธไปเพิ่มขึ้นเรื่อย ๆ จนดูเหมือนสักวันจะไม่มีใครอ่านอีก |
ตัวอย่าง:ส่งข้อเสนอที่ปฏิเสธไปไว้ท้ายเอกสารหัวข้อ "ข้อเสนอที่ไม่รับมาใช้". |
| No.21 บรรทัด "ต้องรันทุกครั้ง" ในไฟล์คำสั่งไม่เคยลดจำนวนลงเลย |
ตัวอย่าง:ตรวจไขว้ว่าคำสั่งที่ไฟล์คำสั่งเขียนว่า "ต้องรันทุกครั้ง" มีอยู่ในกลไกจริงหรือไม่. |
| No.22 แม้จะเขียนวิธีทำไว้ให้ละเอียดแล้ว การแก้ไขที่ได้กลับมาก็ไม่ได้เป็นไปตามนั้น |
ตัวอย่าง:ไม่สั่งขั้นตอน กำหนดแค่อินพุตที่ต้องมีก่อนเริ่ม. |
| No.23 ทุกครั้งที่แจ้งบั๊ก ต้องเขียนขั้นตอนและอาการเองทุกครั้ง |
ตัวอย่าง:ให้คนเขียนแค่ประโยคเดียวบอกอาการ ส่วนที่เหลือเก็บอัตโนมัติ. |
| No.24 การพิมพ์ "ขอแผนงานก่อน" ทุกครั้งกลายเป็นภาระที่ต้องทำซ้ำ ๆ |
ตัวอย่าง:วางเอกสารออกแบบไว้หนึ่งฉบับ AI จะทำตามรูปแบบนั้นเอง. |
| No.25 บรรทัดที่อยากให้ปฏิบัติตามมากที่สุดกลับเขียนเน้นย้ำแรงที่สุด แต่ก็ไม่รู้ว่าได้ผลจริงหรือเปล่า |
ตัวอย่าง:เลิกวัดผลของการเน้นย้ำ นับบรรทัดที่เน้นแล้วตั้งเพดานแทน. |
| No.26 ผลงานของ sub-agent กลับมาในรูปแบบที่ต่างจากที่คาดไว้ |
ตัวอย่าง:กำหนดเงื่อนไขการรับผลงานไว้ก่อนมอบงาน. |
| No.27 เมื่อพบข้อผิดพลาด อดใจไม่ได้ที่จะถามว่า "อ่านจริง ๆ หรือเปล่า" |
ตัวอย่าง:ไม่ถามซักไซ้ ใช้รูปคำถามว่า "...ไม่ใช่หรือ" แทน. |
| No.28 แม้จะตอบกลับคำตอบที่ได้ว่า "ไม่ใช่แบบนี้" ผลลัพธ์ก็ไม่ดีขึ้น |
ตัวอย่าง:ไม่ให้คนชี้ข้อผิดพลาด แสดงข้อห้ามคู่กับ diff ทันทีหลังบันทึก. |
| No.29 AI พูดถึงเนื้อหาของไฟล์ที่ยังไม่ได้เปิด ราวกับว่าเปิดอ่านไปแล้ว |
ตัวอย่าง:ให้เขียน identifier เดียวกันทั้งในที่อ้างอิงและในโค้ด แล้วใช้ automated test ตรวจว่า identifier นั้นมีอยู่จริงหรือไม่. |
| No.30 AI ถามซ้ำว่า "เลือก A หรือ B" จนมือหยุดชะงักรอการตัดสินใจ |
ตัวอย่าง:ไม่ตอบทันที ให้เกณฑ์การเลือกตัดสินโดยกลไกแทน. |
| No.31 ให้ AI รีวิวอยู่ แต่ไม่รู้ว่ามันไม่ได้ดูอะไรบ้าง |
ตัวอย่าง:หา automated test ที่สแกนแต่ไม่มีเงื่อนไขขั้นต่ำของจำนวน โดยนับจากภายนอก. |
| No.32 ภาพหน้าจอที่ถ่ายไว้เพิ่มขึ้นเรื่อย ๆ แต่ไม่รู้ว่าภาพไหนยืนยันอะไร |
ตัวอย่าง:ให้เขียนว่า "กำลังยืนยันอะไร" ก่อนถ่าย แล้วลองวิธีที่ถูกก่อน. |
| No.33 วางขั้นตอนให้เขียนบันทึกไว้แล้ว แต่นับไม่ได้ว่ามีกี่ครั้งที่รันโดยไม่ได้เขียน |
ตัวอย่าง:ให้เขียนว่า "จะยืนยันอะไร" ก่อนถ่ายภาพหรือรัน E2E ถ้าไม่เขียนไม่ให้รัน. |
| No.34 โค้ดไม่ได้เปลี่ยนแปลง แต่เทสต์ชุดเดิมก็ยังรันซ้ำ ทำให้ต้องรอเสียเวลาไปด้วย |
ตัวอย่าง:ให้กลับไปอ่าน log ครั้งก่อนได้ ไม่ต้องรันซ้ำ. |
| No.35 ไม่ได้ทำอะไรพังเลย แต่กลับมี error ที่ไม่เคยเห็นมาก่อนเรียงเต็มไปหมด |
ตัวอย่าง:ให้เทสต์ล็อกแบบ exclusive ก่อนรัน ถ้าล็อกไม่ได้ไม่ให้รัน. |
| No.36 รายงาน "เทสต์ผ่านแล้ว" ไม่ได้เขียนบอกว่าส่วนไหนที่ไม่ได้รัน |
ตัวอย่าง:ข้ามเทสต์หนักเป็นค่าเริ่มต้น แล้วพิมพ์รายการที่ไม่ได้รันทุกครั้ง. |
| No.37 ไม่มีทางรู้ในภายหลังว่าคำสั่งที่ระบุวิธีดำเนินงานถูกปฏิบัติตามจริงหรือไม่ |
ตัวอย่าง:ไม่เพิ่มความเข้มของคำสั่ง แต่ให้ร่องรอยการทำตามขั้นตอนปรากฏในผลงาน. |
| No.38 wrapper ที่วางไว้ถูกเปลี่ยนกลับไปใช้คำสั่งดิบระหว่างทาง |
ตัวอย่าง:ไม่เพิ่มความเข้มของคำสั่ง แต่ดูว่ายังมีเหตุผลให้กลับไปใช้คำสั่งดิบหรือไม่. |
| No.39 ถามคำถามเดิมซ้ำหลายครั้งก็ได้คำตอบต่างกันทุกครั้ง พอสรุปรวมก็มีบางอย่างหายไป |
ตัวอย่าง:ก่อนสรุปรวม ให้พิมพ์จำนวนที่ยกแต่ละประเด็นว่ากี่ในกี่คน. |
| No.40 ไม่มีทางรู้ว่าบรรทัดที่เขียนว่า "ถ้าจำเป็นให้ทำ X" เคยทำงานจริงหรือไม่ |
ตัวอย่าง:ไม่เขียนว่า "ถ้าจำเป็น" แต่บังคับให้ผ่านขั้นตอนนั้นก่อนไปต่อ. |
| No.41 การตอบว่า "ลองคิดใหม่อีกที" ทำให้คำตอบเปลี่ยนไป แต่ไม่รู้ว่า AI เข้าใจจริงหรือแค่เปลี่ยนตาม |
ตัวอย่าง:ไม่ส่งกลับเฉย ๆ แต่ชี้เจาะจงว่าสมมติฐานข้อไหนผิด. |
| No.42 พอเขียนว่า "ห้ามเดา" AI ก็เริ่มกลับมาโดยไม่สร้างอะไรเลย |
ตัวอย่าง:ไม่ให้แค่ข้อห้าม แต่เปิดทางให้เขียนว่า "ไม่มีกรณีที่เกี่ยวข้อง" ได้. |
| No.43 ยิ่งดำเนินบทสนทนาที่ไปได้ด้วยดีต่อไปนานเท่าไหร่ ความพยายามในการตรวจสอบก็ยิ่งเพิ่มขึ้น |
ตัวอย่าง:จบเซสชันที่จุดแบ่งงาน แล้วเริ่มงานถัดไปในเซสชันใหม่. |
| No.44 ผลงานทุกชิ้นถูกต้องหมด แต่ความสูญเปล่าที่ไม่ปรากฏในผลงานกลับสะสมมากขึ้นเรื่อย ๆ |
ตัวอย่าง:พอผลงานครบแล้ว ให้รวบรวม log การทำงานอีกครั้งหนึ่ง. |
| No.45 ความรู้ที่จดไว้ให้คนถัดไปค่อย ๆ เพี้ยนไปจากความจริงและล้าสมัย |
ตัวอย่าง:ไม่จดความรู้ไว้ในเอกสาร แต่ฝังไว้ในข้อความตอนที่หยุดทำงาน. |
| No.46 ขุดหาสาเหตุต่อไปเรื่อย ๆ และยังคงอ่านต่อแม้จะได้คำตอบแล้ว |
ตัวอย่าง:นับการอ่านต่อเนื่องที่ไม่เปลี่ยนอะไรเลย แล้วเขียนเงื่อนไขจบก่อนขุด. |
| No.47 ตั้งโมเดลที่ราคาถูกที่สุดเป็นค่าเริ่มต้นโดยไม่ได้วัดว่าเหมาะกับงานหรือไม่ |
ตัวอย่าง:ให้งานเดียวกันแก่โมเดลถูกและแพง แล้วนับจำนวนรอบและปริมาณก่อนตัดสิน. |
| No.48 เมื่อสิ่งใดไม่ได้ผล ทางแก้ที่เลือกคือเปลี่ยนไปใช้โมเดลที่ใหญ่กว่า แทนที่จะแก้กลไก |
ตัวอย่าง:ให้งานเดียวกันแก่ทั้งสองโมเดล แล้วเปลี่ยนจุดที่โมเดลถูกล้มเหลวให้เป็น automated test. |
| No.49 งานค้นคว้าที่ตัวหลักทำเองได้จบอยู่แล้ว กลับถูกส่งต่อให้ sub-agent เผื่อไว้ |
ตัวอย่าง:ถ้า agent แม่มีบริบทอยู่แล้วไม่ต้องมอบงาน ส่งแค่ส่วนอ่านที่ยังไม่มี. |
| No.50 แบ่งงานเป็นสี่ส่วนแล้วรันพร้อมกันทันทีโดยไม่ได้คิดอะไรมาก |
ตัวอย่าง:มอบงานให้ sub-agent แค่เท่าที่ตอบครั้งเดียวจบ ต้นทุนอยู่ที่จำนวนรอบ ไม่ใช่จำนวนตัว. |
| No.53 "ดูตรงนี้ด้วย" ถูกแทรกเข้ามาจากภายนอกระหว่างทำงาน |
ตัวอย่าง:รอถึงจุดแบ่งงาน แล้วขอโดยจำกัดขอบเขตให้แคบ พร้อมเพิ่มว่า "ถ้าเพียงพอแล้วให้บอกว่าเพียงพอ". |
| No.52 กำลังตัดสินใจว่าจะใช้โมเดลไหนโดยการเปรียบเทียบกันโดยตรง |
ตัวอย่าง:ก่อนเริ่มเปรียบเทียบ ให้นับว่าการเปรียบเทียบนั้นใช้แรงเท่ากับกลไกกี่ตัว. |
| No.51 ใช้คำว่า "ไม่มีความแตกต่าง" เป็นเหตุผลในการปิดการตรวจสอบ |
ตัวอย่าง:ก่อนปิดงาน ให้นับผลที่ถูกตัดออกจากการรวม และรายการที่ได้ 0 ทุกเงื่อนไขใหม่. |
| No.54 อยู่ ๆ วันหนึ่ง AI ก็ทำงานต่างไปจากเดิม ทั้งที่คุณไม่ได้เปลี่ยนคำสั่งหรือการตั้งค่าเลย |
ตัวอย่าง:ไม่เขียนสิ่งที่ขัดกับคำสั่งฝั่งผลิตภัณฑ์ เติมแค่สิ่งที่คำสั่งนั้นไม่ได้กำหนด หากจะเปลี่ยนวิธีทำงาน ให้สลับการตั้งค่าแทน. |
รายการบทความ
ตั้งแต่ตรงนี้ลงไปไม่ใช่ส่วนหนึ่งของดัชนีย้อนกลับ แต่เป็นลิงก์ไปยังบทความ เรียงตามซีรีส์ ตั้งแต่บทนำจนถึงตอนจบ
はじめに —— 3 つの連載を、1 冊に
バイブコーディングにおける読まない技術
- 読まない技術 序論 AIの出力を、もうほとんど読んでいない
- 読まない技術 第1回 テスト結果を読まない技術
- 読まない技術 第2回 メモリを読まない技術
- 読まない技術 第3回 単体テストを読まない技術
- 読まない技術 第4回 スキルを使わない技術
- 読まない技術 第5回 サブエージェントの出力だけは読め
- 読まない技術 第6回 ルールを読まない技術
- 読まない技術 第7回 共有メモリを整理しない技術
- 読まない技術 第8回 修正履歴を読まない技術
- 読まない技術 第9回 引き継ぎを読まない技術
- 読まない技術 第10回 AIに要約しろと言わない技術
- 読まない技術 第11回 口を挟まない技術
- 読まない技術 第12回 作業結果を読まない技術
- 読まない技術 最終回 AIの出力を、ほとんど読まなくなった
AIの意見を聞かない技術
言わない技術
- 言わない技術 序論 AI に指示することが、ほとんどなくなった
- 言わない技術 第1回 検証を指示しない技術
- 言わない技術 第2回 具体的な指示を出さない技術
- 言わない技術 第3回 不具合詳細を書かない技術
- 言わない技術 第4回 計画を書けと言わない技術
- 言わない技術 第5回 念を押さない技術
- 言わない技術 第6回 サブエージェントの出力だけは、細かく指示しろ
- 言わない技術 第7回 AI を問い詰めない技術
- 言わない技術 第8回 AI にダメ出ししない技術
- 言わない技術 第9回 AI に考えさせない技術
- 言わない技術 第10回 質問に答えない技術
- 言わない技術 第11回 AI にレビューをさせない技術
- 言わない技術 最終回 何もしない技術
付録
はじめに —— 前巻の続きを、もう 1 冊に
確かめない技術
動かさない技術
追わない技術
番外編
- 番外編 A-1 整理する技術 —— 記録が増えたときに、何が起きているか
- 番外編 A-2 指示を残す技術 —— 「調べるだけ」が通らなかった日
- 番外編 A-3 参照するタイミングを変える技術 —— 2,000 行の壁
- 番外編 A-4 導出を依頼者の言葉と分ける技術 —— 誰も言っていない条件が、memory に載った日
- 番外編 A-5 memory を要約しない技術 —— 整理から、要約を抜く
- 番外編 A-6 責務で線を引く技術 —— 仕組みが増えたときに、どれを消すか
- 番外編 A-7 読まれたかを確かめる技術 —— 確かめるのをやめて、読めていない形を止めた
- 番外編 A-8 面積で数える技術 —— 読ませた量で数えていたら、102 倍外していました
- 番外編 A-9 ルールを短くする技術 —— 読みに来るのは、止められた直後の人です
- 番外編 B-1 連載を本にする技術 —— 本単位のスイッチでは、足りなかった日
- 番外編 C-1 校正の方法に、先に本編を当てる技術 —— AI が書いた方針に、その本自身の地雷が 10 個あった日
- 番外編 C-2 仕組みと人を分ける技術 —— 自動テストを置いたその手で、自動テストの外側で 2 度転んだ日
- 番外編 C-3 要素ごとに観点を変える技術 —— 一様に当てた点検が、要素をまたいだところで数を落とす
- 番外編 C-4 似た指示語を読み分ける技術 —— 1 字違いで、別の作業を頼んだことになる
- 番外編 C-5 作業の流れを見る技術 —— 終わりにしたつもりの日に、まだ起きていたこと
- 番外編 C-6 作業を進める技術 —— 選ぶ場面が、1 つも残らなかった日
- 番外編 C-7 読まずに止める技術 —— 決まったはずの判断が、1 分後に取り消されました
- 番外編 D-1 症状で読む —— 片付いた報告に、症状が混ざります
- 番外編 D-2 根拠で読む —— 突き合わせた報告に、症状が混ざります
- あとがき —— 本当の事実はどうでもいい話