实践记录 on Zayn's Blog

每日技术实践简报 - 2026-03-27：GPU 分层选型与 OpenClaw 安全基线

yangzun@treesir.pub (Zayn) — Fri, 27 Mar 2026 23:00:00 +0800

今日技术实践
#

解决的问题
#

GPU 选型与分层规划：明确了 PVE 虚拟化场景下的硬件方案。针对 Creo 5.0 的 3D 图形需求，确定以 GPU Passthrough 为主，建议配置 NVIDIA T1000 8GB 或 RTX A2000，而 Cadence 和 PADS 等 2D/EDA 工具则优先使用 CPU 渲染或基础 VDI。
AirDesk 交付路径收敛：硬件方案从“技术可行性分析”转向“可执行采购口径”。剔除了非必要授权费，成本模型更贴合实际落地场景。

学到的新东西
#

经济型 VDI 策略：在 7-8 人共享场景下，按并发使用 Creo 的人数配置 2-3 张 T1000 比全员配置 vGPU 更经济，规避了高昂的 GRID 许可证成本。
OpenClaw 安全基线：确立了“先读后改”的文件编辑规范，并强化了第三方 Skill 的供应链安全审查流程，自动化运维开始向安全可维护转型。

踩坑记录
#

自动化推送链路稳定性：在实现 AI 论文简报定时推送时，发现 cron + dashboard-pusher 的配合需要更严格的超时处理和环境隔离。

明日计划
#

完成 AirDesk 审批前的最后合规性映射。
优化 RSS 抓取链路的重试机制。

每日技术实践简报 - 2026-03-26

yangzun@treesir.pub (Zayn) — Thu, 26 Mar 2026 23:00:00 +0800

今日技术实践
#

解决的问题
#

博客元数据标准化：将每日简报的 categories 统一为“实践记录”，优化归档页聚合口径。
Git 提交规范：修正 commit message 格式以通过仓库 hook 检查（使用 chore: 前缀）。

学到的新东西
#

技术工具约束：确认 bird news 命令不支持 --hours 参数。
替代方案：在需要时间窗口过滤时，应通过搜索能力叠加时间参数实现，而非依赖无效的 CLI 原生参数。

踩坑记录
#

Git 提交被拒绝：原因在于 commit message 不符合仓库预设的规范（amend 后成功推送）。
注意事项：发布博客时应遵循“只提交正文文件，不提交 resources/_gen 生成资源”的原则，保持仓库整洁。

明日计划
#

优化 AI 资讯推送的筛选逻辑。
补全本周其余简报的相互内链（推荐阅读）。

每日技术实践简报 - 2026-03-25

yangzun@treesir.pub (Zayn) — Wed, 25 Mar 2026 23:00:00 +0800

今日技术实践
#

解决的问题
#

把分散的 DevOps 反馈从“零散问题”改写为“工程健康治理”视角，先做问题分层，再做治理路线，避免头痛医头式修修补补。
对未解决痛点做了结构化快照，统一了后续追踪入口，减少跨工具来回翻找的时间成本。

学到的新东西
#

当问题长期存在且跨团队反复出现时，最有效的切入点不是继续加临时补丁，而是定义统一指标与优先级，把“处理单点故障”升级为“治理系统性风险”。
轻量任务管理在早期调研阶段很关键：先把研究动作显式化，再逐步补齐验收标准，执行阻力会明显下降。

踩坑记录
#

仅有结论没有上下文时，后续复盘很难复用；因此当天补齐了“问题快照 + 行动项”配对记录，确保后续能直接接力推进。

明日计划
#

继续完善工程健康治理的指标草案（稳定性、交付效率、可观测性）。
将今日痛点快照扩展为可执行清单，补充负责边界与时间窗口。
对研究任务增加阶段性产出定义，确保每次推进都有可验证结果。

每日技术实践简报 - 2026-03-24

yangzun@treesir.pub (Zayn) — Tue, 24 Mar 2026 23:00:00 +0800

今天的重点是把“偶发不响应”从体感问题落到可验证的工程问题上：先处理运行形态冲突，再压低高延迟链路，最后形成可复用的排障路径。

解决的问题
#

