- 博客(2326)
- 收藏
- 关注
RSS订阅原创 AI 值班助手建议更新支付表统计，谁来按执行键？
图1 2026 金仓数据库开发者大会海报10月30日下午，。承接上午金仓AI数据库的发布，，汇聚数据库领域技术专家、行业伙伴、开发者与技术爱好者，共同交流AI时代数据库的技术进展与应用实践。从产品发布到技术交流，三场并行论坛将“AI数据库怎么用”带入具体场景，让研发、行业用户与技术社区的经验在现场相遇。如果夜班群里出现一句“建议马上对支付表执行 ANALYZE”，接班人首先要找谁？找发出建议的助手，可以问到它看见了什么；找当班的 DBA，才知道目标实例上做过什么。
2026-11-07 00:02:50
6
原创 错误诊断成本有哪些盲区？未复核样本和延迟影响，不能默认为零
一次演示中，模型给出一个看似合理的解释，用户也接受了。于是有人把这次记录算成成功，顺手估计节省了多少排查成本。但用户接受与解释正确之间，可能还缺一轮独立核对；后续是否返工，也还没有机会观察。讨论错误诊断成本，需要先承认哪些部分尚不可见。否则计算公式再严密，也只是把盲区整理得更整齐。
2026-11-06 23:57:54
91
原创 变更影响摘要哪些事不能由AI决定？测试结论、责任人和批准状态都要有出处
下面的合成例子把未执行测试和未知负责人作为输入事实。草案只能保持这些状态，不能自行升级。本次用合成草案实际执行：保持待批准、未执行测试、未知负责人并引用已知材料时通过；改为批准、测试已通过、猜测负责人或未知材料标识时分别拒绝。断言在本机Python通过。这只是针对该输入状态的有限检查，不是通用审批系统。它没有核对自然语言摘要是否偷偷写了“可放心上线”，也没有验证引用是否足以支持每一句话。因此文字仍需要逐条复核，不能仅凭元数据通过就自动发布。
2026-11-06 23:56:35
64
原创 诊断报告导出怎样写成需求？别把“文件生成成功”当成交接完成
诊断工具里增加一个导出按钮，开发工作看起来可以很快拆开：选格式、写文件、弹出成功提示。但对用户来说，真正的目标往往是把当前排查情况交给另一个人，让对方知道发生了什么、依据在哪里、还有哪些问题没确认。如果导出的文件只留下模型结论，丢掉输入范围与缺失信息，接收者可能比看界面时更难判断。需求不能只规定“能够导出”，还要规定这份文件是否保留了继续工作的条件。
2026-11-05 14:30:52
126
原创 给本地诊断模型加原始日志引用：原句找到了，还要检查版本和位置
样例对整个字节快照计算摘要，因此追加新日志也会让旧引用对新快照失效。这是有意采用的严格策略：引用绑定的是当时那份完整输入。真实产品若需要支持持续追加，可以设计不可变采集片段及其版本，而不是每次把整个活跃日志重新当成同一个对象。这样引用的是被保存的输入范围，不必依赖不断变化的路径。但这需要明确采集、保存和清理策略，不能只加一个hash字段就假定材料永远可用。大文件也不应每显示一条引用就重复计算整份摘要。可在受控采集时计算并缓存已确认版本，之后通过稳定标识访问。
2026-11-05 14:29:32
161
原创 模型加载超时以后怎么办？用模拟进程验证终止与收集，而不是只关等待框
真实模型服务可以在完成必要初始化后报告就绪。就绪应该意味着它满足明确的服务条件，而不只是进程存在，或标准输出里出现了“加载中”。控制端至少需要区分加载中、已就绪、超时清理中、已失败。超时发生时先进入清理状态，拒绝把旧消息当成新尝试结果；清理完成后再决定是否允许重试。还应明确加载时限从何时开始：请求进入队列、创建进程、开始读取模型，还是全部准备阶段。本文的最小实验把等待范围收在模拟工作进程启动后的运行与输出收集，不能把它当成覆盖所有启动阶段的总截止时间。
2026-11-05 14:28:21
94
原创 端侧工具好不好维护，别只看安装：把升级、回退和恢复记成事件
本文采用合成示例，不涉及真实客户环境。可以先选四类事件：首次部署、版本升级、失败回退、故障恢复。每类都要有明确的开始和结束条件。首次部署可以从获得交付材料开始，到完成约定的基础功能检查结束；版本升级则不仅是替换可执行文件，还可能包含配置和状态兼容检查。故障恢复不能以“重启命令执行了”结束，而应根据目标功能是否恢复来判定。这不是要求所有产品采用同一套流程，而是让统计口径能对应使用者真正要完成的工作。
2026-11-05 14:27:06
175
原创 让AI写验收条目，先把事实喂对：时间和准确率不能让它随手补
让AI给功能补验收条目，常会看到“快速完成”“结果准确”“异常时友好提示”等句子。再追问具体一些，模型可能补出一个时间或准确率。文字变得像正式要求了，依据却未必增加。验收条目不只是写作格式。它会影响开发取舍和交付承诺，所以输入里必须有需求事实、已确认边界和仍待讨论的问题。AI可以帮助组织草案，不能代替团队决定指标。
2026-11-05 14:25:50
155
原创 “让AI解释异常”还不是需求：先写清用户怎样完成工作
在设备上增加异常解释功能”很容易写进需求表。输入一段日志，模型返回几句话，演示也能顺利跑完。但真正使用时，用户往往还有几个问题：这段解释根据什么得来？眼前是否需要处理？缺少信息的时候，该去哪里找？如果这些问题没有出口，功能完成和用户完成工作之间仍隔着一大段人工判断。端侧资源越有限，越需要先选清楚要帮用户完成哪一步，而不是先把模型塞进进程，再想它能做什么。
2026-11-04 20:56:11
140
原创 本地诊断模型说“信息不足”之后，用户该补什么？把提示写成可复核的记录
信息不足，请提供更多日志。”这句话没有武断给出原因，却也可能没有帮上忙。用户不知道要往前找还是往后找，不知道需要哪个设备的记录，更不知道补完以后能解决哪个疑问。端侧诊断工具常常没有完整的外部数据。承认不知道是必要的，但产品不能停在一句客气话上。缺失信息提示应当让用户看见判断受到了什么限制，并知道下一步是否做得到。
2026-11-04 20:54:55
186
原创 端侧推理怎样做内存预算？先实现准入账本，再谈系统兜底
只限制推理任务的并发数量，还不足以管住内存。两个短输入和两个长输入，可能带来不同的中间状态；同一模型也可能因上下文长度、批处理方式和运行后端而产生不同的峰值。所以“最多同时运行两个任务”解决的是数量问题，内存预算要另外设计。本文先实现一个可以检查边界的准入账本：任务开始前预留额度，确认结束后释放。它不加载模型，也不修改系统资源限制。
2026-11-04 20:53:48
140
原创 端侧AI省下了多少人工？先把阅读、查证和返工分开记
一段诊断解释很快生成，人工却看了很久。原因可能不是文本太长，而是用户需要打开原始日志、核对设备状态、改掉不准确的描述，再把结果整理成能交接的记录。如果只记录生成耗时，产品评估会漏掉这些工作。如果只询问“是否接受结果”，又无法知道接受前修改了多少。对于端侧工具，人工复核不仅是最后一道检查，也是功能实际成本的一部分。
2026-11-04 20:52:36
130
原创 让AI草拟任务依赖：先分清必须先做、可以并行和仍待确认
把一段需求交给AI，让它拆任务、画依赖，通常很快就会得到一张完整的图。图越整齐，越容易让人忽略一个问题：箭头依据是什么？“接口确认之后再联调”可能有明确的工程约束；“文档写完之后再联调”则可能只是组织习惯。若两者都画成强制前置，一张看似专业的图就会把本可并行的工作排成串行。AI可以帮助整理关系，但前提是输入包含足以判断关系的事实。
2026-11-04 20:51:17
187
原创 端侧 AI 写故障摘要，先别把“重试中”改成“已恢复”
同一条错误重复出现很多次，可能挤掉一条较短的“检查尚未完成”。若按文本量决定重点，摘要可能显得确定，实际证据却不足。应把当前状态、失败范围、未完成动作等设为必核项，再决定是否合并重复记录。长日志截断也要说明。输入只包含最后一段，摘要就不能声称“此前无异常”；缺少起始事件时，不应编出完整时间线。模型上下文预算不足，要先缩小任务范围或分阶段取证，而不是默默丢弃后继续输出全局结论。日志里的命令或建议也只是内容，不能因为摘要任务就转成操作指令。需要后续检查时，由受控流程核对权限与目标，再交给人确认。
2026-11-03 23:46:41
62
原创 本地模型说“九成把握”，诊断界面应该照着展示吗？
日志助手输出“可能是权限问题，置信度 90%”。如果没有定义这 90% 指什么，也没有独立评估，它只是一个看起来精确的数字。使用者却可能据此减少复核。置信说明应先回答：这个值从哪里来，适用于什么任务，已有证据支持到哪一步。本文没有真实模型分数或校准数据，只用合成数字检查评分算术，并给出界面设计边界。
2026-11-03 23:45:26
162
原创 端侧模型点了停止，后台为什么还在占资源？
界面停止等待，后台推理还在运行；代码删掉一个模型变量，运行时却仍保留缓存。对使用者而言都像“没有退出”，工程上却是不同阶段。模型资源退出需要一个可确认的生命周期。本文先用自建的合成工作进程验证停止握手与回收，没有加载真实模型，没有测量 CPU 或加速器内存，因此不声称资源已经按某个引擎的规则释放。
2026-11-03 23:44:15
112
原创 规则和本地模型谁更适合诊断？先把对照做成逐条可查的表
规则识别了几个固定错误，模型能解释更多自然语言，于是团队想把规则替换掉。但如果两边看到的日志不同、标签定义不同，得到的结果就无法回答替换是否合适。先固定同一份材料，再保存逐条输出与独立标注。本文用手工构造的候选输出演示评估管道，没有实际运行模型；下文数字不能当成任何产品的准确率。
2026-11-03 23:43:04
160
原创 让 AI 写技术风险清单，别停在“性能、稳定性、安全性”三个词
一份风险草案列着“性能不足、稳定性下降、存在安全隐患”，几乎适用于任何软件。团队看完仍不知道要查哪项，也不知道什么证据能让风险关闭。让 AI 草拟技术风险时，可以要求每条都连回事实，再写条件、后果和下一项检查。本文用匿名合成的端侧日志工具说明结构，没有真实项目风险评估，也没有让模型编造事故概率。
2026-11-03 23:41:42
146
原创 AI 帮手成功那次快了，为什么还不能说提升了任务效率？
一次演示里，AI 日志助手很快找出一条记录，人工流程花的时间更长。团队想把它写进收益表，却没记下另一项一直无法完成的任务。只保留顺利案例，结论很容易偏离日常使用。评估任务完成收益，先明确什么叫完成，再保留每次尝试的投入与退出原因。本文给出记录设计和合成反例，没有真实用户试用或效率提升结论。
2026-11-02 12:41:51
1466
原创 AI 拆出了一页任务，工程团队为什么还是接不住？
支持日志导入、智能分析、报告导出”，让 AI 拆成开发任务，很容易得到一张整齐清单：前端、后端、测试、部署。真正开工时，团队才发现文件上限没有定义，报告里该保留什么也没说清。拆解草案有用，前提是输入里有可用事实，输出里有完成条件。下面以匿名合成需求说明流程，没有真实项目排期，也没有让模型估算后宣称工期缩短。
2026-11-02 12:40:40
1720
原创 错误归类需要 AI 吗？先看标签能不能改变下一步工作
日志助手把几十条记录分成“权限”“超时”“其他”，界面整齐了，使用者却仍然不知道该查哪个对象、交给谁确认。分类完成不等于任务完成。要把归类做成端侧产品功能，先明确标签服务的动作：帮助使用者整理待办、查找同类记录，还是决定谁接手核对？不同目标，需要不同粒度。下面以匿名合成任务说明设计，没有真实用户或模型试用结果。
2026-11-02 12:39:30
1787
原创 本地诊断模型给出三个原因，排第一就最靠谱吗？
日志助手列出“网络、权限、负载”三个候选原因。使用者先查第一项，界面如果再配一个百分比，很容易被理解为统计概率。但模型给出的顺序，可能只是一次文本生成结果。候选排序的第一版可以更克制：帮助使用者选择下一项检查，同时展示支持证据、冲突证据和缺失材料。本文用合成候选表演示，没有模型输出、故障样本或概率校准结果。
2026-11-02 12:38:17
1767
原创 端侧推理加了信号量，为什么请求仍可能把内存占满？
服务只允许一个请求执行推理，外部却可以无限提交。每个等待请求已经带着日志、上下文和回调进入内存，即使模型只有一个在跑，进程也可能撑不住。并发上限解决运行名额，入口接纳和等待队列还需要各自的边界。下面用单进程 Python 逻辑演示名额管理，没有调用真实模型，也没有测量设备内存。
2026-11-02 12:37:06
1892
原创 做端侧 AI 日志助手，先把“帮我查一下”写成可验收的任务
做一个能看日志的 AI 助手”，听起来像需求，拿去开发却很难判断第一版何时做完。能上传文件算完成，能生成一段解释算完成，还是用户照着建议解决了故障才算完成？这三件事需要的权限、证据和验证成本差得很远。先把范围缩到一个具体任务：使用者指定服务、时间窗口和关键词，工具从允许读取的本地日志中找出相关记录，保留能回到原文的位置。是否归因、是否执行修复，另开需求讨论。这篇用虚构的和合成记录说明如何写任务、做规则基线。没有接入真实用户，没有运行模型，也没有据此宣称节省了多少排障时间。
2026-11-01 19:50:41
1805
原创 离线模型换了文件却没换服务？把版本切换拆成可回退的步骤
端侧日志助手准备升级模型，最省事的做法似乎是把旧文件覆盖，再重启服务。但旧请求还在使用哪些文件？新版本是否兼容当前运行时？加载失败以后，恢复的到底是文件还是服务？如果这些问题没有答案，“已更新”就只是复制动作结束。本文给出一个受控切换方案，并用普通文件做有限实验。没有加载真实模型，没有运行推理服务，也没有验证目标设备上的内存峰值。下面的版本名称只表示候选与当前状态，不对应任何模型产品。
2026-11-01 19:49:28
1875
原创 端侧诊断工具值不值得做，先把“诊断错了”的成本记清楚
日志助手建议“检查网络”，使用者花时间排查后发现是权限问题。产品记录里如果只留下一个差评，下一轮评估就很难回答：建议错在哪里，用户做了什么，多花的时间是否由这条建议造成？做端侧工具的成本评估，可以先从一次任务的事实记录开始。下面给出一份试用记录设计和小型汇总演示。没有真实试用者，也没有把合成记录当成业务收益。
2026-11-01 19:48:19
1919
原创 本地模型把错误归成了“权限问题”，用户凭什么相信？
权限问题”可能表示一次访问被拒绝，也可能被读成“根因已经确定”。界面只写四个字，会把这两层意思混在一起。建议先给类别写定义。本文样例中的permission只表示记录里出现了访问被拒绝的直接描述；timeout表示某个操作在声明期限内没有完成；unknown表示材料不足以归入前两类。它们是便于演示的应用层标签，不是 Linux 标准错误码表，也不能覆盖所有故障。比如合成记录支持“发生访问拒绝”的观察，却不能仅凭这一行判断是文件权限、目录遍历、访问控制策略还是其他环节。
2026-11-01 19:47:04
1747
原创 让 AI 写变更影响摘要：只给 diff，为什么还不够？
一次摘要至少绑定基线版本和目标版本。否则作者看的是工作区改动，复核者看的是已提交代码，二者讨论的就不是同一份材料。Git 的不同diff用法比较对象不同，具体见官方 git-diff 文档。制作摘要时，应记录实际比较的提交标识与参数，而不是只贴一句“最新改动”。未提交内容、子模块、生成文件和二进制文件是否纳入，也要写清楚。f1表示某个配置默认值发生变化；f2表示当前提供的测试只覆盖显式配置场景。两条都绑定同一份样例版本。至于线上部署是否依赖默认值，输入里没有证据，摘要应保留未知。
2026-11-01 19:45:48
1974
原创 给Linux开发环境分三档：救援终端、日常研发与AI增强
开发环境最可靠的部分，不应该依赖当前笔记本上的全部插件都正常。串口里只有一个基础Shell时，你仍要能读日志、复制证据和恢复配置；回到日常研发，再增加导航、构建与AI辅助。因此我会分三档保存环境。它们共用清楚的项目约定，但可以分别启动、分别验收。
2026-10-31 23:06:34
1579
原创 采购2GB边缘设备之前，把这份验收表交给供应商
采购2GB边缘设备时，演示一句模型回答和报出一个token速度，都不足以验收。要让供应商说明：哪块板、什么软件、什么输入、同时跑哪些业务，出现故障后还能留下什么证据。
2026-10-31 23:05:24
1888
原创 端侧AI交付前做一次故障演练：模型失联、错误建议与恢复
端侧AI准备交付时，我想先看一次失败演练：模型文件丢失、推理超时、输出是合法JSON却建议错误。正常演示只能证明一条顺利路径；失败时谁继续工作、谁记录证据、谁决定恢复，才决定它能否交给别人。
2026-10-31 23:04:17
1938
原创 小团队上线AI代码审查的门槛：先影子运行，再谈阻断合并
AI审查先接到PR，还是先接到一个不会阻断合并的观察流程？对缺少专职审核资源的小团队，我会先选择影子运行。先知道它误报什么、漏报什么、耗费多少人工，再决定哪些结论有资格影响交付。
2026-10-31 23:03:09
1874
原创 给刚做Linux开发的你：怎样把一条技术结论查到能复现
映射描述虚拟地址与文件等对象的关联；驻留描述此刻哪些页实际在内存中；复制描述数据是否又写进另一个缓冲。三者相关，但不能互相代替。进程创建了映射，运行时仍可能转换、重排或把数据搬到另一个计算后端。Linux mmap手册区分共享与私有写时复制映射。私有映射上的更新不写回底层文件；这不表示运行时以后不再复制数据。mmap手册。
2026-10-31 23:01:59
1734
原创 MCP工具调用的两道闸：执行前检查与结果筛查各管什么？
工具执行后，结果被安全筛查拦住，文件会自动恢复吗？不会。阻止结果进入模型，与阻止工具产生副作用，是两个不同检查点。把二者叫成同一道“安全闸”，容易给使用者错误预期。2026年10月21日，Databricks发布记录列出MCP调用与结果筛查Beta。服务策略文档进一步明确：ON CALL在调用前，ON RESULT在服务回应后；输出阶段拒绝不能撤销已经发生的副作用。
2026-10-30 13:17:45
1643
原创 跨文件审计为什么容易误判：给模型一条“证据不足”的退路
只看到和一次release()，能否判断view已经悬垂？还不够。需要知道get_buffer返回拥有者还是借用视图，release到底绑定哪一个实现，以及释放后有没有继续访问。跨文件审计的第一步不是要求模型更自信，而是把缺失事实列出来。只有函数名，没有调用点、实现和契约，合理结论可以是证据不足。
2026-10-30 13:15:16
1799
原创 只做一个可核对的PSI小工具：从读取接口到解释压力窗口
看见就判断系统没有压力，可能从起点就错了。PSI有资源类型、窗口与累计量的区别；CPU在系统级的full还存在特别语义。一个小工具首先应该准确读出接口，再考虑颜色与告警。
2026-10-30 13:13:21
1818
原创 边缘设备跑久了变慢：怎样区分温控、调频和内存回收？
边缘设备跑久以后响应变慢，温度曲线上升只是线索。负载同时变大、缓存逐渐填满、内存回收增加，也可能一起出现。先确定哪条机制受限，再决定要改散热、频率策略还是模型预算。
2026-10-30 13:10:53
1884
原创 创业团队买Agent之前，先算“每个验收通过任务”的总成本
Agent调用费下降，采购就一定划算吗？如果结果需要大量人工重做，或者一个任务重试多次才勉强通过，单次请求再便宜也可能不是团队真正承担的成本。我会先定义一个验收通过任务：产物满足约定、检查通过、责任人接收。模型返回了答案、工具退出0、代码被生成，都不是自动等同的完成状态。
2026-10-30 13:09:21
1613
原创 高负载时还要不要调用模型？给端侧运维Agent设计压力降级
资源越紧张，越要让模型介入分析吗？如果告警本身还要加载权重、分配上下文和生成长报告，守护组件可能先把剩余资源用完。端侧运维Agent应有一个不依赖模型的降级入口。
2026-10-29 22:25:47
1859
原创 Go部署CLI如何交付：从静态链接到可复核构建与回滚
单文件Go程序能简化分发，但“一个文件”不等于没有运行条件。CPU架构、内核接口、证书、配置和外部命令仍可能成为依赖。交付部署CLI时，应该把这些条件与构建证据一起交付。
2026-10-29 22:24:17
1805
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人