แนวทางการใช้ Claude Code: แยกการวางแผนออกจากการลงมือทำ

 (boristane.com)
86 คะแนน โดย GN⁺ 2026-02-23 | 4 ความคิดเห็น | แชร์ทาง WhatsApp
  • ปรับโครงสร้างวิธีใช้ เครื่องมือเขียนโค้ดด้วย AI ใหม่จากพื้นฐาน โดยเสนอ เวิร์กโฟลว์ที่ต้องผ่านขั้นตอนทบทวนแผนอย่างชัดเจนก่อนเขียนโค้ดเสมอ
  • หลักการสำคัญคือ “ก่อนอนุมัติแผน อย่าให้ Claude เขียนโค้ด” ซึ่งช่วยให้ควบคุมเชิงโครงสร้างและใช้โทเคนได้อย่างมีประสิทธิภาพ
  • กระบวนการทั้งหมดดำเนินเป็นวงจร Research → Plan → Annotation → Todo List → Implementation → Feedback
  • ในแต่ละขั้นจะทำงานร่วมกันโดยยึด เอกสาร markdown (research.md, plan.md) เป็นศูนย์กลาง และยกระดับความสมบูรณ์ผ่านการใส่คอมเมนต์และแก้ไขซ้ำ
  • วิธีนี้เน้น การแยกแล้วผสานพลังการลงมือทำของ AI กับวิจารณญาณของมนุษย์ เพื่อให้ได้ผลลัพธ์ที่เสถียรและสม่ำเสมอแม้ในระบบที่ซับซ้อน

ภาพรวมเวิร์กโฟลว์ทั้งหมด

  • ตลอดราว 9 เดือนที่ผ่านมา ได้ใช้ Claude Code เป็นเครื่องมือพัฒนาหลัก และแทนที่จะใช้วิธีทั่วไปแบบ “ป้อนพรอมป์ต์ → สร้างโค้ด → วนแก้ไข” ก็ได้สร้างกระบวนการที่เป็นระบบโดย แยกการวางแผนออกจากการลงมือทำ
  • ก่อนที่ Claude จะเขียนโค้ด จะต้องให้มันลงมือทำโดยอิงจาก เอกสารแผน (plan.md) ที่ผู้เขียนตรวจและอนุมัติแล้ว เท่านั้น
  • แนวทางนี้ช่วย ลดการลองผิดลองถูกที่ไม่จำเป็น, รักษาอำนาจการตัดสินใจด้านสถาปัตยกรรม, และ เพิ่มคุณภาพให้สูงสุดเมื่อเทียบกับปริมาณโทเคนที่ใช้

Phase 1: Research

  • ทุกงานเริ่มต้นจาก การวิเคราะห์โค้ดเบสอย่างลึกซึ้ง
    • สั่งให้ Claude วิเคราะห์โฟลเดอร์หรือฟีเจอร์ที่กำหนดแบบ “อ่านอย่างละเอียด (detailed, intricacies)”
    • และต้องบันทึกผลลัพธ์ลงใน ไฟล์ research.md
  • เอกสารนี้ทำหน้าที่เป็น พื้นผิวสำหรับการทบทวน (review surface) เพื่อใช้ตรวจสอบความเข้าใจของ Claude และหากมีความเข้าใจผิดก็จะแก้ในขั้นนี้
  • เพราะรีเสิร์ชที่ผิดจะนำไปสู่แผนและการพัฒนาที่ผิด จึงเป็นการป้องกันล่วงหน้าต่อ ปัจจัยความล้มเหลวที่มีต้นทุนสูงที่สุด
  • ตัวอย่างเช่น ป้องกันปัญหาอย่างการมองข้ามชั้นแคช, ไม่สะท้อนกฎของ ORM, หรือสร้างลอจิกซ้ำซ้อน

Phase 2: Planning

  • หลังทบทวนรีเสิร์ชแล้ว จะให้ Claude เขียน แผนการพัฒนาโดยละเอียด (plan.md)
    • รวมถึงโค้ดสไนเป็ตจริง, พาธไฟล์ที่จะต้องแก้, และ trade-off ต่าง ๆ
    • ใช้ ไฟล์ markdown ที่จัดการเองได้โดยตรง แทน plan mode ที่มีมาในตัว
  • หากให้ reference implementation จากโอเพนซอร์สไปด้วย คุณภาพของแผนที่ Claude เขียนจะดีขึ้นมาก
  • สิ่งที่สำคัญยิ่งกว่าตัวเอกสารแผนเอง คือ วงจรการใส่คำอธิบายประกอบ (Annotation) ที่ตามมา

