刚开始装 Skill 时，很容易按“看起来厉害”去收集：写作、设计、代码、浏览器、自动化……装了一堆，真到做产品，还是会卡在：下一步到底该交付什么？ 我现在更愿意按产品阶段来装。规则很简单：一个阶段先留一类能力，先看它能不能交出可检查的东西。输入说不清、验收也没有的 Skill，先别装。 1）调研类：想法还模糊时再用。 输入是目标用户、使用场景和已有假设；留下的是问题清单、竞品观察和待验证的假设。别一上来就要“完整市场报告”，先把你要解决的问题说具体。 2）规划类：方向已经能讲明白时用。 输入是需求边界和约束；留下的是功能拆分、实现顺序和验收条件。没计划就开写，不是真的快，只是把返工往后挪。 3）编码类：任务已经足够小、能直接执行时用。 输入是一条明确任务和现有代码上下文；留下的是能跑起来的功能改动。它不负责替你决定产品做什么，只负责把已经想清楚的事做出来。 4）验证类：功能看起来能用时用。 输入是预期行为和测试路径；留下的是测试结果、检查记录，或者一个明确的失败原因。少了这一步，很容易把“演示没问题”当成“真的能用”。 5）发布前检查类：准备交给别人用时再用。 输入是当前版本和发布清单；留下的是已经确认的风险、缺口和下一步动作。它不能保证上线成功，但能避免把明明没检查过的东西交出去。 最小配置的重点，不是 Skill 越少越好，而是每个阶段都能留下一份证据：假设、计划、可运行的功能、验证记录、发布前清单。 等你连续几次都卡在同一种问题上，再补对应能力。比起一开始把工具堆满，这样更稳。 #Codex #AI开发 #独立开发 #产品搭建 #开源项目 #Skill #副业探索