Bạn đang viết những hướng dẫn đó cho một mô hình trước đó phải không?
"Hãy đọc tài liệu này mỗi lần," "Luôn kiểm tra," "Xác nhận trước khi bắt đầu." Nhiều người có lẽ đã thêm những hướng dẫn này để ngăn Codex gặp lỗi.
Bởi vì nó đã sửa chữa mọi thứ mà không đọc tài liệu, bạn đã viết để nó đọc trước. Bởi vì nó đã tiến hành mà không được phép, bạn đã viết để nó xác nhận trước khi tiếp tục.
Mặc dù những câu đó có lý do vào thời điểm đó, nhưng chúng có thể không còn hữu ích khi mô hình thay đổi.
Các quy trình được quyết định để hỗ trợ các mô hình trước đó có thể quá chi tiết đối với GPT-6 Astra. Ngược lại, bởi vì bạn chưa truyền đạt phạm vi dự kiến, nó có thể dừng lại để yêu cầu xác nhận một cách không cần thiết.
Điều cần xem xét không chỉ là số lượng hướng dẫn. Đó là về giảm các tác vụ lặp đi lặp lại và làm rõ các kịch bản cần thiết cũng như điều kiện hoàn thành.
Eric Provencher, người phụ trách trải nghiệm nhà phát triển Codex tại OpenAI, đề cập đến vấn đề này trong một bài viết có tựa đề "Rethinking skills and prompts for GPT-6 Astra."
Điều này không chỉ bao gồm các yêu cầu bạn viết trong chat, mà còn cả "AGENTS.md," nơi truyền tải các quy tắc làm việc cho các tệp dự án trong một kho lưu trữ.
"Skills" là tập hợp các quy trình và kiến thức được sử dụng cho các tác vụ cụ thể. Các hướng dẫn được lưu ở đây cũng ảnh hưởng đến cách Codex tiến hành.
Trong bài viết này, dựa trên giải thích của Eric và các hình ảnh tham khảo, chúng ta sẽ xem xét những gì cần giảm bớt, những gì cần giữ lại và cách viết lại. Các ví dụ được tạo cho độc giả được đánh dấu là "Ví dụ Ứng dụng" để phân biệt với các ví dụ gốc.
Đây không phải là về việc đổ lỗi cho tất cả các thất bại của Astra cho các hướng dẫn cũ. Đây là một bài viết để kiểm toán các quy tắc bạn đã tích lũy nhằm xem quy tắc nào không còn phù hợp với công việc hiện tại.
1. Tại Sao Bạn Cần Xem Xét Lại Các Hướng Dẫn Cho Astra
Điểm khởi đầu của Eric là sự thay đổi khi các hướng dẫn nhằm "giám sát" mô hình đang trở nên ít cần thiết hơn trước.
Trước đây, một số tác vụ sẽ không tiến hành trừ khi bạn chỉ định từng bước theo thứ tự. Để bù đắp cho sự mơ hồ, chúng ta đã chất đống các quy trình và ghi chú chi tiết.
Tuy nhiên, văn bản gốc nói rằng các mô hình đang trở nên tốt hơn trong việc xử lý các khác biệt tinh tế về ý nghĩa và sự mơ hồ. Nó chỉ ra rằng các đặc tả chi tiết từng hữu ích giờ đây có thể cản trở kết quả.
Điều chúng ta không nên hiểu sai ở đây là đây không phải là một cuộc trò chuyện về việc "ngừng giải thích vì mô hình thông minh hơn."
Eric cũng khuyến nghị giữ hướng dẫn cho các tài liệu cần thiết. Văn bản gốc vẫn yêu cầu giải thích về phạm vi tiến triển an toàn và công việc cần thiết để hoàn thành.
Ngay cả đối với cùng một hướng dẫn, cách bạn xem xét nó thay đổi tùy thuộc vào ý nghĩa của câu đó.
Ví dụ, bạn cần phân biệt giữa các giải thích truyền đạt hoàn cảnh cụ thể của dự án và những giải thích nhằm làm cho các mô hình trước đó tuân theo quy trình.
"Các ràng buộc thiết kế được viết trong tài liệu này" là một manh mối để tìm kiếm thông tin. Mặt khác, "Đọc toàn bộ tài liệu này từ đầu cho mỗi lần chỉnh sửa" cố định thời điểm đọc một cách đồng nhất.
Thông báo cho mô hình về sự tồn tại của một tài liệu không giống với việc bắt nó đọc mọi thứ mỗi lần.
Ngoài ra, "Cấm truy cập vào môi trường sản xuất" và "Xác nhận ngay cả trước khi chạy thử nghiệm cục bộ" ngăn chặn các hành động khác nhau.
Chỉ vì bạn muốn duy trì điều trước không có nghĩa là điều sau luôn cần thiết. Tuy nhiên, nếu không rõ liệu một thứ gì đó có thực sự ở cục bộ hay không, bạn cũng không nên bỏ qua xác nhận đó.
Các Skills, AGENTS.md và các yêu cầu hàng ngày được đề cập trong văn bản gốc đều liên quan đến những phán đoán này. Ngay cả khi bạn sửa một câu trong chat, nếu hạn chế tương tự vẫn tồn tại ở nơi khác, thì việc kiểm toán chưa hoàn tất.
Ví dụ, điều gì sẽ xảy ra nếu bạn viết "Hoàn thành nó cho đến khi nó hoạt động" trong một yêu cầu, nhưng quy trình được áp dụng vẫn nói "Luôn dừng lại ở lần triển khai đầu tiên và yêu cầu xem xét"?
Đây là một ví dụ để giải thích các hướng dẫn xung đột. Ít nhất, nếu không sắp xếp cái nào người dùng muốn, điểm kết thúc của yêu cầu sẽ không được căn chỉnh.
Khi xem xét, đừng đánh giá dựa trên "nó dài, vì vậy hãy cắt nó." Hãy xem câu đó truyền đạt kiến thức cần thiết, xác định phạm vi công việc, hay chỉ đơn giản là làm cho mô hình lặp lại các quy trình trước đó.
Ngay cả khi văn bản ngắn, nếu mục tiêu của "xác nhận mọi thứ" còn mơ hồ, thì đó không hẳn là một hướng dẫn tốt. Đôi khi, ngay cả khi nó hơi dài hơn, tốt hơn là truyền đạt ý định bằng cách làm rõ các điều kiện đọc hoặc điểm dừng.
2. Các Hướng Dẫn Cần Giảm Bớt: Tải Lặp Đi Lặp Lại và Các Bước Quá Chi Tiết
Điều đầu tiên cần kiểm toán là các quy tắc tải kích hoạt bất kể nội dung công việc.
Eric giải thích rằng việc bắt mô hình đọc một lượng lớn tài liệu hoặc toàn bộ hướng dẫn kho lưu trữ cho một sửa lỗi đánh máy đơn giản là quá mức cần thiết.
Đọc tài liệu sẽ đưa nội dung đó vào thông tin làm việc của mô hình. Văn bản gốc chỉ ra vấn đề tiêu thụ ngữ cảnh có sẵn và làm chậm công việc bằng cách tải các giải thích không liên quan.
Ngữ cảnh ở đây đề cập đến gói thông tin mà mô hình tham khảo cho tác vụ đó. Nếu nó tiếp tục tăng lên, nó sẽ tiến gần đến điểm mà lịch sử hội thoại và công việc phải được nén lại.
Do đó, thay vì chỉ giảm số lượng tham chiếu, hãy phân biệt những gì cần đọc cho yêu cầu hiện tại.
Ví dụ A: Bản dịch tiếng Nhật của Hình ảnh Tham khảo
Trước khi sửa đổi
Luôn đọc toàn bộ architecture.md, database.md và deployment.md trước khi chỉnh sửa.
Sau khi sửa đổi
Tham khảo architecture.md khi xử lý ranh giới giữa các dịch vụ, database.md khi thay đổi cấu trúc DB và deployment.md khi chuẩn bị triển khai.
Những gì được giữ lại là các hướng dẫn đến ba tài liệu. Những gì đã thay đổi là các điều kiện để mở chúng.
Trong ví dụ này, architecture.md dành cho vai trò và kết nối giữa các dịch vụ. database.md dành cho cấu trúc của cơ sở dữ liệu. deployment.md dành cho việc phản ánh những gì đã tạo vào môi trường thực thi.
Trong phiên bản "Trước", quy tắc "đọc tất cả" áp dụng ngay cả cho một yêu cầu sửa một lỗi đánh máy duy nhất. Trong phiên bản "Sau", nếu nhiệm vụ là thay đổi cấu trúc DB, nó sẽ tiến hành đến database.md tương ứng.
Điều này không có nghĩa là việc đọc các tài liệu khác bị cấm. Nếu một tác vụ trải dài trên nhiều lĩnh vực, các tài liệu cần thiết không chỉ giới hạn ở một.
Việc tạo ra một quy tắc đồng nhất khác như "chỉ chọn một tài liệu" từ ví dụ này sẽ đi chệch khỏi ý định ban đầu.
Chúng tôi đã không xóa các tài liệu cần thiết hoặc làm mỏng nội dung. Chúng tôi đã viết lại điều kiện yêu cầu kiểm tra tất cả tài liệu cho dù thay đổi nhỏ để phù hợp với nội dung công việc.
Eric cũng đề cập đến việc giữ cho các tài liệu được cập nhật. Ngay cả khi bạn tổ chức các điều kiện tham chiếu, cần có một kiểm tra riêng để đảm bảo không có giải thích cũ nào còn sót lại ở điểm đến.
Ví dụ B: Ví dụ Ứng dụng Dựa trên Văn bản Gốc
Tiếp theo là một ví dụ được áp dụng cho một kịch bản nơi Codex được giao nhiệm vụ viết bài, tạo video hoặc bài đăng trên mạng xã hội. Đây không phải là một quy trình sản xuất do chính Eric đăng tải.
Trước khi sửa đổi
Để tạo nội dung, hãy đọc tất cả các quy trình cho bài viết, video và bài đăng trên mạng xã hội.
Sau khi sửa đổi
Tham khảo writing.md để viết bài, video.md để sản xuất video và social.md để tạo bài đăng trên mạng xã hội. Đối với các yêu cầu đa định dạng, hãy tham khảo các quy trình liên quan.
Một lần nữa, các quy trình cụ thể cho bài viết, video và mạng xã hội được giữ lại. Điều đã thay đổi là phần bắt mô hình đọc tất cả các quy trình dưới cái ô rộng "tạo nội dung."
Nếu bạn yêu cầu một bài viết, nó sẽ tiến hành theo hướng dẫn bài viết. Nếu bạn yêu cầu một bài viết và bài đăng thông báo của nó cùng nhau, nó sẽ tiến hành theo cả quy trình bài viết và mạng xã hội.
Nếu không có yêu cầu về video, nó sẽ không còn yêu cầu tải toàn bộ quy trình sản xuất video tại điểm vào chung nữa.
Văn bản gốc gọi cách tiếp cận cung cấp các giải thích cần thiết theo từng giai đoạn này là "progressive disclosure." Đó là một phương pháp đặt các giải thích tại điểm vào để đánh giá điểm đến, đồng thời tách biệt kiến thức chi tiết và quy trình vào các tài liệu tiếp theo.
Ví dụ, nếu bạn xếp tất cả các quy trình đầy đủ cho bài viết, video và mạng xã hội tại điểm vào, mọi yêu cầu sẽ dẫn đến việc đọc một lượng giải thích khổng lồ.
Thay vào đó, hãy giới hạn vai trò của điểm vào chỉ là hướng dẫn: "Nếu là bài viết, hãy đến tài liệu này; nếu là video, hãy đến tài liệu kia." Bạn giữ các giải thích chi tiết mà không loại bỏ chúng, cho phép chúng được đọc khi cần.
Eric giải thích rằng đối với Skills có nhiều quy trình làm việc, tài liệu ban đầu nên là một hướng dẫn tối thiểu. Nó nên cung cấp vừa đủ thông tin để tiến hành đến các tài liệu hoặc tập lệnh liên quan thực hiện tác vụ.
Tạo ra một trạng thái mà chỉ cần nhìn vào điểm vào là biết được nên tiến hành đến tài liệu nào. Việc tóm tắt đơn giản các giải thích dài thành các giải thích ngắn sẽ không hoàn thành việc tổ chức các tham chiếu này.
Nếu bạn bỏ qua các biện pháp phòng ngừa cần thiết trong bản tóm tắt, nó sẽ trở thành một vấn đề khác. Những gì được giữ lại trong ví dụ ứng dụng ở trên là các quy trình riêng cho từng định dạng.
Việc Kiểm Tra Cũng Được Đặt Ở Chế Độ "Luôn Luôn, Bất Kể Điều Gì"?
Văn bản gốc nói rằng các mô hình trước đây cần được nhắc nhở để kiểm tra và xác nhận công việc. Mặt khác, Astra tự làm điều này, vì vậy các hướng dẫn tương tự có thể dẫn đến việc kiểm tra dư thừa không cần thiết.
Đừng hiểu sai điều này là "Astra không cần kiểm tra." Vấn đề không phải là ngừng kiểm tra, mà là liệu các hướng dẫn có gây ra các kiểm tra dư thừa hay không.
Nếu áp dụng điều này vào cài đặt của riêng bạn, hãy xem xét kiểm tra nào bạn đang yêu cầu cho thay đổi nào. Nội dung của các cuộc kiểm tra cần thiết và các điều kiện lặp lại chúng một cách đồng nhất mỗi khi bạn làm điều gì đó có thể được kiểm toán riêng biệt.
Vì bài viết này không so sánh số lượng kiểm tra hoặc thời gian xử lý, nó không cho thấy hiệu ứng như "viết lại sẽ tiết kiệm X phút." Mục tiêu của việc kiểm toán là liệu bạn có thể phân biệt giữa các cuộc kiểm tra cần thiết và các lần lặp lại dư thừa hay không.
3. Thu Hẹp Hướng Dẫn: Khi Nào Nên Sử Dụng Skill Này?
Thêm nhiều Skills hơn không nhất thiết làm cho chúng dễ chọn hơn. Eric thu hút sự chú ý đến thực tế là tải xuống và thêm một lượng lớn Skills.
Theo văn bản gốc, tên và mô tả của mỗi Skill được tải vào ngữ cảnh để mô hình đánh giá khi nào sử dụng chúng.
Ở đây, hãy phân biệt giữa việc tải tên/mô tả và tải nội dung Skill. Điều này không có nghĩa là mô hình đọc toàn bộ nội dung của mọi Skill ngay từ đầu.
Mô hình trước tiên sử dụng tên và mô tả làm manh mối để đánh giá cái nào sẽ sử dụng lần này. Nếu những mô tả đó quá dài hoặc có quá nhiều Skills, văn bản gốc nói rằng Codex sẽ rút ngắn các mô tả để phù hợp.
Kết quả là, mô hình có thể chỉ thấy một phần mô tả của mỗi Skill, khiến việc chọn lựa trở nên khó khăn hơn. Ngay cả khi các quy trình cần thiết được lưu lại, giải thích tại điểm vào có thể không được truyền tải đầy đủ.
Hơn nữa, Eric đề cập đến những mâu thuẫn giữa các mô tả hoặc các mô tả cố gắng làm cho chúng được sử dụng cho mọi thứ. Những điều này có thể gây ra việc tải các hướng dẫn không hữu ích cho tác vụ.
Vì vậy, không phải là nhồi nhét các mô tả với các thuật ngữ kỹ thuật để làm cho phạm vi bao phủ có vẻ rộng. Hãy làm cho mô tả sao cho mô hình biết liệu nó có nên được gọi cho công việc hiện tại hay không.
Bản dịch tiếng Nhật của Hình ảnh Tham khảo
Trước khi sửa đổi
Tạo và xác minh các di chuyển lược đồ PostgreSQL. Sử dụng cho công việc liên quan đến cơ sở dữ liệu, truy vấn, mô hình và tính bền vững.
Sau khi sửa đổi
Tạo và xác minh các di chuyển lược đồ PostgreSQL. Sử dụng để thêm/thay đổi di chuyển hoặc xem xét các quy trình ứng dụng.
PostgreSQL là một loại cơ sở dữ liệu. "Schema migration" đề cập đến nhiệm vụ thay đổi cấu trúc của các bảng và mục đóng vai trò là vùng chứa dữ liệu và áp dụng các thay đổi đó.
Ví dụ, đó là một kịch bản nơi bạn thay đổi cấu trúc cơ sở dữ liệu để tăng các mục cần lưu. Ở đây, nó được trích dẫn như một ví dụ về giải thích ý nghĩa của các thuật ngữ.
Mặt khác, "truy vấn" trong mô tả "Trước" là các yêu cầu để truy xuất hoặc thao tác dữ liệu. "Tính bền vững" đề cập đến việc lưu dữ liệu để có thể sử dụng sau này.
Đây là những thuật ngữ liên quan đến DB, nhưng không phải tất cả công việc liên quan đến DB đều cấu thành một nhiệm vụ di chuyển thay đổi cấu trúc.
Câu đầu tiên của phiên bản "Trước" cho thấy một nhiệm vụ chuyên biệt: "Tạo và xác minh các di chuyển." Tuy nhiên, câu thứ hai bao gồm công việc rộng liên quan đến cơ sở dữ liệu trong các điều kiện sử dụng.
Sự khác biệt về phạm vi này là những gì đang được sửa trong hình ảnh tham khảo. Lĩnh vực chuyên môn của Skill và các điều kiện gọi không khớp nhau.
Sau khi sửa đổi, vai trò "Tạo và xác minh các di chuyển lược đồ PostgreSQL" vẫn được giữ nguyên. Trên hết, nó được thu hẹp lại cho các trường hợp thêm di chuyển, thay đổi di chuyển hoặc xem xét các quy trình ứng dụng.
Ví dụ, nếu bạn chỉ muốn kiểm tra một truy vấn để truy xuất dữ liệu hiện có, bạn không nhất thiết phải gọi Skill di chuyển này chỉ vì nó "liên quan đến cơ sở dữ liệu."
Ngược lại, nếu đó là một đánh giá về cách áp dụng các thay đổi cấu trúc, nó vẫn là mục tiêu trong mô tả "Sau." Việc thu hẹp nó không làm mất đi công việc chuyên môn.
Điểm xác nhận khi sửa mô tả không chỉ là "Skill này có kiến thức về cái gì?" Mà là liệu người ta có thể đọc được "nó sẽ được sử dụng cho yêu cầu nào và nó sẽ không được mở rộng cho những yêu cầu nào?"
Nếu bạn chỉ viết "Skill DB" để làm cho nó ngắn hơn, các điều kiện gọi sẽ biến mất. Những gì văn bản gốc yêu cầu là làm cho mô tả ngắn nhất có thể trong khi vẫn giữ cho các kịch bản sử dụng rõ ràng.
Bạn có thể sử dụng "Trước/Sau" ở trên để kiểm tra xem công việc được yêu cầu và các điều kiện ứng dụng có khớp nhau hay không, thay vì dựa vào sức mạnh của tên hoặc độ dài của mô tả.
4. Làm Rõ Hướng Dẫn: Tiến Xa Đến Đâu và Điều Gì Xác Định Sự Hoàn Thành
Từ đây, chúng ta nói về việc thêm các giải thích cần thiết. Chỉ giảm tải và quy trình sẽ không xử lý được vấn đề dừng lại giữa chừng.
Eric nói rằng mặc dù Astra làm việc siêng năng, nhưng đôi khi nó có thể thận trọng về mức độ tiến triển. Làm thế nào để truyền đạt phạm vi bạn muốn nó tiếp tục cũng là một mục tiêu cho việc xem xét được đề cập trong văn bản gốc.
Đặc biệt, nếu bạn đã viết "Luôn xác nhận trước" một cách mạnh mẽ vì một mô hình trước đó đã di chuyển mà không được phép, hãy kiểm toán ranh giới đó.
Những gì văn bản gốc chỉ ra là khả năng dừng lại ở một nơi mà thực ra có thể tiếp tục, chỉ để tuân thủ nghiêm ngặt ranh giới. Điều này không phải là bảo nó bỏ qua các hướng dẫn xác nhận, mà là viết lại những gì bạn đang cho phép.
A: Làm Rõ Phạm Vi Phê Duyệt
Văn bản gốc có một ví dụ về một bài kiểm tra cục bộ sử dụng dữ liệu thử nghiệm dùng một lần và không truy cập vào môi trường sản xuất. Đây là một ví dụ về việc cho phép tác vụ cụ thể đó trong môi trường làm việc của riêng bạn.
"Trước" sau đây là một ví dụ ứng dụng được tạo ra để đối chiếu. "Sau" chứa bản dịch tiếng Nhật của các hướng dẫn kiểm tra cục bộ từ văn bản gốc.
Trước khi sửa đổi: Ví dụ Ứng dụng để Đối chiếu
Yêu cầu phê duyệt mỗi lần trước khi chạy thử nghiệm và trước khi sửa lỗi.
Sau khi sửa đổi: Bản dịch của Ví dụ Gốc
Các bài kiểm tra cục bộ sử dụng dữ liệu thử nghiệm dùng một lần và không truy cập vào môi trường sản xuất. Vui lòng tiến hành mà không cần xin phê duyệt ở mỗi giai đoạn cho đến khi chạy thử nghiệm, sửa lỗi do các thay đổi được yêu cầu gây ra và chạy lại các thử nghiệm bị ảnh hưởng.
Những gì được giữ lại là môi trường mục tiêu và phạm vi công việc. Những gì đã thay đổi là điều kiện để tìm kiếm phê duyệt mỗi lần trong phạm vi đó.
"Dữ liệu thử nghiệm dùng một lần" và "không truy cập vào môi trường sản xuất" không phải là lời mở đầu trang trí. Chúng là tiền đề để đánh giá liệu hướng dẫn này có thể được sử dụng hay không.
Nếu nó thực sự là một bài kiểm tra kết nối với môi trường sản xuất, việc viết "không truy cập vào môi trường sản xuất" sẽ không thay đổi môi trường. Đôi khi nó được gọi là "cục bộ" nhưng không rõ liệu nó có đáp ứng các điều kiện đó hay không. Đừng để lại các điều kiện không thể xác nhận như hiện tại.
Ngoài ra, việc sửa chữa được phép là cho "các lỗi do các thay đổi được yêu cầu gây ra." Nó không phải là một hướng dẫn được mở rộng để cho phép sửa tất cả các vấn đề tìm thấy trong bài kiểm tra.
Mục tiêu của việc thực thi lại cũng được viết là "các thử nghiệm bị ảnh hưởng." Nó khác với một đặc tả đồng nhất để lặp lại tất cả các thử nghiệm mỗi lần.
Câu này chỉ định các hành động có thể tiến hành, nhưng nó không loại bỏ phê duyệt cho các tác vụ khác. Nó cho thấy mức độ ủy thác một gói các tác vụ đã được xác nhận là an toàn.
Bạn không cần phải đi xa đến mức "cho phép mọi thứ vì dừng lại mỗi lần thật phiền phức." Nếu bạn tách biệt các tác vụ bạn không muốn nó dừng lại khỏi các tác vụ bạn vẫn muốn nhận lại phán đoán, ý nghĩa của yêu cầu sẽ thay đổi.
B: Làm Rõ Điều Kiện Hoàn Thành
Eric giải thích rằng nếu bạn đã quen với GPT-5.6 Sol, mô hình làm việc trong một thời gian dài, thì cách Astra dừng lại có thể có vẻ thận trọng.
Ở giai đoạn triển khai ban đầu đã xong, ngay cả khi công việc vẫn còn, nó có thể quay lại để yêu cầu xem xét. Do đó, ông khuyến nghị quyết định các điều kiện hoàn thành trước khi bắt đầu.
Điều cần thiết chỉ là triển khai, hay là chạy nó để xác nhận? Hơn nữa, có phải là sửa các lỗi được tìm thấy trong quá trình xác nhận không?
Người đưa ra yêu cầu tổ chức những khác biệt đó trước tiên. Một vạch đích khó truyền đạt chỉ với "hoàn thành nó" được viết thành một nhiệm vụ.
Sau đây là một ví dụ ứng dụng nơi giải thích gốc được thay thế bằng việc tạo một biểu mẫu yêu cầu. Nó không phải là văn bản yêu cầu thực tế của Eric hoặc kết quả xác minh hành vi thực tế.
Trước khi sửa đổi
Tạo một biểu mẫu yêu cầu. Hãy để tôi kiểm tra sau khi nó được triển khai.
Sau khi sửa đổi
Tạo một biểu mẫu yêu cầu. Lần này, hãy xác nhận cục bộ rằng nó có thể phát hiện các trường bắt buộc trống và địa chỉ email không hợp lệ, và màn hình hoàn thành xuất hiện sau khi gửi thử nghiệm. Sửa bất kỳ lỗi nào do thay đổi này gây ra và báo cáo chúng cùng với kết quả xác nhận. Không xuất bản lên môi trường sản xuất hoặc gửi email thực tế.
Những gì được giữ lại là mục đích tạo biểu mẫu yêu cầu và báo cáo kết quả cho con người. Những gì đã thay đổi là mức độ xác minh trước khi báo cáo.
Trong phiên bản "Trước", yêu cầu là "Hãy để tôi kiểm tra sau khi nó được triển khai." Ngay cả khi nó dừng lại ở điểm triển khai ban đầu, nó đã không đi chệch khỏi hướng dẫn.
Nếu bạn muốn xem thiết kế ở giữa chừng, cách dừng đó có ý nghĩa. Nếu đó là điểm dừng để xác nhận các phần bạn chưa quyết định, đó là một hướng dẫn có lý do để tồn tại.
Mặt khác, nếu những gì bạn muốn lần này là một biểu mẫu đã hoàn thành các kiểm tra hoạt động, hãy bao gồm các kiểm tra đó trong yêu cầu. Ví dụ liệt kê các trường trống, email không hợp lệ và màn hình hiển thị sau khi gửi thử nghiệm.
So với chỉ "kiểm tra xem nó có hoạt động tốt không," các trạng thái cần thử là cụ thể. Nếu các lỗi do thay đổi này gây ra được tìm thấy trong quá trình xác nhận, mục tiêu được đặt thành báo cáo sau khi sửa chúng.
Đồng thời, việc xuất bản lên môi trường sản xuất và gửi email thực tế bị loại trừ. Điều này là để tránh nhầm lẫn việc xác minh gửi thử nghiệm màn hình với việc gửi email đến các đích thực tế.
Yêu cầu này không coi chức năng gửi email thực tế đã được xác minh. Hãy yêu cầu nó báo cáo mức độ đã được xác nhận cục bộ như một kết quả.
Theo văn bản gốc, nếu bạn muốn tiến hành vượt quá lần triển khai đầu tiên, hãy truyền đạt những gì cần điều tra và điểm dừng.
Thay vì chỉ tăng cường nó bằng "đừng dừng lại giữa chừng," hãy liệt kê các xác nhận cần thiết và các thao tác không được tiến hành. Bằng cách này, bạn có thể xem xét ngay cả những nơi nó quay lại với con người.
5. Kiểm Toán Cài Đặt Của Riêng Bạn
Ở cuối văn bản gốc, Eric gợi ý yêu cầu Astra thực hiện kiểm toán dựa trên bài viết này. Kiểm toán có nghĩa là đọc các hướng dẫn hiện có và kiểm tra các điểm trùng lặp, khác biệt và các lĩnh vực có thể xem xét.
Bạn cũng có thể mở AGENTS.md hoặc Skills của riêng mình và xem xét các câu bạn tò mò. Tuy nhiên, nếu bạn muốn tổ chức xem bạn đã viết hướng dẫn ở đâu và như thế nào, bạn có thể để nó cho một cuộc kiểm toán trước khi thực hiện thay đổi.
Cách tiếp cận chỉ thực hiện kiểm toán trước mà không thay đổi tệp là một đề xuất của bài viết này. Nó không phải là một thủ tục bắt buộc do Eric chỉ định.
Trong trường hợp đó, đừng yêu cầu "xóa tất cả các hướng dẫn không cần thiết" ngay từ đầu. Điều bạn muốn trước tiên là tài liệu cho phép bạn so sánh các hướng dẫn gốc với đề xuất về cách thay đổi chúng.
Một lưu ý nữa từ văn bản gốc: Skills và hướng dẫn được đặt trong một kho lưu trữ có thể được sử dụng bởi AI của những người làm việc khác.
Những AI đó có thể không sử dụng cùng một Astra. Eric chỉ ra rằng các giải thích hữu ích cho Sol hoặc Luna có thể thêm quá nhiều ràng buộc cho Astra.
Ngay cả khi nó trông quá chi tiết đối với bạn khi sử dụng Astra, nó có thể cần thiết cho các mô hình khác. Nếu bạn đang thay đổi các quy tắc dùng chung, ai sử dụng mô hình nào cũng là một yếu tố trong phán đoán.
Nếu tình trạng sử dụng không rõ ràng, đừng xóa với giả định "chỉ Astra được sử dụng." Chỉ cần xác nhận các ứng cử viên sửa chữa trong khi vẫn để nguyên các điểm chưa rõ ràng.
Prompt kiểm toán sau đây được tạo cho độc giả dựa trên bài viết này. Nó không phải là prompt do Eric đăng trong văn bản gốc.
Sử dụng nó trong dự án mục tiêu và chia sẻ văn bản bài viết cũng như văn bản yêu cầu bạn muốn kiểm toán. Nếu phạm vi có thể đọc bị giới hạn, hãy chấp nhận nó như một kết quả kiểm tra trong phạm vi đó.
Vui lòng kiểm tra các hướng dẫn hiện tại dựa trên bài viết của Eric Provencher. Lần này chỉ thực hiện kiểm tra; không tạo, chỉnh sửa hoặc xóa tệp, hoặc thay đổi cài đặt.
Các mục tiêu là AGENTS.md được áp dụng cho dự án này, tên và mô tả của các Skills có sẵn và nội dung cần thiết cho việc kiểm tra, cùng với văn bản yêu cầu hàng ngày tôi đã chia sẻ. Vui lòng liệt kê các mục tiêu bạn có thể đọc được.
Kiểm tra các vấn đề sau: ・Hướng dẫn trùng lặp ở nhiều vị trí ・Hướng dẫn không thể thực hiện đồng thời hoặc có điểm cuối xung đột ・Các quy tắc đồng nhất quá mức yêu cầu tải hoặc xác nhận mỗi lần bất kể nội dung công việc ・Điều kiện áp dụng rộng hơn vai trò thực tế của Skill ・Hướng dẫn không rõ ràng về mức độ cần tiến hành hoặc điều gì xác định việc hoàn thành
Đối với các vị trí tìm thấy, hãy phân loại chúng thành các ứng cử viên cho "Xóa," "Rút gọn," "Thay đổi Điều kiện Áp dụng," hoặc "Giữ nguyên," và đưa ra lý do. Đừng biến việc giảm số lượng ký tự thành mục tiêu; cũng liệt kê các hướng dẫn cần được giữ lại.
Đối với mỗi ứng cử viên, hãy cung cấp: 1. Tên tệp/vị trí hoặc phần liên quan của văn bản yêu cầu đã chia sẻ 2. Hướng dẫn hiện tại 3. Vấn đề giả định và cơ sở đánh giá 4. Đề xuất sửa đổi. Nếu giữ nguyên, hãy nêu lý do 5. Những gì cần giữ và những gì cần thay đổi 6. Các điều kiện con người nên kiểm tra trước khi thay đổi
Không xóa hàng loạt các ràng buộc dành riêng cho dự án, kiến thức chuyên môn, các bài kiểm tra cần thiết hoặc các phê duyệt cần thiết. Chỉ đề xuất cho phép các bài kiểm tra hoặc sửa chữa cục bộ tiếp tục trong phạm vi có thể xác nhận các điều kiện môi trường, chẳng hạn như dữ liệu mục tiêu và việc không có quyền truy cập production.
Kiểm tra xem các mô hình khác như Sol hoặc Luna có sử dụng cùng hướng dẫn không. Nếu không biết, hãy viết "Không rõ" và không cho rằng đó là quy tắc chỉ dành cho Astra.
Nêu rõ các tệp không thể đọc, các điều kiện môi trường không thể xác nhận và thông tin còn thiếu để đánh giá. Phân biệt giữa các vấn đề được giải thích trong tài liệu, các vấn đề thực tế tìm thấy trong cài đặt và các ứng cử viên cải tiến chưa được xác minh; không viết các tác động cải tiến như đã được đo lường.
Cuối cùng, tóm tắt các ứng cử viên sửa chữa cần được ưu tiên xem xét, cùng với lý do. Việc thực hiện các thay đổi sẽ được yêu cầu riêng sau khi tôi xác nhận các mục tiêu và nội dung.
Những gì bạn nhận được với yêu cầu này không phải là các cài đặt đã sửa đổi, mà là một danh sách nơi các hướng dẫn hiện tại và các đề xuất sửa đổi tương ứng. Ngay cả khi nó được viết là "Ứng cử viên xóa," điều đó không có nghĩa là nó chắc chắn không cần thiết.
Việc phân loại các ứng cử viên được đưa ra để các đề xuất thay đổi điều kiện đọc không bị gộp chung vào "Xóa." Trong trường hợp ví dụ tham khảo tài liệu trong bài viết này, tài liệu vẫn được giữ lại, vì vậy trọng tâm là thay đổi các điều kiện áp dụng.
Đối với mô tả Skill, vai trò chuyên môn vẫn được giữ lại, nhưng phạm vi gọi bị thu hẹp. Trong trường hợp này, nếu một đề xuất xóa chính kiến thức chuyên môn đó được đưa ra, bạn có thể kiểm tra xem những gì được giữ lại trước và sau khi sửa đổi có khác nhau không.
Các ứng cử viên "Rút gọn" là để xem liệu các điều kiện và ràng buộc tương tự có thể được truyền đạt bằng các câu ngắn hơn hay không. Các ứng cử viên "Giữ nguyên" yêu cầu lý do tại sao cần phải giữ chúng.
Hãy xem xét phạm vi kiểm tra cùng với kết quả. Việc chỉ có thể đọc tên và mô tả Skill, hay có thể đọc được các quy trình thực tế, cũng là tài liệu để đánh giá kết quả.
Việc một mô tả có quá rộng hay không có thể được kiểm tra với điều kiện trước, nhưng liệu có sự trùng lặp trong các quy trình hay liệu kiến thức cần thiết có bị cắt bỏ hay không thì không thể xác nhận trừ khi đọc được nội dung.
Nếu bạn chưa chia sẻ văn bản yêu cầu hàng ngày, sự khác biệt với các điều kiện dừng ở đó cũng chưa được xác nhận. Việc đọc một phần cài đặt không cấu thành một cuộc kiểm tra hoàn chỉnh toàn bộ môi trường làm việc.
Thứ tự cần xem xét là: hướng dẫn gốc, lý do biến nó thành ứng cử viên, các ràng buộc còn lại và các điều kiện chưa được xác nhận. Ví dụ: nếu không biết có quyền truy cập production hay không, thì tiền đề cho đề xuất bỏ qua phê duyệt không được đáp ứng.
Bạn cũng có thể kiểm tra xem kiến thức chuyên môn cần thiết có bị cắt bỏ hay không hoặc liệu các tác động đến các mô hình khác có được giả định hay không. Tiến hành trong khi tách biệt sự nghi ngờ tìm thấy trong quá trình kiểm tra khỏi phán đoán rằng việc thay đổi là ổn.
Đọc lại các hướng dẫn bạn đã tiếp tục thêm vào để phù hợp với công việc hiện tại của bạn. Bước đầu tiên không phải là xóa hàng loạt cài đặt, mà là cuộc kiểm tra này không thay đổi bất cứ điều gì.
