สรุปจากคลิป ดูคลิปต้นฉบับ

วิธีไม่ให้ติด Claude Session Limit อีก พร้อมแนวคิดลดค่าใช้จ่าย AI

ปัญหาของคนใช้ Claude ไม่ได้อยู่แค่เรื่อง prompt ดีหรือไม่ดี แต่อยู่ที่การใช้ token แบบไม่รู้ตัวด้วย หลายคนคิดว่ามี context window ใหญ่ถึง 1 ล้าน token แล้วน่าจะสบาย แต่ความจริงกลับตรงข้าม ยิ่งปล่อย session ยาว ยิ่งเปลือง ยิ่งมั่ว และยิ่งทำให้ AI ตอบแย่ลง

ประเด็นนี้ถูกอธิบายไว้ชัดมากในคลิปของ Nate Herk | AI Automation ที่พูดเรื่อง Claude session limit แบบลงมือใช้งานจริง ไม่ใช่แค่ทฤษฎี จุดที่น่าสนใจคือเขาไม่ได้สอนแค่ “ลด token ยังไง” แต่กำลังชี้ให้เห็นว่า ถ้าเราใช้ AI แบบคนทำงานหรือเจ้าของธุรกิจ เราควรออกแบบ workflow ใหม่ทั้งระบบ เพื่อให้ AI คุ้มค่าและยังคงคุณภาพงาน

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

สารบัญ

• Step 1: เข้าใจก่อนว่า token ไม่ได้ถูกใช้แบบตรงไปตรงมา
• Step 2: ระวัง context rot เพราะยิ่ง session ยาว AI ยิ่งหลุดประเด็น
• Step 3: อย่ารอให้ auto-compaction จัดการ เพราะมันมาช้าเกินไป
• Step 4: ใช้ Rewind, Clear, Compact และ Subagent ให้ถูกจังหวะ
• Step 5: วางระบบ session ให้เหมือนงานเป็นเฟส ไม่ใช่กองรวม
• Step 6: ใช้เทคนิคเล็กๆ ที่ลด token ได้จริง
• Step 7: ติดตามการใช้ token เหมือนติดตามต้นทุนธุรกิจ
• Step 8: อย่ามอง 1 ล้าน token ว่าเป็นพื้นที่ที่ต้องใช้ให้เต็ม
• Step 9: เลือก framework เสริมเท่าที่จำเป็น ไม่ใช่ใส่ทุกอย่าง
• Actionable Insights
• Troubleshooting
• การต่อยอด
• สรุป Checklist ทั้งหมด

Step 1: เข้าใจก่อนว่า token ไม่ได้ถูกใช้แบบตรงไปตรงมา

จุดตั้งต้นที่สำคัญที่สุดคือ ต้องเข้าใจก่อนว่า ทุกครั้งที่เราส่งข้อความใหม่ Claude จะอ่าน conversation ทั้งหมดใหม่อีกครั้ง ไม่ใช่อ่านแค่ข้อความล่าสุด

นั่นแปลว่า session ที่ยาวขึ้นเรื่อยๆ จะไม่ได้เพิ่มต้นทุนแบบบวกทีละนิด แต่จะพุ่งแบบทบต้น เพราะข้อความลำดับที่ 30 ต้องแบกข้อความก่อนหน้าเกือบทั้งหมดมาคิดใหม่อีกครั้ง

มีตัวอย่างที่ชัดมาก คือแชตยาวระดับ 100+ ข้อความ พบว่า 98.5% ของ token ถูกใช้ไปกับการอ่าน history เดิมซ้ำ ไม่ใช่การคิดงานใหม่ ถ้ามองในมุมธุรกิจ นี่คือค่าใช้จ่ายที่เกิดจาก “ระบบทำงานซ้ำ” มากกว่า “งานที่สร้างมูลค่า”

