Kiro、Tessl、Conductor、Traycer：付費使用封閉式 SDD AI 編碼工具可以得到甚麼？

โดย Nokka (นก-กา) | ตอนที่ 3 ของซีรีส์เปรียบเทียบเครื่องมือ SDD | ตรวจข้อมูล 24 ต.ค. 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

สายนี้ต่างจากตอนที่แล้วอย่างไร

ตอนที่ 2 ผมพูดถึงเครื่องมือที่ไฟล์ spec อยู่ใน repo ของคุณ และใช้กับ agent ตัวไหนก็ได้

ตอนนี้คืออีกฟากของตลาด คือ ผลิตภัณฑ์ที่ขายเป็นบริการ ซึ่งมีจุดร่วมสามข้อ

โค้ดของตัวเครื่องมือไม่เปิดให้อ่าน
คุณจ่ายเป็นรายเดือนหรือเป็นเครดิต
บางตัวบังคับให้ทำงานในสภาพแวดล้อมของมัน

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

Kiro: IDE ที่ยก spec เป็นแกนกลาง

Kiro มาจาก AWS และเป็นตัวอย่างที่ชัดที่สุดของคำว่า spec-first ในระดับผลิตภัณฑ์ [1]

ทุกฟีเจอร์จะสร้างไฟล์สามชุด คือ requirements.md ที่แตกเป็น user story พร้อมเกณฑ์ยอมรับ design.md ที่มีแผนสถาปัตยกรรม และ tasks.md ที่แบ่งงานเป็นชิ้นเล็ก [1]

ไฟล์ที่ได้มีหน้าตาแบบนี้

.kiro/specs/<feature>/
  requirements.md   user story และเกณฑ์ยอมรับ
  design.md         สถาปัตยกรรมและลำดับการทำงาน
  tasks.md          งานย่อยที่ลงมือได้

จุดที่ผมคิดว่าคุ้มค่าที่สุดคือความสามารถที่เรียกว่า analyze requirements ซึ่งตรวจว่าข้อกำหนดขัดกันเองหรือไม่ และ correctness ซึ่งใช้ property-based testing หาข้อผิดพลาดเชิงตรรกะ

แต่มีรายละเอียดที่คนมักไม่ทันดู คือ correctness ใช้ได้เฉพาะใน IDE ไม่มีใน CLI และเว็บ ส่วน analyze requirements มีใน IDE กับ CLI แต่ไม่มีในเว็บ [1] และข้อจำกัดนี้อาจเปลี่ยนได้ตามเวอร์ชัน

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

ราคาและเครดิต

Kiro คิดเงินเป็นเครดิต ไม่ใช่จำนวนคำขอ [2]

ฟรี 50 เครดิตต่อเดือน ใช้โมเดล open weight และ Claude Sonnet 4.5
Pro 20 ดอลลาร์ต่อคนต่อเดือน ได้ 1,000 เครดิต
Pro+ 40 ดอลลาร์ ได้ 2,000 เครดิต
Pro Max 100 ดอลลาร์ ได้ 5,000 เครดิต
Power 200 ดอลลาร์ ได้ 10,000 เครดิต
ซื้อเครดิตเพิ่มได้ที่ 0.04 ดอลลาร์ต่อเครดิต

แผนเสียเงินได้โมเดลพรีเมียมรวมถึง Claude Sonnet 5 และ Claude Opus 5 [2]

ตัวเลขนี้สำคัญเพราะงาน SDD กินโทเคนมากกว่าการเขียนโค้ดเฉย ๆ อย่างชัดเจน เพราะต้องอ่าน spec อ่านโค้ดเดิม แล้วเขียนแผน

สิ่งที่ได้มาและราคาที่ต้องจ่าย

ได้คือวินัยที่ถูกบังคับโดยเครื่องมือ ไม่ต้องพึ่งความมีระเบียบของคนในทีม

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

Tessl: บทเรียนเรื่องแนวทางที่เปลี่ยนกลางทาง

Tessl เคยเป็นชื่อที่ถูกพูดถึงในฐานะผู้บุกเบิกแนว spec-as-source คือให้ spec เป็นต้นทางและโค้ดถูกสร้างจากมัน

วันนี้หน้าเว็บของบริษัทพูดภาษาใหม่ทั้งหมด คือวางตัวเป็น agent enablement platform ที่ช่วยทีมสร้าง ทดสอบ แจกจ่าย และปรับปรุงสกิลของ agent โดยเริ่มจากสกิล ต่อด้วยลูปการทำงาน แล้วจึงเป็น software factory [3]

