Dayflow 开发复盘：从 YAML 日程网页到本地优先桌面应用

Dayflow 最初只是一个很朴素的想法：做一个只在本地使用的日程与任务管理工具，既能让我直观地安排每天的事情，也能让 AI 编码助手直接读取和维护数据。

从 7 月 22 日目前能找到的最早一轮需求对话算起，到 8 月下旬版本逐渐收敛，整个开发周期大约持续了一个月。在这一个月里，Dayflow 从浏览器里的 YAML 任务页，逐渐变成了带有 SQLite 数据库、照片档案、离线地图、命令行与 MCP 接口的 Windows 桌面应用。这个过程并不是先画好完整蓝图再照表施工，而是在一次次需求确认、真实使用和问题暴露中逐步收敛。

这篇文章记录的重点不是功能清单，而是 Dayflow 为什么会变成现在这样：哪些需求一开始就确定了，哪些设计被实际使用推翻，又有哪些看似局部的问题最终促成了架构升级。

一、先确认真正要解决的问题

最初的需求可以概括成四点：

1. 它首先是一个个人使用的日程与项目管理工具，不需要账号、云同步或多人协作。
2. 数据必须保存在本地，而且格式应该足够透明，方便 AI 助手读取、修改和检查。
3. 任务不只有“今天做什么”，还包括循环任务、截止任务、指定日期任务和没有日期的待办。
4. 第一阶段可以先在浏览器里运行，但结构上要为桌面应用保留升级空间。

这些约束直接排除了不少常见方案。例如，第一版没有采用浏览器本地存储，也没有一开始就接入远程数据库。界面和数据服务被刻意拆开：前端负责交互，本地 Node 服务只监听 127.0.0.1，YAML 文件则是唯一数据源。这样既保留了人工可读性，也方便脚本和 AI 代理进行维护。

第一版的数据被拆成任务、项目、设置和历史记录几部分。任务和项目使用稳定 ID，循环任务的每次执行写入追加式历史；写文件时采用临时文件替换、备份和乐观版本检查，避免两个入口同时修改时静默覆盖彼此的数据。

这套设计当时是合适的。它足够简单，让产品语义能够先跑起来，而不是在需求尚未稳定时先背上一套复杂数据库模型。

二、任务语义比页面布局更重要

最早遇到的困难，不是组件怎么写，而是“日期”到底代表什么。

计划日期和截止日期不能混为一谈

一个任务可能计划在周一开始，也可能要求周五前完成。这两个日期可以同时存在：

• scheduledDate 表示打算何时处理；
• dueDate 表示最迟何时完成。

如果把两者压成一个日期，就会出现很奇怪的行为：一个计划今天开始、周五截止的任务，会在周二立刻被标记为逾期；只有截止日期的任务，又可能直到最后一天才出现，失去了提前推进的机会。

最终的规则是：有截止日期的未完成任务会在截止前持续可见；同时拥有计划日期和截止日期时，只要还没超过截止日，就不能因为计划日已过而被判定逾期。日历、今日页、未来七天和逾期分组都复用同一套日期区间判断，避免各页面各自解释日期。

这个小问题后来成为一个重要原则：产品语义必须先集中定义，再让各个界面消费它，而不是把规则散落在组件条件里。

循环任务不能让错过的实例凭空消失

循环任务最初按当天动态生成实例。这样不用提前制造大量记录，但也带来一个问题：昨天没有完成的循环任务，到了今天就从界面上消失了。

“错过后怎么办”其实没有唯一答案：

• 有些任务必须逐次补做，例如每周复盘；
• 有些任务只需提醒一次累计欠账，例如每天背单词；
• 有些任务过期就没有意义，例如每天早上查看天气。

因此 Dayflow 后来为循环任务引入了三种积压策略：持续保留、合并提醒和仅限当天。日常循环默认合并，周/月循环默认保留，但用户可以单独调整。这样比统一规定“全部补做”或“全部丢弃”更符合真实生活。

