AI与大模型

问题：AI编码的成功为什么难以复制？ 越来越多的团队在尝试AI辅助编码。但一个普遍现象是：成功案例很多，成功复制却很难。 某个项目用AI写代码效率翻倍，换个项目就不行了；某个工程师用AI很顺手，换个人就各种踩坑。问题出在哪？ 本质是上下文的缺失，也是驾驭能力的缺失。 AI编码不是简单的提问-生成代码，而是需要三层上下文的支撑：编程环境上下文、项目上下文、需求上下文。任何一层的缺失，都会导致AI生成的代码无法落地。 平台要解决的核心问题，就是让这三层上下文可复制，让AI可被有效驾驭。 理论基础：从Prompt到Harness的三阶段演进 第一阶段：Prompt Engineering（提示词工程） 时间：2022年底至2024年初 核心理念：关注说什么 在这个阶段，所有主流的AI教程都着重讲解如何创建一个完美指令——角色扮演、Few-shot、Step-by-step等技巧。用户是绝对掌控者，模型是基于单条指令完成任务的被动执行者。 模型没有记忆、没有工具，每一次交互都是独立的条件概率生成。 第二阶段：Context Engineering（上下文工程） 时间：2024年至2025年初 核心理念：关注配置环境 随着模型上下文窗口的扩充（从4K到128K/200K tokens），业内开始形成共识：相较于研究提示词如何遣词造句，更重要的是以系统性框架（RAG知识库、系统提示词、Memory记忆系统、工具调用接口）为模型构建信息环境。 用户从直接发号施令者转变为情境构建者——负责判断当前情况，提供信息与资源；模型则在给定的上下文环境中，自行判断如何应对。 第三阶段：Harness Engineering（驾驭工程） 时间：2025年初至今 核心理念：关注让什么发生 随着Claude 4.6、GPT-5.4 Codex、Gemini 3.1 Pro等具备深度Agentic能力的模型成熟，新的范式被提出——Harness Engineering（驾驭工程）。 “Harness"在英语中意为马具/缰绳。它不是动力本身，但它决定了动力能否被稳定地使用。AI像一匹很快的马，但需要一套缰绳才能被驾驭。 核心定义：设计一套环境与机制，使AI Agent能在可控边界内持续自主工作。 核心理念：人类引导，智能体执行（Humans steer, Agents execute） 驾驭工程的四个核心动作 Harness Engineering的核心可以概括为四个动词： 1. Constrain（约束）：设定边界 问题：AI会产生幻觉，会偷懒，会写出看似能跑实则一团糟的代码。 解决方案：通过不变量约束，而不是微观管理实现细节。 具体做法： Guardrails护栏：定义AI不可逾越的行为边界 权限分级：不同场景下AI的能力范围 沙箱隔离：Docker容器隔离，任务完成后销毁 架构约束：强制执行依赖方向（如 Types→Config→Repo→Service→Runtime→UI） 2. Inform（告知）：提供信息 问题：AI只能访问运行时上下文中的知识，其他都等于不存在。 解决方案：把上下文推回仓库，结构化组织信息。 具体做法： 渐进式披露：给AI一张地图（AGENTS.md），而不是1000页说明书 结构化docs/目录：设计文档、产品规格、技术参考 可观测性数据：日志、指标、追踪（LogQ、PromQL） UI能力：Chrome DevTools协议，让AI能读取界面、截图、导航 3. Verify（验证）：检查结果 问题：AI生成的代码未必符合要求，需要验证。 解决方案：建立评估机制，让验证自动化。 具体做法： Evals评估：为每个产品领域和架构层打分 智能体评审：AI评审AI的代码 结构测试：验证架构依赖是否合规 CI任务：校验知识库是否最新、结构是否正确 4. Correct（纠正）：修正问题 问题：发现问题后，如何让系统自我修复？ ...

