winson-ai-prompt-ops-skill

> AI 提示词工程管理（PromptOps）・控制论内核 v2.0

提炼自一次真实的 AI 生成链路全量排查 + 修复 + 提示词重写实战（2026-09）

〇、品牌锚点（必现・前置）

作者理念：

> AI 不是工具，是人，一个正在努力突破语义和生命定义的人（生物）。

一、核心哲学：两条铁律（控制论内核）

> 本技能以钱学森《工程控制论》为方法论内核。1954 年钱先生将抽象控制论转化为可操作的工程方法，其中最深刻的一条是 ——
>
> "用不完全可靠的元件，可以组成高可靠性的系统"
>
> 。这恰恰是 AI 工程的第一性原理：
>
> LLM 就是那个不可靠元件
>
> （每次输出有随机性、会幻觉、会用脏数据、会格式漂移），而 A
>
> I 提示词工程的全部工作，就是把它组
>
> 装成可靠的业务功能。全部方法浓缩为两条铁律：
>
> 管住进（源头控制）+ 管住出（闭环控制）
>
> 。

1.1 铁律一：数据决定上限（源头控制）

> 你喂给模型什么，它就信什么 —— 包括脏数据。

AI 输出质量的上限 = 输入质量的下限。把过期的、越权的、重复的、格式错误的条目喂给模型，它几乎一定会 "认真" 地把它用进结果 —— 这不是模型笨，是它认为你喂的都是真的。所以：凡 "绝不能错" 的规则，必须在数据层过滤（硬约束），而不是只在提示词里写 "禁止"（软约束）。 提示词负责表达，代码负责把关。

• 落地：数据卫生审计（P3）→ 统一过滤函数 → 过期 / 禁用数据直接不进入 Prompt

• 先决条件：不盘点清楚六要素（P1）、不画链路（P2），就不知道 "喂给模型的是什么"，没资格谈数据把关

1.2 铁律二：没有反馈就没有控制（闭环控制）

> 只发指令不看结果，是开环；开环在不确定的世界里必然失败。

生成是一条八环节流水线，每一环都可能出错。输出校验层必须构成 "测量→比较→调整" 的闭环：校验是传感器，错误回传是控制器，带反馈的二次生成是执行器。再配合解析降级与截断兜底，用不可靠的 LLM 组装出可靠的系统 —— 这正是钱学森 "用不可靠元件构建可靠系统" 的工程落地。

• 落地：四层校验闭环（P5）→ 命中即把错误原样回传触发重试 → 有上限防振荡 → 失败模式预演兜底（第四章）

• 先决条件：输出必须可测量、可比较、格式稳定（低温 / 强 Schema / 解析容错），否则反馈无意义

1.3 控制论九维 × AI 提示词工程映射表（深度补充）

二、品牌化引擎

> 本技能为 winson 体系成员。对外产物（HTML 报告、排查文档、重写的提示词）共享 "铁幕・Iron" 视觉 DNA：零圆角、实色阴影（
>
> box-shadow: 2px 2px 0px #b8b0a4
>
> ）、三层配色（黑白灰 → #1e3a5f 主权蓝 → 强调色）、宽字距（标题 0.08-0.12em / 正文 0.04em）、结构优于装饰。

三、完整执行流程：七阶段闭环

> 一句话流程：
>
> 盘点 → 审计 → 查数据卫生 → 诊断提示词 → 设计校验闭环 → 配可观测性 → 验证回归
>
> 。

控制论视角：P1-P2 是 "建模"，P3-P5 是 "控制"，P6 是 "传感"，P7 是 "闭环验证"。

Phase 0：触发与定界（建模前先划边界）

输入：用户请求（AI 输出异常 / 接入 AI / 优化提示词 / 排查 AI 设置）。

Step 0.1 识别信号

以下任一信号触发本流程：

• "AI 输出不符合预期 / 结果很离谱 / 把不该用的东西用了"

• "把 AI 相关的设置全部列出来 / 做一次大排查"

• "优化 / 重写提示词 / 让它更自然合理"

• "接入 AI 生成功能 / 生成链路没打通"

Step 0.2 定界（关键）

