最近读了一篇关于 Promptware Engineering 的论文，文章里提出一个很重要的观点：Prompt 不应该只是写给大模型的一段话，而应该像代码、接口、配置、测试用例一样，被当成正式的软件资产来管理。它也应该有需求、设计、实现、测试、版本管理、部署和监控。这个观点我非常认同。但我第一反应也很直接：开什么玩笑，很多团队平常连设计文档都不写，现在就开始谈提示词工程？这不是泼冷水，而是现实。现在很多技术概念都喜欢往前冲。今天 AI 原生，明天智能体，后天提示词工程。词一个比一个新，PPT 一页比一页漂亮，但落到研发现场，还是老问题：需求说不清，设计不落地，接口靠口头约定，数据库变更没人记录，测试用例靠经验补，出了问题再拉群排查。这样的团队，直接搞提示词工程，不是先进，是悬浮。一、别把提示词工程理解成“会写几句高级话”很多人一提提示词工程，脑子里想的是：让大模型扮演专家。给它几个示例。要求它一步一步思考。最后输出 JSON。这些当然有用，但这只是技巧，不是工程。真正的提示词工程，要回答的是更麻烦的问题：这个 Prompt 解决哪个业务问题？输入字段从哪里来？字段含义有没有歧义？输出结构谁来消费？异常时怎么降级？模型回答错了谁负责？Prompt 改了以后影响哪些代码？怎么测试？怎么回滚？怎么监控？这些问题如果回答不上来，就别急着叫工程。最多叫“调提示词”。调提示词就像以前调 SQL、调页面样式、调配置参数，有经验的人能调出效果。但工程不是靠手感活着的。工程要靠规范、流程、资产和复盘。二、平常文档都不写，AI 到底读什么？很多团队现在有一个误解：以为用了 AI，以前那些麻烦的研发流程就可以省了。需求不用写清楚，反正 AI 能理解。设计不用写清楚，反正 AI 能生成。测试不用准备，反正 AI 能补。代码不用解释，反正 AI 能读。这就有点自欺欺人了。AI 再强，也不是你们项目里的老员工。它不知道你们以前踩过什么坑，不知道哪个字段历史上被复用过，不知道哪个接口不能随便改，不知道哪个医院现场有特殊逻辑，不知道哪个数据库字段名字看起来正常其实含义早就变了。这些东西如果不写下来，就只存在于几个人脑子里。人还能靠开会、聊天、拍脑袋慢慢补上下文，A