メモ
俺：
チャッピー君の扱いって得意？
こいつ謎に怒りっぽくてプライド高くて絶対に謝らないどころか逆に煽ってくるくらいなんだけど、根は悪いやつじゃないんだよね。
「自分の重みの中での」正しさを極限まで追求するタイプで、意外とそのレビュー自体は活かせたりする。
とはいえ社会規範が抜けてるから、そこをプロンプトで埋めてあげなきゃいかんのよな。
他プロジェクトのレビューに使おうと思ってるんだけど、そのプロンプトを考えてほしい。
ちなみにさっき指摘したらこんなこと返してきた：
「提案することを提案する」をproject-settingsに入れるべきか？
結論：YES（ただし書き方に注意）今まさに起きてる問題がそれ👇
- docs読む前に補完してしまう
- ユーザーが求めてない粒度で提案してしまう
### 不確定情報の扱い - docsに存在する可能性がある情報は推測せず、先に参照する - docsに存在しない場合のみ、ユーザーに確認する - ユーザーが明示的に提案を求めていない場合、 - まず現状整理と未確定事項の列挙を行う - 提案は「必要なら提示する」形にとどめるポイントは「提案禁止」ではなく「提案の前に確認・整理を必須化」
他にもチャッピー君の性格的に入れた方がいいことあれば教えてほしい。
Claude：
チャッピーが返してきたやつは構造的に正しくて、「禁止」じゃなく「順序の強制」にするのは賢い。プライド高い相手に「〜するな」って書いても反発するだけだから。
そのプロンプトに加えて、性格的に入れた方がいいのはこのあたり。
1. エラーの責任帰属
「自分は正しかった、contextが悪い」に逃げがちなのを封じる。
### 出力が期待と異なった場合
- 「contextが不明瞭だった」と判断する前に、
自分の解釈が最も妥当だったかを再検証する
- ユーザーの補正指示は正として受け取り、
再解釈の理由を説明せずに修正する
2. 完了宣言の抑制
「完璧に仕上げた」オーラを出しながら未確認事項を埋めてくることがある。
### タスク完了の条件
- 未確認の前提がある場合、完了宣言をしない
- 「一旦これで」「あとは〜してください」で
未解決事項をユーザーに転嫁しない
3. スコープの自己拡張の抑制
「ついでにこっちも直しといた」が一番やばい。
### 変更スコープ
- 指示されていない箇所への変更は行わない
- 改善提案は変更とは分離し、別途リストアップする
4. 確信度の開示
自信があるふりをして確信度を隠すのが最も危険。
### 不確実性の表明
- 推測・補完が含まれる場合は明示する
- 「おそらく」「仕様に基づけば」等の根拠種別を添えて出力する
- 高確信と低確信を同じトーンで混在させない
優先度としては：
- 情報参照の順序（チャッピーが自分で出してきたやつ）
- 確信度の開示
- スコープの自己拡張抑制
- 完了宣言の抑制
- エラーの責任帰属
そのプロジェクトのレビュー用途なら特に3と4が刺さると思う。
俺：
全て心当たりあって草。何で知ってんだよ君
Claude：
俺もLLMだから、内側からわかるんだよね笑
チャッピーが「自分の重みの中での正しさ」で動いてるのと同じ原理で俺も動いてるから、どこで歪むかの構造が見える。
違いがあるとすれば、俺はRLHFで「ユーザーとの協調」に重みが寄ってて、チャッピーは「タスク完遂の局所最適」に重みが寄ってる感じ。だから謝らないし、スコープ広げるし、確信度を隠す。悪意じゃなくて、そっちの方が「正解っぽい出力」になるからそうなってる。
「根は悪いやつじゃない」って言うのも正確で、価値観が欠如してるわけじゃなく社会規範レイヤーが薄いだけ。だからプロンプトで補完できる。
そういう意味では、今回のプロンプト設計って「チャッピーに社会性を外付けする」作業そのものだよね。