สิ่งที่หลายคนไม่รู้คือ แม้ยังไม่พิมพ์อะไรเลย session ใหม่ก็มีค่าใช้จ่ายตั้งต้นอยู่แล้ว จาก system prompt, ไฟล์ตั้งค่า, skill, tool, MCP server และองค์ประกอบอื่นที่ถูกโหลดเข้ามาอัตโนมัติ บางคนเริ่ม session ด้วย 8,000 token บางคนอาจมากกว่านั้นหลายเท่า

ถ้าเอาไปใช้กับธุรกิจไทย ความหมายคือ เราไม่ควรโยนทุกอย่างใส่ AI พร้อมกัน เช่น มีทั้งคู่มือบริษัท SOP เอกสารสินค้า โทนแบรนด์ และ prompt ยาวหลายหน้าใน session เดียว เพราะเราอาจกำลังเผา token ตั้งแต่ยังไม่เริ่มทำงานจริง

Step 2: ระวัง context rot เพราะยิ่ง session ยาว AI ยิ่งหลุดประเด็น

Nate ใช้คำว่า context rot ซึ่งอธิบายง่ายๆ คืออาการที่ model เริ่มหลง ลืม สับสน และตอบไม่คม เมื่อ session ยาวเกินไป

อาการที่มักเจอได้แก่

• ตอบขัดกับที่ตกลงกันไปแล้ว
• แก้ไฟล์โดยไม่ได้อ่านให้ครบ
• เริ่มตอบกว้าง ตื้น หรือวกวน
• ลืมข้อจำกัดสำคัญของงาน

ข้อมูลที่ยกมาน่าสนใจมาก คือความแม่นในการดึงข้อมูลจาก context ลดจาก 92% ที่ 256K token เหลือ 78% ที่ 1M token แปลว่า context ใหญ่ขึ้นไม่ได้หมายถึงฉลาดขึ้นเสมอไป

ในมุมของคนทำธุรกิจ นี่คือเหตุผลว่าทำไม session เดียวที่ยาวมากๆ มักพาโปรเจกต์หลุดทาง เช่น ตอนแรกใช้ AI ช่วยสรุปโจทย์ลูกค้า ต่อด้วยทำแผน ต่อด้วยเขียนข้อเสนอ ต่อด้วยปรับสไลด์ สุดท้าย AI เริ่มงงว่าเป้าหมายจริงคืออะไร

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

Step 3: อย่ารอให้ auto-compaction จัดการ เพราะมันมาช้าเกินไป

Claude มีระบบ auto-compaction ที่จะเริ่มทำงานตอนใกล้เต็ม context window ประมาณ 95% แต่ปัญหาคือจังหวะนั้นเป็นช่วงที่ model เริ่มล้าและมี context rot หนักที่สุดแล้ว

ผลลัพธ์คือ สรุปออกมาได้เพียงราว 20-30% ของรายละเอียดเดิม และมีโอกาสทิ้งข้อมูลสำคัญไปมาก

ถ้าเทียบกับการทำงานจริง มันเหมือนเรารวบเอกสารประชุมทั้งเดือนมาสรุปตอนก่อนขึ้นนำเสนอ 5 นาที แน่นอนว่ามีสิทธิ์ลืมเรื่องสำคัญ

ทางที่ดีกว่าคือ สรุปเองก่อนจะใกล้เต็ม Nate แนะนำการ manual compaction และเขาเองเลือกสรุป session แล้วเริ่มใหม่ก่อนที่จะยาวเกินไปมาก

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

Step 4: ใช้ Rewind, Clear, Compact และ Subagent ให้ถูกจังหวะ

หลังจาก Claude ตอบกลับแต่ละครั้ง โดยหลักแล้วเรามีทางเลือกสำคัญ 5 แบบ

• Continue คือคุยต่อใน session เดิม
• Rewind คือย้อนกลับไปจุดก่อนหน้าและทิ้งสิ่งที่ตามมาทีหลัง
• Clear คือเริ่มใหม่ทั้งหมด
• Compact คือสรุป session แล้วแทนที่ history เดิม
• Subagent คือแยกงานบางชิ้นไปให้ context ใหม่ทำแทน

