Claude Code Routines จะช่วยเฝ้าดูการเงินของฉันได้ไหม?

 (driggsby.com)
1 คะแนน โดย GN⁺ 24 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อนำ ข้อมูลบัญชีการเงินและตัวเชื่อมต่อ MCP มาเชื่อมกัน ก็สามารถทำให้การตรวจสอบการเงินแบบซ้ำ ๆ เป็นอัตโนมัติได้ด้วยพรอมป์ต์เพียงอย่างเดียว โดยอิงจากข้อมูลยอดคงเหลือ รายการธุรกรรม การลงทุน และสินเชื่อ
  • วิธีเดิมที่ใช้ Codex CLI cron-job มักพังบ่อยเพราะปัญหาการล็อกอินผ่านเว็บ การเรนเดอร์ของเบราว์เซอร์ 2FA และข้อจำกัดของ passkey ทำให้ตรวจสอบแต่ละบัญชีได้ไม่ต่อเนื่องอย่างเสถียร
  • ระบบ อีเมลอัตโนมัติรายวัน ที่ประกอบขึ้นใหม่ ใช้ตารางเวลาตอนเช้า, custom connector และเครื่องมือ email_me() ร่วมกัน เพื่อสรุปทุกบัญชีและมูลค่าสุทธิแล้วส่งออกมาได้ และยังเปลี่ยนเนื้อหาได้ด้วยการปรับพรอมป์ต์
  • ระบบเฝ้าระวังธุรกรรมอัตโนมัติจะค้นหา ธุรกรรมผิดปกติและเงินไหลออกจำนวนมาก โดยเทียบกับรูปแบบล่าสุด และตั้งค่าให้ส่งอีเมลเฉพาะเมื่อเข้าเงื่อนไข เพื่อลดการแจ้งเตือนที่ไม่จำเป็น
  • แนวทางนี้ทำให้สามารถทดลองและขยาย ระบบอัตโนมัติด้านการปฏิบัติการที่ปรับตามบุคคล ได้อย่างรวดเร็วในต้นทุนต่ำมาก และทำให้แม้แต่คนที่ไม่ใช่นักพัฒนาก็จัดการการตรวจสอบการเงินที่เชื่อมกับข้อมูลแบบเรียลไทม์ได้เอง

วิธีจัดวางระบบอัตโนมัติ

  • Driggsby เชื่อมต่อกับบัญชีการเงินผ่าน Plaid แล้วเปิดเผยเครื่องมืออย่างยอดคงเหลือ รายการธุรกรรม ข้อมูลการลงทุน และข้อมูลสินเชื่อผ่าน MCP
  • ตอนแรกการใช้งานหลักคือ การใช้งานแบบโต้ตอบ ที่ถาม Claude ตามต้องการ แต่ต่อมาก็เริ่มเห็นรูปแบบงานซ้ำ ๆ เช่น การตรวจสอบมูลค่าสุทธิ การทบทวนยอดคงเหลือ และการติดตามธุรกรรม
  • Claude Code routines ทำให้งานซ้ำเหล่านี้ กลายเป็นอัตโนมัติได้ง่ายด้วยพรอมป์ต์อย่างเดียว
    • ไม่ต้องเขียนโค้ด agent loop แยกหรือเตรียมสภาพแวดล้อมสำหรับ deployment แค่เชื่อมพรอมป์ต์กับตัวเชื่อมต่อ MCP ก็ใช้งานได้
    • ถ้าจัดการเชื่อมข้อมูลและเครื่องมือเข้ากับตัวเชื่อมต่อ MCP ได้อย่างเรียบร้อย ก็สามารถประกอบระบบอัตโนมัติได้

