การใช้ Claude Code: ประสิทธิภาพอันน่าทึ่งของ HTML

 (twitter.com/trq212)
2 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การใช้ HTML เป็นรูปแบบเอาต์พุตแทน Markdown ใน Claude Code ช่วยให้ใส่การแสดงผล สี ไดอะแกรม และปฏิสัมพันธ์ได้มากขึ้น ทำให้งานที่ได้อ่านและตรวจทานโดยมนุษย์ได้ง่ายขึ้น
  • HTML สามารถแสดงข้อมูลส่วนใหญ่ที่ Claude อ่านเข้าใจได้อย่างมีประสิทธิภาพ ผ่านตาราง, CSS, SVG, script, ปฏิสัมพันธ์ด้วย JavaScript, รูปภาพ, canvas และการจัดวางแบบ absolute
  • Claude Code สามารถอ่านบริบทอย่างระบบไฟล์, MCP, เบราว์เซอร์, และประวัติ Git แล้วนำมาร้อยเรียงเป็นผลลัพธ์แบบ HTML ได้ โดยเริ่มต้นได้เพียงแค่ขอว่า “ช่วยสร้างไฟล์ HTML ให้หน่อย”
  • รูปแบบการใช้งานหลักแบ่งเป็น สเปก·แผน·การสำรวจ, การรีวิวและทำความเข้าใจโค้ด, การออกแบบและต้นแบบ, รายงาน·รีเสิร์ช·การเรียนรู้, และอินเทอร์เฟซแก้ไขแบบใช้ครั้งเดียวที่ปรับแต่งเฉพาะงาน
  • แม้ HTML จะใช้เวลาสร้างนานกว่า Markdown 2–4 เท่า และมี diff ที่รกทำให้ การควบคุมเวอร์ชัน ยากกว่า แต่จุดเด่นด้านพลังการแสดงออก การแชร์ และโอกาสที่จะมีคนอ่านจริงกลับสูงกว่า

เหตุผลที่เริ่มชอบ HTML มากกว่า Markdown

  • Markdown กลายเป็นรูปแบบไฟล์หลักที่เอเจนต์ใช้สื่อสารกับมนุษย์ เพราะเรียบง่าย พกพาได้ดี จัดรูปแบบได้พอสมควร และมนุษย์แก้ไขเองได้ง่าย
  • Claude สร้างไดอะแกรม ASCII ใน Markdown ได้ดี แต่เมื่อเอเจนต์มีความสามารถมากขึ้น Markdown ก็เริ่มให้ความรู้สึกว่าเป็นรูปแบบที่จำกัด
  • ไฟล์ Markdown ที่ยาวเกิน 100 บรรทัดอ่านยาก และทำให้เกิดความต้องการแชร์ภาพรวม สี และไดอะแกรมที่สมบูรณ์ยิ่งขึ้นได้ง่ายกว่า
  • เมื่อเริ่มขอให้ Claude ช่วยแก้ไฟล์มากกว่าการแก้เองโดยตรง คุณค่าของข้อดีสำคัญของ Markdown อย่างการแก้ด้วยมือตรง ๆ ก็ลดลง
  • แม้แต่ภายในทีม Claude Code เองก็มีการใช้ HTML เป็นรูปแบบเอาต์พุตมากขึ้น และดูตัวอย่างได้ที่ html-effectiveness

พลังการแสดงออกและการแชร์ของ HTML

  • HTML ไม่ได้แสดงได้แค่โครงสร้างเอกสารอย่างหัวข้อและการจัดรูปแบบเท่านั้น แต่ยังแสดงข้อมูลได้หลากหลายกว่า Markdown มาก
  • ข้อมูลที่แสดงได้รวมถึง ข้อมูลตาราง ผ่านตาราง, ข้อมูลงานออกแบบผ่าน CSS, ภาพประกอบ SVG, โค้ดชิ้นย่อยผ่านแท็ก script, และปฏิสัมพันธ์ด้วย JavaScript และ CSS
  • สามารถใช้ SVG และ HTML เพื่อแสดง workflow ใช้การจัดวางแบบ absolute และ canvas เพื่อแสดงข้อมูลเชิงพื้นที่ และใส่รูปภาพด้วยแท็ก img ได้
  • ข้อมูลส่วนใหญ่ที่ Claude อ่านเข้าใจได้สามารถแสดงด้วย HTML ได้อย่างมีประสิทธิภาพพอสมควร ทำให้เป็นรูปแบบที่ทั้งส่งข้อมูลเชิงลึกได้ดีและให้มนุษย์ตรวจทานได้อย่างมีประสิทธิภาพ
  • ถ้าใช้ HTML ไม่ได้ Claude อาจต้องหันไปใช้วิธีที่ไม่มีประสิทธิภาพใน Markdown เช่นสร้างไดอะแกรม ASCII หรือใช้ตัวอักษร Unicode เพื่อเดาสี
  • เมื่อ Claude ทำงานซับซ้อนขึ้นและต้องเขียนสเปกกับแผนที่ใหญ่ขึ้น ไฟล์ Markdown ที่เกิน 100 บรรทัดก็แทบอ่านไม่ไหวจริง
  • เอกสาร HTML สามารถจัดโครงสร้างการมองเห็นด้วยแท็บ ภาพประกอบ และลิงก์ ทำให้สำรวจได้ง่าย และยังทำเป็น responsive สำหรับมือถือให้เหมาะกับขนาดหน้าจอที่ต่างกันได้
  • ไฟล์ Markdown มักไม่ได้ถูกเรนเดอร์อย่างดีโดยเบราว์เซอร์ตามค่าเริ่มต้น จึงมักต้องแนบทางอีเมลหรือข้อความ แต่ HTML สามารถอัปโหลดไปที่อย่าง S3 แล้วแชร์เป็นลิงก์ได้ง่าย
  • สเปก รายงาน และคำอธิบาย PR ที่เป็น HTML เปิดดูและอ้างอิงได้ง่ายกว่าสำหรับเพื่อนร่วมงาน จึงมีโอกาสถูกอ่านจริงสูงกว่ามาก
  • เอกสาร HTML รองรับ ปฏิสัมพันธ์สองทาง เช่นใส่ slider หรือ knob เพื่อปรับดีไซน์ หรือเปลี่ยนตัวเลือกของอัลกอริทึมแล้วดูผลลัพธ์ได้ทันที
  • ยังสามารถสร้างฟีเจอร์คัดลอกค่าที่ปรับแล้วกลับไปเป็นพรอมป์ต์สำหรับวางใน Claude Code ได้ด้วย โดยมีตัวอย่างใน playgrounds post

