วิธีสร้างสตาร์ตอัปแบบ AI-native

• นี่คือโมเดลการดำเนินงานแบบใหม่ที่ในขณะที่ AI จัดการงานซ้ำๆ ตอนกลางคืน ผู้ก่อตั้งจะโฟกัสกับการปรับปรุงผลิตภัณฑ์ โดยการเปลี่ยนแปลงที่แท้จริงไม่ได้อยู่ที่การใช้เวลา แต่คือ ความเร็วที่บริษัทเรียนรู้ ทำซ้ำ และพัฒนา
• บริษัทแบบ AI-native เปลี่ยนไปถึงระดับโมเดลการดำเนินงานเอง ใช้คนน้อยลง ประสานงานน้อยลง ให้เอเจนต์ทำงานซ้ำๆ และให้มนุษย์โฟกัสที่ ทิศทาง รสนิยม ความสัมพันธ์ การตรวจสอบ และความรับผิดชอบ
• การเปลี่ยนผ่านดำเนินไปเป็นขั้นตอน ได้แก่ การทำแผนที่งาน การสร้างระบบคอนเท็กซ์ การเลือก automation ที่ง่ายที่สุด การทำให้งานซ้ำๆ กลายเป็นสกิล การ เขียน eval เพื่อตัดสินคุณภาพ และการรันลูปปรับปรุงรายสัปดาห์
• โมเดลถูกเปลี่ยนและปรับปรุงทุกเดือนจนมีความคล้ายกันมากขึ้น ดังนั้นทรัพย์สินเฉพาะของบริษัทจึงเป็น ระบบปฏิบัติการ อย่าง คอนเท็กซ์และ eval
• ในสภาพแวดล้อมที่ทุกคนใช้โมเดลเดียวกัน คูเมืองที่แท้จริงคือ วินัย (discipline) นั่นคือความสม่ำเสมอในการทำแผนที่งานทุกสัปดาห์ สะสมคอนเท็กซ์ เขียน eval และหมุนลูปอย่างต่อเนื่อง

---

การเปรียบเทียบสตาร์ตอัปสองแห่ง

• เปรียบเทียบบริษัทสองแห่งที่ก่อตั้งในเดือนเดียวกันและอยู่ในตลาดเดียวกัน ณ เวลา 9 โมงเช้า
  • บริษัทแรก หัวหน้าฝ่ายปฏิบัติการกำลังจัดการตั๋วซัพพอร์ตที่ค้าง นักวิเคราะห์กำลังทำแดชบอร์ดของสัปดาห์ก่อนใหม่ และผู้ก่อตั้งกำลังติดอยู่กลาง standup เพราะเคสโทรคุยกับลูกค้าที่ไม่มีใครแก้ได้ ทุกคนกำลังตามเก็บปัญหาของเมื่อวานจนผลิตภัณฑ์หยุดนิ่ง
  • บริษัทที่สอง เอเจนต์จัดการทุกอย่างนั้นตลอดทั้งคืนแล้ว ทั้งการจัดหมวดหมู่ตั๋ว อัปเดตแดชบอร์ด และดึง churn risk ออกมาจากบทสนทนา ผู้ก่อตั้งจึงกำลังแก้ปัญหาและปรับปรุงทีมกับผลิตภัณฑ์ไปแล้ว
• ความต่างสำคัญคือ ความเร็วในการเรียนรู้ โดยบริษัทที่สองเรียนรู้ได้เร็วขึ้นทุกวัน ทำให้ leverage สะสมแบบดอกเบี้ยทบต้นตลอดหลายสัปดาห์ หลายเดือน และหลายปี

ขั้นที่ 1 - ทำแผนที่งาน (Map The Work)

• ลิสต์งานซ้ำทั้งหมดที่เกิดขึ้นในช่วง 2 สัปดาห์ที่ผ่านมา เช่น โน้ตจากการคุยกับลูกค้า รีเสิร์ชลีด ดราฟต์ข้อความ outbound การจัดหมวดซัพพอร์ต product QA การ onboarding release note อัปเดตนักลงทุน ตัวชี้วัดรายสัปดาห์ การทำซ้ำบั๊ก การคัดกรองผู้สมัคร การตรวจใบแจ้งหนี้ การติดตามคู่แข่ง เป็นต้น
  • ถ้างานนั้นเกิดซ้ำ ก็เป็นตัวเต็งสำหรับการ encode และในปฏิทินของผู้ก่อตั้งส่วนใหญ่มักมีรายการแบบนี้ 20~40 รายการ
  • ถ้าทีมช่วงเริ่มต้นลิสต์อย่างตรงไปตรงมา มักจะเจองาน 10~15 อย่างที่กลายเป็นรูทีนไปแล้ว

