Recently, I helped a friend create an automated tool for gathering bidding leads. Initially, I followed what seemed like a "standard process." I wrote requirement documents, interaction specifications, and then handed them over to the AI to implement step by step. To help it perform better, I even searched for and installed a bunch of seemingly great skills. Quickly, it produced a fully functional version that could generate keywords, scrape information, and perform matching evaluations. From a results perspective, the tool was viable. But it was also a shoddy product that made my eyes burn—bloated, cumbersome, inexplicably complex, and very difficult to use.
Each layer of its logic was reasonable, but when stacked together, the experience deteriorated. You could clearly see rules and processes constantly being added, but these things didn't make the product better. At that point, I realized the problem lay in the division of labor between me and the AI—it was an issue with my working mindset. I was asking the AI to help me build a tool, but I was still using old-fashioned methods. So, I started doing the opposite. I stopped obsessing over defining the process clearly and deleted the documents in the project's root directory. I directly presented my core requirements to the AI, asking it to propose implementation plans and execute them. Features were also constantly being trimmed. Most of the things I initially thought "should be there" were deleted one by one, leaving only the core parts. Breaking things apart and rebuilding them, the whole process felt more like playing a gear-matching game. First, assemble a roughly usable form, then examine this construct from different angles, go back to adjust local implementations, or even scrap and rebuild the whole thing. Many of my decisions happened only "after seeing the results." Therefore, this development process wasn't linear; it was constantly looping back.
My working method started from a relatively chaotic outcome. "Bidding information collection" wasn't a completely fixed goal because I had never worked in this business area before and had no historical baggage. So, how to collect, how to filter, and the interactive experience had no predetermined path. More often, I just had a general direction, then first created a usable form, and continuously adjusted based on the results. In this process, the goal itself would drift. I might start wanting to do A, but after seeing intermediate results, I would gradually revise it to A', or even turn it into a completely different B. This repeated backtracking 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 then adjusting the 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 make the model proceed in a step-by-step manner. It relies on clear inputs, stable steps, and explicit intermediate validation, breaking down a process into reusable modules. When the problem has converged and the process is stable, this method is very efficient. But its implicit premise is that the goal is determined, the path is foreseeable, and the process is a verifiable closed loop. For me, step-by-step would instead become a constraint. I would be forced to make local decisions before seeing the whole picture, and these decisions would soon be overturned by myself.
This difference became even more apparent in the final stages of development.
During that period, I spent a lot of energy on interaction and visual details.
For example, shifting a component 3px to the right, or limiting the minimum scaling width of an element. Individually, these changes seemed almost meaningless, but stacked together, they directly affected the overall user experience.
This kind of work is difficult to "skillify."
It has no clear trigger conditions and no standard answers. It's hard for me to write a rule specifying when something should be moved 3px. More often, it's just because I took a look, 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 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 a high standard.
Looking back at the entire process, skills are more suitable for a type of problem that has already been formalized. The process is stable, inputs and outputs are clear, and it can be broken down into standard steps for repeated reuse. They serve a production method close to an assembly line.
What I was doing at the time, however, was constantly probing, adjusting, and even redefining the process itself.
This is a state closer to exploration.
In this state, I don't need to ensure that every step of the process can be clearly broken down, nor that every step hits the correct node. What I need is to gradually approach a better answer by continuously generating results.
So the problem isn't with skills, but rather whether I want to "finish" the task or "do it well."