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 to AI to implement step by step. To help it perform better, I also 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 the result, the tool worked. But it was also a flawed 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 had asked 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 continuously trimmed. Most of the things I initially thought "should be there" were removed one by one, leaving only the core parts. Breaking things apart and reconstructing them felt more like playing a game of equipment matching. First, assemble a roughly usable form, then examine this construct from different angles, and later adjust local implementations or even completely start over. Many of my decisions happened only "after seeing the results." So, this development process wasn't linear but constantly looped back.
My working method started from a relatively chaotic result. "Bidding information collection" wasn't a completely defined goal because I had never worked in this business area before and had no historical baggage. There was no fixed path for how to collect, filter, or design the interaction experience. More often, I just had a general direction, then first created a usable form and continuously adjusted it based on the results. During this process, the goal itself drifted. I might have initially wanted to do A, but after seeing intermediate results, I gradually adjusted it to A', or even something 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 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 progress 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 predictable, and the process is a verifiable closed loop. For me, step-by-step instead became a constraint. I was forced to make local decisions before seeing the whole picture, and these decisions were quickly overturned by myself.
This difference became even more apparent in the final stages of development. During that time, I spent a lot of energy on interaction and visual details. For example, shifting a component 3 pixels to the right or limiting the minimum scaling width of an element. Individually, these changes seemed almost meaningless, but when combined, 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 3 pixels. More often, it's just because I looked at it, felt something was off, and then repeatedly fine-tuned it 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 perfection.
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. It serves 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 issue isn't with skills, but rather whether I want to "get things done" or "get things done well."