AI 研发管理 · Local-first
章法（PlayBook）是一套开源的 AI 研发管理系统。你用带检查表的提示词定义研发的每一步和完成标准， 任何厂商的 AI 按步骤领活、交作业、过检查——过程可验收、进度可追溯，需求、版本和发布只记一处、只走一个口。
Why PlayBook
用 AI 做了一段时间项目之后，我发现瓶颈不在「写得快不快」，而在「管不管得住」：
AI 生成的文档、代码、草稿越堆越多，有用的和过期的混在一起。项目越往后，越说不清哪些是事实、哪些是垃圾。
项目一多，「这个做到哪了、现在是哪个版本、上次停在哪一步」全靠脑子记。隔几天再打开，就得从头翻一遍。
每开一个新对话，都要把规范重新交代一遍。AI 怎么做、做成什么样，全看这一次发挥——质量全凭运气。
后来想清楚的一件事
问题不在 AI 的能力，而在没有人给 AI 立规矩：每一步做什么、做完的标准是什么、状态记在哪里，都应该在开工前定义好。 章法就是按这个思路做的——先把 AI 研发的流程定义成系统能执行的规矩，再让任何厂商的 AI 照着干活、由系统负责记账。 这套规矩落地，就是下面的「三层交付」。
Three Layers
每层独立可用、逐层增强：先有规矩，再有守规矩的系统，最后是可随时重建的脸。
默认流程定义 + 提示词资产库。每份提示词必须带检查表才能「上岗」——没有内容，系统只是空壳；有了它，任何 AI 都知道该怎么干活。
管账和管结构：照流程定义生成工作区、状态变更先校验后记账、发布一键收口、账目异常能亮牌——规范不再只是一叠文档。
看板和版本列表，是账本的视图。它随时可以从账本整体重建——删掉重来，不丢失任何项目事实。
01 · 流程是数据
步骤、依赖、完成标准都是可修改的定义，而不是刻在文件夹里的死规矩。版本开工时对流程拍快照：改流程不影响进行中的版本，新开的版本自动用新流程——好方法随认知进化，而不是被第一天锁死。
02 · 执行与分工
任何厂商的 AI 注册即可进车间，和人遵守同一套规则：领任务时提示词和上游材料自动配齐，交作业自动过检查表，不符合就打回返工。多个 AI 并行干活互不冲突——你从调度员变回决策者。
03 · 需求与版本
进度账只记一处、只走一个口，每次变更先校验后记账。需求池三态一目了然；把一批需求打包成版本，开版本自动生成工作区和任务链；发布一键收口——归档、需求完成、发布记录、清理一次完成。
04 · 文档链与交接沉淀
概念、PRD、技术文档、开发规范、UI、模块设计、产品路线图按文档链逐步推进：AI 辅助起草、人确认定稿，每步产出随流程自动沉淀。原型验证通过时，需求文档、验收记录和交接包已经在手里——交接不再从零开始。
Quick Start
从填写项目基础信息到生成 Markdown 底座：选启动方式、定流程方案、确认后初始化执行—— 目录结构、状态台账、流程方案和提示词库一次就位，全程约 1~2 分钟。
Current Status
章法正在用它自己的流程开发自己：概念、PRD、技术文档与模块设计已就位，首发版本面向「产品经理的高保真原型试验」场景。在第一个可用版本打磨完成前，先把话说在前面：
它不是什么
不是 AI 编码工具——自己不写代码，干活的是你选的任何 AI；不是「一句话生成应用」的碰运气工具——做按规范、可验收、可沉淀的快；也不是禅道、Jira 类管理软件的替代品——不做工时、排期图和权限审批。
Get Started
章法将以 MIT 协议开源，源码与安装包统一通过 GitHub 仓库提供。仓库已创建——可以先 Star / Watch 关注，发布后第一时间获取；所有事实记在本地文件里，谁都能读、能带走、不锁定。
1
关注 GitHub 仓库
Star / Watch，开源发布时第一时间收到通知
2
下载或自行构建
从 Releases 获取安装包，或从源码自行构建
3
本地运行，定你的规矩
本地文件车间，数据都在你自己的设备上
形态与平台