• การจัดระดับ autonomy

  • L1 สำหรับมนุษย์เท่านั้น เช่น การตัดสินใจเชิงกลยุทธ์ การรับคนขั้นสุดท้าย การคืนเงินก้อนใหญ่ การลงนามทางกฎหมาย การสื่อสารกับบอร์ด
  • L2 คือ AI เตรียมไว้ มนุษย์อนุมัติ เช่น ดราฟต์อัปเดตนักลงทุน redline สัญญา การเขียนหน้า pricing ใหม่ และซัพพอร์ตแมโคร
  • L3 คือ AI ลงมือทำ มนุษย์กำกับดูแล เช่น การคัดแยกอินบาวด์ การส่งต่อ meeting note การเสริมข้อมูลลีด และการสร้างเทสต์
  • L4 คือทำงานอัตโนมัติได้ภายในขอบเขตที่ชัดเจน เช่น การติดตามคู่แข่ง การสร้างรีพอร์ตกลางคืน การดึงข้อมูลจากใบแจ้งหนี้ของเวนเดอร์ที่รู้จักอยู่แล้ว และการตรวจจับความผิดปกติแบบง่าย

• เวิร์กโฟลว์น่าเบื่อมักชนะ

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

• งานที่ไม่ควร automate

  • ตัดงานที่เกิดไม่บ่อย ไม่ชัดเจน ต้องการความไว้วางใจสูง หรือยังไม่นิ่งออกไป
  • ทีมของ C.H. Robinson เคยดันงานคัดแยกอีเมลวันละ 10,000 ฉบับขึ้นไปถึง L4 แต่สุดท้ายต้องถอยกลับมา L2 เพราะกำกับดูแลไม่ไหว ปริมาณงานกลบต้นทุนของการคัดผิด
  • ถ้าอธิบายไม่ได้ว่าผลงานที่ดีหน้าตาเป็นอย่างไร แปลว่ายังไม่พร้อมสำหรับการ encode และถ้าผลลัพธ์ผิดเพียงครั้งเดียวอาจทำลายความสัมพันธ์กับลูกค้าได้ ก็ควรเดินช้าๆ

• การตั้งต้น

  • เริ่มจากเอกสาร 1 หน้าและ 3 เวิร์กโฟลว์ ได้แก่ ส่วนบุคคล (การคัดแยก inbox, daily brief, ดราฟต์อัปเดตนักลงทุน), งานที่เผชิญหน้ากับลูกค้า (สรุปการโทร, จัดหมวดหมู่ตั๋ว, เสริมข้อมูลลีด), และงานภายใน (สร้างเทสต์, ดึงข้อมูลใบแจ้งหนี้, เขียนคำอธิบายตัวชี้วัดรายสัปดาห์)
  • การทดลองมากเกินไปพร้อมกันจะทำให้สมาธิกระจาย และนำไปสู่โหมดล้มเหลวที่พบบ่อยที่สุด คือมี pilot ค้างอยู่ 20 ตัวแต่ไม่เสร็จสักตัว

ขั้นที่ 2 - สร้างระบบคอนเท็กซ์ (Build The Context System)

• คอนเท็กซ์คือ operating memory ของสตาร์ตอัปแบบ AI-native เป็นที่เก็บทุกอย่างที่บริษัทรู้เกี่ยวกับตัวเองไว้ในจุดที่เอเจนต์อ่านได้
  • โมเดลเปลี่ยนได้ แต่คอนเท็กซ์คือทรัพย์สินเฉพาะของบริษัทอย่างแท้จริง มันคือสิ่งที่แยกเอเจนต์ที่ทำงานเหมือน co-founder ออกจากเอเจนต์ที่ทำงานเหมือนพนักงานชั่วคราวที่สับสน
  • ถ้าใช้เวลาเขียนผลลัพธ์ใหม่มากกว่าตรวจทาน ปัญหาไม่ได้อยู่ที่พรอมป์ต์หรือโมเดล แต่อยู่ที่เอเจนต์ยังรู้จักบริษัทไม่พอ

• วิธีวินิจฉัยรายสัปดาห์

  • เอางานตัวแทนมาหนึ่งงาน แล้วให้เอเจนต์ตัวใหม่ที่มีเพียง workspace context เสนอการกระทำถัดไป 3 อย่าง
  • ถ้ามีข้อเสนอที่แข็งแรงอย่างน้อย 2 ข้อ แปลว่าคอนเท็กซ์ทำงานได้ดี แต่ถ้าได้คำตอบทั่วไป 3 ข้อ แปลว่าคอนเท็กซ์ยังอ่อนเกินกว่าจะกู้ด้วยพรอมป์ต์