Annotation Cycle

  • ผู้เขียนจะเปิด plan.md แล้ว เพิ่มคอมเมนต์ inline ด้วยตัวเองโดยตรง
    • เช่น แก้สมมติฐานที่ผิด, ปฏิเสธแนวทาง, หรือเพิ่มความรู้เฉพาะโดเมน
    • ตัวอย่าง: “อันนี้ต้องเป็น PATCH”, “ไม่ต้องมีแคช”, “ย้ายฟิลด์ visibility ไปไว้ระดับลิสต์” เป็นต้น
  • จากนั้นสั่ง Claude ว่า “ให้อัปเดตเอกสารตามคอมเมนต์ แต่ยังไม่ต้องลงมือพัฒนา”
  • จะ วนรอบคอมเมนต์-อัปเดตนี้ 1~6 ครั้ง โดยใช้คำสั่ง “don’t implement yet” เพื่อป้องกันการลงมือเร็วเกินไป
  • เอกสาร markdown ทำหน้าที่เป็น สถานะ (state) ที่ใช้ร่วมกันได้ ซึ่งชัดเจนและมีโครงสร้างมากกว่าการสั่งงานแบบสนทนา
  • ผ่านการทำซ้ำ แผนทั่วไปจะ ค่อย ๆ พัฒนาเป็นสเปกที่เข้ากับระบบจริงได้อย่างสมบูรณ์

การสร้าง Todo List

  • ก่อนลงมือพัฒนา จะให้ Claude เพิ่ม รายการงานย่อย (todo list)
    • รวมงานย่อยในแต่ละขั้นเพื่อใช้ติดตามความคืบหน้า
    • Claude จะทำเครื่องหมายรายการที่เสร็จแล้ว จึงติดตามสถานะได้ง่ายแม้เป็นเซสชันยาว

Phase 3: Implementation

  • เมื่อทุกการตัดสินใจถูกยืนยันแล้ว จึงสั่งให้ลงมือทำด้วยพรอมป์ต์มาตรฐาน
    • เช่น “อย่าหยุดจนกว่าจะทำทุก task เสร็จ”, “ห้ามใส่คอมเมนต์ที่ไม่จำเป็น”, “ห้ามใช้ชนิด any/unknown”, “ทำ typecheck อย่างต่อเนื่อง” เป็นต้น
  • คำสั่งนี้เป็น ขั้นตอนเชิงกลที่ทำตามแผนตรง ๆ โดยการตัดสินใจเชิงสร้างสรรค์ได้เสร็จสิ้นไปก่อนแล้ว
  • หากข้ามแผนแล้วไปลงมือทำทันที ก็จะกลายเป็นการเขียนโค้ดบนสมมติฐานที่ผิด ดังนั้นกฎ “don’t implement yet” จึงเป็นอุปกรณ์นิรภัยหลัก

Feedback During Implementation

  • ระหว่างลงมือทำ ผู้เขียนจะเปลี่ยนบทบาทเป็น ผู้กำกับดูแล
    • ฟีดแบ็กจะสั้นและชัด เช่น “ฟังก์ชันนี้หายไป”, “ย้ายไปแอป admin” เป็นต้น
    • เวลาแก้ฝั่งฟรอนต์เอนด์ อาจใช้คำสั่งสั้น ๆ อย่าง “wider”, “2px gap” หรือใช้สกรีนช็อตร่วมด้วย
  • มีการอ้างอิงโค้ดเดิมบ่อยครั้งเพื่อ รักษาความสม่ำเสมอของ UI/UX
  • หากไปผิดทิศทาง จะ git revert แล้วลองใหม่โดยลดขอบเขตงานลง ซึ่งได้ผลดีกว่าการค่อย ๆ แก้ต่อจากของที่ผิด

