本期「开发者说」邀请到超级峰。2019 年，他独立开发的微信小程序积累了 200 多万用户；2024 年底，他开始使用 Cursor，并开发了"芝士相机"；如今，他正在探索面向办公与企业业务的 AI 工作台。这是一条有代表性的个人开发者实践路径，但它并不是简单的"从小产品走向大产品"。贯穿始终的是同一个问题：当 AI 能够生成代码，开发者如何继续保有对产品的价值，并为它后续的使用与迭代负责？以下是他的叙述。
从手工写小程序，到用 Cursor 做芝士相机，再到现在探索 AI 工作台，我越来越在意一个问题：东西做出来之后，能不能继续改、继续用，持续服务真实用户？
我有软件工程背景，也做过八九年的 ToB 产品。AI 让我跨过了不少技术门槛，但没有替我决定什么值得做、做到什么程度才算合格。这次分享尽量呈现我做产品背后的真实问题与思考，希望为同样在探索的伙伴开拓一些用 AI 做产品的解题思路。
一、拿场景找实现，不要拿工具找需求
我的百万级用户产品是由微信小程序、Python 技术实现的 GIF 制作工具，早期不懂这些代码，只能在实现功能过程中不断查代码、复制粘贴、拼进去，再看报不报错。那时的顺序是：先解决开发问题，把产品做出来，再考虑怎么服务用户。
后来想做 iOS 产品，我不想再从头学一门开发技术。恰好 2024 年 AI 编程工具兴起，我找到了 Cursor 这款工具，直接帮我省去了学习跟编写 iOS 代码的阶段，可以更专注于产品设计本身。
芝士相机缘起于生活中很具体的一个场景，如何拍好照片：参考网红姿势，不一定适合自己的体型和习惯；想重现自己以前拍得好看的一张照片，又很难向拍摄者描述清楚。能不能直接导入旧照片，提取人物轮廓，再照着轮廓引导拍摄？
AI 帮我跨过了 iOS 开发和轮廓提取算法两道门槛。到现在，我也不知道里面的代码具体怎么写，但我知道自己要解决什么问题。可以说，AI 重构了我做独立产品的思路和顺序：以前是拿技术实现产品，技术决定自己能做什么；现在是拿场景去模型里"换"一个产品，先从具体问题出发，再验证 AI 能否实现。
当下，AI 前沿工具和技术层出不穷，但我会更慎重地采纳。除非它相对成熟，或者正好能补进我的工作流，否则不会轻易加入。先有场景，才知道该比较速度、稳定性，还是成本；没有场景，拿五十个工具来试，可能只是挨个玩了一遍。最终很难衡量它在自己的产品场景里是否带来提升，以及提升多少、成本是否划算。只有基于具体场景验证，工具和技术才可评估，否则很容易陷入"感觉不错，落地效果却不佳"的困境。
二、看不懂每段代码，也要有办法发现偏差
我很早就发现目录结构的重要性。做芝士相机时，首页、拍摄页面、抠图功能等等，我都会放到不同目录。比如我要求优化抠图逻辑，AI 却开始修改首页目录，即使不知道代码细节，我也能发现它可能走偏了。目录不只是方便找文件，也是上下文和控制手段。原本完全看不见的实现过程，可以通过修改发生的位置，获得一点间接判断。
这跟我以前写产品方案的习惯有关。写需求时，我会把列表怎样排序、默认展示多少条、跳转到哪里，以及特殊情况处理和边界写清楚。目的不是文档越长越好，而是减少后续执行过程中的反复沟通和返工。
跟 AI 协作，我也是一轮一轮推进：提出需求，看执行结果，指出不符合预期的地方，再调整。如果它整理不好文档，我会看它是不是不知道规范在哪里，或者缺了某个工具，而不是反复说"你再做好一点"。
我更愿意把 Agent 当"员工"：先给目标，看它能做到什么程度，再补约束。如果一开始就替它想完所有步骤，就很难发现它真正的能力边界。AI 编程的核心，是"提出需求---AI 执行---人工验收"的 Human in the Loop 循环。我关注目标，AI 负责落地执行，最终由我验收结果并提出改进意见。这就像带一个实习生，而 AI 大概率是个很强的实习生。放开手让 AI 去做，结果往往远超预期。
但不参与细节的代码编写与审查，并不意味着对整体产品没有掌控。我现在做产品，更像是在搭积木：从场景、流程到模块架构，更关注产品该包含哪些模块、每个模块有哪些流程、每个流程又对应哪些场景。
我一直认为，技术架构或技术语言是产品语言的翻译，而好的模块分类和场景定义，正是 AI 实现时的优质原始材料。也正因这些原始材料由我自己设计，所以除了代码细节，我对产品的整体模式与架构仍有很强的掌控力。
三、客户会告诉你，"跑通"离"能用"还有多远
我在做 AI 工作台产品 MotiClaw 的过程中，最近对接了一个电商客户，他的诉求是：已经有了一张商品图，要把商品图案稳定地替换到展示图片上。
我的思路是，先把待替换区域变成绿幕模板，再把新图案放上去。流程跑通了，我肉眼看效果也不错。但客户要对接工厂，会盯图案纹路里的细节。有些地方我看不出问题，他会指出不够精准。以前他们用 Photoshop 和 3D 来做，就是因为可控性更高。
目前这个问题还没有完全解决，我们在尝试图像编辑模式，看能不能更好地保留细节。不过，这个案例已经推动我把工作流能力搭了起来。它让我更明确：真实用户不仅给你需求，还会给你一个比"看起来不错"严格得多的验收标准。场景驱动的产品设计，价值远大于闭门造车。
再举个例子，以博主的角色做内容，一个功能跑出来，就可以成为一篇文章的亮点；但用创业的心态做产品，你要继续面对真实用户使用中的问题。无论产品多小，都可能有 Bug。用户提出十个功能，要不要全加？只加两个，先加哪两个？这些都是做产品时真实的细节，以及在各种限制条件下的产品决策，这些才是长出真正能持续提供服务产品的关键。
我也在做自媒体，为了多平台发布的便捷性，给自己做了一款发布工具。正因为持续高频的使用，才有机会在自己的场景里不断打磨产品细节。自己就是用户，这是一种很好的产品起点。从用户反馈（也就是自己）到需求分析，再到开发验收，都是最短路径。
多平台发布需要稳定的发布组合，所以我设计了"先创建组合、再发布"的流程，并支持不同组合之间快速切换发布。各平台的运营流量标签通常需要自己记录，既然有了发布工具，自然也可以帮我持续管理这些标签。于是，就有了"预设内容标签"这个功能。这些需求不会自动出现在一段通用提示词里，得有人在真实工作中遇见它们。如果我自己不长期做内容，很难想到这些。产品经验的价值，往往就在这里：你知道哪些地方会让用户反复难受并且感同身受。
四、从人工到自动，AI 自动化才是当前版本答案
我把自己的开发实践分成三个阶段：手工编程、AI 辅助编程，再到以 AI 为主的自动化编程。
第三阶段，不是同时开更多对话窗口，而是把已经验证的能力放进一个持续运行的场景。比如每日复盘，我会让 AI 定时回看前一天的工作：产品做了什么，内容做了什么，有哪些需要注意，下一步有什么建议。
那 AI 怎么能知道我做了什么？产品这一块，可以看代码变更；内容这一块，我每次创作都有对应文件夹，里面有文稿、原片、成片。AI 从这些记录中提取信息，而不是等我重新写一份"今天做了什么"交给它。
所以，自动化之前有很多基础工作。文件放在哪里，目录怎么命名，什么算完成，这些都影响它能不能稳定执行。一个"生成日报"的 Skill，只解决了被调用时做什么。完整场景还要确定：什么时候触发，从哪里拿数据，用什么能力，结果交到哪里。
我在做的一个社群付费服务也完成了自动化，也是类似循环：用户给场景，我先跑通，再让 AI 按规范整理成教程，生成分享消息，发到群里。而且，通过 AI 自动化，我只需在社群里表达观点，剩下的交给 AI：自动读取社群信息，整理并沉淀到知识库，甚至生成发布文案，我直接复制粘贴回社群，就能进一步提供更深度的服务。有些问题只需要一段提示词，不必硬做成工作流；有些可以沉淀成工具，再反复使用。
如何最大化 AI 的效果并让它持续发生？我的建议是，不妨先问自己：这件事怎样才能自动运行？这个问题会逼你梳理业务、定标准，而不只是不断找工具、试工具。
五、Agent 越强，越要想清楚哪些事情需要稳定
我正在做的 AI 工作台，早期产品偏通用，主要解决本地 Agent 的配置和使用。后来发现，还得往具体业务里走，于是增加内容工作台、工作流等能力。
我的想法是：把选题、生图、发布等能力封装成服务，用工作流组合，由 AI 员工执行，再向上打包成不同用户需要的解决方案。普通用户不应该先记住 CLI 指令或底层调用方式，才知道怎么做事，而是可以直接选择要用的服务。比如记录日历，选中相应服务，把沟通内容交给它，说"帮我记一下"，就应该能执行。
我不觉得 Agent 变强，工作流就过时了。A 做完交给 B，这种业务关系没有消失，只是某些执行者变成了 AI。工作流首先解决稳定性；需要灵活时，可以组合服务、嵌套工作流；遇到特殊情况，再让 AI 结合上下文处理。我的探索是，把稳定的部分固定下来，让模型承担一部分例外和复杂度，而不是把一切都交给临场发挥。
这款产品还在内测，目前已有部分用户开始付费，后续我会更侧重企业里的垂类应用场景。我并不打算做通用 AI，那是大厂的赛道；而垂类企业场景结合我自己的过往经验，是一个比较契合自己背景的方向。
很多人好奇我用了哪些模型，其实模型选择同样要落到场景里。我自己开发时，默认倾向使用能力最好的模型。如果 AI 模型是要放进产品里用的，这些场景就会考虑成本、稳定性和响应速度等因素。有的环节我会用 DeepSeek 系列模型，因为 DeepSeek 依然很有性价比，智能水平也完全够普通用户使用。如果大家想用，推荐试试硅基流动，接入很方便。总之，用户需要的是合适的服务，不一定是模型排行榜上的第一名。
六、能复制一份能力，不代表解决了维护问题
我对 Skill 的一个顾虑，是它太容易做出来、复制出去，却不一定有清晰有效的维护方式。你给别人一份 Skill，对方加了数据、改了逻辑。你更新之后，怎么同步？他的改动要不要保留？谁负责后续问题？
原先软件里的管理和工程问题，并不会因为封装形式变轻就消失。需要区分什么适合做 Skill，什么适合做插件，什么应该成为有人持续维护的软件。AI 带来的低门槛没有取消这些工程问题，只是让它们更晚才出现。
这也是我对"每个人都自己开发一个工作台"持保留态度的原因。用 AI 做出系统之后，还有部署、故障处理、持续迭代，以及从自己用到多人用的一系列问题。愿不愿意承担这些，跟能不能生成第一版，是两回事。
我也不追求让 AI 二十四小时一直跑。现在更多是定时运行一些后果不太严重的任务。模型执行长程任务的能力对我的价值，是原来三到五轮沟通的事情，可能一到两轮就完成了，而不是它运行得足够久。如果两秒就能做出来，我为什么一定要长程？最终要看它有没有减少我的介入，有没有更稳定地解决问题。
我觉得人的经验像一个筛选漏斗：你知道什么好、什么不好，才能从模型里提炼出符合自己要求的产品。没有这个漏斗，得到的可能只是模型的平均值。
眼下那个电商客户的图像纹路问题，还需要继续试。对我来说，持续做产品就是这样：流程跑通不是结束，用户指出哪里不够好，下一轮工作就从那里开始。基于场景驱动的循环，才是与 AI 最好的协同方式，它帮你不断蒸馏出真实世界属于你自己的最优解。
关于如何用 AI 持续做出有价值的产品，我认为：代码与执行可以交给 AI，但关键决策与判断仍需自己把控方向盘，这是我们对真实世界的感知与品味。好在，我们可以基于场景建立"实践---沉淀---AI 自动化"的飞轮，让有依据的决策沉淀进 AI 自动化工作流，让长期经验与观察形成的直觉在关键环节掌舵。这种双轮驱动，一方面放大 AI 的能力，另一方面也放大人的能力，最终一起驶向充满可能性与创造力的未来。
结语
从"拿技术实现产品"，到"拿场景去换一个产品"，再到把验证过的能力沉淀成自动运行的飞轮，超级峰走的这条路径也是很多 AI 应用探索者正在走或将要走的路，是一条共同进化路线。
硅基流动一直在做的是让这条路上比较"重"的几步变"轻"：模型不必自己部署，选型不必一次定终身，验证过的场景可以更快、更稳地跑起来。开发者可以把精力放在产品判断上，这个场景值不值得做、要解决什么问题。
硅基流动 Token 工厂为用户提供包含 DeepSeek、Qwen、GLM、Kimi 等在内的 170+ 主流开源模型，覆盖文本、图像、视频、语音等多模态能力，让"选模型、用模型"这件事变得简单，开箱即用、按量付费，兼容 OpenAI / Anthropic 协议，无缝接入各类工具，点击下方「阅读原文」体验。
如果你也在用 AI 做产品，欢迎来「开发者说」聊聊你的故事；也欢迎来硅基流动，把心里的那个场景，先跑起来。