“一人失能，全家失衡”，这是许多有失能老人家庭面临的现实困境。被称为社保“第六险”的长期护理保险，正是为了破解这一难题而生。最新数据显示，我国长期护理保险参保人数已超3.2亿，基金累计支出1142亿元，惠及超460万失能人员。然而，随着覆盖面快速扩大，资金安全和评估公平性问题开始浮出水面。9月20日，审计署审计科研所发布报告，直指四大问题，其中失能评估管理存在漏洞、欺诈骗保套保多发尤为刺眼。前不久，上海披露了一起典型的骗保案：有老人前脚刚通过长护险失能评估，后脚就出门旅游、骑车买菜。调查发现，评估机构与护理机构串通，教唆老人“装病”通过评估，再将本该用于医疗护理的资金，变成了上门打扫卫生的“家政服务”。两家机构累计套取基金200余万元。     问题定性难在哪？技术盲区在哪？从审计视角看，这类问题的定性并不简单。它涉及几个层面的判断：评估机构是否履行了独立评估职责？护理服务是否真实发生？资金流向是否与申报服务一致？一个“被失能”的老人，表面上手续齐全、评估报告完整。但如果把评估记录、服务记录、医保结算数据和老人的出行轨迹放在一起比对，矛盾就会暴露。技术上的难点在于数据壁垒：评估数据在卫健委或民政系统，结算数据在医保系统，出行轨迹在交通或公安系统。传统审计靠人工抽查，面对海量、跨系统的数据，几乎不可能做到全量核验。   智能审计的技术破局：从“抽样”到“全量穿透”要识破这类骗局，核心在于多源异构数据的全量关联分析。如果把这条问题交给铭太科技智能审计定性助手，底层技术会这样运转：第一步：基于NLP的问题标准化。 系统通过自然语言处理技术，将“老人装病通过评估、机构提供家政而非护理”的杂乱线索，解析并重构为规范的审计表述：“失能评估管理存在漏洞，护理服务未真实发生，存在欺诈骗保风险”。第二步：知识图谱与规则引擎的定性匹配。 系统依托审计知识图谱，自动关联《长期护理保险失能等级评估管理办法》等法规，匹配“欺诈骗保”的定性特征向量，输出精准的定性结论。第三步：构建异常检测模型生成整改建议。 系统建议建立“评估-服务-结算”三维比对模型：将老人的失能评估等级、护理人员的GPS定位与服务时长、医保系统的结算明细进行交叉验证。如果发现某位“重度失能”老人，其护理工单时间与他的公交出行记录、医疗就诊记录高度冲突，系统自动触发“假服务”预警。每一步的整改动作，系统都会同步生成佐证材料清单：评估记录、服务轨迹、结算明细、追回凭证。措施写得再细，佐证凑不齐，问题就销不了号。 “第六险”的钱，要花在刀刃上长期护理保险制度正在从试点走向全面建制，3.2亿人参保的盘子只会越来越大。钱越多，监管的责任越重。智能审计的技术价值，不是替代审计人员的专业判断，而是打破跨部门数据壁垒，把“评估记录、服务轨迹、结算数据”放在同一个算法模型里跑，让隐蔽的异常特征自己浮出水面。“第六险”保的是失能人员的尊严，也是千万家庭的喘息空间。这笔钱，经不起“被失能”的消耗。

同样的中药，为什么越卖越贵？ 2026年6月，审计署披露的2025年度审计工作报告，揭开了中药产销领域的一块“遮羞布”。审计署调查了10个省份、66户中药企业、28家医疗机构，涉及资金215.91亿元，查出问题金额高达46.52亿元。这近50亿的问题资金背后，藏着几个非常“刺激”的手法： 一是药企虚增中药材采购成本。有的企业为了凑数，连本单位员工都搜集来编造采购记录。二是虚列销售费用，搞“带金销售”推高药价。三是医疗机构侵蚀医保基金。中药是老百姓的“救命药”，医保基金是老百姓的“保命钱”。这些问题不仅掏空了医保资金，更让无数患者为虚高的药价买单。 问题披露了，但难点在怎么查、怎么改。把这条线索交给铭太智能审计定性助手，它的第一步不是急着下结论，而是做疑点全量筛查与问题标准化。  传统的审计抽样，是从100笔里抽10笔看。而智能审计系统可以通过多源数据交叉比对：将中药材采购台账、员工花名册、银行流水、销售费用明细放在同一个数据模型里跑。“采购记录里的供应商，有没有本企业的员工？”“这批中药材的采购单价，为什么比同期市场均价高出这么多？”“巨额的销售费用，最终流向了哪里？”当系统捕捉到这些异常特征后，自动提取关键要素，将模糊的线索转化为标准的审计问题表述：“部分药企通过虚增采购成本、虚列销售费用（带金销售）等方式推高药价，存在套取资金、利益输送风险。”第二步，是问题定性。系统根据特征向量匹配，调取内置的“带金销售”“虚增成本”的定性规则和典型案例，给出定性结论。同时，自动关联《中华人民共和国药品管理法》《医疗保障基金使用监督管理条例》等具体条款，让定性有法可依。 第三步，是整改闭环。查出问题只是“上半篇文章”，整改才是“下半篇文章”。系统自动匹配整改措施：追回被虚增成本套取的资金；规范采购与销售费用核算；建立药企与医疗机构间的合规防火墙。 更关键的是，系统同步生成了佐证清单：采购比价报告、资金流向追查记录、医保基金退回凭证、制度修订文件。措施写得再漂亮，佐证凑不齐，问题就销不了号。 46.52亿元的问题资金，折射出的是中药产业链上的深层次顽疾。靠人工去一一核实，成本高、周期长、易漏审。而智能审计的价值，就是用技术手段穿透数据的迷雾，让隐蔽的违规手法无处遁形，让每一分“保命钱”都花在刀刃上。中药的价格，容不得“水分”。审计的监督，容不得“盲区”。

