2 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Latheは、LLMに代わりに考えさせるのではなく教えさせるための実験で、プロンプトから実習型の技術チュートリアルを生成し、ユーザーがローカルUIで実際に手を動かして追いながら学べるようにする
  • 単一パートまたは複数パートのチュートリアル生成をサポートし、質問、チュートリアル検証、新しいパートへの拡張、検索タグ追加のためのLLM skillsを提供する
  • Claude Code、Cursor、Codexの対話型LLMセッションでチュートリアルを生成でき、Go製のlathe CLIがチュートリアルの保存、管理、レンダリング、永続状態を担う
  • CLI自体はLLMを呼び出さず、Webボタンとlathe verifylathe extendコマンドは、LLMセッションに貼り付けるためのskill commandを提供する方式になっている
  • ローカルWeb UIはlathe serveで実行し、デフォルトポートは4242; チュートリアル一覧では、タイトル、テーマ、タグ、リポジトリ、ツールバージョンでの検索と、新しい順・古い順・タイトル順の並べ替え、状態・種類・タグ・バージョンのフィルタリングをサポートする
  • 読書UIは、右サイドバーの目次ナビゲーション、本文途中のサイドノート、チュートリアル末尾の読者向け練習問題を提供する
  • すべてのチュートリアルは、使用した出典、モデル、チュートリアルの文体を導いたプロンプトを記録し、出典記録はmetadata.jsonsourcesフィールドとUIの出典パネルで確認できる
  • チュートリアルはグローバルパス~/.lathe/tutorials/にスラッグごとのディレクトリとして保存され、metadata.jsonpart-01.mdのようなパートファイル、またはindex.mdで構成される
  • インストールは単一のスタンドアロンバイナリlathe$PATHに置く方式で、macOS向けHomebrew cask、curl | shインストールスクリプト、Go 1.25+ベースのgo install、ソースビルドをサポートする
  • skillsはバイナリに同梱されており、lathe skills installでClaude Code、Cursor、Codex向けの場所にインストールできる
  • チュートリアルの文体はvoiceで制御され、デフォルトのplainspokencompanionが同梱されており、/lathe-voiceでカスタムvoiceを作成できる
  • voiceは文体だけを変え、正確性、リサーチ、引用、検証、構造は変えない; カスタムvoiceは、実在人物のなりすまし、資格の偽装、LLMによる著作の否認を拒否するよう設定されている
  • 検証は任意であり、対話型LLMセッションで/lathe-verify <slug>として実行される; 新しいmktemp -dスクラッチディレクトリにファイルを作成し、コマンドと## Checkpointブロックを実行したあと結果を記録する
  • 検証状態はunverifiedverifyingverifiedfailedskippedextendingのいずれかで、必要なツールがない場合は失敗ではなくskippedとして記録される
  • 検証は通常のLLM権限モデルの下で実行されるため、ツール呼び出しを見て承認でき、スクラッチディレクトリはビルド成果物をリポジトリ外に置くための慣習にすぎず、セキュリティ境界ではない
  • LatheはLLMである以上、LLMが失敗するのと同じ形で失敗しうるため、チュートリアル生成には利用可能な中で最大の“thinking”モデルの使用を推奨している
  • 現在の自己テスト済みユースケースはmacOS上のClaude Codeであり、それ以外の構成も動作する可能性はあるが未検証だと明記している
  • 個人学習のための私的利用以外のコンテンツ作成用途は想定していない

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsの意見
  • 関心のあるテーマについて、LLMにソクラテス式問答で継続的にクイズを出させる似たようなやり方もよい
    より深いレベルの質問を投げ続けて自分で答えにたどり着けるようにすると、その過程で問題を真剣に考えることになり、理解・学習・記憶に役立つ
    そのため、どんなコーディングエージェントや類似ツールでも使える Socratic-quiz スキルを作った: https://pchalasani.github.io/claude-code-tools/plugins-detai...
    例えば糖尿病/インスリン、ドーパミンと動機づけ、Claudeの実装のように直感に反する内容をよりよく理解するのに使ってみたし、いわゆる認知負債を減らすのにも役立つ
    強いLLMはこうしたクイズが意外とうまく、一種の心の理論のようなものまで見せる

    • この場合、コンテキスト長の劣化はどう扱っているのか気になる
      より難しい質問は、コンテキストがほぼ埋まった頃になってようやく出てくるはずだが
    • 力の源泉がLLMなら、LLMなしのあなたは何なのか?
    • 実際の資料で学ぶことを補完する用途なら有用かもしれない
      糖尿病/インスリン、ドーパミンと動機づけのような複雑なテーマを「理解した」と軽く言っているが、完全に理解するにはかなりの勉強が必要だ
      好奇心ベースの学習として見るならよいが、実際に重要だったり真剣な内容を学ぶ方法としてはどうだろうか
      資料を調べて、ガイド付きの授業を追う従来のやり方のほうが、この方法より整っていて速い
  • 昔からずっといた、かなり明確な範囲の人たちは今後も存在し続ける気がする
    ある人は好奇心が強く、自分のしていることを理解したい、あるいは理解する必要があり、別の人はそうではなく、ただ実行したいだけだ
    その欲求そのものが、専門家を作る根本的な性格特性
    LLMはこうした好奇心の強い人たちにとって夢のような道具で、むしろさらに加速させるだろう
    実際の「損失」はほとんどなく、気にしない人たちが仕事をもっと簡単にできるようになるだけだ
    彼らにとってもよく、好奇心の強い人たちにとってもよいので、全体としては得だ

    • 両方あると思うし、対象が何かと同時に何をしているかにもよる
      あるときは長く深く掘り下げるのが楽しくて面白い
      逆に、なぜ何かがうまくいかないのかにはあまり好奇心がなく、ただ動くようにして本来やりたかったことに戻りたいときもある
      結局、LLMはどちらの場合でも役に立つと感じる
    • ある人は環境に関係なく好奇心を持ち続けられるだろうが、ある人は人生経験によって好奇心を育てたり失ったりする方向に揺れうる
      いつでもそばにある**「今すぐ答えだけをくれ」ボタン**は、彼らを無関心な側へ引っ張る強い力になりうる
  • かなり新鮮なアイデアだと思う
    LLMの大きな利点は、優れた学習ツールであることにある
    多くの人は何かを生成するために使いたがるが、そこから得られる知識は過小評価されているようだ
    これまで手にできる最高のチューターかもしれない
    付け加えると、プロジェクトで金を稼ごうとしているかどうかを公開しなければならないような雰囲気はあまり好きではない
    金を稼ぐことが悪魔視されたり、白い目で見られたりしてはならない

  • 最近、仕事でこの一般的なパターンをかなり使っている
    決定論的な作業はカスタムCLIアプリとして作り、エージェントハーネスにはスキルを付け、そのスキルをエージェント内で実行させて、CLIとエージェント的推論で成果物を作らせるというやり方だ
    例えば「過去1か月にわたるこれらのチームのバックログ活動について、役員向けの要約を作ってくれ」と言えば、5〜10分で数ページの文書が読めるようになり、分析したチケットの引用も付いている
    人を煩わせたり、別の仕事を頼んだりする必要はなく、バックログをいつも通り最新かつ詳細に保っておけばよい
    反復作業で一貫した結果を出しにくい純粋なエージェント利用と、些細なことのたびに完全なアプリを作るか買うしかない状況との間で、非常に有用な位置を占めている

    • このアプローチはうまく機能するし、同意する
      ただ、ずっと逆にひっくり返したいとも思ってしまう
      望ましい構造は、ワークフロー知識と判断の大半を実際のコードに持たせた従来型のCLIプログラムで、特定のワークフローステップでだけコーディングエージェントを「ほんの少し」呼び出す形だ
      どう実装すればよいのかよくわからない
      こういうライブラリがすでにあるのか、あるならどう動くのかも気になる
      ちゃんとやるなら、CLIソフトウェアが既知のローカルIPCソケット経由でやり取りできるバックグラウンドサービスが必要そうだ
      例えば docker デーモンのような方式だ
      だが、そのようなIPC機能を公開しているコーディングエージェントソフトウェアやフレームワークは知らない
    • 同意する
      このパターンは Simon Willison の何かの仕事、たぶん Rodney と Showboat で初めて見た気がする
      特定のワークフローでは、Skills + CLI の組み合わせがLLMの柔軟性とCLIの一貫性の間でよいバランスを与える
    • 決定論的な作業の例をいくつか挙げられるか気になる
      例では、決定論的な作業は「このチームのバックログを取得すること」で、LLM部分は「各バックログを処理すること」と「要約をまとめること」だったのか?
  • まさにこの目的に合わせて、人気の**/grill-me スキル**を更新した
    昨日、pandasで極端に大きなデータセットをロードしようとしたときに、正確に何が起きているのかを、最後の細部に至るまで非常に洞察に富んだ詰問セッションで掘り下げた

    • そのバージョンをどこかに公開している?
  • すばらしいやり方だと思う
    少し前に友人に、プログラミングはコードを自分の手で直接タイプすることで学ぶものだと話した
    そこで、興味や必要に合わせた最小限の教育用サンプルを LLM で生成してみるよう勧めた
    Zed Shaw 式のプログラミング学習法、つまり音楽や美術の習作のようにコード例を手でそのままタイプする方法を試してみた
    しばらく学んでいたものの苦戦していたプログラミング言語で試してみたところ、数時間タイプしただけで流暢さが大きく向上した
    数時間タイプしているうちに、数週間勉強していたときより多くのコードを書いていたことに気づいた
    まだ言語をよく知らないとコードを生み出す作業は非常に遅くエラーも多いが、正しいコードをタイプすること自体は比較的単純だ
    そこでアプローチを「ただ盲目的にタイプする」に切り替えると、少なくとも読解と筋肉記憶の面では、数時間でそれまでの数週間より多くの練習ができた
    もちろん理解も重要だが、私の経験ではそれは別の軸であり、たいていは記憶と流暢さの後からついてくる
    何かを理論的に理解していることと、実際に使えることの間には大きな違いがある
    ここにある一般原理は、Stephen Krashen の言語習得におけるインプット仮説だ: https://en.wikipedia.org/wiki/Input_hypothesis
    子どもはただ話し言葉を聞き、入力にさらされることで言語を学ぶという内容で、大人も同じ方法で学べるとされている
    今はもうなくなっているかもしれない、すばらしい Web サイト All Japanese All The Time でもこの話を知った
    著者は日本語を大量に聞く方法で自ら仮説を試し、1年で流暢さを得たとしている
    https://web.archive.org/web/20080705194055/http://www.alljap...

  • とても良いアイデアで、この混乱した時代における LLM の正気な使い方のように感じる
    新しいプロジェクトを始めるときに何もかもが摩擦に感じられる状況で、勢いをつける良い方法になりそうだ

    • 実際、私の主なユースケースもまさにそこだ
      新しいプロジェクトに入るハードルを下げて、慣れてきたら自分でさらに深く進められる土台を作ってくれる
  • 興味深い領域を扱っていると思う
    システム設計面接の準備でも似たことを考えた
    Twitter 設計と WhatsApp 設計に関するブログ記事シリーズをいくつか使って実験してみた: https://prepcommons.com/
    それでも、最初のリクエストをただ処理するよりはるかに多くの労力がかかった
    AI は誰でも平均的な結果を作れるようにしてくれるが、良い結果を作るには今でもセンスと目利きが必要だ
    おそらく講義にもまったく同じことが当てはまるだろう

  • すばらしいプロジェクトなので試してみるつもりだ
    新しいテーマを勉強するとき、手元の資料をすべて LLM の「プロジェクト」に入れて、実際のコンテンツに基づいて教えてもらいスピードを上げるやり方はかなり気に入っている
    その一方で、すべてが自分の望む形できれいに整理されて出てくると、元資料を自分で見て苦労しながら把握して積み上げる理解が弱くなるのではないかと心配でもある
    だから、この方法のように LLM が引き起こす知的な怠惰をある程度和らげつつ、実際に自分の手でやることへより焦点を当てるアプローチは、私の好みにとても合っている

  • もっと気になるのは、自作のバイブコーディングツールを実際に使ってみた体験だ
    紹介だけでは、本当に使っていて気に入っているのかがよく分からない
    使っていて、時々反論もすると言っていたが、それ自体が一つの学習戦略なのかもしれない
    また、「別のモデルでチュートリアルがコンパイルできるかテストする」というのも、機能と呼ぶには少し微妙だ
    もちろん、一度のリクエストで完璧なチュートリアルを期待しているわけではない
    手書きのプロンプトの代わりにこれを使うべき理由もよく分からないし、ChatGPT Study モードがなぜ失敗したのかも気になる
    面白そうだったからだ

    • かなり使っているし、とても気に入っている
      もちろん自分でプロンプトを作ってもいい
      私が価値を感じているのは、再利用可能なスキルやプロンプトがチュートリアルを組み立て、Claude がただコピペするためのコードを出すのではなく、私が新しい概念を考えたり学んだりするのを助けてくれる点だ
      それにローカル UI のおかげで、Claude の Markdown 出力をスクロールするよりもチュートリアルを追いやすい
      チュートリアルシリーズが継続的に残るので、後から興味のあるテーマやチュートリアルの拡張に /lathe-extend で簡単につなげられる
      ただ、個人的に役立っているツールというだけで、誰にでもそうである必要はない
      ChatGPT Study は使ったことがないので、もう少し見てみる。教えてくれてありがとう