做内部研发平台时总被一个问题卡住：一个 Project 到底何时结束？一次性交付有明确终点，产品与长期团队却持续产生工作。把两种生命周期混进同一个容器，正是企业研发平台信息组织失序的根源。

做内部项目管理平台时，我曾经反复遇到一个看似简单的问题：一个“项目”究竟应该在什么时候结束？

如果它指一次支付系统改造，生产发布、验收完成以后就应该归档；如果它指负责支付产品的团队，需求、缺陷、迭代和版本会持续产生，几乎没有真正的结束日期；如果它指一个基础技术平台，团队成员会变化，专项会一轮轮启动，但服务本身可能存在很多年。

现实中的这三类对象，进入软件后经常都被装进一个叫 Project 的容器。

最初问题并不明显。团队只有十几个人，一个“支付项目”足以放下需求、任务和缺陷。几年后，管理员开始纠结：项目已经结束，为什么不能关闭？关闭后旧缺陷到哪里查？下一代版本是继续放在旧项目里，还是复制一个“支付项目二期”？成员、字段、流程、看板和自动化要不要一起复制？

很多团队最后选择不关闭。于是项目的开始时间、结束时间和完成状态逐渐失去意义。另一些团队按年度或大版本复制项目，同一产品的事实被切成几段，跨年需求、遗留缺陷和长期指标都要重新拼接。

这不是管理员不会用软件，而是产品模型把两种生命周期不同的事物混在了一起：

• 一次性交付有明确目标和结束条件；
• 产品、服务、业务能力和长期团队会持续产生工作。

所以，第九篇要解决的并不是“项目菜单应不应该改名为空间”，而是企业研发平台最基础的信息组织问题：一条事实长期属于哪里，一次临时交付怎样引用它，不同角色又怎样从自己的入口读取同一批事实。

全文会围绕一个判断展开：

一条工作项应有一个稳定的长期归属，可以进入多个交付上下文；不同角色再通过视图读取和操作同一批事实。

读完这篇，你可以回去判断两件事：自己平台里那些常年不关闭的“项目”，哪些其实早就是空间；以及哪些新概念值得做成独立实体，而不是只是塞进菜单。

01 同一个“项目”，实际混进了三种产品语义

讨论 Project 和 Space 之前，必须先把“项目”这个词拆开。否则产品经理、研发负责人和项目经理看似在讨论同一个概念，实际说的是三件不同的事。

第一种，是项目管理学意义上的项目。它是为了创造独特结果而开展的临时性工作，有目标、范围、时间、资源和结束条件。无论采用预测型还是敏捷型方法，只要目标达成、终止或移交，这个项目就应该结束。它是管理对象，不是软件菜单。

第二种，是项目管理软件里的 Project 容器。它通常负责工作项编号、成员入口、字段方案、工作流、看板、版本、报表和权限。早期研发工具围绕一次项目建立数据，自然把 Project 设计成顶层容器。但当团队把同一容器连续使用几年以后，它早已不再只是临时项目，而是产品、服务或团队的长期工作区。

第三种，是企业日常语言里的“项目”。“支付项目”“客户端项目”“数据平台项目”有时指产品，有时指部门，有时指系统，有时才指真正的一次性交付。用户不会先完成概念建模再给软件提需求，他们只会沿用组织内部最熟悉的称呼。

三种语义混用，会把很多产品问题伪装成配置问题。

例如，用户说“项目成员应该长期保留”，他可能在描述产品团队；用户说“项目完成后要冻结范围”，他描述的却是一次性交付；用户说“两个项目要合并”，也可能只是组织把两个业务工作区整合到一起。若平台只有一个 Project 实体，只能让同一对象同时承担长期归属、临时计划、成员管理和配置作用域。

短期看，这种设计非常省事：创建一个容器，其他资源全部挂在下面。长期看，它会出现四类冲突。

当一个对象被迫同时满足两列要求，产品体验就会变得别扭。项目不敢关闭、历史反复迁移、配置不断复制，本质上都在提醒设计者：容器的生命周期选错了。

02 四款产品，选择了四条不同的组织路线

市场上的产品没有统一答案。Jira、飞书项目、ONES 和 TAPD 的差异，不只是菜单名字不同，而是长期事实放在哪一层、临时计划怎样表达、跨容器聚合由谁承担。

