APIANT

Kỹ thuật tích hợp ưu tiên AI với Claude Code: Một phiên gỡ lỗi thực tế

Hướng dẫn chi tiết về kỹ thuật tích hợp ưu tiên trí tuệ nhân tạo, kèm theo các câu hỏi gợi ý thực tế.

Hình minh họa chia đôi khung hình: một phiếu hỗ trợ và một thẻ vấn đề GitHub ở bên trái, một mạng lưới các nút tự động hóa được kết nối ở bên phải, được nối với nhau bằng một đường màu xanh lá cây duy nhất.

Hầu hết các câu chuyện "AI viết mã cho tôi" đều là các bản demo với lời nhắc và kết quả rõ ràng. Nhưng đây không phải vậy. Đây là một phiên làm việc thực tế trên một sản phẩm tích hợp APIANT thực sự, bao gồm cả các lời nhắc thực tế, những sai lầm, những chỉnh sửa và khoảnh khắc trí nhớ con người đánh bại máy móc.

Vấn đề không phải là trí tuệ nhân tạo (AI) gây ấn tượng. Vấn đề là sự hợp tác thực sự diễn ra như thế nào khi bạn ngồi xuống và bắt tay vào làm việc.

Cấu hình

Sản phẩm này là một trong những sản phẩm tích hợp với CRMConnect của chúng tôi. Từ Mindbody đến HubSpotMột khách hàng báo cáo rằng các giao dịch bán hàng được thanh toán bằng nhiều phương thức khác nhau đang bị đồng bộ hóa sai. Một giao dịch bán hàng trị giá 8.400 đô la được chia cho ba phương thức thanh toán khác nhau lại hiển thị trong HubSpot dưới dạng một giao dịch duy nhất trị giá 400 đô la. 8.000 đô la còn lại đã bị thiếu trong quy trình bán hàng.

Chúng tôi theo dõi công việc kỹ thuật trên GitHub Issues. Cuộc trò chuyện với khách hàng diễn ra trên HubSpot Service Hub. Buổi làm việc bắt đầu bằng việc người xây dựng hướng AI vào công việc cần thực hiện.

Gợi ý: “Hãy xem xét vấn đề thanh toán”

Trí tuệ nhân tạo (AI) đã tìm kiếm các vấn đề trên GitHub của kho lưu trữ, tìm thấy sự cố đang mở, trích xuất toàn bộ nội dung và đọc lại: một lỗi bán hàng đa phương thức thanh toán, với hai ID thực thi sản phẩm được trích dẫn làm bằng chứng. Không cần hướng dẫn từng bước. Sau đó, nó hỏi bước tiếp theo một cách rõ ràng thay vì đoán mò.

Gợi ý: “Logic hoạt động như thế nào và những thao tác/hành động tự động nào được thực hiện?”

Trí tuệ nhân tạo (AI) đã tải quy trình tự động hóa liên quan từ nền tảng, phân tích cấu trúc từng bước và giải thích chính xác lỗi xảy ra. Quy trình tự động hóa tạo ra một khóa loại bỏ trùng lặp cho mỗi giao dịch HubSpot. Đối với các giao dịch bán hàng đa phương thức thanh toán, Mindbody trả về một hàng cho mỗi phương thức thanh toán, tất cả đều dùng chung một khóa, vì vậy hàng thứ hai và thứ ba xung đột với giao dịch được tạo bởi hàng thứ nhất và số tiền của chúng đã bị loại bỏ một cách âm thầm.

Hữu ích. Nhưng nhà thầu đã có lợi thế hơn rồi.

Gợi ý đã thay đổi mọi thứ.

Gợi ý: “Hãy so sánh mã định danh duy nhất này cho giao dịch với cách chúng ta thực hiện với dự án crmconnect-mindbody-zoho. Tôi tưởng chúng ta đã giải quyết xong vấn đề ở đó rồi. Hãy so sánh thật kỹ.”

Chỉ một câu này đã thay đổi hoàn toàn cục diện công việc. Người thợ xây không mô tả cách khắc phục. Anh ta chỉ vào một sản phẩm tương tự và nói, đại ý là, hãy đi đọc tài liệu đó.

