Flow · คลังคำตอบกรรมการ

Q OpenStreetMap แม่นยำไหม?

ในกรุงเทพ OSM ครอบคลุมถนนหลัก/รองได้ดีและชุมชน mapper ไทยแอคทีฟ — เพียงพอสำหรับ “ลำดับจุด + ระยะ + เวลาเดินทางโดยประมาณ”. เราใช้ ตัวคิดเส้นทาง (OSRM) และ ตัวค้นพิกัด (Nominatim) จากแผนที่เปิด. ข้อจำกัดที่ยอมรับ: ไม่ใช่ traffic แบบเรียลไทม์เท่า Google. เราจึงแสดงเวลาเป็น “~ประมาณ” และเผื่อ buffer ไว้ ไม่เคลมว่าเป๊ะวินาที. เลือก OSM เพราะ open data ตรงเงื่อนไขงาน และต่อยอด/host เองได้ ไม่ผูก API ราคาแพง.

Q รถติดหรือฝนตกทำยังไง?

ตอนนี้เราจัดการเชิง เผื่อความเสี่ยงล่วงหน้า ไม่ใช่ react สด: แผน “เครียดน้อยสุด” ใส่ buffer เดินทาง/พักมากขึ้น และระบบเตือน “จุดเสี่ยง” ช่วงที่แน่นเกินไป. Roadmap ข้อถัดไป คือ “ปรับแผนสดระหว่างวัน” — ถ้ารถติด/ฝนหนักกว่าคาด ให้ AI เสนอสลับลำดับงานที่เหลือ และดึง traffic แบบเรียลไทม์มาเสริม. เรายอมรับว่ายังไม่ทำในต้นแบบ 2 วัน แต่สถาปัตยกรรม (คิดแผนใหม่ได้ทุกเมื่อ) รองรับไว้แล้ว.

Q ถ้า AI ล่ม?

แอป ไม่ล้มทั้งระบบ — ทุก API route ออกแบบให้ degrade graceful: ถ้าเรียก AI ไม่ได้ ระบบ fallback เป็นแผนสำรอง/เรียงตามเวลาในงาน ทันที (เห็นป้าย “โหมดสาธิต offline”). ส่วนแผนตัวอย่างในเดโมเรา pre-bake ไว้ (cache คำตอบจริง) จึงโชว์ได้แม้เน็ต/AI มีปัญหา. แปลว่ากรรมการกดแล้วได้ผลเสมอ ไม่มีจอขาว.

Q ทำไมเลือกใช้ Claude ไม่ใช่ ChatGPT หรือ Gemini?

เราใช้ Claude ผ่าน official SDK โดยผสม 2 รุ่นตามงาน: Haiku (เร็ว/ถูก) สำหรับงานเบา เช่น แตกข้อความ/ตั้งชื่อวัน และ Sonnet สำหรับวางแผนที่ต้องคิดละเอียด. เหตุผล: คุณภาพการทำตามคำสั่งภาษาไทย + โครงสร้าง JSON ที่นิ่ง + คุมต้นทุนได้ด้วยการเลือกรุ่น. ทั้งนี้ดีไซน์เราไม่ผูกตาย — เปลี่ยน provider ได้เพราะแยก logic คะแนน/เส้นทางออกจากตัว LLM แล้ว.

Q ถ้า AI จัดแผนผิด ผู้ใช้แก้เองได้ไหม?

ได้ทั้งหมด. ทุกงานแก้เวลา/ลำดับ/สถานที่เองได้, ล็อกเวลาที่ต้องไม่ขยับเป็น anchor, และคุยต่อกับ AI ได้ (follow-up chat) เช่น “ฉันขับรถเอง” แล้วมันจัดใหม่ให้. AI เป็นจุดเริ่ม ไม่ใช่คำตัดสิน.

Q ทำไมเลือกแก้ “ความเครียดจากการจัดการเวลา” ไม่ใช่ปัญหาการเดินทางโดยตรง?

