AI 製作的作品集仍有一個問題：作者必須解釋作品背後的決策

The portfolio has animations. The repository has a README. The deployment works.

Then someone asks: “Which decision in this project was yours?”

“I built it with React” does not answer that question. Neither does a list of tools or a paragraph about a seamless user experience.

A polished site can help people inspect your work. It cannot supply the reasoning behind work you have not thought through.

Try this before adding another project

Open one project you actually understand. Explain a single decision without naming the framework first.

Use four prompts:

1. What behaviour needed to change?
2. What options did you have?
3. Why did you choose this one?
4. What can another person inspect to check your explanation?

Treat this as a preparation exercise, not a claim about what every employer asks. If you cannot answer yet, investigate the project before rewriting the portfolio copy.

Replace a claim with a small, inspectable case

Here is a fictional example, not a project result from my work.

Thin version: “Built a responsive product catalogue with advanced filtering.”

Useful version: “The selected filters disappeared when someone shared the catalogue URL. I put the shareable filter state in URL parameters, kept temporary input outside that state, and defined defaults for missing parameters. The check was to select filters, copy the URL into a fresh tab, and compare the visible selection and results.”

That version gives a reader something to question. Why separate temporary input? What happens with an invalid parameter? Does the browser's Back button restore the previous state?

Those questions reveal understanding more effectively than another adjective about the interface.

Include the tradeoff you did not hide

In the fictional example, putting state in the URL makes it shareable, but it also makes the chosen representation visible and persistent in browser history. You still have to decide what belongs there.

Write down an alternative you considered and a reason for rejecting it. The reason should come from a constraint in your project, not a generic claim that one approach is always better.

If you did not measure conversion, do not invent an improvement percentage. A reproducible behaviour check is already evidence of something specific. It just proves less than a controlled business experiment.

If a coding tool helped, explain what you checked

You can describe a suggested implementation you accepted, a change you rejected and the check that informed the decision. Keep the account accurate. Do not replace missing reasoning with a made-up story about ownership.

For team projects, separate your contribution from the team's result. For confidential work, use only material you can share; a public portfolio does not need customer data to explain a technical choice.

A stronger next step than another redesign

Take your weakest case and remove every sentence that could describe a hundred other projects. Add the constraint, your decision and one inspectable result.

Then ask a reader what they would question. If their questions are about the engineering rather than what the project even does, the case is becoming easier to discuss.

I'm Daniil. I write about frontend decisions, practical developer tools and explaining engineering work. Follow for more concrete examples.

What is the hardest part of your portfolio to explain without opening the code?