做一人公司，最容易陷进去的阶段，往往不是产品上线以后，而是还没开始之前。

你可能有一个想法，知道自己想服务某类人，却迟迟说不清第一步该做什么：先访谈用户，还是先写代码？产品做到什么程度可以收费？客户从哪里来？什么时候该加功能，什么时候应该停手？

这些问题，单靠 Agent 给一个漂亮答案，意义不大。真正有用的地方在于：把问题拆开，按顺序处理，并且让每一步都尽量接触真实用户。

最近看到一个开源项目，把 Lavingia 的创业方法论拆成了 10 个可以交给 Agent 调用的 Skill。它们覆盖了从找人群、验证想法，到定价、获客和复盘的一整段过程。

这套 Skill 解决的，是“下一步做什么”

《小而美》这类创业方法论，读完以后很容易产生一种错觉：道理都懂，真正落地时还是不知道从哪里下手。

把内容拆成 Skill，变化在于它不再只是一本书里的观点，而变成了一个个具体入口。你遇到“还没找到用户”的问题，就调用 find-community；产品已经做出来，却不知道怎么卖，可以看 first-customers。

项目在 GitHub 上获得了不少关注。

但 star 数量只能说明有人在看，不能证明它适合所有项目。我的判断是，这套 Skill 更适合早期产品、独立开发和小规模服务业务。已经有成熟团队、明确渠道和复杂组织流程的人，未必需要把每一步都重新拆一遍。

0. 小红书图文一句话生成与发布 skill

同样的拆分方式，也可以放到内容生产里。

【红鸦小红书图文 Skill】的名称是 redya-xiaohongshu，由红鸦 AI 提供，可以安装到 WorkBuddy、Codex、Claude Code、Cursor 等 Agent 工具中。输入主题后，它会生成小红书标题、发布正文和逐页图片提示词，还能继续批量生成整套图片；普通图文、知识型图文和商品带货图文都可以处理。

商品模式下，可以先上传商品资料建立商品档案，再关联档案创作；有多篇内容时，也支持一次处理多篇图文任务。

GitHub 仓库地址：

https://github.com/rnthking/redya-skills

使用这个 Skill 需要个人 API Key。进入“红鸦 Skills”页面获取即可。API Key 是账号凭证，不要放进公开截图、公开仓库，也不要转发给别人。

拿到 Key 后，可以把下面这段安装任务交给 WorkBuddy、Codex、Claude Code 或 Cursor。让 Agent 先检查当前环境，再完成安装、配置和连接验证，通常比手动找目录更省事。

请帮我安装「红鸦小红书图文」能力到当前 AI 环境：

1. 下载 https://hy.ithinkai.cn/openapi/skill.md 的内容，保存为 ~/.claude/skills/redya-xiaohongshu/SKILL.md
2. 设置环境变量 REDYA_API_KEY=rk-你的APIKey
3. 设置环境变量 REDYA_BASE_URL=https://hy.ithinkai.cn

装好后我要用它生成小红书图文笔记。

安装完成后，可以先让 Agent 生成标题、正文和每页图片大纲。先检查结构，再决定哪些页面需要出图，适合对内容顺序和视觉表达有要求的情况。

如果只是想快速处理一个主题，也可以直接把主题交给 Agent，让它连续完成文案和整套图片。

也可以打开红鸦 AI 网页端，在可视化界面里输入主题或文章素材。标题、正文和每页图片提示词都能继续调整，确认后再批量生成图片。

做商品图文时，可以先关联商品档案，让每一页参考对应的真实商品图。这样处理商品信息时，画面、文案和商品资料更容易保持一致。

Agent 和网页端共用同一个红鸦账号与积分，生成内容会保存到“我的创作”，后面可以继续查看和处理。

想在 WorkBuddy、Codex、Claude Code 或 Cursor 里直接调用，就安装 redya-xiaohongshu；更习惯在页面里编辑标题、正文和图片提示词，则使用红鸦 AI 网页端。
 

1. find-community：先别急着想产品

如果你只有一个模糊方向，比如“想做 AI 工具”“想服务创作者”，这还不算产品想法。

