记录行为的操作成本。
传统时间记录需要频繁填写表单：先选分类，再写内容，最后保存。记录动作一旦太重，用户很难在真实生活中持续使用。
计时器因此成为首页唯一的中心控件01选择活动02填写标题03补充描述04选择时长05确认保存
图为操作路径示意，不是产品截图。
JIKO迹刻
Record the moment.
Revisit the everyday.
一款围绕时间记录、日常回顾与事项提醒设计的微信小程序。 计时留下轨迹，回顾读懂轨迹，提醒把轨迹接向下一段时间。
让日常记录成为可以回看的时间轨迹。
JIKO 迹刻是一款围绕时间记录、日常回顾和事项提醒设计的微信小程序。用户可以用圆环计时器记录工作、学习、运动与生活，通过时间轴、每日报告和每周回顾理解时间分配；小迹助手则把自然语言转化为记录、提醒或简单对话。产品采用本地优先的数据策略，并通过微信登录与 CloudBase 完成云端同步。
把计时、回顾与提醒做进一个微信小程序。
- 我的工作
- 独立负责产品设计、界面交互、开发与发布准备；接入 DeepSeek 和 CloudBase 服务。
- 已有成果
- 已形成计时、时间轴、每日记录与周回顾流程，完成 AI 助手、提醒和云同步接入。
当前处于审核与内部测试阶段。网页上的计时器与助手演示都是本地交互示意，不保存记录、不调用模型；小程序本身已可运行，但长期使用效果仍待验证。
查看产品流程记录要轻，回顾要有用。
01选择活动02填写标题03补充描述04选择时长05确认保存
图为操作路径示意，不是产品截图。
记录行为的操作成本。
传统时间记录需要频繁填写表单：先选分类，再写内容，最后保存。记录动作一旦太重，用户很难在真实生活中持续使用。
计时器因此成为首页唯一的中心控件零散记录缺乏上下文。
单条计时数据很难回答时间究竟去了哪里。需要时间轴、每日记录与周回顾，把碎片组织成可以比较、可以回看的连续反馈。
同一份记录需要支持多个时间尺度记录与提醒彼此分离。
记录与待办通常存在于不同工具。正在发生的事与接下来要做的事被拆成两处，回顾因此失去了下一步的落点。
轨迹需要能一直延伸到还没有发生的日子
零散记录缺乏上下文。
单条计时数据很难回答时间究竟去了哪里。需要时间轴、每日记录与周回顾，把碎片组织成可以比较、可以回看的连续反馈。
同一份记录需要支持多个时间尺度NODES04 条LINKS00 条内容字段全部未填写
时间为概念示意数据，非真实用户记录。
记录与提醒彼此分离。
记录与待办通常存在于不同工具。正在发生的事与接下来要做的事被拆成两处，回顾因此失去了下一步的落点。
轨迹需要能一直延伸到还没有发生的日子PAST已记录 × 3PRESENT现在FUTURE待办 × 2
图示设计问题与三者关系，不是已实现的功能。
一次记录，
如何成为一条可以回看的轨迹。
时间不只是不断经过的数字。它可以被记录、组织、回顾，并与接下来的计划建立联系。 下面这一段由滚动推动：向下推进阶段，向上可以退回， 设备里的界面始终由你的滚动位置决定，而不是由计时器决定。
RECORD记录此刻
一次记录只需要选择一个活动并按下开始。计时器是首页的中心，也是产品里唯一需要立刻做决定的地方。
ORGANIZE组织记录
结束的计时不会停在计时器里。它变成时间轴上的一个节点，带开始时间、结束时间和时长，成为可以被翻阅的轨迹。
REVIEW回顾日常
同一份记录在更大的时间尺度上被重新阅读。一周、七天、活动分布，回答的是这段时间究竟去了哪里。
REMIND连接未来
轨迹不停在今天。自然语言被解析成结构化事项，确认后进入提醒，时间轴因此继续向还没有发生的日子延伸。
界面为依据已发布小程序结构重建的 SVG 示意，用于说明产品流程； 真实界面截图见首屏与下方产品图集。
RECORD记录此刻
一次记录只需要选择一个活动并按下开始。计时器是首页的中心，也是产品里唯一需要立刻做决定的地方。
ORGANIZE组织记录
结束的计时不会停在计时器里。它变成时间轴上的一个节点，带开始时间、结束时间和时长，成为可以被翻阅的轨迹。
REVIEW回顾日常
同一份记录在更大的时间尺度上被重新阅读。一周、七天、活动分布，回答的是这段时间究竟去了哪里。
REMIND连接未来
轨迹不停在今天。自然语言被解析成结构化事项，确认后进入提醒，时间轴因此继续向还没有发生的日子延伸。
界面为依据已发布小程序结构重建的 SVG 示意；真实界面截图见上方产品图集。
RECORD → ORGANIZE → REVIEW → REMIND
四个阶段不是四个功能，而是同一份记录在四个时间尺度上的样子。 界面上的每一个控件都在回答同一个问题：这段时间发生了什么，以及接下来呢。
选择活动，开始一次计时。
Loading JIKO product study…
四张真实界面，各自承担一件事。
这是小程序里实际交付的四个界面：周回顾、计时与助手、主题设置，以及圆环与显示模式。 同一版式、同一套色温，放在一起能看出它始终是同一个产品。 点击任意一张可以放大查看，方向键切换。
自然语言是入口，结构化草稿才是结果。
小迹助手接入 DeepSeek，把一句话里的活动与时间提取成字段， 形成一条可以确认的事项。这个界面上最关键的一步不是解析， 而是解析之后仍然停住，等用户确认。
选择左侧任意一句，查看它被解析成哪些字段，以及在确认之前会停在什么状态。
以上为交互原理示意：字段与解析结果依据真实助手的输出结构手工编写，不是 DeepSeek 的实时响应，也不会创建任何真实提醒。 小程序中的助手接入 DeepSeek 理解活动与时间信息，解析完成后仍需用户确认， 再由微信订阅消息发送到期通知。
四个决定，贯穿整条时间轴。
把圆环计时器放在首页中心，围绕活动类型、开始与暂停组织操作。开始一次记录只需要两个动作，记录入口服务于正在发生的事，而不是服务于一份事后要填的表单。代价是记录的粒度由活动分类决定，无法在计时中写更细的描述。
RECORD. REVIEW. REMIND.
迹刻当前处于审核与内部测试阶段。下面区分三件事：已经实现并可运行的、 已完成设计但尚未验证的，以及下一阶段仍需改进的。
- 完成计时、时间轴、日志、每日记录与每周回顾的核心产品闭环。
- 完成微信订阅消息、定时触发器、天气服务和 AI 助手的服务接入。
- 建立本地优先、支持导入导出与云端同步的数据管理方式。
- 完成主题、圆环、壁纸、深浅色模式和交互反馈等个性化体验。
- 完成隐私保护指引、审核材料、体验版上传与正式发布准备。
- 自然语言解析后的日程与待办草稿，需要真实使用检验确认率与修改率。
- 周回顾的活动分布是否真的改变了回顾行为，尚未有可用数据。
- 记录频率、提醒到达率与提醒关闭率都还没有长期样本。
当前最大问题是创建记录的操作成本仍然偏高，计时过程中无法补充描述； 其次是提醒到达率依赖微信订阅消息的授权次数，产品无法自行保证送达。 下一阶段先做更长周期的自用测试，再决定是否调整记录流程与提醒策略。