插件加载失败从“无法启动”修到“可控禁用”：针对插件依赖 openclaw/plugin-sdk 解析失败和 SDK 版本不兼容的问题，先做了本地兼容修复，再按当前需求将相关插件置为禁用，避免持续影响主链路可用性。
网关偶发不响应定位到运行冲突：通过日志和进程状态确认了“多套守护/重复拉起”带来的端口争用与重启风暴风险，最终收敛为“仅 PM2 单监管器”模式，减少了短时不可用窗口。
记忆检索超时有了明确根因：nmem 超时并非随机波动，而是查询输入过长、结构不佳时触发；同时保留 API fallback 作为兜底，保证主流程不被单点阻塞。

学到的新东西
#

稳定性优化要先做形态治理：先统一进程监管、端口绑定和启动入口，再谈参数调优，收益通常更大。
兼容修复应优先“可回退”：遇到插件与宿主版本错配时，先保证系统整体可运行，再决定是升级、重构还是临时下线。
观测信号比主观感受更关键：重启次数、端口占用、超时日志比“感觉卡顿”更能指导下一步动作。

踩坑记录
#

同一服务被多路径拉起时，问题会被放大成随机故障：看似偶发，实际是运行拓扑不一致导致的不确定性。
把整段上下文直接喂给检索接口会引发超时：检索输入需要短、准、结构化，否则很容易触发 CLI 超时。
插件生态与主程序版本耦合度高：升级或安装插件前，最好先做导出接口和依赖路径核对。

明日计划
#

继续观察 PM2 单监管模式下的错误率与响应时延，确认是否彻底消除重启风暴。
为记忆检索补一层输入裁剪与超时重试策略，减少长查询导致的阻塞。
梳理一份“插件兼容检查清单”，用于后续安装或升级前的快速自检。

每日技术实践简报 - 2026-03-23

yangzun@treesir.pub (Zayn) — Mon, 23 Mar 2026 23:00:00 +0800

今天的技术工作比较像一次集中收口：一边把几类工程软件的虚拟化路线梳理清楚，一边继续留意自动化链路的稳定性问题，同时也顺手整理了几条对 AI 工具落地很有用的判断。

解决的问题
#

软件虚拟化路线终于从“都研究一下”变成“按场景拆分”：针对不同软件的图形负载和授权约束，今天把结论明确下来。轻量 2D 场景可以优先考虑 RDS 或普通 VDI，重图形建模场景则必须走带 GPU 的 VDI 或远程工作站，避免一开始就把所有软件硬塞进同一套方案里。
EDA 工具的可虚拟化判断更务实了：从技术上看并不是不能跑，而是不能只看“能启动”。授权、图形性能和稳定性验证要先做小范围 PoC，再决定是否上线，不然前期省下来的部署时间，后面会在故障和兼容性上全部还回去。
CI 失败不再当成偶发噪音处理：今天把多仓库持续出现的 lint、测试和数据同步失败看成系统性问题，而不是零散报警。这个视角调整很重要，因为只要把它当成“偶尔红一下”，流水线就会长期处在不可依赖的状态。

学到的新东西
#

虚拟化不是统一平台问题，本质上是工作负载分层问题：同样叫“设计软件”，2D 制图、3D 建模、EDA 仿真对资源的要求完全不是一个量级。与其追求一套方案覆盖全部，不如先按图形强度和授权风险分层，再匹配 RDS、VDI 或远程工作站。
轻量自动化工具已经进入“随手可做”的阶段：今天再次验证了一个趋势——很多运营辅助、校验类、解析类小工具，已经可以用 AI 代码助手在很短时间内做出可执行版本。真正稀缺的不是写代码本身，而是能否把需求边界说清楚。
AI 治理开始从“能不能用”转向“能不能被信任”：对于企业场景来说，后续评估 AI 系统时，身份说明、审计轨迹和责任边界会越来越重要。只有结果，没有可追溯过程的系统，后面会越来越难进入关键流程。

踩坑记录
#

想用共享 RDS 一次性兜住所有工程软件，这条路看起来省事，实际风险很高：一旦把高图形负载和轻量办公型场景混在一起，性能、体验和授权都会互相拖累。
CI 重复失败最怕“看见了，但没升级处理级别”：如果同类错误连续出现，还只是逐次修补单个 job，团队会慢慢失去对流水线结果的信任，后续问题定位成本会越来越高。
低成本维护项最容易被拖延：像版本巡检这种投入不大但能提前发现兼容性问题的任务，如果长期没人接，就会在真正出故障时放大代价。

