Structured-Prompt-Driven Development (SPDD)

เกี่ยวกับบทแปลนี้

บทความนี้เป็น บทแปลภาษาไทยอย่างไม่เป็นทางการ ของ “Structured-Prompt-Driven Development (SPDD)” โดย Wei Zhang และ Jessie Jie Xia (Thoughtworks)

เผยแพร่ครั้งแรกบน martinfowler.com เมื่อ 28 เมษายน 2026 และเพิ่มส่วนถาม-ตอบเมื่อ 4 พฤษภาคม 2026 (Martin Fowler มีส่วนร่วมในการขัดเกลาโครงเรื่องและไดอะแกรมของต้นฉบับ)

แปลและเรียบเรียงเพื่อการศึกษา — ไดอะแกรมเชิงแนวคิดวาดใหม่เป็นภาษาไทย ส่วนภาพหน้าจอของเครื่องมือมี link ไปยังต้นฉบับ และศัพท์เทคนิคคงไว้เป็นภาษาอังกฤษตามต้นฉบับ ลิขสิทธิ์ของเนื้อหาต้นฉบับเป็นของผู้เขียน

วิธีทำให้การแก้ code ด้วย LLM กำกับดูแลได้ ตรวจทานได้ และนำกลับมาใช้ซ้ำได้

ผู้ช่วยเขียนโปรแกรมที่ขับเคลื่อนด้วย LLM พิสูจน์แล้วว่ามีคุณค่ามากทีเดียว แต่ส่วนใหญ่ยังเป็นคุณค่าในระดับนักพัฒนารายคน

องค์กรไอทีภายในของ Thoughtworks นำเครื่องมือเหล่านี้มาใช้กับทีมต่าง ๆ และได้พัฒนาวิธีการและ workflow ขึ้นมาตัวหนึ่งที่เราเรียกว่า Structured Prompt-Driven Development (SPDD) — การพัฒนาที่ขับเคลื่อนด้วย structured prompt บทความนี้อธิบายตัวอย่าง workflow แบบเรียบง่าย พร้อมรายละเอียดบน GitHub

workflow นี้ปฏิบัติต่อ prompt ในฐานะชิ้นงานชั้นหนึ่ง (first-class artifact) ที่ถูกเก็บไว้คู่กับ code ใน version control และนำมาใช้เพื่อจัดแนวการพัฒนาให้ตรงกับความต้องการทางธุรกิจ

เราพบว่านักพัฒนาต้องมีทักษะหลักสามอย่างจึงจะทำงานนี้ได้อย่างมีประสิทธิภาพ ได้แก่:

alignment — การจัดแนวเจตนา
abstraction-first — ออกแบบนามธรรมก่อน
iterative review — การตรวจทานแบบวนซ้ำ

เมื่อทีมเริ่มนำผู้ช่วย AI สำหรับเขียน code มาใช้ ผลที่ได้แรก ๆ มักปรากฏในระดับบุคคล กล่าวคือ นักพัฒนาคนหนึ่งสามารถร่าง แก้ และ refactor code ได้เร็วกว่าเดิมมาก

แต่ความเร็วในการส่งมอบ (delivery speed) นั้นแทบไม่เคยถูกจำกัดด้วยความเร็วในการพิมพ์ เมื่อมองดูตลอดวงจรการส่งมอบทั้งหมด ตั้งแต่ requirement ไปจนถึงการ release จะเห็นแรงเสียดทานแบบใหม่โผล่ขึ้นมา:

requirement ที่กำกวมถูกแปลงเป็น code อย่างรวดเร็ว และความเข้าใจผิดก็ขยายตัวตามไปด้วย
การรีวิวต้องรับมือกับการเปลี่ยนแปลงปริมาณที่มากขึ้น และความไม่สอดคล้องกันก็แทรกเข้ามาได้ง่ายขึ้น
ปัญหาด้านการ integrate และ test โผล่ขึ้นมามากขึ้น เพราะคำว่า “generate ได้แล้ว” ไม่ได้แปลว่า “ตรงเจตนาแล้ว”
ความเสี่ยงบน production ประเมินยากขึ้น เมื่อปริมาณการเปลี่ยนแปลงเพิ่มสูงขึ้น

ดังนั้น ใช่ — ความเร็วในระดับท้องถิ่นดีขึ้นจริง แต่นั่นไม่ได้แปลงเป็น throughput ในระดับทั้งระบบโดยอัตโนมัติ

มันเหมือนกับการซื้อรถ Ferrari มาขับบนถนนโคลน เครื่องยนต์ทรงพลังก็จริง แต่เวลาที่ไปถึงจุดหมายถูกกำหนดด้วยสภาพถนนและการจราจร

จากประสบการณ์ของเรา คำถามที่แท้จริงไม่ใช่ “เราจะ generate code ให้มากขึ้นได้อย่างไร?” แต่คือ เราจะทำให้การเปลี่ยนแปลงที่ AI สร้างขึ้นกำกับดูแลได้ ตรวจทานได้ และนำกลับมาใช้ซ้ำได้อย่างไร เพื่อให้ทีมทำงานได้ทั้งเร็วขึ้นและปลอดภัยขึ้น

นั่นนำพาทีมไอทีภายในของ Thoughtworks (Global IT Services) ไปสู่วิธีการและ workflow ที่ตอนนี้เราเรียกว่า Structured Prompt-Driven Development (SPDD) เป้าหมายของ SPDD คือเปลี่ยนความช่วยเหลือจาก AI จาก “ประสิทธิภาพส่วนบุคคล” ให้กลายเป็น “ความสามารถระดับองค์กร” ที่ขยายขนาดได้ โดยไม่ต้องแลกกับคุณภาพ

Prompt ในฐานะชิ้นงานส่งมอบชั้นหนึ่ง

SPDD คืออะไร?

Structured Prompt-Driven Development (SPDD) คือวิธีการทางวิศวกรรมที่ปฏิบัติต่อ prompt ในฐานะชิ้นงานส่งมอบชั้นหนึ่ง (first-class delivery artifact)

แทนที่จะพึ่งบทแชตแบบทำไปเรื่อย (ad hoc) SPDD เปลี่ยน prompt ให้เป็นสินทรัพย์ที่สามารถควบคุม version (version control), ตรวจทาน, นำกลับมาใช้ซ้ำ และปรับปรุงให้ดีขึ้นเมื่อเวลาผ่านไปได้

ทีมใช้ structured prompt เพื่อเก็บ requirement, ภาษาของ domain (domain language), เจตนาในการออกแบบ, ข้อจำกัด และการแตกย่อยงาน (task breakdown) จากนั้น LLM จึง generate code ภายในขอบเขตที่นิยามไว้ ผลลัพธ์จึงคาดเดาได้มากขึ้นและตรวจสอบได้ง่ายขึ้น

SPDD มีองค์ประกอบหลักสองส่วน คือ REASONS Canvas และ workflow ของ SPDD โดยมีภาพรวมของทั้งวงรอบดังนี้

flowchart TB
  subgraph ITN["Iteration N"]
    direction TB
    bi1["Business Intent"]
    sp1["Structured Prompt<br/>versioned · reviewable · reusable"]
    ct1["Code & Tests"]
    bi1 -->|"REASONS Canvas"| sp1
    sp1 -->|"code generation"| ct1
    ct1 -.->|"sync"| sp1
  end
  subgraph ITN1["Iteration N+1"]
    direction TB
    bi2["Business Intent"]
    sp2["Structured Prompt<br/>versioned · reviewable · reusable"]
    ct2["Code & Tests"]
    bi2 -->|"REASONS Canvas"| sp2
    sp2 -->|"code generation"| ct2
    ct2 -.->|"sync"| sp2
  end
  sp1 ==>|"accumulated prompt assets"| sp2
  ct1 ==>|"accumulated code assets"| ct2

ภาพ 1 — ภาพรวมของ SPDD: ในแต่ละ iteration เจตนาทางธุรกิจ (Business Intent) ถูกแปลงผ่าน REASONS Canvas ไปเป็น structured prompt (ที่ควบคุม version-ตรวจทาน-ใช้ซ้ำได้) แล้วจึง generate ออกมาเป็น Code & Tests ลูกศรประ “sync” สื่อว่าการเปลี่ยนแปลงฝั่ง code ถูก sync กลับเข้าหา prompt ส่วนลูกศรหนาระหว่าง iteration คือ สินทรัพย์ prompt และ code ที่สะสมไว้ ซึ่งกลายเป็น context ตั้งต้นของรอบถัดไป · ดูภาพต้นฉบับ ↗

REASONS Canvas

REASONS Canvas คือโครงสร้างสำหรับ generate prompt มันบังคับให้เกิดความชัดเจนรอบ ๆ ประเด็นต่อไปนี้: requirement, domain model, แนวทางแก้ปัญหา (solution approach), โครงสร้างของระบบ, การแตกย่อยงาน, บรรทัดฐานที่นำกลับมาใช้ซ้ำได้ (reusable norms), และมาตรการป้องกัน (safeguards)

ทั้งหมดนี้เพื่อให้ LLM ถูกนำทางด้วย “เจตนา” ไม่ใช่ “การเดา”

REASONS Canvas เป็นโครงสร้างเจ็ดส่วนที่นำทาง prompt จาก เจตนา → การออกแบบ → การลงมือทำ → การกำกับดูแล (intent → design → execution → governance)

flowchart TB
  subgraph MAIN["Main Area"]
    direction LR
    subgraph ABS["Abstraction Parts — intent & design"]
      direction LR
      R["R — Requirements"]
      E["E — Entities"]
      A["A — Approach"]
      S["S — Structure"]
    end
    subgraph SPE["Specific Parts — execution"]
      O["O — Operations"]
    end
  end
  subgraph STD["Common Standard Parts — governance"]
    direction LR
    N["N — Norms"]
    SG["S — Safeguards"]
  end
  ABS ==> SPE
  MAIN -.-> STD

ภาพ 2 — โครงสร้างของ REASONS Canvas: ส่วนพื้นที่หลัก (Main Area) แบ่งเป็น ส่วนนามธรรม (intent & design — R, E, A, S) และ ส่วนเฉพาะเจาะจง (execution — O) ด้านล่างคือ ส่วนมาตรฐานร่วม (governance — N, S) ที่ใช้พาดผ่านทุกส่วน · ดูภาพต้นฉบับ ↗

ส่วนนามธรรม (เจตนาและการออกแบบ)

R — Requirements: เรากำลังแก้ปัญหาอะไร และอะไรคือ DoD (Definition of Done — นิยามของคำว่าเสร็จ)?
E — Entities: entity ของ domain และความสัมพันธ์ระหว่างกัน
A — Approach: กลยุทธ์ว่าเราจะตอบโจทย์ requirement ได้อย่างไร
S — Structure: การเปลี่ยนแปลงนี้อยู่ตรงไหนในระบบ มีคอมโพเนนต์และ dependency อะไรบ้าง

ส่วนเฉพาะเจาะจง (การลงมือทำ)

O — Operations: แตกกลยุทธ์นามธรรมออกเป็นขั้นตอนการ implement ที่เป็นรูปธรรมและทดสอบได้

ส่วนมาตรฐานร่วม (การกำกับดูแล)

N — Norms: บรรทัดฐานทางวิศวกรรมที่พาดผ่านทุกส่วน (การตั้งชื่อ, observability, defensive coding ฯลฯ)
S — Safeguards: ขอบเขตที่ต่อรองไม่ได้ (invariant, ขีดจำกัดด้านประสิทธิภาพ, กฎความปลอดภัย ฯลฯ)

Canvas จัดแนวเจตนาและขอบเขตให้ตรงกันก่อนที่จะ generate code เป็นการ “ย้ายความไม่แน่นอนไปทางซ้าย” (moving uncertainty to the left)

เนื่องจาก structured prompt เก็บ specification ไว้ครบทั้งชุด ผู้ตรวจทานจึงใช้เหตุผลกับชิ้นงานชิ้นเดียว แทนที่จะต้องไล่ดูบทแชตที่กระจัดกระจายกับ diff ที่ไม่ครบ และเพราะทุก prompt ใช้โครงสร้างเดียวกัน prompt ทุกอันจึงกำกับดูแลได้ในแบบเดียวกัน

ยิ่งความรู้ของ domain และการตัดสินใจด้านการออกแบบสะสมอยู่ในแต่ละ prompt มากขึ้น มันก็ยิ่งทบความเชี่ยวชาญของแต่ละคนเข้าด้วยกันข้ามรอบการทำงาน และลดความแปรปรวนภายในทีม

workflow ของ SPDD

workflow นำ prompt เข้ามาอยู่ภายใต้วินัยเดียวกับ code ไม่ว่าจะเป็น commit history, การรีวิว, และ quality gate และยังบังคับใช้กฎข้อหนึ่งที่เรียบง่ายแต่ทรงพลัง:

เมื่อความเป็นจริงเบนออกจากกัน ให้แก้ที่ prompt ก่อน — แล้วค่อยอัปเดต code

เมื่อเวลาผ่านไป สิ่งนี้เปลี่ยนวิธีทำงานของทีม การรีวิวขยับจาก “จับ bug” (spot the bug) ไปสู่ “ตรวจเจตนา” (check the intent) การทำงานซ้ำ (rework) ควบคุมได้มากขึ้น และ pattern ที่ใช้ได้ผลก็สะสมเข้าเป็น library ของ prompt ที่นำกลับมาใช้ซ้ำได้ ซึ่งเป็นรากฐานของ AI-First Software Delivery (AIFSD)

ถ้าคุณรู้จัก Spec-Driven Development มาก่อน คุณจะจำจุดตั้งต้นเดียวกันนี้ได้ คือ เขียน spec ให้ชัดเจนก่อน แล้วปล่อยให้ model implement ตามนั้น

แต่ SPDD มองจากมุมที่ต่างออกไป มันปฏิบัติต่อ structured prompt ในฐานะสินทรัพย์ของทีมที่กำกับดูแลได้ นำกลับมาใช้ซ้ำได้ และมี version (REASONS + workflow) ซึ่งวิวัฒน์ไปพร้อมกับ code — แนวทางที่ Birgitta Böckeler จัดว่าเป็นแบบ spec-anchored

SPDD เพิ่มอะไรเข้าไปจาก spec-driven development

SDD และ SPDD มีจุดตั้งต้นเดียวกัน คือ generate spec ก่อน generate code แต่ SPDD เพิ่ม “วิธีการ” ว่า spec นั้นถูกผลิต ตรวจทาน และคงให้ sync กับ code อย่างไรเข้ามาด้วย

