AI 最容易做出 Demo，最难做出产品：我做两个 AI 资讯站的经验
最近我做了两个站点。
一个叫 AI 作，每天会从二十多个英文艺术信源里提炼出一份简洁的 AI 资讯，三五分钟就能看完。
另一个叫 AI 件报，每天会分析三百多篇 AI 论文，再把其中最值得看的几篇用更容易理解的方式呈现出来。
这两个站做出来之后，很多人问我同一个问题：
这两个站到底是怎么做出来的？
有意思的是，如果放在以前，大家更关心产品体验，很少追问“这个东西是怎么做出来的”。但现在，只要一个产品沾上了“AI”“外部工具”“自动化”这些标签，大家立刻就会追问实现方式。
这里面当然有真实的求知欲。AI 确实降低了开发门槛，很多人都想学，也想试着做自己的产品。
但我也能感觉到一种潜台词：
既然现在不用自己写那么多代码，是不是谁都可以轻松做出来？
很多人期待的，是一个神奇的 Prompt，一个别人不知道的技巧，一个神秘的 skills 文件，或者一套“照着抄就行”的工作流。
但如果坦白说，这两个站做出来，几乎没有什么可以神化的技巧。我甚至一个 skill 都没有用，连正式的 PRD 都没写，更多时候就是直接用自然语言描述要怎么做。
真正有价值的，不是某个 Prompt，而是背后的思路。
一、AI 最容易做出“唬人的东西”，最难做出“长期可运行的产品”
这是我这次最大的感受。
如果让我给 AI 做产品这件事打个难度分，我会这样看：
- 做一个看起来很炫的 Demo，难度是 1
- 做一个自己真的会长期用、而且很好用的工具，难度是 10
- 做一个可以发布给别人、长期稳定运行、不经常出问题的产品，难度是 1000
这个差距是巨大的。
因为现在的 AI，最擅长的一件事，其实是帮你很快做出一个“像样的东西”。
比如你让它写一个小工具、做一个酷炫页面、配置一个多 Agent 团队、弄几个不同角色的 AI 员工，看上去都很厉害，而且往往几句话就能做出来。这种体验会带来很强的满足感，让人觉得自己好像突然拥有了很大的生产力。
但问题是，这些东西很多只是 看起来像产品。
我其实看过不少所谓的 AI 作品，坦白说，绝大部分都还比较粗糙。它们更像一个玩具，而不是一个真正可以持续运行、持续维护、持续对别人提供价值的产品。
所以我的判断和很多流行说法不太一样。
与其沉迷于研究那些 AI 的奇技淫巧，不如把更多精力放在对业务、产品和技术的理解上。
AI 确实降低了门槛，但它没有替代这些基础能力。恰恰相反，很多时候它把这些能力的重要性放大了。
二、技术选型：为什么我故意选了一套很“原始”的方案
先说这两个站的基本背景。
它们都不是团队项目，而是我个人做的；也不是我现在最重要的主力项目，更不是靠它们赚钱的核心业务。
所以我从一开始就有一个非常现实的约束：
我不可能持续投入巨大的精力去维护它们。
我需要的是一套：
- 足够简单
- 足够干净
- 足够可控
- 后期维护成本尽可能低
并且，这两个站本质上都是信息展示站，不需要复杂的动态交互，也不需要推荐算法、复杂的权限系统和商业后台。
基于这些前提，我最后选择的技术栈是：
- Python 脚本
- Jinja2 模板
- Markdown 作为中间格式
- 生成静态 HTML
- 部署到 Cloudflare
这套技术栈很冷门，甚至在很多人看来有点“老”，有点“不够时髦”。
以前如果是团队做产品，大家会很在意技术栈是不是主流。比如用 React、Next.js，一部分原因是生态成熟，另一部分原因是未来好招人、容易扩团队。
但在 AI 时代，我觉得一个很大的变化是：
AI 几乎什么代码都会写，所以技术选型终于可以真正从业务需求出发，而不是从框架流行度出发。
这两个站现在整个项目的 Python 依赖只有 6 个包。其中还有 2 个包是专门用来处理字体优化的。
依赖越少，系统越干净，长期维护成本通常就越低。和动辄几百个包的现代前端项目相比，这套方案反而更接近我真正想要的东西：
- 结构清晰
- 可读性高
- 易于理解
- 出问题时容易定位
更重要的是，我很担心 AI 帮我做一个大项目之后，慢慢把它变成一堆“屎山代码”。
很多人现在已经有这种体验：
- 开头写得很快
- 项目越来越复杂
- AI 越改越乱
- 出了问题之后，人已经读不懂了
- 最后整个系统不可维护
这两个站是我第一次真正用 AI 方式做产品，我不希望它们走到那一步。所以我的目标不是“让 AI 尽情发挥”，而是：
让整个架构从第一天开始就尽量可控。
在我的方案里，绝大多数中间输入输出都是 .md 文件，而不是直接在一堆复杂的数据结构里来回传。每一步输出都是人类可读的。这样一来，如果哪一步出了问题，我可以非常容易地知道问题在哪里。
这就是我整个技术选型的底层逻辑。
三、前端设计：不是 AI 的默认审美，而是人的判断在起作用
很多人问我这两个站的前端是怎么写的。
因为前端是最容易被感知到的部分。大家看到页面之后，会觉得“这个站设计得还不错”，自然会好奇它是怎么做的。
但坦白说，在整个项目里，前端的工作量其实并不算大。真正复杂的地方根本不在这里。
现在很多 Web Coding 工具的默认风格，大家都见过：
- 左边一个侧边栏
- 一堆圆角卡片
- 标准化按钮
- 一眼就能看出 AI 味很重
这种默认设计并不是不能用，但如果大家都这么做，最后很容易千篇一律。
所以我一开始就没想走“默认审美”这条路，而是想做一个更适合阅读、更克制、更稳定的设计。
我没有自己画设计图，也没有找参考图，而是完全通过自然语言描述：
- 想要什么气质
- 页面里放什么元素
- 字距、字号、间距怎么调
- 链接和标题的视觉关系应该是什么样
AI 先写一个 Demo，然后我再一点点调。
比如这个网站里，中英文的字体逻辑其实是反着来的：
- 中文标题用了更有气质的字体
- 正文用无衬线体保证阅读效率
- 英文部分又做了另一套搭配
这些东西 AI 不会天然替你决定。它当然可以给你生成一个“差不多能看”的东西，但要不要这样搭配、为什么这样搭配，还是人的判断在起作用。
所以从这个角度来说，前端设计也不是“AI 自动做出来的”，而是：
AI 给出基础草稿，人负责方向与判断。
四、真正复杂的地方，不是页面，而是 pipeline
真正让这两个站成立的，不是前端，而是它背后的整条生产管线。
无论是 AI 资讯站还是论文分析站，本质上都不是一个页面，而是一条自动化 pipeline。
这个 pipeline 至少包含这几个大步骤：
- 从网上抓取原始数据
- 对抓取数据做筛选和打分
- 生成内容
- 审核内容
- 构建页面
- 部署上线
但这只是大流程。每个环节下面其实又有很多子环节。
比如“写作”这个步骤，在我的系统里并不是一个单一动作，而是进一步拆成了几个不同角色：
- 编辑：读取所有素材，判断什么值得写，决定选题与角度
- 写手：根据编辑给出的结构和要求，把文章写出来
- 审核：检查稿件质量，如果不合格就打回重写
这里有一个很重要的原则：
关注点分离，比拟人化角色更重要。
很多人现在喜欢给 AI 团队设定各种角色，感觉像在带一个真实团队。但我更关心的不是“像不像人”，而是它在业务流程里承担什么职责。
编辑的工作重点是判断和组织素材；写手的重点是文字表达；审核的重点是质量控制。这样拆开之后，每个环节都可以单独优化，而且不会互相污染。
如果让一个角色从头干到尾，它就会同时受到素材、表达、结构、风格等多个维度的干扰，最后效果往往更差。
五、做 Demo 很容易，做连续运行的系统很难
为什么我说做产品的难度远高于做 Demo？
因为 Demo 只需要在某一个瞬间表现良好，但真正上线的系统要面对的是：
- 每天都运行
- 输入每天都不同
- 不同来源质量参差不齐
- 系统不能轻易崩
- 输出风格不能越来越漂
拿资讯站举例。
我这个站上线时有 13 个信源，后来扩展到 25 个，又去掉了几个，现在保持在 20 多个左右。不同网站可能会在不同时间报道同一条新闻。
于是问题就来了：
1. 去重不能太弱，也不能太强
如果去重太弱，今天和明天可能是同一条头条新闻反复出现。
如果去重太强，又可能把真正有新进展的内容也一起过滤掉。
2. 不同数据源的抓取逻辑完全不一样
有的网站有 API，有的没有。
有的网站适合早抓，有的网站适合晚一点抓。
像 Hacker News、Reddit 这种有投票机制的网站，如果抓得太早，人类反馈还没形成；抓得太晚，又可能错过时效。
3. 论文和新闻的处理逻辑根本不同
新闻需要快，所以是 T+0 的处理逻辑。
论文不需要那么快，反而更适合等几天，让社区反馈积累起来，再根据投票和讨论判断哪些论文更值得看。
所以两个站虽然都叫“信息处理”，但背后的处理方式并不一样。
很多人会觉得，“你开源一下，换个数据源不就行了，我也能做一个自己的头条”。
但问题恰恰在这里：
不同的数据源，不只是网址不同，而是整套业务逻辑都不同。
抓取方式、抓取时机、去重方式、筛选方式、写作方式、评价标准，全都要重新设计。
这也是为什么“看起来简单”的产品，实际上做起来并不简单。
六、Prompt 不是重点，反馈系统才是重点
很多人一提到 AI 产品，最先想到的是 Prompt。
但我的感受是，如果你要把系统做稳，Prompt 远没有反馈结构重要。
我现在的做法是：
- 我会给每个环节一套清晰的写作规范
- 也会不断优化这些规范
- 但真正决定系统稳定性的，是审核反馈够不够具体
比如说，一篇文章写得太长。
如果审核只告诉写手：
这篇文章太长了，请精简一下。
这个反馈很抽象，AI 可能根本抓不住重点。它有可能删错地方，也有可能重新写一篇新的开头，最后还是不合格。
而我现在更倾向于用“具体反馈”来约束系统：
- 当前写了多少字
- 目标字数是多少
- 超出了多少
- 建议删减哪一部分
- 每段大概要压缩多少
我甚至会用 Python 去计算具体字数，再把这些结果喂给审核环节。
我的一个经验是：
具体的反馈，要优于抽象的指令。
这件事看起来不“神奇”，但它比很多所谓的 Prompt 技巧都更有效。
因为 AI 最大的问题不是“不会生成”，而是“在模糊边界里很容易失控”。
七、真正让系统稳定运行的，是容错设计
如果只是做 Demo，你不需要考虑容错。
但如果要做一个每天自动运行的网站，容错几乎是核心能力。
这里面至少有几个层面：
1. 超时要可控
每一个步骤都不能无限等待，否则整条管线会被拖死。
2. 失败要能分类
不是所有失败都一样。
有的是硬失败，必须中断；
有的是软失败，可以降级继续运行。
比如配图生成失败，这当然不好，但如果文章本身已经可用了，就不应该因为没有图片而整篇不能发布。
3. 审核要有重试，但不能无限循环
审核不通过时可以打回重写，但重试一定要有上限，否则系统可能会一直卡死在那里。
4. 日志必须足够可读
只有日志可读，你才能知道：
- 哪一步出错了
- 为什么出错
- 是模型问题、数据问题还是系统问题
这些都不是“炫酷”的内容，但它们决定了一个系统能不能真正跑起来。
八、为什么我尽量少用 JSON，而更多用 Markdown
这里再分享一个比较具体但很有用的经验。
很多 AI 工作流喜欢让模型直接输出 JSON，因为看起来结构化、标准化，后面处理也方便。
但我自己的实践是：
在中间流程里，我尽量少让模型直接承担严格 JSON 输出，而更倾向于用 Markdown。
原因很简单：
- Markdown 对模型更自然
- 对人类更可读
- 对调试更友好
- 出错时更容易救
JSON 的问题不是不能用，而是模型在复杂场景里总会有一些小错误：
- 少个逗号
- 多个引号
- 结构不完整
- 某个字段意外丢失
如果你把整个系统建立在“模型必须 100% 输出合法 JSON”上，那么系统稳定性会很差。
我的做法是两层：
1. 中间格式优先使用 Markdown
2. 必须用 JSON 的地方，就写一个非常强悍的容错解析器，做防御性解析
这比不断去打磨 Prompt，试图让 AI 永远不犯格式错误，要靠谱得多。
九、一个有意思的发现：英文资料不一定适合直接写英文
这两个站的原始资料大部分都是英文。
很多人会自然地觉得：既然原始资料是英文，那让 AI 直接写英文，应该更容易写好。
但我的实际体验正好相反：
让 AI 直接基于英文材料写英文，很多时候反而更容易写差。
原因比较复杂，但我后来大概理解了一点：
当系统涉及语言转换时，AI 反而会被迫重新组织、重新思考，这会让它更认真地“消化”材料。
如果它直接用英文写英文，很多时候会更容易陷入“贴着原文改写”的惯性，反而更套路、更平。
所以在不同业务里，我对中英文内容的处理方式也不完全一样。
有些内容适合先写中文，再翻英文；
有些内容则适合中英文分别独立生成，因为它们面对的阅读体验要求不同。
这背后其实仍然是同一个问题：
不要把 AI 当成一个统一黑箱，而要根据业务去设计它的工作方式。
十、面向未来的编程：既要约束 AI，又要给 AI 留进化空间
这是我这次做这两个站时，最在意的一个问题。
因为 AI 进步太快了。
如果你今天把整个系统写得过于死板、过于结构化，那么未来模型能力变强之后，你可能吃不到新模型的红利。
它还是只能在你预设的狭窄轨道里工作。
但如果你给它太多自由，系统又会失控。
所以我现在越来越在意的是一种我自己称之为：
面向未来的编程
什么意思？
就是你既要用逻辑把系统兜住，又要给 AI 留出发挥空间。
举个例子。
我会给写作系统一些建议性的风格要求，但我不会把每一种表达都写死。我会告诉它：
- 你可以参考这些方式
- 如果你有更好的表达，可以使用
- 但要避免和之前的表达方式重复
这就形成了两层结构：
第一层：硬约束
- 字数范围
- 格式要求
- 去重规则
- 发布条件
- 重试上限
- 错误处理逻辑
第二层：软自由
- 选题角度
- 表达方式
- 叙事风格
- 结构优化
- 更好的写法尝试
当未来模型更强时，第二层会自动变好；
而第一层保证系统仍然稳定。
这就是我现在最看重的一种系统设计方法。
十一、最后的结论：AI 没有缩小高手和普通人的差距，反而可能放大了
最后说一个可能不太讨喜，但我越来越确信的判断：
AI 并没有缩小高手和普通人的差距，很多时候反而放大了。
因为高手原本就有：
- 更强的业务理解
- 更强的产品判断
- 更强的技术抽象能力
- 更强的工程组织能力
AI 出现之后，他们可以用更高的效率把这些能力表达出来。
而如果一个人只有一些零散的 AI 技巧，却缺少这些底层能力，那通常只能做出“看起来还行”的东西。
这两个站本身都不算什么复杂的大项目，但它们背后用到的，恰恰不是某种神秘 Prompt，而是很多年积累下来的产品和工程判断。
所以如果你问我，今天最值得学习的到底是什么，我的答案其实很简单：
- 不要只学 AI 技巧
- 要提升对业务的理解
- 要提升对产品的理解
- 要提升对技术与系统的理解
因为只有这样，你才真的有可能做出一个好产品，而不只是一个像产品的玩具。
最后一句话
如果你今天要用 AI 做产品，我觉得最重要的不是问：
“有没有一个更厉害的 Prompt？”
而是应该问：
“我设计的这个系统，能不能在未来随着 AI 进步而一起进步？”
这可能比任何技巧都更重要。