一句话把脑子里的想法变成能点、能跳、能演示的小程序原型顺带把需求文档也吐出来——这事我最近真做成了靠的就是一个自己写的 Skill。先说清楚它是什么一个跑在 Codex 类智能体环境里的技能脚本输入是一句自然语言描述输出是一套可运行的 HTML 原型页面加一份结构化的 PRD 文档。适合谁看产品经理、独立开发者、接私活的前端、以及所有被先出个原型看看这句话折磨过的人。我踩过的坑、调过的参数、翻过的车下面全盘托出。1. 为什么我要把原型PRD打包成一个 Skill1.1 单独生成原型和单独写 PRD 的割裂感大多数人做原型的流程是这样的先在脑子里想清楚要什么然后打开设计工具画几屏画完发现逻辑对不上回头改改完再写 PRD写的时候又发现原型里漏了状态于是再回去补。这个来回拉扯的过程我做过不下二十次每次都要耗掉大半天。问题的根子在于原型和 PRD 本质上是同一份需求的两种表达。原型是给眼睛看的PRD 是给逻辑看的。你让两个独立的过程去产出它们中间必然产生信息损耗。我试过先写 PRD 再画原型也试过先画原型再补 PRD两种顺序都别扭——前者容易写成空中楼阁后者容易漏掉边界情况。所以我的思路很直接既然它们是同一份东西那就让同一个 Skill 一次性产出。输入一句话Skill 内部先做需求解析再同时生成 HTML 原型和 PRD 文档两者共享同一份中间数据结构。这样原型里有的页面PRD 里一定有对应的模块说明PRD 里定义的字段原型里一定能找到落点。1.2 一句话输入到底能承载多少信息有人会问一句话能说清楚什么我实测下来一句话的信息密度比想象中高得多。比如做一个宠物领养小程序首页展示待领养宠物列表点进去看详情能提交领养申请——这句话里已经包含了产品类型宠物领养、核心页面首页列表、详情页、申请页、核心动作浏览、查看、提交、数据实体宠物、申请。Skill 要做的不是凭空脑补而是把这句人话拆解成结构化的需求骨架然后基于常见产品实践补全合理细节。比如提交领养申请这个动作Skill 会自动补上表单字段姓名、联系方式、养宠经验、提交后的状态反馈成功提示、审核中状态、以及异常情况重复提交、信息不全。这些补全不是瞎编而是基于大量同类产品的通用模式。提示一句话输入的质量直接决定输出质量。建议至少包含产品类型核心页面关键动作三要素信息越具体补全的细节越贴合预期。1.3 Skill 相比直接对话智能体的优势在哪直接跟智能体说帮我生成一个小程序原型它也能给你吐 HTML但每次输出的结构、风格、完整度都不一样而且不会附带 PRD。Skill 的价值在于把怎么做固化下来固定的解析流程、固定的页面结构模板、固定的 PRD 章节格式、固定的输出文件组织方式。我对比过两种方式直接对话生成的 HTML十次里有三次缺 CSS、两次页面跳转是死链、五次没有空状态用 Skill 之后这些基础问题全部消失因为 Skill 的脚本里写死了检查逻辑。这就是 Skill 和裸对话的本质区别——它把经验变成了可复用的流程。2. Skill 的内部工作链路拆解2.1 从自然语言到需求骨架的解析层Skill 的第一步是把输入的那句话拆成结构化的需求骨架。我用的方案是让智能体先输出一份中间 JSON包含产品名称、目标用户、核心功能列表、页面清单、每个页面的元素和交互。这份 JSON 是整个 Skill 的中枢后面的 HTML 和 PRD 都从它派生。为什么要有这个中间层因为直接让智能体从一句话跳到 HTML它容易顾此失彼——写着写着忘了某个页面或者页面之间的跳转关系对不上。有了中间 JSON相当于先画了一张地图后面无论生成什么都是从地图出发不会跑偏。解析层的提示词我改过七八版关键经验是要求智能体对每个页面必须列出正常态、空状态、加载态、错误态四种状态。这一条加上之后生成的原型完整度提升非常明显因为很多原型工具的通病就是只画正常态一到空数据就露馅。2.2 HTML 原型的生成策略与页面组织HTML 原型这块我选择生成多个独立 HTML 文件而不是单页应用。原因很实际单页应用需要引入路由库或者自己写切换逻辑生成的代码量大、容易出错而且不方便单独打开某一屏给别人看。多个 HTML 文件之间用普通链接跳转简单直接用浏览器打开就能点发给别人也不用配置环境。页面组织上我固定了几个约定每个页面文件以页面名命名比如home.html、detail.html、apply.html所有页面共用一份style.css保证视觉统一页面顶部有一个模拟的小程序导航栏底部有 tab 栏如果产品有的话。这些约定写死在 Skill 里保证每次输出结构一致。生成策略上有个细节值得说我要求智能体在生成 HTML 时使用内联的模拟数据而不是留空。比如宠物列表页直接生成六到八条假数据每条有图片占位、名称、年龄、品种。这样打开页面就是满的演示效果远好于空列表。图片用纯色块加文字占位避免依赖外部图片资源导致加载失败。2.3 PRD 文档的章节结构与字段映射PRD 部分我参考了常见的需求文档结构固定了这么几个章节产品概述、目标用户、功能清单、页面详情、数据字段定义、交互流程、异常处理、非功能性需求。每个章节的内容都从中间 JSON 派生保证和原型一致。页面详情这一节是重点每个页面都要写清楚页面目标、包含元素、元素交互、跳转关系。数据字段定义这一节把每个数据实体比如宠物、申请单的字段名、类型、是否必填、说明列成表格。这个表格是给开发看的原型是给设计看的两者配合起来一份需求基本就齐了。注意PRD 里的字段定义要和原型里的展示字段严格对应。我在 Skill 里加了一条校验逻辑如果原型里出现了 PRD 没定义的字段就在输出末尾给出警告提醒补全。2.4 输出文件的组织与命名约定Skill 最终输出一个文件夹结构是这样的output/ prototype/ home.html detail.html apply.html style.css PRD.md requirements.jsonrequirements.json就是中间那份需求骨架保留它是为了方便后续修改——想调整需求改这个 JSON 再重新生成即可不用从头再来。这个设计是我迭代到第三版才加上的前两版每次改需求都要重新跑一遍完整流程很浪费时间。3. 手把手跑通第一个原型生成3.1 环境准备与 Skill 的安装位置Skill 本质是一个带提示词和脚本的文件夹放在智能体约定的技能目录下即可被识别。以 Codex 类环境为例技能目录通常在用户配置目录下的skills文件夹里。你把 Skill 文件夹整个拷进去重启智能体它就能在技能列表里看到。Skill 文件夹里我放了三个东西SKILL.md技能说明和提示词、template/HTML 和 PRD 的模板文件、scripts/辅助脚本比如文件组织、字段校验。SKILL.md是核心里面写清楚了技能什么时候触发、输入是什么、输出是什么、内部步骤有哪些。安装完先别急着跑复杂需求用一个最简单的例子验证链路通不通。我一般用做一个待办清单小程序能添加、完成、删除任务来测试这个需求足够简单出问题容易定位。3.2 一句话输入的写法与实测案例输入写法上我总结了几个模板实测下来效果稳定基础型做一个[产品类型]小程序[核心页面1]能[动作1][核心页面2]能[动作2]带角色型做一个面向[目标用户]的[产品类型]小程序主要功能是[功能描述]带约束型做一个[产品类型]小程序[功能描述]要求[特定约束如支持搜索、有分类筛选]实测案例我输入做一个二手书交易小程序首页能浏览书籍列表并搜索点进详情看书籍信息和卖家能发起私聊。Skill 输出的原型包含首页带搜索框和书籍卡片列表、详情页书籍信息、卖家信息、私聊按钮、聊天页消息列表和输入框三个页面PRD 里对应写了三个页面的详情和书籍、卖家、消息三个数据实体的字段。整个过程大概两分钟。3.3 生成结果的验收清单生成完不要直接交付先按这个清单过一遍检查项合格标准常见问题页面完整性输入提到的页面全部生成漏掉次要页面跳转连通性每个按钮点击有响应死链、跳转错页数据填充列表页有模拟数据空列表、占位符未替换状态覆盖有空状态和错误态只有正常态PRD 对应字段与原型一致字段名对不上样式统一各页面视觉一致字体、间距不统一这份清单是我踩坑踩出来的。最开始我只看页面能不能打开结果交付给同事演示时点了个按钮没反应当场尴尬。后来每次生成完都按清单过一遍问题基本能在交付前发现。3.4 常见报错与快速修复跑 Skill 的过程中遇到过几类典型问题。一类是生成的 HTML 里中文乱码原因是模板文件没声明 UTF-8 编码在head里加上meta charsetutf-8就好了。另一类是页面跳转链接写成了绝对路径本地打开找不到文件改成相对路径即可。还有一类是 PRD 生成到一半截断通常是输出长度超限。解决办法是把 PRD 拆成两次生成先出前半部分章节再出后半部分最后合并。我在 Skill 脚本里加了分段生成的逻辑超过一定长度自动拆分。4. 让原型更接近真实产品的几个关键调整4.1 模拟数据的真实感处理假数据假不假直接决定演示效果。我最初的版本用商品1、商品2、商品3这种占位演示时一眼假。后来改成让智能体根据产品类型生成贴合场景的数据比如二手书小程序就生成真实书名、作者、成色描述、价格区间。图片占位也有讲究。纯灰色块太单调我改成用 CSS 渐变加文字不同条目用不同色系视觉上丰富很多。如果产品对图片依赖强还可以用 SVG 画简单的示意图比色块更接近真实。4.2 交互反馈的补全技巧原型最容易忽略的是交互反馈。用户点了按钮总得有反应。我在 Skill 里要求每个可点击元素至少有一种反馈按钮点击后变色或出现提示、表单提交后显示成功状态、列表加载显示骨架屏。这些反馈用纯 CSS 和少量 JavaScript 就能实现不需要框架。比如按钮点击态用:active伪类提交成功用一个隐藏的提示层切换显示。代码量不大但演示时的完整度提升明显。4.3 空状态与异常态的补位空状态是原型的照妖镜。列表没数据时显示什么搜索无结果时显示什么网络错误时显示什么这些在真实产品里必须处理但原型阶段经常被跳过。我在 Skill 里强制要求每个列表页和搜索页都生成空状态用一个居中的图标加提示文字表示。异常态同理表单校验失败、提交重复、权限不足这些场景各生成一个提示样式。虽然原型不跑真实逻辑但把这些状态画出来评审时就能提前发现设计漏洞。4.4 样式统一与响应式适配多个 HTML 文件共用一份 CSS是保证视觉统一的关键。我把颜色、字体、间距、圆角这些设计变量定义在 CSS 顶部的:root里各页面引用变量改一处全局生效。响应式方面小程序原型主要在手机尺寸下看我固定用 375px 宽度作为设计基准用max-width限制容器宽度在桌面浏览器里居中显示模拟手机屏幕。这样在电脑上打开也是手机的样子演示时更直观。5. PRD 自动生成的细节打磨5.1 功能清单的颗粒度控制功能清单写太粗没用写太细冗余。我的经验是控制到一个功能点对应一个可验证的操作这个颗粒度。比如用户管理太粗用户能注册、能登录、能修改昵称、能修改头像就合适。Skill 里我让智能体从中间 JSON 的功能列表直接映射每个功能点必须包含功能名称、功能描述、涉及页面、优先级。优先级用 P0/P1/P2 标注P0 是核心链路必须有的P1 是重要但可延后的P2 是锦上添花的。5.2 页面详情与交互流程的对应关系页面详情和交互流程是 PRD 里最容易脱节的两部分。我的做法是让交互流程直接引用页面详情里的元素编号。比如流程写用户在首页点击搜索框元素1-3进入搜索页这样评审时能直接对照。交互流程我用文字加编号步骤描述不用流程图。原因是流程图在 Markdown 里不好维护改一个节点要重画文字步骤改起来方便而且智能体生成文字比生成图形稳定得多。5.3 数据字段定义的规范化数据字段定义我用表格呈现每个实体一张表字段包含字段名、类型、是否必填、默认值、说明。类型用通用的 string、number、boolean、array、object不绑定具体语言方便不同技术栈的开发者理解。字段命名我要求用驼峰式和前端习惯一致。这个细节看似小但能减少开发和产品之间的沟通成本——产品写的字段名和开发代码里的字段名一致对接时少一轮确认。5.4 异常处理与非功能性需求的补全异常处理这一节我要求覆盖三类输入异常必填未填、格式错误、业务异常重复提交、状态冲突、系统异常网络失败、超时。每类给出提示文案和处理建议。非功能性需求容易被忽略但评审时经常被问到。我固定写这几项性能首屏加载时间目标、兼容性支持的设备范围、安全敏感信息处理原则、可维护性代码组织约定。这些内容不用很细但要有体现需求考虑的完整性。6. 迭代过程中踩过的坑与经验6.1 生成内容过长导致截断的处理这是最常遇到的问题。一次生成三个页面加完整 PRD输出很容易超限结果就是后半截没了。我试过几种方案一是分段生成先出页面再出 PRD二是精简模板去掉冗余注释三是让智能体先输出目录再逐节填充。最终我采用的是分段加合并Skill 脚本控制生成顺序每段生成完写入文件最后合并。这样即使某段超限也只影响那一段不会全盘丢失。这个改动让生成成功率从大概六成提升到九成以上。6.2 页面跳转死链的排查方法死链问题排查起来烦人因为要一个个点。我后来写了个简单的检查脚本扫描所有 HTML 文件里的href提取目标文件名检查文件是否存在。不存在的列出来一目了然。排查之外更重要的是预防。我在 Skill 的提示词里明确要求生成跳转链接前先确认目标页面在页面清单里如果目标页面不存在要么补上要么改成提示功能开发中。这条规则加上后死链基本绝迹。6.3 字段不一致的自动校验思路原型和 PRD 字段对不上是隐蔽性很强的问题肉眼检查容易漏。我的方案是在 Skill 脚本里加一个校验步骤从 HTML 里提取所有展示字段通过约定的 class 名标记从 PRD 的 JSON 里提取所有定义字段两者做差集有差异就报警。这个校验不追求百分之百准确能抓住大部分明显的不一致就够了。实测下来它帮我发现了不少原型加了字段忘了写 PRD的情况。6.4 从原型到可交付 PRD 的最后一公里原型生成完PRD 也生成了但离真正能交付还有距离。我总结的最后一公里工作包括通读一遍 PRD 修正明显的语病和逻辑跳跃、补充项目背景和业务价值这类需要人来判断的内容、根据实际团队情况调整优先级、加上版本记录和修订说明。这些工作 Skill 做不了也不该做因为它们依赖具体业务上下文。Skill 的价值是把重复的、结构化的部分自动化把人的精力解放出来做真正需要判断的部分。认清这个边界用起来才不会失望。7. 这套 Skill 还能往哪些方向扩展7.1 接入真实设计规范的可能性目前生成的样式是我自己定的一套通用规范如果团队有现成的设计系统可以把颜色、字体、组件样式替换成团队的规范。做法是把设计变量抽成一个配置文件Skill 生成时读取这个配置。这样产出的原型直接符合团队视觉标准评审时少一层样式后面再调的扯皮。7.2 多端输出的改造思路现在输出的是 HTML 原型理论上同一份中间 JSON 可以派生出其他形态导出成设计工具的格式、生成接口定义的草稿、甚至生成测试用例的骨架。中间 JSON 这个设计的好处就在这里它是需求的抽象表达换一种输出只是换一个渲染器。7.3 与版本管理和协作流程的结合生成的requirements.json可以纳入版本管理每次需求变更改这个文件diff 一目了然。团队协作时原型和 PRD 作为产物提交中间 JSON 作为源文件维护形成源文件-产物的清晰关系。这个模式我在小团队里试过比直接改 HTML 再同步 PRD 靠谱得多。7.4 需求变更时的增量再生成需求变了不用从头再来。改中间 JSON 里对应的部分Skill 支持只重新生成受影响的页面和 PRD 章节。这个增量能力是我最近才加上的实现方式是在 JSON 里给每个页面和章节打上标识重新生成时对比标识只处理变化的。对于需求频繁变动的项目这个能力省下的时间很可观。最后分享一个我用了很久的小习惯每次生成完先自己当用户走一遍核心流程把不顺的地方记下来再决定是改输入重生成还是手动微调。原型这东西自己走一遍比看十遍都管用。