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

• เชื่อมต่อข้อมูลการเงินผ่าน Plaidด้วยเครื่องมือ MCP เพื่อจัดการยอดคงเหลือ ธุรกรรม การลงทุน และข้อมูลเงินกู้ พร้อมทำให้การตรวจเช็กการเงินที่เคยต้องทำซ้ำ ๆ ถูกทำอัตโนมัติด้วย Claude Code routines
• ระบบอัตโนมัติบนเบราว์เซอร์ที่ใช้ cron เดิมพังบ่อยจากปัญหาการเรนเดอร์, 2FA prompt, ข้อผิดพลาดที่ดึงได้เพียงบางบัญชี, การเปลี่ยนรูปแบบอีเมล และข้อจำกัดของ passkey ทำให้เกิด Driggsby ขึ้นมาเพื่อลดปัญหาเหล่านี้
• อีเมลสรุปการเงินรายวันประกอบด้วยเพียงพรอมป์ต์ เวลาเรียกใช้งาน และ Driggsby custom connector แต่เพราะ Gmail connector ทำได้แค่สร้างฉบับร่าง จึงเพิ่มเครื่องมือ email_me() เพื่อแก้ปัญหาการส่งจริงและความเสถียรของรูปแบบ
• ด้วยวิธีเดียวกัน ยังทำระบบอัตโนมัติสำหรับ การตรวจจับความผิดปกติของธุรกรรม Amex ในช่วง 7 วันล่าสุด และ การเฝ้าระวังเงินไหลออกก้อนใหญ่เกิน $500 จาก checking account โดยตั้งค่าให้ไม่ส่งการแจ้งเตือนเมื่อทุกอย่างปกติ
• ภาระในการตั้งค่าและดีบักต่ำพอที่จะทำ financial routine แบบปรับแต่งเฉพาะบุคคล แยกตามคู่สมรสได้ และกลายเป็นฐานอัตโนมัติที่ขยายต่อได้รวดเร็วไปสู่การเฝ้าดูการลงทุน การสมัครสมาชิก และการใช้จ่าย

---

จุดเริ่มต้นของระบบอัตโนมัติและโครงสร้างของ Driggsby

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

สิ่งที่ routines เปลี่ยนไป

• Claude Code routines ที่เพิ่งเปิดตัวเมื่อไม่กี่วันก่อน ทำให้การย้ายคำถามซ้ำ ๆ เหล่านี้ไปสู่ ระบบอัตโนมัติเต็มรูปแบบ ทำได้ง่ายขึ้น
• ลูปเอเจนต์ที่รันอยู่บนคลาวด์ไม่ใช่เรื่องใหม่ แต่จุดเด่นของ routines คือกระบวนการตั้งค่าที่เรียบง่ายมาก
  • ไม่ต้องเขียนโค้ดสำหรับ agent loop เอง หรือกำหนดว่าจะ deploy ไว้ที่ไหน
  • ไม่ต้องลุกขึ้นมารันสภาพแวดล้อมเองอย่าง OpenClaw, Codex SDK หรือ claude -p on Hetzner
• แค่เขียนพรอมป์ต์ แล้วเชื่อมข้อมูลและเครื่องมือผ่าน MCP connector ให้เรียบร้อย ก็จัดทำระบบอัตโนมัติได้ทันที

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

• แทนที่สเปรดชีตเก่า

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

• ขั้นตอนการตั้งค่า routine

  • เพียงกรอกพรอมป์ต์ ตั้งเวลาให้รันทุกเช้า เชื่อม Driggsby custom connector แล้วกดบันทึก การตั้งค่าก็เสร็จ
  • แต่ในตอนแรกกลับติดปัญหาทันที เพราะยังไม่มีวิธีส่งอีเมล