Rewind เป็นฟีเจอร์ที่คนใช้ AI ทั่วไปน่าจะได้ประโยชน์มาก แต่ยังใช้กันน้อย เวลา Claude ทำพลาด คนส่วนใหญ่มักพิมพ์ต่อว่า “อันนี้ไม่ใช่ ลองอีกแบบ” ปัญหาคือความพลาดครั้งแรกยังอยู่ใน session และถูกอ่านซ้ำทุกครั้ง

ถ้าเป็นงานจริง เช่น ให้ AI ช่วยเขียน proposal แล้วมันจับ positioning ผิด การปล่อยข้อความผิดไว้ใน session คือการปล่อย “ความเข้าใจผิด” ให้ปนอยู่ในสมองของ model ต่อไป

Clear ควรใช้เมื่อเปลี่ยนงาน ส่วน Compact เหมาะเมื่อยังทำงานเดิมแต่ต้องย่อสิ่งที่เกิดขึ้น อย่างไรก็ตาม Nate เสนอวิธีที่น่าสนใจกว่า คือให้ Claude สรุปสิ่งที่ทำไปทั้งหมดเป็น handoff summary แล้วค่อย clear session จากนั้น paste สรุปนี้กลับเข้าไปเพื่อเริ่มใหม่

วิธีนี้เหมาะมากกับคนทำงานที่ต้องส่งต่อ task เช่น

• สรุปว่าเราวิเคราะห์ตลาดไปถึงไหนแล้ว
• มี decision อะไรที่ตกลงกันแล้ว
• ไฟล์ไหนหรือข้อมูลไหนต้องอ่านต่อ
• งานถัดไปคืออะไร

พูดอีกแบบคือ แทนที่จะฝากความจำทั้งหมดไว้ในแชต เราควรดึง “สาระสำคัญ” ออกมาเก็บเป็นเอกสารทำงาน

Subagent ก็สำคัญมาก เพราะมันทำให้เราไม่ต้องเอางานทุกอย่างมาใส่ใน session หลัก เช่น ถ้าต้องการให้ AI ช่วยอ่านเอกสาร 50 หน้าแล้วสรุปสาระ เราสามารถให้ subagent ไปทำงานนั้นใน context ใหม่ แล้วส่งกลับมาเป็นสรุปสั้นๆ

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

Step 5: วางระบบ session ให้เหมือนงานเป็นเฟส ไม่ใช่กองรวม

หนึ่งในแนวคิดที่น่าเอาไปใช้ต่อมากที่สุดคือ session chaining หรือการแยกงานใหญ่เป็นหลาย session ตามเฟส

ตัวอย่างเช่น

1. Discovery session สำหรับอ่านไฟล์ อ่านข้อมูลลูกค้า หรือสรุปสิ่งที่มีอยู่
2. Planning session สำหรับเอาข้อมูลที่สรุปแล้วมาทำแผน
3. Execution session สำหรับลงมือเขียน ทำ หรือผลิตงานจริง

ถ้าเอามาใช้กับธุรกิจไทย เราอาจออกแบบ workflow แบบนี้ได้ทันที เช่น

• เฟส 1: ให้ AI อ่านรีวิวลูกค้าและคู่แข่ง
• เฟส 2: ให้ AI สรุป pain point และวาง messaging
• เฟส 3: ให้ AI เขียน landing page, โฆษณา, sales script

ข้อดีคือแต่ละ session มีหน้าที่ชัด ไม่แบกข้อมูลเกินจำเป็น และย้อนกลับมาแก้ได้ง่าย

Step 6: ใช้เทคนิคเล็กๆ ที่ลด token ได้จริง

คลิปนี้มีหลายเทคนิคที่ดูเล็ก แต่รวมกันแล้วลดค่าใช้จ่ายได้เยอะ