“完成”也不总是一个布尔值

在后续使用中又出现了“超量完成”的需求。它不是一种全新的任务状态：任务生命周期依然是已完成，只是这次完成值得额外标记。

如果把它硬塞成第三种状态，会影响筛选、统计、循环历史、项目进度和已有接口。最后采用的模型是保留 completed 状态，再增加 completionKind=overcompleted 作为完成事件的修饰信息。界面用星标和克制的浅金色动效表达，统计、CLI 和 MCP 则都能读取这个字段。

这次改动提醒我：状态和状态的属性不是同一层概念。 分清两者，能显著减少兼容成本。

三、从浏览器页面到真正的桌面应用

早期版本通过浏览器访问本地服务，随后尝试过 Edge 应用模式，最终才切换到 Electron。迁移的原因并不只是想要一个安装包，而是浏览器方案逐渐暴露出体验和交付上的边界。

例如，YAML 文件被修改时，开发服务器的文件监听会触发热更新，页面导航偶尔跳回“今日”；一键启动还要同时保证页面服务、数据服务和静态资源都正常。为此先后增加了数据目录排除、基于哈希的路由状态、启动健康检查和更稳妥的脚本包装。

Windows 双击启动脚本还踩过一个很具体的坑：带中文和 UTF-8 内容的 .cmd 文件，在部分命令行环境中会因为编码和换行被错误解析。最终把入口缩减成纯 ASCII 包装，只负责调用 npm.cmd，复杂逻辑留在跨平台脚本中，同时让错误窗口保持可见，避免“一闪而过”。

这些修补让浏览器版本可用，但也更加明确了桌面化的价值。正式的 Electron 版本不再依赖 Web 服务和端口，数据迁移到应用数据目录，并加入托盘、窗口状态、启动锁、备份恢复和安装包。

密码功能也做了边界说明：它使用带盐的 scrypt 哈希，只用于阻止别人直接进入应用，并不加密本地数据库和照片。把“入口锁”宣传成“数据加密”会制造错误的安全感，所以产品文档中必须明确二者区别。

四、一些没有走通的路线

开发过程中最耗时的探索之一，是让 Dayflow 直接使用 Wallpaper Engine 壁纸。

普通图片和视频并不困难，难的是 Wallpaper Engine 的 Scene 与 Application 类型。我们先后研究过透明窗口、专用捕获窗口、DWM 镜像、Windows Graphics Capture 和原生 D3D11 捕获，但每条路线都有明显代价：

• 可能额外弹出一个用户可见窗口；
• 子窗口镜像存在系统限制；
• 原生捕获会显著增加生命周期、显卡兼容和打包复杂度；
• Scene 包本身也不是可以直接交给浏览器播放的媒体文件。

继续投入当然可能做出一个勉强可用的方案，但它会让日程工具背负一套与核心价值无关的高风险图形子系统。最后的边界是：支持本地上传和 Wallpaper Engine 中能够直接播放的媒体资源；Scene 与 Application 类型保持降级提示，不承诺原生渲染。

这不是“技术做不到”，而是一次产品取舍。试验代码的价值，有时就是帮助项目更准确地知道自己不应该做什么。 已经证明不合适的原生镜像代码随后被移除，避免半成品长期留在主路径里。

五、YAML 为什么最终让位于 SQLite

YAML 的最大优点是透明，但它的代价会随着数据增长越来越明显。

在早期规模下，几十个任务和少量历史记录的读写没有压力。然而所有变更都需要解析并重写完整文件，历史记录增大后，写入时间随文件体积持续上升。压力测试中，数万条历史已经让一次写入达到秒级。与此同时，照片档案、批量导入、引用保护和更复杂的筛选需求也开始出现。

因此数据库重构不是为了“换一种更专业的技术”，而是因为数据规模和事务语义已经跨过了 YAML 的舒适区。

