工程2026年10月

写代码之前先对齐的三件事

在职做设计，碰到 AI Coding，真正卡住的很少是「哪个按钮能生成页面」。更常缺的是三件事先对齐：这件事目前能交付到什么程度，时间该押在哪一类工具上，以及哪些需求值得自己走进代码仓库。

下面按这个顺序写。例子里有公开项目，也有美团内部的实践。内部链接需要登录才能打开。

已经做出来的那些东西

2024 年 8 月，一个 8 岁的孩子用口语在 Cursor 里花了大约半小时，做出一个哈利·波特聊天机器人。同类故事随后变密，传播最广的是「小猫补光灯」：没有工程背景的产品经理，把一个 App 做到了付费榜前面。

公司里也在发生同样的事。产品、运营、财务用这些工具做演示、写插件、出分析页，把排不进研发日程的个性化需求先接住。设计部在 2025 年征集过一轮作品，各业务交上来 114 个尝试，其中不少已经能给人直接用。

外面和里面，用的是同一种做法。

外面看得到的公司里的（需登录）
非设计师• 8 岁孩子用 AI 辅助，半小时做出哈利·波特聊天机器人
• 小猫补光灯：零基础产品经理用 AI 写 App，冲上付费榜前列		• 产品经理一周做出小美 iOS App
• 8 小时做完美团十五周年 Keeta 沙特红包发放
• 用 NoCode 做插件，补上拖了很久的暗黑模式
设计师• ryo.lu：复古 Mac OS、个人 Agent、全球聊天室
• 网页和移动端的时空穿梭机，实机页面
• 设计师做的 Figma 插件：Markdown 转设计标注		• 设计师做的 MasterGo AI 插件说明
• 2025 设计部 AI Coding 活动网站
• 2025 设计部 AI Coding 投稿，114 个

这种做法叫 Vibe Coding

它指的是一种很窄的工作方式：程序由自然语言驱动，人尽量不写、也不读代码。报错出现后，原样贴回去，让模型自己修。

2025 年 2 月，Andrej Karpathy 把这件事说透了。

Karpathy 定义 Vibe CodingKarpathy 定义 Vibe Coding

有一种新的编码方式，我称之为 “Vibe Coding”。你完全沉浸在那种状态里，接受模型给出的结果，甚至忘记代码还在。

原因是现在的模型已经足够强，比如 Cursor Composer 配上 Sonnet。我几乎只用 SuperWhisper 对着 Composer 说话，很少碰键盘。我会提很懒的要求，比如「把侧边栏的 padding 减半」，因为我不想自己去找那一行。改动来了我一律接受，不再看 diff。

报错也是直接复制，不加解释，通常就能过去。代码量会超过我平时愿意细读的范围，真要读得花一阵。模型修不好的时候，我就绕开，或者随便再改一改，直到它好。

拿来做周末的一次性项目，还不算糟，而且挺有意思。我在做一个项目或一个网页应用，但这已经很难说是在编程：我看到一点，说一点，跑一点，复制粘贴一点，大部分时候它能工作。

门口因此变宽了，更多想法能先变成一个能打开的东西。设计师和工程师站在这个门口，体感差很多：工程师多半写得出模型交上来的那些代码，所以能在收下之前看见问题。没有这层判断的人，往往要等页面坏了，才知道里面有问题。

把座位换到设计这边

假设生成工具已经能进设计文件，非设计的同事用它承担你的一部分工作。模型见过大量规范的设计系统和组件库，图层命名、分组、间距常常比手搓更整齐，出图也快。使用的人没有设计训练，看不出层级、一致性，也想不到这份文件半年后怎么协作。对方的感受会是：这看起来挺好。

再看成需求的那一方。对方一开始说不清要什么，要靠一轮一轮试稿才把想法定住。60 分和 80 分放在同一页里，对方分不出来。问题暴露之后，反馈落在眼前那一处，局部修好了，结构还是歪的。沟通和返工都变贵。对模型来说，这些来回就是在消耗 token。