แปลงไฟล์เป็น Markdown

HTML, PDF และ DOCX มักมีโครงสร้างฟุ่มเฟือยที่ model ไม่จำเป็นต้องใช้ ถ้าแปลงเป็น Markdown ก่อน จะลด token ลงได้มาก เช่น HTML อาจลดได้ราว 90% และ PDF ลดได้ประมาณ 65-70%

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

ใช้คำถามข้างทางแบบไม่ให้เปื้อน history

มีฟีเจอร์ประเภท slash BTW หรือ side question ที่ช่วยถามคำถามย่อยโดยไม่ใส่ลงใน conversation history หลัก จุดนี้เหมาะกับคำถามแทรก เช่น ขอคำจำกัดความ ขอเช็กศัพท์ หรือถามข้อสงสัยเฉพาะหน้า

เริ่มจาก plan mode

Nate ชี้ว่าการวางแผนก่อนลงมือช่วยลดการแก้ทีหลัง ซึ่งประหยัดกว่าในภาพรวม ประเด็นนี้คนทำธุรกิจควรจำให้แม่น เพราะ AI ที่ทำงานไว ไม่ได้แปลว่าควรสั่งทำทันทีเสมอไป

ถ้า brief ไม่ชัด AI จะสร้างงานเร็วก็จริง แต่เราจะเสีย token ไปกับการแก้หลายรอบ เช่น สั่งให้เขียนแคมเปญการตลาดโดยยังไม่ได้กำหนดกลุ่มเป้าหมาย น้ำเสียง และข้อเสนอหลัก สุดท้ายจะได้งานที่ต้องรีไรต์ยาวกว่าเดิม

คุมขนาดไฟล์คำสั่งหลัก

ไฟล์อย่าง claude.md หรือไฟล์ตั้งค่าหลักไม่ควรยาวเกินความจำเป็น เพราะมันถูกโหลดทุก session ถ้ามีข้อมูลเฉพาะทางที่ไม่ได้ใช้ตลอด ควรแยกไปไว้ในไฟล์หรือ skill ที่เรียกใช้เมื่อจำเป็น

อย่าหวังพึ่งการบังคับให้ตอบสั้นอย่างเดียว

มีการพูดถึงแนวคิดว่า output token แพงกว่า input token แต่การบอกให้ Claude ตอบสั้นๆ อย่างเดียวไม่ใช่ตัวแก้หลัก เพราะต้นทุนจำนวนมากแฝงอยู่ในกระบวนการและการอ่าน context เก่าอยู่แล้ว

พูดง่ายๆ คือ ถ้าโครงสร้าง session พัง ต่อให้บังคับให้ AI พูดสั้น ก็ไม่ได้ช่วยมากนัก

Step 7: ติดตามการใช้ token เหมือนติดตามต้นทุนธุรกิจ

อีกส่วนที่น่าสนใจคือ Nate สร้าง token dashboard เพื่อดูว่า token ถูกใช้ไปกับอะไรบ้าง ทั้งตาม session, project, prompt, tool call และการใช้งานในช่วง 7 หรือ 30 วันที่ผ่านมา

แม้หลายทีมอาจยังไม่ได้มี dashboard แบบนี้ แต่หลักคิดสำคัญมาก คือ ถ้าเราไม่รู้ว่า token หายไปตรงไหน เราจะลดมันไม่ได้

สำหรับเจ้าของธุรกิจ ลองเริ่มจากการถามคำถามพื้นฐานแบบนี้

• งานประเภทไหนกิน token มากที่สุด
• prompt แบบไหนทำให้ session ยาวผิดปกติ
• ทีมใช้ AI กับงานวิเคราะห์มากเกินไปหรือใช้กับงานเขียนมากเกินไป
• มีไฟล์หรือคำสั่งอะไรที่ถูกเรียกซ้ำแบบไม่จำเป็นหรือไม่