ข้อจำกัดของวิธีเดิมและการเปลี่ยนผ่าน

  • ก่อนหน้านี้เคยใช้ Codex CLI cron-job แบบไม่โต้ตอบให้ล็อกอินเข้าไปยังบัญชีธนาคาร บัตรเครดิต โบรกเกอร์ และบัญชีเกษียณ เพื่อดึงยอดคงเหลือกับธุรกรรมล่าสุด แล้วส่งอีเมลสรุปการเงินรายวัน
    • ใช้ Chrome DevTools MCP เพื่อล็อกอินแต่ละเว็บไซต์และดึงข้อมูลออกมา
    • แม้จะเป็นแค่งานง่าย ๆ อย่างส่งอีเมลสรุปการเงินรายวันให้คู่สมรส แต่ในทางปฏิบัติมันพังบ่อยมาก
  • ปัญหาคือมันมักล้มเหลวอีกทันทีในวันถัดไป และการทำงานระดับบัญชีก็มักหยุดชะงักจาก ปัญหาการเรนเดอร์ของเบราว์เซอร์ หรือคำขอ 2FA ที่เกิดขึ้นโดยไม่คาดคิด
    • บางครั้ง GPT เปลี่ยนรูปแบบอีเมลไปทั้งหมด หรือระหว่างรันเกิดความสับสนจนดึงข้อมูลมาได้เพียงบัญชีเดียว
    • ในบรรดาบัญชีที่ต้องเพิ่มใหม่ บางแห่งก็ อนุญาตเฉพาะการล็อกอินด้วย passkey
  • เพราะความขัดข้องซ้ำ ๆ เหล่านี้ ทุกครั้งที่อีเมลที่คาดหวังไม่มาถึงก็ต้องลงมือแก้เอง และเพื่อให้กระบวนการนี้เครียดน้อยลง จึงสร้าง Driggsby ขึ้นมา

ระบบอีเมลรายวันอัตโนมัติ

  • สิ่งแรกที่สร้างใหม่คือ อีเมลรายวัน โดยมีเป้าหมายให้ได้รับสรุปทุกบัญชีและมูลค่าสุทธิในรูปแบบที่อ่านง่ายทุกเช้า
    • เดิมข้อมูลนี้อยู่ในสเปรดชีตเก่า ๆ ที่ไหนสักแห่งบน Google Drive
    • แม้การอัปเดตจะใช้เวลาแค่ราว 15 นาที แต่แรงเสียดทานเล็กน้อยนั้นก็ทำให้อัปเดตไม่บ่อย และมากที่สุดก็แค่ประมาณทุก 6 เดือนครั้ง
  • ใน routines การตั้งค่าเริ่มต้นทำได้ง่ายมาก เพียงใส่พรอมป์ต์ ตั้งตารางตอนเช้า และเชื่อม Driggsby custom connector
  • แต่ช่วงแรกยังไม่มีวิธีส่งอีเมล และเมื่อใส่ Gmail connector เข้าไป ก็ได้เพียงฉบับร่างที่จัดรูปแบบมาดี
    • Gmail connector ส่งอีเมลจริงไม่ได้ ทำได้เพียงสร้าง draft
  • เพื่อแก้ปัญหานี้จึงเพิ่ม เครื่องมือ MCP email_me() เข้าไปใน Driggsby และวิธีนี้ก็ใช้งานได้ค่อนข้างสะดวก
    • จำกัดผู้รับไว้เฉพาะอีเมลที่ยืนยันแล้วของเจ้าของบัญชี และปิดกั้นลิงก์กับรูปภาพเพื่อให้ได้ระดับความปลอดภัยที่ยอมรับได้
    • บังคับให้เนื้อหาเป็น Markdown แล้วเพิ่ม CSS ให้กับอีเมลที่เรนเดอร์จาก Markdown เพื่อลดความไม่สม่ำเสมอของรูปแบบที่เกิดขึ้นในแต่ละรอบการทำงาน
  • บั๊กเล็ก ๆ บางอย่างแก้ได้ค่อนข้างง่ายด้วย inspectability ของ routines
    • UI ดูคล้ายเซสชัน Claude Code ปกติใน Claude Desktop หรือเว็บแอป จึงตรวจดูสถานะระหว่างรันได้ง่าย
  • หลังผ่านการทดสอบ อีเมลรายวันก็ส่งมาถึงได้จริง และหลังจากนั้นหากต้องการเปลี่ยนเนื้อหาอีเมล ก็สามารถ ปรับเฉพาะพรอมป์ต์ ใน UI ของ routines ได้โดยไม่ต้องแก้โค้ด
  • เนื่องจากคู่สมรสทั้งสองดูข้อมูลคนละแบบ จึงสามารถจัด อีเมลรายวันคนละฉบับ ด้วยพรอมป์ต์แยกกันได้

