AI 编码代理从您的代码仓库中工作，那么为什么要将任务保留在 Jira 中？了解任务作为代码如何将它们以 Markdown 形式存储在 Git 中，与代码和文档并排放置。AI 编码代理在它们所需的一切都存在于仓库时效果最佳，因为代码是它们的真实来源。然而，大多数团队仍在 Jira 或 Redmine 等工具中跟踪任务和需求，这些工具位于仓库之外。将任务存储为简单的 Markdown 文件改变了这种情况：代理可以在一个地方读取需求和代码，每个任务变更都像任何其他提交一样被版本控制和可审查。Docs as Code 方法已经提供了这种演变的蓝图，一个与 Git 同步的网页界面可以让技术作者和产品负责人保持沟通，而不必强迫他们进入命令行。Docs as Code 文档已经从独立文档软件转变为 Git 仓库中的 Markdown 文件。今天，它通常位于代码仓库中的 /docs 文件夹内。这种做法被称为 Docs as Code 或 Docs Like Code。随着 AI 编码代理的出现，这种方法变得更加有用。代理可以阅读文档以理解系统，修改代码，并在同一工作流程中更新相关文档。文档成为软件开发的一个不可或缺的部分，而不是必须在之后单独完成的活动。任务作为代码同样的原则适用于开发任务。当任务存储为 Markdown 文件时，代理可以直接读取它们，利用它们来规划工作，并在同一文件中记录结果。Git 使任务历史与软件和文档的历史一起可访问。这个想法在规范驱动开发 (SDD) 中已经反映出来。SDD 使用 Markdown 中的规范来定义在 AI 代理实现之前预期的行为。任务文件可以发挥类似的作用，尽管细节的层级取决于工作。一个小的维护任务可能只需要一个简短的描述，而复杂的特性可能需要接受标准、技术决策、依赖关系和测试要求。SDD 通常由专用工具如 Spec Kit 支持，但一个更简单的方法就足以开始：将任务文件本身视为规范。这样使过渡更简单，因为它只需要 Git 和代理。以下是一个包含五个步骤的简单工作流程：描述任务。写一个需要实现的变更或特性的简短描述。分析需求。代理读取任务并检查相关代码和文档。创建实施计划。代理添加一个拟议的解决方案，并确定其打算进行的更改。审核与批准。开发人员审核计划并授权实施。实施与报告。代理更改代码，必要时更新文档，并将实施报告附加到任务文件中。任务描述、实施计划和报告保持在一个文件中。这使得审查原始需求、理解计划方法以及查看代理实际更改的内容变得容易。审批步骤让人们保持掌控。代理不会直接从任务描述进入实施；计划可以先进行审查和更正。一个示例设置在我自己的设置中，我使用三个独立的 Git 仓库：代码、文档和任务。文档和任务通常有不同的访问要求。文档可以是公开的，而任务可能包含有关未完成的安全修复、内部规划或尚未宣布的功能的敏感信息。独立的仓库让您可以独立配置访问权限并保持任务的私密性。在本地，开发人员将文档和任务仓库克隆到代码仓库内的文件夹中。两个文件夹都在代码仓库的 .gitignore 文件中列出，因此父仓库不会跟踪它们的内容。每个克隆的仓库保留其自己的 Git 历史，可以独立地进行提交、推送和同步。/code-repo /src /tests /docs # 独立的文档仓库 /user-guides /admin-manuals /developer-docs /tasks # 独立的私有任务仓库 /release-123 task-551-something-descriptive.md task-552-something-descriptive.md .gitignore # 排除文档和任务 所有信息现在都可以被本地编码助手如 Claude Code 或 OpenCode 获取。在实施任务时，代理读取任务，分析代码，实施变更，并更新相关文档。实施报告与任务保持在一起，而实际的代码更改则记录在代码仓库中。在 Git 提交中引用任务文件名有助于将实施与原始需求联系起来。当任务被组织到发布文件夹中时，代理可以使用已完成的任务和 Git 历史来草拟变更日志和发布说明。