เหตุผลที่ใช้ Claude Code คู่กับ HTML

  • Claude Code สามารถอ่านบริบทหลายแบบ เช่น ระบบไฟล์, MCP, เบราว์เซอร์, และประวัติ Git แล้วร้อยเรียงออกมาเป็นผลลัพธ์ HTML ได้
  • ตัวอย่างเช่น สามารถค้นหาไฟล์ HTML ทั้งหมดที่สร้างในโฟลเดอร์โค้ด แล้วจัดกลุ่มและจัดประเภท ก่อนสร้างไฟล์ HTML ที่มีไดอะแกรมแทนแต่ละประเภทได้
  • นอกจากระบบไฟล์แล้ว ยังดึงบริบทเพิ่มได้จาก MCP อย่าง Slack และ Linear, เว็บเบราว์เซอร์ผ่าน Claude in Chrome, และประวัติ Git
  • กระบวนการสร้างเอกสาร HTML ร่วมกับ Claude ให้ความรู้สึกสนุกกว่า และทำให้รู้สึกมีส่วนร่วมและลงทุนกับชิ้นงานมากขึ้น
  • ไม่จำเป็นต้องสร้างสกิล /html แยกต่างหาก แค่ขอว่า “ช่วยสร้างไฟล์ HTML ให้หน่อย” หรือ “ช่วยสร้าง HTML artifact ให้หน่อย” ก็เริ่มได้
  • เคล็ดลับสำคัญคือรู้ว่า artifact นั้นควรทำอะไร และจะใช้งานอย่างไร โดยช่วงแรกควรเขียนพรอมป์ต์ใหม่ตั้งแต่ต้นทุกครั้งเพื่อเรียนรู้รูปแบบการใช้งานที่หลากหลาย