prompt คือชิ้นงานที่ถูกดูแล ไม่ใช่ของที่ generate ครั้งเดียวแล้วทิ้ง มันผ่าน workflow ที่นิยามไว้ และยังคงเป็นบันทึกของ “สิ่งที่ตั้งใจจะทำ”
จาก requirement สู่ engineering spec REASONS Canvas ไปไกลกว่าแค่ “ระบบควรทำอะไร” มันเก็บแนวทางที่เลือกใช้ โครงสร้างของระบบ บรรทัดฐานทางวิศวกรรม และมาตรการป้องกัน — เป็นการให้ขอบเขตการ implement แก่ LLM ไม่ใช่แค่เป้าหมาย
sync ไม่ใช่ส่งต่อแล้วจบ (sync, not handoff) prompt และ code ยังคง sync กันอยู่ การเปลี่ยนแปลงฝั่งใดฝั่งหนึ่งสะท้อนกลับไปอีกฝั่ง เพื่อให้เจตนาและการ implement ไม่เบนออกจากกัน
การควบคุมระดับทีมที่ทำซ้ำได้ ประเด็นไม่ใช่ “spec ที่ละเอียดขึ้น” แต่คือวิธีที่สอดคล้องกันสำหรับให้ทีมกำกับดูแลผลลัพธ์ของ AI และพกพาสิ่งที่ตัดสินใจไปแล้วต่อข้ามรอบการทำงาน ส่วนการวิเคราะห์ trade-off ที่อยู่เบื้องหลังการตัดสินใจเหล่านั้นอยู่ในเฟส analysis ส่วน Canvas บันทึกเฉพาะ “ผลลัพธ์”

เป้าหมายของ workflow SPDD คือเปลี่ยน input ทางธุรกิจ → นามธรรม → การลงมือทำ → การตรวจสอบ → การ release ให้เป็น “วงรอบปิด” (closed loop) ¹ — และทำให้แน่ใจว่าสินทรัพย์ prompt กับ code วิวัฒน์ไปด้วยกัน ไม่ใช่แยกกันเดิน

flowchart TB
  s1["Step 1 — create initial requirements"]
  s2["Step 2 — clarify analysis"]
  s3["Step 3 — generate analysis context"]
  s4["Step 4 — generate structured prompt"]
  s5["Step 5 — generate code"]
  s6["Step 6 — generate unit tests"]
  s7["integrate, build, and deploy"]
  ac(["analysis context"])
  sp(["Structured Prompts"])
  cd(["Code → git"])
  s1 --> s2 --> s3 --> s4 --> s5 --> s6 --> s7
  s3 -.-> ac -.-> s4
  s4 -.-> sp -.-> s5
  s5 -.-> cd

ภาพ 3 — workflow ของ SPDD ทั้งหกขั้น ตั้งแต่สร้าง requirement ตั้งต้น ไปจนถึง integrate-build-deploy แต่ละขั้นกลางทางผลิตชิ้นงานที่ส่งต่อให้ขั้นถัดไป — analysis context, Structured Prompts, และ Code (เก็บใน git) โดย Step 4 อาศัย REASONS Canvas เป็นโครง · ดูภาพต้นฉบับ ↗

จุดมุ่งหมายของ workflow นี้คือยึดการทำงานร่วมกันไว้ที่ตัว prompt เพื่อให้นักพัฒนาและ product owner หลีกเลี่ยงการวนจัดแนวความเข้าใจซ้ำ ๆ

prompt ตั้งขอบเขตที่ชัดเจนให้กับการ generate code ลดความสุ่มจาก non-determinism ของ LLM และทำให้กำกับดูแลได้ง่ายขึ้น

เมื่อปฏิบัติต่อ structured prompt ในฐานะชิ้นงานชั้นหนึ่งใน version control เราก็เปลี่ยนวิธีปฏิบัติที่ได้ผลให้กลายเป็นสินทรัพย์ที่นำกลับมาใช้ซ้ำได้ เพิ่มความสอดคล้อง และลดการ “คิดค้นใหม่” โดยไม่จำเป็น

ในทางปฏิบัติ ขั้นตอนเหล่านี้ดำเนินผ่านคำสั่งที่ openspdd มีให้ ซึ่งเป็นเครื่องมือ command-line ที่ implement workflow SPDD ตารางด้านล่างสรุปแต่ละคำสั่ง

คำสั่ง	ประเภท	จุดประสงค์
`/spdd-story`	เสริม (Optional)	แตก requirement ก้อนใหญ่ออกเป็น user story ที่ส่งมอบได้อย่างเป็นอิสระ ตามหลัก INVEST
`/spdd-analysis`	จำเป็น (Core)	ดึง domain keyword จาก requirement สแกน code ที่เกี่ยวข้อง และผลิตการวิเคราะห์เชิงกลยุทธ์ที่ครอบคลุมแนวคิดของ domain ความเสี่ยง และทิศทางการออกแบบ
`/spdd-reasons-canvas`	จำเป็น (Core)	generate REASONS Canvas ฉบับเต็ม — พิมพ์เขียวที่รันได้ ตั้งแต่เหตุผลระดับสูงลงไปจนถึง operation ระดับ method
`/spdd-generate`	จำเป็น (Core)	อ่าน Canvas แล้ว generate code ทีละ task โดยทำตาม operation, norm และ safeguard ที่นิยามไว้ใน prompt อย่างเคร่งครัด
`/spdd-api-test`	เสริม (Optional)	generate script ทดสอบ API ที่ใช้ cURL พร้อม test case แบบมีโครงสร้างครอบคลุมกรณีปกติ กรณีขอบ และกรณีผิดพลาด
`/spdd-prompt-update`	จำเป็น (Core)	อัปเดต Canvas แบบเพิ่มทีละส่วนเมื่อ requirement เปลี่ยน (requirement → prompt → code)
`/spdd-sync`	จำเป็น (Core)	sync การเปลี่ยนแปลงฝั่ง code (refactor, fix) กลับเข้า Canvas เพื่อให้ prompt ยังเป็นบันทึกที่ตรงกับ code ปัจจุบัน (code → prompt)

ยกระดับ billing engine ด้วย SPDD

workflow ที่ซับซ้อนทำความเข้าใจได้ยากในระดับนามธรรม เราจึงเตรียมตัวอย่าง workflow ของการยกระดับระบบซอฟต์แวร์ที่มีอยู่แล้วเอาไว้ ระบบนี้และการยกระดับของมันจำเป็นต้องมีขนาดเล็ก เพื่อให้เข้าใจได้ภายในบทความสอนแบบ tutorial

อย่างไรก็ตาม ตัวอย่างนี้เป็นตัวอย่างแบบ end-to-end ที่ครบถ้วน ตั้งแต่การสร้าง requirement ตั้งต้น, การวิเคราะห์ requirement ทางธุรกิจ, การ generate และรีวิว structured prompt, การผลิตและตรวจสอบ code ไปจนถึงการเก็บกวาดและทดสอบขั้นสุดท้าย

คุณสามารถทำตามตัวอย่างนี้ไปด้วยได้ โดยติดตั้ง openspdd ในสภาพแวดล้อมของคุณเอง

ระบบปัจจุบัน

ระบบปัจจุบันเป็น billing engine แบบเรียบง่ายที่คำนวณบิลค่าใช้งาน large-language model มันรับ record ที่บันทึกว่าใช้ token ไปกี่ตัวใน1 session แล้วคำนวณเป็นบิล

codebase ฉบับเต็มของ version ตั้งต้นนี้ดูได้บน GitHub repository นี้รวม user story ของ requirement ตั้งต้น และ ชิ้นงาน SPDD ทั้งหมด ที่ใช้ generate มันขึ้นมา

เพื่อความกระชับ เราจะไม่อธิบายการ generate ตั้งต้นในที่นี้ แต่มันก็ทำตามขั้นตอนเดียวกับการยกระดับโดยพื้นฐาน เราเลือกอธิบายการยกระดับเพราะงานส่วนใหญ่บนระบบหนึ่ง ๆ ล้วนเป็นการยกระดับ

โจทย์การยกระดับ

ด้วยความต้องการทางธุรกิจที่เปลี่ยนไปและ feedback ตรงจากผู้ใช้ เรากำลังยกระดับ billing engine ให้เปลี่ยนจาก model การตั้งราคาแบบตายตัว (static pricing) ไปสู่โครงสร้างที่ซับซ้อนและยืดหยุ่นกว่า

การอัปเดตนี้มุ่งรองรับกลยุทธ์การสมัครสมาชิก (subscription) ที่หลากหลาย และการตั้งราคาแบบแปรผันตาม model ผ่านการเปลี่ยนแปลงสำคัญต่อไปนี้:

ยกระดับ API: อัปเดต endpoint POST /api/usage เดิมให้รับ parameter modelId ตัวใหม่ที่จำเป็นต้องมี (เช่น “fast-model”, “reasoning-model”)
การตั้งราคาตาม model (model-aware pricing): เปลี่ยนจากเรตเดียวทั้งระบบไปสู่การตั้งราคาแบบไดนามิก โดยค่าใช้จ่ายจะแปรผันตาม model AI ที่ถูกเรียกใช้
ตรรกะการคิดบิลแบบหลายแพลน (multi-plan billing): เพิ่มพฤติกรรมการคิดบิลที่แตกต่างกันตามระดับการสมัครสมาชิกของลูกค้า:
- แพลน Standard (ปรับให้เหมาะสม): ยังคงโควตารายเดือนแบบรวม (global monthly quota) ไว้ แต่การใช้งานส่วนเกิน (overage) ตอนนี้คิดด้วยเรตเฉพาะของแต่ละ model
- แพลน Premium (ใหม่): ทำงานโดยไม่มีขีดจำกัดโควตา มี split billing คือ prompt token และ completion token ถูกคิดเงินแยกกันด้วยเรตที่ต่างกันตาม model ที่ใช้
ความสามารถในการขยายเชิงสถาปัตยกรรม: implement design pattern ที่ขยายได้ (เช่น Strategy หรือ Factory) เพื่อแยกสูตรการคำนวณของแต่ละแพลนออกจากกันอย่างสะอาด ทำให้ระบบรองรับ model การตั้งราคาใหม่ ๆ ในอนาคตได้ง่าย

เนื่องจากส่วนใหม่นี้ครอบคลุมทั้ง requirement ทางธุรกิจและรายละเอียดเชิงเทคนิค โดยทั่วไปมันจึงถูกทำให้เสร็จร่วมกันผ่าน session การ pairing ระหว่าง PO (หรือ BA) กับนักพัฒนา

ขั้นที่ 1: สร้าง requirement ตั้งต้น

เพื่อเริ่มกระบวนการอย่างรวดเร็ว เราใช้คำสั่ง /spdd-story ² generate user story จากโจทย์การยกระดับได้โดยตรง

โดยทั่วไป user story มาจาก PO หรือ BA แต่ใน workflow ของเรา เราสามารถแปลง story รูปแบบใดก็ได้ให้อยู่ในรูปแบบและมิติที่สอดคล้องกัน ตราบใดที่มีการจัดแนวร่วมกันบน acceptance criteria สุดท้าย ขั้นนี้จะทำโดย PO, BA หรือนักพัฒนาก็ได้ ขึ้นอยู่กับการแบ่งงานที่ยืดหยุ่นของทีม

`/spdd-story` ทำงานอย่างไร

คำสั่งนี้แตก requirement ก้อนใหญ่ออกเป็น user story ที่ส่งมอบได้อย่างเป็นอิสระตามหลัก INVEST (งานละ 1–5 วัน) แต่ละ story มี acceptance criteria เขียนด้วยภาษาธุรกิจ พร้อมใช้เป็น input ให้ /spdd-analysis

จุดประสงค์ของมันคือทำให้ requirement ก้อนใหญ่จัดการได้ และรับประกันรูปแบบที่เป็นมาตรฐานและคาดเดาได้สำหรับขั้นถัดไป

คำสั่ง:

/spdd-story @idea-of-the-enhancement.md

AI วิเคราะห์คำอธิบายโจทย์การยกระดับและแตกมันออกเป็น user story สองอัน:

story ที่ generate ออกมาอัตโนมัตินั้นละเอียดพอที่จะใช้เป็นฐานสำหรับ project จริงได้ แต่สำหรับการเดินตามตัวอย่างนี้ เรารวบมันเป็น story เดียวที่ย่อให้ง่ายลง เพื่อให้ตัวอย่างอยู่ได้ในตัวเอง

คำสั่ง:

รวม2 user story ต่อไปนี้ให้เป็น story เดียวที่ย่อให้ง่ายลง:

@[User-story-1-1-initial]Multi-Plan-Billing-Foundation-&-Standard-Plan-Model-Aware-Pricing.md
@[User-story-1-2-initial]Premium-Plan-Split-Rate-Billing.md

ข้อกำหนด:
1. รวมทั้งสองแพลน (Standard และ Premium) เป็น story เดียวที่ลื่นไหล
2. คงไว้เฉพาะส่วน: Background, Business Value, Scope In, Scope Out และ Acceptance Criteria
3. ตัดรายละเอียดระดับการ implement ออก — เน้นว่าระบบควรทำอะไร ไม่ใช่ทำอย่างไร
4. Acceptance Criteria ต้องใช้รูปแบบ Given/When/Then พร้อมตัวอย่างตัวเลขที่เป็นรูปธรรม
5. คงผลลัพธ์ให้กระชับ — ไม่เกินหนึ่งหน้า
6. เก็บไว้เพียง3 AC ระดับสูง

คำสั่งทำนองนี้แทบไม่เคยให้ข้อความเหมือนกันเป๊ะทุกครั้งที่รัน — ตัว model และการสุ่ม (sampling) ทำให้เกิดความต่างเล็กน้อย — เราจึงยังคาดหวังว่าจะต้องรีวิวและปรับผลลัพธ์ก่อนถือว่าเป็นฉบับสุดท้าย story รวมด้านล่างคือ version ที่เราขัดเกลามาเพื่อบทความนี้ ซึ่งเป็นการรวบ2 story ตั้งต้นให้ง่ายลงโดยตั้งใจ

📄 User Story รวม (ฉบับย่อ)

Background

เมื่อ platform LLM API ของเราขยายขนาดขึ้น model การตั้งราคาแบบเดียวไม่เพียงพออีกต่อไป เราต้อง refactor billing engine ที่มีอยู่ให้รองรับกลยุทธ์ subscription ที่ต่างกัน และการตั้งราคาแบบแปรผันตาม model AI ที่ถูกเรียกใช้ เพื่อวางรากฐานสำหรับแพลนคิดบิลที่ซับซ้อนขึ้นในอนาคต