迁移到 SQLite 时有几条不能退让的要求：

• 旧 YAML 数据必须能够安全迁移，并保留备份；
• 循环任务历史继续保持追加式记录；
• 并发修改仍要有版本保护；
• Agent CLI 的能力不能因为存储层更换而丢失；
• 迁移失败不能留下半新半旧的数据状态。

这次重构把“存储实现”和“外部能力”正式分开。界面、CLI 与 MCP 不直接拼 SQL，而是调用共享的数据访问层。数据库后来经历了多次 schema 升级，但旧数据可以按版本顺序迁移，当前运行时也能检查数据库版本是否兼容。

六、AI 接口不是数据库字段的自动投影

Dayflow 从一开始就希望能被 AI 助手维护。YAML 阶段这很直接，SQLite 阶段则需要更明确的接口，于是增加了 CLI 和 MCP 服务。

这里很容易产生一个误解：数据库里增加一个字段，AI 接口是不是就自动获得这个字段？答案是否定的。

数据库 schema、共享领域模型、查询映射、写入逻辑、MCP 输入结构和返回结构是不同层次。增加一个字段时，需要逐层确认：

1. 数据库是否迁移；
2. 领域模型是否表达；
3. 查询和写入是否完整映射；
4. CLI 与 MCP 是否需要公开；
5. 老客户端缺省这个字段时是否仍然兼容；
6. 测试和文档是否覆盖新行为。

MCP 的自动启动也曾引发过一次真实故障。项目级配置把服务标记成必需，但指向的是尚未生成的构建产物，导致新的编码任务在启动阶段直接失败。解决方案不是删除 MCP，而是让它默认关闭或可选，在产物和环境验证通过后再显式启用。

这件事让我更重视一个规则：辅助能力不应该成为项目本身无法打开的单点故障。 尤其是为 AI 准备的工具，更要允许在工具暂时不可用时继续开发和修复。

七、照片档案让“本地优先”接受了一次完整检验

照片功能最初看起来只是“给成就附一张图”，很快却扩展成一个独立的本地档案系统：分类、拍摄时间、地点、EXIF GPS、拍摄想法、后续感想、批量导入、去重、缩略图、引用保护和离线地图。

这部分最终形成了几条稳定规则：

• 原图导入后保持不可变，编辑只修改数据库中的元数据；
• 使用 SHA-256 去重，不依赖文件名判断；
• 缩略图和缓存可以重建，原图不参与破坏性处理；
• 被成就引用的照片不能直接删除；
• 目录导入支持暂停、继续、取消和恢复；
• 坐标和 EXIF 时间必须被标准化，不能让不同时区和方向信息在界面上悄悄出错。

EXIF、缩略图与桌面打包

手机照片经常依赖 EXIF 方向显示。原文件看起来正常，不代表生成的缩略图一定正常。早期缩略图曾出现方向错误，解决方式是生成阶段读取方向并旋转，同时通过缓存版本让旧缩略图失效；原图本身始终不修改。

图片处理库 Sharp 升级后，还需要重新检查 Electron 打包。原生模块如果被错误塞进 asar，开发环境正常，安装包里却可能无法加载。因此最终把相关二进制明确解包，并对打包后的应用执行冒烟测试，而不是只在开发服务器里验证。

虚拟列表为什么只显示前八行

照片越来越多后，选择器改成了虚拟列表。但某次桌面布局调整把滚动容器从 window 改成了 .main，虚拟化逻辑仍监听旧对象，于是滚动后不再计算新行，看上去像是“只能加载前八行”。

修复不是增加分页数量，而是让虚拟器监听真正的滚动元素，并在排序变化时重置滚动位置。顺便加入了拍摄时间升降序，缺少时间的照片无论升序还是降序都固定排在末尾。

这个问题很典型：性能组件通常依赖隐含的布局契约。 页面结构改变后，即使类型检查和静态测试都通过，也必须在真实滚动容器中验证交互。

