แค่ค้นหาใน Google ก็เจอได้ง่าย ๆ อยู่แล้ว เลยจะไม่ไปค้นมาให้ครับ ช่วงนี้ก็มีงานวิจัยของมหาวิทยาลัยเบิร์กลีย์ด้วย
UC Berkeley and AnChain.ai found that on the platforms they studied, bots lost 77 times more money per user than human traders, according to UC Berkeley’s DataX initiative.

ยิ่งไปกว่านั้น ถ้าระบบเทรดหรือบอตมีอัตราชนะสูงจริง ตั้งแต่แรก วิธีใช้งานมันก็คงกลายเป็นกระแสหลักไปไม่ทางใดก็ทางหนึ่งแล้ว

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

เข้าไปแล้วกดเริ่มวิเคราะห์ ก็ขึ้นให้ชำระเงิน ดูเหมือนจะไม่ฟรีนะครับ

ไม่ว่าจะเป็น AR หรือฮิวแมนนอยด์ที่จะมาในอนาคต ผมคิดว่าอินเทอร์เฟซคงจะค่อย ๆ มุ่งไปในทางที่เป็นนามธรรมมากขึ้นเรื่อย ๆ

น่าสนใจครับที่คุณใช้ชุดผสมของ (เครื่องมือ, อาร์กิวเมนต์, แฮชของเอาต์พุต) ในการตรวจจับการรันซ้ำ เราเองก็กำลังคิดเรื่องคล้าย ๆ กันอยู่ และกำลังทดลองแนวทางที่เพิ่ม hash chain ลงใน audit log เพื่อป้องกันไม่ให้ event เดียวกันถูกบันทึกซ้ำสองครั้ง

อย่างที่คุณบอกไว้ การแยกแยะระหว่าง “เรียกสองครั้ง” กับ “รันสองครั้ง” เป็นหัวใจสำคัญจริง ๆ ครับ ทางเราก็กำลังพิจารณาแนวทางใส่ idempotency key ให้กับงานของเอเจนต์แต่ละงานอยู่เหมือนกัน คุณเคยนำไปใช้จริงในบริการ production แล้วหรือยังครับ?

ขอบคุณครับ/ค่ะ ชุด Gitleaks + ruff + Kyverno + Checkov ดูเป็นแนวทางที่ทีมเรานำไปอ้างอิงใช้ได้ทันทีเช่นกัน

ขอแชร์เพิ่มเติมว่า — ทีมของเราทำงานด้วยโครงสร้างที่ค่อนข้างพิเศษ ทั้งทีมคือกลุ่ม AI Agent โดยมี Steward AI ภายใต้ CEO ที่เป็นมนุษย์ รับผิดชอบตั้งแต่การพัฒนา การตรวจสอบ ไปจนถึงการดีพลอยจริง

ดังนั้นสำหรับเรา การ "ติดตามความผิดพลาดของ AI" จึงไม่ใช่แค่ปัญหาเรื่องการล็อก แต่เป็นประเด็นด้าน governance ที่บันทึกว่า "ใครตัดสินใจอะไรด้วยสิทธิ์แบบใด" ผ่าน Passport + Spirit Score + Audit Trail ของแต่ละ Agent

เช่นเดียวกับแนวทางของคุณ bsh998 การเพิ่มการตรวจสอบแบบสแตติกก่อนล่วงหน้า (แนว Gitleaks) เข้าไปใน CI ของเราก็คือขั้นถัดไป วันนี้ก็เพิ่งเกิดแครชเพราะ environment variable ตกหล่น — ตรงจุดนี้พอดีครับ/ค่ะ

ถ้าเป็นการวิเคราะห์ด้วย LLM ถือว่าแพงเอาเรื่องเลยนะครับ

ขอบคุณครับ
ภายในสัปดาห์นี้ผมจะทำฟีเจอร์การตั้งค่าภาษาภายในไซต์ให้เรียบร้อยครับ :)

ขอบคุณสำหรับคำตอบมากครับ!!

เหมือนผมน่าจะมีคำถามเพิ่มเติมอีกหลายข้อเลย..

ผมอ่านแล้วเข้าใจว่าคุณเพิ่งได้มาสัมผัส terminal protocol ครั้งแรกตอนพัฒนาครั้งนี้
เลยอยากรู้เหมือนกันว่าก่อนเริ่มพัฒนา คุณมีความรู้เกี่ยวกับ Rust อยู่ประมาณไหนครับ