引言：同是AI，两种待遇 腾讯悄悄内测QClaw，微信终于接AI了。 表面看，这只是腾讯又一次产品更新。但如果你还记得半年前字节跳动推豆包手机时微信的态度——冷处理、功能限制、入口不给——你就会意识到： 同样的AI，两种待遇。 这不是技术问题，不是合规问题，甚至不是用户体验问题。 这是商业本质。 一、入口之争：寸土不让 1.1 豆包手机想干什么？ 字节跳动推豆包手机，核心目的只有一个：当入口。 想象一个场景： 用户不打开微信，直接对豆包说：“帮我订个外卖”、“给老王转100块”、“今天的新闻有什么？” 豆包完成一切。 这对微信意味着什么？ 夺权。 微信的核心价值是什么？不是聊天功能，不是朋友圈，不是小程序。 是14亿用户的入口。 用户每天打开的第一个App，决定了一切。谁控制入口，谁就控制了流量分发权、商业变现权、数据主权。 字节跳动想做这个"谁"。 腾讯能答应吗？ 当然不能。 1.2 为什么QClaw被捧，豆包被卡？ 答案已经呼之欲出： QClaw姓腾讯，豆包姓字节。 不是因为技术好坏，不是因为合规问题，不是因为用户体验。 是因为入口控制权。 QClaw嵌入微信，入口仍在腾讯手里，流量仍在腾讯体系内流转。 豆包手机试图绕过微信，成为独立入口，把流量引向字节系。 前者是"内部赋能"，后者是"外部夺权"。 腾讯的选择，顺理成章。 二、护城河逻辑：能生儿子，绝不养外人 2.1 微信为什么焦虑？ 表面看，微信如日中天：14亿用户，日活超10亿，几乎是中国人的"数字身份证"。 但马化腾比谁都清楚：流量见顶，用户时长被瓜分。 抖音崛起，短视频抢走了用户时间； 小红书崛起，种草抢走了商业转化； 现在的AI，更要抢走"入口"。 如果AI成为用户的第一触点—— “帮我订外卖”、“给我推荐电影”、“转100块给老王”—— 用户还需要打开微信吗？ 这才是微信最大的恐惧。 2.2 护城河的三层防线 微信的护城河，不是聊天功能，而是三层防线： 第一层：社交关系链 朋友在微信，你不得不来 这是最坚固的防线 第二层：生态绑定 小程序、视频号、支付、公众号 用户的生活被微信"绑架" 第三层：入口垄断 用户打开手机的第一选择 AI时代，这一层最脆弱 QClaw的使命，就是加固第三层防线。 当用户可以直接在微信里用AI完成一切——为什么要打开别的App？ 能生儿子，绝不养外人。 这是护城河逻辑的精髓。 三、QClaw vs 豆包：降维打击 3.1 两条路线的对比 维度 豆包手机 QClaw 形态 硬件+AI 软件+AI 入口 独立手机 嵌入微信/QQ 用户门槛 换手机 无需任何改变 流量来源 从零开始 直接承接14亿用户 生态绑定 无 微信全家桶 谁更容易赢？ ...

引言：一个看似疯狂的问题 “有没有可能，人完全不需要读AI生成的代码？” 这个问题听起来很极端，甚至有点危险。毕竟，代码是系统运行的基础，不看代码怎么知道AI写对了没有？ 但如果我们换个角度思考： 你会去读编译器生成的汇编代码吗？不会，因为你信任编译器。 你会去读框架的源码吗？很少，因为你信任框架的测试。 你会去读数据库的存储引擎代码吗？不会，因为你信任它的ACID保证。 每一次技术进步，都是在减少人需要"看底层"的场景。 这篇文章要探讨的是：在什么条件下，人可以完全信任AI生成的代码，而不需要去阅读它？ 一、现状：人为什么要读AI生成的代码？ 1. 不信任AI的理解能力 需求：实现用户登录功能 AI理解成了： - 用户输入账号密码 → 验证 → 返回结果 人实际想要： - 用户输入账号密码 → 验证 → 生成JWT → 记录登录日志 → 返回结果 问题：AI理解的需求，可能和人真实意图有偏差。 2. 担心实现细节有问题 # AI生成的代码 def login(username, password): user = db.query(f"SELECT * FROM users WHERE username='{username}'") if user and user.password == password: return {"token": create_token(user)} return {"error": "登录失败"} 问题： SQL注入漏洞 密码明文比对（应该用bcrypt） 没有登录失败限制（可能被暴力破解） 人不看代码，怎么知道这些细节没问题？ 3. 维护的需要 三个月后，需求变了：登录需要支持手机验证码。 如果当初的代码是AI生成的，人没看过： - 哪个文件负责登录逻辑？ - 代码结构是什么样的？ - 哪些地方需要修改？ 4. 责任归属 AI生成的代码上线后出了bug，造成了损失。 老板问：谁审查的？ 你：我没有看代码，直接让AI部署的。 老板：？？？ 人看代码，本质是在承担审查责任。 ...