การเฝ้าระวังธุรกรรมผิดปกติและการใช้จ่าย

  • หลังจากอีเมลรายวันเข้าที่แล้ว ก็เริ่มเพิ่มระบบอัตโนมัติอื่น ๆ โดยใช้ข้อดีที่ว่าสามารถรัน agent ได้โดยไม่ต้องแบกรับภาระโครงสร้างพื้นฐานเพิ่มเติม
  • อย่างแรกคือการตั้ง ระบบเฝ้าระวังธุรกรรมผิดปกติ จากข้อมูลธุรกรรม โดยใน routine ที่รันรายสัปดาห์จะดึงธุรกรรมบัตรเครดิต Amex ย้อนหลัง 1 ปี แต่โฟกัสเฉพาะ 7 วันล่าสุด
    • หากธุรกรรมใน 7 วันล่าสุดดูไม่เป็นไปตามคาดเมื่อเทียบกับรูปแบบเดิม เช่น การเรียกเก็บเงินซ้ำ การเปลี่ยนค่าบริการสมัครสมาชิก หรือชื่อร้านค้า/คำอธิบายที่ไม่คุ้นเคย ก็ให้ส่งอีเมล
    • ถ้าธุรกรรม 7 วันล่าสุดดูปกติและสอดคล้องกัน ก็จะไม่ส่งการแจ้งเตือน
  • พรอมป์ต์ที่เรียบง่ายแบบนี้อาจทำให้เกิด false positive ได้ แต่ก็ดูเป็นระบบที่มีต้นทุนในการปรับแต่งและต้นทุนในการตรวจทานต่ำเมื่อเวลาผ่านไป
  • ต่อมาสำหรับบัญชีเดินสะพัด ก็สร้าง routine สำหรับเฝ้าระวัง เงินไหลออกขนาดใหญ่ที่ไม่คาดคิด
    • ตรวจดูเฉพาะธุรกรรมของวันล่าสุด แล้วเทียบกับรูปแบบตลอด 12 เดือนที่ผ่านมา เพื่อค้นหารายการที่เกิน $500 และเป็นเงินไหลออกจำนวนมากหรือผิดปกติ
    • เพราะระบบอัตโนมัติรันทุกวัน จึงจำกัดขอบเขตการตรวจสอบให้แคบลงอย่างมากเหลือเพียงวันล่าสุด
    • หากพบรายการที่เข้าเงื่อนไข ก็จะส่งอีเมลที่มีหัวข้อว่า "Checking account outflow alert" และหากไม่พบก็จะไม่แจ้งเตือน
  • หลังจากนั้นแนวทางนี้ก็ขยายไปสู่ การติดตามการลงทุน การวิเคราะห์ค่าสมัครสมาชิก และการเฝ้าระวังหมวดการใช้จ่ายต่าง ๆ
    • เพราะตั้งค่าด้วย routines ได้ง่ายมาก เมื่อเวลาผ่านไปความจำเป็นในการรวมหลายเงื่อนไขเข้าด้วยกันหรือปรับพรอมป์ต์ให้ละเอียดขึ้นก็จะมากขึ้น

ทำไมเรื่องนี้จึงสำคัญ

  • จุดแข็งสำคัญของ routines คือ ลองทำได้แทบไม่ต้องออกแรง
    • ถ้านึกพรอมป์ต์ออก ก็เริ่มรันระบบอัตโนมัติได้ทันที
  • อีกจุดที่โดดเด่นคือแม้แต่คนที่ไม่ใช่นักพัฒนาก็ยังจัดการระบบอัตโนมัติบนคลาวด์ที่เชื่อมกับข้อมูลจริงแบบ live ได้เอง
    • คู่สมรสที่เป็น CPA ก็ยังดึงข้อมูลเรียลไทม์ของ Driggsby มาใช้และรันระบบอัตโนมัติของตัวเองได้โดยตรง
  • รูปแบบการใช้งานเช่นนี้ทำให้สามารถสร้าง ระบบอัตโนมัติด้านการปฏิบัติการที่ปรับตามบุคคล ได้อย่างรวดเร็วด้วยเพียงพรอมป์ต์และตัวเชื่อมต่อ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 24 일 전