มีเครดิตฟรี 1,000 ต่อเดือน และขายองค์กรพร้อมลูกค้าองค์กรขนาดใหญ่ [3]

ผมไม่คิดว่านี่คือความล้มเหลว แต่เป็นหลักฐานว่าแนวคิดที่ขายยากที่สุดใน SDD คือการทำให้ spec รันได้จริง เพราะภาษาที่คนอ่านง่ายไม่ได้บังคับให้เครื่องตรวจตามได้โดยอัตโนมัติ

บทเรียนสำหรับคนเลือกเครื่องมือคือ อย่าผูกกระบวนการทั้งทีมกับคำสัญญาที่ผลิตภัณฑ์ยังไม่พิสูจน์ ถ้าจะลอง ให้ลองในโครงการเล็กก่อน

Conductor: จัดทีม agent ขนานทั้งบนเครื่องและบนคลาวด์

Conductor ไม่ใช่เครื่องมือเขียน spec โดยตรง แต่แก้ปัญหาที่ตามมาหลังจากคุณมี spec ดีแล้ว นั่นคืองานหลายชิ้นที่อยากทำพร้อมกัน

หน้าเว็บวันนี้วางตัวเป็นบริการที่รัน agent เป็นทีมบนคลาวด์ ไม่ใช่แค่แอปเดสก์ท็อปสำหรับแมคอย่างที่หลายคนยังเข้าใจ มี workspace แยกและ sandbox ของตัวเอง ควบคู่กับแอปแมคและแอปมือถือ [4]

รองรับ Claude Code, Codex, Cursor และ OpenCode และให้คุณดูภาพรวมว่า agent แต่ละตัวกำลังทำอะไร แล้วรีวิวรวมถึง merge การเปลี่ยนแปลง [4]

เวอร์ชันล่าสุดใน changelog คือ 0.91.0 ลงวันที่ 15 ต.ค. 2026 [4] ซึ่งยังไม่ถึง 1.0 และไม่มี repo สาธารณะให้ตรวจโค้ดภายใน

จุดที่ต้องคิดคือ Conductor แก้ปัญหาเรื่องการจัดการงานขนาน ไม่ได้แก้เรื่องคุณภาพของข้อกำหนด ส่วน Traycer ในหัวข้อถัดไปก็ทำงานคล้ายกันในแง้นี้ ถ้า spec กำกวม การรันห้าตัวขนานจะทำให้คุณได้ความกำกวมห้าชุดพร้อมกัน

Traycer: รวม agent หลายค่ายไว้ในที่เดียว

Traycer วางตัวเป็นศูนย์กลางสำหรับงาน agentic coding คือให้คุณใช้ subscription ที่มีอยู่แล้ว รัน Claude Code, Codex, OpenCode และ Cursor ควบคู่กัน พร้อมกลไกให้ agent คุยกันเองเพื่อขอรีวิวหรือส่งงานต่อ [5]

จุดขายคือ context ที่แชร์กันระหว่างงาน worktree ที่แยกจากกัน และการทำงานต่อจากเครื่องไหนก็ได้ เพราะมีทั้งแอปเดสก์ท็อป มือถือ และ remote host [5]

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

ผลิตภัณฑ์ที่ผมตัดออก และเหตุผล

มีผลิตภัณฑ์เล็กอีกหลายตัวที่โฆษณาว่าทำ spec-driven development เช่น Intent และ Auto

ผมตัดออกจากบทนี้เพราะตรวจเอกสารสาธารณะได้ไม่พอจะยืนยันว่ามันทำงานอย่างไรจริง และการเขียนรีวิวจากหน้าโฆษณาอย่างเดียวจะทำให้คุณตัดสินใจจากคำกล่าวอ้าง ไม่ใช่จากข้อเท็จจริง

ถ้าคุณใช้ตัวใดอยู่และอยากให้ผมลองตรวจเพิ่ม บอกได้ครับ

เทียบกับเกณฑ์หกข้อจากตอนที่ 1