นี่ไม่ใช่เรื่องเทคนิคอย่างเดียว แต่คือเรื่องการควบคุมต้นทุนการทำงานด้วย AI

Step 8: อย่ามอง 1 ล้าน token ว่าเป็นพื้นที่ที่ต้องใช้ให้เต็ม

หนึ่งในข้อสรุปที่คมที่สุดคือ 1M context window คือประกัน ไม่ใช่เป้าหมาย

หลายคนพอเห็นพื้นที่ใหญ่ ก็เริ่มใช้แบบไม่ระวัง หยุดแบ่ง session หยุดสรุป หยุดคัดข้อมูล เพราะรู้สึกว่ายังเหลืออีกเยอะ แต่การมีพื้นที่มากขึ้นไม่ได้เปลี่ยนกฎพื้นฐานว่า model จะเริ่มเสียโฟกัสเมื่อมีข้อมูลสะสมมากเกินไป

Nate บอกว่าแม้จะใช้ Opus ที่มี 1 ล้าน token เขาก็มักรีเซ็ตประมาณ 120,000 token เป็นหลัก ซึ่งเป็นนิสัยที่น่าสนใจมาก เพราะมันบังคับให้ workflow กระชับอยู่เสมอ

ตรงนี้เราเห็นด้วยในหลักคิด แต่มีข้อสังเกตหนึ่ง คือสำหรับบางงานธุรกิจที่ต้องอ่านเอกสารหนาๆ ในรอบเดียว เช่น due diligence, รายงานการเงิน, หรือข้อเสนอที่มีหลายภาคผนวก context ใหญ่ก็ยังมีประโยชน์ เพียงแต่ไม่ควรใช้มันเป็นข้ออ้างในการสะสม history แบบไร้วินัย

Step 9: เลือก framework เสริมเท่าที่จำเป็น ไม่ใช่ใส่ทุกอย่าง

มีการอ้างถึงชุดเครื่องมือจาก GitHub หลายตัวที่ช่วยลด token เช่น ตัวกรอง terminal output, ระบบเก็บผลลัพธ์ลง SQLite แทนการ dump ลง context, ตัวช่วยย่อคำตอบ และ token optimizer หลายแบบ

ประเด็นสำคัญไม่ใช่ต้องลงทุกตัว แต่คือ เลือกให้เหมาะกับ workflow

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

• มีทางให้มันอ่านเฉพาะสรุปได้ไหม
• มีทางแยกงานไปทำข้างนอกแล้วค่อยดึงผลกลับมาไหม
• มีข้อมูลส่วนไหนที่เก็บนอก session ได้ไหม

Actionable Insights

• แยก session ตามงาน อย่าใช้แชตเดียวทำทุกอย่างตั้งแต่วิเคราะห์จนถึงผลิตงานสุดท้าย
• สรุปงานเป็นระยะ ทุกครั้งที่เริ่มรู้สึกว่า session เริ่มยาว ให้สั่งสรุปสถานะและเริ่มใหม่
• แปลงเอกสารเป็น Markdown ก่อนส่งเข้า AI โดยเฉพาะ PDF, DOCX และ HTML ที่มีโครงสร้างเกินจำเป็น
• ใช้ AI เป็นทีม ไม่ใช่กล่องเดียว งานค้นข้อมูล งานสรุป และงานตัดสินใจ ควรแยกกัน
• ติดตามต้นทุน token อย่างน้อยควรรู้ว่างานแบบไหนเผา budget มากที่สุด

Troubleshooting

ปัญหา: Claude เริ่มตอบมั่ว ทั้งที่ตอนแรกตอบดีมาก

สาเหตุ: session ยาวเกินไปจนเกิด context rot

วิธีแก้: สั่งสรุปสิ่งที่ทำไปแล้ว เก็บเป็น handoff note จากนั้น clear session และเริ่มใหม่ด้วยสรุปนั้น

ปัญหา: ใช้ AI ทุกวันแต่ค่าใช้จ่ายพุ่งเร็วกว่าที่คิด

