把个人经验
炼成可靠系统

结论先行：Skill 只是接口，系统才是产品

把某个人的经验“写成提示词”，最多得到一次像样的模仿。要稳定输出一种 SOP 服务，必须完成四次转换：验证经验真的有效；把叙述变成可观察的知识模型；把知识模型编成流程、决策、数据和工具契约；最后用评测、权限、版本与运营把它变成可维护系统。

研究证据 专家直觉只有在环境存在稳定线索且反馈长期、快速、明确时才可靠；低可预测环境里的自信不是准确性的代理。见 Kahneman & Klein, 2009。

官方事实 OpenAI 将 Skill 定义为包含指令、资源和可选脚本的可复用工作流；官方结构与加载机制见 Build skills。

为什么个人经验很难蒸馏

研究证据 CTA 文献指出普通专家访谈容易不完整；并发有声思维对当前注意内容更可靠，追问未被注意的“为什么”可能诱发推断。见 Ericsson & Simon, 1980、Sacks et al., 2023。文献中的“可能漏掉 70% 子任务”来自特定研究链，只应视为风险信号，不能当通用估算。

先证明“经验源有效”，再提取经验

不要按头衔、资历、表达能力或自信挑专家。先构建代表性任务集，再寻找能稳定取得优异结果、并能被结果证据或下游评价复核的人。最好加入一名对照专家、一个新手视角和一个交付物接收者，以暴露分歧和隐含标准。

研究证据 专家绩效研究强调在代表领域本质的任务上观察可复现的卓越表现，而不是用年资替代验证。见 Charness & Tuffiash, 2008。刻意练习很重要，但“一万小时足以解释专家差异”的强命题并不成立，参见 Hambrick et al., 2014。

知识采集：ACTA 搭骨架，CDM 挖判断，观察与日志校事实

四条证据线同时采集

每个关键判断都问这 8 个问题

1. 当时你先注意到什么？哪个信号让它重要？
2. 你试图实现什么目标？还有哪些相互冲突的目标？
3. 你考虑过哪些方案？为什么排除？
4. 如果关键线索反过来，你会如何改变判断？
5. 新手通常在哪里误判？他们缺的是什么线索？
6. 什么信息会让你停下、补问、换源或升级？
7. 你如何知道这一步完成了？可观察证据是什么？
8. 这条规则适用于哪些条件，又在哪些条件下失效？

研究证据 ACTA 的任务图、知识审计和模拟访谈来自 Militello & Hutton, 1998；CDM 的关键事件决策探针来自 Klein, Calderwood & Macgregor, 1989。CTA 在商业知识工作中的量化效果证据弱于医疗、航空和军事领域，这是本报告的外推限制。

三层建模：服务蓝图 × BPMN × DMN

这三种表示回答不同问题，不能互相替代。小团队无需追求完整符号学，但应保留它们的语义：谁在体验什么、工作如何流动、判断依据是什么。

一个轻量的分层示例

客户层      提交需求 ───── 等待澄清 ───── 审阅草案 ───── 接收交付
可见接触    范围确认       缺口清单         证据与限制       结果与回执
──────────── 可见线 ─────────────────────────────────────────
后台流程    解析 → 查询 → 决策网关 → 生成 → 质量门 → 发布
支持系统    身份 / 数据目录 / 规则库 / 审批 / 版本库 / 审计

决策 D-07：证据是否足够？
  IF 权威来源 ≥ 1 且时效合格且无重大冲突 → continue
  IF 来源冲突但可解释                         → human_review
  IF 来源不适用 / 过期 / 跨权限               → stop

正式标准 / 方法 BPMN 2.0.2 旨在兼顾业务可读与技术实现；DMN 1.5 与流程模型互补；服务蓝图方法见 Bitner, Ostrom & Morgan, 2008。这些来源证明表示法成熟，不证明使用它们必然改善业务结果。

0–9 阶段完整生命周期

下面的阶段与退出门是本报告综合形成的工程框架，不是某一标准的原文。核心思想与 ISO 的过程方法、PDCA 和 NIST 的持续 TEVV（测试、评估、验证、确认）一致。

