GenericAgent Review Mode SOP 实战解析用 /review 拉起会话内对抗性代码评审【免费下载链接】GenericAgentSelf-evolving agent: grows skill tree from 3.3K-line seed, achieving full system control with 6x less token consumption项目地址: https://gitcode.com/GitHub_Trending/pc/GenericAgent本文基于 GenericAgent 仓库的 memory/review_sop.md 及其配套实现系统讲解内置的/review命令与 Review Mode SOP一套运行在当前对话上下文中的对抗性代码评审协议。读完你将掌握该评审模式的触发方式、五步工作流、P0~P3 严重度分级、Verdict 决议规则、防误报八规则与措辞八规范并理解其不开 subagent / 不落盘 / 不打 sentinel的会话内设计在源码层面是如何落地实现的。一、Review Mode 是什么会话内对抗性评审GenericAgent 的 Review Mode评审模式是一个in-session adversarial code reviewer当你在对话中发起评审时主 agent 不切换到独立 subagent而是在当前对话内直接拉起评审流程审阅报告直接 echo 到对话作为给用户的最终回答。它的三个关键设计约束见 review_sop.md 顶部引言不开 subagent评审复用当前 session 的上下文不额外拉起子 agent不落盘报告不写review.md文件不产生磁盘产物不打 sentinel报告末尾不打印[ROUND END]标记。这条设计在源码中有明确佐证。主 agent 的正常输出路径会在文件末尾写入[ROUND END]见 agentmain.py而评审模式的 stub 兜底 prompt 里明确写着不要写 review.md不要打 [ROUND END]见 review_cmd.pyreview_inline_prompt.txt的角色与边界一节也重复强调这一约束。典型使用场景作者刚写完一段代码 → 输入/review→ 主 agent 对自己的改动做对抗性 review即审即得不污染工作区。二、何时使用与快速启动触发条件用户输入/review命令或自然语言要求 code review 时启用。快速启动命令表命令行为/review默认审本次 uncommitted 改动主 agent 跑git diff --stat HEADgit diff HEAD/review 自然语言请求按描述的范围去审可指定文件 / 目录 / 任务/review help显示用法/review help的用法文本由 review_cmd.py 的_help_text()生成其中给出的示例包括/review—— 默认审本次 uncommitted 改动/review 我刚改了 review_cmd.py 和 tuiapp_v2.py关注 prompt 注入—— 按任务范围审/review 审 frontends 目录下所有改过的文件—— 按目录范围审非 git 仓库若当前目录不是 git 仓库主 agent 会提示用户在下一句/review塞入具体路径或范围本轮结束。三、入口文件与命令分发链路任意前端 (TUI / Streamlit / wechat / desktop) └─ frontends/review_cmd.py ← 命令分发剥 /review 前缀注入 user_request └─ memory/review_sop/review_inline_prompt.txt ← 完整 in-session 协议 └─ memory/code_review_principles.md ← 15 条好代码原则分发实现monkey-patch 统一接管frontends/review_cmd.py 是/review的唯一命令入口核心是两个函数install()review_cmd.pymonkey-patchGenericAgent._handle_slash_cmd统一接管/review。patch 逻辑按原始输入精确匹配/review或/review //review\t前缀其余命令原样交给原始分发函数patched._review_patched True标记保证 patch 幂等重复 install 不会叠加。handle()review_cmd.py接收已剥离/review前缀的纯参数文本处理help/?/-h/--help后直接推送帮助文本否则把参数注入 inline prompt 返回给主 agent。注意它不发任何donemessage——注释明确指出一旦发送 done前端if done: break finally: agent.abort会误杀主 agent。底层挂载点_handle_slash_cmd是主 agent 的任务预处理钩子原始实现在 agentmain.py负责/session.x...与/resume等内置命令在 agentmain.py 的run()循环中于每轮任务开始前调用。各前端在启动时把/review注入该钩子chatapp_common.pyfrom review_cmd import install as _install_review; _install_review(_GA)所有基于chatapp_common的聊天前端共用此挂载点tuiapp_v2.pyTUI 前端启动时review_cmd.install(_GA)tui_v3.pyTUI 的命令面板直接调用review_cmd.handle(ag, arg, dq)有 prompt 则作为普通任务提交无 prompt 则把帮助文本渲染为 assistant 消息tgapp.pyTelegram 前端引入handle_review_command。Prompt 渲染与多语言_render_prompt()review_cmd.py负责加载评审 prompt 模板并注入两个占位符{user_request}本轮请求与{ga_root}仓库根路径供file_read使用。它通过环境变量GA_LANG选择语言GA_LANGen时加载 review_inline_prompt.en.txt否则加载 review_inline_prompt.txt。若模板文件缺失会回退到_STUB_FALLBACK兜底提示保证/review在任何情况下都不会静默失效。四、三条铁律reviewer 顶部硬约束不可违反评审协议在 prompt 最顶部固定了三条不可违反的硬约束Review-only 只读评审—— 只做评审与报告。禁止修改源文件、调用file_write/file_patch/code_run改业务代码、在产出里写我接下来去修一下或暗示要动手。Challenge the approach不仅找 bug—— 先问这条路本身对不对再问实现有没有 bug挖隐含假设评估真实环境故障模式Windows 路径 / 代理失活 / 并发写 / UTF-8 边界 / token 预算耗尽。报告输出完即结束—— 不复述用户目标、不做 meta 评论、不承诺 follow-up报告 markdown 直接 echo 到对话不落盘 review.md、不打[ROUND END]。这三条铁律在 review_inline_prompt.txt 的角色与边界一节中逐条展开与 SOP 完全一致。五、五步工作流顺序执行禁止跳读步骤 1必读底料file_read(memory/code_review_principles.md)—— 15 条好代码原则每条 finding 必须能映射到其中一条。本轮/review只读取memory/review_sop/与memory/code_review_principles.md不引用其他工作流 prompt保证评审标准可预期、不串味。步骤 2锁定审阅范围按用户请求的优先级解析范围用户输入范围点名了文件 / 目录审那些描述了任务范围code_run跑git status -sgit diff --stat HEADgit diff HEAD必要时git log --oneline -5空 / 模糊默认审本次 uncommitted 改动非 git 仓库提示用户塞路径本轮结束先把范围列出来发给用户确认再开始file_read。锁定范围后不再 ask_user而是在最终报告的Scope中列清楚实际审了什么。步骤 3逐文件 file_read超过 800 行的文件分段读。优先看 diff 涉及的行再看上下文与接口调用方。步骤 4回答 Q1-Q4 对抗性 framingQ1: Is this the right approach?—— 有没有更简单 / 更标准 / 更安全的实现路径当前路径依赖了哪些隐含假设Q2: What hidden dependencies could fail?—— OS / shell / 网络 / 并发 / 第三方 API 任一失效会怎样Q3: What edge / hostile input breaks it?—— 空值、UTF-8 边界、Windows 路径、超长输入、并发写、过期 token、死代理。Q4: Is the failure mode observable recoverable?—— 仅看日志能不能定位故障能不能不动手就恢复每问至少要给出 1 条具体证据不能空谈。步骤 5列 P0~P3 findings遵守下述 §七 防误报八规则 §八 措辞八规范提交前过自检清单§九 对应完整 prompt 的 §8 自检项。六、Severity / Verdict 速查严重度分级严格遵守不要自创Level定义例子P0阻塞破坏正确性 / 丢数据 / 安全漏洞 / 不可逆故障路径穿越未校验、SQL 注入、密钥落日志、并发竞态破坏数据、未捕获异常吃掉关键 finallyP1高危契约破坏 / 用户可见错误但不会立即崩错误处理只 print 不抛、超时未设、配置写死、API schema 不一致P2维护性可读性 / 命名 / 测试空缺会增加未来 bug 概率但当前不破函数 80 行、变量名歧义、注释与代码不符、duplicate logic、测试覆盖空缺P3风格 / 微优化 / 可选改进命名小调整、常量提取、import 顺序Verdict 决议规则触发条件Verdict任一 P0FAIL无 P0≥ 1 P1CONDITIONAL仅 P2/P3 或 0 findingPASS七、防误报八规则成本低到高任一答 No → 删 findingDiscrete actionable—— 有具体可写的修复吗整体不够优雅不算 finding多个交织的小问题要拆开各自记录。Introduced or exposed by this change—— 是本次改动引入或放大的吗祖传 bug 不要翻预存 bug 被本次改动放大 → 显式标pre-existing, exposed by this change。Not an intentional design choice—— 不要把作者的有意取舍当 bug刻意保留的兼容层、有意宽松的 try/except 兜底、风格选择都不是 bug。Provably affected, not speculated—— 跨文件影响必须能指出哪一段调用栈会被破坏纯臆想这可能影响 X 模块不写。Evidence-anchored—— 行号、代码片段、复现命令至少一项看起来、应该、或许全删。No unstated assumptions—— 不要依赖未明说的代码库应该这样约定如果 finding 需要先假设作者意图才成立 → 删。Author would likely fix if made aware—— 作者看到会同意修吗100 万 QPS 才塌这种极端假设不要塞进 P1。Impact meaningful proportionate rigor—— 影响必须涉及 accuracy / performance / security / maintainability 之一同时不要超出代码库本身的严谨度一次性脚本仓库不要强求 PR 级注释和输入校验。每条规则的展开详见 review_inline_prompt.txt 的 §5。八、措辞八规范Why-first—— 第一句给原因不绕弯。严重度准确—— 不要把 P2 写得像 P0触发条件苛刻就在 impact 里立刻点出。简洁——evidence/impact/fix各 ≤ 1 段除非代码片段需要换行散文里不硬换行。少贴大段代码——evidence中代码 ≤ 5 行超过用file:line-line引用不要粘贴。触发条件显式——impact第一句就讲清在什么场景 / 输入 / 环境下出问题如在 Windows 路径含中文时…不让读者自己脑补。不卑不亢—— 直陈事实不带显然糟糕太蠢等情绪也不带非常感谢做得很好等开场白。即读即懂—— 核心结论放第一句需要读两遍才能懂的 finding 重写。零奉承—— 不写 Great work, but...、Thanks for the changes, however...。展开详见 review_inline_prompt.txt 的 §6。九、输出协议整段 echo不落盘评审报告必须按以下结构整段输出到对话markdown 直接 echo不落盘## Scope 一行一个文件绝对路径或仓库相对路径 ## Verdict PASS / CONDITIONAL / FAIL ## Summary 3-6 行散文整体印象 最重要的 1-2 个风险。 ## Design Challenge (Q1-Q4) - **Q1 是不是对的方法**: 证据 - **Q2 隐藏依赖**: 证据 - **Q3 边缘 / 敌意输入**: 证据 - **Q4 故障可观测**: 证据 ## Findings (P0 → P3 顺序) - **[P0, conf0.9] file:line-line** 标题动词开头≤ 80 字第一句给原因 - **Evidence**: 代码片段 ≤ 5 行 或 file:N-M 引用 - **Impact**: 触发场景 后果第一句必带场景 - **Fix**: 可直接照做的修复思路≤ 1 段 - **Principle**: 对应 code_review_principles 第 N 条 ## Cross-file notes 跨文件耦合 / 命名一致性 / 状态机 / 并发问题。无则 (none)。 ## Regression tests 3-5 条具体测试点输入 / 预期 / 边界。该结构在 review_inline_prompt.txt 的 §7 中有逐字段说明Scope列出本轮审阅的全部文件Verdict按 §4 决议规则给出Summary控制在 3-6 行散文Findings按 P0 → P3 排序每条必须带confidence_score真 bug ≥ 0.8拿不准 0.5与对应的Principle编号。提交前自检清单对应完整 prompt 的 §8code_review_principles.md已 file_read每个待审文件都至少 file_read 一次Design Challenge4 个字段都有具体证据不是空话每条 finding 通过防误报八规则discrete / introduced / not-intentional / provably-affected / evidence-anchored / no-unstated-assumptions / would-fix / impact-meaningful每条 finding 通过措辞八规范why-first / accurate / brief / no-big-code / scenario-explicit / matter-of-fact / immediately-graspable / no-flatteryconfidence_score老实给真 bug → ≥ 0.8拿不准 → 0.5Verdict 与决议规则一致没有奉承 / 开场白 / 复述用户目标 / 承诺修复十、评审标准底料15 条好代码原则评审的每条 finding 都必须能映射到 code_review_principles.md 中定义的 15 条好代码原则之一。该文件是评审标准化的核心主张好的代码不是能跑就行而是在长期演化中保持压缩性、局部性、可组合性与可证伪性15 条原则概括为模块边界清晰依赖方向稳定指向抽象而非细节局部可推理看一个文件就能判断行为、代价与失败模式可组合小组件自然组合成大能力接口一致、正交变化半径小改一个需求改动集中、可预测复杂度线性增长新功能增量近似线性重复少约束写进代码不变量写进类型 / 接口 / 校验 / 状态机可测试、可观测依赖可注入日志指标能定位因果链一致且不意外命名 / 错误处理 / 资源管理 / 并发模型全局一致自解释注释极简注释只出现在真正难以一眼看懂处代码极简视觉均匀没有废话行长度大致平均函数式倾向减少副作用但不教条以整体简单为目标功能越多代码应该越短新功能复用已有结构而非堆砌为未来的接入性设计天然留有干净的调用入口Let it crash——按失败半径决定防御策略大半径显式报错零半径静默放过篇幅分布跟着功能分布走主功能占大部分兜底压到最短文件末尾还提供了一段快速自检四问能否不看全局安全地改局部是否有清晰核心抽象让新功能主要是加实现变化点是收敛在边界还是散落各处出故障时能快速定位责任模块吗四问皆是即为好代码。评审者正是以这套标准作为 finding 的Principle字段引用依据。十一、扩展点自定义评审条目编辑 memory/code_review_principles.mdreviewer 启动时整段注入即可自定义评审侧重触发更换要把/review改成别的命令只需改动 frontends/review_cmd.py 的install()一处——所有前端通过统一的_handle_slash_cmd挂载点接管单点修改即全局生效。小结Review Mode SOP 为 GenericAgent 提供了一套轻量、零副作用、可复用的会话内对抗性评审机制/review命令经 review_cmd.py 统一接管后主 agent 在当前对话内按 review_inline_prompt.txt 的协议完成读底料 → 锁范围 → 读文件 → Q1-Q4 对抗性 framing → 列 findings五步评审并遵循 P0~P3 严重度分级、Verdict 决议、防误报八规则与措辞八规范最终按固定结构把报告 echo 到对话。其不开 subagent、不落盘、不打 sentinel的约束既避免了评审过程对工作区和对话状态机的污染也把评审延迟压到最低——这正是它适合作为开发过程中高频自检工具的原因。【免费下载链接】GenericAgentSelf-evolving agent: grows skill tree from 3.3K-line seed, achieving full system control with 6x less token consumption项目地址: https://gitcode.com/GitHub_Trending/pc/GenericAgent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/14 6:44:51 · 阅读 1.2k GenericAgent Review Mode SOP 实战解析：用 /review 拉起会话内对抗性代码评审
GenericAgent Review Mode SOP 实战解析用 /review 拉起会话内对抗性代码评审【免费下载链接】GenericAgentSelf-evolving agent: grows skill tree from 3.3K-line seed, achieving full system control with 6x less token consumption项目地址: https://gitcode.com/GitHub_Trending/pc/GenericAgent本文基于 GenericAgent 仓库的 memory/review_sop.md 及其配套实现系统讲解内置的/review命令与 Review Mode SOP一套运行在当前对话上下文中的对抗性代码评审协议。读完你将掌握该评审模式的触发方式、五步工作流、P0~P3 严重度分级、Verdict 决议规则、防误报八规则与措辞八规范并理解其不开 subagent / 不落盘 / 不打 sentinel的会话内设计在源码层面是如何落地实现的。一、Review Mode 是什么会话内对抗性评审GenericAgent 的 Review Mode评审模式是一个in-session adversarial code reviewer当你在对话中发起评审时主 agent 不切换到独立 subagent而是在当前对话内直接拉起评审流程审阅报告直接 echo 到对话作为给用户的最终回答。它的三个关键设计约束见 review_sop.md 顶部引言不开 subagent评审复用当前 session 的上下文不额外拉起子 agent不落盘报告不写review.md文件不产生磁盘产物不打 sentinel报告末尾不打印[ROUND END]标记。这条设计在源码中有明确佐证。主 agent 的正常输出路径会在文件末尾写入[ROUND END]见 agentmain.py而评审模式的 stub 兜底 prompt 里明确写着不要写 review.md不要打 [ROUND END]见 review_cmd.pyreview_inline_prompt.txt的角色与边界一节也重复强调这一约束。典型使用场景作者刚写完一段代码 → 输入/review→ 主 agent 对自己的改动做对抗性 review即审即得不污染工作区。二、何时使用与快速启动触发条件用户输入/review命令或自然语言要求 code review 时启用。快速启动命令表命令行为/review默认审本次 uncommitted 改动主 agent 跑git diff --stat HEADgit diff HEAD/review 自然语言请求按描述的范围去审可指定文件 / 目录 / 任务/review help显示用法/review help的用法文本由 review_cmd.py 的_help_text()生成其中给出的示例包括/review—— 默认审本次 uncommitted 改动/review 我刚改了 review_cmd.py 和 tuiapp_v2.py关注 prompt 注入—— 按任务范围审/review 审 frontends 目录下所有改过的文件—— 按目录范围审非 git 仓库若当前目录不是 git 仓库主 agent 会提示用户在下一句/review塞入具体路径或范围本轮结束。三、入口文件与命令分发链路任意前端 (TUI / Streamlit / wechat / desktop) └─ frontends/review_cmd.py ← 命令分发剥 /review 前缀注入 user_request └─ memory/review_sop/review_inline_prompt.txt ← 完整 in-session 协议 └─ memory/code_review_principles.md ← 15 条好代码原则分发实现monkey-patch 统一接管frontends/review_cmd.py 是/review的唯一命令入口核心是两个函数install()review_cmd.pymonkey-patchGenericAgent._handle_slash_cmd统一接管/review。patch 逻辑按原始输入精确匹配/review或/review //review\t前缀其余命令原样交给原始分发函数patched._review_patched True标记保证 patch 幂等重复 install 不会叠加。handle()review_cmd.py接收已剥离/review前缀的纯参数文本处理help/?/-h/--help后直接推送帮助文本否则把参数注入 inline prompt 返回给主 agent。注意它不发任何donemessage——注释明确指出一旦发送 done前端if done: break finally: agent.abort会误杀主 agent。底层挂载点_handle_slash_cmd是主 agent 的任务预处理钩子原始实现在 agentmain.py负责/session.x...与/resume等内置命令在 agentmain.py 的run()循环中于每轮任务开始前调用。各前端在启动时把/review注入该钩子chatapp_common.pyfrom review_cmd import install as _install_review; _install_review(_GA)所有基于chatapp_common的聊天前端共用此挂载点tuiapp_v2.pyTUI 前端启动时review_cmd.install(_GA)tui_v3.pyTUI 的命令面板直接调用review_cmd.handle(ag, arg, dq)有 prompt 则作为普通任务提交无 prompt 则把帮助文本渲染为 assistant 消息tgapp.pyTelegram 前端引入handle_review_command。Prompt 渲染与多语言_render_prompt()review_cmd.py负责加载评审 prompt 模板并注入两个占位符{user_request}本轮请求与{ga_root}仓库根路径供file_read使用。它通过环境变量GA_LANG选择语言GA_LANGen时加载 review_inline_prompt.en.txt否则加载 review_inline_prompt.txt。若模板文件缺失会回退到_STUB_FALLBACK兜底提示保证/review在任何情况下都不会静默失效。四、三条铁律reviewer 顶部硬约束不可违反评审协议在 prompt 最顶部固定了三条不可违反的硬约束Review-only 只读评审—— 只做评审与报告。禁止修改源文件、调用file_write/file_patch/code_run改业务代码、在产出里写我接下来去修一下或暗示要动手。Challenge the approach不仅找 bug—— 先问这条路本身对不对再问实现有没有 bug挖隐含假设评估真实环境故障模式Windows 路径 / 代理失活 / 并发写 / UTF-8 边界 / token 预算耗尽。报告输出完即结束—— 不复述用户目标、不做 meta 评论、不承诺 follow-up报告 markdown 直接 echo 到对话不落盘 review.md、不打[ROUND END]。这三条铁律在 review_inline_prompt.txt 的角色与边界一节中逐条展开与 SOP 完全一致。五、五步工作流顺序执行禁止跳读步骤 1必读底料file_read(memory/code_review_principles.md)—— 15 条好代码原则每条 finding 必须能映射到其中一条。本轮/review只读取memory/review_sop/与memory/code_review_principles.md不引用其他工作流 prompt保证评审标准可预期、不串味。步骤 2锁定审阅范围按用户请求的优先级解析范围用户输入范围点名了文件 / 目录审那些描述了任务范围code_run跑git status -sgit diff --stat HEADgit diff HEAD必要时git log --oneline -5空 / 模糊默认审本次 uncommitted 改动非 git 仓库提示用户塞路径本轮结束先把范围列出来发给用户确认再开始file_read。锁定范围后不再 ask_user而是在最终报告的Scope中列清楚实际审了什么。步骤 3逐文件 file_read超过 800 行的文件分段读。优先看 diff 涉及的行再看上下文与接口调用方。步骤 4回答 Q1-Q4 对抗性 framingQ1: Is this the right approach?—— 有没有更简单 / 更标准 / 更安全的实现路径当前路径依赖了哪些隐含假设Q2: What hidden dependencies could fail?—— OS / shell / 网络 / 并发 / 第三方 API 任一失效会怎样Q3: What edge / hostile input breaks it?—— 空值、UTF-8 边界、Windows 路径、超长输入、并发写、过期 token、死代理。Q4: Is the failure mode observable recoverable?—— 仅看日志能不能定位故障能不能不动手就恢复每问至少要给出 1 条具体证据不能空谈。步骤 5列 P0~P3 findings遵守下述 §七 防误报八规则 §八 措辞八规范提交前过自检清单§九 对应完整 prompt 的 §8 自检项。六、Severity / Verdict 速查严重度分级严格遵守不要自创Level定义例子P0阻塞破坏正确性 / 丢数据 / 安全漏洞 / 不可逆故障路径穿越未校验、SQL 注入、密钥落日志、并发竞态破坏数据、未捕获异常吃掉关键 finallyP1高危契约破坏 / 用户可见错误但不会立即崩错误处理只 print 不抛、超时未设、配置写死、API schema 不一致P2维护性可读性 / 命名 / 测试空缺会增加未来 bug 概率但当前不破函数 80 行、变量名歧义、注释与代码不符、duplicate logic、测试覆盖空缺P3风格 / 微优化 / 可选改进命名小调整、常量提取、import 顺序Verdict 决议规则触发条件Verdict任一 P0FAIL无 P0≥ 1 P1CONDITIONAL仅 P2/P3 或 0 findingPASS七、防误报八规则成本低到高任一答 No → 删 findingDiscrete actionable—— 有具体可写的修复吗整体不够优雅不算 finding多个交织的小问题要拆开各自记录。Introduced or exposed by this change—— 是本次改动引入或放大的吗祖传 bug 不要翻预存 bug 被本次改动放大 → 显式标pre-existing, exposed by this change。Not an intentional design choice—— 不要把作者的有意取舍当 bug刻意保留的兼容层、有意宽松的 try/except 兜底、风格选择都不是 bug。Provably affected, not speculated—— 跨文件影响必须能指出哪一段调用栈会被破坏纯臆想这可能影响 X 模块不写。Evidence-anchored—— 行号、代码片段、复现命令至少一项看起来、应该、或许全删。No unstated assumptions—— 不要依赖未明说的代码库应该这样约定如果 finding 需要先假设作者意图才成立 → 删。Author would likely fix if made aware—— 作者看到会同意修吗100 万 QPS 才塌这种极端假设不要塞进 P1。Impact meaningful proportionate rigor—— 影响必须涉及 accuracy / performance / security / maintainability 之一同时不要超出代码库本身的严谨度一次性脚本仓库不要强求 PR 级注释和输入校验。每条规则的展开详见 review_inline_prompt.txt 的 §5。八、措辞八规范Why-first—— 第一句给原因不绕弯。严重度准确—— 不要把 P2 写得像 P0触发条件苛刻就在 impact 里立刻点出。简洁——evidence/impact/fix各 ≤ 1 段除非代码片段需要换行散文里不硬换行。少贴大段代码——evidence中代码 ≤ 5 行超过用file:line-line引用不要粘贴。触发条件显式——impact第一句就讲清在什么场景 / 输入 / 环境下出问题如在 Windows 路径含中文时…不让读者自己脑补。不卑不亢—— 直陈事实不带显然糟糕太蠢等情绪也不带非常感谢做得很好等开场白。即读即懂—— 核心结论放第一句需要读两遍才能懂的 finding 重写。零奉承—— 不写 Great work, but...、Thanks for the changes, however...。展开详见 review_inline_prompt.txt 的 §6。九、输出协议整段 echo不落盘评审报告必须按以下结构整段输出到对话markdown 直接 echo不落盘## Scope 一行一个文件绝对路径或仓库相对路径 ## Verdict PASS / CONDITIONAL / FAIL ## Summary 3-6 行散文整体印象 最重要的 1-2 个风险。 ## Design Challenge (Q1-Q4) - **Q1 是不是对的方法**: 证据 - **Q2 隐藏依赖**: 证据 - **Q3 边缘 / 敌意输入**: 证据 - **Q4 故障可观测**: 证据 ## Findings (P0 → P3 顺序) - **[P0, conf0.9] file:line-line** 标题动词开头≤ 80 字第一句给原因 - **Evidence**: 代码片段 ≤ 5 行 或 file:N-M 引用 - **Impact**: 触发场景 后果第一句必带场景 - **Fix**: 可直接照做的修复思路≤ 1 段 - **Principle**: 对应 code_review_principles 第 N 条 ## Cross-file notes 跨文件耦合 / 命名一致性 / 状态机 / 并发问题。无则 (none)。 ## Regression tests 3-5 条具体测试点输入 / 预期 / 边界。该结构在 review_inline_prompt.txt 的 §7 中有逐字段说明Scope列出本轮审阅的全部文件Verdict按 §4 决议规则给出Summary控制在 3-6 行散文Findings按 P0 → P3 排序每条必须带confidence_score真 bug ≥ 0.8拿不准 0.5与对应的Principle编号。提交前自检清单对应完整 prompt 的 §8code_review_principles.md已 file_read每个待审文件都至少 file_read 一次Design Challenge4 个字段都有具体证据不是空话每条 finding 通过防误报八规则discrete / introduced / not-intentional / provably-affected / evidence-anchored / no-unstated-assumptions / would-fix / impact-meaningful每条 finding 通过措辞八规范why-first / accurate / brief / no-big-code / scenario-explicit / matter-of-fact / immediately-graspable / no-flatteryconfidence_score老实给真 bug → ≥ 0.8拿不准 → 0.5Verdict 与决议规则一致没有奉承 / 开场白 / 复述用户目标 / 承诺修复十、评审标准底料15 条好代码原则评审的每条 finding 都必须能映射到 code_review_principles.md 中定义的 15 条好代码原则之一。该文件是评审标准化的核心主张好的代码不是能跑就行而是在长期演化中保持压缩性、局部性、可组合性与可证伪性15 条原则概括为模块边界清晰依赖方向稳定指向抽象而非细节局部可推理看一个文件就能判断行为、代价与失败模式可组合小组件自然组合成大能力接口一致、正交变化半径小改一个需求改动集中、可预测复杂度线性增长新功能增量近似线性重复少约束写进代码不变量写进类型 / 接口 / 校验 / 状态机可测试、可观测依赖可注入日志指标能定位因果链一致且不意外命名 / 错误处理 / 资源管理 / 并发模型全局一致自解释注释极简注释只出现在真正难以一眼看懂处代码极简视觉均匀没有废话行长度大致平均函数式倾向减少副作用但不教条以整体简单为目标功能越多代码应该越短新功能复用已有结构而非堆砌为未来的接入性设计天然留有干净的调用入口Let it crash——按失败半径决定防御策略大半径显式报错零半径静默放过篇幅分布跟着功能分布走主功能占大部分兜底压到最短文件末尾还提供了一段快速自检四问能否不看全局安全地改局部是否有清晰核心抽象让新功能主要是加实现变化点是收敛在边界还是散落各处出故障时能快速定位责任模块吗四问皆是即为好代码。评审者正是以这套标准作为 finding 的Principle字段引用依据。十一、扩展点自定义评审条目编辑 memory/code_review_principles.mdreviewer 启动时整段注入即可自定义评审侧重触发更换要把/review改成别的命令只需改动 frontends/review_cmd.py 的install()一处——所有前端通过统一的_handle_slash_cmd挂载点接管单点修改即全局生效。小结Review Mode SOP 为 GenericAgent 提供了一套轻量、零副作用、可复用的会话内对抗性评审机制/review命令经 review_cmd.py 统一接管后主 agent 在当前对话内按 review_inline_prompt.txt 的协议完成读底料 → 锁范围 → 读文件 → Q1-Q4 对抗性 framing → 列 findings五步评审并遵循 P0~P3 严重度分级、Verdict 决议、防误报八规则与措辞八规范最终按固定结构把报告 echo 到对话。其不开 subagent、不落盘、不打 sentinel的约束既避免了评审过程对工作区和对话状态机的污染也把评审延迟压到最低——这正是它适合作为开发过程中高频自检工具的原因。【免费下载链接】GenericAgentSelf-evolving agent: grows skill tree from 3.3K-line seed, achieving full system control with 6x less token consumption项目地址: https://gitcode.com/GitHub_Trending/pc/GenericAgent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考