我的个人创意本：用Workbuddy构建一个"创意孵化器"——用大模型把小创意养大、把相似创意整合放大，实现从想法到创意价值的全生命管理

摘要：workbuddy构建一个"想法孵化器"App 的完整复盘——用大模型给备忘录里注定死去的小想法装上孵化流水线（评分门 + 重写整合），再把相似的小想法合并成更大的想法。全文讲清三件事：产品的价值与功能框架怎么收敛、开发中六道真正卡住的坎（功能框架收敛 / IMA 归档 / 网络检索驱动成长 / 模板库蒸馏 / AI 选型失效 / 空壳 APK）、以及这个案例对 FDE 工程师的七条启发。 作者：蒋保平 ｜ 发布时间：2026-10-02 ｜ 标签：WorkBuddy、AI 辅助开发、AI及大数据、大模型应用、前端工程、效率工具 先说结论

做 AI 辅助开发，"让模型写代码"是最不值钱的环节。真正决定这个工具好不好用的，是三件事：把想法变成可匹配的设计语言、把 AI 生成的内容约束成真实可跑的界面、把离线包交付闭成"用户真能打开"的环。代码只是这三件事的副产品。

这篇文章不是教程，是复盘。素材来自「个人创意本」这个 App 从第一版迭代到 v98（versionCode 99 / 1.4.59）的全过程。它解决的是一个更幽暗的问题——备忘录里的想法注定死去：一个太小的想法撑不起行动，一堆相似的想法又各自单薄。创意本用大模型给想法装上一条孵化流水线，再用"相似整合"把单薄变成厚实。下面按"价值功能 / 开发难点 / 对 FDE 的启发"三块展开，难点部分只讲真正卡住过的地方。

适合谁读：① 正在用 AI 搭子（如 WorkBuddy / Cursor）做轻量 App 的开发者，想看一个完整项目怎么从想法走到上线；② 前端工程师，尤其关心"生成式 UI 怎么约束、设计系统怎么能被程序匹配"；③ 技术管理者 / 独立开发者，想评估"AI 辅助开发"到底省了哪部分、又在哪里反而更贵。如果你想看坑，重点读第二、三节。

一、价值与主要功能：让一个小想法，长成值得做的产品

结论：它不是"记想法的备忘录"，是"想法的孵化器"。整个产品围绕两条价值主轴——① 一个很小的想法，如何通过大模型持续孵化成一个有价值的想法；② 一堆相似的小想法，如何整合成一个更有价值的想法。原型生成、价值评估、知识库，都是给这两条主轴打工的器官。

大多数人记创意的终点，是备忘录里一行三个月后自己都看不懂的字。创意本押注的是另一条路：想法是有生命的——它需要被喂养、被验证、被合并。打开 App 第一眼不是列表，是一片星空图谱：每个想法是一颗行星，大小代表价值评分与成长值，相似的想法之间自动连着线。

想法星空图谱：本地生活类想法自动连线成簇，记账/读书等异类想法各自独立

主线一：从一个很小的想法，孵化成一个有价值的想法

一句"周末不知道去哪"能走多远？创意本给每个想法配了一条生长流水线：

一句话想法 → AI 完善 + 待确认澄清 → 每隔几天自动联网检索 → 评分门（整体价值不提升，整轮丢弃）→ 洞察与情报重写整合进介绍 → 新版本 + 成长值

成长时间线：5 轮生长，整体价值 3→8 递增，每轮洞察、新增标签、情报原文与整合状态

这张成长时间线就是孵化主线的实况：一个初始评分只有 3 的念头，经过 5 轮"检索→评分→整合"，长成了评分 8、成长值 58 的 A 类想法——"去哪玩"长出了"和谁一起玩"，又长出了"中小商户供给"。有三个设计值得单独说：

1. 评分门是硬约束。每轮生长前先评估一次、生长后再评估一次，整体价值不提升就整轮丢弃、不并入想法——宁可空转，不让想法被低质情报污染。这是"持续孵化"不跑偏的关键。
2. 重写整合，不是追加罗列。每轮的洞察与情报由大模型消化后重写进"一句话 / 问题 / 用户 / 方案 / 独特处"，产出新版本——想法介绍始终是一段连贯的表述，而不是越粘越长的情报流水账。版本演进完整留痕，随时可回溯。
3. 失败也留痕、可撤回。被评分门拦下的轮次标记"已评估·评分未提升"；万一降分更新溜进来了，App 启动时会自动撤销该轮情报与整合版本。名称始终只由人改，大模型在整合链路里碰不到它。