Business Value

Flexible Monetization: รองรับกลยุทธ์การคิดบิลที่หลากหลาย (Standard, Premium) เพื่อจับตลาดหลายกลุ่ม
Model-Aware Pricing: คิดเรตต่างกันตาม model AI ที่ใช้
Architecture Scalability: implement design ที่ขยายได้ (เช่น Strategy Pattern) เพื่อแยกตรรกะการคำนวณและเพิ่ม model การตั้งราคาในอนาคตได้ง่าย

Scope In

ยกระดับ endpoint POST /api/usage ที่มีอยู่
field ใหม่ใน request: เพิ่ม modelId (จำเป็น, string, เช่น “fast-model”, “reasoning-model”)
implement กลไก routing (Strategy/Factory Pattern) เพื่อจัดการสูตรการคำนวณที่ต่างกัน
implement Plan Type สองแบบแรก:
- Standard Plan (refactor ของเดิม): มีโควตารายเดือนแบบรวม เรต overage ตอนนี้ขึ้นกับ modelId
- Premium Plan (ใหม่): ไม่มีโควตา prompt token และ completion token คิดเงินแยกกัน และเรตต่างกันตาม modelId

Scope Out

ตรรกะส่วนลดแบบขั้นบันได/ตามปริมาณที่ซับซ้อน (เลื่อนไป Phase 2)
การสร้างและกำหนดแพลน subscription (CRUD)
การออก invoice

Acceptance Criteria (ACs)

Base Validations (ทั้งของเดิมและของใหม่)
- Given request ที่ไม่ถูกต้อง (เช่น ขาด modelId, token ติดลบ)
- When backend ตรวจสอบ request
- Then คืน HTTP 400 พร้อมข้อความ error ที่เหมาะสม
Standard Plan พร้อม overage ตาม model
- Given ลูกค้า “Standard” ที่มีโควตา 100,000 ต่อเดือน ใช้ไปแล้ว 90,000 และเรต overage ของ “fast-model” คือ $0.01/1K
- When ส่ง 30,000 token สำหรับ “fast-model”
- Then บิลแสดง: 10,000 จากโควตา, 20,000 ส่วนเกิน, คิดเงิน $0.20
Premium Plan พร้อมเรตแยก
- Given ลูกค้า “Premium” สำหรับ “reasoning-model” เรต Prompt คือ $0.03/1K, Completion คือ $0.06/1K
- When ส่ง 10,000 prompt token และ 20,000 completion token สำหรับ “reasoning-model”
- Then บิลแสดง: 0 จากโควตา, ค่า prompt $0.30, ค่า completion $1.20, รวม $1.50

ขั้นที่ 2: ทำความกระจ่างจากการวิเคราะห์

ก่อนกระโดดเข้าสู่การ implement นักพัฒนาจะรีวิว user story เพื่อสร้างความเข้าใจร่วมกันว่ามันหมายความว่าอย่างไรในทางปฏิบัติ ถ้ามีประเด็นระดับธุรกิจที่ชัดเจน นี่คือจุดที่จะจัดแนวกับ BA หรือ PO

ในกรณีนี้ story ชัดเจนพออยู่แล้ว เราจึงเดินหน้าแตกมันออกตามสามมิติ ได้แก่ ตรรกะแกนกลาง (core logic), ขอบเขต (scope boundaries) และนิยามของคำว่าเสร็จ (definition of done)

ตรรกะแกนกลาง — field ใหม่ที่จำเป็นบน API หนึ่งตัวคือ modelId ลูกค้าจะบอกเราว่าใช้ model AI ตัวไหน ซึ่งเป็นกุญแจไขไปสู่ราคาที่ถูกต้อง

Standard Plan: ลูกค้ามีโควตา token รายเดือน ใช้ภายในโควตาไม่คิดเงิน ส่วนเกิน (overage) คิดด้วยเรตเฉพาะ model (เช่น fast-model $0.01/1K เทียบกับ reasoning-model $0.03/1K) ตรรกะโควตาเดิมคงไว้ เปลี่ยนเฉพาะการ lookup เรต
Premium Plan: ไม่มีโควตา ทุก token คิดเงินตั้งแต่ตัวแรก prompt token และ completion token คิดแยกกัน แต่ละอย่างด้วยเรตเฉพาะ model บิล = ค่า prompt + ค่า completion แพลนนี้เป็นของใหม่ทั้งหมด
Routing: ระบบดูว่าลูกค้าอยู่แพลนไหนแล้วส่งต่อไปยังสูตรคิดบิลที่ตรงกัน design ต้องขยายง่าย เพราะแพลน Enterprise (Story 2) เป็นลำดับถัดไป

ขอบเขต — เราคำนวณเฉพาะบิลปัจจุบันเท่านั้น เราไม่ได้สร้าง CRUD ลูกค้า, ไม่ได้ query บิลย้อนหลัง, ไม่ได้จัดการ subscription และไม่ได้เพิ่ม/ลบ model

นิยามของคำว่าเสร็จ — ฉากทัศน์ต่อไปนี้เรียบเรียง acceptance criteria ของ story ใหม่ด้วยรายละเอียดการ implement ที่ทีมต้องตรวจสอบ ข้อที่สี่ (รูปแบบ response) ไม่ใช่ AC ทางธุรกิจอันใหม่ แต่เป็นสัญญาเชิงไม่เป็น function (non-functional contract) ที่นักพัฒนาเพิ่มเข้ามาเพื่อให้เกณฑ์ทดสอบได้แบบ end-to-end

Validation: ขาด modelId → HTTP 400; ลูกค้าไม่รู้จัก → HTTP 404; token ติดลบ → HTTP 400; validation เดิมทั้งหมดยังคงอยู่ครบ
การคิดบิลแพลน Standard: ลูกค้าที่มีโควตา 100K ใช้ไปแล้ว 90K ส่ง 30K token สำหรับ fast-model ($0.01/1K) ผลที่คาดหวัง: 10K ครอบคลุมด้วยโควตา, 20K ส่วนเกิน, คิดเงิน $0.20 — request เดียวกันกับ reasoning-model ($0.03/1K) ได้ $0.60 (ตรรกะโควตาเดียวกัน แต่เรตต่างกัน)
การคิดบิลแพลน Premium: ลูกค้าส่ง 10K prompt token + 20K completion token สำหรับ reasoning-model (prompt $0.03/1K, completion $0.06/1K) ผลที่คาดหวัง: $0.30 + $1.20 = $1.50 ไม่มีโควตา ไม่มี overage — prompt และ completion คิดแยกกัน
รูปแบบ response: HTTP 201 คืน bill ID, customer ID, จำนวน token, timestamp, modelId และรายละเอียดการคิดเงินที่เหมาะกับแพลน

ถ้าฉากทัศน์เหล่านี้ผ่านทั้งหมด แปลว่าเราพิชิต story นี้ได้แล้ว

ขั้นที่ 3: generate analysis context

เมื่อ requirement และขอบเขตชัดเจนแล้ว เราใช้คำสั่ง /spdd-analysis โดยป้อน requirement ทางธุรกิจเข้าไป เพื่อสั่งให้ AI generate context การวิเคราะห์ที่ครอบคลุม

`/spdd-analysis` ทำงานอย่างไร

คำสั่งนี้ดึง domain keyword จาก requirement ทางธุรกิจ (เช่น “billing”, “quota”, “plan”) แล้วใช้มันสแกนเฉพาะส่วนของ codebase ที่เกี่ยวข้อง ไม่ใช่ทั้งหมด มันระบุแนวคิดที่มีอยู่เดิม แนวคิดใหม่ กฎทางธุรกิจหลัก และความเสี่ยงทางเทคนิค

ผลลัพธ์เป็นเอกสารที่อุดมไปด้วย context ครอบคลุมการรู้จำแนวคิดของ domain ทิศทางเชิงกลยุทธ์ และการวิเคราะห์ความเสี่ยง มันเป็น input สำหรับขั้นถัดไป คือการ generate REASONS Canvas

คำสั่ง:

/spdd-analysis @[User-story-1]Multi-Plan-Billing-Foundation-&-Model-Aware-Pricing.md

ชิ้นงานที่ได้: เอกสาร analysis context ตั้งต้น

คำสั่งนี้ผลิตการวิเคราะห์ระดับกลยุทธ์ที่ตั้งอยู่บนการสำรวจ codebase จริง ผลลัพธ์มุ่งไปที่ “อะไร” และ “ทำไม” ทั้งหมด โดยตั้งใจหลีกเลี่ยงรายละเอียดการ implement แบบละเอียดในขั้นนี้ โดยทั่วไปจะครอบคลุม:

แนวคิดของ domain: ของเดิมเทียบกับของใหม่, ความสัมพันธ์, กฎทางธุรกิจ
แนวทางเชิงกลยุทธ์: ทิศทางการแก้ปัญหา, การตัดสินใจด้านการออกแบบ, trade-off
ความเสี่ยงและช่องโหว่: ความกำกวม, กรณีขอบ, ความเสี่ยงทางเทคนิค, ความครอบคลุมของ acceptance criteria

รีวิวและขัดเกลา analysis context — เราใช้ความเข้าใจ requirement ทางธุรกิจของเราเองมารีวิวเอกสารที่ generate ออกมา โดยโฟกัสที่จุดที่ทักษะ alignment เน้นย้ำ การรีวิวนี้มีสองจุดประสงค์ คือยืนยันว่าความเข้าใจของเราตรงกับการตีความของ AI และค้นพบกรณีขอบหรือฉากทัศน์ที่ AI อาจเผยให้เห็นทั้งที่เราคิดไม่ถึง ในกรณีนี้ การรีวิวโฟกัสที่หลายจุดสำคัญ:

Strategy Pattern ถูกพิจารณาอย่างเหมาะสมหรือไม่
การยึดตามหลัก OOP ที่ระบบเดิมวางไว้ โดยเฉพาะ ISP และ SRP
ความสมเหตุสมผลของกลยุทธ์ที่เสนอสำหรับการเพิ่ม field ใหม่
ระบุกรณีขอบที่ก่อนหน้านี้คาดไม่ถึง
เปิดเผยความเสี่ยงทางเทคนิคที่อาจเกิดขึ้น

เมื่อรีวิวเสร็จ การวิเคราะห์ของ AI ส่วนใหญ่ตรงกับเจตนาเชิงสถาปัตยกรรมของเรา ที่จริงในบางจุดข้อพิจารณาของมันครอบคลุมยิ่งกว่าของเราเสียอีก

📷 ภาพ 4 — รีวิว analysis context ของ Step 3: กรณีขอบและความเสี่ยงที่ดึงมาจากเอกสาร analysis · ดูภาพหน้าจอต้นฉบับ ↗

พูดกันตามตรง ในขั้นนี้เรามีเพียงการจัดแนวเชิงแนวคิดระดับสูงเท่านั้น แม้เราจะนึกภาพการ implement ออกอย่างรวดเร็วในส่วนที่เรามีประสบการณ์มาก่อน แต่เรายังไม่สามารถวางรายละเอียดเชิงเทคนิคแบบละเอียดทั้งหมดของส่วนที่ไม่คุ้นเคยได้ในตอนนี้

อย่างไรก็ตาม นั่นไม่เป็นไรเลย ทิศทางโดยรวมจัดแนวกันแล้ว เราเดินหน้าไปสู่ขั้นถัดไปได้ คือสังเกตว่า AI “จำลอง” รายละเอียดการ implement ที่เป็นรูปธรรมภายในกรอบและ context ที่เราตั้งไว้อย่างไร

เมื่อมีรายละเอียดที่จับต้องได้เหล่านี้แล้ว เราจึงค้นพบปัญหาที่ลึกและซ่อนอยู่ และตัดสินใจ trade-off บนสถานการณ์จริงได้ — รับเอาแนวทางที่ประโยชน์มากกว่าข้อเสีย และทิ้งส่วนที่เหลือ

การตัดสินใจ: ยอมรับการวิเคราะห์ตามที่เป็นและเดินหน้าต่อ

ขั้นที่ 4: generate structured prompt

`/spdd-reasons-canvas` ทำงานอย่างไร

คำสั่งนี้อ่าน context ทางธุรกิจ (ผลลัพธ์ของ /spdd-analysis หรือคำอธิบาย requirement โดยตรง) แล้วผสมกับสถานะปัจจุบันของ codebase จากนั้น generate specification ด้านการออกแบบครบทั้งเจ็ดมิติของ REASONS — ตั้งแต่ “ทำไมเราถึงทำสิ่งนี้” ไปจนถึง “อะไรที่เราต้องไม่ทำ”

ผลลัพธ์เป็นพิมพ์เขียวที่รันได้ (executable blueprint) ส่วน Operations แม่นยำลงไปถึง method signature, ชนิดของ parameter และลำดับขั้นการทำงาน

คำสั่ง:

/spdd-reasons-canvas @GGQPA-001-202603191100-[Analysis]-multi-plan-billing-model-aware-pricing.md

ชิ้นงานที่ได้: structured prompt ตั้งต้น

มาถึงจุดนี้ เราผ่านกลยุทธ์ระดับสูงในเฟส analysis มาแล้ว ดังนั้นเวลารีวิว structured prompt เราจึงไม่ได้เริ่มจากศูนย์ แต่กำลังพิจารณาว่า AI แปลความเข้าใจร่วมของเราไปสู่โครงสร้าง REASONS Canvas ได้อย่างไร ตั้งแต่กลยุทธ์ ไปสู่นามธรรม ไปสู่รายละเอียดที่เป็นรูปธรรม

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

นี่คือการจัดแนวเจตนาในระดับที่ลึกขึ้น — ทำให้แน่ใจว่าก่อนจะ generate code ใด ๆ AI ได้ “จำลอง” ทั้งทางแก้ปัญหาภายในกรอบที่เรานิยามไว้แล้วอย่างได้ผล เราได้รีวิวจากมุมมองภาพรวม แทนที่จะหลงอยู่กับรายละเอียดตั้งแต่ต้น

ถ้า structured prompt ต้องแก้ไขล่ะ?

เราไม่เคยแก้ file structured prompt ด้วยมือ แต่จะคงบทสนทนาแบบวนซ้ำของ SPDD ไว้แทน:

ระบุช่องโหว่: มองหาองค์ประกอบที่ขาด (เช่น หลัก OO ที่หายไป หรือกฎทางธุรกิจที่เข้าใจผิด)
ป้อน prompt ใหม่: ป้อนเจตนาที่ขาดไปให้ AI โดยตรงผ่าน interface แบบสนทนา
AI อัปเดต file: AI ประมวลเจตนาใหม่ และขัดเกลาเฉพาะส่วนของ structured prompt ที่ต้องเปลี่ยน

เราจะเห็นตัวอย่างที่เป็นรูปธรรมทีละขั้นของ workflow “อัปเดต prompt ก่อน” นี้ในภายหลัง ตอนที่เราแก้ prompt เพื่อแก้ความไม่ตรงกันของตรรกะทางธุรกิจ ก่อนที่จะแตะ code ใด ๆ

โฟกัสการรีวิวที่จุดที่ทักษะ abstraction-first เน้นย้ำ ในกรณีนี้ context พื้นฐานนี้ฝังอยู่ใน codebase และ structured prompt ก่อนหน้าอยู่แล้ว ดังนั้นเมื่อ generate structured prompt สำหรับ iteration นี้ AI จึงคำนึงถึงแนวทางเชิงสถาปัตยกรรมและหลัก OO เหล่านี้โดยธรรมชาติ

ผลก็คือ แม้เนื้อหาที่ generate ออกมาจะซับซ้อนสูง แต่ก็มีปัญหาใหญ่อยู่น้อยอย่างน่าทึ่ง เราเลือกที่จะเดินหน้า generate code ด้วย structured prompt นี้ก่อน แล้วค่อยทำการรีวิวที่ลึกขึ้นภายหลังเพื่อหาความผิดปกติระดับ code

มาถึงตอนนี้ เราบรรลุฉันทามติอย่างหนักแน่นในระดับเจตนาแล้ว ทั้งปัญหาแกนกลางและเส้นทางการแก้ไข แม้อาจมีรายละเอียดตกหล่นเล็กน้อย แต่นั่นไม่ใช่เรื่องน่ากังวล การได้จัดแนวขอบเขตโดยรวมกับ AI ทำให้การปรับแต่งระดับท้องถิ่นควบคุมได้มาก ตอนนี้เราจึงเปลี่ยนเข้าสู่เฟสการ generate code

ขั้นที่ 5: generate code

ขั้นนี้มีรายละเอียดมากกว่า เพราะเรากำลัง generate code ของผลิตภัณฑ์ ทดสอบ และการรีวิวของเรามีผลลัพธ์ที่เป็นไปได้สองทาง

generate code ผลิตภัณฑ์ — เมื่อ structured prompt ของเรานิ่งแล้ว ก็ใช้มัน generate code ผลิตภัณฑ์

`/spdd-generate` ทำงานอย่างไร

คำสั่งนี้อ่าน REASONS Canvas แล้ว generate code ทีละ task ตามลำดับที่นิยามไว้ใน Operations มันยึดตาม coding standard ใน Norms และข้อจำกัดใน Safeguards อย่างเคร่งครัด — ไม่ด้นสด ไม่เพิ่ม feature เกินกว่าที่ spec นิยามไว้

หลักการแกนกลาง: prompt เก็บเจตนา ส่วน code คือการ implement เจตนานั้น code ที่ generate ต้องสอดคล้องแบบ 1:1 กับ specification นี้

คำสั่ง:

/spdd-generate @GGQPA-001-202603191105-[Feat]-multi-plan-billing-model-aware-pricing.md

ชิ้นงานที่ได้: code ที่ generate จาก structured prompt

ด้วยการอนุมานเชิงตรรกะหลายรอบที่เราทำไว้ก่อนหน้าด้วย structured prompt เราเข้าสู่การรีวิว code ด้วยโฟกัสและลำดับความสำคัญที่ชัดเจน:

สถาปัตยกรรม: code ทำตามสถาปัตยกรรม 3 ชั้น (3-tier) ที่เราคาดหวังอย่างเคร่งครัดหรือไม่
ตรรกะทางธุรกิจ: การ implement ในชั้น Service ตรงกับเจตนาตั้งต้นของเราอย่างสมบูรณ์หรือไม่
ขอบเขตของการเปลี่ยนแปลง: การแก้ไขถูกจำกัดอยู่ในขอบเขตที่ structured prompt นิยามไว้อย่างเคร่งครัดหรือไม่ มีการเปลี่ยนแปลงที่ไม่เกี่ยวข้องหรือ scope creep หรือเปล่า

ในกรณีนี้ ด้วย context ที่แม่นยำสูง code ที่ generate ออกมาส่วนใหญ่ตรงตามที่เราคาดหวัง ยกเว้น “magic number” ไม่กี่ตัว เราจะปรับมันออกเมื่อการตรวจสอบ function เสร็จสิ้น

ประเด็นสำคัญตรงนี้คือ: อย่ากังวลที่จะทำผิด และอย่าเครียดที่จับรายละเอียดได้ไม่ครบทุกจุดอย่างสมบูรณ์ในครั้งแรก ตราบใดที่เรายังวนซ้ำและเดินหน้าผ่าน workflow SPDD ต่อไป ก็ยังมีโอกาสแก้ทางอีกมาก code smell เล็กน้อยปล่อยไว้ก่อนได้ — เราตรวจสอบ function แกนกลางก่อน แล้วค่อยวนกลับมาปรับให้เหมาะสม

ตรวจสอบ feature — ระหว่างการตรวจสอบ feature workflow SPDD มีคำสั่ง /spdd-api-test สำหรับ generate script ทดสอบ function ³

`/spdd-api-test` ทำงานอย่างไร

คำสั่งนี้ดึงข้อมูล endpoint ของ API จากการ implement หรือจาก acceptance criteria แล้ว generate script ทดสอบที่ใช้ cURL script มีตารางสรุป test case แบบมีโครงสร้างครอบคลุมกรณีปกติ กรณีขอบ และกรณีผิดพลาด เมื่อรัน มันจะแสดงผลการเปรียบเทียบ “คาดหวังเทียบกับจริง”

คำสั่ง:

/spdd-api-test

ชิ้นงานที่ได้: script ทดสอบ API

ด้วยกฎที่นิยามไว้ในคำสั่ง AI จึง generate script ที่สร้างฉากทัศน์ทดสอบที่ต้องการด้วยคำสั่ง curl เราสามารถรีวิวฉากทัศน์ที่ AI generate ได้ในส่วน “TEST CASE OVERVIEW” ของ script

📷 ภาพ 5 — script ทดสอบ API ที่ generate ขึ้น: ฉากทัศน์ทดสอบที่ AI สร้างด้วยคำสั่ง curl · ดูภาพหน้าจอต้นฉบับ ↗

การรัน: เมื่อ generate script เสร็จแล้ว ก็รันมัน:

sh scripts/test-api.sh

ผลลัพธ์: การทดสอบ function ทั้งหมดผ่านเรียบร้อย

📷 ภาพ 6 — ผลการทดสอบ API: การทดสอบ function ทั้งหมดผ่าน · ดูภาพหน้าจอต้นฉบับ ↗

รีวิว code และปรับขั้นสุดท้าย — ด้วยการจัดแนวเจตนาอย่างเข้มงวดในขั้นแรก ๆ งานหนักก็เสร็จไปแล้ว ในขั้นนี้ ปัญหาที่เหลือมักเป็นความคลาดเคลื่อนของตรรกะเล็กน้อย หรือ code smell ระดับผิวเผิน

เพื่อรักษาความแม่นยำในวิธีปฏิบัติทางวิศวกรรม เราจัดประเภทการปรับขั้นสุดท้ายเหล่านี้ออกเป็นสองชนิดที่แตกต่างกัน โดยอิงว่ามันเปลี่ยนพฤติกรรมที่สังเกตได้ของระบบหรือไม่ และจัดการแต่ละชนิดด้วยกลยุทธ์ที่ต่างกันภายใน workflow SPDD

flowchart LR
  ev{"evaluate review"}
  ev -->|"logic correction"| up["update prompt"]
  up --> rg["regenerate code"]
  ev -->|"refactoring"| uc["update code"]
  uc --> sy["sync prompts"]

ภาพ 7 — สองทางตอบสนองต่อการเปลี่ยนแปลงจากการรีวิว code: ถ้าเป็น logic correction (เปลี่ยนพฤติกรรม) ให้แก้ prompt ก่อนแล้วค่อย regenerate code (prompt → code) ส่วนถ้าเป็น refactoring (ไม่เปลี่ยนพฤติกรรม) ให้แก้ code ก่อนแล้ว sync กลับเข้า prompt (code → prompt) · ดูภาพต้นฉบับ ↗

การแก้ตรรกะ (เปลี่ยนพฤติกรรม)

กลยุทธ์: แก้ prompt ก่อน แล้วค่อย generate code สำหรับประเด็นที่เกี่ยวกับกฎทางธุรกิจหรือตรรกะที่ไม่ตรงกัน (ซึ่งโดยเนื้อแท้เปลี่ยนพฤติกรรมที่สังเกตได้ของซอฟต์แวร์) ให้อัปเดต structured prompt เพื่อล็อกเจตนาที่ถูกต้องไว้ก่อนเสมอ ก่อนจะแตะ code นี่คือการอัปเดตหรือแก้ bug ไม่ใช่การ refactor

ยกตัวอย่าง ตอนเก็บ modelId ลงในบิล ปัจจุบันเราอนุญาตให้ field นี้เป็น nullable ได้ เหตุผลเบื้องหลังคือความจำเป็นต้องรองรับ backward compatibility กับข้อมูลย้อนหลัง ทำให้ทางแก้ชั่วคราวนี้เป็นการตัดสินใจเชิงสถาปัตยกรรมที่สมเหตุสมผล

อย่างไรก็ตาม ยังมีอีกทางเลือก ถ้าผู้มีส่วนได้ส่วนเสียทางธุรกิจยืนยันได้ว่าค่า modelId ควรเป็นอะไรก่อนการเปลี่ยนแปลงนี้ เราก็สามารถรวมพฤติกรรมของระบบให้เป็นหนึ่งเดียวและกำจัด technical debt ที่อาจเกิดขึ้นนี้ได้ สมมติว่าหลังยืนยันกับฝ่ายธุรกิจแล้ว modelId ของบิลย้อนหลังทั้งหมดควรตั้งเป็น fast-model

📷 ภาพ 8 — prompt ต้องอัปเดต: ด้วยเจตนาที่ชัดเจนนี้ เราจึงโต้ตอบกับ AI เพื่ออัปเดต structured prompt ก่อน · ดูภาพหน้าจอต้นฉบับ ↗

`/spdd-prompt-update` ทำงานอย่างไร

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

สิ่งนี้ต่างจาก /spdd-sync: sync ไหลจาก code ไปยัง spec เมื่อ code เปลี่ยน ส่วน prompt-update ไหลจาก requirement ไปยัง spec เมื่อ requirement เปลี่ยน

คำสั่ง:

/spdd-prompt-update @GGQPA-001-202603191105-[Feat]-multi-plan-billing-model-aware-pricing.md
model_id เป็น field ที่จำเป็น และค่า default คือ fast-model
อิงการตัดสินใจนี้ อัปเดตส่วนที่เกี่ยวข้องของ structured prompt

AI อัปเดต structured prompt ตามคำสั่งนี้

ชิ้นงานที่อัปเดต: structured prompt ที่อัปเดตแล้ว

เมื่อยืนยันแล้ว ใช้คำสั่ง /spdd-generate อัปเดต code ที่สอดคล้องตาม structured prompt ที่เพิ่งอัปเดต:

/spdd-generate @GGQPA-001-202603191105-[Feat]-multi-plan-billing-model-aware-pricing.md

AI ภายใต้กฎที่นิยามในคำสั่ง /spdd-generate เข้าใจการเปลี่ยนแปลงที่ต้องทำ และทำการอัปเดตแบบเจาะจงเฉพาะ codebase ที่ได้รับผลกระทบ

ชิ้นงานที่อัปเดต: code ที่อัปเดตแล้ว

สิ่งสำคัญที่ต้องสังเกตคือ เราไม่ได้ regenerate codebase ทั้งหมดใหม่ เรายังใช้ structured prompt เดิม และ AI จัดการ diff แบบเจาะจง:

ระบุจุดที่ไม่ตรงกัน: สังเกตว่าพฤติกรรมของ modelId ตอน persist ไม่สอดคล้องกับ requirement ทางธุรกิจใหม่ (ต้องบังคับและมีค่า default)
เล็งไปที่ snippet ของ prompt: คัดลอกส่วนที่นิยามตรรกะเก่าออกมาจาก structured prompt
อัปเดต prompt: วาง snippet ที่ดึงมาลงในแชตพร้อมกฎทางธุรกิจที่แก้ใหม่ สั่งให้ AI อัปเดต structured prompt ก่อน
generate การอัปเดต code แบบเจาะจง: เมื่อ prompt สะท้อนความจริงใหม่แล้ว รัน /spdd-generate ชี้ไปยัง file ที่อัปเดต AI ทำ diff แบบเจาะจงเฉพาะ codebase ที่ได้รับผลกระทบ แทนที่จะ regenerate ทุกอย่างใหม่จากศูนย์

Refactoring (code สะอาดและสไตล์)

“การเปลี่ยนแปลงที่ทำต่อโครงสร้างภายในของซอฟต์แวร์ เพื่อให้เข้าใจง่ายขึ้นและแก้ไขได้ถูกลง โดยไม่เปลี่ยนพฤติกรรมที่สังเกตได้ของมัน”

— Martin Fowler

กลยุทธ์: refactor code ก่อน แล้ว sync กลับเข้า prompt สำหรับประเด็นเชิงโครงสร้างหรือสไตล์ที่ไม่เปลี่ยนพฤติกรรมที่สังเกตได้ ให้สั่ง AI refactor code โดยตรง แล้วใช้คำสั่ง sync อัปเดตเอกสาร prompt

ยกตัวอย่าง class BillingServiceImpl ที่ AI generate มี magic number ที่ฮาร์ด code อยู่บางตัว ซึ่งต้องดึงออกมาเป็นค่าคงที่ (constant) ที่มีความหมาย

private int calculateRemainingQuota(String customerId, PricingPlan plan) {
    if (plan.getMonthlyQuota() == null || plan.getMonthlyQuota() == 0) {
        return 0;
    }

    LocalDate currentDate = LocalDate.now(ZoneOffset.UTC);
    LocalDateTime monthStart = currentDate.withDayOfMonth(1).atStartOfDay();
    LocalDateTime monthEnd = currentDate.plusMonths(1).withDayOfMonth(1).atStartOfDay();

    Integer currentMonthUsage = billRepository.sumIncludedTokensUsedForMonth(customerId, monthStart, monthEnd);
    return plan.getMonthlyQuota() - currentMonthUsage;
}