• ใช้ Git repository เป็นฐาน

  • เริ่มจาก Git repository กลางเพียงอันเดียวที่ทุกคนในทีมและทุกเอเจนต์อ่านได้ ใช้ version control ได้ ดู diff ได้ ทั้งคนและเอเจนต์อ่านได้ และไม่ผูกกับ runtime ของเวนเดอร์รายใดรายหนึ่ง
  • ภายในวันที่ 7 workspace อาจประกอบด้วยรูทเดียวที่มี CLAUDE.md, context/company.md, context/product.md, context/customers.md, context/lessons.md และ GTD.md สำหรับงานที่กำลังทำอยู่
  • รักษาไว้ให้เป็นข้อความที่เขียนด้วยมือ 40~60 บรรทัด ดีกว่าข้อความไร้แก่น 400 บรรทัดที่ถูกสร้างขึ้นมาพร้อมลิสต์ยาวเหยียดของสิ่งที่ควรหลีกเลี่ยง

• แบ่งตามขอบเขตสิทธิ์

  • เมื่อโตขึ้น ให้ใช้ repository บริษัทที่แชร์ร่วมกัน + repository ส่วนตัวตามฟังก์ชัน (sales, product, engineering, finance, support) หรือ repository ส่วนตัวตามโปรเจกต์/ลูกค้า + รูทที่แชร์ทั้งบริษัท
  • ในระดับ enterprise ให้ใช้ private Git server เช่น Gitea, GitHub Enterprise หรือ GitLab ที่กำหนดสิทธิ์ได้ระดับไดเรกทอรีและ repository
  • Goose อินเทอร์นัลฮาร์เนสของ Block อ่านสตรีมอาร์ติแฟกต์เดียวกันด้วย scope ตามบทบาท และทันทีที่ scope เหลื่อมกัน มันจะเริ่มผสมบริบทของคำพูดสาธารณะกับดีลส่วนตัวเข้าด้วยกัน ดังนั้น boundary จึงสำคัญมาก

• ข้อมูล 3 ประเภทที่เข้าไปในระบบ

  • ตัวเชื่อมต่อ - ดึงข้อมูลภายนอกจาก SaaS, API, MCP server, อีเมล, ปฏิทิน, CRM, ซัพพอร์ต, analytics, GitHub, Linear, Stripe, warehouse และเอกสาร
    • ทุกคอนเน็กเตอร์ต้องมีตัวระบุ สิทธิ์ตามขอบเขต audit log และ credential ที่ถูกจัดการไว้ ไม่เช่นนั้นมันจะกลายเป็นช่องโหว่ความปลอดภัยที่ใหญ่ที่สุด โดยเลเยอร์ IAM อย่าง Zitadel จะดูแลวินัยด้านตัวตน
    • งานรันโค้ด MCP ของ Anthropic ใช้คอนเท็กซ์ราว 150,000 โทเคน เหลือราว 2,000 โทเคน หรือ ลดลง 98.7% เมื่อเทียบกับแนวทางที่พรีโหลด definition ของทุกเครื่องมือล่วงหน้าด้วยรูปแบบ filesystem ของโฟลเดอร์เซิร์ฟเวอร์
  • ข้อมูลที่บริษัทสร้างขึ้น - สเปก สรุปลูกค้า การตัดสินใจ บทเรียน โน้ตโปรเจกต์ กฎการปฏิบัติงาน โดยค่าเริ่มต้นใช้ Markdown
    • กฎที่สำคัญที่สุดคือ แยกระหว่างต้นฉบับ (raw) กับข้อมูลสกัด (distilled) เช่น transcript ของการโทรคือ raw ส่วนการตัดสินใจจากสายนั้น ข้อคัดค้านของลูกค้า ผู้รับผิดชอบติดตามต่อ และความเสี่ยงต่อการต่ออายุคือ distilled ซึ่งเป็นสิ่งที่เอเจนต์ใช้ค้นหาจริง
    • decision log ควรถูกเก็บแบบ append-only ทีละหนึ่งบรรทัด เพื่อให้เหตุผลยังตามมากับข้อสรุป
  • ฐานข้อมูลและสตรีม - เช่นข้อมูลผลิตภัณฑ์ใน Postgres, ข้อมูลการตลาดใน warehouse และ analytics event ซึ่งเดิมก็มีแหล่งอยู่แล้ว
    • อย่าก๊อปลง Markdown แบบไม่คิด ให้ฐานข้อมูลเป็นต้นทางต่อไป มอบผู้ใช้อ่านอย่างจำกัดให้เอเจนต์ จัดทำเอกสารสคีมาในไฟล์สำหรับเอเจนต์อย่าง data-models/postgres.md และระบุ query/การเขียนที่อนุญาตไว้ให้ชัด
    • ตั้งค่าเริ่มต้นไม่ให้เอเจนต์ลบข้อมูล production ได้ โดยกรณี Replit ช่วงกลางปี 2025 ที่ coding agent ลบ production DB ระหว่างเซสชัน เป็นเครื่องเตือนว่าคำสั่งในพรอมป์ต์ไม่ใช่ security boundary

