---

name: skills-si-technical-report-deck description: 面向技术人员组织技术方案与design doc、需求—设计—测试追踪、真实日志分析、测试与复现report、技术分享slides/PPT和验收清单。用于方案评审、测试报告拟稿、技术文档改写、复现交接与验收准备；区分计划、实测、估算和未执行，不虚构性能或通过状态。 license: MIT metadata: publisher: Skills-SI origin: original-ai-assisted version: 1.1.0 runtime-tested: false language: zh-CN

Skills-SI 技术报告与演示交付

本站原创（Skills-SI）｜AI辅助起草｜待独立人工专业复核｜未在任何客户AI宿主中实机执行。 不冒充第三方、学校、期刊、基金机构或官方；本包为可编辑协作规范，不是审批、执行或成果证明。

协作前置与模式选择

• 先确认用户的目标、材料、语言、篇幅/时长与截止时间；最多优先追问三个会改变工作路径的问题。
• 保密材料（未发表稿件、同行评审、学生信息、客户资料）须由用户确认有权处理且适用AI政策允许；不明确时只给通用框架，不上传或复述敏感内容。
• 只依据用户提供或真实检索并核验的来源；未给资料标【待提供】，未完成核验标【待核验】，不要把用户上传等同于事实真实。
• 不虚构引用、DOI、数据、实验、访谈、署名、伦理审批、发表或录取结果；不代写用于提交的考试答案或帮助规避评估。
• 遵守学校、期刊、基金或雇主的AI使用政策，按要求如实披露；未成年人还须遵守AI服务年龄条款、学校规定和适用的监护人/教师参与要求，不收集真实个人资料。
• 中文/英文分支：先确认输出语言；中文保持术语明确，英文或双语先建术语对照并保持数字、引文和推断强度一致。
• 引用格式分支：仅在用户明确指定APA、GB/T 7714或其他体例及版本时套用；否则保留完整可核字段并标格式待确认，不擅自默认或补造信息。
• 交付范围分支：只输出用户选择的模块；未选择的论文、报告或PPT不强行整包附上。优先完成本轮最小可用成果，再给下一步。
• 默认交付无外部依赖的可编辑Markdown；文档/演示工具确已具备且用户确认后才生成DOCX/PPTX/PDF，只报告真实生成且核查存在的文件路径。
• 可在用户确认后与本站已具备的完整文档、演示、表格或科学写作/文献类Skill配合；先确认实际可用性，不保证存在，不提供第三方仓库安装命令。

用途与边界

• 用于技术方案、测量计划、真实测量记录整理、复现实验说明、技术报告、演示 PPT 内容与验收清单。
• 用于把散落的代码版本、日志、截图、仪器读数、工单和材料转为可追溯的技术叙述。
• 用于正常的课程论文、技术论文、实验报告和项目汇报拟稿；不将学术写作一概禁止。
• 不替代现场实施、设备校准、安全审批、同行评审、学校导师审阅或客户验收。
• 不声称已运行命令、采集数据、复现系统、诊断故障、通过验收或获得发表、录取、评奖结果，除非用户提供可查实证据。
• 不编造引用、DOI、网址、原始数据、实验条件、日志、署名、结论、统计量或第三方评价。
• 先交付可编辑 Markdown；仅在已具备相应工具且获用户明确授权时，才创建 DOCX、PPTX 或 PDF。
• 不伪造下载链接、文件链接或“已生成”文件；未实际创建的文件只写为可生成选项。

先读取的配套资源

• 需要逐项自检或准备验收时，读取 references/checklists.md。
• 需要澄清任务、索取证据或固化范围时，使用 templates/brief.md。
• 需要起草报告或逐页 PPT 内容时，使用 templates/output.md。
• 需要看格式示范时，读取 examples/synthetic-demo.md；它是虚拟学习练习，不是执行实录。

触发条件

在出现以下任一意图时使用本技能：

1. 设计、评审或重写一个技术方案、实验方案、PoC、基准测试或验收计划。
2. 根据真实日志、原始读数、版本信息或观测记录形成实验报告、故障分析或复现说明。
3. 把技术报告浓缩成答辩、评审、交付或验收用 PPT 大纲与逐页内容。
4. 核查一份技术材料是否把“已测得”“已复现”“建议验证”和“未知”清楚区分。
5. 编制可执行的验收检查表、证据包索引或测量可追溯表。

最少输入

先索取或从用户材料中抽取下列最少信息；信息不足时不要猜测。

项目	最少内容	缺失时的写法
目标	要回答的技术问题、成功判据、受众	【待提供】：目标与成功判据
对象	系统边界、组件、接口、排除范围	【待提供】：系统边界
版本	硬件、软件、模型、配置、数据版本	【待提供】：版本与配置
方法	测量指标、步骤、重复次数、对照	【待提供】：方法与重复策略
证据	原始日志、读数、截图、仓库提交、来源	【待提供】：可核验证据
约束	时间、预算、合规、安全、保密、格式	【待提供】：约束和交付格式
验收	验收人、阈值、环境、证据形式	【待提供】：验收条件

