Ppdd.bot
中EN

Prompt-Driven Development · 实践手册

把规矩写下来,
让 agent 照做

把需求、纪律和验收写成规则文件与 skill,agent 每次开工都读同一份,不靠你在对话里反复交代。这里有方法、文章和能直接拷走的模板。

CLAUDE.mdrepo / root
# 项目规则
> 只放必须遵守的纪律。
## 底线
- 未经明确授权:不合并 PR、不部署生产
## 分支与 PR
- PR 必须写「验证 / 风险 / 回滚」
- 按风险域拆分,各自单独成 PR
## 决定与待办
- 对外文案、计费:单列「待否决的决定」
- 待办写入 ledger,随代码提交
放进仓库,每次开工自动加载

提示词不是咒语,
是规格说明

Prompt-Driven Development(提示词驱动开发,PDD)把你对 agent 的要求写成规则文件、skill 和模板:做什么、不能做什么、怎样算做完。这些文件放进仓库,纳入版本管理,和代码一起评审。

它不是提示词技巧合集,也不替代测试、代码评审和人的判断;它的目标是,写代码的换成 agent 之后,这些环节照样管用。

同一件事,两种做法

维度随手写 promptPDD
规矩放在哪每次在对话里重新交代,换个会话就忘
写进仓库里的规则文件,每次开工自动加载
怎样算做完agent 说完成了,就算完成
先写失败测试;PR 写清验证、风险、回滚
要人拍板的事埋在改动说明里,上线后才发现
单列「待否决的决定」:选了什么、备选、怎么回退
遗留项回复末尾一句「以后再做」
写进待办账本(ledger),随代码提交,等人裁决

六条原则

本站所有文章和模板,都是从这六条展开的。

  1. 规则文件只放硬纪律

    规则文件每次都进上下文,只写必须遵守的条款;日常约定拆到 skill 和文档。

  2. 写清何时该用

    一件事一个 skill,描述里写明何时该调用。描述含糊,agent 就很难在对的时候用上它。

  3. 开工前核对五要素

    长任务先核对:仓库与分支、范围、待拍板的决定、底线、PR 粒度。没写明的按默认值走并说明。

  4. 决定要能被否决

    对外文案、计费、限制用户、删数据:agent 可先按推荐方案做,但须单列选择、备选与回退。

  5. 验收写成闸门

    先写失败测试再实现。PR 须有验证、风险、回滚三段,交给 CI 检查,缺段或只写占位符就拦下。

  6. 交接写给不在场的人

    待办写进 ledger,不留在回复里。收尾汇报先写结论和需要对方做的事,再写过程。

知识库

按主题组织的长文。每篇讲一个能落地的做法,附可以直接改的片段;还没写完的标「撰写中」。

  • 全部
  • 规则文件
  • Skill
  • 决策
  • 流程
  • 质量
  • 协作
  1. 01规则文件你的规则文件太长了:哪些该留,哪些该挪走把硬纪律和日常约定分开,让规则文件短到 agent 每次都能读完、读进去。撰写中
  2. 02Skill写好 skill 描述,让 agent 在该用的时候想起它agent 靠描述判断要不要调用 skill:写清适用场景、触发信号,以及什么时候不该用。撰写中
  3. 03决策「待否决的决定」:agent 先做,人来拍板哪些决定必须单列,清单怎么写,回退方案怎么写才能真的执行。撰写中
  4. 04流程长任务开工前,先核对五要素仓库与分支、范围、待拍板的决定、底线、PR 粒度,以及没人写明时用哪些默认值。撰写中
  5. 05质量让 CI 读 PR 描述:验证、风险、回滚缺一不可用一个小脚本拦下缺段和只写占位符的描述,并说明为什么推送前要先在本地跑一遍。撰写中
  6. 06质量长会话里的周期性评审清单定时让 agent 回看 diff,从正确性、安全、性能、一致性、可维护性五个角度逐项检查,按固定格式汇报。撰写中
  7. 07协作只写在回复里的待办,等于没有把遗留项写成文件随代码提交,裁决后归档,不删除。撰写中
  8. 08协作收尾汇报:写给没看过程的人先写结论和需要对方做的事,再写过程;编号、缩写和内部名词第一次出现时带一句解释。撰写中

模板

复制到仓库,把方括号里的内容换成你的。

一份规则文件长什么样

通用节选,方括号里换成你项目的值。

L1–3
开头一句话说清:只放纪律。

L9
底线写成「未经授权不做」,而不是「尽量小心」。

L17–18
人要拍板的事,单独列出来。

CLAUDE.mdmarkdown · 18 行
# 项目规则
> 只放必须遵守的纪律。日常约定写进 skill 或 docs。
## 开工前
- 长任务先核对仓库与分支、范围、待拍板的决定、底线、PR 粒度;没写明的按默认值走,并在第一句话里说明
## 底线
- 未经明确授权:不合并 PR、不部署生产、不写生产库
## 分支与 PR
- 分支从最新 main 切出,寿命不超过 [N] 天
- PR 描述必须包含「验证 / 风险 / 回滚」三段,只写占位符不算
- 按风险域拆分:改提示词、改计费、改数据结构各自单独成 PR
## 决定与待办
- 对外文案、计费、限制用户、删除数据:先按推荐方案做,单列「待否决的决定」
- 待办写入 [ledger 目录] 并随代码一起提交,只写在回复里不算

规划中

一句话需求,展开成结构化开发提示词

我们正在规划一个工具,尚未上线。设想是:输入一句需求,按本站的方法补齐范围、验收标准和待拍板的决定,输出一份能直接交给 agent 的提示词。