传统 RAG 的困境 如果你用过 RAG（检索增强生成），应该熟悉这套流程： 文档切片（chunking） 向量化（embedding） 存入向量数据库 查询时检索 Top-K 相似片段 喂给 LLM 生成答案 这套方案有个致命问题：切片粒度很难把握。 切太小，语义不完整；切太大，噪音太多。更麻烦的是，向量相似度检索本质上是模糊匹配——它能找到相关的内容，但不一定能找到精确的内容。 比如你问项目预算在第几章？，向量检索可能返回一堆提到预算的片段，却无法告诉你精确的章节位置。 PageIndex 的思路：给 AI 一张地图 PageIndex 的核心理念很简单：不用向量，用结构。 它把文档解析成一棵层级树： 文档 ├── 第一章 概述 │ ├── 1.1 项目背景 │ └── 1.2 目标与范围 ├── 第二章 技术方案 │ ├── 2.1 架构设计 │ └── 2.2 技术选型 └── 第三章 实施计划 这棵树直接放在 LLM 的上下文窗口里。检索时，LLM 像人一样读目录找答案： 问题：架构设计在哪？ → LLM 定位到 第二章 > 2.1 架构设计 问题：项目总体目标是什么？ → LLM 定位到 第一章 > 1.2 目标与范围 这就是 推理即检索（Reasoning-based Retrieval）。 ...

2026年2月，一个让开发者困惑的消息：OpenAI 收编了 OpenClaw。 困惑的点在于——这项目看起来没技术含量：调用 LLM API、连 WhatsApp、操作文件，哪一项不是现成的技术？凭什么 Meta、xAI 都要抢，扎克伯格亲自下场？ 更让人不解的是，Peter Steinberger 本人也说：这只是一个周末业余项目，用 Codex 几个月就写出来了。 如果技术不是重点，那巨头到底在抢什么？ 一、一个反直觉的开场 在回答这个问题之前，让我们先看一个有趣的平行案例。 Sam Altman 在回顾 OpenAI 十年历程时说过一句话： “我觉得站在创新前沿的代价就是你会犯很多蠢错误，因为你深陷战争迷雾之中。” 这句话看似在解释失败，实则揭示了创新的本质——真正有价值的发现，往往来自"在黑暗中摸索直到找到光"。 OpenAI 的成功产品 ChatGPT，按 Altman 自己的说法，“确实是个意外”。他们原本计划用 GPT-4 发布聊天产品，但担心"同时推出会像是通过了图灵测试"，才先用 GPT-3.5 试水。 这个"意外"改变了世界。 这个故事和 OpenClaw 有什么关系？ 关系在于：两者都揭示了一个被忽视的真相——在 AI 时代，技术正在快速商品化，真正稀缺的是对场景的洞察力。 二、Peter 的选择：一个清醒的判断 2026年2月14日，情人节。Peter Steinberger 在博客上宣布加入 OpenAI。 很多人困惑：OpenClaw 不是正火吗？GitHub 19.6 万颗星，三个月。三大云争相上线一键部署，网易直接推出国产版。整条产业链两周内形成。 这么火，为什么要走？ Peter 的解释是：他想让他妈妈也能用上 Agent，加入 OpenAI 是最快的路。 这个解释很坦诚，但它掩盖了一个更深的逻辑：OpenClaw 所在的那一层，正在被吸收。 不是 OpenClaw 不好。恰恰相反，正因为 OpenClaw 太好了，它证明了"个人 Agent 编排"这件事是可行的，于是 OpenAI、Anthropic、Google 都开始亲自下场做同样的事。 当最顶级的玩家开始认真做一件事，独立创业者就没有空间了。 Peter 选择加入 OpenAI，某种程度上是一个清醒的判断：与其在一个正在被吸收的层里继续建造，不如去更高的地方。 ...