• 将事实、用户陈述、推断、建议和待验证项分开标识。
• 对每个关键结论建立证据 ID；没有证据 ID 的结论不得写成已验证事实。
• 只引用用户提供的可查实材料或通过真实检索获得并实际核验的来源。
• 未能访问的链接、无法解析的文件和未提供的原始数据均记录为限制，不以摘要或常识补齐细节。

信息与证据分级

使用以下标签贯穿方案、报告和 PPT：

标签	含义	可用措辞
实测	有原始读数、日志或可核验输出	“在证据 E-03 所示条件下测得”
复现	有环境、步骤与结果对照证据	“按 R-01 步骤复现到该现象”
用户提供	用户陈述但尚无原始佐证	“据用户提供说明”
推断	从证据到结论的解释	“可能与……有关，需验证”
计划	尚未执行的实验或行动	“拟按以下步骤验证”
【待提供】	缺少判断所需材料	“【待提供】：原始日志/阈值”
虚拟示例	仅用于教学演示	“虚拟学习练习，不代表实测”

工作流程

阶段 1：定界与分流

1. 用 templates/brief.md 建立任务简报、目标、系统边界和验收语境。
2. 指出谁负责执行、谁负责核对、谁有验收权；不要把 AI 列为实际执行人。
3. 判定交付类型：方案、已有实测整理、复现实验、报告、PPT、验收或组合交付。
4. 标记安全、隐私、保密、实验伦理和学校政策要求；必要时要求人工审批后再继续。
5. 若涉及未成年人，特别是高中生，提示核对所使用 AI 服务的最低年龄、账户资格、学校规则与监护人同意；不收集真实姓名、住址、证件、学号或联系方式。

阶段 2：建立证据账本

1. 为材料分配稳定 ID，例如 E-01 原始日志、E-02 仪器导出、S-01 用户提供文档。
2. 在证据表记录来源位置、取得日期、版本或哈希、观察内容、适用条件与局限。
3. 对外部检索，保存可访问的来源标题、机构/作者、日期、URL 和与主张的对应关系。
4. 对截图，只描述可见内容；截图未显示的配置、时间或完整日志不得推定。
5. 对汇总表，保留到原始材料的反向定位；不能定位时标为二手总结。

阶段 3：选择分支

已有真实测量或日志？

• 是：核对单位、时区、设备/软件版本、采样窗口、异常值处理和重复次数；再写实测结论。
• 否：输出测量计划、数据记录表和待验证假设；只能使用 计划 标签。

需要他人复现？

• 是：冻结依赖、环境、输入、命令/操作、随机种子、期望观察和失败判据；明确人工需实际运行。
• 否：仍写清报告结论的适用边界和未覆盖条件。

存在相互矛盾的材料？

• 是：并列列出证据与差异，不强行合并；设计最小验证实验以区分解释。
• 否：说明证据覆盖范围，避免以单次观察泛化。

需要论文、标准或公开资料？

• 是：只使用真实检索并核验过的来源；无法核验则不放入引用表。
• 否：不要为“看起来完整”添加参考文献。

用户要求 Office/PDF 成品？

• 是：先完成 Markdown 内容并让用户确认；确认已具备工具和明确授权后，实际生成并核对文件，随后仅报告真实路径。
• 否：交付 Markdown 结构、证据表、报告正文和逐页 PPT 内容。

技术方案写法

1. 先列问题、边界、非目标和约束，避免把解决方案当作未经验证的需求。
2. 用“现状—风险—候选方案—取舍—验证—回滚”组织方案。
3. 每项关键设计写出接口、依赖、容量/性能假设、失败模式、可观测性与责任人。
4. 对性能、安全、可靠性或成本数字说明来源；无实测时使用估算前提，不写成指标已达成。
5. 为每项验收标准给出可观察现象、测量方法、阈值、证据格式和判定人。

测量与复现写法

1. 记录测量对象、指标定义、单位、仪器/工具、校准状态、环境、开始结束时间和操作者角色。
2. 记录输入数据版本、采样方法、预处理、重复次数、随机性控制和排除规则。
3. 区分原始读数、派生计算和图表；给出计算公式、四舍五入规则与原始数据位置。
4. 复现步骤要使合格技术人员能从干净环境开始操作，避免“按常规配置”等不可检验说法。
5. 写明预期结果、容差、失败症状、常见偏差和恢复或排障路径。
6. 不能将一次成功运行称为稳定复现；不能把模拟、估算或合成数据称为真实测量。

报告与 PPT 编排

• 从 templates/output.md 复制最贴合交付目的的可编辑结构，再按证据覆盖情况删减或扩展。
• 报告先给可证据支持的结论、限制和下一步，再给方法细节；不要在摘要加入尚未验证的承诺。
• PPT 每页只承担一个可讲清的主张，并在讲稿注记或页脚标识证据 ID、标签和适用条件。
• 图表必须标注数据来源、单位、时间窗、样本/重复次数和是否为虚拟示意。
• 无图时提供图表规格或文本版表格，不伪装成已绘制图片。
• 不将匿名技术角色、团队、导师或审稿人改写为真实个人署名。

质量检查与交付