Jira 的变化尤其容易被误读。Jira 把原来的 Project 改称 Space，官方明确说明这首先是术语与图标更新，既有键值、数据、工作流和配置不会因此自动重构。它不能证明底层模型已经全部改变。但这个命名变化仍然重要：当一个容器既服务产品、团队、服务台，又服务传统项目时，Space 比 Project 更接近用户的真实使用方式。

与此同时，Atlassian 体系又提供独立的 Projects，用来表达有目标、时间范围、状态和跨团队协作的工作。这里值得学习的不是品牌命名，而是职责拆分：长期工作区和临时交付不必争夺同一个顶层实体。

飞书项目更直接地采用空间模型。工作项、视图和空间配置在一个长期协作区域内运行，需要跨多个空间观察时，再由全景视图承接。TAPD 当前也把基础协作区域称为“项目空间”，需求、迭代、缺陷和空间设置都在其中运行；与此同时，它仍保留项目集、父子项目和跨项目视图，用于组织更大的交付范围。ONES 则继续以项目作为主要工作容器，再通过项目集和计划能力向上聚合。

这四条路线都能工作。产品经理不能因为名字叫“空间”，就判断模型更先进；也不能因为仍叫“项目”，就判断它只适合一次性交付。真正应该追问的是：

• 容器是否允许长期存在；
• 工作项的主身份由谁提供；
• 临时交付是否需要复制工作项；
• 跨容器计划能否读取同一事实；
• 容器结束后，历史关系是否仍然连续。

名称只是一层产品语言。资源的归属关系、运行规则和生命周期，才是模型本身。

03 关键分离：长期归属与交付上下文不是同一种关系

从第一性原理看，研发平台必须回答两个不同问题。

第一个问题是：“这条需求长期属于谁？”答案用于确定稳定编号、默认类型、字段语义、流程、搜索入口和历史治理。它需要一个主要且稳定的归属。

第二个问题是：“这条需求这一次为了什么而交付？”答案可能是某个专项、目标、迭代、版本、里程碑、发布计划，甚至是一项合同承诺。它会随计划变化，也可能同时存在多个观察角度。

如果用同一个外键同时回答两个问题，交付计划一变化，工作项身份也会被迫变化。把需求从“收银台升级项目”移到“年度降本项目”，可能连编号、工作流、权限和历史入口都跟着改变。为了避免移动，团队又会复制一条需求，随后产生两个负责人、两个状态和两份评论。

这里值得记住一条更底层的原理：低频变化的事实，不应该挂在高频变化的对象上。长期归属几乎不变，交付上下文频繁变化，用同一个外键把两者粘在一起，身份就会跟着计划漂移。这条原理也能解释本系列的两个相关结论：编号必须属于空间，因为编号不能随计划变化；配置必须长期治理，因为配置是低频变化的规则资产，不能由一次临时项目带走。

更稳妥的模型是让工作项只有一个长期主归属，再通过关系进入交付上下文。

以“支持银行卡分期”为例，它长期属于支付空间，编号始终是支付空间下的稳定身份。当前它可以同时被纳入：

• “收银台升级”专项，用于说明临时目标和责任；
• 第二十三次迭代，用于表达团队本周期的投入承诺；
• 三点二版本，用于表达计划共同交付的产品范围；
• 七月灰度发布，用于表达成果实际进入的环境和用户范围；
• “提升支付成功率”目标，用于说明为什么值得做。

这些关系并不必然都是多选。一个工作项在同一时间只能进入一个当前迭代，还是允许被多个团队迭代引用；只能属于一个目标，还是允许贡献多个目标——都需要按业务语义决定。关键不在于“一切都做成多对多”，而在于不要让临时计划重新定义工作项的长期身份。

项目也可以保留，但应被定义为交付对象，而不是第二个同职责容器。当一次专项确实需要独立目标、负责人、计划日期、预算、风险、合同、外部成员和归档结论时，把它建模成正式项目是有价值的。它可以聚合多个空间中的工作项，也可以拥有自己的里程碑和状态。

但项目不应再复制一套工作项类型、字段、流程、成员和视图，然后要求各空间把事实搬进去。否则 Space 和 Project 只是两个都能装一切的盒子，用户仍要回答“我到底在哪边创建需求”。

所以，“空间与项目能否并存”的准确答案是：

可以同时存在于产品模型中，但不能作为两个职责相同、层层嵌套的资源容器。

