วิธีเขียนสเปกที่ดีสำหรับ AI Agent

 (addyosmani.com)
110 คะแนน โดย GN⁺ 2026-01-19 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • หากโยนสเปกจำนวนมหาศาลให้ AI coding agent ทีเดียว มักจะทำงานได้ไม่ดีนัก โดยหัวใจสำคัญอยู่ที่การเขียน สเปกอย่างชาญฉลาด
  • แนวทางที่แนะนำคือ นำเสนอวิสัยทัศน์ระดับสูงก่อน แล้วให้ AI ขยายเป็นแผนรายละเอียด จากนั้นใช้ Plan Mode เพื่อตรวจทานแผนในโหมดอ่านอย่างเดียว ก่อนสลับไปยังขั้นตอนเขียนโค้ด
  • จากผลการวิเคราะห์ไฟล์ตั้งค่า agent กว่า 2,500 ไฟล์บน GitHub พบว่าสเปกที่มีประสิทธิภาพควรครอบคลุม 6 ด้านหลัก ได้แก่ Commands, Testing, Project Structure, Code Style, Git Workflow, Boundaries
  • งานขนาดใหญ่ควรถูกแยกเป็น งานย่อยแบบโมดูลาร์ แทนการใช้พรอมป์ต์ขนาดยักษ์เพียงอันเดียว และควรให้เฉพาะคอนเท็กซ์ที่จำเป็นต่อแต่ละงานเพื่อป้องกันคุณภาพลดลง
  • การฝัง ขอบเขต 3 ระดับ (Always/Ask first/Never), การตรวจสอบตัวเอง, และการทดสอบความเหมาะสมไว้ในสเปก พร้อมทดสอบ ทำซ้ำ และพัฒนาอย่างต่อเนื่อง คือแก่นของ เวิร์กโฟลว์การพัฒนาแบบขับเคลื่อนด้วยสเปก

TL;DR

  • ควรเขียน สเปกที่ชัดเจน โดยมี รายละเอียดในระดับที่เหมาะสม (โครงสร้าง, สไตล์, การทดสอบ, ขอบเขต ฯลฯ)
  • งานขนาดใหญ่ควร แตกออกเป็นหน่วยเล็ก แทนการใช้พรอมป์ต์ก้อนเดียว
  • ควรวางแผนใน โหมดอ่านอย่างเดียว ก่อน แล้วจึง ลงมือทำและปรับปรุงอย่างต่อเนื่อง

หลักการสำคัญ: เขียนสเปกอย่างชาญฉลาด

  • การโยนสเปกขนาดมหึมาให้ AI agent ตรง ๆ มักล้มเหลว เพราะติดข้อจำกัดของ context window และ attention budget ของโมเดล
  • “สเปกอัจฉริยะ” คือเอกสารที่ช่วยชี้นำ agent ได้อย่างชัดเจน อยู่ภายในขนาดคอนเท็กซ์ที่ใช้งานได้จริง และ พัฒนาไปพร้อมกับโปรเจกต์
  • นี่คือการสรุปหลักการจากประสบการณ์ใช้งาน coding agent อย่าง Claude Code และ Gemini CLI ให้ออกมาเป็น เฟรมเวิร์ก

หลักการ 1: ให้ภาพใหญ่ก่อน แล้วให้ AI ร่างรายละเอียด

  • แทนที่จะพยายามออกแบบทุกอย่างอย่างละเอียดตั้งแต่แรก ให้เริ่มจากการกำหนด คำอธิบายเป้าหมาย และข้อกำหนดหลักไม่กี่ข้อให้ชัดเจนก่อน
  • ใช้สเปกตั้งต้นนี้ในลักษณะคล้าย “product brief” แล้วให้ agent นำไปต่อยอดเป็น สเปกรายละเอียด
  • agent ที่อิง LLM มักเติมรายละเอียดได้ดีเมื่อคำสั่งระดับสูงชัดเจน แต่ถ้าภารกิจคลุมเครือก็มีแนวโน้มจะออกนอกทางได้ง่าย
  • เพราะฉะนั้น หัวใจสำคัญคือการปัก ภารกิจที่ชัดเจน ไว้ตั้งแต่ต้น เพื่อไม่ให้ agent หลงทาง

  • การใช้ Plan Mode

    • Plan Mode ของ Claude Code เป็นโหมดที่ล็อก agent ให้อ่านได้อย่างเดียว และให้ทำเพียงวิเคราะห์ codebase กับจัดทำแผนอย่างละเอียด
    • เมื่อเข้า Plan Mode ด้วย Shift+Tab แล้วอธิบายว่า “ต้องการสร้างอะไร” agent จะไล่ดูโค้ดที่มีอยู่และร่างสเปกเบื้องต้นขึ้นมา
    • ในขั้นตอนนี้ สามารถกำชับให้ตรวจสอบทั้งสถาปัตยกรรม แนวปฏิบัติที่ดี ความเสี่ยงด้านความปลอดภัย และกลยุทธ์การทดสอบไปพร้อมกันได้
    • ควรรักษา Plan Mode ไว้จนกว่าแผนจะถูกขัดเกลาอย่างเพียงพอและ ไม่เปิดช่องให้ตีความผิด จากนั้นจึงค่อยออกจาก Plan Mode และเข้าสู่ขั้นตอนปฏิบัติ

  • ใช้สเปกเป็นคอนเท็กซ์

    • สเปกที่ยืนยันแล้วควรบันทึกไว้เป็นไฟล์อย่าง SPEC.md และเมื่อลงมือทำงานก็เลือกส่งกลับให้ agent เฉพาะส่วนที่จำเป็น
    • เพราะไฟล์สเปกยังคงอยู่ข้ามแต่ละเซสชัน มันจึงช่วย ตรึง AI ให้ยึดอยู่กับจุดอ้างอิงเดียวกันได้แม้กลับมาเริ่มโปรเจกต์ใหม่
    • ช่วยลดปัญหา การลืม ที่เกิดขึ้นเมื่อประวัติการสนทนายาวขึ้นหรือเมื่อมีการรีสตาร์ต agent
    • เหมือนกับที่ทีมใช้ PRD (เอกสารข้อกำหนดผลิตภัณฑ์) เป็นเกณฑ์อ้างอิงร่วมกัน สเปกนี้จึงทำหน้าที่เป็น “เอกสารอ้างอิงหนึ่งเดียว” สำหรับทั้งมนุษย์และ AI

  • รักษาแนวคิดแบบมุ่งเป้าหมาย

    • สเปกระดับสูงควรเน้นที่ what/why มากกว่าการเขียนวิธีทำทั้งหมดตั้งแต่แรก และเลื่อนรายละเอียดของ how ออกไปภายหลัง
    • จัดโครงสร้างคล้าย user story และเกณฑ์การยอมรับ: “ผู้ใช้คือใคร? / ต้องการอะไร? / ความสำเร็จหน้าตาเป็นอย่างไร?”
    • GitHub Spec Kit ก็เน้นแนวทางเดียวกัน คือ “ให้คำอธิบายระดับสูงว่าเรากำลังสร้างอะไรและทำไปทำไม แล้วให้ coding agent สร้างข้อกำหนดรายละเอียดโดยยึดประสบการณ์ผู้ใช้และเกณฑ์ความสำเร็จเป็นศูนย์กลาง”

