Arkme Demo

这是一个用于候选人笔试的移动端前端 Demo。候选人需要克隆本项目后，在 Codex 客户端中根据给定需求继续迭代。完成后将内容推到你自己的 GitHub 中，并把项目链接发给我们。

候选人答题流程

候选人克隆项目后，请用 Codex 客户端打开本项目，并先输入：

请先阅读 AGENTS.md 和 docs/candidate-rules.md，然后按其中的答题规范完成后续需求。

本地测试入口

默认测试入口：

移动端 Demo： http://127.0.0.1:5173/

消息测试后台： http://127.0.0.1:5173/sendtest

若你电脑上的 5173 端口被占用，系统会自动按递增的方式创建新端口开启服务。

安排模块版本说明

当前 Demo 已实现到「安排 V2」的可验证闭环。V2 的目标不是把完整安排系统一次性做完，而是证明：用户可以手动创建安排，也可以在本机配置自己的 OpenAI-compatible API 后，从自然语言或粘贴对话中识别安排候选，确认后写入同一份低焦虑安排列表，并能在详情页理解这条安排为什么存在。

简单功能验证文档：

docs/arrangements-v2-demo-check.md

V2 当前已经能做到什么

1. 安排入口与首页

• 底部导航有“安排”入口。
• 安排首页包含标题、AI 设置入口、创建入口和“粘贴对话识别”入口。
• 首页承载同一份安排数据，不为今日、本周、无时间维护独立数据源。
• 安排按五段展示：
  • 需要关注
  • 接下来
  • 随时可看
  • 以后再说
  • 已处理
• 卡片主动作保持轻量，只暴露“已处理”和“以后再说”。

2. 时间总览与过滤

• 顶部提供“今日 / 本周 / 无时间”的轻量时间总览。
• 这些入口是对同一份安排列表的过滤，不是独立数据库。
• 点击“今日”“本周”“无时间”后，页面仍显示五段列表，只是列表内容按时间过滤。
• 在过滤状态下处理某条安排后，主列表和顶部数字会同步变化。
• 已处理或以后再说的安排不会继续计入顶部待处理时间数字。

3. 手动创建与本地规则解析

• 支持点击右上角“+”写下一个安排。
• 自然语言输入优先，表单补充。
• 支持本地规则解析关键句式：
  • 明天下午三点提醒我给客户打电话
  • 后天去医院
  • 周五前整理方案
• 如果识别不到明确字段，不报错、不强迫补全，会以原文生成可编辑的低打扰安排。
• 创建前会展示可编辑预览，用户可以调整标题、时间、提醒、关联人、地点和默认归类。
• 确认后跳转到安排详情，并展示“已生成安排”反馈。

4. 提醒字段

• 安排数据中包含提醒字段。
• 创建安排时可以识别或手动填写提醒。
• 详情页可以添加、修改或关闭提醒。
• 卡片可以展示提醒意图，例如“提醒 今天 15:00”。
• V2 暂不发送真实系统 push，只证明提醒能作为安排语义的一部分被理解和配置。

5. 详情页解释

• 详情页展示当前状态、时间、提醒、关联人、地点、责任人等信息。
• “为什么存在”区域展示来源片段或自然语言输入。
• AI 或示例识别生成的安排会展示识别依据。
• 详情页能说明这条安排是本地解析、示例识别、AI 识别还是手动/样例生成。
• 数据结构已预留 sources[]、sourceText、sourceQuote、originalCandidate、editedFields[] 等字段，为后续多来源和追溯能力做准备。

6. 收束机制

• 卡片支持“已处理”和“以后再说”两个主动作。
• 详情页支持更多次级动作：
  • 已处理
  • 以后再说
  • 提醒 1 小时前
  • 关闭提醒
  • 不再需要
  • 取消
  • 删除这条安排
• “已处理”表示事情完成或已经发生。
• “以后再说”表示暂时搁置。
• “不再需要 / 取消 / 删除”用于纠错和清理。
• 原定时间已过不会显示红色失败感，只使用“原定时间已过”的轻提示。

7. AI 设置

• 安排页右上角提供 AI 设置入口。
• 支持 OpenAI-compatible endpoint：
  • Base URL
  • Model
  • API Key
• API Key 仅保存在本地浏览器，用于本次 Demo 调用，不上传到即我服务器。
• 支持清除 Key。
• 支持测试连接。
• 保存配置不强制要求测试成功，避免配置流程阻塞用户体验。

8. 粘贴对话识别