จุดเริ่มที่ถนัด: Kiro ถนัดงานใหม่และฟีเจอร์ใหม่ · Conductor กับ Traycer ไม่เกี่ยวกับจุดเริ่ม แต่เกี่ยวกับการจัดการงานขนาน
สิ่งที่ถูกบังคับใช้จริง: Kiro บังคับผ่านขั้นตอนใน IDE · Tessl บังคับผ่านสกิลและลูปที่ทีมสร้างเอง · Conductor และ Traycer บังคับแค่ระดับแยก workspace ไม่ได้บังคับว่า spec ต้องมี
การเชื่อมกับ agent: Kiro ล็อกกับตัวเอง · Conductor และ Traycer เปิดรับ agent หลายตัว และทั้งคู่มีทั้งแอปเดสก์ท็อปและทางรันบนคลาวด์หรือเครื่องระยะไกล
ร่องรอยตรวจสอบ: Kiro ได้จากไฟล์สามชุด · Tessl ได้จากสกิลและประวัติการรัน · Conductor กับ Traycer ให้ร่องรอยระดับงานและ branch ไม่ใช่ระดับข้อกำหนด
ภาระที่เพิ่มให้ทีม: Kiro ต่ำที่สุดเพราะมีหน้าจอช่วย · Tessl สูงกว่าเพราะต้องออกแบบสกิลเอง · Conductor และ Traycer เพิ่มภาระเรื่องการจัดการงานขนาน
สุขภาพของโครงการ: ทั้งสี่เป็นบริษัทที่ยังขยับ แต่ความเสี่ยงเรื่องการเปลี่ยนแนวทางมีจริง ดังกรณี Tessl

ใครควรจ่ายเงินให้สายนี้

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

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

ความเสี่ยงที่ต้องชั่งก่อนเซ็น

ข้อมูลออกจาก repo: บริการแบบโฮสต์อาจเห็นข้อกำหนดและโค้ดของคุณ ต้องอ่านข้อตกลงให้ครบ
ค่าใช้จ่ายผันตามการใช้: เครดิตหมดกลางงานคือปัญหาที่เกิดจริงในทีมที่ใช้เครื่องมือแบบนี้
การย้ายออกยาก: spec เป็น markdown ก็จริง แต่โฟลเดอร์ คำสั่ง และสถานะงานผูกกับผลิตภัณฑ์นั้น การย้ายจึงต้องจัดโครงใหม่และตรวจซ้ำ
การเปลี่ยนแนวทางของบริษัท: Tessl คือตัวอย่างที่มีให้เห็นแล้ว

คำถามที่ผมจะถามก่อนจ่ายเงิน

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

ตอบสามข้อนี้ได้ก่อน ก็ค่อยทดลองแบบเสียเงินน้อย ๆ

ถ้าคุณกำลังเลือกซื้ออยู่

ลองเปิดหน้า pricing ของผู้ให้บริการ แล้วคำนวณว่าเครดิตหนึ่งหน่วยพอสำหรับงานหนึ่งชิ้นของคุณหรือไม่ ถ้าคำนวณไม่ออก นั่นคือคำตอบว่าคุณยังไม่ควรเซ็นสัญญารายปี

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

ก่อนไปตอนต่อไป

ทั้งสี่ตัวในตอนนี้แก้ปัญหาเรื่องประสบการณ์และค่าใช้จ่าย แต่ยังเหลือคำถามใหญ่อีกข้อ คือถ้าอยากให้ agent ทำงานเป็นทีมตามกระบวนการที่กำหนดไว้ตั้งแต่ต้นจนจบ ควรใช้ framework ตัวไหน

ตอนที่ 4 ผมจะเทียบ Superpowers, BMAD และ Spec Kitty พร้อมตัวเลข issue ที่บอกภาระของคนดูแล

REF

[1] Kiro, "Specs", สืบค้น 24 ต.ค. 2026 (โครงสร้าง requirements, design, tasks · ตารางความสามารถแยกตาม IDE CLI เว็บ และมือถือ · analyze requirements · correctness). https://kiro.dev/docs/specs/

[2] Kiro, "Pricing", สืบค้น 24 ต.ค. 2026 (เครดิตและราคาแต่ละแผน · โมเดลที่ใช้ได้). https://kiro.dev/pricing/

[3] Tessl, หน้าแรกของบริษัท, สืบค้น 24 ต.ค. 2026 (ตำแหน่งผลิตภัณฑ์ปัจจุบัน สกิล ลูป และ factory · เครดิตฟรี 1,000 ต่อเดือน). https://tessl.io/

[4] Conductor, หน้าแรกและ changelog, สืบค้น 24 ต.ค. 2026 (รัน agent เป็นทีมบนคลาวด์และบนเครื่อง · workspace และ sandbox แยก · รองรับ Claude Code, Codex, Cursor, OpenCode · เวอร์ชัน 0.91.0 ลงวันที่ 15 ต.ค. 2026). https://conductor.build/

[5] Traycer, หน้าแรก, สืบค้น 24 ต.ค. 2026 (ใช้ subscription เดิม · รองรับ Claude Code, Codex, OpenCode, Cursor · agent คุยกันเอง · worktree). https://traycer.ai/