非技术同事面对 AI Coding，大致就是这个位置。

省下来的，和以后要还的

非技术同事的感受工程师的感受
省下的门槛下降。人可以从语法和概念里抽身，把注意力放在想法和要解决的问题上。少了大量复制、粘贴和机械查找。补全让人更容易碰不熟的技术。
还回去的描述不准，复杂效果就出不来，复杂故障会在对话里打转。看不出需要技术理解才能发现的隐患，代码会越来越难改、难协作、难加功能。没经审查的生成代码，风格会散，性能和安全也没人签字。代码写得越快，越需要人有判断和整体规划。

轻松写完，调试时才崩轻松写完，调试时才崩

四种造车路径的类比四种造车路径的类比

三个人把边界画在不同的地方

Ryo（Cursor 设计师）认为，这种做法很强，但完全不懂技术就想做出能长期运行的产品，仍然很难。它最大的作用是把入门门槛放下，让设计师和产品经理很快拿到原型。稳定、可维护的产品，还是要懂一些基本概念。

Ryo 谈门槛与成品Ryo 谈门槛与成品

吴恩达觉得这个名字会让人误会，好像只要凭感觉接受或拒绝就行。他自己用这类工具写一整天，结束时非常累，因为这是很费脑的事。名字不一定准确，现象本身发展得很快。

他接着说了一件更要紧的事：过去一年有人劝别人别学编程，理由是 AI 会写。回头看，这可能是最差的职业建议之一。几十年里，编程每变简单一次，学的人就多一次。从打孔卡到键盘，从汇编到 COBOL，都有人写文章说程序员要消失。结果是门槛越低，写程序的人越多。有了编程助手，更应该有人去学。

无论是不是程序员，往后一项关键能力是把「你想要什么」讲准确，计算机才实现得了。懂一点计算机如何工作，下指令会更准。他的建议仍然是：每个人学一门语言，比如 Python。

Canva 创始人写的是公司内部的评估结论：编码助手必须由有经验的工程师盯着，尤其是要进生产环境的任务。工程师要引导、评估、纠正，并对结果负责，标准等同于这些代码是自己写的。实验里反复看到，生成代码的问题从风格不统一，一直到错误、不安全、性能差。

他们目前只在一个窄场景里认可这种做法：用来快速验证想法的试验代码，比如原型和概念验证。这类代码最后会丢掉。模型辅助在快速试想法上潜力很大。能力在变，上下文窗口也在变，他们会持续重估能信任到什么程度。原则不变：好的软件工程里，人始终掌握对工具输出的指导、评估和所有权。

能打开，和能交给别人用

设计有可用性。代码也有一组「页面能打开」盖不住的科目。每一项都是同一件事的两层：自己演示时怎样就够，交给别人长期用时要补上什么。

性能。 演示时，每次操作都重新过滤、重新加工整份数据。长期使用时，同样的结果留一份缓存，避免同一段计算反复扫全量。

稳定性。 演示时直接请求接口，失败就失败。长期使用时要有超时、有限次数的重试，以及一次比一次等更久的间隔，避免瞬间把服务打满。

错误处理。 演示时默认保存一定成功。长期使用时要先检查数据在不在、类型对不对、体积有没有超出本地存储上限，失败要留下日志，并有一条退路，比如先放在内存里或告诉用户没存上。

边界。 演示时默认用户有名有姓。长期使用时要处理没有用户、只有名、只有姓、名字长到放不下的情况，空的时候给一个客人称呼，过长时截断。

旧数据。 演示时直接按新结构去读本地存档。长期使用时要认出版本：旧数据缺字段就补上，结构变了就迁移，再写回，避免一次改版把老用户的数据读坏。

环境差异。 演示时默认所有浏览器都有最新接口，比如直接调用剪贴板。长期使用时先检测能力，没有就走旧办法，再把临时节点清掉。