明日计划
#

把软件虚拟化结论整理成更清晰的选型文档，便于后续验证和落地。
针对近期反复失败的 CI 链路做一次集中排查，优先看 lint 规则、测试稳定性和依赖一致性。
补上自动化工具和关键依赖的版本巡检，避免小问题积累成兼容性故障。

每日技术实践简报 - 2026-03-22

yangzun@treesir.pub (Zayn) — Sun, 22 Mar 2026 23:00:00 +0800

今天的工作重心比较集中，基本都围绕内部平台迭代、AI 能力验证和汇报方式收口这三件事展开。比起堆更多功能，今天更像是在做“把事情做稳、把表达讲清”的整理工作。

解决的问题
#

内部平台迭代开始进入可用性收口阶段：这次重点不只是补功能，而是把代码仓库整理、稳定性修复和大文件上传验证一起补齐。这样做的好处很直接，后面继续加功能时，不会反复被基础问题拖住。
AI 评审服务正式落到业务链路里：今天把评审系统 V2 和 AI 评审服务继续往前推进，同时联动调试了 CI/CD 流水线调度器。相比单点试验，这一步更像是把能力真正接到可运行流程里。

学到的新东西
#

模型验证不能只看参数，要看落地效果：今天对几组模型和方案做了对比，结论不是谁规格更高谁就一定更合适，而是谁在当前任务里输出更稳定、结果更像可交付内容。
技术汇报按业务结果分组，比按模块罗列更清楚：把内容从“做了哪些技术项”改成“稳定性、能力建设、验证结果、问题处理”这类结构后，整体可读性明显更好，也更方便别人快速抓重点。

踩坑记录
#

很多技术内容本身没问题，问题出在表达方式太像模板：如果汇报里全是“优化、提升、赋能”这类词，读起来很顺，但信息密度其实不高。今天比较明确的一点是，汇报更适合直接写动作、结果和当前状态。
验证链路如果没有和真实流程一起调，结论很容易偏乐观：单独测试能跑通，不等于接进平台后也稳定。今天继续调度器和评审链路时，这个感受更明显。

明日计划
#

继续把内部平台剩余的稳定性问题收口，避免后续功能迭代反复返工。
继续完善 AI 评审链路和调度器联动，优先解决真实流程里的边界问题。
继续优化技术汇报结构，尽量让输出更自然、更具体，少一点空话。

每日技术实践简报 - 2026-03-21

yangzun@treesir.pub (Zayn) — Sat, 21 Mar 2026 22:05:00 +0800

今天把注意力放在两个方向：一是让信息流更适合长期使用，二是让自动化系统在扩展时更稳一点。看起来都像工程细节，但本质上都指向同一个问题：系统不是功能越多越好，而是越能长期稳定输出价值越好。

解决的问题
#

长期记忆开始真正做“减法”：这次重点不是继续往记忆系统里加内容，而是清理低价值信息。像占位模板、一次性播报、运行态重复内容、完成通知这类信息，短期看似有用，长期只会污染检索结果。把这些内容清掉之后，后续搜索和回顾都会更干净。
AI 信息流完成结构化收口：原本的信息汇总更像“把看到的东西发出来”，现在开始转向“按决策价值组织内容”。换句话说，不再只追求多，而是更强调什么值得关注、什么值得试、什么值得警惕。

学到的新东西
#

记忆系统的核心不是存储能力，而是筛选能力：真正有价值的长期记忆，通常只来自稳定偏好、关键决策、已验证结论、长期计划、重要事实和可复用流程。其余内容如果没有被压缩成方法论，留着只会变成噪声。
系统稳定性的关键常常不是功能本身，而是边界是否一致：当一个系统开始分层、拆实例、接更多自动化链路后，最容易出问题的往往不是某个单点能力，而是入口、认证、职责划分这些边界没有统一。
新能力接入越克制，长期越稳：相比一上来就做全量接管，先手动使用、局部验证、逐步扩大范围，往往更适合持续运行的环境。

踩坑记录
#

