开什么玩笑，平常文档都不写，现在搞提示词工程

最近读了一篇关于 Promptware Engineering 的论文，文章里提出一个很重要的观点：Prompt 不应该只是写给大模型的一段话，而应该像代码、接口、配置、测试用例一样，被当成正式的软件资产来管理。它也应该有需求、设计、实现、测试、版本管理、部署和监控。

这个观点我非常认同。

但我第一反应也很直接：

开什么玩笑，很多团队平常连设计文档都不写，现在就开始谈提示词工程？

这不是泼冷水，而是现实。

现在很多技术概念都喜欢往前冲。今天 AI 原生，明天智能体，后天提示词工程。词一个比一个新，PPT 一页比一页漂亮，但落到研发现场，还是老问题：需求说不清，设计不落地，接口靠口头约定，数据库变更没人记录，测试用例靠经验补，出了问题再拉群排查。

这样的团队，直接搞提示词工程，不是先进，是悬浮。

一、别把提示词工程理解成“会写几句高级话”

很多人一提提示词工程，脑子里想的是：

让大模型扮演专家。
给它几个示例。
要求它一步一步思考。
最后输出 JSON。

这些当然有用，但这只是技巧，不是工程。

真正的提示词工程，要回答的是更麻烦的问题：

这个 Prompt 解决哪个业务问题？
输入字段从哪里来？
字段含义有没有歧义？
输出结构谁来消费？
异常时怎么降级？
模型回答错了谁负责？
Prompt 改了以后影响哪些代码？
怎么测试？怎么回滚？怎么监控？

这些问题如果回答不上来，就别急着叫工程。

最多叫“调提示词”。

调提示词就像以前调 SQL、调页面样式、调配置参数，有经验的人能调出效果。但工程不是靠手感活着的。工程要靠规范、流程、资产和复盘。

二、平常文档都不写，AI 到底读什么？

很多团队现在有一个误解：以为用了 AI，以前那些麻烦的研发流程就可以省了。

需求不用写清楚，反正 AI 能理解。
设计不用写清楚，反正 AI 能生成。
测试不用准备，反正 AI 能补。
代码不用解释，反正 AI 能读。

这就有点自欺欺人了。

AI 再强，也不是你们项目里的老员工。它不知道你们以前踩过什么坑，不知道哪个字段历史上被复用过，不知道哪个接口不能随便改，不知道哪个医院现场有特殊逻辑，不知道哪个数据库字段名字看起来正常其实含义早就变了。

这些东西如果不写下来，就只存在于几个人脑子里。

人还能靠开会、聊天、拍脑袋慢慢补上下文，A