想法详情头部：成长值徽章、结构化字段（一句话/问题/用户/方案/独特处），这是被孵化过 5 轮之后的形态

主线二：相似的想法，整合成一个更大的想法

单个小想法的宿命是单薄。创意本把"相似性"变成了生产力：图谱按内容相似度自动连线（开篇那张星空图里，本地生活的五个想法已经自己抱成了团）；在全景视图里勾选它们，一条命令合并：

全景视图多选 3 个相似想法，出现"合并为一个大想法"操作栏

合并结果：字段互补合并、知识库与待办汇总，三个子想法自动挂到新想法之下

合并不是复制粘贴，有几层处理：字段互补合并（同位去重）、知识库去重并入、待办汇总、子想法自动挂上级——原来三个单薄的想法变成一个"本地生活"大想法的三根支柱，各自的知识积累直接抬高大想法的评估依据。配置大模型 Key 后由模型对内容做去重、互补与提炼的重写整合；无 Key 时本地拼接兜底，功能永远可用。

为两条主线打工的器官

① AI 原型生成——孵化出来的想法，值得"看一眼"。本地选型引擎先按想法语义从 32 个布局范式 + 5 套视觉风格里选型，大模型只输出内容计划（模块与文案，绝不写 HTML），本地渲染成可下钻、图表化的真实页面：

AI 原型：想法#1 生成的"周末去哪儿玩"首页，图表横幅 + 行程时间线，内容来自知识库情报

生成链路是本地选型 → 大模型只写内容 → 本地渲染三段式，模型从不直接碰 HTML：

AI 原型生成链路：本地选型引擎 → 大模型只写内容计划 → 本地渲染器产出真实可下钻原型页；内容未命中关键词时按想法名稳定兜底

关键点：选型与渲染都在本地，大模型只负责"填内容"。这也是后面难点二的根——当校验只认本地 8 个粗粒度范式时，AI 选的远程模板全被判无效，整条链路的"多样性"就塌了。（架构图另存为可独立查看的 SVG：ai-proto-flow.svg）

② AI 价值评估——孵化方向的裁判。三维 10 分制（市场潜力 / 技术先进性 / 产品独特性）加权出整体分，每个维度给文字佐证；横向全宽文本框承载长文，避免窄列撑爆：

AI 价值评估：三维评分 + 横向文本框佐证 + 同类产品特点与独特之处

③ 知识库感知——孵化的口粮。自动搜集的市场信息逐条做差异对比（威胁等级 / 价值分），既喂给评估当佐证，也喂给生长流水线当增量：

知识库：市场信息逐条带摘要、来源、威胁等级与差异对比入口

④ 开发建议——孵化到什么程度"值得动手"，它给答案。整合初始想法与市场信息，产出产品概念功能架构图、MVP 范围、"明确不做"清单与本周最小验证实验：

开发建议：功能架构图 + MVP 范围 + 明确不做 + 本周最小验证

⑤ 全景管理与离线可用——想法的操盘台与保险箱。全景视图批量管理（升降级 / 归档 / 子想法 / 多选合并），想法卡片直接显示成长状态（"已刷新 N 轮" / "评分未提升"）；整套应用打包成 Android APK（WebView + 本地静态服务），无网也能继续孵化：

全景管理：想法卡片带评分、成长状态与批量操作

功能速览表

说明：本章截图均来自 App 实机（v98），页面数据为演示引擎生成的示例数据；配置大模型 Key 后，孵化检索、内容整合与原型内容计划由真实大模型驱动。

二、开发过程：六道真正卡住的坎（不是流水账）

结论：这个项目的难点从来不在"写功能"，而在六处——功能框架怎么收敛、灵感怎么归档不丢失（IMA 知识库对接）、网络信息怎么驱动想法持续成长、模板库从哪来、AI 选的框架为什么没生效、以及"装了打不开"的空壳 APK。第一件是产品定义、决定方向；其余五件是实现卡点，其中两件（IMA 归档、网络检索）解决"想法怎么活下来、长得大"，三件（模板库、AI 选型、空壳包）解决"做出来、跑得通"。

