/handoffというスキルを書いたんだ。セッションが圧縮制限に近づいたり、役に立たなくなったときに、やったことや話したことを説明するマークダウンファイルを生成してコミットするんだ。圧縮の前にやるから/handoffって呼んでるよ。（「圧縮ってそういうものじゃないの？」そうだけど、それは消えちゃう。これは圧縮されたセッションの永久記録みたいなもの。）長期的な一貫性を保つのに役立つかは分からないけど、私のセッションは時々そのドキュメントを参照することがある。もっと言うと、これは「日報」タイプのシステムとして優れていて、マネージャー（や未来の自分）に何をしたか、なぜそうしたかを見せることができる。要するに、その長期的な一貫性を冗長なマークダウンファイルに凝縮した方が、あなたや未来のセッションが必要に応じて読めるかもしれない。多くのコンテキストは、試行錯誤や解決すべき問題を見つけることに関するもので、コンテキストウィンドウを埋めるためにそれを求めるよりも、もっと簡潔に文書化できるはずだ。 EDIT: 誰かがインストール手順を聞いたから、ここに投稿したよ： https://news.ycombinator.com/item?id=47581936

無駄な言葉を防ぐルールをすでに自分のシステムやプロジェクトのCLAUDE.mdに含めていない人がいるのが信じられない。冗長性に関しては…最近の研究によるとかなり有用みたいだよ。Gemini 3.1から引っ張ってきた「2つの主要なパラダイム：冗長な推論経路を生成する（自己整合性）と、冗長なモデルから出力を集約する（アンサンブル）」についての新しい論文が書かれている。

あと、推論時間のスケーリングもね。答えにたどり着くときにトークンをもっと生成することで、より良い答えが出せるんだ。余分なトークンが全て役立つわけじゃないけど、モデルがタスクパフォーマンスで強化学習されたときに最小の長さを最適化するのは逆効果みたい。

何をするか説明するな。ただやれ。 同じ理由でここに来た。正確にこのセクションの出力が間違ったことをしてるって教えてくれた回数を計算できないよ。だから中止してプロンプトを修正できたんだ。

でも出力トークンは5〜10倍も高いから、結局は価格的にかなり変わってくるよね。

そうだけど、プロンプトキャッシングで入力コストが90%も下がるし、出力トークンはキャッシュされないから高くつく。これってどうなると思う？

自分の出力トークン比率は2%（高価なトークンで50%の節約、考えることも含めてるので、これがもっと多いこともある）。似たようなトーンと出力フォーマットのシステムプロンプト内容を持ってる。

同意。こういうプロジェクトは短期的な視点に見えることが多いよね。最近は、新しいものが流行を超えて続くと確信できるまでは、バニラの設定を保つ方向に傾いてる。AIラボに飲み込まれない限り、ニッチな用途だけのものにならないかどうかも考えちゃう。例えば、ワークツリーはまだ使ったことがないし、MCPもほとんど使ってない。でも、スキルは大好き。

これらの「Claudeを修正する」レイヤーには隠れたコストがあって、ワークフローが常に自分の下で動いてるんだよね。一つが役立っても、数週間後にはそれが時代遅れになったり、デフォルトに組み込まれたりすることを賭けてるようなもんだ。

Claude Codeに関しては「効率的市場仮説」みたいなものを共有してるよ。Anthropicは基本的に自分たちの製品を使い倒してる天才たちの温床だから、バニラ設定がコードを書くのに最もパフォーマンスが良いものになるような市場圧力がすごく高いんだ。私はCLAUDE.mdを非常に賢いリモートの同僚への初稿メモみたいに扱って、Claudeのいろんなクセをそのまま活かしてるけど、すごくうまくいってるよ。

うん、確かに。「冗長な」出力の多くは方向性を強化するためにあるんだよね。例えば「あなたは絶対に正しい！」っていうのは、ユーザーが正しいってことだし、反対の道は無視すべきってこと。だから、これを取り除くと曖昧さが出てきちゃう。これは望んでることじゃないよ。

一般的にはその懸念は妥当だと思うけど、ここに当てはまるかはよく分からないな。ここでの目的は、低価値の出力を排除することみたいだし、例えばお世辞やプロンプトの再表現、フォーマットのノイズなど、役に立つ推論を抑えるのとは違うと思う。そういう意味では、短い出力が必ずしも悪い答えを意味するわけじゃない。ただ、モデルに推論を提供する前に答えを出させようとすると、時にはモデルが早まって方向性を決めてしまうかもしれないね。

Claude Codeが思考なしを選択肢にしてないとは思わないな。最低限「低い」思考があるって感じ。

うわぁ。そんな自信満々に言われると、ほんとにムカつく。私、これが一番嫌いなLLM主義だわ。「ある指示。常にこれ、決してあれ。」

これって本当？ 非推論型のLLMは自己回帰的だよね。推論型のLLMは「1行目」の前に何千もの推論トークンを出力できる。

「推論前の答え」っていうのはその証拠だよ。トランスフォーマーの最も基本的な概念を見失ってる。著者がトランスフォーマーの仕組みを理解してないとは思わないな。この指示の意図は出力トークンコストを攻撃的に減らすことにあるみたい。つまり、この指示はQwenモデルシリーズの/nothinkトークン指示を模倣するためのハックだと読んでる。もし質の高い出力が目標なら、確かに極端すぎるかもしれないけど、このリポジトリには冗長性を（定量的に）減らすための有用な指示が他にもあるよ。

ほとんどのプロバイダーはすでにCOTの長さをAPIで制御できるんじゃない？ 理由がいらないなら、こうやってハックするんじゃなくて、APIリクエストで無効にすればいいのに。（内部的には空のブロックを事前に埋めてるだけだと思うけど、これを公開してるプロバイダーは「考えないこと」がトレーニングの一部として含まれてることを確実にしてるんだろうね。）

短いレスポンスを強制すると、推論や思考の連鎖に悪影響が出るよ。いくつかの潜在的な利点はあるけど、レスポンスの長さを強制したり、回答のタイミングを決めたりすると、答えを出すことを優先するあまり、幻覚が増える可能性があるんだ。もっとトークンが必要だったら、さらに推論して応答を検証するのに使うべきなんだけど。一般的に、複数行を使って推論するように訓練されてるから、複雑なタスクにはこのプロンプトはあまり役に立たないよ。

答えは常に1行目。推論はその後、決して前には来ない。これが答える前に推論するのを止めるわけじゃない。これはユーザー向けの出力にだけ影響して、推論トークンには影響しない。答えを示す時点で既に推論は終わっていて、説明の上に答えを表示するだけなんだ。

私にとっては「誰がこのプレミアLLMをうまく活用する方法を一番知ってるのか – それを作ったAnthropicなのか、それともこのランダムな人なのか？」ってシンプルな話だよ。だから今はOpenCodeみたいなものよりも、ファーストパーティのツールにしか興味がないんだ。

これにアプローチする最良の方法は、役立ちそうなものをいくつか選ぶことだと思う。包括的な評価がほとんどないし、人それぞれやってることが大きく異なるから、ここは巨大な雰囲気祭りだ。トーンや出力フォーマットを何度も試行錯誤してみたけど、能力には影響しないみたい（自分の雰囲気評価に基づいて）。