升级反馈循环
Mawflow Seed 会持续更新。它的更新不应该来自抽象想象，而应该来自真实项目的使用反馈：哪些提示词反复失效，哪些检查缺失，哪些模块档案字段不够，哪些脱敏规则需要更严格。
本页说明 Seed 如何把项目经验回流成可复用装备，同时避免把非公开项目事实、客户数据或平台运行时混入公开仓库。
循环总览
text
项目使用 Seed
↓
发现协作缺口
↓
记录候选改进
↓
脱敏和通用化
↓
补文档 / Pack / 检查
↓
运行 readiness gate
↓
发布到公开 Seed什么适合回流
| 类型 | 可回流示例 |
|---|---|
| Prompt Spec 改进 | 更清楚的输入资料、禁止修改、验收和收口字段。 |
| Task Pack 结构 | 更稳定的 SESSION_STATE.md、任务拆分和恢复协议。 |
| Check Pack | 新增公开安全检查、模块档案检查、分发包检查。 |
| 模块档案规则 | 更清楚的页面、API、数据、验证和文档同步字段。 |
| 脱敏规则 | 新增常见泄露形态、公开前人工复核清单。 |
| 示例 Pack | 已授权、已脱敏、可复用的示例任务和交付证据。 |
什么不适合回流
| 类型 | 原因 |
|---|---|
| 具体客户需求 | 属于客户数据，不应进入公开 Seed。 |
| 未公开任务资料和提示词 | 只服务某次特定执行，不是公开装备。 |
| 平台运行时代码 | 云端项目空间、平台工具路由、远程执行、审批和企业治理运行时不属于 Seed。 |
| 真实 secret 或连接串 | 任何情况下都不能作为公开示例。 |
| 本机维护路径 | 只属于当前设备，不具备公开复用价值。 |
候选改进怎么记录
发现可复用改进时，建议先记录成候选，而不是直接改公开规范：
| 字段 | 说明 |
|---|---|
| 场景 | 在什么项目或任务中反复出现。 |
| 问题 | 当前 Seed 为什么不够。 |
| 建议 | 要补文档、Pack、脚本还是检查。 |
| 兼容性 | 是否影响已有项目。 |
| 脱敏状态 | 是否移除了客户、路径、账号、URL、日志和密钥。 |
| 验证方式 | 如何证明这个改进有效。 |
候选成熟后，再转成公开文档、示例 Pack 或检查脚本。
回流前的通用化
从项目经验回流到 Seed 时，需要完成三步：
- 去项目化：删除项目名、客户名、业务细节和未公开任务资料。
- 去环境化：删除本机路径、未公开域名、非公开仓库地址和临时配置。
- 结构化：保留目标、边界、步骤、检查、验收和风险。
最终公开内容应该让开发者知道“怎么用”，而不是看到一次性项目过程。
发布 gate
回流后的内容至少要通过：
bash
git diff --check
bash ops/scripts/check-seed-open-source-readiness.sh --strict --format json
bash ops/scripts/check-local-boundary.sh如果包含示例 Pack 或分发包，还应运行：
bash
bash ops/scripts/check-seed-distribution-readiness.sh公开仓库地址规则
公开文档中的 Seed 仓库地址只使用官网确认的公开地址：
text
https://github.com/mawflow/mawflow-seed不要写非公开仓库地址，不要写维护者本机目录，不要把一次性同步目标当成公开事实源。
和 Studio / Enterprise 的边界
Seed 的升级反馈循环只改进开源装备包。Studio 和 Enterprise 的平台能力、企业治理、审批、模型调用治理、自动调度和私有化运行时不通过 Seed 回流公开。
如果某个反馈只对企业平台有价值，应进入 Enterprise 产品路线，而不是公开 Seed。
下一步
如果你要贡献公开内容，先阅读 脱敏规则 和 检查与发布 gate。