Recently, I helped a friend build an automated bidding lead collection tool. At first, I followed almost a "standard process": writing requirement documents, interaction descriptions, and then handing them over to AI to implement step by step. To help it perform better, I even searched for and installed a bunch of seemingly impressive skills. Soon, it produced a fully functional version that could generate keywords, scrape information, and perform matching evaluations.
From the results, this tool worked.
But at the same time, it was a flawed product that made me furious—bloated, cumbersome, unnecessarily complex, and hard to use.
Each layer of logic was reasonable on its own, but when stacked together, the experience deteriorated. You could clearly see rules and processes piling up, yet none of this made the product better.
At that point, I realized the issue lay in my division of labor with the AI—it was a problem with my own work mindset. I had the AI help me build a tool, but I was still using methods from an older era.
So later, I flipped the approach. I stopped obsessing over defining the process clearly and deleted the documents in the project root directory. I directly threw my core requirements at the AI, letting it come up with implementation plans and execute them.
Features were continuously trimmed. Most of the things I initially thought "should be there" were deleted one by one, leaving only the core parts.
I broke things apart and restructured them. The whole process felt more like equipping gear in a game.
First, I pieced together a roughly usable form, then examined this construct from different angles, and went back to adjust local implementations—or even completely overhauled it. Many of my decisions only happened "after seeing the results."
So this development process wasn't linear; it was full of back-and-forth.
My way of working started from a relatively chaotic outcome. "Bidding information collection" wasn't a fully defined goal because I had no prior experience in this area and no historical baggage. So how to collect, how to filter, and the interaction experience all had no clear path. More often than not, I just had a rough direction, made a usable form first, and then continuously adjusted based on the results.
In this process, the goal itself drifted.
I might have initially wanted to do A, but after seeing intermediate results, I gradually revised it to A', or even a completely different B. This back-and-forth was part of the process, meant to accommodate the uncertainty of the specific goal.
I didn't need to define the problem clearly from the start, nor did I need to ensure every step was "correct." Instead, by continuously generating results, observing them, and adjusting direction, I gradually approached a more reasonable form.
It was also during this process that I began to realize the boundaries of skills.
The core of a skill is to have the model advance step by step. It relies on clear input, stable steps, and explicit intermediate verification, breaking a process into reusable modules. When the problem has converged and the process is stable, this approach is highly efficient.
But its implicit premise is that the goal is determined, the path is predictable, and the process is a verifiable closed loop.
For me, step by step became a constraint instead. I was forced to make local decisions before seeing the big picture, and those decisions were soon overturned by myself.
This difference became more apparent in the final stages of development.
During that time, I spent a lot of effort on interaction and visual details.
For example, moving a component 3px to the right, or limiting the minimum zoom width of a certain element. These changes seemed meaningless individually, but when stacked together, they directly affected the overall user experience.
This kind of work is hard to "skillify."
It has no clear trigger conditions or standard answers. It's difficult to write a rule explaining when to move something 3px. More often than not, I just looked at it, felt something was off, and then repeatedly fine-tuned until it looked right.
These adjustments were about making judgments, not executing tasks.
Skills can complete implementations under clear constraints, but they struggle to participate in this kind of fine-tuning process without clear boundaries. They can ensure structural correctness but find it hard to polish the experience to perfection.
Looking back at the whole process, skills are better suited for problems that have already been standardized. The process is stable, input and output are clear, and it can be broken down into standard steps for repeated reuse. It serves a production method close to an assembly line.
What I was doing, however, was constantly exploring, adjusting, and even redefining the process itself.
This is a state closer to exploration.
In this state, I don't need to ensure every step can be clearly broken down, nor do I need every step to hit the right node. What I need is to continuously generate results and gradually approach a better answer.
So the issue isn't with skills, but whether I want to "get things done" or "do things well."