先别做产品，做 Codex 插件

SaaS 不会被干掉，而是会用另外一种方式生长。

Lenny 最近采访了一个博主叫 Dan Shipper，他认为 SaaS 提供的服务可以直接集成到用户自己在用的 Codex 或者 CoWork 里面。

如果是做一个新需求，你不需要从头从零去开发一个完整的产品，发布一个 Codex 插件就行了。

然后再在必要的场景下搭配一些网站，让 Agent 可以直接用内嵌的浏览器打开。

我觉得这个方法很适用于这种情况：如果你的目的本身不是要做产品，而是单纯想解决一个问题，那它就非常合适。

它能帮你节省产品研发的工时，同时能直接利用现在最好的 harness，而且模型、算力、token 还是用户自带的，不需要你去承担。

这让我回想起 Kubernetes 刚流行的时候，大家会觉得做分布式部署工程师这个岗位很酷，但是实操下来，大家都自嘲是 YAML 工程师。因为 Kubernetes 是采用声明式设计，你需要去维护一大堆 YAML 规范文件。

搞不好后面一段时间，做 AI 开发的都会自嘲为 AI 插件开发工程师。

总之，大概就是我们可以不用先从产品研发开始，而是直接开发 Agent 的插件。因为一个很现实的条件是，现在每个人都有一个自己的 Agent，如果你面向的用户也是这种情况，那就可以直接为这些人服务。

Dan Shipper 的原话也是说，他只为 Codex 和 Claude 用户服务。

如果你面向的是更加初级的用户，而且你又能覆盖开发成本的话，那么就直接参考 Codex 好了。

你可以把内嵌浏览器做进去，把垂直领域的功能和技能内嵌进去。必要的话，再加上文档批注等功能。

总之，Agent 产品的形态现如今基本上已经尘埃落定了，就是双栏或者三栏式的布局。

当然你还要做的一件事情就是，你不能光给一个输入框，因为小白用户不会写提示词，你得给他们提供模板。

另外也讨论了最近很火的 FDE（前线部署工程师）。

其实就这个岗位的需求来说，这是一个非常实在的岗位需求。因为即便背景是模型能力在增长，Agent 越来越多，但要让这一套东西能够运转良好，仍然需要有人管理它们。

Dan Shipper 认为，短期来说这部分的职位需求会越来越多，难以被轻易取代。

当然，FDE 的工作并不轻松，需要建立对业务的深入理解。

听说有人分析了 1000 多份 FDE 的 JD，统计下来有 55% 的时间是要跟客户对话的。我觉得这个比例并不夸张，即便在剩下的 45% 里，你就算不跟客户对话，也可能是在做行业研究。

最终，真正用在开发上的时间只有很少一部分。这可能会变成未来的常态。