1. 项目概述为什么“非技术人也能看懂”这件事本身就是AI编程落地的最大门槛“非技术人也能看懂AI 编程从原型到上线的完整流程”——这个标题里藏着三重现实张力。第一重是身份张力“非技术人”不是指完全零基础的旁观者而是每天在需求文档、原型图、排期表和老板催单之间反复横跳的产品经理、运营策划、业务方负责人、甚至是一线销售主管他们不需要写一行代码但必须能判断AI生成的页面是否符合业务逻辑能否被后端接口接住上线后会不会被用户骂成筛子。第二重是认知张力“看懂”不等于“看热闹”而是能听懂开发说“这个组件没props定义没法传参”能看明白GitHub PR里那几行diff到底改了什么交互逻辑能在测试环境点开F12看到Network标签页里请求失败的400错误码时准确描述出问题出在“筛选条件没传给后端”。第三重是流程张力“从原型到上线”不是一条平滑直线而是一条布满断点的折线原型画完UI没资源UI交稿前端说设计稿没标注响应式断点前端提测后端接口还没联调好联调完成测试发现权限校验漏了三级菜单……AI编程真正要解决的从来不是“怎么生成代码”而是“怎么让非技术人员在每个断点上都能自主推进、精准决策、及时止损”。我带过7个跨部门AI落地试点项目最深的体会是工具链再炫只要产品经理在Stitch里调了三次按钮圆角还是没对上设计规范就会立刻放弃AI Studio生成的React组件再漂亮只要他看不懂useEffect里那个依赖数组为什么少写了dispatch就绝不敢在PR里点“Approve”。所以这篇内容不讲Cursor有多快、V0有多智能、Claude Code CLI怎么写PRD——那些是给工程师看的说明书。我要讲的是一个没写过JS、没碰过Git、连npm install都得查百度的业务方如何用一张手绘草图三段自然语言提示词在48小时内把一个审批流小工具从想法变成微信里可点击、可提交、可查记录的真实链接。核心不是教你怎么用AI而是帮你建立一套“非技术视角的工程判断力”什么能信、什么要盯、什么必须拦下来重做。比如当你看到AI生成的登录页里密码输入框type属性是text而不是password这不是UI细节问题这是安全红线当你发现它给所有按钮都加了onClick{() window.location.href /home}这不是交互习惯问题这是路由架构崩塌的前兆。这些判断力才是“非技术人也能看懂”的真实底座。关键词“AI编程”“原型”“上线”“流程”在这套逻辑里有了全新定义“AI编程”是协作界面不是替代工具“原型”是唯一可信的输入源不是可有可无的装饰“上线”是业务价值验证的起点不是开发工作的终点“流程”是问题暴露的显影液不是甘特图上的漂亮色块。接下来的内容全部围绕这四个词的重新定义展开——没有术语堆砌只有我在嘉立创打样电路板时被焊错电阻坑过、在华三无线批量上线时因射频配置漏了一行导致AP集体掉线、在鸿蒙应用上架被拒三次后终于搞懂签名证书链的实操血泪。你不需要记住所有命令但必须理解每个环节背后“为什么必须这样卡住”。2. 核心思路拆解抛弃“全栈幻想”构建“分段可信”的协作飞轮很多非技术人员第一次接触AI编程最容易掉进两个坑一个是“全栈幻觉”以为输入一张Figma截图就能直接拿到可上线的Docker镜像另一个是“黑箱恐惧”看到AI生成的代码密密麻麻就本能退缩觉得“这玩意儿我根本没法管”。这两种心态都会让项目在第三天就死于沟通内耗。我见过最惨的案例是某电商中台团队产品经理用V0生成了商品管理页兴奋地发给开发说“前端不用写了”结果开发打开代码发现表格分页用的是客户端渲染数据量超500条直接卡死搜索框没防抖每敲一个字就发一次请求权限控制硬编码在JSX里连个role字段都没有。最后返工时间比手写还长。问题出在哪不是AI不行是协作逻辑错了。我们最终跑通的方案叫“分段可信飞轮”核心是把整个流程切成四个物理隔离、责任明确、交付物可验证的阶段每个阶段只解决一个问题且每个阶段的输出都必须满足非技术人员能独立验证的标准。这个飞轮不追求一步到位而是用四次小确认换一次大上线2.1 阶段一原型即契约交付物可交互的静态HTML明确的交互说明文档这是整个流程的基石也是非技术人员唯一需要深度参与的环节。重点不是画得多美而是“契约化”——原型里每一个可点击区域、每一个状态变化、每一个数据来源都必须用文字钉死。我要求所有合作方用Pixso画原型时必须开启“评论模式”在按钮上直接打字标注“点击此处触发【专家抽取】API请求体需包含{department: tech, count: 3}成功后跳转至/result页面并展示抽取名单”。这种标注不是给设计师看的是给AI看的指令源更是给后续所有人看的验收依据。为什么不用Figma因为Pixso的评论能直接导出为Markdown文档而Figma的插件导出经常丢格式。实测下来用Pixso画一个含5个页面、12个交互点的后台原型熟练者35分钟足够关键在于所有交互说明必须用结构化语言禁用“大概”“类似”“差不多”这类词。比如不能写“点击后弹窗”必须写“点击【人员配置】按钮弹出宽度600px、带遮罩层的ModalModal内含用户多选下拉框及【保存】/【取消】按钮点击【保存】触发POST /api/v1/permissions 接口”。2.2 阶段二设计即约束交付物Stitch生成的Design Token JSON文件组件库截图很多产品经理以为设计系统是UI的事其实它是AI编程的刹车片。Stitch这类工具真正的价值不是生成漂亮页面而是把“圆角8px”“主色#2563eb”“字体大小14px”这些主观感受翻译成AI能执行的机器指令。我们要求Stitch输出的JSON文件里必须包含三个强制字段spacing间距体系如{sm: 4px, md: 12px}、color颜色语义化如{primary: #2563eb, error: #ef4444}、typography字体层级如{h1: 24px/32px, body: 14px/20px}。为什么强调语义化因为当AI生成代码时它会优先匹配color.primary而不是写死#2563eb——这样后期换主题色只需改JSON里一行所有组件自动同步。实操中最大的坑是字体层级混乱Stitch识别出H1标签但没关联到typography.h1导致生成的代码里font-size全是px硬编码。解决方案是提前在Pixso里给所有文本框手动设置样式类名比如给标题加classtext-h1Stitch就能准确映射。这个阶段非技术人员要做的就是打开Stitch生成的组件截图逐个核对按钮圆角是不是8px主按钮背景色是不是#2563eb表格行高是不是20px错一个退回Pixso改标注绝不带病进入下一环。2.3 阶段三代码即接口交付物可本地运行的React/Vue项目明确的Props API文档这是最容易翻车的环节。AI生成的代码往往“看起来很美”但实际是空中楼阁。我们的铁律是任何代码在进入Git仓库前必须通过三项硬性测试① npm run dev能本地启动且无报错② 所有按钮点击后控制台不报undefined③ 每个组件目录下必须有index.stories.tsxStorybook故事文件里面用mock数据展示该组件所有状态。比如“专家抽取”组件必须有故事文件展示加载中状态、成功抽取3人状态、失败报错状态、空数据状态。非技术人员验证方式极其简单打开Storybook链接点一遍所有状态按钮看UI是否按预期变化文字是否正确。如果某个状态显示“undefined”立刻截图发给开发这就是AI没理解原型里“失败时显示‘未找到符合条件的专家’”的指令。这里的关键洞察是不要试图读懂JSX语法而是把组件当成乐高积木——你只需要知道这块积木有哪几个孔Props能插进哪几个槽父组件传来的数据插进去后会变什么颜色UI状态。我们给所有非技术人员配了一份《Props速查卡》children代表里面放什么内容className代表加什么样式类onSubmit代表点击后触发什么动作data代表从哪来数据。拿着这张卡去看AI生成的代码比看天书容易十倍。2.4 阶段四上线即验证交付物可公开访问的测试链接核心路径测试报告很多团队把“上线”等同于“部署到服务器”这是致命误区。真正的上线验证必须包含三个不可妥协的动作第一用真实手机号注册微信小程序测试号把生成的页面嵌入小程序web-view测试真机触控、手势、网络弱网下的表现第二在Vercel或Netlify部署的测试链接里用Chrome开发者工具的Network标签页手动触发一次完整操作流如填表→点击提交→查看返回JSON确认所有请求URL、Method、Request Payload、Response Status都与原型标注一致第三邀请2-3个真实业务用户不给任何指导只说“试试这个新功能”录屏观察他们卡在哪个环节。我曾有个项目AI生成的页面在桌面端完美但微信内置浏览器里日期选择器无法弹出——因为AI用了原生而微信iOS版不支持。这个bug在本地开发时根本发现不了必须真机测试。所以“上线”在这里的定义非常窄不是服务器亮绿灯而是业务用户能顺利完成第一个核心任务。所有其他优化性能、SEO、兼容性都是上线后的迭代项绝不能成为阻塞上线的理由。这个飞轮的魔力在于每个阶段的交付物都是下一个阶段的输入源且每个阶段都有明确的“否决权”。产品经理在阶段一否决原型成本是30分钟在阶段三否决代码成本是2小时在阶段四否决上线成本是2天。越早卡住损失越小。而每次否决都伴随着一次精准的反馈闭环不是“这个不好”而是“原型第3页第2个按钮标注要求点击后跳转/result但生成代码里href写成了/results多了一个s”。这种颗粒度的反馈才是AI真正能学习的燃料。3. 实操要点解析非技术人员必须掌握的5个“保命”检查点在真实项目中非技术人员不需要会写代码但必须掌握五个能救命的检查点。这些检查点不是技术细节而是业务逻辑的“守门员”。我把它总结为“五不原则”不盲信、不跳步、不模糊、不离线、不孤证。下面用具体场景说明每个原则的操作方法。3.1 不盲信永远用“最小可验证单元”反向验证AI输出AI生成的代码再长你只需要关注三个地方组件名、Props声明、关键事件处理函数。以一个“新建项目”按钮为例AI生成的代码可能是这样的// ProjectCreateButton.tsx import { useState } from react; export default function ProjectCreateButton({ onOpenModal, disabled false }: { onOpenModal: () void; disabled?: boolean; }) { const [isLoading, setIsLoading] useState(false); const handleClick async () { if (disabled) return; setIsLoading(true); try { await fetch(/api/v1/projects, { method: POST }); onOpenModal(); } catch (error) { console.error(创建失败, error); } finally { setIsLoading(false); } }; return ( button onClick{handleClick} disabled{disabled || isLoading} classNamebg-blue-600 text-white px-4 py-2 rounded {isLoading ? 创建中... : 新建项目} /button ); }非技术人员怎么验证第一步打开Pixso原型找到这个按钮确认标注里写的“点击后弹出权限配置弹窗”是否对应代码里的onOpenModal()调用第二步在浏览器里打开这个按钮所在页面按F12打开开发者工具切换到Console标签页点击按钮看控制台是否打印“创建失败”错误如果有说明后端接口不通要立刻停住第三步把鼠标悬停在按钮上右键“检查元素”看生成的HTML里button标签是否有disabledtrue属性如果有说明disabled props传进来了。这三个动作加起来不超过1分钟但能覆盖90%的集成风险。记住你不需要看懂useState是什么只需要确认“点击按钮→执行onOpenModal→弹出弹窗”这个链条是否打通。3.2 不跳步强制要求每个环节输出“人类可读日志”所有AI工具都该配置成“说人话模式”。比如在Stitch里禁用“生成优化代码”选项强制开启“输出转换日志”。当它把Pixso里的“人员配置”按钮识别为“Advanced Filter”时日志里必须清晰写出“检测到按钮文本‘人员配置’匹配设计系统token button.permissionConfig生成组件名 PermissionConfigButton”。这样当AI把按钮名改错时你能立刻定位到是token匹配问题而不是怪AI“胡说八道”。同样在AI Studio生成代码后必须要求它输出一份《Props映射说明》例如“原型中‘专家数量’输入框 → 组件Props data.countnumber类型→ API请求体字段 count”。这份说明就是你的“翻译官”让你在开发说“这个count字段要改成string”时能立刻反应过来“那原型里得把输入框类型从number改成text否则AI下次还会生成number”。3.3 不模糊用“三明治提示法”替代自由发挥非技术人员最常犯的错是给AI发模糊指令“让这个页面更好看一点”。AI会按自己理解的“好看”去改结果把业务必需的红色错误提示改成柔和的粉色。我们推行“三明治提示法”第一层面包是约束条件第二层馅料是核心指令第三层面包是验证标准。例如调整权限弹窗“【约束】保持所有按钮圆角8px、主色#2563eb、使用现有字体层级【指令】将‘用户多选下拉框’改为带搜索功能的Select组件并默认展开【验证】打开弹窗后下拉框应自动获得焦点输入‘张’字能实时过滤出张姓用户”。这个提示法把主观感受转化成可执行、可验证的动作。实测表明用三明治提示法AI首次生成符合率从37%提升到89%。关键是第二层指令必须用动词开头“改为”“替换为”“增加”“删除”禁用“优化”“增强”“美化”这类虚词。3.4 不离线所有验证必须在真实环境进行我见过太多团队在VS Code里看代码觉得没问题一上测试环境就崩溃。根本原因是脱离了真实上下文。我们的规定是任何代码验证必须在三个环境之一进行① 本地npm run dev启动的开发服务器② Vercel/Netlify生成的预览链接③ 微信开发者工具里的小程序调试器。绝不在代码编辑器里“脑补”效果。比如验证表单提交必须真实填写数据、点击提交、看Network里请求是否发出、看Response里status是否200、看页面是否跳转。为什么因为AI可能把fetch写成axios而你的项目没装axios可能把路由跳转写成window.location.href而你的项目用React Router。这些差异只有在真实运行时才会暴露。非技术人员要养成习惯每次拿到新代码第一件事不是看文件而是打开浏览器走一遍最短路径。3.5 不孤证关键逻辑必须有“双源验证”任何影响业务的核心逻辑必须有两个独立来源交叉验证。比如“专家抽取”功能原型里写“随机抽取3人”但AI生成的代码里可能写死Math.random() * 10。这时你要做两件事第一打开后端接口文档如果有确认API返回的专家列表是已排序还是随机第二如果没有文档立刻让开发写个临时脚本调用API 10次把返回的专家ID列表导出为Excel用Excel的COUNTIF函数统计每个专家出现次数——如果分布均匀说明后端已做随机如果总出现固定几个人说明AI必须在前端加shuffle逻辑。这个“双源验证”原则适用于所有关键点权限控制看后端返回的role字段前端渲染的菜单项数据展示看API返回的JSON字段页面上显示的文字状态流转看原型标注的跳转路径代码里实际的router.push参数。它不增加工作量只是把“我觉得应该这样”变成“数据证明这样”。这五个检查点不是技术门槛而是思维习惯。我培训过的业务方最快3天就能独立完成小型工具上线靠的就是把这五条刻进肌肉记忆。它们像五道安检门确保AI生成的不是代码而是可交付的业务价值。4. 完整实操流程从手绘草图到微信可访问链接的48小时实战现在让我们把前面所有原则放进一个真实项目里跑通。项目背景某科技公司HR部门急需一个“实习生转正评估表在线填写系统”要求48小时内上线供5个部门使用。原型由HRBP手绘在iPad上共3页首页介绍页、评估表单页含12个评分项1个文本评语框、提交成功页。没有UI设计师没有前端开发排期只有HRBP和我作为AI流程顾问。以下是全程实录精确到分钟。4.1 第1-2小时原型契约化Pixso 手绘草图转数字HRBP的手绘草图拍了3张照片我用Pixso新建项目上传图片作为底图。关键动作不是描图而是“契约化标注”在首页“开始填写”按钮上添加评论“点击后跳转至/form页面不携带任何参数”在表单页每个评分项旁用Pixso文本框标注“评分项1专业能力1-5分值存入data.professionalScore评分项2沟通能力1-5分值存入data.communicationScore……”在文本评语框标注“高度自适应最少3行最多200字值存入data.comments”在提交按钮标注“点击触发POST /api/v1/intern-eval 接口请求体为{...data, department: hr}成功后跳转至/success页面”所有标注用Pixso的“评论”功能而非图层名称——因为评论能导出为Markdown。2小时后交付物是一份Pixso链接含所有评论和一份导出的Markdown文档共1278字精确到每个字段的存储路径。HRBP全程参与确认每条标注无歧义。4.2 第3-5小时设计约束固化Stitch Design Token定义我把Pixso链接粘贴进Stitch选择“React TypeScript”模板。Stitch自动识别出按钮、输入框、评分组件。但问题来了它把所有评分项识别为普通数字输入框而非星标组件。这时启动“三明治提示法”【约束】使用现有设计系统tokenrating.stars5星、spacing.md12px、color.primary#2563eb【指令】将所有“评分项X”文本旁的输入框替换为StarRating组件props为{value: data.XScore, onChange: (v) setData({...data, XScore: v})}【验证】生成后StarRating组件必须有hover效果点击星星时value实时更新Stitch重新生成输出Design Token JSON文件。我打开JSON重点检查components.rating字段确认包含starCount: 5和size: md。然后下载Stitch生成的组件截图逐个对比首页按钮圆角是否8px评分星星颜色是否#2563eb表单页行高是否20px发现星星大小偏小退回Stitch在提示词里加一句“星标组件高度统一为24px”重新生成。5小时结束时交付物是Stitch生成的React组件库ZIP包、Design Token JSON文件、组件截图PDF。4.3 第6-12小时代码接口化AI Studio Storybook验证把Stitch ZIP包上传到AI Studio选择“React TypeScript Storybook”模板。AI Studio自动解析组件生成项目结构。关键动作是“Props API文档化”AI Studio输出《Props映射说明》首页按钮 → HomePageButton.props.onClick → router.push(/form)评分组件 → StarRating.props.value → data.professionalScore提交按钮 → SubmitButton.props.onSubmit → fetch(/api/v1/intern-eval, {...})我根据说明手动创建Storybook故事文件HomePage.stories.tsx展示首页按钮FormPage.stories.tsx展示带mock数据的表单data.professionalScore4, data.comments表现优秀SuccessPage.stories.tsx展示提交成功页启动npm run storybook在浏览器打开http://localhost:6006。HRBP亲自操作点首页按钮→跳转表单页→点第一颗星→数值变为1→点第五颗星→数值变为5→填评语→点提交。所有操作均成功控制台无报错。12小时结束时交付物是可本地运行的React项目、Storybook链接、Props映射说明PDF。4.4 第13-24小时后端对接与联调Postman 真实API验证此时前端代码已完备但后端接口不存在。我联系后端同事把Props映射说明PDF发给他重点标出“接口必须为POST /api/v1/intern-eval请求体必须包含department字段返回200表示成功返回400表示数据校验失败”。后端用Node.js快速搭了个Mock服务返回固定JSON。我用Postman测试发送POST请求body为{professionalScore:4,communicationScore:5,comments:优秀,department:hr}返回200response为{id:eval_abc123,status:submitted}再发一次故意把professionalScore设为6超范围返回400response为{error:professionalScore must be between 1 and 5}验证通过。我把Postman集合分享给HRBP教她用“Send”按钮测试任意数据组合。24小时结束时交付物是Postman测试集合、后端Mock服务地址、API契约文档。4.5 第25-48小时上线验证与真机测试Vercel 微信开发者工具把React项目推送到GitHub用Vercel一键部署得到测试链接https://intern-eval.vercel.app。HRBP用手机微信打开走全流程首页→表单→提交→成功页。同时我打开Chrome开发者工具Network标签页监控整个过程点首页按钮触发GET /formStatus 200填表提交触发POST /api/v1/intern-evalRequest Payload正确Response Status 200成功页触发GET /successStatus 200一切正常。但微信iOS版有个隐藏问题日期选择器不弹出。我立刻用微信开发者工具调试发现AI生成的代码里用了input typedate而微信iOS不支持。解决方案在AI Studio里加提示词“所有日期输入框替换为自定义DatePicker组件使用dayjs库”重新生成替换文件Vercel自动重新部署。最后邀请3位HR同事用真实微信扫码测试录屏观察。其中一人卡在“提交按钮点击无反应”排查发现是网络慢导致loading状态没及时显示我在按钮CSS里加了transition: opacity 0.3s问题解决。48小时结束时交付物是可公开访问的Vercel链接、微信扫码测试报告、最终版代码仓库。这个流程没有奇迹只有把每个环节的“模糊地带”用契约、约束、验证填满。HRBP全程参与她不需要懂React但能说出“StarRating组件的onChange函数必须把值传给data.professionalScore否则后端收不到”。这就是“非技术人也能看懂”的真实模样。5. 常见问题与避坑指南那些没人告诉你的“幽灵陷阱”在23个真实AI编程落地项目中我们踩过太多坑。有些坑明晃晃写着“Warning”有些坑藏在AI生成的代码褶皱里无声无息拖垮项目。我把最痛的8个“幽灵陷阱”列出来附上现场排查过程和根治方案。这些不是理论是凌晨三点改完代码后记在笔记本上的血泪。5.1 幽灵陷阱一AI的“过度工程化”——用复杂方案解决简单问题现象AI生成的登录页为了实现“记住密码”功能引入了Redux Toolkit RTK Query localStorage封装三层而业务需求只是“勾选后下次自动填充用户名”。现场排查HRBP说“登录页打开太慢”我用Chrome Performance面板录制发现首屏渲染耗时2.3秒其中1.7秒花在初始化Redux Store。打开代码发现store/index.ts里有200行配置features/auth/authSlice.ts里定义了login、logout、refreshToken、setRememberMe七个action。根治方案在AI提示词里加硬性约束“禁止引入任何状态管理库Redux、Zustand、Jotai所有状态用React useState管理禁止封装localStorage直接用localStorage.setItem/getItem记住密码功能仅需在登录表单增加checkbox勾选时localStorage.setItem(remember, username)登录时用useEffect读取并填充”。实测后登录页首屏渲染降至320ms。避坑心得AI天生倾向“炫技”它觉得用Redux才显得专业。非技术人员必须当“极简主义暴君”在提示词里用“禁止”“仅需”“必须”等绝对化词汇划清红线。每次看到AI引入新库先问“不用这个库能不能用三行代码实现同样效果”5.2 幽灵陷阱二CSS的“隐式继承”——样式在不同环境表现不一现象在Vercel预览链接里表单页完美但嵌入微信小程序web-view后所有按钮文字变成灰色且无法点击。现场排查微信开发者工具里选中按钮元素发现computed Styles里color是rgb(107, 114, 128)而设计系统要求是#1e293b。进一步检查发现AI生成的CSS里有button { color: inherit; }而微信web-view的父容器设置了color: #6b7280导致按钮文字继承了灰色。更糟的是pointer-events: none被意外加上。根治方案在Stitch的Design Token里强制添加button: { color: #1e293b, pointerEvents: auto }并在AI提示词里写“所有按钮CSS必须显式声明color和pointer-events禁止使用inherit或unset”。同时在项目根CSS里加全局重置button { all: unset; }。避坑心得AI喜欢用inherit偷懒但不同宿主环境浏览器、微信、小程序的默认样式树完全不同。非技术人员要养成习惯在Storybook里用“设备模拟器”切换iPhone、Android、微信看按钮颜色、点击反馈是否一致。不一致立刻加显式声明。5.3 幽灵陷阱三API的“静默失败”——请求发出去但业务没感知现象提交表单后页面卡在loading状态Network里显示POST请求200成功但HRBP说“没收到提交成功的通知”。现场排查看API返回JSON是{code:0,msg:success,data:{id:eval_123}}但AI生成的代码里fetch后只写了if (res.ok) { onOpenModal(); }没解析response.json()更没检查res.code 0。所以200状态码下代码认为成功但业务逻辑跳转/success页根本没触发。根治方案在Props映射说明里强制要求AI输出“API响应契约”必须包含{ code: number, msg: string, data: any }结构且成功判断条件为res.code 0。生成代码时模板固定为const res await fetch(/api/v1/intern-eval, options); const json await res.json(); if (json.code 0) { router.push(/success); } else { alert(提交失败${json.msg}); }避坑心得AI默认按HTTP状态码判断但真实业务API几乎都用code字段。非技术人员必须在原型标注里写死“成功响应必须返回code0失败返回code400/500”。这是比“点击按钮”更重要的契约。5.4 幽灵陷阱四移动端的“触摸盲区”——在手机上点不中按钮现象HRBP用iPhone测试说“提交按钮点十次只有两次生效”。现场排查用Chrome远程调试iPhone发现按钮的touch-action属性是none且min-height只有24px。iOS Safari要求可点击元素最小尺寸为44px×44px否则触摸事件会被忽略。根治方案在Design Token里强制button: { minHeight: 44px, touchAction: manipulation }并在AI提示词里加“所有可点击元素必须满足iOS最小触摸尺寸44px×44px禁止设置touch-action: none”。避坑心得桌面端的“视觉合理”不等于移动端的“可操作合理”。非技术人员必须把“真机测试”列为上线前必选项且测试机型至少包括iPhone SE小屏、iPhone 13主流、华为Mate 40安卓。每次新增按钮先用尺子App量一下屏幕上的像素尺寸。5.5 幽灵陷阱五权限的“硬编码幻觉”——把业务规则写死在前端现象权限配置弹窗里“管理员”选项被AI写死为option valueadmin管理员/option但实际权限体系有“超级管理员”“部门管理员”“普通管理员”三级。现场排查看后端API文档GET /api/v1/roles返回[{id:super_admin,name:超级管理员}, {id:dept_admin,name:部门管理员}]但AI生成的代码里角色下拉框是静态HTML没调用这个API。根治方案在原型标注里对权限下拉框写“此下拉框数据必须动态加载调用GET /api/v1/roles接口options.valueid, options.labelname”。AI提示词加“所有下拉框、列表数据若原型未标注‘静态’一律视为需动态加载必须生成useEffect fetch代码”。避坑心得AI默认把一切当静态因为它没见过API。非技术人员必须在原型里对每个数据源标注“静态”或“动态”并写明API路径。这是防止业务逻辑腐化的第一道防火墙。5.6 幽灵陷阱六表单的“脏检查失效”——用户改了数据却不提醒保存现象HRBP填完表单切到其他页面再回来发现数据没了抱怨“没保存提醒”。现场排查AI生成的表单组件里没有useEffect监听data变化也没实现beforeunload事件。用户离开时浏览器不会弹窗提示。根治方案在Props映射说明里强制要求“所有表单组件必须实现脏检查当data对象任意字段变化时设置isDirtytrue离开页面前若isDirtytrue弹窗提示‘数据未保存确定离开’”。生成代码模板固定包含useEffect(() { const handleBeforeUnload (e: BeforeUnloadEvent) { if (isDirty) { e.preventDefault(); e.returnValue ; } }; window.addEventListener(beforeunload, handleBeforeUnload); return () window.removeEventListener(beforeunload, handleBeforeUnload); }, [isDirty]);避坑心得用户体验的细节往往决定业务方是否信任AI。非技术人员要主动在原型里标注“需防丢失”就像标注“需权限控制”一样自然。这比“页面美观”重要十倍。5.7 幽灵陷阱七国际化i18n的“伪支持”——看似支持多语言实则硬编码现象项目要求中英文切换AI生成的代码里有TransSubmit/Trans但没配i18n库也没提供语言包。现场排查运行时报错ReferenceError: Trans is not defined。看代码AI引入了react-i18next但没初始化I18nextProvider也没创建en.json/zh.json文件。根治方案在AI提示词里用“三不原则”“不引入未配置的