เพราะการเดินทางเป็น อาการ ส่วนความเครียดจากคุมเวลาไม่ได้คือ ต้นเหตุ. คนกรุงเทพไม่ได้เครียดเพราะรถติดอย่างเดียว แต่เครียดเพราะต้องวิ่งหลายที่ในวันเดียวแล้ว “เอาไม่อยู่”. งานวิจัยชี้ว่าตัวลดเครียดคือ ความรู้สึกว่าคุมเวลาได้ ไม่ใช่จำนวนงานที่เสร็จ. เราจึงแก้ที่ความรู้สึกคุมได้ แล้วเอาการเดินทาง (ตัวกินเวลาตัวใหญ่สุดของเมืองนี้) มารวมในสมการ — ได้ทั้งต้นเหตุและบริบทเมือง. ตรงกับ PEOPLE Track (สุขภาพจิตคนเมือง).

Q มีข้อมูล/แบบสำรวจของกลุ่มเป้าหมายจริงกี่คนที่ยืนยันว่าปัญหานี้เกิดจริง?

มีทั้งระดับชาติและจากทีมเอง:

• กรมสุขภาพจิต (ศูนย์ฯ ที่ 13) สำรวจคนวัยทำงานในกรุงเทพ 2,261 คน ครบ 50 เขต พบ 45% มีความเครียดผิดปกติ (ปานกลาง 29% · มาก 8% · รุนแรงสุด 8%) [1]
• สำรวจสุขภาพจิตพนักงานไทย 2566: วัยทำงาน 40% เครียดสูง [2]
• สายด่วน 1323 ปี 2566: “เครียด-วิตกกังวล-ทำงานไม่มีความสุข” เป็น ปัญหาอันดับ 1 ของแรงงานไทย (5,989/8,009 สาย) [3]
• คนไทยมีปัญหาสุขภาพจิต ~10 ล้านคน, วัยทำงาน 7 ใน 10 กำลังหมดไฟ สูงกว่าค่าเฉลี่ยโลก [6]

Q งานวิจัยที่อ้าง ถูกเอามาใช้ออกแบบ Flow ยังไง?

Macan (1994) และ Häfner & Stock (2010, RCT n=71) ชี้ตรงกันว่า การบริหารเวลาเพิ่ม “perceived control of time” → ลดความเครียดจริง แต่ไม่เพิ่ม performance [5]. เราแปลงเป็นดีไซน์ตรง ๆ: (1) วัด “คะแนนความคุมได้” เป็น metric หลัก ไม่ใช่จำนวนงานเสร็จ, (2) ชู buffer/ช่วงพัก เพราะความสบายใจคือเป้า, (3) ให้ผู้ใช้คุม/ล็อกเองได้ เพื่อเสริมความรู้สึก control. งานวิจัยไม่ได้แค่อ้างประกอบ แต่เป็นแกนที่กำหนดว่าเราวัดอะไร.

Q ต่างจาก Google Calendar / Todoist / Notion ยังไง?

พวกนั้นเป็น ที่เก็บ (เรากรอกสิ่งที่ตัดสินใจแล้ว). Flow เป็น ตัวช่วยตัดสินใจ (พิมพ์ของดิบ AI จัดให้). Todoist จัดงานแต่ไม่รู้จักเวลาเดินทาง, Calendar รู้นัดแต่ไม่บอกว่าเรียงแบบนี้จะเครียด, Notion ยืดหยุ่นแต่ต้องตั้งระบบเอง. ไม่มีตัวไหน รวม งาน+เวลา+เส้นทาง+คะแนนความเครียด ในปุ่มเดียว และไม่มีตัวไหนวัด “ความคุมได้”.

Q มี Google Calendar อยู่แล้ว ทำไมต้องใช้ Flow เพิ่ม?