先问自己：你认识哪些人？能进入哪些社区？愿意长期听谁的问题？find-community 适合用来整理这些线索，最后得到一批更具体的人群和社区，而不是一张泛泛的用户画像。

可以直接输入：

我想做一个小产品，但还不确定服务谁。请根据我的经历、资源和可接触渠道，帮我筛选几个适合深入了解的社区。

它不能替你找到“最好的市场”。你仍然要进去聊天，听别人怎么描述问题。

2. validate-idea：把“我觉得需要”变成证据

很多产品想法都来自自己的不方便。问题是，自己的痛点不一定足够普遍，也不一定有人愿意付钱解决。

validate-idea 可以帮你设计访谈问题、验证步骤和早期测试方案。比较有用的输出，应该包括：要找谁聊、问什么、观察哪些行为，以及什么信号可以继续，什么信号应该停下来。

比如：

我想做一个面向小团队的知识库工具，请帮我设计 10 次用户访谈，并列出不能只听口头表达、还需要观察的行为。

这里要特别小心 Agent 的“市场判断”。它能帮你准备问题，但无法替你完成访谈，更不能把几句“听起来不错”当成购买意愿。

3. mvp：砍掉那些暂时没人需要的功能

独立开发最常见的拖延方式，是不断完善第一版。

登录、权限、后台、数据看板、自动化流程……每一项单看都合理，加在一起，产品可能三个月还没见到用户。

mvp 的任务，是把想法压缩到一个能够尽快交付的版本。可以让它回答：

这个产品如果只能保留一个核心动作，用户必须完成什么？请按一个周末能做完的标准，列出 MVP 范围，并标记所有可以延后的功能。

我比较认同这种用法。MVP 不是“功能少一点的正式产品”，而是一次验证用户是否愿意使用、愿意留下反馈，甚至愿意付费的实验。

4. processize：先用人工服务跑通

有些人一想到服务，就开始设计系统。

其实很多业务一开始根本不需要系统。比如资料整理、内容审核、报告生成、定制咨询，这些事情完全可以先人工完成几次，看看客户到底在意哪个环节。

processize 可以把一次服务拆成输入、处理、交付和复盘。这样做的好处，是你会更早发现真正重复的部分。

可以这样问：

先不开发软件。请把这项服务拆成一套人工可执行的流程，并指出完成 5 次交付后，哪些环节最值得自动化。

这里有个实际判断：如果一项服务还没有稳定交付过几次，自动化通常只是把猜测写进代码。

5. first-customers：把“找客户”拆成动作

产品做出来以后，最难受的时刻经常到来了：没人主动来。

first-customers 会帮助你整理潜在客户来源、触达顺序和沟通方式。熟人、已有社区、垂直内容渠道、陌生邮件，应该分别尝试，而不是一上来就做一套宏大的增长计划。

输入可以是：

我的产品已经能完成核心功能，请按每天 1 到 2 小时的投入，设计一个获得第一批付费用户的行动计划，并区分验证动作和销售动作。

“前 100 个客户”不适合所有项目。高客单价定制服务，可能几十个客户就已经很重；一个小众工具，也不一定需要追求这个数字。Skill 能帮你拆目标，但目标本身仍要结合业务模型调整。

6. pricing：先做一个能被验证的价格

定价不是找一个看起来顺眼的数字。

可以让 pricing 结合客户类型、交付成本、替代方案和产品价值，给出几个价格假设，再设计验证方法。例如，先给三位真实客户报价，观察他们的问题是“太贵”，还是“还没理解价值”。

可以这样提问：

请给这个产品设计三档初始价格，并说明每档适合什么客户、包含哪些边界，以及我应该如何用真实交易验证。

它输出的是价格假设，不是定价真理。没有真实交易，价格表再完整也只是文档。

7. marketing-plan：先找一条能坚持的渠道

早期项目不适合同时经营五六个平台。

marketing-plan 可以帮助你围绕目标用户设计内容、社区、邮件或合作渠道。不过，计划里最好明确每周投入多少时间、发布什么、看什么指标，否则最后只会得到一份“持续输出、建立品牌、扩大影响”的空计划。