空间回答长期归属，项目回答临时交付。项目完成后可以冻结计划和结论，工作项仍留在原空间，后续缺陷、复盘记录和下一版本继续沿着同一身份演进。

这个分离还有一个直接收益：一次跨产品项目不再要求先调整组织结构。比如“统一会员与支付权益”需要会员、支付和客户端三个团队协作，项目仪表盘可以组合三个空间的工作项；各团队仍在自己的空间内使用熟悉的类型和流程。项目管理者看整体范围与风险，团队负责人维护各自事实，双方不必争夺数据所有权。

04 空间不是组织、团队、项目和权限边界的别名

定义长期空间以后，最容易犯的错误是把企业中的所有结构都塞进一棵树：集团下面是部门，部门下面是团队，团队下面是空间，空间下面是项目，项目下面是工作项。

这张树看起来整齐，却通常不符合真实协作。

组织回答管理与治理关系；团队回答谁持续承担责任并投入产能；空间回答一批业务事实长期属于哪里；项目回答一次临时目标如何组织；权限回答某个主体在特定条件下能执行什么动作。它们可能相关，但不是彼此的同义词。

判断一个新概念是否值得成为独立实体，可以连问四个问题：它是否有独立生命周期，是否有独立责任主体，是否以不同的频率变化，是否需要独立的权限与入口。四个答案都是肯定的，它就应该拥有自己的对象；全部否定，它多半只是一个字段、一类关系或一个视图。

一个支付空间可能由产品、服务端、客户端、测试和数据多个团队共同维护；一个基础平台团队也可能服务十几个空间；一个成员可以属于一个正式团队，同时参与两个专项；一个项目可以组合三个空间中的工作项。把这些关系强行压成父子层级，组织一调整，数据归属就要跟着搬家。

更可靠的设计是保留几类明确关系：

• 工作项必须有一个主空间，决定稳定身份与默认运行上下文；
• 团队可以主责一个或多个空间，也可以作为服务团队参与其他空间；
• 成员通过团队、空间角色或临时协作关系参与工作；
• 交付项目可以引用一个或多个空间中的工作项；
• 组织为这些实体提供治理和发现入口，但不自动等同于数据归属。

权限边界也必须单独处理。同一空间中的两条工作项，可能因为保密级别、客户数据或外部协作拥有不同可见范围；一个跨空间项目仪表盘能查询三类工作，也不代表查看者自动获得所有明细权限。本篇只定义事实放在哪里、查询从哪里发起。谁可以看见和操作，要由第十一篇的授权策略判断。

无主工作项也要有兜底。从外部导入的孤儿数据、跨团队协作草稿，可以暂时进入平台公共空间，或允许暂时缺少主空间；但编号、搜索、报表和自动化等关键能力必须受限，直到它获得明确的主归属。否则“稳定归属”会从一个原则漏成一片例外。

空间应该切多大

空间过大，几十个团队共用一个入口，类型、字段、状态和公共视图会不断膨胀；空间过小，每个小组、每次活动、每个版本都新建空间，跨空间搜索、关系和报表又会成为日常负担。

判断粒度时，不要先看组织图，而要看四种稳定性。它们也可以归纳为两个底层问题：事实是否长期需要一起查询，规则是否长期需要一起变化。

1. 业务语言是否稳定一致：同名“需求”在两边是否表达相近事实，完成标准是否相近；
2. 事实是否需要长期一起查询：需求、缺陷和版本是否属于同一产品历史；
3. 规则是否经常共同变化：工作项类型、字段、状态和自动化；
4. 是否存在明确且长期的治理责任人。

如果四项大多一致，放在同一空间能降低管理成本；如果对象语义、数据隔离、流程责任和治理主体长期不同，就应拆开。组织结构可以作为线索，却不应成为唯一依据，因为部门可能每年调整，而产品、服务和业务能力往往更稳定。

空间的“长期”也不是永远不变。名称可以因品牌或组织调整而变化，稳定标识和内部身份则应尽量保留。若把展示名称直接作为外部集成、工作项编号和报表关联的唯一身份，一次改名就会破坏链接、同步规则和历史查询。

05 信息架构不是菜单树，而是对象、入口与作用域的组合

很多产品在设计企业信息架构时，先画首页和左侧导航：首页下面放工作台、空间、项目、报表和配置中心。站点地图画完了，看起来层级完整，却没有回答一条需求究竟属于谁。

