自打我做 AI 内容之后，我每天都会接触大量的新工具。

老朋友应该知道，我经常测试新的编程 Agent，也会持续研究各种模型。

白天体验产品，晚上整理内容、写文章、做配图，已经成了固定节奏。

以前我觉得，AI 的价值就是帮我更快完成这些事情。

但工具越用越多，我反而发现了一个问题：

工具增加了，工作并没有变简单。

一个产品测试完，要整理体验和优缺点；

文章写到一半，要重新调整方向。

我开始意识到，真正的问题在于 Agent 能不能真正融入我的工作流程。

前段时间刷 GitHub 时，我看到一些有意思的 Skill 项目。

有人开始把自己的工作方法、经验和判断标准整理出来，让 Agent 在执行任务时可以直接参考。

我突然想到，

如果把一个人的日常工作拆成不同岗位，

再给每个岗位配上一套 Skill，

会不会真的能搭出一个 AI 工作团队？

于是我找了 6 个不同方向的 Skill。

从产品分析、开发协作，到内容创作、销售推进和财务管理。

这篇文章，就带大家看看这些 Skill 到底能不能帮一个人搭起一套 AI 工作团队。

solo-analyze 先把错误方向拦下来

很多一人公司的问题，往往出现在第一步。

想到一个新点子，马上让 AI 帮忙分析市场、用户和商业模式，很快就能得到一份看起来完整的方案。

但真正需要想清楚的是，

谁会为这个产品付费？

为什么他们现在愿意购买？

你有没有足够的优势接触到这批用户？

我选中的第一个 Skill 就是 solo-analyze，来自 solo-founder-playbook。

 

这个项目把 101 篇创业者访谈中的模式整理成六个面向独立创业者的 Skill。

solo-analyze 负责评估一个点子的市场、获客、创始人匹配度和潜在风险。

它像一场立项前的压力测试，专门给兴奋的创意降温。

我会用这种任务来试它。

我准备做一个面向小型健身房的 AI 续费提醒工具。请用 solo-analyze 评估这个想法，重点检查付费意愿、获客渠道、创始人优势和最可能失败的三个原因。最后给出继续、缩小范围或放弃的建议。

它最有价值的输出，可能是让你在写第一行代码前砍掉一个伪需求。

但这里又需要注意的点：

101 篇访谈提供的是历史模式，无法代替今天的实时市场数据。

遇到价格、竞品和行业变化，仍然需要补充真实的一些数据。

prd-development 把模糊想法压成可交付范围

方向确定以后，先把要做的东西整理清楚。

一人公司开发产品时，很容易把各种想法混在一起。

用户需求、页面设计、功能列表、商业目标全部堆在脑子里，

今天觉得登录功能重要，明天又想优先做支付。

结果忙了两周，回头看却很难说清楚，

这个版本到底服务谁，又解决了什么问题。

prd-development 来自 Product-Manager-Skills。它把用户问题、产品方案和验收标准整理成结构化 PRD，让开发前的思考更加清晰，也减少后续反复修改。

 

我看中它，还有一个原因：

它适合帮助一人公司控制产品范围。

一份适合独立开发者的 PRD，需要先把几个问题想清楚。

用户为什么需要这个产品？

第一版准备交付哪些功能？

哪些需求暂时不做？

上线以后，用什么标准判断它有没有价值？

可以这样给任务：

把下面的产品想法整理成一份两周内可以完成的 MVP PRD。先明确核心用户和使用场景，再输出用户流程、功能范围、验收标准，以及明确不做的内容。功能数量控制在五项以内。产品想法是……

这里有几个很关键的限制。

“两周”“不超过五项”“明确不做”，会迫使产品范围保持在一个人可以完成的程度。

如果没有这些约束，即使 PRD 写得很专业，

也容易变成一份规模过大的产品规划。

Skill 可以帮你整理思路、补充遗漏，

但最后决定做什么、放弃什么，还是需要创始人自己判断。

一份清晰的 PRD，能让执行过程少走弯路，但产品有没有价值，最终还要交给真实用户验证。

gstack 给交付环节补上一支工程小队

前两个 Skill 解决的是想清楚。

到了交付阶段，一人公司会面对另一种压力。

需求要拆，界面要看，代码要写，测试要跑，安全问题要查，上线前还要确认有没有遗漏。

任何一环松掉，都会在用户第一次打开产品时暴露出来。

第三个选择是 Garry Tan 的 gstack，它的根入口真实存在于仓库的 SKILL.md中。

 

 