• เวอร์ชันขั้นสูงและการติดตามที่มา

  • context graph แบบมีโครงสร้าง - ก่อนให้เอเจนต์ค้นหา ให้นำต้นฉบับไปแปลงเป็นเอนทิตีและความสัมพันธ์ เช่น บุคคล บริษัท ข้อคัดค้าน คำมั่นสัญญา feature request ความเสี่ยงต่อการต่ออายุ งานติดตาม วันที่ การตัดสินใจ และลิงก์ไปยังแหล่งที่มา
    • แทนที่จะเก็บ transcript ไว้เฉยๆ ให้สกัดเนื้อหาออกมาและเชื่อมสายสนทนาของบุคคลหรือโปรเจกต์เดียวกันเข้าด้วยกัน เพื่อให้ตอบคำถามอย่าง "ความเสี่ยงต่อการต่ออายุของ Vandelay Industries คืออะไร?" ได้พร้อมอ้างอิงบรรทัดคำพูดที่ถูกต้อง
  • ทุกสรุปต้องไล่ย้อนกลับไปหาที่มาได้เสมอ ไม่ว่าจะเป็น transcript, ticket, commit, invoice หรือแถวข้อมูลใน DB ถ้าไม่มีที่มา สรุปที่ฟังดูน่าเชื่อแต่ตรวจสอบไม่ได้จะสะสมขึ้น และความเชื่อมั่นต่อเอเจนต์ทั้งระบบจะพังทลายตั้งแต่คำตอบผิดครั้งแรก
    • เมื่อมีที่มา เอเจนต์จะถูกตรวจสอบย้อนหลังได้ ทำให้สมาชิกทีมคลิกครั้งเดียวเพื่อเช็กต้นทางและคลี่คลายความเห็นต่างได้ภายในไม่กี่วินาที

ขั้นที่ 3 - เลือก automation ที่ง่ายที่สุด (Choose The Simplest Automation)

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

• การใช้งานตามประเภทเครื่องมือ

  • สคริปต์ - ขั้นตอนแบบกำหนดแน่นอน (ส่งออกรายงาน, แปลง CSV, รันทดสอบ, ตรวจลิงก์, ตรวจสอบ JSON, ฟอร์แมต weekly metrics pack)
  • มนุษย์ที่มี AI ช่วย - เอาต์พุตที่ยังต้องใช้วิจารณญาณก่อนออกจากบริษัท (อัปเดตนักลงทุน, อีเมลผู้ก่อตั้ง, ข้อความบนหน้าราคา, โน้ตสัญญา)
  • เวิร์กโฟลว์ - เมื่อรู้ลำดับขั้นล่วงหน้า (รวบรวมคอล→สรุป→ดึงข้อโต้แย้ง→เขียนโน้ต CRM→สร้างการติดตามผล), โดยเอนจินอย่าง LangGraph, Temporal, Inngest, Prefect จะรับผิดชอบเรื่องลำดับ, การ retry, และ observability
  • เอเจนต์ - เมื่อไม่สามารถกำหนดเส้นทางล่วงหน้าได้ (สืบสวนบั๊กในโปรดักชัน, วิจัยตลาด, เคสซัพพอร์ตผิดปกติ, บัญชีลูกค้าที่ซับซ้อนยุ่งเหยิง)
    • bb agent ของ Browserbase เป็นเอเจนต์อเนกประสงค์แบบเผชิญหน้าผ่าน Slack ที่โหลดไฟล์สกิลและสิทธิ์แบบ scoped ต่างกันตามงาน — ดีกว่าการสร้างบอตแยกตามงาน เพราะบอตเหล่านั้นจะค่อย ๆ เพี้ยนไปคนละทิศทางเมื่อเวลาผ่านไป

• Harness - ชั้นความปลอดภัย 6 ขั้น

  • Preflight - ตรวจคอนเท็กซ์และสิทธิ์ก่อนที่เอเจนต์จะใช้โทเค็น
  • Plan - แยกย่อยงานและเปิดให้เห็นขั้นเสนอแผน
  • Approve - ให้มนุษย์หรือโมเดลตัดสินเป็นด่านกั้นแผนที่ไม่ดี ก่อนลงมือทำ
  • Execute - ลงมือปฏิบัติงาน
  • Verify - ตรวจสอบเอาต์พุตด้วยการทดสอบ, schema, rubric, และตัวอย่าง
  • Log - บันทึกสิ่งที่เกิดขึ้นลงใน execution file เพื่อให้รอบถัดไปมีคำตอบที่ถูกต้อง

