AI探索指南

  1. 的理发师,之所以越来越懂你,不是因为他的剪刀升级了

    的理发师,之所以越来越懂你,不是因为他的剪刀升级了。
    是因为他逐渐学会了你的审美和验收标准。
    Agent也是一样。
    真正优秀的Agent,不会只保存聊天记录。
    它会逐渐建立一个关于用户的模型,知道这个用户在什么场景下,想要什么样的结果。
    所以我现在越来越觉得,Agent的核心并不只是模型能力。
    它还包括需求确认、Context管理、过程反馈和长期Memory。
    现在很多Agent最大的问,就是太像一个过度自信的理发师。
    用户拿出一张图,说照这个剪。
    它回答:明白。
    然后低头就是一剪刀。
    真正可靠的Agent,必须知道自己不知道什么。
    @aigc1024

  2. 很多人都没意识到,用Agent做事,尤其是Vibe Coding,本质上就是去理发

    很多人都没意识到,用Agent做事,尤其是Vibe Coding,本质上就是去理发。
    前段时间我去理发,拿了一张GPT帮我改过的发型图,问理发师能不能帮我剪成这样。
    他明显有点犹豫。
    我问他为什么。
    他说,这种需求最难。
    因为他根本不知道,这个发型是怎么剪出来的。
    这只是一张最终效果图。
    没有过程,没有侧面,没有背面,也没有告诉他每个地方该留多长。
    他只能盯着结果,反推中间步骤。
    更麻烦的是,他也不知道自己到底能不能做到。
    图片里的效果可能依赖发质、头型、打理方式,甚至可能根本不符合现实。
    他既不知道路径,也无法完全确认自己的能力能不能实现。
    我当时突然觉得,这不就是今天所有Agent面对的问吗?
    用户给出的通常只是一个模糊的结果。
    但这个结果怎么实现,中间需要哪些步骤,有哪些隐藏条件,用户自己往往也说不清楚。
    Agent只能猜。
    它要猜用户真正想要什么,也要猜自己应该怎么做。
    一个模型可能很会写代码,但它不知道这个项目里会不会遇到没权限的接口、不兼容的依赖、缺失的数据,或者某个自己根本处理不了的问。
    所以Agent面对的,其实是两种不确定性。
    第一种是需求不确定性。
    用户说想要一个高级的网站。
    什么叫高级?
    是视觉高级、交互高级、代码架构高级,还是看起来适合融资?
    用户自己脑子里可能有一个感觉,但很难完整表达出来。
    第二种是执行不确定性。
    Agent即使理解了目标,也不代表它知道最合适的实现路径,更不代表它一定做得到。
    这和理发师拿着一张AI发型图时的状态完全一样。
    我又问理发师,那你遇到这种需求,怎么尽量避免剪坏?
    他说,最好的办法就是剪之前先给你看效果,剪的过程中不断问你。
    这其实就是一个可靠Agent应该有的工作方式。
    执行前,先把自己的理解展示出来。
    执行过程中,也不要一口气直接做到最后。
    遇到不可逆操作,需要单独确认。
    Agent真正需要优化的,并不是少问问。
    它需要学会在正确的时间,问最有价值的问。
    问得太多,用户会烦。
    完全不问,最后很容易把头发直接推成三毫米,然后告诉你任务已完成。
    而理发师还告诉了我另一件事。
    我问他,什么情况下你最有可能剪出一个超过客户预期的发型?
    他说,最好是这个客户已经在我这里剪过很多次。
    我知道他的头发是什么状态,知道他喜欢什么,知道他平时怎么打理,也知道他说剪短一点,到底是多短。
    这就是Memory真正的价值。
    Memory并不只是记住用户上次说了什么。
    一个长期合作

  3. 《算完这笔账,我发现机器人的iPhone时刻比所有人想的都近》

    《算完这笔账,我发现机器人的iPhone时刻比所有人想的都近》
    昨天跟做具身智能的朋友吃饭,大家都在说"数据是瓶颈"——真实场景的第一视角操作数据太少,实验室里攒的那点根本不够用。
    回家我算了一晚上,结果吓一跳:这个瓶颈,可能根本不需要几千万台机器人,100万台消费级产品进家庭,一年就破了。
    先给你们看现在行业有多惨:
    • Meta砸了那么多钱做的Ego4D,迄今为止最大的公开第一视角数据集,3670小时
    • 斯坦福那个RDT-2,100个专门的UMI采集器扔到100多户人家里玩命录,最后也就1万小时
    • 小米机器人吹了半天,预训练用了10万小时UMI,真正来自真实家庭的机器人数据,7200小时
    7200小时什么概念?还不够一个人连续看一年。
    那要练出一个真正能用的机器人大模型,到底需要多少有效数据?
    大家普遍的共识是1000万小时起步,1亿小时基本就够打了。
    问来了:得卖多少台机器人进家庭,才能一年攒够这个数?
    我把所有参数拆到最保守算了一遍:
    • 单台机器人一天真正干活(不是待机、不是用户瞎玩)的时间:1小时(扫地机器人都能跑1.78小时,操作机器人不会比这个少)
    • 录下来的视频里真正能用来训练的有效率:10%(专业采集员8小时也就出2-3小时有效数据,普通用户瞎用能有10%不错了)
    • 用户愿意开数据上传的比例:30%(家里的视频,换你你也不一定敢开)
    • 买回去不积灰的月活率:50%(参考所有消费电子)
    最后算出来单台机器人一年能贡献36.5小时有效数据。
    所以答案是:
    ✅ 1000万小时有效数据 = 27万台活跃贡献的机器人 = 80-120万台总销量
    ✅ 1亿小时有效数据 = 270万台活跃贡献的机器人 = 800-1200万台总销量
    什么概念?
    100万台年销量,是什么水平?
    ——特斯拉Cybertruck去年卖了差不多这个数。
    1000万台年销量,就是iPhone首年的销量水平。
    换句说:
    不需要机器人像手机一样人手一台,只要它能成为一个年销百万级的"小众爆品",数据飞轮就转起来了。
    一旦转起来,后面就是指数级的正向循环:数据越多→机器人越好用→买的人越多→数据更多。
    几个反常识的点:
    1. 有效率才是最大杠杆:如果能把有效数据率从10%提到30%,需要的机器人数直接砍到1/3。这就是为什么现在所有公司都在死磕自动数据筛选和任务引导——你家机器人擦桌子的10分钟里,哪30秒是真正有价值的,自动挑出来,效率直接翻三倍。
    2. 隐私比技术难搞:第一视角拍的是你家全貌,要是能靠端侧计算、联邦学习把opt-in率从30%拉到70%,门槛又降一半。谁先解决"数据可用不可见",谁就拿到了数据飞轮的钥匙。
    3. 临界点比所有人想的都近:之前大家都觉得要几千万台才能破局,现在看,只要有一家公司能把消费级机器人做到年销100万台——注意,是真正能用的、不是玩具——数据瓶颈明年就破。
    最后说个玄学:
    互联网的历史告诉我们,所有的"数据瓶颈",最后都是靠消费级产品普及解决的,不是靠实验室堆人。
    语音识别的数据瓶颈,是智能手机普及破的;
    人脸识别的数据瓶颈,是美颜相机普及破的;
    自动驾驶的数据瓶颈,是特斯拉卖车破的。
    机器人也不会例外。
    现在看100万台好像很多,回头看,可能就是某一款产品发布后一年的事。
    那个临界点,比我们所有人想象的,都要近得多。
    (欢迎做机器人的朋友来杠,我也想知道我哪里算错了👀)
    @aigc1024

  4. 上周 ChatGPT Health 的功能向美国用户推出了,我试了一下,这东西非常顶啊!

    上周 ChatGPT Health 的功能向美国用户推出了,我试了一下,这东西非常顶啊!
    即使你没有美国其他的健康应用,只是有 Apple Watch 的一些健康数据,它也能分析出非常多的信息。
    比如说我长期的那个“有氧适能”低问。我一直以为是自己身体有什么问,导致长期运动以后依然无法提升。
    但是 GPT 就分析出来了(尤其是配合 ChatGPT Pro 使用,效果更顶):
    它分析出这是因为 Apple Watch 的有氧适能测试只针对徒步和跑步,而我这两个运动进行得比较少,所以它就没有机会进行测试。
    还有就是它对你身体的运动量、睡眠,以及其他一些因素对健康的影响,分析得都非常准确。
    其实我们在 Apple Watch 中的很多数据平时都被浪费了,如果拉长时间维度来看,这些数据非常有用。
    现在 ChatGPT 可以对这些数据进行非常准确和清晰的分析,它还会去检索各种权威的健康信息网站。
    如果你经常使用 Apple Watch 的,建议你开启这个功能试试。目前该功能只针对美国市场开启。
    甚至可以设置一个定时任务,让它每周针对你这周的这个 Apple Watch 数据,给你一份健康报告
    @aigc1024

  5. Claude Code 已将代码审查做成“可调档位”:

    Claude Code 已将代码审查做成“可调档位”:
    Low:低成本快速检查
    Medium:性价比最高,适合日常使用
    High:深度审查重要功能
    Ultra:多个 Agent 并行找 Bug,再独立复现验证,减少误报
    投入更多算力,检查就更深入。现在的开发流程,已经是 AI 写代码,另一组 AI 负责挑错,人类只审核关键决策。

    AI探索 | Hermes/OpenClaw|优质资源|优质信息

  6. 夯爆了!三句让 AI 反推生图提示词

    夯爆了!三句让 AI 反推生图提示词。
    第一句:
    “帮我拆解这张图片,重点分析主体、场景、风格、色调、构图和细节,越详细越好。”
    第二句:
    “根据以上分析,反向生成一套完整的 AI 生图提示词,最大程度还原原图的风格、氛围和质感。”
    第三句:
    “把这套提示词优化成 AI 可直接生图的版本,补充细节,优化表达,确保复制即可使用。”
    @aigc1024

  7. 美国总统科技顾问David Sacks公开甩出一句:Kimi K3修好了15个关键安全漏洞,而Codex和Fable以"网络安全护栏"为由拒绝修

    美国总统科技顾问David Sacks公开甩出一句:Kimi K3修好了15个关键安全漏洞,而Codex和Fable以"网络安全护栏"为由拒绝修。
    有趣的市场,有人指出他现在骂的护栏,正是他当初支持的那类;拿一个"修bug轶事"去推翻整套AI安全政策,逻辑上跳得太快。

    AI探索 | Hermes/OpenClaw|优质资源|优质信息

  8. 看电视刷到《硅谷坐标》这个节目,发现挺有意思啊,这简直是技术人的综艺节目🤣

    看电视刷到《硅谷坐标》这个节目,发现挺有意思啊,这简直是技术人的综艺节目🤣
    看输出猜模型这个环节太好玩了,就连研究员们也猜不准!
    听听Open AI研究员们对御三家AI大模型的一些理解,对于新模型发布前旧模型会降智的问,看看他们怎么答👇

    AI探索 | Hermes/OpenClaw|优质资源|优质信息

  9. 看电视刷到《硅谷坐标》这个节目,发现挺有意思啊,这简直是技术人的综艺节目🤣

    看电视刷到《硅谷坐标》这个节目,发现挺有意思啊,这简直是技术人的综艺节目🤣
    看输出猜模型这个环节太好玩了,就连研究员们也猜不准!
    听听Open AI研究员们对御三家AI大模型的一些理解,对于新模型发布前旧模型会降智的问,看看他们怎么答👇

    AI探索 | Hermes/OpenClaw|优质资源|优质信息

  10. 看电视刷到《硅谷坐标》这个节目,发现挺有意思啊,这简直是技术人的综艺节目🤣

    看电视刷到《硅谷坐标》这个节目,发现挺有意思啊,这简直是技术人的综艺节目🤣
    看输出猜模型这个环节太好玩了,就连研究员们也猜不准!
    听听Open AI研究员们对御三家AI大模型的一些理解,对于新模型发布前旧模型会降智的问,看看他们怎么答👇

    AI探索 | Hermes/OpenClaw|优质资源|优质信息

  11. 清华开源 20k star,只需单击一下,即可获得沉浸式多智能体学习体验

    清华开源 20k star,只需单击一下,即可获得沉浸式多智能体学习体验
    输入主或扔份文档,OpenMAIC 立刻生成完整课堂:AI老师实时讲课+白板画图,AI同学主动辩论,你随时插提问,还能上手调参数跑3D模拟、玩小游戏、在线写代码。
    支持本地部署、Ollama/Lemonade零API key,PPTX/HTML一键导出,也能直接从飞书/Telegram拉起。
    MIT协议,自部署随便玩,学东西终于不是被动刷视频了。

    AI探索 | Hermes/OpenClaw|优质资源|优质信息

  12. OPC 的第一原则就是:

    OPC 的第一原则就是:
    从你下决心做 OPC 第一天开始,你就应该是盈利的!
    为什么说第一天就应该开始盈利,因为:
    一台电脑 + 一个AI订阅 + 一个有Wi-Fi的咖啡馆足够你开始赚钱!
    如果没有赚到钱,那就说明你没有发现需求的能力,没有找到客户的能力,没有开发产品的能力…
    那么找个班上是最好的选择…

    AI探索 | Hermes/OpenClaw|优质资源|优质信息

  13. aude)

    aude)
    但在真正删减之前,还应该先建立评测。
    因为 Anthropic 所说的是在其编程评测中没有观察到损失,不代表删除 80% 的规则适用于每个公司、每个 Agent 和每个业务场景。
    客服、金融、医疗、生产运维和代码生成面对的风险完全不同。
    更合理的方式是:
    先建立一组真实任务和历史失败案例。
    记录当前版本的完成率、错误率和人工干预率。
    逐步删除重复和过度限制的规则。
    比较修改前后的结果。
    保留真正能降低风险的规则,删除只是在制造心理安全感的规则。
    最后
    这篇文章表面上讨论的是 Claude Code 的系统提示词,背后反映的其实是人类与模型协作关系的变化。
    模型能力弱的时候,人类需要把每一步都写清楚。
    模型能力增强以后,人类更重要的工作不再是替它决定每一步,而是:
    定义目标。
    提供真实环境。
    设计工具。
    划定边界。
    建立反馈。
    验证结果。
    这和管理一个团队很像。
    面对经验不足的人,需要给详细 SOP;面对能力强的人,继续事无巨细地规定每一个动作,反而会降低他的判断力和创造力。
    因此,模型越强,上下文工程越不应该追求“把所有事情都写进去”。
    真正优秀的上下文,不是信息最多、规则最细,而是:
    该出现的信息,在正确的时候出现;该由模型判断的,留给模型判断;该由系统保证的,绝不只依赖模型自觉。
    提示词工程没有消失。
    它只是从“教模型说什么”,升级成了“设计模型如何工作”。
    @aigc1024

  14. 模型越聪明,越不能把它当成流程机器人

    模型越聪明,越不能把它当成流程机器人
    Anthropic 最近发布了一篇关于上下文工程的文章。
    随着 Claude Fable 5 和 Opus 5 发布,他们删除了 Claude Code 超过 80% 的系统提示词,但在内部编程评测中没有观察到明显损失。过去那些用来“保护模型”的详细规则,随着模型能力提升,开始变成限制模型能力的枷锁。(Claude)
    很多人看到这里,可能会得出一个结论:
    提示词工程已经不重要了。
    但我认为,更准确的说法是:
    提示词工程正在从“写更多指令”,转向“设计更好的上下文结构”。
    一、为什么模型越强,规则反而要越少?
    早期模型判断力较弱,经常会出现过度注释、擅自修改文件、遗漏验证步骤、错误调用工具等问。
    为了弥补模型能力的不足,人们只能不断增加规则:
    不要写太多注释。
    不要修改无关文件。
    修改前必须先阅读代码。
    完成后必须运行测试。
    不要创建额外文档。
    不要执行危险命令。
    这些规则在当时是有价值的,因为它们相当于模型的“外置判断系统”。
    但随着模型能力提升,模型已经能够从代码风格、目录结构、用户意图和任务目标中推断出很多事情。此时继续保留过去的详细约束,就可能产生三个问。
    第一是规则冲突。
    系统提示词说“不要写注释”,Skill 说“为复杂逻辑增加注释”,用户又说“保持和原项目一致”。模型需要先花费推理能力判断到底听谁的。
    第二是注意力稀释。
    上下文窗口虽然越来越长,但模型真正需要解决的是:哪些信息与当前任务最相关。大量通用规则会挤占模型对代码、需求和异常信息的关注。
    第三是能力折损。
    一些规则原本是为了防止旧模型犯错,但新模型已经能够处理例外。继续强制执行规则,就相当于要求一个高级工程师严格按照新员工操作手册工作。
    Anthropic 过去要求 Claude 默认不写注释,新版则只保留一句更高层的原则:
    写出与周围代码一致的代码,匹配它的注释密度、命名和惯用方式。
    前者是在规定动作,后者是在定义判断标准。(Claude)
    这背后其实是一种管理方式的变化:
    过去是给模型 SOP,现在是给模型目标、边界和判断依据。
    二、规则不是越少越好,而是要放在正确的位置
    “精简系统提示词”不等于“不要规则”。
    真正应该删除的,是模型可以从环境中自行推断出来的规则,以及在不同上下文层里被重复描述的规则。
    而以下几类内容仍然需要明确保留:
    不可逆操作的边界。
    安全、隐私与合规要求。
    明确的业务目标和角色定位。
    模型无法从代码中发现的特殊约定。
    容易踩坑但没有显性提示的历史问。
    例如,“保持代码风格一致”可以交给模型判断;但“未经确认不得删除生产数据库”就不能只依赖模型的判断力,而应该通过权限、审批、沙箱和工具限制来保证。
    所以未来的 Agent 不是没有约束,而是把约束分成两种:
    软约束交给模型理解,硬约束交给系统执行。
    能通过权限控制的,不要只写在提示词里。
    能通过参数类型保证的,不要依靠自然语言提醒。
    能通过测试验证的,不要要求模型“务必认真检查”。
    能通过状态机限制的,不要让模型在无限的行动空间里自由选择。
    三、从“给示例”到“设计接口”
    过去教模型使用工具,最常见的方法是给它几个调用示例。
    但示例存在一个问:它不仅告诉模型怎么做,也在无形中限制模型只能在示例附近探索。
    更好的方法,是把工具本身设计得足够清晰。
    例如,一个任务工具的状态参数只允许:
    pending
    in_progress
    completed
    这三个枚举值本身就在向模型表达任务的生命周期。
    再规定同一时间只能有一个任务处于 in_progress,模型自然就能理解任务切换和进度管理,而不需要再写十几个调用示例。Anthropic 将这种变化总结为:从提供示例,转向设计具有表达力的接口。(Claude)
    这件事对 Agent 产品特别重要。
    很多 Agent 不稳定,并不一定是模型能力不够,而是工具设计得太模糊:
    参数含义不清楚。
    多个工具能力重叠。
    返回结果没有固定结构。
    失败原因无法被模型识别。
    工具名称无法表达真实用途。
    权限和使用条件只藏在提示词里。
    于是开发者只能继续增加提示词,试图用自然语言弥补糟糕的接口设计。
    但真正优秀的 Agent 架构,应该让工具的名称、参数、返回结构和权限边界本身就构成上下文。
    最好的提示词,有时不是一段文字,而是一个设计良好的接口。
    四、上下文窗口不是仓库,而是工作台
    过去构建 Agent 时,大家很容易产生一种冲动:
    把所有可能有用的信息都提前塞进上下文。
    业务规则、操作手册、历史案例、代码规范、工具说明、异常处理、测试流程,全部放进系统提示词或者 CLAUDE.md。
    这样看起来信息非常完整,但结果往往是模型每次处理一个小任务,都要背着一整套知识库上路。
    Anthropic 现在强调的是“渐进式披露”:
    系统提示词只放长期、通用、必须始终存在的信息。
    CLAUDE.md只描述仓库用途、核心约定和真正难以发现的坑。
    代码审查、发布、验证、数据迁移等独立流程拆成 Skills。
    具体任务需要的设计稿、代码、测试和资料,通过引用或搜索按需加载。
    工具的完整定义,也可以在真正调用时再载入。
    Claude Code 的 Skills 正是采用这种方式:Skill 的主体只有在相关任务触发时才加载,因此长流程和参考资料不会在每次会开始时持续占用上下文。(Claude)
    这其实说明,上下文管理正在越来越像计算机的存储层级:
    系统提示词类似操作系统内核。
    CLAUDE.md类似项目配置。
    Skills 类似按需加载的程序模块。
    Memory 类似跨会的长期记忆。
    当前对类似工作内存。
    引用文件和检索结果类似临时调入的外部数据。
    问不再是“模型知道多少”,而是:
    它能否在正确的时间,获取正确的信息。
    所以长上下文并不能自动解决上下文问。
    一个 Agent 即使拥有数百万 Token 的窗口,如果把过期规则、重复规则和互相冲突的规则全部装进去,仍然会表现得很差。
    上下文工程的核心不是扩容,而是调度。
    五、从简单文档到“可执行的上下文”
    Anthropic 还提到一个很重要的变化:
    过去人们主要给模型 Markdown 需求文档,现在可以直接给它 HTML、代码、测试文件、函数实现和评分标准。
    这意味着“上下文”不再只是文字说明,而可以是能够被执行、比较和验证的对象。(Claude)
    例如要实现一个页面,与其写几百字描述:
    顶部有导航栏,左侧有菜单,卡片之间保持一定间距,按钮使用圆角……
    不如直接提供一个 HTML 原型。
    要迁移一个函数,与其解释它应该如何工作,不如直接引用另一个项目中的正确实现。
    要告诉模型什么叫“好的 API”,与其写一些抽象原则,不如给它:
    现有优秀 API。
    反面案例。
    测试用例。
    验收标准。
    评分 Rubric。
    这代表需求表达正在从“自然语言描述”走向“多模态、结构化、可验证的参考环境”。
    未来最有效的上下文,往往不是一句“请认真完成”,而是:
    这里是目标。
    这里是参考实现。
    这里是禁止修改的边界。
    这里是测试方法。
    这里是验收标准。
    模型拥有判断空间,但结果可以被外部系统验证。
    六、从提示词工程,走向环境工程
    把这些变化继续往前推一步,会发现 Agent 开发正在经历三个阶段。
    第一阶段是提示词工程。
    重点是研究一句怎么写,角色怎么设定,示例怎么组织,怎样才能让模型输出理想结果。
    第二阶段是上下文工程。
    重点变成如何组织系统提示词、Memory、Skills、知识库、工具说明、任务历史和引用文件。
    第三阶段可能是环境工程。
    不再主要通过语言要求模型怎么做,而是设计一个让模型自然做对事情的环境:
    工具职责清晰。
    权限边界明确。
    信息可以按需检索。
    关键状态能够持续保存。
    错误可以被观察。
    结果可以被测试。
    失败后可以自动修正。
    高风险操作需要审批。
    也就是说,未来 Agent 的质量,越来越不只取决于模型和提示词,还取决于模型所处的“数字工作环境”。
    同一个模型,放在一个工具混乱、规则冲突、信息过载的环境里,可能表现得像一个能力一般的助手。
    放在一个接口清晰、权限合理、反馈及时、资料可检索的环境里,它才可能表现得像一个成熟员工。
    七、自动记忆并不代表可以放弃知识管理
    Anthropic 从手动写入 CLAUDE.md,逐渐转向自动记忆,这确实可以降低维护成本。
    但自动记忆也会带来新的问:
    模型可能记住错误结论。
    临时偏好可能被误认为长期规则。
    旧项目经验可能污染新项目。
    过期信息可能长期保留。
    个人偏好和团队规范可能混在一起。
    所以 Memory 不能只是“能写进去”,还需要有完整的治理机制:
    记忆从哪里来?
    适用于个人、项目还是组织?
    有效期多长?
    是否有证据和来源?
    什么时候应该更新?
    谁可以查看和删除?
    发生冲突时谁优先?
    未来真正复杂的 Agent 系统,需要的不只是 Memory,而是记忆的生命周期管理。
    八、如何重新整理自己的上下文系统?
    可以先把现有上下文里的每一条信息重新分类。
    始终有效、与产品角色有关的内容,放在系统提示词。
    整个项目长期有效、模型又无法自行发现的约定,放在 CLAUDE.md或 AGENT.md。
    代码审查、部署、测试、调研等可复用流程,拆成 Skills。
    本次任务才需要的需求、代码和设计稿,通过引用按需加载。
    用户习惯、长期偏好和历史经验,放进 Memory。
    安全、权限、审批和不可逆操作,交给代码和系统机制控制。
    然后重点检查三件事:
    有没有同一条规则在多个地方重复出现?
    有没有两条规则在某些场景下互相冲突?
    有没有模型通过阅读代码和目录就能理解、却仍然被写进规则的废?
    Claude Code 现在的 /doctor 会检查未使用但持续消耗上下文的 Skills、MCP 和插件,识别重复的 CLAUDE.md内容,并建议删除模型可以直接从代码库推断的信息。(Cl