AI 怎样从业务事实生成候选 Spec
一句话收获：AI 负责生成，人负责事实、边界和证据准入。
这个场景在解决什么问题
目标（goal）是理解"事实 → 未知 → 候选生成 → 人工审查 → 外部验收"这一条顺序。观察方式是让 AI 先整理材料，再生成和修订 Spec（规格说明）。值得单独学，是因为 AI 特别能"快速拼出一份像样的文档"，但"像样"不等于"正确"，必须靠人来把关事实、边界和证据准入。
先理清这条判断链（文字版）
先让 AI 把原始材料整理成事实、规则、假设、偏好、方案、未知六类，再让 AI 生成候选 Spec 初稿，接着由人审查并指出缺口，最后让 AI 根据补充修订并由外部验收放行。判断链是：
- 让 AI 先区分信息身份，把材料分类，避免把建议写成事实。
- 让 AI 基于分类生成结构完整的候选 Spec 初稿。
- 由人工审查者指出目标偷换、事实臆造、范围扩张、验收不足等问题。
- 让 AI 根据补充事实和反例修订，经外部验收确认当前基线可用。
逐层详解
第 1 步：整理事实
原文：AI 将原始材料分成事实、规则、假设、偏好、方案和未知。
白话：AI 先把一堆原始材料分门别类，标清楚哪些是"确凿的事实"、哪些是"必须遵守的规则"、哪些是"待验证的假设"、哪些是"主观偏好"、哪些是"可选方案"、哪些是"还不清楚的未知项"。
类比：像整理房间先把东西分类——衣服归衣服、证件归证件、垃圾归垃圾，分完才知道什么能扔、什么要收好、什么还缺。
举例：一个客服工单系统需求材料里，"工单有 7 种状态"是事实，"超过 24 小时未响应必须升级"是规则，"用户一般晚上投诉多"是假设，"界面要简洁"是偏好，"可以接电话或邮件通道"是方案，"数据迁移成本"是未知项——AI 先把这些身份标清楚。
为什么重要：先区分信息身份，避免把建议写成事实——如果分不清"我认为"和"事实是"，后面整个 Spec 都会建立在沙子地上。
怎么验证（证据点）：
- 事实有来源：每条事实都能找到出处。
- 假设已标记：假设被明确标出来，不冒充事实。
- 未知仍保留：没搞清楚的地方没有被硬填成答案。
别踩的坑（边界）：分类完整不代表事实已经权威确认——分得再整齐，也不能证明这些事实本身是可信的。
落地检查：先确认事实质量——落地时第一步就核对事实的来源和可信度，而不是急着往下生成。
第 2 步：生成候选 Spec
原文：AI 形成目标、范围、对象、状态、异常、停止和验收初稿。
白话：AI 基于整理好的材料，产出一份规格说明初稿，涵盖目标、范围、处理对象、状态、异常处理、停止条件、验收标准这些板块。
类比：像实习生根据你给的资料，先搭出一份完整的方案框架，框架看着齐全，但内容对不对还得你逐条审。
举例：AI 基于工单需求，生成候选 Spec 初稿，写明"目标是把工单及时闭环、范围覆盖邮件和电话通道、对象是工单、状态含 7 种流转、异常含超时升级、停止条件、验收标准"等。
为什么重要：AI 擅长快速组织完整候选——AI 的长处就是快速把零散信息拼成结构完整的文档，这正是它该干的活。
怎么验证（证据点）：
- 结构完整：各板块齐不齐。
- 未知单列：未知项被单独列出来，没有被假装解决。
- 来源可回查：每处内容能回到原始材料溯源。
别踩的坑（边界）：完整外观不证明语义正确——文档长得再全，内容可能是错的、偷换的、臆造的。
落地检查：候选必须回到原始事实审查——落地时拿到初稿别急着用，逐条拿它对照原始事实审。
第 3 步：人工发现缺口
原文：审查者指出目标偷换、事实臆造、范围扩张和验收不足。
白话：人来审这份候选 Spec，专门挑四类毛病：目标是不是被偷偷换掉了、有没有凭空编造的事实、范围是不是被顺手扩大了、验收标准是不是不够硬。
类比：像老师批改论文，不是挑错别字，而是看结论是不是偷换了论点、数据是不是编的、讨论范围是不是跑偏了、怎么算合格有没有说清。
举例：审查者发现候选 Spec 把目标从"及时处理工单"偷换成了"自动化一切工单"，把一句没有来源的"客户要求 1 小时内响应"当成事实写进去，范围从"邮件通道"扩张到"所有渠道"，验收标准写成了"界面好看"这种没法测的东西。
为什么重要：人掌握业务目的和责任边界——AI 不知道业务里什么最重要、谁该为结果负责，这些只有人心里有数。
怎么验证（证据点）：
- 缺口明确：到底缺什么、错哪里说得清。
- 证据要求明确：缺的内容需要补什么证据，说得清。
- 不可补全项明确：哪些是补不出来的，明确标记。
别踩的坑（边界）：人工审查不是逐字润色——审查不是帮 AI 把文字改通顺，而是盯系统成立的关键条件。
落地检查：审查关注系统成立条件——落地时审查的重点是"这个系统能不能立得住"，而不是文笔。
第 4 步：AI 修订与放行
原文：AI 根据补充事实和反例修订，外部验收确认当前基线可用。
白话：人把缺口和补充事实、反例丢回给 AI，AI 据此修订 Spec；修订后再由外部（不参与生成的机制）验收，确认这份基线现在可用了。
类比：像老师指出问题、学生改稿、再由第三方（如答辩委员会）确认这版能不能通过。
举例：审查者补充了真实响应时间数据、给出"某类工单不能自动处理"的反例，AI 据此修订 Spec，最后外部验收确认这版基线可以进入实现阶段。
为什么重要：人和 AI 形成生成—审查—修订闭环——AI 生成、人审查、AI 修订，人机来回形成闭环，质量才逐步收敛。
怎么验证（证据点）：
- 差异可见：改了哪里、前后差异能看得到。
- 关键边界有载体：重要的边界都落在了明确的文档/规则载体上。
- 验收条件可执行：验收标准是可执行的，不是空话。
别踩的坑（边界）：Spec 放行不等于实现完成——Spec 通过审查只是"蓝图定了"，不代表代码实现已经做完做对。
落地检查：后续仍由 Harness 和测试验证实现——放行 Spec 后，真正实现还得靠 Harness 和测试去验证，不能以为万事大吉。
落地可行性小结
本场景涉及的技术栈：AI 生成 Spec（用 LLM 做信息分类 + 文档生成）、人工审查（人参与把关）、外部验收机制。落地动作：设计一个固定的 Spec 结构模板（目标、范围、对象、状态、异常、停止、验收），让 AI 先按"事实/规则/假设/偏好/方案/未知"分类材料再生成；人重点审目标偷换、事实臆造、范围扩张、验收不足四类问题；修订后由独立机制验收。常见坑：一是把 AI 生成的"结构完整"误当"内容正确"；二是人工审查沦为改错别字。检查点：每条事实是否有来源、每个未知项是否单列、验收条件是否可执行。
回顾
- 先区分信息身份（事实/规则/假设/偏好/方案/未知），避免把建议写成事实。
- AI 负责快速生成结构完整的候选，但"完整外观"不等于"语义正确"。
- 人负责审查，重点盯目标偷换、事实臆造、范围扩张、验收不足，而不是逐字润色。
- 生成—审查—修订形成闭环，但 Spec 放行不等于实现完成，后续仍需 Harness 和测试验证。