真正的信息架构至少包含三层。

第一层是对象层。空间、工作项、团队、目标、项目、迭代、版本、发布和视图分别是什么对象，哪些有稳定身份，哪些只是关系或查询结果。

第二层是作用域层。一条工作项在哪个空间内被编号，哪套默认规则对它生效，一次查询覆盖哪些空间。这一层只定义边界，不直接等于权限；它与后文空间视图的“数据范围”是同一件事的两种说法。

第三层才是入口层。个人工作台、空间首页、项目仪表盘、全局搜索和组织仪表盘，帮助不同角色进入相同对象网络。

入口可以很多，事实源只能有一份。用户在个人工作台修改负责人，在空间列表批量更新优先级，在看板拖动状态，在项目计划里调整日期，最终都应回到同一个工作项和同一套命令规则。否则每个入口都会长成一套局部系统。

这也是为什么“空间首页”不应该只是多放几个菜单。好的空间首页要回答：这里长期负责什么，当前有哪些目标和交付，哪些工作正在进行，哪些依赖和风险需要关注，公共工作方式从哪里进入。它是业务上下文入口，而不是文件夹封面。

06 视图不是数据副本，而是面向决策的投影

确定长期归属之后，才轮到“不同角色怎样看”。

研发关心今天先处理什么；产品经理关心哪些需求应该进入下一轮；项目经理关心范围、日期和依赖是否偏离；负责人关心目标、版本和跨团队风险。让所有人使用同一张表并不专业，为每种角色复制一套数据更危险。

正确做法是让视图成为同一对象网络的查询与操作入口。

一个可运行的视图至少要回答四个问题。

1. 选择什么。 空间视图查询所属空间的数据；需要组合多个空间时，把它做成仪表盘，而不是无限扩展视图的数据范围。两者都要明确包含哪些工作项类型、使用哪些筛选条件，是否沿层级或关联关系继续展开。
2. 怎样组织。 按什么字段排序、分组和汇总，显示哪些列或卡片属性，使用列表、看板、树、甘特图、日历、路线图还是图表。
3. 允许做什么。 只读分析，还是可以拖动、编辑、批量操作、调整日期和创建子项。任何写操作都必须执行工作项本身的校验、状态机、权限和自动化，不能因为来自某个视图就绕过规则。
4. 由谁维护。 这是个人临时视图、团队公共视图，还是组织治理口径。所有者决定谁能修改视图定义，而不是谁能看见查询结果中的每条数据。

可以把视图理解为一张可保存的决策界面，而不是一张复制出来的新表。列表适合高密度扫描和批量处理；看板适合观察状态分布、在制品和流动；树形视图适合理解分解与汇总；甘特图适合分析时间、层级与依赖；日历适合发现某天发生的事件；路线图适合观察目标、版本和跨团队节奏；报表把对象事实聚合为指标。

这些视图可以拥有完全不同的页面，但不能拥有各自独立的业务真相。工作项在看板上从“开发中”拖到“待测试”，应执行第六篇定义的同一个流转步骤；在甘特图里调整计划日期，应写回同一字段并触发依赖校验；在树上新增子项，应建立第五篇定义的层级关系。

技术上，平台当然可以为大规模路线图和报表建立搜索索引、缓存或物化结果。所谓“同一事实源”并不是要求所有页面每次都直接扫描主库，而是要求这些结果都能从权威对象重建，且不能在缓存或报表里独立修改出另一种状态。

视图配置不能重新定义业务规则

视图可以决定显示哪些字段、卡片上露出什么信息、怎样分组和着色；它不应该重新定义字段类型、状态迁移和关系语义。

如果同一条缺陷在列表里可以直接关闭，在看板里却必须先填写验证结果；如果甘特图允许把子项拖到父项开始之前，而详情页又不允许，那么用户看到的不是灵活性，而是相互冲突的产品规则。

视图只负责让用户更高效地发起操作，真正的合法性由工作项元模型、状态机、关系规则和权限引擎共同判断。详情页、看板、甘特图、批量操作、接口和未来的 Agent，都应该调用同一套业务命令。

07 空间视图与跨空间仪表盘，不是同一种资源

把视图按“公共、个人、跨空间”分类，其实混合了两个不同维度：由谁维护，以及查询哪些数据。