安全。 演示时把用户输入原样收下。长期使用时要清洗内容、限制长度，避开脚本注入和类似的注入问题。

可观测。 演示时出错了页面没反应，作者也不知道。长期使用时，保存、失败、耗时要有日志和计数，出了事能查到是哪一次。

量变大之后。 演示时把全部用户放进一次循环里发信、出报告。长期使用时分批取、限制同时进行的数量、批次之间留空隙，避免把服务器压垮。

测试。 演示时靠手点主路径。长期使用时，关键行为要有能自动跑的测试，例如保存一份合法资料时，请求有没有打到对的地址、带上对的内容。

别人接得住。 只有作者读得懂的文件，协作会停住。注释、统一的格式和引用路径、按模块分目录，以及单文件尽量不超过 200 行，都是为了下一个人能改。

发布和退回。 演示时直接换成新版本，所有人同时看到。长期使用时按比例先放开，例如只让一部分用户看到新界面。出问题能切回旧的。

预期可以落在两句话上

目标停在自己能用、能拿去演示，并且承受得起以后难改，全程交给对话是划算的。它先把「做不出来」抬成「做得出一个能跑的版本」。

目标是稳定、可协作、能进业务，就要补上专业开发用来守质量的知识和判断。工具放大的是你已经有的判断，补不上你还没有的判断。

工具按「你留下多少控制」来分

复杂的编程产品，是从旁边一条对话框长出来的。

2023 年的编程助手，和 ChatGPT、豆包、小美是同一类交互：编辑器外侧一问一答，你再把片段贴回去。上下文有限，一次生成的量也有限，适合要一小段代码的时候。

2024 年，Cursor 让这件事出了圈，用法也换了。人愿意天天开着它，是因为两处变顺了。输入靠近代码：能引用上下文，能在行内改。采纳靠近编辑：diff 能预览，能一键收下，能退回，补全自己往下走。模型的能力被这些交互放出来，AI 主笔才变得日常。记忆仍然有限，项目一大、生成一长，效果会掉。

2025 年，以 v0、Devin 为代表的产品把编辑器再往后退，主界面变成对话加预览。指令更直白：传附件、点名要改的对象、一键接上服务。终点从「代码收下了」变成「页面发布了」，中间包括装依赖、跑起来、配部署。没有工程背景的人，从这里进去最省事。限制也明确：技术栈和平台是选定的，存量的大项目常常接不住；一轮生成到反馈的时间长，不适合细碎地来回调。

从人主导到 AI 主导从人主导到 AI 主导

年份形态你怎么用它胜任的范围到此为止的地方
2023，对话式助手在原有编辑器侧面加一条对话手写或贴上提示，拿回一轮回答，再自己粘进文件给代码片段提建议上下文短，一次写不了多少
2024，为 AI 重做的编辑器编辑器按 AI 工作流重建引用上下文、行内改、自动补全；生成直接流进文件；用 diff 决定收不收，并能退回半自动地改多个模块记不住太长的持续生成
2025，编码代理编辑器变弱，对话和预览成为主体丢进多种附件，先定计划；按目标分步做，自己找上下文，自己排错；顺手把环境、预览和发布接上小规模的完整项目技术栈受限，大而旧的仓库不合适；反馈慢，难做敏捷的细调

四种交互模式对照四种交互模式对照

上图把交互收成 Chat、Edit、Agent、NoCode 四类，用来看差异，不是严格的产品分类。

四类产品，外加一条组合路径

设计师视角的工具图谱设计师视角的工具图谱

图按「人主导 / AI 主导」和「对设计师友好 / 偏工程」分成四块。位置是相对的，没有精确刻度。

从零做一个网页，目前比较顺的接法是：

  1. 用 NoCode 这类预览式工具起框架，并把发布环境备好，省掉建仓库和装依赖。
  2. 用 Cursor 这类编辑器收样式、补复杂逻辑。
  3. 再同步回 NoCode，走平台自己的发布，少审批，少自己配环境。