正式指导 ISO 过程方法把输入、活动、检查和输出纳入 PDCA；NIST AI RMF 强调接近部署条件的可重复 TEVV、人工监督和持续监控。见 ISO/TC 176 Process Approach、NIST AI RMF Core。

Skill 文件结构与渐进披露

官方事实 Codex/ChatGPT 先看到 Skill 的 name 和 description；匹配后才加载完整 SKILL.md。Codex 初始 Skill 列表有上下文预算，描述可能先被缩短，所以描述必须前置最关键用例和触发词。详情见 OpenAI Build skills。

experience-sop/
├── SKILL.md                  # 必需：路由、契约、核心约束、停止条件
├── agents/
│   └── openai.yaml          # 可选：UI、显式/隐式调用、MCP 依赖
├── references/
│   ├── decision-rules.md    # 判断树、证据等级、例外
│   ├── data-contract.md     # schema、字段口径、新鲜度
│   ├── source-policy.md     # 来源优先级与冲突处理
│   └── failure-playbook.md  # 重试、降级、升级、补偿
├── scripts/
│   ├── query_data.py        # 确定性查询、分页、限流
│   ├── normalize.py         # 清洗与 schema 校验
│   └── verify_output.py     # 业务不变量核验
├── assets/
│   └── report-template.md   # 交付模板；不是模型指令
└── evals/                   # 工程扩展，非官方必需目录
    ├── cases.jsonl
    └── trigger-cases.jsonl

三层信息放置规则

脚本化的边界

当同一逻辑会被反复重写，或确定性执行显著提高可靠性时才加脚本。把参数校验、分页、格式转换、哈希、幂等记录和机器可判不变量放进代码；把含糊判断、证据权衡和人工升级留在指令/决策层。新增脚本必须真实运行验证。

查询“成功”与数据“可用”是两件事

每个关键查询先问：这份数据能回答当前问题吗？然后才检查完整性、准确性、及时性、一致性、唯一性和有效性。返回 HTTP 200 或 SQL 有结果，只能说明调用执行了，不能证明结论成立。

政府 / 标准 GAO 的数据可靠性框架以“数据是否适用于研究问题”为首要判断；英国政府数据质量框架给出六个质量维度；W3C PROV 用 Entity–Activity–Agent 追踪产物来源。见 GAO-20-283G、UK Government Data Quality Framework、W3C PROV。

查询契约的最低字段

query_id: customer-health-v3
question: "哪些客户在未来 30 天存在流失风险？"
source: crm-warehouse / snapshot=2026-09-06T00:00:00Z
authority: system-of-record | derived | advisory
purpose_limit: retention-analysis
schema_version: customer_health.v3
filters: { tenant_id, active=true, region }
freshness_slo: 24h
quality_gates: [completeness, uniqueness, validity, timeliness]
transformations: [timezone-normalize, deduplicate-by-customer-id]
provenance: [source_record_id, query_hash, retrieved_at]
empty_result: return NO_MATCH; never infer records
owner: revenue-ops
expires_or_review_at: 2026-12-01

工具契约：把开放能力改成窄动作

避免给模型 sql(query)、shell(command)、fetch(url)、send(anything) 之类开放工具。改为 get_order(order_id)、draft_refund(...)、apply_approved_refund(...)，并用版本化 JSON Schema 约束输入输出。

name: apply_approved_refund
version: 2.1.0
purpose: 对已批准订单执行退款
risk: high
input_schema: refund.input.v2.json
output_schema: refund.output.v2.json
auth: delegated_user; audience=payments-api; scope=refund:create
authorization: tenant + order_owner + refund_limit
approval: required; binds_to=canonical_request_hash
idempotency: required; reconcile=get_refund_by_key
timeout_ms: 5000
retry: only [429, selected_5xx, network_before_response]; max=3
logging: metadata_only; redact=[customer_name, payment_token]
owner: payments-team

官方事实 OpenAI function calling 使用 JSON Schema，并建议开启 strict mode；但 strict 只保证形状，不保证事实、业务合法或授权。见 Function calling。OWASP 将开放能力、过多权限与过度自治列为 Excessive Agency 根因，见 OWASP LLM06:2025。