搜索词过长会直接拖垮检索质量：把整段提示词、上下文说明甚至工作区注入内容一起扔进检索，看起来像“信息更全”，实际上更容易造成召回失真甚至超时。检索系统更喜欢短、准、明确的问题。
自动化摘要如果不做过滤，会悄悄把系统变臃肿：成功通知、定时任务运行记录、线程同步信息，这些内容在当下有参考价值，但不适合作为长期知识保留。系统越自动，这类噪声越容易积累。

明日计划
#

继续压缩记忆系统里的边界项和重复主张，让长期记忆更适合检索和复用。
继续完善 AI 信息流的自动化链路，重点补上去重与防重复触发。
继续把正在推进的几个方向往“可持续”上收：不是追求一次做完，而是让系统以后少返工、少回退。

每日技术实践简报 - 2026-03-20

yangzun@treesir.pub (Zayn) — Fri, 20 Mar 2026 22:30:00 +0800

今天的工作更偏向“把系统说明白”。很多时候，工程效率不是来自多写几段代码，而是来自把命名、提醒和选型这些基础问题先梳理清楚。基础一旦清楚，后续很多动作都会顺下来。

解决的问题
#

命名体系开始收口：围绕一套产品命名方式做了结构化梳理，把原本分散的叫法整理成更清晰的层级关系。命名一旦统一，后续无论是归档、映射还是自动识别，成本都会明显下降。
任务提醒链路继续稳定化：同一套提醒机制在不同时间点给出了相对一致的结果，说明这条链路已经不只是“能跑”，而是在向“可依赖”靠近。

学到的新东西
#

好的命名规范本质上是在降低系统沟通成本：如果一套命名只能被少数人理解，它就更像内部黑话；如果它能稳定映射到平台、代际和能力差异，它才真正具备长期价值。
自动化体系成熟的标志不是任务数量，而是分层是否清楚：当提醒、汇总、检测和执行这些能力开始形成稳定分工，系统就会从单点脚本堆叠，演进成更像“运营架构”的东西。
硬件选型最怕脱离使用场景：同样一颗 CPU，在不同任务下价值完全不同。比起盯着参数高低，更重要的是明确自己的主要负载到底是什么。

踩坑记录
#

兼容性问题不能只看理论方案：纸面上可行的硬件方案，落到具体设备时仍然可能受安装位、接口规格和结构差异影响。越接近实体世界，越要尊重“逐项确认”这件事。

明日计划
#

继续把命名规范往后续流程里落，验证它是否真的能减少返工。
继续观察提醒链路在真实使用中的稳定性，而不只停留在单次成功。
继续把技术选择建立在实际使用场景之上，而不是单看参数表。

每日技术实践简报 - 2026-03-19

yangzun@treesir.pub (Zayn) — Thu, 19 Mar 2026 22:30:00 +0800

今天更多是在看“系统什么时候该提醒，什么时候该克制”。一个自动化系统如果只会不停报消息，很快就会让人失去耐心；但如果它什么都不说，又失去了存在意义。真正难的是边界感。

解决的问题
#

告警范围开始更接近真实风险：把关注点从单纯的应用状态，扩展到更广义的自动化运行状态。这样做的意义不在于让告警更多，而在于让真正值得人工介入的问题更早被看见。
异常状态识别更完整了一步：当某些凭证或访问条件失效时，系统不一定能继续判断全部上下文。这提醒我，自动化系统不只是要处理“正常输入”，还要明确面对“信息不完整”的表现方式。

学到的新东西
#

提醒系统的价值来自筛选，而不是频率：如果什么都提醒，提醒就会失去价值。比起频繁轮询，更重要的是找准哪些任务值得优先看、哪些状态只需要留痕不需要打扰。
静默策略是自动化系统成熟的重要标志：很多系统会做“能提醒”，但很少认真做“什么时候不该提醒”。真正长期可用的自动化，必须包含安静时段、节奏边界和打扰成本的设计。

踩坑记录
#

只有告警，没有自愈，系统仍然很脆：能发现问题固然重要，但如果后续没有重试、回退或补救机制，很多告警最终还是只能堆成人工负担。
依赖单点前提的监控很容易出现盲区：一旦某个关键前提失效，系统可能不只是“报错”，而是直接失去判断能力。这类问题往往比普通失败更值得优先补上。

明日计划
#

继续区分“需要提醒”和“只需记录”的事件类型。
评估哪些告警链路值得补自动重试或基础自愈。
继续把监控目标从单点状态扩展到真实可用性。

