Chúng tôi dạy Claude đọc purchase order, nhưng vẫn để một con người ký duyệt

Một purchase order rơi vào một hộp Gmail dùng chung dưới dạng PDF. Một người trong team vận hành mở nó ra, đọc đơn hàng trên trang giấy, rồi gõ lại vào ERP, từng dòng, từng màu, từng size. Vài phút cho mỗi đơn, vài lần một ngày, mỗi ngày làm việc. Nhàm chán, máy móc, và đúng kiểu công việc âm thầm bào mòn con người và mời gọi lỗi gõ nhầm chui vào hệ thống dữ liệu gốc.

Nhà sản xuất hàng may mặc tìm đến chúng tôi không cần "AI". Họ muốn lấy lại những phút đó, và muốn đơn hàng trong ERP phải đúng. Hai mục tiêu đó kéo về hai hướng ngược nhau, và toàn bộ thiết kế thực ra là về việc giữ được cả hai cùng lúc.

Bài toán nằm sau bài toán

Đọc một PDF nghe có vẻ dễ, cho đến khi bạn nhìn vào một purchase order ngành may mặc. Nó không phải một danh sách phẳng. Một dòng đơn hàng là một ma trận màu/size: một lưới mà "Style 4471, Navy" giao với "S / M / L / XL", mỗi ô một số lượng, rồi màu tiếp theo lại bắt đầu một lưới mới bên dưới. Con người đọc cái lưới đó trong một giây. Một extraction ngây thơ làm nó nát thành cháo.

Nên nhiệm vụ thật chưa bao giờ là "biến PDF thành text". Nó là: biến một lưới trực quan thành các dòng đơn hàng có cấu trúc mà ERP chấp nhận, với số lượng rơi đúng vào dưới đúng size, mọi lần.

Và điểm đến cũng có ý kiến riêng. Đơn hàng phải vào được Indigo8, một ERP ngành may mặc, đúng cái hình dạng mà import của nó mong đợi: đúng mã SKU, đúng đơn vị, áp đúng business rule. Lấy dữ liệu ra khỏi PDF là một nửa việc. Đưa nó vào một dạng mà ERP nuốt trôi không phàn nàn là nửa còn lại.

Cách tiếp cận

Chúng tôi dựng một pipeline thẳng và quan sát được: inbox bên trái, ERP bên phải, một đường nối rõ ràng giữa từng chặng.

Một watcher nhặt PDF mới từ một folder Gmail đã gắn nhãn và đẩy một job vào queue. PDF gốc cùng metadata của nó được ghi vào storage trước tiên, kèm một unique ID, trước khi bất cứ thứ gì khác đụng vào, nên mỗi đơn hàng có một audit trail ngay từ khoảnh khắc nó đến. Claude làm phần extraction, trả về một JSON schema chặt chẽ thay vì text tự do. Một bước validate-and-map áp business rule và nắn JSON về đúng format import của Indigo8. Rồi nó dừng, và đợi một con người.

Cái khoảng dừng đó là cái ô quan trọng nhất trong sơ đồ.

Vì sao có một con người ở cổng (một cách cố ý)

Phiên bản hiển nhiên của sản phẩm này sẽ đọc PDF và đẩy đơn hàng thẳng vào ERP. Chúng tôi đã có thể dựng cái đó trong tuần thứ tư. Chúng tôi chọn không làm vậy, và đó là quyết định tôi bảo vệ quyết liệt nhất.

ERP là hệ thống dữ liệu gốc. Một số lượng sai trong đó không phải lỗi bề mặt. Nó là một đơn hàng sai, một lệnh cắt sai, mua sai vải. Cái giá của một sai lầm là bất đối xứng: tự động hoá phần đọc tiết kiệm vài phút, nhưng một đơn auto-push sai có thể tốn nhiều ngày. Nên ở phase 1, mọi đơn hàng được trích xuất đều hiện lên trong một review dashboard nhỏ. Một người nhìn PDF gốc đặt cạnh lưới đã trích xuất, duyệt hoặc sửa, và chỉ khi đó nó mới đi tiếp. Những ca confidence thấp hoặc extraction lỗi được đẩy sang một queue riêng thay vì âm thầm đoán bừa.

Việc của AI là gõ. Việc của con người là chịu trách nhiệm. Chúng tôi không muốn làm mờ ranh giới đó cho tới khi các con số xứng đáng.

Kế hoạch chưa bao giờ là giữ một con người ở đó mãi mãi. Nó là để đo: chạy pilot, theo dõi báo cáo độ chính xác extraction hằng tuần, và để auto-push vào ERP chỉ bật lên ở phase 2 một khi số lần phải sửa tiệm cận về không. Niềm tin là thứ bạn giành được bằng một quá trình có thành tích, không phải thứ bạn mặc định ngay ngày đầu.

Cái gì thực sự khó

Ba thứ, không cái nào là phần mọi người hay nghĩ.

Ma trận màu/size. Extraction thường vẫn làm sụp các lưới. Cách sửa là ngừng hỏi "các dòng line item" mà bắt đầu hỏi cấu trúc một cách tường minh: một schema với màu, size, và số lượng từng ô, và buộc model điền vào. Cho model thấy đúng cái hình dạng bạn muốn thì nó ngừng ứng tác. Cái lưới là khác biệt giữa một demo và một thứ team vận hành thực sự tin.

Phần mapping, không phải phần đọc. Khi JSON đã sạch, phần rối là dịch nó sang đúng cái Indigo8 mong đợi: khớp SKU, áp rule về đơn vị và nghiệp vụ, xử lý những đơn không vừa happy path. Đây là khúc giữa kém hào nhoáng mà không demo nào cho thấy và mọi integration thật đều sống trong đó.

Cái inbox nhàm chán. Theo dõi một hộp Gmail một cách đáng tin khó hơn nó trông: OAuth không âm thầm hết hạn, chọn giữa push và poll, không xử lý cùng một email hai lần, retry mà không nhân đôi một đơn hàng. Chúng tôi dựa vào một queue và một đường dead-letter để một lỗi tạm thời thành một lần retry, chứ không phải một PO bị mất.

Bọc quanh tất cả: structured logging, alert khi bất kỳ extraction hay validation nào lỗi, và một audit trail đầy đủ cho từng PO: PDF gốc cộng dữ liệu đã trích xuất, giữ chung dưới một ID. Khi có gì đó trông sai, bạn có thể mở lên chính xác cái gì đã đến và chính xác model đã hiểu nó thành gì.

Nó dừng ở đâu

Phase 1 đã chạy thật và đi qua human review. Những phút gõ tay cho mỗi đơn đã biến mất; cái còn lại cho con người là một cú liếc nhanh và một nút duyệt (vài giây, không phải vài phút), và đơn hàng vào ERP là đã được kiểm, chứ không phải cầu may. Báo cáo độ chính xác hằng tuần đang làm đúng việc của nó: xây cơ sở bằng chứng để quyết định khi nào auto-push đủ an toàn để bật.

Bài học chúng tôi muốn trao cho ai đang tự động hoá việc nhập dữ liệu vào một hệ thống dữ liệu gốc: tự động hoá công việc, đừng tự động hoá trách nhiệm, ít nhất là cho tới khi dữ liệu nói rằng bạn đã xứng đáng. Model là phần dễ và hào hứng. Audit trail, phần mapping, và cổng human review mới là thứ khiến nó an toàn để vận hành.

---

Chúng tôi thiết kế và xây các pipeline document-automation và ERP-integration như thế này end-to-end. Nếu bạn có một hộp PDF đang nuôi một hệ thống mà ai đó phải gõ tay, liên hệ với chúng tôi.