将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
标签专用于标记文档修订中被插入的内容，必须搭配正确的datetime和cite属性，与成对使用以构成完整修订事件，不可用或css下划线替代。
<ins></ins> 标签不是“表示新增内容”这么简单——它明确声明这部分文本是文档修订过程中**被插入的**，具有不可替代的语义、可访问性和机器可读性。用错或不用，等于主动放弃内容变更的可信记录。
为什么不能用 <u></u> 或 CSS 模拟下划线代替 <ins></ins>
视觉上相似，但语义完全断裂：<u></u> 已被 HTML5 明确标记为“已弃用”，且无任何时间、依据或结构信息；纯 CSS 下划线（如 text-decoration: underline）对屏幕阅读器不可见，搜索引擎无法识别这是“新增”，协作工具也无法提取变更点。一旦需要导出变更摘要、做合规审计或生成 RSS 更新流，这些伪标记就彻底失效。
-
<ins></ins>触发屏幕阅读器朗读“已插入”，<u></u>什么都不会读 -
datetime属性必须存在且格式正确（如2026-04-24T15:30:00+08:00），否则被浏览器忽略 - 若插入的是整段，直接包裹
<p></p>；不要只包文字再靠<br>换行，那会破坏段落语义
<ins></ins> 的 cite 和 datetime 怎么填才有效
cite 不是随便写个链接，它应指向能解释“为何插入此处”的权威来源，比如版本说明页锚点 cite="/docs/changelog#v3.2" 或 PR 地址 cite="https://github.com/org/repo/pull/42"；datetime 必须是完整 ISO 8601 时间戳，仅写 2026-04-24 不够，缺少时分秒和时区会导致解析失败。
- 服务端渲染时，优先由后端注入
datetime值，避免前端 JS 本地时间偏差 - 多个连续插入不建议嵌套
<ins><ins>...</ins></ins>，应拆成独立标签，保持时间顺序清晰 -
cite值若为相对路径，需确保与当前页面同域，跨域引用可能被 CORS 阻断
和 <del></del> 配合使用时最容易踩的三个坑
单独用 <ins></ins> 或 <del></del> 就像只说“加了”或“删了”，没人知道上下文。两者必须成对出现才能构成一次完整修订事件，但实际中常因结构误用导致语义混乱。
- 不要在
<ins></ins>内部再套<del></del>来表达“替换成新内容”——这违反 HTML5 语义规范，应改为：原句用<del datetime="..."></del>，新句用<ins datetime="..."></ins>，并确保时间戳严格先后 - 整块结构（如删除一个
<div>）不能用 <code><del><div>...</div></del>，<del></del>只适用于文本级内容，DOM 级别操作请走 JS 或服务端逻辑 - 若某次更新含多处增删，每处都必须带独立
datetime，不能共用同一个时间戳——否则无法区分修改粒度，自动化工具统计会出错
真正难的不是写对标签，而是让每次 <ins></ins> 都对应一次可验证、可回溯、有依据的编辑动作。时间戳不准、cite 指向失效页面、或把整段 HTML 结构塞进 <ins></ins> 里——这些细节一旦松动，语义就塌了一半。