Staying in the Driver’s Seat

  • ไม่มอบ อิสระเต็มรูปแบบ ให้ Claude โดยการตัดสินใจสุดท้ายยังเป็นของมนุษย์เสมอ
  • สามารถเลือกใช้เพียงบางส่วนจากข้อเสนอของ Claude หรือแก้ไข, ลบ, และกำหนดทางเลือกทางเทคนิคใหม่ได้
    • ตัวอย่าง: “อันแรกใช้ Promise.all”, “อันที่สี่กับห้าข้ามไป”
    • “เอาฟังก์ชันดาวน์โหลดออก”, “ห้ามเปลี่ยนฟังก์ชันซิกเนเจอร์”, “ให้ใช้เมธอดของไลบรารีที่ระบุ” เป็นต้น
  • Claude รับหน้าที่ ลงมือทำเชิงกล, ส่วนมนุษย์รับหน้าที่ ตัดสินใจและจัดลำดับความสำคัญ

Single Long Sessions

  • ทำงานต่อเนื่องตั้งแต่รีเสิร์ชไปจนถึงพัฒนาใน เซสชันยาวเพียงเซสชันเดียว
    • ระหว่างเซสชัน Claude จะสะสมบริบทอย่างต่อเนื่อง และด้วย auto-compaction ก็ยังรักษาบริบทได้เพียงพอ
    • plan.md จะถูก เก็บไว้ในรูปแบบสมบูรณ์ตลอดทั้งเซสชัน และสามารถอ้างอิงได้ตลอดเวลา

สรุปประเด็นสำคัญ

  • “อ่านให้ลึก เขียนแผน ขัดเกลาด้วยคอมเมนต์ แล้วค่อยลงมือทีเดียว”
  • แม้ไม่มีพรอมป์ต์ซับซ้อนหรือ system instruction พิเศษ ก็ยังคงได้คุณภาพสูงด้วยไปป์ไลน์ที่มีวินัยซึ่ง แยกการคิด (Thinking) ออกจากการพิมพ์ (Typing)
  • Research ช่วยกันการแก้ไขแบบไม่รู้จริง, Plan ช่วยกันการแก้ไขที่ผิดทิศ, และ Annotation คือจุดที่ใส่วิจารณญาณของมนุษย์เข้าไป
  • การลงมือขั้นสุดท้ายจะ ทำเป็นกระบวนการอัตโนมัติหลังจากที่ทุกการตัดสินใจถูกยืนยันแล้ว จนเกิดเป็นโครงสร้างการทำงานร่วมกันที่มีประสิทธิภาพ

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

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

 
naka98 2026-02-25

ผมก็เจอปัญหาคล้าย ๆ กันอยู่เรื่อย ๆ เหมือนกันครับ ถ้าร่วมงานกับ AI แบบอิงแชตอย่างเดียว การแตกงานเป็นหน่วยย่อย (WBS), ความคืบหน้า, และบันทึกการตัดสินใจก็มักจะพร่าเลือนไปครับ
 
pcj9024 2026-02-23

พอเอาไฟล์แผนไว้ในรีโปไปเลย แล้วเก็บสิ่งที่ถูกนำไปใช้จากการรันตามแผนนั้นไว้ด้วย ก็ช่วยรักษาคอนเท็กซ์ได้ค่อนข้างดีเลยครับ
 
geekbini 2026-02-23

เนื้อหานี้ไม่ได้จำกัดอยู่แค่กับ Claude เท่านั้น แต่ดูเหมือนว่าจะสามารถประยุกต์ใช้ได้โดยทั่วไปกับบริการ AI อื่น ๆ ที่ทำงานบน CLI เช่นกัน
 