หลักการ 2: จัดโครงสร้างสเปกให้เหมือน PRD ระดับมืออาชีพ (หรือ SRS)

  • สิ่งสำคัญคือต้องมองสเปกสำหรับ AI ไม่ใช่แค่ชุดบันทึกย่อ แต่เป็น เอกสารที่มีโครงสร้างพร้อมส่วนต่างๆ ที่ชัดเจน
  • รูปแบบที่ครอบคลุมและเป็นระเบียบเหมือน PRD หรือเอกสารออกแบบระบบ เหมาะอย่างยิ่งกับ AI ที่ ตีความเนื้อหาแบบตามตัวอักษร
  • จากผลการวิเคราะห์ไฟล์ตั้งค่าเอเจนต์มากกว่า 2,500 ไฟล์บน GitHub พบว่าสเปกที่มีประสิทธิภาพมักมี 6 ด้านหลัก ร่วมกัน

    • 1. Commands

      • วางคำสั่งที่สามารถรันได้ไว้ช่วงต้นของเอกสาร
      • ไม่ใช่แค่ระบุชื่อเครื่องมือ แต่ต้องระบุคำสั่งเต็มพร้อมแฟลกด้วย: npm test, pytest -v, npm run build

    • 2. Testing

      • ระบุอย่างชัดเจนถึงวิธีรันทดสอบ เฟรมเวิร์กที่ใช้ ตำแหน่งของไฟล์ทดสอบ และระดับ coverage ที่คาดหวัง

    • 3. Project Structure

      • แยกตำแหน่งของซอร์สโค้ด เทสต์ และเอกสารให้ชัดเจน
      • ตัวอย่าง: "src/ สำหรับโค้ดแอปพลิเคชัน, tests/ สำหรับ unit test, docs/ สำหรับเอกสาร"

    • 4. Code Style

      • แทนที่จะอธิบายสไตล์แบบยืดยาว โค้ดสั้นๆ จริงเพียงหนึ่งชิ้น มีประสิทธิภาพกว่ามาก
      • ควรแสดงกฎการตั้งชื่อ มาตรฐานการฟอร์แมต และตัวอย่างผลลัพธ์ที่พึงประสงค์ไปพร้อมกัน

    • 5. Git Workflow

      • หากระบุกฎการตั้งชื่อ branch รูปแบบข้อความ commit และข้อกำหนดของ PR เอเจนต์ก็จะทำตามโฟลว์นั้น

    • 6. Boundaries

      • ต้องกำหนดให้ชัดเจนว่ามีพื้นที่ใดบ้างที่เอเจนต์ห้ามแตะต้องโดยเด็ดขาด
      • เช่น secrets, ไดเรกทอรี vendor, การตั้งค่า production, โฟลเดอร์เฉพาะบางส่วน
      • งานวิจัยของ GitHub ยืนยันว่า "ห้าม commit secrets โดยเด็ดขาด" เป็นข้อจำกัดที่มีประโยชน์และถูกกล่าวถึงบ่อยที่สุด

  • ระบุสแตกให้เฉพาะเจาะจง

    • อย่าเขียนกว้างๆ แบบ “โปรเจกต์ React” แต่ควรระบุให้ชัดอย่าง “React 18 + TypeScript + Vite + Tailwind CSS”
    • ต้องใส่เวอร์ชันและ dependency หลักร่วมด้วย เพราะสเปกที่คลุมเครือย่อมนำไปสู่โค้ดที่คลุมเครือ

  • ใช้รูปแบบที่สม่ำเสมอ

  • ผสานสเปกเข้ากับ toolchain

    • ควรมองสเปกไม่ใช่เป็นแค่เอกสาร แต่เป็น "artifact ที่นำไปใช้งานได้จริง" ซึ่งเชื่อมกับการจัดการเวอร์ชันและ CI/CD
    • GitHub Spec Kit ใช้ เวิร์กโฟลว์แบบ 4 ขั้นพร้อมเกต ที่วางสเปกไว้เป็นศูนย์กลางของกระบวนการวิศวกรรม
      • Specify: ให้คำอธิบายระดับสูงว่ากำลังสร้างอะไรและทำไม จากนั้นโค้ดดิ้งเอเจนต์จะสร้างข้อกำหนดโดยละเอียด
      • Plan: จัดทำแผนทางเทคนิคที่รวมสแตกที่ต้องการ สถาปัตยกรรม และข้อจำกัดต่างๆ
      • Tasks: แยกสเปกและแผนออกเป็นหน่วยงานจริง และแตกแต่ละงานให้มีขนาดที่ทดสอบได้
      • Implement: โค้ดดิ้งเอเจนต์ดำเนินการแต่ละ task ทีละรายการ หรือทำแบบขนาน

  • Persona แบบเฉพาะทางผ่าน agents.md

    • ในเครื่องมืออย่าง GitHub Copilot สามารถกำหนด persona ของเอเจนต์แบบเฉพาะทาง ได้
    • สามารถแยกบทบาทอย่าง @docs-agent (เอกสารเทคนิค), @test-agent (QA), @security-agent (รีวิวโค้ด) ได้
    • ไฟล์ agents.md แต่ละไฟล์ทำหน้าที่เป็นสเปกแบบเข้มข้นที่บรรจุรูปแบบพฤติกรรม คำสั่ง และขอบเขตของ persona นั้น

  • ออกแบบ Agent Experience (AX)

    • เช่นเดียวกับที่ออกแบบ API โดยคำนึงถึง Developer Experience (DX) สเปกก็ควรถูกออกแบบโดยคำนึงถึง Agent Experience (AX) ด้วย
    • รูปแบบที่สะอาดและ parse ได้ง่ายมีความสำคัญ
      • OpenAPI schema ของ API ที่เอเจนต์จะใช้
      • สรุปเอกสารสำหรับการใช้งานโดย LLM (llms.txt)
      • การกำหนด type แบบชัดเจน
    • ยิ่งสเปกเป็นไปตามมาตรฐานอย่าง MCP (Model Context Protocol) มากเท่าไร เอเจนต์ก็จะยิ่งเข้าใจและทำงานได้เสถียรมากขึ้นเท่านั้น

  • รักษาให้เป็นเอกสารที่มีชีวิต

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