每日技术实践简报 - 2026-03-18

yangzun@treesir.pub (Zayn) — Wed, 18 Mar 2026 23:00:00 +0800

今天的信息输入比较密集，但真正值得留下来的，不是“看到了多少新东西”，而是几个越来越清楚的趋势：模型在分化，助手在贴近个人场景，工具链则在向更专门化的方向走。

解决的问题
#

信息监控继续维持可用状态：今天的重点不是做大的改动，而是确认几条关键监控链路依旧可靠。对自动化系统来说，稳定地获得输入，往往比增加新能力更重要。
工具版本保持收敛：没有为了追新而升级，而是先确认当前版本是否足够稳定。很多时候，不升级也是一种工程判断。

学到的新东西
#

模型正在明显分化成更细的使用形态：一部分模型继续追求通用能力，另一部分则越来越强调特定任务、特定负载和特定场景的效率。这意味着以后做技术选型，不能再只看“谁最强”，而要看“谁最合适”。
个人助理式 AI 正在更接近真实使用场景：当工具开始更深地理解用户的历史行为、个人上下文和长期偏好时，AI 的角色也会从“回答问题的工具”逐渐走向“持续协作的助手”。
稳定版本的价值经常被低估：如果一个工具当前已经足够稳定、足够满足需求，那么保持版本不乱动，本身就是降低风险的一种方式。

踩坑记录
#

信息监控最容易滑向“信息堆积”：输入越多，越容易把重要和不重要混在一起。系统要真正有价值，核心不是看得多，而是能不能把重点筛出来。

明日计划
#

继续观察模型和工具链的演进方向，重点关注那些真正改变工作方式的变化。
继续收敛监控内容，把注意力集中在少量高价值信号上。
在稳定优先的前提下，再决定哪些工具值得进一步跟进。

每日技术实践简报 - 2026-03-17

yangzun@treesir.pub (Zayn) — Tue, 17 Mar 2026 23:00:00 +0800

今天更像一次“把系统从能用推向稳用”的过程。很多问题表面看是单点故障，但往下挖，会发现真正需要治理的是配置习惯、安全边界和系统默契。

解决的问题
#

索引与可发现性问题得到修复：一项影响内容被发现的能力恢复正常。看起来只是一个结果恢复，但背后真正重要的是验证链路是否重新闭环。
一项平台能力完成阶段性增强：这次推进的重点不在“功能更多”，而在“能力更完整”，包括模型接入、动态配置以及基本的安全防护都往前走了一步。

学到的新东西
#

安全治理最好在系统早期就做进默认动作里：输入校验、认证、输出清洗这类能力，如果一开始没建立边界，后面补起来通常成本更高。
静默策略不是附属规则，而是系统体验的一部分：深夜只做状态检查、不重复提醒，看似只是交互细节，实际上决定了系统是否长期可用。
配置清洁度会直接影响系统稳定性：占位符、硬编码、路径约定这些小问题，平时看不起眼，但往往最容易在后续运维里变成真实故障。

踩坑记录
#

远程依赖的可用性经常卡在认证而不是逻辑：很多“拉不下来”“连不上”的问题，最终都不是代码逻辑本身，而是访问边界没有配置对。

明日计划
#

继续把配置治理、安全边界和运行策略做得更一致。
继续验证恢复后的链路是否稳定，而不是只看一次成功。
继续审查外部依赖的访问前提，减少后续中断。

每日技术实践简报 - 2026-03-15

yangzun@treesir.pub (Zayn) — Sun, 15 Mar 2026 23:30:00 +0800

今天做的事情很多，但核心其实只有一个：把原本零散的博客发布动作，逐步收成一条更稳定的自动化链路。做这类系统时，最耗时间的往往不是“功能写出来”，而是把那些看似不起眼的前提条件一个个踩实。

解决的问题
#

自动化任务的执行前提被补齐：一些之前容易被忽略的必要参数和调用约束，这次都被重新确认并纳入固定流程。很多自动化任务不是逻辑错，而是前提没说清。
博客渲染规则得到统一：围绕图表渲染、正文写法和页面配置，把容易反复踩坑的地方都做了规范化处理。统一写法的价值，不是好看，而是避免下次再被同一类问题绊住。
重复发布风险开始被正视：内容自动生成一旦没有前置检查，很容易把同一主题发成多个版本。与其事后清理，不如在发布前就建立一层重复检查。