คำสั่งที่ 1:

@BillingServiceImpl.java ใน method calculateRemainingQuota
มี magic number บางตัวที่ต้องจัดการให้เป็นค่าคงที่

AI ทำการ refactor code ตามคำสั่งนี้ (จำกฎทองไว้: refactor เป็นก้าวเล็ก ๆ แบบเพิ่มทีละนิดเสมอ) ถ้าผลลัพธ์ตรงตามที่คาดหวัง เราใช้คำสั่ง /spdd-sync sync รายละเอียด code ที่เพิ่งอัปเดตเหล่านี้กลับไปยังตำแหน่งที่สอดคล้องกันภายใน structured prompt

คำสั่งที่ 2:

`/spdd-sync` ทำงานอย่างไร

คำสั่งนี้เปรียบเทียบ code ปัจจุบันกับ specification ใน Canvas แล้ว sync การเปลี่ยนแปลงฝั่ง code (refactor, แก้ bug, คอมโพเนนต์ใหม่) กลับเข้า Canvas

เป้าหมายคือคง Canvas ให้เป็นเอกสารการออกแบบที่ตรงกับ code ปัจจุบัน แทนที่จะเป็นบันทึกประวัติศาสตร์ที่ล้าสมัย

/spdd-sync

AI สรุปการเปลี่ยนแปลงตามกฎที่นิยามในคำสั่ง /spdd-sync แล้วทำตามข้อกำหนดเชิงโครงสร้างของ REASONS Canvas เพื่อเขียนรายละเอียดคำอธิบาย code ที่อัปเดตกลับเข้าไปในส่วนที่สอดคล้องกันของ structured prompt

เมื่อรันทั้งสองคำสั่งแล้ว เราจะเห็นการเปลี่ยนแปลงทั้งของ prompt และ code ได้ที่นี่

สำหรับ code smell ที่ลึกหรือซ่อนอยู่ ก็เพียงทำซ้ำขั้นตอนเหล่านี้ กฎทองคือคง structured prompt ให้ sync กับ codebase ล่าสุดของคุณเสมอ

Regression test — เมื่อปรับให้เหมาะสมเสร็จทั้งหมดแล้ว ให้ restart service และรัน script ทดสอบ API อีกครั้ง เพื่อให้แน่ใจว่าไม่มี function แกนกลางใดพังระหว่างการเก็บกวาด

ผลลัพธ์: ผ่านทั้งหมด

📷 ภาพ 9 — ผล regression test: ผ่านทั้งหมดหลังการเก็บกวาด · ดูภาพหน้าจอต้นฉบับ ↗

ขั้นที่ 6: generate unit test

การทดสอบ function เพียงอย่างเดียวไม่เพียงพอต่อการตรวจสอบที่หนักแน่น มันทำหน้าที่เป็นการตรวจเสริมเป็นหลัก และไม่ถูกนับเข้าใน code coverage การเซ็นรับรองขั้นสุดท้ายของตรรกะแกนกลางต้องอาศัย unit test ที่ครอบคลุม

ปัจจุบัน workflow SPDD ยังไม่มีคำสั่งทดสอบเฉพาะที่สรุปเสร็จสมบูรณ์ (จะมาในรอบพัฒนาถัดไป) เป็นทางออกชั่วคราว เราใช้แนวทางที่ขับเคลื่อนด้วย template (template-driven) generate structured prompt สำหรับ unit test

generate test prompt ตั้งต้น — เราเริ่มด้วยการผสมรายละเอียดการ implement เข้ากับ template ทดสอบมาตรฐานของเรา เพื่อ generate test prompt ฐาน

คำสั่ง:

อิงจาก prompt รายละเอียดการ implement
@GGQPA-001-202603191105-[Feat]-multi-plan-billing-model-aware-pricing.md
ผสมกับ template @TEST-SCENARIOS-TEMPLATE.md
ช่วย generate file test prompt ให้หน่อย

ตัดซ้ำและขัดเกลาฉากทัศน์ — หลัง generate structured test prompt ตั้งต้น ฉากทัศน์ทดสอบที่เสนอมาบางส่วนซ้ำกับที่เรามีอยู่แล้ว เพื่อแก้เรื่องนี้ เราสนทนาต่อ สั่งให้ AI เทียบ prompt ที่ generate กับ test suite ที่มีอยู่ ระบุฉากทัศน์ที่ใหม่จริง ๆ และเอาส่วนที่ซ้ำซ้อนออก

คำสั่ง:

@GGQPA-001-202603191105-[Test]-multi-plan-billing-model-aware-pricing.md
มี test ที่ซ้ำกับของเดิม เปรียบเทียบ test ที่เกี่ยวข้องที่มีอยู่
แล้วเพิ่มเฉพาะ test สำหรับฉากทัศน์ใหม่เท่านั้น

ชิ้นงานที่อัปเดต: structured prompt ของ test

generate code unit test — เมื่อฉากทัศน์ทดสอบที่ขัดเกลาแล้วถูกรีวิวและยืนยัน ก็ใช้ test prompt ฉบับสุดท้ายขับเคลื่อนการ generate code จริง

คำสั่ง:

อิงจาก test prompt ที่ generate
@GGQPA-001-202603191105-[Test]-multi-plan-billing-model-aware-pricing.md
ช่วย generate code unit test ที่สอดคล้องกัน

ผลลัพธ์: test ผ่านทั้งหมด commit ของ test

ตัวอย่างนี้ส่งมอบอะไรบ้าง

นี่คือบทสรุปของ workflow SPDD ที่ครบถ้วน ผ่านกระบวนการมาตรฐานนี้ เราส่งมอบผลลัพธ์สำคัญต่อไปนี้ได้สำเร็จ:

การ implement ตรรกะทางธุรกิจที่จัดแนวกับเจตนาได้สูงเป็นพิเศษ (~99%)
ความโปร่งใสทางวิศวกรรมที่ครบถ้วน รวมถึงความเข้าใจที่ชัดเจนในเส้นทางการ implement การตัดสินใจทางเทคนิค และ trade-off ที่ยอมรับ
สินทรัพย์ structured prompt ที่ sync แน่นกับ codebase ปัจจุบัน วางรากฐานที่มั่นคงสำหรับรอบพัฒนาในอนาคต
ความเชี่ยวชาญของคนที่ทบทวีคูณ ส่งเสริมการสะสมประสบการณ์และ model ความคิดของนักพัฒนาอย่างต่อเนื่อง ขณะที่เราวนทำงานร่วมกับ AI

ดู diff ของ code ทั้งหมดสำหรับการยกระดับนี้บน GitHub

เรายังเตรียม feature ยกระดับเป็นโบนัสไว้ด้วย — แพลน Enterprise คิดบิลแบบขั้นบันไดตามปริมาณ ถ้าคุณสนใจฝึกมือ เราขอแนะนำอย่างยิ่งให้ลองจัดการมันด้วย workflow SPDD ที่กล่าวถึงข้างต้น

ทักษะหลักสามอย่าง

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

Abstraction first — ออกแบบก่อน generate

ก่อน generate code ใด ๆ คุณต้องชัดเจนว่ามี object อะไรบ้าง มันทำงานร่วมกันอย่างไร และขอบเขตอยู่ตรงไหน

หากขาดสิ่งนี้ AI มักจะวิ่งไปกับรายละเอียดการ implement ในขณะที่โครงสร้างพังทลาย ความรับผิดชอบที่ไม่ชัด ตรรกะที่ซ้ำซ้อน interface ที่ไม่สอดคล้องกัน — และต้นทุนก็มาปรากฏทีหลังในการรีวิวและการทำงานซ้ำ อ่านเพิ่มเติม ↗

Alignment — ล็อกเจตนาก่อนเขียน code

ก่อนการ implement คุณต้องทำให้ “เราจะทำอะไร / เราจะไม่ทำอะไร” ชัดเจน และตกลงกันเรื่องมาตรฐานและข้อจำกัดเด็ดขาดล่วงหน้า มิฉะนั้นคุณจะลงเอยด้วยผลลัพธ์ที่ออกเร็วแต่ทำงานซ้ำช้า อ่านเพิ่มเติม ↗

Iterative Review — เปลี่ยนผลลัพธ์ให้เป็นวงรอบที่ควบคุมได้

คุณต้องการให้ความช่วยเหลือจาก AI ทำตัวเหมือนกระบวนการทางวิศวกรรม ไม่ใช่ร่างทีเดียวจบ

หากขาดวงรอบรีวิว-แล้ว-วนซ้ำที่มีวินัย ทีมจะลงเอยด้วยการบังคับให้ model ปะแก้ไปเรื่อย ๆ จนทางแก้เบนออกไป หรือไม่ก็เริ่มใหม่ซ้ำแล้วซ้ำเล่าจนคุมต้นทุนและเวลาไม่ได้ อ่านเพิ่มเติม ↗

SPDD เหมาะกับตรงไหน

การประเมินความเหมาะสม

SPDD เป็นการลงทุนทางวิศวกรรม ตารางด้านล่างให้คะแนนว่ามันคุ้มค่าแค่ไหนในแต่ละสถานการณ์ ตั้งแต่แนะนำอย่างยิ่ง (5 ดาว) ไปจนถึงไม่เหมาะสม (1 ดาว)

คะแนน	สถานการณ์	หมายเหตุ
★★★★★	การส่งมอบที่ขยายขนาดและเป็นมาตรฐาน	ตรรกะทางธุรกิจที่ซ้ำสูงและต้องดูแลรักษาระยะยาว (เช่น สร้าง API ที่คล้ายกันหลายตัว, ทำ workflow ธุรกิจหลักให้อัตโนมัติ)
★★★★★	ต้อง compliance สูงและมีข้อจำกัดเด็ดขาด	สภาพแวดล้อมที่ต้องทำตามกฎระเบียบ มาตรฐานความปลอดภัย หรือกฎสถาปัตยกรรมเข้มงวด (เช่น ระบบแกนกลางทางการเงิน, การ deploy หลายช่องทาง/หลาย client)
★★★★☆	การทำงานร่วมในทีมและการตรวจสอบย้อนกลับได้	การส่งมอบแบบหลายคนที่ต้องติดตามและรีวิวการเปลี่ยนแปลงได้แบบ end-to-end
★★★★☆	งานคงความสอดคล้องที่พาดข้ามหลายส่วน	การ refactor ซับซ้อนที่ตรรกะต้อง sync กันแน่นข้ามหลาย microservice หรือต่างภาษา
★★☆☆☆	hotfix ดับไฟ	การแก้ production แบบ “หยุดเลือดไหล” ที่ความเร็วสำคัญกว่าวินัยเชิงสถาปัตยกรรม
★★☆☆☆	spike เชิงสำรวจ	เมื่อเป้าหมายคือพิสูจน์ไอเดียเร็ว ๆ ไม่ใช่ส่งมอบซอฟต์แวร์คุณภาพ production ภาระการกำกับดูแลของ SPDD จะไม่คุ้ม
★★☆☆☆	script ใช้ครั้งเดียว	การล้างข้อมูลแบบใช้แล้วทิ้งหรือ script ชั่วคราว ที่ต้นทุนเริ่มต้นของ SPDD สูงเกินเทียบกับคุณค่า
★☆☆☆☆	หลุมดำของ context	เมื่อ domain นิยามได้แย่และกฎทางธุรกิจไม่ชัด คุณตั้งขอบเขตที่มีความหมายให้ model ไม่ได้
★☆☆☆☆	งานสร้างสรรค์/เชิงภาพล้วน ๆ	งานที่ขับเคลื่อนด้วยรสนิยมและความสวยงามมากกว่าตรรกะ (เช่น การสำรวจ UI เชิงภาพ, copywriting การตลาด)

Trade-off ที่ต้องชั่งน้ำหนัก

ผลตอบแทนจากการลงทุน (Return on investment)

ประโยชน์	ผลกระทบ	ความเร็ว	สิ่งที่ได้
Determinism	สูง	ทันที	เข้ารหัสตรรกะเป็น spec ที่แม่นยำ ลด hallucination และการตีความแบบ “สร้างสรรค์” ลงอย่างมาก
Traceability	สูง	ทันที	ทุกการเปลี่ยนแปลงที่มีนัยสำคัญย้อนกลับไปยัง structured prompt ได้ ปิดวงรอบการตรวจสอบ
รีวิวเร็วขึ้น	สูง	ระยะสั้น	code “มาถึง” ใกล้มาตรฐานทีมมากขึ้น การรีวิวจึงโฟกัสที่ตรรกะและการออกแบบ ไม่ใช่การจัดรูปแบบและเก็บกวาด
Explainability	ปานกลาง-สูง	ค่อยเป็นค่อยไป	เจตนาและพฤติกรรมมองเห็นได้ในระดับภาษาคน ลดภาระทางความคิดในการทำความเข้าใจและดูแลรักษา
วิวัฒน์อย่างปลอดภัยขึ้น	สูง	ระยะยาว	ขอบเขตที่นิยามชัดและการ implement แบบทีละขั้นทำให้การเปลี่ยนแปลงแบบเจาะจงเสี่ยงน้อยลงและวนปรับได้ง่ายขึ้น

การลงทุนเริ่มต้น (Upfront investment)

ด้าน	กำแพง	ลักษณะ	สิ่งที่ต้องใช้
การเปลี่ยน mindset	สูง	ต้องฝึกอย่างต่อเนื่อง	ทีมต้องปรับตัวสู่ “ออกแบบก่อน” แทน “เขียน code ก่อน”
ความเชี่ยวชาญระดับสูงตั้งแต่ต้น	ปานกลาง-สูง	ต่อ feature	วิศวกรที่แปลกฎทางธุรกิจให้เป็นนามธรรมที่สะอาดและข้อจำกัดด้านการออกแบบได้
เครื่องมือ automation	ปานกลาง	ตั้งค่า infrastructure	หากไม่มี automation SPDD จะชน throughput เพดานและคง prompt ให้สอดคล้องได้ยาก openspdd รัน workflow ในบทความนี้ — ตั้งแต่ analysis และ structured REASONS prompt ไปจนถึง code และการรองรับ test เสริม — เป็นขั้น CLI ที่ทำซ้ำได้ ชิ้นงานจึงมี version และรีวิวได้ แทนที่จะติดอยู่ในแชต องค์กรขนาดใหญ่อาจยังต้องวาง platform ความรู้ทับอีกชั้นเพื่อจัดการและใช้ซ้ำสินทรัพย์ในสเกลใหญ่

