แม้แต่บันทึกฉบับหลักของตัวเองเรื่อง Claude Code ก็มีวันหมดอายุ — สมมติฐาน 4 ข้อที่เปลี่ยนไปแล้ว ค้นพบจากการอ่านบันทึกรีลีสรายสัปดาห์ทุกฉบับ

บทนำ

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

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

ข้อค้นพบที่ 1: มีการเพิ่มกฎ deny แบบไร้เงื่อนไข ที่ข้ามตัวจำแนก

กฎสิทธิ์แบ่งเป็นแบบที่วิ่งผ่านการตัดสินของ AI (ตัวจำแนกที่ตัดสินบนพื้นฐานของบทสนทนาก่อนหน้า) กับแบบที่ไม่วิ่งผ่าน บันทึกรีลีสของสัปดาห์หนึ่งมีการตั้งค่าใหม่ของแบบหลัง

New settings.autoMode.hard_deny rules block matching actions unconditionally in auto mode, regardless of allow exceptions, for actions that should never run automatically even when broader allow rules apply

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

ข้อค้นพบที่ 2: การกระทำที่เคยถามมนุษย์ ตอนนี้ถูกยุติด้วยการตัดสิน

บันทึกรีลีสของอีกสัปดาห์หนึ่งอธิบายการเปลี่ยนแปลงที่ตัวกลไกการยืนยันความปลอดภัยเดิมเอง

In auto mode, the checks for dangerous rm commands, background jobs, and suspicious Windows paths no longer open permission dialogs; the auto-mode classifier adjudicates them instead

คำสั่งลบที่อันตราย, กระบวนการที่รันอยู่เบื้องหลัง และการดำเนินการกับพาธ Windows ที่น่าสงสัย เคยเปิดกล่องยืนยันให้มนุษย์ ตอนนี้ ไม่มีกล่องปรากฏ และการตัดสินของ AI เอง (ตัวจำแนก) เข้ามาแทนที่ ถ้าคุณถือสมมติฐานที่ว่า “การกระทำอันตรายจะถูกคนยืนยันเสมอ” สมมติฐานนั้นเปลี่ยนไปอย่างเงียบ ๆ ในวินาทีที่เวอร์ชันขึ้น

ข้อค้นพบที่ 3: การสลับโมเดลมีทริกเกอร์ต่างกัน 3 แบบ

ก่อนหน้านี้ ตอนอ่านเอกสารอีกฉบับ ฉันยืนยันเงื่อนไขหนึ่งที่โมเดลสลับอัตโนมัติไว้แล้ว คราวนี้ บันทึกรีลีสของอีกสัปดาห์หนึ่งเผยเงื่อนไขอีกแบบที่ชี้ไปยังปรากฏการณ์เดียวกัน

Claude Code now switches to your configured --fallback-model for the rest of the session when the primary model is not found, instead of failing every request

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

ข้อค้นพบที่ 4: เงื่อนไขจากต้นฉบับหายไปจากคำอธิบายที่ฉันเขียนเมื่อไม่กี่วันก่อน

ทุกอย่างจนถึงตรงนี้คือการเปลี่ยนแปลงในฝั่งผลิตภัณฑ์ ข้อค้นพบสุดท้ายวิ่งไปอีกทาง ในบทความก่อนหน้า ฉันเขียนสิ่งต่อไปนี้เกี่ยวกับฟีเจอร์ที่ “แตกงานภายในเซสชันโดยหอบบริบทของบทสนทนาไปด้วย”

The in-session forked subagent has been renamed to /subtask

ฉันตรวจสิ่งนั้นกับต้นฉบับของเอกสารทางการที่เกี่ยวข้อง ทีละตัวอักษร

A forked subagent, started with /subtask, is a subagent that inherits your full conversation context instead of starting fresh. … With agent view turned off, the forked-subagent command is /fork instead and /subtask isn’t available.

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

และแม้แต่เอกสารภายใน 2 ฉบับก็ยังต่างกันว่าเงื่อนไขนั้นมีอยู่หรือไม่

หลังพบการตกหล่นนั้น ฉันตรวจเอกสารอ้างอิงเชิงเทคนิคของอีกภาษาหนึ่งที่เขียนถึงฟีเจอร์เดียวกันเพื่อความชัวร์ ฉบับหนึ่งบอกว่า

Deprecated; ignored. Subagents inherit the parent session’s permission mode; agent-definition frontmatter may override it

อีกฉบับมีเงื่อนไขกำกับในรายการเดียวกัน

The mode field is deprecated and ignored on Claude Code v2.1.212 or later: subagents inherit the parent session’s permission mode, and a subagent definition’s permissionMode can override it, except when the parent uses bypassPermissions, acceptEdits, or auto, and Claude Code ignores a definition’s permissionMode: "bypassPermissions" when bypass mode is disabled by permissions.disableBypassPermissionsMode

