前置原则：
前期方向要足够窄，但是要以大目标为导向。这样才能获得现金流。做通用平台对于个人开发者前期根本赢不了，必须曲线救国。
必须以极致的用户体验为导向。
推广速度必须够快，要建立一个循环生态。
Thinking
我想做一个什么样的产品，有哪些原则。
如果我想做一个平台级的产品，让我的产品变成平台，让开发者基于我的产品去开发，让用户更方便地使用产品，如果我们把工作流包装成产品，可以买卖出售，这是一个好主意吗？
首先我们需要知道用户想要什么。用户想要的是，他描述一个需求给我的产品，我的产品就能自动构建出完美解决这个需求工作流的产品。
所以决不能再让用户去决定使用谁的工作流，这样会增加认知负担。所以最佳的方式是，AI 构建并选择最优的工作流。
实际上，前期应该使用 AI 让它使用我的系统工具去构建工作流，让用户尝试使用自然语言反馈去修改工作流，到一个完全可以使用的状态。这个时候这个工作流就成了一个资产，而且有一定的用户锁定。
然后我的产品应该去获取这些工作流的数据，去优化我的 AI。以后的 AI 就知道了如何更好地直接构建出最优的工作流。
那么这里就需要有一个分层：哪些人的数据可以用于训练，哪些人的数据不能用于训练。免费试用的可以用，付费用户则不用。
不过如果做的是 To B 客户，用户绝不会希望自己的数据被用于训练。不过有时候付费用户的工作流反而更有价值。所以有时候需要做一些匿名化处理，比如只获取工作流的设计，匿名化数据。
那么如果我把它构建成一个平台，有什么好处？让用户之间可以买卖工作流，难道不是我去直接获取用户这些工作流数据再去做模型优化泛化就够了吗？
而且用户希望的并不是让他再去挑工作流，而是直接一步到位。所以要么你就可以用 AI 自动选择这些工作流，不过事实上这样也是错误的，因为人们的需求非常杂，哪有说别人的工作流就完全符合用户需求。
也就是说，最佳的方式还是：
直接让用户使用 AI 去构建工作流，根据自然语言反馈给 AI，让 AI 去修改工作流到合适的效果。然后我获取这些构建工作流的数据，我就知道要怎么做，才能让 AI 一步到位地设计这个工作流。
那么要让 AI 去构建这个工作流，有哪些要素？
如果我们思考平时人类的工作流步骤，这里有几个标准的工作流举例：
- 写代码（前端后端）
- 营销
- 财务税务
- 法律
- 医生
- 金融
- 科研实验
- 销售
- 电子商务
- 供应链
- 医疗保健
- 保险
- 创意设计
进一步抽象的话，会包含这几个阶段：
- 感知：实时监控你的所有数据流（邮件、会议、文件）
- 建模：自动识别出哪些是“任务”，哪些是“背景知识”
- 博弈：自动在多个工具方案中选择最优解
- 编码：生成结果
- 进化：根据你的点击、修改或反馈，更新自己的处理策略
也就是说，一个完整的工作流可以拆成：
- 我们需要接收到任务，这里就有一个触发工作的操作。
- 我们收到任务之后进行规划，需要知道完成任务需要哪些东西，需要调用哪些工具。
- 执行智能处理。
- 输出结果。
- 反馈与更新，也就是进化。
我当前的思考
我的思考是，有两种方式。
像目前 Codex 的方式是：你在一个任务窗口里让它给你解决任务，当它第一次完成任务，你可以让它生成一个 skill。它下次遇到类似任务就会调用这个 skill，执行一样的工作流。
这里面的工作流细节对用户来说是隐藏的，除非用户自己去看 skill 文件。不过用户其实只在乎它能不能解决任务。
不过这里完成工作流的智能处理部分，也就是你期望它的工作流到底应该怎样设计，它很适合重复完成同一种处理任务。但这里面有几个还没实现的点。
1. 数据输入与任务触发
每次都需要我手动输入数据以及触发流程。
如果它可以嵌入到其他软件数据里，并在用户希望的时间点自己获取数据并触发流程，会有更好的用户体验。也就是类似 ERP 自动获取数据并发货那种感觉。
这个应该需要接入各种 MCP。不过 MCP 里有软件触发 AI 的操作吗？
这个数据获取与触发应该是双向的：
- 软件告诉 AI，有新的任务输入，然后触发 AI
- 或者 AI 去触发任务，然后去获取数据
本质上，依然是人类设计的方案去触发任务。这里面 AI 都是被触发或者被设计的。
也就是说，这里我们还需要有一个非常方便的触发操作，让任务触发后可以顺利调用 AI 工作流去处理任务。
所以应该有一个 API 接口，可以非常方便地把软件接入 AI，让软件去触发 AI。
2. agent 的拆分与复用
这种工作流暂时没有与其他 agent 嵌套。
这导致了一个问题：如果一个任务过于复杂，里面其实可以拆分成多个负责不同任务的工作流 agent。拆分的原则就是，这些 agent 是否可以被其他任务复用。
而且如果这些 agent 可以被其他任务复用，那它就更像是一个公司架构，工作流也会更加可控。
而理想的设计，是让 AI 根据需求自动去拆分工作流。
这里我们就需要设计一些模块，让工作流成为模块，能够进行调用与组装。
3. 工具调用
AI 需要使用到各种工具去完成任务。现在传统的做法，是让 AI 通过模拟鼠标点击去使用软件工具。常见的工具比如网络搜索、命令行工具。
最理想的方式，是这些工具直接开放对应接口给 AI 进行操作。
不过这些厂商大概率不会开放，除非开放之后能扩展他们的业务，或者不影响他们的业务。
不过现在传统的接口，都是网页跟桌面应用。本质上应该也是有数据接口连接到前端 UI 上的。那为什么不做一个映射器，把这些 UI 接口都映射成软件可以控制的工具？
事实上早就有人实现了，所以我只需要去集成他们的工具即可。
4. 结果是否真的符合预期
AI 能否最终生成一个符合用户期望的结果，比如：
- 回复邮件
- 输出成某些结构化或非结构化格式
- 或者直接完成某些操作
我当前的结论
至于长程规划任务、由多 agent 组成的公司、记忆，其实都不是目前商业化最关键的东西。
实现前面提到的这些东西，就已经可以解决大部分问题了。
最后一个我觉得必须持续关注的能力是：
RL 能力，也就是在工作中学习的能力。
