# AI Workflow：从MealPrep项目提炼的票单驱动智能体软件开发工作流 > AI Workflow是一套从实际项目（MealPrep AI）中提炼出的系统化智能体驱动软件开发流程，通过票单粒度控制、自验证循环和并行代理机制，实现大规模复杂项目的AI辅助交付。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-05-11T22:43:53.000Z - 最近活动: 2026-05-12T01:29:12.962Z - 热度: 137.2 - 关键词: AI辅助开发, 智能体工作流, 软件开发, 票单管理, MealPrep AI, LLD, 代码审查 - 页面链接: https://www.zingnex.cn/forum/thread/ai-workflow-mealprep - Canonical: https://www.zingnex.cn/forum/thread/ai-workflow-mealprep - Markdown 来源: ingested_event --- # AI Workflow：从MealPrep项目提炼的票单驱动智能体软件开发工作流 ## 项目起源与背景 AI Workflow并非来自理论推演，而是从真实的软件开发实践中淬炼而成。它的诞生地是一个个性化膳食规划系统项目——MealPrep AI，该项目涉及约70至90个后端开发任务，跨越四个开发波次。面对如此规模的代码库，开发团队遇到了一个普遍性的难题：单个AI代理的上下文窗口无法容纳整个项目，而完全依赖人工编码又无法在合理时间内完成。 更棘手的是，让AI代理"一口气做完所有事"往往会产生难以审查的代码垃圾；而完全放弃AI辅助，又意味着放弃巨大的生产力乘数。正是在这种张力中，一套新的工作范式逐渐成形：票单粒度的代理任务分配、自验证循环、规范化的操作手册，以及人类作为架构师、审查者和合并协调者的角色定位。 ## 核心理念与架构 AI Workflow的核心理念可以用一句话概括："AI负责打字，人类负责思考"。这并非贬低AI的能力，而是承认在复杂软件项目中，架构决策和方向把控仍然需要人类的判断力。代理的价值在于将详细设计转化为高质量代码，而不是替代设计过程本身。 该工作流强调几个关键原则。首先是票单必须"代理友好"——每个任务的范围应该控制在10到25个文件之间，足够小以便单个代理能够完整理解上下文，又足够大以产生有意义的交付物。其次是自验证机制——代理必须在报告完成前通过完整的测试套件（如Maven的`mvn verify`），否则人类将陷入手动修复的泥潭，效率优势荡然无存。 第三个关键原则是LLD（Low-Level Design，详细设计文档）作为单一事实来源。票单引用LLD，代理阅读LLD，审查者信任LLD。如果LLD存在错误，应该在编写更多票单之前修正它，而不是在实现阶段打补丁。 ## 工作流组件详解 AI Workflow仓库包含五个核心目录，每个都承载着特定功能： ### Playbook：规则手册 Playbook定义了整个工作流的"游戏规则"。它明确了什么是票单、什么是自验证、什么是审查标准。这些规则不是抽象的建议，而是从实际项目中总结出的硬性约束。例如，它规定了票单的最大文件数、测试覆盖率要求、以及代理报告必须包含的验证证据。 ### Templates：模板库 Templates提供了三类关键模板：票单模板、代理提示词模板和风格指南模板。票单模板确保每个任务都有清晰的范围界定、验收标准和依赖关系说明；代理提示词模板则指导如何为特定任务生成最优的代理指令；风格指南模板确保代码风格的一致性。 ### Conventions：约定集 Conventions目录收录了经过实战检验的模式，如验证循环的实现方式、并行代理的协调机制等。这些不是理论上的最佳实践，而是"在这个项目中我们这样做，因为那样做会出问题"的经验结晶。 ### Decisions：决策日志 Decisions采用ADR（Architecture Decision Records）格式，记录了每一个非显而易见的设计选择、背后的原因以及尝试过的替代方案。例如，其中一条决策详细解释了为什么将原本27个规范项、40个文件的`auth-01`票单拆分为三个更小的票单后，交付速度提升了三倍。 ### Starter-kits：启动套件 Starter-kits提供按技术栈分类的项目脚手架，目前以Spring Boot为主，未来计划扩展更多技术栈。这些脚手架包含了项目初始化所需的所有基础设施：构建配置、CI流水线、测试框架和代码规范工具。 ## 实际应用流程 AI Workflow的预期使用流程分为六个阶段： 首先是高层设计（HLD）和详细设计（LLD）阶段。这与传统开发流程无异，AI代理在此阶段的角色是辅助而非替代。设计文档将成为后续所有工作的权威参考。 第二阶段是代码库初始化。如果存在匹配的starter-kit，可以直接复制使用；否则需要手工搭建基础架构。第一个票单通常是"project-setup"，负责落地所有约定和工具链。 第三阶段是票单编写。根据templates/ticket-template.md的格式，将LLD分解为具体可执行的任务。每个票单应该链接到LLD的相关章节，明确文件范围，并列出验收标准。 第四阶段是代理执行。按照templates/agent-prompt-template.md生成代理指令，代理读取票单、LLD和playbook后编写代码，通过自验证后报告结果。 第五阶段是人类审查与合并。审查者检查代理报告、浏览代码差异、运行CI流水线，最后执行合并。 第六阶段是playbook的持续迭代。当某个环节出现摩擦时，及时更新约定和模板，让整个系统随项目演进而优化。 ## 性能指标与预期 根据项目文档，当工作流调优到位后，每个票单的预期处理时间为30至60分钟，其中人类介入时间约为5到10分钟。这意味着开发者可以在一小时内完成一个中等复杂度的功能模块，同时保持对代码质量的控制。 并行代理的使用可以进一步提升吞吐，但需要为每个代理明确划定范围边界，即便如此，每批并行任务仍可能产生5到15分钟的合并冲突解决时间。这提醒我们，AI辅助开发并非完全消除协调成本，而是将其从"写代码"转移到"协调代理"。 ## 适用场景与边界 AI Workflow明确指出了其适用范围。它适合以下场景：总工作量超过约10个票单或50小时个人开发；希望AI承担大部分编码工作但人类控制架构；对测试质量有严格要求；愿意在实现前投入时间编写详细规格。 反之，以下场景不适合使用AI Workflow：一次性脚本或原型（ overhead过高）；架构尚未成型的代码库（playbook需要架构作为约束基础）；纯研究性质的实验代码（形式化是额外负担）。 ## 项目现状与展望 截至2026年5月，AI Workflow已完成第一波提取，包含playbook和templates。其原始项目TwoLaugh/foodSystem已交付约9个生产票单。第二波及后续波次的验证正在进行中，仓库将随实际项目的发展而持续演进。 对于正在探索AI辅助开发规模化应用的团队，AI Workflow提供了一个经过实战检验的参考框架。它不是唯一正确的做法，但它是"从真实项目中生长出来"的做法，这种实践根基使其具有独特的参考价值。