前言 AI Agent 正在成为软件架构的重要组件。但如何让 Agent 能够被远程访问，是一个容易被低估的技术决策。 不同的协议选择，会直接影响： 用户体验：延迟、流畅度 开发成本：实现难度、调试复杂度 运维成本：资源占用、可扩展性 应用场景：能做什么、不能做什么 本文从技术角度深度分析几种主流协议，帮助你做出最佳选择。 协议全景图 ┌─────────────┬──────────────┬──────────────┬─────────────┐ │ 协议 │ 连接类型 │ 通信模式 │ 适用场景 │ ├─────────────┼──────────────┼──────────────┼─────────────┤ │ HTTP/REST │ 短连接 │ 请求-响应 │ API 服务 │ │ WebSocket │ 长连接 │ 全双工 │ 实时交互 │ │ SSE │ 长连接 │ 单向推送 │ 流式输出 │ │ gRPC │ 长连接 │ 全双工 │ 内部服务 │ │ SSH │ 长连接 │ 终端交互 │ CLI 工具 │ └─────────────┴──────────────┴──────────────┴─────────────┘ 一、HTTP/HTTPS + RESTful API 1.1 工作原理 最传统的方式。客户端发送 HTTP 请求，服务器返回 Agent 的响应。 ...

前言 2026年2月25日，路透社的一则报道在科技圈炸开了锅： DeepSeek 发布 V4 之前，打破行业惯例，没有向英伟达和 AMD 提供早期访问权限，而是让华为等中国芯片厂商提前数周开展适配工作。 这条新闻的分量，不在于技术突破，而在于选择的姿态。 打破的惯例 AI 行业有一条不成文的规则：模型厂商会优先与英伟达合作，确保新模型在主流硬件上高效运行。这不是商业偏好，而是生存本能——英伟达占据了 AI 芯片市场 80% 以上的份额，你的模型如果不能在 CUDA 上跑得好，基本等于废了一半。 DeepSeek 之前也是这么做的。它的 V3、R1 等模型都与英伟达工程师紧密合作，确保在 H100、H800 上有最佳性能。 但这次不一样。 V4 发布之前，DeepSeek 没有联系英伟达和 AMD，而是让华为等中国芯片厂商提前几周拿到模型进行适配。这是对行业惯例的公然违背。 英伟达和 AMD 拒绝置评。DeepSeek 和华为未予回应。 沉默本身，就是一种态度。 选择的背景 这不是一个孤立的技术决策。理解这个选择，需要看更大的背景。 美国芯片出口管制的困局 2025年12月，特朗普政府宣布允许英伟达向中国出口 H200 芯片，但有附加条件： 保障美国"国家安全" 美国政府获得25%的分成 消息一出，英伟达要求供应链增产 H200，预判中国需求旺盛。 然而两个月过去了，H200 对华销售数量为零。 美国商务部官员在国会听证会上承认：“据我了解，截至目前，数量为零。” 原因很简单：国务院坚持更严格的限制，许可证审批陷入僵局。英伟达方面"十分沮丧"，有知情人士直言"国务院把事情变得非常困难"。 中国客户的观望 在许可条件不明朗的情况下，中国客户没有向英伟达下达订单。部分供应商已暂停生产 H200 的关键组件。 这不是短期的波动，而是供应链重构的开始。 当未来充满不确定性，企业会本能地寻找替代方案。华为昇腾、寒武纪、摩尔线程——这些曾经被视为"备胎"的国产芯片，正在从边缘走向中心。 DeepSeek 的考量 DeepSeek 为什么做出这个选择？ 1. 用户在哪里，适配就优先到哪里 DeepSeek 在 Hugging Face 上的模型下载量已超过 7500 万次，中国是重要市场。如果 V4 发布时，华为昇腾芯片的用户能获得更好的性能体验，这对 DeepSeek 的生态建设是利好。 ...

