如何用 WorkBuddy 做出产品 Demo
很多人以为做产品 Demo 一定要会写代码、会设计页面、会搭前端环境。实际上，如果目标是做一个用于售前沟通、方案汇报或内部评审的演示 Demo，真正关键的不是技术门槛，而是能不能把"这个 Demo 要讲什么"说清楚。
01 先确定 Demo 给谁看
如果是给客户演示，就要让对方快速看懂系统解决什么问题、业务怎么流转、价值在哪里；如果是内部评审，就要突出功能边界、流程合理性和后续开发方向。演示目标越清楚，WorkBuddy 生成的内容越不容易跑偏。
一个好 Demo 通常不追求大而全，而是先把核心闭环跑通。
比如从申请、审核、执行、反馈到归档；或者从用户进入、选择服务、提交信息、查看结果到后续跟进。只要主线清楚，页面数量少一点也能讲明白。
图2：从模糊需求到可演示 Demo 的通用流程。
03
先做轻量版本，让流程跑起来
第一版 Demo 不需要连接真实后台，也不需要一开始就做成完整系统。更实用的方式，是把需求文件丢给 WorkBuddy，让它用模拟数据先做一个轻量版本：能打开、能切换页面、能点击关键按钮、能展示核心流程状态变化。
这样做的好处是修改成本低。你可以先判断业务表达是否正确，再决定要不要补页面、补角色、补交互。相比一开始就追求复杂功能，轻量版本更适合售前和方案阶段快速验证思路。
04
用截图反馈问题，而不是只说不好看
Demo 做出来后，普通人最有效的反馈方式是截图。哪里错位、哪里看不懂、哪里文字太多、哪里不符合业务，都可以直接圈出来发给 WorkBuddy。截图比一句"页面不好看"更容易让 WorkBuddy 定位问题。
更重要的是，不要只改样式，还要追问设计意图。如果某个图表看不懂，可以直接问："这个模块想向客户表达什么？"有时候真正的问题不是颜色和位置，而是这个模块本身没有讲清楚业务含义。
图3：同样是让 WorkBuddy 做 Demo，输入方式不同，产出质量会明显不同。
05
用客户会问的问题补齐闭环
一个 Demo 是否可信，往往取决于客户追问时能不能讲下去。比如数据从哪里来，谁来处理，处理后如何反馈，异常怎么闭环，移动端和后台如何协同。这些问题如果没有提前想清楚，页面再好看也容易显得空。
可以把这些问题直接抛给 WorkBuddy，让它按"轻量化可演示"的方式补进 Demo。注意，这里不是要求它做完整系统，而是让演示逻辑更完整，让客户知道这件事在系统里是怎么被承接的。
06
最后交付的不只是页面
一个可用的产品 Demo，最好同时准备几类交付物：可以浏览器打开的页面、可点击的核心流程、模拟数据、现场演示动线、完整界面截图，以及可回退的版本。这样 Demo 不只适合现场操作，也能放进方案、PPT 或汇报材料。
版本管理也很重要。每次关键调整都建议另存新版本，不要直接覆盖旧版。售前过程经常会反复变化，保留版本能减少返工，也方便回看每一轮修改到底解决了什么问题。
图4：一个合格的产品 Demo，不只是页面，还包括演示和交付材料。
可以直接复用的提示词
我需要做一个给客户演示的产品 Demo，目前资料不完整。请你先从产品经理角度判断 Demo 应该演示哪些核心流程，不要做功能堆砌。
请按轻量化可演示版本实现 Demo，使用模拟数据，重点让业务主线能跑起来，页面要适合现场讲解。
这个模块我看不懂设计意图，请解释它想表达什么业务含义。如果表达不清，请重新命名并调整页面元素。
客户可能会问这些问题：数据从哪里来、谁负责处理、异常如何闭环。请按轻量化方式补充到 Demo 中。
请保留旧版本，新建增强版 Demo，并导出完整界面图片，方便放进方案或 PPT。