Jira Planner 的巧思：先把模糊意图问成规格，再交给 AI 执行

很多团队已经有能写代码的 AI agent，却仍然要花大量时间解释「到底要做什么」。需求只写了一句目标，模型就会自行补全范围、架构约束和边界条件；等人发现方向偏了，返工的已经不只是几行代码。

Jira Planner 是 Atlassian 放进 Jira 的计划工具，面向需要多人对齐的多迭代功能、架构决策和其他复杂开发工作。用户可以从一个并不完整的想法开始，让 Planner 追问范围、约束和成功标准，再结合代码库、Teamwork Graph 与 Confluence 历史生成结构化规格，最后拆成带依赖关系、里程碑和验收标准的 Jira 工作项。12

Jira Planner 的发布说明显示，产品于 2026 年 8 月 19 日进入 Early Access。使用前需要 Jira Cloud、Rovo、Teamwork Graph 和 Confluence 连接，Planner 会把计划发布为可编辑的 Confluence Live Docs；Early Access 目前采取分批开放。1

Jira Planner 最值得注意的入口，不是让用户先写一份完整 PRD，而是接受一个粗略目标。用户只要说明想做什么，Planner 就会先搜索相关上下文，再提出需要确认的问题。官方演示里，用户输入一个「Financial Health Overview」功能想法后，Planner 先检索 Teamwork Graph，再追问「一眼看到财务状况时，什么最重要」，并给出可选择的答案。1

这个交互把「写需求」拆成了两个动作：人先给方向，AI 再找出方向里缺失的决策。用户不必在空白文档里一次性想全范围、约束和成功标准，但用户仍然要对关键选项作判断。Planner 的追问也不是脱离项目语境的通用问卷，因为产品会先读取代码、团队知识和已有决策，再把问题放回当前项目里。12

这套顺序解决的是 agent 最容易犯的一种错：模型把缺失信息当成授权，自行替用户做决定。Atlassian 的发布说明把问题说得很直接：如果需求没有写清范围、架构约束和边界情况，agent 会沿着自己的补全继续执行，最后交付一个「看起来很自信」但并非团队想要的结果。1

设计代价也很明确。Planner 把思考前置成一轮轮回答，短小任务可能因此显得偏重；如果追问没有带着足够上下文，用户只是把写文档换成了填问卷。真正值得借鉴的地方不是「让 AI 多问几个问题」，而是让 AI 先从已有资料中找出不确定点，再只把必须由人决定的问题推回来。

很多 AI 工具把规格输出成一段聊天文本，用户还要把文本复制到文档、任务系统和 coding agent。Jira Planner 选择把中间结果留在 Jira 的工作结构里：一个计划对象里并列放着 Requirements、Technical plan 和 Work items，用户可以编辑计划、邀请工程师和设计师协作、留下行内评论，再检查规格是否已经足够清楚。

Planner 发现的歧义会被标出来，并给出缺失信息的提示。计划确认后，产品会把内容拆成 Jira 工作项；每个工作项带着验收标准、依赖关系、里程碑和完整计划的上下文，之后才进入 agent 编排。1

这个选择改变了交接单位。agent 接到的不是某个聊天窗口里暂时存在的 prompt，而是团队可以继续修改、分派、审查和追责的工作项。Jira 的官方指南把规格称为 agent 的锚点：规格包含需求和验收标准，Teamwork Graph 再补上跨 Jira、Confluence、代码和其他协作工具的上下文；agent 的活动和 Pull Request 也会继续绑定在工作项上。2

独立技术媒体 DevOps.com 对这套思路的概括是，Atlassian 正在把 Jira 变成 agent 工作流的分配、跟踪、审查和治理层；报道还提到，Jira Planner 会从代码库、Jira 和 Confluence 中提取信息，生成结构化技术规格，供 AI agent 或人类开发者继续使用。3

Atlassian 对 15 名高吞吐工程师的访谈也给出了一个相近的工作语境：工程师把项目拆成边界清楚的 Jira 工作项，交给 coding agent 并行处理；工作项而不是聊天记录或命令行，负责协调团队和 agent，明确依赖顺序还能减少 PR 互相冲突。4

Jira Planner 的代价，是把团队带进一个更重的工作管理层。用户需要连接多个 Atlassian 数据源，团队也要接受计划、任务、agent 活动和人工审批都围绕 Jira 留痕。对于一次性的简单修复，这套结构可能超过任务本身的需要；对于需要多人协作、跨仓库依赖和持续审查的工作，结构化中间对象才有机会减少反复解释。

Jira Planner 的核心巧思，可以压缩成一条顺序：先让 AI 读取上下文并找出缺口，再让人回答真正需要判断的问题；先把答案沉淀成可协作的规格，再拆成带验收标准和依赖关系的工作项，最后交给 agent 执行。

这条顺序把 AI 产品的重点从「生成一份看起来完整的内容」移到了「建立一份团队可以继续检查的中间对象」。产品经理得到的是更清楚的范围，设计师和工程师得到的是可评论的计划，agent 得到的是可执行的上下文。Jira Planner 也因此提醒产品设计者：当模型开始替人做多步工作时，最重要的交互往往不是最后那个生成按钮，而是生成之前如何暴露不确定性，以及生成之后把结果放在哪里继续被人接管。