• ใส่ guardrail ไว้ในโค้ดและการตั้งค่า (ไม่ใช่ในพรอมป์ต์)

  • พรอมป์ต์ว่า "อย่าลบข้อมูลโปรดักชัน" ไม่ใช่ขอบเขตความปลอดภัย
  • รายการที่ต่อรองไม่ได้ — เพดานการรันและค่าใช้จ่ายรายวัน, เพดานการ retry, ความลึกสูงสุดของการเรียกเครื่องมือ, credentials แบบ scoped ต่อเอเจนต์, ห้ามเขียนลงโปรดักชันโดยไม่มีการอนุมัติ, ห้าม auto-merge โค้ด, kill switch ระดับทั้ง fleet
  • เหตุการณ์ recursive generation ที่เกิดขึ้นตลอดปี 2025 (เอเจนต์เรียกลูกเอเจนต์ซ้ำไปเรื่อย ๆ) ทำให้เกิดต้นทุนจริงก่อนที่ harness จะตามทัน — ต้องวางเพดานไว้ที่ runtime ก่อนที่โมเดลจะมีโอกาสเพิกเฉยต่อคำสั่ง

ขั้นที่ 4 - เข้ารหัสสกิลและ eval (Encode Skills And Evals)

• ทั้งหมดจนถึงตรงนี้ยังเป็นแค่การเตรียมการ ส่วนเครื่องยนต์ที่ทำให้บริษัทเติบโตแบบทบต้นทีละน้อยทุกสัปดาห์ คือการเข้ารหัสงานซ้ำให้เป็นสกิลและให้คะแนนด้วย eval
  • สกิลคือคำแนะนำที่ใช้ซ้ำได้พร้อมตัวอย่างสำหรับงานที่ทำซ้ำ — หลังจากทำด้วยมือสองครั้งแล้วค่อยเข้ารหัสส่วนที่ซ้ำ
  • ทุกสกิลต้องมีรูปแบบที่ชัดเจน — ขอบเขต, อินพุต, คอนเท็กซ์ที่ต้องโหลด, ขั้นตอน, รูปแบบเอาต์พุต, ตัวอย่าง, กฎการ escalate, เจ้าของ, execution log
  • ถ้าไม่ได้ระบุว่ารับอะไร ส่งคืนอะไร ขอความช่วยเหลือเมื่อไร และใครเป็นคนดูแล สิ่งนั้นไม่ใช่สกิล แต่เป็นพรอมป์ต์ยาว ๆ

• ตัวอย่างเทมเพลตสกิล (customer-call-synthesis)

  • Scope: คอลขายหลังได้ transcript แล้ว / Inputs: transcript, ประวัติบัญชี, product context, โอกาสที่กำลังเดินอยู่
  • Load: ICP, ราคา, product roadmap, taxonomy ของข้อโต้แย้ง / Steps: ดึงข้อเท็จจริง→จัดกลุ่มข้อโต้แย้ง→ระบุความเสี่ยง→เขียน follow-up
  • Output: โน้ต CRM, customer brief, feature request, next action / Examples: คอลก่อนหน้า 3 ครั้งพร้อมโน้ตที่คาดหวัง
  • Escalate: ประเด็นกฎหมายหรือความปลอดภัย, ความเสี่ยงการ churn, ราคาแบบ enterprise / Owner: revenue lead / Eval: คอลเก่า 30 ครั้งพร้อมฟิลด์ที่คาดว่าจะดึงได้

• เริ่มจากสกิลที่เป็นมิตรกับผู้ก่อตั้ง

  • สรุปคอลลูกค้า - ดึงข้อโต้แย้ง, feature request, ความเสี่ยง, คำมั่นสัญญา, next action จาก transcript ดิบ
  • จัดหมวด inbox - แยกข้อความนักลงทุน, ลูกค้า, การจ้างงาน, งานปฏิบัติการ และร่างคำตอบสำหรับ 3 หมวดแรก
  • อัปเดตนักลงทุน - เขียนคำบรรยายจาก metrics และการตัดสินใจ พร้อมอ้างอิงทั้งสองด้าน
  • วิเคราะห์หน้าราคา - เทียบหน้าเว็บปัจจุบันกับ log ข้อโต้แย้งล่าสุดของลูกค้า
  • คำบรรยาย metrics รายสัปดาห์ - อธิบายว่าอะไรเปลี่ยน, อะไรพัง, และอะไรที่ควรตรวจ
  • สร้างเทสต์ - แปลงสเปกให้เป็นเทสต์และร่าง PR