说准确一点，gstack 是一个路由入口，下面连接产品审视、设计、工程计划、代码评审、质量检查、安全检查和发布等角色化工作流。

你不必每次都让他全面给你查看项目。

开工前，让它把需求转成工程计划。页面完成后，从设计视角检查信息层级和交互。

代码写完后，再进入 review、QA、安全和发布检查。

一个可尝试的任务是这样。

这是我的两周 MVP PRD 和当前代码库。请先给出实现计划，标出风险最高的模块和依赖关系。不要直接大范围改代码，等我确认计划后再进入开发。

这套流程能把独立开发者容易跳过的检查节点重新放回来。

content-strategy 解决产品没被发现的问题

你有没有发现一个很奇怪的现象？

很多一人公司的产品，其实已经做得不错了。

功能也在更新，体验也在优化，但用户增长就是慢。

原因往往就是没人持续告诉用户，

你为什么值得被关注。

尤其是一人公司，没有专门的市场团队。

今天追一个热点，明天发一个功能更新，忙了一圈以后回头看，

内容发了不少，却很难沉淀出一套自己的增长方式。

content-strategy 来自 marketingskills。

它关注主题选择、内容支柱、搜索意图、选题集群和发布规划，

让 Agent 在开始写内容之前，先帮你梳理清楚，

 

我更愿意把它理解成内容总编，写稿只是后续环节。

先把用户反复遇到的问题整理成长期主题，再判断每个主题适合做教程、案例、对比还是观点，最后才进入单篇创作。

这样写出来的内容彼此有关联，也更容易沉淀成搜索入口和销售素材。

可以先给它这些信息。

我的产品帮助独立咨询顾问整理客户访谈并生成交付报告。下面是十条真实客户提问和三条成交原因。请制定一个四周内容策略，给出三个内容支柱、每个支柱的目标读者、搜索意图、八个具体选题，以及每篇内容通向产品的自然动作。

影响结果的，通常是你提供给 Skill 的输入。

产品名称、目标用户这些基础信息，只能帮助它搭出一个大致框架。

真正有价值的内容线索，来自客户真实问过什么，以及他们最后为什么选择购买。

如果只给一个产品名称，Skill 很容易生成一份逻辑完整、看起来不错的内容计划，但里面的选题未必贴近真实需求。

内容框架可以交给 AI 整理，用户说过的话，需要自己长期积累。

访谈记录、评论区反馈、客服消息和搜索数据，很多时候都比 AI 临时生成的标题更值得参考。

sales 把有人感兴趣推进到有人愿意买单

有流量之后，还差最现实的一步。

很多独立创始人愿意做产品、写内容，却不愿意主动销售。

于是“有人点赞”“有人收藏”“有人说不错”被当成市场验证，几个月后才发现没有稳定收入。

我选的销售 Skill 名字就叫 sales，来自 solo-founder-skills。

它覆盖创始人亲自销售、潜在客户清单、冷启动触达，以及如何找到前 100 位客户。

 

对于一人公司，销售流程不用一开始就搭得很复杂。

最小闭环只有四步，确定最可能购买的人，写一条与他相关的触达信息，完成一次需求对话，记录拒绝和成交原因。

别只让它写一封通用销售邮件。把具体产品、具体客户和具体触发事件放进去。

我的产品面向拥有 5 到 20 名员工的设计工作室。下面是产品能解决的问题、三个已成交客户的共同点，以及十家潜在客户的公开信息。请帮我排序名单，为前三家分别写一条个性化首触达消息，并设计两轮不过度打扰的跟进。

它可以帮助整理销售流程，减少那些没有针对性的沟通，也让后续跟进更有节奏。

但联系人信息是否准确、沟通是否符合规则、对方有没有继续交流的意愿，这些环节仍然需要人工确认。

money-finance 让收入、成本和现金流说真话

财务管理通常是最容易被放到最后的一件事。

一人公司的收入和支出来源越来越多以后，账户里的数字很容易失去清晰的业务对应关系。

订阅收入、一次性项目、退款、工具订阅和推广费用，每一笔单独看都不算大，

长期累积下来，却可能影响最终利润。

money-finance 来自 show-me-the-money。

它帮助整理收入分析、费用跟踪、定价策略和经营指标，也会根据不同业务类型关注 MRR、ARR、CAC、LTV 和流失率等数据。

 

这个 Skill 更适合处理已经产生的经营数据，帮助把数字整理成下一步需要回答的问题。

比如：

哪些客户贡献了主要收入？

哪个套餐销量不错，但实际利润较低？

模型成本有没有随着用户增长同步上升？

按照目前的支出水平，还能维持多久？

