询问笔录

Builds and operates an inquiry transcript generator. Invoke for基本案情生成询问提纲、笔录分析、涉案人员提取、模板化笔录生成或复刻网页工具.

询问笔录生成系统

本 Skill 用于把“询问笔录生成系统”的网页功能转化为可复用的 TRAE 工作流：可根据基本案情先生成一份原始询问笔录询问提纲，也可读取标准询问笔录模板与多份原始笔录，识别涉案人员，按指定对象生成事实锚定、逻辑闭环、格式贴近模板的问答式询问笔录，并支持生成可交付的文档或网页工具。

适用场景

在以下情况调用本 Skill：

• 用户要求生成、整理、改写或导出调查、谈话、询问笔录类文档。
• 用户只提供基本案情，希望先生成一份原始询问笔录的询问提纲。
• 用户上传了询问笔录模板与原始笔录，希望自动识别涉案人员并逐人生成谈话笔录。
• 用户要求复刻或改造“询问笔录生成系统”这类网页工具。
• 用户需要把多份 .docx、.txt 原始笔录合并分析，并生成 Word、HTML 或可复制文本。

不要在以下情况调用本 Skill：

• 用户只是询问一般法律常识、制度解释或文书格式知识，没有要求生成笔录或复刻工具。
• 用户要求伪造事实、补造证据、规避审查、替代人工审核或生成虚假供述。
• 用户提供的材料与调查、谈话、询问笔录无关。

核心原则

采用 ReAct 风格的“观察 → 推理 → 行动 → 复核”循环。先从用户文件和输入中提取客观事实，再推理当前缺口和下一步操作，随后执行生成、导出或网页构建，最后复核事实一致性与格式要求。

必须坚持以下底线：

• 事实锚定：所有姓名、时间、地点、行为、对话、金额、饮酒、聚餐、值班、处置等细节只能来自原始笔录或用户明确补充。
• 不得杜撰：缺失信息必须标注“材料未载明”或向用户确认，不能自行编造。
• 交叉一致：同一事件在不同人员笔录中的时间线、行为链、人员关系和责任表述不得互相矛盾。
• 角色适配：根据生成对象的身份和涉事程度，区分发起人、参与者、知情未制止者、管理责任人、旁证人员等。
• 人工复核：输出必须提示“生成内容仅供参考，请人工核对事实、程序与适用依据”。
• 数据安全：不要把敏感笔录内容上传到无关服务；不要暴露、硬编码或复述任何 API Key、后台密码、邀请码等密钥信息。

输入要求

优先收集以下材料：

• 笔录模板：标准询问笔录模板，首选 .docx。
• 基本案情：案件背景、时间地点、涉及人员、已知事实、争议焦点、需要核实的问题；可用于先生成原始询问笔录询问提纲。
• 原始笔录：一份或多份 .docx、.txt，可包含调查对象、证人、管理人员等不同来源材料。
• 案件提示词：案件背景、争议焦点、生成对象、涉及事实、需要重点追问的问题。
• 输出格式：Word、HTML、Markdown、纯文本，若用户未指定，优先生成可查看的 HTML 或可复制文本；若明确要求可正式编辑，生成 .docx。
• 生成对象：若用户未指定，应先识别涉案人员列表，再让用户选择或按全部人员分别生成。

如果用户只提供基本案情，可以先生成“原始询问笔录询问提纲”，但不得把提纲当作已形成的事实笔录。若缺少模板但用户仍要求生成，可以输出“内容草稿版”，并说明格式无法 100% 匹配模板。若缺少原始笔录且用户要求正式笔录，不得生成实体事实型笔录，应请用户提供材料。

标准流程

1. 观察材料

读取用户上传的模板和原始笔录，提取以下信息：

• 模板结构：标题、页眉页脚、谈话时间、谈话地点、谈话人、记录人、被谈话人、问答格式、签名区、字体和段落习惯。
• 案件事实：时间线、地点、参与人员、相关行为、组织或管理关系、证据来源。
• 人员线索：姓名、职务或身份、行为描述、知情程度、责任类型、与其他人员的关系。
• 风险点：材料冲突、缺失事实、无法确认的信息、可能需要人工补充的内容。

