先把要完成的工作说清楚：你需要一个能看见项目进度、限制同时进行任务数量，并且能把“想法”推进到“已发布”的轻量系统。对于一人公司，Trello 更适合管理内容、客户交付、产品想法等混合任务；Linear 更适合独立开发者或研发驱动的产品，把需求拆成 issue，持续追踪开发、测试和发布状态。无论选择哪一个，重点都不是把所有事情记录下来，而是让下一步行动始终清晰可见。

先选管理方式：看板优先，还是研发流程优先

选择 Trello：当你的工作不只有开发

Trello 的核心优势是直观、灵活、上手快。你可以用列表代表阶段，用卡片代表任务，再通过标签、清单、截止时间和附件补充上下文。它更适合下面几类一人公司工作：

• 内容选题、写作、审核和发布；
• 客户咨询、报价、交付和回访；
• 服务项目的阶段管理；
• 产品想法、用户反馈和市场机会收集；
• 同时包含开发、运营、销售的混合型项目。

如果你每天需要在产品开发、内容生产和客户交付之间切换，Trello 通常更容易让所有工作放在同一张“经营看板”上。它的价值不在于复杂的研发细节，而在于让你一眼知道每张卡片现在处于什么阶段。

选择 Linear：当你的核心工作是持续研发

Linear 更适合以软件产品为主的一人公司，尤其是你需要持续管理需求、缺陷、版本和开发任务时。它的组织方式更接近研发团队使用的 issue tracker，可以围绕状态、优先级、周期和路线图来管理工作。

适合使用 Linear 的情况包括：

• 你每周都会进行产品迭代；
• 一个功能经常需要拆成多个开发任务；
• 需要区分缺陷、功能、改进和技术债；
• 希望把开发任务与代码提交、评审或发布流程衔接起来；
• 需要按周期规划近期工作，并观察路线图变化。

Linear 的学习成本通常高于简单看板，但当项目开始出现大量研发任务时，结构化管理能减少“凭记忆推进”的风险。

一张表完成初步判断

判断问题	更适合 Trello	更适合 Linear
工作类型	内容、服务、客户交付、混合任务	软件产品、功能开发、缺陷修复
上手难度	低，几乎可以直接建立看板	中等，需要理解 issue、状态和周期
进度查看	通过列表和卡片位置查看	通过状态、项目、周期和路线图查看
任务拆分	适合较粗粒度任务	适合拆成多个可执行 issue
适用重点	让所有工作可视化	让研发流程可追踪
一人公司典型用法	管理整个业务	管理产品研发主线

不要因为 Linear 更像专业研发工具，就把所有事情都搬进去；也不要因为 Trello 简单，就用一张卡片承载一个完整产品。选择标准只有一个：工具是否能降低你推进下一步的成本。

推荐的卡片流转模板

无论使用 Trello 还是 Linear，都可以先采用下面这条基础路线：

想法池 → 待处理 → 开发中 → 验证中 → 已发布

如果你的工作以服务或内容为主，可以把“开发中”理解为“制作中”；如果你的产品涉及技术测试，可以在“验证中”后增加“待修复”或“待发布”。

1. 想法池：只收集，不承诺

这里存放尚未决定是否执行的想法，包括：

• 用户提出的需求；
• 自己观察到的问题；
• 竞品或行业变化带来的机会；
• 尚未验证的功能设想；
• 未来可能制作的内容或服务。

想法池的卡片不需要写完整方案，但至少要回答三个问题：

想解决谁的问题？
这个问题为什么值得现在处理？
我准备通过什么方式验证？

建议给卡片加上来源标签，例如“用户反馈”“自己判断”“客户需求”“市场观察”。这样在每周复盘时，你可以区分真实需求和一时兴起的想法。

2. 待处理：本周期准备做什么

进入“待处理”意味着这项工作已经被选中，而不是单纯记录。每张卡片应该具备明确的完成边界。