รูปแบบการใช้งานหลัก

  • สเปก, แผน, การสำรวจ

    • HTML เป็นแคนวาสที่สมบูรณ์สำหรับให้ Claude ขุดลึกลงไปในปัญหา และสามารถเริ่มงานจากชุดไฟล์ HTML หลายไฟล์แทนแผน Markdown เดี่ยวได้
    • สามารถเริ่มจาก brainstorming หลายทิศทาง จากนั้นขยายหนึ่งแนวทางให้เป็น mockup หรือชิ้นส่วนโค้ด แล้วค่อยเขียนแผนการนำไปพัฒนา
    • เมื่อพอใจกับแผนแล้ว ก็สร้างเซสชันใหม่และส่งไฟล์เหล่านี้ต่อเพื่อให้ลงมือพัฒนาได้ ขณะที่ validation agent ก็สามารถอ่านไฟล์เดียวกันเพื่อเก็บบริบทที่กว้างขึ้นได้
    • สามารถให้สร้าง 6 แนวทางสำหรับหน้าจอ onboarding ที่มี layout, tone และความหนาแน่นต่างกันในกริด HTML เดียว พร้อมแสดง trade-off ของแต่ละตัวเลือก
    • ยังสามารถให้สร้างแผนการพัฒนาในรูป HTML ที่อ่านง่าย ซึ่งมีทั้ง mockup, data flow และชิ้นส่วนโค้ดที่ควรตรวจทาน
    • ใช้สำรวจแนวทางการพัฒนาโค้ดและเปรียบเทียบงานออกแบบหลายแบบได้

  • การรีวิวโค้ดและการทำความเข้าใจโค้ด

    • โค้ดอาจอ่านยากในไฟล์ Markdown แต่ใน HTML สามารถเรนเดอร์ diff, คอมเมนต์, flowchart และโครงสร้างโมดูลได้
    • ใช้เพื่อทำความเข้าใจโค้ดที่เอเจนต์เขียน รับ code review หรืออธิบายสิ่งที่เปลี่ยนไปให้คนที่กำลังรีวิว PR ได้
    • บางครั้งทำงานได้ดีกว่าหน้า diff มาตรฐานของ GitHub และยังทำเวิร์กโฟลว์ที่แนบไฟล์อธิบายโค้ดแบบ HTML ไปกับทุก PR ได้ด้วย
    • สามารถให้สร้าง HTML artifact สำหรับรีวิว PR โดยโฟกัสที่ลอจิก streaming/backpressure ที่ไม่คุ้นเคย ใส่คอมเมนต์ข้างบรรทัดใน diff จริง และใช้สีแยกตามระดับความรุนแรง
    • ใช้ได้กับการเขียน PR, รีวิว PR และทำความเข้าใจหัวข้อในโค้ด

  • การออกแบบและต้นแบบ

    • Claude Design สร้างอยู่บน HTML และ HTML มีพลังในการแสดงงานออกแบบสูง แม้พื้นผิวสุดท้ายจะไม่ใช่ HTML ก็ตาม
    • Claude สามารถสเก็ตช์ดีไซน์ด้วย HTML ก่อน แล้วค่อยเขียนเป็นภาษาที่ต้องการ เช่น React หรือ Swift
    • สามารถทำต้นแบบปฏิสัมพันธ์อย่างแอนิเมชันและแอ็กชันต่าง ๆ รวมถึงใส่ slider หรือ knob เพื่อปรับค่าที่ต้องการ
    • สามารถให้สร้างปุ่ม checkout ที่เมื่อคลิกแล้วเล่นแอนิเมชัน ก่อนเปลี่ยนเป็นสีม่วงอย่างรวดเร็ว พร้อมมี slider หลายตัว ตัวเลือกต่าง ๆ และปุ่มคัดลอกพารามิเตอร์ที่ลงตัว
    • ใช้สำหรับสร้าง artifact ของ design system, ปรับแต่งคอมโพเนนต์, ทำภาพรวมไลบรารีคอมโพเนนต์ และต้นแบบแอนิเมชันสนุก ๆ

  • รายงาน, รีเสิร์ช, การเรียนรู้

    • Claude Code เก่งในการสังเคราะห์ข้อมูลจากหลายแหล่งให้ออกมาเป็นรายงานที่อ่านง่าย
    • สามารถให้ค้นหาใน Slack, codebase, ประวัติ Git, อินเทอร์เน็ต ฯลฯ แล้วสร้างรายงานที่อ่านง่ายสำหรับตัวเอง ผู้บริหาร หรือทีมได้
    • ผลลัพธ์อาจเป็นเอกสาร HTML ยาว ๆ, คู่มือแบบโต้ตอบ, หรือรูปแบบสไลด์และ deck
    • การให้สร้างไดอะแกรมด้วย SVG ก็ช่วยเรื่องการแสดงภาพได้มาก
    • ตัวอย่างหนึ่งคือการเตรียมบทความเกี่ยวกับ prompt caching โดยให้อ่านประวัติ Git แล้วสร้างไฟล์รีเสิร์ช HTML เชิงลึกที่ครอบคลุมการเปลี่ยนแปลงทั้งหมดของ prompt caching
    • หรือให้อ่านโค้ดที่เกี่ยวข้องกับ rate limiter แล้วสร้างหน้าคำอธิบาย HTML เดียวที่มีไดอะแกรม flow ของ token-bucket, ชิ้นส่วนโค้ดสำคัญพร้อมคำอธิบาย 3–4 จุด และส่วน gotchas ด้านล่าง
    • ใช้กับสรุปการทำงานของฟีเจอร์, คำอธิบายแนวคิด, รายงานสถานะประจำสัปดาห์, รายงานอุบัติการณ์, และภาพประกอบ SVG·flowchart·technical diagram

  • อินเทอร์เฟซแก้ไขแบบปรับแต่งเฉพาะงาน

    • เมื่ออธิบายสิ่งที่ต้องการด้วยกล่องข้อความอย่างเดียวได้ยาก สามารถสร้างตัวแก้ไข HTML แบบใช้ครั้งเดียวที่ออกแบบมาให้เข้ากับข้อมูลที่กำลังทำงานอยู่ได้
    • มันไม่ใช่โปรดักต์หรือเครื่องมือใช้ซ้ำทั่วไป แต่เป็นไฟล์ HTML เดี่ยวที่สร้างขึ้นให้เหมาะกับข้อมูลเฉพาะชิ้นนั้น
    • หัวใจสำคัญคือการมีส่วนส่งออกตอนท้ายอย่าง “copy as JSON” หรือ “copy as prompt” เพื่อให้คัดลอกผลที่จัดการใน UI ไปวางกลับใน Claude Code ได้
    • เช่น เปลี่ยนตั๋ว Linear 30 ใบให้เป็นการ์ดที่ลากได้ในคอลัมน์ Now / Next / Later / Cut และคัดลอกผลลำดับสุดท้ายเป็น Markdown พร้อมเหตุผลสั้น ๆ ของแต่ละ bucket
    • หรือทำการตั้งค่า feature flag ให้เป็นตัวแก้ไขแบบฟอร์ม จัดกลุ่มตามพื้นที่ แสดง dependency เตือนเมื่อเปิด flag ทั้งที่ prerequisite flag ยังปิดอยู่ และคัดลอกเฉพาะคีย์ที่เปลี่ยนไปเป็น diff
    • เวลาปรับ system prompt ก็สามารถมีพรอมป์ต์ที่แก้ไขได้พร้อมช่องตัวแปรที่ไฮไลต์ไว้ทางซ้าย และการเรนเดอร์ตัวอย่างอินพุต 3 แบบแบบเรียลไทม์ทางขวา พร้อมตัวนับอักขระ·โทเค็นและปุ่มคัดลอก
    • ใช้ได้กับการจัดลำดับตั๋ว·กรณีทดสอบ·ฟีดแบ็กใหม่, การแก้ไขการตั้งค่าแบบมีโครงสร้าง, การปรับพรอมป์ต์·เทมเพลต·ข้อความ, การคิวเรตชุดข้อมูล, การใส่คำอธิบายเอกสาร·ทรานสคริปต์·diff, และการเลือกค่าที่อธิบายด้วยข้อความได้ยาก เช่น สี, easing curve, crop region, cron schedule, regex