空间视图默认查询所属空间。 列表、看板、树、甘特图挂在空间下，由空间或个人维护，数据范围是本空间，也可以显式引入依赖空间中的阻塞项。它服务空间内的日常操作，写操作回到源工作项。

跨多个空间的组合不是视图，而是仪表盘。 产品经理要跟进散落在支付、会员和客户端三个空间的需求；组织要检查试点空间的流程合规；跨团队交付要把三个空间的工作项放进同一张甘特图——这些都是把多个空间的数据组合到一个可保存的入口。仪表盘由个人或组织维护，默认用于展示与发现，允许的写操作同样回到源工作项，不会产生第二份状态。

不能因为某张页面上显示了几个空间的数据，就叫它视图；也不能因为仪表盘数据跨空间，就自动把它变成组织公共资产。

这里还有第三个常被混淆的概念：数据权限。视图和仪表盘保存的都是查询定义，数据范围定义它试图查询什么，权限决定当前用户实际能得到什么。用户拿到一个跨空间仪表盘链接，并不因此获得所有工作项的访问权；同样，用户有权查看一条工作项，也不代表他可以修改团队公共视图。

因此，产品至少要分别保存：所有者、共享范围、查询范围和运行时权限结果。把它们折叠成一个“可见性”开关，后续一定会同时伤害协作和安全。

公共视图和仪表盘还要有自己的生命周期。个人离职后，他创建但已经成为团队日常入口的视图是否消失？公共仪表盘被修改时，其他人是否能看见变更？组织口径被替换后，旧报表是否还能复现？这些问题说明它们都是需要标识、所有者、版本和审计的产品资源，而不是一串藏在浏览器地址里的筛选参数。

08 个人工作台：把多个空间中的责任汇成一个行动入口

空间是以业务对象为中心的入口，工作台则是以人为中心的跨空间入口。前者回答“这条工作长期属于哪里”，后者回答“无论工作在哪个空间，今天有哪些事情需要我处理”。两者解决的问题不同，不能让用户为了找到自己的工作，先记住每条工作项属于哪个空间。

假设一名产品经理同时参与支付、会员和客户端三个空间。在支付空间里，他是“支持银行卡分期”等几条需求的负责人；在会员空间里，有需求等待他评审；在客户端空间里，他对一个版本结果负责，但当前开发动作在其他人手中。如果仍按空间逐个进入，他每天要打开三个空间、切换多个视图，再判断哪些事项真的轮到自己。

工作台要做的不是把三个空间的数据复制到一张“我的任务表”，而是基于统一用户身份，查询当前用户与各空间工作项之间的责任关系，再把结果组织成行动队列。

这张图里最重要的不是箭头，而是中间的责任关系。工作项仍由空间提供稳定身份，责任关系只记录“哪个用户以什么角色参与哪条工作”。工作台根据当前用户、可访问空间和有效责任关系生成查询结果；用户发起操作时，再调用源工作项的业务命令。这样才能同时保证个人入口统一、空间事实不被复制。

最基础的查询当然是“负责人等于当前用户”，但企业研发平台很快会遇到更多责任语义：工作项负责人、当前流程节点处理人、评审人、审批人、结果责任人、关注人，分别代表不同动作。如果全部压进一个“负责人”字段，用户会看到一长串与自己有关、却不知道为什么出现的工作项。

更清楚的设计，是先把责任关系映射为个人下一步需要完成的判断：

模型落到页面后，工作台也不应该只给用户一张没有上下文的任务列表。下面是一版概念原型：顶部先按待执行、待判断、待跟进和风险分类，筛选器再收窄空间、类型与责任角色；每条卡片同时解释来源空间、工作项身份、我为什么看到它，以及下一步应该做什么。

这张原型刻意没有复制完整详情页。工作台只保留做判断所需的信息和动作入口，点击以后回到源工作项继续处理。如果为了让用户“在一个页面完成所有事”，又把各空间的字段、流程、评论和关系全部重做一遍，工作台很快就会变成第二套工作项系统。

每条结果至少要显示来源空间、工作项类型、稳定编号、标题、我与它的责任关系、当前状态和时间风险。用户不需要先进入空间才能理解任务，但点击或操作以后，仍然回到原工作项。工作台不能生成第二份状态，也不能因为跨空间聚合就绕开源空间的字段校验、状态机和权限规则。

这里还有三个容易被忽略的不变量。