• V2 提供“粘贴对话识别”的手动入口。
• 支持来源类型选择：
  • 对话文本
  • 私聊
  • 群聊
  • 发给自己
  • 其他文本
• 未配置 API Key 时，不伪装成真实 AI 调用，而是提供“查看示例识别”。
• 配置 API Key 后，点击“AI 识别对话”会调用用户配置的 OpenAI-compatible endpoint。
• 模型必须返回结构化 JSON，前端会做格式校验。
• 识别失败时保留原文，并提供重试、修改 API 设置、手动创建等出口。

9. 多候选确认

• 粘贴对话可以一次识别出多条候选安排。
• 候选列表分为：
  • 可直接确认
  • 需要你看一下
• 候选卡片展示标题、时间、提醒、来源片段和识别标签。
• 人物、地点、责任人只在有明确值且有助于理解时展示。
• 普通用户界面不展示百分比置信度，只展示：
  • 识别较明确
  • 需要你确认
  • 信息不完整
• 只有识别较明确、字段完整、未被忽略的候选可以被“确认明确候选”批量写入。
• 低置信度或信息不完整候选必须逐条编辑确认或忽略。

10. AI 写入规则

• 模型只负责抽取标题、时间、提醒、人物、地点、来源片段、缺失字段、责任人提示和识别标签。
• 五段归类由前端规则决定，不让模型直接决定最终 section。
• 确认写入后，安排进入同一份五段列表。
• 详情页可以展示来源片段、识别依据、识别信息和用户编辑痕迹。
• 用户对候选的修改只保存在本条安排中，V2 不做自动学习。

对应原始需求的达成情况

原始需求的核心不是做一个传统待办工具，而是验证“安排”能否统一承载待办、日程、提醒、规划、任务等未来事项，并用 AI 从自然语言和对话中生成可处理、可解释、低焦虑的安排。V2 已经覆盖了其中的最小闭环，但还没有覆盖完整产品化能力。

V2 已经达成的原始需求

• 统一未来事项容器：用“安排”统一承载待办、日程、提醒、任务、规划等还未发生但需要后续处理的事项。
• 五段状态模型：实现“需要关注 / 接下来 / 随时可看 / 以后再说 / 已处理”。
• 手动创建：支持用户主动写下安排，覆盖 AI 无法理解隐喻或模糊输入的情况。
• 自然语言优先：创建页以自然语言输入为主，表单字段作为补充。
• 本地规则解析：先覆盖最明确的句式，让 Demo 不依赖模型也能跑通基础创建。
• 提醒作为安排字段：支持提醒字段、提醒展示、关闭提醒、详情页修改提醒。
• 时间相关呈现：提供“今日 / 本周 / 无时间”的轻量时间总览和过滤。
• 低焦虑体验：过时安排不使用红色失败感，而是用“原定时间已过”的轻提示。
• 收束机制：支持“已处理”“以后再说”“不再需要”“取消”“删除”等不同收束方式。
• 详情解释：详情页能解释这条安排为什么存在、来源是什么、现在是什么状态、后续怎么处理。
• API Key 入口：支持用户配置自己的 OpenAI-compatible API，不把模型调用绑定到平台服务器。
• AI 识别闭环：支持粘贴对话识别、多候选、结构化 JSON 校验、用户确认后写入安排。
• 多候选确认：支持一次从一段文本里识别多条候选，并区分明确候选和需要确认的候选。
• 用户控制权：AI 只能生成候选，不能绕过用户确认直接创建正式安排。

V2 尚未达成的原始需求

• 没有从真实“发给自己”消息中自动捕捉安排。
• 没有从真实私聊消息流中自动捕捉安排。
• 没有从真实群聊消息流中自动捕捉安排。
• 没有自动给对方生成安排，也不支持给别人写入安排。
• 没有处理完整群聊中的成员关系、责任人分派和群内可见范围。
• 没有多来源自动合并，例如把家人多次提醒“去医院”的对话合并到同一条安排。
• 没有根据后续对话自动判断安排完成、取消、改期或不再需要。
• 没有真实系统通知或 push，只保留提醒语义。
• 没有完整日历系统，例如月历、周历、日程时间段视图和拖拽改期。
• 没有区分“用户必须自己做 / AI 可提前准备 / AI 可直接完成”的执行机制。
• 没有 AI 代办执行。
• 没有长期个性化学习，也不会把用户本次纠正自动用于下一次识别。
• 没有跨设备同步、归档、恢复、导出等完整数据治理能力。

后续建议