近日，一张广东佛山12345处理回复工单截图引发热议。   患者给药房工作人员送了一罐1.9元的健力宝汽水，随后通过12345举报，称对方存在违规收礼问题。禅城区卫生健康局调查后回复：该名工作人员未主动索取，主观认为这是老病患对医务人员的感谢，因盛情难却而接收。医院已对该医生进行严厉批评，并对全院人员多次进行《医疗机构工作人员廉洁从业九项准则》培训。卫健局确认，举报以及回复内容属实。  收一罐1.9元的汽水，到底算不算“违规收礼”？这个问题看似简单，实则涉及审计问题定性中最常见的难点：法规条款是固定的，但适用场景是弹性的。我们试着把这条问题丢进铭太科技智能审计问题定性助手，看看AI怎么判断。  第一步：问题标准化智能审计问题定性助手首先把口语化的新闻描述，翻译成规范的审计问题表述：“禅城区某医院药房工作人员在诊疗服务过程中，接受患者赠送的健力宝汽水（价值1.9元），虽未主动索取，但未按规定拒绝或上交，违反医疗机构工作人员廉洁从业相关规定，存在廉洁风险隐患。”一句话的差别，把“收了汽水”变成了“未按规定拒收上交，存在廉洁风险”。定性方向清晰了。第二步：问题定性智能审计问题定性助手给出的定性结论是：“医疗机构工作人员在诊疗服务中收受患者物品，虽未主动索取但未按规定拒收上交，违反医疗机构工作人员廉洁从业九项准则，存在廉洁风险隐患。”  第三步：定性依据自动匹配了相关法规条款：《医疗机构药品集中采购工作规范》第二十七条：严禁以权谋私，不得以任何理由和方式收取财物或牟取其他不正当利益。《食品药品监督管理工作人员八条禁令》第五条：严禁收受行政相对人及相关单位现金、有价证券、支付凭证和贵重礼品。同时，铭太科技智能审计问题定性助手也明确指出：这些法规“现行有效”，可以放心引用。  第四步：审计意见AI自动生成了一段完整的审计意见：“审计发现，禅城区某医院药房工作人员在诊疗服务过程中，接受患者赠送的健力宝汽水（价值1.9元），虽未主动索取，但未按规定当场拒绝或登记上交，事后引发患者通过12345热线举报。该问题反映出医院在廉洁从业管理方面存在制度执行不严、日常管控不到位、岗位人员廉洁风险防控意识不足等管理短板。此类行为违反医疗机构工作人员廉洁从业相关规定，虽涉案金额微小，但暴露出个别工作人员对廉洁纪律底线的认识模糊……存在廉洁合规隐患。”这段话把“1.9元的汽水”和“廉洁纪律底线的认识模糊”联系起来了，定性准确，逻辑完整。  第五步：审计管理建议最后，铭太科技智能审计问题定性助手给出了四条管理建议：健全制度体系：细化诊疗服务中收受患者财物的界定标准、处置流程及登记上交规范。强化宣贯培训：将廉洁纪律教育纳入岗位必修内容，提升风险识别与防范能力。完善日常管控：加强对药房、临床等关键岗位人员履职行为的监督与提醒。健全自查预警：定期开展重点岗位廉洁风险排查，推动从事后处置向事前预防延伸。审计的价值，不是“一刀切”一罐1.9元的汽水，看起来是小事。但它折射出的，是制度执行中“尺度”和“标准”的普遍难题。审计要做的，不是简单地说“对”或“错”，而是让每一个判断都有据可依、有例可循。智能审计问题定性助手，输入问题描述，自动完成问题标准化、匹配定性依据、生成审计意见和管理建议。让审计判断，从“凭经验”走向“有标准”。   你们单位遇到过“收了不合适、不收又不好意思”的情况吗？评论区聊聊。 

​6 月 23 日国家审计署披露：26 个省份工伤保险基金共审计 1151.1 亿元，查出问题 48.69 亿。其中扎眼的一笔 ——16 个省份、100 多家用人单位和劳务派遣公司，从 2015 年至今，靠农民工不懂政策、签 "自愿放弃" 类不平等协议，盘剥克扣工伤保险待遇 1.82 亿！这些不是报表数字，是工地上摔下来、该到那个农民工手里的救命钱。  一、一张 "自愿放弃"，1.82 亿就没了套路不复杂：入职时签 "自愿放弃社保""工伤一次性了断 "；真摔下来，按远低于法定标准私了，还得签收条。工人不懂政策、不敢闹、急着拿钱治伤，协议就生效了。十年时间、上百家公司，一勺一勺舀走 1.82 亿。  二、把建筑工 "包装" 成服务员更隐蔽的一招在参保环节。高风险行业费率高，企业就勾连中介，把一线工人改成服务业低风险岗位按低档费缴 ——170.6 万人被这么 "包装" 过。建筑项目更直接：3.41 万个项目、226 万农民工连工伤保险都没上，应缴保费 25.3 亿。真出了事，往往是社会兜底。 三、两头吃：骗认定、吃器具22 个省份 580 人编造事故和就诊记录，骗工伤认定套取待遇 4813万；12 个省份 44 家辅助器具机构以次充好、虚假配置，虚报多领 2562万。22 个省份 613 家医院还利用 "工伤报销无自付、无封顶" 口子过度医疗，多结算 4.55 亿。 四、这类问题为什么难整改？问题披露了，但整改不是 "退钱" 这么简单。这个案子涉及 16 个省、100 多家公司、跨度 10 年。要查清每一笔被克扣的钱、退还给每一个被侵害的职工，靠人工翻台账几乎不可能。而且退钱只是第一步。更关键的是堵制度漏洞 —— 怎么保证代领过程透明？怎么让职工知道自己该拿多少？怎么防止同类问题再发生？这些，不是写一份整改报告就能解决的。 五、系统能帮上什么忙？把这条问题丢进铭太科技小铭铭审计整改助手，它给出的第一步不是写措施，而是"问题标准化"： ​部分省份劳务派遣公司利用农民工不熟悉政策签订不平等协议，盘剥克扣工伤保险待遇，涉及金额 1.82 亿元，损害职工合法权益，存在社保基金监管失控风险。定性一变，整改思路就变了 —— 不是 "退这一笔"，而是 "查所有笔、堵制度漏洞"。整改方案按分阶段整改铺开，全链条从排查、追缴、审核、监管到长效机制。最关键三条：  一是全面排查。对 16 个省份 100 余家劳务派遣公司的协议全覆盖审查，逐人核实待遇发放。二是依法追缴。确认被克扣的待遇限期全额返还，1.82 亿元应追尽追、应退尽退。三是源头治理。 劳务派遣协议工伤条款前置审核，待遇直发职工本人账户，砍掉中间环节。每一项动作背后，都配了佐证清单：排查底稿、追缴回单、职工签收记录、审核记录、培训签到、整改总结。措施写得再漂亮，佐证凑不齐，问题就销不了号。六、审计整改难在哪？说到底卡在三件事：责任界定不清、标准把握不准、成效难以量化。基层人手少、经验少，碰上跨年度、跨区域、涉及面广的问题，常常不知从哪下笔；写了一堆措施交上去被打回来，因为 "说不清"。铭太科技小铭铭审计整改助手，深耕审计监督数智化二十年，让审计整改从 "凭经验写" 变成 "有标准可查"。把散落在制度文件和典型案例里的经验，沉淀成可复用的骨架：输入问题，自动完成定性、生成分阶段整改方案、列出佐证材料清单。判断和责任还是人来扛，但 "怎么写、写什么、拿什么证明"，系统帮你理清楚。  你们单位遇到过类似的工伤保险待遇代领问题吗？整改方案写不实、佐证材料凑不齐？评论区聊聊。​

