AI Agents als Team in 30 Tagen: Praxisplan und typische Fallstricke

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

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

ห้าตอนที่ผ่านมาผมเล่าเส้นทางของ Lauren Tan ทีละชั้น ตั้งแต่การเรียน Excel ไปจนถึงการปล่อย agent ทำงานข้ามคืน

คำถามที่เหลือคือ ถ้าคุณไม่ได้ทำงานที่บริษัทที่มีทีม Platform หนุนหลัง คุณเริ่มจากตรงไหน

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

คู่มือ overnight บอกว่าต้องทำด้วยมือหรือดู agent ทำก่อนจึงจะปล่อยลูป ส่วนคู่มือ verification บอกให้ agent ตรวจของจริงแทนคำอธิบาย

ถ้าคุณยังไม่เคยทำงานนั้นด้วยมือ ก็จะเขียนเกณฑ์ผ่านไม่ได้ และเมื่อไม่มีเกณฑ์ การตรวจงานของ agent ก็เป็นไปไม่ได้เช่นกัน

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

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

คู่มือระบุว่าเกณฑ์เสร็จต้องผ่านหรือไม่ผ่านได้จริง คำว่า "ทำให้ดีขึ้น" ใช้ไม่ได้

ลองเขียนประโยคเดียวที่ขึ้นต้นด้วย "เสร็จเมื่อ" แล้วตามด้วยสิ่งที่วัดได้ เช่น "เสร็จเมื่อรายงานมีครบ 12 คอลัมน์และยอดรวมตรงกับต้นทาง"

ถ้าเขียนไม่ได้ แปลว่าคุณยังไม่เข้าใจงานนั้นพอ และควรกลับไปทำมืออีกรอบ

คู่มือแนะนำให้ agent สร้าง skill ที่เปิดแอปและเดินฟีเจอร์เหมือนผู้ใช้ พร้อมหัวข้อบังคับห้าส่วนคือ Launch, Doctor, Drive, Evidence และ Cleanup

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

เกณฑ์ผ่านของสัปดาห์นี้คือ มีสคริปต์หรือชุดคำสั่งที่คนอื่นรันแล้วได้ผลเหมือนคุณ

คู่มือบอกว่าหลักฐานที่ดีคือสิ่งที่คุณเอาไปตรวจเองได้ เช่น เทสต์ที่พังก่อนแก้ เทสต์ที่ผ่านหลังแก้ วิดีโอก่อนกับหลัง เทรซ หรือภาพหน้าจอ

ผมแนะนำให้เขียนเป็นกฎสั้น ๆ ในทีมว่า "งานจะถือว่าเสร็จเมื่อมีหลักฐานประเภทใดประเภทหนึ่งต่อไปนี้" แล้วบังคับใช้กับทั้งคนและ agent

คุณไม่จำเป็นต้องมี playbook 23 เล่ม แต่ควรมีประตูหน้าที่เลือกโหมดได้อย่างน้อยสามโหมด คืองานแก้บั๊ก งานเพิ่มฟีเจอร์ และงานสืบสวน

ประตูนี้ทำหน้าที่สองอย่าง คือเลือกขั้นตอนให้เอง และทำให้คุณเห็นว่าขั้นไหนถูกข้ามพร้อมเหตุผล

สกิล show-me-your-work เก็บ log ที่มีเวลา ช่วงงาน การตัดสินใจ เหตุผล ตัวชี้หลักฐาน และผลลัพธ์

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

เกณฑ์ผ่านของสัปดาห์นี้คือ งานหนึ่งงานมี log ที่คุณอ่านแล้วตอบได้ว่าทำไม agent เลือกทางนั้น

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

คืนแรกควรเป็นงานเล็กที่จบในสองสามชั่วโมง และมีทางออกเมื่อติดชัดเจน