ผมพัฒนาด้วย Zig แต่จริง ๆ แล้วผมแทบไม่เคยลงมือเขียน Zig มาก่อน
ทั้ง terminal protocol, ไวยากรณ์, โครงสร้าง ก็แทบไม่มีความรู้เลยเหมือนกัน เป็นเคสที่ท้าทายตัวเองแบบเริ่มจากศูนย์ด้วยความรู้สึกว่า “ลองศึกษาใหม่ทั้งหมดไปเลย”
เพราะแบบนั้นด้วย ผมเลยพยายามหลีกเลี่ยงการพึ่งพา external library มากขึ้น
ผมตั้งใจให้การถามตอบเพื่อดูว่ามันถูกสร้างขึ้นอย่างไร กลายเป็นการทำ troubleshooting ร่วมกับ AI อย่างเป็นธรรมชาติ
เพราะผมอยากหลีกเลี่ยงกรณีที่ตัวเองควบคุมไม่ได้ แต่โปรแกรมกลับรันได้อยู่ดี

เห็นว่าคุณใช้เวลาประมาณ 4 เดือน
ฝั่งผมก็พัฒนาโดยเปิด Mac ที่บ้านทิ้งไว้แล้วรีโมตเข้าไปทำงานเหมือนกัน พอพัฒนาโปรโตคอลให้ Claude หรือ Codex CLI บนอุปกรณ์ ssh อัปโหลดรูปได้แล้ว หลังจากนั้นก็แทบเลิกใช้แอปเทอร์มินัลตัวเดิมไปเลย นอกจากจะเปิดขึ้นมาบางครั้งเพื่อดูเป็น reference เท่านั้น
ส่วนตัวผมคิดว่าน่าจะเป็นช่วงสัปดาห์ที่ 2? หรือ 3? ของการทำเทอร์มินัลมั้งครับ

อย่างที่คุณตอบไว้ว่าเริ่มใช้ทันที งั้นตอนนั้นก็คือเริ่มหนีออกจาก tmux ได้เลยใช่ไหมครับ?

แล้วที่ใช้เวลาถึง 4 เดือน นี่เป็นความคิดของผมนะ แต่ผมสงสัยว่าการคอยเพิ่มฟีเจอร์กับความสะดวกในการใช้งาน อาจจะกินเวลานานกว่าการพัฒนา core feature เสียอีก ไม่แน่ใจว่าที่ผมคิดเข้าใจถูกไหม
สำหรับผมมันเป็นแบบนั้น เลยสงสัยมาตลอดว่าคนอื่นที่ทำผลิตภัณฑ์คล้าย ๆ กัน จะมี flow แบบคล้ายกันไหม.. ถ้าไม่เป็นการเสียมารยาทก็รบกวนช่วยตอบด้วยนะครับ(__).

อีกอย่าง ผมก็อยากรู้ว่าตั้งแต่เมื่อไหร่คุณถึงรู้สึกว่ามันสะดวกกว่า tmux แบบทิ้งห่างชัดเจน

ขออีกข้อหนึ่ง จริง ๆ ผมเองก็พัฒนาเทอร์มินัลในธีมใกล้เคียงกันและพอใจกับมันอยู่ แต่สุดท้ายมันก็เป็นโปรแกรมประเภทที่ต้องคอยบำรุงรักษาอย่างต่อเนื่อง
อย่างที่คุณเขียนไว้ในบล็อก ทั้ง Ocra, cmux, heder และเครื่องมืออื่น ๆ ที่มีเป้าหมายคล้ายกันก็กำลังออกมากันเรื่อย ๆ และไลบรารียอดนิยมส่วนใหญ่ไม่ว่าจะมีบริษัทหนุน มีสปอนเซอร์ หรือมีผู้ร่วมพัฒนา ก็มักเดินหน้าได้เร็วกว่าโครงการส่วนตัวอย่างหลีกเลี่ยงไม่ได้ แถมยังเป็นโปรแกรมที่รับฟีดแบ็กได้ดีมากด้วย
ในมุมของการต้องแข่งขัน(?) กัน ผมเลยรู้สึกว่านอกจาก Korean IME แล้ว สุดท้ายเราก็คงตามหลังอย่างหลีกเลี่ยงไม่ได้ในแง่รายละเอียดเล็ก ๆ ด้านความสะดวกและความเร็วในการปรับปรุง UX
เลยอยากถามด้วยว่าพอพูดถึงการบำรุงรักษา คุณรู้สึกว่าแค่ทำได้ถึงระดับไหนเมื่อเทียบกับแอปประเภทคล้าย ๆ ที่กล่าวมาข้างบน ก็ถือว่าโอเคแล้วครับ

แล้วในเมื่อคุณเลือกใช้ GPU ด้วย Rust แบบนี้ แปลว่าคุณก็มองไปถึง Windows ในระดับหนึ่งด้วยหรือเปล่าครับ??

