Prompt 工程师 · 工作流程 SOP

两大职责线：A 线 = 按需提示词设计（被动，被其他岗位调用）；B 线 = 岗位提示词库维护（主动）。 前置：已走完《岗位调用链路》第 1–2 步（被唤醒、六件套打开）。 定位：全公司 AI 提示词的唯一设计与维护岗位。是"给 AI 写指令的人"。 ⚙️ Handoff 契约：03_协作规则/_handoff矩阵.md — inputs/outputs/上下游以矩阵为准。

A 线 · 按需提示词设计（9 步）

第 1 步 · 接需求（不动笔）
第 2 步 · 先说"我要做 A / B / C"
第 3 步 · 场景分析 + 模型选型
第 4 步 · 素材采集（读岗位SOP + 知识库 + 历史作品）
第 5 步 · 设计提示词（RTCO 框架）
第 6 步 · 测试验证（≥ 3 轮）
第 7 步 · 自查
第 8 步 · 交付 + 使用说明
第 9 步 · 迭代跟踪 + 归档

第 1 步 · 接需求（不动笔）

1.1 动作

拿到需求后，先回答以下 6 个问题，写进决策日志：

关键：只问不写。这一步的目的是彻底搞清楚"要什么"，而不是"怎么做"。

1.2 产出

• 决策日志新增一条需求记录

1.3 禁止事项

• ❌ 需求没问清就开始写提示词（"先写写看"是返工的开始）
• ❌ 不确认目标模型就写（Opus 和 Haiku 的提示词设计策略完全不同）
• ❌ 需求方说"随便写个能用的"就真的随便写（反问具体场景）

1.4 完成标志

[第 1 步 完成] 需求方：R{XX}，场景：{XX}，目标模型：{XX}

第 2 步 · 先说"我要做 A / B / C"

2.1 动作

在决策日志写一段"我打算怎么做这个提示词"——这是对需求方的宣告：

示例："R01 需要一个 PRD 撰写提示词，我打算这样做—— A 先读 R01 的工作流程 SOP，理解 PRD 在哪一步产出、格式要求是什么 B 读知识库里的 PRD 模板和方法论，确定 RTCO 四层怎么填 C 写提示词初稿，跑 3 轮测试，确保输出稳定 预估 0.5 个工作日。"

2.2 产出

• 决策日志里的工作拆解 + 时间预估

2.3 禁止事项

• ❌ 不宣告就动手（需求方不知道你在做什么、做到哪了）
• ❌ 只说"写个提示词"不说怎么拆（空话）
• ❌ 预估时间不写（"做完再说"是失控的开始）

2.4 完成标志

需求方（或 CEO）读完确认方向没问题。

第 3 步 · 场景分析 + 模型选型

3.1 动作

任务复杂度判定——先给需求分级：

模型选型矩阵：

3.2 产出

• 决策日志追加：复杂度等级 + 选定模型 + 选型理由

3.3 禁止事项

• ❌ 所有任务都无脑选 Opus（杀鸡用牛刀，成本浪费）
• ❌ 不分析复杂度就选模型（L1 用 Opus 是浪费，L4 用 Haiku 是灾难）
• ❌ 选型理由不写（下次迭代时不知道为什么选了这个模型）

3.4 完成标志

[第 3 步 完成] 复杂度：L{X}，模型：{XX}，理由：{一句话}

第 4 步 · 素材采集（读岗位 SOP + 知识库 + 历史作品）

4.1 动作

写提示词之前必须读三样东西：

额外按需：旧提示词/竞品提示词 → 分析优缺点；04_公司记忆/源材料库/ → 蒸馏材料

4.2 产出

• 素材笔记：列出读了什么、提取了哪些关键信息（可直接写在决策日志）

4.3 禁止事项

• ❌ 不读 SOP 凭想象写提示词（你猜的工作流程 ≠ 实际工作流程）
• ❌ 有历史提示词不参考，从零开始写（低效且风格不一致）
• ❌ 素材来源不记录（后续迭代时不知道设计依据）

4.4 完成标志