真正离线的地图

照片地图最终使用 MapLibre 和随应用分发的 PMTiles 矢量数据，实现东亚范围的离线查看。它没有在后台批量缓存公共地图服务，也不依赖联网时临时下载瓦片。

照片之间的连线只表示按时间和坐标推断出的移动顺序，不是 GPS 轨迹。这个限制被明确写进界面和文档，避免用户把推断路径理解成真实记录。

八、Windows 窗口体验也是产品的一部分

桌面化后，窗口本身就成了交互界面的一部分。Dayflow 先后处理了最大化、F11 全屏、自定义标题栏拖动、双击标题栏、窗口控制按钮和 Windows Snap 布局。

自绘标题栏很容易做出“看起来像桌面应用”的效果，却丢掉系统级能力。最终接入 Windows Window Controls Overlay，让应用保留原生窗口控制区域和 Snap 行为，同时把页面内容、弹窗和滚动条正确限制在标题栏下方。

这类问题很难靠截图发现。鼠标、键盘、拖动、最大化、不同缩放比例以及弹窗层级都需要单独验证。

九、最后一轮修复比新增功能更能暴露工程质量

后期版本以修复和发布整理为主，其中有两个问题尤其值得记录。

临时目录泄漏并不是生产缓存泄漏

开发期间发现系统临时目录中不断出现 dayflow-* 文件夹。最初怀疑是照片缓存没有清理，但检查后发现，正式运行时的缓存位于应用数据目录，真正泄漏的是测试创建的临时目录。

多组测试各自创建目录，却没有统一的回收路径。最后把临时目录创建和清理收敛到一个辅助模块，在成功、失败和异常退出路径中都执行清理。完整测试和发布检查后，残留数量归零。

先确认“谁创建了文件”，再决定修复生产代码还是测试代码，避免了在错误位置做无效优化。

浏览器能访问 GitHub，Git 却推不上去

发布时还遇到终端连接 GitHub 443 端口失败，而浏览器访问正常。进一步检查发现系统代理运行在本地端口，但 Git 没有使用它。为仓库配置正确的代理后，推送恢复正常。

这类环境问题很容易被误判为远端服务故障。浏览器和命令行可能根本没有使用同一条网络路径，排查时应该分别检查 DNS、直连、系统代理和工具自身配置。

十、Dayflow 的演进路径

如果把这段开发压缩成一条时间线，大致可以分成以下阶段：

现在的 Dayflow 已经形成了比较清晰的分层：

React 界面 / Electron 主进程 / Agent CLI / MCP
                    ↓
              共享领域与数据访问层
                    ↓
        SQLite 元数据 + 本地照片与离线地图文件
                    ↓
             备份、迁移与版本检查

数据库是当前唯一运行时数据源；照片原图、可重建缩略图和离线地图资源保存在文件系统中。应用不启动 Web 服务，不依赖端口，也不要求联网才能使用核心功能。

十一、这次 AI 协作开发留下的经验

回看整个过程，我认为最有价值的并不是在短时间内堆出了多少页面，而是形成了几条可以复用的开发原则。

1. 先让需求变成可判定的规则

“截止任务应该更显眼”不够具体；“从进入可执行区间开始持续展示，超过截止日且未完成才算逾期”才是能被实现和测试的规则。

2. 原型的数据方案不必成为永久方案

YAML 帮助第一版快速建立透明的数据契约，SQLite 则在数据量和事务要求增长后接棒。前者并不是错误选择，关键是提前知道它的退出条件。

3. 外部接口必须与内部存储解耦

CLI 和 MCP 应该表达稳定的产品能力，而不是把数据库表直接暴露出去。这样 schema 升级时，旧调用方仍有兼容空间。

4. 被否决的方案也需要收尾

Wallpaper Engine 原生镜像等路线在验证后被放弃，对应的试验代码也应该删除或隔离。保留一半可用的路径，会让未来维护者误以为它仍受支持。

