AI-Task案例 | 几分钟做出产品的新手教程

这不是炫技，而是一次思维方式的切换。我们把它写下来，是想说明一个事情：在 ai-task 这种工具出现之后，做事的”形状”已经变了。

传统做法：写一份新手教程要经历什么

如果按以前的标准流程做这件事——给一个产品加一套面向新用户的图文教程，大概的链路是这样的：

总耗时：1-2 周，至少 4 个角色，3 次会议。

更要命的是：每一次”用户看完发现写错了”——比如教程里写”挑一个 commit 发布”，但产品里其实根本没这个操作——都意味着整条链路再走一遍。文档工程师改完，前端可能还要改截图，QA 还要回归。

这次我们怎么做的

整件事是这样的——

第 1 句话：

在侧栏「官方反馈」按钮上方加一个「新手教程」入口，进去能看到给普通用户看的前端使用文档。

没有 PRD，没有原型图。

几分钟后：6 篇教程、侧栏按钮、独立视图、目录布局、Markdown 渲染、跳转链接，全都跑起来了。当场就能在测试环境点开看。

然后开始挑刺：

• “教程里链接显示成 undefined 了。” → AI 排查后发现是产品里早就存在的一个老 bug，顺手修了
• “应用形态那个多选很怪，明明只有一个选项。” → 改成单选 radio
• “Chat 和任务讲不清楚。” → 换比喻：Chat = 微信私聊，任务 = 微信群（多人并行）
• “你写的’挑 commit 发布’是错的，产品里根本没这一步。” → AI 直接去读发布页的源码，确认两条真实路径，把三篇教程一起改对

最后，全部上线。

整个过程：

• 1 个人（提需求 + 给反馈）
• 1 个对话框（不是一个 IDE、一个 Figma、一个 Confluence、一个 Jira 来回切）
• 0 次会议
• 每一轮反馈到看到结果，单位是分钟

思维方式的差异

这件事最关键的不是”AI 写代码很快”，而是做事的方法变了。

旧思维：先想清楚，再动手

传统流程的核心假设是：改动很贵，所以前置思考要尽量充分。

• 立项要把目标想全
• 设计要把界面想完
• 文档要把用例想透
• 开发开工就尽量不要返工

每一步都在试图”一次做对”，因为做错的代价很高——返工要拉人开会、协调档期、改文档、改设计、改代码。

新思维：先跑出来，再迭代

AI 把”做一版”的成本砍到接近 0 之后，逻辑反过来了：

先把 v1 跑出来，然后看着它说哪里不对，哪里改。

这听起来像废话，但它意味着：

• 你不需要在动手前把所有事情想清楚
• 你不需要在脑子里推演产品的样子，因为可以直接看到
• 你不需要为反馈道歉——反馈是流程的一部分，不是失败
• 你不需要为”写错了”内疚——错的不是你，是 v1 的假设，下一版改掉就好

这次教程系统从 v1 到 v4，每一版都不是”返工”，每一版都是把上一版当作真实存在的样品来评估。这种节奏，传统流程做不到——因为传统流程里”做一版样品”本身就要 1 周。

还有一个隐性差异：你不再需要”翻译”自己

旧流程里，产品经理要把脑子里的想法翻译成 PRD，给设计；设计要再翻译成视觉稿，给前端；前端再翻译成代码。每一道翻译都会丢信息，于是最后做出来的东西经常是”似是而非”。

ai-task 里你直接说：”这里讲不清楚，换成微信群的比喻试试。” AI 听懂、改完、上线。没有中间人。

为什么是 ai-task 能做到，而不是直接用 ChatGPT

很多人会问：这不就是用 ChatGPT 写代码 + 自己粘贴吗？不是。

中间最关键的差距是：ai-task 不是一个聊天工具，而是一个能直接动你产品的工程师。

具体到这次教程系统的开发，ai-task 干了下面这些”聊天工具干不了的事”：

1. 它认识你的代码库 — 知道侧栏按钮叫 feedback-entry-btn，知道页面用 hash 路由，所以新按钮放在哪里、视图怎么注册、跳转用什么协议，都不用你教
2. 它直接改 git 仓库 — 每一轮迭代都对应一个真实的 commit，不是”AI 给你贴一段代码”。改坏了能 revert，PR review 一目了然
3. 它能就地验证 — 改完直接进测试环境，几分钟内你能在浏览器里点
4. 多轮对话有连续性 — “再改一下这里”、”前面那个比喻还是有问题”，这些”懒得复述上下文”的指令它能接住
5. 它会自己读源码确认 — 用户说”挑 commit 发布是错的”，AI 不会反驳也不会硬猜，**它去读了 deploy-details.html**，用代码里真实的判定条件还原产品形态，然后改文档
6. 改动跨越内容 / 代码 / 样式 / 配置 — 一次对话里既写了 6 篇 markdown，又改了 JS、HTML、CSS、缓存版本号；这些文件之间的引用一致性它自己保证

这 6 件事，每一件都对应传统流程里的一个”角色”——产品、前端、QA、内容运营、SRE、技术负责人。ai-task 把它们装到了一个对话框里。

这件事的”杠杆”在哪

把这次教程开发当成一个杠杆样本，可以看到三个维度的放大：

最后一行，看似不重要，其实是这件事最大的红利。它解放的是你”不敢做”的那部分事——以前因为”动起来太麻烦”而搁置的小优化、小改进、小内容。

这意味着什么

简单说三句：

1. 以前”成本不允许做”的事，现在可以做了——比如给一个老产品补一套教程，给一个内部工具加一个引导页，给一份说明书做一次润色
2. “想清楚再做”的纪律可以放松——可以”做出来再想清楚”，因为做出来比想清楚更便宜
3. 一个人能干的事比以前多得多——这是真正意义上的”独立创作者”工具

如果你做产品、做内容、做小型自研工具，ai-task 想给你的就是这种**”想到就能做、做了就能改、改了就能上”**的节奏。

给读者的一句话

别给 AI 写需求文档。直接说：我想要一个 X，加上去看看。

剩下的，让 ai-task 跑给你看。

ai-task项目地址：https://ai-task.yuban.site/