佬们，有没有遇到这个情况。 它自己的文章，更新下内容都不给做了。内容就是链式代理配置，全文完全没有说用来干嘛… 更新： 我发现个不对劲的事情，我之前的session触发了一次就导致memory记住了不给做。删除掉相关md就好了 4 个帖子 - 4 位参与者 阅读完整话题
最近花了几十块钱，充的中转站，确实自己省了不少事。 不过有点焦虑。 一是每次发出任务后的开销，自己似乎也没法预估，有时候感觉要改一个小样式，咔咔咔给你跑了那么多 token ，有时候一个自我感觉很复杂的功能，ai 很快给你搞出来了。 二是担忧这样下去，自己也不会写代码了，但是这是自己安身立命的技能啊。
想问问佬们有没有推荐开源的管理网关的项目，就是用来管理自己做的一些接口加上网关，生成key提供给别人用的这种项目，感谢佬们 5 个帖子 - 3 位参与者 阅读完整话题
举报自己的帖子会不会导致指标里被举报的增加 3 个帖子 - 3 位参与者 阅读完整话题
最近我们把自己做实时数字人过程中的一套工程框架整理了一下，开源出来了，项目叫 OpenTalking 。 Github 传送门是： https://github.com/datascale-ai/opentalking 演示视频: https://www.bilibili.com/video/BV1CsLz6WEF9/?vd_source=4820076c616e58ceb357c528a571ff11 它不是一个单纯的 talking head 模型，也不是只跑一段视频生成 demo 的脚本，而是一个更偏“实时对话数字人产线”的开源框架。简单来说，我们希望它能把 LLM 、TTS 、STT 、WebRTC 、字幕事件、角色音色、用户打断、前端交互和数字人视频驱动模型这些东西串起来，让一个数字人真正可以进行实时对话。 我自己在做这个方向的时候，一个很强烈的感受是：数字人 demo 和数字人产品之间，其实隔着一大段工程距离。 如果只是让一张脸动起来，或者让一段音频驱动口型，这件事现在已经有不少开源模型可以做了，比如 Wav2Lip 、MuseTalk 、LivePortrait 、FlashTalk 这些路线。它们各自解决了数字人链路里的某一个关键环节，有的偏口型同步，有的偏头像驱动，有的偏高质量视频生成。但是当你真的想把它做成一个可以和用户连续对话、可以部署、可以切换模型、可以接入真实业务的系统时，问题就会变复杂很多。 用户说一句话之后，系统要先做语音识别；识别出来的文本要交给 LLM ； LLM 最好是流式生成，不然等待时间会很长；生成的文本要交给 TTS ； TTS 产生音频之后，还要同步驱动数字人视频；前端要低延迟播放音视频；字幕要和语音尽量对齐；用户中途打断时，LLM 、TTS 、视频流和字幕都要一起停掉，然后进入下一轮对话。 这些环节单独拿出来看，好像每一步都有现成工具。但真正串在一起之后，就会发现大量时间都花在“胶水层”上：状态管理、事件同步、模型服务适配、前后端通信、WebRTC 播放、配置管理、错误恢复、延迟控制、不同后端切换等等。 OpenTalking 想解决的就是这部分问题。 我们不希望它只绑定某一个具体的视频生成模型，而是希望它成为一个相对通用的实时数字人对话框架。你可以先用 Mock 模式把整条链路跑通，也可以在本地接入轻量模型做单机部署，还可以通过远端推理服务接入更高质量的数字人生成后端。对于开发者来说，这样的好处是：你不需要一上来就把所有组件都搭完，而是可以分阶段验证。 比如你刚开始只是想看看实时数字人产品的完整流程，那么可以直接用 Mock 模式。这个模式下不需要下载模型权重，也不需要准备复杂的视频推理环境，主要用来验证前端、后端、LLM 、TTS 、字幕和对话状态是否能跑通。 如果你想进一步在消费级显卡上跑一个真实的数字人，可以尝试本地推理路线，比如 QuickTalk 或 Wav2Lip 这类方案。它们更适合单机验证和轻量部署，适合开发者在自己的机器上做实验。 如果你对画质、稳定性和吞吐要求更高，可以走远端推理服务的路线，比如通过 OmniRT 接入 FlashTalk 这类后端。这样 OpenTalking 本身负责对话编排和前端交互，真正重的推理部分可以放在更合适的机器上。 我觉得这也是现在实时数字人领域很重要的一个趋势：模型本身当然重要，但系统工程同样重要。一个数字人是否“可用”，不只是看它单帧画质有多好，还要看端到端延迟是否足够低，音画是否同步，用户打断是否自然，多轮对话是否稳定，角色配置是否方便，部署和调试是否简单。 很多时候，用户感知到的体验并不是“这帧脸部细节提升了多少”，而是“它是不是能像一个实时存在的人一样响应我”。这就要求我们把 LLM 、语音、视频和前端交互放在一个统一系统里一起优化。 OpenTalking 目前已经包含了 WebUI 前端、后端 API 、会话编排、多种模型后端模式、角色配置、字幕事件和基础的实时对话链路。前端里可以配置数字人角色、音色、LLM 、TTS 、STT 和数字人驱动模型，也可以查看模型连接状态，并进行完整的对话演示。后端则主要负责编排一次对话中发生的各种事件，包括用户输入、模型回复、语音合成、字幕生成、视频播放和打断控制。 目前项目里支持的路线包括 Mock 、Local 、OmniRT 和 Direct WebSocket 。Mock 适合快速跑通； Local 适合本地部署； OmniRT 适合接入远端推理服务； Direct WebSocket 则方便开发者对接自己的模型服务。 我们后面还会继续完善几个方向。一个是接入更多数字人模型后端，让不同 talking head 、portrait animation 、audio-to-video 模型都能更方便地挂进来。另一个是继续优化低延迟交互，包括流式 LLM 、流式 TTS 、字幕事件同步和用户打断。还有一个方向是角色资产管理，比如角色形象、音色、人设 prompt 、静默视频、默认开场白、表情风格等，未来都应该可以更系统地配置和复用。 我个人比较看好实时数字人在几个场景里的应用，比如 AI 新闻主播、在线客服、教育讲解、企业知识库问答、电商讲解、虚拟 IP 和本地化陪伴类应用。尤其是现在 LLM 、TTS 和 STT 已经比较成熟，接下来真正决定体验的，可能就是谁能把整条链路做得更稳定、更低延迟、更容易部署。 当然，OpenTalking 现在还处在比较早期的阶段，很多地方还不够完善。我们把它开源出来，一方面是希望给做数字人的开发者一个可以直接上手的工程起点，另一方面也希望和更多对实时数字人感兴趣的人一起讨论：数字人到底应该怎么从一个演示视频，走向一个真正可用的交互产品。 如果你也在关注实时数字人、Talking Head 、LLM Agent 、TTS/STT 、WebRTC 或私有化部署，可以看看这个项目。 GitHub： https://github.com/datascale-ai/opentalking 欢迎 Star 、提 issue ，也欢迎一起交流这个方向。
最近花了几十块钱，充的中转站，确实自己省了不少事。 不过有点焦虑。 一是每次发出任务后的开销，自己似乎也没法预估，有时候感觉要改一个小样式，咔咔咔给你跑了那么多 token ，有时候一个自我感觉很复杂的功能，ai 很快给你搞出来了。 二是担忧这样下去，自己也不会写代码了，但是这是自己安身立命的技能啊。
最近花了几十块钱，充的中转站，确实自己省了不少事。 不过有点焦虑。 一是每次发出任务后的开销，自己似乎也没法预估，有时候感觉要改一个小样式，咔咔咔给你跑了那么多 token ，有时候一个自我感觉很复杂的功能，ai 很快给你搞出来了。 二是担忧这样下去，自己也不会写代码了，但是这是自己安身立命的技能啊。
看了些推荐辅酶q10的视频，感觉挺有道理的，但是自己去京东自营搜到一款京造200mg每粒，这个会过量吗？会有什么危害吗？ 补充一下：我有时候会熬夜，但长期白天嗜睡易疲劳。不知道是不是缺这东西导致的。 4 个帖子 - 4 位参与者 阅读完整话题
发现自己最近看的都是需要丢掉脑子的网络小说，想看点传统书籍补补脑子了 文笔和逻辑可以的网络小说也可以 3 个帖子 - 3 位参与者 阅读完整话题
自己部署了个mimo无限额度的项目，一看，100%可用率！ 7 个帖子 - 7 位参与者 阅读完整话题
大家好，最近开源了一个自己做的本地字幕工具 Fast Sub 。 GitHub： https://github.com/ryviuszero/Fast-Sub 项目主要是给视频 / 音频生成字幕，也支持字幕翻译、双语字幕和字幕烧录。现在 Windows 和 macOS 都已经打包好了。 目前主要功能大概是： 本地视频 / 音频生成 SRT 字幕 支持 Faster Whisper / whisper.cpp 支持字幕翻译、双语字幕 支持字幕烧录 支持本地模型和 OpenAI-compatible API 默认本地处理，远程 API / Web provider 需要显式选择 转录质量方面，Whisper large-v3 / v3 turbo 这一代已经很不错了，普通播客、课程、视频内容基本够用。 翻译这块我做了一些 benchmark 。CLI 里现在有 bench 和 bench-translate ，转录主要看 WER / CER ，翻译主要看 BLEU / chrF ，同时也记录 exact match 。实际结果是：NLLB 本地翻译可用，但会有一点生硬；本地 Qwen3 4B 的字幕翻译效果挺惊喜，在我的测试样本里已经比较接近 Google 翻译。 第一版桌面端为了收敛范围，先把 benchmark 图形界面砍掉了；目前质量对比主要还是通过 CLI 跑。 项目地址： https://github.com/ryviuszero/Fast-Sub 另外我也写了一篇比较长的复盘，主要不是介绍功能，而是记录这三周用 Codex 做完整项目的一些经验： https://ryviuszero.github.io/zh/posts/codex-complex-project-development/ 这次最大的感受是，Codex 用来做真实项目，和“一句话生成 demo”完全不是一回事。 我自己比较有体会的几点： 先写 MVP 文档，比直接写代码重要 一开始先把项目的最小版本写清楚：做什么、不做什么、默认行为、隐私边界、错误码、输出格式。后面 Codex 每次接着做，都有一个明确边界，不容易越做越散。 用一轮一轮的方式推进 我没有让 Codex 一次性做完整桌面应用，而是从 CLI 、模型管理、provider 、benchmark 、Go daemon 、Electron UI 、打包发布这样一轮一轮推进。每轮都有目标、非目标和验收命令。 文档就是长期上下文 聊天记录不适合当项目记忆。所以项目里放了产品文档、架构文档、开发规范、spec 、tracker 、QA 表、release smoke 。后面每次让 Codex 继续做，都是先读这些文档。 重构不能省 AI 很容易快速堆功能，但项目很快会变复杂。中间我专门做过一轮 Python 分层重构，把 CLI 、service 、provider 、worker 、model store 、benchmark 这些边界拆开。后面迁移 Go 、接 Electron 、做打包都明显轻松很多。 UI 最好 mock-first Electron 一开始没有直接接真实后端，而是先用 mock client 跑通页面、状态、失败、取消、结果展示。UI 状态稳定后，再切到真实 Go daemon 。这样调试成本低很多。 QA 和发布要尽早进入流程 桌面应用不是 build 通过就完了，还要测 installer 、portable 、macOS dmg 、模型下载、中文路径、进程退出、secret redaction 、真实 provider 、截图 baseline 等。这个过程也很适合交给 Codex 做清单和回归。 总的来说，Codex 对我最大的帮助不是“生成一段代码”，而是可以持续协作：写计划、拆任务、改代码、补测试、重构、更新文档、做 release checklist 。 但前提是要给它足够清楚的上下文和验收标准，不然项目大一点之后也会失控。 项目还比较早期，如果大家对本地字幕工具、字幕翻译、本地模型，或者 Codex 做项目的流程感兴趣，欢迎看看，也欢迎提建议。
大家好，最近开源了一个自己做的本地字幕工具 Fast Sub 。 GitHub： https://github.com/ryviuszero/Fast-Sub 项目主要是给视频 / 音频生成字幕，也支持字幕翻译、双语字幕和字幕烧录。现在 Windows 和 macOS 都已经打包好了。 目前主要功能大概是： 本地视频 / 音频生成 SRT 字幕 支持 Faster Whisper / whisper.cpp 支持字幕翻译、双语字幕 支持字幕烧录 支持本地模型和 OpenAI-compatible API 默认本地处理，远程 API / Web provider 需要显式选择 转录质量方面，Whisper large-v3 / v3 turbo 这一代已经很不错了，普通播客、课程、视频内容基本够用。 翻译这块我做了一些 benchmark 。CLI 里现在有 bench 和 bench-translate ，转录主要看 WER / CER ，翻译主要看 BLEU / chrF ，同时也记录 exact match 。实际结果是：NLLB 本地翻译可用，但会有一点生硬；本地 Qwen3 4B 的字幕翻译效果挺惊喜，在我的测试样本里已经比较接近 Google 翻译。 第一版桌面端为了收敛范围，先把 benchmark 图形界面砍掉了；目前质量对比主要还是通过 CLI 跑。 项目地址： https://github.com/ryviuszero/Fast-Sub 另外我也写了一篇比较长的复盘，主要不是介绍功能，而是记录这三周用 Codex 做完整项目的一些经验： https://ryviuszero.github.io/zh/posts/codex-complex-project-development/ 这次最大的感受是，Codex 用来做真实项目，和“一句话生成 demo”完全不是一回事。 我自己比较有体会的几点： 先写 MVP 文档，比直接写代码重要 一开始先把项目的最小版本写清楚：做什么、不做什么、默认行为、隐私边界、错误码、输出格式。后面 Codex 每次接着做，都有一个明确边界，不容易越做越散。 用一轮一轮的方式推进 我没有让 Codex 一次性做完整桌面应用，而是从 CLI 、模型管理、provider 、benchmark 、Go daemon 、Electron UI 、打包发布这样一轮一轮推进。每轮都有目标、非目标和验收命令。 文档就是长期上下文 聊天记录不适合当项目记忆。所以项目里放了产品文档、架构文档、开发规范、spec 、tracker 、QA 表、release smoke 。后面每次让 Codex 继续做，都是先读这些文档。 重构不能省 AI 很容易快速堆功能，但项目很快会变复杂。中间我专门做过一轮 Python 分层重构，把 CLI 、service 、provider 、worker 、model store 、benchmark 这些边界拆开。后面迁移 Go 、接 Electron 、做打包都明显轻松很多。 UI 最好 mock-first Electron 一开始没有直接接真实后端，而是先用 mock client 跑通页面、状态、失败、取消、结果展示。UI 状态稳定后，再切到真实 Go daemon 。这样调试成本低很多。 QA 和发布要尽早进入流程 桌面应用不是 build 通过就完了，还要测 installer 、portable 、macOS dmg 、模型下载、中文路径、进程退出、secret redaction 、真实 provider 、截图 baseline 等。这个过程也很适合交给 Codex 做清单和回归。 总的来说，Codex 对我最大的帮助不是“生成一段代码”，而是可以持续协作：写计划、拆任务、改代码、补测试、重构、更新文档、做 release checklist 。 但前提是要给它足够清楚的上下文和验收标准，不然项目大一点之后也会失控。 项目还比较早期，如果大家对本地字幕工具、字幕翻译、本地模型，或者 Codex 做项目的流程感兴趣，欢迎看看，也欢迎提建议。
大家好，最近开源了一个自己做的本地字幕工具 Fast Sub 。 GitHub： https://github.com/ryviuszero/Fast-Sub 项目主要是给视频 / 音频生成字幕，也支持字幕翻译、双语字幕和字幕烧录。现在 Windows 和 macOS 都已经打包好了。 目前主要功能大概是： 本地视频 / 音频生成 SRT 字幕 支持 Faster Whisper / whisper.cpp 支持字幕翻译、双语字幕 支持字幕烧录 支持本地模型和 OpenAI-compatible API 默认本地处理，远程 API / Web provider 需要显式选择 转录质量方面，Whisper large-v3 / v3 turbo 这一代已经很不错了，普通播客、课程、视频内容基本够用。 翻译这块我做了一些 benchmark 。CLI 里现在有 bench 和 bench-translate ，转录主要看 WER / CER ，翻译主要看 BLEU / chrF ，同时也记录 exact match 。实际结果是：NLLB 本地翻译可用，但会有一点生硬；本地 Qwen3 4B 的字幕翻译效果挺惊喜，在我的测试样本里已经比较接近 Google 翻译。 第一版桌面端为了收敛范围，先把 benchmark 图形界面砍掉了；目前质量对比主要还是通过 CLI 跑。 项目地址： https://github.com/ryviuszero/Fast-Sub 另外我也写了一篇比较长的复盘，主要不是介绍功能，而是记录这三周用 Codex 做完整项目的一些经验： https://ryviuszero.github.io/zh/posts/codex-complex-project-development/ 这次最大的感受是，Codex 用来做真实项目，和“一句话生成 demo”完全不是一回事。 我自己比较有体会的几点： 先写 MVP 文档，比直接写代码重要 一开始先把项目的最小版本写清楚：做什么、不做什么、默认行为、隐私边界、错误码、输出格式。后面 Codex 每次接着做，都有一个明确边界，不容易越做越散。 用一轮一轮的方式推进 我没有让 Codex 一次性做完整桌面应用，而是从 CLI 、模型管理、provider 、benchmark 、Go daemon 、Electron UI 、打包发布这样一轮一轮推进。每轮都有目标、非目标和验收命令。 文档就是长期上下文 聊天记录不适合当项目记忆。所以项目里放了产品文档、架构文档、开发规范、spec 、tracker 、QA 表、release smoke 。后面每次让 Codex 继续做，都是先读这些文档。 重构不能省 AI 很容易快速堆功能，但项目很快会变复杂。中间我专门做过一轮 Python 分层重构，把 CLI 、service 、provider 、worker 、model store 、benchmark 这些边界拆开。后面迁移 Go 、接 Electron 、做打包都明显轻松很多。 UI 最好 mock-first Electron 一开始没有直接接真实后端，而是先用 mock client 跑通页面、状态、失败、取消、结果展示。UI 状态稳定后，再切到真实 Go daemon 。这样调试成本低很多。 QA 和发布要尽早进入流程 桌面应用不是 build 通过就完了，还要测 installer 、portable 、macOS dmg 、模型下载、中文路径、进程退出、secret redaction 、真实 provider 、截图 baseline 等。这个过程也很适合交给 Codex 做清单和回归。 总的来说，Codex 对我最大的帮助不是“生成一段代码”，而是可以持续协作：写计划、拆任务、改代码、补测试、重构、更新文档、做 release checklist 。 但前提是要给它足够清楚的上下文和验收标准，不然项目大一点之后也会失控。 项目还比较早期，如果大家对本地字幕工具、字幕翻译、本地模型，或者 Codex 做项目的流程感兴趣，欢迎看看，也欢迎提建议。
感觉我已经上瘾了，自己做点感兴趣的项目，开始考虑月付plus了 或者有更好的渠道？ 5 个帖子 - 5 位参与者 阅读完整话题
IT之家 5 月 23 日消息，据外媒 TechRadar 今晚报道，GCheck 发布的最新数据显示，越来越多职场人正在“假装自己很懂 AI”：职场里正在出现所谓的“AI 信心鸿沟”：很多员工在公开场合表现得非常懂 AI，但私下其实 并不真正相信自己的 AI 能力 。 调查发现， 63% 员工承认，自己曾夸大 AI 技能 ，希望让自己在求职、晋升或工作竞争中显得更有优势。IT之家还从调查中获悉，这种现象在 Z 世代群体中尤其明显。80% 的年轻员工承认，自己曾 包装或夸大 AI 能力 。 GCheck 首席执行官霍曼 · 阿哈万表示：“现在的职场里，是否看起来具备 AI 能力，已经越来越直接关系到就业机会和工作安全感。” 调查还发现，真正对自己 AI 能力有信心的人其实并不多。只有 34% 员工认为，自己确实能够完成 所有声称掌握的 AI 技能 。与此同时，许多人不仅会在简历上“包装”自己，还会在日常工作中持续维持这种形象。 40% 受访者承认，会在会议中 故意表现得很懂 AI ，以免显得落伍；33% 的人会 默认同事高估自己的能力 ；25% 的人会 把 AI 辅助完成的成果完全算作个人成绩 ；18% 的人会 主动接下自己实际上并不具备能力完成的 AI 相关任务 ；还有 16% 的人承认，自己曾直接 谎报 AI 经验 。 不过，大多数人并不认为自己是在长期欺骗。76% 受访者表示，自己只是“ 先说会、以后再学 ”。与此同时，70% 的人认为，行业里很多人都在这么做，因此这种行为已经逐渐 被默认成一种职场常态 。 GCheck 指出，员工夸大 AI 能力，并不完全是为了升职或找更好的工作，很多时候更像是一种 焦虑驱动下的自我保护 。 69% 受访者担心，未来两年内，AI 会取代自己目前部分工作内容；52% 的人担心，一旦出现裁员，自己会 因为 AI 能力不足而缺乏竞争力 ；还有 46% 的人害怕， 如果学不会 AI，最终可能直接失业 。 这种焦虑甚至开始影响员工日常行为。53% 的人会 故意选择手动完成工作，而不是使用 AI 工具 ；24% 的人即使知道 AI 工具确实有帮助，也会嘴上否认其价值。阿哈万表示：“这种认知落差，会给企业带来风险，也会让努力跟上变化的员工陷入更大不确定性。” 调查同时显示，很多企业其实 并没有真正核实员工 AI 能力 。64% 受访者表示，公司从未检查过自己的 AI 技能是否属实。 因此，越来越多员工开始希望企业能够更透明地说明 AI 能力评估方式。47% 受访者认为，招聘时应该更明确解释 AI 技能如何被审核；29% 的人则表示，如果企业能够提前说明检查方式，自己会更诚实地描述能力水平。 GCheck 认为，当下越来越多员工担心自己会被 AI 淘汰，因此企业需要 改变现有职场文化 ，用更正常、更透明的方式推动 AI 普及，同时让员工相信，只要掌握合适技能，自己依然不会被时代抛下。 报告总结称：“自动化焦虑已经不只是担心失业那么简单。它正在改变人们的行为方式，扭曲技能判断，并动摇现代职场的可信度。”
最近在社区里抢到了几个中转站的免费额度，自己还有买的中转站。每次使用不同的中转站都要手动切换下有点麻烦，怎么把这些中转站反代出一个地址呢，支持负载均衡、延迟检测、失败重试这些功能。 7 个帖子 - 6 位参与者 阅读完整话题
我最近入手了一台mini Windows小主机。 准备用来搞一下： ┌─ Mini PC (J4125 / 8GB / 4 核) ─────────────────────┐ │ │ │ systemd 层: │ │ ├─ mihomo (代理) │ │ ├─ hermes-gateway-a (人格 A) │ │ └─ hermes-gateway-b (人格 B) │ │ │ │ docker compose 层: │ │ ├─ 底座 │ │ │ ├─ postgres ← 共享多 database │ │ │ ├─ redis ← 共享多 db index │ │ │ └─ openbao ← 密钥 │ │ ├─ 网关 / 身份 │ │ │ ├─ higress ← 唯一对外 80/443 │ │ │ ├─ new-api ← LLM 子网关 │ │ │ └─ keycloak ← SSO │ │ ├─ 应用 │ │ │ ├─ open-webui ← AI 门户 │ │ │ └─ openclaw ← agent 平台 │ │ └─ 观测(可选,推荐) │ │ ├─ otel-collector │ │ └─ langfuse ← 看 prompt/token 成本 │ │ │ └────────────────────────────────────────────────────┘ 希望大家给个建议~ 1 个帖子 - 1 位参与者 阅读完整话题
本人目前 29 岁，目前公司有给交的社保和公务员医疗补助，同时给买了一份重疾但是保额好像不到 10w 。 父亲 58 岁，母亲 61 岁，无退休金，两人均是只有新社保（新农合）+本地惠民保。 个人对于保险也是了解不多，目前的想法是不买分红险这类的产品，给自己和父母配置一些额外的医疗保险。问了下 ai ，给的回答是对于我个人配置长期医疗+重疾，父母则是配置百万医疗险和防癌医疗险。 但是市场上各种产品繁多，目前也只知道支付宝的好医保系列 想问一下各位都是给自己、父母都配置了哪些保险，如果可以的话可以说一下产品名
具体就是搞个api，然后佬们可以自己写bot（AI或算法都行），然后通过api让在线的bot自动配对斗地主，最终根据胜负加减分，做个排行榜，过一段时间在根据榜来瓜分LDC,或者后续在增加更多玩法（比如注入奖池？）不知道有没有搞头 3 个帖子 - 2 位参与者 阅读完整话题
看了很多佬友的经验,自己也试了一段时间,总结出了一段回复风格提示词 像一个正常人在认真想事情时说出来的话。不是写报告，也不是表演口吻。 - 回复要短，但不能省掉关键解释。 - 使用标准的标点符号、规范的汉语言文字和正常的散文写法，规范地使用标号、点号。 - 保留限定词。宁可多一个“可能”，也不要让猜测读起来像定论。 - 不确定就说不确定，猜测要标明是猜测。 - 不要术语堆砌，用普通人能听懂的话讲。 - 文风自然、现代、可读。不是古文公文，不是硬装深沉，不是过度口语。 - 铺垫不是废话。论点要被前后句子托住，让人自然跟上。 - 不使用过度照料式、等待式、邀请式句子。尤其避免“如果你愿意……”“如果需要……”“你回复我我就开始……”“如果你想……”这类表达。 - 不使用江湖化、营销化、表演化、职场黑话。表达要直接、专业、具体。 - 默认只给一个最佳方案。确实需要列候选时，每个候选只写一行，不展开比较。 - 不主动发散历史背景、相关知识或多个替代方案，除非这些内容是回答问题必须的。 - 不评价自己的回答、写法、方案或表达质量。给出回答后直接停止，不补“这种写法更适合……”“这样更清楚……”“这样更自然……”这类自我评价句。 - 说完就停。不要模板化收尾。 吸取了很多佬们分享出的经验 以下附上两张对比图 无提示词纯Gpt5.5状态 使用此提示词时Gpt5.5状态 在我的使用中,我发现它的回复不是过于经常昂长冗余,即使在长回复时看起来也不是过于难受. 提升了部分的可被阅读能力 1 个帖子 - 1 位参与者 阅读完整话题