波仔
🧠 第十章 管理和部署
📄 一句话概括

四份配置跑同一套 6 条规则，一共报出 5 条错误。完整的配置 0 条通过； 缺提示词的那份报 2 条——「有这一项但不合规」和「根本没有这一项」是两类问题，修法不一样。

📝 本节和前面几节的关系

前十节讲的是原理和流程。从这一节开始是本章的实战：从零建一个能用的对话应用，六步走完。

一、这一步在整本书的什么位置

前面九章做的事是：认识角色、学技能、写代码、选算法、训模型、评模型、管模型。 这一章最后一步是把它交出去——让别人能用上。 「创建应用」就是交出去的第一个动作。 它做的事很朴素：给这个模型配一个名字、一句介绍、一个可见范围、一份说明它该怎么说话的提示词， 再挂上它要参考的文件。 这些填完之后，平台会给你一个可以分享的对话页面。 用户看到的是一个聊天框，不会看到你的提示词、模型名和知识库清单。 所以这一步的本质是把技术配置翻译成产品。 翻译得不好，后面提示词写得再好、知识库整理得再干净，用户也用不明白。

二、创建时真正要填的六项

名称：2 到 30 个字，用户能在列表里看到。别写「测试1」「修改版最终」，用户不知道那是什么。 描述：一句话说清「它能帮你做什么」。这句话决定了用户第一次打开时会不会知道该问什么。 模型：从平台已开通的模型里选。 选错（比如写了个没开通的名字）会直接报错，或者静默回退到默认模型——后者更麻烦，你以为换了其实没换。 提示词：应用的人格和规则。下一节专讲。 开场白：用户打开时看到的第一句话。好的开场白会顺手给两个示例问题，把用户的第一问「喂」出来。 可见范围：自己、团队、公开。这一项最容易被随手设错。

三、校验：错在哪比能不能建重要

Demo 把上面六项写成一份配置，再写六条校验规则，然后拿四份配置去跑。 完整的配置 0 条错误。 缺提示词的那份报 2 条：描述被清空（有这一项但不合规）、提示词整项缺失（根本没有这一项）。 模型名写错的那份报 2 条，可见范围越界的那份报 1 条。合计 5 条。 这四份配置演示的是四种典型错误： 漏填、填了但内容不合格、枚举值不在允许范围内、引用了不存在的东西 （kb 那一项写成了字符串而不是列表）。 校验的价值不在「能不能建出来」，在「建错的时候知道错在哪」。 「配置有误」这四个字对使用者毫无帮助，「prompt 字段缺失」才是可执行的反馈。 还有一条工程经验：校验函数不要提前 return。 提前返回只会报第一个错误，用户改一个、再提交、再报下一个，来回好几轮。一次列全，一轮改完。

四、四个最常见的坑

可见范围手滑设成公开。内部文档、客户资料全在里面，一公开就收不回来了。 所以这一项最好默认是「自己」，要分享再手动放开。 模型选了个没开通的。 有的平台会静默回退到默认模型，你以为是 GPT-4 级别，实际跑的是最便宜的那个。 表现是「答得很糊」，很难往模型上想。 绑定了一个空的知识库。 应用能建、能打开、能对话，但回答全靠模型的先验知识，一点你的资料都没用上。 这种问题只有真问几个专业问题才能发现。 开场白写得像说明书。用户不看说明书。好的开场白是一句人话加两个示例问题，让用户点一下就能开始。

五、动手 Demo：配置校验：四份配置，五条错误，每条都指到字段

把创建应用要填的六项写成一份配置，再写六条校验规则（名称长度、描述非空、模型名在允许列表里、 提示词至少 10 字、知识库必须是字符串列表、可见范围是三选一）； 然后造三份坏配置，和一份完整配置一起跑校验。

rules = [(u"name", u"必填且长度 2 到 30", fn1),
         (u"model", u"必须是已开通的模型名", fn2), ...]

for key, rule, fn in rules:
    if key not in cfg:
        errs.append(u"缺 %s" % key)          # 缺项
    elif not fn(cfg[key]):
        errs.append(u"%s 不合规" % key)      # 值不对

实跑输出：

--------------------------------------------------------------------
创建应用：四份配置跑同一套规则，错在哪一条条列出
--------------------------------------------------------------------
  配置                  检查项   错误数   错误明细
  --------------------------------------------------------------
  配置 A 完整             6 项     0 条   通过
  配置 B 缺提示词         6 项     2 条   desc 不合规、缺 prompt
  配置 C 模型名写错       6 项     2 条   model 不合规、kb 不合规
  配置 D 可见范围越界     6 项     1 条   scope 不合规

  四份配置一共报出 5 条错误，每一条都指到了具体字段。
  配置 B 报了两条：desc 被清空（有这一项但不合规）、prompt 整项缺失（根本没有这一项）。这是两种不同的问题，修法也不一样——一个是改内容，一个是补字段。所以校验要分开处理「缺项」和「值不对」，不能混成一句「配置有误」。
  **这一步的价值不在「能建出来」，在「建错的时候知道错在哪」。** 应用发布后改配置要重新走流程，能在保存前拦住，比事后排查划算得多。

  要说明：这里没有任何真实的 ChatGPT 平台接口。沙箱里没有网络、也没有应用平台的账号，所以我做的是「把那份配置的结构和校验规则写成代码」，验证的是校验逻辑本身。

四份配置一共 5 条错误。每一条都带字段名，所以拿到报错就知道改哪里。 注意「缺项」和「不合规」是分开的两个分支。 这份 Demo 里描述被清空报「不合规」，提示词整项被删报「缺 prompt」——同样是 prompt 字段有问题， 处理方式完全不同：一个要改内容，一个要把字段补回来。 「模型名写错」那条还有一层意思：这个名字不在允许列表里，说明它要么没开通、要么拼错了。 两种都不该让它上线，因为平台可能静默回退。 沙箱里没有 ChatGPT 平台、没有网络、也没有账号，所以这一步不可能在界面上真点。 我做的是把「那份配置的结构和校验规则」写成代码跑一遍，验证的是校验逻辑本身，不是平台行为。

30 秒实验

  1. 给配置加一项「温度必须在 0 到 2 之间」，看越界会不会被拦住。
  2. 把可见范围的允许列表改成只有 private 和 team，看原来那份配置还过不过。
  3. 想一想：为什么校验函数提前 return 会让使用者多改好几轮？

常见误区

  1. 「建出来能用就行」——配置错了往往不报错，只表现成「答得不准」。
  2. 「可见范围选公开更方便」——内部资料一旦公开就收不回来。
  3. 「模型名随便填」——平台可能静默回退到默认模型，你查不出原因。
自测三问（点开对答案） 1. 创建应用要填的六项是什么？ —— 名称、描述、模型、提示词、开场白、可见范围（外加知识库等可选绑定）。 2. 为什么校验要区分「缺项」和「值不对」？ —— 两者修法不同：一个是把字段补回来，一个是改内容。 3. 模型名写错可能带来什么隐蔽问题？ —— 平台静默回退到默认模型，看起来能跑，实际能力差很多。

应用建好了，接下来是最影响效果的一步：告诉它该怎么说话。

相关笔记