Prompt 工程师实测：把模糊需求炼成可靠 AI 行为的工种

角色定位：它是什么

Prompt 工程师是 agency-agents-zh 项目里一个工程部角色，核心任务是把含糊的产品需求翻译成 LLM 能稳定执行的精确规格。与 backend-architect 关注服务拓扑、ai-engineer 侧重模型训练不同，这位角色专攻「人与模型之间的接口层」——prompt 本身的设计、验证与持续维护。他的设定很直白：把每一条 prompt 当科学假设，用实验精神迭代，用版本管理兜底。

能力边界实测

角色交付物包含四类硬资产：System Prompt 模板、Prompt 测试套件、变更日志格式、Few-Shot 构造器。模板强制采用 Role → Constraints → Reasoning → Examples 结构，杜绝「要有帮助」这类模糊修饰；测试套件要求 pytest 参数化覆盖正常路径、边界、失败模式各至少一例；变更日志必须记录改动与实测影响，而非单纯的功能描述。

我们的体验是，这套方法论对生产环境 prompt 的漂移问题有针对性。角色设定中反复强调「用实际会用的模型和 temperature 测试」，正是因为 GPT-4 与 Claude 3.5 对同一 prompt 的响应方差可能极大。他也明确标记自身局限：绝不假设模型具备未提供的知识，必须靠上下文或示例打底。

上手体验

四阶段工作流是角色的骨架：需求翻译 → 初稿 → 迭代 → 生产交接。需求阶段强制追问输出格式、三类常见输入、拒绝场景，落笔前必须先写 prompt_spec.md——这个纪律能挡住大量后期返工。迭代阶段的核心规则是「一次只修一个问题」，同时改多处会让因果判断失焦；冻结门槛是连续三轮全量测试通过。

实际使用中，这个流程对中小团队略重。如果你的 prompt 只有两三行、调用量不高，完整 pytest 回归可能显得过度。但一旦 prompt 进入产品核心链路——比如客服分类器、代码审查入口——这套工程化手段的价值会快速显现。

适合谁用

三类人最直接受益：一是要把 LLM 输出稳定性从「大概对」提升到「可上线」的 AI 工程师；二是需要为多款模型（GPT、Claude、Gemini、Mistral 及开源模型）维护同一套业务逻辑的跨平台团队；三是想建立 prompt 资产可复用、可审计的中台型组织。个人玩票或原型验证阶段，角色的完整流程可以裁剪使用，但其约束定义和版本管理思想仍值得吸收。

同类角色怎么选

与清单内其他工程角色对比，分工差异清晰：

• Drupal 购物车工程师：纯后端领域专家，解决电商系统的支付、订单、促销逻辑，与 LLM 无交集。
• IT 服务经理：流程治理角色，聚焦 ITIL 框架下的 incident、problem、change 管理，不触碰模型行为设计。
• 多智能体系统架构师：关注 multi-agent 拓扑、智能体间协调与故障恢复，Prompt 工程师则是单点接口的精密打磨者——一个管系统架构，一个管单条指令的确定性。
• OrgScript 工程师：专精特定 DSL（OrgScript）的语法与 AST，Prompt 工程师面对的是自然语言的开放性歧义，而非形式化语言的解析问题。

若你的场景是多 agent 编排，选多智能体系统架构师；若只是让单个 LLM 调用更可靠，Prompt 工程师更对位。

使用建议

角色兼容工具列表极长，从 OpenClaw、Claude Code 到 Cursor、Windsurf、Codex CLI 等 16 款工具均可承载。建议优先在支持版本管理、CI 集成的环境中落地——比如把 prompt 文件纳入 Git，用 pytest 或类似框架跑回归。角色设定中的「已知局限」文档要求尤其值得执行：对失败模式坦诚，比过度承诺更能保护下游团队。最后，不要跳过「手动跑 10 个测试用例」的初稿环节，自动化再完善，也替代不了人对「意外输出」的直觉判断。