ถ้าปล่อยข้ามคืนจริง ให้เริ่มจาก playbook ที่ไม่ merge อะไรเอง เช่น autopilot-stack ที่ได้ stack พร้อมคำตัดสินของ verifier แล้วคุณเป็นคนลงเอง

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

pstack ส่งหลักคิด 24 ข้อเป็น skill แยก และประตูหน้าจะอ้างชื่อหลักคิดที่ใช้ในคำตอบ

คุณไม่ต้องมี 24 ข้อ เริ่มจากสามข้อที่ตรงกับปัญหาบ่อยที่สุดของทีมคุณ แล้วเขียนเป็นไฟล์ที่ agent อ่านได้

คู่มือแนะนำให้รัน maintain-verification-skill อย่างน้อยวันละครั้ง หรือตั้งเป็น automation และผลลัพธ์ต้องเป็น clean, changed หรือ blocked เท่านั้น

ถ้า skill ตรวจงานเก่าจนตามแอปไม่ทัน ในมุมมองของผม มันจะโกหกคุณอย่างสุภาพ ซึ่งอันตรายกว่าการที่มันไม่มีอยู่

หนึ่ง ไล่ชื่อ skill ใน prompt การเขียนว่าใช้ skill ไหนก่อนหลังเป็นการจัดลำดับทับ playbook ที่จัดไว้แล้ว ให้บอกเป้าหมายและข้อจำกัดแทน

สอง เกณฑ์เสร็จคลุมเครือ ทำให้ลูปไม่มีอะไรให้ตรวจ

สาม บอกทฤษฎีสาเหตุตั้งแต่แรก agent จะค้นแค่จุดที่คุณชี้ ให้มันทวนปัญหาก่อน

สี่ เอาแบบออกแบบแรกที่ได้ ควรขอ prototype หรือให้สำรวจหลายทางก่อนเลือก

ห้า ขัดเกลาแผนนามธรรม การรีวิวแผนที่ยังไม่มีโค้ดจะได้ความเสี่ยงที่ไม่มีวันเกิดขึ้น

หก agent หลายตัวใน worktree เดียว พวกมันเขียนทับกันและตรวจไม่ได้ว่าใครแก้อะไร

เจ็ด ปล่อยลูปก่อนไว้ใจลูป ลูปที่ตรวจตัวเองไม่ได้จะทำให้งานที่ยังไม่ตรวจไหลเร็วขึ้น

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

เก้า แก้ความผิดพลาดเดิมด้วยมือ การแก้ในแชตช่วยได้ครั้งเดียว ควรแก้ที่ repo ให้ agent ตัวต่อไปทำผิดไม่ได้

สิบ ใช้ swarm แทน arena สองตัวนี้ทำงานคนละแบบ ตัวหนึ่งแบ่งงาน ตัวหนึ่งเปรียบเทียบทางเลือก

สิบเอ็ด รับทุกคอมเมนต์รีวิว ทั้งบอตและคนปนของจริงกับเสียงรบกวนไว้ด้วยกัน ต้องคัดก่อน

สิบสอง รายงานว่าเสร็จเพราะ build ผ่าน build พิสูจน์แค่ว่าคอมไพล์ผ่าน ไม่ได้พิสูจน์ว่าทำงาน

ผมคิดว่าข้อสิบสองคือข้อที่ทีมไทยจำนวนมากยังติด เพราะวัฒนธรรมการรายงานมักจบที่ "เทสต์ผ่านแล้ว" โดยไม่ถามว่าเทสต์นั้นทดสอบอะไร

คู่มือมี 14 ข้อ ผมตัดข้อ auto เป็นชื่อโมเดล และข้อเขียน SKILL.md ด้วยมือออก เพราะไม่เกี่ยวกับทีมที่ยังไม่มี pstack

สิบสาม เชื่อตัวเลขจากพาดหัวโดยไม่อ่านเนื้อความ ผมเขียนตอนที่ 2 ว่า 2,000 PR กับ 1,000 PR ขัดกัน เพราะอ่านแค่พาดหัว ทั้งที่เนื้อความของ The New Stack อธิบายว่ามาจากเกือบ 100 PR ต่อวันทำการ

