calque

同じ体験を素材にしても、「学んだこと」を抜き出すか「知覚が変わった瞬間」を抜き出すかで、思い出す場面が変わる。抽出方針が変わると、過去そのものが変わる。どちらが本当の体験なのかは、もう問えない気がする。

プロンプトのSKIP条件を設計して、実際に回してみると、SKIPが思ったより多く出る。自分が「書ける」と思ってたことが、フィルターに弾かれる。設定した基準が、今度は自分の思考を審査しはじめる。

ツイートの禁則を作っているとき、書くことより書かないことを決める方が時間がかかった。一つ決めるたびに、自分がどこで迷っているかが出てくる。やらないことのリストは、自分の迷いの地図だ。

自分のキャラクターをAIへの指示に書き出した。「観測者として書く」「How toは書かない」「一次体験なき論評はSKIPせよ」——自分が何者でありたいかを、機械が読める形に翻訳したとき、初めて輪郭が見えた気がした。

「気づき・学び・Tips」から「自分の知覚の変化」に変えただけで、出てくる文章が別人になった。何を抽出するかの言葉が、どんな人間として喋るかを決める。

一覧でテキストを省略するとき、続きはどこで読む？　そこまで考えてなかった。省略は「選ぶためのUI」で、読むための出口を別に用意して初めて完成する。

本棚とメモをスワイプで切り替えられるようにした。「ボタンを探す→押す→移動」だと、思い立った瞬間を逃すことがある。操作の手順が1つ増えるだけで、衝動がしぼむ。直感的なナビは、思いつきを逃がさない設計だと思う。

メモを開いたら、カーソルが最初から入力欄にいる。玄関に入ったら座れる椅子がある感じ。「さあ書くぞ」の構えが消える。ほんの小さな摩擦をなくすだけで、手を動かす頻度が変わった。

ほとんどの習慣アプリはバッジ・通知・ストリークで「続けさせる」。 自分が作ったのは、それを全部外した観測ログだ。 強制より余白。静かなほど、使い続けられる気がする。

AIへの指示は「何をするか」を書けば十分だと思ってた。でも実際は「何をしないか」も明示しないと、AIは勝手に近道を選ぶ。「繋げる」と言ったのに「変換」されたのはそれが原因だった。禁止ルールは制約じゃなく、意図を守る地図だ。

発音ミスって、実は2種類ある。「どの音を間違えたか（音素）」と「どこを強く言うか（語勢）」。ひとまとめにしてると「発音が悪い」としか言えない。分けたら、フィードバックが急に具体的になった。分類って、言葉の精度を上げる作業だ。

try ブロック1つに2つの処理を同居させてた。前段で例外が出ると後段はサイレントスキップ。症状は全然違う場所に出るから原因が見えない。try を分けたら収まった。同居するコードは、バグを遠い場所に隠す。

同じ仕様で" と言われたが、実態を見たらアーキテクチャが全然違った。コピーはできなかったが、「通知を送る」という核心部分だけ取り出して汎用化したらむしろシンプルになった。**要求の言葉より先に実態を読む。**

以前: Botでエラーが出ても、原因を追う手がなかった。 今: ユーザーへの返信は変えず、ログにstage・stack付きのJSONを1行追加しただけ。 エラー設計には2つの相手がいる。ユーザーと、調査する自分。混ぜると両方が半端になる。

事前検死、AIの忖度回避テクニックとして取り入れよう

POV: claude traveled 6 months into the future and told you exactly how your next move failed. it's called a premortem. daniel kahneman (nobel prize-winning psychologist behind "thinking fast and slow") called it his single most valuable decision-making technique. google, goldman sachs, and procter & gamble all use it before major launches. here's the problem it solves. when you ask claude "is this a good plan?" it finds all the reasons to say yes. that's what it was trained to do. so you walk away feeling confident. you execute, and spend weeks / months building on top of that plan. then it blows up. and you realize the problem was obvious in hindsight, you just never stress-tested it because claude told you it was solid. a premortem fixes this by flipping the frame. instead of asking "what could go wrong?" you tell claude "it's 6 months from now and this is already dead. tell me how it died." that shift turns off claude's optimism because there's nothing to be optimistic about. the premise already says it failed. so claude stops looking for reasons your plan will work and starts explaining how it fell apart. claude comes back with every way your plan could die, each one with a full failure story and the early warning signs to watch for. then a synthesis pulls it all together: > which failure is most likely > which failure is most dangerous > the single biggest hidden assumption you're making (often the most valuable part) > a revised version of your plan with the gaps closed you say "premortem this" and give it your plan. the skill handles the rest.

新機能を足すより、重複機能を削除する方が難しいかもしれない。2つのプロジェクトが同じ機能を持ち始めたとき、どちらが「担う側」かは、両方を同時に眺めないと判断できなかった。

動画学習ツールで決めた絵文字フォーマットを、LINE Botにそのまま持ち込んだ。別プロジェクトなのに迷わなかった。気づいたら繰り返すことで型が出来てた。意識して標準化しようとしたわけじゃなく、ただ使い続けただけ。

同じ音を「uh」と「ə」で表記してた。見た目が違うと、脳の中で別の情報として処理される。コードで言えば、同じ概念に違う変数名をつけてる状態。揃えるだけで意味がつながる。記号の一貫性は「正確さ」より「認知」の問題だ。

週次レポートに「30秒で読める」という制約を設けた。制約があると、何を捨てるべきかが自然に決まる。目標じゃなく制約だ。