GN⁺ 2026-02-23
ความคิดเห็นจาก Hacker News

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

    • ในแง่นี้ โครงสร้างแบบ sub-agent ช่วยได้มาก ให้ตัวหนึ่งรับหน้าที่วางแผน อีกตัวลงมือทำ และอีกตัวรีวิว บทบาทจะชัดเจนขึ้น จะทำแบบ blue team/red team ก็ได้ สุดท้ายหัวใจคือการช่วยให้ LLM ให้เหตุผลได้ถูกต้องขึ้นด้วยคำสั่งที่ชัดเจนกว่าเดิม
    • ถ้าใส่ ลำดับการใช้งานทั้งกรณีใช้งาน ไว้ในคำสั่งด้วย โมเดลก็จะไม่ไปทำพฤติกรรมหลุดประเด็น
    • แต่การเปิดเผยสมมติฐานแบบนี้ก็อาจเปลี่ยนพฤติกรรมของโมเดลได้เหมือนกัน เหมือนแค่ใส่ printf() บรรทัดเดียวแล้ว Heisenbug หายไป
    • บอกว่าแทบไม่มี syntax error งั้นเหรอ? ประสบการณ์ผมไม่เหมือนกัน ตอนเพิ่ม S3 backend ให้โปรเจกต์ Rust เล็ก ๆ Claude ดันติด ลูปหลอน API เผาเงิน $20 ไปใน 30 นาที ทั้งที่จริง ๆ เป็นปัญหาไวยากรณ์ง่าย ๆ
    • บทความนี้เขียนด้วย ChatGPT หรือเปล่า?

  • มีคนบอกว่าต้องใช้คำอย่าง “ลึก ๆ”, “ละเอียด” ถึงจะทำให้ Claude ไม่อ่านแบบผิวเผิน แต่พูดตรง ๆ ว่า ผมไม่เข้าใจโดยสัญชาตญาณเลย ว่าทำไมมันถึงเป็นแบบนั้น

    • นั่นเป็นเพราะ attention mechanism LLM ฝึกมาจากทั้งอินเทอร์เน็ต และข้อความที่มีคำอย่าง “ดูรายละเอียดของปัญหา” มักจะมีคำตอบระดับผู้เชี่ยวชาญอยู่ด้วย พอมีคำแบบนี้ โมเดลจึงให้น้ำหนักกับข้อมูลกลุ่มนั้นมากขึ้น เหตุผลเดียวกับที่พรอมป์ต์อย่าง “ทำตัวเหมือนอาจารย์ MIT” ใช้งานได้
    • แต่คำอธิบายแบบนี้มันเหมือน ความเชื่องมงาย มากกว่า ไม่มีหลักฐานที่ตรวจสอบเชิงสถิติได้ และให้ความรู้สึกเหมือน การคิดแบบไสยศาสตร์ ระดับเอาเครื่องบูชาไปถวายเทพสุริยะ ถ้ามันได้ผลจริงก็น่าจะพิสูจน์เป็นปัญหาการทำ optimization ได้ แต่ไม่มีใครเปิดเผยข้อมูล
    • ตอนนี้การพัฒนาซอฟต์แวร์เป็นยุคที่ ประหลาดมาก ไม่มีใครรู้จริงว่า LLM ทำตัวแบบนั้นเพราะอะไร เราได้แต่หวังว่าพรอมป์ต์จะไปขยับความน่าจะเป็นได้ดี แต่ก่อนนี่เป็นวงการที่ค่อนข้างเป็น deterministic เดี๋ยวนี้กลับกลายเป็นว่าต้องเขียนคำสั่งตัวหนาในไฟล์ AGENTS.md ราวกับพ่อแม่กำลังพูดกับลูก
    • แปลกดีที่เห็นเรื่องแบบนี้แล้วคนยังรับกันอย่างจริงจัง มันแทบจะเหมือน โหราศาสตร์ฉบับวิศวกรรม
    • ถ้ามอง latent space ของโมเดลเหมือนภูมิประเทศจะเข้าใจได้ง่ายขึ้น พรอมป์ต์ก็เหมือนการปล่อยลูกบอลลงในจุดหนึ่ง และการเลือกคำจะกำหนดว่าลูกบอลจะกลิ้งลงหุบไหน คำอย่าง “อย่างลึกซึ้ง” ช่วยให้ลูกบอลอยู่ในบริเวณที่ต้องการได้ดีขึ้น มันอาจไม่ใช่คำอธิบายที่สมบูรณ์แบบ แต่พอคิดแบบนี้แล้วมันก็ใช้งานได้จริงสำหรับผม

  • ผมใช้โครงสร้างที่มีเอกสาร 3 ประเภทกับสกิล 2 แบบ
    Specs คือเอกสารออกแบบคงที่ของโปรเจกต์, Plans คือแผนการทำงานที่ LLM สร้างขึ้น, และไฟล์ Working memory ใช้ติดตามสถานะความคืบหน้า
    ใช้ planner skill ของ Gemini Pro เพื่อสร้างแผนใหม่ และใช้ implementer skill ของ Codex เพื่อเอาไปทำจริง
    แบบนี้คอนเท็กซ์จะเบาและโฟกัสมากขึ้น ทำงานได้มีประสิทธิภาพกว่าเดิม แม้ใช้แพ็กเกจ $20 ของ Codex/Gemini ก็ยังเดินงานได้เร็วพอ

    • ผมก็ใช้แนวคล้ายกัน สร้างไฟล์ spec จากบทความวิจัย แล้วค่อยพัฒนาแผนร่วมกับ Claude แบบโต้ตอบกัน จัดการ requirements–tests–definitions ในสไตล์เอกสาร system engineering ของ IEEE Claude ทำตามกติกาได้ดีถ้ามี guardrail ให้ ส่วนตัวผม Claude เข้ากับสไตล์มากกว่า Codex
    • เป็นแนวทางที่ดี แต่ผมสงสัยว่า monorepo เป็นทางเลือกที่ดีกว่าในยุค AI หรือเปล่า ที่บริษัทผมแยกแอป Next.js ออกเป็นหลาย repo เลยกำลังชั่งใจว่าควรรวมเป็นอันเดียวไหม

  • ไอเดียการ ใส่คอมเมนต์ไว้ในเอกสารแผนโดยตรง รู้สึกสดใหม่ดี เลยสงสัยว่ามีวิธีเก็บคอมเมนต์พวกนั้นแยกไว้หรือจัดการให้กลับมาทบทวนทีหลังได้ไหม

  • มีบางอย่างในแนวทางนี้ที่ผมไม่ค่อยชอบ
    อย่างแรก วิธี บิ๊กแบง ที่สร้างโค้ดทั้งหมดทีเดียว มักทำให้ได้ก้อนโค้ดขนาดใหญ่ที่เข้าใจยาก ผมคิดว่าการวางแผนและลงมือทำแบบเป็นขั้นจะดีกว่า
    อย่างที่สอง แม้จะมีการให้ฟีดแบ็ก แต่กลับ ไม่อัปเดต knowledge base น่าเสียดาย ควรบันทึกสาเหตุของข้อผิดพลาดไว้เพื่อไม่ให้ซ้ำอีกครั้ง
    สุดท้าย ไม่มีการพูดถึงเรื่องการทดสอบเลย ควรมี Test-Driven Development (TDD) อย่างน้อยบางส่วน น่าสนใจว่าแนวทางพัฒนาที่มี AI ช่วยจะผสานกับวิธีการแบบนี้อย่างไร

    • ผมก็มีประสบการณ์คล้ายกัน เลยแบ่ง PLAN.md ออกเป็นหลายขั้น และเขียนพรอมป์ต์อย่างระวังให้ทำแค่ขั้นปัจจุบัน การทดสอบก็ใส่เป็นส่วนหนึ่งของแผนเหมือนกัน แต่ตอนนี้ยังมักไปเพิ่มช่วงท้ายอยู่

  • เวิร์กโฟลว์นี้จริง ๆ แล้วคือ วิธีมาตรฐานของ Claude Code ที่ Anthropic แนะนำ แต่ข้อเสียคือถ้าแผนไม่สมบูรณ์ก็ต้องเริ่มใหม่ตั้งแต่ต้น
    เพราะงั้นผมเลยแบ่ง ออกแบบ → วางแผน → ลงมือทำ ออกเป็นหลายแบตช์ ถ้าแบ่งแผนเป็นหน่วยละไม่เกิน 1,500 บรรทัด จะควบคุมความซับซ้อนได้ง่ายกว่า
    แอป 30,000 LOC ของผมมีแผนรวม 100,000 บรรทัด จะให้ทำทีเดียวเป็นไปไม่ได้

    • ผมก็เจอแบบเดียวกัน เลยแยกแผนให้เล็กลง แล้วใช้ branch แยกตามฟีเจอร์ ในการจัดการคอมมิต กลายเป็นว่า AI กลับทำให้นิสัยการพัฒนาของผมดีขึ้น
    • จริง ๆ แล้วเวิร์กโฟลว์ที่บอกว่า “แตกต่างแบบสุดขั้ว” กลับเป็นแค่การใช้ Plan mode พื้นฐาน เอง ก็แอบน่าเขินนิด ๆ
    • ผมก็คิดว่า การทำแบบค่อยเป็นค่อยไป คือคำตอบ การทำโปรเจกต์ใหญ่ให้เสร็จทีเดียวตอนนี้ยังเป็นแค่ ภาพลวงตา
    • ต่อให้แผนไม่สมบูรณ์แบบก็ไม่เป็นไร แค่ย้อนกลับเฉพาะส่วนที่ AI แก้ แล้ววนซ้ำจากขั้นก่อนหน้าอีกครั้งก็พอ หัวใจคือการเปลี่ยนแปลง ทีละหน่วยเล็ก เพื่อลดความซับซ้อน
    • แผน 100,000 บรรทัดนี่เกือบล้านคำแล้ว แค่อ่านอย่างเดียวก็กินเวลา 66 ชั่วโมง ในทางปฏิบัติเป็นไปไม่ได้เลย

  • ผมไม่ได้ยึด plan.md เป็นหลัก แต่เน้น scaffold ที่รันได้กับ validation loop มากกว่า
    ผมสร้างระบบชำระเงินจริงชื่อ Kolibri Tickets ร่วมกับ AI และหัวใจสำคัญไม่ใช่ให้โมเดลพิมพ์โค้ดได้เร็ว แต่คือ ออกแบบ validation loop ให้ดี

    • รักษาโครงกระดูกที่รันได้ไว้ตั้งแต่ต้น
    • เพิ่มทีละ vertical slice บาง ๆ เท่านั้นในแต่ละครั้ง
    • บังคับให้มี สิ่งส่งมอบที่ตรวจสอบได้ เช่น เทสต์, ไทป์, state machine
    • และทำรีแฟกเตอร์ให้เป็นเรื่องปกติ
      แบบนี้จะทำให้ส่งขึ้นใช้งานได้เร็วขึ้นจริง ไม่ใช่แค่ “ภาพลวงตาเรื่องความเร็ว” เอกสาร Plan เป็นวิธีหนึ่งในการรักษาสถานะร่วมกัน และ harness ที่ตรวจสอบได้ ก็เป็นอีกวิธีหนึ่ง
    • ผมเองก็อยู่ในยุคที่ต้นทุนของโค้ดถูกลง เลยตั้งเป้า test coverage 100% ตอนนี้กำลังใช้ static typing ใน Python, เทสต์ด้วย Playwright และ mutation testing ด้วย ทุกวันนี้เอเจนต์สามารถวนลูปทำงานเป็นชั่วโมงแล้วส่งโค้ดที่แทบไม่ต้องแก้อีก

  • ผมใช้ Claude Code เพื่อ เตรียมการสอน
    เขียนโน้ตการสอนด้วย Quarto แล้วให้ Claude แปลงเป็น สไลด์ Slidev จากนั้นก็ใส่คอมเมนต์ในสไลด์เพื่อให้ฟีดแบ็ก เช่น “อันนี้แยกเป็นสองสไลด์”, “ตรงนี้เพิ่มรูปภาพ”
    ฟีดแบ็กแบบ คอมเมนต์บนตัวเอกสาร ทรงพลังมาก ช่วยได้มากทั้งเรื่องระยะห่างของโทเค็นและการคงบริบท

    • จริง ๆ Quarto เองก็รองรับหลายฟอร์แมตอย่าง PowerPoint, PDF, HTML อยู่แล้ว เลยสงสัยว่าทำไมถึงใช้ Slidev แทน ไม่ให้ Claude สร้างเอกสาร Quarto ใหม่เลยล่ะ?
    • อยากรู้ว่าฟีดแบ็กนี่ใส่เป็น คอมเมนต์อินไลน์ หรือเปล่า เช่น # เปลี่ยนส่วนนี้เป็น X
    • ไม่ทราบว่า Claude skill นั้นเปิดซอร์สไว้หรือยัง

  • ตอนนี้มีเครื่องมืออย่าง Kiro ของ Amazon, Antigravity ของ Google, Spec Kit ของ GitHub และ OpenSpec ที่มีฟังก์ชันลักษณะนี้อยู่แล้ว

  • ความล้มเหลวที่แพงที่สุดของการเขียนโค้ดแบบมี AI ช่วย ไม่ใช่ syntax error แต่คือ การนำไปใช้ที่บางส่วนทำงานได้ดี แต่พังทั้งระบบโดยรวม
    เพราะงั้นผมเลยเพิ่ม brief.md ตั้งแต่ต้น เพื่อระบุการนิยามปัญหา ตัวชี้วัดเป้าหมาย และเกณฑ์หยุดทำฟีเจอร์ แบบนี้จะช่วยลดต้นทุนจากความไม่สอดคล้องกันระหว่างเป้าหมายทางธุรกิจกับการลงมือทำทางเทคนิค