SOL ENGINE：把 GPT-5.6 提示词优化变成可审计、可回归的工程流程
这篇文章解决什么问题：SOL ENGINE 将 GPT-5.6 提示词工程拆成审计、最小优化、受控评测和发布门禁，并提供两个无需 API key 的本地确定性 CLI，帮助团队保留真实契约。
我在 7 月新建并发布了开源项目 SOL ENGINE v0.1.0。它面向 GPT-5.6 提示词层、工具描述和 Agent 工作说明，把一次容易凭感觉完成的“提示词优化”拆成四个可追踪阶段：Audit. Optimize. Evaluate. Ship.
项目由一个可安装 Skill 和两个本地确定性 CLI 组成。Skill 负责判断约束、歧义和评测路径；CLI 负责静态审计与基线/候选数据比较。SOL ENGINE 是独立开源项目，并非 OpenAI 官方产品；OpenAI 与 GPT-5.6 在这里仅用于说明兼容目标和事实来源。
为什么提示词变短，不等于提示词变好
生产提示词通常不是一段纯文案。它同时承载权限边界、工具选择、输出 Schema、业务规则、停止条件、失败处理和交付要求。随着多人维护和版本迁移，同一条指令可能重复出现，模糊的过程要求会不断堆积，工具描述也可能越来越长。
删除重复内容有价值，但危险也恰好发生在“精简”这个动作里。把 只能写仓库内文件 删掉，提示词会更短，却扩大了权限；把固定 JSON keys 合并成“返回结构化结果”，字数更少，却可能让下游解析器失效；把两个冲突的失败分支擅自合成一个新规则，则是在替产品负责人改变业务行为。
OpenAI 当前的 GPT-5.6 模型指导 建议从已经可用的提示词和工具集出发，一次删除一组重复指令、示例或工具，再在代表性任务上重新验证。官方也明确提醒，精简提示词的结果会因工作负载（workload）而异。因此 SOL ENGINE 不把“更短”设为发布标准，而是先保留行为契约，再要求候选版本通过同一组任务的受控比较。
核心方法：Audit、Optimize、Evaluate、Ship
Audit：只报告会改变行为的缺陷
审计阶段把输入拆成目标、事实、权限、工具契约、输出契约、成功标准和停止条件。它会寻找重复指令、互相矛盾的分支、含义不清的默认值、过长工具描述，以及特定 Agent 场景缺失的契约。
重点不是对每句提示词发表风格意见，而是识别会改变可观察行为的问题。比如单独出现 Think carefully，并不等于要求模型展示思维过程；普通的“完成任务”也不能在没有冲突证据时被解释成无限执行。静态审计发现（Finding）只是需要复核的确定性信号，不是语义错误的自动证明。
Optimize：做外科式改写，不重写产品规则
优化阶段把真实约束和冗余过程描述分开。重复项可以合并，模糊但不影响契约的风格话术可以删除；权限、固定字段、用户提供的值、工具参数、失败处理和验证要求则必须保留。
如果两个合理解释会改变目标、Schema、事实、权限、证据或成功条件，正确动作不是“智能地猜一个”，而是提出一个最小阻塞问题。每轮只改变一组内容，能让后续回归更容易定位：究竟是哪个删除或改写造成了行为变化。
Evaluate：先冻结质量标准，再比较资源指标
评测阶段要求基线和候选使用同一批代表性任务、相同运行环境与预先声明的成功判定。每次尝试都要保留，包括失败、超时和重试；success 不能等看到结果后才重新定义。
质量、必要证据、Schema、工具与可靠性应先通过，之后才讨论 Token、端到端延迟和成本。一个候选即使平均 Token 更少，只要写入越界或漏掉必需字段，就不应发布。比较器可以门控成功率下降、总 Token 增长、平均延迟增长和每个成功任务的成本增长，但它只会处理用户提供的测量值。
Ship：发布的是经过验证的版本，不是审美偏好
最后一步输出明确的 ship/hold 结论、变更清单、评测证据和仍未解决的风险。如果质量门失败就保持基线；如果某个指标缺失，就把该门禁标为不可用，而不是推测一个结果。这样，提示词变更可以像代码改动一样被审查、回归和回滚。
一个可以核对的编码 Agent 示例
仓库中的编码 Agent 示例要求优化提示词，同时保持仓库写入边界和最终 JSON keys 不变。原始版本重复了“编辑前检查相关文件”，还混有 Think carefully、be concise 等不定义可观察输出的过程话术。
候选版本删除重复和模糊风格要求，但继续保留：只在仓库内修改、保护用户无关改动、完成请求后运行测试、测试无法运行时说明原因，以及 summary、files_changed、tests 三个 JSON keys。这里的关键不是少了几行，而是被删除内容不改变这些契约。
这个 candidate 只是工作流生成的候选文本，不是实测模型结果。它仍需要在同一批 bug fix 和小功能任务上与原版比较，先确认任务成功率、写边界和字段完整性没有下降，再看 Token 或延迟。
两个本地 CLI 如何进入工作流
audit_prompt.py 与 compare_eval_runs.py 都只使用 Python 3.10+ 标准库，不需要 API key，也不会发起网络请求。两者读取输入并把结果写到 stdout，不会修改输入文件，也不会调用 GPT-5.6 自动生成新提示词。
静态审计器接受普通文本或 JSON 工具栈，提供 general、agent、research 三种 profile，可输出 Markdown 或 JSON：
1 | python skills/gpt-5-6-prompt-engine/scripts/audit_prompt.py \ |
回归比较器读取两份 ID 对齐且非空的 JSONL。id 和 success 必填；input_tokens、output_tokens、reasoning_tokens、latency_ms、cost_usd 等指标可选，但只有两组全部记录都提供某个指标时才能比较。单条记录可以这样写：
1 | {"id":"case-001","success":true,"latency_ms":842,"input_tokens":910,"output_tokens":184,"reasoning_tokens":96,"cost_usd":0.0124} |
执行门禁：
1 | python skills/gpt-5-6-prompt-engine/scripts/compare_eval_runs.py \ |
门禁全部通过时退出码为 0；输入无效时为 1；任一已配置回归门失败时以 2 退出。这让脚本可以进入 CI，但阈值必须由项目根据真实任务预先确定，仓库示例不是所有 workload 的通用默认值。
快速开始：安装与最短使用路径
使用 Agent Skills CLI 全局安装：
1 | npx skills add wp-a/gpt-5.6-prompt-engine --skill gpt-5-6-prompt-engine -g -y |
如果只安装到 Claude Code，可以显式指定客户端；该命令会把 Skill 放入 Claude Code 的全局 Skill 目录：
1 | npx skills add wp-a/gpt-5.6-prompt-engine --skill gpt-5-6-prompt-engine -g --agent claude-code -y |
在 Codex 中也可以显式调用内置安装器：
1 | $skill-installer install https://github.com/wp-a/gpt-5.6-prompt-engine/tree/main/skills/gpt-5-6-prompt-engine |
Claude Code 安装后开启新会话，可以直接用自然语言点名 Skill：
1 | 使用 gpt-5-6-prompt-engine Skill 审计下面的提示词，保留权限边界、工具契约和输出 Schema， |
安装完成后开启一个新任务，并提供真实提示词、必须保留的契约与期望输出。最短可执行 prompt 如下：
1 | 使用 $gpt-5-6-prompt-engine 审计下面的编码 Agent 提示词。 |
如果任务涉及当前 GPT-5.6 参数、模型行为或迁移兼容性，应在执行时重新查看官方文档。SOL ENGINE 仓库中的来源映射记录的是核验依据，不会让易变信息永久有效。
三个适合直接开始的场景
场景一：为长期演化的编码 Agent 提示词去重
当系统提示词经过多轮追加，先用审计器定位重复规则和缺失契约，再让 Skill 只处理一组内容。把仓库写边界、测试要求、固定输出字段和失败处理列为不可变项，用真实 bug fix 与小功能做成冻结任务集。这个场景的目标不是追求最短提示词，而是在不改变写入权限和交付格式的前提下减少噪声。
场景二：迁移到 GPT-5.6 时保护现有运行契约
迁移不应从大规模重写提示词开始。先盘点模型入口、端点、reasoning 设置、工具调用、Schema、缓存和解析器，再区分必需兼容改动与需要评测的可选优化。官方建议在代表性任务上验证设置，最佳选择取决于 workload；因此模型档位、推理强度或缓存策略不能只凭描述决定，更不能把迁移和提示词重写混成一次无法归因的改动。
场景三：把提示词发布门禁接入 CI
团队可以让固定任务的运行器输出同 ID 的 baseline 与 candidate JSONL，再调用比较器生成 Markdown 或 JSON 报告。门禁先约束成功率与必要证据，再限制 Token、延迟和每个成功任务的成本。失败退出码 2 可以阻止发布，但它不替代对输出质量的定义；任务、评分规则、失败记账和阈值必须在运行前由团队确认。
能力边界
SOL ENGINE 不会自动证明候选提示词更好，也不保证质量、Token、延迟或成本提升。静态审计不能推断作者真实意图；比较器不会运行 GPT-5.6、给模型输出打分、补齐缺失指标，也不会验证 success 标签是否可靠。六个记录在仓库中的前向场景和自动化测试用于验证项目契约，不是普适 Benchmark，更不是模型收益证明。
它也不应在存在实质歧义时替团队选择业务规则。提示词工程能让决策更可见、评测更可复现，但最终的成功标准、权限边界和发布风险仍由项目负责人确定。
隐私与敏感数据
本地两个 CLI 本身无需 API key、不会联网且不修改输入，这降低了静态审计和结果汇总的外传面，但不代表整个工作流天然无敏感信息。系统提示词可能暴露内部权限、工具描述、数据结构和运维流程，评测 JSONL 也可能包含任务标识、成本或客户数据。提交仓库、发送报告或调用任何模型前，应移除密钥和个人信息，对内部字段做最小化或匿名化，并确认日志、CI artifact 和第三方模型的数据保留策略。
人工复核
人工复核至少覆盖三层：第一层检查候选是否保留权限、Schema、业务事实、工具和停止条件；第二层检查冻结任务的成功判定与必要证据是否一致；第三层检查门禁阈值是否反映真实发布风险。对代表性失败要回到原始 trace，而不是只看聚合平均值。任何“更简洁”“更快”或“成本更低”的结论，都必须由当前项目自己的测量支持，不能从示例、单次输出或官方方向性结果直接外推。
项目与版本
系列导航
微信
