我们如何构建软件工厂，将Astro的GitHub问题数降至零
内容提要
Astro团队利用AI代理构建自动化流水线，将GitHub问题从200多个降至约30个，预计下月归零。系统通过标签状态机驱动，自动复现、诊断、修复问题并发布预览版。失败案例暴露代码架构或文档缺陷，促使团队改进。该框架已开源为Flue和triagebot-action，供其他项目复用。
延伸解读
自动化三阶段：从复现到修复
Astro的自动化流水线严格遵循人工处理问题的步骤：复现、诊断、验证、修复。每个阶段由独立的子代理执行，并通过report.md传递信息，以避免LLM强行修复的偏见。这种设计确保了每个环节的透明性和可审计性，也使得自动化流程更接近真实维护者的工作方式。
标签状态机：轻量级流程控制
整个流水线仅依赖GitHub标签作为状态机，如“triage needed”和“fix verified”，不额外存储状态。每次触发时，代理通过阅读issue评论来推断当前状态和下一步操作。这种设计简化了系统，使其易于理解和维护，也方便其他项目复用。
失败即改进信号
当代理无法正确修复问题时，团队将其视为代码库存在架构或文档缺陷的信号。例如，HMR相关bug因缺少注释和测试导致代理反复出错，补充注释后问题解决。这种反馈循环不仅提升了代理性能，也改善了代码库的可维护性，对人和AI都有益。
开源框架与行动
团队将通用工作流抽象为Flue框架，并将具体实现开源为triagebot-action。其他项目可以直接使用或fork改造。这体现了从特定问题到通用解决方案的演进，鼓励社区参与和定制，而非提供一成不变的成品。
Q&A
Astro团队是如何将GitHub问题数从200多个降至零的？
Astro团队开发了一个自动化流水线，利用AI代理在GitHub Actions中自动复现、诊断和修复问题，并发布预览版供用户验证。通过标签状态机驱动流程，将问题数从200多个降至约30个，预计下月归零。
Astro的自动化问题处理流程具体包括哪些步骤？
流程包括四个阶段：复现（克隆用户提供的仓库验证问题）、诊断（通过插桩和日志定位根因）、验证（检查测试和文档判断是否为预期行为）、修复（将复现转化为失败的单元测试，根据架构指南实施修复）。每个阶段由独立的子代理执行，并通过report.md传递信息。
Astro的自动化系统是如何通过标签状态机来管理问题的？
每个新问题自动标记为“triage needed”，当用户确认修复后变为“fix verified”。流水线本身不保存状态，而是通过读取问题的评论和标签来推断当前状态和下一步操作。
当AI代理无法修复问题时，Astro团队如何解读这一失败？
团队将失败视为代码库存在架构或文档问题的信号，具体可能指向不清晰的抽象、缺少注释或测试覆盖不足。通过修复这些问题，代理和人类开发者都能更好地理解代码。
Astro团队如何确保自动化系统不会让用户感到疏远？
团队发现自动化反而增加了与用户的互动，他们现在更多地在Discord、RFC讨论和功能请求中与社区成员交流。自动化处理了重复性工作，让维护者能专注于更有价值的互动。
Flue和triagebot-action是什么？它们之间有什么关系？
Flue是一个开源的、平台无关的框架，用于构建持久的AI代理和工作流。triagebot-action是Astro团队将triage逻辑解耦后形成的独立GitHub Action，它基于Flue构建，并已开源供其他项目使用。
其他项目如何利用Astro的自动化框架？
其他项目可以直接使用triagebot-action，或者fork它来定制自己的自动化流程。团队鼓励阅读和改编代码，以构建适合自己项目的自动化“工厂”。