权限、审批、幂等、重试与审计

计划—验证—执行—核验

用户意图
  ↓  身份 / 租户 / 目的 / 风险 / 预算
结构化计划（LLM）
  ↓  schema + 授权 + 策略 + 数据质量检查
审批（仅高风险；绑定确定性请求摘要）
  ↓  idempotency_key + deadline + 窄工具
外部执行
  ↓  回读权威系统 / 对账 / 业务不变量
带 provenance 的交付 + 脱敏审计事件

标准 / 官方事实 最小权限见 NIST SP 800-53 AC-6；OAuth 范围、audience 与资源约束见 RFC 9700；HTTP 幂等语义见 RFC 9110 §9.2.2；安全重试实践见 AWS Builders' Library。OpenAI 明确要求把 Skill 当成可能不可信的特权代码/指令，网络环境下防止提示注入与数据外泄，见 Skills API guide。

离线评测是发布门，在线评测是漂移雷达

Golden set 应混合真实生产样本、专家标注、历史事故和合成边界场景，覆盖常态、困难、空结果、多语言、长上下文、恶意输入、越权、工具失败与数据陈旧。每次 Skill、prompt、模型、工具 schema、政策或数据源变更都运行回归；非确定性任务重复采样并报告分布，而不是只跑一次。

SLO：以“合格任务”而非 API uptime 为核心

官方 / SRE OpenAI 建议评测贴近真实分布、覆盖典型/边缘/对抗案例、持续评测并用人工标签校准自动 grader，见 Evaluation best practices 与 Evaluate agent workflows。SLO 与 error budget 方法见 Google SRE。

版本、发布与回滚：让每次运行可复现

每次运行至少记录：skill_version、prompt hash、模型 snapshot、工具/schema 版本、数据源与快照、政策版本、eval 版本和时间。否则一次回归发生后，你无法回答“究竟什么变了”。

官方事实 Hosted Skills 支持 default_version、latest_version 和显式版本引用；默认版本不能直接删除，需要先切换。见 Skills API guide 和 Create an immutable skill version。本地 Skill 使用 Git/tag 是工程建议，不是 OpenAI 强制标准。

发布门禁

1. 静态结构校验通过，references 可发现，脚本已真实运行。
2. 代表性评测按风险切片无不可接受回归；高严重度失败为零。
3. 权限、审批、重试、幂等、对账、日志脱敏均有故障测试。
4. 上一稳定版本可取得，回滚步骤已演练，kill switch 有负责人。
5. 变更摘要说明影响、数据/模型依赖、已知限制和复审日。

个人、小团队、产品化：三种成熟度方案

升级条件：不是调用量一大就升档。出现多人协作、跨租户、高敏数据、不可逆外部动作、监管义务或明确 SLO 时，应提升控制成熟度；反之，不要为个人低风险流程制造企业级治理负担。

90 天实施路线

12 件 MVP 工件

1. 一页服务契约：触发、输入、输出、非范围、SLA、风险。
2. 代表性案例与结果证据集：不是只收集成功故事。
3. ACTA 任务图 + 知识审计：步骤、线索、取舍、新手误区。
4. 关键/失败事件 CDM：时间线、决策点、反事实。
5. 服务蓝图或泳道图：客户、前后台、支持与交接。
6. 决策表：输入、规则、冲突、信息不足与升级。
7. 异常/恢复表：触发、检测、暂停、补偿、沟通、负责人。
8. 数据与查询契约：来源、字段、时效、质量、provenance。
9. 逐步 SOP：动作、对象、条件、完成证据。
10. 关键暂停点检查表：短、可观察、可动作、可确认。
11. 验收测试集：常态、困难、边界、对抗、权限与故障。
12. 运行/异常/覆盖/变更日志：版本、证据、人工覆盖与学习。

可直接使用的 SOP 字段与 Skill 骨架

SOP 字段模板

SKILL.md 示例骨架

