软件分析与设计笔记 17：用生成式 AI 做设计与开发：能用的场景与要防的坑

这是我在学习软件分析与设计时整理的系列笔记。概念部分是我按自己的理解写的，示例与图示都是自己编、自己画的。理解有偏差的地方欢迎指出。

贯穿案例：片区家电维修派单系统。这一篇讲怎么把生成式 AI 用在这个项目的具体环节上 —— 以及在哪些环节绝不能用。

0 从「帮我写个函数」说起

很多人用生成式 AI（generative AI）的第一个场景是补全代码。用久了会发现一个规律：它在「有明确目标、缺具体实现」的地方非常好用；在「目标本身还没想清」的地方基本帮不上忙，甚至会帮倒忙。

这个规律在本例里可以验证。如果你问它「帮我设计一个家电维修派单系统」，它会给你一份听起来很专业的方案 —— 但那份方案和你真正的问题（小林不知道谁有空、老陈白跑、王姐手工汇总）没有任何关系。因为它在猜「一个派单系统通常长什么样」，而不是在理解你的业务。

原因不难理解：它的工作方式是根据上下文（context）生成最可能的续写。上下文清楚，续写就准；上下文含糊，它只能给你一个听起来合理的猜测 —— 而听起来合理，恰恰是最危险的部分。这里说的「模型」，通常指大语言模型（large language model, LLM）。

1 它擅长什么、不擅长什么

一句话概括：它是「候选生成器」，不是「判断者」。

2 三个站得住的场景

2.1 造示例数据（sample data）

做线框图（wireframe）和原型（prototype）时，最枯燥的活之一就是编几十条看起来合理的数据。让模型按你给的结构批量生成，能省掉大量时间。

本例里最典型的一次：画派单台线框时需要 20 条工单数据。有效的问法是 ——

按这个结构生成 20 条工单数据：order_no（格式 WO-yyyyMMdd-nnn）、appliance_type（只能从空调/冰箱/洗衣机/热水器里选）、fault_desc（10–25 字，口语化，像客户自己说的话）、status（CREATED/ASSIGNED/IN_PROGRESS/PENDING_PARTS/COMPLETED 之一）、created_at（近 7 天内）。其中至少 3 条 status 为 PENDING_PARTS。

有效做法是：给出一个带注释的骨架，把每个字段的要求写在旁边（取值范围、从哪些选项里选、长度限制），再要求它按这个结构生成。约束越具体，结果越可用。

注意最后那句「至少 3 条 PENDING_PARTS」——它保证了数据能覆盖到你关心的那个状态，而不是 20 条全是 CREATED。

2.2 解释陌生的代码或文档

拿到一段别人的实现、一份陌生的接口文档，先让模型讲清结构，再要求它按你的场景改写。这一步的价值不在于它写得多好，而在于它帮你跳过了「读懂」的冷启动阶段。

本例里的用法：供应商库存接口的文档只有一份 PDF，用模型先把它讲成「这个接口能回答什么问题、有哪些必填参数、错误码有哪几类」，然后再自己判断 —— 后面那个判断不能交给它。

2.3 起草初稿

访谈提纲（interview script）、问卷初稿、界面上的文案措辞、报告的开头段落 —— 这些东西从一版草稿改起，永远比从空白页起步快。

本例里 13 篇那份问卷，第一版就是让模型按「五个问题、覆盖缺料频率与影响」起草的，然后逐条改成现在的版本（把二选一改成填数字、把选项补全）。

2.4 三者的共同点

这三者的共同点是：产出是一个「候选」，后面一定要有人筛。一旦跳过筛选环节，它就从助力变成了风险。

3 两个必须警惕的地方

3.1 它会复现训练数据里的偏见（bias）

这是最容易被忽视、后果又最严重的一点。

让模型生成「一张典型的店铺老板头像」或「一位数据科学家的画像」，你会看到高度一致的结果：某个性别、某个年龄段、某种肤色。换个措辞，结果就跟着变 —— 这正说明这些特征不是来自你的需求，而是来自训练数据里的分布。

对做需求分析的人，这里有个直接的推论：不要让模型替你生成用户画像（persona）的人物特征。画像的价值在于「这个人真实的行为与痛点」，而不是「他的性别年龄收入」。让它画头像做示意图没问题，把它当成用户研究结论就出问题了。

本例里的具体做法：05 篇那份小林画像里的「行为」那一栏 —— 「先记进 Excel 第 37 行、再翻便签本逐个打电话、没接就记下回头再打第二次」—— 这三句只能来自观察，模型编不出来。它编出来的是「小林，28 岁，大专学历，工作认真负责」，那种东西对设计零价值。

这个问题在业界被归到负责任 AI（responsible AI） 与 AI 治理（AI governance） 的范畴里 —— 核心要求是：系统性的偏见要在流程上被检查，而不是靠使用者临时留意。

3.2 它会编得很像真的

模型会生成看起来很权威但完全错误的内容：不存在的条款、对不上的数字、看似真实的引用。这类现象通常叫幻觉（hallucination）。

危险之处在于它错得很流畅。一段编造的说明读起来比一段正确的说明还顺，因为它就是按「读起来顺」的目标生成的。

