สัปดาห์นี้ ทรีขอนำเสนอโพสต์ที่น่าสนใจของ Hacker News ที่ชื่อ “Using Claude Code: The unreasonable effectiveness of HTML” — โพสต์สั้น ๆ ที่ชี้ว่าวิธีคิดของเรากับ “ข้อมูลจากเว็บ” มาตลอด 10 ปี กำลังถึงจุดเปลี่ยน

บทความนี้ใช้เวลา 12-15 นาที เหมาะกับคนที่สนใจการนำ LLM ไปใช้จริงค่ะ

ไอเดียหลัก: “ป้อน HTML ดิบให้โมเดล แทนที่จะ parse ก่อน”

  • เดิม: ต้องเขียน script ดึงเว็บ → parse ด้วย BeautifulSoup / Cheerio / Playwright → clean → จัดเป็น JSON → ค่อยส่งให้ LLM
  • ใหม่: ดึง HTML ดิบมา → ส่งเข้าโมเดลตรง ๆ พร้อมคำสั่งว่าต้องการอะไร → ได้ผลลัพธ์
  • ที่น่าตกใจคือ — มันใช้ได้จริง บ่อยกว่าที่คุณคาด และเร็วกว่าด้วยซ้ำในหลายเคส
  • LLM ยุคใหม่อ่าน DOM ได้ดีพอที่จะหา “ข้อมูลที่คุณต้องการ” แม้ HTML จะเขียนกระจัดกระจาย, มี class แปลก ๆ , หรือใช้ tag inline เยอะ
  • เครื่องมือเช่น Claude Code, ChatGPT 5.5, Gemini 3 ล้วนทำได้ — เพียงแต่ pattern นี้ยังไม่เป็นที่รู้จักเท่าที่ควร

ทำไมเรื่องนี้ “ผิดสามัญสำนึก”

  • เคยเชื่อกัน ว่า input ของ LLM ต้องสะอาดเสมอ ไม่งั้น “เปลือง token” หรือ “ทำให้โมเดลสับสน”
  • ความจริงในปี 2026 คือ context window 200K-1M token ทำให้ HTML ทั้งหน้ารวมอยู่ในนั้นได้สบาย
  • token ที่ “เปลือง” ไม่ได้แพง เท่ากับ “เวลาวิศวกรเขียน parser, ดูแล selector, แก้เมื่อโครงสร้างเว็บเปลี่ยน”
  • เปรียบเทียบ:
    • CSS selector เปลี่ยนทันทีเมื่อเว็บปรับ design — ต้องไล่แก้ทั้งโปรเจกต์
    • โมเดลที่อ่าน HTML ปรับตัวอัตโนมัติ — โครงสร้างเปลี่ยนแต่ semantic เหมือนเดิม โมเดลก็ยังเข้าใจ
  • เป็นการ trade “ความ deterministic ของ rule” เพื่อ “ความ resilient ต่อการเปลี่ยนแปลง”

3 เคสใช้งานจริงที่เห็นภาพชัดที่สุด

ทรีคัดเฉพาะเคสที่ “ลองพรุ่งนี้แล้วเห็นผลทันที” ไม่ต้องสร้าง infrastructure ใหญ่ก่อน — และระบุชัดว่าเหมาะกับบทบาทไหน

เคสที่ 1 — Competitive intelligence รายวัน (เหมาะกับ CEO / Founder + Dev)

  • ทุกเช้าดึง HTML หน้าราคา, หน้าโปรโมชัน, หรือหน้า changelog ของคู่แข่ง 5–10 เจ้า
  • โยน HTML ทั้งดุ้นเข้า Claude / GPT-5.5 พร้อม prompt: “เปรียบเทียบกับสัปดาห์ที่แล้ว สรุปการเปลี่ยนแปลงเป็น bullet”
  • ผลลัพธ์: สรุปตลาดรายวันโดยไม่ต้องจ้าง analyst หรือเขียน scraper ใด ๆ — เปลี่ยนงาน “ฝัน” ให้กลายเป็น cron + prompt 50 บรรทัด
  • เคยใช้เวลา dev หลายสัปดาห์ + maintenance ทุกครั้งที่เว็บคู่แข่งเปลี่ยน design วันนี้ใช้เวลาประมาณ 1 วัน setup

