About

关于

写代码、做产品，也写下怎么做的。白天是 AI 解决方案产品经理——做的事是：深入业务一线找到真实的效率瓶颈，用 AI 系统化地解决，再把解法抽象成可复用的方法论。

3 年 B 端一线 + 正式产品岗经历，让我从"卖产品给客户"开始，慢慢走到"为客户和同事建系统"。Suniverse 是这个过程的副产品——把工作里 / 业余里做出来能复用的东西，集中放在一个地方。

我相信 —— 真实业务里的判断力比课程里的概念更值钱。所以这个站上的 3 个方法论（双数据源架构 / 三步精炼 Prompt / 三维决策框架），都是从具体项目里一个个问题解出来的，不是从培训里抄来的。

MVP 主义

PHTI 一天上线，video-scribe v0.1 先跑通最小链路再迭代。完整版是做不出来的——只有真实反馈能告诉你下一步往哪走。我对"先做一份完美的设计文档再施工"持怀疑态度。

先梳理工作流，再匹配工具

很多 AI 项目一开始就错在"我能用 AI 做什么酷炫的东西"。正确的顺序是先把人在做什么动作拆出来——比如运营 1 人 8 平台 70 条 / 周，先拆出"资讯采集工 / 选题策划 / 文案工 / 适配工 / 归档员"5 个具体岗位，再判断哪些可以让 AI 替代、哪些应该留给人。

AI 是加速器，决策是我自己的事

我熟练使用 Claude / Cursor / ArkClaw，但写 PRD 时大模型只是辅助。判断什么值得做、什么不值得做、什么必须人来做——这些没法外包给 AI。这一点越做项目越坚定。

60% 业务理解 / 30% 架构取舍 / 10% AI

做完几个 AI 项目后才发现，真正难的不是调用 LLM——调用今天就是几行代码。难的是业务理解和架构取舍。把这个比例记反——以为 AI 占 60%、业务 10%——多半做不成。

这是从项目里"自己长出来"的认知，跟课程概念无关。挑 4 条最有信号的：

把同事当用户

做内部 AI 提效项目和做对外产品是一样的——不调研就出方案，方案必然脱离实际。"选题灵感大多去知乎现刷现拿"这种需求要先问出来，再开始想架构。不调研直接写设计文档，是最贵的浪费。

先解决确定性高的问题，再碰确定性低的

我做内容中台时一开始想搞"全自动抓取" —— 但各地官网结构不同、反爬策略不同，稳定性根本不可控。后来才发现同事的痛点其实是"改写和跨平台适配"而非"找不到资讯"。先解决能确定解决的问题，再扩展到不确定的。

MVP 先用最少节点跑通

多次超时和报错之后才发现，简化方案反而更快成功。每多一层抽象就多一层不确定性——智能体调用工作流比直接运行更脆，工作流多节点串联比 Bot 直出三版更脆。MVP 阶段要追求确定性，不要追求优雅。

告警用原生自动化，内容生成用 AI——不要错配

实时触发、确定性高的场景用飞书自动化 / cron / webhook；信息聚合、内容生成的场景才用 AI。选工具要匹配场景特征，不是看谁更新潮。曾经想用 AI Agent 做任务超期告警——后来想清楚那是事件驱动场景，飞书原生就能做得又快又稳。

AI 协作       Claude · Cursor · Google AI Studio
工作流编排     ArkClaw · n8n · 飞书多维表格
后端 / 数据    Python · Supabase · PostgREST · ECharts
模型 / 语音    Whisper · SiliconFlow API · GLM-4.7 · 豆包 TTS
原型 / 设计    Figma · Stitch

Email     zsy1122334455@gmail.com