SVG是代码，但Agent仍需看到渲染结果

Coding agents are getting very good at writing SVG. That does not mean they are automatically good at making icons. An SVG can be syntactically valid, structurally clean, and still look wrong when rendered at 24 pixels. A path can be perfectly legal XML and still feel off-center. A stroke can be consistent in code and still look too heavy next to the rest of an icon set. That is because SVG has two representations at once: code the agent can inspect an image the agent needs to judge A reliable workflow needs both. The useful loop is not: prompt → SVG → done Enter fullscreen mode Exit fullscreen mode It is: choose → render → inspect → adjust Enter fullscreen mode Exit fullscreen mode For vector assets, visual feedback is part of correctness. Valid SVG is not the same as a good icon Agents are naturally good at checking things that can be verified from markup. They can inspect: viewBox paths groups fills strokes IDs transforms masks gradients metadata Enter fullscreen mode Exit fullscreen mode They can also enforce system rules such as: grid: 24×24 stroke: 1.5 linecap: round linejoin: round color: currentColor Enter fullscreen mode Exit fullscreen mode Those checks matter. They reduce structural errors and make automated workflows safer. But they do not answer the most important visual question: Does the icon actually look right? Two icons can use the same grid and stroke width while feeling completely different. One may look too heavy. Another may appear too small. A mathematically centered symbol may still look optically off-center. Markup can tell you how the icon is built. It cannot fully tell you how the icon feels when rendered. What only rendering reveals Some problems become visible only after the SVG is turned into pixels. Optical balance A circle, triangle, arrow, and asymmetric symbol occupy space differently. Good icon design often needs optical correction rather than purely geometric alignment. Visual weight The same stroke width does not guarantee the same perceived weight. Dense geometry can look heavier than open geometry. Small-size legibility An icon that looks fine at 128 px may fail at 16 px. Gaps disappear. Details collapse. Thin features lose clarity. Consistency with neighboring icons Icons are rarely judged alone. A new icon needs to fit the set around it: [ search ] [ settings ] [ new icon ] [ user ] [ close ] Enter fullscreen mode Exit fullscreen mode That means comparing occupied area, stroke density, negative space, corner treatment, and visual center. These are visual checks, not XML checks. The missing step: render before you trust A better agent workflow looks like this: 1. Retrieve or create the SVG 2. Inspect the structure 3. Apply the change 4. Render the result 5. Inspect the rendered image 6. Compare it with system rules 7. Adjust if needed 8. Validate the final SVG Enter fullscreen mode Exit fullscreen mode The key difference is simple: rendering is not the final step. Rendering becomes part of the reasoning loop. Instead of asking: Did I produce valid SVG? the agent can ask: Did I produce the right SVG? Render at the sizes that matter For icons, a single preview is usually not enough. A practical check should include common interface sizes: 16 px 20 px 24 px 32 px Enter fullscreen mode Exit fullscreen mode This is where subtle problems become obvious. An agent may discover that: a gap closes at 16 px a detail becomes noisy at 20 px an icon feels heavier than its neighbors the visual center shifts at small sizes This matters especially when the SVG was: generated by AI traced from a raster image converted from another icon set simplified automatically converted from stroke to outline The file can be valid while the geometry still needs work. A practical workflow for SVG icons A production-oriented pipeline can stay simple. 1. Retrieve Start from an existing icon whenever possible. Keep its context: set icon ID source license version Enter fullscreen mode Exit fullscreen mode 2. Inspect Check the SVG structure: viewBox path count stroke model fills IDs groups transforms Enter fullscreen mode Exit fullscreen mode 3. Modify Apply the smallest necessary change. Keep the source flexible. Avoid flattening geometry unless the delivery target requires it. 4. Render Generate previews at the sizes used by the product. 5. Compare Place the result next to icons from the same system. Look for visual drift. 6. Adjust Fix geometry, spacing, or stroke behavior. Then render again. 7. Validate and export Run structural checks one more time, then generate the final asset or framework-specific output. That gives you a clean separation: source SVG → visual validation → delivery output Enter fullscreen mode Exit fullscreen mode Visual feedback is part of correctness For code, we already accept layered validation. A change may need to: compile pass tests pass linting pass type checks Enter fullscreen mode Exit fullscreen mode SVG needs the same mindset. For an icon, correctness might mean: SVG parses ✓ structure is acceptable ✓ system rules are respected ✓ render looks correct ✓ small-size preview works ✓ Enter fullscreen mode Exit fullscreen mode The visual check is not an optional polish step. It is part of validation. That becomes even more important when agents generate or modify assets without constant human supervision. Final thought For SVG, correctness has two layers. The markup has to be valid. The rendered result has to be right. Agents can inspect the first directly. For the second, they need to see. choose → render → inspect → adjust Enter fullscreen mode Exit fullscreen mode That loop is what turns SVG generation into a reliable vector workflow.