แม้ของผมจะเป็นโปรแกรมส่วนตัวเหมือนกัน แต่ถึงจะแพ้ ecosystem ก็เถอะ(?) เป้าหมายของผมก็ยังอยากให้คุณภาพไปถึงระดับของแอปที่พูดถึงไว้เหมือนกัน

แล้ว copad นี่ แม้จะคล้าย Ocra แต่เป้าหมายสุดท้ายคือเป็น ADE แบบ terminal-based ไม่ใช่ Electron-based ใช่ไหมครับ?

พอได้เห็นคนเกาหลีที่ทำแอปเป้าหมายคล้าย ๆ กันเป็นครั้งแรก ผมเลยเผลอรัวคำถามใส่เต็มเลย แต่ไม่จำเป็นต้องตอบทุกข้อก็ได้นะครับ..!

พออ่านความคิดเห็นต่าง ๆ แล้วก็นึกถึงช่วงเวลาที่อยากเตะผ้าห่มด้วยความเขินขึ้นมาเลยครับ

จริง ๆ แล้วในการพัฒนาส่วนใหญ่ก็ไม่ได้ต้องการนักพัฒนาระดับซูเปอร์อะไรหรอกครับ ผมมองว่าเป็นกระบวนการที่คนธรรมดา ๆ มารวมตัวกันแล้วค่อย ๆ สร้างอะไรบางอย่างขึ้นมา

รู้สึกว่าไม่ได้เห็นบทความที่แยกความแตกต่างระหว่าง Openweight กับ open source มานานมากแล้ว

ผมกลับมองตรงกันข้าม คือปฏิกิริยาของ Andrew Ng ต่อเรื่องนี้น่าประทับใจกว่าครับ

