Agent 能让人做出很多产品，怎样避免发布越多、维护越忙？

项目清单要写持续任务而非截图

为每个已发布产品记下当前入口、最近的用户反馈和仍需自己处理的事项。配置更新、内容补充、错误排查或账号服务等，若实际存在，就放进清单。把项目展示和持续任务放在同一页，可以看清哪些作品已经投入使用，哪些仍处于演示阶段。

可以记录这些事项什么时候发生、处理时需要找哪些资料，以及处理后如何确认恢复。这样决定要不要继续维护时，会有实际过程可看。预告没有披露项目的用户规模、收入或维护工时，本文也不据此给出它们的经营判断。

先处理用户卡住的那条任务链

收到反馈时，先问用户原本想完成什么，在哪一步停住，是否还有其他办法完成。若相同问题反复出现，优先让这条任务稳定下来，再考虑新增功能。修复后沿着用户的操作重新走一遍，并留下复现方式，避免同一个问题以后还要从头回忆。

没有反馈的项目，也可以先找适合的人试用核心流程。根据观察决定继续完善、保留为作品展示，还是暂停新的投入。选择暂停并不需要证明项目没有价值，而是明确目前能投入的精力与希望获得的反馈，减少所有项目同时等待处理的状态。

新项目开始前先安排后续责任

准备发布新产品时，提前写清谁接反馈、哪些问题会优先处理、暂时不承诺哪些功能。个人开发者可以保留简短的运行说明和常见故障记录，让之后接手任务的自己不必重新理解整个项目。是否继续发布，应结合现有待办与实际使用需求判断。

本文适用于同时维护多个小产品的个人开发者，也适合已经积累许多原型的人整理去留。摘要只提供了一段访谈预告，不能说明作者倦怠的完整原因，更不能推出所有多产品开发都不可行。这里讨论的是发布后的精力分配，不是对该作者项目结果的评价。

把讨论变成可检查的小任务

可以先观察自己一个项目一周的待办，先给功能开发与故障修复分别记时，再补上用户支持和依赖更新的工作量。若决定暂停，先停止新增承诺，说明现有用户怎样获取数据与支持，再决定归档仓库。归档不会自动关闭线上服务或完成用户迁移。本文没有取得访谈完整内容，也未统计作者维护日志。