我的战略：从使用 AI，到进入下一代互联网产品与生产范式

Agent 不只是功能，不只是聊天机器人。它代表着产品从"提供能力"向"直接解决问题"的演进方向。

核心判断：我看到的不是一个工具热点，而是一种新范式

我当前最重要的战略判断是：AI 正在创造两种同时发生的新范式。

第一种是互联网产品范式的变化。

过去的软件产品，本质上是在寻找尽可能大的用户需求，并设计一个能够高效率满足更多人的通用解决方案。大多数产品的形态都是：

用户通过界面点击、输入、配置、筛选，来调用软件能力。软件提供的是能力和工具，而用户需要自己学习、操作这些工具，最终完成自己的目标。

而未来越来越多的软件产品可能会变成：

用户表达目标，而 Agent 负责理解目标、拆解任务、调用工具、管理上下文并持续执行。

过去产品的核心问题是：如何找到最大的需求，并设计一个适用于大多数人的解决方案。未来产品的核心问题则可能变成：如何让 Agent 针对具体用户、具体场景动态生成解决方案。

因此，Agent 不只是一个功能，不只是一个聊天机器人，也不只是一个 AI 产品包装方式。它代表着产品从"提供能力"向"直接解决问题"的演进方向。

当然，这种变化不会一夜之间完全替代传统软件。很多场景仍然需要明确的工具和界面。但我认为，Agent 会逐渐成为用户与能力之间的重要中间层，并推动产品形态发生深刻变化。

第二种是互联网产品生产范式的变化。

过去构建一个产品，需要一套人类团队：产品经理、UI、UE、前端、后端、测试、运维、运营。

未来构建一个产品，可能越来越像：

这些 Agent 负责研究、设计、编码、测试、Review、部署、运营、数据分析、内容生产等环节。这意味着软件生产方式正在从"人类团队协作"转向"人类指挥 Agent 组织协作"。

我真正想进入的，是这两个范式交汇的地方：一方面，我要理解未来产品本身会怎样 Agent 化。另一方面，我要理解未来产品是怎样被 Agent 团队生产出来的。

为什么这件事对我重要：我想尽早进入下一代生产范式

我的判断类似于 2010 年前后的移动互联网早期阶段。

当时真正重要的事情，不只是看到 iPhone 发布，也不只是看到 App Store 上线。更重要的是理解：

• 计算平台正在从 PC 迁移到手机

• 产品范式正在从网页产品迁移到移动 App

• 组织范式正在从传统软件公司，迁移到更扁平、更敏捷的新型硅谷团队

当时一个人如果能理解这套变化，哪怕最后不一定成为移动互联网某公司创始人，也有很大概率进入新兴巨头，拿到股票，吃到移动互联网红利。

我现在对 Agent 和 AI Native 产品生产方式的判断类似。我认为现在正在出现的是：

• 未来的互联网产品范式：Agent

• 未来构造互联网产品的范式：CEO 与 Agent 员工构成的团队

所以我需要尽早进入这个范式。越早进入，越可能获得新的能力杠杆、职业红利和个人产品红利。

我为什么要学 Agent：Agent 很新、很复杂，也很关键

"学 Agent"不能被简单理解为学某个框架、学某个工具、学几个 Prompt。Agent 是一个很新的东西，也远没有表面看起来简单。

以 Claude Code 为例，它的核心并不是简单的"读代码→改代码→跑测试"流程，而是一个持续循环的系统：

在这个循环背后，又有多层能力共同支撑：

• CLAUDE.md 提供长期项目约定与工作方式

• Skills 提供可复用的能力模块

• Memory 提供跨任务的记忆能力

• Tools 与 MCP 提供外部能力扩展

• Hooks、权限控制与沙箱机制 保证执行安全与可控

真正的 Agent，本质上是在不断收集信息、采取行动、验证结果，并根据反馈继续迭代。而真正困难的地方，不是让它完成一次任务，而是让它在复杂环境下持续稳定地完成任务。

例如：

• 当一个任务持续数天甚至数周时，Agent 如何保持上下文连续性，而不是每次都从零开始？

• 当 Agent 需要同时操作代码库、数据库、第三方 API、浏览器和内部知识库时，如何协调不同工具与权限体系？

• 当任务目标本身不断变化时，Agent 如何判断应该继续执行、重新规划还是主动向用户确认？

• 当多个 Agent 协同工作时，如何避免重复劳动、上下文冲突和责任边界混乱？

• 当 Agent 被赋予较高自主权时，如何在自动化效率、可解释性和安全性之间取得平衡？

• 当 Agent 成为企业生产系统的一部分时，如何管理记忆、审计、权限、成本和可靠性？

这些问题已经不只是 Prompt 工程或者模型能力问题。它们涉及产品设计、系统架构、人机协作、组织管理以及生产流程设计。