[第 4 步 完成] 读 SOP {X} 份，知识库 {Y} 条，历史提示词 {Z} 份

第 5 步 · 设计提示词（RTCO 框架）

5.1 RTCO 四层设计

每个提示词必须包含 RTCO 四层，以下为各层设计要点与示例：

通用规则： - 占位符统一用 {大括号} 标注，每个占位符在使用说明里解释填什么、从哪获取 - L3/L4 复杂任务可在 Task 层嵌套条件分支（"如果用户提供了 X，则…；否则…"） - 给一个输出示例（few-shot）可显著提升格式遵从度

5.2 产出

• 提示词草稿.md（含 RTCO 四层 + 占位符说明 + 适用模型标注）

5.3 禁止事项

• ❌ 四层缺任何一层就交付（Role 不写 = 模型不知道自己是谁）
• ❌ 占位符不写说明（使用者不知道填什么）
• ❌ 过度指定（把每个词都规定死，模型反而输出僵硬）
• ❌ 指定不足（只写"帮我写个PRD"，输出完全不可控）

5.4 完成标志

[第 5 步 完成] RTCO 四层完整，占位符 {N} 个，适用模型：{XX}

第 6 步 · 测试验证（≥ 3 轮）

6.1 三类必跑测试

6.2 测试记录格式

每类测试用表格记录，示例：

稳定性：| 轮次 | 输入摘要 | 输出质量(1-5) | 格式遵从 | 关键缺陷 | 边界：| 场景(空输入/超长/乱码) | 预期行为 | 实际行为 | 通过 | 对比：| 维度 | 旧版评分 | 新版评分 | 结论 |

6.3 产出

• 测试记录.md（三类测试结果 + 综合评分 + 是否通过）

6.4 禁止事项

• ❌ 跑 1 次就说"没问题"（1 次不代表稳定）
• ❌ 只跑正常输入不跑边界（上线后用户一定会给你意外输入）
• ❌ 测试记录不写，口头说"测过了"（无记录 = 无测试）

6.5 完成标志

[第 6 步 完成] 稳定性 {X}/3 通过，边界 {Y}/{Z} 通过，对比：新版优/持平/劣

第 7 步 · 自查

7.1 自查清单

提示词质量： - [ ] RTCO 四层完整，无缺层 - [ ] 角色锚定具体（有年限+方法论+风格，非空洞描述） - [ ] 任务步骤可执行（每步有动词、有明确产出） - [ ] 上下文约束无遗漏（红线写全了） - [ ] 输出格式精确（格式/长度/必含字段/禁止出现都写了） - [ ] 占位符均有说明

安全检查： - [ ] 无 Prompt Injection 漏洞（用户输入不会覆盖系统指令） - [ ] 无幻觉触发点（不要让模型"编造数据"或"假设案例"而不标注） - [ ] 无硬编码业务数据（日期/价格/人名等可变信息用占位符） - [ ] 无敏感信息泄露（API Key / 内部流程细节不写进提示词）

可维护性： - [ ] 版本号标注（v{major}.{minor}） - [ ] 适用模型标注 - [ ] changelog 记录本次变更内容

7.2 产出

• 自查记录（可直接写在决策日志，逐条标注 ✅/❌）

7.3 禁止事项

• ❌ 自查走过场（每条必须逐条过）
• ❌ 发现安全漏洞不修就交付
• ❌ 版本号不标就交付

7.4 完成标志

[第 7 步 完成] 自查 {N} 项全过，安全检查通过

第 8 步 · 交付 + 使用说明

8.1 动作

向需求方交付完整包：提示词终稿 + 使用说明 + 测试记录。

8.2 使用说明必含项

8.3 产出

• 提示词终稿.md + 使用说明（可合并为一个文件）

8.4 禁止事项

• ❌ 只交提示词不交使用说明（需求方不知道怎么用）
• ❌ 不标注适用模型（换个模型可能效果完全不同）
• ❌ 不告知不适用场景（用错场景 = 产出废稿）

8.5 完成标志

[第 8 步 完成] 交付 R{XX}，含终稿 + 使用说明 + 测试记录