5. 发布验证必须覆盖安装后的真实环境

原生模块、窗口行为、文件协议和权限问题，往往不会在开发服务器中出现。除了单元测试、类型检查和构建，还需要启动打包产物，验证数据库迁移、图片加载、离线资源和主要交互。

6. 修复阶段是在偿还隐含假设

虚拟列表默认滚动发生在窗口、测试默认临时目录会自行消失、项目配置默认生成产物已经存在——这些都不是显式需求，却会变成真实故障。后期修复的本质，是把隐含假设变成代码中的明确契约。

十二、仍然保留的边界

Dayflow 目前依然是一款个人、本地优先的 Windows 应用。它不提供账号体系、云同步和多人协作；入口密码不等于磁盘加密；离线地图有固定覆盖范围；照片连线是推断顺序而非真实轨迹；Wallpaper Engine 的 Scene 与 Application 类型也没有被包装成“完整支持”。

这些限制不是待办列表里的疏漏，而是当前版本主动划定的产品边界。只有当新的真实需求足以改变这些边界时，才值得引入对应的复杂度。

从 Dayflow 的开发过程来看，可靠的软件往往不是从“功能最多”开始的，而是从一次次准确地回答三个问题开始：用户真正想完成什么，当前方案在哪里失效，以及下一次修改怎样不破坏已经成立的部分。

十三、作为实际开发者的点评

前面的内容偏向事实记录，最后这一节换成开发者视角，直接评价这次 AI 协作开发做得怎么样。

总体评价：它证明了 AI 能完成项目，但没有证明开发可以不需要工程判断

Dayflow 是一次相当成功的 AI 辅助开发：一个非团队、约一个月周期的个人项目，完成了从需求分析、前端交互、本地服务到 Electron、SQLite、原生模块、离线地图和安装包的连续演进。AI 在阅读代码、批量修改、补测试、查文档、定位跨文件调用链和整理发布资料方面，明显压缩了实现成本。

但如果把它概括成“只要描述想法，AI 就能自动做出成熟软件”，结论会完全失真。真正决定项目能否继续向前的，仍然是需求语义、架构边界和验收标准。计划日期与截止日期的区别、循环任务的积压方式、入口锁与数据加密的区别、照片连线是不是轨迹，这些都不是模型通过多写代码就能自行回答的问题。

现在主流 AI 编码方案大致可以分成三类：编辑器内协作、能够操作终端和仓库的本地代理，以及在隔离环境中接收任务并提交变更的云端代理。它们的界面和自动化程度不同，但有效工作方式正在趋同：把仓库规范写进项目、把任务切成可验证的小单元、让代理能够运行构建和测试，并限制工具与权限范围。OpenAI 的当前模型指南强调目标、约束、授权边界和成功标准；GitHub 的云端编码代理文档也强调任务范围、仓库说明和可复现的依赖环境。OpenAI 模型与编码工作流指南、GitHub Copilot 编码代理最佳实践

因此，工具选择当然会影响体验，但它通常不是第一决定因素。2026 年一项分析了 7,156 个 AI 生成 PR 的研究发现，任务类型对合并率的影响很大，而且没有一个代理在所有任务类型中都最好；这也意味着脱离任务分布谈“哪个 AI 最强”，很容易得到误导性的结论。AI 编码代理分任务类型比较研究

这次开发做对了什么

第一，项目很早就建立了稳定的外部数据语义。YAML 后来虽然被 SQLite 替换，但任务 ID、循环历史、版本检查和 AI 可访问性没有一起被推翻。这使数据库重构成为存储层迁移，而不是产品重新开始。

第二，真实使用不断进入反馈循环。循环任务消失、无限任务只能看不能完成、照片列表只显示八行，这些都不是最初规格可以完整预见的。用户使用后提出具体问题，AI 回到代码和数据中定位原因，再通过测试与打包验证修复，这比一次性生成整套应用可靠得多。Anthropic 的官方实践把“给代理一个能判断通过或失败的检查”视为最高杠杆之一，并建议用测试、构建退出码和视觉对比形成紧密反馈环；Dayflow 后期的稳定性提升基本符合这个模式。Claude Code 最佳实践