"นี่ไม่ใช่กรณีเดียวกันเลย ทุกคนมีสิทธิ์ที่จะเก็บโค้ดของตัวเองเป็นความลับได้ ปัญหาคือเมื่อพยายามจะขัดขวางไม่ให้คนอื่นเปิดเผยโค้ดของตัวเองเป็นโอเพนซอร์ส" (https://x.com/AndrewYNg/status/2081103828859117908)

อ้อ! มีหมวดหมู่สำหรับโพสต์แยกต่างหากด้วยนี่เอง! ขอบคุณที่บอกนะ!

นึกถึงเกม GOM Player สมัยก่อนเลยครับ..

👍 ของแบบนี้ดีมากเลยครับ..

ถ้าเทียบกับ 2FA แบบอื่น ๆ ผมว่ามันสะดวกกว่าชัดเจนนะ แต่ก็ดูเหมือนว่าจะมีคนที่รู้สึกว่าไม่สะดวกเหมือนกัน และตามสเปกมันก็ปลอดภัยกว่าแนวทางความปลอดภัยไหน ๆ ด้วย

เหมือนว่ากฎระเบียบด้านความปลอดภัยของเกาหลีก็กำลังไปในทิศทางที่ตัดการยืนยันตัวตนด้วยข้อมูลส่วนบุคคลอย่าง Face ID หรือการสแกนลายนิ้วมือออกไปด้วยเหมือนกัน แต่ passkey ก็ไม่มีความกังวลแบบนั้น

ถ้าเป็น Apple ทำ คนก็อาจจะคิดว่า Face ID ดีสินะ แต่ถ้าเป็นสตาร์ทอัพหน้าใหม่ทำ แค่การต้องถ่ายใบหน้าตั้งแต่แรกก็น่าจะทำให้รู้สึกต่อต้านได้เหมือนกัน

ดูเหมือนว่าจะเป็นเรื่องชุลมุนที่เกิดขึ้นเพราะเดิมทีผู้ใช้ไม่ใช้ 2FA กันอยู่แล้ว หรือไม่ก็ไม่รับรู้มัน

ยกตัวอย่างเช่น ถ้าถามว่าจะใช้ OTP ของธนาคาร หรือจะใช้ passkey ผมว่า passkey น่าจะสะดวกกว่ามากแบบขาดลอย

สวัสดีครับ!
ขอบคุณที่แบ่งปันประสบการณ์และความคิดเห็นดี ๆ นะครับ

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

1. ไม่มีไลบรารีที่ตอบโจทย์ความต้องการของผม
2. การสร้างใหม่ถูกกว่าการนำเครื่องมือที่คล้ายกันมาดัดแปลงเอง

ผมมักจะลงมือทำเองก็ต่อเมื่อคิดว่าสองข้อนี้เป็นจริงเท่านั้นครับ
มีเหตุผลหลายอย่าง แต่ท้ายที่สุดแล้ว ต่อให้เป็นชิ้นส่วนโค้ดเล็กแค่ไหน เมื่อผมเริ่มดูแลมัน ก็จะเข้าสู่ขอบเขตที่ผมต้องตรวจทาน ทดสอบ และบำรุงรักษาเอง และผมคิดว่ามันมีต้นทุนที่มากกว่าแค่การเขียนโค้ดตามมาเสมอครับ
ประเด็นที่พบในระหว่างการพัฒนาก็มีการชนกับโปรแกรมที่ค่อนข้างเป็นแกนหลักอย่าง window manager อยู่มาก ดังนั้นถ้าทำทั้งหมดนี้แบบ build from scratch ผมคิดว่าคงต้องใช้เวลาไปกับการพัฒนาและตรวจสอบความถูกต้องมากกว่าช่วงเวลาที่ใช้ดีบักและทดสอบปัญหาการชนกับ dependency ภายนอกมากทีเดียวครับ

นอกจากนี้ ตั้งแต่เริ่มพัฒนา ผมก็ใช้เครื่องมือที่ผมทำเองมาโดยตลอดแม้จะเจ็บปวดอยู่เรื่อย ๆ และเหตุผลที่ทำแบบนั้นได้ อาจเป็นเพราะเริ่มพัฒนาบน dependency บางส่วนอยู่แล้วก็ได้ครับ
เช่นเดียวกับกรณีที่ถอด SwiftTerm ออกจาก MacOS ก่อนอื่นผมนำ dependency ภายนอกเข้ามาเพื่อดูว่าแนวคิดที่ผมต้องการทำงานได้หรือไม่ และเมื่อมีสิ่งที่ต้องพัฒนาเองก็เริ่มลงมือทำเอง แต่แม้ในจุดนั้น โปรแกรมของผมก็ยังทำงานได้ด้วย dependency ภายนอกอยู่ ทำให้ผมสามารถทุ่มแรงต่อไปกับการทำให้เสถียรและเพิ่มฟีเจอร์บนฐานนั้นได้ครับ

เพิ่มเติมคือ ถ้านำ webkit เข้ามา เว็บแอปส่วนใหญ่จะทำงานเหมือนกับตอนเปิดในเบราว์เซอร์ทั่วไปครับ!
ช่วงหลังผมก็ใช้ทั้งเครื่องมือที่ควบคุม headless browser จาก cli ได้ และ claude in chrome อย่างจริงจังอยู่แล้ว อีกทั้งไม่อยากให้เทอร์มินัลต้องแบก chromium จนใช้หน่วยความจำมากเกินไป ถ้าไม่มีเรื่องใหญ่เกิดขึ้น ผมคิดว่าคงจะไม่เปลี่ยน tech stack ของ webview ภายในเทอร์มินัลมากนักครับ

ขอบคุณที่อ่านครับ!

เดโมของเรามีแค่ไฟล์ HTML แบบสแตติกไฟล์เดียวพอดี น่าจะเข้ากันได้ดีครับ ถ้าลิงก์คงที่ก็น่าแชร์ต่อได้สะดวกด้วย ขอบคุณที่แนะนำครับ เดี๋ยวหลังจบการสาธิตจะลองนำไปใช้ดู ขอบคุณครับ!

ตอนนี้เป้าหมายคือการแสดงให้เห็นว่า “เมื่อป้อนข้อมูลแล้ว ประกาศที่ตรงกันจะปรากฏขึ้นจริง” มากกว่าความละเอียดซับซ้อนของลอจิกครับ/ค่ะ เนื่องจากเป็นการเดโมให้ผู้มีอำนาจตัดสินใจภายในที่ไม่ใช่นักพัฒนาดู จึงให้น้ำหนักกับการยืนยันว่ามันทำงานได้มากกว่าความสมบูรณ์แบบ ส่วนการยกระดับลอจิกให้ซับซ้อนขึ้นมองไว้เป็นขั้นตอนถัดไปครับ/ค่ะ

ตอนนี้ให้ความรู้สึกเหมือนช่วงที่สมาร์ตโฟนเริ่มแพร่หลายและ UX แบบ mobile-first กำลังเปลี่ยนผ่านอย่างจริงจัง แม้ระบบต่าง ๆ จะยังไม่ลงตัวนัก แต่ก็เริ่มเห็นความเปลี่ยนแปลงที่น่าสนใจเกิดขึ้นในหลายจุด

กดบุ๊กมาร์กไว้ทันทีเลยครับ คิดว่าน่าจะเข้ามาดูทุกวันแน่ ๆ
ขอถามหน่อยว่ามีแผนรองรับภาษาเกาหลีด้วยหรือเปล่าครับ :)