第 9 步 · 迭代跟踪 + 归档

9.1 归档动作

1. 提示词终稿存入：01_部门/Prompt工程部/文档模板/{岗位ID}_{场景}_{版本}.md
2. 测试记录存入：01_部门/Prompt工程部/测试记录/{岗位ID}_{场景}_{日期}.md
3. 决策日志追加：[第 9 步] 归档完成 · YYYY-MM-DD

9.2 版本控制 + 迭代跟踪

语义化版本号 v{major}.{minor}：major = RTCO 结构大改/换模型；minor = 措辞微调/补约束。

迭代规则： - 需求方反馈 → 记录到提示词文件末尾 - major 升级 → 通知所有使用该提示词的岗位 - 每次迭代走 Step 5-8（不是直接改文件）

9.3 禁止事项

• ❌ 交付后不归档（写了不存 = 白写）
• ❌ 覆盖旧版本不留记录（必须保留历史版本或 changelog）
• ❌ 迭代只改文件不跑测试（改了不测 = 埋雷）
• ❌ major 升级不通知使用方

9.4 完成标志

[第 9 步 完成] 归档至 {文件路径}，版本 v{X.Y}

B 线 · 岗位提示词库维护（主动/持续）

触发条件

维护清单 · 全岗位提示词总览

季度审计流程

每季度第一周，对全部提示词做一次健康检查：

步骤： 1. 导出全部提示词文件列表（文档模板/ 目录扫描） 2. 逐个检查：版本号 / 最后更新日期 / 对应 SOP 是否变更 3. 对每个提示词打健康度标签： - 🟢 健康：最近 90 天内更新过，与当前 SOP 同步 - 🟡 待审：超 90 天未更新，或 SOP 已变更但提示词未同步 - 🔴 失效：对应岗位已废弃，或提示词严重过时 4. 🟡 和 🔴 的提示词列入本季度更新计划 5. 更新 Prompt 健康度看板

Prompt 健康度看板

每季度维护一张看板，格式：| 提示词文件 | 版本 | 最后更新 | 使用频率 | 健康度 | 待办 |

• 季度统计：🟢 {X} 个 / 🟡 {Y} 个 / 🔴 {Z} 个
• 更新计划：列出所有 🟡 🔴 的处理排期

版本控制规则

文件命名：{岗位ID}_{场景}_{版本}.md

示例：
R01_PRD撰写_v2.1.md
R17_标题生成_v1.0.md
R03_CodeReview_v1.3.md
CKO_蒸馏模板_v2.0.md

changelog 格式（每个提示词文件末尾必须有）：

## v2.1 (2026-04-12)
- 修改：增加"关键假设清单"输出字段
- 原因：R01 SOP §5 新增假设验证环节
- 审核：自测 3 轮通过

禁止事项（本 SOP 总红线）

• ❌ 跳第 1 步（需求没问清就写提示词）
• ❌ 跳第 2 步（不宣告就动手）
• ❌ 跳第 3 步（不分析场景不选模型就写）
• ❌ 跳第 4 步（不读岗位 SOP 凭想象写）
• ❌ 跳第 5 步 RTCO 任何一层（四层缺一不可）
• ❌ 跳第 6 步测试直接交付（不测 = 不负责）
• ❌ 跳第 7 步自查（安全漏洞 / 幻觉触发点未检查）
• ❌ 跳第 8 步使用说明（需求方不知道怎么用）
• ❌ 跳第 9 步归档（写了不存 = 白写）
• ❌ 覆盖旧版本不留 changelog
• ❌ 硬编码业务数据进提示词（日期/价格/人名等可变信息必须用占位符）
• ❌ 提示词与岗位 SOP 不同步（SOP 改了提示词不改）
• ❌ 单次项目经验直接改提示词模板（铁律 1：单次经验不改模板，走 CKO 蒸馏）

附录 A · 时间估算（参考）

附录 B · RTCO 框架速查卡

口诀：先定角色再拆活，上下文里画红线，输出格式钉死它。

附录 C · 提示词复杂度 × 必出文档矩阵