不愧是啄木鸟啊！感谢指出～

        这段代码主要用来演示如何捕获 diff，触发自动化反馈，确实是只会触发在本地终端，无可争议。

        针对此，通常建议使用 Notification Hook，监听 agent_completed 事件，对接到 IM 上，文中有补充道。

落地的话，结合你们的项目与公司的方向吧。因为专门的 agent 或者是 skill 的形式，对于知识库的依赖以及架构都是不同的，前者属于专门的智能体工程范畴，后者更加灵活重点可以放在知识库的质量上。且如果现有体系属于旧工程师搭建的 GUI 的情况下，其实可以直接考虑轻量 AI 重构，那么知识库也可以作为输入的形式，符合轻量高效。

具体人力时间只能说个大概，从 4 月份开始，人力分为专项 + 专人 all in

这种情况下需要你们公司的 CLI 基础设施建设跟得上，多平台 CLI 化，对于 Agent 而言才是理想环境。

怎么开始伤春悲秋了呢，就拿前段时间大热的 DeepSeek 招聘事件，算是国内无穷趋近 AI 的业务吧。其中就有 QA 岗位：https://app.mokahr.com/social-recruitment/high-flyer/140576#/job/50733e68-4b26-4037-8b63-2ed781aa44ed

        首先针对于 PRD 和技术文档，test-runner 会基于新增功能的全新测试，其中的回归是基于 CLAUDE.md 中涉及到的 “关键风险区域” 和 “历史缺陷” 在现有的回归测试集中进行的回归。
        而且需求不断的迭代完全可以靠 AI 驱动的 case 作为回归集，并且曾经的一些 GUI 或者是已有沉淀下来的 case 早已作为养料用 AI 标准化重构了，所以早已有了一大批可以复用且适合作为回归集的 case 了。
        另外，AI 需要了解的业务逻辑都是通过沉淀的知识库的形式来解决的，我们会先让 AI 去洗现有人类沉淀的文档，并且配有专人去把控去洗，把这些都整理为知识库的形式。
        以及，AI 执行的时候，不需要 “猜” 表的关系，而是依据知识库中的明确指引去执行校验。
        AI 断言在完全的 AI 驱动的情况下，也会有断言标准知识库用于参考，并辅以 prompt 执行。

不客气，一起加油！我简单补充一下：如果 skill 需要扩容的情况下，建议拆开 skill，主 skill 包含子 skill 化，这样效果会更好一些。

嗯是这样的，不同模型用于训练的数据集、偏好对齐、架构都有差异。

        难道现在写技术文章的评判标准变成了 “越排版混乱、越语无伦次就越像人写的” 吗？😂

        全文每一个字都是我自己敲的，连段首的缩进空格都是我一个个手动调的，“笔者” 也是我一贯的行文习惯。辛苦梳理的干货被一句 “AI 味” 盖章，确实挺让人哭笑不得。

        不过我也反思了一下，可能是我这篇逻辑理得太顺、排版修得太齐了、截图给的太好了、链接给的太全了。下次要不故意敲错几个字、少打个标点，是不是就符合您对 “人类手写” 的刻板印象了？

        最后呀，我特意去拜读了一下您过往的文章，发现您在排版上似乎稍微有点……不拘小节。为了提升您以后的阅读体验，送您一个段首缩进空格的排版呀，不用感谢我：
“        ”

        哈哈，这话有点像"既然有 IDE 自动补全，干嘛还学写代码"。

        我非常支持用 skill-creator 来加速写 Skill，这叫"善假于物也"。但你要是连 Skill 的门道都不懂，丢给 skill-creator 的需求不是太模糊就是太随意，最后生成的 Skill 也就是个"能跑但不好用"的东西。

        我的看法很简单：先搞懂 Skill 怎么设计（这篇文章讲的），再用 skill-creator 帮你实现和迭代。这样才叫 1+1>2。