1 我们正处在软件开发的分水岭
AI Coding如火如荼的迅速获得到广大程序员的偏爱，虽然有些程序员偶尔会意识到这不是对自己的替代么，但仍忍不住疯狂的迷上AI Coding。狂热起来，像不像飞蛾扑火（程序员制造的AI Coding会不会让程序员失业呢）？
AI Coding对整个行业的冲击无疑是划时代的，但是评估他的整个影响，还很难说，我们只能看到他得巨大的动能，但是冲击之后是什么样子，大部分我们只能一边看，一边学习和接受。 就像汽车代替马车，旧的行业逐渐淡出，新的行业兴起，车夫失业了，司机的需求出现了。
这里我们先不对整体的冲击做预测，过于宏达也过于虚幻了。 我们先聚焦到SRS软件需求规格说明这一点上，来看需求分析师(或系统架构，产品经理等），如何应对这场变革，还需不需要写SRS、PRD（红旗还能打多久）？！
2 提示词工程，AI时代的新外语
以前我们学技术、查资料，学习英语很重要。 现在跟AI的沟通协作过程中，人们很快发现，不同的沟通方式差异很大。因此出现了一个新兴的专业领域叫提示词工程(prompt engineering)，这里(https://www.promptingguide.ai/)汇集里提示词工程的概念、技术、工具、以及论文等。深入研究的可以看看。 这里(http://sxo.cc/analysis/prompt-engineering)有中文的简单扼要的介绍。
根据斯坦福2023年的研究数据，使用提示词工程和AI沟通，质量能提升73%，而如果不使用的话，则AI的潜力只能发挥30%左右。
当然对于日常的简单对话，提示词工程并无特殊明显的效果，因为通常上下文都很短。一旦需要AI完成比较严肃的任务型的工作，那么上下文立刻就成为决定AI生成质量的关键因素。尤其是在编程任务中，AI需要对整体有足够的了解，才能够精准的进行编程，否则就会有大量的误解、无关的蔓延、错误的引用产生。 这就对上下文的大小提出来强大的挑战。
研究人员首次真正意识到上下文的重要性，是2018年，Eric Zelikman（斯坦福大学）发表了论文“上下文就是一切”: Context is Everything: Finding Meaning Statistically in Semantic Spaces（2018 年 3 月，2025 年 9 月更新至 v4）, 有兴趣的话链接如下：https://arxiv.org/pdf/1803.08493v4 。
基于对上下文的扩展和应用，一些研发人员甚至提出了RAG已经过时的观点。认为上下文就可以解决所有的问题，并且更精炼更准确。
似乎我们只需要从底层不停地扩充上下文，堆叠硬件算力就可以简单的解决模型幻觉，误解等问题。
但是显然大家低估了对AI的需求，尤其随着AI编程等等重型任务越来越多，上下文腐烂基本随时可见，新的研究更发现上下文的严重不足。不仅简单的扩张上下文不能解决问题，而且过大的上下文(long context)，反而更容易引起模型的噪声、错误。性能反而显著的下降。 相关研究论文见这里:Lost in the Middle: How Language Models Use Long Contexts（2023 年 7 月）,链接是：https://arxiv.org/abs/2307.03172
所以基本上，我们没法简单的依赖扩充上下文来实现对AI的无障碍协作，将来也不行。 大部分情况下， 学习如何跟AI对话(提示词工程）仍是非常有用的。
3 提示词需求文档(Prompt Requirement Document)
在氛围编程(vibe coding)描绘的场景下，你只需要给出一句话，AI就能完成编程工作。并且现在的AI能力就已经很接近vibe coding的场景了。编程都能完成，那测试用例岂不是更加小菜？ 自动测试更无需多言。 至于产品手册，操作说明，部署文档，发行注释，对AI来说更是顺手拈来。
似乎整个软件工程的环节都无需人工了。。。。。。
但是，等等。 你是不是得给一句话，AI才能开始干活。 总归这句话省不了吧。 AI干的活好不好，不全依赖这句话么？
为此，一些研发人员再和AI编程的协作过程中，尝试借助提示词工程的能力，并更进一步，升级成 提示词需求文档 1! 见这里(https://medium.com/@takafumi.endo/prompt-requirements-document-prd-a-new-concept-for-the-vibe-coding-era-0fb7bf339400)
为了让AI编程更好的理解需求，从而生成准确的代码。 精准的描述需求的文档，SRS,SRD,PRD等规格说明显然仍是必不可少的。 但是在研发人员的实践中，将需求规格文档扔给AI，效果并不好。不仅仅是上下文超长的问题，长的上下文导致的注意力飘忽也很严重。毕竟，大模型的起源就是注意力机制，见论文：（Attention Is All You Need），链接：https://arxiv.org/abs/1706.03762 。上下文太长你让他注意哪儿呢。
于是一些研发人员开始研究哪些文档更方便AI的理解和使用。于是就有了提示词需求文档(Prompt Requirement Document)PRD。
虽然不言自喻，传统的需求文档都是给人看的。 但需要喂给AI时，大家就得反思AI需要的是什么，不需要的是什么了。 因此对于新的提示词需求文档PRD， 其设定的目标就是人和AI的公共文档。
这里涉及到另一个数据管理方面的术语SSOT:唯一真相来源或单一事实来源。
SRS对于人类来说，已经算是要求极高的规格化的文档了。但是从AI的角度来看，仍充满了信息冗余（人类习惯用重复以加强印象），以及缺失大家认同的事实（团队内有默契的表述）。 因此要和AI共同使用，需要从SSOT的角度重新梳理需求规格。
SSOT强调唯一性、权威性、准确性。要求所有其他的数据都由SSOT而来，或者引用SSOT。 这对于AI来说刚好是恰逢其好。
说到这里，我解释下为什么仍然需要需求文档，而不是给AI一句话就行了。 事实上，我认为 氛围编程(vibe coding) 是个非常错误的概念，虽然是大佬提出来的。 因为你要是真的一句话，AI就给你写好了所有的代码，生成了所有的文档，手册，部署脚本，测试用例，产品相关的一切。 那么不论这些代码，程序，文档，脚本如何的丰富，如何的强大， 他实质上的信息量，就是原始的那一句话。
举个极端的例子，我一句话生成了一张光盘内容的管理系统。 当我需要到另一个很远或很严格无法携带很多数据的地方去的时候。我需要压缩信息量，那么整个光盘内容都是可以删掉的，我只需要带原始的那一句话就行。 到了地儿，我就凭这句话重新生成一遍就行了。信息熵就这么多。
这个不仅和从源码编译出程序的概念一样，甚至操作也都类似。 有原始的内容，就可以生成最终的内容。那么原始的内容才是最重要最核心的。生成的都是临时，可以重复的。
但除了简单明了的工具类应用，可以一句话说清楚外。任何复杂的系统，他必然是无法再一句话的信息量里涵盖所有的细节的。 因此用一句话去生成，必然会导致错乱混淆的结果。
氛围编程，用一种美好的幻想误导了大部分的人。 并且最重要的是，他误导了很多的技术圈外的人，让人觉得真的可以人人都可以用AI来编码，从此不需要程序员了，这是一种很糟糕的幻想，并最终会由很多人得盲目且反复的试错而告终。
那么我们如何用SSOT来构建提示词需求文档PRD呢？ 一些已知的有效实践如下：
3.1 首先是提示词需求文档PRD的三原则：指南、指导和守卫 (guideline,guidance,guardrails)
- 指南：共享 AI 与人类的理解： 一个全面的知识库，用于建立项目背景、技术原理和架构决策。该基础确保 AI 助手和人类团队成员基于相同的理解开展工作，从而在方法和方向上保持一致——类似于传统的 PRD 如何围绕产品需求协调利益相关者 2。
- 指导：演进提示的方法论。 这是一种结构化方法，旨在帮助开发人员将抽象概念演进为 AI 系统能够准确解读和执行的精确指令。该系统包含带注释的提示示例、模式库、情境最佳实践和常见陷阱 3警告，即使是 AI 协作新手也能创建有效的提示，并生成一致、高质量的结果。
- 护栏：AI 辅助代码审查。 一套明确的自动化评估标准和质量检查点，专门用于解决已知的项目风险和反复出现的痛点。这些护栏使 AI 系统能够对拉取请求进行初步代码审查，在人工审查开始之前识别出基本问题。这种系统化的方法减轻了人工审查人员的认知负担，使他们能够专注于更复杂的架构问题，同时确保代码质量标准的一致性执行。
4 格式与内容
在研究人员的一些尝试中，发现对于AI来说，md的表格形式是最有效的结构化形式。 使用人类的描述语言给AI描述需求，显然是过于冗余且难以保证精确的。因此研发人员很早就尝试各种格式化的数据，用于和AI沟通。
在尝试过多种结构化数据后，如json,yaml等等。研究人员发现以竖线分割的属性字段，类似md的表格形式，对AI来说效果最好。既能精准的描述数据内容，又非常的简约，节省上下文。
一个建议的提示词需求文档的工作流程如下：
- 初始设置 定义基本规则和项目概述。
- 需求设计 与人工智能协作明确功能。
- 细化指令 将这些功能转化为机器友好的提示（如特殊的“魔术提示”）。
- 实施 与AI共同创建代码并进行验证。
- 重构 提高质量并保持一致性。
- PRD 更新 将经验教训 4和新信息整合回 PRD。
5 提示词需求文档的不足之处
作为一个刚提出来的设想概念，提示词需求文档强调了人类和AI共享的同一份单一事实来源，保证了和AI的协作效率。 但是SSOT并没有完备性上的约束，因此需求规格是否完备，仍依赖于分析师的经验水准。
另外一点可以理解的是，作为一个新兴的概念，还并没有事实上的标准支撑，因此大家也是各自以自己的方式在尝试。