หลักการ 3: แยกงานออกเป็นพรอมป์ต์และคอนเท็กซ์แบบโมดูลาร์

  • แทนที่จะยัดทุกอย่างไว้ในพรอมป์ต์ขนาดใหญ่เพียงอันเดียว ให้ส่งคอนเท็กซ์เพื่อให้ โฟกัสทีละหนึ่งงานเท่านั้น
  • หากใส่ความต้องการ โค้ด และคำสั่งของทั้งโปรเจ็กต์ไว้ในพรอมป์ต์เดียว กลับยิ่งทำให้เกิดความสับสนได้ง่าย
  • ไม่ใช่แค่เสี่ยงชนข้อจำกัดด้านโทเค็นเท่านั้น แต่ยังอาจทำให้สมาธิของโมเดลลดลงอย่างมากจาก “คำสาปของคำสั่ง (curse of instructions)”

  • คำสาปของคำสั่ง

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

  • แบ่งสเปกออกเป็นขั้นตอนหรือคอมโพเนนต์

    • หากเอกสารสเปกยาวหรือครอบคลุมขอบเขตกว้าง ให้พิจารณาแยกออกเป็นหลายส่วน
    • ตัวอย่าง: แยก “Backend API Spec” และ “Frontend UI Spec” เป็นคนละเซกชัน
    • ตอนทำงานฝั่งแบ็กเอนด์ ก็ไม่จำเป็นต้องส่งสเปกฝั่งฟรอนต์เอนด์มาด้วยทุกครั้ง
    • ในสภาพแวดล้อมแบบมัลติเอเจนต์ อาจมีเอเจนต์หรือซับโปรเซสแยกตามแต่ละโดเมนได้ด้วย
    • คู่มือ AI ของ DigitalOcean ก็เตือนว่า “อย่าผสมงานยืนยันตัวตนกับการเปลี่ยนแปลงสคีมาฐานข้อมูลไว้ในครั้งเดียว”

  • TOC/สรุปแบบขยายสำหรับสเปกขนาดใหญ่

    • วิธีหนึ่งคือให้เอเจนต์ช่วยเขียน สารบัญแบบขยาย (TOC) ที่สรุปภาพรวมของสเปกทั้งหมดก่อน
    • ย่อแต่ละเซกชันให้เหลือเพียงประเด็นสำคัญหรือคีย์เวิร์ดไม่กี่ข้อ พร้อมอ้างอิงตำแหน่งของรายละเอียด
    • ตัวอย่าง: “Security: ใช้ HTTPS, ปกป้อง API key, ทำ input validation (ดูสเปกฉบับเต็ม §4.2)”
    • เมื่อมีสรุปเชิงลำดับชั้นแบบนี้ พรอมป์ต์จะเก็บไว้เฉพาะภาพรวม และค่อยส่งรายละเอียดเมื่อจำเป็น
    • TOC แบบขยายทำหน้าที่คล้ายดัชนี ช่วยให้เอเจนต์รับรู้ว่า “อ้อ มีเซกชันด้านความปลอดภัยอยู่” แล้วร้องขอส่วนที่เกี่ยวข้องได้
    • แนวทางสรุปแบบลำดับชั้น นี้ช่วยให้ LLM รักษาโครงสร้างระดับสูงไว้ได้ดีขึ้น

  • ใช้ซับเอเจนต์หรือ “สกิล”

    • สามารถใช้ มัลติเอเจนต์ที่แยกบทบาทชัดเจน ได้ เช่น ซับเอเจนต์ (หรือ “สกิล”) ตามที่ Anthropic กล่าวถึง
    • ซับเอเจนต์แต่ละตัวถูกตั้งค่าให้เหมาะกับความเชี่ยวชาญเฉพาะด้าน และได้รับเฉพาะบางส่วนของสเปกที่เกี่ยวข้องกับโดเมนนั้น
    • ตัวอย่าง: ซับเอเจนต์ Database Designer รับรู้เฉพาะเซกชันโมเดลข้อมูล ส่วนซับเอเจนต์ API Coder รับรู้เฉพาะสเปก API endpoint
    • วิธีนี้ทำให้แต่ละเอเจนต์มีคอนเท็กซ์ที่เล็กลงและบทบาทที่ชัดขึ้น ส่งผลให้ความแม่นยำดีขึ้นและทำงานแบบขนานได้
    • Claude Code รองรับการกำหนดซับเอเจนต์ที่มี system prompt และเครื่องมือของตัวเอง

  • เอเจนต์แบบขนานเพื่อเพิ่ม throughput

    • การรันหลายเอเจนต์พร้อมกันกำลังกลายเป็น ขั้นถัดไปของประสิทธิภาพการทำงานสำหรับนักพัฒนา
    • แทนที่จะรอให้เอเจนต์ตัวหนึ่งทำเสร็จก่อน ก็ส่งเอเจนต์หลายตัวไปจัดการงานที่ไม่ทับซ้อนกันแบบขนาน
    • Simon Willison เรียกสิ่งนี้ว่า “การยอมรับเอเจนต์เขียนโค้ดแบบขนาน” และบอกว่า ได้ผลอย่างน่าทึ่ง แต่ก็เหนื่อยทางความคิดพอสมควร
    • หัวใจสำคัญคือการแบ่งขอบเขตงานให้ชัด เพื่อไม่ให้เอเจนต์รบกวนงานของกันและกัน
    • เฟรมเวิร์ก orchestration อย่าง LangGraph หรือ OpenAI Swarm ช่วยประสานงานลักษณะนี้ได้
    • และหากใช้เวกเตอร์ดาต้าเบสอย่าง Chroma เป็น shared memory ก็จะเข้าถึงคอนเท็กซ์ร่วมกันได้โดยไม่ต้องพรอมป์ต์ซ้ำ

  • เอเจนต์เดี่ยว vs มัลติเอเจนต์: ควรใช้เมื่อไร

    ด้าน เอเจนต์เดี่ยว เอเจนต์แบบขนาน/มัลติเอเจนต์
    ข้อดี ตั้งค่าง่าย มี overhead ต่ำ และดีบักกับติดตามโฟลว์ได้ง่าย throughput สูง รับมือการพึ่งพากันที่ซับซ้อนได้ดี และเชี่ยวชาญแยกตามโดเมนได้
    ข้อเสีย คอนเท็กซ์ล้นในโปรเจ็กต์ใหญ่ ความเร็วในการวนรอบลดลง และเป็นจุดล้มเหลวเดียว ต้นทุนในการประสานงานเพิ่มขึ้น มีโอกาสเกิดความขัดแย้ง และต้องมี shared memory
    เหมาะกับกรณี โมดูลที่แยกขาดจากกัน โปรเจ็กต์ขนาดเล็กถึงกลาง การทำต้นแบบระยะแรก โค้ดเบสขนาดใหญ่ แยกงานเขียนโค้ด/ทดสอบ/รีวิว และการพัฒนาฟีเจอร์ที่เป็นอิสระต่อกัน
    เคล็ดลับ ใช้สรุปสเปก อัปเดตคอนเท็กซ์ตามงาน และรีเซ็ตเซสชันบ่อย ๆ ช่วงแรกควรจำกัดไว้ที่ 2~3 เอเจนต์ แชร์เครื่องมือผ่าน MCP และทำขอบเขตให้ชัด

  • ให้แต่ละพรอมป์ต์โฟกัสเพียงหนึ่งงาน/หนึ่งเซกชัน

    • ต่อให้ไม่มีสภาพแวดล้อมมัลติเอเจนต์ที่ซับซ้อน ก็ยังบังคับความเป็นโมดูลาร์ด้วยตนเองได้เพียงพอ
    • ตัวอย่าง: หลังเขียนสเปกแล้ว ในขั้น “Step 1: implement ฐานข้อมูลสคีมา” ให้ส่งมาเฉพาะเซกชัน Database ของสเปก
    • ทุกครั้งที่งานหลักเปลี่ยน ควรจัดคอนเท็กซ์ใหม่เพื่อลดความฟุ้งซ่านจากข้อมูลเก่าหรือข้อมูลที่ไม่เกี่ยวข้อง
    • บางคู่มือแนะนำให้เริ่มเซสชันใหม่ เมื่อมีการเปลี่ยนฟังก์ชันหลัก เพื่อจัดระเบียบคอนเท็กซ์

  • ใช้คำสั่งอินไลน์และโค้ด TODO

    • วิธีหนึ่งคือใส่สิ่งที่ต้องทำไว้ในคอมเมนต์ // TODO ภายในโค้ด แล้วให้เอเจนต์ค่อย ๆ เติมทีละข้อ
    • TODO แต่ละอันทำหน้าที่เป็น มินิสเปก สำหรับงานย่อยหนึ่งงาน
    • ผลลัพธ์คือ AI จะโฟกัสในขอบเขตที่แคบมาก เช่น “ให้ implement เฉพาะฟังก์ชันนี้ตามสเปกสั้น ๆ นี้”

