面向编程支持人员的上下文工程
上下文工程是指确定编码支持人员在执行操作前可获取哪些信息的工作。它是影响输出质量最有力的手段，因为一个能力再强的模型，其表现上限也取决于您给到它的输入信息。
在 Jira 中，支持人员所需的上下文已经包含在工作之中。工作项承载目标与验收标准，Teamwork Graph 将其关联至代码、相关决策以及配套文档，以便支持人员依据真实意图执行，而非依靠空白提示词。该上下文可在团队内共享，不会被局限在单台设备的本地文件中。
本指南介绍什么是上下文工程、为什么上下文窗口才是编码支持人员真正的约束条件，以及如何在 Jira 中设计上下文，让支持人员获取所需信息，而无需您在每一条提示词中手动提供。实际操作中，这归结为您在现有工作中执行的几项操作：
向支持人员提供目标，而非仅提供提示词。将 Jira 工作项编写为规范，并设定用于评判支持人员的验收标准。
依靠 Teamwork Graph 提供周边上下文。以工作项作为提示词的起点，Teamwork Graph 会将其扩展为该任务对应的文档、决策记录以及相关上下文信息。
保持标准共享且实时更新。约定存储于 Confluence 中，所有支持人员与团队伙伴均从同一来源获取规范。
向所有支持人员提供同一套上下文层。Claude Code、Cursor、Codex、GitHub Copilot、Jira 编码支持人员等各类编码支持人员，均可获取相同的组织级上下文。
什么是上下文工程？
上下文工程是主动确定模型在每一步可获取哪些信息的实践，以此让编码支持人员拥有正确完成工作所需的全部内容。此类信息不止包含提示词，还包括代码库、您的标准、依赖关系、git 历史记录、工具定义、目标以及验收标准。为每一项任务筛选整理这套信息集合，是一项全新的工作。
提示词工程指由您自行整理信息，并将其置入单条指令中。上下文工程则是由系统在多步骤任务全过程为支持人员提供所需内容：确定输入内容、检索哪些信息、对哪些内容生成摘要、哪些信息予以舍弃，从而让支持人员可按需自行查找其余信息。
需要注意的是，更多的上下文并不一定等同于更好的上下文：
高信号上下文是真正有助于完成当前任务的信息
低信号上下文是模型仍需读取的过时、偏题或重复内容
随着上下文窗口被低信号令牌占满，即便模型本身并未发生变化，回答也会变慢且准确度下降。这种衰减被称为上下文腐化：当上下文窗口充斥过时、低信号或互相矛盾的令牌时，输出质量逐步下滑。优质的上下文工程既要补充正确的上下文，同样也要剔除过时的上下文。
为什么上下文窗口是编码支持人员的约束条件？
编码模型仅能对上下文窗口内可容纳的信息进行推理，而该窗口相较于代码库、文档以及团队历史记录而言容量有限。倘若任务对应的约定、架构或是决策从未进入上下文窗口，即便能力强大的支持人员，依旧会输出错误或不安全的代码。
当交由支持人员来收集上下文时，会反复出现若干失效模式：
支持人员在长任务中发生目标偏移，因为随着新的低信号令牌不断涌入，它早期做出的决策会被挤出上下文窗口。
过度检索，拉入窗口的信息远多于实际所需，将令牌预算消耗在噪声内容上。
无法获取您未主动提供的标准，最终输出的代码违背团队其余成员遵循的模式。
独立运行时表现正常，但完全不了解团队其他成员或其他支持人员在同一区域开展的工作。
相反，让支持人员可便捷获取正确上下文，使其能够在执行过程中自行调取所需内容，您的提示词便可保持高层级视角，无需手动逐条写明每一项约定与决策。
如何在 Jira 中为编码支持人员开展上下文工程？
在 Jira 中，直接将工作本身作为上下文：意图存放于工作项中，周边知识通过 Teamwork Graph 建立关联，持久化的标准与决策从 Confluence 和 Loom 中调取，所有支持人员与团队伙伴均从同一来源获取内容。Jira 的覆盖范围不再局限于单台设备上的本地文件，而是延伸至目标、正在进行的决策与沟通，以及全部工作历史记录。它对所有此类信息实现共享，因此支持人员执行任务所依据的上下文，对整个团队而言都是结构化、实时更新且统一的。
上下文工程基于三项原则：
选择正确的信息
保持信息结构化
保持信息可持久留存
1. 筛选与检索：将工作项编写为规范
筛选是为任务选取规模最小的高信号上下文集合；检索是按需调取正确信息，而非预先将全部内容一股脑填入上下文窗口。在 Jira 中，这两项工作均从工作项开始。
在 Jira 中的实现方式：将目标写在描述中，验收标准以清单形式列出。这会以支持人员可识别的结构，向其提供意图以及用于评判的衡量标准。随后将该工作项分配给已建立关联的支持人员。支持人员会从工作项及其关联上下文开始处理任务，而非读取整个代码库。与支持人员交互打磨这份规范也是工作的一部分：支持人员可快速读取大量内容，并在开展任务前帮您发现信息缺口。
即将推出：Jira 规划器可将想法转化为可供支持人员使用的计划与工作项，且上下文已附加。加入候补名单。
2. 共享上下文：关联工作内容，而非粘贴
结构与格式至关重要：对上下文进行整理，让支持人员能够理解信息脉络，保持信息关联而非复制副本。Teamwork Graph 可提供周边上下文，无需每次手动拼接整理。
在 Jira 中的实现方式：将工作项关联至相关工作项、代码以及存储规范、RFC 或决策记录的 Confluence 页面。支持人员会继承该任务周边全部上下文，而不仅限于工作单文本。Loom 演示同样适用：录制的缺陷复现过程或是设计依据，会将文字稿与摘要一并存入 Teamwork Graph，如此一来，原本讲给团队伙伴的说明，就变成了支持人员可以读取的上下文。该机制从真实工作中提供“经检索得到的正确信息”，而非依赖一套需要您搭建并维护的独立向量存储库。
3. 持久化：将标准与决策保存在可持续积累的位置
持久化（或称记忆），指跨会话保留长期有效的信息，使支持人员不必每次都从零开始。需要区分三类信息：支持人员在任务执行期间持有的信息、任务之间应当留存的信息，以及需要时可进行查询的信息。
在 Jira 中的实现方式：约定、架构决策以及首选模式存放于共享 Confluence 空间，全体团队成员与每一个支持人员都可通过 Teamwork Graph 从同一数据源调取，而非保存在某个人的设备上、其他人无法查看的副本。随着工作在系统内流转，Teamwork Graph 的信息会不断丰富，后续支持人员便可调取更多内容。上下文会随着工作完成持续积累，开发人员无需额外手动操作。
保障团队协同工作需要两点：所有支持人员均可共用的统一上下文层，以及保障上下文可靠、访问合规的治理机制。
面向所有支持人员的统一上下文层
您所构建的上下文，只有所有工具都能够使用，才有价值。为每一个支持人员重复灌输团队标准，是导致上下文腐化退化的最快捷方式。
在 Jira 中的实现方式：通过两条路径，向任意编码支持人员提供同一套组织上下文。Teamwork Graph CLI 让您的编码支持人员可从终端直接访问该上下文及其工具；完成一次配置后，支持人员在工作过程中即可查询 Teamwork Graph。Atlassian Rovo MCP 服务器可为 Claude、Cursor、Codex 以及 GitHub Copilot 这类 MCP 客户端提供同等能力。无论采用哪种方式，都依靠 Teamwork Graph 承载信息：工作项、决策、文档与代码整合为统一的可查询层。您只需完成一次上下文工程，就可以对接任意执行工作的模型使用。
治理：保障上下文信息可靠且合规
上下文只有在内容为最新版本，并且支持人员具备访问权限时才有价值。随着更多支持人员调用共享层，治理机制保障该共享层可信。
Jira 中的工作机制：支持人员继承团队已在使用的同一套权限作为基准，因此支持人员仅能看到其背后用户可查看的内容，不会超出该范围，还可通过支持人员专属规则进一步限定访问范围。关于访问、审批与审核如何协同运作，请参阅 Jira 中的智能体化工程护栏与安全保障。
Jira 如何适配您其余的上下文技术栈？
如今编码支持人员的大部分上下文都驻留在单台设备上：所打开的代码存储库、若干本地文件，以及开发人员在提示词中输入的各类内容。这套模式适用于单人工作场景，但上下文分散、按人员隔离，并且会丢失历史信息。Jira 与 Teamwork Graph 将关键上下文归集至一套共享、最新、可治理的层，供整个团队以及各类支持人员调取使用。
上下文维度 | 没有 Jira 时的存在位置 | Jira 和 Teamwork Graph 新增的能力 |
目标与验收标准 | 开发人员的提示词、聊天对话、个人记忆 | 工作项承载目标及评判标准，全员共享 |
代码库与历史记录 | 单台设备上打开的代码存储库 | 工作项关联实现该任务的分支、提交记录与拉取请求，任何人都可追溯任务对应的变更 |
标准与约定 | 本地配置文件（CLAUDE.md、AGENTS.md）、自述文件、口传经验 | Confluence 中持久化的共享标准，可供所有支持人员与团队伙伴调用 |
相关文档与决策 | 分散在文档、工作项和人员脑海中 | 该图谱自动将规范、RFC、决策记录关联至对应工作 |
跨会话记忆 | 按支持人员隔离、窗口内，窗口关闭即丢失 | 决策与历史记录持久留存，工作在系统流转过程中上下文可不断累积 |
令牌与成本效率 | 窗口内引用完整文件与整个代码存储库，每次运行均产生对应费用 | 支持人员基于与任务关联的高有效信息集开展工作 |
以上能力并不会取代您的编码支持人员、IDE 或是本地配置。这些工具依旧负责处理各代码存储库内的细节以及实际代码编写工作。Jira 是构建于上层的共享层，所有工具所依托的上下文均可实现结构化、实时更新，并且在整个团队内保持统一。
如何在 Jira 中为首个支持人员提供真实的上下文
上下文工程归根结底是为了向支持人员提供工具和信息，以便其自行查找所需内容。Jira 和 Teamwork Graph 是其通过 MCP 或 CLI 访问的共享上下文层，因此，工作就是保持该层准确且互连。
从一个格式完善的工作项入手，体验支持人员自行猜测与依据意图开展工作二者之间的区别。
为支持人员设定评判标准。选择一项范围明确、风险低且易于撤销的任务，例如独立的重构或小型缺陷修复，并在描述中写明目标，同时在清单中列出验收标准。
让支持人员继承上下文，而非粘贴上下文。在分支、提交记录或拉取请求中引用工作项关键字，将工作项与代码建立关联，同时绑定背后对应的文档或决策。支持人员将获取该任务周边的全部关联上下文，而不只是工作单内的文本内容。
指向共享标准。将支持人员应当遵循的约定关联至 Confluence 页面，确保后续支持人员与团队伙伴使用同一套信息来源。
将工作项分配给支持人员。支持人员从工作项及其关联上下文入手，相比完整代码库或是空白提示词，这是一个目标更为聚焦的起始点。
对照初始设定的标准开展审查。依据工作项中编写的验收标准对拉取请求进行核查，以此按照您最初提供给支持人员的标准来评判输出结果。
让支持人员完成闭环。任务结束时提示支持人员更新工作项，填入会话摘要、关键决策与取舍权衡，以及关联的拉取请求，以便后续团队伙伴或支持人员借助 Teamwork Graph，接续处理未完成的工作。
按此方式处理若干条工作项，该图谱便会随业务流转填充数据：每一个支持人员都会在工作项上留存摘要、关键决策以及关联的拉取请求，后续支持人员就能够基于比上一轮更完备的信息启动工作。这就是可累积的上下文工程，而非每次运行都全部重置上下文。
上下文工程常见问题解答
上下文工程与提示词工程有何区别？
提示词工程是为单条提示词手动整理相关信息的实践方法。上下文工程则是搭建一套系统，为支持人员的多步骤任务提供信息，涵盖信息检索、结构化处理、记忆留存以及目标本身，以此按需调取所需细节。
人工智能编码支持人员如何从 Jira 获取上下文信息？
支持人员从工作项、其描述与验收标准以及 Teamwork Graph 中调取上下文。Teamwork Graph 会关联相关工作、文档与代码，让支持人员依据真实意图执行操作，而非基于空白提示词。
即便提示词编写得很好，编码支持人员为什么仍会产出错误代码？
提示词很难承载约定、架构，以及任务背后的决策。大多数支持人员的问题属于上下文层面的问题，并非模型本身的问题，优化上下文带来的改善效果，远胜于打磨提示词措辞。
如果我的支持人员已经可以读取代码存储库，我还需要上下文工程吗？
需要。代码存储库只能告诉支持人员代码“是什么”，却无法说明代码“为何要这样设计”、应当遵循哪些标准，以及团队内其他正在推进的工作。上下文工程负责补齐上述剩余信息。
什么是上下文腐化？
上下文腐化是指随着上下文窗口被过时、低有效信息或是互相矛盾的令牌信息填满，支持人员输出质量逐步变差的现象。即便模型本身没有发生任何改动，支持人员的回复也会变慢、准确度下降。