สงครามเฟรมเวิร์ก Claude Code

 (shmck.substack.com)
40 คะแนน โดย GN⁺ 2025-09-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตอนนี้นักพัฒนายังอยู่ในช่วงเรียนรู้ วิธีทำงานร่วมกับ AI และคุณค่าของ Claude จะถูกดึงออกมาได้สูงสุดเมื่อใช้งานมันในฐานะ เฟรมเวิร์ก ไม่ใช่แค่แชตบอตธรรมดา
  • ในชุมชนมีการทดลองหลากหลายรูปแบบอย่างต่อเนื่องเกี่ยวกับการจัดวางและใช้งาน Claude จนถึงขั้นเรียกได้ว่าเป็น Claude Code Framework Wars
  • จากแนวโน้มนี้กำลังก่อให้เกิดรูปแบบการใช้ Claude ในหลายบทบาท เช่น ผู้จัดการโครงการ, สถาปนิก, นักพัฒนา, ผู้รีวิว
  • การออกแบบเฟรมเวิร์กต้องตัดสินใจหลัก 8 ด้าน ได้แก่ การจัดการงาน, การให้คำแนะนำ, การทำงานร่วมกันของเอเจนต์, การจัดการเซสชัน, การเข้าถึงเครื่องมือ, การพัฒนาโค้ด, การส่งมอบ, การเก็บรักษาบริบท
  • บทเรียนสำคัญคือ AI ไม่ได้มาแทนนักพัฒนา แต่กำลังก้าวมาเป็น เพื่อนร่วมงานที่ช่วยทวีคูณประสิทธิภาพผ่านกฎและบทบาทที่มีโครงสร้าง

บทนำ

  • แนวคิดหลัก: มอง Claude ไม่ใช่แค่เครื่องมือสนทนา แต่เป็น เฟรมเวิร์ก ที่ใช้กฎชัดเจนและขั้นตอนการทำงานเพื่อสร้างผลลัพธ์ที่คาดการณ์ได้และมีคุณค่า
    • นักพัฒนาจะเปลี่ยนจากการลงมือเขียนโค้ดไปสู่ บทบาทมูลค่าสูง (การจัดการโครงการ, การออกแบบ, สถาปัตยกรรม)
    • เฟรมเวิร์ก Claude Code ทำงานได้ด้วย พรอมป์ต์ที่มีโครงสร้าง โดยไม่ต้องเขียนโค้ด
  • สงครามเฟรมเวิร์ก Claude Code: ชุมชนนักพัฒนากำลังทดลองแนวทางหลากหลายเพื่อใช้งาน AI ให้เกิดประสิทธิผล
    • มีโปรเจกต์โอเพนซอร์สนับสิบที่แข่งขันกันกำหนดขั้นตอนการทำงานและโครงสร้างบทบาท
    • ตัวอย่าง: Agent OS, Claude-Flow

ตัวเลือกสำคัญที่ควรพิจารณาในการออกแบบเฟรมเวิร์ก

1. ตำแหน่งของการจัดการงาน

  • จำเป็นต้องกำหนด แหล่งเก็บงาน ที่ Claude สามารถอ้างอิงได้
    • Markdown backlog: จัดการงานเป็นรายการสิ่งที่ต้องทำในรูปแบบ Markdown
    • ข้อความแบบมีโครงสร้าง: แปลงสเปกผลิตภัณฑ์ให้เป็นงาน
    • Issue/Ticket: เก็บสเปกไว้ใน GitHub Issues หรือ Jira ticket และเชื่อมกับการรีวิวโค้ด
      • ตัวอย่าง: ccpm
    โฆษณา
  • หัวใจสำคัญ: งานต้องถูกเก็บไว้ในตำแหน่งที่ Claude เข้าถึงและติดตามได้

