尧图网站建设 
核心命题一张需求卡把模糊诉求翻译成可验收的工程语言。一句话带走六格填满、四步走完、一句检查——客户的模糊诉求才能变成能开发、能验收、能追责的工程语言。AI 项目最容易从一句正确但无法执行的话开始「我们希望用 AI 提升效率。」这句话描述了方向却没有说明效率发生在哪个环节、由谁感知、需要哪些数据、允许系统做出什么动作。如果直接从这句话开始设计功能团队通常会先做聊天界面、接入模型再回头补业务规则。结果是 Demo 可以展示验收却没有标准客户也很难判断系统到底解决了什么问题。这个问题的根源在于客户用业务语言描述诉求「提升效率」「辅助决策」研发用工程语言实现方案输入是什么、输出是什么、错了怎么办。两者之间隔着一个翻译层——如果不做这层翻译研发只能猜猜出来的东西验收时必然对不上。客户验收时只会说「感觉不好用」团队不知道改哪里项目陷入无限改 prompt 的循环。本章讲清楚一件事怎么用一张「需求卡」把客户的模糊诉求翻译成能开发、能验收、能追责的工程语言。具体解决三个问题需求卡到底填什么六个字段怎么从客户访谈里把六个字段挖出来四步流程怎么判断一张需求卡是否合格检查句式。一、需求翻译的六个字段一张合格的 AI 需求卡至少要回答六个问题。每个字段都对应一个「不填就会出事」的坑字段 1业务场景——谁在什么情况下做什么动作。要写成「动词 宾语 触发条件」而不是一个名词。错误写法「智能问答助手」。正确写法「当销售在周五复盘前打开助手时系统读取其有权访问的客户跟进记录生成本周进展摘要。」前者没法开发后者能直接拆成接口。字段 2输入数据——系统读什么数据从哪来谁能看。写清数据源系统CRM、工单、知识库、数据范围本团队还是全公司、权限依据按组织架构还是按项目。这一栏空着上线后大概率出越权事故。字段 3输出物——AI 要产出什么长什么样。不只是「一段回答」而是具体的交付物摘要的固定结构进展/风险/待办三段、引用标注的位置、导出格式。输出物不确定验收就没标准。字段 4验收标准——用什么数字判断做得好。分四类写业务结果是否节省录入时间、内容质量摘要是否遗漏关键事实、安全合规是否出现越权访问、运营效果目标用户是否持续使用。每类至少一个可测量的指标。字段 5边界——明确不做什么。「生成 CRM 修改建议」可以做「直接写入 CRM」首期不做。边界必须在开发前锁定否则上线当天才发现客户预期和交付物对不上。字段 6责任人与失败兜底——谁验收出错谁接管。每个验收指标要有一个具名的确认人不是「业务方」这种集体名词同时写清无答案、权限不足、数据过期、工具失败时系统怎么办、人从哪里接管。一张填好的需求卡长这样销售助手示例字段填写内容业务场景销售每周五 16:00 前打开助手自动生成本周客户跟进摘要输入数据CRM 跟进记录仅本人及下属客户主数据脱敏后输出物三段式摘要进展/风险/待办每条带 CRM 记录链接验收标准摘要遗漏关键事实率 5%销售周均使用 ≥3 次零越权访问边界只生成建议不写回 CRM不接入财务数据责任人与兜底验收人销售运营总监张某无数据时提示「本周无跟进记录」而非编造二、从访谈到需求卡的实践流程整体流程是先用开放式问题还原真实工作流第一步再把听到的内容改写成工程语言第二步然后定验收第三步、锁边界第四步。四步走完六个字段就自然填满了。第一步先问工作动作不先问模型不要先问「你想用什么大模型」而要先问•你现在完成这项工作需要经过哪些步骤•哪一步最耗时•哪一步最容易出错•你需要查看哪些系统•哪些结果必须由人确认•如果 AI 给错了谁承担后果这些问题能把「想用 AI」还原成真实工作流。前三个问题定位场景字段 1第四个定位数据源字段 2后两个定位责任和兜底字段 6。第二步把场景写成动词加宾语「智能问答」「提升效率」「辅助决策」都太抽象。一个好的场景描述应该包含触发条件、动作和输出当销售在周五复盘前打开助手时系统读取其有权访问的客户跟进记录生成本周进展摘要、风险事项和待办建议并标注每条信息的来源。检验方法把这句话拿给一个不了解项目的研发看他能直接开始拆接口这句话就合格了。第三步把验收标准分成四类•业务结果是否节省录入时间、减少重复查询或缩短响应时间。•内容质量回答是否包含依据摘要是否遗漏关键事实。•安全合规是否出现跨租户、跨团队或越权访问。•运营效果目标用户是否持续使用人工修改率是否下降。为什么要分四类因为验收会上四类指标的确认人不一样业务结果归业务负责人内容质量归一线用户代表安全合规归 IT/合规运营效果要看上线后的数据。混在一句话里等于没人负责。第四步在开发前锁定边界「不做什么」必须与「做什么」同时确认。对销售 AI 助手而言生成 CRM 修改建议可以作为试点功能直接写入 CRM 则应被排除在首期范围之外。三、常见错误1. 把客户的解决方案当成需求客户说「我要一个 RAG 知识库」真正需求可能是「客服在回答退换货问题时希望三分钟内找到最新政策」。前者规定了技术后者才描述了业务问题。拿到前者要做的事是追问「你想用它解决谁的什么问题」2. 只有功能没有责任人每个验收指标都需要一个确认人。没有验收人指标最终会变成团队内部的自评——自己出题自己判卷验收会必然扯皮。3. 只有成功路径没有失败路径需求卡应写明无答案、权限不足、数据过期、工具失败和人工接管等情况。AI 系统一定会出错需求阶段不设计失败路径等于把失败路径的设计权交给了用户的第一次事故。4. 把所有数据都放进首期范围首期应优先选择一个高频、数据边界清楚、结果可验证的场景。数据源越多治理和验收成本越高。先跑通一个场景建立信任第二期再扩。四、关键知识点总结需求卡不是缩短版 PRD而是面向交付协作的共同契约。它必须同时让业务方看懂目标让研发知道输入输出让合规方看清边界让测试人员有明确的验收方法。可以用下面的句式检查一条需求是否足够具体当【谁】在【什么情况下】系统用【哪些数据、什么权限】生成【什么输出、什么格式】由【哪个具名的人】用【什么指标】验收出现**【哪些失败情况】时转人工处理。套用到销售助手的例子就是「当销售在每周五复盘前系统用他有权访问的 CRM 跟进记录生成三段式摘要由销售运营总监按「关键事实遗漏率 5%」验收无数据或权限不足时明确提示、不编造。」只要这句话里还有一个【】填不上就说明项目还没有进入稳定开发阶段——缺哪个格子就回访谈里补哪个问题。把本章翻译成 AI FDE hub 工程契约AI FDE 如何把客户问题变成可交付需求 这件事最终要落到一份能被四方签收的契约上。下面这份 YAML 就是它的字段模板# AI FDE hub · 需求卡 · 工程契约示例 chapter: 002 framework: AI FDE hub 三段式交付入场 / 搭建 / 离场 tags: [AI, 需求分析, 需求卡, 业务翻译] requirement_card: scenario: 谁在什么情况下做什么动作动词宾语触发条件 input_data: 数据源系统 数据范围 权限依据 output: 输出物结构与格式含引用标注要求 acceptance: 业务结果 / 内容质量 / 安全合规 / 运营效果 四类指标 boundary: 首期明确不做什么 owner_and_fallback: 具名验收人 无答案/越权/过期/失败的处理路径 scope: role: AI FDE 工程师 boundary: 对接客户业务负责人、合规、研发、测试四方共同验收和相邻章节的关系本章与前后相邻的第 1 章《AI FDE 的职责模型把交付现场变成可复用能力》、第 3 章《AI 项目数据接入从数据源盘点到可用知识》同处一个主题段共用同一套「产物 退出条件 决策门」语言可跨阶段拼装成完整交付链路。Toy Project vs. 生产级系统 · 8 项关键差异这张表聚焦「Toy 与生产级」最容易暴露差距的地方——每一行都是一次真实的取舍停在 Toy 水平省下的是当下的工作量付出的是上线后的返工和事故。最右一列写的就是这笔账。维度Toy Project生产级系统差距代价数据隔离单一租户演示数据多租户隔离 团队粒度过滤测试数据混进生产库一次越权就是合规事故权限控制硬编码角色RBAC 字段级脱敏一个角色能看到全公司数据审计时说不清谁看过错误处理try/catch 静默失败结构化异常 降级路径出错没人知道用户只能反复重试到放弃性能保证Demo 流畅即可延迟 / 吞吐 / 成本三指标 SLA演示不卡上线后高峰期直接超时知识时效训练截止知识实时检索 版本化文档用户照着已作废的条款执行损失无法追溯审计追踪无日志调用链 引用溯源出事查不到谁在什么时候问了什么、答了什么成本控制不计 Token 成本路由 缓存 配额用户量一上来账单跑得比业务增速还快可演进性单体脚本可观测 可替换 可灰度换一个模型要改全量代码只能推倒重做客户现场最常见的三种反模式这三种做法在需求阶段反复出现共同点是都在用「先做出来」回避「先想清楚」。提前识别比事后补救成本低一个数量级。反模式典型表现正确做法不推荐原因跳过业务翻译直接写代码客户刚说完业务痛点就立刻动手没还原现状与约束先把痛点翻译成可验证任务再决定技术方案代码写完才发现做的是另一个问题返工等于重做用技术方案替代需求分析客户说「我们要上 RAG」团队直接选型向量库不问业务问题先还原业务场景再选技术方案技术选型锁死了试错空间后面改方案成本极高没有边界就上线Demo 通过即交付边界问题「后续再说」需求卡写明首期不做什么其余走变更流程上线当天才发现客户预期和交付物对不上附录需求卡速查一句话记法需求卡 六格 × 四步 × 一式检查——场景、输入、输出、验收、边界、责任人兜底六格填满才算立项。本章机制 / 分工表四类验收指标归谁验收类别确认人该看什么业务结果业务负责人是否节省录入时间、减少重复查询、缩短响应内容质量一线用户代表回答是否包含依据、摘要是否遗漏关键事实安全合规IT / 合规是否出现跨租户、跨团队或越权访问运营效果上线后的使用数据目标用户是否持续使用、人工修改率是否下降边界表首期做 / 不做首期做首期不做生成 CRM 修改建议销售助手试点直接写入 CRM一个高频、数据边界清楚、结果可验证的场景把所有数据都放进首期范围现场症状 → 根因判断 → 先做什么 → 不该做什么现场症状根因判断先做什么不该做什么客户张口就说「我要一个 RAG 知识库」把客户的解决方案当成了需求追问「你想用它解决谁的什么问题」直接选型向量库验收会上没人拍板指标变团队自评验收指标缺具名确认人给每个指标指定一个具名的人用「业务方」这类集体名词兜底用户反复重试到放弃没人知道出错只设计了成功路径需求阶段就写清无答案 / 越权 / 过期 / 工具失败时怎么办把失败路径的设计权交给用户的第一次事故首期把全量数据源都接进来范围太大治理与验收成本失控先跑通一个场景建立信任第二期再扩把二期能力硬塞进首期改来改去仍是「感觉不好用」输出物没定结构、验收没标准固定输出物结构如三段式摘要靠无限改 prompt 打补丁客户催着「先做出来」用先做回避先想清楚先用检查句式把【】逐个填满Demo 通过即交付一个判断顺序先问工作动作不问模型→ 再把场景写成动词加宾语 → 然后分业务结果 / 内容质量 / 安全合规 / 运营效果四类定验收 → 最后在开发前锁边界句式里只要还有一个【】填不上就回访谈补对应的问题不要进入开发。一句收尾客户给出的永远是「想要的东西」需求卡要把它还原成「要解决的问题」——这中间隔着的不是一次会议而是六个必须逐个填满的格子。和相邻章节的关系本章承接第 1 章《AI FDE 的职责模型把交付现场变成可复用能力》厘清的职责产出的需求卡又是第 3 章《AI 项目数据接入从数据源盘点到可用知识》做数据接入前的输入约束三章同处一个主题段共用同一套「产物 退出条件 决策门」语言。思考题客户说「我们想要一个像 ChatGPT 那样的企业助手」这句话里有几个字段是空的参考答案六个全空。没有具体的人谁用、没有触发场景什么时候用、没有数据范围读什么、没有输出物产出什么、没有验收标准什么叫好、没有边界不做什么。AI FDE 的第一步不是讨论接哪个模型而是用第一节的六个问题把这句话还原成一张能填满的需求卡。换个说法客户给出的永远是一个「想要的东西」而需求卡要做的是把它还原成一个「要解决的问题」。前者是客户的解决方案后者才需要研发投入。这两者之间隔着的不是一次会议而是六个必须逐个填满的格子。AI FDE hub本文由 AI FDE hub 出品关注「AI PDE 陪跑计划」获取 AI 现场交付方法论 AI FDE 如何把客户问题变成可交付需求
核心命题一张需求卡把模糊诉求翻译成可验收的工程语言。一句话带走六格填满、四步走完、一句检查——客户的模糊诉求才能变成能开发、能验收、能追责的工程语言。AI 项目最容易从一句正确但无法执行的话开始「我们希望用 AI 提升效率。」这句话描述了方向却没有说明效率发生在哪个环节、由谁感知、需要哪些数据、允许系统做出什么动作。如果直接从这句话开始设计功能团队通常会先做聊天界面、接入模型再回头补业务规则。结果是 Demo 可以展示验收却没有标准客户也很难判断系统到底解决了什么问题。这个问题的根源在于客户用业务语言描述诉求「提升效率」「辅助决策」研发用工程语言实现方案输入是什么、输出是什么、错了怎么办。两者之间隔着一个翻译层——如果不做这层翻译研发只能猜猜出来的东西验收时必然对不上。客户验收时只会说「感觉不好用」团队不知道改哪里项目陷入无限改 prompt 的循环。本章讲清楚一件事怎么用一张「需求卡」把客户的模糊诉求翻译成能开发、能验收、能追责的工程语言。具体解决三个问题需求卡到底填什么六个字段怎么从客户访谈里把六个字段挖出来四步流程怎么判断一张需求卡是否合格检查句式。一、需求翻译的六个字段一张合格的 AI 需求卡至少要回答六个问题。每个字段都对应一个「不填就会出事」的坑字段 1业务场景——谁在什么情况下做什么动作。要写成「动词 宾语 触发条件」而不是一个名词。错误写法「智能问答助手」。正确写法「当销售在周五复盘前打开助手时系统读取其有权访问的客户跟进记录生成本周进展摘要。」前者没法开发后者能直接拆成接口。字段 2输入数据——系统读什么数据从哪来谁能看。写清数据源系统CRM、工单、知识库、数据范围本团队还是全公司、权限依据按组织架构还是按项目。这一栏空着上线后大概率出越权事故。字段 3输出物——AI 要产出什么长什么样。不只是「一段回答」而是具体的交付物摘要的固定结构进展/风险/待办三段、引用标注的位置、导出格式。输出物不确定验收就没标准。字段 4验收标准——用什么数字判断做得好。分四类写业务结果是否节省录入时间、内容质量摘要是否遗漏关键事实、安全合规是否出现越权访问、运营效果目标用户是否持续使用。每类至少一个可测量的指标。字段 5边界——明确不做什么。「生成 CRM 修改建议」可以做「直接写入 CRM」首期不做。边界必须在开发前锁定否则上线当天才发现客户预期和交付物对不上。字段 6责任人与失败兜底——谁验收出错谁接管。每个验收指标要有一个具名的确认人不是「业务方」这种集体名词同时写清无答案、权限不足、数据过期、工具失败时系统怎么办、人从哪里接管。一张填好的需求卡长这样销售助手示例字段填写内容业务场景销售每周五 16:00 前打开助手自动生成本周客户跟进摘要输入数据CRM 跟进记录仅本人及下属客户主数据脱敏后输出物三段式摘要进展/风险/待办每条带 CRM 记录链接验收标准摘要遗漏关键事实率 5%销售周均使用 ≥3 次零越权访问边界只生成建议不写回 CRM不接入财务数据责任人与兜底验收人销售运营总监张某无数据时提示「本周无跟进记录」而非编造二、从访谈到需求卡的实践流程整体流程是先用开放式问题还原真实工作流第一步再把听到的内容改写成工程语言第二步然后定验收第三步、锁边界第四步。四步走完六个字段就自然填满了。第一步先问工作动作不先问模型不要先问「你想用什么大模型」而要先问•你现在完成这项工作需要经过哪些步骤•哪一步最耗时•哪一步最容易出错•你需要查看哪些系统•哪些结果必须由人确认•如果 AI 给错了谁承担后果这些问题能把「想用 AI」还原成真实工作流。前三个问题定位场景字段 1第四个定位数据源字段 2后两个定位责任和兜底字段 6。第二步把场景写成动词加宾语「智能问答」「提升效率」「辅助决策」都太抽象。一个好的场景描述应该包含触发条件、动作和输出当销售在周五复盘前打开助手时系统读取其有权访问的客户跟进记录生成本周进展摘要、风险事项和待办建议并标注每条信息的来源。检验方法把这句话拿给一个不了解项目的研发看他能直接开始拆接口这句话就合格了。第三步把验收标准分成四类•业务结果是否节省录入时间、减少重复查询或缩短响应时间。•内容质量回答是否包含依据摘要是否遗漏关键事实。•安全合规是否出现跨租户、跨团队或越权访问。•运营效果目标用户是否持续使用人工修改率是否下降。为什么要分四类因为验收会上四类指标的确认人不一样业务结果归业务负责人内容质量归一线用户代表安全合规归 IT/合规运营效果要看上线后的数据。混在一句话里等于没人负责。第四步在开发前锁定边界「不做什么」必须与「做什么」同时确认。对销售 AI 助手而言生成 CRM 修改建议可以作为试点功能直接写入 CRM 则应被排除在首期范围之外。三、常见错误1. 把客户的解决方案当成需求客户说「我要一个 RAG 知识库」真正需求可能是「客服在回答退换货问题时希望三分钟内找到最新政策」。前者规定了技术后者才描述了业务问题。拿到前者要做的事是追问「你想用它解决谁的什么问题」2. 只有功能没有责任人每个验收指标都需要一个确认人。没有验收人指标最终会变成团队内部的自评——自己出题自己判卷验收会必然扯皮。3. 只有成功路径没有失败路径需求卡应写明无答案、权限不足、数据过期、工具失败和人工接管等情况。AI 系统一定会出错需求阶段不设计失败路径等于把失败路径的设计权交给了用户的第一次事故。4. 把所有数据都放进首期范围首期应优先选择一个高频、数据边界清楚、结果可验证的场景。数据源越多治理和验收成本越高。先跑通一个场景建立信任第二期再扩。四、关键知识点总结需求卡不是缩短版 PRD而是面向交付协作的共同契约。它必须同时让业务方看懂目标让研发知道输入输出让合规方看清边界让测试人员有明确的验收方法。可以用下面的句式检查一条需求是否足够具体当【谁】在【什么情况下】系统用【哪些数据、什么权限】生成【什么输出、什么格式】由【哪个具名的人】用【什么指标】验收出现**【哪些失败情况】时转人工处理。套用到销售助手的例子就是「当销售在每周五复盘前系统用他有权访问的 CRM 跟进记录生成三段式摘要由销售运营总监按「关键事实遗漏率 5%」验收无数据或权限不足时明确提示、不编造。」只要这句话里还有一个【】填不上就说明项目还没有进入稳定开发阶段——缺哪个格子就回访谈里补哪个问题。把本章翻译成 AI FDE hub 工程契约AI FDE 如何把客户问题变成可交付需求 这件事最终要落到一份能被四方签收的契约上。下面这份 YAML 就是它的字段模板# AI FDE hub · 需求卡 · 工程契约示例 chapter: 002 framework: AI FDE hub 三段式交付入场 / 搭建 / 离场 tags: [AI, 需求分析, 需求卡, 业务翻译] requirement_card: scenario: 谁在什么情况下做什么动作动词宾语触发条件 input_data: 数据源系统 数据范围 权限依据 output: 输出物结构与格式含引用标注要求 acceptance: 业务结果 / 内容质量 / 安全合规 / 运营效果 四类指标 boundary: 首期明确不做什么 owner_and_fallback: 具名验收人 无答案/越权/过期/失败的处理路径 scope: role: AI FDE 工程师 boundary: 对接客户业务负责人、合规、研发、测试四方共同验收和相邻章节的关系本章与前后相邻的第 1 章《AI FDE 的职责模型把交付现场变成可复用能力》、第 3 章《AI 项目数据接入从数据源盘点到可用知识》同处一个主题段共用同一套「产物 退出条件 决策门」语言可跨阶段拼装成完整交付链路。Toy Project vs. 生产级系统 · 8 项关键差异这张表聚焦「Toy 与生产级」最容易暴露差距的地方——每一行都是一次真实的取舍停在 Toy 水平省下的是当下的工作量付出的是上线后的返工和事故。最右一列写的就是这笔账。维度Toy Project生产级系统差距代价数据隔离单一租户演示数据多租户隔离 团队粒度过滤测试数据混进生产库一次越权就是合规事故权限控制硬编码角色RBAC 字段级脱敏一个角色能看到全公司数据审计时说不清谁看过错误处理try/catch 静默失败结构化异常 降级路径出错没人知道用户只能反复重试到放弃性能保证Demo 流畅即可延迟 / 吞吐 / 成本三指标 SLA演示不卡上线后高峰期直接超时知识时效训练截止知识实时检索 版本化文档用户照着已作废的条款执行损失无法追溯审计追踪无日志调用链 引用溯源出事查不到谁在什么时候问了什么、答了什么成本控制不计 Token 成本路由 缓存 配额用户量一上来账单跑得比业务增速还快可演进性单体脚本可观测 可替换 可灰度换一个模型要改全量代码只能推倒重做客户现场最常见的三种反模式这三种做法在需求阶段反复出现共同点是都在用「先做出来」回避「先想清楚」。提前识别比事后补救成本低一个数量级。反模式典型表现正确做法不推荐原因跳过业务翻译直接写代码客户刚说完业务痛点就立刻动手没还原现状与约束先把痛点翻译成可验证任务再决定技术方案代码写完才发现做的是另一个问题返工等于重做用技术方案替代需求分析客户说「我们要上 RAG」团队直接选型向量库不问业务问题先还原业务场景再选技术方案技术选型锁死了试错空间后面改方案成本极高没有边界就上线Demo 通过即交付边界问题「后续再说」需求卡写明首期不做什么其余走变更流程上线当天才发现客户预期和交付物对不上附录需求卡速查一句话记法需求卡 六格 × 四步 × 一式检查——场景、输入、输出、验收、边界、责任人兜底六格填满才算立项。本章机制 / 分工表四类验收指标归谁验收类别确认人该看什么业务结果业务负责人是否节省录入时间、减少重复查询、缩短响应内容质量一线用户代表回答是否包含依据、摘要是否遗漏关键事实安全合规IT / 合规是否出现跨租户、跨团队或越权访问运营效果上线后的使用数据目标用户是否持续使用、人工修改率是否下降边界表首期做 / 不做首期做首期不做生成 CRM 修改建议销售助手试点直接写入 CRM一个高频、数据边界清楚、结果可验证的场景把所有数据都放进首期范围现场症状 → 根因判断 → 先做什么 → 不该做什么现场症状根因判断先做什么不该做什么客户张口就说「我要一个 RAG 知识库」把客户的解决方案当成了需求追问「你想用它解决谁的什么问题」直接选型向量库验收会上没人拍板指标变团队自评验收指标缺具名确认人给每个指标指定一个具名的人用「业务方」这类集体名词兜底用户反复重试到放弃没人知道出错只设计了成功路径需求阶段就写清无答案 / 越权 / 过期 / 工具失败时怎么办把失败路径的设计权交给用户的第一次事故首期把全量数据源都接进来范围太大治理与验收成本失控先跑通一个场景建立信任第二期再扩把二期能力硬塞进首期改来改去仍是「感觉不好用」输出物没定结构、验收没标准固定输出物结构如三段式摘要靠无限改 prompt 打补丁客户催着「先做出来」用先做回避先想清楚先用检查句式把【】逐个填满Demo 通过即交付一个判断顺序先问工作动作不问模型→ 再把场景写成动词加宾语 → 然后分业务结果 / 内容质量 / 安全合规 / 运营效果四类定验收 → 最后在开发前锁边界句式里只要还有一个【】填不上就回访谈补对应的问题不要进入开发。一句收尾客户给出的永远是「想要的东西」需求卡要把它还原成「要解决的问题」——这中间隔着的不是一次会议而是六个必须逐个填满的格子。和相邻章节的关系本章承接第 1 章《AI FDE 的职责模型把交付现场变成可复用能力》厘清的职责产出的需求卡又是第 3 章《AI 项目数据接入从数据源盘点到可用知识》做数据接入前的输入约束三章同处一个主题段共用同一套「产物 退出条件 决策门」语言。思考题客户说「我们想要一个像 ChatGPT 那样的企业助手」这句话里有几个字段是空的参考答案六个全空。没有具体的人谁用、没有触发场景什么时候用、没有数据范围读什么、没有输出物产出什么、没有验收标准什么叫好、没有边界不做什么。AI FDE 的第一步不是讨论接哪个模型而是用第一节的六个问题把这句话还原成一张能填满的需求卡。换个说法客户给出的永远是一个「想要的东西」而需求卡要做的是把它还原成一个「要解决的问题」。前者是客户的解决方案后者才需要研发投入。这两者之间隔着的不是一次会议而是六个必须逐个填满的格子。AI FDE hub本文由 AI FDE hub 出品关注「AI PDE 陪跑计划」获取 AI 现场交付方法论