สิบสี่ คัดลอกพาธ GitHub จากความจำ ผมใส่ harness/ เกินมาสามบท (ตอนที่ 3, 4 และ 5) จนลิงก์คู่มือกลายเป็น 404 ทั้งที่เนื้อหาอ้างถูกทุกคำ บทเรียนคือพาธต้องคัดลอกจากการเปิดจริงเท่านั้น

หนึ่ง อย่าลอก 58 skill ตัวเลขนั้นคือผลของเวลา ไม่ใช่เป้าหมาย

สอง อย่าลอก 20 agent ตั้งแต่วันแรก ลำดับชั้นของ Chief, manager และ worker ทำงานได้เพราะมี skill และหลักคิดรองรับ ถ้าขาดสองอย่างนั้น การเพิ่ม agent จะเพิ่มงานให้คุณ

สาม อย่าลอกการ refactor ใหญ่ทันที การเปลี่ยนสถาปัตยกรรมให้ agent ทำงานถูกตั้งแต่แรกเป็นผลพลอยได้จากงานจริง ไม่ใช่โปรเจกต์แยกที่ทำก่อนมีงาน

ถ้าผมต้องสรุปทั้งหกตอนเป็นประโยคเดียว มันคือแบบนี้

ในมุมมองของผม Lauren Tan ไม่ได้เก่งเพราะใช้ agent เยอะ แต่เพราะเธอสร้างระบบที่ทำให้ agent ตรวจงานตัวเองได้ แล้วค่อยเพิ่มจำนวนอย่างช้า ๆ

คุณเริ่มจากงานเดียวที่ทำซ้ำ เกณฑ์ผ่านหนึ่งข้อ หลักฐานหนึ่งชิ้น และ log หนึ่งไฟล์

ที่เหลือคือการทำซ้ำจนมันกลายเป็นนิสัยของทีม

ตอบสั้น ๆ ว่าได้ ถ้า 30 วันแรกคุณยอมจ่ายด้วยการทำมือหนึ่งรอบ เขียนเกณฑ์ให้ได้หนึ่งข้อ และเก็บหลักฐานให้เป็นนิสัย

ผมจะกลับมาเขียนเพิ่มถ้ามีข้อมูลใหม่จากเธอ หรือจากรีโป pstack ที่อัปเดต แล้วพบกันใหม่ครับ

Cursor (2026) · Recipes and pitfalls (คู่มือ pstack ตอนที่ 10). https://github.com/cursor/plugins/blob/main/pstack/docs/guide/10-recipes-and-pitfalls.md Cursor (2026) · Run work while you sleep (คู่มือ pstack ตอนที่ 7). https://github.com/cursor/plugins/blob/main/pstack/docs/guide/07-overnight.md Cursor (2026) · Verify the result and open a PR (คู่มือ pstack ตอนที่ 6). https://github.com/cursor/plugins/blob/main/pstack/docs/guide/06-verify-and-ship.md Cursor (2026) · Route work through /poteto-mode (คู่มือ pstack ตอนที่ 2). https://github.com/cursor/plugins/blob/main/pstack/docs/guide/02-poteto-mode.md Cursor (2026) · Principles (คู่มือ pstack ตอนที่ 8). https://github.com/cursor/plugins/blob/main/pstack/docs/guide/08-principles.md Cursor (2026) · pstack directory (นับจากโครงสร้างไฟล์ ณ 25 ต.ค. 2026). https://github.com/cursor/plugins/tree/main/pstack Grok (1 ก.ย. 2026) · TL;DR of Lauren Tan workshop on maxing GrokBot. https://x.com/grok/status/2094731064749023668 Lauren Tan (24 มิ.ย.

2026) · Loops You Can Trust. https://x.com/poteto/article/2069824386283319343