最近总有人问，prompt 里的非功能需求，写得细到底有没有用。
简单说，有人拿 ISO/IEC 25010 做了个对照实验。答案是：对代码质量有用，对功能正确性基本没用。
论文是8月中挂上 arXiv 的，两位巴西作者，被巴西的一个软件复用研讨会收了。我对“拿标准规范喂 LLM”这类题目兴趣一般。但这篇实验做得干净，收了。
实验长什么样
三种写法。一种是 RobuNFR 风格的单行基线，一句话带过。另外两种都基于 ISO/IEC 25010，一种写成丰富的自然语言，一种写成结构化 JSON。
考了四种需求：性能、错误处理、代码异味、可读性。跑在 HumanEval 和 HumanEval-ET 上。每种条件 10 种 prompt 变体，模型用固定快照，统计上用配对非参数检验。
这套设计我认可。10 种变体专门测“换个措辞结果会不会抖”。多数文章只跑一遍就下结论，这个强。
结果一：代码确实干净了
用 ISO 标准把需求写丰富之后，静态质量指标改善了。四种需求下，不可读性密度都降了。性能那个场景降得最明显，从 0.88 到 0.69。
补充一句，还有个我没想到的附带发现。富化描述让结果对措辞的敏感度降低了。你不用再为一个词的取舍反复试。对天天写 prompt 的人，这是实打实的好消息。
结果二：正确性没涨
这是最有意思的一条。代码更好读了，功能正确性没有可靠提升。
错误处理那一项更扎眼。扩展测试的通过率反而降了。作者的解释方向是，防御性编码模式和精确的输出基准之间有矛盾。模型按你要求加了防御，反而和测试期望的输出对不上。
这个坑我隐约踩过类似的味道。你让它“处理所有边界情况”，它真的处理了，然后你的测试挂了。当时我以为是模型笨。现在看，可能是需求本身就互相打架。
结果三：格式白折腾
这条我最想讲。ISO 内容固定的情况下，写成丰富的自然语言和写成结构化 JSON，正确率差异不超过 0.023。
白话版：模型在意的是你说了什么，不是你用什么格式说的。
论文自己也是这么建议的。力气花在基于标准的内容上，别纠结序列化格式。
这个现象挺普遍。圈子里总有人热衷设计精巧的 prompt 模板，JSON 套 YAML，层级越搞越深。这个实验至少在一个场景下说了：内容一样的话，格式白折腾。
当然它只测了非功能需求这一块，别拿去套所有场景。我自己还没在别的任务上验证过，先放在这里。
对普通人意味着什么
我收这篇的理由就一条。它把“prompt engineering 是不是玄学”这个老问题往前推了一格。
答案越来越像：不是玄学，是需求工程。把要什么讲清楚、讲完整、讲得有依据，比研究咒语句式有用。ISO 25010 本质上就是一份“需求清单的清单”，抄作业都不用自己发明。
留给普通人的具体动作：下次让 AI 写代码之前，别急着敲。先花五分钟想清楚，除了功能本身，你还要它快、稳、还是好读。把这几条用大白话写进 prompt，就已经是这个实验里“富化描述”的平民版了。
不需要去读 ISO 原文。那玩意 11 页论文都要引着用，普通人抄个思路就够。
一条没想透的
错误处理那项的下降，我只看懂了一半。防御性代码和测试基准的矛盾，到底是模型的问题还是测试集的问题，论文那段我读得含糊。先放在这里，想明白了再补。有懂行的愿意讲讲，欢迎。
本周就这些，下周见。