AI 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-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 AI Agent 工程化全景：从框架选型到生产落地

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

从 7 层架构到框架选型、从多智能体协作到记忆系统、从 Coding Agent 到企业工具链的 AI Agent 2026 工程化实践全景。

Claude Code + GitLab pr-agent：AI 驱动的持续迭代开发实践

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

32 个 MR 的真实案例，展示 Claude Code + GitLab CI + pr-agent 三位一体的 AI 驱动持续迭代开发工作流。

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

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

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

解决的问题
#

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

学到的新东西
#

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

踩坑记录
#

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

明日计划
#

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

OpenClaw AI Agent 架构解析：多引擎联动与记忆系统

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

OpenClaw AI Agent 架构解析
#

核心架构
#

graph TB
subgraph Agent["OpenClaw Agent"]
Claude["Claude Sonnet 4.6"]
GPT["GPT-5.2/5.3"]
GLM["GLM-5"]
Gemini["Gemini Pro"]
end
subgraph Router["Model Router"]
Route["路由层"]
end
subgraph Skills["Skills Layer"]
Blog["blog-post-generator"]
Daily["daily-blog-generator"]
Code["coding-agent"]
Others["90+ skills..."]
end
subgraph MCP["MCP Layer"]
Team["Teambition MCP"]
NMem["Nowledge Mem MCP"]
Other["其他 MCP..."]
end
Claude --> Route
GPT --> Route
GLM --> Route
Gemini --> Route
Route --> Skills
Skills --> MCP

1. 多 AI 引擎联动
#

模型配置
#

{
 "providers": {
 "anthropic-local": {
 "models": ["claude-sonnet-4-6"]
 },
 "openai-codex": {
 "models": ["gpt-5.2", "gpt-5.3-codex"]
 },
 "zai": {
 "models": ["glm-5"]
 }
 }
}

路由策略
#

flowchart LR
A[任务类型] --> B{判断}
B -->|日常对话| C[Claude Sonnet 4.6]
B -->|代码生成| D[GPT-5.3-Codex]
B -->|复杂推理| E[GPT-5.4]
B -->|中文任务| F[GLM-5]

任务类型	推荐模型	原因
日常对话	Claude Sonnet 4.6	成本低、速度快
代码生成	GPT-5.3-Codex	代码能力强
复杂推理	GPT-5.4	推理能力最强
中文任务	GLM-5	中文理解好

Sub-Agent 编排
#

graph LR
Main[主 Agent
Claude Sonnet 4.6] --> S1[Sub-Agent 1
GPT-5.2 搜索总结]
Main --> S2[Sub-Agent 2
Claude 文档处理]
Main --> S3[Sub-Agent 3
GPT-5.3 代码审查]

2. 记忆系统
#

架构图
#