​近日，国家审计署一份报告，强农惠农富农资金被点名：抽查19省296县6680个产业融合发展项目，问题金额234.57亿元。更扎眼的是——749个项目没守住“土特产”三个字。赣州明明是“世界橙乡”，却被向18县摊派38.5万亩蔬菜大棚，种出来供不对需、普遍亏损。钱花出去了，这账怎么交？  一、先把“土特产”拆成三道题最常见的毛病，是把审计报告原文照抄进整改方案，抄完发现没法往下写。先尝试把问题情况发给铭太科技小铭铭智能审计整改助手，做的第一步不是写措施，而是“问题标准化”：把“摊派任务、产业空心”翻译成“未充分考虑当地水土自然禀赋、脱离优势特色、产业基础设施未配套即上马，存在财政资金损失浪费风险”。  这句话背后，是规则引擎加知识图谱在起作用——系统把“土特产”要求拆成可打勾的检查项：水土禀赋、优势特色、产能配套。AI按图索骥给每个问题贴标签，749个项目顺势分成三堆：不“土”124个、不“特”197个、不“产”428个。一句话的差别，决定整改是“就事论事改一件”，还是“举一反三改一片”。 二、整改不是写态度，是排工期  审计整改分三类：立行立改、分阶段整改、持续整改。这条牵扯解约清退、重建机制、追责，属典型“分阶段整改”。把小铭铭给出的指引压成一条主线，12个月就清楚了。 前3个月止血。成立专项工作组，对6680个项目全覆盖摸底，建立问题台账，精准锁定749个偏离项目；赣州就由农业农村局牵头，对18县大棚逐县核查。   中间6个月动手术。分类施策：不“土”的重论证选址，不“特”的重定位特色，不“产”的补齐基础设施；同步建立项科学论证机制，新建项目必须先交土壤检测、水资源论证、市场供需三份报告，专家评审通过才能上马；对234.57亿元问题金额逐笔绩效评估，能追的追、能调的调。最后3个月防复发。月度调度、季度通报、滞后约谈；逐县验收销号，把“土特产”匹配度写进干部考核防反弹。追责贯穿全程：直接、分管、领导责任一层层划清。三、最容易被退回的，是“改完了却说不清”整改材料被打回来，多半不是没改，而是说不清。铭太科技智能审计整改助手小铭铭在指引末尾给了一份“标准化整改卷宗”清单：排查底稿、分类处置方案、资金调整文件、验收资料、追责决定等11类材料一一对应。  改了哪些要有数字：调整项目X个、修订制度X项、追回资金X万元；凭什么说改了要有材料：调整批复、新旧制度对比、绩效评估报告、验收销号记录。措施写得再漂亮，佐证凑不齐，问题就销不了号。措施和材料对上，整改台账才算真正闭环。四、难的不是改，是没人教你怎么改说到底，基层卡在三件事：资源禀赋把握不准、产业论证标准不清、成效难量化。AI能帮上的恰恰是这层。  把问题丢进铭太科技智能审计整改助手，它先“识别意图”，再用RAG检索增强，从审计准则和典型案例库里召回相似问题，最后按一张“填表模板”（结构化schema）吐出五栏：标准化表述、类型判定、分阶段措施、成效指标、证明材料清单。等于给审计员配了个不会累的实习助手，把查制度、翻案例的活先干了。但判断和责任还是人来扛——模型给的是建议骨架，责任认定、实质把关得人工。这也是铭太科技·小铭铭智能审计整改助手在做的事。你们单位写惠农资金整改，最难的是措施写不实，还是材料凑不齐？评论区聊聊。​

