SECTION 01
会用 AI 的人,和"知道用 AI"的人,差在哪
先做个对照。同样让 AI 做一个"会员积分商城",两种人两种结局:
知道用 AI:"帮我做个积分商城"
AI 直接生成了一个看起来像样的商城页面。
但积分怎么算?兑换规则?风控?异常?全没定——因为提问的人自己也没想清楚。
结果:改 8 轮,最后推倒重来。
会用 AI:走四步工序
宣讲先定积分规则、兑换阈值、成功指标、范围声明,红队质疑一遍。
PRD 把每条需求写成可验收的规格,异常流全覆盖。
原型验证流程,再让 AI 照着编码、自测、部署、回访。
结果:一次到位,改动很少。
同一个模型,产出质量天差地别。差的不是 AI,是你有没有把"想法到上线"拆成标准工序。
CORE
知道用 AI 是"会发指令";会用 AI 是"会拆工序"。前者的产出靠 AI 发挥,后者的产出被你的工序兜住下限。
SECTION 02
为什么原型改来改去:把决策拖进了表现层
大部分人的工作流是:拿到需求 → 直接画原型 → 边画边改。问题不在原型,而在原型被迫同时承担了三件事:
- 探索方向——到底做什么、不做什么;
- 拍板决策——积分规则、边界条件、取舍;
- 验证细节——流程走不走得通、异常怎么处理。
方向没定、决策没拍,全压给原型,原型当然改来改去——因为每一处修改,背后都是一次本该更早发生的决策。
| 返工发生在哪一层 | 相对成本 | 发生频率 |
|---|
| 宣讲层(文字) | ×1 | 低 |
| PRD 层(规格) | ×10 | 中 |
| 原型层(表现) | ×100 | 高(没工序时) |
| 开发上线后 | ×1000 | 致命 |
METHOD
把最贵的问题,提到最便宜的层解决——这是整套工序的唯一目的。
SECTION 03
四步工作流:决策宣讲 → 标准 PRD → 交互原型 → AI 编码部署
下面就是鱼在真实项目里反复验证的四步工序。每一步的产出,都要过一道验收关卡,关卡不过,不进下一步。
01
决策宣讲(立项规划)——把方向和边界先说死
背景现状、方案总览、实施路径、成功指标、场景流程示例、存疑点、待决策点、范围声明、红队质疑、决策日志,一页纸讲清"要不要做、怎么做、做到什么算成"。
过关:方向没问题,红队质疑有回应
02
标准 PRD——把"决定"翻译成"规格"
需求分级、功能需求(带编号和验收表述)、指标与护栏、异常流、风险与假设。每条都可验收、可开发、可测试,每个"为什么"都能回溯到决策日志。
过关:无歧义,异常流全覆盖,无隐藏脑补
03
交互原型——只验证流程,不探索方向
关键路径完整可点通,状态与异常分支可见,标注 REQ/决策编号。方向在宣讲定,规格在 PRD 定,原型只负责让"文字上的成立"变成"点击上的成立"。
过关:用户走完一遍,说"这就是我要的"
04
AI 编码与部署——从原型到上线
让 AI 依据 PRD + 原型 + 决策日志直接编码,与 REQ 一一对应,覆盖异常流,自测走查,打包,部署,并回访线上确认与本地一致。你只做最后的验收。
过关:每个 REQ 有实现,线上回访一致,验收通过
第四步的部署细节,这篇不展开。平台选择、令牌安全、踩坑清单,在《发布上线篇》已经讲透了;从"上线可用"到"持续迭代、灰度、监控",鱼留到下一篇专门写。
SECTION 04
工序一:决策宣讲——最便宜的止损
宣讲是整套工序的灵魂,也是全部返工成本里最便宜的一次止损。这一层谈不拢,下面三层都不用做。
一份合格的宣讲必须包含这十块,缺一不可:
- 背景与现状 —— 为什么是现在做,痛点在哪;
- 方案总览 —— 整体怎么解,一句话 + 一个示意图;
- 实施路径 —— 分几步走,每步的输入输出;
- 成功指标 —— 可量化,且带护栏指标(不能因为做成这件事而变坏的东西);
- 场景流程示例 —— 挑一条关键路径,从头走到尾;
- 存疑点 —— 还没想清楚的地方,明确列出来;
- 待决策点 —— 每个给 2~3 个候选方案 + 你的倾向,而不是开放式问题;
- 范围声明 —— "做什么"+"不做什么"(不做什么至少 3 条);
- 红队质疑 —— 站最挑剔立场自问"什么情况下会失败",并给出回应;
- 决策日志 —— 已拍板的决策列表,编号 / 问题 / 决定 / 理由 / 日期。
RED TEAM
红队是宣讲的灵魂,不是摆设。方向错了,做得越快错得越远——红队是整套工序里唯一一道"踩刹车"的关卡。
SECTION 05
工序二:标准 PRD——把决定翻译成规格
PRD 不是把宣讲再抄一遍,而是把"决定"翻译成"规格"。判断标准很简单:开发照着它能不能直接动手,测试照着它能不能写出用例。
核心几件事:
- 需求分级 —— L / M / S 三级,标清优先级,避免小需求套满配模板;
- 功能需求带编号 —— 每条 REQ-xx 配 Given/When/Then 验收表述,可测试;
- 指标与护栏 —— 成功指标 + 反指标,明确数据来源;
- 边界与异常流 —— 断网、失败重试、超时、权限不足……每条都要有,这是开发阶段需求返工的最大来源;
- 风险与假设 —— 所有【假设】集中汇总,不隐藏脑补;阻塞缺口一次性问清楚。
还有一条容易被忽略的:PRD 要引用决策日志编号。每个"为什么"都能回溯——三周后开发问"这里为什么这么定",你不用重新解释一遍,翻日志就行。
SECTION 06
工序三:交互原型——只做一件事
到这一步,方向定了、规格定了,原型只负责验证一件事:流程走不走得通。
原型该有的
完整流程可点通
关键路径从入口到完成,每一步都能点,不是静态示意图合集。
原型该有的
异常分支可见
加载、空态、失败、重试、边界值,至少覆盖主要异常。
原型该有的
决策与埋点标注
页面上标 REQ/决策编号,关键位置标埋点,看的人知道"这里为什么这么做"。
一个省钱的中间步骤,鱼强烈建议:灰模走查。高保真之前,先画线框 + 状态流转表,把流程逻辑的错误先杀掉——线框上改一个流程,比高保真上改便宜一个数量级。
WHY IT WORKS
你的原型不用怎么改,不是画得好,而是方向、规格、异常全在前面定完了——原型只剩"验证"这一件事。
SECTION 07
工序四:AI 编码与部署——最后一公里
前三道工序的产出物(PRD + 原型 + 决策日志)齐了,就到了 AI 最擅长的部分:让 AI 照着实现,从代码到上线。
把三份产出物交给 AI,要求"严格按此规范实现"
代码与 PRD 的功能需求编号一一对应,覆盖异常流,基本自测。
AI 自测走查
交付前先"以用户视角"走一遍关键路径,截图或描述每一步,确认没有流程断裂。
打包 + 部署
按目标环境打包,部署到约定平台。静态站用 Cloudflare Pages 这类零成本方案就够,详见《发布上线篇》。
回访线上,确认一致
部署完成必须回访线上地址,确认内容与本地一致——这是最容易被忽略、也最容易翻车的一步。
你验收,过关才算完
对照工序三的验收标准走一遍线上版本,你说"过"才算完成。
部署细节(平台选择、令牌安全、踩坑合集)在《发布上线篇》。从"上线可用"到"持续迭代、灰度、监控",是下一篇的内容——这篇先把"从想法到上线"这条主线讲完。
相关阅读 · 发布上线篇
工序四的部署细节,都在这一篇
三分钟把 HTML 变成真网址 · 让 AI 替你发布 · 五个最常见的踩坑
去读发布上线篇 →
SECTION 08
把这套工序,装进一个 Skill
方法讲完了,直接给你可执行的资产。鱼把这套四步工序封装成了 idea-to-launch skill——一份写给 AI 看的、跨行业通用的工作流规范。把它连同你的想法材料一起发给任意 AI,说一句"严格按此规范执行",AI 就会按四道工序、每道工序带验收关卡地推进。
为什么强调跨行业:四道工序本身不挑行业——互联网产品、内容创作、内部工具、实体服务,都适用。差别只在"哪一块最该写细",skill 末尾附了一张行业适配表,用之前替换对应行即可。
idea-to-launch-skill.md · 四步工作流 · 跨行业通用
下载 .md
四道工序 + 铁律 + 反例清单 + 行业适配表,换成你的想法就能用。
在页内展开预览全文
加载中……
写在最后
AI 时代的个人壁垒,不是你会不会用 AI——那很快人人都会——而是你手里攒了多少套"把想法做成事"的工序。今天就从你手头最小的一个想法开始,走一遍这四步。
下一篇,鱼会把工序四的后半段补完:从"上线可用"到"持续迭代、灰度、监控"——产品上线不是终点,是运营的起点。敬请期待。