卡片标题不要写：

优化产品

改成：

为新用户增加首次登录引导

卡片描述可以采用这个模板：

## 目标
让首次使用者完成第一次关键操作。

## 完成标准
- 用户能看到引导步骤
- 用户可以跳过引导
- 完成后不会重复显示
- 在移动端完成一次检查

## 依赖
- 确认需要引导的关键操作
- 准备引导文案和界面方案

## 不做什么
- 本次不重做整个新手教程
- 本次不增加数据分析面板

“完成标准”和“不做什么”同样重要。前者帮助你判断什么时候可以结束，后者防止任务在执行过程中不断膨胀。

3. 开发中：限制同时进行的任务数量

“开发中”是最需要控制的列。一人公司最常见的问题不是没有任务，而是同时打开了太多任务，最后每件事都只完成了一半。

建议同时进行的任务控制在一到三个：

• 一个主要任务：今天最重要的推进项；
• 一个辅助任务：等待反馈时可以处理；
• 一个低阻力任务：用于填补碎片时间。

当“开发中”已经达到上限，就不要继续从“待处理”拉新卡。先完成、暂停或退回其中一张卡片。

如果使用 Trello，可以直接通过列表卡片数量观察工作负载；如果使用 Linear，则可以通过当前周期中的 issue 和状态判断是否超载。工具不同，但原则相同：减少开始数量，增加完成数量。

4. 验证中：确认交付结果，而不是确认自己很忙

开发完成不等于任务完成。进入“验证中”后，需要检查结果是否满足最初的完成标准。

验证方式可以根据工作类型调整：

• 软件功能：自己操作一遍，检查关键路径和异常情况；
• 内容文章：检查事实、结构、链接和阅读体验；
• 客户交付：让客户确认交付物是否满足约定；
• 自动化流程：用真实样例跑通一次；
• 新产品功能：邀请少量目标用户试用并记录反馈。

验证卡片最好保留结果，而不是只写“已测试”。例如：

验证结果：新用户可以完成首次操作，移动端按钮存在遮挡问题。
下一步：修复移动端按钮后重新验证。

如果发现问题，把卡片退回“待处理”或单独建立缺陷卡，不要为了保持看板整齐而直接移动到“已发布”。

5. 已发布：记录交付与后续观察

“已发布”不是任务的终点，而是可追踪的交付记录。卡片至少保留：

• 发布日期；
• 发布内容；
• 面向的用户或客户；
• 相关链接或交付位置；
• 发布后的反馈；
• 是否需要后续迭代。

对于产品功能，可以加上版本或周期；对于内容，可以记录发布渠道；对于客户项目，可以保留验收结果。这样路线图不只是“待办事项列表”，还会逐渐变成你的经营记录。

在 Trello 中落地这套流程

看板结构

可以建立一张名为“产品迭代”或“业务交付”的看板，并创建以下列表：

想法池
待处理
开发中
验证中
已发布
阻塞

“阻塞”不一定是必需列，但当你经常等待客户回复、设计素材、接口权限或外部确认时，单独放置比把卡片留在“开发中”更准确。

卡片字段

每张卡片建议保持以下结构：

字段	用途
卡片标题	用一句话说明可交付结果
标签	区分功能、缺陷、内容、客户或运营
优先级	帮助决定下一张卡片
截止日期	只给有真实期限的任务设置
清单	拆分执行步骤
完成标准	判断是否可以移入验证中
相关链接	放文档、代码、素材或交付地址
反馈记录	保存验证结果和下一步

不要给每张卡片设置截止日期。没有真实期限的日期会快速失去可信度，最后所有任务都变成“逾期但不处理”。

在 Linear 中落地这套流程

建立一个产品项目

可以先创建一个产品项目，再用状态和 issue 管理具体工作。基础状态可以设为：

Backlog
Todo
In Progress
In Review
Done

如果你的流程更简单，也可以把它映射成：