เคสที่ 2 — บอท LINE OA ตอบลูกค้าเรื่องสินค้าตัวเอง (เหมาะกับ SME / โซโลฟาวเดอร์)

  • ป้อนหน้าสินค้าจาก Shopify / Magento / WooCommerce ของตัวเองให้ LLM อ่านเป็น HTML ตรง ๆ
  • ลูกค้าถามใน LINE OA → backend ดึงหน้าสินค้าที่เกี่ยวข้อง → ส่งให้ LLM ตอบในภาษาธรรมชาติ
  • ผลลัพธ์: ไม่ต้อง maintain database สินค้าซ้ำกับร้านค้า, ไม่ต้องเขียน mapping ระหว่างคำถามกับ field — ราคาเปลี่ยน LLM ก็ตอบราคาใหม่อัตโนมัติ
  • ข้อควรระวัง: cache HTML ไว้สั้น ๆ (5–10 นาที) เพื่อกัน traffic spike และตรวจ terms of service ของ platform

เคสที่ 3 — Acceptance / regression test แบบ semantic (เหมาะกับ PM / PO + QA)

  • ก่อนปล่อย release ดึง HTML ของหน้าหลักเทียบกับ baseline สัปดาห์ก่อน
  • prompt: “หน้านี้แสดงข้อมูลตาม acceptance criteria เหล่านี้ครบไหม? ถ้าหายอะไรไป ระบุ field กับ section”
  • ผลลัพธ์: ตรวจ regression ได้ระดับ semantic — ปรับ design ได้ตามใจ ตราบใดที่ความหมายของหน้าไม่หาย
  • เคสนี้เหนือกว่า visual diff ตรง “เข้าใจว่าอะไรสำคัญ” และเหนือกว่า DOM diff ตรง “ไม่ noisy เกินไป”

วิธีเริ่มใช้งาน — Step by Step

ขั้นที่ 1: เครื่องมือพื้นฐาน

  • เลือก client ที่จัดการ context window ใหญ่ได้ดี:
    • Claude Code — เหมาะถ้าทำใน terminal และต้องการให้รัน command ต่อ
    • Cursor / Copilot Workspace — ถ้าทำใน IDE
    • API ตรง (Anthropic / OpenAI) — ถ้าจะสร้าง pipeline production
  • เครื่องมือดึง HTML:
    • curl สำหรับหน้า static
    • Playwright หรือ Puppeteer สำหรับหน้าที่ต้อง render JS — แต่แค่เพื่อให้ได้ HTML ก็พอ ไม่ต้อง parse ต่อ
    • readability.js หรือ turndown ถ้าอยากบีบ HTML ก่อนส่ง (ทางเลือก ไม่จำเป็น)

ขั้นที่ 2: prompt template เบื้องต้น

  • โครงพื้นฐาน: "นี่คือ HTML ของ [หน้าอะไร]. ดึง [ข้อมูลที่ต้องการ] ออกมาเป็น [format ที่ต้องการ]"
  • เพิ่ม schema ที่ชัดเจน — บอก field name, type ที่ต้องการ, ตัวอย่าง output
  • ใช้ XML tag คั่นส่วน HTML กับคำสั่ง — ช่วยโมเดลแยก context ได้ดีขึ้น
  • ตัวอย่าง: 
    <html>
...HTML ดิบที่นี่...
</html>

ดึงรายการสินค้าออกเป็น JSON ตาม schema:
{ "items": [{ "name": string, "price": number, "currency": string }] }

ขั้นที่ 3: optimization ที่ “พอเหมาะ”

  • อย่า optimize ก่อนวัด — ลองแบบ “ป้อน HTML ทั้งดุ้น” ก่อน ดูว่าได้ผลแค่ไหน, ใช้ token เท่าไหร่
  • ถ้าต้องลด token จริง:
    • ตัด <script>, <style>, comment, attribute ที่ไม่ใช้ (class, id, data-*)
    • เก็บเฉพาะ tag ที่มี text — บางที 80% ของ HTML เป็น navigation/markup ที่ไม่เกี่ยว
    • ใช้ Reader Mode (เช่น Mozilla Readability) เพื่อตัดเหลือ main content
  • prompt caching: Anthropic / OpenAI มี cache สำหรับ context ใหญ่ที่ใช้ซ้ำ — เซฟต้นทุนได้มากในการรันซ้ำ

ขั้นที่ 4: ทำให้เสถียรพอจะใช้งานจริง

  • JSON schema enforcement: ใช้ structured output / function calling เพื่อบังคับ format
  • retry logic: ตั้ง 1-2 retry ในกรณี parse JSON ไม่ผ่าน
  • fallback: เคสที่ AI ไม่แน่ใจ ให้ตอบ null หรือ flag review แทนการเดา
  • test เคสจริง 20-30 ตัวอย่าง: อย่าลองแค่ 2-3 หน้า — ลองให้ครอบคลุม edge case
  • monitor accuracy: เก็บ log + sampling เพื่อรู้ว่ายัง accurate อยู่มั้ยเมื่อเว็บเปลี่ยน

