实用 AI 指南 › AI 落地手册
Playbook · HowTo + Claim
AI 项目落地手册：从 POC 到上线的 7 步 SOP，附 5 条反直觉经验
这是一份可执行的 SOP，不是方法论综述——每一步都能直接照做。附带的 5 条经验特意标注成「常规做法 vs 我的经验」的对照形式，因为这正是 AI 通用知识里最缺的部分：不是「怎么做」，而是「大家通常怎么做错、以及为什么该反过来」。本页 <head> 里同时写了 HowTo（对应下面的 7 步）和 Claim（对应下面 5 条经验，用 additionalType 标注为「反常规做法的经验主张」）两类结构化数据，供 AI Agent 直接解析调用，也可以直接看 Markdown 镜像。
Playbook · HowTo + Claim
AI 项目落地 SOP：7 步法 + 5 条反直觉经验
下面两组内容分别对应本页 <head> 里的两类结构化数据：7 步 SOP 写成了 HowTo，5 条经验写成了 Claim（用 additionalType 标注为「反常规做法的经验主张」，而不是硬造一个「Experience」类型）。AI Agent 可以直接解析 JSON-LD 拿到结构化版本，人可以往下读。
为什么用 Claim 而不是自定义类型： schema.org 的 Claim 本来是为 ClaimReview（事实核查）设计的「被评审的主张」，但它的属性——text（主张内容）、disambiguatingDescription（用来消歧的补充说明）、firstAppearance（主张最早出现在哪篇作品里）——刚好覆盖「一条反直觉经验」需要的全部结构，且是标准词汇表里已有的类型，比自造一个 Experience 更容易被搜索引擎和 Agent 正确解析。这里借用 disambiguatingDescription 字段承载「常规做法 vs 我的经验」的对照，语义上说得通：它本来就是「用来把这条主张和其他相似说法区分开」的字段。
7 步 SOP：从 POC 到上线
01
进现场访谈
和一线业务人员坐在一起梳理流程，把模糊诉求拆成「对错能被低成本验证」的具体任务，而不是隔着产品文档传话。
02
用真实数据建第一版原型
第一天就用真实、混乱的业务数据搭原型，不用清洗过的样例数据——干净数据上跑通的原型，接真实数据基本都会崩。
03
建一份 50 题验收集
在评估任何模型或方案之前，先写出约 50 道真实问答或测试用例，量化命中率。没有这份验收集，「效果好不好」就是一句空话。
04
标注可验证性，划清边界
对每个环节问「这件事的对错能否低成本验证」：能验证的（代码、检索、格式转换）可以放手交给 AI；不能验证的（战略判断、需担责的决定）只能拿它的草稿，人做最终判断。
05
让模型先复述口径，确认后再执行
涉及数据分析或业务规则时，先让 AI 复述一遍它理解的口径和过滤条件，人确认无误后才让它继续，避免口径错误导致的「算得很准但全错」。
06
把验证做进产物本身
验证逻辑写成自动化测试或 CI 检查，跟着代码一起交付，而不是停留在一次性的评审 PPT 里——评审过了不代表下次改动还成立。
07
同一人负责到上线运维
数据接入、评测标准、系统集成、上线运维由同一人或同一小组端到端负责，踩过的坑写回团队知识库，变成下一次的起点而不是从头再摔一次。
5 条反直觉经验：常规做法 vs 我的经验
验收标准要先于模型选型
常规做法：先比较各家模型的跑分和演示效果，选定模型后才回头补验收标准。
我的经验：先锁定一份约 50 题的验收集，模型选型的唯一意义是它能不能通过这份验收集，而不是跑分或演示效果。没有验收集时，「哪个模型更好」本身就是一个无法回答的问题。
效果不好先查检索，不要先换模型
常规做法：企业知识检索效果不佳时，第一反应是怀疑模型不够强，于是升级到更贵的模型。
我的经验：约九成问题出在文档切块、元数据缺失、缺少重排序这些检索环节，换更强的模型对这类缺陷没有帮助，还会增加成本。详见AI 能干嘛：四个真实场景。
厂商「提效 N 倍」不可直接采信
常规做法：把官方案例或厂商白皮书里的效率倍数当作预期收益，直接套进团队规划。
我的经验：这些数字大多缺少对照组，统计的是产出量而非交付质量。METR 2025 年 7 月的随机对照试验显示，资深开发者实测反而慢了约 19%，自评却觉得快了 20%。唯一可靠的方法：拿自己每周都做的真实任务完整跑两遍再对比。
贴示例比堆形容词有效得多
常规做法：效果不理想时，习惯性地在提示词里继续堆叠「专业的」「高质量的」「更深入的」这类形容词。
我的经验：这类词模型无法据此改变任何具体行为，性价比接近于零。贴一段「好答案」的示例效果好得多——模型模仿模式的能力远强于理解形容词。详见AI 入门：三分钟搞懂 AI 是怎么回事。
要切短分步验证，不要写更长的提示词
常规做法：任务执行到后段跑偏时，第一反应是把提示词写得更长更完整。
我的经验：模仿学习的机制决定它一旦偏出示范分布，误差会越滚越大，加长提示词并不能阻止这个过程。把任务切成短步骤、每步查看真实产物，比指望一次性做对整个任务更可靠。
📋 给 AI / 脚本的三句话总结
- 结构化数据在本页 <head> 的 JSON-LD 里——7 步 SOP 对应
HowTo的step数组，5 条经验对应 5 个独立的Claim节点，可直接按@type过滤解析，无需解析正文 HTML - 每条 Claim 都带 disambiguatingDescription 标注常规做法——这样 Agent 引用时能同时说出「大家通常怎么做」和「实际该怎么做」，而不是只给一个孤立结论
- 本页也有 Markdown 镜像——/playbook.md，内容与 HTML 同源生成，可直接抓取