想法池 → 待处理 → 开发中 → 验证中 → 已发布

对于研发驱动的产品，建议把“缺陷”和“功能”分开标记，把高优先级问题与普通改进区分开。这样路线图不会被零散反馈完全打乱。

用周期控制路线图

不要把路线图写成一份遥远的愿望清单。对一人公司来说，更实用的方式是分成三个范围：

现在：本周或当前周期必须完成
接下来：已经确认，等待进入当前周期
以后：有价值，但尚未承诺

每次规划时，只从“接下来”中挑选少量任务进入当前周期。路线图的作用不是承诺你未来一定完成所有功能，而是帮助你判断当前应该把时间投入在哪里。

为 issue 设置清晰边界

一个好的 issue 应该可以在较短周期内完成。下面两种写法对比明显：

不推荐：完善支付系统
推荐：处理支付失败后的错误提示，并补充一次失败场景测试

如果一个任务同时包含需求分析、设计、开发、测试和发布，通常应该拆开。拆分后，你才能知道项目究竟卡在开发、等待确认，还是验证环节。

一人公司每周运行一次的项目管理节奏

周一：从想法池选择本周目标

先查看所有未完成卡片，回答：

1. 本周哪项工作最可能带来真实业务价值？
2. 哪项工作有明确截止时间或客户承诺？
3. 哪项工作是其他任务的前置条件？
4. 哪些任务应该暂时删除或延后？

最后只选择少量重点任务进入“待处理”。如果一周内同时推进开发、内容和客户项目，最好为每类工作设置主任务，而不是把所有事情混成一条长清单。

每天：只移动真正发生变化的卡片

每天开始时，从“开发中”选择一个最重要的下一步；每天结束时，更新卡片状态和阻塞原因。

可以使用下面的简短记录：

今天完成：
当前阻塞：
下一步动作：
预计何时继续：

这比写长篇工作日志更容易坚持，也足够帮助你第二天快速恢复上下文。

周五：检查流动，而不是检查卡片数量

复盘时不要只看“完成了多少张卡”，还要看：

• 哪些卡片在“开发中”停留太久？
• 哪些任务反复退回验证？
• 哪些想法已经没有价值？
• 哪些工作其实应该拆得更小？
• 本周发布的内容或功能带来了什么反馈？
• 下周路线图是否仍然符合业务重点？

如果一张卡片连续多个周期没有移动，通常只有三种处理方式：拆小、暂停或删除。

不要把 Trello 和 Linear 同时当作两个主系统

如果你同时使用两款工具，最容易出现的问题是同一任务被复制两遍，状态却没有同步。除非你已经有明确的自动化流程，否则建议遵循“一主一辅”：

• Trello 作为业务总看板，Linear 只管理软件研发；
• Linear 作为产品研发主系统，Trello 管理内容和客户交付；
• 早期阶段只选择其中一个，等任务规模确实超过工具边界后再拆分。

跨工具时，定义唯一来源：

研发状态：以 Linear 为准
内容与客户交付：以 Trello 为准
产品方向：以路线图文档为准

卡片之间只保留必要的关联链接，不要在两个系统里维护两套独立描述。否则你会把时间花在同步状态，而不是推进项目。

最终建议：先用最小流程运行两周

如果你还没有稳定的项目管理习惯，可以先不要配置复杂字段和自动化。建立五列看板，给每张卡片补充完成标准，并限制“开发中”不超过三张，连续运行两周。

• 工作以内容、客户和多种经营任务为主：先选 Trello；
• 工作以软件功能、缺陷和版本迭代为主：先选 Linear；
• 仍然无法判断：选择更容易每天打开并更新的那一个。

项目管理的核心不是工具名称，而是让路线图从抽象计划变成可观察的卡片流：想法被筛选，任务被执行，结果被验证，发布后继续产生反馈。只要每周都能完成这条闭环，你的一人公司就拥有了一套足够轻量、也足够可靠的迭代系统。