หลักการ 4: ฝังการตรวจสอบตนเอง ข้อจำกัด และความเชี่ยวชาญของมนุษย์

  • อย่ามองสเปกว่าเป็นเพียงรายการสิ่งที่เอเจนต์ต้องทำ แต่ให้มองเป็น คู่มือควบคุมคุณภาพ และสะท้อนความเชี่ยวชาญของตนเองลงไปอย่างเต็มที่
  • สเปกที่ดีจะชี้ให้เห็นล่วงหน้าว่า AI อาจพลาดตรงไหน และวาง ราวกันตก (guardrails) ไว้ตรงจุดนั้น
  • ใส่ความรู้เฉพาะโดเมน, edge case และ “ข้อควรระวัง” ต่าง ๆ เพื่อไม่ให้ AI ทำงานแบบไร้บริบทเหมือนอยู่ในสุญญากาศ
  • ถ้ามองว่าสเปกคือ ทั้งโค้ชและกรรมการ ของ AI จะเข้าใจได้ง่ายขึ้น: ชี้นำแนวทางที่ถูกต้อง และเบรกพฤติกรรมที่ผิดทันที
  • จากผลการวิเคราะห์ไฟล์เอเจนต์มากกว่า 2,500 ไฟล์ของ GitHub สเปกที่มีประสิทธิภาพที่สุดไม่ใช่แค่รายการข้อห้าม แต่ใช้ ระบบขอบเขต 3 ระดับ
    • ระบุให้ชัดว่าเมื่อใดเอเจนต์สามารถทำต่อได้เลย, เมื่อใดต้องหยุดเพื่อถาม, และเมื่อใดต้องหยุดโดยสิ้นเชิง

    • ✅ Always do (ทำเสมอ)

      • งานที่ต้องทำโดยไม่ต้องถาม
      • ตัวอย่าง: “รันทดสอบทุกครั้งก่อน commit”, “ปฏิบัติตาม naming convention ของ style guide เสมอ”, “บันทึกข้อผิดพลาดลง monitoring service เสมอ”

    • ⚠️ Ask first (ถามก่อน)

      • งานที่ต้องได้รับการอนุมัติจากมนุษย์
      • ตัวอย่าง: “ถามก่อนแก้ไข database schema”, “ถามก่อนเพิ่ม dependency ใหม่”, “ถามก่อนเปลี่ยนการตั้งค่า CI/CD”
      • แม้ทางเทคนิคจะทำได้ แต่เป็นการเปลี่ยนแปลงที่มีผลกระทบกว้าง จึงควรถูกคัดกรองไว้ตรงนี้ว่าเป็น การเปลี่ยนแปลงที่ต้องใช้ดุลยพินิจของมนุษย์

    • 🚫 Never do (ห้ามทำเด็ดขาด)

      • พื้นที่ hard stop ที่ชัดเจน
      • ตัวอย่าง: “ห้าม commit secret หรือ API key เด็ดขาด”, “ห้ามแก้ไข node_modules/ หรือ vendor/ เด็ดขาด”, “ห้ามลบเทสต์ที่ล้มเหลวโดยไม่มีการอนุมัติอย่างชัดแจ้ง”
      • งานวิจัยยังยืนยันด้วยว่า “ห้าม commit secret เด็ดขาด” เป็นข้อจำกัดที่มีประโยชน์และพบได้บ่อยที่สุด

  • ส่งเสริมการตรวจสอบตนเอง

    • ชี้นำให้เอเจนต์ ตรวจสอบผลลัพธ์ด้วยตนเอง โดยอ้างอิงจากสเปก
    • หากเครื่องมืออนุญาต ให้ใส่ขั้นตอนใน workflow ที่รัน unit test หรือ lint ด้วยตัวเองหลังสร้างโค้ดเสร็จ
    • ในระดับพรอมป์ต์ก็สามารถสั่งให้ตรวจทานซ้ำได้
      • ตัวอย่าง: “หลัง implement แล้ว ให้เปรียบเทียบผลลัพธ์กับสเปกเพื่อตรวจสอบว่าตรงตามข้อกำหนดทั้งหมดหรือไม่ และถ้ายังไม่ครบให้แสดงรายการที่ยังไม่ครบ”
    • เป็นวิธีทำให้ LLM เทียบผลลัพธ์ของตัวเองกับสเปก เพื่อลดการตกหล่น

  • LLM-as-a-Judge สำหรับการตรวจสอบเชิงอัตวิสัย

    • สำหรับเกณฑ์ที่ทำอัตโนมัติได้ยาก เช่น code style, readability หรือการปฏิบัติตาม architectural pattern ให้ใช้แนวทาง LLM-as-a-Judge
    • ให้เอเจนต์ตัวที่สอง (หรือพรอมป์ต์แยก) ตรวจทานผลลัพธ์ของเอเจนต์ตัวแรกตามเกณฑ์คุณภาพในสเปก
    • ตัวอย่าง: “ตรวจสอบว่าโค้ดนี้ปฏิบัติตาม style guide ของเราหรือไม่ และทำเครื่องหมายจุดที่ละเมิด”
    • เอเจนต์ในบทบาทกรรมการจะส่ง feedback กลับมา เพื่อนำไปปรับใช้หรือใช้เป็นจุดเริ่มต้นของการแก้ไข

  • การทดสอบความสอดคล้อง

    • Willison แนะนำให้สร้าง conformance suite
    • เป็นชุดทดสอบที่ไม่ผูกกับภาษาใดภาษาหนึ่ง (มักอยู่ในรูปแบบ YAML) และทำหน้าที่เป็นสัญญาที่ทุก implementation ต้องผ่าน
    • หากกำลังสร้าง API, conformance suite จะนิยามอินพุตและเอาต์พุตที่คาดหวังไว้ และโค้ดที่เอเจนต์สร้างต้องผ่านทั้งหมด
    • ในส่วน Success ของสเปก ให้ระบุเกณฑ์ให้ชัด เช่น “ต้องผ่านทุกเคสใน conformance/api-tests.yaml”

  • ใช้การทดสอบในสเปก

    • ถ้าเป็นไปได้ ให้ใส่ แผนการทดสอบหรือการทดสอบจริง ไว้ในสเปกและลำดับการไหลของพรอมป์ต์โดยตรง
    • ทำให้ข้อกำหนดชัดเจนด้วย test case แบบเดียวกับ TDD
      • ตัวอย่าง: ใน Success Criteria ระบุว่า “อินพุตตัวอย่างนี้ต้องสร้างเอาต์พุตนี้เท่านั้น”
    • Willison อธิบายว่าชุดทดสอบที่แข็งแรง มอบ พลังระดับซูเปอร์พาวเวอร์ ให้เอเจนต์ได้แทบจะจริง
    • เพราะเมื่อเทสต์ล้มเหลว ก็สามารถตรวจสอบและวนซ้ำได้ทันที
    • ในโครงสร้างแบบ subagent ยังสามารถมีtest agent โดยเฉพาะ ที่รับเกณฑ์จากสเปกแล้วคอยตรวจสอบผลลัพธ์โค้ดอย่างต่อเนื่องได้

  • สะท้อนความรู้เฉพาะโดเมน

    • ในสเปกควรใส่ insight ที่อิงโลกความจริง ซึ่งมักมีแต่ผู้พัฒนาที่มีประสบการณ์หรือผู้ที่เข้าใจบริบทเท่านั้นที่รู้
    • ตัวอย่าง: เมื่อต้องสร้างเอเจนต์สำหรับอีคอมเมิร์ซ ควรระบุให้ชัดว่า “products” และ “categories” มีความสัมพันธ์แบบ many-to-many
      • อย่าคาดหวังว่า AI จะอนุมานสิ่งนี้ได้เอง
    • หากไลบรารีใดใช้งานยาก ก็ควรระบุจุดพลาดที่พบบ่อยหรือข้อควรระวังไว้ด้วย
    • นี่คือการถ่ายทอด บทบาทความเป็นเมนเทอร์ ของตนเองลงในสเปก
      • ตัวอย่าง: “เมื่อใช้ไลบรารี X จะมีปัญหา memory leak ในเวอร์ชัน Y ดังนั้นให้ใช้วิธีหลบเลี่ยง Z”

  • มินิมัลลิซึมสำหรับงานง่าย

    • แม้สเปกที่รัดกุมจะสำคัญ แต่ส่วนหนึ่งของความเชี่ยวชาญคือการรู้ว่า เมื่อไรควรทำให้เรียบง่าย
    • สำหรับงานที่ค่อนข้างง่ายและแยกขาดจากส่วนอื่นได้ สเปกที่ละเอียดเกินไปอาจยิ่งเพิ่มความสับสน
    • ตัวอย่าง: สำหรับงานอย่าง “จัด div ให้อยู่กึ่งกลางหน้า”
      • แค่กำหนดว่า “ให้วิธีแก้กระชับ และอย่าเพิ่ม markup หรือ style ที่ไม่จำเป็น” ก็เพียงพอ
    • ตรงกันข้าม งานซับซ้อนอย่าง “implement OAuth flow ที่มีทั้ง token refresh และการจัดการข้อผิดพลาด” จำเป็นต้องมีสเปกละเอียด
    • หลักเชิงประสบการณ์คือ ปรับความหนาแน่นของสเปกให้เหมาะกับความซับซ้อนของงาน

  • ให้มนุษย์เป็นตัวกรองคุณภาพขั้นสุดท้าย

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

