Piv

核心用法

FTW（First Try Works）是一个基于Plan-Implement-Validate（PIV）循环的结构化开发框架，通过/ftw命令提供两种工作模式：

Full模式：面向大型功能开发，需先有PRD（产品需求文档）。支持多阶段编排，自动发现或指定PRD文件，按阶段执行代码库分析→PRP生成→执行→验证→调试→提交的完整流水线。子代理包括Executor（实现）、Validator（独立验证）、Debugger（修复），形成闭环质量保证。

Mini模式：无需PRD，通过3-5个发现性问题快速启动小型功能开发。自动完成需求澄清→代码库分析→PRP生成→实现→验证，适合100行以内的变更。

Init模式：快速初始化项目目录结构（PRDs/PRPs/templates/PRPs/planning）。

显著优点

1. 质量内建：强制独立验证子代理，避免"自测自验"的认知偏差
2. 上下文隔离：每个子代理100%新鲜上下文，防止上下文污染和token溢出
3. 智能降级：Mini模式根据变更规模自动选择验证策略（自验/独立代理）
4. 语义化提交：统一Built with FTW标记，便于追溯
5. 调试熔断：3次调试循环后强制人工介入，防止无限循环

潜在局限

• 启动成本：Full模式强制要求PRD前置，对探索性开发不够友好
• 子代理依赖：重度依赖sessions_spawn工具，环境兼容性受限
• 验证盲区：Validator独立验证但缺乏运行时测试能力，无法捕获环境相关问题
• 人工瓶颈：Executor BLOCKED或HUMAN_NEEDED时流程中断，响应延迟不可控

适合人群

• 追求"一次到位"交付质量的成熟工程团队
• 已有完整PRD实践的中大型项目
• 需要严格变更追溯的合规场景
• 对AI生成代码质量有高要求、愿意投入验证成本的开发者

常规风险

| 风险类型 | 说明 | 缓解建议 |

|---------|------|---------|

| 子代理超时 | 复杂任务可能导致sessions_spawn超时 | 拆分PRP粒度，设置阶段上限 |

| PRD-代码漂移 | PRD更新后未同步修订PRP | WORKFLOW.md中增加版本检查 |

| 验证假阳性 | Validator可能过度宽松或过度严格 | 保留人工抽查机制 |

| 目录污染 | init模式重复执行可能覆盖文件 | 添加存在性检查再执行 |

| Git依赖 | 要求系统预装git | 前置环境检查，友好报错 |

---

来源：GitHub开源项目（SmokeAlot420/ftw），属于社区驱动工具，建议结合团队代码审查流程使用。

核心用法

FTW (First Try Works) 是一个面向软件开发团队的结构化工作流 Skill，提供三种工作模式：

Full PIV 模式：基于 PRD（产品需求文档）执行完整的多阶段开发流程，支持从第1阶段到第N阶段的渐进式交付。通过 /ftw [prd-path] [start] [end] 调用，系统会自动发现项目中的 PRD 文件并按阶段执行。

Mini 模式：轻量级的发现驱动构建，无需预先编写 PRD。通过 /ftw mini [feature-name] 启动，先进行3-5个问题的快速需求澄清，然后生成 PRP（Prompt Requirements Plan）并直接执行，适合中小型功能开发。

Init 模式：项目初始化，快速搭建 PRDs、PRPs 目录结构和 WORKFLOW.md 模板。

工作流程的核心是 PIV 循环：Planner（通过子代理分析代码库并生成 PRP）→ Executor（独立子代理执行实现）→ Validator（独立子代理验证结果）→ Debugger（如发现问题则修复）。每个阶段使用 sessions_spawn 创建全新上下文的子代理，确保上下文预算可控。

显著优点

1. 架构清晰的分工体系：Orchestrator 保持轻量，专职协调；Executor、Validator、Debugger 各司其职，避免单一代理上下文过载
2. 强制验证机制：每个阶段必须通过独立 Validator 的完整验证，确保"First Try Works"的质量承诺
3. 灵活的启动方式：既支持严谨的 PRD 驱动开发，也支持快速迭代的 Mini 模式，适应不同场景
4. 零安全风险：纯 Markdown 文档架构，无可执行代码，无外部依赖，无网络请求
5. 版本化交付：每个阶段完成后自动生成语义化提交（Built with FTW），便于追溯

潜在缺点与局限性

1. 学习成本较高：需要理解 PRD、PRP、PIV 等概念体系，新用户上手需要阅读多个参考文档
2. 子代理依赖：实际代码执行由子代理完成，其质量取决于底层模型能力，可能出现理解偏差
3. 调试循环限制：最多3次自动调试循环，复杂问题可能仍需人工介入
4. 目录结构约束：强制要求 PRDs/PRPs 目录布局，对已有项目迁移不够友好
5. Git 依赖：需要系统安装 git，Windows 环境支持未明确

适合的目标群体

• 中小型开发团队：追求规范流程但不想引入重型项目管理工具
• AI 辅助开发实践者：希望系统化利用多代理协作提升代码质量
• 开源项目维护者：需要结构化的贡献者协作流程
• 技术负责人：需要可验证、可追溯的开发交付物
• 敏捷转型团队：在轻量与规范之间寻找平衡

使用风险

1. 子代理执行风险：虽然 FTW 本身无代码执行能力，但生成的 PRP 会被子代理执行，需审查 PRP 中的命令安全性
2. 上下文隔离边界：Orchestrator 与 Sub-agent 的上下文切换可能导致信息丢失，关键决策点需人工确认
3. 验证标准漂移：Validator 的判断标准可能因模型版本变化而不一致，建议在 WORKFLOW.md 中明确验收标准
4. 文件覆盖风险：自动化流程可能覆盖未提交的本地修改，建议配合 Git 工作流使用