从Skill到应用，看似一步之遥，实则天壤之别。本文作者在将已验证的AI协作能力封装成独立应用时，遭遇了产品形态、成本模型、权限边界等多重挑战。文章详细复盘了这一过程，揭示了Vibe Coding时代产品决策的核心价值——AI能加速代码，但方向与边界仍需人来定义。

这两天，我准备把几个效果不错、同时具备通用能力的 Skill 做成一个工具，让更多项目经理、售前、产品经理和实施人员可以直接使用。

最终结果预览：AI按照确认后的方案完成了第一版Windows客户端及安装包。

原本我以为，既然 Skill 已经跑通，把它放进一个应用界面应该不会太难。真正开始以后才发现：从想法到 Skill，和从 Skill 到应用，完全不是一个量级。

Skill 解决的是“AI 应该怎么做”；应用还要解决“谁来用、在哪里运行、需要什么权限、成本由谁承担，以及如何稳定交付”。

01 为什么我想把 Skill 做成应用

起点其实很简单：我做的几个 Skill 被同事使用后，反馈比较好，后来还有同事被推荐过来使用。这让我产生了一个想法——与其每次单独分享 Skill，不如把这些能力组合成一个应用。

我设想的应用可以围绕项目交付自动生成文档，例如模块级汇报材料、操作级功能清单、用户手册和其他项目文档。用户只需要输入链接或视频，系统就能生成对应文档。

目标用户也比较明确：项目经理、售前、产品经理、实施人员，以及需要准备软件著作权材料的人。

02 从想法到 Skill，为什么相对容易

从想法到 Skill，本质上是把一段已经验证有效的协作过程固化下来。

把已经验证有效的对话过程整理成“生成用户手册”Skill。

先和 AI 交互、调试，通过多轮迭代得到满意结果，再让 AI 把前面的目标、步骤、规则和验收标准总结为 Skill。

后面发现结果需要优化时，可以同时修改 Skill，让方法随着实践一起迭代。

结果不满足要求时，继续补充交付标准，并同步优化Skill。

从想法到skill主要解决三个问题:

1. 明确输入：需要用户提供什么材料。
2. 固化过程：AI 应该按照什么顺序工作。
3. 统一结果：输出需要符合的格式和验收标准。

只要原来的方法已经跑通，沉淀 Skill 更多是一次结构化整理。它仍然运行在AI 工具中，不需要单独处理账号、部署、计费和产品界面。

03 从 Skill 到应用，正确顺序比写代码重要

从 Skill 到应用，我后来总结出一条更稳妥的路径：先分析，再定方案，最后才写代码。不要一上来就让 AI 开始开发，而是先把脑海里的想法变成一个能够验证、能够取舍的产品方案。

这一步看起来像是在“耽误开发时间”，实际上是在减少后面的返工。因为一个应用不只是多了一个界面，它还会牵扯产品载体、账号体系、数据采集、模型调用、文档生成、支付方式和部署成本。

开发前先做可行性分析：确认产品形态、能力边界、技术难点和商业模式。

1. 先让 AI 做一份可行性分析

我先把自己的设想尽量完整地告诉 AI：希望把自动生成用户手册的 Skill 做成应用，用户输入系统链接后，应用自动采集页面并生成 Word；同时说明目标用户、初步收费方式和期望的使用流程。

这份分析让我第一次看到，原来我以为只是“把 Skill 套一个界面”，背后其实包含了页面采集、任务服务、AI内容生成、Word排版、账号与订单等多个模块。

2. 根据分析结果，重新调整自己的想法

可行性分析不是为了证明原来的想法正确，而是帮助我发现原方案中没有想清楚的地方。比如：是否强制采集固定数量的页面、能否自动发现所有菜单、生成不完整时怎么提醒用户，以及浏览器插件是不是唯一合适的载体。

这一步还要明确哪些动作可以自动完成，哪些动作必须由用户确认。例如，应用可以采集页面结构、文字和截图，但不能擅自执行保存、删除、审批或发布等业务操作。

