夜雨聆风
你的AI工具，为什么总是"看起来厉害，用起来别扭"？
一个内容Agent从Demo到"每天愿意用"的真实改造记录
你有没有遇到过这样的AI工具？
打开一个AI写作工具，输入主题，它"唰"地生成一篇文章。看起来挺厉害，对吧？
但你真把它用在日常工作中，问题就来了：
- 点"生成"之后页面转圈，你不知道它卡住了还是在干活
- 生成了，但只有页面能看，想下载？手动复制粘贴
- 想发到公众号？还得自己打开后台、粘贴、调格式
- 想在服务器上用？本地跑得好好的，部署上去全是报错
- 写给同事看还行，写给不懂技术的朋友？内容太硬
这些问题单个看都不大。但加在一起，就决定了这个工具是"Demo"还是"日常用品"。
前段时间，我就在做一件事：把一个能生成内容的AI原型，改造成一个真的能跑起来的小工具。 这篇文章，聊聊中间补上的那些工程细节。
第一步：让AI干活的过程被看见
最早的版本，用户点"生成"后，页面上只有一行字：
processing | 21.9s
这个体验很糟糕。
你想想，你点了一个按钮，然后什么信息都没有。你会不会怀疑：是不是卡住了？是不是报错了？到底在搜索还是在写文章？
内容生成不是一瞬间完成的事。 它背后可能经历了：搜索资料→分析资料→生成内容→评估质量→修改内容。如果这个过程完全不展示，用户很难建立信任。
所以我做了一件看起来很简单的事：让执行步骤实时显示在页面上。
现在页面会显示这样的进度：
🔄 正在生成内容...
✅ 搜索相关资料
搜索完成
✅ 选择生成策略
使用策略：观点评论
🔄 Step 2/3 · 生成内容
正在生成公众号文章
你可以理解为：这就像点外卖时能看到"商家已接单→骑手已取餐→正在配送中"。 比只看到"配送中 21.9s"要安心得多。
更关键的是，哪怕某一步失败了，比如搜索资料没搜到，用户也能看到："搜索失败，继续使用已有内容"。失败时能降级，比突然报错友好一百倍。
第二步：从"凭空生成"到"基于素材再创作"
最早的版本只支持用户输入一句话，比如"帮我写一篇关于AI的公众号文章"。
但真实的内容创作不是这样的。
你写文章时，手边通常会有一些材料：
- 一篇技术学习笔记
- 一段项目复盘
- 一份会议记录
- 一堆零散的想法
所以我加了上传笔记功能。现在可以直接上传 .md 或 .txt 文件，然后告诉AI："根据这篇笔记生成一篇公众号文章，面向普通人，通俗易懂一点。"
这一步非常关键。
"凭空生成"和"基于素材再创作"是两回事。 前者容易空泛、像AI模板；后者更贴近你的真实经验、观点更扎实、风格更个人化。
换句话说：AI不应该替你思考，而是帮你把原始笔记变成适合各个平台的表达。 这才是普通创作者最需要的自动化。
第三步：让AI知道"对谁说"
这个问题来自我自己的使用体验。
同样一篇公众号文章，读者不同，写法完全不同。
面向程序员，可以写："MCP本质上是一个标准化的上下文协议。"
面向普通人，这句话就太硬了。更好的写法是："你可以把MCP理解成AI的'插线板'。以前AI只能自己想，现在可以通过MCP接上各种工具。"
所以我在生成流程里加了一个功能：识别用户的写作要求。
当用户输入"讲得通俗一点""面向小白""少用术语"时，系统会自动抽取这些要求，变成结构化信息：
目标读者：小白
公众号模式：通俗科普
表达语气：易懂
避免：少用术语
然后生成文章时切换到对应的模式。
这件事解决了一个很实际的问题：不是所有公众号文章都该写成技术博客。 很多时候，你真正想触达的，是"可能需要它但还没理解它"的人。这时候，文章的任务不是展示专业，而是降低门槛。
第四步：生成的结果，必须能带走
以前生成的内容只显示在聊天窗口里。测试没问题，但真实使用很别扭。
因为生成完以后，下一件事通常是：保存、修改、发给别人审阅、复制到发布平台。
所以我加了按平台下载Markdown文件的功能。如果生成了公众号、小红书、抖音三份内容，页面会出现三个下载按钮：
⬇️ 公众号
⬇️ 小红书
⬇️ 抖音
为什么按平台拆开而不是合并？因为每个平台后续处理方式不同：
- 公众号文章可能要继续排版
- 小红书内容可能要配图
- 抖音脚本可能要拆分成分镜
每个平台都应该有独立文件。 这是小细节，但小细节决定工具是不是顺手。
第五步：打通公众号草稿箱
这一步最让我感觉"这个项目开始接近真实工作流了"。
生成公众号文章后，现在可以直接把Markdown保存到微信公众号草稿箱。这里借助了一个外部开源工具 kuaifa，它负责和微信公众号后台打交道。
整个流程从：
生成 → 复制 → 打开公众号后台 → 粘贴 → 调格式 → 保存
变成了：
生成 → 上传封面 → 保存草稿
当然，目前还不是全自动发布。我反而觉得先保存到草稿箱更合理。因为公众号文章是对外发布的内容，最后一步最好由人确认：标题合适吗？封面合适吗？有没有事实错误？排版舒服吗？
AI负责推到"可发布前一公里"，人负责最后确认。 这个边界我觉得很健康。
最折磨的一步：Docker部署
说实话，这段时间最花时间的不是写AI Agent，而是让它在服务器上跑起来。
本地能跑，不代表服务器能跑。 这次踩了几个典型坑。
第一个坑：依赖太重
一开始Docker构建会拉一堆大包：torch、sentence-transformers、nvidia-cuda……普通云服务器根本扛不住。
很多人只是想先跑起来看看，并不需要本地向量数据库。所以我把依赖拆分成了两份，Docker默认使用轻量版本，不安装那些大包。
原则很简单：默认能跑，比默认全能更重要。 用户第一步不是研究架构，而是先跑起来。
第二个坑：依赖版本不锁
Python依赖不锁版本会出问题。比如Gradio升级后，旧代码里的参数就不兼容了。
后来我把关键依赖锁住：
gradio==4.44.1
pydantic-ai-slim[openai]==0.8.1
huggingface-hub==0.36.2
还有一个有意思的事：我一开始用 pydantic-ai，但它会带上Google、MCP、Bedrock等一堆额外依赖。我的项目当前只需要OpenAI兼容接口，所以换成了 pydantic-ai-slim[openai]，少装了很多东西。
教训是：依赖不是越全越好，尤其在Docker里，越多越容易冲突。
第三个坑：Gradio的API冲突
还有一个隐蔽的问题：页面运行时，Gradio会生成API schema。在某些依赖组合下会报错。但这个项目不依赖Gradio的API文档，只需要页面能正常访问。
所以加了一个兼容处理：如果API信息生成失败，就返回空信息，让页面继续加载。
这不是最优雅的方案，但在当前阶段，它是合理的工程取舍。
现在它更像一个"内容生产工作台"了
如果说第一版只是一个"生成器"，那现在它已经覆盖了这些环节：
输入素材 → 识别需求 → 选择策略 → 生成内容
→ 展示进度 → 保存文件 → 下载结果 → 推送公众号草稿
→ 服务器部署
这不是一个完整的内容自动化系统。但它已经不再只是一个Prompt Demo。
Demo追求的是"看起来能做"，工具追求的是"每天愿意用"。 而"每天愿意用"，靠的往往不是模型能力，而是这些不起眼的工程细节：
- 失败时能降级
- 过程能看见
- 文件能下载
- 部署别太痛苦
这些东西不酷，但它们决定一个AI项目能不能离开本地终端。
下一步做什么？
目前还有几个明显的短板：
- 1命令行能力还没完全跟上Web UI。 后面需要让CLI也支持风格和受众参数，方便自动化任务。
- 1RAG需要更轻量的部署策略。 可能会拆成"轻量模式"和"增强模式"，让用户按需选择。
- 1发布链路还可以扩展。 小红书图文卡片、抖音口播分镜、发布日历、多平台状态追踪……但我不急着堆功能。因为这段时间最大的感受是：AI项目真正难的，不是多做几个Agent，而是让每一步都稳定、可控、可解释。
写在最后
做这个项目之前，我以为重点是Prompt、Agent架构、模型能力。
做下来发现，真正拉开差距的是工程耐心。
一个能用的AI Agent项目，至少得回答这些问题：
- 用户怎么输入？
- 过程怎么展示？
- 失败怎么降级？
- 结果怎么保存？
- 怎么部署到服务器？
- 依赖冲突怎么办？
- 怎么让普通人也能看懂生成内容？
没有哪个问题特别炫。但每解决一个，工具就离真实使用近一步。
所以如果你也在做AI Agent项目，我的建议是：别只盯着"更聪明的Agent"，也要多花时间做那些看起来普通的事情——按钮、日志、下载、配置、部署、错误提示。
这些东西，才是一个AI项目从玩具变成工具的路。
*你觉得一个AI工具从"Demo"变成"日常工具"，最关键的一步是什么？欢迎在评论区聊聊你的看法。*
— 完 —