ยังมีต่อ: ทลายกำแพง “เฉพาะผู้เชี่ยวชาญ”

ด้วย trade-off ในวันนี้ SPDD อาจดูเหมือนเป็นวิธีการที่สงวนไว้สำหรับสถาปนิกอาวุโส เพราะมันตั้งมาตรฐานสูงด้านนามธรรมและการสร้าง model แต่นั่นไม่ใช่เป้าหมายปลายทางของเรา

เรากำลังพยายามลดกำแพงนั้นลง เพื่อจัดการคอขวดในการขยายขนาด เรากำลังสำรวจวิธีนำสินทรัพย์ SPDD ที่มีอยู่กลับมาใช้ซ้ำ และทำให้กฎทางธุรกิจที่ซับซ้อนและข้อจำกัดด้านการออกแบบ “เครื่องอ่านได้” และ “ฉลาด” มากขึ้น เพื่อให้นำไปใช้อย่างสอดคล้องได้โดยไม่ต้องพึ่งสัญชาตญาณของแต่ละคน

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

แนวทางเพิ่มเติมที่จะทำให้ SPDD นำไปใช้ได้ง่ายขึ้นกำลังตามมา

บทสรุป

ด้วยการใช้ REASONS Canvas, การทำเจตนาให้กระจ่าง, การวางนามธรรมที่ถูกต้อง, การแตกงานเป็น task ที่เป็นรูปธรรม และการล็อกขอบเขต เราได้มอบพื้นที่ที่นิยามชัดเจนให้ AI ทำงาน

ภายในพื้นที่นั้น SPDD อาจไม่ใช่เส้นทางที่สั้นที่สุดสู่ “generate code เร็ว ๆ” แต่มันเป็นหนึ่งในวิธีที่เชื่อถือได้มากที่สุดในการส่งมอบ “การเปลี่ยนแปลงที่ถูกต้อง” อย่างมั่นใจ

พูดกันตามตรง SPDD เปล่งประกายที่สุดใน domain ที่หนักด้านตรรกะ ส่วนในด้านที่ขับเคลื่อนด้วยการตัดสินเชิงสุนทรียะ — เช่น การจัดสไตล์ frontend — เรายังคงสำรวจ pattern ทางวิศวกรรมที่จะมั่นคงได้เท่ากับการสร้างเชิงตรรกะล้วน

กรอบในบทความนี้เป็นเพียง “ท่า” คุณค่าที่แท้จริงมาจากการลับ meta-skill ที่อยู่เบื้องหลัง ได้แก่ นามธรรมและการสร้าง model, การวิเคราะห์อย่างเป็นระบบ และความเข้าใจธุรกิจในภาพรวมอย่างลึกซึ้ง นี่คือจุดแข็งของมนุษย์ที่ท้ายที่สุดเป็นตัวกำหนดว่าเราจะได้คุณค่าจาก AI มากแค่ไหน

ในยุค AI การพัฒนาซอฟต์แวร์ไม่ใช่การประลอง IQ ของ model แต่เป็นการประลอง bandwidth ทางความคิดของวิศวกร — ว่าเราคิดได้ชัดเจน ตีกรอบปัญหา และตัดสินใจได้ดีเพียงใด

เราขอปิดท้ายด้วยคำพูดที่จับวิญญาณของ SPDD ไว้ได้:

“ในวิทยาศาสตร์ ถ้าคุณรู้ว่ากำลังทำอะไรอยู่ คุณก็ไม่ควรทำมัน ในวิศวกรรม ถ้าคุณไม่รู้ว่ากำลังทำอะไรอยู่ คุณก็ไม่ควรทำมัน”

— Richard W. Hamming

กิตติกรรมประกาศ

เราขอขอบคุณ Martin Fowler อย่างจริงใจ แม้ตารางงานจะรัดตัว เขาก็ทุ่มเทอย่างลึกซึ้งให้บทความนี้ ตั้งแต่การลับโครงเรื่อง การทำให้แนวคิดสำคัญกระจ่าง ไปจนถึงการยกระดับการเล่าเรื่องด้วยภาพด้วยไดอะแกรมที่ปรับปรุงและสร้างใหม่

สายตาที่เฉียบคมต่อรายละเอียดและความใส่ใจในความแม่นยำของเขาหล่อหลอมผลลัพธ์สุดท้ายอย่างลึกซึ้ง

เราขอบคุณอย่างยิ่งต่อ Eric (Ke) Zhou, Wei Sun, Sara Michelazzo, Rebecca Parsons, Matteo Vaccari, May (Ping) Xu, Zhi Wang, Feng Chen และ Da Cheng สำหรับคำวิจารณ์และข้อคิดที่ลึกซึ้ง ความเห็นของพวกคุณช่วยให้เราทำหลายแนวคิดสำคัญที่เป็นรากของวิธีการนี้ให้กระจ่างขึ้น

เราขอชื่นชมผู้ปฏิบัติยุคแรกด้วย: Jie Wang, Jian Gao, Yixuan Feng, Siyuan Li, Yixuan Li, Biao Tian, Wei Cheng, Qi Huang และ Yulong Li ขอบคุณที่พิสูจน์ SPDD ใน project จริง และสำหรับความอดทนขณะที่แนวทางค่อย ๆ สุกงอม feedback จากแนวหน้าของพวกคุณเป็นรากฐานสำคัญที่ทำให้ SPDD ใช้งานได้จริงและทนทาน

ท้ายสุด ในจิตวิญญาณของการลงมือทำตามที่เราสอน บทความนี้เองก็ถูกหล่อหลอมขึ้นด้วยความช่วยเหลือของ large language model — Claude 4.5 Sonnet, Claude 4.6 Opus, Gemini 3.1 Pro และ ChatGPT 5.4

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

ถาม-ตอบ

หลังเผยแพร่บทความนี้ เราได้รับคำถามมากมาย นี่คือคำตอบบางส่วน

ในเมื่อ rules, นิยาม workflow และ execution hook ก็กำกับผลลัพธ์ของ AI อยู่แล้ว SPDD เติมเต็มช่องว่างอะไรกันแน่ — การจับคู่ที่แน่นขึ้นระหว่าง prompt กับ code, การทำ version ที่กันการ drift ตามเวลา, หรือทั้งสองอย่าง?

ทั้งสองอย่าง และมันเสริมกัน global rule และ hook เป็นตาข่ายนิรภัยระดับสูงที่มีคุณค่า แต่ในงานวิศวกรรมประจำวัน มันอยู่ในระดับนามธรรมที่ทำให้ขั้น generate จริงยังทึบอยู่ นี่คือวิธีที่ SPDD เติมเต็มช่องว่างที่ guardrail ระดับสูงเพียงอย่างเดียวปิดไม่ได้:

ควบคุมเจตนาได้ละเอียดขึ้น กฎระดับสูงอธิบายกลยุทธ์และขอบเขตกว้าง ๆ แต่ปล่อยให้ code ที่ generate เป็นกล่องดำ SPDD ทำให้ขั้นตอนการแก้ปัญหาชัดเจนผ่าน REASONS Canvas — เจตนา, การออกแบบ, การลงมือทำ, การกำกับดูแล — ผู้รีวิวจึงใช้เหตุผลกับแผนได้ก่อน code และคนยังอยู่ในวงรอบในจุดที่สำคัญ
สินทรัพย์เจตนาที่ใช้ซ้ำได้ prompt แบบทำไปเรื่อยใช้ได้ครั้งเดียว SPDD เปลี่ยน structured prompt ให้เป็นชิ้นงานที่ควบคุม version และเดินทางไปพร้อม code เก็บเจตนาทางธุรกิจ การตัดสินใจด้านการออกแบบ และข้อจำกัด นั่นคือสิ่งที่ปิดวงรอบระหว่าง prompt กับ code ตามเวลา และกัน drift ช้า ๆ ที่เกิดขึ้นเมื่อดูแลแต่ code เพียงอย่างเดียว
กรอบสำหรับการเรียนรู้ของมนุษย์ ถ้าเราปล่อยให้ model ผลิต code โดยไม่กำกับ ทักษะการสร้าง model และนามธรรมของเราเองจะอ่อนลงตามเวลา SPDD บังคับให้นักพัฒนาใช้เหตุผลกับปัญหาเคียงข้างเครื่องมือ ความรู้ของ domain และวิจารณญาณการออกแบบจึงทบทวีข้ามรอบ แทนที่จะสูญไปหลังจบแต่ละแชต

สิ่งนี้ต่างจากชุดคำสั่ง (instruction set) แบบดั้งเดิมที่วางไว้ใน project/โซลูชันด้วย progressive disclosure (การเปิดเผยข้อมูลทีละขั้น) อย่างไร?

ความต่างแกนกลางคือ SPDD ปฏิบัติต่อ structured prompt ในฐานะ file ที่ถูกดูแลและควบคุม version:

โครงสร้างตายตัว แทนกฎ free-text แทนที่จะป้อนคำสั่งปลายเปิดให้ model เราใช้ REASONS Canvas — template เจ็ดส่วนตายตัวครอบคลุมเจตนา การออกแบบ การลงมือทำ และการกำกับดูแล AI ต้องวางแผนภายในรูปทรงนั้น ทำให้แผนอ่านและรีวิวได้อย่างสอดคล้องกันทั้งทีม
เจตนาก่อน code คำสั่งทำให้ requirement, domain และแนวทางกระจ่างก่อน generate อะไร — ย้ายความไม่แน่นอนไปทางซ้าย ข้อขัดแย้งถูกแก้ในระดับ prompt ที่แก้ได้ถูก แทนที่จะโผล่มาทีหลังใน code
แตกงานผ่าน Operations มิติ O — Operations ของ Canvas แตกกลยุทธ์นามธรรมเป็นขั้น implement ที่เป็นรูปธรรมและทดสอบได้ ลงไปถึง method signature และลำดับการทำงาน ผู้รีวิวตรวจขั้นเหล่านี้ก่อนเขียน code ใด ๆ การ generate จึงเป็นการแปลแผนที่ตกลงกันแล้วอย่างซื่อตรง
sync สองทาง ไม่ใช่ส่งต่อแล้วจบ instruction และเอกสารออกแบบใน project แบบดั้งเดิมล้าสมัยทันทีที่ code เดินหน้า ใน SPDD prompt และ code ผูกกัน: เมื่อกฎธุรกิจเปลี่ยน /spdd-prompt-update ไหล requirement → prompt → code เมื่อ code ถูก refactor /spdd-sync ไหล code → prompt spec จึงเป็นบันทึกที่ตรงกับระบบปัจจุบัน ไม่ใช่ภาพถ่ายในอดีต

มนุษย์สร้าง “ทำไม” เบื้องหลังการตัดสินใจผ่านการพูดคุยและ context ที่สะสม ไม่ใช่แค่ code สุดท้าย SPDD ปิดวงรอบนั้นด้วยการเรียนรู้อัตโนมัติ หรือ “ทำไม” ยังถูกแบกโดยมนุษย์?

ขึ้นอยู่กับว่าเราหมายถึงอะไรด้วยคำว่า “ปิดวงรอบ” ถ้าคำถามคือ SPDD มีวงรอบการเรียนรู้แบบปิดของ AI ไหม — ที่ทุกแชตสอน model เงียบ ๆ และระบบฉลาดขึ้นเองหรือไม่ — คำตอบตรง ๆ คือยัง และเราตั้งใจเช่นนั้น openspdd รันเป็นกรอบกึ่งอัตโนมัติที่นำโดยมนุษย์ และมนุษย์ยังเป็นผู้เฝ้าประตูสำหรับการตัดสินใจหลักทั้งหมด

แต่ตัว “ทำไม” เองไม่ได้ติดอยู่ในหัวมนุษย์หรือกระจัดกระจายในบทแชต มันถูกเก็บไว้ใน structured prompt ในฐานะชิ้นงานชั้นหนึ่ง:

Canvas เข้ารหัสเหตุผล R (Requirements พร้อม DoD), A (Approach) และ context การวิเคราะห์ใน Step 3 บันทึกชัดว่าเรากำลังแก้อะไร ทำไม และยอมรับ trade-off ไหน — ไม่ใช่แค่ “สร้างอะไร”
version control ทำให้คงทน เพราะ prompt ถูก commit คู่กับ code “ทำไม” จึงเดินทางไปกับระบบข้ามคนและเวลา แทนที่จะหายไปเมื่อปิดหน้าต่างแชตหรือนักพัฒนาออกจากทีม
sync สองทางทำให้ทันสมัย /spdd-prompt-update ไหล requirement → prompt → code เมื่อเจตนาเปลี่ยน /spdd-sync ไหล code → prompt เมื่อการ implement เปลี่ยน ชิ้นงานจึงเป็นบันทึกที่ตรงกับระบบปัจจุบัน ไม่ใช่ภาพถ่ายในอดีต
แต่ละ iteration เริ่มจากสินทรัพย์ที่สะสม การพัฒนาต่อยอดครั้งถัดไปเริ่มด้วย Canvas ที่มีอยู่เป็น context ความรู้ของ domain และการตัดสินใจด้านการออกแบบจึงทบทวีคูณ แทนที่จะถูกค้นพบใหม่ทุกรอบ

ดังนั้น วงรอบถูกปิดด้วย workflow และตัวชิ้นงาน ไม่ใช่ด้วยกลไกการเรียนรู้อัตโนมัติ ผู้รีวิวขยับจาก “จับ bug” สู่ “ตรวจเจตนา” เพราะตอนนี้เจตนาอยู่ในที่ที่ตรวจสอบได้

นี่คือ design ที่นำโดยมนุษย์โดยตั้งใจ และเราคิดว่ามันถูกต้องสำหรับตอนนี้ — จนกว่าการตรวจสอบอัตโนมัติในชั้นสินทรัพย์จะสุกงอมพอจะรับภาระมากขึ้น

ถ้านักพัฒนาสองคนเขียน Canvas เดียวกันแล้วได้ spec ต่างกัน — และไม่มีนิยามที่เป็นทางการของคำว่า “ดี” — SPDD ก็แค่ดันปัญหาความแปรปรวนขึ้นไปอีกชั้น แทนที่จะแก้มันไม่ใช่หรือ?

พูดตรง ๆ นั่นเป็นการอธิบายจุดที่เราอยู่วันนี้ได้อย่างเป็นธรรม Canvas บีบแถบความแปรปรวนให้แคบลงเมื่อเทียบกับ prompt แบบอิสระ แต่ไม่ได้กำจัดมัน