下面只展开这六道坎，第一道是更前置的产品定义问题（功能框架怎么收敛），后五道是实现过程中的技术卡点（含"灵感怎么不丢""网络信息怎么驱动成长"两件数据/检索难题）；每条仍按"现象 → 真根因 → 解法"讲，不列版本号流水账。

难点一：完整功能框架怎么定——从核心价值反推，而非堆功能

现象：起步时只有一个模糊痛点——"备忘录里的想法会死"。但"想法会死"能长出多少功能？做着做着极易滑向功能堆砌：看见竞品有同步就加、有 AI 写作就加，最后又变成一个塞满开关的笔记 App，没人说得清它到底解决什么。

真根因：缺一个"收敛器"。没有把"核心价值"翻译成"功能边界"的推导逻辑，需求只会膨胀、不会收敛。功能不是从竞品清单抄来的，是从要解决的那个核心矛盾里反推出来的；没有反推，加再多功能也只是堆。

解法：用两条价值主轴当收敛器，从矛盾倒推功能——

• 矛盾一：一个太小的想法撑不起行动 → 反推出"生长流水线"（孵化主轴）：需要定期联网检索、评分门、重写整合，把小想法持续养大。
• 矛盾二：一堆相似的想法各自单薄 → 反推出"相似整合"（合并主轴）：需要相似度图谱、多选合并、子想法挂上级，把单薄拼成厚实。
• 再问一句"孵化出的东西怎么让人相信它值得做" → 反推出原型生成、价值评估、知识库、开发建议四个"器官"，它们全部为两条主轴打工，没有一个是独立凑数的。

关键判断：先定主轴，再定器官；器官必须能映射回主轴，否则它就是该砍的需求。 功能框架不是列清单，是把一个矛盾结构化成"谁来解决、怎么解决"。最终收敛出"两条主轴 + 五个器官 + 全景/离线操盘台"，正好对应第一节那张功能速览表——那张表本身就是这轮收敛的产物，而不是凭空加出来的功能堆。

难点二：如何与 IMA 知识库对接——让灵感与网络情报随时归档、不丢失、建素材库

现象：想法的价值常在"灵光一现就消失"。灵感碎片、随手记的念头、以及生长流水线抓回来的网络情报，散落在 App 本地和浏览器标签页之间；清缓存、换设备、或 App 重装，这些素材说没就没。更麻烦的是：它们若只堆在本地，未来想做"跨想法知识应用"（评估、原型、开发建议要调历史素材）时根本无从调取。

真根因：本地存储是"孤岛"，没有把"采集"和"归档"做成一条自动链路；而且外部知识库（如 IMA）的归档若不做结构化组织，塞进去也是一堆不可检索的碎片，沉淀越多越废。

解法：把 App 的"知识库/情报"与 IMA 打通——每条想法、每轮生长的情报、每次检索结论，按"想法"维度自动组织成带标签、带来源、带时间戳的可检索条目推送到 IMA；建立去重与增量归档，避免重复灌；灵感与情报永不丢，长期沉淀出"按想法聚合"的素材库，后续评估/原型/开发建议都能直接调取历史素材。

关键判断：归档的颗粒度要按"想法 + 时间"组织，而不是按 App 平铺。否则知识库越大越不可检索，所谓"素材库"只是另一个垃圾堆。

难点三：如何通过网络搜索到"有价值"信息，驱动想法持续成长

现象：生长流水线每隔几天要联网检索，但搜索引擎返回的是噪声——广告、聚合站、过时内容；而且"搜到了"不等于"想法成长了"，大量检索结果对想法毫无增益，反而稀释了核心，让一个清晰的念头越粘越乱。

真根因：检索数量与"想法价值提升"是两件事。缺一个"检索 → 筛选 → 判定增益"的闭环：没有对结果做可信度/时效性过滤，也没有用评分门去判定"这轮情报到底有没有让想法更值钱"。

解法：① 检索层做定向 + 时效过滤（限定权威源、按时间衰减），只取增量信号；② 每轮检索结论先由模型做"差异对比"（威胁等级 / 价值分），只保留与想法相关且有增益的情报；③ 最关键——用评分门兜底：检索 + 整合后重新评估，整体价值不提升就整轮丢弃、情报不并入。网络信息不是"越多越好"，而是"只留让想法长大的那部分"。