​江西彭泽县，2019年把1.24亿元产业补助拨给九江一家生态农业公司，协议约定公司带动农户养小龙虾、负责包销。钱拨下去再没人跟踪——2024年公司“跑路”，农户的虾没人收，只能半价贱卖。  这不是孤例。审计署2025年度报告披露：19省296县抽查6680个乡村产业融合项目，问题金额234.57亿。其中2141个项目从一开始就不符合“联农带农”初衷（1631个完全没措施、325个措施写在纸上），白补了115.83亿；另有37县拖欠54.94万农民岗位补贴、伙食补助共16.8亿。  为什么总是“审计抽查才发现”？一个县几百个补贴项目，数据散在四个部门：申报在农业农村局、拨付在财政局、企业经营在税务电力社保、农户台账在乡镇。基层审计就几个人，靠翻纸质台账一年查几十个，日常监控基本缺位。  技术能补哪一环？从四层架构入手。第一层，数据治理。 四个源数据先做口径对齐——企业名称统一、项目编号映射、时间口径拉齐，这是后面一切分析的前提。  第二层，规则引擎跑批。 审计经验固化成规则按月自动跑：申报说带200户但社保本地用工为零；补贴发了半年企业用电开票纹丝不动；该直打农民社保卡的钱中间过了企业账户；验收报告说户均增收5000元但台账分红为零。第三层，模型补盲。 规则抓“明显不对”，模型抓“看着都对但反常”：同类项目平均补贴每户3000元、某项目突然报到2万；同一法人穿透后在5个县同时拿同类补贴。第四层，疑点工单闭环。 每条疑点自动生成核查工单派到属地，核查结论、佐证、整改回传直至销号。把“人找问题”变成“问题找人”——基层还是那几个人，监控范围从一年抽查几十个变成每月跑遍全县在补项目。回到智能审计方面，整改报告需要怎么写？我们试了铭太科技小铭铭智能审计整改助手。把彭泽这条问题丢进去，它第一步不是急着写措施，而是先做问题标准化：  彭泽县在产业补助资金拨付后未履行后续监管职责，导致项目单位未按协议带动农户养殖小龙虾并包销，2024年该公司停止经营，小龙虾无人收购，造成农户经济损失，存在财政资金使用效益低下和监管缺位风险。定性一定，思路就清楚了——不是“退一笔钱”，是“补一套机制”。  AI给出的措施里最关键四条：建全过程监管。 季度核查、年度评估、大额项目专人跟踪。建动态监控台账。 经营状况、协议履行、收购凭证逐月更新。存量拉网排查。 已跑路的追缴资金、协调替代收购主体、法律追责。绩效和后续拨款挂钩。 带动效果不达标的暂缓或取消下年补助。每条措施后面都配了佐证清单——管理办法原文、台账更新记录、追缴回单、替代收购协议、农户签收记录。措施写得再漂亮，佐证凑不齐就销不了号。  查出问题是“上半篇文章”，改到位才是“下半篇”。铭太科技深耕审计监督数智化二十年，旗下小铭铭审计整改助手，把项目台账、补贴流水、联农记录串在一条线上，让审计整改从“翻台账”变成“对数据”。你们那边见过“补贴发了但项目没影”的事吗？评论区一起聊聊。​

基于云审计服务实现资源操作日志关联分析概述本案例帮助入门开发者快速掌握如何使用华为云 CTS（云审计服务） 和 LTS（云日志服务），实现云资源操作日志的采集、存储和查询分析。解决的问题安全审计：追踪谁在什么时间对什么资源做了什么操作问题排查：快速定位资源变更导致的问题合规检查：验证操作是否符合规范应用场景| 场景 | 说明 ||------|------|| 安全审计 | 追踪敏感操作（删除、权限变更） || 问题排查 | 定位资源异常变更时间点 || 合规检查 | 验证操作是否符合审批流程 |架构图graph LR A[云资源操作] --> B[CTS 云审计服务] B --> C[LTS 云日志服务] C --> D[LTS SQL 分析] D --> E[Dashboard 可视化] style A fill:#e1f5fe style B fill:#fff3e0 style C fill:#f3e5f5 style D fill:#e8f5e9 style E fill:#fce4ec数据流说明：用户对云资源执行操作（创建、修改、删除）CTS 自动记录所有操作事件CTS 将日志投递到 LTS 进行存储使用 LTS SQL 进行查询分析Dashboard 可视化展示操作趋势前置条件1. 华为云账号已注册华为云账号并完成实名认证账号下有至少一个 ECS 实例或 VPC 等云资源2. CLI 工具安装华为云 CLI（hcloud）：# 方式一：pip 安装pip install hcloud# 方式二：下载安装包# https://support.huaweicloud.com/productdesc-hcli/hcli_01_0001.html配置 CLI 认证：hcloud configure set --cli-mode=AKSK \ --cli-access-key=YOUR_AK \ --cli-secret-key=YOUR_SK \ --cli-region=cn-north-43. 权限要求需要以下权限（或拥有 `Tenant Administrator` 角色）：`CTS Administrator`：管理云审计服务`LTS Administrator`：管理云日志服务`ECS Administrator`：用于模拟操作产生日志操作步骤步骤 1：开通 CTS 云审计服务CTS 默认会创建一个系统 tracker，记录所有云服务操作。# 查询已存在的 trackerhcloud CTS ListTrackers# 如果需要指定项目 IDhcloud CTS ListTrackers --project_id=$PROJECT_ID预期输出：{ "trackers": [ { "tracker_name": "system", "tracker_type": "system", "status": "enabled" } ]}如果没有 tracker，创建一个：hcloud CTS CreateTracker \ --tracker_name=system \ --tracker_type=system步骤 2：创建 LTS 日志组和日志流创建用于存储 CTS 操作日志的日志组和日志流。# 创建日志组（ttl_in_days 为日志保留天数，范围 1-365）hcloud LTS CreateLogGroup \ --log_group_name=cts-audit-logs \ --ttl_in_days=30# 记录返回的 log_group_id# 示例输出：{"log_group_id": "xxxx-xxxx-xxxx"}# 创建日志流hcloud LTS CreateLogStream \ --log_group_id=YOUR_LOG_GROUP_ID \ --log_stream_name=cts-events预期输出：{ "log_group_id": "xxxx-xxxx-xxxx", "log_stream_id": "yyyy-yyyy-yyyy"}> 提示：也可以跳过此步骤，直接在步骤 3 中启用 CTS 的 LTS 投递功能，CTS 会自动创建日志组和日志流。步骤 3：配置 CTS 日志投递到 LTS启用 CTS 的 LTS 投递功能，将操作日志投递到 LTS 进行分析。# 启用 LTS 投递（CTS 会自动创建日志组和日志流）hcloud CTS UpdateTracker \ --tracker_name=system \ --tracker_type=system \ --is_lts_enabled=true验证配置：hcloud CTS ListTrackers确认输出中 `is_lts_enabled` 为 `true`，并记录自动创建的 `lts_log_group_id` 和 `lts_log_stream_id`。> 说明：启用 LTS 投递后，CTS 会自动创建名为 `CTS` 的日志组和日志流，无需手动创建。步骤 4：模拟资源操作产生日志执行一些云资源操作，产生审计日志。# 示例：查询 ECS 列表（产生查询操作日志）hcloud ECS ListServersDetails# 示例：创建一个测试安全组（产生创建操作日志）hcloud VPC CreateSecurityGroup \ --project_id=YOUR_PROJECT_ID \ --security_group.name=test-sg-audit等待日志生成：CTS 日志通常在 5-10 分钟内投递到 LTS。步骤 5：使用 LTS SQL 查询分析使用 LTS SQL 查询操作日志。#### 5.1 查询最近 1 小时的所有操作SELECT * FROM log WHERE __time__ > now() - 1hORDER BY __time__ DESCLIMIT 100#### 5.2 查询指定资源的操作历史SELECT time, user.name as operator, operation, resource_type, resource_nameFROM logWHERE resource_id = 'YOUR_RESOURCE_ID'ORDER BY time DESC#### 5.3 按操作类型统计SELECT operation, COUNT(*) as countFROM logWHERE __time__ > now() - 24hGROUP BY operationORDER BY count DESC#### 5.4 按操作者统计SELECT user.name as operator, COUNT(*) as operation_countFROM logWHERE __time__ > now() - 24hGROUP BY user.nameORDER BY operation_count DESC步骤 6：创建 Dashboard 可视化在 LTS 控制台创建 Dashboard 展示操作数据。# 创建 Dashboard（需要通过控制台或 API）# 建议图表：# 1. 操作趋势折线图（按时间）# 2. 操作类型饼图# 3. 操作者柱状图# 4. 敏感操作列表（删除、权限变更）Dashboard 配置示例：| 图表名称 | 类型 | SQL 查询 ||----------|------|----------|| 操作趋势 | 折线图 | 按时间统计操作数量 || 操作类型分布 | 饼图 | 按操作类型统计 || Top 操作者 | 柱状图 | 按操作者统计 || 敏感操作 | 表格 | 过滤 delete/update 类型 |预期结果查询结果示例+---------------------+----------+------------------+---------------+----------------+| time | operator | operation | resource_type | resource_name |+---------------------+----------+------------------+---------------+----------------+| 2026-04-28 09:30:00 | user1 | createServer | ecs | test-server || 2026-04-28 09:25:00 | user2 | deleteSecurityGroup | vpc | old-sg || 2026-04-28 09:20:00 | user1 | updateServer | ecs | prod-server |+---------------------+----------+------------------+---------------+----------------+Dashboard 效果Dashboard 将展示：过去 24 小时的操作趋势操作类型分布（创建/修改/删除比例）最活跃的操作者敏感操作列表常见问题Q1: 为什么查询不到日志？可能原因：CTS 日志投递有 5-10 分钟延迟LTS 日志组/流配置错误查询时间范围不正确解决方案：等待 10 分钟后重试检查 tracker 配置中的 LTS 参数扩大查询时间范围Q2: 如何查询敏感操作？SELECT * FROM logWHERE operation LIKE '%delete%' OR operation LIKE '%update%'ORDER BY __time__ DESCLIMIT 50Q3: 日志保留多久？LTS 默认保留 7 天可在 LTS 控制台修改保留时间（最长 365 天）参考链接[CTS 云审计服务文档](https://support.huaweicloud.com/productdesc-cts/cts_01_0001.html)[LTS 云日志服务文档](https://support.huaweicloud.com/productdesc-lts/lts_01_0001.html)[LTS SQL 查询语法](https://support.huaweicloud.com/usermanual-lts/lts_07_001.html)[华为云 CLI 文档](https://support.huaweicloud.com/productdesc-hcli/hcli_01_0001.html)