ความคิดเห็นจาก Hacker News

  • ช่วงหลังผมลองตั้งค่าแบบนี้เอง ใช้ https://tiller.com/ ซิงก์รายการเดินบัญชีและบัตรเครดิตเข้า Google Sheets แล้วใช้ GitHub Actions mirror สเปรดชีตนั้นไปยังฐานข้อมูล Supabase ฟรี
    จากนั้นให้ Claude/Codex เข้าถึงประวัติธุรกรรมและยอดคงเหลือผ่าน Supabase MCP หรือ psql ด้วยคำถามภาษาอังกฤษ ซึ่งความสามารถในการหาลักษณะแบบการสมัครสมาชิกหรือแพตเทิร์นผิดปกตินี่น่าประทับใจทีเดียว โดยเฉพาะเรื่อง การคาดการณ์กระแสเงินสด ที่เครื่องมือออนไลน์มักทำได้ไม่ดีนัก เช่น สามารถถามได้ว่าจากรูปแบบการใช้จ่ายรายเดือนและเงินสดที่มีอยู่ ควรย้ายไปเก็บออมได้เท่าไร
    ฝั่งการจัดหมวดหมู่อัตโนมัติ Claude จัดการ DSL แบบกำหนดเอง ได้ค่อนข้างดี ผมให้มันสร้างชุดกฎในรูปตาราง markdown สำหรับทำ normalization ของผู้รับเงิน/หมวดหมู่ และให้รันกฎเหล่านั้นพร้อมกันใน GitHub Actions ด้วย

    • สงสัยว่า Tiller ดึงข้อมูลธุรกรรมธนาคารมาอย่างไร
      อยากรู้ว่าใช้ตัวกลางแบบ Plaid หรือเปล่า หรือยังต้องส่งข้อมูลรับรองของเว็บแบงก์กิ้งอยู่ และจัดการ 2FA กันอย่างไร
      สำหรับสถาบันการเงินที่ไม่มี API อย่างเป็นทางการ ยังต้องพึ่งการ screen scraping อยู่หรือไม่ และถ้ามีบั๊กจนเกิดการคลิกหรือกดยินยอมโดยไม่ตั้งใจ หรือถึงขั้นโอนเงินผิด จะเกิดอะไรขึ้น เรื่องนี้ทำให้กังวล แม้จะบอกว่าเป็นแบบอ่านอย่างเดียว แต่แทบไม่เคยเห็นธนาคารไหนรองรับบัญชีเสริมแบบอ่านอย่างเดียวจริง ๆ สำหรับธนาคารส่วนบุคคล
      ยังสงสัยด้วยว่าถ้าเกิดความเสียหายทางการเงินในวงกว้าง จะมีประกันหรือการค้ำประกันให้ชดเชยหรือไม่ และก็กังวลเรื่องนัยด้านความเป็นส่วนตัวจากการเปิดเผยข้อมูลธนาคารทั้งหมดให้บริษัทสองแห่ง มีคนพูดถึงคดีแบบกลุ่มเกี่ยวกับการขายหรือแชร์ข้อมูลอย่างไม่เหมาะสมด้วย แต่ผมไม่รู้ว่าจริง ๆ แล้วเกิดอะไรขึ้น
      อีกอย่างคือข้อกำหนดของธนาคารมักมีเงื่อนไขว่าคุณตกลงจะไม่แชร์รหัสผ่านกับบุคคลที่สาม มันเลยคาใจอยู่ การฝากเรื่องการเงินไว้กับบริการเว็บ/คลาวด์ทำให้รู้สึกไม่สบายใจมาก และผมอยากได้ซอฟต์แวร์ฝั่งไคลเอนต์ที่รันในเครื่องและคุยกับ API ของธนาคารโดยตรงมากกว่า ไม่แน่ใจว่าในแคนาดามีแบบนั้นไหม
      ได้ยินว่าระบบโอเพนแบงก์กิ้งกำลังจะมา แต่ก็ยังไม่ชัดว่าซอฟต์แวร์ที่คนทั่วไปเขียนเองจะเข้าถึงได้หรือไม่ ถ้ามันเชื่อถือได้จริง และบังคับใช้นโยบายที่ลดการเก็บข้อมูลภายในหลังดาวน์โหลดแล้วให้น้อยที่สุดได้ ผมก็อยากใช้ API ของธนาคารเหมือนกัน
    • ผมก็ขอเชียร์ Tiller อีกเสียง
      ใช้ Tiller มาตั้งแต่ Mint ถูก Intuit ซื้อไป และผมก็มีการตั้งค่าคล้าย ๆ กัน ต่างกันแค่ว่าผมใช้โมเดล qwen แบบรันในเครื่องกับ API key ที่ทำผ่าน OAuth เพื่อเข้าถึง sheets แต่แนวทางแบบ Claude Routine น่าจะง่ายกว่ามาก
    • อันนี้เจ๋งมาก อยากรู้ว่ามีแผนจะปล่อยเป็น โอเพนซอร์ส ไหม
      อยากเห็นทั้งวิธีตั้งค่าทั้งหมด โดยเฉพาะใช้พรอมป์ต์แบบไหน
    • สงสัยว่าทำไมไม่ใช้ Plaid ตรง ๆ ที่ชั้นล่างไปเลย

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

    • ผมใช้ actualbudget.org ติดตามรายจ่ายทั้งหมด แต่จะอัปเดตบัญชีลงทุนแค่เดือนละครั้ง
      ผมคิดว่าสิ่งที่เกี่ยวกับตัวเลขควรเป็นแบบกำหนดได้แน่นอนทั้งหมดอยู่แล้ว
      ผมเคยให้ LLM ดูฐานข้อมูล SQLite แล้วบอกว่ามองเห็นอะไรจากธุรกรรม 5 ปีย้อนหลังบ้าง สิ่งที่มันจับได้หรือเตือนให้นึกถึงก็น่าประทับใจดี แต่ก็ยังไม่แน่ใจว่ามี คุณค่าเชิงปฏิบัติ จนทำให้ผมเปลี่ยนพฤติกรรมอะไรจริงหรือไม่
      กำลังจะลองให้มันช่วยทบทวนรายเดือนอยู่สักพัก แต่แค่ตอนอัปเดตงบประมาณ ปกติผมก็รู้อยู่แล้วว่าสถานะการเงินเป็นอย่างไร เลยไม่แน่ใจว่าจะช่วยได้มากแค่ไหน
    • อยากรู้ว่าเคยลองดึงธุรกรรมธนาคารด้วยชุด Actual Budget + SimpleFIN ไหม
      ผมใช้ชุดนั้นติดตามบัตรเครดิตกับบัญชีกระแสรายวัน และถ้าต้องการก็สามารถต่อ MCP เข้าไปเพื่อวิเคราะห์ข้อมูลทั้งหมดจากจุดเดียวได้
    • ขอบคุณ แล้วในทางกลับกัน อยากรู้ว่าถ้ามีอะไรเพิ่มเข้ามาถึงจะทำให้คุณสนใจ

  • ผมอยู่แคนาดาและใช้ https://lunchmoney.app/ สำหรับการติดตาม โดยเปิด Plaid integration ไว้ด้วย
    มันมี API เลยให้ LLM เขียน CLI ให้ และทำให้เอเจนต์ดึงข้อมูลที่ต้องการได้แทบตามใจ
    อีกอย่างที่ให้มันทำคือสะสมกฎการติดแท็ก ซึ่งผมตั้งให้รันด้วย cron วันละครั้ง บางครั้งก็ให้มันไล่ดูกฎเพื่อสร้างกฎใหม่สำหรับธุรกรรมที่ยังไม่ถูกจัดหมวด
    ผมว่ารูปแบบที่ให้ LLM จดจำงานไว้ในรูปกฎหรือโค้ด นี่ดีมาก แค่มี CLI ที่ query ได้ ก็แทบจะสั่งเอเจนต์ให้ทำอะไรก็ได้แล้ว

    • ผมเป็นผู้ก่อตั้ง Lunch Money ดีใจที่คุณใช้งานแบบนี้
    • อยากรู้ว่า use case หลักคืออะไร

  • สำหรับคนที่สนใจ ขอสรุปภาพรวมของ โครงสร้าง infra/ความปลอดภัย ของเรา
    backend กับ CLI เขียนด้วย Rust ที่บังคับ linting อย่างเข้มงวด ส่วนเว็บแอปรันบน Axum และเชื่อม Postgres ผ่าน sqlx
    ฟีเจอร์ทางการเงินเป็นแบบ อ่านอย่างเดียว ไม่มีเครื่องมือโอน จ่ายบิล หรือส่งเงิน และฝั่ง AI เองก็ไม่สามารถย้ายเงินได้
    ใน Plaid เราขอเฉพาะข้อมูลธุรกรรม การลงทุน และหนี้สิน ไม่ขอ auth/transfer/payment initiation จึงไม่ได้รับเลขบัญชีเต็มหรือเลข routing มีแค่ mask 4 หลักท้ายพื้นฐานเท่านั้น
    ชื่อผู้ใช้และรหัสผ่านธนาคารจะไม่ผ่านเรา แต่ไปผ่าน Plaid Link โดยตรง ส่วนเราจะเก็บแค่ access token ของแต่ละสถาบัน
    access token ของ Plaid ถูกเก็บในฐานข้อมูลแยกอีกชุดหลังบริการ custody Cloud Run เดี่ยว ขณะจัดเก็บจะเข้ารหัสด้วย Cloud KMS และ broker จะเรียก KMS encrypt/decrypt endpoint โดยวัสดุกุญแจรากจะไม่ออกนอกขอบเขต Google HSM เลย มีเพียง service account ของ broker เท่านั้นที่มีสิทธิ์ถอด/เข้ารหัส และเว็บแอปไม่มีสิทธิ์อ่านฐานข้อมูลนั้น
    ทุกการเรียกเข้ารหัส/ถอดรหัสจะส่ง Plaid item ID เป็น AAD เพื่อไม่ให้เอา ciphertext ของ item หนึ่งไปสลับถอดด้วย token ของอีก item ได้
    แต่ละบริการ Cloud Run จะรันด้วย cloud identity และ DB role ของตัวเอง และการเรียกภายในระหว่างบริการก็ยืนยันตัวตนด้วย identity token อายุสั้น
    ฐานข้อมูล production ไม่มี public IP และค่า secret ต่าง ๆ ก็เก็บไว้ใน managed secret storage ไม่ได้อยู่ใน source หรือ container image
    ตัว AI connector ใช้ OAuth 2.1 + PKCE และมี scope แยกตามผู้ใช้ สามารถ revoke ได้จาก UI ทุก tool call จะถูกบันทึกชื่อเครื่องมือ อาร์กิวเมนต์ที่ผ่านการทำความสะอาดแล้ว ไคลเอนต์ที่เรียก และเหตุผลที่เอเจนต์เสนอมา เพื่อให้เห็นว่า LLM ขออะไรแทนผู้ใช้บ้าง
    ฝั่ง AI ไม่มีเครื่องมือ fetch-URL, shell หรือ I/O ทั่วไป และจะคืนเฉพาะข้อมูลการเงินแบบมีโครงสร้างเท่านั้น ส่วน networking, IAM, DB grant ทั้งหมดจัดการด้วย Terraform และการเปลี่ยนแปลง infra ก็ทำผ่านเส้นทางนั้นเท่านั้น
    การเข้าถึง infra ถูกควบคุมด้วย 2FA และ security key

    • ขอบคุณที่เปิดเผย รายละเอียดเชิงเทคนิค แบบนี้จริง ๆ
      ให้ความรู้สึกว่าคุณเข้าใจกลุ่มผู้อ่านของเว็บไซต์นี้ และการออกแบบความปลอดภัยอย่างพิถีพิถันในแต่ละชั้นก็ทำให้เชื่อถือเครื่องมือนี้มากขึ้นด้วย
      ผมเองก็เคยคิดจะทำอะไรคล้าย ๆ กัน โดย MVP แรก ๆ แค่ดาวน์โหลด PDF statement ด้วยมือแล้วให้ Claude ช่วยตั้ง ledger สำหรับงานบัญชีแบบ plain text แล้วค่อยคิดจะต่อ Plaid ภายหลัง
      โดยเฉพาะอย่างยิ่ง ผมสงสัยว่าคนทั่วไปใช้ Plaid กันอย่างไร ต้องมีจำนวนผู้ใช้ถึงระดับหนึ่งก่อนหรือไม่ถึงเริ่มได้ หรือผมสามารถสมัครบัญชี Plaid เพื่อใช้งานส่วนตัว เชื่อมบัญชีส่วนตัวกับบัญชีธุรกิจของตัวเองเข้ากับ API ที่ใช้ง่ายได้เลยหรือไม่
    • ถ้าจะ downvote คนที่มาแชร์รายละเอียดทางเทคนิคของผลิตภัณฑ์หรือโพสต์ Show HN อย่างน้อยก็ควรบอกเหตุผลหน่อย

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

    • ใช่เลย เวลาใช้เครื่องมือแบบนี้ต้องนึกถึง prompt injection ไว้เสมอ

  • อันนี้ดูเหมือน ทางออกที่วิ่งหาปัญหา มากกว่า https://tiller.com/ อย่างเดียวก็เพียงพออยู่แล้ว ทำการคำนวณทุกอย่างที่อยากได้ในสเปรดชีตได้ และข้อดีเพิ่มคือไม่มี ภาพหลอน
    ผมก็ไม่ค่อยเข้าใจเหมือนกันว่าทำไมต้องการสรุปแบบยืดยาวจาก LLM แค่นั่งจัดหมวดการใช้จ่ายด้วยตัวเองเป็นครั้งคราว ความผิดปกติก็เห็นได้เร็วอยู่แล้ว และ Tiller ก็ทำให้ขั้นตอนนั้นง่ายด้วย

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

  • Era Finance ของเรากำลังทำโซลูชันที่มุ่งตรงมาจุดนี้พอดี เป็น MCP ชื่อ Era Context ที่เชื่อมเอเจนต์ใด ๆ ที่รองรับเข้ากับการเงินส่วนบุคคล ดูได้ที่ https://era.app
    ตอนนี้เราโฟกัสที่เครื่องมือแบบอ่าน แต่ก็เตรียมเครื่องมือแบบเขียนอย่างการโอนเงินหรือจ่ายหนี้ไว้แล้ว
    ถ้ามีฟีเจอร์ที่อยากได้ ผมอยากให้ส่งอีเมลหา alex ที่โดเมนด้านบน อนึ่งผมคือ Alex ซีอีโอ และนี่แทบเป็นครั้งแรกที่มา HN แต่ก่อนหน้านี้เคยรับผิดชอบ web presence ของ stripe.com และก่อนหน้านั้นก็อยู่ที่ Square/CashApp

    • ดูน่าสนใจ กำลังลองใช้อยู่ตอนนี้เลย

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

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

  • ธนาคารหลักของผม Monzo ในสหราชอาณาจักรมี API เต็มรูปแบบและ trigger webhook สำหรับ event ต่าง ๆ
    เลยทำ WhatsApp bot ที่ถามให้ช่วยอธิบายเมื่อมีธุรกรรมผิดปกติได้ โดยใช้ LLM เฉพาะกับส่วนการให้เหตุผล และยังตั้งระบบอัตโนมัติให้กวาดยอดคงเหลือก่อนเที่ยงคืนของทุกวันไปเข้าบัญชีออมทรัพย์เพื่อ maximize ดอกเบี้ยรายวันด้วย
    ผมจะคงเงินไว้ในบัญชีใช้จ่ายประจำวันแค่เล็กน้อย และถ้าระหว่างวันมีการใช้เงิน ก็เติมกลับจากบัญชีออมทรัพย์เพื่อรักษายอดต่ำ ๆ แบบนั้นไว้ ถ้ามีรายจ่ายก้อนใหญ่ค่อยย้ายเองด้วยมือ

    • เจ๋งมาก อยากให้ปล่อยเป็น โอเพนซอร์ส และน่าเสียดายที่ในสหรัฐยังไม่มีสภาพแวดล้อมแบบนี้ เพราะถ้ามีก็คงง่ายขึ้นมาก

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

    • แนะนำให้ลอง GPT ของ Codex ด้วย
      ผมเองก็รู้สึกว่า Claude มีแนวโน้มเกิดภาพหลอนได้เก่งพอตัว โดยเฉพาะกับชุดข้อมูลที่ไม่สมบูรณ์หรือมีข้อจำกัด