ไม่ได้ให้ทิ้ง Calendar — Flow ทำงานคนละชั้น. Calendar ตอบ “มีอะไรกี่โมง” / Flow ตอบ “วันนี้ควรเรียงยังไงให้ไม่พัง ไปทางไหน เผื่อเวลาตรงไหน”. Roadmap เราคือ เชื่อม Google Calendar ดึงนัดเดิมมาวางแผนต่อ — เป็นส่วนเสริม ไม่ใช่คู่แข่งตรง ๆ. Flow = ชั้นวางแผน/ตัดสินใจที่อยู่บนปฏิทิน.

Q อะไรที่คู่แข่งทำไม่ได้ แต่ Flow ทำได้?

รวม เส้นทางเดินทางเข้าไปในแผนงาน + ให้ คะแนนความคุมได้แบบโปร่งใส + เสนอ 2 สไตล์แผน (เร็วสุด/เครียดน้อยสุด) จาก input ภาษาไทยดิบ ๆ ในคลิกเดียว และเป็น open source. ชุดนี้รวมกันยังไม่มีเจ้าไหนทำ.

Q AI จัดลำดับงานจากข้อมูลอะไรบ้าง?

จากเวลาที่ผู้ใช้ระบุ/ล็อก (anchor), สถานที่และเวลาเดินทางระหว่างจุด (จาก OSM/OSRM), duration ที่ประมาณจากชนิดงาน, จุดเสี่ยง (ดึก/แน่นเกิน), และสไตล์ที่เลือก (เร็วสุด vs เครียดน้อยสุด). AI เติมงานที่จำเป็นแต่ลืม (เดินทาง/กินข้าว) และทำเครื่องหมาย “เติมโดย AI” ให้ตรวจได้.

Q หาก AI ล่ม ระบบทำงานต่อได้ไหม?

ได้ — fallback แผนสำรอง + แผนเดโม cache ไว้ (ดูหัวข้อ “ถ้า AI ล่ม”). ฟีเจอร์ที่ไม่ต้องใช้ AI (ดูตาราง, แผนที่จาก OSM, คะแนนจากสูตร) ทำงานปกติทั้งหมด.

Q คะแนน 80 กับ 60 ต่างกันยังไงในทางปฏิบัติ?

80 = วันที่ค่อนข้างหลวม มี buffer ระหว่างงาน จุดเสี่ยงน้อย เดินทางไม่หนัก → “เอาอยู่สบาย ๆ”. 60 = วันแน่นขึ้น มีช่วงต้องรีบ/เสี่ยงสาย หรือเดินทางเยอะ → “ทำได้แต่ต้องระวัง”. ความต่างมาจากการหักที่ อธิบายได้ทุกบรรทัด ผู้ใช้จึงเห็นว่าถ้าเลื่อนงานนิดเดียวคะแนนขยับยังไง — มันคือเครื่องมือ “ลองปรับแล้วเห็นผล” ไม่ใช่แค่ป้ายคะแนน.

Q มั่นใจได้ยังไงว่าคะแนนนี้สะท้อนความเครียดจริง / ทดสอบกับคนจริงหรือยัง?

ตอบตรง ๆ: เรายังไม่ได้ทดสอบเชิงสถิติระยะยาวว่าคะแนนสูง = เครียดลดลงจริงในผู้ใช้. สิ่งที่เรามั่นใจคือ ตัวแปรในสูตร (ความแน่น, จุดเสี่ยง, เวลาเดินทาง) ล้วนเป็นปัจจัยที่งานวิจัยโยงกับความรู้สึกควบคุม/ความเครียด และสูตรโปร่งใสตรวจสอบได้. การพิสูจน์ผลกับผู้ใช้จำนวนมากคือ ขั้นถัดไปที่เราตั้งใจทำ — เราเลือกพูดความจริงมากกว่าเคลมเกิน.

Q เวลาเดินทางที่แสดง เรียลไทม์หรือประมาณ?

เป็นค่าประมาณจากระยะทาง/ความเร็วเฉลี่ยบนเครือข่ายถนน OSM ยังไม่ใช่ traffic เรียลไทม์. เราจึงแสดงด้วยเครื่องหมาย “~” และเผื่อ buffer. การดึง traffic เรียลไทม์เป็น roadmap. เลือกแบบนี้ก่อนเพราะใช้ open data ตรงโจทย์ และเพียงพอต่อการ “วางแผนล่วงหน้า” ซึ่งคือ use case หลัก.

