Back to selected work

碎片花园 / Fragment Garden

让被保存的灵感
重新生长

一款本地优先的 AI 笔记工具，用植物生长映射内容状态，通过“记录—回访—追加—发芽”，让旧内容重新产生价值。

  • AI Product Design
  • Personal Knowledge Tool
  • Human-in-the-loop AI
  • Vibe Coding
  • Local-first Web App
Role
Independent Product Designer & Builder
Project status
Working local-first MVP · July 2026

01 / Problem

内容被保存了，
但没有再次出现

真正的问题不是缺少收藏入口，而是保存动作结束后，内容逐渐失去上下文，也很少在合适的时机重新回到用户视野。

我把机会重新定义为：降低再次遇见旧内容、补上判断并继续行动的成本，而不是再做一个更复杂的分类系统。

问题与机会地图：灵感分散在不同工具，保存后失去上下文和下一步，产品机会是让旧内容重新进入当下。
  1. 01 / 内容入口

    灵感散落在不同工具里

    备忘录、聊天软件、浏览器收藏和相册分别接住内容，却没有统一的后续路径。

  2. 02 / 保存后的断点

    内容留下了，价值没有继续

    上下文逐渐丢失，回访依赖用户先想起它，收藏越多反而越像负担。

  3. 03 / 产品机会

    让旧内容重新进入当下

    由伙伴带回旧内容，再让用户追加判断、证据和下一步。

02 / Mechanism

记录—回访—追加—发芽

记录只负责接住内容。持续价值来自后续三步：旧内容重新出现、用户补上新的判断，最后在明确授权和确认后发展成一篇独立的新笔记。

  1. 01

    Record

    记录

    先把未成熟内容种下来。

  2. 02

    Rediscover

    回访

    伙伴把旧内容带回视野。

  3. 03

    Append

    追加

    补上判断、证据或下一步。

  4. 04

    Sprout

    发芽

    确认后形成有来源的新笔记。

核心生长循环：记录文字链接或图片，伙伴带回旧内容，用户追加判断，再将积累内容发芽为保留来源关系的新笔记。

用户负责价值判断、补充内容、确认是否发芽。

产品负责降低记录、回访与整理的行动成本。

03 / Key Experiences

三个体验，把收藏变成持续使用

花园、卡片、伙伴和 AI 不是四个独立功能。它们共同服务同一件事：让内容先被可靠接住，再在未来重新产生价值。

Foundation / Two modes

花园不是卡片列表的皮肤，而是第二种使用方式

花园模式让内容状态变得可感知，适合漫游与回访；卡片模式回到清晰、可检索的笔记，适合精确处理。模式切换服务任务，而不是视觉装饰。

碎片花园双模式真实界面：左侧为花园漫游与回访，右侧为卡片查找与整理。

A / Reliable capture

先接住内容，再可靠地整理

文字可以立即创建；链接和图片只有在处理成功后才创建正式笔记与植物。失败时保留任务供用户重试，不在花园中留下空卡片。

本轮素材中的链接与图片结果来自同一套公开演示备份，不代表本机第三方服务实时调用成功。

文字、链接和图片输入流程真实界面：文字直接本地保存，链接和图片处理成功后进入统一的可继续补充笔记模型。
  1. 文字本地校验后立即创建正式笔记与植物。
  2. 链接保留来源并进入整理任务，成功后才正式创建。
  3. 图片先真实预览，补充上下文后进入处理任务。
  4. 失败保留任务供重试，不留下空卡片或空植物。

B / Rediscovery

让旧内容重新回到视野

花园和伙伴不是装饰。伙伴会将旧内容重新带回用户视野，用户可以重新阅读，并继续追加观察、证据与下一步。

产品价值不在“推荐”本身，而在用户重新理解旧内容后留下新的判断或行动。

伙伴回访与继续生长真实界面：伙伴带回一条旧内容，用户打开后追加新的判断、证据和下一步。

C / Human-in-the-loop AI

发芽，而不是改写

AI 使用前需要用户明确授权。原笔记和追加内容作为受控上下文，生成结果需要确认；失败时不修改原文、不创建空内容，并保留新旧笔记的来源关系。

发芽成功预览与确认生成未在本轮本机跑通；页面只展示已验证的授权、失败保护与公开演示备份中的既有来源关系。

发芽的人机协作真实界面：生成前明确授权，失败不修改原笔记，既有演示数据展示新旧笔记的双向来源关系。
  1. 生成前说明将发送哪些数据，再由用户确认。
  2. 失败时不改原笔记、不创建空卡片，并允许重试。
  3. 确认后新内容独立保存，原笔记保持不变。
  4. 可追溯原笔记与新笔记保留双向来源关系。

04 / Product Decisions

我如何定义问题，
并做出取舍

我的角色是 Independent Product Designer & Builder：负责问题定义、核心循环、信息架构、AI 控制边界与验收口径，并通过 Vibe Coding 和 Codex 完成实现与测试回归。

01

Define the real problem

目标不是更快地存，而是更自然地回来

搜索只能服务“我已经想起某条内容”的场景。伙伴回访解决的是想起之前的那一步。

02

Protect the content model

处理任务不是正式卡片

链接和图片成功后才创建笔记与植物，避免用空卡片制造“已经保存”的错觉。

03

Separate usage modes

花园负责状态，卡片负责内容

沉浸和效率不必挤在同一界面；两种模式共享同一内容事实，但承担不同任务。

04

Keep AI reversible

AI 生成新笔记，不改写旧笔记

授权、预览、确认、来源关系和失败保护共同确保用户保留最终控制权。

05 / Result & Reflection

真实结果，
以及仍未被证明的部分

这不是一组概念稿。当前已有可运行的本地 MVP、公开演示数据和逐页核验记录；同时，未跑通或缺少证据的结果不会被包装成成功。

110 GitHub Stars
4 Forks
3 Active input types
11 Core states manually verified

GitHub snapshot · July 2026

产品职责与结果：从需求洞察、产品定位、核心机制、体验设计到 Codex 协作交付，并列出三种输入、十一项核验状态、一组来源关系以及 110 Stars 和 4 Forks。
  1. 01需求洞察

    识别“保存后遗忘”，而不只是搜索困难。

  2. 02产品定位

    从收藏工具转向可持续补充的个人笔记。

  3. 03核心机制

    定义记录、回访、追加、发芽的闭环。

  4. 04体验设计

    双模式、伙伴回访、授权与失败保护。

  5. 05Codex 协作交付

    完成文档、实现、测试回归与多轮迭代。

Reflection

植物隐喻只有在促成回访时才有价值

这次最重要的产品判断，是把游戏化从“奖励记录”转向“帮助旧内容回来”。花园负责建立记忆与状态感，真正的价值仍发生在用户重新阅读、追加判断和做出下一步的时候。

下一阶段首先应补齐第三方服务环境下的成功链路实拍，再用真实连续使用记录验证回访与追加是否发生；在此之前，不提前宣称效率或长期留存效果。

View public repository