หลักการข้อ 5: ทดสอบ ทำซ้ำ และพัฒนาสเปกต่อเนื่อง (ใช้เครื่องมือให้ถูกต้อง)

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

  • การทดสอบอย่างต่อเนื่อง

    • อย่ารอจนกว่าการพัฒนาทั้งหมดจะเสร็จ ควรทดสอบหรือทำการตรวจแบบแมนนวลอย่างง่ายตามไมล์สโตนสำคัญหรือในระดับฟังก์ชัน
    • หากพบความล้มเหลว อย่าฝืนเดินหน้าต่อ แต่ให้แก้สเปกหรือพรอมป์ตก่อน
    • การทดสอบอัตโนมัติมีประสิทธิภาพเป็นพิเศษ และหากมีชุดทดสอบอยู่แล้ว ก็สามารถให้เอเจนต์รันคำสั่งอย่าง npm test ได้โดยตรง
    • ใช้ผลลัพธ์การทดสอบที่ล้มเหลวเป็นอินพุตของพรอมป์ถัดไปได้ทันที
      • ตัวอย่าง: “ผลลัพธ์ยังไม่ตรงตามสเปกใน X, Y, Z ให้แก้ไข”
    • ลูปแบบ agentic loop ที่ต่อเนื่องจากโค้ด → ทดสอบ → แก้ไข → ทำซ้ำ เป็นวิธีที่ทรงพลังมาก

  • การทำซ้ำที่ตัวสเปกเอง

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

  • การจัดการคอนเท็กซ์และการใช้เครื่องมือด้านความจำ

    • ecosystem ของเครื่องมือ ที่ช่วยจัดการคอนเท็กซ์และองค์ความรู้ของ AI agent กำลังเติบโตอย่างรวดเร็ว
    • หากใช้แพตเทิร์น RAG (Retrieval-Augmented Generation) เอเจนต์จะดึงเฉพาะข้อมูลที่จำเป็นจาก knowledge base เช่น vector database ได้ทันที
    • หากสเปกมีขนาดใหญ่มาก อาจฝัง embedding แยกตามเซกชันไว้ แล้วให้เอเจนต์ค้นคืนเฉพาะส่วนที่เกี่ยวข้องที่สุดแทนการรับทั้งหมด
    • เฟรมเวิร์กที่อิง MCP (Model Context Protocol) สามารถจัดส่งคอนเท็กซ์ที่เหมาะกับงานปัจจุบันโดยอัตโนมัติ
    • เครื่องมืออย่าง Context7(context7.com) จะดึง snippet ที่เกี่ยวข้องจากเอกสารมาให้อัตโนมัติตามงานที่กำลังทำ

  • การทำงานแบบขนานอย่างระมัดระวัง

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

  • การควบคุมเวอร์ชันและการล็อกสเปก

    • ใช้เครื่องมือควบคุมเวอร์ชันอย่าง Git เพื่อติดตามงานของเอเจนต์อย่างละเอียด
    • ยิ่งใช้ AI มากขึ้น ความสำคัญของนิสัยการจัดการเวอร์ชันที่ดีก็ยิ่งมากขึ้น
    • คอมมิตไฟล์สเปกเองไว้ในรีโพซิทอรีเพื่อเก็บประวัติการเปลี่ยนแปลง
    • เอเจนต์เองก็สามารถอ่าน git diff หรือ blame เพื่อเข้าใจบริบทของการเปลี่ยนแปลงได้
      • ในทางปฏิบัติ LLM เก่งมากพอสมควรในการตีความ diff
    • เมื่อวางสเปกไว้ในรีโป ทั้งนักพัฒนาและ AI ก็จะติดตามวิวัฒนาการของโปรเจกต์ร่วมกันได้
    • Willison อธิบายว่าโมเดลนั้น “เก่ง Git อย่างดุดัน”

  • การพิจารณาเรื่องต้นทุนและความเร็ว

    • งานที่ใช้โมเดลขนาดใหญ่และคอนเท็กซ์ยาว อาจช้าและมีต้นทุนสูง
    • ควรแยกการเลือกโมเดลอย่างมีกลยุทธ์
      • ใช้โมเดลที่เร็วและถูกกว่าสำหรับร่างแรกหรือการทำงานซ้ำ ๆ
      • ใช้โมเดลที่เก่งที่สุด (และแพงกว่า) สำหรับผลลัพธ์สุดท้ายหรือการใช้เหตุผลที่ซับซ้อน
    • ตัวอย่าง: ให้ GPT-4 หรือ Claude จัดการการวางแผนและขั้นตอนสำคัญ ส่วนงานขยายง่าย ๆ หรือการรีแฟกเตอร์ให้โมเดลโลคัลหรือ API model ขนาดเล็กรับผิดชอบ
    • เอเจนต์สำหรับรันเทสต์หรือลินเตอร์เอเจนต์ มักใช้โมเดลที่เล็กกว่าก็เพียงพอ
    • ขนาดคอนเท็กซ์ก็เป็นสิ่งที่ต้องบริหารเช่นกัน

  • มอนิเตอร์และล็อกทุกอย่าง

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

  • การเรียนรู้และการปรับปรุง

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

