Article /

AI Workflow Summary in Practice

A set of AI development workflows I am currently testing and using

UI and code workflows are crowded right now, and many paths still have no settled best practice.

  • Screenshot-based image/video generation, template screenshots plus Figma edits, design screenshots plus antigravity / lovable / figma for code recreation and background video
  • Use prompts to generate wireframes and then hand them off to UI-oriented skills
  • Use prompts plus pencil for design-to-code

Subscriptions across these tools are expensive.

I have not tried everything yet, so there is still no settled best practice. But once productivity goes up, you still need to care about aesthetics. More creators are already putting out landing pages with better visual quality, and visual expectations for landing pages will likely become part of the development workflow. (PS: Many UI designers now use d2c, while programmers are used to generating with prompts. These two perspectives should be combined.)

In real code work, single-model end-to-end generation has many problems, and it only fits low-complexity tasks.

  • prompt keeps expanding, and context pollution gets worse
  • the UI first draft looks complete, but the structural boundaries are unstable
  • one conversation changes too much at once, making deviations hard to locate
  • testing and review easily become superficial

I. Clarify the Requirement

If you generate a high-fidelity interface before the requirement has converged, the result usually looks complete but the implementation loses focus. Component placement, information hierarchy, above-the-fold priorities, and state boundaries will all be reworked later.

Block-level page structure should be determined before the visual draft. Common tools are wiretext and mockdown. After the page structure and interaction are clear, bring in AI UI tools.

  • Pencil: good for quickly generating an editable first draft
  • variant ai: good for finding a style direction first, then exporting .js for Claude Code or Codex to continue cleaning up the structure

The generated result should only be treated as a draft, not as the final implementation. Before development starts, confirm the layout hierarchy, component boundaries, and key states.

II. Split Execution

The development phase is where you can reduce overhead by splitting work.

For medium or higher complexity requirements, first judge whether the task can be split. A baseline method is:

  1. Split the requirement into 2 to 4 relatively independent sub-tasks
  2. Bind each sub-task to its own git worktree and its own session
  3. Merge independently verifiable small increments first, then do cross-module convergence at the end

The direct benefit is isolated context and less serial work, which speeds development. Page structure, form interactions, and test coverage can move forward separately, and problems are easier to locate.

This method also has boundaries. If tasks are too tightly coupled, forcing parallelism only exposes integration cost earlier. When shared state or cross-module coordination is involved, reduce parallelism proactively.

Third-party tools:

  • superset: for parallel worktree orchestration
  • happy: for remotely controlling Claude Code

As Claude's official tools have filled in remote control and worktree support, tools like these are better treated as enhancements around other CLIs.

III. Multi-Model Collaboration

The point of multi-model collaboration is not parallelism by itself, but using each model where it is strongest.

ccg-workflow can act as the orchestration layer: Claude Code handles coordination, frontend tasks route to Gemini first, backend tasks route to Codex first, and the final patch lands after mutual review.

Without a shared standard, multiple models do not create stable gains. They only amplify differences in naming, boundaries, and implementation style.

Common commands:

  • End-to-end: /ccg:workflow
  • By task type: /ccg:frontend, /ccg:backend, /ccg:debug, /ccg:optimize, /ccg:review

When a requirement has many constraints and the goal is easy to drift, use /ccg:spec-* first to define the spec. Only consider /ccg:team-* parallel multi-task execution when a simple task can be split into more than three independent modules.

IV. Testing and Review

I have only tried a few tools lightly for testing:

  1. apifox + skill testing: if Apifox was not used during development, I would not recommend using an Apifox skill for the final test pass
  2. midscene testing: when I tried it before there was no automated testing mode; now there is one, but I have not tried it yet, so judgment reserved

After the main flow is done, I use prompts to do acceptance testing. I still recommend continuously writing unit tests during development instead. When a functional block is complete, run multi-model, multi-round review and fixes, focusing on four things:

  1. potential bugs and boundary problems
  2. maintainability
  3. robustness
  4. alignment with the intended design patterns

If this is a large project, I recommend using /ccg-review and /ccg-debug to fix bugs.

After AI review, there still needs to be human review, mainly to confirm:

  1. the requirement is actually satisfied
  2. naming, styling, and coding conventions match team standards (or write them into a team skill during planning and enforce them later through linting)

AI can also be used for CI/CD, PRs, and issues:

V. Minimum Reusable Flow

Compress the method above to the smallest end-to-end flow:

  1. Use wireframe tools to lock the page structure and information hierarchy first, then use UI generation tools to get an editable first draft
  2. Prioritize the MVP in development, and push simple tasks forward through worktree-based independent subtasks
  3. For complex requirements, use /ccg:plan or /ccg:spec-* first to lock constraints, then start implementation
  4. Before merging, do unified multi-model multi-round review, testing, and manual checks, then do stabilization refactoring at the end