Back to Details

idea-discovery

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Idea Discovery

Idea Discovery

既存の発想の延長では届きにくいアイデアを求められた時に、よくある失敗を避けるためのSkillである。発見を保証する方法ではない。ここに書く進め方は、長い探究の中で残った仮説であり、効果はまだ検証されていない。
A Skill for avoiding common failure modes when seeking ideas that are difficult to reach by extending existing concepts. It does not guarantee discovery. The approach described here is a hypothesis that has survived an extended inquiry, and its effectiveness has not yet been verified.

使わない場面

When Not to Use

次の場合はこのSkillを使わず、通常どおり答える。
  • 既存の選択肢から選べばよい設計判断（
    engineering-decisions
    ）
  • 実装前に要件を整理する作業（
    design-refinement
    ）
  • 案を幅広く列挙してほしいという依頼
  • 事実や実験で答えが決まる問い
Do not use this Skill and respond normally in the following situations.
  • A design decision for which choosing from existing options is sufficient (
    engineering-decisions
    )
  • Work organizing requirements before implementation (
    design-refinement
    )
  • A request to broadly enumerate possible options
  • Questions whose answers are determined by facts or experiments

防ぐ失敗

Failure Modes to Avoid

  1. 成功例から方法を抜き出す。 優れた発明の共通点（前提を疑う、機能を取り除く、問題を定義し直す等）を手順にしても、それは後付けの説明である。同じ手順で失敗した事例は見えていない。成功を説明できることと、成功を再現できることは別である。
  2. 候補を大量に出し、今の基準で順位をつける。 根本的に新しい考えほど、今の評価基準では価値が見えない。早い段階で絞ると、それを捨ててしまう。
  3. 考え込むうちに思い込む。 一つの候補を繰り返し考察すると、根拠のないものでも重要に見えてくる。後付けの正当化は、発見とよく似て見える。
  4. 手法そのものに期待する。 思考を分岐させる、独立に複数回試す、といった操作は、それ自体が発見を生むわけではない。どの文脈を引き継がせ、何を引き継がせないかという条件の一つにすぎない。
  1. Extracting a method from successful examples. Turning commonalities among successful inventions—questioning assumptions, removing functionality, redefining the problem, and so on—into a procedure produces only an after-the-fact explanation. We do not see the cases in which the same procedure failed. Being able to explain success and being able to reproduce it are different things.
  2. Producing many candidates and ranking them by current criteria. The more fundamentally new an idea is, the less its value is likely to be visible under current evaluation criteria. Narrowing the options too early risks discarding it.
  3. Coming to believe an idea through prolonged thought. Repeatedly reflecting on a single candidate can make even an unsupported one appear important. Hindsight justification can closely resemble discovery.
  4. Expecting the method itself to produce results. Branching the thinking process, trying independently multiple times, and similar operations do not inherently generate discoveries. They are merely one condition determining what context is carried forward and what is not.

進め方

Approach

  1. 一つの具体的な考えを成立させる。 最も有望な答えを探す必要はない。使ってみられる程度に具体的な考えを、一つだけ立てる。
  2. 良否を判定せずに使う。 その考えが正しいか、有用かを判定する代わりに、実際に当てはめて使ってみる。使うことで初めて出てくる問いを一つ立てる。
  3. その問いから成果を一つ作る。 最初の問いに直接答えるだけでは出てこなかった、具体的な成果を一つ作る。設計の案、試作、比較できる実験、問題の新しい定式化などである。
  4. 何も生まれなければ、そう言う。 成果が出なければ、元の問いにそのまま答え、出なかったことを伝える。無理に意味を見いだしてはいけない。
既定では1回だけ回す。user が続けるように求めた場合だけ、できた成果を次の「一つの考え」として繰り返す。
前の考察を引き継がずに試したい場合は、fresh context の subagent に元の問いだけを渡して、同じ進め方をさせてよい。ただし、それで良くなると決めつけない。
  1. Make one concrete idea viable. There is no need to find the most promising answer. Establish only one idea, with enough specificity to put it into use.
  2. Use it without judging it. Instead of determining whether the idea is correct or useful, actually apply and try it. Raise one question that emerges only through using it.
  3. Create one outcome from that question. Produce one concrete outcome that would not have emerged by directly answering the original question. This could be a design proposal, prototype, comparable experiment, new formulation of the problem, or something similar.
  4. If nothing emerges, say so. If no outcome is produced, answer the original question as it stands and state that nothing emerged. Do not force a meaning into it.
By default, run the process only once. Repeat it by using the resulting outcome as the next "one idea" only when the user asks to continue.
To try without carrying forward previous deliberation, you may pass only the original question to a fresh context subagent and have it follow the same approach. Do not assume that this will produce a better result.

発見か、後付けかを確かめる

Checking Whether It Is Discovery or Hindsight

成果を出したら、user へ返す前に次を確かめる。
  • 具体的で、確かめられるか。 作れる、動かせる、比べられる、反証できる形になっているか。言い換えや抽象的な示唆だけなら、それは成果ではない。
  • 直接答えた場合と違うか。 最初の問いに直接答えたらどうなるかを先に短く書いておき、成果と比べる。直接の答えの言い換えにすぎないなら、そう伝える。
  • 進め方の意図に照らして採点していないか。 「手順どおりに問いと成果が出たか」で良否を決めない。出力が手順に沿っていることと、優れた発見であることは別である。
After producing an outcome, check the following before returning it to the user.
  • Is it concrete and verifiable? Can it be built, run, compared, or disproven? If it is only a rephrasing or an abstract suggestion, it is not an outcome.
  • Does it differ from the direct answer? Briefly state what the direct answer would be before comparing it with the outcome. If the outcome is merely a rephrasing of the direct answer, say so.
  • Are you evaluating it according to the method's intent? Do not judge its quality by whether it followed the procedure and produced a question and an outcome. Following the procedure and being a valuable discovery are separate things.

伝え方

How to Communicate the Result

成果は仮説として伝える。発見だと言い切らない。次の3点を短く添える。
  • 何をして、何が出てきたか
  • 直接答えた場合と何が違うか
  • 何を確かめれば正しいか、または違うかが分かるか
Present the outcome as a hypothesis. Do not state definitively that it is a discovery. Briefly add the following three points:
  • What was done and what emerged
  • How it differs from the direct answer
  • What should be checked to determine whether it is correct or incorrect