• V3 应优先补“真实对话理解层”：接入真实消息来源，识别私聊、群聊、发给自己的安排；处理多人责任关系；支持多来源合并；从后续对话中提示状态更新；继续保持用户确认和低焦虑原则。
• V4 应补“完整产品化层”：完整日历和真实提醒、协作权限、给对方生成候选安排、AI 代办执行、个性化学习、跨设备同步和数据治理。

一句话总结：V2 证明“用户确认后的 AI 候选可以进入安排系统”；V3 要证明“系统能从真实对话中持续理解安排”；V4 要证明“安排能成为完整的时间、提醒、协作和 AI 执行系统”。

V2 暂不做什么

• 不自动监听真实私聊、群聊或发给自己的消息流。
• 不给对方创建安排。
• 不真正提醒对方。
• 不做真实系统 push。
• 不做完整月历、周历、拖拽改期和时间段日程视图。
• 不做多来源自动合并。
• 不做复杂群成员分派。
• 不做 AI 直接代办执行。
• 不把用户本次纠正自动写入长期偏好。

V3 未来需要做到什么

V3 建议聚焦“从真实消息流中识别、更新和合并安排”，把 V2 的手动粘贴识别升级为更接近真实产品的智能安排系统。

1. 真实消息来源接入

• 从发给自己、私聊、群聊等真实消息流中识别安排。
• 明确区分真实消息流和用户手动粘贴文本。
• 给用户提供是否开启自动识别的控制入口。
• 避免后台静默识别造成隐私和误触发问题。

2. 多人聊天责任识别

• 在多人对话中识别谁提出、谁执行、谁受益、谁只是参与讨论。
• 候选安排中记录责任人提示，例如：
  • 我来做
  • 对方会做
  • 某人负责
  • 责任人需确认
• 默认只给当前用户生成和自己有关的安排。
• 对“可能不是你要执行”的安排进行明确提示，必须确认后才能写入。

3. 多来源合并

• 将多条相关对话归集到同一条安排。
• 例如：用户自己说“后天去医院”，家人又提醒“记得去医院”，后续姐姐询问身体情况，这些应关联到同一安排。
• 详情页展示 1-3 条关键来源，并允许展开更多上下文。
• 支持判断新消息是创建新安排，还是补充已有安排。

4. 对话驱动状态更新

• 从后续对话中识别安排是否已发生、已完成、不再需要或需要改期。
• 例如用户说“我今天上午去医院体检了，身体没啥情况”，系统应能提示之前的“去医院检查”安排可能已处理。
• 自动更新前应先给用户确认，避免误判。

5. 更强的低焦虑整理机制

• 对过期但未完成的安排提供更自然的处理方式。
• 支持批量“以后再说”。
• 支持轻量改时间。
• 支持长期未处理安排的柔性归档或降噪。
• 避免把未完成事项渲染成失败或负罪感。

6. 可解释的 AI 追溯

• 保存模型识别版本、来源消息、候选快照和用户确认记录。
• 详情页更清楚地展示“AI 初始识别 + 用户修正 + 后续来源补充”。
• 为多来源合并和后续自动更新提供可追溯依据。

V4 未来需要做到什么

V4 建议聚焦“完整时间系统、真实提醒、协作边界和 AI 执行能力”，从 Demo 进入更完整的产品能力阶段。

1. 完整时间系统

• 月历视图。
• 周历视图。
• 日程时间段视图。
• 拖拽改期。
• 时间段安排与截止时间安排并存。
• 循环安排和循环提醒。
• 更完整的今天、本周、本月、无时间总览。

2. 真实提醒系统

• 真实系统通知或应用内通知。
• 提前提醒。
• 重复提醒。
• 到点提醒。
• 未处理后的柔性再提醒。
• 支持关闭单条提醒或关闭某类提醒。

3. 协作和权限

• 支持给别人生成候选安排，但必须经过权限和确认。
• 支持对方侧镜像安排。
• 支持群聊中不同成员看到与自己有关的安排。
• 支持责任人变更和协作确认。
• 明确哪些信息只属于自己，哪些可以在群聊或协作关系中共享。

4. AI 代办执行

• 区分三类安排：
  • 只能用户自己完成
  • AI 可以提前帮用户准备一部分
  • AI 可以直接完成
• 对可执行安排提供 AI 预处理能力，例如整理资料、生成草稿、准备消息、创建文档。
• 真正执行前必须有用户确认。
• 执行结果要回写安排详情。

5. 个性化学习

• 在用户明确开启后，允许本地记录用户纠正样例。
• 支持查看、删除和清空本地偏好样例。
• 后续识别可以参考用户偏好，但必须可解释、可关闭。

6. 更完整的数据治理

