任务拆解写到“能开工、能验收”的程度，关键是把边界落成一张可核对的边界卡：输入写来源、形态和可用标准，输出写交付物、格式和存放位置，前置依赖写依赖对象、就绪标志和等待处理，不包含事项写清容易混入的相邻工作，验收口径写验收人、检查项和通过标准。本文给出字段填法、四步流程、角色分工、完整示例和完成检查清单，适用于单个可执行工作项的边界描述。
要点总览（TL;DR）
- 把任务边界写成一张边界卡：输入写来源、形态和可用标准，输出写交付物、格式和存放位置，前置依赖写依赖对象、就绪标志和等待处理，不包含事项写清相邻工作及归属，验收口径写验收人、检查项和通过标准。
- 填写顺序从交付物倒推：先定输出，再追溯输入与前置依赖，然后划定不包含事项，最后约定验收口径，四步各有完成标志，答不上四个问题就回到对应步骤补充。
- 边界卡由任务负责人起草，拆解主持人组织评审，依赖方确认依赖事项，验收人在执行前确认验收口径；输出增减、依赖时间变化或验收标准调整时，由负责人更新并通知相关方。
- 提交前按检查清单核对，输出无交付物、依赖无就绪标志、验收人未确认属于阻断项，任务不应进入执行；边界卡确认状态要与任务状态保持一致。
- 边界卡需要随任务一起承载和流转，可写进工作项的描述或字段中，让输入、输出、依赖和验收口径与任务状态放在同一处。
一张边界卡：五项字段怎么填
边界卡的作用，是让接手任务的人在开工前就能判断“我手上有没有东西可做、做完交给谁、什么算做完”。五项字段各管一件事，填写时都落到具体名词和可观察状态，避免“相关资料”“尽快完成”这类无法核对的表述。
| 字段 | 填写要求 | 示例句式 |
|---|---|---|
| 输入 | 写清材料或数据的名称、来源方、形态（文档、接口文档、数据表、设计稿等）、版本或时间范围，以及“可用”的判断标准 | 输入为《订单服务接口说明 v1.2》，由后端组在需求评审后提供，含请求参数、返回码和错误示例；字段缺失超过两处即视为不可用 |
| 输出 | 写清交付物名称、格式、粒度、存放位置和命名规则，一个任务可以有多项输出，但要逐项列出 | 输出为《联调记录》一份，Markdown 格式，存放在项目文档库“联调”目录，按“日期-模块”命名；附问题清单一张 |
| 前置依赖 | 写清依赖对象（人或团队）、依赖事项、就绪标志，以及依赖未就绪时本任务的处理方式 | 依赖后端组完成测试环境部署，就绪标志为环境地址可访问且冒烟用例通过；未就绪时先完成用例编写，不进入实际调用 |
| 不包含事项 | 写清容易混入本任务的相邻工作，并注明归属任务或归属人 | 不包含前端页面改造与性能压测，分别归入“前端适配”任务和“性能专项”任务 |
| 验收口径 | 写清验收人、检查项和通过标准，检查项与输出逐条对应 | 验收人为测试负责人；检查项：联调记录覆盖全部约定接口、问题清单每条有责任人和状态；通过标准：接口调用成功率达标且遗留问题均有结论 |
五项字段之间存在对应关系，填写时要互相对齐。输出与验收口径一一对应：每项输出至少对应一个检查项和一个通过标准，没有验收方式的输出说明任务还没拆清。输入与前置依赖要区分开：输入是本任务要消费的材料或数据，前置依赖是本任务开始前必须由他人完成或就绪的条件。两者都要写就绪标志，区别在于输入关注“材料能不能用”，依赖关注“条件有没有到位”。
填写句式可以统一为“对象＋来源/归属＋状态标准”。例如输入写成“什么材料，谁提供，什么形态，达到什么状态可用”；依赖写成“谁在什么时间前完成什么，以什么现象作为就绪标志”。统一句式的好处是评审时能快速发现缺项：只写了对象没写状态标准的字段，通常就是后续扯皮的地方。
从拆解动作到边界卡：四步操作流程
边界卡不建议从“我要做什么”开始写，而应从交付物倒推。按下面四步推进，每一步都有明确的输入、动作、输出和完成标志，四步走完边界卡即可提交确认。
第一步：识别交付物，倒推输出
输入是任务在整体拆解中的位置和上一级目标。动作是问“这个任务结束后，别人能拿到什么”，把交付物逐项列成名词，再补上格式、存放位置和命名规则。输出是一份输出清单。完成标志：每项输出都能被第三方找到并打开，不存在“完成开发”“推进联调”这类动作型描述。
第二步：追溯输入与前置依赖
输入是第一步的输出清单。动作是对每项输出反推“做它需要什么材料、需要谁先完成什么”，把材料归入输入、把他人须先就绪的条件归入前置依赖，并分别补上来源和就绪标志。输出是输入清单和依赖清单。完成标志：每条输入和依赖都有明确的责任方与可观察的就绪状态，且标注了未就绪时的处理方式。
第三步：划定不包含事项
输入是任务名称、输出清单以及拆解时讨论中出现的相邻工作。动作是把容易被认为是本任务范围、但实际归属别处的工作逐条写出，并注明归属任务或归属人。输出是不包含事项清单。完成标志：清单里每条都是具体工作而非“其他事项”，且至少覆盖拆解讨论中被提到过一次的边界模糊点。
第四步：约定验收口径
输入是输出清单和不包含事项。动作是为每项输出指定验收人和检查项，写出通过标准，并确认验收人本人认可这套标准。输出是验收口径表。完成标志：每条输出都有对应检查项，每个检查项都有可判断通过与否的标准，验收人已确认。
四步完成后，边界卡应能回答四个问题：拿什么做、做出什么、什么不归我做、怎样算做完。任何一个问题答不上来，回到对应步骤补充，不带着缺口进入执行。
谁写、谁确认、谁验收：角色与交付物分工
边界卡不是任务负责人一个人的文档。起草、确认、执行、验收各环节有不同角色参与，分工不清时最常见的后果是验收标准在执行中被临时改写。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 任务负责人 | 按四步流程起草边界卡，维护输入、输出和依赖状态，变更时第一时间更新 | 边界卡初稿、变更记录 |
| 拆解主持人 | 组织边界卡评审，检查五项字段是否齐全、输出与验收是否对应，协调跨任务的范围争议 | 评审结论、待补项清单 |
| 依赖方 | 确认依赖事项与就绪时间，就绪后给出可观察的完成信号，无法按时就绪时提前告知 | 依赖确认意见、就绪通知 |
| 验收人 | 在任务进入执行前确认验收口径，执行中按检查项核对，完成后给出通过或不通过的结论 | 验收口径确认、验收结论 |
确认时点安排在任务进入执行之前。任务负责人完成初稿后，由拆解主持人组织一次简短评审，依赖方和验收人分别确认与自己相关的字段，确认后的边界卡作为执行依据。执行过程中出现以下情况需要变更：输出交付物增减、依赖就绪时间变化、验收标准调整、发现新的相邻工作需要划出范围。变更由任务负责人发起，更新边界卡并通知依赖方和验收人，涉及验收标准的变更必须经验收人重新确认后才生效。
边界卡需要随任务一起被承载和流转。在 ONES 中，可以把边界卡内容写进工作项的描述或字段中，让输入、输出、依赖和验收口径与任务状态放在同一处，评审意见和变更记录也留在工作项里，减少边界信息散落在聊天记录和本地文档中的情况。具体字段如何配置，以团队实际使用的工作项类型为准。
示例：一个接口联调任务的边界卡
以下示例为演示情景，用于说明五项字段的落地写法，不代表任何真实项目。
| 字段 | 填写内容 |
|---|---|
| 任务名称 | 订单查询接口联调 |
| 输入 | 《订单服务接口说明 v1.2》，由后端组在开发完成后提供，含请求参数、返回码和错误示例；测试环境账号一组，由测试组提供。可用标准：接口说明覆盖本次联调的全部接口，账号可登录测试环境 |
| 输出 | 《联调记录》一份，Markdown 格式，存放在项目文档库“联调”目录，按“日期-模块”命名，记录每个接口的调用结果与差异；《问题清单》一张，每条含问题描述、责任人和当前状态 |
| 前置依赖 | 依赖后端组完成测试环境部署，就绪标志为环境地址可访问且冒烟用例通过；依赖前端组提供页面调用入口，就绪标志为入口在测试环境可点击。未就绪时先完成联调用例编写，不进入实际调用 |
| 不包含事项 | 不包含前端页面样式调整，归入“前端适配”任务；不包含接口性能压测，归入“性能专项”任务；不包含线上环境验证，由发布任务统一安排 |
| 验收口径 | 验收人为测试负责人。检查项一：联调记录覆盖接口说明中的全部接口，每个接口有调用结果；检查项二：问题清单每条有责任人和状态，遗留问题均有结论。通过标准：约定接口全部完成调用且结果有记录，遗留问题不超过约定数量并已排期 |
逐项看这份边界卡：输入写到了文档名称、版本、提供方和可用标准，接手人不需要再问“接口说明在哪、全不全”；输出写到了格式、目录和命名规则，验收时能直接找到文件；前置依赖写到了依赖对象、就绪标志和等待期间做什么，避免任务空转；不包含事项把样式调整、性能压测和线上验证三项相邻工作明确划出，并注明了归属；验收口径的检查项与两项输出一一对应，验收人和通过标准都可判断。
这个示例也说明一个常见问题：如果只写“完成订单查询接口联调”，输入、输出和验收都无从核对，任务在执行中很容易被追加样式修改或性能测试。边界卡的价值就在于把这些内容提前写成文字，让范围争议在开工前解决。
完成检查：边界卡是否可执行的核对项
边界卡提交确认前，按下面清单逐项核对。清单中的阻断项不满足时，任务不应进入执行状态。
| 检查对象 | 检查项 | 不满足时的处理 |
|---|---|---|
| 输入 | 每条输入有名称、来源方和可用标准；不存在“相关资料”这类笼统表述 | 阻断：补齐来源与可用标准后再提交 |
| 输出 | 每项输出是可找到的交付物，有格式和存放位置；没有动作型描述 | 阻断：把动作改写为具体交付物 |
| 前置依赖 | 每条依赖有责任方和可观察的就绪标志；写明了未就绪时的处理方式 | 阻断：补就绪标志；无法确定时先与依赖方确认 |
| 不包含事项 | 列出的相邻工作具体，且注明了归属；覆盖了拆解讨论中的边界模糊点 | 返工：与拆解主持人核对范围后补充 |
| 验收口径 | 有明确验收人；每条输出至少对应一个检查项和一个通过标准；验收人已确认 | 阻断：验收人未确认前不进入执行 |
| 整体一致性 | 输出与验收逐条对应，输入与依赖无混淆，五项字段之间无矛盾 | 返工：按四步流程回查对应步骤 |
| 任务状态联动 | 边界卡确认状态与任务状态一致：未确认的任务不处于执行中；依赖未就绪的任务标注等待原因；验收未通过的任务不关闭 | 阻断：调整任务状态或补充说明后再流转 |
检查时可以用一个简单判断收尾：把边界卡交给没有参与拆解的人，看他能否说出“拿什么做、做出什么、什么不归我做、谁来验收、什么算通过”。五问都能答上，边界卡即可执行；有答不上的，回到对应字段补充，不靠口头解释弥补文档缺口。
常见问题
输入和前置依赖看起来很像，拆解时怎么区分？
按“谁消费、谁提供”来分：输入是本任务要消费的材料或数据，比如接口说明、设计稿、测试账号；前置依赖是本任务开始前必须由他人完成或就绪的条件，比如测试环境部署完成、页面入口可点击。两者都要写就绪标志，输入的标志是“材料能不能用”，依赖的标志是“条件有没有到位”。如果一条内容既像材料又像条件，看它是否需要他人先完成一项工作才能产生，需要就归入前置依赖。
任务执行到一半发现边界卡写漏了，应该怎么处理？
先判断漏掉的内容属于哪一类：输出交付物增减、依赖就绪时间变化、验收标准调整，还是发现新的相邻工作需要划出范围。由任务负责人更新边界卡，通知依赖方和验收人；涉及验收标准的变更，必须经验收人重新确认后才生效。变更记录留在边界卡或工作项里，避免口头约定替代书面口径。如果漏项导致任务已经偏离原范围，先暂停相关动作，补齐边界后再继续。
小任务也需要写完整的五项字段吗？
字段结构可以保留，篇幅按任务复杂度压缩。半天以内、单人完成、交付物明确的小任务，输入和输出各写一句、依赖写“无”或一行、不包含事项写最容易混入的一项、验收口径写清验收人和一条通过标准即可。判断标准是接手人能否不追问就开工、验收人能否直接判断通过与否。任务越小，越不需要长篇描述，但“什么算做完”这一项不能省。
验收人一直不确认验收口径，任务能不能先开工？
不建议先开工。验收口径未确认时，执行中的判断标准可能被临时改写，返工风险高。可以先把边界卡中已确认的输入、输出和依赖部分推进起来，同时把验收口径的确认作为待办明确到验收人，约定确认时间。如果验收人暂时无法确认，由拆解主持人协调，先确定检查项框架，通过标准可以后续细化，但验收人和检查项范围应在执行前落定。
不包含事项写多少条合适？
按拆解讨论中实际出现过的边界模糊点来写，通常三到五条即可，每条是具体工作并注明归属任务或归属人。写“其他事项”没有核对价值。判断是否写够，可以看评审时是否还有人问“这个要不要我们做”；如果相邻工作已经被明确划出并注明归属，范围争议在开工前就能解决。任务执行中再出现新的相邻工作，按变更流程补充。
