工作流 AI 机会地图（AI Opportunity Map）
这套方法在解决什么
大多数「AI 能帮我们做什么」的讨论会失败，是因为它停留在口号层面——每个人都同意 AI 有用，但没人知道下周该动哪一件事，也没人愿意为结论负责。
这套方法把那个会换掉议题：不再问「AI 能不能用」，而是产出一份每个环节都有编号、有级别、有判据引用、可以逐条反驳的清单。能被反驳，才值得讨论；能排序，才能决定先做哪个。
一句话总结产出：一份把「凭感觉讨论」变成「逐条可证伪」的工作流 AI 机会地图。
适用对象不限于建筑行业。设计院是原产地，但这套框架对任何「有人做判断、有人做搬运、有人做签章」的组织都成立——医院科室、律所、工厂车间、银行网点、政府办事窗口都可以直接套。换行业时读 references/variants.md。
一、开工前先定标（必做，不要跳过）
这一步决定了后面全部判断的基准。缺少任何一项就先去问用户，不要自己假设——基准错了，190 条判断会一起错。
| 变量 | 说明 | 为什么关键 |
|---|---|---|
{{机构}} |
被分析的对象（哪个行业、什么类型的组织） | 同为设计院，国有大院与深化设计公司的可替代比例能差一倍 |
{{覆盖范围}} |
要拆哪些部门/专业 | 先窄后宽。第一版建议锁 5–7 个板块，拆完再扩 |
{{技术水位基准年}} |
例如「2026 年」 | 定级会随监管与技术平移，必须写死一个基准年并写进报告，否则报告半年后就自相矛盾 |
{{现有工具栈}} |
现在用什么软件/系统 | 判断「落地难度」要用；已有工具能做的，别算成机会 |
{{交付形态}} |
单文件 HTML / Word / 表格 | 默认单文件 HTML，见第四步 |
{{红线}} |
不可触碰的边界 | 如「签章责任不可转移」「图纸不上公有云」。每家不同，必须问清 |
把这张表填好写在报告开头。这是唯一需要用户深度参与的地方，其余步骤可以自主推进。
二、七步工作流
第一步 · 行业水位调研
在动笔拆解前先摸清「现在实际做到哪一步」。跳过这步的定级必然飘——模型会按「AI 应该能做到」定级，而不是按「现在真的做到了」。
按 3–4 条线调研（如：创意生成线 / 生产制造线 / 审查合规线 / 经营管理线），每条线输出四件事：
- 代表产品（谁做的、什么形态：插件 / 独立软件 / 平台）
- 能力边界——能做到什么，明确做不了什么
- 已见成效——有具体数字就写（周期压缩、错误率下降），并标注是「厂商宣称」还是「第三方验证」及数据时间
- 受限原因——技术、数据、监管还是组织原因
硬要求：区分「已经普及」和「只有 demo」。只有 demo 的不要写成已落地。搜不到可靠信息就写「未找到可靠信息」，不要用推测填充。检索工具用 WebSearch；需要跨源比对时用 domain_search。
第二步 · 板块清单与阶段划分
先出清单，等用户确认后再展开。这一步的价值在于低成本纠偏——清单错了重来只花五分钟，拆完 190 条再发现错了就是一天。
格式：| 序号 | 板块 | 包含范围 | 工作性质（创意型/计算型/流程型/关系型） | 预估环节数 |
同时给出每个板块内部的阶段划分。阶段划分要贴合该专业真实的作业顺序，不要套统一模板——这是外行和行家的分水岭。
第三步 · 逐环节拆解（核心，质量瓶颈在这里）
一次只做一个专业。 不要一次写完所有板块：长文写到后面质量会衰减，而且用户在清单阶段无法整体判断粒度对不对。
流程是两段式：
1. 先只输出该板块的环节清单（编号 + 名称 + 级别 + 维度），让用户确认粒度
2. 确认后再补全每个环节的四段内容
环节的粒度标准、四段内容的具体要求、阶段内环节数区间、必须捕捉的三类「隐形环节」——见 references/framework.md。粒度是整件事最容易崩的地方，动笔前一定先读那一节。
第四步 · 定级对抗式复核
这一步是整份报告可信度的来源，不要省。 让模型换身份，作为最严厉的质疑者攻击自己的定级，找五类问题（判据与结论矛盾、同类不一致、定级理由空转、隐性责任漏判、过度乐观）。
复核完统计：一共几条问题、其中会改变级别的几条。如果一条都没发现，判定为没认真查，重新逐条过一遍。
判据体系、评分锚点、定级映射规则、分布自检基准——见 references/judgment.md。
第五步 · 优先级打分矩阵
回答「先做哪个」。先定锚点再打分，否则分数没法对齐（不给锚点，模型会全给中间档）。
从全部环节中筛出「有明确 AI 介入价值」的（经验值约 40%），逐条给四个维度打分并算 P 值：
P = 提效幅度E × 0.35 + 替代可能R × 0.25 + (6 − 落地难度D) × 0.25 + (6 − 责任风险K) × 0.15
注意 D 和 K 是难度/风险，5 分代表最差，公式里做减分项。产出按 P 降序的完整表 + 前 12 名 + 三条归纳结论。锚点定义见 references/judgment.md。
第六步 · 生成单文件 HTML 报告
用捆绑脚本生成，不要手写 HTML：
python scripts/build_report.py --data <你的 data.json> --out <输出.html>
报告规格、数据 schema、以及这套报告最关键的交互设计（「页面上每一个数字都是一道门」的通用钻取机制）——见 references/html-spec.md。开始做报告前必读，否则会做出一个「能看不能查」的静态页，那等于浪费了整份数据的价值。
第七步 · 交付前自检（必须真跑，不许只说「已检查」）
python scripts/verify_report.py --html <输出.html> --data <你的 data.json>
脚本会校验数字一致性、标签平衡、零外部依赖，并用无头浏览器实测筛选与钻取是否真的生效。逐项报告「通过 / 不通过 + 具体证据」，不通过的直接修掉再报一次。
自检项清单与常见的七类翻车对照表见 references/quality.md。
三、三条铁律（违反任何一条，成果都会失去讨论价值）
1. 判据③④⑤是否决权，①②只是可行性。
技术上完全可做、但涉及签章或法定责任的环节，一律不进「可替代」。必须到现场的，直接判「暂不可替代」或只给前后置辅助。
这条是整套方法最反直觉、也最值钱的地方。它解释了为什么 AI 在专业组织里会从「不签字的活」倒推着落地。如果一份分析里所有技术可行的环节都判成了可替代，说明它没理解责任结构，回去重判。
2. 每条定级都必须可被反驳。
判据引用与结论对不上，等于没写。禁止出现「规则明确，适合自动化」这类装饰性判据——必须落到具体判据编号 + 高/中/低 + 一句「卡在哪里」。
3. 出稿前跑分布自检。
四个级别的占比应大致落在 A 15–20% / B 50–60% / C 15–20% / D 8–12%。偏了就回去重判，不要直接交付：
- B 超过 70% → 没有区分「能出初稿」和「能直接替代」
- A 超过 30% → 大概忽略了签章责任，重点复查所有对外交付物
- D 少于 5% → 把组织想得太弱了，对外博弈、现场决策、方案立意都不该低于 10%
分布自检不是为了让数字好看，而是把「有没有偷懒」变成可测量的信号。
四、交付物
默认产出一份单文件 HTML 讨论底稿：零外部依赖、双击离线可开、可以直接发给别人。
三个必须有的东西：
- 一句话结论先行 —— 放在封面。管理层只看这一屏。
- 每个环节能展开 —— 做什么 / 输入产出 / AI 怎么介入 / 为什么定这个级。四段齐全。
- 结论层 —— 每个板块给小结；结尾给 6–8 个「答案不在报告里，只在你那儿」的待议问题，让读者带着去开会。
再加两条业界惯例：报告必须显式声明技术水位基准年；全篇必须有「不该做什么」的判断（D 类不能少于 8%，否则是讨好型输出）。
五、路由表
| 你现在要做的 | 读哪份 |
|---|---|
| 拆解环节、定粒度、划阶段、识别隐形环节 | references/framework.md |
| 定级、写判据、打分、跑分布自检 | references/judgment.md |
| 生成网页报告、做钻取交互 | references/html-spec.md |
| 换行业 / 换组织类型 / 压力测试 / 单点深挖 | references/variants.md |
| 交付前自检、避坑、法规锚定 | references/quality.md |
| 看一个跑通的完整实例 | assets/data.example.json |
六、不要做的事
- 不要跳过定标。 基准年、红线、覆盖范围缺一项，后面全白做。
- 不要一次拆完所有板块。 质量在第三个板块之后会明显衰减，而且用户失去了在低成本时纠偏的机会。
- 不要手写 HTML。 用脚本。手写必然出现统计数字与环节数对不上——这是本项目历史上最常见、最顽固的错误。
- 不要接受「一条问题都没发现」的复核结果。 那等于没做复核。
- 不要交付一份全是「可替代」或全是「提效」的报告。 没有「别碰」的档，筛选器就筛不出「不该投钱」的区域，而这恰恰是决策最需要的一栏。
- 不要在报告里写「AI 前景广阔」这类话。 每一条结论都要能从表里读出来。
- 不要编造。 产品、厂商、成效数据必须标来源与时间；无法核实的写「厂商宣称」或「待核实」。