python复制编辑from flask import Flask, jsonifyimport cv2import osapp = Flask(__name__)# 加载人脸识别器face_cascade = cv2.CascadeClassifier('/ai_face/data/haarcascade_frontalface_default.xml')# 视频路径video_path = '/ai_face/data/material_video.mp4'@app.route('/detect_face', methods=['GET'])def detect_face():    face_data = {}    cap = cv2.VideoCapture(video_path)    frame_id = 0    while cap.isOpened():        ret, frame = cap.read()        if not ret:            break        gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)        faces = face_cascade.detectMultiScale(gray, 1.3, 5)        coords = []        for (x, y, w, h) in faces:            coords.append({'x': int(x), 'y': int(y), 'w': int(w), 'h': int(h)})        if coords:            face_data[f'frame_{frame_id}'] = coords        frame_id += 1    cap.release()    return jsonify(face_data)if __name__ == '__main__':    app.run(host='0.0.0.0', port=7047)```------##在 `apps` 目录下运行：``bash复制编辑python3 face_recognition.py```------##在浏览器或 curl 中访问：```bash复制编辑curl http://<服务器IP>:7047/detect_face``返回值示例：``json复制编辑{  "frame_3": [    {"x": 120, "y": 80, "w": 60, "h": 60}  ],  "frame_15": [    {"x": 200, "y": 110, "w": 55, "h": 55}  ]}``` 

