ก่อนขายแอปที่สร้างด้วย AI ให้ลูกค้าคนแรก ลองตอบให้ได้ว่า เมื่อระบบทำงานผิด ใครจะได้รับผลกระทบ และเราจะรู้ได้อย่างไรว่าผิด คำตอบนี้ช่วยกำหนดได้ทั้งขอบเขตสินค้าที่ควรเริ่มขายและเรื่องที่ต้องเรียนเพิ่มก่อนส่งมอบ
ในบทสนทนา How to Actually Build & Sell Software with AI as a Non-Techie ของ Nate Herk กับ Dave Ebbelaar ประเด็นสำคัญคือเส้นทางจากเครื่องมือใช้เองไปสู่ซอฟต์แวร์ที่ธุรกิจอื่นต้องพึ่งพา Dave เล่าว่าเขาใช้ coding agent สร้างโค้ดให้ แต่ยังต้องกำหนดสิ่งที่ต้องการ ตรวจผล และเข้าใจโครงสร้างของระบบที่กำลังสร้าง
สำหรับคนทำธุรกิจคนเดียว บทสนทนานี้ช่วยให้เลือกได้ว่าจะเริ่มจากงานขนาดไหน ต้องมีหลักฐานอะไรจึงค่อยขยาย และควรขายเป็นบริการติดตั้งหรือผลิตภัณฑ์ที่ลูกค้าสมัครใช้เอง ตัวอย่างแอปพิมพ์ตามเสียงและงานบริการลูกค้าด้านล่างมาจากคลิป ส่วนตัวอย่างงานใบเสนอราคาเป็นข้อเสนอประยุกต์ของบทความ
บันไดสี่ขั้นช่วยเลือกความรับผิดชอบที่จะรับเพิ่ม
ช่วง 12:42–17:20 Dave แบ่งซอฟต์แวร์ออกเป็นสี่ลักษณะตามคนที่ใช้และวิธีส่งมอบ แต่ละขั้นทำให้เราเริ่มมีเรื่องที่ต้องดูแลเพิ่มขึ้น
- เครื่องมือใช้เอง อาจรวมงานที่เคยกระจายอยู่หลายแอป หรือแก้ปัญหาเฉพาะตัว เรารู้บริบทของข้อมูลและเห็นข้อผิดพลาดด้วยตัวเองได้ง่ายกว่า
- เครื่องมือภายในทีม คนอื่นเริ่มใช้ร่วมกัน ต้องรู้ว่าใครเข้าถึงข้อมูลชุดไหนได้ และใครดูแลเมื่อขั้นตอนทำงานสะดุด
- ซอฟต์แวร์พร้อมบริการติดตั้ง เรานำระบบไปขายให้ธุรกิจอื่น พร้อมปรับให้เข้ากับงานของลูกค้า ขอบเขตการปรับแต่ง การดูแล และความรับผิดชอบต่อข้อมูลจึงต้องชัดขึ้น
- ผลิตภัณฑ์ที่สมัครใช้เอง ลูกค้าสร้างบัญชีและเริ่มใช้โดยไม่ต้องให้เราติดตั้งทีละราย ระบบต้องรองรับผู้ใช้ที่มีบริบทหลากหลาย และเราอาจไม่ได้อยู่ด้วยตอนเขาพบปัญหา
Dave เตือนเรื่องการข้ามจากการทดลองไปขายระบบที่บริษัทอื่นต้องพึ่งพาทันที โดยยังไม่รู้ว่าข้อมูลไหลผ่านส่วนใดบ้าง การเริ่มจากใช้เองเปิดโอกาสให้เรียนรู้จากข้อผิดพลาด ก่อนเพิ่มคนที่ได้รับผลกระทบ
อย่างไรก็ตาม บันไดนี้เป็นกรอบคิดเรื่องขอบเขตงาน ไม่ใช่คะแนนรับรองความปลอดภัย เครื่องมือที่มีผู้ใช้คนเดียวแต่อ่านข้อมูลลูกค้าทั้งบริษัทก็ต้องระวังมาก สำหรับคนทำงานคนเดียว ควรพิจารณาชนิดข้อมูลและสิ่งที่ระบบมีสิทธิ์ทำควบคู่กับจำนวนผู้ใช้เสมอ
อีกข้อที่นำไปใช้ได้คือ เราอาจทำธุรกิจอยู่ที่ขั้นบริการติดตั้งได้ โดยไม่จำเป็นต้องรีบไปถึงระบบสมาชิก หากลูกค้าแต่ละรายมีขั้นตอนต่างกัน การช่วยปรับงานและพาคนเริ่มใช้เป็นส่วนหนึ่งของสิ่งที่เราส่งมอบได้
เริ่มสร้างเร็วได้ เมื่อบอกได้ว่ากำลังทดลองอะไร
ช่วง 21:04–27:03 Dave เล่าว่าเขาใช้เอกสารแผนยาว ๆ น้อยลง และเริ่มจากบอกสิ่งที่ต้องการให้ agent สร้าง จากนั้นทดลองใช้และแก้จากสิ่งที่เห็นจริง เขาพบว่าหลายครั้งเราจะรู้ว่าต้องการอะไรชัดขึ้นเมื่อมีของให้ลอง
รายละเอียดที่ควรเก็บมาด้วยคือ เขาทดลองบน branch แยก ซึ่งเป็นชุดการเปลี่ยนแปลงที่ยังไม่ถูกส่งเข้าใช้งานจริง ประสบการณ์ของเขายังช่วยให้เห็นว่าควรยอมรับหรือแก้ส่วนใด คนเริ่มต้นจึงควรยืมวิธีทดลองจากเขา พร้อมกำหนดขอบเขตที่ตัวเองตรวจได้
ตัวอย่างสมมติของบทความ: หากคุณรับทำใบเสนอราคาให้ธุรกิจเล็ก ๆ งานแรกอาจเป็นเครื่องมือที่อ่านรายการความต้องการแล้วร่างรายการสินค้าให้เจ้าของตรวจ ยังไม่ส่งเอกสารหาลูกค้าและยังไม่ยืนยันราคาอัตโนมัติ คำสั่งเริ่มต้นควรบอกว่าข้อมูลมาจากไหน อะไรต้องปรากฏในร่าง และเมื่อหาเงื่อนไขไม่เจอให้หยุดถามอย่างไร
เมื่อได้ต้นแบบ คำว่า “ยังไม่ดี” จะช่วย agent ได้น้อยกว่าการชี้ว่า “คำขอนี้ไม่ได้ระบุจำนวน แต่ระบบเติมจำนวนให้เอง” จากนั้นเก็บคำขอที่ทำให้พลาดไว้ใช้ทดสอบรอบต่อไป วิธีนี้ทำให้การลองเล่นกับแอปค่อย ๆ กลายเป็นการเรียนรู้ที่ไม่หายไปเมื่อเปลี่ยนคำสั่ง
Nate เสนอในคลิปให้ AI ถามกลับเพื่อทำความต้องการให้ชัดด้วย หากยังอธิบายงานไม่ได้ เราอาจให้มันถามถึงผู้ใช้ ข้อมูล และผลลัพธ์ทีละเรื่อง ก่อนเริ่มสร้างส่วนที่ยังคลุมเครือ
ใช้กรณีของแอปพิมพ์ตามเสียงเรียนรู้วิธีตรวจรับ
ช่วง 30:03–33:27 Dave ใช้แอปพิมพ์ตามเสียงของทีมอธิบายคำว่า “งานที่ดี” ผู้ใช้ต้องพูดแล้วได้ข้อความกลับไปยังแอปที่กำลังใช้ได้รวดเร็ว แก้ข้อผิดพลาดบางส่วน และยังเก็บสิ่งที่ผู้ใช้ตั้งใจพูดไว้ ข้อกำหนดเหล่านี้ช่วยให้ทีมเห็นว่ากำลังปรับปรุงอะไร
เขาเล่าว่าทีมรวบรวมข้อมูลจากบัญชีที่ใช้ภายใน แทนการนำข้อมูลของผู้ใช้ทั่วไปมาสร้างชุดทดสอบ แล้วจับคู่ข้อมูลเข้ากับผลที่คาดหวัง เมื่อแก้ระบบก็มีกรณีเดิมให้ตรวจซ้ำ เรื่องนี้เป็นวิธีทำงานที่ผู้พูดรายงานในคลิป ไม่ใช่การตรวจสอบนโยบายข้อมูลของผลิตภัณฑ์อย่างอิสระ
ถ้าประยุกต์กับตัวอย่างใบเสนอราคา เราควรมีทั้งคำขอที่ข้อมูลครบ คำขอที่ระบุรุ่นสินค้าไม่ชัด และคำขอที่มีเงื่อนไขซึ่งเครื่องมือไม่มีข้อมูลตอบ เกณฑ์อาจเป็น “คงชื่อรุ่นตามต้นทาง” หรือ “เว้นราคาที่ไม่มีในรายการอ้างอิงและแจ้งให้คนตรวจ” แทนการดูเพียงว่าร่างออกมาสวยหรืออ่านคล่อง
Dave กล่าวถึงการใช้ AI ช่วยสร้างข้อมูลจำลองและปรับระบบวนซ้ำตามเป้าหมายที่ตรวจได้ด้วย สำหรับงานธุรกิจ ข้อมูลจำลองควรผ่านสายตาคนที่รู้หน้างานก่อน เพราะชุดทดสอบที่ง่ายเกินไปอาจทำให้เราเชื่อมั่นเกินกว่ากรณีที่เคยทดสอบ
สิ่งที่ควรเก็บไว้หลังแต่ละรอบจึงมีทั้งตัวอย่างที่ผิด เหตุผลที่ถือว่าผิด และผลหลังแก้ เมื่อเปลี่ยนโมเดลหรือเพิ่มฟังก์ชัน เราจะกลับมาตรวจเรื่องที่เคยแก้แล้วได้ โดยไม่ต้องอาศัยความจำ
เมื่อคำตอบมีได้หลายแบบ ให้คนวางมาตรฐานก่อนใช้ AI ตรวจ
ช่วง 35:51–41:34 Dave ยกงานบริการลูกค้าเป็นตัวอย่าง คำตอบหลายประโยคอาจแก้ปัญหาเดียวกันได้ จึงตรวจด้วยการเทียบข้อความตรงตัวอย่างเดียวไม่ได้ เขาเสนอวิธีใช้โมเดลอีกชุดประเมินคำตอบ หรือ LLM as a judge
วิธีที่เขาอธิบายเริ่มจากให้คนอ่านตัวอย่างและบอกว่าผ่านหรือไม่ พร้อมเหตุผล แล้วให้โมเดลผู้ตรวจอ่านชุดเดียวกัน จากนั้นหาว่าคนกับโมเดลเห็นต่างตรงไหนและปรับคำสั่งของผู้ตรวจ กระบวนการนี้ช่วยถ่ายทอดมาตรฐานที่อยู่ในหัวคนให้ออกมาเป็นเกณฑ์ที่นำกลับมาใช้ได้
สำหรับคนดูแลธุรกิจเอง เราอาจเริ่มจากเหตุผลที่พบจริง เช่น คำตอบสุภาพแต่รับปากในสิ่งที่ร้านทำไม่ได้ หรือให้ข้อมูลถูกแต่ไม่บอกว่าลูกค้าควรทำอะไรต่อ เหตุผลที่เจาะจงเช่นนี้ทำให้รู้ว่าผู้ตรวจ AI กำลังตรวจเรื่องเดียวกับเราหรือเพียงชอบถ้อยคำที่ดูเรียบร้อย
ตัวเลขความเห็นตรงกันที่ผู้พูดยกในคลิปเป็นตัวอย่างอธิบายการปรับเกณฑ์ ไม่ใช่ผลรับประกันของทุกระบบ และความเห็นตรงกันก็ยังมีโอกาสผิดทั้งคู่ได้ ควรทบทวนตัวอย่างใหม่เป็นระยะ โดยเฉพาะเมื่อเปลี่ยนโมเดล ซึ่ง Nate ตั้งข้อสังเกตว่าอาจตีความคำสั่งเดิมต่างออกไป
สองเรื่องที่ทำให้ต้นแบบโตต่อยาก
ช่วง 42:46–51:51 Dave แยกโครงสร้างออกเป็นสองระดับ ระดับแรกคือส่วนต่าง ๆ ของระบบ เช่น หน้าจอ ระบบประมวลผล และฐานข้อมูล สื่อสารกันอย่างไร ระดับที่สองคือภายในโครงการจัดไฟล์และส่วนประกอบของโค้ดอย่างไร
ทีมของเขาเคยต้องเปลี่ยนชุดเทคโนโลยีที่ใช้สร้างผลิตภัณฑ์ หลังเริ่มจากสิ่งที่คนในทีมคุ้นเคยแล้วพบว่าไม่เหมาะกับสิ่งที่อยากทำในระยะต่อมา บทเรียนจากเรื่องนี้คือ ก่อนผูกงานจำนวนมากกับทางเลือกหนึ่ง ควรให้ผู้พัฒนาหรือ agent อธิบายว่าตัวเลือกนั้นเหมาะกับลักษณะผลิตภัณฑ์อย่างไร และมีข้อจำกัดใดที่จะเจอเมื่อขยาย
คำถามที่คนไม่เขียนโค้ดก็ใช้ได้คือ “เมื่อผู้ใช้กดปุ่มนี้ ข้อมูลถูกส่งไปที่ไหน ใครตรวจสิทธิ์ และเก็บผลไว้ตรงไหน” หากยังตอบไม่ได้ การเพิ่มผู้ใช้หรือต่อข้อมูลจริงจะทำให้ตรวจปัญหาได้ยากขึ้น คำอธิบายควรอ้างถึงระบบที่เราสร้างอยู่ด้วย ไม่ใช่แผนภาพมาตรฐานที่ใช้ได้กับทุกแอป
อีกเรื่องที่ Dave เล่าคือฟีเจอร์ทดลองที่ถูกทิ้งไว้ เมื่อมีฟีเจอร์ใหม่มาพึ่งโค้ดบางส่วนของมัน วันหนึ่งเราลบของเก่าที่คิดว่าไม่ใช้แล้ว งานส่วนอื่นกลับพัง นี่เป็นเหตุผลให้มีรอบจัดระเบียบโครงการและทดสอบงานเดิม ไม่ใช่สั่งเพิ่มฟีเจอร์ต่อไปเรื่อย ๆ
เมื่อนำกลับมาที่บริการใบเสนอราคา ก่อนลบหน้าทดลองหรือเปลี่ยนวิธีอ่านรายการสินค้า ควรตรวจว่าการคำนวณหรือการส่งออกเอกสารยังพึ่งส่วนเดิมอยู่หรือไม่ คนทำธุรกิจอาจไม่ได้ตรวจโค้ดทั้งหมดเอง แต่สามารถขอรายการผลกระทบและผลทดสอบของงานที่ลูกค้าใช้จริงก่อนรับการเปลี่ยนแปลงได้
ก่อนรับข้อมูลลูกค้า ต้องรู้ว่าระบบป้องกันอะไรอยู่
Dave เน้นตั้งแต่ช่วง 19:20–20:25 ว่าข้อมูลที่รั่วไปแล้วเรียกกลับด้วยการออกเวอร์ชันใหม่ไม่ได้ และกลับมาขยายเรื่องนี้ในช่วง 53:32–1:01:31 ด้วยประเด็นเรื่องสิทธิ์ฐานข้อมูล บัญชีผู้ดูแล ข้อมูลลับ และการเข้าถึงเครือข่าย
ในคลิป เขาเสนอ Supabase เป็นตัวเลือกเริ่มต้นและชวนให้เรียนเรื่อง row-level security หรือกฎที่กำหนดว่าผู้ใช้เข้าถึงข้อมูลแถวใดได้ คำแนะนำนี้เป็นมุมมองของเขา สิ่งที่เจ้าของระบบควรตรวจให้ได้คือบัญชีหนึ่งอ่านหรือแก้ข้อมูลของอีกบัญชีได้หรือไม่ และส่วนใดเป็นผู้บังคับใช้สิทธิ์นั้น
มีสองคำอธิบายในคลิปที่ควรระวังเมื่อนำไปทำจริง ประการแรก การทำพื้นฐานไม่ใช่หลักประกันว่าจะถูกเจาะไม่ได้ ประการที่สอง การอนุญาตเฉพาะ IP ของส่วนหน้าจอใช้เป็นสูตรเดียวกับทุกระบบไม่ได้ เส้นทางคำขอจากเบราว์เซอร์และจากเซิร์ฟเวอร์อาจต่างกัน จึงต้องตรวจสถาปัตยกรรมของแอปก่อนตั้งกฎเครือข่าย
เรื่องข้อมูลลับก็ต้องดูปลายทางด้วย การเก็บ API key ในตัวแปรสภาพแวดล้อมยังไม่ตอบว่าค่านั้นจะถูกส่งไปให้เบราว์เซอร์เห็นหรือไม่ หากกำลังรับข้อมูลของธุรกิจอื่น ควรให้ผู้เชี่ยวชาญตรวจสิทธิ์และเส้นทางข้อมูลจริง การสั่ง agent ว่า “ช่วยทำให้ปลอดภัย” ยังไม่ใช่หลักฐานที่ใช้ส่งมอบงานได้
ในตัวอย่างใบเสนอราคา เราจึงควรเริ่มทดสอบด้วยข้อมูลจำลอง และตรวจด้วยบัญชีทดสอบที่แยกจากกันก่อนรับข้อมูลจริง การซ่อนปุ่มหรือซ่อนหน้าจอไม่เพียงพอที่จะสรุปว่าข้อมูลข้ามบัญชีเข้าไม่ถึง
ขายงานแรกให้พอดีกับสิ่งที่ยังดูแลไหว
ช่วง 1:03:15–1:05:54 Dave มองว่า แม้เครื่องมือจะเข้าถึงง่ายขึ้น ธุรกิจยังต้องการคนที่ลงมือนำไปใช้จริง ความสามารถในการสร้างจึงอาจต่อยอดเป็นงานบริการได้ แต่คลิปนี้ไม่ได้แสดงยอดขายหรือพิสูจน์ว่าข้อเสนอแบบใดจะมีลูกค้าซื้อแน่นอน
ข้อเสนอสำหรับคนทำธุรกิจคนเดียวคือ เริ่มขายขอบเขตงานที่อธิบายและตรวจรับได้ ในตัวอย่างของบทความ อาจเป็นการติดตั้งระบบช่วยร่างใบเสนอราคาจากรายการสินค้าที่ลูกค้าอนุมัติ โดยกำหนดให้คนตรวจราคาก่อนส่ง พร้อมตกลงว่าการเปลี่ยนรายการสินค้าและการแก้ข้อผิดพลาดอยู่ในความดูแลของใคร ขอบเขตเช่นนี้ช่วยให้คุยกับลูกค้าได้ตรงกว่าคำสัญญาว่าจะทำงานขายให้อัตโนมัติทั้งหมด
หลังทดลองใช้งาน สิ่งที่ควรกลับมาดูคือ ลูกค้าใช้กับงานใดจริง ต้องแก้ร่างตรงไหนบ่อย และเวลาที่เราดูแลระบบยังคุ้มกับงานที่รับหรือไม่ หากแต่ละรายต้องปรับหลายส่วนมาก ก็เป็นข้อมูลสำคัญก่อนตัดสินใจทำระบบสมัครสมาชิก
บันไดของ Dave จึงมีประโยชน์กับการตัดสินใจเรื่องถัดไปมากกว่าการเร่งให้ขึ้นถึงขั้นสุดท้าย เริ่มจากปัญหาที่รู้จัก เก็บหลักฐานจากการใช้จริง แล้วเพิ่มความรับผิดชอบเมื่อเราตรวจและดูแลงานนั้นได้ การเลือกขอบเขตที่พอดีทำให้คนคนเดียวมีโอกาสส่งมอบงานได้ต่อเนื่อง โดยยังมีเวลารับผิดชอบต่อลูกค้าที่เข้ามาแล้ว
ดูบทสนทนาต้นฉบับ
เรียบเรียงจากบทถอดเสียงที่เก็บไว้ของ How to Actually Build & Sell Software with AI as a Non-Techie บทสนทนาของ Nate Herk กับ Dave Ebbelaar ความยาวถึง 1:09:29 ภาพประกอบมาจากวิดีโอเดียวกัน ข้อความเกี่ยวกับเครื่องมือและวิธีทำงานอ้างอิงสิ่งที่ผู้พูดอธิบายในคลิป ส่วนข้อเสนอสำหรับงานใบเสนอราคาเป็นการประยุกต์ของบทความ