นักพัฒนาสองคนที่เขียนต่อ requirement เดียวกันยังผลิต Canvas ที่ต่างกันได้ และนักพัฒนาคนเดิมก็อาจผลิตอันที่บางกว่าในวันอื่น เรายังไม่มีมาตรฐานที่ตกผลึกและเป็นภววิสัยว่า Canvas ที่ “ดี” หน้าตาเป็นอย่างไร

สิ่งที่กรอบนี้พึ่งตอนนี้คือชุดเกณฑ์พื้นฐาน — โครงสร้าง, ความละเอียด (granularity), ระดับนามธรรม และการแตกงาน — ที่ถูกเข้ารหัสไว้ในคำสั่ง openspdd

แต่ละคำสั่งเข้ารหัสกลยุทธ์การคิดที่ดึงผลลัพธ์ไปสู่รูปทรงที่สอดคล้องกัน ยกพื้นให้ผู้ปฏิบัติที่ประสบการณ์น้อย และให้ผู้รีวิวมีสิ่งตายตัวให้ตอบสนอง นั่นคือการลดความแปรปรวนที่มีนัยสำคัญ แต่ไม่เหมือนกับการตรวจอัตโนมัติจากภายนอก

การปิดช่องว่างที่เหลือนั้นคือทิศทางต่อไปของการกำกับดูแล: การตรวจสอบอัตโนมัติในชั้นสินทรัพย์ (analysis, Canvas, ชิ้นงาน prompt) เพื่อให้กรอบเองจับกรณีที่ Canvas ครบโครงสร้างแต่ระบุรายละเอียดไม่พอในเชิงเนื้อหา จนกว่าจะมีสิ่งนั้น คำตอบที่ซื่อตรงคือวิจารณญาณของมนุษย์ยังเป็นตัวรับน้ำหนัก

SPDD ทนทานแค่ไหนเมื่อขยายข้ามงานหลาย project หลายสาขาวิชา หลาย domain — และเพดานที่แท้จริงอยู่ตรงไหน: ที่ความสามารถของ AI หรือที่ว่าตัวปัญหาเองตีกรอบได้สะอาดแค่ไหน?

ขีดจำกัดส่วนใหญ่อยู่ที่ฝั่งปัญหา ไม่ใช่ฝั่ง model แม้มี model ที่แข็งแกร่งกว่าหรือวงรอบการเรียนรู้ที่ดีกว่า เราก็ไม่แนะนำให้ยกขอบเขตขนาดมหึมาที่ข้ามหลาย project-หลาย domain ให้ AI ในครั้งเดียว

สิ่งที่สำคัญกว่าคือปัญหาถูกตีกรอบชัดแค่ไหน และทีมสะสม context ไว้มากเท่าไร ความสามารถดิบของ model แทบไม่เคยเป็นคอขวด ด้วยเหตุผลสามข้อ:

ต้องแตกย่อย ขอบเขตที่ใหญ่หรือข้าม domain ควรถูกแตกเป็นหน่วยเล็ก ๆ ที่อยู่ในตัวเอง ซึ่งสร้าง model ได้แม่นทีละหน่วย หากขาดวินัยนี้ แม้ model ที่แข็งแกร่งก็เสียความสอดคล้องเมื่อขอบเขตกว้างขึ้น
ขอบเขตที่ไม่ชัดจำกัดอัตราความสำเร็จ ใน “หลุมดำของ context” — domain ที่กฎธุรกิจไม่ชัดและขอบเขตอ่อนแอ — อัตราความสำเร็จของ SPDD ตกลง เพราะ model ไม่มีอะไรที่มีความหมายมาคอยจำกัดมัน AI ที่ทรงพลังกว่าไม่ได้แก้เรื่องนี้ มันแค่ล้มเหลวอย่างมั่นใจกว่าเดิม
สินทรัพย์การตัดสินใจช่วยตามเวลา งานสเกล portfolio แบบ end-to-end ไม่ใช่สิ่งที่เราจะยกให้ทำเองโดยอัตโนมัติวันนี้ มันจะเปลี่ยนไปเมื่อ “สินทรัพย์การตัดสินใจ” — context ในอดีต, ทางเลือกสถาปัตยกรรม, pattern เชิงบรรทัดฐาน — สะสมมากพอจะยกอัตราความสำเร็จขึ้นถึงระดับที่ยอมรับได้ จนกว่าจะถึงตอนนั้น แนวทางที่นำโดยมนุษย์ทีละหน่วยคือค่าเริ่มต้น

SPDD เป็น model-agnostic ไหม? prompt ที่สะสมไว้ทำงานเทียบเท่ากันข้าม Claude, GPT และ Gemini หรือไม่ หรือการเปลี่ยน model ระหว่าง iteration — สลับผู้ให้บริการ, ออฟไลน์-เครื่องเองเทียบกับออนไลน์-ระยะไกล, หรือผู้ให้บริการอัปเดตจนเปลี่ยนพฤติกรรมการให้เหตุผล — จะทำให้ prompt drift หรือ code เบนได้? ชิ้นงานที่แท้จริงคือ prompt-as-spec หรือ prompt + การตั้งค่า model?

SPDD ตั้งใจให้เป็น model-agnostic และเราใช้มันข้ามรุ่น model มาตั้งแต่ยุค Claude 3.5 Sonnet workflow ไม่ขึ้นกับ model ตัวใดตัวหนึ่ง อย่างไรก็ตาม ความสามารถดิบยังสำคัญ: model ที่ให้เหตุผลแข็งแกร่งกว่าก็ผลิต canvas ที่ดีกว่า

จากประสบการณ์ลงมือ สำหรับขั้น analysis และ generate REASONS Canvas ที่เป็นงานหนัก Claude (โดยเฉพาะ Opus) มักนำ ตามด้วย GPT Codex และ Gemini 3.x Pro

แต่เมื่อล็อกเจตนาไว้ใน structured prompt แล้ว เฟสถัดไปเป็นการทำตามคำสั่งเป็นส่วนใหญ่ การสลับไปใช้ model ที่เก่งน้อยกว่าเล็กน้อยจึงมีความเสี่ยงเจตนา drift ที่จัดการได้ มองแบบนี้ ชิ้นงานคือ spec ส่วน model คือผู้ลงมือทำตาม spec นั้น

เรื่องออฟไลน์-เครื่องเองเทียบกับออนไลน์-ระยะไกล: วันนี้เราไม่แนะนำ LLM แบบออฟไลน์-เครื่องเองสำหรับ SPDD model เล็กที่ใส่ลงฮาร์ดแวร์เครื่องเองได้ยังขาดความสามารถที่จำเป็นสำหรับขั้น analysis และ generate canvas และการ deploy model ใหญ่ที่เก่งพอบนเครื่องเองก็แทบไม่คุ้มค่า

ดังนั้น SPDD ไม่รับประกัน determinism สัมบูรณ์ และเราไม่ได้อ้างเช่นนั้น สิ่งที่มันทำคือคงความสุ่มจาก non-determinism ของ LLM ไว้ในขอบเขตที่ควบคุมได้

ส่วนคุณจะมองชิ้นงานเป็น prompt-as-spec หรือ prompt + การตั้งค่า model เป็นการตัดสินใจเชิงกลยุทธ์ที่ผูกกับข้อจำกัดด้านต้นทุน compute และ compliance ของคุณ — และทีมควรตัดสินใจอย่างมีสติ

เมื่อความสามารถของ LLM ก้าวหน้าขึ้น ตัววิธีการ SPDD เปลี่ยนไปด้วยหรือไม่ หรือเปลี่ยนแค่ความเป็นไปได้ในทางปฏิบัติที่จะนำมันไปใช้?

วิธีการไม่ได้เปลี่ยนในเชิงพื้นฐาน วงรอบแกนกลางยังเหมือนเดิม: ยึดทุกอย่างไว้ที่ structured prompt และใช้มันค่อย ๆ ทำเจตนาให้กระจ่างขึ้น

สิ่งที่เปลี่ยนคือเราโอนภาระงานด้วยมือไปให้เครื่องมือที่ทำซ้ำได้บน LLM ได้มากแค่ไหน

เมื่อ model ทำตาม structured prompt และให้เหตุผลกับ context ที่อุดมขึ้นได้ดีขึ้น เราก็กลั่นแต่ละขั้นของ workflow ให้เป็นกลยุทธ์การคิดที่นำกลับมาใช้ซ้ำได้ — คำสั่งอย่าง /spdd-analysis, /spdd-reasons-canvas, /spdd-generate และ /spdd-sync สามสิ่งเกิดขึ้นจากตรงนั้น:

จากขับเคลื่อนด้วย template สู่ขับเคลื่อนด้วยกลยุทธ์ ช่วงแรก SPDD พึ่ง template โซลูชันอย่างหนัก หากไม่มี template ที่สรุปมาดีตั้งแต่ต้น คุณภาพผลลัพธ์ก็ตก ทำให้เริ่มใน domain ใหม่ได้ยาก ตอนนี้แต่ละคำสั่งเข้ารหัสตัวกลยุทธ์การคิดเอง แม้ไม่มี template LLM ก็ทำตามกลยุทธ์ผลิตร่างแรกที่สมเหตุสมผลได้ เราขัดเกลาต่อจากนั้น และเมื่อเคสมากพอผ่านกลยุทธ์เดียวกัน template ก็ปรากฏเป็นผลพลอยได้ — สินทรัพย์จึงถูกสร้างขึ้นด้วยการใช้งาน แทนที่จะเป็นเงื่อนไขก่อนเริ่มงาน
automation สูงขึ้น ขั้นที่เคยขับด้วยมือด้วย prompt ทำไปเรื่อย ตอนนี้เรียกใช้เป็นคำสั่ง workflow จึงรันโดยต้องประคองน้อยลงมาก
ผลลัพธ์เสถียรขึ้น เพราะแต่ละคำสั่งเข้ารหัสกลยุทธ์การคิดเดียวกันทุกครั้ง ชิ้นงานที่มันผลิต — analysis, REASONS Canvas, code ที่ generate — จึงสอดคล้องกันมากขึ้นจากรอบสู่รอบ และกำกับดูแลกับรีวิวได้ง่ายขึ้น

ในฐานะ “ผู้นำ” ที่เป็นมนุษย์ คุณตัดสินอย่างไรว่าเมื่อไรต้องทำ prompt engineering เพิ่มในขอบเขต portfolio เดียวกัน?

ผมพึ่งตัวกระตุ้นที่เป็นรูปธรรมสามอย่าง ซึ่ง map ตรงกับขั้นรีวิวใน workflow SPDD:

พฤติกรรมไม่ตรงกัน ระหว่างการทดสอบ function (มักด้วย /spdd-api-test) ผมโฟกัสที่พฤติกรรมระบบมากกว่ารายละเอียดการ implement ถ้าผลลัพธ์เบนจาก acceptance criteria ที่นิยามไว้ นั่นเป็นสัญญาณว่า prompt ยังจับเจตนาได้ไม่แม่นพอ — เคสแก้ตรรกะคลาสสิกที่เราอัปเดต prompt ก่อน แล้วค่อยอัปเดต code
ตรรกะซับซ้อนเกินเหตุ เมื่อรีวิว code สำคัญ ถ้า AI สร้างทางแก้ที่วิจิตรเกินกว่าที่ปัญหาควรเป็น มักเป็นเพราะส่วน Approach หรือ Operations ของ prompt ระบุไม่พอ การรัดข้อจำกัดเหล่านั้นให้แน่นมักทำให้การ generate รอบถัดไปเรียบง่ายลง
ทำตามคำสั่งไม่สำเร็จ เมื่อ AI ไม่ทำตามคำสั่งชัด ๆ หรือละเมิด Norm หรือ Safeguard จาก canvas ผมถือเป็นสัญญาณว่าต้องทำข้อจำกัดนั้นให้เด่นหรือชัดเจนขึ้นใน prompt เอง แทนที่จะสู้ศึกเดิมซ้ำในแชต

ทำไม workflow ของ SPDD มีหกขั้น แทนที่จะเป็น pattern วางแผน-แล้ว-เขียน code ที่ง่ายกว่า? ยืนยันเจตนาครั้งเดียวในการรีวิวเดียวหลัง generate แผนไม่ได้หรือ?

คำตอบสั้น ๆ คือภาระทางความคิด (cognitive load) การยืนยันเจตนาต้องกระจายไปตลอด workflow เพราะการอัดมันเป็นการรีวิวเดียวหลัง generate แผนวางของมากเกินไปต่อหน้าผู้รีวิวในคราวเดียว

ในทางปฏิบัติ คนคงสมาธิระดับนั้นไม่ไหว — พวกเขากวาดตา เลื่อนไว้ทีหลัง หรืออนุมัติตามค่าเริ่มต้น และเจตนา drift ก็เลี่ยงไม่ได้ แม้ทุกอย่างจะดูถูกต้องบนกระดาษ

หกขั้นมีอยู่เพื่อให้แต่ละจุดตรวจเล็กพอที่จะมีส่วนร่วมกับมันได้จริง:

Step 1 หล่อไอเดียดิบให้เป็น user story (อาจมี AI ช่วย) และ Step 2 คือจุดที่มนุษย์รีวิวและทำให้กระจ่างว่า story นั้นหมายความว่าอย่างไรในเชิงธุรกิจ — ยึดที่ปัญหาที่ถูกต้องก่อนงานออกแบบใด ๆ จะเริ่ม
Step 3 ยืนยันความเข้าใจ domain ความเสี่ยง และทิศทางเชิงกลยุทธ์ — “ทำไม” และ “อะไร”
Step 4 ยืนยัน structured prompt — การออกแบบและ operation — หลังจากตกลงเรื่อง analysis แล้วเท่านั้น
Step 5 ยืนยันพฤติกรรมและ code หลังล็อกเจตนาแล้วเท่านั้น
Step 6 generate unit test เป็นลำดับสุดท้าย เมื่อการ implement เสถียรแล้ว

พอถึงเวลาที่ผู้รีวิวมอง code requirement, domain model และการออกแบบก็ถูกเซ็นรับรองไปแล้ว ความสนใจจึงไปอยู่กับการตัดสินใจที่สำคัญในขั้นนั้น ประเด็นไม่ใช่ขั้นที่มากขึ้นเพื่อตัวมันเอง แต่คือการตัดสินใจที่แคบลงต่อขั้น เพื่อให้มนุษย์อยู่ในวงรอบได้

SPDD รัน API test ก่อนรีวิว code แต่ unit test ทีหลัง — แทบจะกลับด้านกับ TDD ทำไมจึงเรียงลำดับแบบนั้น?