• 支持安排归档。
• 支持删除与恢复。
• 支持来源证据管理。
• 支持导出。
• 支持跨设备同步。
• 支持本地 Key、模型调用和隐私策略的清晰说明。

即我「安排」模块原始需求口述

候选人任务

在AI编程时代，不再有传统的需求文档。更多的是拿到模糊的需求然后结合AI做梳理和处理。下面是需求发起人的原始口述需求。请候选人需要像真实工作一样，先把这段原始需求交给 AI 辅助分析，再自行判断出核心需求、版本节奏。然后结合自己的判断做实现。

原始需求

在以往的工具软件中，有很多待办、日程、项目、任务、提醒、规划等，甚至每个细分的一个app、一个功能模块等，但在我看来这些都属于还没发生但需要用户后续执行落地的大大小小的东西。 因此我给即我定义了‘安排’这个更抽象的更全新的功能模块，来统一处理这样的逻辑。承载以往的待办日程等相关的处理需求。在即我中，对安排模块，是这样规划的。ai可以从发给自己、从私聊群聊对话等地方，识别出用户的安排内容，比如发给自己‘后天去一趟医院’，安排模块自己生成一条相关日程。比如有人给自己发’明天来公司帮我带个早餐，我回复 好的。这时候自动在安排模块 对自己生成 明天到公司帮xxx带早餐，在对方安排模块生成 yy明天来公司帮自己带早餐 。 群聊中也会有类似的处理逻辑，唯一还不确定的是群聊中到底只展示和用户自己相关的，还是说整个群聊中有的安排都呈现。 安排项需要有多条归集或者合并机制，比如说，我规划了后天去趟医院，然后这时候也有可能因为家人知道了自己身体的情况，然后呢自己的爸爸和自己发个消息说，一定记得去医院，知道吗？然后我回复好的，我已经有安排了。然后可能姐姐也跟自己发条消息说，你这个身体情况怎么办的？然后我跟她回复。我已经到医院挂号了，那么这几条类似的东西应该合并在同一条安排里面。但是呢，需要再详情中把所有相关的对话上下文都呈现出来，让用户感知到对应到哪些内容。同时也需要考虑到AI识别的局限性。比如用户有某种具有隐喻的事项或者待办。比如用户输入‘～～’，但用户内心可能定义的是‘游泳 当然也有可能是其他，但是这个AI大概率是没办法识别出来的，因此还需要有手动创建安排内容的机制。 绝大多数的安排都和人、和时间、和地点等相关。从这个角度，安排的呈现也需要考虑到这内容。 然后，和时间有关的，不仅每个安排项后边尽可能识别出时间，或者让用户后续输入时间。还需要考虑到在日历中的呈现效果，让用户查阅日历的时候，就能够有全局总览之感。还有就是安排项的完成机制，不能总是永无止境的创造新的安排，这样子待完成的安排项会越来越多堆积着给用户很大的心理负担。那么需要有好的完成机制，完成机制最常规的就是用户可以进模块中手动，怎样更优雅的操作完成。但是更智能的可能是根据对话上下文等自动判断完成状态。比方说，后边用户和他的姐姐说，我今天上午去医院体检了，然后身体没啥情况，我这个鼻子后边可以正常恢复。那么对于之前创建的一个可能去医院检查的这个安排项来说，应该是对应到，然后呢会变更这个状态。然后我还能想到的是像时间的处理层面，待办呐、任务啊、提醒这些似乎都是截止时间的形式，但是日程呢似乎是时间段的形式。然后待办和任务这种有明确的完成状态，但是提醒这个好像是一种机制，提醒了就发生了就够了，并不一定对于用户来说，用户完成了。然后还需要考虑到提醒是一种非常中间的状态，用户可能明确创建个提醒，在什么时候给自己提醒，然后也有可能用户的创建的，嗯。像，比方说任务待办或者日程，用户可能需要去设置提醒。不管是提前什么时候提醒，还是说某种循环的提醒，让用户记得去执行这些项目。然后我还想到的是，有很多安排项出来之后，其实可以区分哪些是必须只能靠用户自己人工完成的，有哪些是可以AI先提前帮用户执行部分，再等着用户去做后边的内容的，还有哪些是可能AI就可以百分百帮用户直接给执行了的，那么这也需要有不同的处理机制。关于安排这个模块，我的想法是不管是手动还是智能创建的，整个项会越来越多越来越多。那么随着用的越来越久，用户可能感知到，哎呀，自己怎么好像堆积的要完成的事情越来越多，会产生一种无形的腹内感。但是我的产品哲学是，人生充满了变数，不一定必须需要按照遵循之前设定的轨迹，设定的要做的事情来完成。跳出这个圈子完全也没什么问题。因此我也不希望刚才这种担忧，就是待安排项越来越多，给用户很大的焦虑。并且这些项没有轻重缓急，全罗列下来可能也很头疼。那么我的判断是，理论上真真核心值得关注的安排项其实也是少数的。然后再就是这个安排项的识别的AI机制，我的思考是需要在产品里面让每个用户能够自己输入自己的API，可以消耗自己的TOKEN。哦，对了，我还想到了。比方说，在传统的任务管理软件中，用户会不断地创建任务、设定截止时间。但是呢，80%的任务其实用户并不能在截止时间完成。然后这些没有被完成的任务呢，用户也不是说不想完成了，也不会直接删除或者不会点完成。但是同时呢，其实也无法每条都确定后面到底新的截止时间是什么。因此呢，这里可能需要优雅地处理，不能像传统的任务管理软件，如果有很多这种超过截止时间没完成的，就一直一大坨红色的，截止未完成的提醒，让用户产生强烈的焦虑感。当用户在这个模块产生焦虑感的时候，对应对我们这个APP就会有一种负面的焦虑感，就会想远离。但是其实人生绝大部分的任务不完成又能怎样呢？也不会怎样，尤其是在当下这个社会形态下更是如此。因此，我们不能从产品层面就约束死，然后超过时间就什么强行的红色提醒干嘛的。那这块到底怎么处理呢？需要好好想一想。我这边可能大概的构思是，有一个长按之后的，或者右滑之后的，以后再说。我的判断是用户看到很多这些超过时间没完成了之后。安徽第一又不能点完成，第二又不能删除，第三呢？你说改修改新的，记得时间吧，Excel想不到那么最快的方式，内心上可能有种。哎呀，以后再说吧，比较符合用户的直觉。以上就是我口述大概想到的关于安排模块的需求，不一定很全，大家可以借助 aI来做一些补充，做一些分析。然后关于实现层面呢，因为大家时间关系，我的判断是不可能所有人都把所有的东西都实现上，因为每个人能力不一样。然后呢，因此需要大家通过AI把这个需求真正梳理清楚之后呢，然后自己判断优先级，以最小可用的方式然后每一个小版本一个小版本的迭代。比方说大家可以先把安排模块这个框架搭起来，然后呢把手动创建安排，然后完成安排这个最基础的做出来。这时候可能只做出这一个，我们就可以感知到大家对于交互界面的一些基本的审美和判断。然后第二层呢，我们真正想看的是大家对AI的理解和使用。第二层核心的就是需要在产品中增加可以绑定API。API大模型的API。然后呢绑定了之后呢，再把我上面罗列的很多种识别的场景，一个一个场景地做出来。就是我的建议是一个场景一个场景地做，不要贪多把所有场景做全。每做一个场景，其实你的能力对a的理解就会提升一点。哦，说到这个场景，其实还有一点我忘了说呢？比方说关于私聊之中，可能你的对象给你发消息说，嗯。那么理论上这种连续的对话之中，其实最终需要识别的是帮对象带A、B、C、D、E。几个物品。这种怎么在多人对话中识别的机制，大家需要考虑到，和Codex一起探讨，把这个好好识别到，好好执行到。我们为什么给这个任务呢？因为这个任务就是我们内部规划，马上我们自己就会开发上线的东西，当然我们已经开发了一个Demo，但是这个demo是几个月之前做的一直没升级，还有很大的升级空间呢，之前一直没时间做，现在在加速这个的落地。因为这个我们是完全全新创新的一个产品模块，因此呢，现在在市面上是没有任何可借鉴的。你如果想去借鉴其他的方案，那么大概率是失败的。因为我们的判断，很多人对这块的洞察是不够的。然后我们真正看重的点是，你能对这个需求第一层能理解多少？然后第二个就是当你和AI探讨理解的需求之后，执行层面呢，就是不管是交互的优雅，然后形式，还是说视觉层面的美观舒服层面。然后用户体验层面的好用层面，我们推荐的是，如果你时间不够。那就是尽可能一个版本一个版本把每个理应做的，把它打磨的好，而不是说一下子把所有需求都实现了，但是需求整体是很难用的，你需要考虑到的是，比方说你最终可能要实现这些需求，但是你真正交付给我们的需要是把我们当成一个线上的用户一样，需要是考虑用户的真实的体验、真实的感受。通过这个我们也可以判断出一种你把自己放在用户的角色的换位思考的能力。