หลีกเลี่ยงความผิดพลาดที่พบบ่อย

  • จากการวิเคราะห์ไฟล์เอเจนต์กว่า 2,500 ไฟล์บน GitHub พบว่าสาเหตุหลักของความล้มเหลวคือ สเปกและคำสั่งคลุมเครือเกินไป

  • พรอมป์ตที่กำกวม

    • คำขออย่าง “ช่วยทำอะไรเจ๋ง ๆ หน่อย” หรือ “ทำให้มันทำงานดีขึ้น” ให้ เกณฑ์ในการตัดสินใจแทบไม่มีเลย สำหรับเอเจนต์
    • ควรระบุอินพุต เอาต์พุต และเงื่อนไขข้อจำกัดให้ชัดเจนที่สุดเท่าที่ทำได้
    • การกำหนดบทบาทแบบทั่วไป เช่น “คุณคือ coding assistant ที่มีประโยชน์” แทบไม่ช่วยอะไร
    • ในทางกลับกัน หากระบุ บทบาท ขอบเขต และข้อจำกัดไปพร้อมกัน เช่น “คุณเป็น test engineer ที่เขียนเทสต์สำหรับ React component ให้ทำตามตัวอย่างนี้และห้ามแก้ source code เด็ดขาด” จะได้ผลดีกว่ามาก

  • คอนเท็กซ์มากเกินไปโดยไม่มีสรุป

    • การเทเอกสาร 50 หน้าลงในพรอมป์ตตรง ๆ แล้วคาดหวังให้โมเดลเข้าใจเอง มักล้มเหลวเป็นส่วนใหญ่
    • จำเป็นต้องใช้ การสรุปแบบลำดับชั้น หรือ RAG เพื่อเปิดเผยเฉพาะเนื้อหาที่เกี่ยวข้องโดยตรงกับงานปัจจุบัน
    • การเพิ่มความยาวของคอนเท็กซ์ ไม่ได้ชดเชยคุณภาพของคอนเท็กซ์ที่ ไม่ดีพอ

  • ข้ามการตรวจทานโดยมนุษย์

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

  • สับสนระหว่าง vibe coding กับ production engineering

    • การทำต้นแบบอย่างรวดเร็วด้วย AI หรือที่เรียกว่า “vibe coding” เหมาะกับช่วงสำรวจหรือโปรเจกต์ใช้ครั้งเดียว
    • หากนำผลลัพธ์นั้นไปปล่อยขึ้น production ตรง ๆ โดยไม่มีสเปกที่เข้มงวด การทดสอบ และการตรวจทาน ก็มีโอกาสเกิดปัญหาสูง
    • ต้องแยก “vibe coding” ออกจาก “AI-assisted engineering” ให้ชัดเจน โดยอย่างหลังต้องอาศัย วินัยและกระบวนการ ตามที่อธิบายไว้ในคู่มือนี้
    • สิ่งสำคัญคือการตระหนักว่าตอนนี้คุณกำลังทำงานอยู่ในโหมดใด

  • มองข้าม “สามประสานร้ายแรง”

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

  • การตกหล่นของ 6 พื้นที่หลัก

    • หากสเปกไม่ได้ครอบคลุม Commands, Testing, Project Structure, Code Style, Git Workflow และ Boundaries เอเจนต์ก็มีแนวโน้มจะพลาดข้อมูลสำคัญที่จำเป็นต่อการทำงาน
    • ก่อนส่งให้เอเจนต์ ควรตรวจซ้ำด้วย เช็กลิสต์ 6 ด้าน อีกครั้งเพื่อความปลอดภัย

