从一张用了六年的 Excel，到我的第一个 Android App 作者: zhaoyang 时间: 2026-08-25 分类: AI 开发 ## “朝夕有序”是怎样从一个念头，慢慢长成完整产品的 过去五六年，我一直用 Excel 管理自己的工作日程。每天上班后的第一件事，就是打开工作进度表，看看今天有哪些事情需要完成。合同续签、设备巡检、资产盘点、数据核对、机房运维、采购和项目推进，一项项排在表格里，开始日期、结束日期和当前进度也尽可能整理得清清楚楚。 <!--more--> 有了新的合同，我会从原来的流程模板中复制一份，再根据这次合同的具体情况修改每个环节的日期；有了新的盘点或巡检任务，也要先找到过去相似的记录，复制出来重新安排。如果事情推进得比预期快，实际流程已经进入下一环节，Excel 里的时间却还停留在原计划上，我就需要手工调整当前状态和后续日期；如果供应商没有及时回复，整个事项停在原地，表格里的后续计划同样需要重新修改。 这套方法陪伴了我很多年。从某种意义上说，那张 Excel 确实像是我的“外脑”，它替我保存了大量工作记录，也让我能够在纷繁的事务中维持基本秩序。但我慢慢发现，**Excel 能保存事情，却不能真正替我记住事情。** 现实里的工作不会严格按照表格往前走。有些事情今天看了一眼，暂时没有可做的动作，只能过几天再确认；有些事情正在等待别人回复，什么时候能继续并不由我决定；还有一些周期工作，虽然已经提前写进表格，但如果我没有主动翻到对应的日期，它们仍然可能被忽略。 表格里的信息越多，我越需要依赖自己的记忆。我仍然要记得某份合同进行到了哪一步、某个供应商是不是还没有回复、下个月有没有固定巡检、某位员工离职后账号和软件权限是否已经关闭。很多事情虽然已经写进 Excel，但只要我没有主动找到对应的行，它们就不会自己回到我的视野里。 我因此逐渐意识到，**真正的外脑不只是替我存放信息，而是让我可以放心地忘记。** 我应该只需要把一件事情告诉系统一次，至于它什么时候应该重新出现、下一步应该做什么、需要等到哪一天再确认，都应该交给系统处理。 这就是“朝夕有序”最初的念头。 ## 一开始，我只想做一个工作 Todo List 最早的想法其实很朴素。我想做一个工作台，用来跟进设备巡检、合同签署、资产盘点、数据比对等固定工作。对于合同和采购这类有固定流程的事项，我希望只要选择一次模板，系统就能自动生成相应步骤。每天早上打开系统，它告诉我今天应该做什么；下班前再看一眼，知道今天完成了什么，还有哪些事情需要继续。 公司的资产管理系统已经能够在员工离职时向外部推送消息，我希望工作台接收到这类消息后，可以自动生成账号关闭、权限回收等事项。以后其他系统如果产生了需要我处理的事情，也可以通过接口主动推送进来，而不再要求我分别登录各个系统检查。 在分析过去几年的工作进度表后，我发现那些 Excel 里其实早就存在一套隐性的产品模型：一个事项下面有多个步骤，一些步骤需要按顺序执行，一些工作会周期性出现，合同、采购、维修、盘点也有相对稳定的流程，完成以后还需要留下可以回顾的历史记录。 第一版设计因此很容易走向复杂。人员可以做成独立对象，设备可以做成独立对象，合同、供应商和软件授权也都可以建立结构化关联，再往下还可以增加审批单号、附件、条件分支和复杂流程。这些设计在逻辑上都成立，却离我真正想解决的问题越来越远。 我最终决定把方向收回来。人员、设备、合同编号和供应商信息不需要全部变成数据库里的业务对象，写在事项标题、说明和工作记录里就足够了。我不需要再建设一个资产系统、采购系统或者 ITSM，那些系统有它们自己的职责。我的系统只需要回答两个问题：**今天有什么事情需要我处理，以及如果今天处理不了，下一次什么时候再让我看到。** 这次做减法，后来成了整个产品最重要的边界。朝夕有序最终只保留事项、步骤、模板、重复规则和工作记录等少数核心对象。简单事情就是一条普通事项，复杂事情才使用步骤，重复工作交给周期规则，正在等待的事情暂时离开首页，到指定日期再重新出现。 ## 我想管理的不是日期，而是注意力 早期版本仍然沿用了 Excel 的思路，使用开始日期、截止日期和执行区间。如果一件事情计划从 8 月 1 日持续到 8 月 20 日，那么在这二十天里，它每天都可能出现在工作台上。但这恰恰延续了过去 Excel 带给我的噪音。 真实工作很少是一条从开始日期匀速走向结束日期的直线。更多时候，我今天联系供应商，随后等待回复；几天以后收到报价，再提交审批；审批以后继续等待，中途还可能需要补充资料，或者改到下周再确认。很多事情今天出现在眼前，并不意味着今天一定能够推进。我可能只是检查了一下当前情况，然后决定明天再看。 这不是失败，也不应该被定义成延期，它只是正常工作的一部分。于是，整个产品的日期模型发生了最关键的一次变化：系统不再试图预测一件事情什么时候做完，而是只记录它的“下次处理日期”。 **下次处理日期的含义，不是从哪一天开始连续执行，而是哪一天应该把这件事情重新交还给我。** 如果事情确实存在明确的最终期限，再额外填写一个可选的“硬截止日期”。前者负责调度我的注意力，后者负责提醒真实风险，两者不再混在一起。 每天面对一件事项时，我只需要作出几个自然的决定：完成、明天再看、改天处理、等待，或者记录进展。如果进入等待状态，它就暂时从首页消失，到了我指定的日期再重新出现。如果是多步骤事项，系统也只关注当前步骤，当前步骤完成以后，再根据模板规则决定下一步当天、下一个工作日或若干天后出现，而不是提前为未来所有环节制造一套很可能失真的时间表。 现在回头看，这不只是一项产品功能的调整，也是我对时间管理的一次重新理解。**很多时候，我们真正需要管理的并不是时间本身，而是注意力应该在什么时候重新回到一件事情上。** ## 为什么先做 Web，再做 Android 在产品形态的选择上，我决定先完成 Web，再开发 Android，这并不是偶然的顺序，而是当时最适合这个项目的路径。 项目刚开始时，真正困难的并不是手机界面应该长什么样，而是底层业务规则还没有完全稳定。事项和步骤是什么关系，重复任务应该怎样生成，“明天再看”和“未处理”有什么区别，等待状态什么时候恢复，流程模板怎样衔接，公司的资产管理系统推送过来的事件如何转化为事项，这些问题都需要经过大量讨论和真实使用才能确定。 如果一开始就做 Android，产品模型每调整一次，数据库、服务端接口、客户端本地存储、同步逻辑和手机界面都可能一起返工。相比之下，Web 更适合承担早期探索。它更新快，不需要重新打包安装，页面能够容纳更复杂的模板、设置、日历和数据管理界面，也更方便查看数据库结果、排查问题和快速验证交互。 Web 版本首先建立了整个系统的“事实中心”：PostgreSQL 保存数据，服务端负责日期计算、流程推进、重复实例、请假顺延和通知，独立 Worker 执行定时任务，钉钉和飞书负责主动提醒，外部系统通过接口把事件推送进来。等这些业务语义稳定以后，服务端 API 也逐渐成为一份可以运行的产品契约。 这时再做 Android，客户端就不需要重新发明一套业务规则。它只需要围绕移动场景解决三个问题：怎样更快地看到今天的事情，怎样更快地记下一件事，以及没有网络时怎样继续工作。复杂的流程计算仍然留在服务端，Android 只表达用户意图并负责本地体验。 从这个角度看，Web 并不是 Android 之前的临时版本，而是整个产品的业务底座；Android 也不是 Web 的缩小版，而是在稳定底座上重新设计出来的移动入口。**先做 Web，让我把产品想清楚；再做 Android，让这个产品真正进入我的生活。** ## 我不想让工具成为新的压力来源 这套产品思路也和我自己的生活经历有关。2025 年 10 月，我开始认真制定五年计划，长期方向并不模糊，我知道自己希望在职业、健康和学习上走到哪里。但制定一份大计划相对容易，真正困难的是把它拆成年度重点、阶段目标、季度计划和每周行动，即使已经拆出来，执行仍然很难。 工作任务经常无法提前准确预判。有时一天突然需要加班，有时又可以正常下班，原本安排好的运动、学习或个人计划很容易被临时工作打乱。偶尔一次还可以重新安排，连续几次以后，人就会产生明显的挫败感。计划表上留下越来越多没有完成的内容，仿佛不断提醒自己又没有做到；新的计划却还在继续增加。时间久了，打开计划本身都会带来压力，于是干脆不再打开，也不想继续完成。 我因此意识到，一个真正适合长期使用的个人系统，不应该只在一切顺利的时候有效，它更应该解决的是：**当生活已经被打乱以后，我怎样以最低的心理成本重新开始。** 所以朝夕有序从一开始就刻意避免制造焦虑。它不会因为我把事情改到明天，就立刻用红色告诉我“逾期一天”；不会因为目标暂停，就计算一个难看的完成率；也不会把断掉的计划变成必须补完的任务债务。事情没做完，可以重新安排；动作太大，可以缩小成下一步；最近很忙，可以暂时降低要求；正在等待别人，就先从视野里消失。 我越来越确信，真正好的效率工具不应该不断提醒用户不够自律，而应该帮助用户保留重新开始的能力。**计划被打断并不可怕，真正重要的是忙完以后还能从原来的地方接回来。** ## 从 Web 到我的第一个 Android App Web 版本上线以后，我开始认真考虑 Android 客户端。这对我来说有一层很特别的意义，因为它是我第一个真正完成的 Android App。 在此之前，我并没有完整开发过安卓应用。为了把它做出来，我需要先解决最基础的问题：安装 Android Studio、配置 SDK、处理缺失的 `android.jar`，再研究中文语言包，让整个开发环境变得更容易理解和使用。后来还经历了模拟器里的应用无法正常打开、构建环境不完整、真机调试、正式签名、安装包升级和桌面组件尺寸不一致等问题。 这些问题有些非常技术化，看起来甚至与产品设计没有直接关系，但只有逐一解决它们，应用才会从 PRD 和代码变成手机上真正可以点开的图标。第一次看到自己设计的功能运行在安卓手机上，看到桌面 Widget 能直接显示今天的事项，看到点击按钮真的可以完成、改期或新增任务，那种感受和网页上线并不一样。它不再只是浏览器里的一个系统，而是真的进入了我的日常生活。 Android 的产品定位也在开发过程中逐渐明确。它不需要复制 Web 上的全部能力。Web 负责配置模板、管理重复规则、查看完整历史和维护系统设置；Android 只保留今天、收件箱、日程、我的和快速新增等高频入口。复杂功能仍然存在，但被放到更合适的位置，不再挤占每天真正要用的界面。 桌面组件甚至比 App 本身更接近我对外脑的想象，因为真正的外脑不应该要求我先想起“我要打开这个软件”。它应该安静地待在手机桌面上，在我拿起手机时，就让我看到今天真正需要处理的事情。因此，今日事项、极速新增、日程、收件箱和生日纪念日等 Widget 逐渐成为移动端的重要组成部分，并针对不同桌面网格和实际尺寸做了响应式适配。 后来，Android 又补上了本地 Room 数据库、增量同步、离线操作队列和可信本地会话。前后各 30 天的事项形成了一个 61 天离线窗口，即使在飞机上、地铁里或者网络不稳定时，我仍然可以查看、完成、改期和记录事项，等恢复网络后再与服务器同步。到这一刻，它才真正接近我最初想象中的外脑：即使环境并不完美，它仍然尽可能替我记住事情。 ## 产品是在一次次“不对”里长出来的 从最初的 PRD 到完整产品，中间并不是一条顺利的直线。大量问题只有在真实使用以后才会暴露出来：手机端分类太多会显得拥挤，某一天任务过多会让日历难以阅读，流程模板的日期方向不够直观，重复任务可能生成错误实例，归档导出的内容不准确，周报可能把过多事项发给大模型，Android 页面也曾经显得复古、空洞，不像一个愿意每天使用的应用，Widget 在四列和五列桌面上的实际表现也存在差异。 很多时候，我给出的反馈非常直接，比如页面太大、布局错位、按钮没有反应、概念发生重复，或者系统替我作出了并未授权的决定。这些看似零碎的意见，实际上不断帮助产品接近真实需求。 一个产品的完整，不是因为开发者把最初的 PRD 全部实现了，而是因为它开始经受真实世界的反驳。PRD 认为应该这样，实际使用却觉得不顺手，那就修改 PRD；架构上看起来很优雅，但增加了认知负担，那就重新收缩；功能虽然做出来了，但用户不愿意使用，它就仍然不能算完成。 朝夕有序并不是在第一次设计时就被完整想清楚的，它是在一次次发现问题、承认问题、重新修改、再次部署和继续使用的过程中长出来的。 ## 让五年计划真正变成今天的下一步 当事项、日程、提醒、Android 和 Widget 都逐渐完整以后，我又回到了那个一直没有解决的问题：五年计划怎样真正进入生活？ 如果再做一套复杂的目标管理系统，需要维护 OKR、完成率、关键结果和各种层级，只会制造新的负担；但如果彻底不要目标，我每天完成的事情又可能与长期方向毫无关系。 最后，目标模块被定义成一座很薄的桥：长期方向连接年度重点，年度重点连接当前阶段，当前阶段最终只产生少量可以执行的下一动作。目标存在于后台，动作进入前台。我不需要每天重新阅读五年计划，也不需要为长期目标维护虚假的百分比，系统只要确保每个当前阶段始终存在一到三个真正可以执行的动作。 这些动作和普通事项没有区别，它们同样进入今天、日程和 Widget，同样可以完成、等待或改期。当一个目标动作完成以后，系统再询问下一步应该做什么，是安排一个更小的动作、稍后再决定，还是当前阶段已经完成。如果一个目标动作连续被改期，系统也不会用红灯批评我进度落后，而是把它放进“需要重新决定”，让我选择继续、缩小、暂停或放弃。 目标模块因此不再负责管理我的人生，它只负责防止那些重要的长期方向永远停留在规划文档里。**制定目标并不困难，困难的是让目标在每一个普通的星期一，变成一件足够具体、真正可以开始的事情。** ## AI 应该减轻负担，而不是接管生活 MiniMax 接入以后，我也刻意限制了 AI 的权限。它可以理解自然语言，可以建议步骤，可以总结一段时间的工作进展，也可以根据本周真实完成的工作，为我生成一份可以发给领导的正式周报，但它不能在后台悄悄创建几十个任务，不能自动修改目标，更不能替我安排整个人生。 AI 的价值不是替我作决定，而是减少机械性的整理工作。把零散记录整理成周报，把一个模糊想法拆成几个可以执行的步骤，把复杂事项总结成当前进展，这些事情原本会消耗额外精力，却并不是真正的决策。AI 可以承担这些摩擦，最终的确认仍然由我完成。 这也逐渐形成了产品的一条基本原则：**系统可以替我记忆，可以帮助我思考，但不能静默地替我生活。** ## 为什么最后叫“朝夕有序” 产品逐渐完整以后，我希望它拥有一个真正属于自己的名字，最后选择了“朝夕有序”。一方面，因为我叫朝阳，这个名字与我自己有一点特别的联系；另一方面，它也准确表达了我希望达到的生活状态。 “有序”并不是把每天的每一分钟都安排得严丝合缝，也不是要求自己永远不被打乱。真正的有序，是早上知道今天往哪里走，晚上知道今天完成了什么；即使中间被工作、生活和意外打乱，也仍然知道下一次应该从哪里接回来。 所以它的 Slogan 最终成为：**朝有所向，夕有所成。** 这句话不是要求每天都必须取得多大的成就。“有所向”只是不要忘记方向，“有所成”也可以只是完成了一个很小的下一步。 ## 它不仅是一个产品，也是我重新理解自己的过程 从一张用了五六年的 Excel，到 Web 系统，再到我的第一个 Android App、桌面 Widget、云端服务、离线同步、AI 周报和目标驱动，这个过程表面上是在开发一款软件，实际上也是我重新理解自己如何工作、如何生活，以及如何面对计划被打乱的过程。 我过去以为，只要把计划制定得足够详细，就会更容易完成；后来才明白，真正阻碍执行的往往不是缺少计划，而是每一次重新判断、重新拆解、重新安排和重新记忆所产生的认知成本。我过去也以为，计划没有完成，是因为自己不够自律；后来才明白，一个只能在理想状态下执行的计划，本身就不够可靠，真正值得信任的系统必须允许忙碌、变化、暂停和重新开始。 因此，朝夕有序最终想解决的，并不是如何把一个人训练得像机器一样严格。它想做的，只是替我记住那些不应该被忘记的事情，在合适的时候把下一步交给我；当我被现实打乱以后，也不急着责备我，而是帮助我从现在的位置重新接上。 这是我第一个真正完成的 Android App，也是我第一次把多年形成的个人工作方法，完整地变成一个可以运行、可以触摸、可以每天使用的产品。现在，我终于可以把一些事情放心地忘掉了，因为我知道，在该想起它们的时候，朝夕有序会把它们重新交还给我。 标签: none
评论已关闭