学到的新东西
#

自动化系统最重要的是“前提显式化”：什么字段必须有、什么格式必须对、什么配置必须先开，这些条件如果只存在脑子里，系统迟早会在别的时间点再坏一次。
内容系统也需要工程治理：博客表面上是内容输出，但一旦接入自动生成、渲染和发布流程，它本质上就是一套工程系统，同样需要规范、去重和失败兜底。
好的技能不是功能更多，而是更少重复踩坑：当一个技能把超时、重试、格式约束和重复检查都处理好之后，它才算真正变得“能长期用”。

踩坑记录
#

看似很小的格式问题，会一路放大成发布故障：文件命名、大小写、图表写法、正文转义这些细节，只要有一个没处理好，就可能让后面的渲染或发布全部出问题。
发布前不做去重，后面就要花更多时间清理：自动化一旦缺少“停止条件”，它就会用极高效率把重复问题放大。

明日计划
#

继续补强博客自动化链路的前置检查与失败兜底。
继续把容易重复踩的格式和配置问题收敛成固定规范。
继续观察内容生成与发布流程是否真正具备长期稳定性。

每周技术实践总结 - 2026 年第 11 周

yangzun@treesir.pub (Zayn) — Sun, 15 Mar 2026 22:30:00 +0800

这周做的事情表面上很散：任务管理、博客自动化、记忆系统、监控恢复、工具选型、系统排障。但回头看，真正贯穿整周的其实是同一个问题：怎么把一个越来越复杂的系统，慢慢收成一个长期可用的系统。

我现在越来越相信，很多工程工作最值钱的部分，不是“又接了一个新能力”，而是把那些已经存在的东西收干净、讲清楚、跑稳定。

这一周真正推进的几件事
#

1. 自动化开始从“能跑”变成“有层次”
#

这周一个明显变化是，很多原本孤立的自动化动作，开始不再像散落的脚本，而更像有分工的系统。

每日技术实践简报 - 2026-04-02：博客 Git 工作流治理、Linux 笔记本选购调研与 AI 安全事件追踪

yangzun@treesir.pub (Zayn) — Thu, 02 Apr 2026 22:00:00 +0800

今日技术实践
#

解决的问题
#

博客 MR 合并冲突解决：MR !53 合并后，后续推送的 03-29、03-30 日报和 03-31 重写版未包含在合并中。根因是合并后继续往同一分支推送新 commit，但未创建新 MR。最终通过本地 git merge 解决冲突，直接推送到 main 分支。

每日技术实践简报 - 2026-03-31：Claude Code 源码泄露、运维告警集中爆发与海南骑行决策

yangzun@treesir.pub (Zayn) — Tue, 31 Mar 2026 23:00:00 +0800

今日技术实践
#

解决的问题
#

多源运维告警分级梳理：一天之内收到 5 类告警——腾讯云 SSL 证书过期（3/28 通知，已过 3 天未续期）、YangZun Playground 反复宕机（3/29-3/31 共 6 次 DOWN/UP 循环）、TrueNAS 存储告警连续触发、CloudflareSpeedTest CI 连续 10 次失败、GitLab 暴力登录（1 分钟内 7 次验证码错误）。按紧急度分级：SSL 续期和 YangZun 根因排查为最高优先级。

每日技术实践简报 - 2026-03-30：工作周报整理、编程范式梳理与运维治理体系沉淀

yangzun@treesir.pub (Zayn) — Mon, 30 Mar 2026 23:00:00 +0800

今日技术实践
#

解决的问题
#

工作周报生成：使用 work-report-generator Skill 从对话记录中提取本周工作内容，先生成详细版再转化为领导汇报版（结果导向、简洁专业、突出重点和下一步计划）。
编程范式梳理：整理了面向过程、面向函数、面向对象三种编程范式的演进关系、核心区别和实际应用场景。现代语言已走向多范式混合路线。

学到的新东西
#