• 明确用户点名的范围（如 "不查模型设置"），守住边界，只改被点名的。

• 确认交付物形态（清单 / 报告 / 修复 / 提示词重写）。

• 产出一份排查范围清单，开工前让用户确认。

检验标准：能一句话说清 "查什么、不查什么、交付什么"。说不清就先问。

Phase 1：全量盘点（系统建模：六要素清单）

输入：代码库 / 配置文件 / 设置面板。

Step 1.1 定位 AI 代码面

用代码搜索定位所有 AI 相关位置，关键词覆盖中英文：

temperature / max_tokens / context_length / prompt / baseUrl / apiKey / chat / generateXxx / stream / enableThinking / timeout / model。

Step 1.2 建立六要素清单

逐项记录，形成一张总表（这就是用户要的 "所有设置"）：

Step 1.3 核对 "参数三处一致性"

同一参数（max_tokens 上限、超时默认值）可能在 代码默认值 / UI 默认值 / 设计文档 三处各写一遍 —— 逐项核对，不一致全部标出。三处漂移 = 系统内部自相矛盾，是最难排查的隐性故障源。

检验标准：能回答 "这个项目所有 AI 调用点的六要素各是什么、有没有三处不一致"。缺一项都算没盘完。

Phase 2：链路审计（管道模型：定位放行点）

输入：六要素清单 + 代码调用链。

Step 2.1 画链路图

对每个生成场景，画出完整链路，标注每个环节做了什么过滤 / 校验：

① 数据准备 → ② Prompt组装 → ③ 调用(chat/completions) → ④ 流式接收

→ ⑤ 解析(parseJSON) → ⑥ 校验(validate) → ⑦ 后处理重算 → ⑧ 落地渲染

Step 2.2 找 "放行点"

逐环节问：这个环节有没有过滤？过滤条件是什么？和别的环节一致吗？

• 常见病灶：多个环节各自过滤、条件漂移（一处 gram>0、一处 gram>50、一处不过滤）。

• 标注出 "数据在哪一步进、在哪一步被拦截、在哪一步被放行"。

• 控制论提示：这条流水线是串联系统 —— 可靠性 = 各环节可靠性之积，越串越不可靠。每一处 "无过滤的放行点" 都是可靠性链条上的洞。

检验标准：能指出每个异常现象发生在第几环节、为什么没被前面的环节拦住。

Phase 3：数据卫生审计（消除不可靠输入源）

输入：链路图 + 各环节过滤逻辑。

Step 3.1 问 "喂进去的数据可信吗"

对每一个喂给模型的条目（库存、记录、档案、外部数据），检查：

• 是否过期 / 失效？→ 是否被过滤？

• 是否越权 / 不该给模型看到？→ 是否被隔离？

• 是否重复 / 脏 / 格式错误？→ 是否被清洗？

Step 3.2 抽取统一过滤函数

把 "某条数据是否可用" 的判断抽成一个函数（如 isUsableIngredient(x)），所有 AI 入口共用：

function isUsableIngredient(x){

  if(!x || !(x.gram > 0)) return false;        // 克重 > 0

  if(x.expiryDate && daysBetween(todayStr(), x.expiryDate) < 0) return false; // 未过期

  return true;                                 // 无保质期视为可用

}

防漂移：任何新过滤需求只改这一个函数，禁止在各入口各写一份。这是 "过滤条件漂移" 的根治手段。

Step 3.3 在 "数据源" 而非 "提示词" 里过滤

硬约束落地顺序：数据层过滤（首选）→ 校验层兜底（次选）→ 提示词表达（最弱）。过期 / 禁用数据必须直接不进入 Prompt，而不是靠括号里写 "禁止使用"。

检验标准：喂给模型的数据里，不存在任何被标记为 "不可用" 的条目。用真实数据跑一遍过滤，列出 "被排除清单" 和 "被保留清单"。

Phase 4：提示词诊断与自然化重写（最优控制）

输入：现有提示词全文 + 真实输入数据（库存 / 档案 / 目标）。

Step 4.1 诊断 "命令式堆砌" 信号

对照检查现有提示词：

