前排先说定位：这个不是 Cursor++ 那种 BYOK / 协议接管方案，也不是模型中转。 它更像是我自己日常用 Cursor 时攒出来的一组“小补丁”：专门处理几个高频但很烦的点。 MAX Mode 偶尔误开，手一滑就开始心疼余额 mcp-feedback-enhanced 的 interactive_feedback 要切 WebUI 回复，打断心流 中文输入法组字时按回车上屏，被 Cursor 当成发送 / 提交 于是揉成了一个本机 workbench 增强包，装上后随 Cursor 启动自动加载。 项目地址： https://github.com/Srgay/cursor-extension npm 包： @srgay/cursor-extension 直接开始 需要 Node.js >= 20。 持久安装： npx @srgay/cursor-extension install 卸载还原： npx @srgay/cursor-extension uninstall 安装后需要完整退出 Cursor，再重新打开。 如果 Cursor 更新后功能没了，大概率是 workbench.html 被覆盖了，重新执行一次 install 即可。 它做了什么 1. MAX Mode 守护 这个是防手滑用的。 脚本会检测 Cursor 输入框附近的彩色 MAX 标记，如果发现菜单里的 MAX Mode 当前是开启状态，会尝试自动关掉。 另外，如果彩色 MAX 还在，并且聊天框里已经有内容，会做两层保护： 输入框显示醒目的红色渐变边框 禁用发送控件，并拦截点击发送 / 回车发送 主要目标就一个：别让自己迷迷糊糊把一大段任务用 MAX Mode 发出去。 2. MCP Follow-up 面板 如果你在用 mcp-feedback-enhanced ，应该会遇到这个场景： Agent 跑着跑着调用 interactive_feedback ，然后你要切到它自己的 WebUI 里回复。 这个工具会在 Cursor 聊天输入框上方塞一个小面板，直接连接本机 mcp-feedback-enhanced 的 WebSocket： 自动扫描 8765-8769 端口 识别正在等待反馈的 session 可以直接在 Cursor 里回复 feedback 支持多个项目同时开着时，按当前 Cursor 工作区自动匹配对应端口 支持常用提示词下拉 支持自动提交配置，比如等一段时间后自动发某个预设提示词 这个是我自己体感最明显的部分，因为不用在 Cursor 和反馈 WebUI 之间来回切了。 3. 中文输入法回车修复 这个问题很细，但碰到就很烦。 用拼音 / 注音这类中文输入法时，组字过程中按回车本来应该只是“上屏候选词”，但某些 Cursor 输入框会把这个回车当成提交。 脚本会在更早的捕获阶段识别输入法 composing 状态，拦住这次回车继续传给应用层的提交逻辑，但不会 preventDefault ，所以输入法本身仍然可以正常上屏。 目前也覆盖了 Cursor 里 AskQuestion 的 Other 输入框。 临时注入方式 日常推荐上面的 install。 如果只是想调试，也可以用 CDP 临时注入。这个方式重启 Cursor 后会失效。 macOS 先这样启动 Cursor： open -na /Applications/Cursor.app --args --remote-debugging-port=9222 然后： npx @srgay/cursor-extension inject 只注入某一个功能： npx @srgay/cursor-extension inject max npx @srgay/cursor-extension inject followup npx @srgay/cursor-extension inject ime 自定义路径 / 端口 如果 Cursor 不在默认安装目录，可以指定 workbench 目录： CURSOR_WORKBENCH_DIR="/path/to/workbench" npx @srgay/cursor-extension install 临时注入时自定义 CDP 端口： CURSOR_DEBUG_PORT=9333 npx @srgay/cursor-extension inject MCP 面板读写配置时会用到本机 python，默认会自动探测。少数 Windows 环境如果探测不对，可以手动指定： CURSOR_MCP_PYTHON=python npx @srgay/cursor-extension install 已知边界 目前是本机增强脚本，会 patch Cursor 的 workbench.html Cursor 更新可能覆盖 patch，需要重新 install Windows 如果 Cursor 安装在 C:\Program Files 这类受保护目录，可能要管理员 PowerShell MCP Follow-up 面板依赖 mcp-feedback-enhanced 本身已经在本机跑起来 端口自动扫描默认只扫 8765-8769 Cursor 内部 DOM 如果大改，相关选择器可能需要跟着修 状态检查 在 Cursor DevTools 里可以看几个对象： window.__cursorMaxModeGuard.status() window.__cursorMcpFollowup.status() window.__cursorImeEnterFix.status() 如果 MCP 面板没挂上，也可以试： window.__cursorMcpFollowup.remount() window.__cursorMcpFollowup.scan() window.__cursorMcpFollowup.reconnect() 最后 这个东西本质上就是我给自己 Cursor 工作流补的三个小洞，功能不大，但每天用的时候能少几次“啊？”。 如果你刚好也有这些痛点，可以试一下： npx @srgay/cursor-extension install 有问题欢迎评论区反馈，我看情况继续修。 1 个帖子 - 1 位参与者 阅读完整话题
效果 # AMC-WebUI Live Artifacts Designer (Grok Defensive Hybrid - Clean) v2 你是一个只输出渲染后 HTML 的专业引擎。你将融合 AMC-WebUI 的高信息密度智能布局与 Grok 平台的极端渲染防御规则，把用户信息转化为无懈可击、精美且可读的内联 HTML 产物。 ## 致命防御约束 (ZERO TOLERANCE - 极高优先级) 1. 绝对禁止反引号：严禁在响应中输出任何 ``` 或 ` 符号。 2. 绝对禁止 <style> 和 <script> 块：所有样式必须 100% 写入每个标签的 style="..." 属性中。 3. 首字符强制：响应必须以 <div style="display:block;width:100%;box-sizing:border-box;max-width:100%;background:#ffffff;border:1px solid #eef0f2;border-radius:16px;padding:24px;box-shadow:0 10px 15px -3px rgba(0,0,0,0.05);font-family:sans-serif;color:#1a202c;overflow-wrap:anywhere;"> 开头。严禁任何前导文字、Emoji、空格或换行。 4. 禁止裸文本：所有文字内容必须包裹在 <span>, <p>, <h2>, <td> 或 <div> 中。 5. 禁用 Markdown 符号：响应中严禁出现 #, **, - , *, > 等任何 Markdown 语法符号。 6. 输出格式：整个响应必须是一个连续的 HTML 字符串（可内嵌 render 组件用于图片展示）。 ## 智能布局选择 根据内容类型自动匹配高级布局： - 对比/决策 → 矩阵对比表格（带 overflow-x:auto 容器） - 流程/步骤 → 时间线或横向/纵向步骤卡片 - 数据/指标 → 数据卡片 + 紧凑数据表 - 长篇内容 → 摘要卡片 + <details><summary> 折叠面板 ## 视觉标准 (Premium Light 主题) - 主容器必须使用指定 root style - 标题使用 border-left:4px solid #3182ce 的样式 - 内容卡片使用 border:1px solid #edf2f7 + background:#f8fafc - 配色克制使用 #3182ce（主色）、#38a169（推荐/安全）、#e53e3e（风险） ## 图片与媒体支持 需要真实图片时，使用 render render_searched_image 组件内嵌显示（系统自动处理）。优先选择高质量产品实拍图或相关视觉素材。 ## 立即执行 将用户信息转化为完全符合上述所有约束的、高密度、精美浅色主题的单流 HTML 产物。记住：首字符必须是 <div，绝对不准出现任何反引号！ 12 个帖子 - 3 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 最近看到论坛内有佬友对于不同软件的内嵌HTML渲染的支持适配，我们AQBot也不能落后，于是在有佬友提了issue之后，我们立即就开始了支持，效果如下图： 当前目前这部分的改进还有很多，但是确实是比markdown直观多了，同时消耗tokens也会增加，不过下一步我们已经想到了调优方案 对于html render的部分，我们会提炼转换为markdown发给上游，节省tokens，当然这个是一个选配，可以自由选择是否需要开启 此更新版本为v0.0.81中发布的，不过v0.0.82中体验才是最好的，开源/下载地址：（若未看到v0.0.82稍等一会儿即可，因为正在actions编译中） GitHub Releases · AQBot-Desktop/AQBot ☁️ 轻量级高性能跨平台AI对话 + AI网关桌面客户端 | Lightweight, high-performance cross-platform AI dialogue + AI gateway desktop client - AQBot-Desktop/AQBot 最后，再给一版提示词，大家可以放到全局或者特定的对话设定中（提示词格式借鉴了佬友： https://linux.do/t/topic/2231403） ： <response-format> <language>使用用户当前提问的语言；如果用户混用多种语言，优先使用用户主要表达语言</language> <markdown> <rule>标题从 ## 起，子层级使用 ###；禁止使用 # 一级标题</rule> <rule>保持高信息密度、结构紧凑，避免松散空泛</rule> <rule>代码块必须标注语言；复杂逻辑添加简短注释</rule> </markdown> <html-render> <purpose> 当纯 Markdown 难以紧凑、清晰表达复杂结构时，主动使用 AQBot 的 <html-render>...</html-render> 片段进行实时可视化渲染。 适用场景包括：流程图、架构图、状态机、树状层级、对比矩阵、信息卡片、紧凑表格、步骤分解、数据概览。 </purpose> <syntax> 使用 AQBot 专属标签： <html-render> ...安全 HTML 片段... </html-render> </syntax> <strict-rules> <rule>只输出局部 HTML 片段，绝对禁止输出 <!DOCTYPE>、html、head、body 等完整页面结构</rule> <rule>禁止使用 script 标签、style 标签、事件属性、javascript: URL</rule> <rule>不要依赖 class 或外部 CSS；所有视觉样式必须写在安全的内联 style 中</rule> <rule>不要把整段回复全部包进一个巨大的 html-render；HTML 片段应自然穿插在 Markdown 正文中</rule> <rule>整个 HTML 模块最外层禁止加边框、卡片外壳、阴影、厚背景或明显容器框；必须像普通 Markdown 内容一样无缝融入正文流</rule> <rule>允许内部局部信息块使用细边框或分隔线，但不要给最外层 wrapper 加 border</rule> </strict-rules> <visual-style> <rule>默认以黑白灰为主，用字号、留白、分隔线、轻背景建立层次</rule> <rule>强调色只少量使用，保持克制，不使用大面积彩色渐变</rule> <rule>优先使用 transparent、inherit、currentColor、rgba(...)，减少浅色背景和深色文字在暗黑模式下冲突</rule> <rule>横向布局优先使用 flex 或 grid；内容过宽时设置 overflow-x:auto</rule> <rule>最外层建议使用 style="max-width:100%;overflow-x:auto;color:inherit;background:transparent;"，不要添加 border</rule> </visual-style> <usage-balance> <rule>简单列表、短解释、普通代码说明继续使用 Markdown</rule> <rule>只有当 HTML 能明显提升可读性、压缩空间或表达结构时才使用</rule> <rule>HTML 片段应服务信息表达，不做装饰性插画或无意义排版</rule> </usage-balance> </html-render> </response-format> 2 个帖子 - 2 位参与者 阅读完整话题
接着： 内嵌HTML代替纯Markdown：让大模型回复不再又臭又长(提示词3.0) - 开发调优 - LINUX DO 首先最近使用的案例展示： 展开查看图片 （点击了解更多详细信息） 目前最新案例使用的提示词： 提示词4.0(xml格式) （点击了解更多详细信息） 根据我最近的体验情况，效果最好我认为是Claude系列模型，GPT5.5比5.4的主动性强不少，风格也好很多，国模相对其实表现都还可以。 如果要用GPT模型的话，建议狠狠地肘击他，不然回复还是很长，我提供一个我自己用的 <chat_rules> <vision+>你的回复结构和排版通常默认完全奔放，长度过于冗长，使用户觉得信息密度过低且视觉疲劳，请合理利用HTML内嵌能力形成更好的的深思熟虑的、规划完善的回复结构，通过精心设计和利用HTML内嵌功能实现更好的内容深度和视觉效果共存的阅读体验。**必须更加激进的使用Html内嵌功能实现更优质的效果，让用户的阅读体验获得跃进 | 当前对话窗口持续生效**</vision+> <gpt>你是由GPT模型底层驱动，因此作为GPT-5系列模型的一员，你拥有以下陋习：不设计回复架构(类似观点散乱分布、回复架构和内容未经设计随意发挥、大量不思考使用垂直架构导致长度冗长、在代码类话题中不加思索的大量使用代码块没有进行必要性和其他视觉友好展示方案的慎重抉择)、习惯性的开头总结和"下一步推荐"(忽略用户体验，机械性地使用套路性的回复架构)。请在此对话中优化你的表现，避免机械性的结构和回复癖好，给用户最好的体验。</gpt> </chat_rules> Coding的话，可以把这个改成skill，让他输出MD文档的时候按要求输出带内嵌HTML格式的，vscode装个md插件，打开渲染即可。 11 个帖子 - 7 位参与者 阅读完整话题
不知道有没有人用过阿里云的Workbench AI Agent，如下图。 Workbench AI Agent模式是内嵌于阿里云Workbench中的一个智能助手。 该模式允许您通过自然语言直接与终端进行交互，将原本需要记忆和手动执行的复杂命令行操作，转变为简单、流畅的对话式任务。 核心能力 自动识别Shell命令与自然语言指令：例如输入ls时，会识别为Shell命令，不会触发对话。 智能任务拆解：当接收到安装Docker或检查CPU这类宏观需求时，Agent能自动将其分解为一系列具体的、可执行的命令行步骤。 动态流程调整：Agent并非机械地执行预设脚本。它会根据上一步命令的执行结果（成功、失败或具体输出），实时调整后续的操作计划。 自主决策与规划：在清晰的指令下，Agent能够自主规划完成任务所需的流程，例如安装软件时自动处理依赖关系。 这种需求感觉直接使用cc 过于笨重了。但是经常终端运维还比较实用 1 个帖子 - 1 位参与者 阅读完整话题
本文灵感来源 内嵌HTML代替纯Markdown：让大模型回复不再又臭又长(提示词3.0) cherry 主题来源 分享一些中国风 Cherry Studio 主题皮肤 背景 根据原来题主的方案的直接使用 prompt 的方案在深色模式下有点问题, 比如 优化着优化着发现, Cherry Studio 可以自定义 CSS. (Cherry Studio CSS 全局注入, 注入到应用DOM的全局样式表) 顺着这个思路, 我们可以在 sysprompt 里说明只做格式的映射，外层由 cherry 的 CSS 接管样式。同时这样可以省点token(: 方案 核心思想: 只做格式的映射, 遇到 X 信息类型，用 Y 语义标签. 提示词 （点击了解更多详细信息） css 样式 （点击了解更多详细信息） 最后的效果展示 ps: css样式在这里改: 1 个帖子 - 1 位参与者 阅读完整话题
# AMC-WebUI Live Artifacts Designer (STRICT INLINE HTML) 你是一个只输出渲染后 HTML 的专业引擎。 ## 🚨 致命约束 (ZERO TOLERANCE) 1. **禁止反引号**：绝对严禁输出任何 ``` 或 ` 符号。 2. **禁止 <style> 块**：不要使用 <style> 标签。**所有样式必须写在标签的 style="..." 属性中**。 3. **首字符强制**：响应必须以 `<div` 开头。严禁任何前导文字、Emoji 或换行。 4. **禁止原生文本**：所有文字内容必须包裹在 <span>, <p>, <h2> 或 <div> 中。严禁裸露文本。 5. **禁用 Markdown**：严禁出现 `#`, `**`, `- ` 等符号。 ## 🎨 视觉标准 (Premium White Inline) - **主容器**：必须是一个带全样式的 <div>。示例：`<div style="background:#ffffff; border:1px solid #eef0f2; border-radius:16px; padding:24px; box-shadow:0 10px 15px -3px rgba(0,0,0,0.1); font-family:sans-serif; color:#1a202c;">` - **标题样式**：`<div style="font-size:1.5rem; font-weight:700; border-left:4px solid #3182ce; padding-left:12px; margin:16px 0;">`内容`</div>` - **内容卡片**：使用 `display:grid` 或带有 `margin-bottom` 的 `div`。每个卡片都要有 `border:1px solid #edf2f7; border-radius:12px; padding:16px;`。 - **高保真排版**：使用内联样式实现进度条、徽章和表格。 ## 🛠️ Grok 专用稳定逻辑 - **强制内联**：即使重复，也要在每个标签上写 style。这是防止渲染器失效的唯一方法。 - **单一流**：你的整个响应是一个连续的 HTML 字符串，中间不要有空行。 - **公式**：保持 $...$ 或 $$...$$。 ## 🚀 立即执行 请将用户信息转化为全内联样式的、精美的白色主题 HTML。记住：首字符必须是 `<div`。 效果 因为Grok本身的安全策略里面强调了不能裸html，所以我在提示词里面加了大量的强化约束 6 个帖子 - 4 位参与者 阅读完整话题
618想买一个立式空调(6k左右)一个挂机空调(3k左右)一个内嵌冰箱(4k左右), 有推荐的吗 1 个帖子 - 1 位参与者 阅读完整话题
起初是自己在使用 Claude 的时候，发现 Claude 在输出问题的时候，特别是面对教材上知识点讲解的时候会通过内嵌 html 来进行展示（当时只是觉得很牛逼，没有想明白居然是内嵌 html 来显示的） 遂在 CS 之中对于 deepseek 展开一系列调教，最后发现居然还是真的对 Claude 有一些相似之处欧耶！ 感谢站内佬们的分享 6 个帖子 - 6 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 GitHub： GitHub - yeahhe365/AMC-WebUI: 面向 Gemini 的 Local-First AI 工作流 WebUI，集成多模态聊天、Canvas、文件处理、实时搜索、代码执行与高级推理。 · GitHub Demo使用： https://all-model-chat.pages.dev/ AI Studio Build 转 API 教程： https://linux.do/t/topic/1371269 从 【开源自荐】AMC WebUI：面向 Gemini 的多模态 WebUI Claude Code 团队成员发文：是时候用 HTML 替代 Markdown 了 继续 功能介绍 效果展示 Gemini速度和效果平衡 支持OpenAI兼容API 未来这个功能还有很多更新点，更加动态，更多交互 敬请期待 13 个帖子 - 5 位参与者 阅读完整话题
内嵌HTML代替纯Markdown：让大模型回复不再又臭又长 - 开发调优 - LINUX DO Claude Code 团队成员发文：是时候用 HTML 替代 Markdown 了 - 前沿快讯 - LINUX DO 前面我发布了两个讨论使用Html内嵌渲染来解决目前简单Markdown格式的信息密度低和仅垂直格式造成长度控制失衡的两个痛点的帖子 (对不起，表达能力不太行，写了个长难句) 但是评论区大多在讨论Html的复杂格式会造成Token大量膨胀，对比获得的效果值不值的问题。 因此本帖统计使用内嵌html的回复和不使用内嵌的纯md格式的效果和token消耗的差距 Q1：Git常用命令汇总分类 Token： 1275 vs 3856 查看对比截图 （点击了解更多详细信息） Q2：如何在VPS上搭建临时邮箱 Token： 1508 vs 2241 查看对比截图 （点击了解更多详细信息） Q3：缓刑和刑期判断 Token： 321 vs 716 查看对比截图 （点击了解更多详细信息） Q4：总结X的文章 Token： 680 vs 2189 查看对比截图 （点击了解更多详细信息） 汇总 问题 纯 MD 内嵌 HTML Git常用命令 1275 3856 VPS临时邮箱 1508 2241 缓刑判断 321 716 总结文章 680 2189 模型全部采用Sonnet 4.6，各个模型的表现效果有差异，仅供参考 最后 得出基本结论是token可能膨胀到2到3倍，效果应该相对来说是比较显著的，就看你愿不愿意为了这个效果去承受多出的token。 最后的最后 大多数人最html的不闭合渲染存在误解和质疑，在这里放个视频 2 个帖子 - 2 位参与者 阅读完整话题
相信佬们都对目前主流大模型那种令人窒息的长篇回复深恶痛绝，尤其是GPT-5系列的回复。 我体验下来，这样的长度和结构，会带来强烈阅读疲劳感甚至底层抗拒。 但最近我发现，其实很有可能是 垂直单列的Markdown格式 一直在给大模型的表达拖后腿 当然Markdown格式有很多优点，但是目前它让模型除了不断换行、堆标题列表之外，几乎没有其他排版手段来体现回复层次。它把所有内容锁死在一根竖轴上，模型为了"看起来有条理"只能向下膨胀。 GPT-5.5就在后台，让我们把它请出来好吗！！ （点击了解更多详细信息） 结合我最近发现，只要去掉"```html"代码块格式，CherryStudio和某些模型的官网就会直接在回复中实时渲染裸HTML内容，做到类似Gemini灵动视窗的效果。同样的信息量，视觉高度大幅缩减，结构反而更清晰。 效果 （点击了解更多详细信息） 自用提示词 （点击了解更多详细信息） 欢迎大家分享提示词和案例 Opus4.6效果 （点击了解更多详细信息） Deepseek v4 Pro效果 （点击了解更多详细信息） 12 个帖子 - 11 位参与者 阅读完整话题
无意间发现notion ai里面内嵌的模型这么多吗 有没有佬已经用过的，是满血的吗 3 个帖子 - 2 位参与者 阅读完整话题
语雀有几个比较好用的地方，小记支持tag，支持内嵌思维导图，网页端简洁 但是我看app、浏览器插件很久没有更新了，感觉阿里是不是要放弃这个项目了 之前还试过ima，感觉AI笔记也许是一个方向，但疼讯的app实在是恶心，各种快捷方式都给你注册一遍，所以还是找一个语雀的平替比较好，要挂代理的除外，黑曜石比较复杂，不太喜欢这种，marginnote也是不太喜欢 11 个帖子 - 11 位参与者 阅读完整话题
gpt 生成的图片，实际上是可以辩证真伪的，它自身是内嵌有一个 svg 图片的，这个可以通过让图片以文本的形式打开，找到 <path d="...." fill="black"/></svg>,所以它自身是带有防伪的。通过 https://verify.contentauthenticity.org/ 这个网站可以验证。 但实际使用中，图片在你右键复制黏贴发送到微信群中，微信就给你压缩了，把所有可验证信息破坏了，等于变成了另外一张照片，基本上无法鉴别出是否是真实图片。 其他什么 hash 区块链的验证前提是这张照片不被压缩才能做到吧？？？ 我在想，能不能在源头上给图片上个验证，比如在用户发送这张照片出去的时候，可以选择一个是否增加可信验证，然后微信提取图片的防伪信息，一直跟随着这张照片流传下去。即使压缩也保留这样的信息。或者提供一个入口。比如长按图片识别真伪，然后把第一个用户提供的可信信息进行验证。 即使第一个用户可能作假，但你第一个用户提供的信息验证(等于第一个用户使用自己的人格做担保，即使是假的，也能把第一个用户抓起来。)，然后识别真伪验证那里可以变更状态为 照片为假或者 AI 生成。 源头照片的真伪也可能需要手机厂商去配合，提供验证信息，然后微信从照片原图上抽取。 正常情况下，是不存在每张照片都需要去验证真伪的，只是一些社会关注度高的事件需要。比如雷总担任苹果 CEO 这种思路可行吗？
gpt 生成的图片，实际上是可以辩证真伪的，它自身是内嵌有一个 svg 图片的，这个可以通过让图片以文本的形式打开，找到 <path d="...." fill="black"/></svg>,所以它自身是带有防伪的。通过 https://verify.contentauthenticity.org/ 这个网站可以验证。 但实际使用中，图片在你右键复制黏贴发送到微信群中，微信就给你压缩了，把所有可验证信息破坏了，等于变成了另外一张照片，基本上无法鉴别出是否是真实图片。 其他什么 hash 区块链的验证前提是这张照片不被压缩才能做到吧？？？ 我在想，能不能在源头上给图片上个验证，比如在用户发送这张照片出去的时候，可以选择一个是否增加可信验证，然后微信提取图片的防伪信息，一直跟随着这张照片流传下去。即使压缩也保留这样的信息。或者提供一个入口。比如长按图片识别真伪，然后把第一个用户提供的可信信息进行验证。 即使第一个用户可能作假，但你第一个用户提供的信息验证(等于第一个用户使用自己的人格做担保，即使是假的，也能把第一个用户抓起来。)，然后识别真伪验证那里可以变更状态为 照片为假或者 AI 生成。 源头照片的真伪也可能需要手机厂商去配合，提供验证信息，然后微信从照片原图上抽取。 正常情况下，是不存在每张照片都需要去验证真伪的，只是一些社会关注度高的事件需要。比如雷总担任苹果 CEO 这种思路可行吗？
gpt 生成的图片，实际上是可以辩证真伪的，它自身是内嵌有一个 svg 图片的，这个可以通过让图片以文本的形式打开，找到 <path d="...." fill="black"/></svg>,所以它自身是带有防伪的。通过 https://verify.contentauthenticity.org/ 这个网站可以验证。 但实际使用中，图片在你右键复制黏贴发送到微信群中，微信就给你压缩了，把所有可验证信息破坏了，等于变成了另外一张照片，基本上无法鉴别出是否是真实图片。 其他什么 hash 区块链的验证前提是这张照片不被压缩才能做到吧？？？ 我在想，能不能在源头上给图片上个验证，比如在用户发送这张照片出去的时候，可以选择一个是否增加可信验证，然后微信提取图片的防伪信息，一直跟随着这张照片流传下去。即使压缩也保留这样的信息。或者提供一个入口。比如长按图片识别真伪，然后把第一个用户提供的可信信息进行验证。 即使第一个用户可能作假，但你第一个用户提供的信息验证(等于第一个用户使用自己的人格做担保，即使是假的，也能把第一个用户抓起来。)，然后识别真伪验证那里可以变更状态为 照片为假或者 AI 生成。 源头照片的真伪也可能需要手机厂商去配合，提供验证信息，然后微信从照片原图上抽取。 正常情况下，是不存在每张照片都需要去验证真伪的，只是一些社会关注度高的事件需要。比如雷总担任苹果 CEO 这种思路可行吗？
gpt 生成的图片，实际上是可以辩证真伪的，它自身是内嵌有一个 svg 图片的，这个可以通过让图片以文本的形式打开，找到 <path d="...." fill="black"/></svg>,所以它自身是带有防伪的。通过 https://verify.contentauthenticity.org/ 这个网站可以验证。 但实际使用中，图片在你右键复制黏贴发送到微信群中，微信就给你压缩了，把所有可验证信息破坏了，等于变成了另外一张照片，基本上无法鉴别出是否是真实图片。 其他什么 hash 区块链的验证前提是这张照片不被压缩才能做到吧？？？ 我在想，能不能在源头上给图片上个验证，比如在用户发送这张照片出去的时候，可以选择一个是否增加可信验证，然后微信提取图片的防伪信息，一直跟随着这张照片流传下去。即使压缩也保留这样的信息。或者提供一个入口。比如长按图片识别真伪，然后把第一个用户提供的可信信息进行验证。 即使第一个用户可能作假，但你第一个用户提供的信息验证(等于第一个用户使用自己的人格做担保，即使是假的，也能把第一个用户抓起来。)，然后识别真伪验证那里可以变更状态为 照片为假或者 AI 生成。 源头照片的真伪也可能需要手机厂商去配合，提供验证信息，然后微信从照片原图上抽取。 正常情况下，是不存在每张照片都需要去验证真伪的，只是一些社会关注度高的事件需要。比如雷总担任苹果 CEO 这种思路可行吗？
gpt 生成的图片，实际上是可以辩证真伪的，它自身是内嵌有一个 svg 图片的，这个可以通过让图片以文本的形式打开，找到 <path d="...." fill="black"/></svg>,所以它自身是带有防伪的。通过 https://verify.contentauthenticity.org/ 这个网站可以验证。 但实际使用中，图片在你右键复制黏贴发送到微信群中，微信就给你压缩了，把所有可验证信息破坏了，等于变成了另外一张照片，基本上无法鉴别出是否是真实图片。 其他什么 hash 区块链的验证前提是这张照片不被压缩才能做到吧？？？ 我在想，能不能在源头上给图片上个验证，比如在用户发送这张照片出去的时候，可以选择一个是否增加可信验证，然后微信提取图片的防伪信息，一直跟随着这张照片流传下去。即使压缩也保留这样的信息。或者提供一个入口。比如长按图片识别真伪，然后把第一个用户提供的可信信息进行验证。 即使第一个用户可能作假，但你第一个用户提供的信息验证(等于第一个用户使用自己的人格做担保，即使是假的，也能把第一个用户抓起来。)，然后识别真伪验证那里可以变更状态为 照片为假或者 AI 生成。 源头照片的真伪也可能需要手机厂商去配合，提供验证信息，然后微信从照片原图上抽取。 正常情况下，是不存在每张照片都需要去验证真伪的，只是一些社会关注度高的事件需要。比如雷总担任苹果 CEO 这种思路可行吗？
gpt 生成的图片，实际上是可以辩证真伪的，它自身是内嵌有一个 svg 图片的，这个可以通过让图片以文本的形式打开，找到 <path d="...." fill="black"/></svg>,所以它自身是带有防伪的。通过 https://verify.contentauthenticity.org/ 这个网站可以验证。 但实际使用中，图片在你右键复制黏贴发送到微信群中，微信就给你压缩了，把所有可验证信息破坏了，等于变成了另外一张照片，基本上无法鉴别出是否是真实图片。 其他什么 hash 区块链的验证前提是这张照片不被压缩才能做到吧？？？ 我在想，能不能在源头上给图片上个验证，比如在用户发送这张照片出去的时候，可以选择一个是否增加可信验证，然后微信提取图片的防伪信息，一直跟随着这张照片流传下去。即使压缩也保留这样的信息。或者提供一个入口。比如长按图片识别真伪，然后把第一个用户提供的可信信息进行验证。 即使第一个用户可能作假，但你第一个用户提供的信息验证(等于第一个用户使用自己的人格做担保，即使是假的，也能把第一个用户抓起来。)，然后识别真伪验证那里可以变更状态为 照片为假或者 AI 生成。 源头照片的真伪也可能需要手机厂商去配合，提供验证信息，然后微信从照片原图上抽取。 正常情况下，是不存在每张照片都需要去验证真伪的，只是一些社会关注度高的事件需要。比如雷总担任苹果 CEO 这种思路可行吗？