• eval 3 ชั้น (สะสมตามลำดับ)

  • ชั้นแรก, คำตอบจริงที่ติดป้ายกำกับด้วยมือ — มนุษย์ระบุว่าเอาต์พุตที่ดีจากตัวอย่างจริงหน้าตาเป็นอย่างไร
  • ชั้นที่สอง, การตรวจแบบกำหนดแน่นอน — ให้คำตัดสินชัดเจนโดยไม่มีต้นทุน (schema ถูกต้อง, ตัวเลขตรงกับแหล่งข้อมูล, ลิงก์เปิดได้, มีการอ้างอิงอยู่จริง, เทสต์ผ่าน)
  • ชั้นที่สาม, การตัดสินโดย LLM — ใช้เฉพาะส่วนที่การตรวจแบบกำหนดแน่นอนไปไม่ถึง (คุณภาพงานเขียน, อารมณ์, ความสอดคล้องกับบรีฟ) โดยโมเดลเล็กและเร็วก็เพียงพอ แต่ก่อนจะเชื่อถือได้ต้องปรับเทียบด้วยตัวอย่างที่มนุษย์ทำเครื่องหมายไว้

• กรณีศึกษา: สรุปคอลลูกค้า

  • revenue lead ทำเครื่องหมายคอลเก่า 30 ครั้ง — ข้อเท็จจริงสำคัญ, ข้อโต้แย้ง, ความเสี่ยง, การติดตามผล
  • การยืนยันแบบกำหนดแน่นอน — ความถูกต้องของชื่อ, มูลค่าในสัญญา, สัปดาห์ของวันติดตามผล; ส่วนการตัดสินว่าบรีฟฟังดูเหมือนคอลจริงหรือไม่ ให้ LLM เป็นผู้ตัดสิน
  • หลังรันราว 50 ครั้ง มักมีสองอย่างที่พังซ้ำ ๆ — ติดตามผู้พูดไม่สำเร็จเมื่อมีคนในคอลเกิน 3 คน หรือรวมข้อโต้แย้งคนละเรื่องเข้าด้วยกัน — จึงแก้ที่ระดับคลัสเตอร์และเขียนใหม่จนทำงานสม่ำเสมอ

• กรณีศึกษา: การจัดประเภทลีดแบบ outbound

  • ผู้ก่อตั้งติดป้ายลีดเก่า 300 รายว่าเหมาะกับ ICP หรือไม่แบบ yes/no
  • การตรวจเชิงกล — บริษัทมีอยู่จริงหรือไม่, เว็บไซต์โหลดได้หรือไม่, มีการกรอกจำนวนพนักงานหรือไม่ / ที่เหลือใช้การตัดสินโดย LLM เทียบกับคำอธิบาย ICP
  • เมื่อมี eval พร้อมแล้ว ลูปพัฒนาพรอมป์ต์โอเพนซอร์ส (GEPA, DSPy) จะเขียนพรอมป์ต์จัดประเภทใหม่ข้ามคืนโดยเทียบกับ labels — ผู้ก่อตั้งไม่อ่านพรอมป์ต์สุดท้าย และมีเพียงผลตัดสินของ eval เท่านั้นที่สำคัญ

• ความสุกงอมของ eval 5 ขั้น

  • 1. ตรวจตัวอย่างเดียวด้วยมือ → 2) ให้คะแนนเคสจำนวนน้อยด้วย rubric ที่เขียนไว้ → 3) ใช้ rubric นั้นกับเคสเก่า 20–300 รายการ → 4) ทดสอบด้วยชุด holdout ที่เอเจนต์ไม่เคยเห็น → 5) ติดตามตัวชี้วัดธุรกิจที่สกิลนั้นตั้งใจจะขยับ

• รักษาสภาพที่ดีหลังเปิดใช้ — ตัวเลข 6 ตัวทุกสัปดาห์

  • acceptance rate, อัตรา override, ต้นทุนต่อการรัน, cycle time, เวลารีวิว, จำนวน incident
  • acceptance rate คือหัวใจ — ถ้าต่ำกว่าราว 70% (นับการแก้เล็กน้อยว่า accepted) แปลว่ายังไม่พร้อมยกระดับความเป็นอัตโนมัติ
  • เมื่อ acceptance rate ต่ำ การเขียนพรอมป์ต์ใหม่แทบไม่เคยเป็นคำตอบที่ถูกต้อง โดยปกติมักเป็นหนึ่งในสี่อย่าง — เพิ่มคอนเท็กซ์ที่ runtime, ทำขอบเขตสกิลให้แคบลง, เพิ่มตัวอย่างการทำงานจริงลงในไฟล์, เขียนกฎการ escalate ให้ชัดสำหรับเคสที่ไม่ควรรับงานนั้นมาตั้งแต่แรก

ขั้นที่ 5 - ทำให้ทีมเป็น AI-native (Make The Team AI-Native)