บทสรุป

  • การเขียนสเปกอย่างมีประสิทธิภาพสำหรับ AI coding agent ต้องอาศัยทั้ง หลักการวิศวกรรมซอฟต์แวร์ที่แข็งแรง และแนวทางที่เข้าใจคุณลักษณะของ LLM แล้วปรับให้สอดคล้อง
  • ทุกอย่างเริ่มต้นจากการกำหนดเป้าหมายให้ชัดเจน แล้วค่อยแบ่งบทบาทให้ AI ขยายแผนและรายละเอียดต่อจากจุดนั้น
  • สเปกไม่ควรถูกมองเป็นแค่บันทึก แต่ต้องปฏิบัติกับมันในฐานะ เอกสารออกแบบอย่างจริงจัง โดยควรมีองค์ประกอบหลัก 6 ด้าน และถูกมองเป็น อาร์ติแฟกต์ที่นำไปปฏิบัติได้จริง ซึ่งเชื่อมต่อกับ toolchain
  • แทนที่จะให้ทุกอย่างในคราวเดียว ควรแบ่งส่งตามหน่วยงานเพื่อรักษาโฟกัสของเอเจนต์
    (สารบัญสรุป, sub-agent, และการ orchestration แบบขนาน เป็นวิธีที่ใช้ได้จริงในการจัดการสเปกขนาดใหญ่)
  • ใช้ ขอบเขต 3 ระดับ (Always / Ask first / Never), การตรวจสอบตัวเอง และการทดสอบความเหมาะสม เพื่อป้องกันกับดักที่ AI มักพลาดล่วงหน้า
  • หัวใจสำคัญคือการมองสเปกและการพัฒนาไม่ใช่ผลลัพธ์ที่ตายตัว แต่เป็น กระบวนการแบบวนซ้ำ และค่อยๆ ปรับแต่งทั้งสเปกและโค้ดไปพร้อมกันผ่านการทดสอบและฟีดแบ็ก
  • หากทำตามแนวทางนี้ จะสามารถ ลดโอกาสได้อย่างเห็นได้ชัด ที่ AI agent จะหลงทางในคอนเท็กซ์ขนาดใหญ่หรือไหลไปสู่คำตอบที่เพ้อเจ้อ

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

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

 
gomjellie 2026-01-22

แม้จะเป็นการแปลด้วย AI แต่มีฉบับแปลภาษาเกาหลีด้วย เลยขอแชร์ลิงก์ครับ

https://rosetta.page/post/…
 
qor0923 2026-01-20

ขอบคุณครับ
 
googol 2026-01-19

โดยส่วนตัวแล้ว ตอนที่พัฒนาโปรเจกต์ด้วย SDD (Specs Driven Development) ผมรู้สึกได้ถึงการเพิ่มขึ้นของประสิทธิภาพการทำงานอย่างชัดเจนในช่วงแรก แต่ก็ยังไม่สามารถเขียนโค้ดทั้งหมดโดยอิงจากสเปกได้ และทุกครั้งที่จำเป็นต้องแก้ไขด้วยตนเองก็ต้องอัปเดตทั้งโค้ดและสเปกไปพร้อมกัน ทำให้กลับกลายเป็นว่าประสิทธิภาพการทำงานลดลง