DEV Community

Nokka
Nokka

Posted on AI-assisted

pstack คืออะไร และทำไม skill ที่โตจากความผิดพลาดจริงจึงช่วย AI agent ได้?

โดย Nokka (นก-กา) | ตรวจข้อมูล 25 ต.ค. 2026 · ตอนที่ 3 จาก 6 ของชุด "หนึ่งคนกับทีม agent"

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

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

Lauren Tan เขียนไว้ในบทความของเธอว่า เธอไม่ได้ตั้งใจสร้าง pstack ขึ้นมาเป็นผลิตภัณฑ์ [4]

เธอแค่เริ่มเปลี่ยนความล้มเหลวที่เกิดซ้ำ ๆ ให้เป็น skill ทีละตัว

ทำซ้ำบั๊กก่อนแตะโค้ด ตั้งสมมติฐานหลายข้อแล้วตัดทิ้ง เขียนเทสต์ที่พังก่อน สแกนผลกระทบรอบนอก diff เทียบทางเลือกก่อนเลือก และเก็บภาพของจริงก่อนกับหลัง [4]

ทุกครั้งที่ความผิดพลาดเกิดซ้ำ เธอเติมบทเรียนนั้นกลับเข้าไปในคำสั่งของมัน

ผมคิดว่านี่คือคำตอบว่าทำไม skill ถึงได้ผลกว่าคำสั่งยาว ๆ ที่เขียนครั้งเดียวจบ

pstack มีอะไรอยู่ในนั้น

ตัวเลขที่ตรวจจากรีโปจริง

รีโป cursor/plugins บน GitHub เก็บ pstack ไว้ในโฟลเดอร์ pstack และนับได้ว่าในนั้นมี skill 58 ตัว playbook 23 เล่ม และ principle 24 ข้อ [1]

ตัวเลขนี้ผมไม่ได้อ่านจากบทความที่ไหน แต่ไล่จากโครงสร้างไฟล์จริงในรีโป ณ วันที่ตรวจ [1]

สิ่งที่น่าสนใจคือสัดส่วน ใน 58 ตัวนั้นเป็นหลักคิด 24 ข้อ เหลืออีกราว 34 ตัวเป็นเครื่องมือเฉพาะทาง เช่น การเขียน technical writing การตรวจ benchmark และการทำความสะอาด prose ส่วน playbook 23 เล่มเป็นไฟล์แยกในโฟลเดอร์ poteto-mode [2][6]

/poteto-mode คือประตูหน้าเพียงบานเดียว

ผู้รับงานที่เลือก playbook เอง

เอกสารของ pstack อธิบายว่า /poteto-mode ทำหน้าที่เป็นทางเข้าเดียว คุณบอกเป้าหมาย มันจับคู่งานเข้ากับ playbook หนึ่งใน 23 เล่ม แล้วคัดลอกขั้นตอนของ playbook นั้นลงในรายการงาน ก่อนเรียก skill อื่นตามที่แต่ละขั้นต้องใช้ [2]

ถ้าขั้นไหนถูกข้าม มันจะยังคาไว้ในรายการพร้อมเหตุผลว่า skip: <reason> ไม่ใช่หายไปเงียบ ๆ [2]

จุดนี้ฟังดูเล็ก แต่ผมคิดว่ามันคือหัวใจของการตรวจงาน เพราะคุณเห็นได้ทันทีว่า agent ข้ามขั้นตอนไหนและเพราะอะไร

ห้าองค์ประกอบของ prompt ที่ดี

เอกสารระบุว่า prompt ที่ใช้ได้ควรมีไม่เกินห้าอย่าง อย่างละหนึ่งประโยค [2]

  • เป้าหมาย: เกิดอะไรผิด หรืออยากได้อะไร
  • เกณฑ์เสร็จ: ต้องผ่านหรือไม่ผ่านได้จริง คำว่า "ทำให้ดีขึ้น" ใช้ไม่ได้
  • หลักฐานที่อยากเห็น: output ของคำสั่งจริง วิดีโอของ flow ค่าที่บันทึกไว้ หรือตัวเลขก่อนกับหลัง
  • สิ่งที่คุณรู้แล้ว: อาการ ขั้นตอนทำซ้ำ log หรือลิงก์
  • ข้อจำกัดจริง: "ทำซ้ำก่อน" "ยังไม่ต้องแก้โค้ด" "พฤติกรรมต้องไม่เปลี่ยน" "ให้ผมดูก่อนไปต่อ"

