如何给不同类型的软件制定 AI Workflow

不同类型的软件，适合的 AI Workflow 是不一样的，我大致把它们分成两类：内容型的和功能型的。

内容型的项目

比如做一些运营的视频、搞个个人的博客，这种需要大量的人介入，因为它们是你个人观点想法的体现，属于内容输出型的东西。

当然，人的参与度是可以逐步降低的。做法就是前期大量介入，先去做一些内容，把路子探明，然后把人的经验沉淀下来，也就是沉淀为领域经验。这样制作的内容越多，沉淀下来的领域经验越多，需要人介入的部分就越来越少了。

这种其实很适合用 RSI 的思路去做，构建一个自我进化的领域经验沉淀机制，到后面形成一个闭环，靠飞轮效应去逐渐提升。

功能型的项目

比如我们的可视化平台、各种客户端程序，还有我自己搞的 Mac 清理软件等等，这些其实都属于业务功能开发，很适合走我之前弄的那套 AI Workflow：闲暇时候储备需求、澄清需求、制定评估标准，并将其转化为可供 AI 直接执行的任务，然后空的时候让 CodeX 去执行就可以了。

工作流的模式可以是：

1、找想法。从 GitHub、平时看到的博客、别人的文章、微信公众号、x.com 上面的内容等等，通过这种方式找到一些想法，或者让 AI 去扒取和逆向，以这种方式挖掘需求。

2、基于我的 AI Workflow，把需求沉淀为需求池(储备需求、澄清需求、制定评估标准，并转化为可供 AI 直接执行的任务)。

3、空余的时候让 CodeX、OpenCode 这些 AI Runtime 去自动调度和执行。

这样我们就能源源不断地有需求了。

功能型项目也要分类

功能型项目内部差别也很大，按确定性来分，大概能分成三类，它们能交给 AI 的程度完全不同。

业务开发和可视化组件开发：这类一般都有明确的需求和设计稿，比如 Figma 设计稿，确定性非常强。通过 Figma MCP 再加上一些视觉模型，就能让 AI 自动去实现相关功能，并自己完成自测验收。所以这类是非常适合全流程自动化开发的。

探索类：比如尝试一些之前没人搞过的内容，生成信息图、生成视频等等。这类因为缺乏领域经验，需求也很模糊，需要不断尝试摸索，所以初期比较难弄成全流程自动化。不过探索的过程中，一般都会在公司的聊天软件里积累下非常多的信息。等开发完成，或者进行到一定阶段以后，就可以让 AI 去分析这些聊天群里的内容，收集大家的经验去做蒸馏，再把蒸馏出来的领域经验回填到开发流程里，这样 AI 自动化的占比就能逐步提升。

重构老项目：这类有参考、上下文也足够，所以 AI 实现的效果会比较好，很适合做全流程自动化。这也是为什么网上都喜欢拿它来测试模型能力，因为真能上线。

AI 自动接力的开发流水线

这套工作流可以理解为一条 AI 自动接力的开发流水线：

人定目标和验收标准，总控安排优先级，把工作变成边界清楚的任务。
开发 AI 领取任务，在独立的工作区里实现和测试；多个 AI 可以并行，靠依赖和锁防止互相覆盖。
独立的评审 AI 检查交付，有问题就退回修改；通过后由集成 AI 合并并再次验证，全部通过才算完成。
监督器持续接力，巡检器检查异常；进度和检查点都会保存，中断后可以接续，无法安全处理的问题交给人裁决。

核心是：AI 负责持续执行，工具约束流程，真实验证决定是否完成，人负责目标、授权和例外。

需求一定要分类

另外就是一定要对需求做分类。比如之前我们是去挖用户的问句，那肯定是不够的，那只是一个类型，远远不够，一定要做大量的抽象分析挖掘，以数据驱动的方式去找有价值的需求，不然就是瞎搞，搞出来都是垃圾。