第三，仓库说明和发布规则逐步变成了可执行约束。它们不仅告诉 AI 使用什么技术，还说明不能破坏什么、何时必须迁移、哪些安全表述不能混淆。VS Code 当前文档同样建议把架构、技术栈、安全和测试约定写进项目级指令，并让不同目录按需加载更具体的规则。VS Code 项目指令文档

第四，几个失败探索最终得到了收尾。Wallpaper Engine 原生捕获没有因为投入过时间就强行进入正式版，MCP 自动启动影响项目可用性后也被改成可选。这说明 AI 开发仍然可以做减法，而不是把所有生成过的代码都当作沉没成本保留下来。

中间存在的主要问题

最明显的问题是需求扩张过快。任务管理、成就、壁纸、照片档案和离线地图，每一项都足以形成独立子系统。它们在一个月内连续进入主线，造成了多次跨层修改：数据库字段、统计口径、CLI、MCP、桌面窗口和安装包往往需要一起变化。项目最终完成了这些修改，但维护面明显大于最初的个人日程工具。

更理想的做法是先定义版本主题和退出条件。例如 1.x 只解决任务语义与桌面交付，2.x 再引入照片，地图则在照片数据模型稳定后单独进入实验分支。AI 写代码很快，反而更容易让人低估新增功能带来的永久维护成本。

第二个问题是部分需求在实现后才补验收标准。Wallpaper Engine 的“支持”究竟是读取媒体文件、捕获桌面，还是直接渲染 Scene，一开始没有被限定；照片“轨迹”也需要后来澄清只是时间顺序推断。如果先写出“支持矩阵”和“不支持项”，可以少走不少原生捕获路线。

第三个问题是验证体系建立得偏晚。早期问题更多依赖人工发现，后期才逐步形成百余项测试、打包冒烟和临时目录清理检查。像虚拟列表滚动容器、标题栏拖动、Windows Snap、EXIF 方向这些问题，本来就不容易被普通单元测试覆盖，还需要固定的桌面交互与视觉检查清单。

第四个问题是长对话容易把已经否决的方向继续带在上下文里。当一个方案被连续修正多次，模型可能继续围绕旧假设打补丁，而不是重新判断目标。Claude Code 的文档建议在无关任务之间清理上下文，并在同一问题反复纠正后用吸收了新结论的提示重新开始；这一点对任何长会话编码代理都适用。Claude Code 上下文管理建议

第五个问题是 AI 集成曾经反过来阻塞开发。把尚未构建的 MCP 服务设成项目必需项，就是典型例子。工具能力不应该默认拥有无限权限，也不应该成为仓库无法打开的前置条件。Gemini CLI 的技能指南把易错操作收敛为低自由度脚本，并强调最小范围、审查第三方技能和避免硬编码秘密；这些原则同样适合 MCP、脚本和本地代理工具。Gemini CLI Agent Skill 最佳实践

不要把“感觉更快”当成已经提高生产率

AI 开发最容易产生的错觉，是界面变化得很快，于是整个工程也一定更快。实际成本还包括解释需求、等待代理、阅读改动、修复回归、重建上下文和维护新增代码。

METR 在 2025 年针对熟悉自身开源仓库的资深开发者所做实验中，观察到当时的 AI 工具让任务平均变慢约 19%；到 2026 年，后续实验的原始数据开始出现加速信号，但研究者认为参与者选择偏差、多代理并行和计时困难使结果不足以可靠估计当前提升幅度。这个变化既不能证明 AI 没用，也不能证明今天一定有固定比例的提速；它更适合作为提醒：生产率必须用自己的任务、质量和返工成本衡量。 METR 2026 年开发者生产率实验更新