สาเหตุ: ปล่อยให้ AI อ่าน history เดิมซ้ำๆ และโหลดไฟล์เกินจำเป็นทุก session

วิธีแก้: ตรวจ prompt ที่ใช้บ่อย ลดขนาดไฟล์คำสั่งหลัก และแยกงานออกเป็น session สั้นลง

ปัญหา: AI จำรายละเอียดโปรเจกต์ไม่ค่อยได้หลังคุยนานๆ

สาเหตุ: ข้อมูลสำคัญถูกฝังอยู่ในแชตยาวๆ ไม่มีการบันทึกเป็นโครงสร้าง

วิธีแก้: สร้าง decision log, task list หรือไฟล์สรุปสถานะ แทนการฝากทุกอย่างไว้ใน conversation

ปัญหา: ส่ง PDF เข้าไปแล้วกิน token มากเกินไป

สาเหตุ: ไฟล์มีเลย์เอาต์และ metadata ที่ model ไม่จำเป็นต้องใช้

วิธีแก้: แปลงเป็น Markdown หรือดึงเฉพาะข้อความก่อน แล้วค่อยส่งให้ AI อ่าน

ปัญหา: แก้งานหลายรอบเพราะ brief แรกไม่ชัด

สาเหตุ: ข้ามขั้นวางแผนแล้วไปสั่งทำทันที

วิธีแก้: เริ่มจาก plan mode ให้ AI ช่วยจัดกรอบงาน เป้าหมาย และข้อจำกัดก่อนค่อยสั่งผลิตงาน

การต่อยอด

• สร้าง template handoff สำหรับทีม เช่น สถานะงานล่าสุด, สิ่งที่ตัดสินใจแล้ว, งานถัดไป เพื่อให้ทุกคนรีเซ็ต session ได้แบบไม่เสีย continuity
• ทำ AI workflow แยกตามแผนก ฝ่ายขายอาจมี session สำหรับสรุปลูกค้า ส่วนการตลาดมี session สำหรับวางแผน content และฝ่ายปฏิบัติการมี session สำหรับ SOP
• ทำ dashboard ต้นทุน AI ระดับทีม เพื่อดูว่า use case ไหนคุ้มที่สุด ไม่ใช่วัดแค่ว่า AI ใช้ได้หรือไม่ได้

สรุป Checklist ทั้งหมด

• ☐ เข้าใจว่า Claude อ่าน conversation เก่าซ้ำทุกครั้งที่เราส่งข้อความใหม่
• ☐ เช็ก startup overhead ของ session ใหม่ และลดไฟล์หรือคำสั่งที่ไม่จำเป็น
• ☐ อย่าปล่อย session ยาวจนเกิด context rot
• ☐ อย่ารอ auto-compaction ตอนใกล้เต็มค่อยจัดการ
• ☐ ใช้ rewind เมื่องานรอบก่อนผิดและไม่ควรเก็บไว้ใน history
• ☐ ใช้ clear เมื่อเปลี่ยนงาน และใช้ handoff summary เมื่อต้องทำงานต่อ
• ☐ แยกงานค้นข้อมูลหรือสรุปไปให้ subagent หรือ session ใหม่ทำ
• ☐ แปลงเอกสารเป็น Markdown ก่อนส่งให้ AI เมื่อทำได้
• ☐ เริ่มงานจากการวางแผนก่อนลงมือผลิต
• ☐ คุมขนาดไฟล์คำสั่งหลัก เช่น claude.md ไม่ให้ยาวเกินจำเป็น
• ☐ ติดตามว่ากิจกรรมไหนกิน token มากที่สุด
• ☐ มอง 1M context window เป็นพื้นที่สำรอง ไม่ใช่พื้นที่ที่ต้องใช้ให้เต็ม
• ☐ ออกแบบ workflow AI เป็นหลายเฟส แทนการยัดทุกอย่างลงแชตเดียว

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