Q ถ้ารถติด/อุบัติเหตุ/ฝนหนัก ระบบรับมือยังไง?

ดูหัวข้อ “รถติดหรือฝนตก” — ตอนนี้เผื่อ buffer + เตือนจุดเสี่ยงล่วงหน้า, roadmap คือปรับแผนสด+ traffic เรียลไทม์ บนสถาปัตยกรรมที่ re-plan ได้ทุกเมื่อ.

Q กลุ่มเป้าหมายหลักคือใคร?

คนวัยทำงานในกรุงเทพที่ต้องวิ่งหลายที่ในวันเดียวและจัดเวลาไม่สมดุล — กลุ่มที่สถิติเครียดสูงสุดและเป็นแกนของ PEOPLE Track. ขยายต่อได้ถึงนักศึกษา/ฟรีแลนซ์ที่ตารางยืดหยุ่น. (หมายเหตุ: ผู้สมัครแข่งเป็นเยาวชน 15–24 แต่ ผู้ใช้ผลิตภัณฑ์ คือวัยทำงาน).

Q ตอนนี้มีผู้ใช้จริงกี่คน / feedback อะไรมากสุด / ฟีเจอร์ไหนมาจากผู้ใช้?

เป็น prototype ผ่านการทดสอบ 2 รอบ ได้ 15 feedback (ยังไม่เปิด public scale). เสียงที่ดังสุดคือ “อยากรู้ว่าพักได้ตอนไหน” และ “คะแนนมาจากไหน” → เราเลยเพิ่มการโชว์ช่วงพักในไทม์ไลน์ และเปลี่ยนคะแนนเป็นสูตรกดดูที่มาได้. ฟีเจอร์ที่เกิดจากผู้ใช้โดยตรง: แสดงช่วงพัก, ที่มาคะแนนโปร่งใส, ค้นพิกัด OSM อัตโนมัติ.

Q ถ้าเปิดจริง หารายได้จากไหน?

แกนยังเป็น open source ฟรีเพื่อสาธารณะ. โมเดลรายได้ที่เป็นไปได้โดยไม่ขัดเจตนา: freemium (ซิงก์ข้ามเครื่อง/ฟีเจอร์ทีมแบบจ่าย) และ B2B/B2G ให้องค์กร/รพ./กทม. เอาเวอร์ชันปรับแต่งไป deploy ดูแลพนักงาน. ตัวฟรีสำหรับประชาชนยังอยู่เสมอ.

Q ต้นทุน AI ต่อผู้ใช้เท่าไร / รองรับหลักแสนคนได้ไหม?

ต้นทุนต่ำเพราะ คุมด้วยดีไซน์: ใช้ Haiku (ถูก) กับงานเบา, เรียก AI เฉพาะตอน “จัด flow” ไม่ใช่ทุกคลิก, และ cache แผนซ้ำ. ฝั่ง scale: ฐานข้อมูลผู้ใช้อยู่บนเครื่อง (localStorage) → server เรา แทบไม่ต้องเก็บข้อมูล (stateless) ไม่มีภาระเก็บข้อมูล ขยายแนวนอนง่าย. ตัวแปรต้นทุนหลักคือจำนวนครั้งเรียก AI ซึ่งจัดการได้ด้วยการเลือกรุ่น/แคช/จำกัด rate.

Q เก็บข้อมูลตำแหน่งผู้ใช้ไหม / เก็บนานแค่ไหน / PDPA / ถ้ารั่ว?