คำถามที่พบบ่อยและข้อจำกัด

  • โดยทั่วไป Markdown ใช้โทเค็นน้อยกว่า แต่ HTML มีพลังการแสดงออกและโอกาสถูกอ่านจริงสูงกว่า จึงทำให้ผลงานโดยรวมดีขึ้น
  • ใน 1MM context window ของ Opus 4.7 ปริมาณโทเค็นที่เพิ่มขึ้นไม่ได้รู้สึกเด่นชัดมากนักเมื่อเทียบกับขนาดหน้าต่างบริบท
  • แม้จะหยุดใช้ Markdown แทบทุกกรณีแล้ว แต่นี่ก็เป็นแนวทางใช้งานที่ค่อนไปทางชอบ HTML อย่างมาก
  • ไฟล์ HTML เปิดได้ในเบราว์เซอร์บนเครื่อง และยังขอให้ Claude เปิดให้ดูก็ได้ หากต้องการลิงก์ที่แชร์ได้ก็อัปโหลดไป S3 ได้
  • การสร้าง HTML ใช้เวลานานกว่า Markdown และอาจนานกว่า 2–4 เท่า แต่ถือว่าผลลัพธ์คุ้มค่า
  • หนึ่งในข้อเสียที่ใหญ่ที่สุดคือ การควบคุมเวอร์ชัน เพราะ diff ของ HTML รกกว่า Markdown และรีวิวยากกว่า
  • หากอยากให้ Claude สร้าง HTML ที่ตรงรสนิยม frontend design plugin ก็ช่วยได้
  • หากต้องการให้เข้ากับสไตล์ของบริษัท ก็สามารถให้ Claude ดู codebase แล้วสร้างไฟล์ HTML ของ design system เดียวขึ้นมา เพื่อใช้เป็นเอกสารอ้างอิงสำหรับไฟล์ HTML อื่นต่อไป
  • การใช้ HTML ช่วยลดความกลัวว่าต้องปล่อยให้ Claude ตัดสินใจ เพราะจะไม่อ่านแผนที่ Claude เขียนไว้อย่างลึกพอ และช่วยให้รู้สึกอยู่ใน flow ของการทำงานร่วมกับ Claude ได้มากขึ้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 1 시간 전
