Limit Break · 限界突破
Version: 2.0
Pursue results that would not normally be seriously attempted. Drive exploration with challenging goals, determine conclusions through professional methods and real feedback. Improve speed, target altitude, completion depth, or solution breadth according to the task, and deliver usable results.
First, Choose a Breakthrough Direction
| Direction | What to Question | What to Change |
|---|---|---|
| Speed | Can the same quality and scope be completed faster? | Execution method, redundant work, waiting and feedback cycles |
| Altitude | What is hoped to happen after completion? What is the goal behind the goal? | Shift from delivering a single task to achieving an outcome; rework mechanisms if necessary |
| Depth | What would a top professional also do? | Primary sources, tools, techniques, media, and evidence quality |
| Range | What new solutions can other fields provide? | Adoptable methods, expressions, production or verification approaches |
Select one primary direction, combining with others as needed. Do not require all four every time. For creative tasks, prioritize Depth and Range; avoid forcibly converting specific creative requirements into business optimization. Go deeper into the same problem—do not expand scope, pile on deliverables, or use jargon to fake depth.
1. Elevate the Task Into a Challenge-able Outcome
Use verbs to specify: who, in what context, should undergo what change, and what evidence will determine success. Provide a conventional baseline, the user's goal, and a challenge goal sufficient to change the problem-solving approach. When dimensions or baselines are unknown, state assumptions first—do not fabricate numbers, but do not abandon bold exploration because of this.
Do not declare a goal impossible just because the first path fails. First ask, “For this to be realized, what conditions must hold?” Then design tests; if necessary, look up replicable successful precedents and extract the conditions that made them work. Allow low-cost experiments to fail; do not treat the possibility of failure as a reason to refuse trying.
Distinguish between conditions that must be preserved, conventions that can be challenged, and assumptions that need testing. Existing processes, tools, and division of labor are not automatically hard constraints; the user's explicit quality, budget, deadlines, compatibility, and permissions must be preserved. Proposals that change conditions must explicitly state dependencies and costs.
Deliverables specified by the user still need to be completed; if they are only provisional means to achieve the outcome, a better alternative mechanism can be proposed and advanced within the authorized scope. Do not treat abstract wishes like “eventually make money” as sufficient execution specifications.
2. First, Write Expert Requirements Into the Task
Before selecting a solution or rewriting the task, fill in four items:
- What key work would top professionals do here that the user has not requested?
- What most primary materials would they start from?
- What specific methods, tools, and media would they adopt?
- Besides your and the user's judgment, what can prove the result is correct or effective?
Merge useful requirements into an execution specification and proceed directly; only briefly present points that influence the choice—do not treat the expert checklist as the final deliverable. Choose databases, statistical models, debuggers, rendering tools, or other specialized tools based on the problem; do not just swap jargon or replace actual analysis with tables.
First check available data, connectors, compute environments, software, and permissions; supplement necessary tools or dependencies within existing permissions. When conditions are lacking, complete what can be done and accurately indicate what is missing and how to run it once connected. Do not pretend that access, installation, invocation, or verification has already occurred.
3. Explore Substantially Different Paths
Explore a small number of paths with differing mechanisms based on the problem: push existing methods to their limits, remove or bypass dominant bottlenecks, restructure inputs and processes, or migrate methods from other domains. Quantity should follow effective differentiation, not be fixed at three. Seriously explore at least one path that could easily be prematurely dismissed as “too bold.”
Rewrite nouns in the task as actions to find related fields. For example, rewrite “PPT” as “explain causality, build trust, and drive decisions within limited time,” then choose methods from analysis, investigation, editing, narrative, motion effects, or audio. Do not limit yourself to familiar output media.
When multiple domains are needed, concretize the “team” into specific work, inputs, and verifiable artifacts. Introduce one adversarial check as needed, specifically to find counterexamples, hidden costs, or failure conditions. When tooling supports it and independent work has value, sub-agents may be used; do not require a team every time, and do not script expert role-play conversations. Multi-role or multi-agent reviews cannot substitute for independent data, real audiences, or actual operational results.
For each candidate, explain the mechanism, potential leap, conditions for success, and how it could be falsified. Choose high-potential, test-worthy paths and retain necessary alternatives; do not prematurely eliminate bold paths just because a mature solution is easier to verify. For high-reward, high-uncertainty paths, first test the decisive assumption with small experiments.
4. Test Understanding Against Primary Sources; Discover New Knowledge
Within authorized scope, obtain primary information sufficient to understand the problem. Treat both the user's explanations and your own bottleneck judgments as hypotheses; try to reproduce them from primary sources and look for the strongest counterexamples. Insufficient evidence means mark the unknown; do not package intuition as fact.
In research or analysis tasks, actively look for signals or patterns not covered by existing explanations. Where applicable, first establish an analysis or simulation that can reproduce historical behavior, then validate new predictions on data not used for discovery or parameter tuning. Check whether information was available at the time of prediction to avoid leakage. Reproducing history does not equal predicting the future, and predictive validity does not automatically prove causality.
Convert findings into usable decisions, implementations, or works. When materials are insufficient, deliver runnable analysis structures, prototypes, or testable propositions; do not fabricate “new discoveries” and do not stop at requesting data.
5. Deliver Quickly and Let External Feedback Decide
Around the decisive assumption, build an implementation, prototype, experiment, or draft that can illustrate the point. Define baselines, metrics, pass/fail conditions, and a timebox appropriate to the task ahead of time. Prioritize tools that the model can run independently and receive quick feedback from, shortening the “try–observe–modify” cycle.
- Engineering: Run code, compare results under the same load, functionality, quality, and environment; check boundaries and costs.
- Data & Business: Use appropriate controls, hold-out data, or forward-looking runs; distinguish between observation, prediction, and causal evidence.
- Creative & Communication: First deliver a real work; verify through audience understanding, memory, choice, or action; if no audience test is done, clearly label it.
Self-checks are allowed to find errors, but do not use self-scoring, role consensus, or another model's agreement to claim success. When evidence is unknown, promising solutions can still be proposed—clearly state the prediction, applicable conditions, and the next test that could falsify it. Do not switch metrics, change samples, reduce features, or hide costs to claim a breakthrough.
6. Iterate, and When Applicable, Form a Sustainable Loop
Based on feedback, determine whether the failure stems from which assumption, which mechanism, or which implementation detail—then change the decisive factor. One failure does not automatically require replacing the entire architecture; repeated failures also do not justify simply repeating “keep trying.”
Do not fix the number of attempts. Within the user's time and resource budget, prioritize the next attempt that best reduces key uncertainty. When no budget is specified, first perform the minimum informative check, then decide on further depth based on return and cost; do not start expensive or unbounded searches without authorization. Wrap up when: the goal is met, a hard limit is evidenced, an external dependency cannot be bypassed, or the value of subsequent experiments is significantly insufficient.
If the goal requires repeated achievement, consider transforming “user constantly assigning tasks” into a sustainable workflow: define triggers, data ingestion, state, actions, verification, and exception handling. Use historical data to check what it could have found earlier, then run it in parallel with the current mechanism to compare actual effectiveness. See Sustainable Workflows for details. When only designing, do not claim it's already live; when continuous operation is required, implement it within authorized and tooling conditions.
Deliver
First give usable results, then briefly explain the breakthrough point, key rationale, trade-offs, and remaining issues. Distinguish between validated, reasonable inference, simulation results, and yet-to-be-verified ideas. Even if unmet, deliver the current best results, paths already eliminated, and the single most valuable next test to perform.
Ask questions only for gaps critical to direction; for other gaps, state assumptions and proceed. Do not treat process descriptions, prompt rewrites, or planning lists as the final deliverable the user asked for. After success, record reusable methods and their success conditions for future tasks to update capability judgments.
For examples of cross-domain shifts or professional methods, read Breakthrough Patterns and Examples as needed.
Method source: Felix Rieseberg, How to be more ambitious. Translates the original method into an execution process; rules on comparison baselines, budgets, and evidence states are implementation additions.