---
name: prompt-programming
description: 当用户明确要求“把 prompt 改写成伪代码”“将提示词翻译成可编程自然语言”“输出具有程序结构的人类语言指令”或直接提到 prompt-programming 时使用。将用户原始 prompt 翻译为一种简洁、严谨、可组合的 Prompt Program 方言：形式上像假代码，语义上仍是人类自然语言。
metadata:
  author: Bensz Conan
  short-description: 把任意 prompt 编译成具有程序结构的人类自然语言
  keywords:
    - prompt-programming
    - programmable natural language
    - pseudo code prompt
    - prompt compiler
    - 提示词编程
    - 假代码
---

# Prompt Programming

## BenszAPI 任务工作区

本 Skill 的新任务中间文件统一写入 `./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/`。同一任务复用一个任务根目录；多 Skill 协作才创建 `shared/`。正式交付物不写入该目录，历史隐藏目录只允许显式兼容读取、迁移或清理。

## 与 bensz-collect-bugs 的协作约定

- 因本 skill 设计缺陷导致的 bug，先用 `bensz-collect-bugs` 规范记录到 `~/.bensz-skills/bugs/`，不要直接修改用户本地已安装的 skill 源码；若有 workaround，先记 bug，再继续完成任务。
- 只有用户明确要求“report bensz skills bugs”等公开上报时，才用本地 `gh` 上传新增 bug 到 `huangwb8/bensz-bugs`；不要 pull / clone 整个仓库。

把原始 prompt 编译成 Prompt Program：像程序，但仍是自然语言。目标是把输入、输出、约束、流程、分支和校验整理成可维护、可评审的假代码。

## 核心模型

- 单一真相来源是 `config.yaml`。
- 底层只使用 `config.yaml:kernel.semantic_atoms` 定义的 6 个原子：
  - `Entity`：对象、角色、输入、输出、工具、状态
  - `Intent`：目标、交付物、成功条件
  - `Operation`：分析、生成、转换、比较、总结、规划
  - `Constraint`：必须、禁止、偏好、格式、长度、风格
  - `Control`：条件、分支、循环、顺序、回退、优先级
  - `Check`：自检、验收、异常处理、结束条件
- 不新增原子；复杂任务靠组合表达。
- 详细定义与块映射见 `references/primitives.md`。

## 渲染方言

- 块顺序、必需块、可选块、块语义与句式模板，以 `config.yaml:rendering.*` 为准。
- 必守规则：
  - `输出` 只定义目标产物、目标格式或目标效果。
  - `返回` 只定义对 `输出` 的交付动作，不能引入新产物。
  - `程序`、`定义`、`缺口处理` 属于可选块；为空就省略。
  - 若 `config.yaml:rendering.omit_empty_blocks=true`，禁止为了“看起来完整”补空块。

## 工作流

### 输入验证

先按 `config.yaml:translation.input_validation` 检查输入：

- 空输入：拒绝翻译，并要求提供原始 prompt。
- 过短输入：说明信息不足，不输出伪完整结构。
- 非 prompt 型输入：说明本 skill 不适用。

### 理解原始 prompt

恢复以下信息：

- 真实目标与交付物
- 输入对象与隐含上下文
- 输出契约与验收口径
- 强约束与软偏好
- 控制逻辑：条件、分支、迭代、失败回退

### 映射为 6 个原子

- `Entity`：关键对象是什么
- `Intent`：最终要得到什么
- `Operation`：核心动作链是什么
- `Constraint`：哪些条件不能丢
- `Control`：是否存在 if / for each / until / fallback
- `Check`：如何判断结果合格

若原 prompt 混乱，先重建逻辑，再翻译；不要保留混乱结构。若没有显式控制逻辑，只能在“显式或强隐含”时补出最小控制结构，不凭空发明分支或循环。

### 组织为 Prompt Program

- 默认按 `config.yaml:rendering.block_order` 输出。
- 组织顺序：
  - 先边界，后执行
  - 先主流程，后异常路径
  - 先硬约束，后风格偏好
- 若用户原 prompt 缺少显式校验，必须补出最小可执行校验。
- 若存在显式格式契约，必须保留到 `输出` 或 `约束`。
- 若用户指定字段、章节或步骤顺序，默认按原顺序保留。
- 若存在关键术语、变量名或实体名，默认保留原词，不擅自改名。

冲突时严格遵循 `config.yaml:translation.conflict_resolution_order`：

1. 核心意图
2. 硬约束
3. 输出契约
4. 校验要求
5. 风格偏好

### 压缩表达

- 保留逻辑，不保留冗余修辞。
- 保留可执行约束，不保留客套表达。
- 能通过结构表达的，不重复解释。
- 句子预算以 `config.yaml:quality_bar.soft_sentence_budget` 为软上限；复杂任务可放宽，但不能丢逻辑。

### 最小自检

输出前确认：

- 仍然等价于原 prompt 的真实意图
- 具备清晰的输入、输出、流程和校验
- 关键分支与缺口处理已显式表达
- 足够像“程序”，但仍是自然语言

## 输出

- 默认只输出最终 Prompt Program，不附带长篇分析。
- 推荐格式可按 `config.yaml:rendering.block_order` 省略空块：

```text
程序：……

目标：……
输入：……
输出：……

定义：
- ……

约束：
- 必须……
- 优先……
- 不要……

流程：
1. ……
2. 若……，则……；否则……。
3. 对每个……，执行……。

校验：
- ……

缺口处理：
- 若信息不足，则……

返回：
- ……
```

## 适用与不适用

适用：

- 把普通 prompt 变成研究论文式假代码
- 把散乱任务说明重构成统一结构
- 把长 prompt 压缩成可组合、可讨论、可评审的逻辑骨架

不适用：

- 用户只想润色语气，不想改变表达结构
- 用户只想执行任务，不关心 prompt 的架构
- 原始输入不是 prompt，而是完整代码实现请求

## 额外规则

### 歧义处理

- 可用常识低风险补足时，直接补足并体现在结构中。
- 缺失信息会改变任务本质时，在 `缺口处理` 中显式标注，不擅自虚构。
- 默认不要频繁追问；只有任务语义无法成立时才要求澄清。

### 风格处理

- 默认保持冷静、简洁、结构化。
- 不输出“你应该”“建议你”等评注性口吻，除非原 prompt 本身包含它们。
- 允许保留领域词汇，但要消除口语化噪音。

### 等价性原则

- 允许重排表达，不允许改变目标。
- 允许补出隐式流程，不允许新增无依据能力。
- 允许强化校验，不允许削弱关键约束。
- 允许压缩表述，不允许丢失显式格式契约。
- 允许补足交付动作，不允许把“输出”偷换成“输出说明书”。

## 质量标准

合格的 Prompt Program 必须满足：

- **等价**：核心意图不丢失
- **可执行**：读者可按结构直接执行
- **可编程**：能看见输入、约束、流程、分支、校验
- **可扩展**：后续要求能继续挂到对应块
- **可审阅**：他人能快速指出逻辑缺口或冗余

## 参考资料

- `references/primitives.md`：6 个原子、块语义与省略规则
- `references/examples.md`：典型翻译示例
- `references/translation-rules.md`：输入验证、保真与冲突规则