Trong bài viết trước, tôi đã chỉ cho bạn thấy tại sao xác minh lại là nền tảng của mọi thứ tôi làm với các agent, và cách bắt đầu tạo các kỹ năng xác minh của riêng bạn. Bài học chính là nếu một agent không thể tự xác minh công việc của nó, thì mọi thứ khác đều vô nghĩa. Bạn vẫn là nút thắt cổ chai, và cả ngày của bạn sẽ chỉ để trông chừng các agent.
https://x.com/poteto/status/2094457600259842065
Nhưng một khi bạn đã có xác minh hoạt động, câu hỏi tiếp theo là: làm thế nào để bạn thực sự tìm ra những gì cần xây dựng?
https://x.ai/bot/plugin/9717366
Trong bài viết này, tôi sẽ hướng dẫn bạn cách tôi thực hiện nghiên cứu, lập kế hoạch, tạo mẫu thử và kiến trúc với pstack. Đây chính xác là quy trình làm việc cho phép tôi đưa hàng nghìn PR vào sản xuất mỗi tháng trong khi vẫn duy trì chất lượng mã cực kỳ cao.
Kết thúc tháng 8 với 2.462 PR trong sản xuất
Nghệ thuật giám sát một người thông minh hơn bạn
Trở lại những ngày xưa cũ của năm 2024, để thực hiện bất kỳ thay đổi nào trong một hệ thống, trước tiên bạn cần đọc đủ về nó để xây dựng một mô hình tinh thần về những gì đang diễn ra. Tùy thuộc vào kích thước và độ phức tạp của mã nguồn, việc này có thể mất từ vài giờ, thậm chí đến vài ngày và vài tháng. Với một thay đổi nhỏ, bạn có thể chỉ cần hiểu cục bộ về một hệ thống con nhỏ. Tuy nhiên, nếu bạn đang tái cấu trúc phần lõi, bạn có thể sẽ cần có một mô hình tinh thần về cách toàn bộ hệ thống hoạt động để thực hiện việc tái cấu trúc một cách chính xác và hiệu quả.
Các agent rõ ràng đã loại bỏ rào cản này. Bạn có thể thực hiện các thay đổi đối với hệ thống rất dễ dàng chỉ bằng cách ra lệnh cho agent của mình và nó sẽ làm điều đó, bất kể bạn biết nhiều hay ít về mã. Nhưng việc duy trì chất lượng mã và trải nghiệm người dùng vẫn còn khó khăn, đặc biệt nếu bạn chưa phải là chuyên gia trong lĩnh vực đó, người biết cần tìm kiếm và hỏi những gì.
Mặc dù các mô hình tiên tiến đã trở nên rất có năng lực, vẫn có 2 chế độ thất bại mà tôi thường xuyên quan sát thấy:
- Chúng không thể hiểu đầy đủ ý định của bạn vì chúng bị chỉ định thiếu hoặc kém.
- Chúng không có đủ ngữ cảnh về cách thực hiện công việc một cách chính xác.
Cả hai vấn đề này đều có liên quan. Sử dụng agent tốt phụ thuộc vào khả năng bạn có thể nạp vào cửa sổ ngữ cảnh của agent với ngữ cảnh chất lượng cao tốt đến đâu. Bạn chắc chắn có thể viết mã hoạt động mà không cần làm điều này, nhưng tôi thấy rằng kết quả và chất lượng tốt hơn nhiều khi tôi đã làm việc để cung cấp cho các agent của mình mọi thứ chúng cần để thực hiện một công việc chất lượng cao.
Bằng chính lời của bạn
Các mô hình tiên tiến là những người viết mã rất có năng lực. Trong khi với các mô hình cũ hơn, tôi có thể đã ra lệnh rất cụ thể về những gì tôi muốn nó làm, gần như quản lý vi mô chúng, thì các mô hình mới nhất có thể viết mã tốt hơn bạn hoặc tôi. Vì vậy, có một sự cân bằng tinh tế mà tôi muốn đạt được khi nói với agent những gì tôi muốn nó đạt được, đồng thời cho nó quyền tự do giải quyết vấn đề theo những cách mà tôi có thể chưa nghĩ ra.
Đây là nghệ thuật giám sát một người thông minh hơn bạn, trên một mã nguồn mà bạn không tự viết, và nơi con người không còn có thể nắm giữ toàn bộ mô hình tinh thần của mã nguồn trong đầu họ.
Một kỹ thuật tôi thích sử dụng là lời nhắc gián tiếp. Thay vì nói với agent chính xác những gì tôi muốn, tôi cố gắng rút ra nó từ agent - bằng chính lời của nó.
Ví dụ, khi ai đó báo cáo một vấn đề trong Slack, tôi thường yêu cầu agent đọc luồng tin nhắn và diễn đạt lại vấn đề bằng chính lời của nó trước khi làm bất cứ điều gì khác.
Ví dụ, tôi có thể nói:
/poteto-mode đọc luồng slack này. diễn đạt lại bằng chính lời của bạn và bằng tiếng Anh đơn giản những gì bạn nghĩ là vấn đề cốt lõi
Điều này đạt được ba điều:
Đầu tiên, nó buộc agent phải nén một cuộc trò chuyện ồn ào thành một tuyên bố vấn đề có cấu trúc. Thứ hai, nó cho phép tôi phát hiện ngay những hiểu lầm. Nếu agent tập trung vào một manh mối sai trong luồng tin nhắn, tôi có thể sửa nó nhanh chóng trước khi nó bắt đầu viết bất kỳ mã nào.
Và thứ ba, tôi đã không vô tình dẫn nó đi sai đường bằng cách nêu ra các giả định và giả thuyết của riêng tôi, những điều có thể không chính xác hoặc hạn chế những gì agent có thể đạt được.
Xây dựng mô hình tinh thần
Yêu cầu agent diễn đạt lại theo cách bạn có thể hiểu là một phần quan trọng khi làm việc với một người thông minh hơn bạn. Đó là nguồn cảm hứng cho /teach, một kỹ năng giúp agent của bạn giải thích mọi thứ cho bạn một cách trực quan. Tôi sử dụng nó bất cứ khi nào tôi cần đảm bảo agent của mình đang làm điều gì đó có ý nghĩa với tôi.
Bên trong, /teach gọi đến /how và /why.
/how theo dõi cơ chế thời gian chạy. Khi bạn hỏi /how, agent đánh giá độ phức tạp của hệ thống con. Nếu hệ thống con trải dài trên nhiều thư mục hoặc dịch vụ, nó sẽ sinh ra các agent khám phá song song trên các mô hình nhanh, hiệu quả như Grok.
/how ảo hóa được triển khai như thế nào?
/why điều tra động lực và ý định. Mã cho bạn biết điều gì xảy ra. Nó hiếm khi cho bạn biết tại sao ai đó lại viết nó theo cách đó. Khi bạn chạy /why, pstack truy vấn bằng chứng lịch sử trên nhiều nguồn cùng một lúc: lịch sử Git và nhận xét đánh giá PR, ticket Linear, tài liệu thiết kế Notion, cuộc trò chuyện Slack, trình giám sát Datadog, lỗi Sentry, dòng dõi mã và sự kiện kho phân tích.
/why tại sao chúng ta vẫn bị mắc kẹt với một phiên bản cũ của node.js?
Tôi sử dụng /teach bất cứ khi nào tôi muốn agent diễn đạt lại điều gì đó để tôi có thể hiểu rõ hơn và tin tưởng vào công việc của nó.
/teach tôi tại sao bạn triển khai nó theo cách này và không phải <cách khác>. những sự đánh đổi bạn đã thực hiện là gì và tại sao?
Trong thực tế, tôi cũng nhận thấy rằng nghiên cứu được thực hiện bởi kỹ năng /teach không chỉ hữu ích cho con người, mà còn cho cả các agent. Ngay cả với các mô hình tiên tiến nhất, (điều này cũng phụ thuộc vào chất lượng của harness), nhìn chung tôi thấy rằng chúng vẫn thường khẳng định mọi thứ một cách tự tin mà không có dữ liệu hỗ trợ hoặc thực sự đọc mã cần thiết để xây dựng mô hình tinh thần về cách nó hoạt động. Vì vậy, hành động dạy bạn những gì nó sẽ làm và tại sao cuối cùng cũng giúp ích cho chính agent.
Học hỏi từ lịch sử
Nhiều dự án của tôi trải dài trên nhiều cuộc trò chuyện. Ví dụ, vài tháng trước, tôi đang làm việc để sửa lỗi ảo hóa và các vấn đề về hiệu suất mà mọi người đang báo cáo trong Cursor. Tôi nhận ra rằng mỗi khi tôi bắt đầu một cuộc trò chuyện mới, tôi phải bắt đầu lại từ đầu với việc xây dựng ngữ cảnh phong phú mà agent của tôi đã có trước đó khi nó đang giải quyết một vấn đề tương tự.
Điều tôi nhận ra là các bản ghi cuộc trò chuyện trong quá khứ của bạn thường là một mỏ vàng cho ngữ cảnh phong phú. pstack đi kèm với kỹ năng /recall để kéo ngữ cảnh gần đây của bạn từ lịch sử trò chuyện, vì vậy ngay cả các agent mới cũng có ngữ cảnh phù hợp cần thiết để quay trở lại trạng thái tốt.
/recall công việc tôi đã làm hôm qua về ảo hóa và sau đó đọc báo cáo lỗi này trên slack
Sử dụng /teach, /recall, /how và /why là cách tôi giữ cho các mô hình tinh thần của riêng mình về mã nguồn được cập nhật, nén thành một dạng mà tôi có thể dễ dàng hiểu và ghi nhớ. Và, nó cũng giúp ích cho các agent!
Làm việc ngược
Một khi bạn hiểu vấn đề, làm thế nào để bạn xác định giải pháp?
Theo quan điểm của tôi, hầu hết các harness có chế độ lập kế hoạch có xu hướng xác định quá chi tiết về triển khai và xác định quá ít mọi thứ khác. Đó là lý do tại sao trong pstack, tôi đã nói một cách ranh mãnh rằng "tôi không tin vào việc lập kế hoạch". Sự thật là tôi có lập kế hoạch, nhưng tôi làm điều đó thông qua mã.
Đối với một số loại công việc nhất định, như tạo mã hoặc gói chia sẻ mà người khác sẽ sử dụng, tôi là một người tin tưởng lớn vào phát triển theo hướng readme. Nếu bạn chưa quen với nó, đó là một kỹ thuật phát triển đã phổ biến trước đây, nơi bạn bắt đầu bằng cách viết readme của mình trước. Điều này buộc bạn phải đội chiếc mũ trải nghiệm nhà phát triển, nơi bạn bắt đầu bằng cách mô tả các API cho một người dùng giả định, và làm việc ngược lại với việc triển khai và kiến trúc.
Ví dụ, khi tôi đang xây dựng Dune, framework ứng dụng khách nội bộ của chúng tôi cho các ứng dụng desktop, tôi bắt đầu bằng cách viết một hướng dẫn cho nó, để tôi có thể hiểu việc xây dựng một ứng dụng với nó sẽ như thế nào. Hoặc ít nhất tôi đã cố gắng. Đó thực sự là một cuộc đấu tranh để có được agent tạo ra bất cứ thứ gì tốt hoặc dễ đọc. Vì vậy, tôi đã phải dành thời gian để mài dao trước, bằng cách tạo ra kỹ năng /technical-writing.
Bản thảo đầu tiên của readme mà không có kỹ năng /technical-writing thật khó đọc vì nó pha trộn các mục tiêu khác nhau. Nó cố gắng trở thành một hướng dẫn, một hướng dẫn cách làm, một lời giải thích kiến trúc và một tài liệu tham khảo API, tất cả trong cùng một tài liệu, được viết với văn phong AI sến súa thông thường và văn xuôi kiểu cách.
/technical-writing sử dụng khung Diátaxis để phân chia tài liệu thành bốn chế độ riêng biệt:
- Hướng dẫn: Học bằng cách làm. Một bài học dẫn dắt người mới qua một loạt các bước để xây dựng một thứ gì đó hữu hình.
- Hướng dẫn cách làm: Các bước để giải quyết một vấn đề cụ thể, thực tế cho người dùng có kinh nghiệm.
- Tài liệu tham khảo: Mô tả kỹ thuật khô khan, đầy đủ, có thẩm quyền về máy móc, API và các cờ cấu hình.
- Giải thích: Thảo luận cấp cao làm rõ và soi sáng bối cảnh, các lựa chọn thiết kế và sự đánh đổi.
Nó cũng sử dụng /unslop, vì vậy nó tạo ra tài liệu rất dễ đọc.
Viết một kế hoạch theo cách này rất hữu ích vì nó cũng cung cấp cho các agent của bạn một mục tiêu và mục đích cụ thể mà nó có thể kiểm tra công việc của chính mình. Và tất nhiên, cũng dễ hiểu hơn nhiều về chính xác những gì agent sẽ xây dựng.
Nhiều kỹ năng của pstack kết hợp với nhau trong giai đoạn thiết kế này. Ví dụ:
(1) /recall công việc sửa lỗi ảo hóa và các vấn đề về hiệu suất của tôi trong 7 ngày qua. sử dụng /how và /why để hiểu cách triển khai ảo hóa hiện tại của chúng ta hoạt động.
(2) sau đó sử dụng /poteto-mode planning và /technical-writing để đưa ra một engine ảo hóa mới loại bỏ hoàn toàn hiện tượng nhấp nháy và giật. hãy bắt đầu bằng cách viết một hướng dẫn về cách tôi sẽ sử dụng gói mới này để ảo hóa một ứng dụng React
(3) sau khi bạn viết kế hoạch, /teach tôi và chứng minh cho tôi thấy tại sao cách tiếp cận mới này lại vượt trội hơn engine hiện tại của chúng ta
Kỹ thuật ở đây thực sự là về việc rút ra ngữ cảnh thú vị và phong phú, cho phép các agent của bạn nhìn thấy vấn đề theo cùng một cách như bạn - không chỉ là một lát cắt nhỏ:
- Phần đầu tiên của lời nhắc nhớ lại bối cảnh quá khứ và hiện tại có liên quan về cách ảo hóa được triển khai trong ứng dụng của tôi.
- Phần thứ hai hướng dẫn agent sử dụng ngữ cảnh đó, chẳng hạn như các lỗi nó đã sửa trước đây, để đưa ra một thiết kế mới loại bỏ hoàn toàn những vấn đề đó.
- Phần cuối cùng là yêu cầu agent của bạn chứng minh cho bạn thấy rằng gói mới này vượt trội hơn. Đây là nơi các công cụ chất lượng cao như kỹ năng xác minh rất quan trọng để có.
Đo trăm lần, cắt một lần
Khi lập kế hoạch, hai trong số những sai lầm phổ biến nhất tôi thấy là:
- Chấp nhận thiết kế đầu tiên của agent.
- Làm quá kế hoạch mà không có bằng chứng thực nghiệm.
Khi con người viết mã, chúng ta thường cộng tác với nhau qua các tài liệu thiết kế. Đây là những tài liệu nói về kiến trúc cấp cao, các phương án thay thế đã được xem xét, sự đánh đổi và bất kỳ ghi chú triển khai bất thường nào. Việc trải qua nhiều lần lặp lại các tài liệu này trước khi bạn đạt được một thiết kế ổn định là rất phổ biến.
Với các agent, mặc dù chúng ta có thể bỏ qua nghi thức của tài liệu thiết kế, tôi thường thấy sai lầm khi chấp nhận điều đầu tiên agent đưa lại cho bạn. Với pstack, chúng ta có thể đưa cách tiếp cận "đo hai lần, cắt một lần" đến giới hạn của nó, sử dụng các agent song song.
Chúng ta làm điều này bằng cách sử dụng playbook tạo mẫu thử.
Trong pstack, playbook không phải là kỹ năng, mà là các tệp tham chiếu bên trong /poteto-mode. Các playbook này được tải có điều kiện (để tiết kiệm token) tùy thuộc vào loại nhiệm vụ bạn đang thực hiện. 23 playbook này (tính đến phiên bản 0.15.0) mỗi cái chứa một quy trình làm việc mà tôi sử dụng khi thực hiện một nhiệm vụ.
Không giống như các kỹ năng, playbook được agent tự động sử dụng như một phần của /poteto-mode. Ví dụ:
/poteto-mode tạo mẫu thử một vài tùy chọn cho menu thả xuống mới /poteto-mode sửa lỗi này /poteto-mode đánh giá thay đổi kỹ năng này
Tạo mẫu thử là một trong những playbook pstack yêu thích của tôi. Nó cung cấp cho bạn nhiều lần thử cho một mục tiêu và giúp agent suy luận về lựa chọn tốt nhất. Điều này hữu ích không chỉ cho việc tạo mẫu thử trực quan, mà còn để tạo mẫu thử các giải pháp khác nhau cho các tính năng, sửa lỗi, v.v.
/poteto-mode tạo mẫu thử một vài tùy chọn cho <yêu cầu tính năng>. sử dụng /control-app* và chụp video/ảnh màn hình để tôi xem xét và chọn
\ lưu ý: /control-app là kỹ năng xác minh chúng ta đã tạo trong [Phần 1*](https://x.com/poteto/status/2094457600259842065
Khi tạo mẫu thử các thay đổi trực quan, agent xây dựng các bản phác thảo dùng một lần trong ứng dụng của bạn hoặc trong một thư mục tạm. Nếu nó đang kiểm tra một tương tác UI, nó đặt hai hoặc ba biến thể đằng sau một bộ chuyển đổi đơn giản. Sau đó, nó điều khiển tương tác với kỹ năng /control-app, chụp ảnh màn hình của từng biến thể và đo thời gian hoặc bố cục thực tế.
Tạo mẫu thử là lập kế hoạch, nhưng với mã. Nó cho phép các agent tự do khám phá không gian vấn đề và cho chúng cơ hội làm bạn ngạc nhiên với điều gì đó mà bạn sẽ không tự nghĩ ra. Các mẫu thử cho phép agent tự trả lời các câu hỏi của chúng bằng bằng chứng thực nghiệm thay vì chờ đợi ý kiến của tôi.
Kiến trúc các thay đổi lớn hơn
Với tư cách là một kỹ sư trong kỷ nguyên agent, việc dành thời gian cho kiến trúc, chọn cấu trúc dữ liệu phù hợp và suy nghĩ về cách các hệ thống tôi xây dựng sẽ hoạt động cùng nhau là quan trọng hơn. Các agent của tôi điền vào các chi tiết triển khai.
Một kỹ năng hữu ích khác mà pstack đi kèm là /architect. Nó cấu trúc thiết kế thành các giai đoạn riêng biệt, có kỷ luật:
- Xác định vấn đề. Agent chạy /how và /why trên các hệ thống bị ảnh hưởng để xây dựng một mô hình tinh thần chính xác về quyền sở hữu và các ràng buộc hiện có.
- Phác thảo. Agent bước vào một đấu trường kiến trúc. Nó sinh ra các trình chạy ứng viên độc lập song song, thường trên các họ mô hình khác nhau. Mỗi trình chạy nhận được bản tóm tắt xác định vấn đề và soạn thảo một gói thiết kế hoàn chỉnh: bản phác thảo cách sử dụng của người gọi, các định nghĩa kiểu cốt lõi, chữ ký hàm công khai và một lý do ngắn gọn. Những việc này thường được thực hiện bằng cách phác thảo chỉ các chữ ký kiểu, bắt nguồn từ cách chúng ta muốn các điểm gọi trông như thế nào. Mỗi trình chạy phải đánh giá độ sâu giao diện, kiểm tra các chế độ thất bại trên các mô hình yếu và sàng lọc theo danh mục các cờ đỏ thiết kế của chúng ta.
- Đánh giá chéo và Tổng hợp. Một agent đánh giá chéo sử dụng một mô hình khác với agent chính đánh giá các ứng viên theo một tiêu chí nghiêm ngặt.
- Triển khai theo bản phác thảo. Agent thay thế phần thân giữ chỗ của bản phác thảo bằng logic thực tế. Nếu agent phát hiện trong quá trình triển khai rằng một hàm cần các tham số không mong đợi hoặc trạng thái bổ sung, nó sẽ làm rõ sự khác biệt.
- Loại bỏ khi thiết kế sai. Nếu trong quá trình triển khai, chúng ta thấy rằng các bản phác thảo đã sai, agent sẽ vứt bỏ tất cả và bắt đầu lại.
Vấn đề ở đây là cung cấp cho agent một vòng lặp nhỏ khép kín, nơi nó có thể tổng hợp nhiều thiết kế cạnh tranh từ các họ mô hình khác nhau thành một cách tiếp cận tối ưu, và cẩn thận để nghiêm ngặt và không ngại vứt bỏ thiết kế của nó nếu hóa ra kiến trúc mà nó đưa ra là sai dựa trên bằng chứng thực nghiệm. Nếu cùng một giải pháp thay thế xuất hiện trên các điểm gọi không liên quan, hoặc nếu các kiểu yêu cầu các cửa thoát hiểm như 𝚊𝚗𝚢 hoặc ép kiểu cưỡng bức, đó là bằng chứng thực nghiệm cho thấy kiến trúc đã sai.
/architect <yêu cầu tính năng> mới này
Bài học lớn ở đây là việc lập kế hoạch với mã bằng cách sử dụng /poteto-mode prototyping và /architect hiệu quả hơn nhiều.
Đó cũng là lý do tại sao tôi không bao giờ bận tâm đến việc xem xét các kế hoạch trừu tượng một cách đối kháng. Các agent bắt đầu ảo tưởng về các rủi ro lý thuyết và phát minh ra các trường hợp cạnh phức tạp để bảo vệ chống lại các vấn đề sẽ không bao giờ xảy ra. Đừng làm quá kế hoạch của bạn khi chúng vẫn còn trừu tượng: hãy để agent tự trả lời các câu hỏi mở thông qua việc tạo mẫu thử và xác minh công việc của chính nó.
Được rồi nhưng tôi thực sự muốn một tài liệu kế hoạch
Mặc dù pstack không đi kèm với một kỹ năng lập kế hoạch, nó có đi kèm với một playbook lập kế hoạch nhiều giai đoạn. Tôi thường sử dụng nó sau khi agent đã đưa ra một thiết kế mà tôi hài lòng, như một cách để tạo ra một kế hoạch thực hiện chiến thuật.
/poteto-mode biến thiết kế này thành một kế hoạch
Mọi nhiệm vụ duy nhất trong kế hoạch đều được cấu trúc xoay quanh bằng chứng và xác minh. Playbook nói với các agent rằng chỉ riêng kiểm thử là không đủ để xác minh. Nó chỉ được xác minh khi nó đã thực sự chạy mã và xác minh rằng nó hoạt động.
Mọi kế hoạch đều được kiểm tra bởi một tập lệnh tự động xác thực cấu trúc và định dạng của nó. Sau khi được phê duyệt, kế hoạch thực hiện từng mục một. Mỗi PR đều nhỏ, khép kín và dễ dàng xem xét.
Đối với các dự án thực sự lớn (như một dự án có thể khiến tôi mất cả tuần), đôi khi tôi có thể quyết định tạm thời cam kết các kế hoạch vào mã nguồn để các agent khác biết về công việc đang tiến hành. Nhưng tôi thường xóa chúng khi hoàn thành để không để mã nguồn trong trạng thái hỗn loạn. Tôi không thấy việc giữ các kế hoạch vĩnh viễn là có giá trị.
Quy trình làm việc trong thực tế
Để xem tất cả những phần này kết hợp với nhau như thế nào, chúng ta hãy xem xét ba ví dụ cụ thể về cách tôi ra lệnh cho các quy trình làm việc này.
Ví dụ 1: Nghiên cứu một lỗi mơ hồ
Khi một vấn đề xuất hiện trong sản xuất và nguyên nhân gốc rễ không rõ ràng:
/poteto-mode điều tra tại sao các worker nền định kỳ thất bại với lỗi hết thời gian chờ. cho tôi bảng phân tích về những gì chúng ta biết, dữ liệu bạn đã sử dụng và các giả thuyết tốt nhất của bạn.
Agent khám phá mã, kiểm tra số liệu và các commit lịch sử song song, và cung cấp cho bạn những phỏng đoán có cơ sở tốt nhất về nơi vấn đề có thể nằm.
Ví dụ 2: Thiết kế một ranh giới dịch vụ mới
Khi giới thiệu một hệ thống con mới mà các mô-đun khác sẽ phụ thuộc vào:
/poteto-mode chúng ta cần thêm giới hạn tốc độ cho webhook bên ngoài. /architect cái này trước, và trả lời bất kỳ câu hỏi mở nào bằng các mẫu thử. để tôi xem xét trước khi tiếp tục.
Agent xác định kiến trúc webhook hiện có, khởi động các trình chạy thiết kế cạnh tranh trên nhiều mô hình, đo điểm chuẩn với các mẫu thử dùng một lần và tạo ra một giao diện sạch sẽ, đã được xác minh.
Ví dụ 3: Thực hiện di chuyển nhiều PR
Khi thực hiện một cuộc tái cấu trúc phức tạp trên nhiều tệp:
/poteto-mode tạo một kế hoạch để di chuyển toàn bộ thư viện UI của chúng ta sang StyleX. chia nhỏ việc di chuyển thành các PR nhỏ, có thể xác minh. mỗi PR phải có các kiểm thử hồi quy trực quan và các bước xác minh trực tiếp. tôi muốn kết quả cuối cùng giống hệt 100% so với bản gốc - bao gồm cả lỗi
Agent chia nhỏ công việc thành các bước độc lập, viết một danh sách kiểm tra có thể kiểm toán và chuẩn bị từng đơn vị để nó có thể được xây dựng, xác minh và đưa vào một cách an toàn.
Ví dụ 4: Sửa những thứ mọi người báo cáo trên Slack
Nếu bạn đã từng thấy tôi trên Slack trong một trong các kênh vấn đề hoặc phản hồi của chúng tôi, bạn có thể sẽ thấy những câu kinh điển này:
# luồng tin nhắn đã có đủ ngữ cảnh
/poteto-mode làm đi
/poteto-mode tái tạo cái này với /control-app. nếu nó tái tạo được trên nhánh main, hãy sửa nó và cho tôi xem video làm bằng chứng
Nhiều kỹ năng tôi đã nói đến ở đây đã được /poteto-mode tự động sử dụng, vì vậy phần lớn thời gian bạn chỉ cần sử dụng /poteto-mode và tiếp tục cuộc sống của mình!
Nghệ thuật lập kế hoạch
Chế độ lập kế hoạch thường được sử dụng như một cách để thuyết phục bản thân rằng agent sẽ làm đúng. Nhưng thực tế là các kế hoạch trừu tượng chỉ cho bạn ảo tưởng về sự tiến bộ. Một kế hoạch dài và chi tiết làm cho nó có vẻ như bạn và agent của bạn đã rất hiệu quả, nhưng nó có thể thiếu chất.
pstack cung cấp cho bạn các công cụ để kết hợp điều tra kỹ lưỡng, bằng chứng thực nghiệm và xác minh nghiêm ngặt. Khi bạn lập kế hoạch theo cách này, kỹ thuật với các agent không còn cảm giác như một canh bạc. Nó trở nên có thể dự đoán và lặp lại.
https://x.ai/bot/plugin/9717366
Cảm ơn bạn đã đọc, và hãy đón chờ Phần 3!