ผมชอบข้อสี่เพราะมันประหยัดเวลาที่สุด และเป็นข้อที่คนมักลืมใส่

สิ่งที่ควรละไว้

เอกสารยังบอกให้ละสองอย่าง คือวิธีทำ และทฤษฎีสาเหตุของคุณ [2]

การบอกวิธีทำจะปิดโอกาสที่ agent จะเจอทางที่ดีกว่า และการบอกสาเหตุที่คุณเดาไว้จะจำกัดการค้นหาไว้แค่จุดที่คุณชี้ [2]

แทนที่จะเดา เอกสารแนะนำให้ agent ทวนปัญหาก่อนด้วยคำของตัวเอง โดยเฉพาะกับรายงานที่วกวน ถ้าทวนผิดจะเห็นตั้งแต่ยังไม่มีโค้ด และแก้ใช้เวลาแค่ข้อความเดียว [2]

หลักคิด 24 ข้อ ไม่ใช่คติพจน์ติดผนัง

ตัวอย่างที่จับต้องได้

หนึ่งใน principle ที่ผมชอบที่สุดชื่อ principle-encode-lessons-in-structure ซึ่งเขียนไว้ว่า ให้ฝังกฎเป็น lint, metadata flag, runtime check หรือสคริปต์ แทนที่จะเขียนเป็นข้อความเพิ่ม [3]

อีกข้อที่ผมคิดว่าใช้ยากที่สุดคือ principle-never-block-on-the-human ซึ่งบอกว่าคนดูแลแบบไม่ต้องเฝ้า

ดังนั้น agent ควรตัดสินใจงานที่แก้คืนได้แล้วทำต่อ เช่น เขียนโค้ดหรือแก้บันทึก ส่วนงานที่แก้คืนไม่ได้ เช่น force push ลบข้อมูลบนเซิร์ฟเวอร์จริง หรือส่งข้อความออกนอกองค์กร ยังต้องขออนุญาต [9]

และข้อ principle-test-behavior-not-implementation ที่กันไม่ให้เทสต์ผูกกับรายละเอียดภายในจนพังทุกครั้งที่ refactor [7]

ทั้งหมดนี้ไม่ใช่คำขวัญ pstack ส่งหลักคิด 24 ข้อเป็น skill แยก และ /poteto-mode อ่านดัชนีตอนเริ่มงานหลายขั้น แล้วอ้างชื่อหลักคิดที่ใช้ในคำตอบ [8]

verification skill คือของขวัญที่ทีมได้ทุกครั้ง

interview รีโป ไม่ใช่ interview คน

skill ที่ชื่อ create-verification-skill สร้าง skill เฉพาะโปรเจกต์ให้ agent ขับแอปจริงเหมือนผู้ใช้ ทั้งเปิดแอป ทำฟีเจอร์ และเก็บหลักฐาน [5]

คำอธิบายในไฟล์ระบุหลักการที่ผมคิดว่าสำคัญที่สุดข้อหนึ่งของทั้งชุด คือให้ agent อ่านรีโปเพื่อตอบคำถามเองก่อน ไม่ใช่ถามคนเขียน [5]

สิ่งที่ไม่ต้องถามคนคือ ผู้ใช้แตะพื้นผิวไหน แอปเริ่มอย่างไร agent ขับมันด้วยอะไร เก็บหลักฐานแบบไหน และรันสองอินสแตนซ์คู่กันได้หรือไม่ [5]

เหตุผลคือ skill นี้จะถูกอ่านโดย agent ตัวอื่นที่เพิ่งเปิดโปรเจกต์มาและไม่รู้จักแอปเลย ดังนั้นมันต้องเขียนให้คนแปลกหน้าอ่านแล้วทำตามได้ทันที [5]

ตัวอย่างการเขียน prompt แบบที่เอกสารแนะนำ

ผมขอยกตัวอย่างจากรูปแบบในเอกสาร แล้วเติมบริบทสมมติให้เห็นภาพ

/poteto-mode หน้าตั้งค่ากระตุกเวลาเลื่อนรายการ
เริ่มตั้งแต่ deploy เมื่อวาน ผู้ใช้ 2 คนแจ้งใน Slack
ทำซ้ำก่อน แล้วค่อยแก้
เสร็จเมื่อเลื่อนรายการ 200 แถวแล้วไม่มีเฟรมตกเกิน 16ms
ขอวิดีโอก่อนกับหลัง และตัวเลข frame time
Enter fullscreen mode Exit fullscreen mode