graph TB
subgraph Memory["记忆系统"]
WM["Working Memory
(工作记忆)"]
NM["Nowledge Mem
(知识图谱)"]
LT["MEMORY.md
(长期记忆)"]
TL["Timeline
(时间线)"]
end
WM <--> NM
NM --> TL
NM --> LT
Session[每次对话] --> WM
Session --> NM

三层记忆
#

flowchart TD
A[对话启动] --> B[Working Memory
当日焦点]
A --> C[相关记忆
语义搜索]
A --> D[Timeline
最近活动]
B --> E[构建上下文]
C --> E
D --> E
E --> F[Agent 响应]

层级	存储	用途
Working Memory	Nowledge Mem	当日焦点、优先事项
Long-term Memory	MEMORY.md	持久化记忆、偏好
Timeline	Nowledge Mem	活动历史、事件记录

3. 定时任务系统
#

Cron 配置
#

{
 "name": "每日博客简报生成",
 "schedule": { "kind": "cron", "expr": "0 23 * * *" },
 "payload": {
 "kind": "agentTurn",
 "message": "执行 daily-blog-generator skill",
 "model": "anthropic-local/claude-sonnet-4-6"
 },
 "sessionTarget": "isolated"
}

任务类型
#

flowchart LR
A[Cron 任务] --> B{类型}
B -->|systemEvent| C[注入系统事件
无需 model]
B -->|agentTurn| D[隔离会话执行
需要 model]

4. Skills 体系
#

目录结构
#

~/.agents/skills/
├── blog-post-generator/
│ └── SKILL.md
├── daily-blog-generator/
│ └── SKILL.md
├── coding-agent/
│ └── SKILL.md
└── ... 90+ skills

Skill 触发流程
#

sequenceDiagram
participant U as 用户
participant A as Agent
participant S as Skill
participant B as 博客
U->>A: 随机找一篇上传 blog
A->>S: 匹配 blog-post-generator
S->>S: 1. 从远程仓库获取文档
S->>S: 2. 检查博客已有内容
S->>S: 3. 优化文风
S->>B: 4. 发布到博客
B-->>U: 发布成功

5. 最佳实践
#

模型选择流程
#

flowchart TD
A[任务] --> B{复杂度}
B -->|简单| C[Claude Sonnet 4.6
省钱]
B -->|复杂| D{类型}
D -->|代码| E[GPT-5.3-Codex]
D -->|推理| F[GPT-5.4]
D -->|中文| G[GLM-5]

配置规范
#

✅ 模型名必须写完整：anthropic-local/claude-sonnet-4-6
✅ 路径必须用绝对路径
✅ agentTurn 任务必须带 model 字段

避坑指南
#

graph LR
A[问题] --> B{诊断}
B -->|模型回退失败| C[检查 fallback provider]
B -->|Cron 不执行| D[检查 model 字段]
B -->|Skills 加载不到| E[检查绝对路径]

问题	原因	解决方案
模型回退失败	fallback 模型的 provider 未配置	检查 providers 配置
Cron 任务不执行	缺少 model 字段	agentTurn 必须带 model
Skills 加载不到	路径用相对路径	本机必须用绝对路径

这套架构运行稳定，每天自动生成博客简报，任务管理效率提升 49%。

每日技术实践简报 - 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 能力。

当 AI Agent 遇上运维自动化：我的实践踩坑之路

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

当 AI Agent 遇上运维自动化：我的实践踩坑之路
#

花了几天把 AI Agent 集成到日常运维里，踩了不少坑，记录下来供参考。

1. 为什么要用 AI Agent
#

简单说就是：太累了。

字节 Coze 平台实战：从零搭建 AI 智能体

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

字节 Coze 平台实战：从零搭建 AI 智能体
#

踩过不少坑，花了不少时间，终于把 Coze 这套东西摸透了。本文不整虚的，直接上干货。

1. 先说说为什么选 Coze
#

市面上 AI 应用开发平台不少，Coze 几个点比较实在：

AI on Zayn's Blog

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

推荐阅读 #

今日技术实践 #

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

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

推荐阅读 #

今日技术实践 #

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

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

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

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

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

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

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

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

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

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

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

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

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

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

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

2026 AI Agent 工程化全景：从框架选型到生产落地

Claude Code + GitLab pr-agent：AI 驱动的持续迭代开发实践

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

解决的问题 #

学到的新东西 #

踩坑记录 #

明日计划 #

OpenClaw AI Agent 架构解析：多引擎联动与记忆系统

OpenClaw AI Agent 架构解析 #

核心架构 #

1. 多 AI 引擎联动 #

模型配置 #

路由策略 #

Sub-Agent 编排 #

2. 记忆系统 #

架构图 #

三层记忆 #

3. 定时任务系统 #

Cron 配置 #

任务类型 #

4. Skills 体系 #

目录结构 #

Skill 触发流程 #

5. 最佳实践 #

模型选择流程 #

配置规范 #

避坑指南 #

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

推荐阅读 #

今日技术实践 #

推荐阅读
#

今日技术实践
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

推荐阅读
#

今日技术实践
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

解决的问题
#

学到的新东西
#

踩坑记录
#

明日计划
#

OpenClaw AI Agent 架构解析
#

核心架构
#

1. 多 AI 引擎联动
#

模型配置
#

路由策略
#

Sub-Agent 编排
#

2. 记忆系统
#

架构图
#

三层记忆
#

3. 定时任务系统
#

Cron 配置
#

任务类型
#

4. Skills 体系
#

目录结构
#

Skill 触发流程
#

5. 最佳实践
#

模型选择流程
#

配置规范
#

避坑指南
#

推荐阅读
#

今日技术实践
#

解决的问题
#

学到的新东西
#

实际产出
#

踩坑记录
#

其他思考
#

当 AI Agent 遇上运维自动化：我的实践踩坑之路
#

1. 为什么要用 AI Agent
#

字节 Coze 平台实战：从零搭建 AI 智能体
#

1. 先说说为什么选 Coze
#