ความคิดเห็นจาก Hacker News

  • กังวลว่าถ้าหันไปใช้ HTML เราจะสูญเสีย ความสามารถในการเขียนและแก้ไขเอกสารร่วมกันได้ง่าย ระหว่างคนกับ LLM
    ถ้าเป็นแค่ข้อความอธิบายธรรมดาก็ไม่เป็นไร แต่ถ้าเป็นสเปกที่ซับซ้อนกว่านั้น ความสามารถในการเข้าไปแก้ผลลัพธ์ที่สร้างขึ้นมาโดยตรงสำคัญมาก เอกสาร HTML ทำแบบนั้นได้ยากกว่า Markdown มาก และแม้จะสั่งให้ LLM แก้ HTML อีกทีก็ได้ แต่เมื่อในหัวเรารู้อยู่แล้วว่าต้องการจะพูดอะไร มันก็กลายเป็นอุปสรรคอีกชั้นหนึ่ง ถ้าแพตเทิร์นนี้กลายเป็นเรื่องปกติ การสร้างสรรค์ร่วมกันระหว่างคนกับ LLM ก็น่าจะลดลง และจะยิ่งเอนเอียงไปทางมอบหมายให้ LLM ตัดสินใจเรื่องสำนวน โทน และการเลือกเนื้อหาแทน น่าแปลกใจที่ FAQ ของบล็อกไม่ได้พูดถึงความกังวลนี้

    • Markdown รองรับ inline HTML สำหรับองค์ประกอบแบบโต้ตอบอยู่แล้ว ดังนั้นเอกสาร Markdown ที่พ่วงเทมเพลต HTML ที่รู้จักกันดีและขั้นตอน build ง่ายๆ เข้าไป อาจเป็นทางเลือกที่น่าสนใจ
      เช่นใช้คำสั่ง pandoc บรรทัดเดียว
    • ผมคิดว่ายังมีอีกขั้นหนึ่ง ตราบใดที่เป็น HTML ก็แทบทำอะไรก็ได้ แต่การปล่อยให้ LLM นิยามภาษาของตัวเอง ก็ได้ผลดีอย่างน่าประหลาดเหมือนกัน
      ตอนนี้ผมกำลังทำเกมมือถือเล็กๆ มุมมอง isometric มีเสียงประกอบ และให้ Codex สร้างเครื่องมือสำหรับวางบล็อกลงในเอกสาร three.js ที่เตรียมไว้ พร้อมถ่ายภาพหน้าจอผ่าน Chromium developer tools ปรากฏว่ามันสร้างโครงสร้าง JSON เล็กๆ สำหรับนิยามบล็อก สี และเอฟเฟกต์ เพื่อเรนเดอร์ tileset แบบ 2.5D อีกทั้งยังให้มันนิยามเสียงและดนตรีด้วยสคริปต์ uv Python มันก็คิดฟอร์แมต YAML สำหรับสร้างเสียง noise ขึ้นมาเอง การทดลอง SVG pelican นี่เกินความคาดหมายไปมาก และ Codex ก็สร้างทั้ง prototype art ของทหาร อัศวิน นักบวช รวมถึง prototype soundtrack ได้ด้วย
    • เราเขียน HTML ด้วยมือกันอย่างง่ายดายมาหลายสิบปีแล้ว โปรแกรมแก้ไขข้อความเหมาะกับการเขียน HTML มาก และยังมีคำสั่งอย่างตัดบรรทัดอัตโนมัติ ปิดแท็กอัตโนมัติอีกมากมาย ทำให้ การอ่านและเขียน เป็นเรื่องง่าย
    • ดูเหมือนจะจริงก็ต่อเมื่อคุณขังตัวเองไว้กับโปรแกรมจำลอง teletype ดิบๆ เท่านั้น ถ้าเป็นสภาพแวดล้อมสำหรับเขียนโค้ดที่เหมาะสม การแก้ไข HTML ควรจะง่ายมาก และถ้ากระแสกำลังไปสู่ผลลัพธ์จากโมเดลที่สมบูรณ์ยิ่งขึ้น ก็อาจมีตัวแก้ไขแบบ WYSIWYG ในตัวเป็นอีกทางเลือกหนึ่ง
    • ช่วงหลังผมเริ่มใช้ HTML กับรายงาน แต่จะคง ไฟล์ Markdown เป็นรูปแบบกลาง ไว้เสมอ แล้วให้ LLM สร้างเวอร์ชันที่ดูดีกว่าโดยมีกราฟ SVG และภาพประกอบจากตารางใน Markdown

  • มันช่างน่าขันตรงที่นี่ไม่ใช่หน้า HTML แบบโต้ตอบ แต่เป็น โพสต์บน Twitter ที่อัปโหลดภาพเรนเดอร์ของ HTML
    การยกย่อง HTML บนแพลตฟอร์มที่มีโครงสร้างเชิงความหมายน้อยกว่า Markdown เสียอีก สุดท้ายก็ค่อนข้างตลกดี

    • https://thariqs.github.io/html-effectiveness/
      น่าจะเป็นทั้งสองอย่าง
    • อย่าเพิ่งเริ่มพูดถึง “เทมเพลต” ของ Twitter Articles เลย มันไม่รองรับแม้แต่ Markdown

  • พรอมป์ตที่ผมใช้บ่อยเวลาอยากลองไอเดียหรือเครื่องมือใหม่ๆ คือ

    In a single index.html, no dependencies, sparse styling, create an app that

    ผมทำเครื่องมือเล็กๆ แบบนี้มาตั้งแต่ก่อนยุค AI และชอบที่สามารถส่งเครื่องมือให้เพื่อนทางอีเมลพร้อมบอกว่า “ถ้าอยากแก้อะไรก็โยนให้ LLM จัดการได้เลย”

    • วิธีนี้แหละถูกต้อง
      เวลาสร้างแดชบอร์ด แอปเล็กๆ หรือยูทิลิตีที่โต้ตอบกับ API หรือดึงข้อมูลจากที่ไหนสักแห่ง ช่วงขอบเขตที่ไปได้ด้วย ไฟล์ HTML ไฟล์เดียว ที่มีสไตล์และ JS อยู่ข้างในนั้นกว้างอย่างน่าทึ่ง แค่โยนไว้ในโฟลเดอร์ ~ ส่วนตัวบนเซิร์ฟเวอร์แชร์ของบริษัท ทุกคนก็เปิดดูและใช้งานได้ทันที
    • ตอนวนทำดีไซน์ให้ลูกค้าใหม่ ผมก็สร้างด้วย index.html ง่ายๆ ใส่ inline CSS ลงไป และพอพอใจกับผลลัพธ์ ก็เอาไฟล์นั้นไปวางข้างๆ ไฟล์เทมเพลตของโปรเจกต์ แล้วให้ LLM ช่วยผสานดีไซน์จาก index.html เข้าไปในไฟล์เทมเพลต
    • ก่อนหน้านี้ผมไม่เคยคิดถึง use case นี้จริงจังเลย เลยรู้สึกว่าตัวเองงี่เง่านิดหน่อย มันชัดเจนมากว่าใช้งานได้ดี
      ที่ผ่านมาพอใช้ LLM จุดโฟกัสอยู่ที่ “ตัวแอป” เอง ไม่ใช่เครื่องมือเสริมรอบๆ แอป แต่เครื่องมือเสริมพวกนั้นไม่จำเป็นต้องสมบูรณ์แบบหรือรองรับทุกกรณี ขอแค่ทำงานได้พอมีประโยชน์ก็พอ ใช้เสร็จก็ทิ้ง แล้วพรุ่งนี้ค่อยสร้างใหม่ก็ได้
    • ผมค้นพบทริกนี้มานานแล้ว เลยทำเครื่องคิดเลขสำหรับวงจรอิเล็กทรอนิกส์แอนะล็อกไว้เพียบ: https://cofree.coffee/~solomon/calculators/
      การประกอบเครื่องมือแบบนี้อย่างรวดเร็วแล้วเอาขึ้นเว็บแบบ static สะดวกมาก
    • บน Claude เว็บ ถ้าขอ HTML มันก็ทำแบบนี้เหมือนกัน เพราะมันทำออกมาเป็น artifact จึงมีโอกาสสูงที่โมเดลจะ ถูกฝึกกับแพตเทิร์นนี้มาดี

  • เทคโนโลยีเว็บนี่ทำหลายอย่างได้ดีมากจริงๆ คนบ่นกันเยอะก็จริง แต่ก็น่าทึ่ง
    ที่ทำงานก่อนหน้านี้ผมต้องดูแลแอปที่เขียนแบบ vibe coding และสุดท้ายก็ลาออกเพราะเรื่องนั้น โครงสร้างเป็นฟรอนต์เอนด์ Next.js หน้าเดียวกับแบ็กเอนด์ API แยกกัน ทำให้ URL ฝั่งผู้ใช้ไม่สอดคล้องกับ endpoint ของแบ็กเอนด์ เพราะ AI ใส่ React hooks ให้กับทุกอย่าง สถานะเลยอยู่ในหน่วยความจำ และ routing ตาม URL ก็จะไม่มีเลยถ้าไม่ออกแบบไว้โดยตั้งใจ ผลคือเราไม่ได้ลิงก์มาแบบฟรีๆ และผู้ใช้ก็ไม่มีทางลิงก์ไปยังจุดไหนได้นอกจากหน้าเข้าใช้งานหลัก ลิงก์ น่ะนะ โดยเฉพาะกับเครื่องมือภายใน ทุกอย่างควรลิงก์ได้เพื่อให้การทำงานร่วมกันและการแก้ปัญหาง่ายขึ้น แนวคิดการออกแบบที่ต้องมีตำแหน่งทรัพยากรและกริยาแบบเป็นหนึ่งเดียวกันนั้น ถือว่าคิดมาดีมากจริงๆ ตั้งแต่ 30–40 ปีก่อนแล้ว

    • หมายถึงว่าเวลาไปหน้าอื่นหรือแท็บอื่น URL ไม่ได้อัปเดตเลยใช่ไหม?

  • มีจุดแลกเปลี่ยนบางอย่างระหว่าง HTML กับ Markdown ที่ตกหล่นไปตรงนี้ HTML มีประสิทธิภาพด้านโทเคน แย่กว่ามาก และการให้ฟีดแบ็กที่แม่นยำกับแผน HTML ก็ยากกว่า Markdown
    จุดแลกเปลี่ยนทั้งสองนี้กลับเป็นประโยชน์ต่อ Anthropic ถ้าใช้ HTML เป็นสื่อ จำนวนโทเคนก็จะเพิ่มขึ้น และมีโอกาสว่าพวกเขากำลังลงทุนกับเครื่องมือสำหรับใส่คอมเมนต์หรือทำเครื่องหมายบน HTML ในฐานะส่วนหนึ่งของ Claude Design ซึ่งอาจทำให้เกิด lock-in ได้มากขึ้นด้วย จะบังเอิญหรือเป็นกลยุทธ์อันชาญฉลาดก็ไม่รู้

    • มันมีประสิทธิภาพน้อยกว่านิดหน่อยก็จริง แต่ถ้าไม่ได้มีโครงสร้างหรือองค์ประกอบภาพเยอะมาก ความต่างก็ไม่ได้มหาศาล
      และผมก็ไม่ค่อยเข้าใจว่าทำไมการให้ฟีดแบ็กที่แม่นยำถึงยากกว่า Markdown มากนัก เราใส่ id ในแท็ก มี section ต่างๆ ได้อยู่แล้ว
    • HTML ยังมีขอบเขตของ ช่องโหว่จากการรันโค้ด กว้างกว่าด้วย ข้อความธรรมดาไม่ทำอันตรายใดๆ

  • แม้จะทำงานกับ HTML มาหลายสิบปี แต่สำหรับเอกสารง่ายๆ Markdown ก็ยังเร็วกว่า อยู่ดี ถ้ามีจุดกึ่งกลางก็คงดี และจริงๆ ก็มีของที่เพิ่มความสามารถมากขึ้นอยู่แล้ว เช่น GitHub Markdown
    จะ embed Mermaid ก็ได้ หรือจะใช้ MDX ที่ผสมคอมโพเนนต์ได้เมื่อจำเป็นก็ได้ เท่าที่รู้ readme.com ก็ใช้ MDX ภายในเหมือนกัน ถ้าต้องการการ์ดหรือเลย์เอาต์ ก็อาจใส่คอมโพเนนต์ที่อิงกับ Bootstrap อะไรแบบนั้นได้ ตอนนี้ที่ขาดอยู่ก็มีแค่การรองรับจากอินเทอร์เฟซ เพราะในเมื่อเรนเดอร์ HTML ตรงๆ ได้อยู่แล้ว การเพิ่ม Markdown ที่ทรงพลังขึ้นก็คงไม่ใช่เรื่องยากนัก

    • ผมว่า MDX คือจุดกึ่งกลางที่สมบูรณ์แบบเลย เพราะคอมเมนต์นี้ ผมคงเริ่มใช้ MDX แทน Markdown ปกติ

  • ทั้งสเปก Markdown ดั้งเดิม [1] และ CommonMark [2] ต่างก็ระบุชัดเจนว่ารองรับ inline HTML ดังนั้นขึ้นอยู่กับงาน เราจึงพอจะได้ข้อดีของทั้งสองฝั่งในระดับหนึ่ง
    โดยมากคุณใช้หัวข้อและย่อหน้าของ Markdown ตามปกติ แล้วแทรกรูปกับตาราง ซึ่งยังอ่านในรูปต้นฉบับได้ดีโดยไม่ต้องมีแท็ก HTML ถ้าต้องการใส่อะไรอย่าง SVG แบบที่ผู้เขียนยกตัวอย่าง ก็ embed SVG ตรงๆ ได้เลย แล้วคนดูก็เรนเดอร์ Markdown ด้วย viewer ที่ตัวเองชอบได้ ถ้าดูไฟล์ Markdown ดิบใน VS Code แล้วเจอแท็ก HTML ก็แค่กด Cmd+Shift+V เพื่อเปิดพรีวิว จบ แน่นอนว่าถ้าเป็นหน้าเว็บจริงจังที่มีปุ่มโต้ตอบและสไตล์แบบกำหนดเองเต็มรูปแบบก็คงทำได้ยาก แต่ถ้าส่วนใหญ่เป็นข้อความ รูปภาพ ตาราง และแค่เพิ่มองค์ประกอบเสริมเป็นบางจุด ก็ไปได้ไกลพอสมควร
    [1] https://daringfireball.net/projects/markdown/syntax#html
    [2] https://spec.commonmark.org/0.31.2/#html-blocks

    • ผมคิดว่าเอกสาร Markdown ไม่ควรต้องพึ่งพรีวิว ถ้าจะเป็นแบบนั้นก็สร้าง เอกสาร HTML ไปเลยดีกว่า

  • ตั้งแต่เดือนมกราคม ผมผลักดันแนวทางนี้อย่างหนักสำหรับงานที่ไม่ใช่การเขียนโค้ด คุณสมบัติสำคัญคือมันเป็น แหล่งความจริงหนึ่งเดียวที่แก้ไขได้ เข้าใจได้ทั้งโดย LLM และมนุษย์ เรนเดอร์ได้ และค่อยๆ ปรับแก้เพิ่มได้
    ผมคุยกับคนทั่วไปเรื่องงานร่วมกับ AI บ่อยมาก และถ้าบังเอิญเจอวงสนทนาเกี่ยวกับ AI ตามที่สาธารณะ ผมก็มักจะแทรกตัวเข้าไปเหมือนนักมานุษยวิทยา HTML artifact เหมือนแถบ URL ของเบราว์เซอร์แบบใหม่ คล้ายกับที่ผู้ใช้บางคนเข้าใจว่าแถบนั้นจริงๆ คือ Google เดี๋ยวนี้หลายคนพูดถึงงานอย่าง “สเปรดชีต”, “พรีเซนเทชัน”, “สรุปการตลาด 1 หน้า”, “สไลด์โชว์”, “วิเคราะห์คู่แข่ง”, “ไดอะแกรมระบบ HVAC” แล้วบอกว่าการทำงานใน ChatGPT หรือ Claude บนเว็บนั้นไม่ค่อยดี แต่การสร้างเอกสารใหม่ด้วย Claude Code หรือ OpenClaw นั้นเหมือนปาฏิหาริย์
    ถ้าถามต่อว่าเอกสารจริงๆ คืออะไร และประสบการณ์ต่างกันอย่างไร มักต้องซักค่อนข้างเยอะหรือขอให้เขาโชว์ให้ดู เพราะยังไม่มีคำศัพท์ด้านคอมพิวเตอร์มารองรับดีพอ แต่สุดท้ายก็มักลงเอยว่าตัว artifact นั้นเป็น HTML เสมอ ประสบการณ์ที่ดีมาจากการแก้ไขวนซ้ำไฟล์ HTML จริงในระบบไฟล์ (+CSS+ภาพ) พร้อมการเรนเดอร์ทันทีคุณภาพสูง และยังโรย JavaScript เพิ่มได้เล็กน้อยเมื่อจำเป็น ถ้ามีระบบ git ก็อาจได้การจัดการเวอร์ชันโดยไม่รู้ตัว ถ้าไม่มีก็จะแนะนำให้สร้าง checkpoint ซึ่งสำหรับคนทั่วไป การจัดการเวอร์ชันอาจเป็นขั้นถัดไปของการเรียนรู้
    ในทางกลับกัน ประสบการณ์ที่ฝังอยู่บนเว็บคือการคอยจิ้ม DOCX/PPTX/XLSX ที่ยังค้างอยู่ใน context window หลายรอบ พร้อมรับมือกับแนวคิดเลือนรางเรื่องที่เก็บข้อมูลในเครื่อง ทั้งที่จริงๆ แล้วมันเรนเดอร์เป็น HTML อยู่ใน sidebar นั่นเอง เวิร์กโฟลว์แบบ HTML ยังทำให้รวมสื่อชนิดอื่นได้ง่ายขึ้นมากด้วย สุดท้ายแล้วงานนำเสนอแบบนี้ก็คือ vibe coding สำหรับมวลชน และไม่จำเป็นต้องรู้ด้วยซ้ำว่า “เต่า” ทั้งหมดที่ซ้อนอยู่ข้างล่างคืออะไร แต่ถ้าอยากรู้ ก็เปิดออกมาแก้ไขเองหรือส่งต่อให้อีกเอเจนต์ได้ง่าย กลายเป็นว่าระบบที่ถูกสร้างมาเพื่อการสื่อสารร่วมกันแบบมัลติมีเดีย กำลังมีประโยชน์ต่อการที่ปัญญาของเครื่องช่วยงานสื่อสารของเรา

  • ก่อนหน้านี้เรา(https://www.definite.app/) เคยให้เอเจนต์ของเราเขียนรายงานและแดชบอร์ดเป็น สเปก YAML ที่เฟรมเวิร์กฟรอนต์เอนด์จะนำไปเรนเดอร์
    เช่น ถ้าผู้ใช้บอกว่า “ช่วยทำรายงานที่แสดงยอดขายรายเดือนกับจำนวนคำสั่งซื้อ และโชว์ 100 คำสั่งซื้อล่าสุดให้หน่อย” เอเจนต์ก็จะเขียนสเปกที่ฟรอนต์เอนด์เอาไปเรนเดอร์ วิธีนี้เร็วก็จริง แต่เราจมอยู่กับคำขอฟีเจอร์ที่เฟรมเวิร์กต้องรองรับ เช่น “ตรงนี้อยากเอา label ออก”, “ตรงนั้นต้องมี label”, “ทำกราฟนี้เป็น heatmap ได้ไหม” ช่วงสองสามเดือนที่ผ่านมา เราเปลี่ยนให้เอเจนต์เขียน HTML ไปเลย การสร้างใช้เวลานานขึ้น แต่ไม่มีข้อจำกัดเรื่องการปรับแต่ง แม้วิธีใหม่จะยังมีปัญหาอีกมาก เช่นผู้ใช้ที่ไม่ใช่สายเทคนิคต้องมาดีบักแอปประหลาดที่ตัวเองสร้างขึ้น แต่โดยรวมลูกค้าชอบมากกว่ามาก

    • ในกรณีนี้ป้องกัน prompt injection กันอย่างไร?

  • เวลาอ่านผลลัพธ์ยาวๆ จากเอเจนต์ ผมใช้ VIM กับ macOS Quick Look (รวมถึงส่วนขยายสำหรับเรนเดอร์ Markdown) หรือไม่ก็วางลงใน MarkEdit ที่มีพาเนลพรีวิว
    ถ้าแย่ที่สุด ก็ให้เอเจนต์สร้างเว็บเพจโลคัลง่ายๆ ที่ตีความและเรนเดอร์ Markdown ให้ก็ได้ Markdown ถูกคิดค้นขึ้นมาเป็นรูปแบบย่อของไวยากรณ์เว็บ [0] และนี่ก็เป็น use case ตรงตัวเลย ผมคิดว่าปริมาณโทเคนและเวลาที่ต้องใช้เพื่อให้เอเจนต์แปลง Markdown พื้นฐานเป็น HTML น่าจะมากกว่าวิธีเหล่านี้
    0. https://daringfireball.net/projects/markdown/

    • น่าจะจริงที่ใช้โทเคนมากขึ้น แต่ผู้เขียนทำงานที่ Anthropic เลยอาจไม่เคยต้องจ่าย ค่าโทเคน เอง
    • ถ้าอยาก vibe กันให้สุดทาง ทำไมไม่ให้บอทสรุปผลลัพธ์ยาวๆ ให้เลยล่ะ?
      การใช้บอทตอนนี้มันช่างวุ่นวายและวนอ้างอิงตัวเองไปหมดจริงๆ
    • อยากรู้ว่าใช้ Quick Look extension ตัวไหนอยู่ กำลังหาตัวที่ใช้ได้ดีอยู่พอดี