Luật sư Lâm Thượng Luân: Bài viết chuyên đề — BD “cực xịn”, đang bán sức mạnh tích hợp AI

Ở thời đại AI, phát triển kinh doanh có thể tiến hóa toàn diện dựa trên những “điểm đau” của chính đội nhóm mình, dù không phải người làm phát triển toàn thời gian cũng làm được. Xu hướng này có lẽ là thái độ chuẩn bị mà mọi vị trí đều phải có.
(Cuối cùng: Chuyên văn luật sư Lin Shang-Lun》Người chuyên nghiệp hiểu AI liệu có phải sẽ là kẻ chiến thắng trong thời đại AI không?)
(Bổ sung bối cảnh: Chuyên văn luật sư Lin Shang-Lun》Từ vụ việc Cai A-Ga nhìn nỗi sợ AI: Bạn tức không phải vì AI, mà vì sợ bị vượt mặt)

Mục lục

Toggle

• Thứ anh ấy làm, thật sự đụng trúng điểm đau
• Nói về cách anh ấy nhét AI vào
• Nhưng tôi nghĩ, Output còn có thể nhiều hơn
• Dưới góc độ luật sư, có một việc nhất định phải làm: đè ảo giác xuống
• Một vài chức năng tôi nghĩ BD Agent của anh ấy có thể bổ sung
  • Tự động tạo bản sửa đổi hợp đồng từ biên bản cuộc họp
  • Điều chỉnh độ mạnh/yếu của hợp đồng theo lập trường đàm phán
  • Rà soát tuân thủ, chặn rủi ro từ trước
• Cuối cùng

Trong một triển lãm công nghệ, tôi gặp một quản lý phát triển kinh doanh (BD) của một công ty sắp thành “đại công ty”. Đặc biệt hơn là anh ấy tự tay dùng AI làm một bộ hệ thống nội bộ mà công ty họ dùng cho BD. Anh ấy rất hào phóng, rút điện thoại ra đưa cho tôi xem prototype của mình, rồi chúng tôi vừa xem vừa trò chuyện.

Vì bản thân tôi cũng thường xuyên làm phát triển AI, và hơn nữa tôi là luật sư, nên khi xem những thứ của anh ấy khó tránh khỏi việc nghĩ thêm vài tầng. Bài này xem như để tổng hợp lại cuộc trò chuyện hôm đó, ghi lại tôi đã thấy gì, và những hướng tôi đã trò chuyện với anh ấy để có thể tiếp tục “chơi thêm” về sau.

Thứ anh ấy làm, thật sự đụng trúng điểm đau

Ngay từ đầu anh ấy đã nói về một khó khăn rất thực tế: lượng việc phát triển bên ngoài của đội BD quá lớn—lớn đến mức chẳng có ai làm quản lý có thể tiêu hóa hết toàn bộ báo cáo hằng ngày của mọi người. Những gì quản lý có thể đưa ra chỉ là chỉ thị rất thô, không thể hạ chiến thuật chính xác cho từng cửa hàng, từng điểm vị trí. Hơn nữa, sau khi BD tung ra, rất dễ bị va chạm lịch—khiến mọi người cần đồng bộ tiến độ với nhau cũng siêu kém hiệu quả.

Vì vậy anh ấy làm một app. Đăng nhập vào là giao diện admin. Trên đó có nhiều lớp; lớp lõi nhất sẽ trực quan hóa toàn bộ các điểm mà BD đang mở bên ngoài và tình trạng chốt giao dịch. Lợi ích làm được rất trực tiếp:

Một là mọi người không cần nữa việc đồng bộ miệng với nhau; trước khi ai đó mở một đợt phát triển mới, chỉ cần nhìn là biết người khác đã làm những gì, mỗi điểm đang tiến triển đến đâu. Hai là từ góc độ một người đứng quản lý, anh ấy có thể nhìn trực tiếp toàn bộ pipeline—nhà nào đang kẹt ở giai đoạn nào là thấy ngay.

Nói thật, chỉ cần nhìn là biết đây là thứ do một người hiểu BD làm ra. Logic của giao diện đó không phải kiểu kỹ sư nghĩ ra “từ trên trời rơi xuống”; nó thật sự được thiết kế theo cách mà người đi làm việc ngoài thực địa mới nghĩ.

Nói về cách anh ấy nhét AI vào

Tôi bèn tò mò hỏi anh ấy: AI rốt cuộc được dùng ở đâu. Anh ấy nói anh ấy tích hợp một AI, gom toàn bộ kiến thức mà BD dùng khi phát triển bên ngoài, các hợp đồng trong quá khứ và các case hợp tác trước đó thành một cơ sở dữ liệu.