แม้แต่เอกสารทางการ 2 ฉบับเกี่ยวกับฟีเจอร์เดียวกันของผลิตภัณฑ์เดียวกันก็ยังต่างกัน: ฉบับหนึ่งไม่มีอนุประโยคเงื่อนไข อีกฉบับมี อ่านฉบับเดียวแล้วหยุดตรงนั้น แล้วคุณก็จะทำงานต่อไปโดยเข้าใจข้อจำกัดที่มีเงื่อนไขผิดเป็นข้อจำกัดที่ไร้เงื่อนไข

เส้นทางที่ข้อค้นพบเดินผ่าน

จุดเริ่ม: บันทึกฉบับหลักถูกทำขึ้นครั้งหนึ่ง และถูกเปิดดูตั้งแต่นั้นมา
      │
      ├─▶ อ่านบันทึกรีลีสรายสัปดาห์จนจบทุกฉบับ เริ่มจากฉบับเล็กที่สุด
      │        ├─ ข้อค้นพบ 1: มีการเพิ่มกฎ deny ไร้เงื่อนไขที่ข้ามตัวจำแนก (hard_deny)
      │        ├─ ข้อค้นพบ 2: การกระทำที่เคยถามมนุษย์ถูกแทนที่ด้วยการตัดสิน (ตัวจำแนก)
      │        └─ ข้อค้นพบ 3: การสลับโมเดลมี 3 ทริกเกอร์ ระยะเวลาต่างกัน
      │
      └─▶ ถือโอกาสตรวจข้อความในบันทึกฉบับหลักกับต้นฉบับ ทีละตัวอักษร ★ ทิศทางเปลี่ยนตรงนี้
               └─ ข้อค้นพบ 4: อนุประโยคเงื่อนไขหายไปจากคำอธิบายที่เขียนเมื่อไม่กี่วันก่อน
                     │
                     └─▶ เพื่อความชัวร์ ตรวจรายการเดียวกันในเอกสารอ้างอิงเชิงเทคนิคของอีกภาษา
                              └─(เส้นย้อนกลับ)──▶ แม้แต่เอกสารภายใน 2 ฉบับก็ต่างกันว่าเงื่อนไขมีอยู่ไหม
                                                    └─ ⇒ ยุติ: "ตัวฉันเมื่อวาน" ก็ไม่ใช่แหล่งข้อมูลปฐมภูมิเช่นกัน

ใส่การกระทบยอดกับแหล่งข้อมูลปฐมภูมิเข้าไปในขั้นตอน

[การปฏิบัติงาน] การตรวจเชิงกลก่อนสะท้อนเอกสารลงบันทึกฉบับหลัก (สรุป)
1. นับคำที่คุณกำลังจะเพิ่มหรือแก้ ข้ามเอกสารหลัก 3 ฉบับที่มีอยู่
   → ถ้ามันมีอยู่แล้ว ให้บันทึกเป็น "การยืนยันซ้ำ" ไม่ใช่ "ข้อค้นพบใหม่"
2. สำหรับประโยคใดก็ตามที่คุณอ้าง ให้ค้นในไฟล์ต้นฉบับโดยตรงแล้วจับคู่ทีละตัวอักษร
   → ตรวจว่าอนุประโยคเงื่อนไข ("except when", "only when ... is enabled") ไม่ได้
     ตกหล่นไประหว่างการสรุป
3. ที่ใดที่มีหลายเอกสารครอบคลุมฟีเจอร์เดียวกัน อย่ายุติจากฉบับเดียว
   → อ่านทั้งสองฉบับ แล้วบันทึกตัวข้อเท็จจริงที่ว่า "ฉบับหนึ่งมีอนุประโยคเงื่อนไข"

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

การทำบันทึกฉบับหลัก กับการรักษาบันทึกฉบับหลัก เป็นงานคนละอย่าง

การอ่านบันทึกรีลีสรายสัปดาห์จนจบทำให้ชัดยิ่งกว่าข้อเท็จจริงที่เห็นอยู่แล้วว่าสเปกของผลิตภัณฑ์เปลี่ยนไปเรื่อย ๆ มันทำให้ชัดว่า คำอธิบายที่ฉันเขียนเริ่มเก่าลงตั้งแต่วินาทีที่ฉันเขียนมัน แทนที่จะทำเอกสารอ้างอิงครั้งเดียวแล้วเปิดดูอย่างสบายใจตลอดไป คุณต้องกลับไปที่ต้นฉบับเป็นครั้งคราวและกระทบยอดใหม่ทีละตัวอักษร การทำอย่างนั้นคราวนี้พบการเปลี่ยนแปลง 3 อย่างในฝั่งผลิตภัณฑ์ และความผิดพลาด 1 อย่างในฝั่งข้อความของฉันเอง — สมมติฐานที่เคลื่อนไป 4 ข้อในคราวเดียว

ตามรอยคำว่า “แคชพัง” ของ Claude Code กลับไปยังแหล่งข้อมูลปฐมภูมิ — รายงานบั๊กบน Reddit, postmortem ทางการ และงานวิจัย arXiv 2 ฉบับ

ทำไมฉันจึงเลิกใช้ orchestrator subagent ใน Claude Code — ข้อจำกัดเชิงโครงสร้าง 3 ข้อจากสเปกฮาร์เนสทางการ

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

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