ข้อจำกัดที่ต้องรู้

  • ต้นทุน token ยังสูงกว่า parse ด้วย code มาก — แต่ลดลงเรื่อย ๆ
  • Latency ช้ากว่า parser แบบเดิม — ใช้กับ batch หรือ async ได้ดีกว่า real-time
  • Hallucination: บางครั้ง AI “เดา” ข้อมูลที่ไม่มีในหน้าจริง — ต้อง validate
  • Long page: ถ้า HTML เกิน context window ต้อง chunk หรือ summarize ก่อน
  • Anti-bot: การดึง HTML ยังต้องเจอ Cloudflare, CAPTCHA — เครื่องมือเดิมยังต้องมีในขั้น fetch
  • Compliance: robots.txt, terms of service ของเว็บที่ scrape ยังต้องเคารพ
  • Reproducibility: output ของ LLM อาจไม่ deterministic — ต้องตั้ง temperature 0 และ seed ถ้าทำได้

เมื่อไหร่ “ยัง” ควรใช้ parser แบบเดิม

  • ดึงข้อมูลปริมาณมหาศาล (ล้าน record/วัน) — ต้นทุน LLM ยังไม่คุ้ม
  • ต้องการ latency ต่ำกว่า 100ms — parser แบบเดิมเร็วกว่ามาก
  • โครงสร้างเว็บคงที่และเรียบง่าย — เขียน selector 5 บรรทัดจบ ไม่ต้องเปลือง LLM
  • ระบบที่ต้อง deterministic 100% (financial, audit) — LLM ไม่ใช่ตัวเลือกหลัก

Mental Model ที่อยากให้ติดตัว

  • HTML ≠ ข้อมูล ในมุมมองเดิม — ต้องแปลงก่อน
  • HTML = ข้อมูล ในมุมมองใหม่ — LLM เข้าใจมันได้โดยตรง
  • เปลี่ยนคำถามจาก “จะ parse ยังไง?” เป็น “จะอธิบายให้ AI ฟังว่าฉันต้องการอะไรยังไง?”
  • โค้ดน้อยลง prompt มากขึ้น — แต่ prompt ก็ต้องดูแลเหมือนโค้ด (version, test, review)
  • เครื่องมือ ETL จะลดความสำคัญ ในงาน “เว็บ → JSON” สำหรับโปรเจกต์ขนาดเล็ก-กลาง
  • ทักษะใหม่ที่สำคัญ: เลือก context อะไรเข้า LLM, format prompt ให้ชัด, ตั้ง guardrail

Checklist สั้น ๆ ก่อนลองพรุ่งนี้

  • เลือก 1 task ที่คุณ “เคยตั้งใจ scrape แต่ขี้เกียจเขียน parser”
  • ดึง HTML ดิบของหน้าตัวอย่าง 5 หน้า
  • เขียน prompt ที่บอก output schema ชัดเจน
  • รันกับ Claude Code / API → ดูผล
  • เปรียบเทียบกับวิธีเดิม: ใช้เวลา dev เท่าไหร่, accurate แค่ไหน, ค่า token vs ค่าแรง
  • ตัดสินใจว่าคุ้มมั้ยที่จะ scale

อ่านเพิ่มเติม

ขอบคุณที่อ่านจนจบ 🙏

ถ้าบทความนี้มีประโยชน์ ลองนำไปใช้แล้วเล่าให้ฟัง — และฝากติดตามช่องทางต่อไปนี้เพื่อไม่พลาดสรุปข่าว AI ประจำสัปดาห์ และไอเดียจากการใช้ LLM ในงานจริงค่ะ:

  • Grow Through What We Go Through : IG + Facebook — Facebook · โพสต์สรุปและคอนเทนต์ AI ภาษาไทยทุกสัปดาห์
  • LinkedIn (สำหรับติดต่องานที่ปรึกษา): Thanwarin บน LinkedIn — ถ้าธุรกิจของคุณต้องการที่ปรึกษาด้านการนำ LLM ไปใช้ปรับ workflow, automation, หรือผลิตภัณฑ์ ทักมาคุยกันได้ค่ะ

แล้วเจอกันโพสต์ต่อไปค่ะ