2. วิธีให้คำแนะนำแก่ Claude

  • ให้คำสั่งกับ Claude ด้วย โครงสร้างที่ชัดเจน แทนพรอมป์ต์กำกวม
    • คลังคำสั่ง: slash command ที่กำหนดไว้ล่วงหน้า เช่น /create-tasks, /review
    • มาตรฐานการเขียนโค้ด: ระบุ tech stack และแนวปฏิบัติในการเขียนโค้ด
    • นิยามความเสร็จสมบูรณ์: เขียนเกณฑ์การเสร็จงานให้อยู่ในรูปแบบที่ตรวจสอบได้
    • hook สำหรับตรวจสอบแบบ trigger: บังคับ linting และการทดสอบกับทุกการเปลี่ยนแปลง
    • Claude reviewer: ให้ Claude ทำทั้งงานพัฒนาและรีวิวไปพร้อมกัน
  • หัวใจสำคัญ: กฎที่ชัดเจนและทำซ้ำได้ช่วยยกระดับคุณภาพงานของ Claude

3. โครงสร้างการทำงานร่วมกันของเอเจนต์

  • เมื่อใช้เอเจนต์ Claude หลายตัว ต้องประสานงานด้วย บทบาทและแผนงาน
    • การจำลองบทบาท: ให้ AI ทำหน้าที่เป็น PM, สถาปนิก, นักพัฒนา, ผู้ทดสอบ
    • การประมวลผลแบบ swarm ขนาน: รันเอเจนต์หลายตัวพร้อมกันในขั้นตอนที่มีโครงสร้าง เช่น สเปก → pseudocode → โค้ด → การทดสอบ
    • artifact ที่เป็น native ของ repository: เก็บงาน, log, บันทึกการตัดสินใจ (ADR) ไว้ใน codebase เพื่อให้ความจำต่อเนื่อง
  • หัวใจสำคัญ: การประสานงานช่วยป้องกันการชนกันของ AI worker หลายตัว
โฆษณา

4. วิธีจัดการเซสชัน

  • ตั้งค่า เซสชัน ให้เป็นสภาพแวดล้อมการทำงานเพื่อป้องกันความสับสนจากผลลัพธ์ของ AI
    • terminal orchestration: ให้ Claude ควบคุมคำสั่ง หน้าต่าง และ log
    • worktree แบบขนาน: รันหลาย branch พร้อมกันด้วย Git Worktrees
      • ตัวอย่าง: Crystal
    • container แบบขนาน: รัน Claude ใน container แยกอิสระเพื่อลดการชนกัน
  • หัวใจสำคัญ: งานแบบขนานช่วยเพิ่มประสิทธิภาพสูงสุดโดยไม่ชนกัน

4. วิธีรันเซสชัน

  • ตั้งค่า เซสชัน ให้เป็นสภาพแวดล้อมการทำงานเพื่อป้องกันความสับสนจากผลลัพธ์ของ AI
    • terminal orchestration: ให้ Claude ควบคุมคำสั่ง หน้าต่าง และ log
    • worktree แบบขนาน: รันหลาย branch พร้อมกันด้วย Git Worktrees
      • ตัวอย่าง: Crystal
    • container แบบขนาน: รัน Claude ใน container แยกอิสระเพื่อลดการชนกัน
    โฆษณา
  • หัวใจสำคัญ: งานแบบขนานช่วยเพิ่มประสิทธิภาพสูงสุดโดยไม่ชนกัน

5. การเข้าถึงเครื่องมือของ Claude

  • ตั้งค่าให้ Claude ใช้ ความรู้ ครอบคลุมทั้ง tech stack
    • การรวม MCP: เชื่อมต่อ browser, database, test runner, framework สำหรับ UI automation
    • คลังเครื่องมือแบบกำหนดเอง: สร้างด้วย shell script และคำสั่งต่าง ๆ
    • ตัวเข้าถึงฐานข้อมูล: เครื่องมือเข้าถึงฐานข้อมูลที่ทรงพลัง
      • ตัวอย่าง: Claudable with Supabase
    • hook สำหรับทดสอบและตรวจสอบ: รันทดสอบด้วย Vitest, Jest ฯลฯ ก่อนจบงาน
  • หัวใจสำคัญ: การรวมเครื่องมือช่วยเปลี่ยน Claude จากระบบ autocomplete ธรรมดาให้กลายเป็น สมาชิกทีมที่ลงมือทำงานจริง