---
name: customer-renewal-brief
description: 为客户续约评审生成可追溯简报；适用于给定客户 ID 和评审日期的续约准备，不用于自动发送或修改 CRM。
---

# Outcome
生成符合 references/output-contract.md 的续约简报；所有关键判断带证据。

# Inputs
- customer_id（必需）
- review_date（缺失时询问，不推断）

# Workflow
1. 验证范围、身份与数据用途。
2. 读取 references/data-contract.md；运行只读 query_customer.py。
3. 数据未达新鲜度或字段冲突：停止并按 failure-playbook.md 处理。
4. 读取 references/decision-rules.md；输出 rule_id、reason_code、evidence_refs。
5. 按 assets/brief-template.md 生成草案。
6. 运行 verify_output.py；不通过则修正一次，否则升级。

# Authorization boundary
- 允许：读取授权客户数据、生成本地草案。
- 禁止：更新 CRM、发送邮件、承诺折扣。
- 外部写入只能在用户确认具体 diff 后交由独立工具执行。

# Evidence and stopping
- 空结果不得推断；标记 NO_DATA。
- 来源冲突不得静默择一；列出冲突并升级。
- 最多一次自动修正；仍失败则返回证据和阻塞原因。

官方事实 OpenAI 的本地 Skill 必须有带 name 和 description 的 SKILL.md；agents/openai.yaml 可声明 UI、隐式调用策略与 MCP 依赖。自动选择默认允许，只有明确希望“仅显式调用”时才关闭。见 Build skills。

常见失败模式，以及为什么会失败

什么时候不应自动化

“能让模型做”不是“应该让模型做”。人机分工应分别评估信息获取、分析、决策选择和动作执行，并考虑可靠性、后果、可逆性、接管成本与技能衰退。

• 结果无法验证：没有可观察反馈，也没有可信代理指标。
• 环境低效度：线索不稳定、规则快速变化、长期结果强随机，却要求系统复制“直觉”。
• 任务高度一次性或开放：战略、谈判、创作、伦理裁决没有稳定 SOP；最多稳定证据纪律和过程。
• 错误不可逆且高影响：付款、删除、发布、法律/医疗/人事决定，而审批、补偿和责任链尚未建立。
• 数据无权使用或不适用：来源、用途、时效、完整性无法证明。
• 第三方系统缺关键控制：无细粒度权限、幂等、状态查询或审计，又无法用网关/对账弥补。
• 例外比常态多：边界持续变化，人工升级率高到自动化只是在增加协调成本。
• 成本不成立：每个被接受结果的总成本（模型、API、人工、风险）不低于可靠人工流程。

研究证据 自动化会改变人的工作并产生新的协调要求，而非简单替代人。参见 Parasuraman, Sheridan & Wickens, 2000。NIST AI RMF 要求明确人机配置、知识边界、监督、覆盖、恢复和停用机制。

完整来源元数据

以下按本报告首次使用的大致顺序列出。网页来源的日期如未标注，统一以 2026-09-07 为访问日。报告只做短摘述，不复制长段原文。

研究限制

• CTA/ACTA/CDM 在一般知识工作与个人专业服务中的量化效果证据，弱于医疗、航空和军事领域；本报告做了相邻领域迁移。
• BPMN、DMN 与服务蓝图证明了表示法成熟和可交流，不证明单独使用就能改善业务结果。
• “从 SOP 到 LLM Skill”的长期实证仍稀缺；因此借用了人因、质量管理、安全工程和 SRE 的成熟原则，并明确标成工程建议。
• 不存在跨行业通用的访谈数量、golden set 样本量、准确率、抽检率、SLO 或日志保留期；应按业务风险与基线确定。
• 本报告不是法律意见。中国《个保法》、GDPR、行业监管、数据跨境与记录保留义务需按具体主体和数据另行评估。
• OpenAI 产品表面、模型和评测 API 会变化。2026-09-07 的官方文档提到旧 Evals 平台退役时间；实施前应重新核对最新替代接口，而方法论本身不依赖该旧界面。
• OpenTelemetry 的部分 GenAI 字段仍不稳定；内部事件模型应保持稳定，通过 exporter 映射外部语义版本。