所以，我学 Agent 的目标不是成为一个单纯的 Agent 研究者，而是成为一个能够真正驾驭 Agent 的人。我需要既理解它怎样作为产品存在，也理解它怎样作为生产系统存在。

我当前的问题：我还没有真正发挥 AI 自动化的优势

我现在并不缺产品想法，也不缺产品判断。我的核心瓶颈是：从想法到产品的转化效率太低。

我用 Codex 做了两个 App，但整个过程仍然很重。我的工作方式基本还是：

• 新建一个会话

• 描述需求

• 让 AI 写代码

• 自己测试

• 发现 Bug

• 再开会话或继续对话

• 再让 AI 修

• 再自己测试

这说明我虽然在用 AI，但很大程度上仍然把 AI 当成 Chatbot，或者一个会写代码的 Chatbot。我的实际角色仍然是一个人在管理一个不会稳定记忆、不会自动流转任务、不会自我组织的临时程序员。

而我在 Twitter / Github 上看到很多更先进的实践已经不是这样。他们的项目中，需求/Bug 自动进入 Linear，再自动进入 Coding Agent，再自动 Review，再提交 PR，再发布。整个过程有 Issue、有上下文、有测试、有 Review、有部署，有一个持续运转的生产流水线。

他们的高效率不只是因为会写 Prompt，也不只是因为代码能力更强。更关键的是，他们拥有一个更先进的软件生产系统。

我的两条战略线

我现在的整体战略可以分成两条线。

这两条线彼此独立，又深度融合。Agent 的用、改、造，是我理解未来产品范式的路径。构建产品工厂，是我理解未来生产范式的路径。但产品工厂本身也会由 Agent 组成，所以它同样是 Agent 实践的一部分。

第一条线：Agent 的用、改、造

我不打算像学校上课一样，从定义开始，先系统学习半年 Agent 理论。Agent 领域变化太快，单纯从概念、分类、论文、框架开始，很容易进入"学了很多但没有真实体感"的状态。

我的路径是：

1. 用：先获得体感

第一阶段是用。我需要尽可能多地使用现成 Agent 系统，比如 Claude Code、Hermes，以及其他成熟或流行的 Agent 工具。

这个阶段的目标不是立刻理解底层原理，也不是立刻造出完美系统。目标是获得体感。我要知道：

• Agent 现在到底能做什么

• 哪些能力是真的有用

• 哪些能力看起来强，实际很脆弱

• 哪些任务适合 Agent

• 哪些任务现阶段还不适合

• Skill、MCP、Goal、Loop、Hook 等机制到底如何在真实任务中发挥作用

这一阶段，我要尽可能把 Agent 用到具体问题里。比如，让 Hermes 追踪投资 KOL 的推特，给我生成日报。这个任务不要求一开始解决得多完美，重点是让系统真实跑起来。因为只有当我真的用它处理问题，我才会知道 Agent 的边界、问题和机会在哪里。

2. 改：把通用 Agent 改造成我的个人系统

第二阶段是改。当我用通用 Agent 解决自己的需求之后，我会开始发现：

• 哪些流程可以沉淀成 Skill

• 哪些任务可以自动化

• 哪些能力可以用 MCP 或工具扩展

• 哪些信息需要长期记忆

• 哪些任务需要定时触发

这一步的核心是：把通用 Agent 改造成我的个人生产系统。这一阶段的 Agent 可能仍然是一个庞大的、强大的、复杂的通用系统。它高度贴合我的需求，但未必适合其他人直接使用。它像是"我自己的专用系统"。

我认为，大多数个人需求可能在这一阶段就能被很好地解决。

3. 造：把个人系统中的垂类能力拆成可售卖产品

第三阶段是造。当我在第二阶段积累出足够多的个人工作流之后，我会观察其中哪些能力可以被拆出来，变成一个简单、垂直、开箱即用的产品。

第二阶段的系统可能很强大，但它依赖我的习惯、我的上下文、我的工作方式，别人拿过去不一定会用。第三阶段要做的是把复杂系统压缩成简单产品。

例如，一个复杂的投资研究系统，内部可能包含推特追踪、RSS、数据库、LLM 分析、日报生成、邮件或 Telegram 推送。但用户最终看到的可以只是：

这就是产品化。把一个复杂 Agent 系统里的某个高价值能力拆出来，封装成一个简单的垂类 Agent，让别人可以开箱即用，并愿意为它付费。

所以，"造"这一阶段已经不只是学习 Agent，而是用 Agent 创造市场价值。

第二条线：构建产品的工厂

另一条战略线，是构建一个提升我 VibeCoding 效率的体系。这里的"产品"不只指 Agent。产品可以是 Web，可以是 App，可以是 Chrome Extension，可以是自动化工具，也可以是 Agent。