Dayflow 的体感速度确实很快，但也发生了 YAML 重构、壁纸路线回退、MCP 启动故障、虚拟列表回归和测试临时目录泄漏。如果只统计生成了多少代码，会高估收益；如果把这些都视为 AI 的失败，又会忽略一个人能够在约一个月内完成并验证如此多子系统的现实成果。

更合理的评价指标应该至少包括：需求一次通过率、回归数量、人工审查时间、构建与测试通过率、安装后故障、被删除的试验代码、后续维护成本，以及最终真正被使用的功能比例。

怎样更好地使用 AI 进行开发

如果重新开始一次类似项目，我会采用下面这套流程。

1. 先写一页产品合同。 写清用户、核心场景、非目标、数据归属、安全边界和这一版本成功的判据。像“密码只锁入口，不加密数据”应该从第一天就是合同内容。
2. 把需求改写成例子。 不只说“截止任务每天显示”，还要列出计划日在今天、截止日在周五、周二未完成时应出现在哪个分组。例子同时是模型上下文和测试样本。
3. 按风险拆阶段，而不是按页面拆任务。 先验证日期与循环语义，再做桌面封装；先验证 SQLite 迁移和回滚，再做照片导入；先证明离线瓦片许可、体积和读取协议可行，再画地图界面。
4. 每个任务都提供可执行的完成条件。 至少包括需要运行的测试、预期输出、必须人工检查的界面状态和不能改变的行为。代理完成后要自己运行检查，而不是只报告“代码已修改”。
5. 让项目指令保持短而真实。 只写技术栈、目录所有权、关键语义、禁止事项和验证命令；已经可以由 ESLint 自动约束的格式，不必重复塞进上下文。OpenAI 当前指南也建议精简重复指令、只暴露相关工具，并在代表性任务上验证提示修改是否真的有效。OpenAI 模型与编码工作流指南
6. 给高风险操作降低自由度。 数据迁移、发布、密码更换和批量删除使用经过测试的脚本；普通界面探索可以保留较高自由度。AI 负责调用和解释，确定性代码负责执行脆弱步骤。
7. 保持小提交和可回退实验。 每个语义变化先提交基线，原生捕获、数据库重构等高风险探索使用独立分支。验证失败时回退实验，不要在主线继续叠补丁。
8. 定期重开上下文。 每完成一个里程碑，生成一份当前架构、已知限制和下一步目标的短交接，再开始新会话。不要让一个月的全部讨论永久挤在同一个上下文窗口里。
9. 使用第二视角审查，而不是让实现者自评。 可以让另一个代理只读审查迁移、安全和兼容性，也可以由人工对照验收清单检查。重要的是审查者拿到明确标准，并且不能为了让测试通过而修改标准。
10. 始终保留人的最终责任。 AI 可以查找、实现和验证，但产品承诺、隐私边界、依赖许可、发布签名、真实数据迁移和不可逆操作仍应由人确认。

最后的判断

以 2026 年的能力水平，AI 编码代理已经不是只能补全几行代码的辅助工具。只要能读取仓库、使用终端、运行测试并获得稳定项目说明，它完全可以承担跨文件功能、重构、诊断和发布整理等长链路工作。Dayflow 就是一个实际例子。

但“代理可以完成长链路工作”与“代理可以独立承担软件责任”之间仍有很大距离。它擅长把明确的规则快速变成代码，也擅长在有反馈信号时迭代；它不擅长替用户决定含糊的产品语义，也可能在错误方向上高速推进。

因此我对这次开发的中肯评价是：Dayflow 不是一次纯粹的自动生成，而是一次高强度的人机共同设计。AI 显著放大了执行能力，用户的持续反馈决定了方向，测试和工程约束则把速度转化成了可以交付的结果。 更好地使用 AI，不是写出一条更神奇的提示词，而是为它建立更短的反馈环、更清晰的权限边界和更可靠的验证系统。