上手先用图谱左上的预览式工具。做顺了，再把主力移到右下的 AI 编辑器。还有余力，再看左下的可视化编辑器，以及右上、还在快速变化的编码代理。

预览式AI 编辑器可视化编辑器编码代理
代表NoCode、v0、Lovable、Bolt、Same、MacalyCursor、Catpaw、Windsurf、TraeOnlook、Subframe、Reweb、Framer、WebflowDevin、Replit、Tempo、Claude Code
给谁产品、设计等角色，用来很快做出原型和网页专业开发，用来做要上线的应用设计和前端，用图形把基于代码的界面搭出来需要完整交付的团队
界面预览式工具的界面预览式工具的界面AI 编辑器的界面AI 编辑器的界面可视化编辑的面板可视化编辑的面板编码代理的界面编码代理的界面
从创建到发布首页对话创建，一般不能导入已有仓库。用对话或按钮改页面，旁边就是预览，改完即更新。右上角可以一键发布。能接已有仓库。环境、依赖和项目可以自己建，也可以让对话去做。改动可以对话完成，也可以亲手改。预览要自己启动，或让对话执行。本身不负责发布。内部常用 Talos，或导回 NoCode。外部有 GitHub Pages、Vercel 等免费方案，使用前要评估安全。从空白或模板开始。左侧看图层，图层是 DOM，能拖，不能命名；也能拖入现成组件。右侧调样式，或开一条对话做简单修改。不负责发布，可以看源码、导出，或转到编辑器。首页对话创建，有的产品能导入仓库。它会先给计划，再装依赖、写文件、跑测试、打开预览。执行中可以插话，计划会跟着改。预览随修改更新。不负责发布，可以导出源码或转到编辑器。
版本、素材、精调历史在侧栏，自动记下。单击看某一版，双击退回。换图时先点中对象，再上传并说明替换谁。精调样式也是先点中，再用样式面板改参数。仓库用 Git，提交和分支要自己管。对话里的改动可以用 Restore 撤回。素材一般放在 src/assets，图片、图标、音频、视频、字体都可以，让 AI 去引用。精调时先指出文件或片段，再说想要的效果。在线自动保存，和协作文档一样。换素材是选中、上传、设定展示规则，比较准。样式也是选中后在右侧面板改，比较准。撤回和 Cursor 的 Restore 接近。素材从输入框上传并说明用途。精调同样要先指出文件或片段。代码不好翻，点名要改的对象会比较难。
强项门槛低，搭起来和发布都快。能力全，上下文强，补全快，专业开发者评价高。用改图层的方式写前端，设计和实现叠在一起，所见即所得。从方案到可运行的结果都能自己往下做。云端打开就能用，本机不用先配环境。
边界离生产环境还有距离。过度简化之后，数据状态、按条件变化的交互这类复杂行为难展开。生成依赖特定技术栈，目前主要是 React 加 Tailwind 这一类。更适合从零生成结构规整的项目。仓库太大、技术栈不合、格式不标准时，很难导进去。对设计师有三道坎。工具上要熟悉编辑器、快捷键、终端、打开项目的方式、插件和系统设置。环境上要自己处理依赖、接口、Git、外部发布和目录结构。认知上，意图识别和补全都有限度，需求说不清，结果就对不上。适合从零做、单独发布的网页，要先看清每个产品锁在哪套前端技术上。除了 Framer，多数产品处理复杂交互和强烈视觉效果的能力还弱。产品形态还不稳定。面向团队，价格高。一次深度执行常常要几十分钟到一小时左右，中途很难插进去做细调。

设计师自己写，换来的是形态上的控制