• ข้อจำกัดของ Gmail connector และเครื่องมือทดแทน

  • เมื่อลองเพิ่ม Gmail connector ก็ได้อีเมลที่ดูดีและมีข้อมูลหนาแน่น แต่ในความเป็นจริงมันถูกสร้างเป็นแค่ฉบับร่าง ไม่ได้เข้า inbox
  • เพราะ Gmail connector ส่งอีเมลไม่ได้และทำได้แค่สร้าง draft จึงต้องหาวิธีอื่น
  • แม้จะลองดู Claude connector store แล้วก็ยังไม่เห็นวิธีส่งที่ใช้งานสะดวก จึงเพิ่มเครื่องมือ MCP แบบง่าย ๆ ชื่อ email_me() เข้าไปใน Driggsby

• ข้อจำกัดของ email_me() และการทำให้รูปแบบเสถียร

  • email_me() จำกัดปลายทางการส่งไว้เฉพาะ อีเมลที่ผ่านการยืนยันแล้ว ของเจ้าของบัญชี และปิดการใช้งานลิงก์กับรูปภาพ เพื่อให้อยู่ในระดับที่ยอมรับได้ด้านความปลอดภัย
  • เพื่อลดปัญหารูปแบบแกว่งไปมาในแต่ละรอบ จึงกำหนดให้เนื้อหาอีเมลต้องเป็น Markdown เท่านั้น และเพิ่ม CSS สำหรับอีเมลที่เรนเดอร์จาก Markdown

• การดีบักและผลลัพธ์สุดท้าย

  • บั๊กเล็ก ๆ ไม่กี่จุดถูกแก้ได้อย่างรวดเร็ว เพราะสามารถดูขั้นตอนการทำงานของ routines ได้ง่าย
  • UI แทบเหมือนกับ Claude Code session ปกติที่เห็นใน Claude Desktop หรือเว็บแอป จึงตรวจสอบ routine ที่กำลังรันอยู่ได้สะดวก
  • หลังทดสอบไม่กี่รอบ อีเมลเวลา 7:47 น. ก็มาถึงจริง และปัญหาเรื่องอีเมลรายวันก็ถูกแก้ได้
  • หลังจากนั้น หากต้องการเปลี่ยนเนื้อหาอีเมล ก็ทำได้ด้วยการแก้พรอมป์ต์ใน UI ของ routines โดยไม่ต้องแก้โค้ด

• การปรับแต่งแยกสำหรับคู่สมรส

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

การขยายต่อหลังจากอีเมลรายวัน

• ตรวจจับความผิดปกติของธุรกรรมบัตรในช่วง 7 วันล่าสุด

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

• เฝ้าระวังเงินไหลออกก้อนใหญ่จาก checking account

  • ถัดมาคือสร้าง routine เพื่อตรวจว่ามีเงินก้อนใหญ่ออกจาก checking account โดยไม่เป็นไปตามคาดหรือไม่
  • พรอมป์ต์ถูกกำหนดตามเงื่อนไขต่อไปนี้
  • ตัวอย่างพรอมป์ต์ต้นฉบับ
    • ตรวจสอบธุรกรรมของ checking account และเทียบกับข้อมูลธุรกรรม 12 เดือนล่าสุด เพื่อดูว่าในวันล่าสุดมีเงินไหลออกก้อนใหญ่ที่ไม่ตรงกับรูปแบบในอดีตหรือไม่
    • โฟกัสที่ ธุรกรรมเกิน $500
    • เพราะระบบอัตโนมัตินี้รันทุกวัน จึงจำกัดอย่างเข้มงวดให้ตรวจเฉพาะธุรกรรมของวันล่าสุด
    • หากมีรายการที่เข้าเงื่อนไข ให้ส่งอีเมลหัวข้อ "Checking account outflow alert" และหากไม่มี ก็ไม่ต้องแจ้งเตือน

• ขอบเขตการขยายต่อเพิ่มเติม

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

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

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

[GN⁺]

ความคิดเห็นจาก 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 มีแนวโน้มเกิดภาพหลอนได้เก่งพอตัว โดยเฉพาะกับชุดข้อมูลที่ไม่สมบูรณ์หรือมีข้อจำกัด