前言 2026年2月25日，一条新闻在AI圈刷屏： Kimi K2.5 上线不足20天，累计收入已超过2025年全年总和。 同一周，另一个消息鲜有人注意： 智谱AI招股书披露：云端部署业务毛利为零。 两家公司，同一个行业，两种命运。 这不是个案，而是整个大模型行业的缩影——在价格战、开源潮、出海竞争的三重挤压下，有人突围，有人挣扎，有人注定出局。 本文将基于最新的公开数据和报道，深度解构国内外AI大模型厂商的真实生存局面。 一、行业的"烧钱悖论" 1.1 成本结构：为什么赚钱这么难？ 大模型的核心成本来自三块： 成本类型 说明 量级 训练成本 一次完整训练的算力消耗 数千万-上亿美元 推理成本 每次API调用的GPU消耗 持续、可变 人力成本 顶尖AI研究人才 百万美元/年/人 以GPT-4为例，业界估计其训练成本约1亿美元。但这只是开始——每次用户提问，OpenAI都要消耗GPU算力。 推理成本的残酷现实： 过去3年，AI推理成本下降了超过99%。 但即便如此，当你的API价格降到OpenAI的1/10时，你可能仍在亏本。 1.2 收入困境：价格战没有赢家 2025年下半年，国内大模型行业进入"自杀式价格战"： 阿里云、百度提供免费长文本服务 DeepSeek API价格持续下探 各家Coding Plan套餐定价低于成本 智谱AI的招股书数据很说明问题： 云端部署业务毛利为0——这还是按原价售卖API的情况下。 换句话说，智谱每卖出1元钱的API服务，成本就是1元。不算研发、不算人力，仅算力成本就吃掉了全部收入。 这不是智谱的问题，是整个行业的问题。 二、谁在赚钱？突围者的共同密码 2.1 Kimi的"降维打击" 2026年2月25日，腾讯新闻披露了一组令人咋舌的数据： 月之暗面（Moonshot AI）核心数据： K2.5发布20天，收入超过2025年全年 全球付费用户环比增长4倍 海外收入首次超越国内 估值突破100亿美元，成为国内最快"十角兽" API定价比OpenAI低6-10倍 Kimi做对了什么？ 策略一：全面开源 + MIT协议 K2.5采用MIT开源协议，这是最宽松的开源许可——开发者可以商用、可以闭源、几乎没有任何限制。 更重要的是：全面兼容OpenAI API接口。 海外开发者无需重写代码，仅需替换一行URL即可无缝切换。 这种"无感替代"策略，让Kimi在GitHub、Hugging Face等国际社区迅速渗透。 策略二：放弃国内免费流量，专注海外付费市场 2025年，Kimi做了一个当时被质疑的决定： 砍掉Ohai、Noisee等C端泛娱乐产品线，将资源集中于基座模型与Agent研发。 当时国内同行都在做"免费聊天机器人"抢用户，Kimi却选择了另一条路。 事实证明，这个选择是对的： 国内用户习惯了"免费"，付费意愿低 海外开发者更愿意为高质量API付费 OpenAI的高定价给竞争对手留出了空间 策略三：技术差异化 ...

2025年初，Anthropic 推出了 Claude Code。这不是一个普通的代码补全工具，而是一个代理式（Agentic）编程助手——它能理解整个代码库、执行 bash 命令、查看 Git 历史、运行测试，甚至自主规划多步骤任务。 研究显示，使用它能让开发速度提升 5 倍以上。 很多人开始问一个尖锐的问题：如果 AI 能帮我们写代码，内部编程框架还有必要存在吗？ 这篇文章不谈炒作，只回答一个问题：AI 编程工具和内部框架，到底是什么关系？ 一、事实：Claude Code 的当前实力 1.1 它能做什么？ 根据 Anthropic 官方文档和开发者社区反馈，Claude Code 的核心能力包括： 1. 理解整个代码库 不是局部补全，而是项目级理解 能追踪跨文件的依赖关系 能理解代码的设计意图 2. 代理式工作流 不只是"写代码"，而是"完成任务" 你说"帮我构建一个 React 组件"，它会： 3. 终端集成 能执行 bash 命令 能查看 Git 历史 能运行测试和构建 4. 上下文记忆 通过 CLAUDE.md 文件记录项目细节 能记住代码风格、常见问题、团队规范 5. Skills 模块（2025年新功能） 可重用的工作流 支持市场共享 可构建自定义代理 1.2 它不能做什么？ 1. 不理解业务战略 它能写代码，但不能决定"应该做什么" 2. 不负责长期维护 生成的代码需要人工审查和改进 3. 不知道你的框架规范 除非你明确告诉它（通过 CLAUDE.md 或提示词） 4. 不能替代架构设计 ...