• ผู้ก่อตั้งต้องเริ่มก่อน — วิธีที่เร็วที่สุดในการย้ายทีมไปสู่รูปแบบการทำงานใหม่ คือสาธิตให้เห็นสด ๆ ภายในบริบทของบริษัท
  • สาธิต morning brief ที่ดึงมาจาก calendar, inbox, Slack ข้ามคืน, สรุปลูกค้าจากคอลเมื่อวาน, PR เทสต์ที่เอเจนต์รันเทียบกับสเปก, และร่างอัปเดตนักลงทุนที่ทำจาก metrics pack ล่าสุด
  • เป้าหมายคือ การปรับเทียบ — ให้เห็นด้วยตาตัวเองว่าชั้นเอเจนต์ทำอะไรได้และทำอะไรไม่ได้
  • Jack Dorsey ใช้เวลาหลายชั่วโมงทุกเช้าตลอดปี 2025 ใช้เครื่องมือเหล่านี้ด้วยตัวเองก่อนปรับโครงสร้าง Block — นำไปสู่การปรับลดโครงสร้างครั้งใหญ่เพื่อเพิ่มประสิทธิภาพ และการตัดสินใจนั้นก็มาจากผู้นำที่ได้ใช้เอเจนต์จริงด้วยตัวเอง

• ติดตั้งตั้งแต่วันแรก, จบ onboarding ด้วยผลลัพธ์

  • ทุกคนต้องออกจากเซสชันแรกพร้อมผลงานที่ deploy ได้ในวันนั้น (customer brief ที่จัดระเบียบแล้ว, support macro, test PR, บทวิจารณ์หน้าราคา) — การฝึกอบรมที่สร้างงานจริงไม่ได้จะถูกลืมภายในสัปดาห์ถัดไป
  • เครื่องมือ Glass ของ Ramp เติบโตจากผู้ใช้รายวัน 20 คนเป็นราว 700 คนใน 3 เดือน ด้วยกติกาว่าทุก onboarding session ต้องจบด้วยการเพิ่มสกิลหรือ artifact ของพนักงานใหม่ 1 ชิ้นเข้าไปในคลังกลางที่ใช้ร่วมกัน

• บทบาทของมนุษย์ใหญ่ขึ้น

  • มนุษย์เป็นผู้ออกแบบระบบ, ดูแลความสัมพันธ์, ตัดสินเอาต์พุต, และรับผิดชอบ; เอเจนต์เป็นฝ่ายลงมือทำ
  • สมาชิกทีมที่ทำได้แค่งานแคบ ๆ จะถูกเปิดเผยข้อจำกัดในโมเดลนี้ ส่วนคนที่เปลี่ยนวิจารณญาณให้เป็นคำสั่ง, ตัวอย่าง, และ eval ได้ จะยิ่งมีค่ามากกว่าเดิม

• การจ้างงานก็เปลี่ยนไป

  • เกณฑ์การเปิดตำแหน่งสูงขึ้น — บางส่วนที่เมื่อก่อนต้องจ้างคน ตอนนี้กลายเป็นสกิลแล้ว จึงสร้างบทบาทใหม่เฉพาะงานที่ยังต้องใช้มนุษย์จริง ๆ
  • ตอนจ้างงาน แทนที่จะดูความรู้รอบตัวจากนิตยสาร ให้มอบโปรเจกต์ใหญ่ที่ทำมือให้ไม่ทันในเวลาที่กำหนด แล้วสังเกตว่าผู้สมัครบังคับบัญชาเอเจนต์อย่างไร — ดูวิจารณญาณ, รสนิยม, และความสามารถในการกู้สถานการณ์เมื่อเอเจนต์ออกนอกลู่นอกทาง
  • ตัวอย่างจริง — นักวิเคราะห์ต้องทำรายงานจริงให้เสร็จภายใน 3 ชั่วโมงตั้งแต่รวบรวมแหล่งข้อมูล, ดึงหลักฐาน, จนถึงบรีฟที่ขัดเกลาแล้ว; วิศวกรต้องคัดลอกพื้นผิวโปรดักต์จริงหรือสร้างเครื่องมือภายในจากสเปกภายใน 1 วัน (รวมเทสต์); ผู้สมัครสาย growth ต้องทำ market map และแผนแคมเปญสำหรับ 50–100 บริษัท (สแครป, จัดกลุ่ม, เขียน, จัดลำดับความสำคัญ) — หัวใจสำคัญคือทุกอย่างต้องเป็นงานที่ทำมือให้เสร็จไม่ทันภายในเวลาที่กำหนด

ขั้นตอนที่ 6 - บริหารสตาร์ตอัปด้วยวงจรป้อนกลับ (Run As A Feedback Loop)

• สตาร์ตอัปแบบ AI-native ปรับปรุงระบบปฏิบัติการทุกสัปดาห์ แล้ววนกลับไปเริ่มใหม่อีกครั้ง
  • สิ่งที่ต้องทบทวน ได้แก่ สิ่งที่เอเจนต์ทำ จุดที่มนุษย์เข้าไป override, eval ที่ล้มเหลว, บริบทที่ขาดหายไป, ทักษะที่ต้องทำให้แคบลง, workflow ที่ควรยกเลิก, และ workflow ที่ควรเพิ่มระดับความอัตโนมัติ