难点四：模板库从哪来——免费的"设计语言"蒸馏管线

现象：用户要"海量 UI 模板"，但 Mobbin、Screenlane、UX Archive 这类站要么收费、要么有反爬、要么已下线；即便能看，也都是给"人"看的截图，模型运行时并不能拿它去匹配。

真根因：模型运行时去联网搜模板既不经济也不稳定，"可被程序匹配的设计语言"必须离线沉淀成数据。而真实截图又必须有人/模型先"看"一遍蒸馏成 DSL。

解法：建了一条免费蒸馏管线——抓 Mobbin 的公开 SSR（免登录，Next.js RSC 流里直接带 flowActionScreens 数据），绕过有 CF 盾的 Screenlane 和已下线的 UX Archive；14 个品类 × 12 个样本 = 168 个真实 App 流程，抽 56 张截图做 2×2 拼图视觉蒸馏，沉淀出 13 个新 DSL 模板，补齐关键词词典。最终形成 32 模板库 + 两级打分匹配引擎（类型词典粗分 → 同类关键词细分）。

关键判断：模型放"建库期"离线蒸馏，不放"运行时"实时搜索——建库时费一次人工，运行时零成本。

难点五：AI 选的框架，根本没生效

现象：用户反馈"所有原型看起来都差不多"。查下来，AI 明明输出了 layout，但渲染出来永远是那几个通用布局。

真根因：生成链路的 layout 校验只查了内置的 8 个粗粒度范式（chat|commerce|media…），而本地库实际有 32 个布局（含 16 个蒸馏模板包）。AI 只要选任何一个远程模板（如 cart/job），都被判"无效"回退到兜底；更糟的是颜色从没让 AI 参与，命中低时还靠 Math.random() 随机——既雷同又跳跃。两套 key 体系对不上，AI 的选择被彻底忽略。

解法：三处同时修——① 校验改为查完整本地库（远程模板包纳入白名单）；② 新增 style 字段，让 AI 从 5 套视觉风格（fresh/minimal/glass/magazine/dashboard）里显式选配色，并在渲染时真正覆盖主色；③ 把"随机兜底"改成"按想法名稳定选型"（FNV-1a hash），同一想法固定、不同想法自然分散。实测 6 个不同想法 → 6 种不同框架 + 5 种不同配色，AI 选 cart/job 终于能命中模板包。

难点六：装了打不开——空壳 APK（最贵的学费）

现象：APK 安装后点图标没反应。验证发现 APK 里的 classes.dex 是 0 字节——Activity 根本没有任何可执行代码。更隐蔽的是：之前每个版本都验证了"APK 存在 + md5 一致"，却从没看过 dex 内容，于是这个致命缺陷漏了多个版本才被发现。

真根因：构建脚本 build.sh 里 javac 用了 -bootclasspath "$ANDROID_JAR"。android.jar 不含 java.lang.* 等核心类，拿它当 bootclasspath 会直接屏蔽掉 JDK 核心库，javac 报错 Unable to find package java.lang → 0 个 class 产出 → D8 空输入 → 空 dex。这是典型的"只看产物存在、不看产物内容"的验证盲区。

解法：① javac 去掉错误的 -bootclasspath，走默认 JDK 核心库，仅把 android.jar 放 -cp；② 在 build 脚本加防呆断言——构建后若 classes.dex 为空直接 exit 1，从根上杜绝再漏空壳包；③ 安装版本号主动提升，避免旧空壳包被部分 ROM 当"同版本覆盖"拒绝升级。修复后线上 APK 内 dex 恢复到 29660 字节且含 MainActivity。

附：从这几道坎提炼的方法论 - 可被程序匹配的东西，必须离线沉淀成数据，不要指望运行时现搜。 - 模型"选了"不等于"生效了"——校验链路和渲染链路要用同一套 key 体系，并实测验证生效。 - 构建产物的"完整性"不能只看"存在 + md5"，要看内容（如 dex 字节数）。验证盲区比代码 bug 更贵。 - 一切随机兜底都该改成确定性兜底，否则同一输入每次结果不同，调试无从下手。

三、这个案例对 FDE 工程师的启发

