Co sprawia, że dokument planu w markdownie dla projektu rozwoju oprogramowania jest dobry? Jaka jest różnica między dobrym planem a świetnym? Zawsze mówię, że spędzam ponad 85% swojego czasu i energii na fazach planowania. Cóż, co to dokładnie oznacza? Trudno to wyjaśnić w sposób abstrakcyjny; potrzebujesz namacalnego przykładu, aby naprawdę zobrazować niuanse. Postanowiłem więc podzielić się dobrym przykładem z dzisiaj. To również odpowiada na ostatnie pytanie, które otrzymywałem na temat mojego podejścia. Ludzie wydają się mieć wrażenie, że musisz zrobić wszystko w swoim projekcie za jednym razem. W moim podejściu to prawda, ale tylko dla wersji 1! Jeśli zdecydujesz, że chcesz dodać nowe funkcje lub zmienić sposób działania, możesz to oczywiście zrobić, gdy masz działającą wersję 1. A sposób, w jaki to robisz, jest taki sam, jak sposób, w jaki tworzysz wersję 1, czyli najpierw tworzysz super szczegółowy plan w markdownie, a następnie przekształcasz go w beadsy. Podam ci przykład z Cass, mojego programu do wyszukiwania sesji agenta kodowania, który jest dość skomplikowanym programem w Rust, który automatycznie wykrywa, analizuje, przechowuje i indeksuje wszystkie twoje wcześniejsze logi sesji z niemal każdym agentem kodowania. Oferuje błyskawiczne "wyszukiwanie podczas pisania" poniżej 50 ms we wszystkich tych logach i ma wiele innych fajnych funkcji. Postanowiłem, że chciałbym dodać do Cassa funkcję podobną do tej, którą już mam w MCP Agent Mail i w beads_viewer (bv): możliwość eksportowania twojej konfiguracji jako statycznej strony internetowej, która może być serwowana za pomocą GitHub Pages. Możesz zobaczyć przykład dla bv dla tego projektu, który jest ostatecznym wynikiem procesu planowania, który opiszę w tym poście: Ta funkcjonalność sprawia, że generowanie i wdrażanie wyeksportowanej strony za pomocą narzędzia gh jest bardzo szybkie i łatwe. Strona zazwyczaj składa się z pliku sqlite i wielu plików typescript oraz wasm, które działają całkowicie w przeglądarce, ale z bardzo dobrą wydajnością i ładnymi funkcjami oraz stylizacją, co możesz zaobserwować w podanym przykładzie. Teraz, dzielenie się wiadomościami z MCP Agent Mail lub dużą ilością beads to jedno, ale dzielenie się dużą ilością logów sesji agenta kodowania to zupełnie inna sprawa; te rzeczy często zawierają wrażliwe informacje, klucze API, przekleństwa/inwektywy (przynajmniej moje!), oraz inne materiały, które zdecydowanie nie chciałbyś ujawniać światu. Ale GitHub Pages, choć jest miłe, działa tylko dla publicznych repozytoriów (przy okazji, moje narzędzia wspierają również strony Cloudflare, ale GH Pages jest lepsze i łatwiejsze w tym przypadku). Jak więc poradzić sobie z tymi problemami? Odpowiedzią jest szyfrowanie: użytkownik najpierw wybiera, które agenty kodowania uwzględnić, które foldery projektów, okres czasu itd., a następnie generowany jest pakiet (zauważ, że ten pakiet jest w kanonicznym formacie, w który Cass wewnętrznie przekształca wszystkie wiadomości agentów kodowania z ich oryginalnych formatów) i następnie użytkownik podaje hasło do szyfrowania tego pakietu. Pomysł polega na tym, że chociaż repozytorium i strona internetowa są publiczne, wszyscy oprócz ciebie i innych, którym powiesz hasło, zobaczą po prostu pole hasła i nie będą w stanie przeczytać żadnych wiadomości. ...