Vì vậy, trí tuệ nhân tạo đã làm điều đó. Nó đã mở ra... Từ Mindbody đến Zoho Quá trình tích hợp, một sản phẩm hoàn toàn riêng biệt, đã định vị được quy trình tự động hóa xử lý dữ liệu bán hàng lịch sử và đọc dữ liệu đó. Sau đó, nó tìm và đọc chương trình con ghi lại các bản ghi thanh toán. Không phải là các bản tóm tắt. Mà là logic tự động hóa thực tế, từng bước một.

Nó đưa ra một sự so sánh tập trung hơn. Việc tích hợp Zoho thực sự đã giải quyết được vấn đề này, nhưng với một kiến trúc khác:

  • Sản phẩm của HubSpot ghi một giao dịch cố định cho mỗi dòng bán hàng, sử dụng điểm cuối bán hàng cũ hơn của Mindbody, trả về các dòng thanh toán đã được chia nhỏ trước đó.
  • Sản phẩm của Zoho ghi một bản ghi mua hàng chính cùng với các bản ghi con riêng biệt cho từng mặt hàng và từng khoản thanh toán, sử dụng điểm cuối mới hơn của Mindbody, trong đó mỗi khoản thanh toán đều có ID thanh toán thực riêng.

Hai bảng sản phẩm đặt cạnh nhau. Tích hợp Mindbody với HubSpot tạo một hộp giao dịch đơn giản; tích hợp Mindbody với Zoho tạo một giao dịch mua chính kèm theo các mặt hàng và thông tin thanh toán. Một mũi tên cong nối giữa chúng, ghi chú "đọc tích hợp anh em".

Trí tuệ nhân tạo (AI) nhận định rằng Zoho có cấu trúc gọn gàng hơn, và ban đầu đề xuất chuyển toàn bộ mô hình ba đối tượng sang HubSpot.

Nhà thầu thu hẹp phạm vi công việc.

Đây là nơi mà con người giữ cho mọi thứ luôn ở trạng thái thực tế.

Gợi ý: “Chưa sẵn sàng cho phiên bản 4.0. Hãy để dành nó cho sau này, hiện tại chúng tôi cần khắc phục các sự cố về việc thiếu giao dịch mà khách hàng đã báo cáo.”

Trí tuệ nhân tạo (AI) đã hướng tới việc viết lại kiến trúc một cách thỏa đáng. Người xây dựng đã quay trở lại vấn đề cốt lõi: khách hàng cần số tiền giao dịch chính xác, chứ không phải một mô hình dữ liệu mới. AI đồng ý, đóng đề xuất viết lại kiến trúc như một hạng mục cần xử lý trong tương lai, và tập trung vào việc sửa chữa triệt để các quy trình tự động hóa giao dịch hiện có.

Sự điều chỉnh đó rất quan trọng. Trí tuệ nhân tạo giỏi trong việc tìm ra giải pháp tổng quát thanh lịch. Nhưng nó không phải lúc nào cũng giỏi trong việc biết khi nào giải pháp thanh lịch đó lại vượt quá yêu cầu của thời điểm hiện tại. Người xây dựng đã đưa ra nhận định đó chỉ bằng một câu.

Trí tuệ nhân tạo (AI) đã áp dụng nguyên tắc thiết kế của Zoho mà không sao chép cấu trúc của nó: đối chiếu một giao dịch cho mỗi mặt hàng bán hàng, lấy dữ liệu từ điểm cuối giàu thông tin hơn của Mindbody và tổng hợp số tiền chính xác trên các phương thức thanh toán thay vì để khoản thanh toán đầu tiên ghi đè lên các khoản còn lại. Nền tảng khác nhau, hành động khác nhau, nhưng ý tưởng cốt lõi vẫn giống nhau.

Linh cảm

Trong quá trình chỉnh sửa khóa loại bỏ trùng lặp, AI đã xem xét một trong các thành phần của nó: ngày tháng. Lý luận của nó rất rõ ràng. ID giao dịch và ID chi tiết giao dịch đã làm cho khóa trở nên duy nhất. Ngày tháng là dư thừa. Nó đề xuất loại bỏ ngày tháng để đơn giản hóa khóa và loại bỏ nguồn gây lỗi giữa hai quy trình tự động hóa.

Người thợ xây không có văn bản quy định nào để viện dẫn. Ông ta chỉ có trí nhớ.