เทียบกับ prompt ที่ผมเคยเขียนสมัยแรก ๆ ซึ่งยาวกว่านี้เท่าตัว แต่ไม่มีเกณฑ์เสร็จและไม่มีหลักฐานที่ขอ

ผลต่างคืออันแรกตรวจได้ อันหลังได้คำตอบที่ต้องเชื่อใจ

สิ่งที่คนนอก Cursor เอาไปใช้ได้

สามอย่างที่ไม่ต้องย้ายเครื่องมือ

หนึ่ง ทำประตูหน้าให้ตัวเอง ไม่ต้องมี 23 playbook เริ่มจาก 3 อันที่คนมักเริ่มด้วย คืองานแก้บั๊ก งานเพิ่มฟีเจอร์ และงานสืบสวน แล้วให้ agent เลือกเองว่าอยู่ในโหมดไหน [2]

สอง เขียน verification skill หนึ่งตัวต่อโปรเจกต์ ให้ agent เปิดแอปเอง ถ่ายภาพเอง และแนบหลักฐานมากับงาน [5]

สาม เก็บ principle เป็นไฟล์ ไม่ใช่จำ เขียนกฎที่คุณอยากให้ agent ทำตามพร้อมเหตุผลสั้น ๆ แล้วให้มันอ้างถึงตอนตัดสินใจ [3]

ทั้งหมดนี้ทำได้ในเครื่องมือ agent อะไรก็ได้ที่อ่านไฟล์ในโปรเจกต์ได้

บทเรียนที่ผมคิดว่าสำคัญที่สุดของตอนนี้

ตัวเลข 58 skill ไม่ใช่ความสำเร็จ เพราะหลายตัวมีที่มาจากความผิดพลาดที่เกิดซ้ำ แล้วถูกแปลงเป็นบทเรียน [4]

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

แต่ถ้าเริ่มจากงานจริงหนึ่งงาน จดว่ามันพลาดตรงไหน แล้วแก้คำสั่งให้ดีขึ้นหนึ่งจุด คุณจะได้ skill ที่มีน้ำหนัก

สิ่งที่ตอนต่อไปจะตอบ

ตอนนี้เราเห็นโครงแล้ว แต่ยังไม่เห็นว่าการตรวจสอบหน้าตาเป็นอย่างไรในทางปฏิบัติ

ตอนที่ 4 ผมจะลงลึกเรื่อง verification ว่าทำไมเธอถึงบอกว่ามันคือคอขวด และเครื่องมืออย่าง /control-glass ทำงานอย่างไรกับงานจริง

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

REF

[1] Cursor (2026) · pstack directory ในรีโป cursor/plugins (นับจากโครงสร้างไฟล์ ณ 25 ต.ค. 2026: skill 58 · playbook 23 · principle 24). https://github.com/cursor/plugins/tree/main/pstack
[2] Cursor (2026) · Route work through /poteto-mode (คู่มือ pstack). https://github.com/cursor/plugins/blob/main/pstack/docs/guide/02-poteto-mode.md
[3] Cursor (2026) · pstack skill: principle-encode-lessons-in-structure. https://github.com/cursor/plugins/blob/main/pstack/skills/principle-encode-lessons-in-structure/SKILL.md
[4] Lauren Tan (24 มิ.ย. 2026) · Loops You Can Trust. https://x.com/poteto/article/2069824386283319343
[5] Cursor (2026) · pstack skill: create-verification-skill. https://github.com/cursor/plugins/blob/main/pstack/skills/create-verification-skill/SKILL.md
[6] Cursor (2026) · pstack README (ระบุ "twenty-three playbooks"). https://github.com/cursor/plugins/blob/main/pstack/README.md
[7] Cursor (2026) · pstack skill: principle-test-behavior-not-implementation. https://github.com/cursor/plugins/blob/main/pstack/skills/principle-test-behavior-not-implementation/SKILL.md
[8] Cursor (2026) · pstack principles (คู่มือตอนที่ 8: หลักคิด 24 ข้อ และวิธีที่ /poteto-mode อ่านดัชนี). https://github.com/cursor/plugins/blob/main/pstack/docs/guide/08-principles.md
[9] Cursor (2026) · pstack skill: principle-never-block-on-the-human. https://github.com/cursor/plugins/blob/main/pstack/skills/principle-never-block-on-the-human/SKILL.md

Top comments (0)