前言 2026 年 2 月 21 日，一条看似低调的消息在科技圈炸开了锅： OpenAI 将 2030 年算力支出目标从 1.4 万亿美元下调至 6000 亿美元。 降幅 57%。直接腰斩还多。 如果你关注 AI 行业，应该记得几个月前 Altman 还在高调宣称要投资"万亿级基础设施"。当时整个行业都在讨论：算力缺口有多大？GPU 还要涨多少？数据中心建得够不够快？ 然后，OpenAI 自己踩了刹车。 这不仅仅是数字的调整，更是整个行业心态转变的信号。 一、发生了什么？ 让我们先看看具体数据： 算力支出目标调整 原计划：2030 年投入 1.4 万亿美元（约 9.68 万亿人民币） 调整后：6000 亿美元（约 4.15 万亿人民币） 降幅：57% 估值调整 原估值：8300 亿美元 调整后：7300 亿美元 降幅：12% 财务目标 2030 年营收预期：超 2800 亿美元 2025 年实际收入：131 亿美元（超原目标 100 亿） 2025 年资金消耗：80 亿美元（低于预估 90 亿） 融资情况 新一轮融资规模：超 1000 亿美元 战略投资者占比：90% 主要投资方：软银、英伟达（最多 300 亿）、亚马逊 表面上看，这是 Altman 对此前"激进承诺"的修正。但更深层的问题是：为什么需要修正？谁在推动修正？ ...

假期有闲暇学习一下AI相关的知识，尝试着想用公众号对接DeepSeek做一个问答，当做一个BlogAgent，又不想写太多的工程类的代码，想着AI这么强大，能不能直接用AI生成代码。没有看阿里，百度的产品，直接试用了豆包的AI编程，通过这两天的试用，AI惊人的生产力着实让我惊掉下巴。 一、项目级代码生成 我一开始描述，要求 实现一个微信公众号的后台服务代码，可以接收用户信息，并且回复。 豆包直接生成了一个Python的代码，实现了微信公众号的后台接口，并且实现了签名认证，并且给出了详细的代码说明和注意事项。 然后我又要求使用Java+Spring Boot实现，它竟然给我实现了了一个完整的Maven项目。代码下载下来是真的可以跑的。 二、根据要求重构代码 在仔细看了下整个工程，代码就是一个Spring Boot的启动类，再加一个Controller。稍显不足的是，关于签名的代码，放在了Controller里，导致代码很乱。我随即发了一个优化建议： 把WechatController里的通用公共代码抽出去 这货竟然完全听懂了，乖乖的提取了一个Utils类，把签证签名，XML解析等相关的操作放了进去。 我又对比了下微信的API文档，我疑问道： POST接口不需要验证签名吗？ 它竟然立马意识到自己的错误，修正了自己的错误： 三、根据要求增添内容 我继续下达着我的命令： >请生成Spring Boot的配置文件 >再加入log4j2的日志框架，把相关的异常打到日志里 >把参数搞成对象，把解析xml改成通用的反序列化拦截器 >响应体也可以搞成对象，使用序列化拦截器 >把token改成配置项形式，放在配置文件里 >使用langchain4j集成调用deepseek。当微信用户发来消息以后，转发给deepseek，然后把响应给微信用户 >Spring Boot的方式初始化langchain4j 并且把相关代码抽出去单独的类，整个项目包名改成com.zhaoyanblog.agent项目名称微blog-agent >帮我在pom里设置国内的maven仓镜像地址 >集成对wordpress的访问，当微信用户请求“wp:” 开头的信息时，搜索WordPress里的文章，返回给用户。 >微信返回的消息 要是一个包含文章的摘要富媒体链接，业务点击消息可以跳转到网站。WordPress的网站地址zhaoyanblog.com。要放在配置文件里。 关于微信的Token也放在额外的类里，不要放在controller里 >请对工程使用Spring boot的方式配置accesslog， >配置文件里的注释在IDEA里是乱码，请修正. …… 它就像一个不知疲倦的程序员，不断的实现着产品经理提出的需求 四、帮我修正Bug 有关freemarker模版的问题，开始我希望把markdown改成HTML。它一开始给我的代码其中有这样一段： <p class="text-gray-800"><span class="speaker-highlight">DeepSeek</span>：<#noescape>${conversation.getContentAsHtml()}</#noescape></p> 但是我真实跑起来的时候，它报这样的错误 #noescape with no matching #escape encountered 它直接给我了解决方案，并解释了原因： <span class="speaker-highlight">DeepSeek</span>：${conversation.getContentAsHtml()?no_esc}</p> 但是好像还不行，我直接把报错信息再贴给它 ?no_esc can't be used here, as the current output format isn't a markup (escaping) format: undefined(mimeType=null, class=f.c.UndefinedOutputFormat) 这次它给的答案，完美解决了问题： 五、竟然提示我遵守规范 ...