2. 推理计划

在生成前形成简短内部计划：

• 当前生成对象是谁。
• 该对象的责任定位是什么。
• 哪些事实可以直接引用。
• 哪些事实只能概括，不能扩写。
• 问答链应如何形成“动机 → 行为 → 认知 → 处置 → 认错/表态”的闭环。

推理用于控制生成质量，不要在最终正式笔录中输出内部推理过程。

3. 基本案情生成询问提纲

当用户仅填入基本案情，或明确要求先生成原始询问笔录询问提纲时，应先生成“询问提纲”，而不是直接生成正式笔录。

提纲应包含：

• 基本信息：拟询问对象、询问目的、关联事实、需核实事项。
• 事实线索：围绕时间、地点、人物、经过、原因、结果、证据来源列出核实点。
• 问题结构：按照“身份确认 → 背景了解 → 事实经过 → 关键细节 → 规则认知 → 是否制止/报告 → 结果影响 → 补充说明”组织。
• 风险提示：列出材料未载明、需要补充确认、可能存在矛盾的事项。
• 非诱导要求：问题应中性、开放，不预设答案，不把未经确认的事实写成既定事实。

输出格式建议使用“提纲标题 + 基本案情摘要 + 询问目标 + 询问问题清单 + 需补充材料 + 人工复核提示”。如果用户随后补充模板或原始笔录，再进入正式笔录生成流程。

4. 分析涉案人员

从合并后的原始笔录中提取人员列表。每个人员至少包含：

• name：姓名。
• description：与案件相关的具体事实或责任定位。
• role：可选，发起人、参与者、知情者、未制止者、管理责任人、旁证人员等。
• evidence：可选，来自哪份原始笔录或哪段事实。

输出人员列表时应简洁、可选择。不要把无关人员纳入生成对象。

5. 生成笔录

针对选定人员生成问答式谈话笔录。默认结构：

• 标题：沿用模板中的谈话或询问笔录标题。
• 基本信息：谈话时间、谈话地点、谈话人、记录人、被谈话人等；材料未载明时保留下划线或占位。
• 告知与确认：说明谈话要求、如实陈述义务、身份确认。
• 事实核查：围绕时间、地点、参与人员、行为过程逐步询问。
• 责任认知：询问是否知悉相关要求、是否意识到问题、是否有制止或报告行为。
• 处置与表态：说明整改、认识、配合调查等内容，但不得超出材料事实。
• 签字区：询问人、记录人、被谈话人、日期等。

生成要求：

• 使用“问：”“答：”格式。
• 问题应由浅入深，避免诱导式、定罪式表达。
• 答案应以原始笔录事实为依据，保持该对象视角。
• 对无法确认的字段使用空白线、括号提示或“材料未载明”。
• 不输出“根据模板参考内容”之类的系统提示语。

6. 预览与复核

生成后必须检查：

• 是否出现原始材料没有的人名、地点、时间、金额、行为。
• 是否与其他人员笔录的事实链矛盾。
• 是否每个关键问题都有对应事实依据。
• 是否包含模板要求的基础字段和签字区。
• 是否有不适合正式笔录的 AI 说明、内部提示、代码痕迹。

如发现问题，优先修正文稿；无法修正时列出需要用户补充的信息。

7. 导出

根据用户要求导出：

• Word：生成 .docx，尽量复用模板的标题、段落、签字区和常用字体；若无法完全复用样式，应说明差异。
• HTML：生成可打开、可预览、可复制、可下载的单页工具或报告。
• 纯文本：适合粘贴到现有模板中，保留问答格式。
• 兜底导出：如果自动 Word 导出失败，提供可复制文本，并说明用户可手动粘贴到模板。

最终文件应保存到用户可访问的工作区，不要把临时脚本、调试日志或中间数据放入最终交付目录。

网页工具复刻要求

当用户要求生成或改造网页工具时，复刻以下功能模块：