8. grow-sustainably：增长之前先问一句“有必要吗”

有了收入以后，人很容易开始做加法：招人、投广告、扩功能、上新渠道。

grow-sustainably 更适合用来做扩张前的检查。它可以帮你比较新增收入、额外成本、管理复杂度和更轻的替代方案。

如果现有业务还没有稳定交付，或者创始人本人仍然是所有流程的瓶颈，扩张往往只是把问题放大。

9. company-values：把不想做什么也写下来

价值观不是公司介绍页里的几句漂亮话。

对一人公司来说，它更像一组取舍规则：接不接定制需求？要不要为了大客户改变产品方向？遇到短期收入和长期原则冲突时，怎么选？

可以让 company-values 帮你写出 3 到 5 条决策原则，再拿最近遇到的真实问题去测试。如果这些原则无法帮助你做选择，就还不够具体。

10. minimalist-review：定期删东西

项目做久以后，复杂度会悄悄增加。

一个功能、一条流程、一个营销渠道，看起来都舍不得删，最后创始人每天忙于维护，却说不清哪个动作真的带来了客户。

minimalist-review 可以用来检查功能、流程和增长计划，要求 Agent 明确列出：保留什么、删除什么、合并什么、暂缓什么。

可以输入：

请从用户价值、收入贡献和维护成本三个角度审查这份功能列表，给出删除和延后的具体建议，并指出判断依据。

这 10 个 Skill 串起来，大致是一条早期创业路径：

找到人群，验证需求；先手工交付，再做 MVP；找到客户，测试价格；建立一条可持续的获客渠道；增长时保持克制；定期清理复杂度。

它最适合用来减少“凭感觉推进”的时间。至于用户是不是真的需要，仍然要靠你去聊、去交付、去收钱。

book2skill：把书里的方法拆成工作流

看到这套项目后，一个自然的问题是：创业书可以拆成 Skill，其他资料呢？

我自己做了一个 book2skill，思路就是把书籍、课程文稿、文章合集或播客逐字稿里的方法，整理成 Agent 可以调用的独立 Skill。

它比较适合处理这类材料：里面有明确流程、判断条件、检查清单，或者可以反复执行的一套方法。

如果只是观点、故事和案例很多，却没有清晰的行动步骤，转换出来的 Skill 往往会变成一篇结构化摘要。看起来完整，实际调用时还是不知道怎么做。

它的转换过程，不能完全交给 Agent

安装后，可以输入书名或资料，让 Agent 尝试检索和整理。这个过程通常包括：

• 核对书名、作者和版本信息
• 提取核心方法与适用场景
• 筛选可以执行的流程和判断条件
• 生成 Skill 文件及调用说明
• 输出检查结果并打包

但这里有一个容易被忽略的限制：检索到的资料不一定完整，书名相近、版本不同、二手摘要失真，都可能影响结果。

所以，比较稳妥的做法是把它当成“初步整理器”。生成后要回到原书或原始资料，核对关键观点、案例和引用，尤其不要把网络摘要直接当成作者原意。

我会优先保留四类内容：输入是什么，具体怎么做，什么时候停止或切换，以及最终应该得到什么结果。只有这些边界写清楚，Skill 才不会变成一段泛泛的提示词。

Skill 适合沉淀什么

我现在更愿意把 Skill 看成“固定思路的工作入口”，而不是一个替你完成全部工作的专家。

《小而美》的 10 个 Skill，适合把创业早期那些容易混在一起的问题拆开。book2skill 适合把一套方法整理成可重复调用的结构。红鸦这个 Skill，则更偏向把内容选题、文案和图片制作接到同一条流程里。

它们都有一个共同前提：输入材料要靠谱，输出之后要检查，关键判断仍然要回到真实场景。

如果你还没有用户，先别忙着把流程自动化；如果资料本身没读懂，也别急着把它包装成 Skill。对一人公司来说，能持续删掉无效动作，往往比再增加一个工具更难，也更重要。