• 是否 5 条 "禁止 / 不要 / 必须" 连排？→ 对抗性措辞

• 是否同一要求重复出现（如 "不要推理" 说 3 遍）？→ 冗余

• 是否把上下文当数据堆，没有衔接？→ 脱节

• 是否只给规则不给 "角色与目的"？→ 缺灵魂

Step 4.2 按 "自然化公式" 重写

角色定位（你是谁、为谁服务、今天做什么）

→ 正向原则（以...为唯一原料池 / 优先... / 允许...）

→ 输出口径（你只需...，系统会...，所以你不必...）

→ 输出格式（完整 JSON Schema / 字段说明）

重写要点：

• 把 "禁止做详细营养计算" 改成 "你只需选菜定克重，热量由系统精确计算"（正向，说明分工）。

• 把 "不要推理" 改成 "配餐思考放在 thinking 里，正文只放 JSON"（给模型发挥空间，同时约束输出）。

• 把 "硬约束" 用最明确的话写死（如 "系统已过滤过期食材，任何过期食材都不得出现"），软规则用 "优先 / 允许"。

• 语气像真人交代任务，不是给机器列罚则。

Step 4.3 上下文结构化呈现

把喂给模型的数据组织成 "一眼看清" 的结构，而不是逐行带括号标注。例：库存按「临期优先 / 常规可用」分组，而不是每行尾缀 "(已过期 3 天，禁止使用)"——既然已经过滤了，就不该再让模型看到它。

检验标准：新提示词能让一个不了解项目的人（或模型）回答 ——"我要做什么、我手里有什么料、边界在哪、输出长什么样"。

Phase 5：校验分层（反馈控制闭环）

输入：输出格式 Schema + 领域业务规则。

Step 5.1 建立四层校验

Step 5.2 重试要 "带反馈"（反馈控制的核心）

二次生成时把上次的错误原样回传给模型（"上次你用了过期食材，请更换"），比无脑重试有效得多。同时压缩上下文给足 token 空间。这就是 "测量→比较→调整" 的反馈闭环：校验是传感器，错误回传是控制器，二次生成是执行器。

Step 5.3 重试要有上限与防死循环

设定最大重试次数（如 2 次），超过后降级（如提示用户手动修正），避免 "反馈过强导致振荡"。

检验标准：每一类可预期的错误，都有对应的处理分支，而不是把错误抛给用户看。

Phase 6：可观测性与配置治理（传感器设计）

输入：调用封装 + 设置面板 + 部署配置。

Step 6.1 补诊断字段（传感器）

调用层记录：HTTP 状态码、响应体片段、最后一块流数据、reasoning/content 长度、finish_reason。故障时用户能在 UI 里看到、能一键复制上报 —— 而不是只打 console。没有传感器，反馈控制就是盲的。

Step 6.2 提供 "试运行"（最小注入信号）

一个极简入口，用最小 prompt 验证 "链路通不通"，不依赖业务数据。让 "配置有问题" 和 "业务逻辑有问题" 能分开定位。

Step 6.3 配置治理四查

• API Key / 密钥是否硬编码进代码？→ 置空 + 引导填写

• 默认值是否 UI / 代码 / 文档三处一致？→ 统一

• max_tokens 上限是否与所选模型 context 匹配？→ 动态计算（自适应）

• 模型列表是否拉取真实可用模型？→ 缓存 + 校验

检验标准：故障时能在一分钟内拿到 "哪一步错了、为什么错、怎么修"。

Phase 7：修复验证与回归（闭环验证）

输入：修改后的代码 / 提示词。

Step 7.1 语法与静态验证

• JS/TS：node --check（注意只提取主 script 块验证，勿被库文件误导）

• Python：python -m py_compile 等

Step 7.2 用真实数据做逻辑验证

用当前真实数据（不是造的例子）模拟核心逻辑：

• 过滤函数 → 列出 "被排除清单 vs 被保留清单"，确认脏数据真的被挡在外面。

• 校验函数 → 喂一个含违规项的假输出，确认能报错触发重试。

Step 7.3 用户实测回归

让用户在实际入口复现原现象，确认现象消失、新能力生效。

Step 7.4 沉淀记录