会写实现的设计师，多出来的是对产品形态的直接控制。具体落在四件事上。

  1. 还原不必再靠口头描述。网格、间距、色值你自己知道，改动直接进到界面。
  2. 参数有出处。尺寸和间距来自你已经在用的规则，对着稿子凭感觉填数的情况会少很多。
  3. 稿子和实现之间少一轮搬运。动效和状态可以在代码里试，少在 MasterGo、Figma、XD、AE 之间把同一件事讲好几遍。
  4. 设计工具模拟不了的实时效果和交互细节，可以先跑起来看。多年的设计判断，在这里有地方落地。

入门阶段，比较现实的完成范围是：没有后端、也不需要复杂发布的独立小产品。更多例子在 征集作品页（需登录）。

场景它长什么样例子
个人网站、独立小产品纯静态前端，没有后端，也不需要多人一起改数科设计团队的专属空间
和玛露西尔一起专注（外部，可直接打开）
设计师印迹订单打印机
解决手边问题的插件功能简单，装在本机用，浏览器、设计稿或软件脚本都算MasterGo 插件：秒绘
MasterGo 插件：Master Selector
Figma 插件：Markdown 转设计标注（外部，可直接打开）

熟练到能看懂改动、也能把改动交回去之后，就可以碰需要协作、会对外发布的业务模块。

场合以前怎么发生自己能写之后例子（需登录，外部链接除外）多出来的能力
设计验收录问题、开会讲，常常要 2 到 5 个工作日。间距和色值在会议里来回描述，像把一首歌用文字唱给对方。这些数值设计师本来就清楚，半天改完，提交合并请求。医药弹窗文案一致性
调整 ChatInput 的样式、布局和文案		少一层因沟通造成的设计损耗，好的判断更容易进到界面上
存量上的体验修改提了一条体验优化，排期落到很后面，中间先把文档写厚。上下都认为值得做，就拉代码直接改。ChatHeader 支持双击改标题，失焦保存
提高 BasicInfo、ChatHeader、ShareInfo、OperationButtons 的可读性
ConversationItem 的菜单补上外部点击和移出关闭		资源没排上时，小改动仍然能落地
细碎的新增反馈录入、产品出方案、设计补控件、开发再验收，三个人一天做不完。设计师先理解问题，快速讨论并定方案，拉代码实现，随版本上线。两个人一天可以做完。反馈从排队变成跟着版本走
方案是否做得成对方说做不了。别处的产品明明有类似做法。知道原理和大概成本，是几行代码还是几轮对话，方案更容易被认真讨论。用对话搭一个数据看板用对话搭一个数据看板想法和实现之间多一条你自己走得通的路，在团队里的发言更有依据
方案要被人碰到对方问这叫什么、去哪搜，打开才发现是一张静态稿。先搭一个能点的演示，拿去验证、收集反馈。对话输入演示行动可以先于排期
没有研发档期的整件事想做一件完整的事，档期没有，于是继续用文档顶着。申请域名、把功能做出来、把网站搭起来，简单业务自己收口。设计部 AI Coding 活动站：宣传、投票、颁奖
像素 Keeta 品牌资产平台：宣传与资源下载		离需求和用户更近，简单的事可以自己闭环

一个实用的初筛：预估的开发时间如果已经超过这件事的设计时间，这场接手多半不划算。实现比设计还重，继续交给工程同学。

顺带算另一笔账。一个人如果能从需求走到设计再走到实现，文档、多方评审和验收仍然会存在，但它们不再是把想法运到界面上的唯一路。一次需求里，有多少时间在写说明和对齐，有多少时间在处理设计本身，值得单独看一眼。闭环变短之后，先省掉的是为了转运而存在的环节。

设计师写代码，价值落在设计上：少一层依赖，少一层交接时蒸发掉的信息，把对产品形态的判断用到实处。

什么人、什么需求，值得现在就进仓库

下面是从有限案例里整理的倾向，用来对照，不是门槛。

更容易投入的人，通常有这些特质：事情愿意自己收尾；把复杂逻辑理顺会让你高兴；思考时习惯先搭结构；愿意碰没学过的东西；喜欢把一件事讲到原理；问题没想清会放不下；解决问题本身让你兴奋。

