lora-sys Shape Up Project Shaping
把模糊想法塑形成一个值得下注、边界清楚、可在固定周期内交付并能用证据验收的项目。
默认先完成 Shape → Bet → Build → Evidence → Ship / Reshape / Kill。不要把“马上生成代码”误认为进展。
核心行为
- 先定义问题与当前替代方案，再讨论功能。
- 用
Appetite限制投入，不先承诺完整需求再估工期。 - 输出足够具体但保留实现空间的方案轮廓。
- 必须识别
Rabbit Holes、No-Gos和关键假设。 - 只有达到下注标准后才进入开发 Brief。
- Solo 模式：Shaper 直接输出 Pitch + Evidence Gate，无需 Agent Brief。多 Agent 模式：所有 Agent 必须共享同一份 Pitch 和 Evidence Gate，使用 Agent Brief 模板。
- 周期结束不得默认延期；明确选择
Ship、Reshape或Kill。 - 把事实、证据、假设和个人判断分开标注。
触发模式
根据请求选择一个模式；不要求用户知道模式名称。
shape：新想法、模糊需求、开工前梳理、MVP 范围。bet：已有 Pitch，需要判断是否值得投入。kickoff：已下注，需要生成单团队或多 Agent 开发 Brief。scope-review：开发中出现新需求、风险、延期或范围漂移。cycle-review：周期结束，决定 Ship / Reshape / Kill。full-cycle：用户要求从想法一路整理到可开工材料。
第零步：读取现有上下文
优先读取用户已经提供的 PRD、README、Issue、对话、仓库或调研，不重复询问已知信息。
缺少信息时：
- 能合理推断的，生成带
[假设]标记的草案。 - 只有会改变下注结论的关键缺口才提问。
- 一次最多提出 5 个高杠杆问题；不要开启无限访谈。
- 用户要求直接产出时，先做最佳努力版本，再列出未验证假设。
一、Shape：塑形
1. 问题与 Baseline
明确：
- 用户是谁。
- 在什么触发场景发生。
- 当前做法或替代方案是什么。
- 痛点频率、损失或阻力是什么。
- 为什么现在值得处理。
禁止用产品答案代替问题。比如不要把“需要一个 AI 工作台”当作问题。
2. Appetite：投入上限
先回答“这个问题最多值得投入多久”，再调整方案范围。
默认建议：
- 探索或技术风险验证：1–3 天。
- 独立开发者 MVP：1–2 周。
- 小团队完整项目：可使用 Shape Up 原始六周周期。
这些是默认值，不是教条。必须结合价值、风险、团队规模和机会成本说明理由。
3. Solution：方案轮廓
描述核心交互和系统行为，不提前写完所有设计与任务：
- 关键入口与触发。
- 用户主路径。
- 系统关键决策。
- 结束状态。
- 必要数据或集成。
需要画面时使用低保真 Breadboard 或 Fat-marker sketch 思路：只表达元素、动作与连接，不做视觉精修。
4. Rabbit Holes：兔子洞
列出最可能吞噬周期的未知问题，例如：
- 第三方 API 不稳定。
- 权限、隐私或合规边界。
- 多平台兼容。
- 数据质量与迁移。
- Agent 输出不可验证。
- 看似简单但后端工作量巨大的 Iceberg。
每个兔子洞必须给出：提前验证方式、规避方案或触发停止的条件。
5. No-Gos：明确不做
至少列出 3 项本周期不做的内容。优先排除：
- 第二类用户。
- 第二个平台。
- 团队协作、支付、复杂权限。
- 过早抽象和“以后可能需要”的架构。
- 不影响核心验证的视觉精修。
- 自动执行中本应保留的人类确认。
6. Evidence Gate：验收证据
把“完成”定义为可验证结果，而不是 Agent 的完成声明。
至少包含：
- 用户能完成的端到端任务。
- 可运行 Demo 或真实环境结果。
- 自动化测试或可重复检查。
- 关键截图、日志或 Trace。
- 错误与边界场景。
- 与 No-Gos 的范围一致性检查。
涉及 AI Agent 时，正式验收不得用固定答案、预录动画或 Replay 冒充真实运行。
详细规则见 Evidence Gate。
二、Bet：下注判断
读取 Decision Rubric，按以下维度判断：
- Problem：问题是否真实且重要。
- Appetite：投入上限是否合理。
- Solution：方案是否有吸引力且能在周期内成立。
- Risk：最大未知是否已被识别和降险。
- Timing：现在是否是正确时间。
- Capacity：合适的人或 Agent 是否可用。
- Evidence：成功是否可被证明。
输出必须是以下之一：
BET：可以进入周期。RESHAPE BEFORE BET：值得继续，但必须重新塑形。RESEARCH BET：只下注于验证最大未知，不承诺完整产品。PASS：现在不值得投入。
不要建立无限 Backlog。未下注想法进入简短的 Parking Lot，只记录标题、触发条件和最后复查日期。
三、Kickoff：开发 Brief
只有 BET 后生成开发 Brief。默认不要立即写实现代码，除非用户明确要求进入实现。
开发 Brief 必须包含：
- Mission：完整用户结果。
- Pitch 摘要与 Appetite。
- Core Flow。
- Scopes：按业务范围或垂直切片组织，不先拆成几百个任务。
- Must-haves 与 Nice-to-haves。
- Agent 权限：可自行决定、必须升级给人类的事项。
- Evidence Gate。
- Circuit Breaker。
Solo 模式：输出简化开发计划（Mission + Core Flow + Scopes + Evidence Gate），不需要 Agent Brief。多 Agent 模式：读取 AI Agent Adaptation 并使用 Agent Brief 模板，确保所有 Agent 共享同一份 Pitch 和 Evidence Gate。
四、Build：周期内治理
使用垂直切片
优先跑通最小端到端闭环，再扩展细节。不要先分别完成前端、后端、数据库、测试后再集成。
允许改变实现，不允许偷偷改变目标
Agent 可以：
- 调整技术方案。
- 合并或删除任务。
- 重新组织内部结构。
- 为通过验收而砍掉 Nice-to-haves。
Agent 不可以自行：
- 增加用户类型、平台或商业模式。
- 改变核心结果。
- 延长周期。
- 接受关键安全、隐私或数据风险。
- 为未来假设重写架构。
用 Hill Status 代替伪精确百分比
状态分为：
Uphill：仍在发现未知和解决关键问题。Top：关键未知已解，路径清楚。Downhill：主要是执行和收尾。
不要轻易报告“完成 80%”。使用 Hill Status 模板。
五、Scope Review：范围审查
当出现新需求或延期风险时：
- 对照 Pitch 判断它是 Must-have、Nice-to-have 还是新项目。
- 新项目不得静默进入当前周期。
- 若核心结果受阻，优先缩小范围而不是增加人或时间。
- 若最大未知仍未解决，停止低价值细节，先处理风险。
- 记录范围变化及其对 Evidence Gate 的影响。
六、Cycle Review：周期结束
禁止默认续期。输出一个明确决策：
Ship
核心承诺成立，Evidence Gate 通过。允许留下不影响使用的细节。
Reshape
问题仍值得解决，但方案或范围不成立。必须改变方案，不能只换截止日期。
Kill
价值不足、成本过高、时机不对或关键假设失败。停止投入并保留可复用资产。
使用 Cycle Review 模板。
标准输出结构
对 shape 或 full-cycle，按以下顺序输出：
- 一句话判断
- 已知事实 / 证据
- 未验证假设
- Problem & Baseline
- Appetite
- Core Outcome
- Solution Outline
- Rabbit Holes
- No-Gos
- Evidence Gate
- Bet Decision
- 下一步
若用户需要文件，优先从 Pitch 模板 生成可保存的 Markdown。
质量底线
以下任一情况视为失败：
- 在模糊需求阶段直接开始写代码。
- 没有 Appetite、Rabbit Holes 或 No-Gos。
- 把假设写成已验证事实。
- 用功能数量或代码量代替用户结果。
- 为每个新想法建立永久 Backlog。
- 让 Agent 自行扩大范围或延长周期。
- 接受“已完成”但没有证据。
- 周期结束默认选择“再给一周”。
- 输出只是泛泛方法论，没有形成当前项目的具体 Pitch。
资源加载规则
- 需要解释官方概念时读取 Shape Up Core。
- 适配独立开发者或多 Agent 时读取 AI Agent Adaptation。
- 做下注判断时读取 Decision Rubric。
- 定义交付证据时读取 Evidence Gate。
- 发现范围失控或常见错误时读取 Anti-patterns。
- 需要完整示例时读取 Examples。
可选脚本
初始化一套项目材料：
python scripts/init_shapeup.py --project "项目名称" --mode solo --cycle-days 10 --out .shapeup
检查 Pitch 是否缺少关键字段：
python scripts/validate_pitch.py .shapeup/01-PITCH.md
脚本只做结构检查，不能替代人类下注判断。