6. วิธีพัฒนาโค้ด

  • Claude สามารถทำหน้าที่เป็น หลายบทบาท ได้ตามความจำเป็น
    • ผู้จัดการโครงการ (PM): แปลงสเปกผลิตภัณฑ์เป็นงานและ backlog
    • สถาปนิก: ออกแบบโครงสร้างโดยรวม กำหนด interface และวางกฎก่อนเริ่มเขียนโค้ด
    • ผู้ลงมือเขียน: เขียนโค้ดตามการทดสอบและมาตรฐาน
    • QA: ตรวจสอบปัญหาของงาน
      โฆษณา
    • ผู้รีวิว: ตรวจสอบคุณภาพ PR ความอ่านง่าย และความเสี่ยง
  • หัวใจสำคัญ: ใช้ AI ได้ตลอดทั้งวงจรชีวิตของซอฟต์แวร์

7. วิธีส่งมอบโค้ด

  • ต้องกำหนด วิธี ที่โค้ดจะไปถึง repository
    • ความต่างขนาดเล็ก: ให้ AI จัดการ ticket และสร้าง PR ขนาดเล็ก โดยต้องมีการรีวิวเสมอ
    • การทดลอง: ปล่อยการเปลี่ยนแปลงไว้หลัง feature flag
    • การ scaffold ทั้งแอป: สร้างและ deploy ทั้งแอปจากพรอมป์ต์ระดับสูง
  • หัวใจสำคัญ: เลือกระหว่างรอบการทำงานที่ปลอดภัยสำหรับ production หรือการ scaffold เพื่อทำต้นแบบ

8. วิธีเก็บรักษาบริบท

  • แก้ปัญหาการลืมของ Claude ด้วย หน่วยความจำของเฟรมเวิร์ก
    • เอกสารและบันทึกประจำวัน: อัปเดต CLAUDE.md, บันทึกสถาปัตยกรรม, project journal ให้เป็นปัจจุบัน
    • หน่วยความจำต่อเนื่องและการตรวจสุขภาพ: สรุปงานล่าสุด ตรวจสุขภาพโปรเจกต์ และเก็บการตัดสินใจ
      โฆษณา
  • หัวใจสำคัญ: หากไม่มีหน่วยความจำ AI จะทำผิดซ้ำ แต่ถ้ามีหน่วยความจำก็จะต่อยอดความคืบหน้าได้

แนวทางการผสานเข้าด้วยกัน

  • มองตัวเลือกเหล่านี้เป็น เมนู ไม่จำเป็นต้องตั้งค่าทุกอย่างพร้อมกันในครั้งเดียว
    • การตั้งค่าสำหรับผู้เริ่มต้น: Markdown backlog + ความต่างของ ticket
    • ทีมที่มีโครงสร้าง: สเปกผลิตภัณฑ์ + มาตรฐาน + การจำลองบทบาท
    • เน้นการทดลอง: repository artifact + เซสชันแบบขนาน
    • โหมดทำต้นแบบ: app builder + document scaffold

