为什么需要 Seed

本页是历史兼容地址。核心内容已经并入 Seed 总览，主阅读顺序请按“总览 -> 安装 -> 快速开始”进入。

Seed 解决的是一个很具体的问题：AI 可以写代码，但普通仓库往往没有为 AI 协作准备足够清楚的项目结构。需求、边界、模块、验证、交付记录散落在对话、脑子和临时文件里，每次 AI 会话都需要重新理解上下文。

MAWflow Seed 的目标不是替你写业务，而是把仓库改造成适合 AI Coding 的工作区。它让人和 AI 执行会话共享同一套项目事实、任务格式、检查入口和收口方式。

适用对象

• 个人开发者：希望减少重复解释，让 AI 更快理解项目。
• 独立开发者：希望一个人也能把需求、实现、验证和交付记录组织起来。
• 小团队：希望多人和多个 AI 会话使用同一套模块、任务和检查口径。
• 开源项目维护者：希望贡献者能按统一格式提交需求、任务包和验证证据。

Seed 的核心判断

常见问题	Seed 的处理方式
项目边界不明确	用 .maw/、模块档案和组件配置描述项目事实。
需求写得太口语化	用 Prompt Spec 把目标、边界、验收和验证写清楚。
大任务中断后难恢复	用 Task Pack、计划和 SESSION_STATE.md 保存执行状态。
修改后只靠感觉验收	用 Check Pack 和 Verification Pack 记录检查结果。
项目经验只留在聊天里	用学习模式沉淀术语、偏好、踩坑和本机差异。
公开内容容易带出敏感信息	用脱敏规则和 release gates 做公开前检查。

设计原理

1. 先让项目可读

AI 进入仓库时，最需要知道的不是“所有文件”，而是“本次任务应该读哪些事实”。Seed 通过项目身份、组件、模块、能力、项目信号和文档索引，让 AI 先定位再行动。

2. 任务必须可执行

可执行的任务不是一句愿望，而是包含背景、目标、允许修改、禁止修改、验收标准和验证命令的 Prompt Spec。复杂任务再升级为 Task Pack。

3. 结果必须可验证

Seed 鼓励把检查命令、人工验收、失败原因和风险说明写进交付记录。这样下一次维护时，不必从一段对话里倒推“当时到底验证了什么”。

4. 公开必须可审阅

开源仓库、公开任务包和示例案例都需要经过边界确认、脱敏和发布 gate。Seed 把“能不能公开”变成一组可审阅规则，而不是临时判断。

一个最小用例

你想让 AI 编程工具给博客项目增加搜索功能。

不推荐这样写：

帮我加一个搜索。

推荐这样写：

# 给博客增加文章搜索

## 背景
当前项目已有文章列表和文章详情页，但没有搜索入口。

## 目标
- 增加搜索输入框。
- 支持按标题和摘要过滤文章。
- 补充最小测试或验证说明。

## 允许修改
- code/client/**
- docs/modules/blog/**

## 禁止修改
- .local/**
- 与博客无关的组件
- 未脱敏配置和密钥

## 验收标准
- 用户可以输入关键词并看到过滤结果。
- 空关键词展示全部文章。
- 收口说明包含验证命令和风险。

这就是 Seed 想建立的工作方式：先把任务写到可执行，再让 AI 动手。

下一步

阅读 AI Coding 工作区，理解 Seed 如何把仓库分成源码、协议、文档、提示词、脚本和本机资料几个协作区域。