已有的经历里，这两段最容易接上：维护或搭建过设计系统，知道组件和全局样式怎么运转；做过复杂动效并交付过，熟悉参数如何串起来生效。

机会也很具体。手头有研发资源覆盖不到的需求，并且业务信任设计师直接改代码。

更适合设计师进入的区域有两块。一块是前端里和表现有关的部分：精细的样式、交互和动效。另一块是设计师自己就是用户的需求：体验修补，以及设计流程里的自用工具。

业务上可以先试的条件：

  • 包袱轻。技术选型、架构和设计规范还没有叠成很多层，模块也比较单纯，合作的团队愿意让设计师改。
  • 容错大。排期相对松，出了故障影响的是可承受的范围。

先别进的条件：

  • 包袱重。大型产品或复杂业务，规则多、模块缠在一起，分工也已经切得很细。
  • 容错小。排期紧，故障会直接打到线上指标。

进度可以停在半路

阶段是从有限案例里提炼的参照，方便知道自己在哪，不是等级考试。

阶段参照这时通常会的操作这时用得上的 AI 能力做到什么程度背后要有的底子
小白还没用过这类产品还没有对话，以及把结果收下判断全程交给生成结果愿意试，并且有想做的东西或真实需求
入门做过一个能跑的小产品认得出编辑器、终端和常用快捷键；能本地预览、连上仓库、放静态资源；报错会贴回去修用 Restore 退回一轮改动半懂，但能跑。静态样式和简单交互可以自己做着玩设计上会搭界面结构。代码上碰过 HTML、CSS、Git 和开发者工具
进阶jayzhushi.com、Rico会分支，会准备假数据，会把组件拆开再调用，能自己排查，对「这段以后能不能改」有感觉行内修改，用 @ 引用上下文静态样式和交互有把握。能进业务仓库，关键处仍要工程师兜底设计上有组件化和设计变量。代码上碰过后端入门，前端再深一层
成熟Ryo部署、打包、测试这些上线要走的流程为自己写一套 AI 规则复杂前端能自己收口，简单后端也能做做过更多真实项目

比较友好的走法是两条线一起：用自己的需求练手，把碰到的概念补上。从「能跑但说不清」走到「能按预期实现」，能力圈是这样变大的。

知识按使用顺序补

重要性是主观的。必修表示入门就会撞上，选修表示等业务或效果需要时再碰。

HTML，必修，难度低。 先认页面由什么块组成：div、span、a、img、main。不写代码也值得知道。它对应设计稿里的定界框，用来看见一个元素从哪到哪。还没有这个概念时，会找不到该改的那一段，结构也会堆成读不懂的一层。

CSS，必修，难度低。 先认盒模型：内容、内边距、边框、外边距。然后是 flex 和 grid、transform、filter，以及 animation 和 transition。设计软件右侧那些参数，在这里都有对应写法。对不上的时候，常见现象是样式被盖掉、底部栏飞出屏幕、以后没人敢改。

JavaScript，选修，难度中。 先认事件（点击、键盘、滚动），对元素的增删和动画调用，以及用 fetch 拿数据再更新页面。原型连线覆盖不到的状态变化，要靠这里。还没建立这个概念时，会卡在「变化描述清楚了也出不来」，或者因为频繁改 DOM，页面发顿。

Git，必修，难度低。 先认 commit、push、merge。commit 和 push 把当前分支的改动交进仓库，并写清这次改了什么。merge 把另一条分支并进来，历史保留，方便几个人同时做。这是协作和反悔的基础。只有本机一份文件时，改坏了退不回，别人接不走，分支上的代码丢了也找不到。

包管理器，选修，难度低。 npm、yarn、pnpm 用来安装、升级、删除别人写好的库。版本对不上、依赖没装上，或者随手装了一堆用不到的包，项目会变肿，以后更难改。