转载自【捉虫计划】第1期 邀你来一场云上体验捉虫行动，回帖反馈赢开发者定制礼品-云社区-华为云 (huaweicloud.com)

 一、引言  参与“云技术精髓入门级开发者认证课程”是一次收获颇丰且极具意义的学习之旅。本文旨在分享我在该课程学习中的心得感悟以及实验操作经验，并且结合实际案例给出个人的分析见解。此课程不但包含云计算的基本概念与服务模型，还深入钻研了主流云服务提供商（AWS、Azure和GCP）的核心服务和功能。经由实际操作与案例剖析，我对云计算的理解更为透彻，自身技能也有了显著的提升。  二、云技术基础概念  2.1云计算定义  云计算是一种借助互联网提供可动态伸缩的虚拟化资源的技术。它让用户能够按需获取计算能力、存储空间和应用程序，无需购置与维护物理硬件设备。这种模式赋予云计算弹性、自助服务、多租户、按需付费和广泛网络访问等特性，进而使云计算成为现代IT基础设施的重要构成部分。  2.2服务模型（IaaS, PaaS, SaaS）  云计算服务大体可分为三种主要模型：基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）。  IaaS：提供基础设施层面的服务，例如虚拟机、存储和网络等。像AWS的EC2和Azure的虚拟机就是典型代表。 PaaS：为开发者提供一个平台，使其能够在平台上构建、部署和管理应用程序，而无需操心底层基础设施。例如Google App Engine和Microsoft Azure的App Service。 SaaS：直接为用户提供应用程序，用户可通过浏览器访问这些应用，无需安装或者维护任何软件。例如Google Workspace和Microsoft Office 365。 2.3主要云服务提供商介绍  2.3.1 AWS  亚马逊网络服务（Amazon Web Services, AWS）是全球顶尖的云服务提供商之一，其提供涵盖计算、存储、数据库、分析和机器学习等多方面的广泛云计算服务。其核心服务包含EC2（Elastic Compute Cloud）、S3（Simple Storage Service）和RDS（Relational Database Service）等。例如，EC2能够支持可扩展的计算资源，提供多种操作系统和编程语言供用户选择。  2.3.2 Microsoft Azure  微软Azure是一个全方位的云服务平台，从基础设施层到应用层提供各式各样的服务。其核心服务有Azure Virtual Machines、Azure Blob Storage和Azure SQL Database等。举例来说，Azure Virtual Machines提供灵活的计算能力，支持多种虚拟机大小和配置选项。  2.3.3 Google Cloud Platform (GCP)  谷歌云平台（Google Cloud Platform, GCP）提供高性能的计算、存储和数据分析服务。其核心服务包括Compute Engine、Cloud Storage和Cloud SQL等。例如，Compute Engine提供可扩展的计算资源，可用于高性能计算和大规模数据处理。  三、核心服务与功能  3.1计算服务  计算服务使用户能够在云端运行应用程序和工作负载。AWS的EC2、Azure的Virtual Machines和GCP的Compute Engine都属于典型的计算服务。它们均提供可扩展的计算资源，并且支持多种操作系统和编程语言。例如，AWS的EC2能够支持可扩展的计算资源，还提供多种操作系统和编程语言供用户选用。  3.2存储服务  存储服务为数据提供持久化的存储解决方案。AWS的S3、Azure的Blob Storage和GCP的Cloud Storage都是对象存储服务，适用于大规模数据的存储与检索。它们具备高可用性和持久性，从而确保数据的安全可靠。  3.3数据库服务  数据库服务提供托管的数据库解决方案，简化了数据库的部署、管理和运维工作。AWS的RDS、Azure的SQL Database和GCP都是关系型数据库服务。此外，还有像AWS的DynamoDB这样的NoSQL数据库服务以及支持MySQL的Cloud Firestore。  3.4网络服务  网络服务用于配置和管理虚拟网络环境。AWS的VPC（Virtual Private Cloud）、Azure的Virtual Network和GCP的VPC网络都允许用户创建隔离的网络环境，对子网、路由表和防火墙规则进行配置。这些服务保障了网络的安全性和可靠性。  四、实验操作心得  4.1实验环境搭建  在开始实验前，我由于AWS提供丰富的免费层资源，比较适合初学者练习，所以选择了AWS作为实验平台。通过AWS Management Console，我创建了一个免费账户，并设定了必要的安全凭证。随后，我对AWS的基本操作界面，如仪表板、服务列表和服务组资源等进行了熟悉。  4.2虚拟机部署与管理  在AWS中，EC2（Elastic Compute Cloud）是部署和管理虚拟机的核心服务。借助EC2控制台，我学会了创建新的EC2实例的方法。首先，我挑选合适的AMI（Amazon Machine Image），接着配置实例类型、网络设置和存储选项。在启动实例之后，我运用SSH连接到实例，并安装了诸如htop之类的基本监控工具，以便实时监控系统性能。此外，我还掌握了如何使用EC2的自动缩放功能，根据负载动态调整实例数量。  4.3存储桶实践操作  S3（Simple Storage Service）是AWS提供的海量存储服务，适用于非结构化数据存储。在实验过程中，我学会了创建存储桶并配置权限以控制访问。通过AWS CLI工具（Command Line Interface），我练习了上传、下载和删除文件等基本操作。例如，使用“aws s3 cp”命令将本地文件复制到S3桶中，并用“ls”命令列出桶中的文件。另外，我还对S3的版本控制功能进行了探索，它能够跟踪文件的变化，并且在需要的时候恢复到之前的版本。  4.4 API调用示例  API是与云服务交互的重要方式。在实验期间，我学会了运用AWS提供的SDK来实现基本操作。例如，借助Python的boto3库，我编写了一个简单的脚本，实现了启动和停止EC2实例的功能，并且获取了实例的状态信息。此外，我还尝试了通过RESTful API直接与AWS服务进行通信，借助HTTP请求执行诸如创建新的S3桶和上传文件等各种操作。这些实践让我对云服务的工作原理有了更深入的理解，同时提升了我的编程能力。  五、学习方法与技巧  5.1主动学习与实践相结合  在学习过程中，我采用主动学习与实践相融合的方式。除观看视频教程之外，我还积极投身于在线实验室和实操项目，通过实际操作加深对理论知识的理解。每当学到一个新的概念或者技术时，我都会马上在实验环境中进行验证，确保自己真正掌握了这些知识。这种边学边做的方法不但提高了我的动手能力，还增强了我的自信心。同时，我还利用模拟器和沙箱环境进行测试，避免在实际项目中出现错误。  5.2参与社区讨论  加入相关的技术社区是提升技术水平的有效途径。我踊跃参与了多个云计算社区，如Stack Overflow、Reddit的r/aws板块以及GitHub上的开源项目。在这些社区里，我可以和其他开发者交流问题、解答疑惑，还能阅读他人的帖子和评论来获取更多的技术见解。此外，我还关注了一些知名的技术博主和专家，定期阅读他们的博客和技术文章，从而获取最新的行业动态和前沿技术。这些互动不但拓宽了我的视野，还帮我构建了一个互助性的学习网络。  5.3构建个人项目  为了更扎实地巩固所学知识，我构建了一个个人项目——基于云服务的在线文件共享平台。这个项目旨在利用云计算的强大功能，为用户提供便捷、安全的文件存储与共享服务。  我依旧选择AWS作为部署平台，综合运用了多个AWS服务来构建这个项目。在前端方面，我使用了S3来存储静态网页资源，确保用户界面的快速加载和稳定展示。对于后端，我借助了Lambda函数来处理业务逻辑，例如用户的注册、登录验证以及文件的权限管理等操作。在数据库管理上，RDS提供了可靠的关系型数据库支持，用于存储用户信息、文件元数据等关键数据。  在项目开发过程中，遇到了一系列的挑战。比如在确保文件安全传输方面，需要对AWS的安全组规则进行精细的配置，以防止数据在传输过程中被窃取或篡改。同时，为了提高文件的检索效率，在数据库查询性能优化上花费了不少精力，涉及到对SQL语句的优化以及索引的合理设置。另外，在处理多用户同时访问和操作文件时的并发处理问题也颇具挑战性。  通过深入查阅AWS的官方文档、积极在技术社区搜索解决方案以及热心的社区成员的帮助，我成功地将这个在线文件共享平台部署上线，并通过CI/CD流水线实现了持续集成和交付。这个项目让我将云计算相关的理论知识充分地应用到实践当中，极大地锻炼了我的问题解决能力和项目管理能力。  六、补充内容  6.1更多云服务提供商对比  除了AWS、Azure和GCP之外，还有阿里云等云服务提供商。阿里云在国内市场占据重要地位，其提供的弹性计算服务（ECS）类似于AWS的EC2，具有高性价比、本地化服务等优势。在存储服务方面，阿里云的对象存储OSS也有自己的特色，例如和国内的内容分发网络（CDN）结合紧密，能提供更快的内容传输速度。对比不同云服务提供商的价格策略也是一个重要方面，不同的计费模式（如按使用量计费、包年包月等）和优惠活动会影响企业和开发者的选择。  6.2安全性补充  在云计算中，安全性是至关重要的。除了网络服务中提到的虚拟网络安全（如VPC的安全配置），云服务提供商还提供多种安全措施。例如，数据加密方面，AWS提供了多种加密方式，如服务器端加密（SSE），可在S3存储服务中保护数据的机密性。Azure也有类似的加密服务，并且在身份认证和访问管理方面，采用了多因素认证（MFA）等手段，防止非法访问。同时，云服务提供商还需要遵循各种安全标准，如ISO 27001等，以确保服务的安全性。  6.3新兴技术与云计算的融合  随着人工智能和大数据技术的发展，云计算与之的融合越来越紧密。在AWS中，提供了多种机器学习服务，如SageMaker，它可以让开发者更方便地构建、训练和部署机器学习模型。Azure也有类似的机器学习服务。对于大数据处理，云服务提供商提供了如Hadoop和Spark的托管服务，例如AWS的EMR（Elastic MapReduce）。这种融合使得企业可以更高效地处理海量数据并从中挖掘价值。  6.4未来发展趋势展望  云计算的未来发展趋势包括边缘计算与云计算的融合。边缘计算可以在靠近数据源或用户的地方进行数据处理，减少数据传输延迟。云服务提供商可能会推出更多的边缘计算服务，与现有的云服务无缝对接。另外，无服务器计算（Serverless）也是一个重要趋势，如AWS的Lambda服务，开发者只需关注代码逻辑，无需管理服务器，这种模式将进一步简化应用开发和部署流程，提高开发效率。量子计算与云计算的结合也可能是未来的一个发展方向，虽然目前还处于探索阶段，但一旦实现，将为科学计算、密码学等领域带来巨大变革。  七、总结与展望  通过参与“云技术精髓入门级开发者认证课程”，我不仅掌握了云计算的基本概念和服务模型，而且通过实际操作深化了对这些知识的理解。实验操作使我能更加熟练地运用各种云服务，并积累了宝贵的实践经验。我还学会了有效的学习和解决问题的方法。希望这篇笔记能够对其他学员有所助益，让大家在云计算的学习之路上少走弯路，更迅速地掌握这一前沿技术。 

