1. 项目背景与2.0版本升级思路这个项目最开始源于一个特别具体的痛点电商运营部门每天要产出一大批营销图文商品主图、促销海报、社群分享图、朋友圈素材图完了还得配文案文案要贴合卖点图要好看又不能太模板化。我们这边运营同事每天都在重复劳动做一张图最快也要十几分钟遇到活动大促几十个商品一起改版基本就是通宵的节奏。所以去年年初我就冒出一个想法能不能做个工具输入商品基本信息自动输出一套可用的营销图文素材。当时我用最快的方式做了一个原型1.0但那个版本说实话非常简陋。页面把所有逻辑都写死了表单提交后更新一张固定Canvas想改一个字段就要改一段代码想加一个新模板就要复制一整个页面。1.0充其量只是验证了这个方向走得通离运营同事愿意用差了十万八千里。后来大概是今年二月我开始认真尝试用AI编程工具参与开发把整个项目从零重写了一遍这才有了现在的原型2.0。这篇文章就是记录我在这个重构过程中的完整心路历程AI怎么辅助我搭建这个图文生成工具哪些环节AI确实能大幅提效哪些环节AI反而帮倒忙以及我踩过哪些坑。这个2.0版本的定位很明确让运营同事直接通过页面上传商品图片、选择模板、填写卖点文案然后一键生成多尺寸的营销图同时自动配上一段营销文案整个流程控制在两分钟以内。说白了它要解决三个问题一是模板复用不再每次做图都从零开始二是批量生产一次导入几十个商品信息就能批量出图三是图文一体图片和文案一次生成省掉运营在PS和Word之间反复切换的时间。我之所以决定用AI辅助编程来做这次重构原因是经过1.0阶段后我看明白了一件事这类内部工具项目需求变化极快、生命周期不确定、最终形态经常变它不需要多么高深复杂的系统设计但要求你能够快速迭代。而AI编程工具恰好最擅长处理这种技术栈普通、但工作繁琐、改起来频繁的代码。不过这里要提前说清楚AI辅助编程不是输入一句帮我做个电商图文工具就能原地起飞它更像一把趁手的工具用好了效率翻倍用不好也是真的能把你的项目改成一团乱麻。这套方法论我会在后面的章节里全部讲透。1.1 为什么要在原型阶段就引入AI辅助编程很多人第一时间会怀疑原型代码又不会上生产手写就好了引入AI是不是有点小题大做我的看法恰好相反。原型阶段恰恰是AI辅助编程价值最大的阶段因为原型项目最大的特征是需求边界随时在变。今天运营说要加一个模板样式明天产品说要换导出尺寸后天老板看了演示觉得字体太挤要重新设计。这些改动如果全部靠手写大量时间都消耗在改面板、调样式、移动元素坐标这类低价值操作上。我在2.0开发过程中最深的一个体会是AI辅助编程真正厉害的地方不在于能写出很长的代码而在于能根据你的一句话快速修改现有代码。比如我最初用React写模板选择区时缩略图默认用直角卡片后来运营反馈说要改成圆角带阴影我只把这个需求描述给AI它立刻就能定位到相关组件并改好样式整个过程不到一分钟。这在传统开发流程里哪怕代码再简单也要经过定位文件-定位组件-修改样式-刷新验证这几个步骤一两个来回消耗的时间和精力其实不小。但这里有个前提条件必须明确你依然需要具备基本的代码理解能力否则AI改坏了东西你根本发现不了排查起来比你自己写还要痛苦得多。我自己就经历过一次AI在重构模板渲染逻辑时偷偷把预览区的商品图裁切方式改了我直到导出图片时才发现比例不对回溯diff才找到原因。所以我的结论是AI辅助编程适合那些能看懂代码、会拆解需求、但想省掉重复劳动的开发者不适合完全不懂编程、指望AI魔法式产出成品的人。1.2 2.0相对1.0的核心变化我把2.0定义为从能跑变成能用的一次升级。具体拆解开有四个维度的变化。第一模板化。1.0时代每张海报的逻辑都直接写在页面里代码里到处是写死的坐标和颜色值新增一个样式就复制一个页面来改项目越滚越大。2.0把模板抽象成一份标准数据结构每个模板包含背景尺寸、背景色、商品图占位框、标题样式、价格标签位置、卖点文案区域等字段。UI预览读取这份配置来渲染Canvas导出也读取同一份配置来绘制模板和数据彻底分离新增模板只需要在配置里加一个JSON对象完全不需要新增页面。第二批量处理。运营同事一出手就是二三十个商品逐个填写表单再导出显然是灾难。2.0支持从Excel导入商品列表选中模板后一键批量渲染渲染完成后统一打包下载。这一步让工具从玩具变成了生产力实际使用体验完全不同。第三AI文案生成。光有图不行电商图文讲究图配文。运营同事最头疼的其实是文案每张海报配几句卖点文案说法又不能千篇一律。我在2.0里接入了大模型接口用户输入商品名称、核心卖点系统自动生成三套不同风格的营销文案供选择风格包括功能型、情感型、促销型运营可以在这个基础上微调省去从零组织语言的精力。第四多尺寸适配。1.0只能输出一种固定尺寸。但实际场景里商品主图、详情页头部、社群分享图、公众号头图尺寸各不相同。2.0支持切换不同场景的尺寸预设预览区实时刷新导出的图片也随之更换。这个功能在1.0时代是不可想象的因为当时所有绘制逻辑都写死在代码里而2.0把尺寸也纳入了模板配置的一部分。技术上这些变化没有一个算高难度但组合起来工作量很大。如果不是AI辅助编程我很难在一个周末的时间里把这么多功能全部整合完。更重要的是AI不仅帮我写代码还帮我理清了原有的冗余结构很多重构操作不需要我自己逐行处理。1.3 工具选型AI编程到底该用哪一套为了找到最适合原型开发的AI编程方式我前后试过三个流派IDE内置的AI自动补全插件、网页版聊天生成代码、以及Agent式自主编程工具。三者的定位和体验差异极大我直接说结论。如果你的情况是我知道怎么写但记不清某个API的参数或者想快速补全IDE内置插件最实用。我在写Canvas操作这种细节代码时经常靠它提示方法签名相当于一个长了眼睛的智能手册。但它的能力局限在行内补全做不了跨文件的大规模调整。如果你有一个非常明确的小需求比如写一个数组去重函数写一个下载图片的工具方法Chat式对话生成代码很好用生成完复制回项目里就行。但它的缺点是手工复制粘贴来回切换如果项目一复杂你要把AI生成的多段代码正确放到对应目录很容易丢三落四。Agent式自主编程是这次2.0里我使用的主力方式。它能读取项目里的多个文件根据你的指令修改代码、新建文件、执行命令比如把模板渲染逻辑统一改成从配置读取它会自动定位相关文件并完成修改。缺点也有它有时候会自作主张改一些你没让它动的地方所以你必须给它划定一个明确的改动边界并且在每次改动后审查diff。这里我想重点强调一个我个人的习惯每让Agent完成一个功能必须人工检查一次改动范围和结果确认没有改坏已有功能再去干别的。这个习惯在2.0的开发过程中至少帮我避免了三次严重的代码覆盖问题其中一次是AI在重构预览区时顺手把本地存储的键名改了导致历史保存的模板数据全部读不出来。如果没检查diff这个问题要等运营实际使用时才会暴露。2. 系统架构设计与图文生成的核心原理2.1 前端技术选型原型最重要的任务是跑通闭环做原型时最怕在技术选型上过度纠结。这个项目我选了Next.js加React加TailwindCSS组合不是因为Next.js能做SSR还是什么全栈框架而是因为它目录结构清晰、组件化做得顺手、开发环境热更新稳定能让我快速把页面路由和API路由搭起来。你可以换成Vite或者干脆用手写HTML这些都不重要重要的是尽快把数据输入-模板渲染-图片导出这个核心闭环跑通而不是把一整天时间花在工程配置上。原型阶段我强烈建议把数据处理、模板渲染、图片合成、导出下载这四件事全部放在前端完成。原因非常现实原型阶段你大概率没有运维资源也不应该为后端接口联调浪费时间。一个纯前端项目做完直接部署到静态托管服务就能给同事演示后续确认方向后你再补充后端也不迟。像这个项目唯一需要外部服务的就是AI文案生成接口而这个也用简单的API路由转发一下就行数据都通过前端处理。另外一个很重要的原则是先闭环后完善。我见过很多人做原型时一上来就追求UI好看把时间浪费在配色、圆角、阴影这类细节上结果主流程还没走通。我做2.0的顺序是先把上传商品图-填写信息-预览-导出这个主链路用几个最丑的按钮打通确认逻辑正确后再逐个美化。这个顺序能保证你永远有一个可以演示的版本而不是等到deadline才发现流程根本跑不通。2.2 图文生成的核心流程拆解不管界面怎么设计这个工具本质上就是三个步骤。第一步收集数据把商品名称、价格、卖点、品牌这些字段收进来可以表单录入也可以Excel导入。第二步套模板把数据填充到模板对应的位置同时计算文本是否溢出、图片如何裁剪适配。第三步渲染并导出把模板绘制到Canvas上按预设尺寸导出PNG或JPEG图片配合营销文案一起打包下载。这三步听起来简单但每一步都有不少细节坑。先说数据层商品信息字段必须统一规范比如价格区分为现价和原价卖点字段支持多行输入图片字段要支持本地文件和URL两种来源。如果数据结构定义不清楚后面模板渲染和Canvas绘制都会跟着出问题。再说模板层这是整个工具的灵魂。我定义了一套标准的数据结构来管理模板每个模板包含画布宽度、高度、背景色、背景图、商品图位置、标题样式、价格标签位置、卖点区域位置等。为了让大家有个直观感受我贴一个精简版的示例。export interface TemplateConfig { id: string; name: string; scenario: mainImage | detailHeader | shareCard; canvas: { width: number; height: number; background: string; backgroundImage?: string; }; productImage: { x: number; y: number; width: number; height: number; borderRadius?: number; }; title: { x: number; y: number; width: number; fontSize: number; color: string; fontWeight: normal | bold; align: left | center | right; }; price: { x: number; y: number; fontSize: number; color: string; }; sellingPoints: { x: number; y: number; width: number; lineHeight: number; fontSize: number; color: string; }; } export interface ProductData { name: string; price: string; originalPrice: string; brand: string; sellingPoints: string[]; imageUrl: string; }这套结构的好处是UI层预览和Canvas导出都基于同一份配置对象计算。预览组件根据TemplateConfig生成DOM布局绘制组件根据同一份TemplateConfig在Canvas上绘制确保用户看到的预览效果和最终导出的图片完全一致。这也是我在1.0踩过大坑后总结出的经验当时预览和导出各写一套逻辑经常出现屏幕里看着居中了导出的图却偏了的尴尬情况。2.3 Canvas渲染从能画出来到画得专业Canvas做图文合成是前端最直接的方案但对细节要求很高。我梳理了三个最容易出问题的环节文本换行、图片适配、字体加载。文本换行是第一个坑。Canvas的fillText方法不会自动换行如果商品标题比较长直接画上去就会超出画布边界。你需要自己实现换行逻辑核心思路是用measureText逐字测量文本宽度超过指定宽度就插入换行符。我贴一下核心代码这段代码在AI辅助编程里实际运行得比较稳定。function wrapText(ctx, text, maxWidth) { const chars text.split(); const lines []; let currentLine ; for (const char of chars) { const testLine currentLine char; const metrics ctx.measureText(testLine); if (metrics.width maxWidth currentLine ! ) { lines.push(currentLine); currentLine char; } else { currentLine testLine; } } lines.push(currentLine); return lines; }图片适配是第二个坑。商品图的比例和模板预留位置几乎不可能完全一样如果直接drawImage拉伸图片会变形海报瞬间显得很业余。我写了一个cover模式的适配函数思路和CSS的background-size: cover一致先计算目标区域宽高比从原图居中截取一个匹配比例的区域再绘制到画布上。不管原图是横图、竖图还是正方形最后都能无损裁剪适配。function drawImageCover(ctx, img, target) { const targetRatio target.width / target.height; const imageRatio img.width / img.height; let sourceX 0, sourceY 0, sourceWidth img.width, sourceHeight img.height; if (imageRatio targetRatio) { sourceWidth img.height * targetRatio; sourceX (img.width - sourceWidth) / 2; } else { sourceHeight img.width / targetRatio; sourceY (img.height - sourceHeight) / 2; } ctx.drawImage( img, sourceX, sourceY, sourceWidth, sourceHeight, target.x, target.y, target.width, target.height ); }字体加载是第三个坑这个我放到后面常见问题部分详细讲因为它在Canvas合成中实在太容易踩了。这三个环节恰恰也是AI最容易出错的地方AI生成的绘制代码通常只会给你最简单的drawImage加fillText完全不会考虑图片比例、文本溢出、字体加载这些业务细节。你需要自己把这些约束补充到系统里。3. AI辅助编程实操从提示词到可运行代码3.1 第一个里程碑用一段提示词让AI生成完整页面骨架2.0重构启动后我做的第一件事是让AI生成一个完整的页面骨架。这些需求在我脑子里是非常清晰的但想要转化为可靠的代码需要写出一段好的提示词。我总结的经验是要把技术栈、页面布局、关键模块、组件职责边界都写清楚越具体越好尤其要给出关键的交互流程而不是让AI自由发挥。下面是我实际使用过的一个提示词模板效果很不错生成后的页面结构完整、数据流也打通了。请帮我用 Next.jsApp Router TypeScript TailwindCSS搭建一个电商图文生成工具的原型页面。 页面需要包括 1. 左侧是一个模板选择区展示模板缩略图列表点击可以切换当前选中模板。 2. 中间是预览区展示当前模板与当前商品数据绑定后的渲染效果。 3. 右侧是商品信息表单字段包括商品名称、价格、原价、品牌、卖点支持多行输入、商品图片上传。 4. 底部有一个导出PNG按钮点击后把预览内容导出为PNG图片。 5. 模板先用一个 mock JSON 数组管理后续会扩展。 页面整体风格简洁不需要过度设计重点是把功能闭环跑通。AI生成的初始版本超出我预期页面布局合理、表单和预览区的基础数据流是通的。但注意它生成的代码里隐藏了很多想当然的地方比如预览区和导出功能是两套独立的系统。预览区是DOM渲染出来的导出却是拿Canvas临时画的两边逻辑完全不共用数据。这个矛盾在原型阶段不明显一旦开始扩展模板问题就会集中爆发。所以我下一步做的就是让AI完成模板抽象这个关键重构。3.2 让AI完成模板抽象这一关键重构页面骨架跑通之后我做的第一件关键重构是把模板从写死的组件中抽离出来。原始代码里每个模板都是一个独立的组件重复代码非常多我想把它改造成配置驱动的模式。这个重构任务如果是我手动做至少要花一个晚上反复调整但交给AI后整个过程快了很多。我把之前的mock JSON升级为完整的TemplateConfig类型定义然后给AI下达重构指令。这里我学会了一个特别有效的提示词技巧不要急着让AI写最终代码先让它输出实现计划你确认后再让它动手。具体提示词长这样我计划把模板渲染逻辑从写死的组件改为配置驱动。现有的 TemplateConfig 结构已经定义好 请参考这个结构在不改变页面现有功能的前提下重构预览区和导出区让两者都基于配置对象渲染。 先告诉我你计划修改哪些文件、改动逻辑是什么确认后再开始实现。这个技巧极大减少了AI自作主张的情况。因为Agent式工具在接到一个大型重构任务时往往倾向于一次性把所有文件改完有些改动可能与你的预期不符。让AI先列计划你就获得了一个检查点可以在它动手前就发现问题也能顺便判断它是否理解了需求。这个习惯在后续开发中反复被验证极其管用。3.3 Canvas图片合成AI最需要被约束的部分Canvas图片合成是这几个环节里AI最需要被人盯着的部分。AI生成的第一版Canvas绘制逻辑就是一个简单的从左到右画文本的循环商品标题长了直接溢出画布。我的解决办法是补充一段自动换行逻辑并用明确的提示词让AI按这个逻辑重新绘制。我还让AI按照我给的drawImageCover函数统一处理商品图的适配。这两个约束加进去之后AI生成的绘制代码质量一下子提升了几个档次。但这也从侧面说明了一个问题AI的能力上限很大程度上取决于你给它描述业务约束的详细程度。你不告诉它商品图可能变形它就真的会直接拉伸因为从它的角度看拉伸似乎也没什么不对。所以我在做这个项目时养成了一个习惯凡是涉及业务规则的地方我都先自己把规则想清楚写成要点再连同代码要求一起交给AI。这也让我的AI辅助编程风格变得越来越像带着一个效率极高但缺乏常识的初级工程师你需要把常识和业务判断都明确告诉它它才能好好发挥。3.4 批量生成与下载队列、性能与细节批量生成是整个2.0里对运营体验影响最大的一个功能。逻辑本身不复杂核心是一个异步任务队列逐个渲染、逐个导出、最后打包为ZIP下载。真正值得记录的是性能细节。单个Canvas渲染对浏览器来说不算什么但连续渲染50个、80个的时候如果同步执行浏览器会直接卡死页面僵在那里像崩溃了一样。我的做法是分批渲染每批处理三五个任务后让出主线程配合一个简单的进度条这样虽然整体速度慢一些但页面始终是响应的。运营同事看到进度条在走心态会好很多。然后是文件命名。ZIP包里的文件命名必须包含商品名和尺寸比如华为手机-主图-800x800.png否则用户下载后很难对应。这个细节是运营试用后反馈才加的之前文件名是纯数字编号大家都分不清哪个是哪个。这个批量模块的实现过程中AI辅助编程发挥得非常出色。它很快生成了队列、进度条、ZIP打包的完整逻辑前提是我事先把分批渲染防止卡死文件命名规则顺序必须和Excel行一致这几个关键约束写进了提示词。如果这些约束不提前说明AI大概率会给你一个同步for循环加数字文件名功能看起来没问题实际用起来就是一场灾难。4. 踩坑实录与排查技巧4.1 AI生成代码不可用的四个自查方向做这个项目的过程中AI生成的代码出现过各种各样的问题但总结下来基本都可以归入四个大类。第一类是环境不匹配。AI经常写出依赖某个新版本库的代码或者默认某个依赖已经安装实际项目里却不存在。我的对策很简单在提示词里直接写明项目使用Next.js 14、TypeScript 5.x、TailwindCSS 3.x强制文件生成时对齐环境版本。第二类是API拼写错误或参数过时。比如AI生成代码时引用的某个Canvas属性可能与浏览器实际支持的语义不同这种问题只能靠浏览器控制台报错来定位没有更快的捷径。第三类是逻辑过于理想化没处理真实业务。最典型的例子就是我反复提到的文本换行和图片cover裁剪。AI生成的代码往往默认你传入的字符串很短、图片比例刚好合适这在真实运营数据面前几乎不成立。第四类是AI编造了一个看起来非常合理、但实际并不存在的API。这一点我觉得最值得警惕因为它不像拼写错误那样容易发现。我遇到过AI写了一个util.formatPrice函数但实际上项目里根本没有这个工具函数AI只是觉得这里应该有个格式化价格的函数然后顺手编了一个。遇到这种情况只能依赖经验和对项目的熟悉程度去发现所以在让AI生成代码之后花几分钟扫一眼它的引用关系非常必要。4.2 上下文漂移问题AI辅助编程隐藏的陷阱用Agent式工具做项目时间一久会遇到一个特别隐蔽的问题我称之为上下文漂移。简单说AI对话的上下文窗口是有限的当你项目里的文件越来越多、对话内容越来越长AI对项目的记忆会逐渐模糊甚至开始按照它的合理想象补充一些不存在的组件或函数。最典型的一次经历是AI在重构某个模块时引用了另一个其实已经被删除的旧组件还一本正经地在改动说明里写着保持与旧组件一致。我在检查diff时看到这个才意识到它已经完全丢失了项目当前的真实状态开始根据之前的对话记忆自行脑补文件结构了。我的应对策略有三个。第一保持每个对话的粒度小而清晰一个对话只做一个功能完成后就开新对话别在一个对话里塞超过三个任务。第二每次开新对话时我会把项目当前的目录结构和关键文件路径重新描述一遍必要时直接粘贴相关文件的代码完全不给AI靠猜的机会。第三重要的改动文件我会强制AI在修改前输出一个改动说明我确认改动范围之后才让它动手。4.3 图文生成原型项目独有的经典三坑字体、跨域、缓存这三个坑在普通Web项目里很少遇到但凡是做图文生成类工具几乎躲不掉。先说字体问题。运营做电商图很喜欢用有设计感的字体但Canvas绘制时并不是你页面上用了这个字体画到Canvas里就自动生效。你需要先用FontFace在浏览器中加载字体确认加载完成后才能执行Canvas绘制。否则你会发现导出的图片上字体悄悄变成了默认字体海报的质感立刻垮掉。我的做法是页面初始化时预加载所有模板可能用到的字体并通过document.fonts.load确保加载完成再开始绘制。别人分享的排查方法是这样的在Canvas绘制前先执行一遍字体加载并等待Promise返回同时给每个Canvas绘制入口设置好等待逻辑。代码上加一个waitForFonts函数这个函数做三件事加载字体、刷新字体状态、返回Promise。零散字体如果从外部CDN加载还会涉及CORS问题也要一起处理。再说跨域问题。用户上传的商品图片如果来自某个图床可能因为CORS策略不同导致Canvas被污染一旦Canvas被污染toDataURL会直接抛错导出图片就废了。我的处理方式是给所有通过URL加载的图片设置crossOriginanonymous同时尽量引导用户用本地上传把图片转成base64再绘制从根源上绕开跨域问题。最后是缓存问题。开发迭代阶段模板配置和字体文件如果被浏览器缓存了修改之后刷新界面不生效很容易让人误判成代码没改对浪费大量排查时间。我的对策是在开发环境给静态资源URL加版本号参数或者直接在控制台禁用缓存。这个坑看起来不起眼但确实浪费了我至少半天时间。4.4 给AI喂代码的正确姿势最后分享一个特别实际的经验怎么把你的现有代码喂给AI。很多人用AI编程工具时最大的困境是想让AI改代码但它完全理解不了你的现有逻辑。这时候问题往往出在上下文不足你给的代码信息太少AI只能靠猜。我用的几个办法可以供大家参考。第一对于需要修改的文件直接粘贴完整文件内容或关键函数不要只给一句描述AI看不完你的代码就一定会凭经验脑补。第二如果希望AI参照某个现有组件的风格写新组件把原组件代码一起贴上来并说明请保持现有组件的命名风格和接口设计。第三给AI指定明确的输入输出接口让它按接口编写而不是自由发挥比如要求它按照TemplateConfig结构实现模板渲染函数。第四生成结果不符合预期时千万别反复用模糊措辞让它乱试例如还是不行再改改这类反馈毫无信息量。正确的做法是缩小范围精准指出具体函数和具体行为问题比如模板A的标题区域文字溢出时预期是自动缩小字号而不是换行。越精准的反馈AI的修改就越快越准。这些习惯看起来琐碎但实际项目的协作效率差距很大程度就体现在这些细节里。我见过不少人抱怨AI编程工具不靠谱其实很多时候是用法出了问题不是工具本身不行。5. 一点个人体会这个项目做到2.0版本之后我最大的一个感受是AI辅助编程真正颠覆的不是写代码这个动作本身而是整个开发工作的节奏和注意力分配。你不再需要花大量时间敲那些你早就知道怎么写的样板代码而是可以把精力全部集中在这个工具到底该怎么设计才更好用这件事上。它省下来的是一个个具体的编码时间但它逼出来的是你对需求的更深理解和对业务细节的更强把控。你如果不清楚某个模板的价格标签放在哪里最合适AI帮不了你你如果不清楚商品图的裁切规则AI也帮不了你。AI能做的是你想明白之后用最快的速度把它实现出来。所以这个项目下来我反而觉得自己的产品设计能力有了一次不小的锻炼。如果你也想尝试用AI辅助自己完成一个类似的原型项目我建议你先别追求一次生成一个完美的大页面而是先从最小的闭环开始一步一步让AI帮你补全。每完成一个功能立刻运行验证跑通一个再往下走。只要功能闭环是通的后面的优化和扩展AI都会帮你加速。另外不要迷信给AI一个宏大需求它就能回你一个完整产品这种说法。真正好用的提示词往往比较短但有明确的约束和完整的上下文。你越是能把一个需求描述得边界清晰AI的输出就越接近你想要的。这一点我是真正做完这个项目之后才彻底体会到的。2.0版本现在已经在内部试用阶段运营同事给的最多反馈是希望模板再多一点字体选择再丰富一些。所以下一步我可能会继续做3.0加入一个可视化模板编辑器让运营自己可以拖拽调整模板也可能接入团队素材库把品牌logo和常用图标统一管理起来。到时候等新坑踩得差不多了再开一篇接着写。