Hướng Dẫn Prompt
Cách viết đề xuất dự án với Claude
Đề xuất được duyệt là đề xuất cụ thể. Đề xuất bị bỏ qua là đề xuất mơ hồ.
Claude của Anthropic rất giỏi biến một ý tưởng dự án thô sơ thành đề xuất có cấu trúc với phát biểu vấn đề, phạm vi, thời gian biểu, và loại chi tiết cụ thể thực sự khiến bên liên quan nói đồng ý. Điều Claude không biết là ngân sách của bạn, năng lực thực tế của nhóm bạn, hay vấn đề nội bộ của tổ chức bạn, trừ khi bạn nói cho nó biết, đó là lý do "viết cho tôi một đề xuất dự án cho X" thường trả về thứ gì đó chung chung đủ để thuộc về bất kỳ công ty nào. Giải pháp là cung cấp cho Claude các ràng buộc thực tế: đề xuất này dành cho ai, bạn thực sự có gì để làm việc, và quyết định bạn cần từ người đó.
Để yêu cầu Claude viết đề xuất dự án, cung cấp vấn đề bạn đang giải quyết, đề xuất dành cho ai và quyết định bạn cần từ họ, các ràng buộc thực tế của bạn (quy mô nhóm, thời gian biểu ước tính, phạm vi ngân sách), và yêu cầu cấu trúc bản thảo thành phát biểu vấn đề, phương pháp đề xuất, phạm vi, thời gian biểu, và chỉ số thành công. Dán vào bất kỳ tài liệu tham khảo, đề xuất trước đó, hoặc ghi chú bạn đã có, và yêu cầu Claude đánh dấu bất cứ điều gì quá mơ hồ để biến thành một kế hoạch cụ thể.
Ngày đăng
Bài học miễn phí · không cần tài khoảnGặp Gỡ ClaudeVì Sao Chọn Claude?6 phútBắt đầu bài học miễn phíĐiểm chính
- Nói đề xuất dành cho ai và quyết định bạn cần họ đưa ra. Đề xuất để nhóm của bạn lập kế hoạch đọc khác với đề xuất xin một lãnh đạo phê duyệt ngân sách.
- Cung cấp cho Claude các ràng buộc thực tế của bạn: quy mô nhóm, thời gian biểu ước tính, phạm vi ngân sách. Một kế hoạch dựa trên ràng buộc bịa đặt phải được viết lại ngay khi ai đó có số liệu thật đọc nó.
- Yêu cầu chỉ số thành công một cách cụ thể, không chỉ là mô tả công việc. Một đề xuất không nói rõ làm sao để biết nó đã thành công khó được phê duyệt hơn và khó theo dõi sau này hơn.
- Dán vào tài liệu tham khảo bạn đã có: đề xuất trước đó, ghi chú họp, một bản phác thảo thô. Claude tổ chức và mài sắc những gì bạn cung cấp; nó không thể bịa ra bối cảnh đằng sau dự án cụ thể của bạn.
- Đọc kỹ phần phạm vi đặc biệt trước khi gửi. Một phạm vi mơ hồ hoặc rộng hơn ý định thực sự của bạn là lý do phổ biến nhất khiến đề xuất gây ra vấn đề sau này.
Sao chép và dán
Prompt bạn có thể dùng ngay hôm nay
Một bản thảo đầy đủ đầu tiên từ ý tưởng thô sơ
Tôi muốn đề xuất [mô tả ý tưởng dự án của bạn trong một hoặc hai câu]. Đây là dành cho [đề xuất dành cho ai và quyết định bạn cần từ họ]. Đây là những gì tôi thực sự có để làm việc: nhóm [quy mô], thời gian biểu khoảng [khung thời gian], ngân sách khoảng [phạm vi, hoặc 'chưa xác định']. Viết một bản thảo đề xuất với phát biểu vấn đề, phương pháp đề xuất, phạm vi (bao gồm những gì nằm ngoài phạm vi một cách rõ ràng), thời gian biểu ước tính, và chỉ số thành công. Đánh dấu bất cứ điều gì bạn phải đoán vì tôi không cung cấp đủ chi tiết.
Trung thực về những gì bạn chưa biết, như ngân sách, tạo ra bản thảo hữu ích hơn là bịa ra một số để lấp đầy khoảng trống.
Biến ý tưởng lộn xộn thành phát biểu vấn đề
Đây là những ghi chú thô, lộn xộn của tôi về một vấn đề tôi muốn giải quyết: [dán ghi chú của bạn]. Biến điều này thành một phát biểu vấn đề ngắn gọn, hai đến ba câu, giải thích tại sao điều này quan trọng và ai bị ảnh hưởng, chưa mô tả giải pháp. Tôi muốn vấn đề được định hình rõ ràng trước khi đề xuất cách khắc phục.
Giữ phát biểu vấn đề tách biệt với giải pháp; một đề xuất nhảy thẳng đến giải pháp thường làm mất người đọc chưa bị thuyết phục rằng có vấn đề đáng giải quyết.
Xác định phạm vi, bao gồm những gì nằm ngoài
Đây là dự án tôi đề xuất: [mô tả nó]. Viết một phần phạm vi nêu rõ dự án này sẽ bao gồm và không bao gồm gì, với ít nhất ba điều cụ thể được nêu rõ nằm ngoài phạm vi. Tôi muốn tránh đề xuất bị hiểu rộng hơn ý định của tôi.
Một danh sách rõ ràng về những gì nằm ngoài phạm vi thường là phần của đề xuất ngăn chặn nhiều nhầm lẫn nhất sau này.
Kiểm tra độ bền của đề xuất trước khi gửi
Đọc bản thảo đề xuất này như thể bạn là bên liên quan quyết định có phê duyệt không: [dán bản thảo của bạn]. Bạn sẽ có câu hỏi gì trước khi phê duyệt điều này? Thời gian biểu, phạm vi, hoặc chỉ số thành công có vẻ không thực tế hoặc không rõ ràng ở đâu? Hãy cụ thể về điều gì còn thiếu, không chỉ điều gì sai.
Cách này hiệu quả nhất ngay trước khi gửi đề xuất, như một bước kiểm tra cuối cùng thay vì một bước bản thảo sớm.
Điều chỉnh giọng điệu của đề xuất cho đối tượng khác
Đây là đề xuất dự án tôi đã viết cho nhóm của mình: [dán bản thảo của bạn]. Viết lại cho đối tượng lãnh đạo cần phê duyệt ngân sách: bắt đầu với luận điểm kinh doanh và chi phí, giữ chi tiết kỹ thuật ngắn gọn, và chuyển chi tiết triển khai vào phần phụ lục ở cuối.
Cùng một dự án thường cần hai phiên bản khác nhau tùy vào ai đọc và họ cần quyết định điều gì.
Cấu Trúc
Năm phần mà prompt đề xuất cần
Năm phần này biến một ý tưởng mơ hồ thành thứ bên liên quan có thể thực sự hành động theo.
Một phát biểu vấn đề, trước giải pháp
Nêu vấn đề và tại sao nó quan trọng trước khi mô tả giải pháp. Một người đọc chưa bị thuyết phục rằng có vấn đề sẽ không nghiêm túc xem xét một giải pháp được đề xuất cho nó.
Phạm vi, bao gồm những gì nằm ngoài một cách rõ ràng
Nói dự án sẽ làm gì và, quan trọng không kém, sẽ không làm gì. Một đề xuất không có phạm vi rõ ràng có xu hướng mở rộng trong đầu mỗi người thành điều họ cho là nó có nghĩa.
Ràng buộc thực tế, không bịa đặt
Cung cấp cho Claude quy mô nhóm thực tế, thời gian biểu ước tính và phạm vi ngân sách của bạn, dù một phần vẫn còn chưa chắc chắn. Kế hoạch dựa trên số bịa đặt phải làm lại ngay khi số thật xuất hiện.
Chỉ số thành công, nêu rõ ràng
Nói làm sao bạn sẽ biết dự án đã thành công. Một đề xuất không có chỉ số thành công khó được phê duyệt hơn, và nếu được phê duyệt thì khó theo dõi sáu tháng sau.
Hiểu Người Đọc Của Bạn
Cùng một dự án cần đề xuất khác nhau cho đối tượng khác nhau
Một đề xuất viết cho nhóm của bạn lập kế hoạch và một đề xuất viết để xin lãnh đạo phê duyệt ngân sách làm những công việc khác nhau, dù mô tả cùng một dự án. Phiên bản cho nhóm có thể đi sâu vào chi tiết triển khai vì người đọc đã quan tâm đến điều đó. Phiên bản lãnh đạo cần bắt đầu với luận điểm kinh doanh và chi phí, vì đó là quyết định thực sự mà người đọc đó phải đưa ra, và chi tiết không cần thiết chỉ làm chậm quyết định bạn đang yêu cầu.
Nói rõ với Claude ai đang đọc và quyết định bạn cần từ người đó. "Đây là để nhóm tôi lập kế hoạch quý tới" và "điều này cần được phê duyệt ngân sách từ một phó giám đốc không biết chi tiết kỹ thuật" đưa Claude đến hai bản thảo khác nhau, ngay cả cho cùng một dự án, và nêu rõ đối tượng từ trước giúp bạn tránh viết một phiên bản rồi phát hiện sau đó là sai cho người đọc thực sự.
Nếu bạn thực sự cần cả hai phiên bản, thường nhanh hơn khi viết phiên bản chi tiết cho nhóm trước rồi yêu cầu Claude điều chỉnh cho đối tượng lãnh đạo, thay vì viết cả hai từ đầu. Các sự thật cơ bản không thay đổi; chỉ thay đổi điều gì được nhấn mạnh và điều gì chuyển vào phụ lục.
Lỗi Thường Gặp
Điều gì khiến đề xuất bị kẹt lại thay vì được phê duyệt
Đây là những khoảng trống biến một ý tưởng hợp lý thành đề xuất bị bỏ lại không có hồi đáp.
Phạm vi rộng hơn ý định thực sự của bạn
Nếu bạn không nêu rõ điều gì nằm ngoài phạm vi, người đọc sẽ lấp đầy khoảng trống bằng giả định của họ, thường rộng hơn những gì bạn muốn đề xuất. Nói rõ dự án này sẽ không bao gồm gì.
Không có quyết định rõ ràng cho người đọc
Một đề xuất không nói rõ bạn thực sự đang yêu cầu điều gì, phê duyệt, ngân sách, nhân sự, đèn xanh để bắt đầu, khiến người đọc không biết họ cần phản hồi gì.
Số liệu bịa đặt thay cho ràng buộc thực tế
Thời gian biểu hoặc ngân sách mà Claude đoán vì bạn không cung cấp sẽ nghe có vẻ chắc chắn dù là bịa đặt, và người có số liệu thực sẽ nhận ra đề xuất không khớp với thực tế.
Không có cách nào để biết sau này liệu có thành công không
Một đề xuất không có chỉ số thành công khó được phê duyệt một cách chắc chắn, và nếu được phê duyệt thì không có cách thống nhất để kiểm tra sáu tháng sau liệu dự án có đạt được không.
Sử Dụng Những Gì Bạn Đã Có
Dán tài liệu tham khảo của bạn thay vì bắt đầu từ con số không
Nếu bạn có một đề xuất trước đó cho điều tương tự, ghi chú họp thô về vấn đề, hoặc thậm chí một bản phác thảo nửa hoàn chỉnh, hãy dán nó vào thay vì mô tả dự án từ bộ nhớ từ đầu. Claude có thể tổ chức và mài sắc tài liệu bạn đã có đáng tin cậy hơn nhiều so với việc bịa ra bối cảnh cụ thể, lịch sử, và ràng buộc của dự án thực sự của bạn từ mô tả một câu.
Điều này đặc biệt quan trọng với phát biểu vấn đề. Nếu vấn đề xuất hiện trong một cuộc họp, trong một lời phàn nàn của khách hàng, hoặc trong một lần thử thất bại trước đó về điều tương tự, bối cảnh đó thuộc vào prompt. Một phát biểu vấn đề chỉ được xây dựng từ bản tóm tắt hiện tại của bạn về vấn đề thường mất đi chi tiết cụ thể làm cho vấn đề trở nên thực tế và đáng giải quyết ngay từ đầu.
Điều này cũng áp dụng cho ràng buộc. Nếu tổ chức của bạn đã có mẫu đề xuất tiêu chuẩn, phạm vi ngân sách điển hình cho loại dự án này, hoặc quy ước thời gian biểu hiện có, hãy cung cấp trực tiếp cho Claude thay vì để nó mặc định về cấu trúc chung. Một đề xuất đã khớp với cách tổ chức của bạn mong đợi thấy loại tài liệu này sẽ được đọc nghiêm túc hơn một đề xuất đọc như mẫu từ nơi khác.
Bạn nên giữ một thư mục cập nhật các đề xuất đã được phê duyệt tại tổ chức của bạn, dù chỉ là không chính thức, và dán một đề xuất đã thành công vào cạnh bản thảo của bạn khi có thể. Claude có thể nhận ra khuôn mẫu của những gì thường được chấp thuận, cho dù đó là một mức độ trang trọng nhất định, sở thích dùng đoạn văn ngắn hơn là dài, hay thói quen mở đầu bằng cách giảm thiểu rủi ro, và áp dụng chính khuôn mẫu đó vào bản thảo hiện tại của bạn, thay vì mặc định dùng một cấu trúc chung không khớp với những gì thực sự hiệu quả ở nơi bạn làm việc.
Trước Khi Gửi Đi
Những gì cần kiểm tra trước khi đề xuất đến tay người đọc
Đọc phần phạm vi trước và tự hỏi liệu nó mô tả chính xác điều bạn định làm, không hơn không kém. Đây là phần có khả năng gây ra vấn đề nhất sau này nếu nó mơ hồ hoặc rộng hơn ý định thực sự của bạn, vì nó trở thành điều mọi người chỉ vào khi dự án đã triển khai.
Kiểm tra mọi số liệu so với thực tế: thời gian biểu, quy mô nhóm, ngân sách. Một kế hoạch nghe tự tin nhưng dựa trên số liệu đoán tồi tệ hơn một "thời gian biểu chưa hoàn thiện" trung thực, vì cái đầu tiên bị coi là một sự cam kết ngay khi ai đó đọc nó.
Cấu trúc ở đây giúp bạn có bản thảo mạnh nhanh chóng; sự đánh giá về điều tổ chức và người đọc của bạn thực sự cần cho đề xuất cụ thể này vẫn là của bạn trước khi nó được gửi đi.
Đề xuất rõ ràng được đọc. Đề xuất mơ hồ bị bỏ qua.
Cấu trúc này có thể dùng lại cho mọi đề xuất sau đây. Các bài học miễn phí của Nightschool AI đi qua các nhiệm vụ viết công việc thực tế với Claude, bao gồm các quyết định về phạm vi và đối tượng.
Câu hỏi thường gặp
Điều quan trọng nhất cần nói với Claude trước khi nó soạn đề xuất là gì?
Đề xuất dành cho ai và quyết định bạn cần họ đưa ra. Đề xuất để nhóm của bạn lập kế hoạch và đề xuất xin lãnh đạo phê duyệt ngân sách cần khuôn khổ khác nhau, ngay cả với cùng một dự án.
Tôi có nên cung cấp cho Claude một số ngân sách nếu tôi chưa có không?
Không. Nói rằng ngân sách chưa được hoàn thiện thay vì để Claude đoán một số. Một số bịa đặt nghe tự tin sẽ bị coi là cam kết ngay khi ai đó có số liệu thực nhìn thấy nó.
Tại sao đề xuất cần một phần rõ ràng về những gì nằm ngoài phạm vi?
Không có nó, người đọc sẽ lấp đầy khoảng trống bằng giả định của họ về những gì dự án bao gồm, thường rộng hơn ý định thực sự của bạn. Nêu rõ điều gì bị loại trừ ngăn chặn sự trôi dạt đó.
Làm sao tôi viết đề xuất vừa hiệu quả cho nhóm của tôi vừa cho lãnh đạo?
Viết phiên bản chi tiết cho nhóm trước, sau đó yêu cầu Claude điều chỉnh cho người đọc lãnh đạo: bắt đầu với luận điểm kinh doanh và chi phí, giảm chi tiết kỹ thuật, và chuyển chi tiết triển khai vào phụ lục.
Tôi có thể dùng ghi chú từ đề xuất trước hoặc cuộc họp thay vì bắt đầu từ đầu không?
Có, và bạn nên làm vậy. Dán tài liệu tham khảo bạn đã có. Claude tổ chức và mài sắc tài liệu thật tốt hơn nhiều so với việc bịa ra bối cảnh cụ thể của dự án bạn từ con số không.
Tại sao đề xuất cần chỉ số thành công?
Không có cách nêu rõ để đo lường thành công, đề xuất khó được phê duyệt một cách chắc chắn, và không có cách thống nhất để kiểm tra sau này liệu dự án có thực sự đạt được điều đã hứa không.
Tôi nên kiểm tra bản thảo như thế nào trước khi gửi cho bên liên quan?
Yêu cầu Claude đọc nó như bên liên quan sẽ làm và liệt kê những câu hỏi họ sẽ có trước khi phê duyệt. Sau đó kiểm tra riêng từng số liệu trong bản thảo so với ràng buộc thực tế của bạn trước khi gửi đi.
Nếu tổ chức của tôi đã có mẫu đề xuất tiêu chuẩn thì sao?
Cung cấp trực tiếp cho Claude thay vì để bản thảo mặc định về cấu trúc chung. Một đề xuất đã khớp với định dạng mà tổ chức của bạn mong đợi sẽ được đọc nghiêm túc hơn một đề xuất không khớp.
Đề xuất được phê duyệt bắt đầu từ ràng buộc thực tế
Cấu trúc này có thể dùng lại mỗi lần. Cung cấp số liệu trung thực thay vì đoán là phần đáng làm đúng.