Claude Opus 4.7 1M context อ่าน repo ทั้งโปรเจกต์ได้แค่ไหน

ทำไม 1M context ไม่เท่ากับ “ทั้ง repo เสมอไป”

repo จริงไม่ใช่ไฟล์ข้อความสะอาด ๆ ไฟล์เดียว งานวิเคราะห์ codebase ที่มีประโยชน์มักต้องดูหลายอย่างพร้อมกัน เช่น README, config, tests, dependency manifests, CI errors, stack traces, search results และผลลัพธ์จากเครื่องมืออื่น ๆ ทั้งหมดนี้กิน context เหมือนกัน

อีกจุดที่มองข้ามไม่ได้คือ output ถ้าคุณต้องการให้โมเดลสรุป architecture, ไล่ความเสี่ยง, เสนอ test strategy หรือสร้าง patch ขนาดใหญ่ การใส่ input จนเกือบเต็ม 1M tokens อาจทำให้เหลือพื้นที่ตอบไม่พอ แม้ Opus 4.7 จะรองรับ output สูงสุด 128k tokens ก็ตาม

และใน Opus 4.7 ต้องระวังเรื่อง tokenizer เป็นพิเศษ เพราะ Anthropic ระบุว่า tokenizer ใหม่อาจใช้ tokens มากขึ้นประมาณ 1x ถึง 1.35x สำหรับข้อความเดียวกันเมื่อเทียบกับโมเดลก่อนหน้า repo ที่เคยประเมินว่า “น่าจะพอดี” ด้วยตัวนับของรุ่นเก่า อาจไม่พอดีเมื่อใช้ Opus 4.7 จริง

คำว่า “เสถียร” ควรเข้าใจแค่ไหน

มองในแง่ดีได้ แต่ไม่ควรพูดเป็นคำมั่นแบบเด็ดขาด

Anthropic วาง Opus 4.7 ไว้สำหรับงาน agentic workflow ที่ซับซ้อน งานที่รันยาว และ codebase ที่ใหญ่ขึ้น อีกทั้งข่าวเปิดตัวยังบอกว่ารุ่นนี้รับมือ complex, long-running tasks ได้ด้วยความรอบคอบและสม่ำเสมอ

อย่างไรก็ตาม ข้อมูลเหล่านี้สนับสนุนข้อสรุปที่ระมัดระวังมากกว่า: Opus 4.7 ถูกวางให้เหมาะกับงานบริบทยาว งานโค้ดยาว และ workflow หลายขั้นตอนมากขึ้น แต่ไม่ได้พิสูจน์ว่า repo ทุกแบบ, input ทุกขนาด และ agent loop ทุกลักษณะจะเสถียรแบบรอบเดียวจบ

ถ้าเป็นงานจริงจัง เช่น security audit, CI/CD auto-fix, refactor ใหญ่ หรือ agent ที่ทำงานต่อเนื่องนาน ๆ ควรทดสอบกับ repo จริง ชุดทดสอบจริง และกรณีล้มเหลวจริงของทีมคุณเอง

ถ้าจะให้ Opus 4.7 สแกนทั้ง repo ควรทำอย่างไร

1. เริ่มจากทำแผนที่ไฟล์ ไม่ใช่โยนทั้งโปรเจกต์ทันที

ให้สร้างรายการไฟล์และโฟลเดอร์สำคัญก่อน เช่น entry points, modules หลัก, tests, config, dependency files และไฟล์ที่เพิ่งเปลี่ยน จากนั้นค่อยเลือกสิ่งที่ควรเข้า context จริง ๆ

โดยทั่วไปควรตัด build artifacts, generated files, vendor folders, cache, binary files, logs ยาว ๆ และไฟล์ซ้ำออกก่อน เพราะไฟล์เหล่านี้มักกิน context โดยไม่ได้ช่วยให้โมเดลเข้าใจ logic หลักของระบบมากนัก

2. นับ tokens ด้วย Opus 4.7 โดยตรง

อย่าใช้ token count จาก Opus 4.6 หรือโมเดลอื่นมาแทน Anthropic ระบุว่า tokenizer ของ Opus 4.7 อาจใช้ประมาณ 1x ถึง 1.35x tokens และ endpoint /v1/messages/count_tokens จะให้ผลต่างจาก Opus 4.6

3. อย่าใช้ context จนเต็มเพดาน

ถึง input จะใส่ได้พอดี ก็ไม่ได้แปลว่างานจะออกมาดีเสมอไป ถ้าต้องการรายงานละเอียด แผนแก้ไขหลายไฟล์ หรือ patch ขนาดใหญ่ ต้องกันพื้นที่ไว้ให้ output ด้วย เพราะ Opus 4.7 มี output สูงสุด 128k tokens

4. repo ใหญ่ควรใช้ workflow แบบเป็นขั้น

สำหรับโปรเจกต์ใหญ่ วิธีที่มักปลอดภัยกว่าคือให้โมเดลเข้าใจ architecture ก่อน แล้วค่อยอ่านไฟล์สำคัญทีละชุด ค้น reference ตรวจ tests และดู logs ตามลำดับ แนวทางนี้สอดคล้องกับการวางตำแหน่ง Opus 4.7 สำหรับ complex agentic workflows และ larger codebases

5. ให้โมเดลรายงานขอบเขตที่อ่านเสมอ

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

สรุปสุดท้าย

Claude Opus 4.7 รองรับ 1M token context window และ output สูงสุด 128k tokens จริงตามข้อมูลทางการ Anthropic ยังวางรุ่นนี้ไว้กับงาน long-running, agentic workflow และ codebase ที่ใหญ่ขึ้น

ดังนั้น ถ้า repo ทั้งหมดรวมกับ prompt, ประวัติสนทนา, tool results และพื้นที่ output แล้วยังอยู่ในลิมิต การวิเคราะห์แบบรอบเดียว อาจทำได้ แต่ถ้า repo ใหญ่ มี noise มาก หรือคุณต้องการคำตอบยาวและการแก้ไขหลายไฟล์ วิธีที่รอบคอบกว่าคือคัดไฟล์ แบ่งงาน และตรวจผลด้วย test จริง ไม่ใช่ตัดสินจากเลข 1M อย่างเดียว