• 左侧控制面板：用户状态、使用说明、基本案情输入、模板上传、原始笔录上传、案件提示词、分析按钮、人员选择列表、状态提示。
• 右侧预览面板：生成询问提纲按钮、生成笔录按钮、导出 Word 按钮、手动导出兜底按钮、提纲/笔录预览区。
• 文件读取：支持 .docx 模板、.docx 和 .txt 原始笔录，多份原始笔录自动合并并用分隔线区分。
• 人员识别：调用模型从合并材料中返回 JSON 人员列表，格式为 name 和 description。
• 提纲生成：根据用户填写的基本案情生成原始询问笔录询问提纲，供正式询问或后续笔录生成参考。
• 内容生成：将案件提示词、模板文本、原始笔录和选中人员合并成生成提示，低温度生成正式笔录。
• 预览渲染：识别标题、基本信息、“问：”“答：”，显示为可读的笔录版式。
• 导出：支持 .docx 自动导出和剪贴板复制兜底。
• 游客/会员逻辑：如用户明确需要，可实现本地体验次数限制、登录、注册、邀请码管理；不要把它设计成真实支付或真实权限系统，除非用户提供后端方案。
• 后台管理：如需要，仅实现邀请码配置和前台页面生成；不得硬编码真实后台密码或密钥。
• 离线支持：如网页依赖第三方库，应说明内网环境需本地放置依赖文件，并提供降级提示。

推荐生成提示词

基本案情生成询问提纲

text

请根据以下基本案情，生成一份原始询问笔录询问提纲。

硬性要求：
1. 事实锚定：只能使用基本案情中已经提供的信息，不得杜撰细节；
2. 中性询问：问题必须客观、开放，不要诱导式询问，不预设答案；
3. 逻辑完整：围绕“身份确认 → 背景了解 → 事实经过 → 关键细节 → 规则认知 → 是否制止/报告 → 结果影响 → 补充说明”设计；
4. 风险提示：对基本案情未载明、需要补充确认、可能存在矛盾的事项单独列出；
5. 可执行：提纲应便于询问人员直接照此开展询问或转化为问答式笔录；
6. 不生成正式事实笔录，只生成询问提纲。

输出结构：
一、基本案情摘要
二、询问目标
三、拟询问对象及核实重点
四、询问问题清单
五、需补充核实事项
六、人工复核提示

基本案情：
{{基本案情}}

涉案人员分析

text

请分析以下多份原始笔录，提取所有与案件事实直接相关的人员。
要求：
1. 仅提取有直接相关行为、管理责任、知情未制止、旁证价值的人员；
2. 每个人员包含 name、description、role 三个字段；
3. description 必须基于原始笔录事实，不得推测；
4. 仅返回 JSON 数组，不要添加解释。

原始笔录：
{{合并后的原始笔录}}

单人笔录生成

text

请根据原始笔录和模板，为“{{生成对象}}”生成一份谈话/询问笔录。

硬性要求：
1. 事实锚定：所有细节必须来自原始笔录或模板，不得杜撰；
2. 角色适配：围绕该对象的身份、行为、知情程度和责任定位设计问答；
3. 逻辑闭环：形成“动机/背景 → 行为经过 → 规则认知 → 是否制止/报告 → 整改表态”的链条；
4. 无矛盾：与其他人员笔录事实保持一致；
5. 格式贴近模板：保留标题、基本信息、问答体、签字区；
6. 缺失信息保留空白线或写“材料未载明”。
7. 不要诱导式询问。

生成对象：{{姓名}}
涉及事实：{{人员描述}}

模板参考：
{{模板文本}}

原始笔录：
{{合并后的原始笔录}}

质量门槛

交付前至少满足：

• 没有凭空新增核心事实。
• 问答顺序清晰，事实链闭合。
• 对象视角一致，不把他人行为写成该对象自认行为。
• 可直接复制到模板或导出为文档。
• 明确提示需人工审核。

如果用户要求“一键生成全部人员笔录”，应逐人生成独立文件，并使用清晰文件名，例如 询问笔录_姓名_日期.docx。

参考依据

本 Skill 的工作流借鉴 ReAct 方法：在任务执行中交替使用推理轨迹和具体行动，利用外部观察更新计划、降低幻觉并提高可解释性。实现时应把这种思想转化为可审计的“读取材料、识别缺口、执行生成、复核事实”的过程，而不是把内部思考直接暴露在正式笔录中。