3. 把最终想法整理成实施方案

方向调整完成后，我再让 AI 输出完整的实施方案。这里不能只写“做一个生成用户手册的应用”，而要把功能范围、页面流程、技术结构、接口关系、异常处理和验收标准都说清楚。

如果你懂一些前后端技术，可以继续要求 AI 把方案拆细；

这一步千万不要贪多。第一版不是把所有设想都实现，而是验证“输入一个链接，应用能否采集有效页面，并生成一份可用的用户手册”这条最核心的闭环。

4. 方案确认后，再让 AI 开发 MVP

实施方案确认后，才进入真正的 Vibe Coding 阶段。先完成最小可运行版本，再逐步补充页面发现、采集范围选择、Word预览和完整文档生成。

开发过程中，主要关注核心流程能不能跑通：能不能创建任务，能不能打开目标系统，能不能发现菜单和页面，能不能避免重复采集，最后能不能生成结构正确的 Word。

5. 用真实结果测试，再逐项修复

第一版生成以后，再基于真实操作提出优化点。每次修改都尽量围绕一个具体结果，这样 AI 更容易判断应该改页面、流程、规则还是文档结构，也能减少一轮修改牵动整个项目。

6. 上线前，补齐开发阶段看不到的配置

本地能运行，不等于已经可以上线。正式使用前，还需要补齐模型API、服务端地址、登录与支付接口、数据存储、安装包签名、隐私政策和异常日志等配置。

04 这次 Vibe Coding，我踩了哪些坑

第一个坑，是方案没想清楚就做 MVP。后面方向发生变化，AI 需要重新修改，浪费了时间、精力和 Token。

第二个坑，是没有提前确定应用的呈现方式。

第一版我选择了浏览器插件。它可以读取当前页面，在浏览器侧边栏中创建任务、采集页面并生成用户手册。从功能上看，这个方案已经能跑起来。

第一版采用浏览器插件：在侧边栏中完成授权、页面采集和用户手册生成。

但继续梳理真实使用流程后，我发现这类工具并不只是一个网页辅助插件。它还涉及登录、任务管理、专用浏览器采集、页面发现、云端生成和文档交付。相比被限制在浏览器侧边栏里，独立客户端更适合承载完整流程。

调整后的客户端版本：将登录、创建任务、页面发现和手册生成组织成完整流程。

于是，我又把已经做出的插件改成了客户端。界面要重新规划，交互流程、登录方式和页面采集方案也要跟着调整。

产品载体不是开发完成后的包装，而是实施方案的一部分。如果一开始没有想清楚用户在哪里使用、需要完成哪些连续动作，MVP 即使能运行，也可能验证了错误的产品形态。

第三个坑，是混淆了编程套餐与应用 API。个人购买的 Coding Plan 用于辅助开发，并不等于可以直接作为个人应用或商业应用的模型调用能力。应用需要接入符合使用范围的标准开发 API。

第四个坑，是忽略了持续运行成本。应用开发完成以后，即使暂时不迭代，只要持续调用大模型，就会持续产生费用。开发前必须估算调用频率、单次消耗和用户规模。

第五个坑，是所有功能都想交给模型。有些功能使用确定性规则实现得更稳定、更便宜。功能拆分时，应先判断哪些需要语言理解，哪些只是格式转换、字段校验或固定流程。

05 我现在对 Vibe Coding 的理解

Vibe Coding 降低了写代码的门槛，却没有消除产品决策。不会写代码的人也可以做应用，但仍然要回答产品经理一直在回答的问题：用户是谁、问题是什么、第一版验证什么、成本能否接受、结果如何验收。

AI 可以帮助我们分析方案、生成代码和修复问题，但产品形态选错、权限理解错误、成本模型不成立，这些问题不会因为代码生成得快就自动消失。

从想法到 Skill，是把经验固化下来；从 Skill 到应用，是把经验变成别人能够稳定使用的产品。

代码可以由 AI 加速。但方向、边界和成本，仍然需要人想清楚。