1. 按用户唯一身份聚合，而不是按姓名匹配。用户改名、同名或跨组织协作，都不能造成责任错配；
2. 结果是“查询范围与数据权限的交集”。用户参与某个空间，不代表他能看到其中所有保密工作项；权限被收回后，对应结果也应及时消失；
3. 同一工作项可能同时要求用户执行、评审和跟进。界面需要确定主队列并展示其他责任标签，不能复制成三条待办造成重复计数。

产品早期不需要一次做全。最小版本可以先统一用户身份、标准负责人字段、跨空间索引和权限过滤，解决“我负责的工作散落在多个空间”这一高频问题。只有当流程评审、结果责任和风险订阅成为真实需求时，再扩展责任类型和行动队列。

工作台的价值不是做出一个更复杂的首页，而是逐步消除用户寻找工作的成本。

管理者入口遵循同样的原则，但查询起点不同。管理者通常从目标偏差、版本风险、团队容量、跨空间依赖和异常趋势进入，再下钻到具体工作项。执行者从动作进入，管理者从偏差进入，底层读取的仍是同一批事实。

工作台与仪表盘容易混淆，但来源不同：工作台是系统按当前用户的责任关系动态生成的行动队列，仪表盘是人保存下来的跨空间组合。一个回答“今天轮到我做什么”，另一个回答“这段时间跨空间发生了什么”。

全局搜索、收藏和最近访问则解决“我知道自己要找什么”的问题。搜索负责定位，收藏保存长期入口，最近访问提供短期回溯；工作台处理的是系统已经知道责任落在谁身上，应该主动把什么送到他面前。四种入口互相补充，不能彼此替代。

09 从单空间走向企业平台，真正困难的是语义对齐

跨空间查询在技术上像把多张表合并，产品难点却不在查询语句。

支付空间的优先级是紧急、高、中、低，会员空间使用零到三；两个空间都有“已完成”，一个表示开发提交，另一个表示生产验证；两个字段都叫“业务价值”，一个是数字评分，另一个是文本说明。同一个“支持银行卡分期”，在支付空间的“已完成”意味着生产验证通过，在会员空间的同名状态可能只是开发提交——跨空间仪表盘看到两个“已完成”，必须先问它们是不是同一件事。名称一样不代表含义一样，名称不同也不代表不能比较。

要让跨空间仪表盘可信，平台至少需要四层处理。

第一层是平台基础字段。稳定编号、标题、类型、空间、创建时间、更新时间等最低公共属性，可以直接进入通用查询。但即使是“负责人”，也要先确认是当前执行人、结果负责人还是流程节点处理人。

第二层是字段身份。全局字段与空间字段不能只按显示名称合并。只有引用同一个元字段，或经过管理员显式建立映射，平台才应把它们当作同一指标。否则两个都叫“业务价值”的字段应分别展示。一句话：比较必须基于身份，不能基于名称——同名字段不等于同一事实。

第三层是语义归一。各空间的具体状态可以映射为待处理、进行中、已完成等状态类别，不同优先级也可以映射为统一等级。但汇总只能表达归一后的粗粒度结论，用户下钻时仍要看到原始值，不能用统一标签掩盖流程差异。

第四层是质量说明。报表应明确哪些空间未配置字段、哪些记录缺少值、哪些枚举无法映射、哪些结果因权限被隐藏。不要把缺失自动当成零，也不要为了得到一条漂亮曲线，默默排除无法比较的数据。

这里必须接受一个产品事实：覆盖范围越大，语义往往越粗；语义越精确，可比较的空间可能越少。企业级平台的专业性，不是永远给出一个全局数字，而是让使用者知道这个数字基于什么口径、覆盖什么范围、失去了哪些细节。

配置统一能降低聚合成本，但它属于下一篇的配置治理问题。权限过滤决定某个用户能看到哪些结果，属于第十一篇。第九篇只负责把三件事分开：查询想覆盖什么、数据语义是否可比、当前结果如何诚实呈现。

10 从 Project 迁移到 Space：四步过渡

如果现有平台已经运行多年，直接新增一层空间、再把原项目全部挂进去，往往会让模型更复杂。原来的 Project 同时承担数据归属、配置、成员和交付计划，新 Space 又承担一遍相同职责，用户会同时看到两套入口，管理员也不知道规则应该配在哪一层。

