Dự án mẫu là một công cụ jxm-labs dùng thật được: một trợ lý biến đề bài của khách thành <b>bản đề xuất nháp đầu tiên</b> — cách tiếp cận, model, kế hoạch theo giai đoạn và khoảng giá ước lượng — để một senior chỉ việc rà soát. Bên dưới: đề bài khởi động, rồi mỗi yêu cầu ánh xạ thành một quyết định trong quy trình ra sao. dự án tự dùng nội bộ
Từ: Maxime (sáng lập) — jxm-labs
Đến: đội ngũ giao dự án
Chủ đề: Hãy tự làm cho mình một trợ lý viết đề xuất
Cả đội,
Chúng ta thắng nhờ giá và tốc độ, nhưng khâu pre-sales của chính mình lại là nút thắt. Mỗi email khách gửi đến đều phải một senior đọc, rồi tự tay viết phạm vi, chọn cách tiếp cận, và đoán giá từ trí nhớ. Nó chậm, mỗi người làm một kiểu, và junior thì chưa làm được.
Tôi muốn gì. Một trợ lý nhận đề bài thô của khách và soạn bản đề xuất nháp đầu tiên để senior chỉ việc rà soát rồi gửi. Với mỗi đề bài nó cần xuất ra:
Phải dùng kiến thức của chính mình, không được bịa. Mọi ước lượng phải bám vào bảng giá và dự án cũ giống nhất — và trích dẫn dự án đó. Một con số sai trong hộp thư khách làm ta mất tiền hoặc mất uy tín.
Yêu cầu bắt buộc: biết khi nào nên im lặng. Nếu đề bài thuộc loại ta không nhận (tự train model từ đầu, voice thời gian thực), hoặc quá mơ hồ để khoanh vùng, nó KHÔNG được bịa báo giá — mà phải hỏi đúng câu và chuyển cho người thật.
Ràng buộc. Giữ chi phí vận hành hợp lý. Vài giây mỗi đề bài là ổn. Tạm thời tiếng Anh. Là công cụ nội bộ — một lệnh CLI / Slack là đủ để bắt đầu.
Thành công. Senior gửi được phần lớn bản nháp chỉ với chỉnh sửa nhẹ, không bao giờ bịa giá hay bịa dự án, và junior chạy được mà không cần trợ giúp.
— Max
Cụ thể, cái gì được giao — hai lối vào, một agent:
Một giao diện web đơn giản: senior dán đề bài của khách và nhận lại bản đề xuất có cấu trúc trong vài giây — vấn đề, cách tiếp cận, model, kế hoạch giai đoạn, khoảng giá, rủi ro.
Cùng agent đó còn theo dõi một hộp thư chung: đọc từng email đến, nhận diện email nào là đề bài thật, và tự soạn sẵn một đề xuất — để senior mở hộp thư là đã có bản nháp sẵn để rà soát, không phải email trống.
Đằng sau cả hai: RAG trên tài liệu công ty (dịch vụ, bảng giá, dự án cũ, phương pháp) và tài liệu của chính khách (tệp đính kèm đề bài, website, đặc tả). Claude soạn đề xuất bám nguồn và trích dẫn đúng những gì đã dùng.
Mỗi bản nháp được lưu vào database và hiển thị trên dashboard. Senior rà soát, xuất PDF có thương hiệu, rồi duyệt (→ gửi email cho khách) hoặc từ chối. Không gì được gửi nếu thiếu một cú click; nó vẫn từ chối báo giá đề bài ngoài phạm vi hoặc mơ hồ.
Claude Sonnet + embeddings local (chi phí thấp), một database cho các đề xuất, một dashboard web, xuất PDF, và bộ gửi email. CLI cho dev hiện tại; ứng dụng web là sản phẩm bàn giao; lệnh Slack / nhúng CRM tính sau.
| Đề bài nói… | Ta quyết định (giai đoạn nào) |
|---|---|
| "soạn bản đề xuất nháp để senior rà soát" | Có người trong vòng lặp khi soạn, không tự gửi (phạm vi GĐ 1). |
| "dùng kiến thức của mình, không bịa" | Bám kiến thức của agency + rào chắn không-bịa (GĐ 2–3, 5). |
| bảng giá & phương pháp ít đổi; dự án cũ thì tăng dần | Lai (hybrid): ghim dịch vụ/bảng-giá/phương-pháp vào prompt, RAG trên các dự án cũ (GĐ 3). |
| "mọi ước lượng bám dự án cũ giống nhất, trích dẫn nó" | Truy hồi top-k dự án cũ; bám + trích dẫn; báo giá theo khoảng (GĐ 3, 5). |
| "biết khi nào im lặng" (ngoài phạm vi / mơ hồ) | Rào chắn độ-tin-cậy thấp → hỏi làm rõ, không báo giá; 2 bẫy "không được báo giá" trong eval (GĐ 1, 6). |
| "senior gửi được phần lớn bản nháp, không bao giờ sai giá" | Tiêu chí thành công → bảng điểm eval (GĐ 1, 6). |
| soạn một đề xuất là suy luận thực sự | Bắt đầu Haiku, leo lên Sonnet vì eval bắt buộc; Opus chấm điểm (GĐ 4). |
Chưa chắc một đề bài cần cách tiếp cận & model nào? Mở cố vấn. Mã nguồn chạy nằm trong ai-delivery-playbook/project/.