• รันสองลูปพร้อมกัน

  • ลูปด้านใน - ปรับปรุงงานที่มีอยู่แล้ว (ต้นทุนต่อการรัน↓, cycle time↓, incident↓, เวลารีวิวต่อ artifact↓)
  • ลูปด้านนอก - สำรวจสิ่งต่อไปนี้ (เซกเมนต์ลูกค้าใหม่, ไอเดียผลิตภัณฑ์, การปรับราคา, พาร์ตเนอร์ชิป, ความเคลื่อนไหวของคู่แข่ง, การเปลี่ยนแปลงด้านกฎระเบียบ, ความเสี่ยงการ churn) โดย background agent ป้อนตัวเลือกที่เป็นไปได้ตลอด 24 ชั่วโมง และให้มนุษย์เลือกสิ่งที่จะตามต่อ

• Software factory (ส่วนที่ใหญ่ที่สุดของลูปด้านใน)

  • มนุษย์เขียนสเปกและการทดสอบ แล้วเอเจนต์จึงนำไป implement ตามนั้น, การตรวจสอบแบบ deterministic รันได้เอง และให้มนุษย์ตรวจทานก่อน merge
  • เริ่มจากจุดที่เกณฑ์การยอมรับชัดเจนและขอบเขตผลกระทบเล็ก เช่น การสร้าง test, การอัปเกรด dependency, migration, เครื่องมือภายใน, integration scaffold, สคริปต์ QA, การแก้ไขความปลอดภัยอัตโนมัติ
  • กฎเหล็กสองข้อ - ไม่มีอะไร merge อัตโนมัติ, และไม่มีเอเจนต์ตัวใดเขียนลง production
    • แม้แต่ Cursor เองก็ยังคงมีด่านรีวิวโดยมนุษย์ก่อน merge ไปจนถึงต้นปี 2026 ขณะรัน autonomous cloud agent ขนาดใหญ่ และด่านนี้เองที่ทำให้ขยายส่วนที่เหลือได้อย่างปลอดภัย

• ระบบเรียนรู้ตลาด (ลูปด้านนอก)

  • บันทึกการโทร, การดึงข้อโต้แย้ง, การจัดกลุ่ม feature request, การติดตามคู่แข่ง, การสังเกตการเปลี่ยนแปลงการใช้งาน, การอ่านแพตเทิร์นจาก support, การศึกษาดีลที่แพ้
  • เปลี่ยนสิ่งที่ค้นพบให้เป็นสมมติฐาน แล้วทดสอบตัวที่แข็งแรงที่สุดผ่านบทสนทนากับลูกค้า, การทดสอบ landing page, การทดลองผลิตภัณฑ์, คิวรีใหม่กับข้อมูล
  • ให้เอเจนต์เป็นผู้เสนอและให้มนุษย์เป็นผู้เลือก - หากมอบทั้งการเสนอและการตัดสินใจเชิงกลยุทธ์ให้เอเจนต์ จะลงเอยด้วยฉันทามติแบบกลาง ๆ หรือไม่ก็ไต่เนินเพื่อ optimize เมตริกที่ดันขึ้นได้ง่ายที่สุด

• หัวใจของการพัฒนาตัวเองระดับบริษัท = ความสามารถในการเขียน eval

  • ทำ hand-label ตัวอย่างหลายร้อยรายการว่า ดี/ไม่ดี แล้วสร้าง eval เพื่อเชื่อมเข้ากับลูปพัฒนา prompt - เฟรมเวิร์กอย่าง GEPA และ DSPy ใช้ reflection model ขนาดเล็กเพื่อเสนอการกลายพันธุ์ของ prompt จากนั้น eval จะจัดอันดับบนชุด labels แล้ว deploy ตัวชนะ ทำซ้ำ
  • ผู้ก่อตั้งควรเขียน eval และอ่านคลัสเตอร์ของความล้มเหลว แต่ไม่จำเป็นต้องเขียนหรืออ่าน prompt ที่วิวัฒน์ขึ้นมา
  • สิ่งที่เป็นคอขวดไม่ใช่ความสามารถของเอเจนต์ แต่คือคุณเข้ารหัสเกณฑ์ของสิ่งที่เรียกว่า “ดี” ได้หรือไม่ - การเขียนโค้ดช่วยได้แต่ไม่ใช่คอขวด และผู้เชี่ยวชาญโดเมนที่สามารถทำเครื่องหมายผลลัพธ์ว่า ดี/ไม่ดี ได้อย่างน่าเชื่อถือ ก็สามารถหมุนทั้งลูปนี้ได้
  • eval คือ artifact แกนหลักที่รับน้ำหนักทั้งหมดไว้ และทันทีที่การเขียน eval หยุดลง การเติบโตแบบทบต้นของบริษัทก็หยุดตาม

บทสรุป

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