企业官网建设流程全解析

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.js（App 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加载的图片设置crossOrigin="anonymous"，同时尽量引导用户用本地上传，把图片转成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和常用图标统一管理起来。到时候等新坑踩得差不多了，再开一篇接着写。