项目概览
面向建筑、景观与规划设计师，把自然语言问题连接到可核对的规范依据。通过检索、结构化回答、逐条引用与 PDF 原文入口，串起“提问—理解条件—核对来源—反馈问题”的工作路径。
项目起点来自设计工作中反复出现的查规范任务：知道要解决什么设计问题，却未必知道该翻哪本规范、哪一版、哪一条。即使搜到了答案，仍要回到原文件确认措辞、条件、表格和出处。产品希望将这些分散步骤连接起来，让设计师能够解释自己的依据。
产品 MVP 面向建筑、景观和规划设计师，电脑端优先，手机支持基本提问与阅读。首轮深度验证集中在建筑高频任务，其他专业保留探索覆盖。目前已于企业内部上线测试，回答服务于资料查找和辅助理解，项目适用判断仍需专业人员结合完整条件核实。
- 核心任务：查找指定条文、了解某类设计要求、咨询条文适用条件、补充条件后继续核对。
- 核心路径：用户登录 → 自然语言提问 → 模型进行问题规划检索并回答 → 查看引用与原文 → 继续补充条件或提交反馈。
- 当前交付：真实问答、多轮会话、本人历史、引用侧栏、规范目录、私有 PDF 查阅下载、用户反馈与管理员处理。
用户与问题
我将需求聚焦到一个可观察的任务：用户能否从问题出发，找到并核对支持结论的规范依据。用户调研报告显示，75% 的受访者在查询规范时“不确定是否最新版”，79% 的受访者希望精准条文检索，54% 的受访者报告单次查询耗时处于 10—60 分钟区间。这些观察支持查找与核对流程的改进机会。
这是一组探索性样本，查询时间来自受访者自报，没有对照计时，不能据此宣布产品节省了多少时间。历史报告也没有完整呈现深度访谈记录；案例将团队研究结论与我的产品判断分开，避免将团队材料写成个人独立完成的调研。
在使用场景上，执行型设计师需要迅速找到相关条文，专业负责人更关心依据是否完整、条件是否满足，跨专业协作者需要先确定问题涉及哪些规范。
在替代方案上，资料网站擅长文件查阅，通用聊天工具便于提问，专业问答工具则强调领域知识。我的切入点是把提问和来源核对放在同一工作空间，降低用户在搜索结果、聊天答案和 PDF 之间反复切换的成本。
- 版本不清楚 → 展示标准编号、版次与身份核验状态，并单独提示现行效力和项目适用性仍需核实。
- 答案难追溯 → 为每次回答保留对应引用、原文摘录及能够证实的定位信息。
- 问题缺条件 → 将缺少的项目条件明确列出，允许用户在同一会话中补充和更正。
- 资料不完整 → 区分正式条文、条文说明与联网摘要，保留证据缺口，避免把片段解释成完整结论。
我的职责
我的工作贯穿问题定义、功能取舍、AI 工作流设计、知识资料治理和 Web 交付。初期实践围绕团队调研、规范整理与专家测试集展开；后续借助 Codex 进行 AI Coding，将工作流变成可以登录、提问、追溯和反馈的应用。产品判断由我提出与确认，编码和核验工具由 AI 辅助完成。
我把“有依据地回答”进一步拆成可检查的要求：原文和解释分开；每项被支持的请求有真实引用；条文关联的表格不能无声遗漏；页码必须对应同版文件；缺材料时要告诉用户还缺什么。这些要求同时进入提示词、代码校验和界面文案，减少单靠模型自觉遵守的环节。
- 研究与定义：整理已有问卷和竞品材料，确定建筑高频查规范任务优先，划定辅助查询的产品边界。
- 资料治理：梳理文件身份、版本与来源映射，检查正文和表格切片，保留身份存疑资料的隔离状态。
- 流程设计：设计问题规划、检索、回答生成、证据复核和有边界的补搜，定义结构化返回字段。
- 应用交付：推进用户登录、连续会话、本人历史、引用及 PDF、目录和反馈后台的完整使用流程。
- 质量迭代：维护失败案例、区分检索与生成问题、控制真实调用预算。
关键决策
先验证建筑高频任务。保留建筑、景观和规划的定位，但没有把三个专业同时做深作为首版门槛。现有样本与资料偏建筑，先把具体任务的证据链做扎实，比扩展大量未经核验的资料更有价值；代价是景观和规划仍缺少同等深度的质量证明。
采用检索增强生成（RAG）：先取回资料，再让模型围绕材料组织答案。沿用 Coze 编排规划、生成和复核，应用层负责账号、会话、展示和保存。这可以较快打通交付，但也意味着需要处理平台输出差异、调用等待和故障定位，不能把“流程执行成功”当作“答案正确”。
让原文可以被核对。指定原文请求优先展示完整条文，解释另行标明；被选择的原文由来源材料回填并做字面核对，引用要与当前版本、正文和 PDF 身份对应。模型可以辅助表达，条文原文的准确性仍要靠来源与规则共同约束。
把图表作为独立质量问题。检索到条文不代表取到了它关联的完整表格；表格切片还可能遗漏表头、表注或行列关系。因此为已导入关联表设计定向读取与一致性检查，同时保留不能核实的状态。表格全面正确仍是持续验收目标。
把隐私和调用成本纳入体验设计。普通用户仅能查看本人会话；管理员处理用户主动提交的反馈材料。等待或结果未知时提供状态查询，避免把刷新做成自动重发问题，减少重复执行和计费的风险。
产品方案与流程
使用从一条具体问题开始。首页提供“查条文、问要求、问适用”示例，点击后可编辑再发送；也可以先去规范目录，按名称、编号、专业或地域查找资料，再将规范名称和版本带入提问草稿。目录检索负责找文件，自然语言问答负责围绕问题组织依据。
提交后，工作流规划请求并检索相关材料，整理候选来源，再生成结构化答案与复核结果。遇到材料缺口时按分支决定是否有限补搜；补搜不能将网页摘要升级为规范原文。最终回答同时保留实际支持内容、未支持内容、待补条件和使用限制。
阅读时，主区域呈现原文、核心解释和条件；引用侧栏按回答切换，避免多轮问答时错用上一轮来源。引用卡片展示标准、版次、条号、摘录与定位入口；能够匹配时区分 PDF 顺序页和印刷页。只有目录文件而缺少准确条文定位时，明确提示需要自行查找。
连续问答允许补充或更正条件，新建会话独立开始。本人历史承接已保存回答；发生等待或结果未知时查询已有执行状态。发现引用有误、版本存疑或回答不相关时，可以打开反馈，预览将提交的问答与来源材料后再确认，管理员据此处理并记录内部备注。
- 规范目录：展示 80 本关联 PDF 的条目，支持查看和下载。
- 阅读与核对：电脑以正文和引用侧栏并排展示，窄屏以抽屉承接引用，保持同一回答与同一来源的对应。
- 反馈闭环：一条回答保留首次主动反馈，管理员可筛选和处理；处理完成不代表答案已修正或用户已收到通知。
效果与评测
我把质量评估拆成资料、检索、生成和产品流程四层。初期团队材料记录了协同专家设计的 200 道测试题，覆盖规范查找、设计建议与边界问题。
资料层检查版本身份、条文和表格的完整性；检索层检查目标资料是否到达生成输入；生成层核对原文、引用覆盖、数值边界与限定词；网页层检查提交、保存、刷新、历史、引用及 PDF。各层结果分别记录。
一个典型失败是把表格概括中的“宜”改成“需”。即使条文引用正确、流程成功，回答仍改变了要求的语气，因此案例保留为语义失败。另一个问题是用户只要原文、完整表格并要求“不作项目判断”，系统却把这种答复约束当成必须有规范引用的业务请求，导致已有材料也无法输出；后续以限定分类修正，并验证真实缺引用问题仍被拒绝。
- 原文：与固定版本逐字核对，关注标点、表格、数值和限定语，不用“看起来差不多”代替检查。
- 依据：检查每个结论实际引用什么，以及引用能支持到什么程度；缺口须明确保留。
- 交互：验证保存后能否恢复、引用能否对应本轮、PDF 是否实际绘制；文件返回成功不等于阅读画面成功。
- 成本：按真实执行记录调用与预算，失败或状态不明即停，避免重试掩盖缺陷或重复产生用量。
成果与交付
项目已经从工作流方案发展为内部上线测试的 Web 端产品。用户可以登录、提问、继续补充条件、查看本人历史、展开引用、查阅规范目录和 PDF，并主动反馈问题；管理员能够处理反馈。这证明核心业务链已交付，同时保留专业质量和后续可靠性验收的边界。
工程交付覆盖 Next.js 与 TypeScript 网站、Supabase 账号和业务存储、Coze 工作流及 Vercel 部署。AI Coding 帮助我完成实现，我持续负责需求、验收标准和重要取舍。
复盘与下一步
最重要的认识是：专业问答的信任来自可检查的依据。一个回答可能语言流畅、带有引用，却仍然遗漏适用条件、误用版次或改变“宜”的语气。产品经理需要把“可信”拆成具体检查项，并让用户在界面中看见哪些内容得到支持、哪些仍待核实。
第二个认识是：知识资料治理直接决定产品上限。只扩大文档和切片数量，无法自动解决表格缺失、文本识别或版本效力问题。后续应优先维护有限范围的高频资料，把身份、条文、表格、表注与原页对应关系做扎实，再逐步扩展覆盖。
第三个认识是：AI Coding 缩短了从方案到应用的距离，也要求我更明确地表达验收结果。页面出现、接口成功、模型完成和用户任务完成是不同状态；重要能力应沿完整路径验证，异常和预算限制也要进入交付判断。
下一步：
- 逐步拓展多专业规范查询场景。
- 优化工作流链路，设计简单查询和复杂问题处理两条路径，缩短用户等待时长。
- 开放用户自定义规范入库。