Anh ấy đưa một ví dụ rất thực tế: đôi khi BD phát triển đến thương hiệu theo chuỗi, nhưng cách đàm phán với chuỗi hoàn toàn khác so với từng cửa hàng đơn lẻ. Quy mô chuỗi lớn, thế lực lớn, thường phải làm một số trao đổi lợi ích. Nhưng trong quá trình đào tạo, BD thông thường rất khó diễn đạt rõ ràng: “đối phương thuộc quy mô nào, và phía chúng tôi có thể đưa ra những ‘quân bài’ tương ứng gì”. Vì vậy anh ấy giao cho AI để trả lời việc này. Tôi thấy điểm cắt vào như vậy là bắt rất đúng.

Tôi lại hỏi cách anh ấy làm cơ sở dữ liệu. Anh ấy nói thật là thực ra chỉ triển khai trên một Google Sheet, đọc trực tiếp bằng JS. Nhưng anh ấy nhấn mạnh một điểm: mọi thứ BD đã tra gì, và AI trả về gì, đều có ghi lại, đều có thể lần theo dấu vết. Anh ấy còn viết sẵn một “bộ định nghĩa cho thương gia”: AI sẽ chạy một lần định nghĩa trước, xác định khách hàng mới thuộc loại gì, rồi quay lại đối chiếu với các case hợp tác.

Ở đây có một chi tiết nhỏ tôi đặc biệt muốn nêu. Tôi nói với anh ấy: với Gemini Flash bản miễn phí có một “bẫy”—giới hạn token có thể khiến kết quả không như kỳ vọng. Anh ấy đã nghĩ đến từ trước: anh ấy lên sẵn kế hoạch và “đóng cứng” đường đi cho từng câu hỏi—gặp loại vấn đề nào thì chỉ đọc một vài trang nhất định. Như vậy không chỉ không bị sót, mà còn tiết kiệm thời gian, tiết kiệm Token. Cách làm “không nhét đại, trước tiên phán đoán rồi mới bám dữ liệu” này đúng là chạm đúng trọng tâm.

Nhưng tôi nghĩ, Output còn có thể nhiều hơn

Nhìn đến đây, tôi bèn nói với anh ấy một câu khá thẳng: “Thứ của bạn thật sự rất tốt, rất phù hợp với cách dùng của bên bạn. Nhưng—mùi AI không nồng lắm.”

Tôi không phải soi lỗi, mà là cảm thấy vẫn còn không gian để “chơi thêm”. Thứ anh ấy đang làm về bản chất là biến những dấu vết công việc BD trong quá khứ vốn mờ đục, không kiểm soát được, không truy lại được—thành thứ minh bạch, nhìn thấy được, quản được. Tầng input đã làm rất vững.

Nhưng đứng ở góc nhìn người phát triển, tôi thấy anh ấy bị kẹt ở output. Hiện output của anh ấy gần như tập trung vào ChatBox và việc整理 dữ liệu. ChatBox thì đúng là thứ hay, nhưng tôi nghĩ output của anh ấy có thể đưa đến nhiều nơi hơn, chẳng hạn:

Một là trực tiếp xuất ra các tài liệu theo form công ty như MOU, báo cáo… thay vì để người ta xem xong đoạn hội thoại rồi tự mình整理. Hai là dùng các giao diện và luồng quy trình khác nhau để xử lý các nhiệm vụ khác nhau; không phải việc gì cũng nhét vào cùng một khung hội thoại. Dưới lớp thì vẫn là LLM, nhưng có thể thiết kế các Agent khác nhau theo từng tình huống—một loại nhiệm vụ đi với một loại quy trình.

Dưới góc độ luật sư, có một việc nhất định phải làm: đè ảo giác xuống

Đoạn này là tôi nói chuyện với anh ấy dựa trên góc nhìn luật sư. Vì thứ anh ấy làm sẽ đụng đến hợp đồng, đụng đến điều kiện thương mại—dung sai sai sót còn nhỏ hơn nhiều so với người bình thường nghĩ.

Thói quen của tôi là: nội dung do AI tạo ra không được phép bịa đặt bất kỳ thứ gì. Vì vậy tôi đề xuất anh ấy bổ sung hai thứ:

Một là trích dẫn kèm nguồn gốc. Sau mỗi kết quả xuất ra, gắn một citation; bấm vào là thấy “câu này lấy từ tài liệu nào, đoạn nào”. Cái này với anh ấy lại đặc biệt quan trọng—BD cầm “quân bài đàm phán” AI đưa ra đi tác chiến tại hiện trường. Nếu không thể xác nhận lại nguồn gốc, thì tức là đang đem thứ chưa được kiểm chứng đi mạo hiểm.