Gợi ý: “Tôi nhớ là mình đã thêm ngày tháng vào vì nó cần thiết (hai khoản thanh toán trong cùng một giao dịch, hoặc một trường hợp kỳ lạ nào đó tương tự)?”

Cả hai đều không thể chứng minh điều đó từ hệ thống tự động hiện tại. Vì vậy, AI đã xem xét lịch sử phiên bản của hệ thống tự động. Hệ thống tự động có chín mươi ba phiên bản đã lưu, từ năm 2021. AI đã đọc các mô tả thay đổi cho đến khi tìm thấy những thay đổi có liên quan.

Một dòng thời gian dọc thể hiện các phiên bản tự động hóa, hầu hết đều mờ, với một phiên bản tháng 2 năm 2022 được làm nổi bật và kéo vào phần chú thích có nội dung: đã thêm ngày bán hàng để xử lý thanh toán cho các giao dịch bán hàng trước đó.

Từ tháng 1 năm 2022:

“Đã thêm EPOCH MILLIS để lưu ID giao dịch trong cơ sở dữ liệu nhằm đảm bảo tính duy nhất khi thực hiện nhiều khoản thanh toán cho cùng một mặt hàng.”

Từ tháng 2 năm 2022:

“Đã thêm ngày bán hàng vào chức năng tìm kiếm giao dịch theo thuộc tính tùy chỉnh để hệ thống xử lý thanh toán cho các giao dịch đã thực hiện trước đó.”

Theo lời của chính nhà xây dựng, điều đó đã xảy ra bốn năm trước. Khi khách hàng thanh toán sau cho một giao dịch đã thực hiện trước đó, Mindbody sẽ phát hành lại giao dịch đó vào ngày mới. Nếu không có ngày trong khóa, khoản thanh toán sau sẽ xung đột với giao dịch ban đầu và không thể được ghi nhận riêng. Ngày đó không phải là thừa. Nó có vai trò chịu tải, được cố ý thêm vào để xử lý các khoản thanh toán trả góp và thanh toán tự động.

Khóa loại bỏ trùng lặp bốn phần được hiển thị dưới dạng bốn phân đoạn: ID khách hàng, ID giao dịch, ID chi tiết giao dịch và ngày tháng. Phân đoạn ngày tháng được khoanh tròn, với một mũi tên ghi "AI có vẻ dư thừa" và một mũi tên ghi "Lịch sử chịu tải".

Phản ứng của AI là lập tức đảo ngược khuyến nghị của mình và nói rõ điều đó:

“Hãy tin vào trí nhớ đó. Nếu bạn cố tình thêm ngày tháng, nó sẽ được giữ nguyên và việc xóa nó là không thể. Tôi đã tìm thấy nó trong lịch sử phiên bản.”

Sau đó, vấn đề được giải quyết triệt để hơn. Vì ngày tháng phải được giữ nguyên, hai quy trình tự động cần tạo ra cùng một giá trị ngày tháng chính xác, nếu không các khóa sẽ không khớp và sẽ xuất hiện các giao dịch trùng lặp. Quy trình tự động ban đầu tạo ra ngày tháng từ một trường cụ thể trong Mindbody. Trí tuệ nhân tạo (AI) đã điều chỉnh lại quy trình tự động mới để đọc trường giống hệt đó, từ cùng một lệnh gọi API, với cùng một chuyển đổi múi giờ. Cùng một đầu vào, cùng một đầu ra, các khóa được đảm bảo khớp nhau.

Một lỗi hồi quy có thể âm thầm phá vỡ hệ thống xử lý thanh toán trả góp đã không xảy ra. Không phải vì AI cẩn thận, mà vì một người nhớ ra một linh cảm và AI có thể xác minh linh cảm đó dựa trên dữ liệu bốn năm chỉ trong vài giây.

Phần không hào nhoáng: biên dịch, chạy, đọc dấu vết, sửa lỗi.

