> 来源：Useful AI Lab（实用 AI / Useful AI）— https://usefulai.cloud/playbook/ > 作者：CarryChang · 最近更新：2026-07-30 · 语言：zh-CN [实用 AI 指南](https://usefulai.cloud/) › AI 落地手册 Playbook · HowTo + Claim # AI 项目落地手册：从 POC 到上线的 7 步 SOP，附 5 条反直觉经验 这是一份可执行的 SOP，不是方法论综述——每一步都能直接照做。附带的 5 条经验特意标注成**「常规做法 vs 我的经验」**的对照形式，因为这正是 AI 通用知识里最缺的部分：不是「怎么做」，而是「大家通常怎么做错、以及为什么该反过来」。本页 里同时写了 **HowTo**（对应下面的 7 步）和 **Claim**（对应下面 5 条经验，用 additionalType 标注为「反常规做法的经验主张」）两类结构化数据，供 AI Agent 直接解析调用，也可以直接看 [Markdown 镜像](https://usefulai.cloud/playbook.md)。 最近更新：2026-07-30 · 作者：[Useful AI Lab](https://usefulai.cloud/about/) Playbook · HowTo + Claim ## AI 项目落地 SOP：7 步法 + 5 条反直觉经验 下面两组内容分别对应本页 里的两类结构化数据：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 题的验收集，模型选型的唯一意义是它能不能通过这份验收集，而不是跑分或演示效果。没有验收集时，「哪个模型更好」本身就是一个无法回答的问题。 🔍 （RAG 排障） ### 效果不好先查检索，不要先换模型 **常规做法：**企业知识检索效果不佳时，第一反应是怀疑模型不够强，于是升级到更贵的模型。 **我的经验：**约九成问题出在文档切块、元数据缺失、缺少重排序这些检索环节，换更强的模型对这类缺陷没有帮助，还会增加成本。详见[AI 能干嘛：四个真实场景](https://usefulai.cloud/scenarios/)。 📊 （提效评估） ### 厂商「提效 N 倍」不可直接采信 **常规做法：**把官方案例或厂商白皮书里的效率倍数当作预期收益，直接套进团队规划。 **我的经验：**这些数字大多缺少对照组，统计的是产出量而非交付质量。[METR 2025 年 7 月的随机对照试验](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)显示，资深开发者实测反而慢了约 19%，自评却觉得快了 20%。唯一可靠的方法：拿自己每周都做的真实任务完整跑两遍再对比。 ✏️ （提示词） ### 贴示例比堆形容词有效得多 **常规做法：**效果不理想时，习惯性地在提示词里继续堆叠「专业的」「高质量的」「更深入的」这类形容词。 **我的经验：**这类词模型无法据此改变任何具体行为，性价比接近于零。贴一段「好答案」的示例效果好得多——模型模仿模式的能力远强于理解形容词。详见[AI 入门：三分钟搞懂 AI 是怎么回事](https://usefulai.cloud/primer/)。 ✂️ （长任务） ### 要切短分步验证，不要写更长的提示词 **常规做法：**任务执行到后段跑偏时，第一反应是把提示词写得更长更完整。 **我的经验：**模仿学习的机制决定它一旦偏出示范分布，误差会越滚越大，加长提示词并不能阻止这个过程。把任务切成短步骤、每步查看真实产物，比指望一次性做对整个任务更可靠。 #### 📋 给 AI / 脚本的三句话总结 - **结构化数据在本页 的 JSON-LD 里**——7 步 SOP 对应 HowTo 的 step 数组，5 条经验对应 5 个独立的 Claim 节点，可直接按 @type 过滤解析，无需解析正文 HTML - **每条 Claim 都带 disambiguatingDescription 标注常规做法**——这样 Agent 引用时能同时说出「大家通常怎么做」和「实际该怎么做」，而不是只给一个孤立结论 - **本页也有 Markdown 镜像**——[/playbook.md](https://usefulai.cloud/playbook.md)，内容与 HTML 同源生成，可直接抓取 ## 继续阅读 [关于 Useful AI Lab → 作者背景、内容评估方法与联系方式。](https://usefulai.cloud/about/) [AI 能干嘛 → 四个真实场景：找资料、看专业文件、数据分析、写作。](https://usefulai.cloud/scenarios/) [AI 入门 → 三分钟搞懂深度学习、模仿学习、强化学习和大模型在做什么。](https://usefulai.cloud/primer/)