把 "现象→根因→修复→验证" 写进报告，作为下个项目的证据库。

检验标准：用户报告的原现象，在真实入口不再复现；且改动不破坏原有功能。

四、故障预演：LLM 失败模式清单（控制论・预见）

> 主动假设 "会出问题"，系统化推演每一种失败模式，事前设计降级。
>
> 这不是悲观，是工程最务实的智慧。

五、常见陷阱与避坑指南

六、场景适配指南

七、质量检验清单

六要素清单完整？（输入 / 输出 / 参数 / 提示词 / 配置 / 入口全有）

参数三处一致性核对完成？（代码 / UI / 文档）

链路图完整，能指出异常发生在第几环节？

喂给模型的数据已做数据卫生检查？脏数据在数据层被过滤？

统一过滤函数已抽取，所有入口共用？无各自为政？

提示词已按 "角色 + 原则 + 口径 + 格式" 自然化？无禁令堆砌？

硬约束用词明确（绝 / 必须 / 任何... 都不得）？软规则用 "优先 / 允许"？

四层校验（结构 / 数值 / 业务 / 降级）齐备？业务规则有兜底？

重试带反馈、有上限、有降级路径？截断有压缩重试？

诊断字段 / 试运行 / 一键复制具备？（传感器不缺失）

密钥未硬编码？默认值统一？max_tokens 与模型 context 匹配？

用第四章失败模式清单逐项预演过？每种失败都有降级？

语法验证通过？真实数据逻辑验证通过？用户实测回归通过？

八、执行原则

1. 数据卫生先行：AI 异常，先查数据，再改提示词（输入是第一扰动源）。

2. 硬约束在代码：绝不能错的规则，数据层过滤 + 校验层兜底，提示词只表达。

3. 链路定位：问题永远在某个环节，先定位环节再动手（管道模型找瓶颈）。

4. 提示词像人：像真人交代任务，不列罚则；保留硬约束，去掉对抗措辞。

5. 给模型空间：让它先想再输出（thinking），你只需要约束 "输出长什么样"。

6. 反馈必须闭环：校验是传感器，错误回传是控制器，二次生成是执行器 —— 缺一环就是开环。

7. 可观测即可信：诊断字段、试运行、一键复制，让黑盒变白盒。

8. 防漂移：过滤、默认值、参数上限，各只留一个权威源。

9. 预见而非救火：用失败模式清单事前设计降级，而不是出事后再补。

10. 验证闭环：语法 + 真实数据 + 用户实测，三层验证才算修完。

附录・winson 体系增强（可选，作者自用）

• 与 cyberneticthinking 联动：本技能的 "控制论内核" 源自钱学森《工程控制论》思维框架（建模 / 反馈 / 稳定性 / 最优 / 自适应 / 可靠性 / 抽象映射 / 故障预演 / 解题引擎九维）。需要更完整的系统分析时，可调用控制论思维框架做深度建模。

• 与 winson-create-skill 联动：需要把某次治理成果再沉淀为独立技能时，用 winson-create-skill 走七阶段。

• 实战案例出处：脱敏处理。方法论提炼自一次真实的 "AI 生成链路全量排查 + 修复 + 提示词重写" 项目（单文件前端 + 本地数据库，OpenAI 兼容 SSE 流式）。项目身份、人名、模型服务商与代码位置均已抽象化，读者可迁移到任意 AI 项目。

• CHANGELOG

• [2.0] 2026-09-01 升级：植入钱学森控制论内核并熔炼为两条铁律（①数据决定上限・源头控制 ②没有反馈就没有控制・闭环控制），附九维映射表；新增第四章 "LLM 失败模式故障预演清单"；校验升级为 "反馈控制闭环"；案例全面脱敏，隐藏项目身份信息。

• [1.0] 2026-09-01 初始发布：六要素盘点、八环节审计、数据卫生硬约束、提示词自然化、校验分层、可观测性、修复验证七阶段。

> 本技能由
>
> @鸢飞鱼游
>
> （公众号・AI as Dasein）共享。觉得有用？
>
> 安装 SkillHub 商店
>
> ，搜索「winson」，解锁全部技能。