补充模块：需求访谈与受控 AI 交付

资料状态：已蒸馏的课程补充，尚不代表任何学习者已掌握。 来源类型：本地学习资料的压缩方法框架 + 课程设计补充。 公开边界：不包含原始视频、完整转写、私人路径、账号信息、未核实数字或课程宣传。

用途

本模块补强课程 3、4、6、7：把模糊的业务抱怨转化为可验证问题，并把 AI 能力放进有人工确认、异常处理和验收标准的流程。

一、事件式需求访谈

不要从“你有什么痛点”开始。选择一个最近发生的具体事件，依次还原：

角色 → 目标 → 实际步骤 → 使用的系统/资料 → 卡点与例外 → 结果 → 可接受的改进

访谈产物不是访谈纪要，而是能用于决策的问题卡：谁受影响、频率和影响范围、当前处理成本、输入输出、限制条件、是否值得尝试。

二、流程还原与人工边界

对每一个系统步骤，明确：

系统可以辅助判断和整理，但不能默认替代最终责任人。涉及资格、报价、合同、盖章、提交或法律合规的动作，必须由授权人员执行和审核。

三、痛点量化

优先级不是看抱怨声音大小，而是结合：

影响范围 + 严重程度 + 发生频率 + 改进可行性 + 解决成本

这些维度用于讨论和排序，不是一个放之四海皆准的数学公式。数字或权重应来自实际业务记录，并在复盘中修正。

四、最小受控工程链

环境与密钥管理
→ API 服务层
→ 检索/模型能力
→ 工具调用
→ 输入校验、日志、异常和人工审核

• 不把密钥、地址或环境差异写死在代码和公开仓库；
• API 让能力可调用，不自动等于安全、稳定或可上线；
• 工具输入默认不可信，应在工具内部校验；
• 工具输出要包含足以判断结果、来源和异常的结构化信息；
• 具体模型、框架版本、服务价格、端口和参数必须以当前官方文档或实测环境为准。

五、练习任务

选择一个小业务流程，完成：

1. 一张事件式访谈问题卡；
2. 一张角色、输入、系统辅助、人工确认和异常处理表；
3. 一份痛点优先级说明，写明依据和未知项；
4. 一个只读或草稿型 AI 辅助步骤，保留人工审核点。

验收标准

• 能还原实际事件，而不是只列技术名词；
• 每个自动化动作都有输入、输出、责任人和异常处理；
• 没有把辅助标记写成最终资格、价格或合规结论；
• 明确哪些技术细节已经验证，哪些仍待确认；
• 产物可被下一阶段的方案设计直接使用。