公有云计算架构的特点(1) 超大规模。 “云”具有相当的规模，一般拥有数百上千台服务器，能给用户前所未有的计算能力。(2)虚拟化。云计算支持用户在任意位置、使用各种终端获取应用服务。(3) 高可靠性。“云”使用了数据多副本容错、计算节点同构可互换等措施来保障服务的高可靠性，使用云计算比使用本地计算机可靠。(4) 通用性。云计算不针对特定的应用，同一个“云”可以同时支撑不同的应用运行。(5) 高可扩展性。“云”的规模可以动态伸缩，满足应用和用户规模增长的需要。(6)按需服务。“云”是一个庞大的资源池，你按需购买；云可以象自来水，电，煤气那样计费。(7)极其廉价。由于“云”的特殊容错措施可以采用极其廉价的节点来构成云，“云”的自动化集中式管理使大量企业无需负担日益高昂的数据中心管理成本，“云”的通用性使资源的利用率较之传统系统大幅提升，因此用户可以充分享受“云”的低成本优势，经常只要花费几百美元、几天时间就能完成以前需要数万美元、数月时间才能完成的任务。优势：1.分区域、跨区域部署，多Region结构，可靠性得到提升2.底层基于Openstack模块化设计，功能丰富Openstack优势：（1）控制性完全开源的平台，提供API接口，方便与第三方技术集成（2）兼容性OpenStack兼容其他公有云，方便用户进行数据迁移（3）可扩展性模块化设计，可以通过横向扩展，增加节点、添加资源（4）灵活性根据自己的需要建立相应基础设施、增加集群规模（5）行业标准众多IT领军企业已经加入到OpenStack项目