可以这样开始：

下面是最近六个月按月统计的收入、退款、模型调用费、软件订阅费、获客支出和活跃付费客户数。请统一统计口径，计算关键指标，分析利润变化的原因，并给出三项下个月可以验证的改进动作。不要补充不存在的数据，缺少的信息请单独列出。

使用这类分析时，需要特别注意数据口径。

财务判断建立在真实数据基础上，缺失的信息不能靠模型补齐，否则容易得到一份完整但不可靠的分析。

它可以帮助你整理经营情况、发现异常指标。

涉及报税、合规和融资材料时，仍然需要专业人士进行审核。

一人公司工作流

单独看，每个 Skill 解决的都是一个具体环节。

组合起来以后，一人公司的工作流程会变得更清晰。

• solo-analyze 帮你判断方向是否值得投入
• prd-development 帮你明确第一版产品范围
• gstack 负责开发、评审、测试和发布流程
• content-strategy 建立持续输出内容的体系
• sales 推动用户沟通和成交
• money-finance 根据经营数据调整投入方向

不过，这套流程里还有一个重要环节：

信息回流

销售过程中遇到的拒绝，需要重新影响产品判断和 PRD；

内容里反复出现的问题，可以帮助发现新的用户需求；

财务数据暴露出的低利润功能，也需要回到下一版产品规划里重新评估。

当这些反馈能够持续流动，Skill 才真正融入日常工作。

它们记录的不只是执行步骤，也是在帮一个人积累一套可以反复优化的工作方法。

小白直接照着发

如果你用的是 Codex，最省事的方法就是把对应的 GitHub 地址直接发给它。

比如使用下面的这个提示词：

帮我安装这个 Skill。
项目地址：……
先阅读仓库里的 README 和 SKILL.md，再按当前 Codex 环境可用的方式完成安装。如果不兼容，直接告诉我原因，不要强行修改。安装后告诉我安装位置，以及以后怎样调用它。

这里的项目地址，就填文章中对应的 GitHub 链接。

当你安装完成后，可以用下面的提示词去检测一下：

读取刚安装的 SKILL.md，用通俗中文告诉我它最适合处理哪些任务、需要我提供什么材料、最后会交付什么。先不要执行任务，等我继续发材料。

它能把能力说清楚，通常也意味着 Codex 已经识别到了这个 Skill。

当你真正开始使用的时候，不用背复杂命令。

把 Skill 名称、真实任务、现有材料和完成标准一起发过去就够了。

比如这样：

/solo-analyze 评估这个产品想法，找出最可能付费的用户、可行的获客入口和三个失败风险。我的想法是……

/prd-development 把这个想法整理成两周内可交付的 MVP PRD，功能不要超过五项，并写清楚哪些内容暂时不做。

/gstack 检查这份 PRD 和当前代码库，先给出实现计划、主要风险和测试清单，等我确认后再修改代码。

/content-strategy，根据这些客户问题和产品定位，安排四周内容选题，并说明每篇内容面向谁、解决什么问题。

/sales 分析这批潜在客户，排出联系优先级，为前三位分别写首轮触达和两轮跟进，避免群发口吻。

/money-finance 分析最近六个月的收入、退款、成本和付费客户数，先列出缺失数据，再给出三个可以马上验证的改进动作。

把句子里的案例换成自己的真实材料。

输入越具体，Codex 越容易按照 Skill 的工作流推进。

第一次跑完以后，再换一份同类型材料试一次。

第二次依然能少问重复问题、少漏检查项，这个 Skill 才值得长期留下。

最后想说的话

搭完六个部门，我对一人公司又有了新的感受：

很多人刚开始接触 AI 时，会期待它替自己承担更多工作。

但真正进入工作流之后，会发现，效率提升只是表层变化。

更重要的是，你拥有了一套可以持续放大的执行系统。

Agent 可以帮你整理信息、拆解任务、推进流程、完成大量重复工作。

但方向怎么选，资源怎么分配，

机会是否值得投入，依然需要人的判断。

一人公司的核心能力，逐渐从一个人完成所有事情，变成一个人设计一套能够持续运转的系统。

过去，个人的时间和精力决定了业务边界。

现在，一个人的认知、判断和决策质量，会影响整个系统的增长速度。

Agent 负责把想法转化成行动，把流程变得更高效。

你负责设定目标、建立标准、做关键选择。

未来真正有竞争力的一人公司，往往拥有清晰的方向感，

也懂得如何让 AI 围绕目标协同工作。

工具会持续进化。

但最终决定上限的，

依然是人的洞察力和选择能力。