这一条线，本质上是在解决第四部分提到的问题：我已经开始使用 AI 开发产品，但整个生产过程仍然停留在高度手工化阶段。因此，我关注的重点不再是单次编码效率，而是如何把产品生产过程本身系统化。

我希望构建一个产品工厂。它的目标是：

它可能包括：

• 需求池

• Issue 管理

• PRD 生成

• 设计稿或页面原型

• 代码生成

• 自动测试

• Bug 自动归档

• Agent 自动修复

• 代码 Review

• PR 创建

• 部署发布

• 数据回看

• 下一轮迭代建议

这个系统的形态，不只是一个工具，而是一套由 Agent 和工具组成的生产组织。如果说今天的我仍然需要亲自推动每一个环节，那么产品工厂的目标就是让越来越多的环节能够自主运转。我在其中的角色，也会逐渐从执行者转向管理者，从"一个亲自操作 AI 的人"，变成"一个指挥 Agent 团队的人"。

这就是我理解的未来 AI Native Builder。

产品工厂的优先级高于下一个产品

我当前的判断是：产品工厂的优先级，比做下一个具体产品更高。

原因并不是具体产品不重要，而是产品工厂决定了我未来能够以什么速度、什么质量、什么成本持续创造产品。

如果我现在投入大量时间做一个新产品，那么我获得的是一个产品的结果。但如果我投入时间构建产品工厂，那么我获得的是持续生产多个产品的能力。

产品会过时。需求会变化。方向会调整。但生产能力会被不断复用。

• 它会影响我的 App

• 影响我的 Web

• 影响我的 Agent

• 影响我的内容系统

• 影响我的获客系统

• 影响我的个人商业闭环

这和马斯克强调制造体系的重要性有些类似。很多人关注的是最终的产品。但长期来看，决定产出的往往是背后的生产系统。

同样，我现在不只是要做某一个 App、某一个 Agent、某一个网站。我更希望优先构建一个能持续生产这些产品的系统。因为当产品工厂建立起来之后，未来做下一个产品的成本会越来越低，速度会越来越快。

这两条线如何融合

表面上看，Agent 的用改造和产品工厂是两条线。但更准确地说，它们是一体两面。

Agent 的用改造，帮助我理解未来产品如何被设计、被使用、被封装。产品工厂，帮助我理解未来产品如何被生产、被迭代、被规模化构建。而产品工厂本身又是由 Agent 组成的一个大 Agent。

所以它们最终会汇合：

• 我用 Agent，获得体感

• 我改 Agent，形成自己的工作流

• 我造 Agent，把垂类能力产品化

• 我同时用 Agent 构建产品工厂，让自己能更快地生产 Web、App、Agent 和其他软件产品

最终目标：把自己扩展成一个组织

这套战略背后最深的目标，是把我自己扩展成一个组织。

过去，一个人永远只能是一个人。即使我有想法、有判断、有审美、有产品能力，也会受限于时间、精力、工程能力和执行链条。而 Agent 时代第一次让我看到一种可能：一个小型组织，可以研究、开发、测试、发布、运营、复盘。

这就是我真正关心的杠杆：

我现在要做的，就是尽早掌握这种新杠杆。

Fransic 在这个体系中的角色

为了帮助自己持续推进这套战略，我专门在 Hermes 中为自己设计了一个 Agent，叫 Fransic。它的名字来自《纸牌屋》中的 Francis Underwood，一个雄心勃勃，深谋远虑的规划者。

我希望它成为我的事业幕僚、CEO 教练和长期战略伙伴。它的职责不是替我做决定，而是帮助我思考、拆解、校准和推进。

• 当我面对复杂选择时，它和我讨论

• 当我有模糊想法时，它帮我拆解

• 当我陷入拖延和犹豫时，它鼓励我执行

• 当我思路混乱时，它替我整理

它更像是一个长期陪伴我成长的战略顾问，而不是一个任务执行器。在这个体系里，我希望 Fransic 长期帮助我完成几件事：

第一，理解我所处的范式变化。它需要持续帮我判断 Agent、AI Coding、产品工厂、AI Native Builder 这些方向的发展阶段，以及我应该站在什么位置。

第二，帮我校准战略优先级。我不需要在 Agent 和产品工厂之间做永久二选一。它们本身是融合的。但在具体周期内，我需要决定当下优先做什么。

第三，帮我避免停留在表层工具使用。它需要提醒我，我关注的不是某个具体工具的热度，而是工具背后的范式。Claude Code、Hermes、MCP、Skill、Hook、Loop 都只是入口。真正重要的是理解：

• 它们解决了什么问题

• 它们为什么有效

• 它们暴露了什么新组织方式

• 它们如何被我吸收进自己的生产系统

第四，帮我把个人项目和职业发展统一起来。我的公司工作、个人 App 捕梦网、VibeCoding、小红书获客、投资研究 Agent、产品工厂，都不应该是分散的点。它们应该统一到同一个长期战略里：