บทสรุปและนัยสำคัญ

  • บทเรียนหลัก: Claude ทำผลงานได้ดีที่สุดในสภาพแวดล้อมที่ มีโครงสร้าง
    • ไม่ใช่การแทนที่บทบาทนักพัฒนา แต่เป็นการลดงาน boilerplate เพื่อให้โฟกัสกับการกำหนดสเปก การทบทวนการออกแบบ และการนิยามสถาปัตยกรรม
    • หากงานถูกวางผิดทิศก็มีโอกาสหลุดออกนอกเส้นทางได้อย่างรวดเร็ว จึงต้องมีการจัดการเชิงโครงสร้าง
  • แม้ตอนนี้ยังอยู่ในระยะแรก แต่เฟรมเวิร์กกำลังทำให้ AI ค่อย ๆ เปลี่ยนจาก กล่องเวทมนตร์ ไปเป็นกลุ่มของ สมาชิกทีมที่จัดการได้
    • ยิ่งให้โครงสร้างมากเท่าไร ก็ยิ่งได้คุณค่ากลับคืนมากขึ้นเท่านั้น
  • ชุมชนกำลังทดลองเฟรมเวิร์กหลากหลายผ่าน โปรเจกต์โอเพนซอร์ส เพื่อค้นหาวิธีใช้ AI อย่างมีประสิทธิผล
  • นักพัฒนาสามารถใช้ Claude อย่างเป็นระบบเพื่อโฟกัสกับ งานมูลค่าสูง และผสาน AI เข้าเป็นสมาชิกทีมเพื่อเพิ่มประสิทธิภาพสูงสุด

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

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

 
GN⁺ 2025-09-08
ความคิดเห็นจาก Hacker News

  • ลองใช้ "framework" หลายตัวสำหรับ Claude Code แล้ว แต่ยังไม่แน่ใจว่าโดยภาพรวมประสิทธิภาพดีขึ้นจริงหรือไม่
    มันดูเต็มไปด้วยพิธีกรรมรอบกระบวนการที่ซับซ้อนราวกับเป็นสูตรสำเร็จ แต่ก็ยังสงสัยว่าจริง ๆ แล้วมันช่วยเพราะอะไร
    รู้สึกว่าวิธีแบบ framework พวกนี้ไม่ค่อยสอดคล้องกับเป้าหมายการฝึกโมเดล
    ในทางปฏิบัติมันเหมือนโยนข้อมูลที่ไม่จำเป็นเข้าไปให้โมเดล แล้วฝืนทำให้เข้ากับ "กระบวนการที่ฉันตั้งไว้" จนทำให้บริบทปนเปื้อน
    สิ่งสำคัญน่าจะเป็นการกำจัดการปนเปื้อนของบริบท ให้เฉพาะข้อมูลที่จำเป็นต่อการทำงานจริง และค่อย ๆ ปรับปรุงไปทีละขั้น
    วิธีทำงานร่วมกันแบบดั้งเดิมเช่นนี้น่าจะเหมาะกว่าถ้าไปเกิดขึ้นนอกบริบทของเอเจนต์ที่มีข้อจำกัดด้าน context

    • บทความนี้ไม่พูดถึง subagents เลย จึงสงสัยว่ามันเขียนขึ้นเมื่อไหร่
      ฉันมอบหมายงานอย่าง "ดึงมาเฉพาะข้อมูลจาก memory bank ที่เกี่ยวข้องกับงานปัจจุบัน" หรือ "รันเทสต์แล้วส่งกลับมาเฉพาะความล้มเหลวกับ coverage" ให้ subagent ทำ
      แบบนี้ช่วยป้องกันไม่ให้ context ของเอเจนต์หลักเต็มเร็วเกินไปได้
      https://docs.anthropic.com/en/docs/claude-code/sub-agents

    • หลังจากนำแนวปฏิบัติที่ใช้งานได้จริงบางอย่างอย่าง dev containers และ worktrees มาใช้ ชีวิตก็สะดวกขึ้นมาก
      ฉันยังทำ shell script "framework" ของตัวเองสำหรับจัดการไฟล์โปรเจกต์และสร้าง worktree ซึ่งใช้เวลาทำแค่ประมาณสองวัน
      ทำให้ไม่ต้องยึดติดกับเครื่องมือใดเครื่องมือหนึ่ง
      เห็นด้วยว่าปัญหา context ปนเปื้อนเป็นเรื่องจริงที่ต้องใส่ใจ
      โดยเฉพาะหลังจากเจอว่า definition ของ MCP endpoint กิน context ของฉันไปเยอะมาก (ประมาณ 20,000 โทเค็น) เวลาจะเลือก MCP เลยต้องคิดเรื่อง context ด้วยเสมอ

    • รู้สึกว่ามันคล้ายสถานการณ์ของผู้จัดการโปรเจกต์จริง ๆ

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

    • ให้ความรู้สึกคล้าย deep research tool ของ OpenAI
      บ่อยครั้งที่เจอว่ามันไม่สนใจคำถามที่ยังคลุมเครือเลย จนเกิดความผิดพลาดหลายอย่าง

  • พอใช้ framework พวกนี้ อยากรู้ว่าจริง ๆ แล้วเปิดให้มันมีอิสระแค่ไหน และใช้ในสภาพแวดล้อมแบบไหน (greenfield/brownfield)
    อยากถามว่ามีใครเคยใช้ Claude Code กับซอฟต์แวร์ระดับองค์กรแล้วได้ผลลัพธ์แบบมั่นใจบ้างไหม
    ที่บริษัทฉันเข้าถึง Claude Code ได้ค่อนข้างอิสระ แต่ในโค้ดเบสของตัวเองถ้ามี frontend UI หรือ Playwright เข้ามา ผลลัพธ์จะไม่นิ่ง
    อยากรู้เทคนิคการใช้งานจริง เช่น เหลือเศษโค้ดไว้มากแค่ไหน ความล้าจากการทำงานร่วมกับเพื่อนร่วมทีมเป็นอย่างไร ขนาดของ pull request ต้นทุนการ reasoning และจัดการอย่างไรเมื่อทำงานแบบขนาน
    เอกสาร README มักเต็มไปด้วยศัพท์เฉพาะของระบบ อีโมจิ หรือวิธีจัดชุดเครื่องมือที่เฉพาะตัวเกินไป จนบางครั้งให้ความรู้สึกเหมือนเอกสารโฆษณาเพื่อขาย
    สุดท้ายก็คิดว่า Anthropic หรือที่อื่น ๆ คงเอาความสามารถพวกนี้ไปรวมไว้ใน CLI ของตัวเอง
    ส่วนตัวฉันใช้ reasoning model จัดการทั้งสเปกยาว 10 หน้า, lint/type check/formatter/hook แบบเข้มงวด, เช็กลิสต์งาน, และ red/green TDD แล้วให้ GPT-5 แค่คำว่า “go” ครั้งเดียว ผลลัพธ์ที่ต้องการก็ถูกสร้างขึ้นมาอัตโนมัติ
    ถ้ามีแค่เครื่องมือชุดเดียวกัน ใคร ๆ ก็สร้างระบบของตัวเองได้ง่าย

    • ฉันเองก็เพิ่งใช้ Claude Code มาแค่ราว 3 สัปดาห์ แต่ช่วงหลังได้ผลลัพธ์ที่น่าประทับใจจากโครงสร้างตามบทบาท (เช่น persona) ในโค้ดเบส Elixir/Phoenix ขนาดใหญ่ที่มีมากกว่า 500,000 SLOC
      ฉันใช้แพ็กเกจ Max ราคา $200 ทำให้ต้นทุนการ reasoning คงที่
      โดยเฉพาะในสถานการณ์แบบ greenfield อย่างการเพิ่มฟีเจอร์ใหม่ ผลลัพธ์ชัดเจนมาก
      ส่วนงานรีแฟกเตอร์ที่ซับซ้อนหรือการเปลี่ยนแปลงเชิงลึกของระบบก็เดินหน้าได้พอสมควรถ้ามีเอกสารออกแบบที่ดี แต่ถ้าเอกสารไม่พอ ประสิทธิภาพจะไม่ค่อยออก
      ช่วงแรกได้ "โค้ดที่ไม่ดี" ค่อนข้างมาก—ทั้งสไตล์และความสามารถในการนำกลับมาใช้ซ้ำ/บำรุงรักษาที่ยังด้อย แต่หลังจากปรับปรุงไฟล์ CLAUDE.md และบังคับให้ persona ฝั่งนักพัฒนาต้องใช้ subagent "elixir-code-reviewer" คุณภาพโค้ดก็ดีขึ้นอย่างเห็นได้ชัด
      แพลตฟอร์มของเราเป็นโอเพนซอร์ส จึงแชร์การตั้งค่า Claude command และ subagent ไว้ที่นี่
      https://github.com/Simon-Initiative/oli-torus/tree/master/.claude

  • จากบทความบล็อกนี้สัมผัสได้ถึงสไตล์แบบ LLM อย่างชัดเจน
    เป็นข้อมูลที่มีประโยชน์ แต่ก็ตลกดีที่เรากำลังเรียนรู้เรื่อง AI จาก AI

    • ช่วงนี้บทความเกี่ยวกับ AI หลายชิ้นก็ให้ความรู้สึกแบบนี้
      เอาเข้าจริง ถ้าไม่ใช่งานที่ไม่ต้องใช้ความเชี่ยวชาญ คุณต้องคอยเฝ้าดู Claude Code โดยตรง และต้องแทรกแซงทันทีเมื่อมันเริ่มไปผิดทาง
      ในแง่ความปลอดภัยก็ให้สิทธิ์มากเกินไปไม่ได้ และต้องตรวจดูว่ามันรันคำสั่งอะไรจริง ๆ
      "framework" ในตอนนี้ยังต้องไปอีกไกล และในเวลานี้มองมันเป็นแค่ “เด็กฝึกงานจูเนียร์ที่เขียนโค้ดได้เร็วมาก” น่าจะตรงความเป็นจริงกว่า

    • ผู้เขียนอาจตรวจ repo ไม่ละเอียดพอ หรืออาจเป็นผลจากการรีเสิร์ชที่จำกัดจริง ๆ
      ตัวอย่างเช่น superClaude ไม่ใช่ MCP server และ metaGPT ก็ดูเหมือนจะไม่เข้ากับ Claude Code

  • ฉันสงสัยมาตลอดว่าทำไมเราไม่ปล่อยให้ agent จัดการ context ของตัวเองเหมือนมนุษย์
    ไม่เข้าใจว่าทำไมต้องแนบประวัติการทำงานก่อนหน้าทั้งหมดทุกครั้ง
    ถ้าปล่อยให้ agent ตัดสินใจเองว่าควรเก็บ context ไหนไว้จึงจะมีประสิทธิภาพ และให้มันเรียนรู้ข้อดีข้อเสียของการจัดการบริบทด้วยตัวเอง ความสามารถในการทำงานแต่ละอย่างก็น่าจะดีขึ้น

  • ท้ายที่สุดมันก็ดูเหมือน textbook "bitter lesson" ซ้ำรอยอีกครั้ง
    ผู้คนสร้าง "framework" กันสารพัด แต่โมเดลรุ่นถัดไปก็ทำให้ทั้งหมดไร้ความหมาย
    http://www.incompleteideas.net/IncIdeas/BitterLesson.html

  • ค่อนข้างแปลกใจที่ไม่มีการพูดถึง BMAD-method
    จากประสบการณ์ของฉัน BMAD-method เป็นตัวเสริมที่ดีที่สุดสำหรับ Claude Code

    • อยากรู้ว่า BMAD-method คืออะไร
      มันเป็นเพียงระดับ system prompt หรือเปล่า แล้วอะไรทำให้มันรู้สึกมีประโยชน์ขนาดนั้น
      https://github.com/bmad-code-org/BMAD-METHOD

    • ระบบ BMAD ดูคล้ายกับ AgentOS ที่แนะนำในโพสต์
      วิธีทำ context engineering แบบนี้ใช้ได้ผลกับฉัน และฉันก็ให้ Claude สร้าง command กับ agent ขึ้นมาเองก่อนแล้วค่อยปรับให้ตรงกับความต้องการ
      ช่วงหลังยังใช้ทั้ง json และ markdown อย่างจริงจังเพื่อแชร์ context

    • taskmaster ก็เหมือนกัน แต่ไม่มีอยู่ในลิสต์

  • การจัดการ context ให้ความรู้สึกเหมือนการเขียนโปรแกรมระดับล่าง
    ฉันคิดว่ามันคล้ายกับการต้องใส่ค่าที่ถูกต้องลงใน CPU register เพื่อให้ได้การคำนวณที่ถูกต้อง
    ต่างกันตรงที่สำหรับแต่ละงาน เรามีอำนาจในการเพิ่ม/ลบ context น้อยกว่ามาก

  • พอลองใช้ B-MAD Framework แล้วผลลัพธ์ต่างกันมาก จนตอนนี้ทำงานโดยไม่มีเครื่องมือนี้ไม่ได้แล้ว
    หวังว่าในอนาคตจะมี framework แบบนี้เพิ่มขึ้นอีก

  • อยากรู้ว่ามีใครเคยใช้ framework แบบนี้จริงบ้างไหม
    มันให้ผลลัพธ์จริงหรือเป็นแค่กระแส hype

    • บางครั้งพอเข้าไปดูฝั่ง framework จะพบว่าส่วนใหญ่ถูกสร้างขึ้นเพื่อใช้กับตัวเองทั้งนั้น
      ผลลัพธ์ก็เป็นไปตามคาด มีฟีเจอร์สารพัดแต่ไม่มีการตรวจสอบ ไม่มีเอกสารที่ดี และเต็มไปด้วย Claude-isms
      สุดท้ายแล้วมันใช้ได้จริงแค่กับโปรเจกต์ไม่กี่ตัวที่คนสร้างสนใจเท่านั้น