Hai là giảm temperature. Càng là tình huống cần chính xác, không thể bốc đồng, thì càng nên đè độ ngẫu nhiên của mô hình xuống. Kết hợp hai cái này lại thì không gian cho ảo giác sẽ nhỏ đi rất nhiều.

Một vài chức năng tôi nghĩ BD Agent của anh ấy có thể bổ sung

Công ty họ có bộ phận pháp chế, có luật sư; hợp đồng đa phần là mẫu, không sửa nhiều. Nghe có vẻ như AI không có đất dụng võ, nhưng tôi lại thấy chính những tình huống “nhìn có vẻ vững” mới là chỗ để chơi. Tôi lướt qua vài hướng với anh ấy:

2. Tự động tạo bản sửa đổi hợp đồng từ biên bản cuộc họp

Sau khi BD đàm phán xong, thứ mệt nhất là biến hai tiếng thảo luận thành điều khoản chính thức. Việc này AI làm rất giỏi: lấy mẫu công bản đưa cho nó, rồi nhét toàn bộ biên bản cuộc họp vào—nó sẽ sinh ra phiên bản mới dựa theo kết luận; những phần bị xóa/sửa sẽ được đánh dấu bằng track changes, để pháp chế nhìn vào là biết chỗ nào đã bị động.

3. Điều chỉnh độ mạnh/yếu của hợp đồng theo lập trường đàm phán

Cái này tôi thấy thú vị nhất, vì nó vừa có thể nối với logic trong hệ thống của anh ấy. Vấn đề của mẫu công bản là nó không phản ánh được sự chênh lệch về “lực” trong từng lần đàm phán. Đàm phán với một tập đoàn lớn: lập trường bên chúng tôi yếu, thì điều khoản viết mềm hơn một chút; đàm phán với một đối tượng nhỏ: lập trường bên chúng tôi mạnh, thì điều khoản có thể cứng hơn. Không có hợp đồng nào “một kiểu áp cho mọi người”—mỗi hợp đồng đều nên cá nhân hóa. Nếu Agent của anh ấy có thể dựa vào “quy mô đối phương” để tự sinh các phiên bản có độ mạnh/yếu khác nhau, chẳng phải sẽ ăn khớp với ý tưởng “quy mô tương ứng vũ khí” trong hệ thống của anh ấy sao?

4. Rà soát tuân thủ, chặn rủi ro từ trước

Nội dung BD đăng ra bên ngoài thường có rủi ro về tuân thủ. AI có thể giúp rà soát từng câu: chữ nào bị phóng đại quá đà, câu nào nói quá “lố”, vi phạm điều luật nào, nên xóa hay nên thêm cảnh báo. Với một đội BD mỗi ngày chạy ngoài thực địa, khả năng “chặn từ trước” như vậy thực sự rất hữu ích.

Tôi cũng nhắc anh ấy một câu: nếu công ty muốn đặc biệt giữ một vài điều khoản nào đó, thì thực tế không hề mâu thuẫn. Lời lẽ có thể đổi, giọng điệu có thể đổi, nhưng về mặt bản chất là giữ quyền lợi của bên mình—về mặt kỹ thuật thì làm được hoàn toàn.

Cuối cùng

Nói chuyện xong ngày hôm đó, tôi nhớ rất rõ. Anh ấy tốn ba tuần, còn cố ý dùng ngân sách của chính mình—trước khi làm xong prototype thì không đụng đến tài nguyên của công ty. Anh ấy biến một điểm đau thật thành thứ dùng được, và nhân viên đã dùng, ông chủ cũng gật đầu.

Hai tháng rưỡi qua anh ấy làm đi làm lại một việc—tìm điểm đau, tìm thời điểm mà AI có thể chen vào. Tôi nghĩ đây mới là thái độ mà người muốn dùng AI nên có: không phải “AI rất ngầu, thử chơi thôi”, mà là “chỗ này rất đau, AI có thể giúp giảm đau không”.

Nói cho cùng, AI hữu dụng nhất thường không phải cái ngầu nhất, mà là cái hiểu nghiệp vụ nhất, bám sát nhất vào đúng điểm đau thực tế. Nhìn thấy một BD làm cực giỏi bắt đầu nghĩ cách dùng AI để xử lý công việc của mình theo logic riêng, tôi thật sự cũng rất mong anh ấy về sau sẽ làm ra được những gì.