结论：当 AI 把"写代码"的成本压到接近零，前端工程师的价值就从"实现"迁移到"判断、约束与闭环"。

1. 真正稀缺的不是写代码，是把混乱想法结构化成需求的能力

结论先行：当 AI 把"实现"压到近乎免费，FDE 最值钱的一件事，是替用户（或替自己）把一堆零散、甚至互相矛盾的念头，翻译成"可判断、可取舍、可验证"的产品功能需求——而不是一上来就打开编辑器写组件。

这件事在创意本里是产品的起点：用户记下来的往往只是"周末不知道去哪""附近有啥好吃的"这种碎片，彼此看起来毫无关联。创意本没有把它们当孤立待办，而是先立起两条价值主轴（小想法孵化、相似想法整合），把混乱的念头收敛成结构——哪些值得养、哪些该合并、养到什么程度算"值得动手"。这一步没有任何代码参与，却决定了后面所有工作有没有方向，也正好对应第二节说的"功能框架怎么收敛"。

更关键的是验证：结构化出来的需求，很可能是"你以为他要、其实他不要"的。所以创意本内置了"开发建议"模块，直接产出 MVP 范围、"明确不做"清单与"本周最小验证实验"。对 FDE 的通用启发是：用最小成本做一个能跑的 MVP 去对齐真实需求，比在文档里反复推敲需求更可靠——一个周末能验证的小实验，胜过十页 PRD。需求不是讨论出来的，是对齐出来的。写代码，是这一切之后的事。

2. 你写的不再是"页面"，是"可被程序理解的设计语言"

创意本最值钱的部分不是某个组件，而是那张模板库 + 两级打分词典——它把"好看的界面"翻译成机器能匹配的结构化数据。对 FDE 的启发是：组件库、设计系统的终极形态不是"更多组件"，而是"每个组件带可检索的语义标签"，让 AI 能像人一样按场景挑框架。

3. 约束模型，比听模型话更重要

AI 原型生成里，最稳的设计是"模型只产出内容计划（home[] DSL），渲染交给本地引擎"。这反过来提醒前端：不要把排版、配色、布局安全的控制权完全交给生成式模型。用 schema 白名单、校验链、确定性渲染把模型框在安全的轨道里——模型的自由度和系统的健壮性，需要工程师来平衡。

4. 真实环境的问题，不在仿真里复现

空壳 APK 的坑，本质是"只在浏览器里验、从没在真机/真构建产物里验"。对前端工程师的通用教训：Web 优先能加速开发，但交付前必须把它放到最终形态里跑一遍——真机构建、真机安装、真 CDN 缓存。仿真环境的"绿"，常常只是因为它复现不出真实环境的中间态。

5. 布局健壮性是一种工程素养

从"大块空白卡片"到 emoji 再到 SVG 正式图表，再到"三列窄表撑大卡死改横向文本框"——这些都不是功能 bug，是内容驱动布局的健壮性问题。前端要习惯给长文本上 overflow-wrap/word-break、给动态内容设单列堆叠而非多列挤压、给随机/外部数据留安全边界。内容是不可信输入，布局必须防撑爆。

6. 闭环才算完成

发布成功 ≠ 用户拿到。创意本的发布三件套（版本号参数 + cache-busting + 文件指纹校验）和构建防呆，本质都在强调一件事：你定义的"完成"必须包含"对方真的用上了"。对 FDE 来说，埋点验收、真机链路实测、产物内容复核，这些"最后一公里"才是专业度的分水岭。

7. 确定性是可复现体验的底线

图表封面用 FNV-1a + mulberry32 做确定性随机——同一内容每次渲染同一张图，不闪烁。这条原则放大到前端：凡是"会重渲染的东西"（骨架屏、占位图、动效种子），都应绑定稳定种子，避免同一数据每次跳动。可复现，才可被调试。

一句话收尾

创意本这个项目，AI 替我写了大部分代码，但替不了我做三件值钱的事——把想法提炼成可匹配的设计语言、把生成内容约束成真实能跑的界面、把离线包交付闭成用户真能打开的环。代码越廉价，判断、约束与闭环的能力越贵。那些卡点不是障碍，是路径。

本文系作者原创并授权腾讯云开发者社区发表，未经许可，不得转载。