Cuttlefish：运行稳定版 CTS本页介绍了如何运行兼容性测试套件 (CTS)，以便根据 AOSP 源代码评估虚拟设备。构建 Cuttlefish在运行 CTS 之前，请先构建要使用 CTS 测试的虚拟设备。对于 AOSP Cuttlefish，请执行以下操作：$source build/envsetup.sh $lunch aosp_cf_x86_64_phone-userdebug $make -j构建 CTSCTS 是独立于设备工件构建的。如需构建 CTS，请按照以下说明操作。从构建 Cuttlefish 所在树的根目录中，运行以下命令：$source build/envsetup.sh $m -j cts WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY=false TARGET_PRODUCT=aosp_x86_64启动多租户 Cuttlefish 实例注意：如需详细了解如何启动多台 Cuttlefish 设备，请参阅 Cuttlefish 多租户与 powerwashing。从构建 Cuttlefish 所在树的根目录中，运行以下命令：$source build/envsetup.sh $lunch aosp_cf_x86_64_phone-userdebug $launch_cvd --num_instances=8 --daemon启动实例时，请验证每台设备是否都可以访问 adb。$adb devices输出应类似于以下示例输出：List of devices attached 127.0.0.1:6520 device 127.0.0.1:6521 device 127.0.0.1:6522 device 127.0.0.1:6523 device 127.0.0.1:6524 device 127.0.0.1:6525 device 127.0.0.1:6526 device 127.0.0.1:6527 device在 Cuttlefish 实例中启用 Wi-Fi如果未启用 Wi-Fi，部分 CTS 测试会失败。如需在本地托管的所有 Cuttlefish 设备上启用 Wi-Fi，请按照以下说明操作。从构建 Cuttlefish 所在树的根目录中，运行以下命令：$for SERIAL in adb devices | grep -E '127.+device$ | cut -f1'; do $adb -s ${SERIAL} install -r -g tools/tradefederation/core/res/apks/wifiutil/WifiUtil.apk $adb -s ${SERIAL} shell su root svc wifi enable $adb -s ${SERIAL} shell am instrument -e method "connectToNetwork" -e scan_ssid "false" -e ssid "VirtWifi" -w com.android.tradefed.utils.wifi/.WifiUtil $done运行 CTS 稳定版子集并非在 Cuttlefish 上进行的所有 CTS 都会通过，因为某些测试更多是针对实体设备量身定制的。如需使用 cts-virtual-device-stable 测试计划（用于跟踪在虚拟平台上运行稳定的最新功能）运行 CTS，请按照以下说明操作。从构建 Cuttlefish 所在树的根目录中，运行以下命令：$source build/envsetup.sh $lunch aosp_cf_x86_64_phone-userdebug $cts-tradefed run cts-virtual-device-stable --no-enable-parameterized-modules --max-testcase-run-count 2 --retry-strategy RETRY_ANY_FAILURE --reboot-at-last-retry --shard-count 8预计运行该测试需要 20 到 25 分钟时间，并显示类似如下的总结：=============== Summary =============== Total Run time: 22m 8s 184/184 modules completed Total Tests : 92483 PASSED : 92363 FAILED : 0 IGNORED : 71 ASSUMPTION_FAILURE: 49 Shard 0 used: [127.0.0.1:6522] Shard 1 used: [127.0.0.1:6525] Shard 2 used: [127.0.0.1:6524] Shard 3 used: [127.0.0.1:6521] Shard 4 used: [127.0.0.1:6520] Shard 5 used: [127.0.0.1:6527] Shard 6 used: [127.0.0.1:6526] Shard 7 used: [127.0.0.1:6523] ============== End of Results ==============清理测试完成后，请停止虚拟设备。从构建 Cuttlefish 所在树的根目录中，运行以下命令：$source build/envsetup.sh $lunch aosp_cf_x86_64_phone-userdebug $stop_cvd声明：        本文转自：https://source.android.google.cn/setup/create/cuttlefish-cts，仅供学习与交流，非商业用途，版权归原作者所有，如有侵权，请联系删除。

在使用转置卷积时观察到一个棘手的现象（尤其是深色部分常出现）就是"棋盘格子状伪影"，被命名为棋盘效应（Checkboard artifacts）。下图直观地展示了棋盘效应（来源：https://distill.pub/2016/deconv-checkerboard/）本文仅做简要介绍，详细部分请参考论文:Deconvolution and Checkerboard Artifacts（https://distill.pub/2016/deconv-checkerboard）棋盘效应是由于转置卷积的“不均匀重叠”（Uneven overlap）的结果。使图像中某个部位的颜色比其他部位更深。尤其是当卷积核（Kernel）的大小不能被步长（Stride）整除时，反卷积就会不均匀重叠。虽然原则上网络可以通过训练调整权重来避免这种情况，但在实践中神经网络很难完全避免这种不均匀重叠。下面通过一个详细的例子，更为直观展示棋盘效应。下图的顶部部分是输入层，底部部分为转置卷积输出结果。结果转置卷积操作，小尺寸的输入映射到较大尺寸的输出（体现在长和宽维度）。在（a）中，步长为1，卷积核为2*2。如红色部分所展示，输入第一个像素映射到输出上第一个和第二个像素。而正如绿色部分，输入的第二个像素映射到输出上的第二个和第三个像素。则输出上的第二个像素从输入上的第一个和第二个像素接收信息。总而言之，输出中间部分的像素从输入中接收的信息存在重叠区域。在示例（b）中的卷积核大小增加到3时，输出所接收到的大多数信息的中心部分将收缩。但这并不是最大的问题，因为重叠仍然是均匀的。如果将步幅改为2，在卷积核大小为2的示例中，输出上的所有像素从输入中接收相同数量的信息。由下图（a）可见，此时描以转置卷积的重叠。若将卷积核大小改为4（下图（b）），则均匀重叠区域将收缩，与此同时因为重叠是均匀的，故仍然为有效输出。但如果将卷积核大小改为3，步长为2（下图（c）），以及将卷积核大小改为5，步长为2（下图（d）），问题就出现了，对于这两种情况输出上的每个像素接收的信息量与相邻像素不同。在输出上找不到连续且均匀重叠区域。在二维情况下棋盘效应更为严重，下图直观地展示了在二维空间内的棋盘效应。

ListProductsV3消失了，调用其它api试试，有惊喜

ListProductsV3 api 不见了 但是任务还在,有人知道咋回事吗