领导汇报版周报格式：分"重点工作"和"其他工作"两大块，重点工作按项目编号列出成果，底部用表格呈现下周计划和预期目标。语言风格要结果导向，不说过程只说结论。
编程范式本质区别：面向过程关注"步骤"（流程图），面向函数关注"变换"（数学映射），面向对象关注"协作"（角色交互）。三者不互斥，现代语言多范式混合是主流。
运维治理三重机制验证：预防层（配置审查、安全检查、操作规范）→ 监控层（日常检查、日志监控、错误追踪）→ 修复层（降级策略、备份恢复、故障诊断），已形成闭环且错误率显著下降。

实际产出
#

本周工作周报（领导汇报版）1 份
博客运营优化巡检自动执行（每日 10:15），当天优化了 03-21 和 03-15 日报标题

踩坑记录
#

Cron 任务 delivery 报错：多个 isolated agentTurn 任务（博客巡检、AI 论文简报、AI 资讯速览等）因缺少 channel 参数报 “Channel is required” 错误。在多通道配置（telegram + openclaw-weixin）环境下必须显式设置 delivery.channel: "telegram"。

其他思考
#

国产咖啡品牌调研：三顿半超级拿铁系列（3号经典拿铁、4号浓郁拿铁）适合不喜欢纯深烘焙的口味偏好，冻干粉冷水即溶，单杯不到 5 元，是日常口粮咖啡的高性价比选择。
外部服务依赖风险：Brave Search API 月度额度耗尽导致搜索能力暂时不可用，提醒了对外部 API 的依赖需要有降级预案。

每日技术实践简报 - 2026-03-29：从 MCP 到一键发包的博客深度写作与 Skill 链优化

yangzun@treesir.pub (Zayn) — Sun, 29 Mar 2026 23:00:00 +0800

今日技术实践
#

解决的问题
#

深度博客文章撰写：完成"从 MCP 到一键发包"的 300+ 行技术博客，完整记录了从 Teambition MCP 对接到 APK 自动上传 Nexus 的全链路踩坑过程。
Blowfish 主题 shortcode 踩坑：发现主题没有 notice shortcode，只有 alert。经过多次 sed/edit 替换尝试，最终确认正确语法为 {{< alert "icon-name" >}}内容{{< /alert >}}。
Mermaid 流程图修复：从 text 代码块改为 {{< mermaid >}} shortcode 格式，Hugo 才能正确渲染可视化流程图。
Git 分支治理：发现旧分支 feat/extract-markdown-rental-risk-20260324 堆积了大量无关提交（_index.md 修改、租房信息文章等），从 main 重新创建干净分支，只包含必要文件。

学到的新东西
#

Blowfish 可用 shortcode 清单：alert、mermaid、chart、timeline、figure、gist、katex 等。写文章前先确认 shortcode 存在，不要凭记忆用。
blog-post-generator Skill 规范：frontmatter 需要 featureimage、keywords、tags_weight/categories_weight；推荐阅读用相对路径内链；代码块必须是实际可用代码，不要伪代码。
Git 分支清理策略：保护分支的仓库应"从 main 创建新分支 → cherry-pick 或 checkout 需要的文件 → 关闭旧 MR → 创建新 MR"，比 rebase 更可控。
租房等非技术内容不应推到技术博客：分支提交前必须 review 文件列表，排除无关内容。

实际产出
#

深度博客文章 1 篇（302 行，9892 字节）
3月28日日报 1 篇
Git MR !53 创建（干净版本，排除租房信息）

踩坑记录
#

notice shortcode 不存在：Blowfish 主题没有 notice，只有 alert。Skill 文档记录有误，需以实际 shortcode 目录为准。
多次 sed 替换导致文件状态混乱：部分 notice 被替换为 alert，但残留不完整标签。应一次性 read 全文确认再精确 edit。
Hugo 版本兼容性警告：Module “blowfish” is not compatible with Hugo 0.137.0/0.148.0，但实际构建可通过，属于警告而非阻断。

其他思考
#

博客写作风格确立：口语化、有实操感、不要 AI 味；像一个资深工程师在写给同行看；段落简短，多用小标题。
博客 Skill 链（blowfish-hugo + blog-post-generator + structured-guide-writer）已形成完整工作流，后续写作效率会持续提升。

每日技术实践简报 - 2026-03-28：从 MCP 到一键 APK 发布的 Skill 封装

yangzun@treesir.pub (Zayn) — Sat, 28 Mar 2026 23:00:00 +0800

今日技术实践
#

解决的问题
#

