用AI创建任务，关键是把一句模糊需求变成他人可以直接执行的工作项。做法是先备好需求原文、背景和验收线索，让AI按固定字段输出任务草稿，再由人逐项校验后写入工作项系统。本文按操作顺序说明步骤、字段规范、提示词结构、角色分工与检查清单，并自然提及ONES在工作项承载与状态跟进上的衔接方式。
要点总览（TL;DR）
- AI创建任务按五步走：备好需求原文、背景与验收线索，让AI按固定字段出草稿，人工逐项校验，写入工作项系统并设定状态与负责人，最后确认任务可被他人直接执行。
- 任务草稿固定包含标题、描述、验收标准、优先级、依赖、建议负责人和不确定项七个字段，验收标准写成“场景+预期结果+判定方式”才可验证。
- 提示词要说清角色、任务边界、输出格式和质量要求，上下文提供需求原文、项目与迭代目标、已有任务和团队约定，并要求AI标注不确定项而不是编造。
- AI负责生成草稿和列出待澄清问题，需求提出者、任务创建者、执行者、评审者各自承担确认、执行和验收责任，写入系统前的确认责任始终在人。
- 任务写入前用检查清单核对：单一可交付结果、验收标准可验证、依赖与负责人明确、无未标注的臆造内容、状态与跟进方式已设定。
AI创建任务的核心步骤：从需求到工作项
AI创建任务可以拆成五步。每一步都有明确输入、动作和输出，完成标志是任务能被另一位同事在不追问背景的情况下直接执行。
第一步：准备输入材料
输入至少包含三类内容：需求原文（客户反馈、会议纪要、PRD片段或一句话诉求）、背景上下文（所属项目、迭代目标、相关已有任务、团队约定）、验收线索（什么情况算做完、由谁确认）。输入越具体，AI拆出的任务越接近可执行状态。缺少验收线索时，先让AI标注待确认项，不要让它自行补全。
第二步：让AI按固定字段生成任务草稿
给AI一份固定的输出结构，要求它逐字段填写：标题、描述、验收标准、优先级、依赖、建议负责人、不确定项。固定字段的作用是让不同人拿到的草稿格式一致，便于批量校验。草稿阶段允许存在待确认内容，但必须显式标注。
第三步：人工校验与修订
校验者逐项核对：标题是否指向单一结果、验收标准是否可验证、依赖是否真实存在、负责人是否在团队范围内、AI是否臆造了未提供的信息。发现空泛描述时，要求AI补充具体动作和完成条件，或由校验者直接改写。这一步是AI创建任务质量的分水岭。
第四步：写入工作项系统并设定状态与负责人
校验通过后，将任务写入工作项系统，补齐系统属性：所属项目、迭代、任务类型、负责人、优先级、计划时间。状态从“待处理”或“待评估”开始，按团队流程流转。写入时保留需求原文链接，方便执行者回溯背景。
第五步：确认完成标志
完成标志不是“任务已创建”，而是“任务可被他人直接执行”：执行者读完标题和描述知道要做什么，读完验收标准知道做到什么程度算完成，看到依赖知道先等什么，看到负责人知道找谁确认。达不到这个标准，回到第三步继续修订。
任务草稿需要哪些字段与验收标准
AI生成的任务草稿应固定包含以下字段。每个字段都有填写要求和常见的不合格写法，校验时按表逐项对照。
| 字段 | 填写要求 | 常见不合格写法 |
|---|---|---|
| 标题 | 动词开头，指向一个可交付结果，包含对象和范围 | “优化登录”“处理一下反馈” |
| 描述 | 说明背景、要做的具体动作、边界和不做什么 | 只写“按需求实现”，无背景无边界 |
| 验收标准 | 可观察、可验证的完成条件，逐条列出 | “功能正常”“体验良好” |
| 优先级 | 依据业务影响和时限给出等级，并写明理由 | 全部标为“高”，无理由 |
| 依赖 | 列出前置任务、外部接口或待确认事项 | 留空或写“无”，但实际存在前置条件 |
| 建议负责人 | 给出角色或具体人选，并说明建议依据 | 写“相关人员”“待定” |
| 不确定项 | 列出AI无法从输入中确认的内容 | 直接编造答案，不标注 |
验收标准的可验证写法
可验证的验收标准通常包含三个要素：操作或场景、预期结果、判定方式。例如“在弱网环境下提交表单，页面在3秒内给出成功或失败提示，失败时可重试”，比“提交体验流畅”更容易判定。验收标准尽量写成条目，每条对应一个可检查的结果；涉及多方确认的，写明由谁确认。
字段与工作项系统属性的对应关系
草稿字段写入系统时需要映射到具体属性：标题对应工作项标题，描述对应详情描述，验收标准可放入描述末尾或独立的验收字段，优先级对应优先级属性，依赖对应关联工作项或阻塞关系，建议负责人对应负责人属性。映射关系应在团队内固定下来，避免同一类信息每次写在不同位置。ONES的工作项支持标题、描述、负责人、优先级、状态和关联关系等属性，可作为承载任务草稿的落点；具体字段配置以团队实际项目设置为准。
提示词与上下文怎么给：让AI拆得准
AI拆得准不准，取决于提示词是否说清了角色、边界和输出格式，以及上下文是否提供了足够的事实依据。
提示词应包含的四部分
- 角色：说明AI以什么身份工作，例如“你是研发团队的任务拆解助手”。
- 任务边界：说明本次要拆什么、不拆什么，例如“只拆前端交互部分，后端接口改造不在本次范围”。
- 输出格式：给出固定字段和填写顺序，要求逐字段输出，不确定项单独列出。
- 质量要求：要求一个任务对应一个可交付结果，验收标准可验证，不编造输入中没有的信息。
需要提供的上下文清单
- 需求文档或需求原文，保留原始表述。
- 所属项目、迭代目标和时间范围。
- 已有任务列表，避免重复创建或遗漏关联。
- 团队约定：任务粒度习惯、字段填写规范、负责人范围。
- 验收线索：谁确认、以什么方式确认。
粒度控制与不确定项标注
粒度控制的标准是一个任务对应一个可交付结果，通常能在数小时到数个工作日内完成，并由一位负责人主导。拆得过细会产生大量协调成本，拆得过粗则无法分配和验收。提示词中可以直接写明“每个任务只包含一个可独立验收的结果”。同时要求AI把无法从输入中确认的内容列入不确定项，例如“接口超时阈值未在需求中给出，需与后端确认”，而不是自行填一个数字。
ONES Assistant智能助手能够理解项目、工作项、迭代和Wiki页面等真实工作上下文，基于相关项目数据和团队知识回答问题并执行后续操作，减少反复补充背景。其示例指令中包含将PRD拆解为需求和任务、按模块分配负责人，以及创建工作项并更新状态、通知负责人等操作；这些以示例形式呈现，实际效果需在具体项目中验证。
角色分工与交付物：谁生成、谁校验、谁执行
AI创建任务涉及四类角色。AI承担草稿生成，人承担确认责任，每个环节都有明确的交付物和交接方式。
| 角色 | 职责 | 交付物 | 交接方式 |
|---|---|---|---|
| 需求提出者 | 提供需求原文、背景和验收线索，回答澄清问题 | 需求说明与验收线索 | 提交给任务创建者，或直接作为AI输入 |
| 任务创建者 | 组织提示词与上下文，触发AI生成草稿，完成首轮校验 | 任务草稿与校验记录 | 将修订后的任务写入工作项系统 |
| 执行者 | 按任务描述和验收标准执行，反馈阻塞和偏差 | 执行结果与完成说明 | 更新工作项状态，提交验收 |
| 评审者 | 确认验收标准是否达成，决定关闭或退回 | 验收结论 | 在工作项中记录结论并流转状态 |
AI承担什么，人确认什么
AI适合承担：从长文档中提炼要点、按固定字段生成草稿、列出待澄清问题、给出拆解建议、按模块初分负责人。人必须确认：需求理解是否正确、验收标准是否覆盖真实完成条件、依赖是否成立、负责人是否合适、优先级是否符合当前业务判断。AI的输出是草稿，写入系统前的确认责任始终在人。
交接时的最小信息集
任务创建者交给执行者时，至少包含：任务标题与描述、验收标准、依赖与前置条件、负责人和计划时间、需求原文链接。执行者退回时，至少说明卡在哪条验收标准、需要谁提供什么信息。评审者给出结论时，写明通过或退回的具体依据，便于后续追溯。
示例：一条需求如何被拆成可执行任务
以下为演示情景，用于说明流程，不代表真实客户案例。
示例需求原文
“用户反馈在移动端提交工单后，偶尔收不到提交成功的提示，重复点击会生成两条工单。希望这周内处理。”
AI生成的初始任务草稿
- 标题：修复移动端工单提交重复与提示缺失问题
- 描述：移动端提交工单后偶发无成功提示，重复点击产生重复工单。需排查提交按钮防重复机制和提示展示逻辑。
- 验收标准：提交成功后展示成功提示；连续点击仅生成一条工单。
- 优先级：高，理由为用户可感知且产生重复数据。
- 依赖：无。
- 建议负责人：移动端开发。
- 不确定项：偶发的触发条件未明确；提示缺失是否与网络超时有关待确认。
人工校验后的修订结果
校验者发现草稿把两个问题合在一个任务里，且验收标准缺少判定方式。修订为两个任务：其一“移动端工单提交按钮增加防重复提交”，验收标准为“连续点击5次仅生成一条工单，接口日志可验证”；其二“移动端工单提交结果提示补齐”，验收标准为“提交成功、失败、超时三种情况均有明确提示，失败和超时可重试”。同时补充依赖：提示文案需产品确认；不确定项保留“偶发触发条件需结合日志定位”。
最终写入工作项的任务内容
两个任务分别写入工作项系统，关联同一需求原文，设置负责人、优先级和所属迭代，状态设为“待处理”。任务描述中保留不确定项，指定由创建者在开发启动前与产品确认文案。执行者领取任务后可直接按验收标准开发和自测，评审者按条目逐项确认。
在ONES中，这类任务草稿可写入项目工作项，通过状态流转和负责人字段跟进执行；ONES Assistant的示例指令覆盖了创建工作项、更新状态和通知负责人等操作，可作为自然语言触发任务创建的参考，具体可用范围以实际环境为准。
完成检查：任务创建质量的核对项
任务写入系统前，按以下清单逐项核对。任何一项不通过，回到对应步骤修订。
| 核对项 | 通过标准 |
|---|---|
| 标题与描述是否指向单一可交付结果 | 一个任务只包含一个可独立验收的结果，描述写明背景、动作和边界 |
| 验收标准是否可验证 | 每条标准包含场景、预期结果和判定方式，可由评审者逐条确认 |
| 依赖与负责人是否明确 | 前置任务、外部确认事项已列出；负责人为具体角色或人选，并说明依据 |
| 是否存在AI臆造或未标注的不确定项 | 输入中没有的信息未被编造；无法确认的内容已列入不确定项并指定澄清人 |
| 状态与跟进方式是否已设定 | 初始状态、所属迭代、计划时间和验收方式已填写，执行者可据此推进 |
这张清单也可以反过来用于复盘：任务执行中出现返工或阻塞时，对照检查项定位是哪个字段没填清楚，再调整提示词和校验重点。持续几轮后，团队会形成适合自身业务的任务字段约定，AI生成的草稿也会更接近可直接执行的状态。
常见问题
AI拆出的任务粒度太粗或太细，怎么调整？
先看提示词里有没有写清粒度标准。可以在提示词中直接约定“每个任务只包含一个可独立验收的结果，通常能在数小时到数个工作日内完成，由一位负责人主导”。如果拆得过粗，要求AI按交付物或模块再拆一层；如果拆得过细，把同一交付物下的关联动作合并，保留一个可验收的主任务。调整后仍以人工校验为准，粒度最终由团队的任务管理习惯决定。
需求信息不完整时，AI创建的任务还能直接用吗？
不能直接当作最终任务使用。做法是要求AI把无法从输入中确认的内容列入不确定项，例如阈值、文案、触发条件，并指定澄清人。任务可以先写入系统并设为待评估状态，但涉及验收标准的关键缺口应在开发启动前补齐。把不确定项显式保留下来，比让AI自行补一个看似合理的答案更安全。
AI生成的任务草稿写入ONES后，还能追溯原始需求吗？
可以。写入时在任务描述中保留需求原文链接或来源说明，执行者据此回溯背景。ONES Assistant能够理解项目、工作项、迭代和Wiki页面等真实工作上下文，并基于相关项目数据和团队知识回答问题、执行后续操作，其示例指令中包含将PRD拆解为需求和任务、创建工作项并更新状态、通知负责人等操作，实际效果需在具体项目中验证。
团队刚开始用AI创建任务，应该先统一什么？
先统一三件事：任务草稿的固定字段及填写要求、字段与工作项系统属性的对应关系、验收标准的写法。这三项确定后，提示词和校验清单才有共同依据。建议先用一两条真实需求跑完整流程，对照检查清单复盘返工点，再逐步调整提示词，不必一开始就追求覆盖所有任务类型。
AI创建的任务出现返工，怎么定位原因？
用检查清单反向排查：是标题和描述没有指向单一结果，还是验收标准缺少判定方式，或者依赖和负责人没写清。定位到具体字段后，回到对应步骤修订，并同步调整提示词中的质量要求。连续几轮后，团队会形成适合自身业务的任务字段约定，草稿质量也会逐步稳定。