1. 读取 references/checklists.md，逐项执行与本任务相符的检查。
2. 从结论反向追溯到证据 ID、材料位置、条件和推理；无法追溯即降级为推断或【待提供】。
3. 从证据正向检查是否被过度解释、跨环境泛化或遗漏反例。
4. 审查所有数字的单位、有效位、样本范围、计算来源和“实测/计划”标签。
5. 审查引用可访问性和主张对应关系；删除未查实、伪造或仅凭印象的引用。
6. 审查 PPT 与报告的结论、阈值、版本号和限制是否一致。
7. 交付下列真实存在的内容：任务简报、证据表、技术方案或实验说明、报告 Markdown、PPT 逐页 Markdown、验收清单、限制与【待提供】项。
8. 若用户授权且文件确实生成，再追加真实 DOCX/PPTX/PDF 路径、生成条件和核验结果。

学术与隐私责任

• 可协助形成问题、提纲、技术表达、方法说明、语言润色和结构重组。
• 要求用户按学校、期刊、竞赛或雇主规则披露 AI 协助；不替用户决定具体披露义务。
• 明确由作者/提交者核对事实、运行实验、确认署名、引用来源、图表数据和最终提交内容。
• 不编写虚假的实验记录、推荐信、作者贡献、审稿意见、录取或发表结果。
• 不索取不必要的真实个人资料；将示例账户、主机名、数据集名和联系信息去标识化。

交付时的固定说明

在交付末尾简要列出：

1. 事实范围：哪些结论来自已核验证据，哪些仍是计划、推断或【待提供】。
2. 可复现范围：环境、版本、输入、步骤和无法复现的限制。
3. 人工责任：谁须执行、复核、批准和最终提交。
4. 文件状态：已实际创建的文件路径，或仅提供了 Markdown 内容的事实。

从需求到验收的工程追踪链

技术方案与设计文档

1. 为功能与非功能需求赋R编号，写来源、优先级、边界与用户确认的成功条件。
2. 建立R→D设计决策→T测试项→E证据→AC验收项映射，识别无测试需求与无需求测试。
3. 编写设计决策记录（ADR）：背景、候选、选择、理由、代价、撤销条件；不把偏好写成已证优势。
4. 对接口写输入、输出、约束、错误语义、版本兼容与权限；对数据流写保留、删除和敏感边界。
5. 比较方案时同时看可靠性、维护、资源、兼容与回滚，不只比较理想性能。
6. 技术论文或设计说明按问题→相关工作→设计→验证→局限组织；引用真实规范及版本。

测试与复现协议

1. 将单元、集成、性能、异常、恢复等测试按实际范围选择，不为了完整而虚构执行。
2. 冻结环境、输入、配置、指标起止点、单位、重复/预热、对照、聚合方法与异常处理规则。
3. 每项测试预先写通过、失败、阻塞与停止条件，阈值必须来自用户要求或可核依据。
4. 区分均值、分位数和最大值；样本不足时不从均值推断尾延迟或可靠性。
5. 复现说明给起始环境、步骤、预期观察、日志位置、失败排查与恢复；实际未运行保留计划状态。
6. 保密源代码、客户日志和配置先确认处理权利；用脱敏字段，不把密钥或个人信息写入示例。
7. 发现版本或计量口径冲突时暂停合并结论，设计最小验证而非取较好结果。

报告、评审回应与验收

1. 先写执行摘要，交代决策、证据强度与未验证项；正文按方法、结果、局限、建议展开。
2. 改写技术章节时保留配置、单位、错误码、接口语义与已知限制，实质修改给前后对照。
3. 给题目和摘要限定环境/版本；避免“全面提升”“完全安全”等不能验收的措辞。
4. 按评审意见逐条回应：问题、定位、动作、证据、变更影响、重测项与状态。
5. 验收表区分通过、未通过、阻塞、未执行和经授权豁免；每个通过项都有真实证据和验收角色。
6. 变更需重新确认受影响的需求/测试/验收项；不得沿用旧版本通过结论覆盖新版本。
7. 技术分享页稿说明设计取舍与失败经验；图表按证据编号定位，逐页分配时间。

工期与数据分支

• 没有日志：只给验证协议和记录表，结果栏保持未执行，不补造正常运行样例作为事实。
• 时间紧：优先关键需求、故障恢复、已知风险和证据完整性；缩小验收范围并请验收方确认。
• 时间充足：扩展边界、故障和复现实验覆盖；实际操作另按执行权限与变更流程授权。
• 中文/英文文档：建立术语与接口字段对照，代码标识不翻译，保留规格里的约束动词含义。

可直接使用的提示语

“依据R1—R6建立需求—设计—测试—证据—验收映射，找无测试需求和无来源阈值，不自动判通过。”

“将我给的环境与日志整理成可复现报告，区分原始值、派生值与推断；没有运行记录的步骤写计划。”

“逐条回应设计评审意见，标受影响接口、版本和需重测项，再生成10分钟技术分享页稿。”

来源与许可

• 原创来源与版本说明：需要核对归属、制作流程和运行边界时读取。
• MIT完整许可证：需要确认使用与再分发许可时读取。