ไม่เก็บบน server — ตาราง/สถานที่อยู่ใน localStorage ของเครื่องผู้ใช้, ไม่มีบัญชี ไม่มี DB กลาง. “เก็บนานแค่ไหน” = อยู่ในเครื่องจนผู้ใช้ลบเอง ไม่มีสำเนาฝั่งเรา. PDPA: เข้าหลัก data-minimization โดยธรรมชาติ (เก็บน้อยสุด). ถ้าข้อมูลรั่ว: ผลกระทบจำกัดมากเพราะไม่มีถังข้อมูลรวมให้รั่ว — ความเสี่ยงอยู่ที่เครื่องผู้ใช้เองเท่านั้น. การค้นพิกัดส่งเฉพาะชื่อสถานที่ไป Nominatim ตอนค้น ไม่ผูกตัวตน. ถ้าทำบัญชี/ซิงก์ในอนาคต จะเพิ่ม consent + เข้ารหัสตามมาตรฐาน PDPA เต็มรูปแบบ.

Q ทำไมหน่วยงาน (รพ./ศูนย์สาธารณสุข/กทม.) ต้องใช้ Flow / ต้องปรับอะไร / คุยกับใครแล้ว?

ประโยชน์: บุคลากรที่ต้องวิ่งหลายจุด (พยาบาลเยี่ยมบ้าน, ทีมภาคสนาม) วางแผนวัน+เส้นทาง+ลดภาระสมองได้ในเครื่องมือเดียว และ open source ให้เอาไป deploy เองได้ฟรี. ถ้านำไปใช้จริงควรเพิ่ม: บัญชี/สิทธิ์, การซิงก์ทีม, และเชื่อมข้อมูลขนส่งเมือง. ตอบตรง: ตอนนี้ยังเป็น แนวคิด/โอกาสต่อยอด ยังไม่ได้ MOU กับหน่วยงานใด — เราโฟกัสพิสูจน์ตัวต้นแบบกับผู้ใช้ทั่วไปก่อน ไม่เคลมความร่วมมือที่ยังไม่เกิด.

Q จุดอ่อนที่สุดของ Flow ตอนนี้คืออะไร?

ตอบตรงได้คะแนน: (1) เวลาเดินทางยังเป็นค่าประมาณ ไม่เรียลไทม์ · (2) GPS check-in ยังเป็นเดโมจำลอง · (3) ยังไม่มีบัญชี/ซิงก์ ข้อมูลผูกเครื่องเดียว · (4) ผลลด-เครียดยังไม่ได้พิสูจน์เชิงสถิติกับผู้ใช้จำนวนมาก. ทุกข้อมีในแผนแก้ และเราเลือกทำของที่ใช้ได้จริงก่อน แล้วขยายตามเสียงผู้ใช้.

Q ถ้าพรุ่งนี้ Google ทำเหมือนคุณ จะสู้ด้วยอะไร?

ดูหัวข้อ มาแรง — โฟกัสลดเครียด (ไม่ใช่ productivity), บริบทไทย/รถติด, และ open source ให้ civic เอาไปต่อ. เราเล่นในมุมที่เจ้าใหญ่ไม่โฟกัส.

Q อะไรคือความเสี่ยงที่อาจทำให้โครงการไม่สำเร็จ?

ความเสี่ยงหลัก: การ adoption — เปลี่ยนพฤติกรรมคนให้มาพิมพ์วันลงแอปทุกวันยาก, และ ต้นทุน AI ถ้าโตเร็ว. เราลดด้วยการทำ onboarding ให้พิมพ์ครั้งเดียวจบ, คุมต้นทุนด้วยรุ่น/แคช, และเริ่มจากกลุ่มที่ pain แรงสุด (วิ่งหลายที่/วัน) ที่เห็นคุณค่าทันที.

Q ถ้าตัดเหลือ 1 ฟีเจอร์ จะเก็บอะไร เพราะอะไร?

เก็บ “พิมพ์งานดิบ → AI จัดเป็นไทม์ไลน์ทั้งวันให้”. เพราะนั่นคือหัวใจที่ทำให้ผู้ใช้รู้สึก “เอาอยู่” ทันที — เส้นทาง คะแนน 2 แผน คือของเสริมที่ทำให้ดีขึ้น แต่ถ้าไม่มีตัวจัดแผนอัตโนมัติ ก็เหลือแค่ to-do ธรรมดา.