【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址https://gitcode.com/gh_mirrors/je/jevgrep点击查看免费下载导读本文以 jevgrep 仓库内置的.agents/skills/code-review/SKILL.md文档为主体系统讲解其面向 AI 编码 Agent 的代码评审方法论26 条可执行的评审原则覆盖命名、注释、模块边界、测试质量、认证安全、批处理容错等主题以及“Review → 分组引用行号 → clean/not-clean 结论”的评审流程。读完本文你将掌握一套可直接交付给 Agent 的评审 checklist并了解该技能在 jevgrep 仓库中如何与review、refactor-clean、write-tests等技能协同工作以及仓库源码中的对应实现证据。一、技能定位何时触发、用哪些工具该文档的元信息frontmatter界定了技能的使用边界名称namecode-review描述description用于评审已变更代码的命名、过期引用、不必要的复杂度与注释质量应在完成实现工作之后、提交之前或用户要求审查/审计代码时使用允许工具allowed-toolsRead Grep Glob Bash——评审者只被允许读取文件、搜索引用、按模式查找文件和执行 shell 命令不需要也不应修改代码这与 README 中“仓库是只读”的定位一致code-review是审查者产出的是带行号的分组问题清单与最终结论而不是改动本身。修改工作交给refactor-clean形状与implement-spec等实现类技能。二、评审流程与输出契约文档末尾的Your task定义了评审的硬性执行协议输入Review: $ARGUMENTS——若未给出参数则默认评审git diff --staged暂存区或git diff未暂存改动输出要求每个发现的问题必须引用文件和行号cite the file and line number按类别分组Group by category以clean/not-clean的明确结论收尾这个协议保证了评审结果可回溯、可复核。jevgrep 仓库中review技能.agents/skills/review/SKILL.md进一步说明了code-review在整个交付流程中的位置一个完成的变更要经历三道关口——形状shape由refactor-clean负责、diffdiff由code-review负责、文档docs由write-docs负责code-review发现的问题若迫使结构性改动必须回到refactor-clean重新执行而不是带病前进。三、命名与引用的真实性原则 1–33.1 名字必须反映当前现实变量名和函数名应描述它们现在是什么what they ARE而不是曾经是什么。当底层机制发生变化文档举例FUSE → NFS所有相关命名都必须同步更新。评审时问自己一个新读者会被这个名字误导吗3.2 不允许存在过期引用重构之后必须用 grep 搜索对旧方案的引用——遗留的检测逻辑、废弃的功能开关、提到已删除代码的注释。如果某个方案“试过又回退了”就要清除全部痕迹代码库应该看起来“当前方案从一开始就是计划”。3.3 检测逻辑只保留真正必要的一个判断“这个功能能否运行”这类 gate 应当只检查真正关键的那一个条件。不要串联回退式检测binary 存在 OR 源码存在 OR 工具链存在当其中一项检查已能覆盖全部时其余都是噪音。仓库佐证code-review强调的“删除过期路径”在仓库的refactor-clean技能.agents/skills/refactor-clean/SKILL.md中被进一步放大为“零谱系命名”Zero lineage signaling——名字编码历史foo-v2、foo-legacy、以实验命名模块对后来的读者毫无信息量历史应该留在 git 里而不是留在标识符里。四、注释只写 WHY不写发生过什么原则 4注释质量是评审的核心维度之一文档给出了明确的正反清单保留Keep——非显而易见的发现、平台怪癖、“如果删掉这行X 会因 Y 而坏”// com.apple.provenance causes SIGKILL when spawned as child process // umount while server is alive panics the macOS NFS client // NFS client uses cookie verifier to decide if cached readdir is valid删除Remove试过什么、放弃什么、改过什么名字的叙事// We changed this from cp to cat to work around the provenance issue// Wrapper added because FUSE-T was zero-padding (see commit abc123)// Previously this was called fuseAvailable but we renamed it只是复述代码行为、不补充推理的注释很多时候根本不需要注释Often no comment is needed at all原则 26 补充了一条硬规则发现的错误注释本身就是缺陷A comment you discover is false is a defect必须当场修正——错误的注释比没有注释更危险因为它会误导所有后来的读者。五、安装期与运行期分离、消灭中间产物原则 5–6安装脚本负责准备前置条件工具链、系统依赖运行时命令负责编译、缓存、二进制管理。两者不得混用——如果安装脚本在编译运行时也要编译的二进制那么两者必有一方是错的。在多轮方案迭代后要审计是否存在“只是垫脚石”的逻辑为方案 A 加的 workaround切到方案 B 后必须删除即使它无害。代码应读起来像是一个早知道正确答案的人从零写出来的。这条原则在 jevgrep 的 CLI 中有直接体现jg skill命令apps/cli/src/skill.ts把“安装技能”这个职责严格放在安装路径上——它通过npx skills add dzhng/jevgrep --skill jevgrep委托给外部 skills 安装器而不是在jg运行时逻辑中内联任何安装细节搜索运行时则完全不触碰安装相关代码。六、变更之后收紧保证原则 7当某个变更让原本“可能”的事情变成“必然”变量总是被赋值、文件总是被创建、函数总是返回必须审计下游代码中仍然防御旧“可能态”的守卫冗余的空值检查、回退默认值、对不可能再为 null 的值做if (x)守卫——它们暗示着不存在的可能性是误导不再需要重新赋值时优先const而不是let绝不压制信号要修复根因_前缀的未用参数、// ts-ignore、eslint-disable、as any都在掩盖真实问题。参数不用就 DELETE并把删除级联到所有调用方类型不匹配就修类型。运行检查器、修掉每个错误、重复此过程。跨多文件的机械改动正是 Agent 最擅长的事——不存在“调用方太多”这回事七、变更纠缠不清时从干净处重新开始原则 8如果某个文件经历了 3 轮以上相互冲突的编辑用git restore恢复它然后只重新应用真正需要的改动。不要试图外科手术式地修补一团乱麻——从干净状态开始更快、更不易出错。八、测试必须断言真实值而不是只断言集合大小原则 9测试去重、归一化、幂等操作时要断言存储后的值不能只写toHaveLength(1)。长度本身证明不了逻辑正确——一个坏掉的归一化器可能静默丢弃一个输入或存下两个恰好匹配的不同归一化形式。标准模式以格式 A 加入值再以格式 B 重复加入然后同时断言“数量为 1”和“存储值等于期望的归一化形式”// Bad: passes even if normalization is broken expect(data.phones).toHaveLength(1) // Good: proves normalization recognized both formats expect(data.phones).toHaveLength(1); expect(data.phones[0]).toBe(12125551234);仓库佐证jevgrep 的 CLI 参数测试apps/cli/test/args.test.ts正是这一原则的正面实践——它断言解析结果的具体值root: -tree、maxSourceBytes: 12、policy: { hidden: true }而不是只检查“解析成功”对于--concurrency它逐项断言非法输入0、-1、1.5、NaN、1e2、超大整数都会抛错。配套的write-tests技能.agents/skills/write-tests/SKILL.md把这条原则扩展为完整的测试方法论并补充了“证明测试能失败falsify once”“断言设计契约而非当前行为”等进阶要求。九、无薄封装、无纯转发的模块原则 10如果一个模块只是转发另一个包的函数或类型删除它直接导入原包。不要为脚手架代码或未发布的 branch 工作保留本地兼容垫片。纯export * from ...的 barrel 文件没有价值除非它定义了带项目语义的真实公共边界。优先直接使用上游 API 名而不是发明discoverAll()这类本地别名去包装loadSkills()。十、只在真实所有权边界处抽取模块原则 11不要为了减少行数而拆分文件。一个新文件应当拥有读者能命名的一个连贯职责当模块集中了相关策略、状态转换、资源处理或领域特定行为时才抽取模块如果抽取增加了总体间接层却没有厘清所有权就让代码保持本地化好的拆分通常能降低原文件的导入压力因为依赖随职责一起迁移了refactor-clean技能对此的补充是约 1000 行以上是一个“气味”而非判决——内聚的状态机、生成表、单一算法可以合理地大但注册了大量路由、内联处理多个领域的 god-file 就是责任堆积。拆分的对错标准是“每个新模块拥有一个可命名的职责且导入压力下降”而不是“行数变少了”。十一、测试与实现解耦端到端驱动系统原则 12这是文档中篇幅最长、分量最重的一条原则核心论点最有价值的测试套件是与它所覆盖的实现最解耦的那套——解耦到“通过驱动前端来锻炼后端、通过用户走的同一入口来锻炼模块”的程度。戳内部实现的测试冻结了内部驱动公共表面的测试让你可以自由重构底层一切。具体的操作准则优先最外层入口点仍能给出快速、确定性信号的CLI 二进制 顶层导出函数 内部 helper 私有方法。用户调用的是 CLI就对着 CLI 写测试用户看到的是 TUI就通过真实按键命中的同一输入管线驱动它断言渲染出的帧而不是中间状态测试行为而非结构断言可观察结果——退出码、stdout、渲染输出、磁盘上的文件、HTTP 响应、持久化的行。不要断言“哪些函数被调用、什么顺序、什么中间形状”通过的测试应意味着真实用户得到正确结果如果测试在生产路径损坏时仍然通过测试就接错了线。常见气味stub 被测对象本身、绕过 router/dispatcher/parser、手工构造生产环境本来会从输入构建的内部事件测试装置必须按生产环境的接法接线生产中总是设置的输入已定型的 status 流、modal 配置、同样的环境变量属于契约的一部分装置里也要传入等价物。如果你只在真实环境里才能复现某个 bug说明装置跳过了生产环境设置的某个输入——修装置让下一轮同类回归由测试套件捕获而不是由用户捕获耦合的测试是重构税重命名一个内部函数或移动模块导致几十个测试失败、却没有改变任何用户可见行为说明套件测错了层。把那些测试改写到外层表面删掉脆弱的单元测试只留给真正棘手的纯逻辑解析器、归一化器、调度器、带微妙不变量的状态机。其他一切都值得写成集成或端到端测试仓库佐证args.test.ts完全符合“驱动最外层入口点”的要求——它不直接调用内部函数而是对parseCommandCLI 参数解析的公开入口传入用户会敲的原始参数数组[find behavior, --hidden, --no-cache, --max-source-bytes, 12, --, -tree]断言可观察的解析结果与错误行为。十二、失败的检查可能是工具链缺陷而非代码缺陷原则 13在手写类型、加 cast、钉住值、重构代码去让检查器类型检查器、编译器、linter、测试运行器、构建通过之前先确认失败是代码缺陷还是工具链/环境产物。为迎合损坏或不匹配的工具而改代码是掩盖真实问题的 workaround——这是“绝不压制信号”规则的上层延伸。可执行的三条纪律在报告失败的同一工具链下复现——CI/部署的版本和配置而不是只复现本地的。本地全绿什么也证明不了pinned 的预发布版、preview 构建、本机与 CI 之间的版本漂移都可能在相同源码上本地通过、CI 失败或相反如果相同源码在真实/pinned 工具下通过代码就是正确的——修复应落在工具链钉版本、修配置而不是代码。输出有歧义时直接探测工具强制它打印实际计算出的值、类型或错误而不是猜原因保持本地 CI确认把关合并/部署的检查跑的是与部署相同的工具链。版本漂移会让每一个绿色检查都存疑“本地能过”就不再是部署能过的证据十三、身份来自认证绝不来自调用方原则 14行动者身份——org/tenant/workspace id、user id、actor——必须从认证请求API key、session 或验证过的内部 key解析绝不能从调用方提供的参数取得。一个从 args 里读actorId/orgId的公共 mutation 是伪造面spoofing surface不是功能唯一例外是可信内部调用只有当存在有效内部 key 时才接受调用方提供的 actor否则从认证推导身份并拒绝提供的 id要限定到认证范围内的子对象特定 channel、share、app时取子id 并验证它属于认证推导出的父级——不要相信 body 里并行的父 id十四、公共 API 动作 薄认证 分发不内联业务逻辑原则 15公共路由的职责是认证、校验、推导身份、分发给持有工作的模型函数或内部动作。保持这个包装薄——它是认证/运行时边界。不要把第三方 SDK / 分析 / 邮件逻辑内联进公共边界哪怕“只有 3 行”也要推到分发后面。文档特别给出了 Convex 的实践不要为了满足一个 action 就给文件加use node——那会把文件里所有 action 都推进 Node 运行时。正确做法是拆分authdispatch默认运行时→services/thing.tsuse node拥有 SDK 调用。十五、公共端点以最小范围发布原则 16一条路由、一次请求一个条目。不要在出现具体的第二个调用方之前就预先加/batch变体、分页列表或过滤参数。把 schema 内联在路由里不要把 4 行的 schema 抬到共享的schemas.ts“以备复用”——没人复用时就没有复用。除非 body 真的无界否则跳过 body 大小上限。十六、复用既有类型派生而非重声明原则 17如果类型已在上游存在schema 校验器、协议包、生成的 client、SDK直接使用它——不要内联重声明它的形状哪怕只是部分。重声明的形状会漂移。变体用派生// Bad: redeclares a shape that already exists upstream type UserSummary { id: string; name: string; email: string } // Good: derive from the existing type type UserSummary PickUser, id | name | emailConvex/Zod 等价物Infertypeof V、FunctionArgstypeof api.x.y、z.input/z.output。原则 22 将这条扩展为更宽的一般规则必须保持一致的东西需要一个所有者。两个声明各自可以独立变化却又必须保持一致时它们会漂移——把共享决策放在一个家让每个使用点从它组合。平行的 enum、picker 列表、复述别处集合的 switch 都是常见病灶。更难的一半当近亲确实合理地不同时把差异理由写进代码——未记录的差异与漂移 bug 无法区分读者分辨不出意图与疏忽。十七、在索引处过滤绝不take()后过滤原则 18当列表查询要从表的子桶返回行active vs. archived、status X时索引必须完成过滤。不要.take(N)未过滤的查询再在 JS 里.filter()你想要的桶。为什么它坏.take(N)返回索引顺序头部 N 行。如果头部全是另一个桶的行post-filter 即使桶里有几百行更老的行也会返回零。take(N*2)只是推迟失败。正确模式把判别字段放进索引用.withIndex(..., q q.eq(...))或用q.gt(field, 0)表示“存在”桶Convex 把undefined排在已定义值之前。.first()/.unique()与“是否存在任何 X”探测同理。十八、绝不.collect()——用.take(N)限定读取原则 19Convex 的.collect()无上限地读取每个匹配行。对任何按租户随时间累积的东西sessions、events、ledger 行、audit 行第一天还很小的查询最终会在一次 reactive tick 上拉取数千行悄然拖垮整个客户端的响应性。用.take(N)替换.collect()N 是明显高于今天工作集的安全上限100、1000——这是对抗病态数据的 cap不是 UX 分页器。.withIndex(...).filter(...).collect()同理如果确实需要每一行迁移、管理端导出、一次性维护用注释说明并从可取消的 mutation/action运行绝不在 reactivequery里跑十九、不要仅为重命名或补默认值而 map 重映射行原则 20逐字段复制、只为改两个名字或合并undefined → false的对象字面量.map()是噪音而且新加的列会静默丢失直到有人更新 map。如果消费者需要全部字段直接返回行只要子集用Pick/Omit或解构-剩余。只有新名字确实澄清含义时才重命名只有下游确实无法处理缺失时才补默认。存储专用字段_id、_creationTime、内部 id用一次解构-剩余剥掉return rows.map(({ _id, _creationTime, ...row }) row);二十、内部 API 不携带版本或兼容机制原则 21当生产者和消费者都是我们自己自有 apps、services、functions时不要加protocolVersion字段、版本协商、能力标志或“以防对方更旧”的分支。部署就是版本Deploying is the version。唯一真实的兼容轴是字段而非版本——而且它是不对称的不是一个旋钮严格解析请求拒绝未知字段宽容解析响应/事件忽略未知字段这让生产者可以增加字段而无需消费者同步发版覆盖了我们实际存在的唯一倾斜组件各自按自己的节奏更新。气味清单线上 schema 里没人读的版本字面量if (payload.v 2)分支且唯一调用者是我们自己部署的代码对响应做严格解析——它把每次服务端增量变更都变成破坏性变更。例外真正的外部 API无法重新部署的消费者在路由上版本化/v1/绝不按字段版本化。二十一、批处理循环隔离单项失败——一个坏项不能饿死其余原则 24任何遍历独立工作项的循环sweep、cron 批、队列排空、fleet pass、fanout都必须逐项捕获并继续——把失败收集进结果failed列表或记录日志。未捕获的单项 throw 会中止整轮由于 runnercron、scheduler、sync rail下一 tick 会重新选择同一个有序集合一个确定性失败的项会成为永久队首阻塞它后面的一切永远重新排队而指标却显示任务在“重试”。事务上下文中更糟未捕获的 throw 还会回滚游标/进度写入导致同一页无限重跑。捕获错误能保住事务——但失败项 throw 之前的写入会持久化所以要在写入幂等或可安全重跑的项边界处捕获。只有失败可证明是批级别的共享下游不可达时提前退出才是正确的项级别错误永远不是如果调用方需要失败可见性捕获-记录-继续整轮结束后再抛出第一个错误即使有隔离也要小心排序陷阱如果成功项留在候选集里每次重试把阻塞点前的东西全部重新快照sweep 的选择逻辑也要排除已完成的工作可接受的形式逐项 try/catch 结果中的failed按项键控的Promise.allSettled捕获-记录-继续后抛// Bad: one unreachable VM freezes every candidate behind it, forever for (const ws of candidates) { await archive(ws); await mark(ws) } // Good: the same loop, per-item try/catch pushing { workspaceId, error } onto a failed array二十二、重命名用户可见内容 清扫测试可见的一切原则 25用户可见文案、可访问名称、路由、data-*属性对不在你门禁里的测试层是承重的——live-staging 装置、journey 套件、外部监控。一个让所有本地门禁保持绿色的重命名可能在几小时后于别人的会话里悄然破坏它们。当变更重命名可见文案或重构表面时全仓库 grep 旧字符串/选择器——明确包含 test-harness 和 e2e 包——并在同一轮更新每个锚点。产生重命名的 diff 就是必须清扫的 diff评审测试从 diff 里挑一个被重命名的字符串 grep 全仓库。diff 之外的任何存活命中都是下一次 live 运行前的隐患结构优于文案journey 需要锚点时优先在表面拥有一个data-*属性而不是显示文本——这样产品文案可以自由改动而不碰测试。当 journey 锚定文案而结构属性已存在时标记它二十三、让代码比你发现它时更好——整洁的 diff 不值一个不整洁的仓库原则 26这是一条元原则决定了评审的收尾姿态绝不为了保持 diff 聚焦而回退顺手的改进。如果格式化器、linter 或 codemod 顺带清理了你的变更未触及的文件也要提交噪音大就单独提交。回退它是在优化评审时的阅读体验代价是每个未来的 pass 都要重复付出发现死东西就在这一轮删掉死列、死参数、死函数、死导出、只有测试在调用的测试——连同为它辩护的注释一起删除。不要记笔记笔记只是拖延下一位读者还得重新推导它是死的发现的错误注释是缺陷就地修正修复你的变更暴露出的潜在 bug让很少跑的路径每次跑的工作会暴露排序 bug、不可达的清理、从未触发的断言——那现在是你的 bug因为它因你而变得可达“改进”之前先验证确认东西真的死了、错了、坏了再删或重写——grep 消费者、跑测试。自信地删除承重之物远比你在修的脏乱更糟边界不要把无关的行为变更混进 feature 提交不要因为你讨厌邻居模块的形状就重写它。这条规则覆盖机械整洁、死代码、错误注释、你使其可达的 bug——不是机会主义重设计评审测试这个变更落地后仓库里是否有任何文件比之前更糟或携带已知的错误陈述如果有这一轮就没做完二十四、技能协同在 jevgrep 仓库中的完整交付闭环code-review不是孤立运行的。jevgrep 仓库把代码评审、重构、测试、文档写作组织成一个可编排的技能链技能路径负责的关口refactor-clean.agents/skills/refactor-clean/SKILL.md形状shape让每个概念只有一个清晰的家code-review.agents/skills/code-review/SKILL.mddiff审计已定型的变更write-docs.agents/skills/write-docs/SKILL.md文档更新变更触及的文档并验证链接链write-tests.agents/skills/write-tests/SKILL.md测试钉住真实行为而非实现细节review.agents/skills/review/SKILL.md编排顺序、循环与唯一结论review技能规定形状先于 diff 先于文档——重构便宜时先做refactor-clean审计已定型的形状code-review结构问题会把流程送回第二步而不是继续前进最后更新文档并追踪从根 README 向下的链接链。三个关口全部 clean 或已解决才算 done。而code-review的原则 9、12 与write-tests技能高度共振——后者的“断言可观察行为而非内部函数”“绝不断言编译器已保证的类型”“断言真实值而非集合大小”几乎就是评审原则的测试侧镜像。两条技能可以互为检查清单。二十五、在 jevgrep CLI 中的落地证据本文提到的原则在 jevgrep 自身代码中均有迹可循可作为评审技能的活教材原则 12驱动最外层入口点与原则 9断言真实值——apps/cli/test/args.test.ts 通过parseCommandCLI 的公开参数入口传入用户会键入的原始参数断言完整的解析结果对象包括expect(parseCommand([find behavior, --hidden, --no-cache, --max-source-bytes, 12, --, -tree])).toEqual({ kind: search, query: find behavior, root: -tree, // 连字符开头的 root 通过 -- 分隔 noCache: true, maxSourceBytes: 12, policy: { hidden: true }, });并对非法输入断言抛错的具体信息Unknown option、positive integer而非只检查“抛了错”。原则 5安装/运行分离与原则 10无薄封装——apps/cli/src/skill.ts 中installSkill仅做一件事组装npx skills add dzhng/jevgrep --skill jevgrep参数并派生子进程把安装委托给 skills 安装器运行时搜索逻辑apps/cli/src/args.ts完全不触碰安装细节。原则 7收紧保证——apps/cli/src/args.ts 对--concurrency与--max-source-bytes在解析层就完成全部校验正整数、非负安全整数、0表示无限下游无需再防御非法值auth、doctor、skill、cache clear各命令的参数约束也在同一入口严格收窄如auth只在--stdin且--provider合法时接受 provider。原则 21内部 API 无版本机制——CLI 帮助文本同文件help常量明确“Saved credentials only; provider key/URL environment variables are ignored”认证状态只有一种真实来源不保留环境变量等平行通道。技能的实际使用方式则记录在 skills/jevgrep/SKILL.md及仓库根 .agents/skills/jevgrep/SKILL.mdjg检索输出以 “summary ranked file list → verbatim source excerpts → detailed locations” 的结构呈现End context.标记完整上下文结束——这些输出正是code-review技能评审跨文件变更时“grep 旧引用、追踪消费者”所需的第一手材料。二十六、结语把 26 条原则当作一张可执行的评审 checklistcode-review技能的 26 条原则可以被归纳为四类主题评审时按此顺序过一遍即可覆盖全貌真实性1–4、26名字、引用、注释、代码本身都必须反映当前现实历史留在 git 里边界与所有权5、6、10、11、17、20、21、22、23每个概念一个家不重声明、不薄包装、不预置兼容机制、不过早抽取测试与安全9、12、14、15、16、25驱动公共表面、断言真实值、身份来自认证、公共 API 最小化数据与容错18、19、24索引处过滤、有界读取、批处理隔离单项失败加上两条元纪律——原则 13区分代码缺陷与工具链缺陷与原则 7绝不压制信号——以及文档规定的输出协议引用文件与行号、按类别分组、以 clean/not-clean 收尾这套技能就可以作为任何编码 Agent 的提交前自动评审关卡在 jevgrep 这类由 Agent 驱动迭代的仓库中与review、refactor-clean、write-tests组成完整的交付闭环。赞分享【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址https://gitcode.com/gh_mirrors/je/jevgrep点击查看免费下载相关推荐IsaacLab 容器化部署实战Docker 快速搭建可复现的机器人学习仿真环境IsaacLab 容器化部署实战Docker 快速搭建可复现的机器人学习仿真环境 IsaacLab 是 NVIDIA 推出的统一机器人学习仿真框架一个仓库同人工智能强化学习机器人具身智能深度学习WeChatMsg 微信聊天记录导出三条命令留档WeChatMsg 微信聊天记录导出三条命令留档 清理完缓存2021 年那段对话再也搜不到。WeChatMsg 做的就是微信聊天记录导出直接读取本机微信数Capa 与 YARA 选型实战恶意软件分析工具怎么选、怎么搭配Capa 与 YARA 选型实战恶意软件分析工具怎么选、怎么搭配 如果你手上同时有批量样本和少量重点样本Capa 与 YARA 的分工会直接决定你的分析节奏网络安全应用安全创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址https://gitcode.com/gh_mirrors/je/jevgrep点击查看免费下载导读本文以 jevgrep 仓库内置的.agents/skills/code-review/SKILL.md文档为主体系统讲解其面向 AI 编码 Agent 的代码评审方法论26 条可执行的评审原则覆盖命名、注释、模块边界、测试质量、认证安全、批处理容错等主题以及“Review → 分组引用行号 → clean/not-clean 结论”的评审流程。读完本文你将掌握一套可直接交付给 Agent 的评审 checklist并了解该技能在 jevgrep 仓库中如何与review、refactor-clean、write-tests等技能协同工作以及仓库源码中的对应实现证据。一、技能定位何时触发、用哪些工具该文档的元信息frontmatter界定了技能的使用边界名称namecode-review描述description用于评审已变更代码的命名、过期引用、不必要的复杂度与注释质量应在完成实现工作之后、提交之前或用户要求审查/审计代码时使用允许工具allowed-toolsRead Grep Glob Bash——评审者只被允许读取文件、搜索引用、按模式查找文件和执行 shell 命令不需要也不应修改代码这与 README 中“仓库是只读”的定位一致code-review是审查者产出的是带行号的分组问题清单与最终结论而不是改动本身。修改工作交给refactor-clean形状与implement-spec等实现类技能。二、评审流程与输出契约文档末尾的Your task定义了评审的硬性执行协议输入Review: $ARGUMENTS——若未给出参数则默认评审git diff --staged暂存区或git diff未暂存改动输出要求每个发现的问题必须引用文件和行号cite the file and line number按类别分组Group by category以clean/not-clean的明确结论收尾这个协议保证了评审结果可回溯、可复核。jevgrep 仓库中review技能.agents/skills/review/SKILL.md进一步说明了code-review在整个交付流程中的位置一个完成的变更要经历三道关口——形状shape由refactor-clean负责、diffdiff由code-review负责、文档docs由write-docs负责code-review发现的问题若迫使结构性改动必须回到refactor-clean重新执行而不是带病前进。三、命名与引用的真实性原则 1–33.1 名字必须反映当前现实变量名和函数名应描述它们现在是什么what they ARE而不是曾经是什么。当底层机制发生变化文档举例FUSE → NFS所有相关命名都必须同步更新。评审时问自己一个新读者会被这个名字误导吗3.2 不允许存在过期引用重构之后必须用 grep 搜索对旧方案的引用——遗留的检测逻辑、废弃的功能开关、提到已删除代码的注释。如果某个方案“试过又回退了”就要清除全部痕迹代码库应该看起来“当前方案从一开始就是计划”。3.3 检测逻辑只保留真正必要的一个判断“这个功能能否运行”这类 gate 应当只检查真正关键的那一个条件。不要串联回退式检测binary 存在 OR 源码存在 OR 工具链存在当其中一项检查已能覆盖全部时其余都是噪音。仓库佐证code-review强调的“删除过期路径”在仓库的refactor-clean技能.agents/skills/refactor-clean/SKILL.md中被进一步放大为“零谱系命名”Zero lineage signaling——名字编码历史foo-v2、foo-legacy、以实验命名模块对后来的读者毫无信息量历史应该留在 git 里而不是留在标识符里。四、注释只写 WHY不写发生过什么原则 4注释质量是评审的核心维度之一文档给出了明确的正反清单保留Keep——非显而易见的发现、平台怪癖、“如果删掉这行X 会因 Y 而坏”// com.apple.provenance causes SIGKILL when spawned as child process // umount while server is alive panics the macOS NFS client // NFS client uses cookie verifier to decide if cached readdir is valid删除Remove试过什么、放弃什么、改过什么名字的叙事// We changed this from cp to cat to work around the provenance issue// Wrapper added because FUSE-T was zero-padding (see commit abc123)// Previously this was called fuseAvailable but we renamed it只是复述代码行为、不补充推理的注释很多时候根本不需要注释Often no comment is needed at all原则 26 补充了一条硬规则发现的错误注释本身就是缺陷A comment you discover is false is a defect必须当场修正——错误的注释比没有注释更危险因为它会误导所有后来的读者。五、安装期与运行期分离、消灭中间产物原则 5–6安装脚本负责准备前置条件工具链、系统依赖运行时命令负责编译、缓存、二进制管理。两者不得混用——如果安装脚本在编译运行时也要编译的二进制那么两者必有一方是错的。在多轮方案迭代后要审计是否存在“只是垫脚石”的逻辑为方案 A 加的 workaround切到方案 B 后必须删除即使它无害。代码应读起来像是一个早知道正确答案的人从零写出来的。这条原则在 jevgrep 的 CLI 中有直接体现jg skill命令apps/cli/src/skill.ts把“安装技能”这个职责严格放在安装路径上——它通过npx skills add dzhng/jevgrep --skill jevgrep委托给外部 skills 安装器而不是在jg运行时逻辑中内联任何安装细节搜索运行时则完全不触碰安装相关代码。六、变更之后收紧保证原则 7当某个变更让原本“可能”的事情变成“必然”变量总是被赋值、文件总是被创建、函数总是返回必须审计下游代码中仍然防御旧“可能态”的守卫冗余的空值检查、回退默认值、对不可能再为 null 的值做if (x)守卫——它们暗示着不存在的可能性是误导不再需要重新赋值时优先const而不是let绝不压制信号要修复根因_前缀的未用参数、// ts-ignore、eslint-disable、as any都在掩盖真实问题。参数不用就 DELETE并把删除级联到所有调用方类型不匹配就修类型。运行检查器、修掉每个错误、重复此过程。跨多文件的机械改动正是 Agent 最擅长的事——不存在“调用方太多”这回事七、变更纠缠不清时从干净处重新开始原则 8如果某个文件经历了 3 轮以上相互冲突的编辑用git restore恢复它然后只重新应用真正需要的改动。不要试图外科手术式地修补一团乱麻——从干净状态开始更快、更不易出错。八、测试必须断言真实值而不是只断言集合大小原则 9测试去重、归一化、幂等操作时要断言存储后的值不能只写toHaveLength(1)。长度本身证明不了逻辑正确——一个坏掉的归一化器可能静默丢弃一个输入或存下两个恰好匹配的不同归一化形式。标准模式以格式 A 加入值再以格式 B 重复加入然后同时断言“数量为 1”和“存储值等于期望的归一化形式”// Bad: passes even if normalization is broken expect(data.phones).toHaveLength(1) // Good: proves normalization recognized both formats expect(data.phones).toHaveLength(1); expect(data.phones[0]).toBe(12125551234);仓库佐证jevgrep 的 CLI 参数测试apps/cli/test/args.test.ts正是这一原则的正面实践——它断言解析结果的具体值root: -tree、maxSourceBytes: 12、policy: { hidden: true }而不是只检查“解析成功”对于--concurrency它逐项断言非法输入0、-1、1.5、NaN、1e2、超大整数都会抛错。配套的write-tests技能.agents/skills/write-tests/SKILL.md把这条原则扩展为完整的测试方法论并补充了“证明测试能失败falsify once”“断言设计契约而非当前行为”等进阶要求。九、无薄封装、无纯转发的模块原则 10如果一个模块只是转发另一个包的函数或类型删除它直接导入原包。不要为脚手架代码或未发布的 branch 工作保留本地兼容垫片。纯export * from ...的 barrel 文件没有价值除非它定义了带项目语义的真实公共边界。优先直接使用上游 API 名而不是发明discoverAll()这类本地别名去包装loadSkills()。十、只在真实所有权边界处抽取模块原则 11不要为了减少行数而拆分文件。一个新文件应当拥有读者能命名的一个连贯职责当模块集中了相关策略、状态转换、资源处理或领域特定行为时才抽取模块如果抽取增加了总体间接层却没有厘清所有权就让代码保持本地化好的拆分通常能降低原文件的导入压力因为依赖随职责一起迁移了refactor-clean技能对此的补充是约 1000 行以上是一个“气味”而非判决——内聚的状态机、生成表、单一算法可以合理地大但注册了大量路由、内联处理多个领域的 god-file 就是责任堆积。拆分的对错标准是“每个新模块拥有一个可命名的职责且导入压力下降”而不是“行数变少了”。十一、测试与实现解耦端到端驱动系统原则 12这是文档中篇幅最长、分量最重的一条原则核心论点最有价值的测试套件是与它所覆盖的实现最解耦的那套——解耦到“通过驱动前端来锻炼后端、通过用户走的同一入口来锻炼模块”的程度。戳内部实现的测试冻结了内部驱动公共表面的测试让你可以自由重构底层一切。具体的操作准则优先最外层入口点仍能给出快速、确定性信号的CLI 二进制 顶层导出函数 内部 helper 私有方法。用户调用的是 CLI就对着 CLI 写测试用户看到的是 TUI就通过真实按键命中的同一输入管线驱动它断言渲染出的帧而不是中间状态测试行为而非结构断言可观察结果——退出码、stdout、渲染输出、磁盘上的文件、HTTP 响应、持久化的行。不要断言“哪些函数被调用、什么顺序、什么中间形状”通过的测试应意味着真实用户得到正确结果如果测试在生产路径损坏时仍然通过测试就接错了线。常见气味stub 被测对象本身、绕过 router/dispatcher/parser、手工构造生产环境本来会从输入构建的内部事件测试装置必须按生产环境的接法接线生产中总是设置的输入已定型的 status 流、modal 配置、同样的环境变量属于契约的一部分装置里也要传入等价物。如果你只在真实环境里才能复现某个 bug说明装置跳过了生产环境设置的某个输入——修装置让下一轮同类回归由测试套件捕获而不是由用户捕获耦合的测试是重构税重命名一个内部函数或移动模块导致几十个测试失败、却没有改变任何用户可见行为说明套件测错了层。把那些测试改写到外层表面删掉脆弱的单元测试只留给真正棘手的纯逻辑解析器、归一化器、调度器、带微妙不变量的状态机。其他一切都值得写成集成或端到端测试仓库佐证args.test.ts完全符合“驱动最外层入口点”的要求——它不直接调用内部函数而是对parseCommandCLI 参数解析的公开入口传入用户会敲的原始参数数组[find behavior, --hidden, --no-cache, --max-source-bytes, 12, --, -tree]断言可观察的解析结果与错误行为。十二、失败的检查可能是工具链缺陷而非代码缺陷原则 13在手写类型、加 cast、钉住值、重构代码去让检查器类型检查器、编译器、linter、测试运行器、构建通过之前先确认失败是代码缺陷还是工具链/环境产物。为迎合损坏或不匹配的工具而改代码是掩盖真实问题的 workaround——这是“绝不压制信号”规则的上层延伸。可执行的三条纪律在报告失败的同一工具链下复现——CI/部署的版本和配置而不是只复现本地的。本地全绿什么也证明不了pinned 的预发布版、preview 构建、本机与 CI 之间的版本漂移都可能在相同源码上本地通过、CI 失败或相反如果相同源码在真实/pinned 工具下通过代码就是正确的——修复应落在工具链钉版本、修配置而不是代码。输出有歧义时直接探测工具强制它打印实际计算出的值、类型或错误而不是猜原因保持本地 CI确认把关合并/部署的检查跑的是与部署相同的工具链。版本漂移会让每一个绿色检查都存疑“本地能过”就不再是部署能过的证据十三、身份来自认证绝不来自调用方原则 14行动者身份——org/tenant/workspace id、user id、actor——必须从认证请求API key、session 或验证过的内部 key解析绝不能从调用方提供的参数取得。一个从 args 里读actorId/orgId的公共 mutation 是伪造面spoofing surface不是功能唯一例外是可信内部调用只有当存在有效内部 key 时才接受调用方提供的 actor否则从认证推导身份并拒绝提供的 id要限定到认证范围内的子对象特定 channel、share、app时取子id 并验证它属于认证推导出的父级——不要相信 body 里并行的父 id十四、公共 API 动作 薄认证 分发不内联业务逻辑原则 15公共路由的职责是认证、校验、推导身份、分发给持有工作的模型函数或内部动作。保持这个包装薄——它是认证/运行时边界。不要把第三方 SDK / 分析 / 邮件逻辑内联进公共边界哪怕“只有 3 行”也要推到分发后面。文档特别给出了 Convex 的实践不要为了满足一个 action 就给文件加use node——那会把文件里所有 action 都推进 Node 运行时。正确做法是拆分authdispatch默认运行时→services/thing.tsuse node拥有 SDK 调用。十五、公共端点以最小范围发布原则 16一条路由、一次请求一个条目。不要在出现具体的第二个调用方之前就预先加/batch变体、分页列表或过滤参数。把 schema 内联在路由里不要把 4 行的 schema 抬到共享的schemas.ts“以备复用”——没人复用时就没有复用。除非 body 真的无界否则跳过 body 大小上限。十六、复用既有类型派生而非重声明原则 17如果类型已在上游存在schema 校验器、协议包、生成的 client、SDK直接使用它——不要内联重声明它的形状哪怕只是部分。重声明的形状会漂移。变体用派生// Bad: redeclares a shape that already exists upstream type UserSummary { id: string; name: string; email: string } // Good: derive from the existing type type UserSummary PickUser, id | name | emailConvex/Zod 等价物Infertypeof V、FunctionArgstypeof api.x.y、z.input/z.output。原则 22 将这条扩展为更宽的一般规则必须保持一致的东西需要一个所有者。两个声明各自可以独立变化却又必须保持一致时它们会漂移——把共享决策放在一个家让每个使用点从它组合。平行的 enum、picker 列表、复述别处集合的 switch 都是常见病灶。更难的一半当近亲确实合理地不同时把差异理由写进代码——未记录的差异与漂移 bug 无法区分读者分辨不出意图与疏忽。十七、在索引处过滤绝不take()后过滤原则 18当列表查询要从表的子桶返回行active vs. archived、status X时索引必须完成过滤。不要.take(N)未过滤的查询再在 JS 里.filter()你想要的桶。为什么它坏.take(N)返回索引顺序头部 N 行。如果头部全是另一个桶的行post-filter 即使桶里有几百行更老的行也会返回零。take(N*2)只是推迟失败。正确模式把判别字段放进索引用.withIndex(..., q q.eq(...))或用q.gt(field, 0)表示“存在”桶Convex 把undefined排在已定义值之前。.first()/.unique()与“是否存在任何 X”探测同理。十八、绝不.collect()——用.take(N)限定读取原则 19Convex 的.collect()无上限地读取每个匹配行。对任何按租户随时间累积的东西sessions、events、ledger 行、audit 行第一天还很小的查询最终会在一次 reactive tick 上拉取数千行悄然拖垮整个客户端的响应性。用.take(N)替换.collect()N 是明显高于今天工作集的安全上限100、1000——这是对抗病态数据的 cap不是 UX 分页器。.withIndex(...).filter(...).collect()同理如果确实需要每一行迁移、管理端导出、一次性维护用注释说明并从可取消的 mutation/action运行绝不在 reactivequery里跑十九、不要仅为重命名或补默认值而 map 重映射行原则 20逐字段复制、只为改两个名字或合并undefined → false的对象字面量.map()是噪音而且新加的列会静默丢失直到有人更新 map。如果消费者需要全部字段直接返回行只要子集用Pick/Omit或解构-剩余。只有新名字确实澄清含义时才重命名只有下游确实无法处理缺失时才补默认。存储专用字段_id、_creationTime、内部 id用一次解构-剩余剥掉return rows.map(({ _id, _creationTime, ...row }) row);二十、内部 API 不携带版本或兼容机制原则 21当生产者和消费者都是我们自己自有 apps、services、functions时不要加protocolVersion字段、版本协商、能力标志或“以防对方更旧”的分支。部署就是版本Deploying is the version。唯一真实的兼容轴是字段而非版本——而且它是不对称的不是一个旋钮严格解析请求拒绝未知字段宽容解析响应/事件忽略未知字段这让生产者可以增加字段而无需消费者同步发版覆盖了我们实际存在的唯一倾斜组件各自按自己的节奏更新。气味清单线上 schema 里没人读的版本字面量if (payload.v 2)分支且唯一调用者是我们自己部署的代码对响应做严格解析——它把每次服务端增量变更都变成破坏性变更。例外真正的外部 API无法重新部署的消费者在路由上版本化/v1/绝不按字段版本化。二十一、批处理循环隔离单项失败——一个坏项不能饿死其余原则 24任何遍历独立工作项的循环sweep、cron 批、队列排空、fleet pass、fanout都必须逐项捕获并继续——把失败收集进结果failed列表或记录日志。未捕获的单项 throw 会中止整轮由于 runnercron、scheduler、sync rail下一 tick 会重新选择同一个有序集合一个确定性失败的项会成为永久队首阻塞它后面的一切永远重新排队而指标却显示任务在“重试”。事务上下文中更糟未捕获的 throw 还会回滚游标/进度写入导致同一页无限重跑。捕获错误能保住事务——但失败项 throw 之前的写入会持久化所以要在写入幂等或可安全重跑的项边界处捕获。只有失败可证明是批级别的共享下游不可达时提前退出才是正确的项级别错误永远不是如果调用方需要失败可见性捕获-记录-继续整轮结束后再抛出第一个错误即使有隔离也要小心排序陷阱如果成功项留在候选集里每次重试把阻塞点前的东西全部重新快照sweep 的选择逻辑也要排除已完成的工作可接受的形式逐项 try/catch 结果中的failed按项键控的Promise.allSettled捕获-记录-继续后抛// Bad: one unreachable VM freezes every candidate behind it, forever for (const ws of candidates) { await archive(ws); await mark(ws) } // Good: the same loop, per-item try/catch pushing { workspaceId, error } onto a failed array二十二、重命名用户可见内容 清扫测试可见的一切原则 25用户可见文案、可访问名称、路由、data-*属性对不在你门禁里的测试层是承重的——live-staging 装置、journey 套件、外部监控。一个让所有本地门禁保持绿色的重命名可能在几小时后于别人的会话里悄然破坏它们。当变更重命名可见文案或重构表面时全仓库 grep 旧字符串/选择器——明确包含 test-harness 和 e2e 包——并在同一轮更新每个锚点。产生重命名的 diff 就是必须清扫的 diff评审测试从 diff 里挑一个被重命名的字符串 grep 全仓库。diff 之外的任何存活命中都是下一次 live 运行前的隐患结构优于文案journey 需要锚点时优先在表面拥有一个data-*属性而不是显示文本——这样产品文案可以自由改动而不碰测试。当 journey 锚定文案而结构属性已存在时标记它二十三、让代码比你发现它时更好——整洁的 diff 不值一个不整洁的仓库原则 26这是一条元原则决定了评审的收尾姿态绝不为了保持 diff 聚焦而回退顺手的改进。如果格式化器、linter 或 codemod 顺带清理了你的变更未触及的文件也要提交噪音大就单独提交。回退它是在优化评审时的阅读体验代价是每个未来的 pass 都要重复付出发现死东西就在这一轮删掉死列、死参数、死函数、死导出、只有测试在调用的测试——连同为它辩护的注释一起删除。不要记笔记笔记只是拖延下一位读者还得重新推导它是死的发现的错误注释是缺陷就地修正修复你的变更暴露出的潜在 bug让很少跑的路径每次跑的工作会暴露排序 bug、不可达的清理、从未触发的断言——那现在是你的 bug因为它因你而变得可达“改进”之前先验证确认东西真的死了、错了、坏了再删或重写——grep 消费者、跑测试。自信地删除承重之物远比你在修的脏乱更糟边界不要把无关的行为变更混进 feature 提交不要因为你讨厌邻居模块的形状就重写它。这条规则覆盖机械整洁、死代码、错误注释、你使其可达的 bug——不是机会主义重设计评审测试这个变更落地后仓库里是否有任何文件比之前更糟或携带已知的错误陈述如果有这一轮就没做完二十四、技能协同在 jevgrep 仓库中的完整交付闭环code-review不是孤立运行的。jevgrep 仓库把代码评审、重构、测试、文档写作组织成一个可编排的技能链技能路径负责的关口refactor-clean.agents/skills/refactor-clean/SKILL.md形状shape让每个概念只有一个清晰的家code-review.agents/skills/code-review/SKILL.mddiff审计已定型的变更write-docs.agents/skills/write-docs/SKILL.md文档更新变更触及的文档并验证链接链write-tests.agents/skills/write-tests/SKILL.md测试钉住真实行为而非实现细节review.agents/skills/review/SKILL.md编排顺序、循环与唯一结论review技能规定形状先于 diff 先于文档——重构便宜时先做refactor-clean审计已定型的形状code-review结构问题会把流程送回第二步而不是继续前进最后更新文档并追踪从根 README 向下的链接链。三个关口全部 clean 或已解决才算 done。而code-review的原则 9、12 与write-tests技能高度共振——后者的“断言可观察行为而非内部函数”“绝不断言编译器已保证的类型”“断言真实值而非集合大小”几乎就是评审原则的测试侧镜像。两条技能可以互为检查清单。二十五、在 jevgrep CLI 中的落地证据本文提到的原则在 jevgrep 自身代码中均有迹可循可作为评审技能的活教材原则 12驱动最外层入口点与原则 9断言真实值——apps/cli/test/args.test.ts 通过parseCommandCLI 的公开参数入口传入用户会键入的原始参数断言完整的解析结果对象包括expect(parseCommand([find behavior, --hidden, --no-cache, --max-source-bytes, 12, --, -tree])).toEqual({ kind: search, query: find behavior, root: -tree, // 连字符开头的 root 通过 -- 分隔 noCache: true, maxSourceBytes: 12, policy: { hidden: true }, });并对非法输入断言抛错的具体信息Unknown option、positive integer而非只检查“抛了错”。原则 5安装/运行分离与原则 10无薄封装——apps/cli/src/skill.ts 中installSkill仅做一件事组装npx skills add dzhng/jevgrep --skill jevgrep参数并派生子进程把安装委托给 skills 安装器运行时搜索逻辑apps/cli/src/args.ts完全不触碰安装细节。原则 7收紧保证——apps/cli/src/args.ts 对--concurrency与--max-source-bytes在解析层就完成全部校验正整数、非负安全整数、0表示无限下游无需再防御非法值auth、doctor、skill、cache clear各命令的参数约束也在同一入口严格收窄如auth只在--stdin且--provider合法时接受 provider。原则 21内部 API 无版本机制——CLI 帮助文本同文件help常量明确“Saved credentials only; provider key/URL environment variables are ignored”认证状态只有一种真实来源不保留环境变量等平行通道。技能的实际使用方式则记录在 skills/jevgrep/SKILL.md及仓库根 .agents/skills/jevgrep/SKILL.mdjg检索输出以 “summary ranked file list → verbatim source excerpts → detailed locations” 的结构呈现End context.标记完整上下文结束——这些输出正是code-review技能评审跨文件变更时“grep 旧引用、追踪消费者”所需的第一手材料。二十六、结语把 26 条原则当作一张可执行的评审 checklistcode-review技能的 26 条原则可以被归纳为四类主题评审时按此顺序过一遍即可覆盖全貌真实性1–4、26名字、引用、注释、代码本身都必须反映当前现实历史留在 git 里边界与所有权5、6、10、11、17、20、21、22、23每个概念一个家不重声明、不薄包装、不预置兼容机制、不过早抽取测试与安全9、12、14、15、16、25驱动公共表面、断言真实值、身份来自认证、公共 API 最小化数据与容错18、19、24索引处过滤、有界读取、批处理隔离单项失败加上两条元纪律——原则 13区分代码缺陷与工具链缺陷与原则 7绝不压制信号——以及文档规定的输出协议引用文件与行号、按类别分组、以 clean/not-clean 收尾这套技能就可以作为任何编码 Agent 的提交前自动评审关卡在 jevgrep 这类由 Agent 驱动迭代的仓库中与review、refactor-clean、write-tests组成完整的交付闭环。赞分享【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址https://gitcode.com/gh_mirrors/je/jevgrep点击查看免费下载相关推荐IsaacLab 容器化部署实战Docker 快速搭建可复现的机器人学习仿真环境IsaacLab 容器化部署实战Docker 快速搭建可复现的机器人学习仿真环境 IsaacLab 是 NVIDIA 推出的统一机器人学习仿真框架一个仓库同人工智能强化学习机器人具身智能深度学习WeChatMsg 微信聊天记录导出三条命令留档WeChatMsg 微信聊天记录导出三条命令留档 清理完缓存2021 年那段对话再也搜不到。WeChatMsg 做的就是微信聊天记录导出直接读取本机微信数Capa 与 YARA 选型实战恶意软件分析工具怎么选、怎么搭配Capa 与 YARA 选型实战恶意软件分析工具怎么选、怎么搭配 如果你手上同时有批量样本和少量重点样本Capa 与 YARA 的分工会直接决定你的分析节奏网络安全应用安全创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