迁移的第一步不是建表，而是识别现有 Project 的真实用途。可以用几个问题分类：它是否连续多年产生工作？是否围绕稳定产品或服务？成员和配置是否长期存在？所谓结束日期是否长期为空？一个运行五年、需求缺陷版本持续产生、结束日期常年为空的“支付项目”，所有答案都是“是”——它实际已经是空间，只是名字仍叫项目；而一个有合同、节点和验收结论的“收银台改造”，才更像真正的一次性项目。判断完毕，才谈得上迁移。

第二步是拆出临时属性。项目目标、起止日期、预算、里程碑和交付状态不应继续决定工作项身份，可以迁移到独立交付对象，或者在规模较小时用目标、版本和保存视图承接。原容器则保留稳定编号、对象历史和主要业务归属。

第三步是建立兼容期。旧链接、工作项键值、接口参数和自动化不能因为产品术语变化立即失效。界面可以先展示新名称，接口继续兼容旧标识；跨容器仪表盘先读取原有数据，再逐步引导新增工作进入长期空间。迁移日志要能回答每个对象原来在哪里、现在由谁承载以及哪些规则发生过转换。

最后才是清理重复入口。当空间已经能够承担主归属，交付项目已经成为关系对象，旧 Project 菜单才可以退出。模型演进的成功标准不是“所有页面都出现了 Space”，而是团队不再为了新年度、新版本或新专项复制同一产品的工作事实。

11 长期空间也会结束：关闭条件与退出过程

长期不等于永久。产品下线、业务合并、服务退役以后，空间也需要停用和归档，只是触发条件不再是某次项目验收完成。

一个可控的退出过程至少包括：停止新建工作项；处理仍在运行的迭代、版本、流程和自动化；确认跨空间依赖的替代目标；将公共视图和知识入口转为只读；保留稳定编号、关系和历史搜索；最后记录归档原因、责任人和时间。

如果业务合并到另一个空间，还要在“迁移历史”与“保留原身份”之间做选择。大规模移动会改变主归属，并可能影响编号、字段、状态、关系、外部链接、报表口径和自动化。除非确有数据隔离、合规或运营需要，保留旧对象身份、把旧空间设为只读，再在新空间建立承接关系，通常比批量重写历史更稳妥。

空间退出机制反过来也能检验模型是否合理：一次项目完成时，长期业务仍在运行，空间不应关闭；只有承载的业务、产品或服务本身停止，或者已经完成明确迁移，空间才进入归档。

12 从零设计这一层，先做清楚四个决定

第一，什么对象提供长期主身份。 如果工作会跨年度、跨版本持续发生，就让产品、服务或业务空间提供稳定编号、默认上下文和历史入口，不要让一次性交付决定事实是否继续存在。

第二，临时交付怎样进入模型。 简单专项可以用目标、里程碑、版本、标签或保存视图表达；只有需要独立目标、负责人、日期、风险和归档结论时，才升级为正式项目对象。项目可以聚合工作项，但不复制另一套事实。

第三，角色怎样读取同一批事实。 列表、看板、树、甘特图、路线图、报表和工作台应共享对象、关系和业务命令。入口可以不同，状态、日期、负责人和关系不能各自维护。

第四，跨空间差异怎样被承认。 平台需要公共字段、字段身份、显式映射和质量说明。无法比较时应该降级或提示，而不是用同名字段和统一颜色制造虚假的一致性。

回到开头那个问题：一个项目究竟什么时候结束？

如果它是一次性交付，达到结束条件就应该关闭；如果它实际承载的是长期产品、服务或团队工作，就不该继续用临时项目的生命周期要求它。产品经理真正要修复的，不是“项目结束日期”这个字段，而是长期归属与临时交付被混成了一个容器。

当这层模型清楚以后，企业研发平台的信息架构会简单很多：工作项在稳定空间中生长，项目、目标、迭代、版本和发布从不同角度组织交付，个人与管理者通过视图进入同一事实网络。项目可以结束，事实不会因此失去归属；组织可以调整，历史不会因此被迫搬家；页面可以很多，业务真相仍然只有一份。

下一篇，我们继续追问一个更难的问题：当十个空间希望复用同一种需求类型，又允许其中两个空间保留自己的流程时，共享的究竟是模板、引用还是副本？上级配置变化后，下级应该立即继承、选择同步，还是继续使用旧版本？

这将进入企业级项目管理平台最容易积累技术债的一层：配置中心的作用域、复用与变更治理。