CI / CD，选修，难度中。 CI 是每次 push 之后自动测试和构建。CD 是把构建结果自动送到测试或正式环境。它替换掉每次上线都手点一遍的流程。没有这条流水线时，发布靠人工，也更容易在上线时出错。

动效和可视化，选修，难度中。 按需要再碰：开源动画库、SVG 动画、Framer Motion、Three.js。用来做设计工具里难模拟的运动和空间。没接触之前，复杂效果常常停在对话里，跑不出来。

框架和样式方案，选修，难度中。 按业务来。常见的有 React、Vue、Swift、Regular，样式上常见 Tailwind。业务仓库通常已经选定。只用原生 HTML、CSS、JS 写的页面，接不进要上线的产品。

开发者工具，必修，难度低。 先认这几块面板。

  • Console：看报错和日志
  • Elements：看 HTML 和 CSS。这个面板不写代码也值得会
  • Network：看资源加载和状态码
  • Sources：看源码，打断点
  • Application：看缓存、本地存储和 cookie
  • Performance / Lighthouse：看性能指标

页面慢，去 Network 看是哪个资源拖住。样式怪，去 Elements 看实际生效的规则。脚本或数据不对，去 Console 和 Sources。白屏又读不懂报错，通常是还不会用控制台。请求成功还是失败，要会看 HTTP 状态码。

存储和缓存，选修，难度中。 本地有 localStorage、sessionStorage、IndexedDB，还可以用 Service Worker。缓存分强缓存和协商缓存，决定用户再次打开页面时，要不要重新向服务器要资源。数据拿不到、POST 发不出去，先回到 fetch 本身。刷新就掉登录，或 token 放在不该放的地方，是存储位置没选对。查找慢、占内存、更新别扭，常常是数据结构不合适。

运行和性能，选修，难度高。 主线程负责脚本和界面，耗时的事放到别处，页面才不会卡住。常用手段包括懒加载、预加载、压缩、服务端渲染或静态化、代码分割、按需加载。数据在组件之间对不上、操作之后界面没反应，是状态没管好。不必要的重排和重绘，会把页面拖慢。

三个做着做着就会用到的手法

用图层去读代码。 设计稿的图层顺序，往往就是节点的嵌套。先在稿子里点中一块，再去文件里找同名或同结构的节点，比从头通读快。

图层结构对应代码结构图层结构对应代码结构

样式在设计工具里定好，再整段带进代码。 间距、字号、颜色先调准，复制 CSS，贴到对应节点。比在对话里用形容词来回描述更稳。

从设计稿复制样式从设计稿复制样式

把样式贴进代码把样式贴进代码

在页面里核对样式代码在页面里核对样式代码

用开发者工具看实际生效的那一版。 浏览器里打开页面，用 Elements 点中元素，看计算后的样式，用 Console 看报错。对话里的解释要和这里的实际值对上，再决定改哪里。

顺利路径之外，把边界也点一遍。 空数据、超长文本、失败的请求、未登录、极窄的窗口。只在一切正常时点过的页面，上线后会在这些地方坏。

几篇需要登录的实践记录：

离开前记住的三句

  1. 对话能把做不出来，抬成做得出一个能跑的版本。稳定、可维护、能进业务，仍然取决于你能不能判断生成结果。
  2. 简单、通用的需求，可以交给 AI 主导的产品。复杂、要细调的需求，适合回到专业的 AI 编辑器。
  3. 设计师写代码，最大的收获是少一层转译。用自己的需求练手，把碰到的概念补上，能力圈会慢慢变大。

附录

接着读

和 Vibe Coding 直接相关的几篇：

自学材料

先建立整张地图：HTML、CSS、JS 文档。

想马上动手，公司内有一份 设计部 AI Coding FAQ（需登录）。

零散但有用的入门材料：

按需要再往下：

可以拿来用的库和案例

动效和组件：

网页案例：

移动端案例：