การเรียงลำดับนี้ตั้งใจ TDD แบบคลาสสิกใช้ test เพื่อทำให้พฤติกรรมกระจ่าง ป้องกัน regression และหล่อหลอมการออกแบบผ่าน feedback ที่เร็ว SPDD ยังต้องการผลลัพธ์ทั้งสามอย่าง — เพียงกระจายมันต่างกันไปทั่ว workflow:

API test มาก่อนเพราะ code ที่ generate มีต้นทุนต่ำ การรีวิว code อย่างลึกที่อาจไม่ตอบโจทย์พฤติกรรมทางธุรกิจที่ตั้งใจไว้ด้วยซ้ำนั้นมีคุณค่าน้อย /spdd-api-test ตรวจ “อะไร” ที่ขอบระบบอย่างรวดเร็ว เราจึงรู้ว่ากำลังรีวิวสิ่งที่ทำงานได้จริง ก่อนลงแรงรีวิวด้วยมนุษย์
การรีวิว code จึงโฟกัสที่สิ่งที่มีแต่มนุษย์ตัดสินได้ เมื่อ API test ผ่าน การรีวิวก็เพ่งไปที่ตรรกะ สถาปัตยกรรม trade-off และข้อกังวลเชิงไม่เป็น function — ไม่ใช่ว่าพฤติกรรมพื้นฐานถูกหรือไม่
unit test มาสุดท้ายเป็นตาข่ายนิรภัยกัน regression พอถึง unit test เจตนาถูกทำให้ชัดผ่าน structured prompt แล้ว และการ implement ก็เสถียรขึ้นผ่านการตรวจ API และการรีวิว การ generate unit test ตอนนี้จึงเลี่ยงการเขียนใหม่หลังการเปลี่ยนแปลงใหญ่ที่ขับด้วยการรีวิว

ดังนั้น test ไม่ได้สำคัญน้อยลงใน SPDD สิ่งที่เปลี่ยนคือเจตนาถูกทำให้ชัดเร็วขึ้น — ผ่าน structured prompt — และ test ถูกนำมาใช้ในขั้นที่มันสร้างแรงงัดได้มากที่สุด

ถ้า hotfix ถูกจัดว่าเข้ากันได้แย่กับ SPDD feedback ที่สัญญาณแรงที่สุดจาก production — bug กรณีขอบ และโหมดความล้มเหลวที่จุดชนวนการแก้ — ก็จะข้าม spec ไปถาวรและไม่เคยกลับเข้าสู่วิธีการไม่ใช่หรือ?

มันจะเป็นเช่นนั้น ถ้า workflow หยุดที่การแก้ คะแนน 1 ดาวในตารางความเหมาะสมพูดถึงความเข้ากันตอนต้นระหว่างเหตุการณ์เอง: ระหว่าง production incident ที่กำลังเกิด การกู้ระบบต้องมาก่อน และการหยุดเขียน Canvas เป็นการตัดสินใจที่ผิด

แต่การกำกับดูแลไม่ได้ถูกข้าม — มันถูกเลื่อนไปหนึ่งขั้น ในทางปฏิบัติเราแยก hotfix เป็นสองฉากทัศน์:

ฉากทัศน์ A — มี context อยู่แล้ว ถ้า bug ตกอยู่ในพื้นที่ที่ structured prompt ครอบคลุมอยู่แล้ว เราใช้ AI วิเคราะห์ความล้มเหลว ระบุต้นเหตุ แล้วใช้วงรอบ SPDD มาตรฐานในรูปแบบบีบอัด: อัปเดต prompt ก่อน แล้วค่อยอัปเดต code สิ่งนี้คง spec และการ implement ให้เดินคู่กัน และการแก้ก็กลายเป็นส่วนถาวรของสินทรัพย์ที่กำกับดูแล
ฉากทัศน์ B — code เก่าหรือไม่มี context ก่อนหน้า สำหรับการแก้เร่งด่วนใน code ที่ไม่เคยถูกนำเข้า SPDD ทางที่ปฏิบัติได้คือปล่อยให้ AI วิเคราะห์ log และแก้ปัญหาโดยตรง ขั้นปิดท้ายคือการทำ post-mortem โดยตั้งใจ: สังเคราะห์การแก้ โหมดความล้มเหลว และ context ที่เกี่ยวข้องเป็นสินทรัพย์ที่จัดทำเอกสารใหม่ นั่นคือที่ที่วงรอบการกำกับดูแลปิดสำหรับ code เก่า และเป็นวิธีที่ความครอบคลุมของ SPDD ค่อย ๆ ขยายทั่ว codebase อย่างเป็นธรรมชาติ

ประเด็นสำคัญคือสัญญาณจาก production ป้อนกลับได้ — แต่ต้องอาศัยขั้นจัดทำเอกสารที่ชัดเจนและนำโดยมนุษย์ ไม่ใช่เกิดขึ้นอัตโนมัติ การข้ามขั้นนั้นคือสิ่งที่สร้างส่วนต่าง spec/code ตามที่คำถามอธิบาย ส่วนการถือมันเป็นส่วนหนึ่งของ workflow คือสิ่งที่กันมันได้

เคยคิดให้ agent ทำการรีวิว prompt/spec เองไหม — ไม่ใช่มนุษย์รีวิว Canvas แต่เป็น agent ที่อ่าน REASONS Canvas เคียงข้าง code diff แล้วตรวจสอบการจัดแนว?

เคย — นั่นคือสิ่งที่คำสั่ง /spdd-code-review ทำอยู่แล้วโดยพื้นฐาน มันอ่าน REASONS Canvas และ code diff พร้อมกัน และชี้จุดที่ code drift จากเจตนาที่ระบุไว้ คุณจึงโอนการตรวจการจัดแนวให้คำสั่งได้ทุกเมื่อที่ต้องการ

trade-off คือสิ่งที่คุณยอมสละด้วยการทำเช่นนั้น คำสั่งตรวจการจัดแนวได้ แต่มีสองสิ่งที่มนุษย์นำมาสู่การรีวิวซึ่ง agent แทนไม่ได้:

จับ intent drift agent ตรวจได้ว่า code ตรงกับ Canvas ไหม แต่มีแต่มนุษย์ที่บอกได้ว่า Canvas เองยังตรงกับเจตนาทางธุรกิจจริงหรือไม่ หากขาดการตรวจนั้น การรีวิวที่ขับด้วย agent ล้วนอาจดูถูกต้องในเงื่อนไขของมันเอง แต่ยังพลาดเป้าหมายจริง
ให้มนุษย์ได้เรียนรู้ การรีวิวยังเป็นที่ที่มนุษย์เรียนรู้จากทางเลือกของ AI — pattern, trade-off, ตัวเลือกที่ไม่เคยคิดถึง การตัดมนุษย์ออกทำให้เร็วขึ้น แต่ปิดกั้นการเติบโตของทักษะระยะยาวที่ SPDD ออกแบบมาเพื่อปกป้อง

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

อะไรคือก้าวต่อไปของ SPDD — และ roadmap จะลดการพึ่งความเชี่ยวชาญของปัจเจกได้อย่างไร?

สี่ทิศทางกำลังกำหนดวิวัฒนาการของวิธีปฏิบัตินี้ และทั้งหมดดึงไปทางเดียวกัน: พึ่งฝีมือส่วนตัวน้อยลง พึ่งความสามารถระดับองค์กรที่ทำซ้ำได้มากขึ้น

จับ workflow ที่เกิดซ้ำให้เป็นคำสั่งมากขึ้น pattern ที่เริ่มด้วย /spdd-analysis, /spdd-reasons-canvas และ /spdd-generate ยังห่างไกลจากจุดจบ เมื่อเราเจอ pattern ที่เกิดซ้ำใน project จริง เราก็ดึงมันออกเป็นคำสั่งใหม่ workflow ที่สำเร็จแต่ละอันจึงนำกลับมาใช้ซ้ำได้ แทนที่จะเป็นความรู้ที่ปัจเจกถือไว้
การตรวจสอบอัตโนมัติในชั้นสินทรัพย์ เรากำลังสำรวจการตรวจสอบอัตโนมัติไม่ใช่ที่ระดับ code แต่ที่ตัวสินทรัพย์ SPDD เอง — analysis, REASONS Canvas และชิ้นงาน prompt เป้าหมายคือซ้อนการตรวจอัตโนมัติ และเมื่อเวลาผ่านไปก็ซ้อนการตัดสินใจอัตโนมัติบางส่วน ทับบนสินทรัพย์ชั้นเจตนาเหล่านี้ เพื่อให้กรอบจับช่องโหว่ ความไม่สอดคล้อง และการตัดสินรูทีนที่วันนี้พึ่งการรีวิวของมนุษย์ทั้งหมด
ค่อย ๆ ยกอัตรา automation ตัว SPDD เองก็เป็น harness อยู่แล้ว — เพียงเป็นแบบกึ่งอัตโนมัติ ที่มีมนุษย์อยู่ในวงรอบบนการตัดสินใจที่สำคัญ ทิศทางคือยกอัตรา automation ภายใน harness นั้นทีละขั้น โดยให้จังหวะตามสิ่งที่ AI รับมือได้อย่างเชื่อถือได้ในทางปฏิบัติ ส่วนงาน workflow จะรันโดยไม่ต้องประคองมากขึ้นเฉพาะเมื่อ model พิสูจน์ตัวว่าไว้ใจได้ในงานแต่ละชนิด
กลไกความจำสำหรับ “ความจำการตัดสินใจ” เป้าหมายคือให้การตัดสินใจในอดีต — canvas เก่า, trade-off และ pattern ที่ยอมรับ — ทำหน้าที่เป็น context ที่คงอยู่ เพื่อให้ agent ดึงการให้เหตุผลในอดีตที่ถูกต้องมาในสถานการณ์หนึ่ง ๆ แทนที่จะค้นพบใหม่ทุกครั้ง รายละเอียดจะถูกหล่อหลอมด้วย feedback จริง

รวมกันแล้ว ทิศทางเหล่านี้ขยับ SPDD จากวิธีการที่ให้รางวัลผู้ปฏิบัติที่มีฝีมือ ไปสู่ระบบที่ตัวกรอบเองแบกน้ำหนักมากขึ้น

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

📄 อ่านต้นฉบับภาษาอังกฤษ: Structured-Prompt-Driven Development (SPDD) — Wei Zhang และ Jessie Jie Xia, martinfowler.com (28 เมษายน 2026)

ใน pipeline ทางเดียว requirement ผลิต code ออกมาแล้วกระบวนการก็จบ การปรับใด ๆ หลังจากนั้นเกิดขึ้นที่ code เพียงอย่างเดียว และเจตนาดั้งเดิมก็ค่อย ๆ คลาดเคลื่อนไปจากความเป็นจริง

ใน SPDD วงรอบปิดในสองสเกล — ภายใน1 iteration feedback ไหลย้อนกลับ คือการแก้ตรรกะอัปเดต prompt ก่อน code ส่วนการ refactor sync จาก code กลับไปยัง prompt ทั้งสองฝั่งจึงไม่เบนออกจากกันแบบเงียบ ๆ

ข้าม iteration สินทรัพย์ prompt ที่สะสมไว้ — domain model, การตัดสินใจด้านการออกแบบ, บรรทัดฐาน ฯลฯ — กลายเป็น context ตั้งต้นของการพัฒนาต่อยอดครั้งถัดไป แต่ละรอบจึงต่อยอดจากฐานที่กำกับดูแลแล้ว แทนที่จะเริ่มจากศูนย์ ↩
เนื่องจากนี่เป็นคำสั่งแบบเสริม หากยังไม่มีในสภาพแวดล้อมเครื่องของคุณ คุณสามารถ generate มันขึ้นมาได้ด้วย openspdd generate spdd-story ↩
เนื่องจากนี่เป็นคำสั่งแบบเสริม หากยังไม่มีในสภาพแวดล้อมเครื่องของคุณ คุณสามารถ generate มันขึ้นมาได้ด้วย openspdd generate spdd-api-test ↩

Structured-Prompt-Driven Development (SPDD)

SPDD คือ​อะไร?

REASONS Canvas

workflow ของ SPDD

ยก​ระดับ billing engine ด้วย SPDD

ระบบ​ปัจจุบัน

โจทย์​การ​ยก​ระดับ

ขั้น​ที่ 1: สร้าง requirement ตั้งต้น

ขั้น​ที่ 2: ทำความ​กระจ่าง​จาก​การ​วิเคราะห์

ขั้น​ที่ 3: generate analysis context

ขั้น​ที่ 4: generate structured prompt

ขั้น​ที่ 5: generate code

การ​แก้​ตรรกะ (เปลี่ยน​พฤติกรรม)

Refactoring (code สะอาด​และ​สไตล์)

ขั้น​ที่ 6: generate unit test

ตัวอย่าง​นี้​ส่ง​มอบ​อะไร​บ้าง

ทักษะ​หลัก​สาม​อย่าง

Abstraction first — ออกแบบ​ก่อน generate

Alignment — ล็อก​เจตนา​ก่อน​เขียน code

Iterative Review — เปลี่ยน​ผลลัพธ์​ให้​เป็น​วง​รอบ​ที่​ควบคุม​ได้

SPDD เหมาะ​กับ​ตรง​ไหน

การ​ประเมิน​ความ​เหมาะสม

Trade-off ที่​ต้อง​ชั่ง​น้ำหนัก

บท​สรุป

กิตติกรรมประกาศ

ถาม-ตอบ

Footnotes

SPDD คืออะไร?

ยกระดับ billing engine ด้วย SPDD

ระบบปัจจุบัน

โจทย์การยกระดับ

ขั้นที่ 1: สร้าง requirement ตั้งต้น

ขั้นที่ 2: ทำความกระจ่างจากการวิเคราะห์

ขั้นที่ 3: generate analysis context

ขั้นที่ 4: generate structured prompt

ขั้นที่ 5: generate code

การแก้ตรรกะ (เปลี่ยนพฤติกรรม)

Refactoring (code สะอาดและสไตล์)

ขั้นที่ 6: generate unit test

ตัวอย่างนี้ส่งมอบอะไรบ้าง

ทักษะหลักสามอย่าง

Abstraction first — ออกแบบก่อน generate

Alignment — ล็อกเจตนาก่อนเขียน code

Iterative Review — เปลี่ยนผลลัพธ์ให้เป็นวงรอบที่ควบคุมได้

SPDD เหมาะกับตรงไหน

การประเมินความเหมาะสม

Trade-off ที่ต้องชั่งน้ำหนัก

บทสรุป