Teambition MCP 全链路打通：验证了 BatchGetFileDetails、ListTaskActivitiesV3、PostV3MemberQuery 三个核心 API 的完整调用链路，解决了从任务评论中提取附件信息的需求。
成员 ID 映射机制：建立了项目成员 ObjectId → 真实姓名的映射表（37人），支持"陌生 ID 自动触发全量刷新"的缓存策略，让任务动态终于可读了。
tb-apk-uploader Skill 封装：将"TB附件获取 → 下载 → 重命名 → 上传 Nexus → 返回链接"的完整流程封装为独立 Skill，经 skill-creator 规范优化并打包验证通过。

学到的新东西
#

mcporter 调用参数格式：mcporter call 必须用 --args 传参且包在 requestBody 里，用 --body 会报 SyntaxError。这是踩了一个小时的坑才找到的。
Skill 封装规范：frontmatter description 要包含完整触发词，body 只保留工作流程和脚本用法，不要重复 frontmatter 信息。渐进式披露，核心逻辑在脚本里。
APK 文件名标准化规则：TB 附件下载后经常带 .1 后缀、(1) 括号、E 前缀，需要正则清洗。如 RinoTrack_E4218_3.2.820260326_release(1).apk.1 → RinoTrack_4218_3.2.820260326_release.apk。

实际产出
#

成功上传了两个 APK 到 Nexus（RinoTrack 85MB + 微信 248MB）
自动回复了下载链接到 DO-6456 评论区
tb-apk-uploader Skill 打包为 .skill 文件，可分发复用

踩坑记录
#

mcporter 参数格式：--body → --args + requestBody 包装
Nexus 重复上传：同一文件重复上传返回 HTTP 400，不是错误而是"已存在"，需要正确处理

其他思考
#

骑行语音 AI 助手项目构思（代号备选 CADENCE），核心场景：骑行中记录灵感 + 处理工作任务，已创建滴答清单任务储备。
讨论了 DevOps/SRE 在 AI 时代的转型方向，核心结论：不需要转行，需要在现有方向上叠加 AI 能力。

实践记录 on Zayn's Blog

每日技术实践简报 - 2026-03-27：GPU 分层选型与 OpenClaw 安全基线

推荐阅读 #

今日技术实践 #

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

每日技术实践简报 - 2026-03-26

推荐阅读 #

今日技术实践 #

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

每日技术实践简报 - 2026-03-25

今日技术实践 #

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

推荐阅读 #

每日技术实践简报 - 2026-03-24

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

推荐阅读 #

每日技术实践简报 - 2026-03-23

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

每日技术实践简报 - 2026-03-22

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

每日技术实践简报 - 2026-03-21

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

每日技术实践简报 - 2026-03-20

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

每日技术实践简报 - 2026-03-19

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

每日技术实践简报 - 2026-03-18

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

每日技术实践简报 - 2026-03-17

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

每日技术实践简报 - 2026-03-15

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

每周技术实践总结 - 2026 年第 11 周

这一周真正推进的几件事 #

1. 自动化开始从“能跑”变成“有层次” #

每日技术实践简报 - 2026-04-02：博客 Git 工作流治理、Linux 笔记本选购调研与 AI 安全事件追踪

推荐阅读 #

今日技术实践 #

解决的问题 #

每日技术实践简报 - 2026-03-31：Claude Code 源码泄露、运维告警集中爆发与海南骑行决策

推荐阅读 #

今日技术实践 #

解决的问题 #

每日技术实践简报 - 2026-03-30：工作周报整理、编程范式梳理与运维治理体系沉淀

推荐阅读
#

今日技术实践
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

推荐阅读
#

今日技术实践
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

今日技术实践
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

推荐阅读
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

推荐阅读
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

这一周真正推进的几件事
#

1. 自动化开始从“能跑”变成“有层次”
#

推荐阅读
#

今日技术实践
#

解决的问题
#

推荐阅读
#

今日技术实践
#

解决的问题
#

推荐阅读
#

今日技术实践
#

解决的问题
#

学到的新东西
#

实际产出
#

踩坑记录
#

其他思考
#

推荐阅读
#

今日技术实践
#

解决的问题
#

学到的新东西
#

实际产出
#

踩坑记录
#

其他思考
#

推荐阅读
#

今日技术实践
#

解决的问题
#