A Method Adjustment While Organizing a Pythagorean Proof

For a while, I thought this proof project had reached its end.

Starting on April 12, I tried to find a new route for proving the Pythagorean theorem. In the beginning, I organized roughly ten possible directions, but during later duplication checks, derivations, and tests, they failed one after another. Some were only variations of existing proofs, some could not pass strict checks at key steps, and some looked close but never truly closed.

By April 23, I decided to set the first stage aside. That decision was not because the problem was unimportant. It was because continuing in the same way was unlikely to bring a new result. Setting it aside did not mean deleting it. It was more like admitting that one stage of exploration had not produced a usable proof, while keeping the failed paths, judgments, and clues.

The real turn came during a rest.

At that moment, I was no longer forcing the original derivation forward. I had stepped away from the earlier line of thought. In that gap, a new geometric chain suddenly became clearer: perhaps the proof did not need to enter through the previous routes, but could return to the incircle, angle bisectors, excircles, and local similarity. It was not a complete proof yet, but it made me realize that the project was not entirely over. It needed another way in.

Later, I also reconsidered the role of AI in the process.

In the first stage, I had used a relatively strict form of AI assistance: a main agent planned the work, while different subagents explored, checked, or organized separate parts. This kind of structure is useful in engineering tasks, because it makes the steps clearer, keeps boundaries visible, and reduces repeated work.

But in this proof exploration, I gradually found that an overly strict prompt structure could sometimes limit the model’s judgment. It encouraged the model to satisfy the task frame that had already been written, but did not necessarily bring it back to the figure itself. For a problem that required open judgment and a new choice of route, fixing the model too early inside a frame could cause it to miss directions that were less orderly but more valuable.

This does not mean strict prompts are useless. For smaller models, or for engineering tasks with clear boundaries, explicit constraints often improve stability. But when a flagship model is needed for exploration, comparison, and judgment, too much restriction can reduce the space in which it can work. It can also cause existing assumptions in the context to accumulate and affect later answers.

So in the second stage, I adjusted the way I used AI. Instead of asking the model to obey a complete task frame first, I let it understand the new geometric intuition, then participate in deriving, checking, and expressing that direction. In other words, AI was no longer only executing a preset process. It was placed closer to the problem itself.

After that adjustment, the proof exploration moved forward again. In the end, I organized two proof chains that could be read independently: one around the incenter, intercepts, angle bisectors, and local similarity; the other around the incircle, the A-excircle, and the internal homothety center. Both were later organized into Markdown and PDF versions.

Looking back, what mattered was not only that the proof was eventually completed, but that the method itself changed. The failure of the first stage helped me see that not every problem is suited to a highly engineered mode of work. Some mathematical exploration needs to move more slowly. It needs to allow intuition to appear first, then let tools take part in checking and organization.

For me, the judgment left by this experience is that AI can help organize thought and check expression, but it should not too early replace the human choice of direction. Especially in proof writing, the key point is often not to make every step more crowded, but to know where to enter the problem again.