โดย 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 ทำก่อนจึงจะปล่อยลูป [2] ส่วนคู่มือ verification บอกให้ agent ตรวจของจริงแทนคำอธิบาย [3]
ถ้าคุณยังไม่เคยทำงานนั้นด้วยมือ ก็จะเขียนเกณฑ์ผ่านไม่ได้ และเมื่อไม่มีเกณฑ์ การตรวจงานของ agent ก็เป็นไปไม่ได้เช่นกัน
สัปดาห์ที่ 1 หางานที่ทำซ้ำ
เลือกงานที่มีเกณฑ์ผ่านชัด
เป้าหมายของสัปดาห์แรกไม่ใช่การใช้ agent เก่ง แต่คือการหางานหนึ่งงานที่ทำซ้ำทุกสัปดาห์และมีคำตอบว่าถูกหรือผิด
ตัวอย่างงานที่เหมาะ
- รายงานที่ต้องรวบรวมตัวเลขจากหลายไฟล์ทุกวันศุกร์
- การตรวจว่าหน้าเว็บยังแสดงผลถูกหลัง deploy
- การไล่บั๊กที่มีขั้นตอนทำซ้ำแน่นอน
เกณฑ์ผ่านของสัปดาห์นี้คือ คุณทำงานนั้นด้วยมือหนึ่งรอบแล้วจดขั้นตอนได้ครบ โดยไม่ต้องเปิดดูของเก่า
เขียนเกณฑ์เสร็จให้ได้หนึ่งข้อ
คู่มือระบุว่าเกณฑ์เสร็จต้องผ่านหรือไม่ผ่านได้จริง คำว่า "ทำให้ดีขึ้น" ใช้ไม่ได้ [1][2]
ลองเขียนประโยคเดียวที่ขึ้นต้นด้วย "เสร็จเมื่อ" แล้วตามด้วยสิ่งที่วัดได้ เช่น "เสร็จเมื่อรายงานมีครบ 12 คอลัมน์และยอดรวมตรงกับต้นทาง"
ถ้าเขียนไม่ได้ แปลว่าคุณยังไม่เข้าใจงานนั้นพอ และควรกลับไปทำมืออีกรอบ
สัปดาห์ที่ 2 สร้างเครื่องมือตรวจ
verification skill หนึ่งตัวต่อหนึ่งแอป
คู่มือแนะนำให้ agent สร้าง skill ที่เปิดแอปและเดินฟีเจอร์เหมือนผู้ใช้ พร้อมหัวข้อบังคับห้าส่วนคือ Launch, Doctor, Drive, Evidence และ Cleanup [3]
ในงานที่ไม่ใช่แอป หลักการเดียวกันใช้ได้ คือกำหนดว่าอะไรคือการเปิดงาน อะไรคือการตรวจความพร้อม อะไรคือการเดินงานจริง อะไรคือหลักฐาน และอะไรคือการเก็บกวาด
เกณฑ์ผ่านของสัปดาห์นี้คือ มีสคริปต์หรือชุดคำสั่งที่คนอื่นรันแล้วได้ผลเหมือนคุณ
กำหนดมาตรฐานหลักฐาน
คู่มือบอกว่าหลักฐานที่ดีคือสิ่งที่คุณเอาไปตรวจเองได้ เช่น เทสต์ที่พังก่อนแก้ เทสต์ที่ผ่านหลังแก้ วิดีโอก่อนกับหลัง เทรซ หรือภาพหน้าจอ [3]
ผมแนะนำให้เขียนเป็นกฎสั้น ๆ ในทีมว่า "งานจะถือว่าเสร็จเมื่อมีหลักฐานประเภทใดประเภทหนึ่งต่อไปนี้" แล้วบังคับใช้กับทั้งคนและ agent
สัปดาห์ที่ 3 ทำประตูหน้าและบันทึกการตัดสินใจ
ประตูหน้าที่มีสามโหมด
คุณไม่จำเป็นต้องมี playbook 23 เล่ม แต่ควรมีประตูหน้าที่เลือกโหมดได้อย่างน้อยสามโหมด คืองานแก้บั๊ก งานเพิ่มฟีเจอร์ และงานสืบสวน [4]
ประตูนี้ทำหน้าที่สองอย่าง คือเลือกขั้นตอนให้เอง และทำให้คุณเห็นว่าขั้นไหนถูกข้ามพร้อมเหตุผล [4]
decision log ตั้งแต่ยังไม่ต้องใช้
สกิล show-me-your-work เก็บ log ที่มีเวลา ช่วงงาน การตัดสินใจ เหตุผล ตัวชี้หลักฐาน และผลลัพธ์ [2]
คุณยังไม่ต้องปล่อยให้ agent ทำงานข้ามคืนก็ได้ แต่การมี log ทำให้คุณย้อนดูได้ว่างานที่พลาดนั้นพลาดที่การตัดสินใจข้อไหน
เกณฑ์ผ่านของสัปดาห์นี้คือ งานหนึ่งงานมี log ที่คุณอ่านแล้วตอบได้ว่าทำไม agent เลือกทางนั้น
สัปดาห์ที่ 4 ลองคืนแรกที่ยังตื่นอยู่
ปล่อยลูปแต่ยังนั่งดู
คู่มือแนะนำให้รันลูปตอนที่ยังดูอยู่ก่อน จนกว่าจะผ่านสี่ข้อ คือคุณรู้ว่าของดีหน้าตาเป็นอย่างไร agent มีเครื่องมือครบ ทุกขั้นหยุดสายได้ และคุณเคยแปลงความผิดพลาดซ้ำเป็นเครื่องมือแล้ว [2]
คืนแรกควรเป็นงานเล็กที่จบในสองสามชั่วโมง และมีทางออกเมื่อติดชัดเจน
อ่านบันทึกตอนเช้า
ถ้าปล่อยข้ามคืนจริง ให้เริ่มจาก playbook ที่ไม่ merge อะไรเอง เช่น autopilot-stack ที่ได้ stack พร้อมคำตัดสินของ verifier แล้วคุณเป็นคนลงเอง [2]
นี่คือความต่างระหว่างการทดลองกับการเสี่ยง งานที่ยังไม่ merge คือความผิดพลาดที่แก้ได้ด้วยการทิ้ง branch
เดือนที่ 2 ถึง 3 ขยายอย่างมีวินัย
เก็บหลักคิดเป็นไฟล์
pstack ส่งหลักคิด 24 ข้อเป็น skill แยก และประตูหน้าจะอ้างชื่อหลักคิดที่ใช้ในคำตอบ [5]
คุณไม่ต้องมี 24 ข้อ เริ่มจากสามข้อที่ตรงกับปัญหาบ่อยที่สุดของทีมคุณ แล้วเขียนเป็นไฟล์ที่ agent อ่านได้
ทำความสะอาดเครื่องมือตรวจทุกสัปดาห์
คู่มือแนะนำให้รัน maintain-verification-skill อย่างน้อยวันละครั้ง หรือตั้งเป็น automation และผลลัพธ์ต้องเป็น clean, changed หรือ blocked เท่านั้น [3]
ถ้า skill ตรวจงานเก่าจนตามแอปไม่ทัน ในมุมมองของผม มันจะโกหกคุณอย่างสุภาพ ซึ่งอันตรายกว่าการที่มันไม่มีอยู่
กับดัก 12 ข้อจาก 14 ข้อที่คู่มือเตือนไว้ และ 2 ข้อที่ผมเจอเอง
กับดักฝั่ง prompt
หนึ่ง ไล่ชื่อ skill ใน prompt การเขียนว่าใช้ skill ไหนก่อนหลังเป็นการจัดลำดับทับ playbook ที่จัดไว้แล้ว ให้บอกเป้าหมายและข้อจำกัดแทน [1]
สอง เกณฑ์เสร็จคลุมเครือ ทำให้ลูปไม่มีอะไรให้ตรวจ [1]
สาม บอกทฤษฎีสาเหตุตั้งแต่แรก agent จะค้นแค่จุดที่คุณชี้ ให้มันทวนปัญหาก่อน [1]
สี่ เอาแบบออกแบบแรกที่ได้ ควรขอ prototype หรือให้สำรวจหลายทางก่อนเลือก [1]
กับดักฝั่งการทำงาน
ห้า ขัดเกลาแผนนามธรรม การรีวิวแผนที่ยังไม่มีโค้ดจะได้ความเสี่ยงที่ไม่มีวันเกิดขึ้น [1]
หก agent หลายตัวใน worktree เดียว พวกมันเขียนทับกันและตรวจไม่ได้ว่าใครแก้อะไร [1]
เจ็ด ปล่อยลูปก่อนไว้ใจลูป ลูปที่ตรวจตัวเองไม่ได้จะทำให้งานที่ยังไม่ตรวจไหลเร็วขึ้น [1]
แปด เชื่อตัวเลขที่ยังไม่ตรวจ แคชอุ่นหรือโค้ดที่ไม่ได้รันในช่วงจับเวลาทำให้ได้ความเร็วปลอม [1]
กับดักฝั่งทีม
เก้า แก้ความผิดพลาดเดิมด้วยมือ การแก้ในแชตช่วยได้ครั้งเดียว ควรแก้ที่ repo ให้ agent ตัวต่อไปทำผิดไม่ได้ [1]
สิบ ใช้ swarm แทน arena สองตัวนี้ทำงานคนละแบบ ตัวหนึ่งแบ่งงาน ตัวหนึ่งเปรียบเทียบทางเลือก [1]
สิบเอ็ด รับทุกคอมเมนต์รีวิว ทั้งบอตและคนปนของจริงกับเสียงรบกวนไว้ด้วยกัน ต้องคัดก่อน [1]
สิบสอง รายงานว่าเสร็จเพราะ build ผ่าน build พิสูจน์แค่ว่าคอมไพล์ผ่าน ไม่ได้พิสูจน์ว่าทำงาน [1]
ผมคิดว่าข้อสิบสองคือข้อที่ทีมไทยจำนวนมากยังติด เพราะวัฒนธรรมการรายงานมักจบที่ "เทสต์ผ่านแล้ว" โดยไม่ถามว่าเทสต์นั้นทดสอบอะไร
สองข้อที่ผมเจอเองระหว่างทำชุดนี้
คู่มือมี 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 ตัวเลขนั้นคือผลของเวลา ไม่ใช่เป้าหมาย [6][8]
สอง อย่าลอก 20 agent ตั้งแต่วันแรก ลำดับชั้นของ Chief, manager และ worker ทำงานได้เพราะมี skill และหลักคิดรองรับ ถ้าขาดสองอย่างนั้น การเพิ่ม agent จะเพิ่มงานให้คุณ [7][8]
สาม อย่าลอกการ refactor ใหญ่ทันที การเปลี่ยนสถาปัตยกรรมให้ agent ทำงานถูกตั้งแต่แรกเป็นผลพลอยได้จากงานจริง ไม่ใช่โปรเจกต์แยกที่ทำก่อนมีงาน [8]
บทสรุปของชุดนี้
ถ้าผมต้องสรุปทั้งหกตอนเป็นประโยคเดียว มันคือแบบนี้
ในมุมมองของผม Lauren Tan ไม่ได้เก่งเพราะใช้ agent เยอะ แต่เพราะเธอสร้างระบบที่ทำให้ agent ตรวจงานตัวเองได้ แล้วค่อยเพิ่มจำนวนอย่างช้า ๆ
คุณเริ่มจากงานเดียวที่ทำซ้ำ เกณฑ์ผ่านหนึ่งข้อ หลักฐานหนึ่งชิ้น และ log หนึ่งไฟล์
ที่เหลือคือการทำซ้ำจนมันกลายเป็นนิสัยของทีม
ตอบสั้น ๆ ว่าได้ ถ้า 30 วันแรกคุณยอมจ่ายด้วยการทำมือหนึ่งรอบ เขียนเกณฑ์ให้ได้หนึ่งข้อ และเก็บหลักฐานให้เป็นนิสัย
ผมจะกลับมาเขียนเพิ่มถ้ามีข้อมูลใหม่จากเธอ หรือจากรีโป pstack ที่อัปเดต แล้วพบกันใหม่ครับ
REF
[1] Cursor (2026) · Recipes and pitfalls (คู่มือ pstack ตอนที่ 10). https://github.com/cursor/plugins/blob/main/pstack/docs/guide/10-recipes-and-pitfalls.md
[2] Cursor (2026) · Run work while you sleep (คู่มือ pstack ตอนที่ 7). https://github.com/cursor/plugins/blob/main/pstack/docs/guide/07-overnight.md
[3] 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
[4] Cursor (2026) · Route work through /poteto-mode (คู่มือ pstack ตอนที่ 2). https://github.com/cursor/plugins/blob/main/pstack/docs/guide/02-poteto-mode.md
[5] Cursor (2026) · Principles (คู่มือ pstack ตอนที่ 8). https://github.com/cursor/plugins/blob/main/pstack/docs/guide/08-principles.md
[6] Cursor (2026) · pstack directory (นับจากโครงสร้างไฟล์ ณ 25 ต.ค. 2026). https://github.com/cursor/plugins/tree/main/pstack
[7] Grok (1 ก.ย. 2026) · TL;DR of Lauren Tan workshop on maxing GrokBot. https://x.com/grok/status/2094731064749023668
[8] Lauren Tan (24 มิ.ย. 2026) · Loops You Can Trust. https://x.com/poteto/article/2069824386283319343
Top comments (0)