本例里有个具体的风险点：如果你问它「家电维修行业的标准响应时间是多少」，它会给你一个像模像样的数字（比如「行业标准是 4 小时」）。而这个数字会直接变成 15 篇里那条「2 秒响应」之外的业务指标 —— 但它可能是编的。

对应的纪律很简单：凡是会进入需求文档的事实性内容（政策条款、数据口径、行业规范），必须回到原始来源核对 —— 也就是回到基准事实（ground truth），不能拿模型的输出当依据。本例里真正的 ground truth 是小林那 80 通电话的统计，不是任何「行业标准」。

如果你的系统是让模型基于内部资料回答，那就用检索增强生成（RAG）把答案锚定在这些资料上，而不是依赖模型自己的记忆。

4 提问的几条实践

设计提示词（prompt）这件事本身就是一门手艺，通常叫提示工程（prompt engineering）。下面几条是其中最有用的，每条都配上本例的用法：

• 先交代角色和约束。 「你是一位熟悉 UML 的分析师，现在要为家电维修派单系统写「申请配件」的用例描述，约束是：只写主流程 + 三个例外，不要写界面细节」——比直接问问题有效得多；
• 给几个例子（few-shot）。 把「好的输出长什么样」示范一两个，比用文字描述要求准确得多。本例里贴一条已经写好的用例描述当模板；
• 要多个候选，不要一个答案。 「给三种不同的工单状态机设计，并说明各自的取舍」—— 你才能比较；
• 要它说明理由。 让它解释「为什么这么设计」，你才能判断它是不是在套模板；
• 给它你的上下文。 把真实的流程、字段、限制贴进去，让它针对你的场景改写；
• 让它自己找反例。 「这个设计在什么情况下会失效」—— 用来补充你的负面场景（negative scenario）。本例里这一问帮我们想到了「两个客服同时派同一单」。

最后一条特别值得常用：它找反例比找方案更靠谱。因为找反例的本质是枚举，而找方案需要判断。

5 把它用在产品里时的额外要求

如果生成式 AI 不只是你的工具，而是产品的一部分，那要求会高一个量级 —— 这也回到笔记 11 讲的 agent 那套。

本例里有个真实的场景可以对照：如果给客户做一个「智能报修助手」（用自然语言描述故障，模型判断是空调还是冰箱、可能是什么问题），那下面这五条就全部适用：

• 护栏（guardrail） —— 明确它不能说、不能做什么。比如不能给诊断结论（那是医疗/安全问题），只能建议报修类别；
• 人工复核（human review） —— 关键输出必须有人确认才能生效。比如模型判定的故障类别，要允许客服改；
• 可追溯 —— 每个输出都能查到依据。比如「判定为空调用的是哪几个关键词」；
• 回退路径 —— 模型不可用或答不上来时，界面该怎么表现。降级为「请选择家电类型」的表单；
• 对用户的预期管理 —— 让用户知道这是模型的输出、可能有误，而不是权威结论。

尤其最后一条：把模型输出包装成「标准答案」而不加说明，是产品设计上的不负责任。

第一条在本例里还有一层意思：护栏要写进需求文档，而不是写在代码注释里。因为它是需求（「系统不得给出诊断结论」），不是实现细节。

本节自测

1. 为什么说生成式 AI 是「候选生成器」而不是「判断者」？
2. 让模型生成示例数据时，怎么提高可用性？本例中怎么保证数据能覆盖关心的状态？
3. 为什么不该用模型生成用户画像的人物特征？它可能带来什么后果？
4. 什么是幻觉？为什么它特别危险？举出本例中一个具体的幻觉风险。
5. 如果要把模型输出直接展示给最终用户，至少需要补哪三件事？
6. 为什么说「让它找反例比找方案更靠谱」？
7. 本例里「智能报修助手」的护栏应该写在哪里？为什么？

参考答案

1. 因为它根据上下文生成最可能的续写，产出的是「听起来合理」的候选，而不是对业务的判断。上下文含糊时它会给一个听起来专业但与你的问题无关的方案（§0、§1）。
2. 给出带注释的骨架（每个字段的取值范围、选项、长度、时间范围），约束越具体越可用。本例加一句「至少 3 条 status 为 PENDING_PARTS」，保证数据覆盖到关心的状态而不是全是 CREATED（§2.1）。
3. 因为那些特征来自训练数据里的分布，不是来自你的需求。后果是画像变成人口统计表，对设计零价值 —— 画像真正值钱的是「行为」栏（本例小林那三句只能来自观察）（§3.1）。
4. 幻觉是模型生成看似合理但错误的内容。危险在于它错得很流畅（按「读起来顺」的目标生成）。本例风险：「家电维修行业标准响应时间是 4 小时」这类数字可能是编的，而它会被写进需求（§3.2）。
5. 至少补：护栏（不能说/不能做什么）、人工复核（关键输出有人确认）、可追溯（输出能查到依据），此外还需要回退路径与预期管理（§5）。
6. 因为找反例的本质是枚举，找方案需要判断。本例让它找「这个设计在什么情况下会失效」，帮我们想到了「两个客服同时派同一单」（§4）。
7. 应该写进需求文档，而不是代码注释。因为「系统不得给出诊断结论」是需求（约束），不是实现细节 —— 写在代码里，需求评审时没人看得见（§5）。

术语表