Sau khi thiết kế được hoàn thiện, quá trình tiếp theo là kỹ thuật lặp đi lặp lại. Xây dựng thay đổi trong môi trường phát triển, chạy thử, đọc dấu vết thực thi, tìm ra vấn đề tiếp theo, sửa lỗi, chạy lại. Những lỗi thực sự thường gặp lại là những lỗi thông thường:

  • Bước tạo lập thỏa thuận đã thất bại với mười sáu PROPERTY_DOESNT_EXIST Lỗi xảy ra do các liên kết trường không sử dụng tên thuộc tính nội bộ của HubSpot. Trí tuệ nhân tạo đã đọc dấu vết, lấy lược đồ trường của trình kết nối và liên kết lại mọi trường với ID chính xác của nó.
  • Vòng lặp chạy hai lần trong khi đáng lẽ chỉ chạy một lần, vì nền tảng đang đếm số lần lặp dựa trên mảng dài nhất trong dữ liệu nguồn, và mảng thanh toán dài hơn mảng các mục hàng. Trí tuệ nhân tạo đã chèn một điều khiển lặp rõ ràng để vòng lặp chỉ đếm các mục hàng.
  • Bước "tìm kiếm giao dịch" đã làm dừng toàn bộ quá trình khi chưa có giao dịch nào tồn tại, vì chế độ lỗi mặc định của nó coi "không tìm thấy" là lỗi nghiêm trọng. Trí tuệ nhân tạo đã chuyển nó sang chế độ tiếp tục khi xảy ra lỗi để nhánh tạo có thể chạy, phù hợp với cách mà quy trình tự động hóa tương tự đã xử lý.

Một vòng lặp gỡ lỗi bốn nút: Xây dựng, Chạy, Đọc dấu vết, Sửa lỗi, được kết nối theo chu kỳ với một đồng hồ bấm giờ ở trung tâm được ghi nhãn là phút, không phải giờ.

Tất cả những điều này đều không hào nhoáng. Đây chính là bản chất thực sự của công việc tích hợp. Điều đã thay đổi là tốc độ vòng lặp. Trí tuệ nhân tạo (AI) có thể đọc toàn bộ dấu vết thực thi từng bước và chỉ ra bước bị lỗi ngay lập tức, do đó mỗi chu kỳ sửa lỗi chỉ mất vài phút. Không có gì được giao cho khách hàng cho đến khi các bài kiểm tra của nhà phát triển thành công.

Hai cột nằm cạnh nhau. Cột AI đọc mã nguồn, đối chiếu và kiểm tra lịch sử. Cột Builder ghi nhớ, đánh giá phạm vi và hiểu khách hàng. Một biểu tượng dấu cộng màu xanh lá cây nối liền chúng.

Điều này có ý nghĩa gì đối với các nhà xây dựng?

Loại bỏ phần tường thuật và đây là mô hình hoạt động:

  • Điểm mạnh của trí tuệ nhân tạo là khả năng đọc. Nó đã nghiên cứu toàn bộ quá trình tích hợp các thành phần anh em, đối chiếu một vấn đề mà chúng tôi đã giải quyết, điều chỉnh kiến trúc trên hai nền tảng khác nhau và xem xét lại lịch sử đến chín mươi phiên bản để xác minh một quyết định thiết kế. Không một người nào có thể làm được điều đó chỉ trong một buổi chiều.
  • Điểm mạnh của con người là trí nhớ và khả năng phán đoán. Câu “Tôi nghĩ tôi thêm điều đó vào vì một lý do nào đó” không có trong bất kỳ tập tin nào. Câu “Chưa sẵn sàng cho phiên bản 4.0” cũng không có trong bất kỳ tập tin nào. Cả hai đều xuất phát từ kinh nghiệm sử dụng sản phẩm thực tế. Mỗi câu đều làm thay đổi kết quả cuối cùng.
  • Tốc độ đến từ vòng lặp. Đọc nhật ký lỗi, sửa bước đó, chạy lại chương trình. Những trở ngại thường làm chậm quá trình gỡ lỗi, tái tạo lại những gì đã xảy ra, giờ đã biến mất.

Kỹ thuật tích hợp ưu tiên AI không phải là AI hoạt động độc lập, và cũng không phải là con người làm việc nhanh hơn. Đó là AI thực hiện việc đọc mà con người không có thời gian làm, và con người cung cấp ngữ cảnh mà mã nguồn không ghi lại. Kết hợp hai điều đó lại, một lỗi lặp đi lặp lại suốt bốn năm sẽ được hiểu, sửa chữa và xác minh chỉ trong một phiên làm việc duy nhất.

Đó chính là quy trình làm việc đáng để hướng tới.