怎么做 AI 产品

用户为什么不直接用原生的 ChatGPT、Claude Code，而要用你的产品？

选题、开发和营销，都应该围绕这个问题。

一、找到值得付费的工作

a16z 报告显示，在 2026 年 8 月的美国消费者支付样本中，AI 付费者里支出最高的前 10%，贡献约一半的观测支出。CNNIC 的 2026 年上半年调查则显示，32.5% 的生成式 AI 用户会处理工作总结、会议纪要或 PPT。前者统计支出，后者统计用途，不能直接比较付费能力。Andreessen Horowitz ↗、CNNIC ↗

地区	指标	数据
美国	支出最高的前 10% 付费者贡献的观测支出	约一半
美国	支出最高的前 1% 付费者月均 AI 支出	903 美元
美国	AI 付费者月支出中位数	25 美元
中国	用生成式 AI 处理图片或视频的用户占比	47.8%
中国	用生成式 AI 处理文本的用户占比	37.6%
中国	用生成式 AI 处理工作总结、会议纪要或 PPT 的用户占比	32.5%

美国数据对应 2026 年 8 月的 YipitData 消费者样本；中国数据对应 CNNIC 2026 年上半年的使用调查。支出与用途属于不同口径，中国各用途可以重叠。美国数据 ↗、中国数据 ↗

我的判断是，先找一类你能接触到、正在用 AI 完成工作的人，让他们拿出最近一次任务的材料、过程和结果。观察他们使用 ChatGPT 时，还要反复准备什么、核对什么、手工补做什么，以及这些工作有多频繁，要花多少时间和钱。

找到用户确实需要、但原生 ChatGPT 做不好的工作，把它做好。

二、收益才是选择理由

收益要落在一项完整的工作上。以会议纪要为例，除了文字是否通顺，还要看用户是否需要重听录音、核对结论、补全负责人，再把待办录入任务系统。产品究竟省掉哪些步骤，交付是否可靠，都需要验证。

拿同样的真实材料，让你的产品和合理配置的原生工具各做一遍，提前写清什么结果算合格。比较完成质量、人工介入、耗时和总成本；运行、重试、审核，以及学习、配置和维护，都要计入。

再让目标用户亲自操作，确认这些收益在他们自己的材料和工作流程中也能成立。开发者演示成功之后，还要验证用户能否独立完成任务。

用户选择你的理由，应当具体到：这项工作比直接用 ChatGPT 做得更好、更省事，或者总成本更低。

三、优先选择轻量简单的实现方式

动手前，先去 GitHub 找类似项目，实际跑通，判断能否直接使用、扩展或复用。确认已有方案的缺口后，再选择自己的实现方式，不要从零重做已有能力。

优先考虑下面这些方式，并根据实际需求组合使用：

• Hook：在 Agent 运行的指定时机自动执行脚本，例如工具调用前检查参数、修改文件后运行格式检查，适合处理规则性的约束和固定动作。Claude ↗
• Skill：给 Agent 一个额外的专家技能包，核心是一份按需加载的提示词，也可以附带参考资料和脚本，适合提供领域知识和可复用的工作流程。Claude ↗
• MCP：把查询数据、调用业务系统等能力做成标准接口，供支持 MCP 的不同 Agent 接入和调用。Model Context Protocol ↗
• Plugin：把 Skill、MCP 服务、Hook 等打包在一起，方便安装、分发和更新。Claude ↗
• Mod：Claude Code 的扩展形式，可以添加面板、状态栏等界面，也能调整运行行为，并随 Plugin 安装和分发。Claude ↗
• 独立的 Harness 或产品：最后才考虑。当现有平台及其扩展无法满足核心任务、交互或部署需求时，再搭建自己的 Agent 运行框架或独立应用。

Joye 对 Legion 的追问很直接：这套分工和验收，能不能先做成 Skill 加 Hook？我认同这个优先级。管理方式和验收能力，可以先通过轻量版本接受真实任务的检验。Joye Personal Blog ↗

轻量也要体现在用户的安装、配置和使用上。自己按公开说明从零安装一次，再让目标用户独立完成第一项任务，找出哪些地方仍需要开发者在旁边解释或代操作。

接入现有 Agent 生态，也提供了触达现成用户的机会。插件目录是已有的分发渠道；结合案例教程和社区传播，项目有机会随着生态扩大获得更多曝光，但平台的热度不会自动变成产品的用户。Claude ↗

把收益交付到用户熟悉的工具和流程里，降低他多用一个产品的成本。

四、在开发初期设计好架构

一开始就分清业务规则、模型调用、工具执行和结果验收，让模型和工具可以替换，避免改一处就牵动整个系统。

先用最少的模块跑通真实任务，不要提前搭庞大的通用框架。模型升级后重跑测试，删除不再需要的补丁，不要让维护框架本身成为主要工作。

五、做一个好的AI产品

如果现在开始，我建议先找几位能直接联系的目标用户，用他们最近的一项工作检验前面的判断：原生 ChatGPT 能做到哪里，还要人工补什么，你能否用最轻的实现省掉其中一步。约他们在下一次同类任务中独立试用，先把这一项工作做顺。

把一次真实交付写成案例，讲清谁遇到了什么问题、原来怎样用 ChatGPT、用了产品后少做了什么，再附上清楚的试用入口，发到同类用户所在的社区。让读者看得出收益，也知道怎样开始。

接下来，观察用户停在哪一步。有人看却不试，就去问用途是否讲清、需求是否存在、门槛是否太高；试了却做不完，优先修卡住的步骤；同类任务再次出现却不再用，问清他选择了什么、为什么。准备收费时，就给出明确价格，观察用户是否愿意为下一次任务付费。

把失败变成检查案例，把成功交付变成案例和教程，用这些反馈决定下一轮开发和传播。长期迭代、打磨、维护和营销，就落在这些具体工作里：找到真实需求，复用已有方案，解决原生工具做不好的部分，让用户容易用上，再根据实际使用不断改进。

同样的工作再次出现时，用户仍然愿意选择你的产品，才是“为什么不直接用 ChatGPT”最有说服力的答案。