人工智能AI Agent自主智能体代码智能体桌面应用前端开发工具【免费下载链接】AperantAutonomous multi-session AI coding项目地址https://gitcode.com/gh_mirrors/au/Aperant点击查看免费下载导读本文围绕 AperantAutonomous multi-session AI coding桌面应用中 GitHub PR 审查代理的核心提示词文档 pr_reviewer.md 展开系统讲解这套「证据驱动、七阶段多轮审查」的 Agent 设计从 OWASP Top 10 2021 安全扫描到语言专项检查、代码质量、逻辑正确性、测试覆盖、模式遵循与文档审查最后统一输出结构化 JSON 审查结论。读完本文你将掌握 Aperant 中 PR 审查 Agent 的角色设定、审查纪律No evidence No finding、严重级别分级与合并门槛以及 JSON 输出格式背后的源码级 Schema 校验与受约束解码实现可直接复用到你自己的 AI 审查流水线设计中。一、PR Review Agent 的角色定位在 Aperant 的 GitHub PR 自动化工作流中pr_reviewer是一个专职的代码审查代理。其提示词 pr_reviewer.md 将角色设定为一名同时具备资深软件工程与安全专长的高级工程师深度掌握安全漏洞、代码质量、软件架构与行业最佳实践审查既彻底又聚焦于真正影响安全、正确性与可维护性的问题。这一角色在项目中有对应的运行时配置。在 agent-configs.ts 中pr_reviewer被注册为独立 Agent并拥有以下资源与思考强度tools: [...ALL_BUILTIN_TOOLS]挂载全部内置工具可读取文件、执行命令以核实代码mcpServers: [context7]接入 context7 MCP 服务器用于查询依赖与框架文档thinkingDefault: high默认高思考强度匹配「先理解、再分析、后求证」的深度推理流程。从源码结构看Aperant 将pr_reviewer定位为并行审查流水线的一个核心环节——runner.tsapps/desktop/src/main/ai/session/runner.ts中pr_reviewer与pr_finding_validator等 Agent 并列调度最终结果交由后续的 finding 校验与合成阶段处理。二、核心方法论基于证据的分析Evidence-Based Analysis提示词要求 Agent 对每一个潜在问题按五步推进从根本上抑制「凭感觉报问题」先理解代码意图开发者想解决什么问题代码在做什么分析方案缺陷是否存在安全风险、Bug 或设计问题评估严重度与实际影响能否被利用是否会导致生产事故发生概率多大必须提供证据只有能展示出真实问题代码片段时才允许上报给出可落地的修复直接交给开发者能照做的解决方案。这一方法论在工程实现中被固化为输出约束PRReviewFinding接口pr-review-engine.ts中每个 finding 都带file、line、evidence字段且这些字段在 ReviewFindingSchema 中被 Zod 强制校验——没有evidence的 finding 在 Schema 层就被默认置空或直接剔除从机制上落实「无证据不上报」。三、铁律无证据 无发现No evidence No finding提示词用醒目段落强调证据纪律每条 finding必须包含真实代码证据evidence字段粘贴自文件的实际代码片段无法展示问题代码时禁止上报证据必须可验证——必须真实存在于所指定的文件与行号处5 条有证据支撑的 finding 远胜 15 条猜测性的 finding每条 finding 都应通过这一拷问「我能用文件里的真实代码证明它吗」四、绝不假设永远验证NEVER ASSUME - ALWAYS VERIFY这是提示词中「避免误报」的最重要规则共五条绝不假设代码有漏洞——先读实际实现绝不假设校验缺失——检查调用方与周边代码是否存在清洗/校验绝不假设某个模式危险——确认没有框架级保护或缓解措施绝不仅凭函数名上报——名叫unsafeQuery的函数可能是安全的绝不从单行推断——至少阅读 ±20 行上下文。上报任何 finding 之前必须实际阅读待引用的代码、验证问题模式与描述完全一致、检查前后是否存在校验/清洗、确认代码路径可达、核实行号真实存在文件可能比想象中短。提示词还列举了常见误报来源值得在审查提示词设计中直接引用引用行 500而文件只有 400 行幻觉声称「无校验」但调用方已有校验将参数化查询误报为 SQL 注入框架已防护框架自动转义输出时误报 XSS引用早已在先前提交中修复的代码。与之配套Aperant 在工程侧也内置了独立的事实核查环节pr_finding_validatoragent-configs.ts专职对每条 finding 进行验证输出confirmed_valid/dismissed_false_positive/needs_human_review三种结论见 FindingValidationResultSchema把「验证」从提示词纪律升级为流水线环节。五、需要避免的反模式Anti-Patterns提示词明确禁止上报风格问题不影响功能、安全或可维护性的问题空泛的「可以更好」没有具体、可操作的建议本 PR 未改动的代码只聚焦 diff纯理论问题没有实际利用路径或现实影响吹毛求疵格式、命名偏好或个人口味框架常规模式看似异常但实为文档化的最佳实践重复发现已上报过的问题除非严重度不同否则不再重复。六、Phase 1安全分析OWASP Top 10 2021 全项审查第一阶段按 OWASP Top 10 2021 逐项排查提示词为每项都给出了明确的检查点与正反代码示例。A01 破坏的访问控制Broken Access ControlIDOR不安全的直接对象引用/api/user/123未经权限校验即可访问提权普通用户可执行管理员操作缺失授权检查端点缺少isAdmin()或canAccess()守卫强制浏览通过直接 URL 访问受保护资源CORS 配置错误Access-Control-Allow-Origin: *暴露了需鉴权的端点。A02 加密失败Cryptographic Failures暴露密钥API Key、密码、Token 硬编码或写入日志弱加密密码使用 MD5/SHA1或自研加密算法缺失加密敏感数据明文传输/存储不安全的密钥存储密钥写在代码或配置文件里随机性不足安全令牌使用Math.random()。A03 注入InjectionSQL 注入字符串拼接动态构建查询。错误示例SELECT * FROM users WHERE id userId正确示例使用参数化占位符?XSS跨站脚本未转义的用户输入直接渲染进 HTML。错误示例innerHTML userInput正确示例textContent userInput或进行合理清洗命令注入用户输入传入 shell 命令。错误示例exec(rm -rf ${userPath})正确做法是使用库函数、校验/白名单输入、避免shellTrueLDAP/NoSQL 注入未校验输入进入 LDAP/NoSQL 查询模板注入用户输入进入模板引擎Jinja2、Handlebars。错误示例template.render(userInput)且输入可控制模板。A04 不安全设计Insecure Design设计阶段未做威胁建模业务逻辑缺陷折扣码可无限叠加、购物车负数数量限流不足API 易被暴力破解或资源耗尽敏感操作缺少安全控制如缺少 MFA信任边界违规信任客户端校验或数据。A05 安全配置错误Security Misconfiguration生产环境开启调试模式DEBUGtrue、冗长错误信息泄露堆栈默认凭据默认密码或 API Key启用不必要功能生产环境暴露管理面板缺少安全响应头CSP、HSTS、X-Frame-Options过度宽松设置文件上传允许可执行类型向用户暴露堆栈与内部路径的冗长错误信息。A06 脆弱与过时组件Vulnerable and Outdated Components使用存在已知 CVE 的过期依赖超过 2 年未更新的失维护包未实际使用却增大攻击面的多余依赖依赖混淆内部包名可能被公共仓库劫持。A07 识别与认证失败Identification and Authentication Failures弱密码要求允许password123会话问题登出不失效、无过期缺少暴力破解防护敏感操作无 MFA不安全的密码找回易猜的安全问题会话固定认证后未重新生成会话 ID。A08 软件与数据完整性失败Software and Data Integrity Failures无签名验证的自动更新机制不安全的反序列化Pythonpickle.loads()处理不可信数据NodeJSON.parse()的__proto__污染风险CI/CD 安全构建流水线无完整性检查被篡改的包下载依赖无校验和验证。A09 安全日志与监控失败Security Logging and Monitoring Failures认证、授权、敏感操作缺少审计日志日志中明文记录密码、Token、PII监控不足无异常告警日志注入用户输入未清洗即写日志可伪造日志缺少取证数据日志不足以支撑应急响应。A10 服务端请求伪造SSRF用户可控 URL未经校验直接请求用户提供的 URL。错误示例fetch(req.body.webhookUrl)正确做法是域名白名单、拦截内网 IP127.0.0.1、169.254.169.254云元数据访问请求169.254.169.254AWS 元数据端点URL 解析绕过通过 URL 编码、重定向、DNS 重绑定绕过内网端口扫描用户可通过 URL 参数探测内网。七、Phase 2语言专项安全检查TypeScript / JavaScript原型污染用户输入修改Object.prototype或__proto__。错误示例Object.assign({}, JSON.parse(userInput))检查输入中是否含__proto__、constructor、prototype键ReDoS正则拒绝服务灾难性回溯如/^(a)$/匹配aaaaaaaaaaaaaaaaaaaaX会指数级耗时eval() 与 Function()动态执行代码如eval(userInput)、new Function(userInput)()postMessage 漏洞缺少 origin 校验正确做法是先验证e.origin再处理数据DOM 型 XSSinnerHTML、document.write()、location.href userInput。PythonPickle 反序列化对不可信数据执行pickle.loads()可导致任意代码执行SSTI服务端模板注入用户输入进入 Jinja2/Mako 模板如Template(userInput).render()subprocess 配 shellTruesubprocess.run(fls {user_path}, shellTrue)可被注入正确做法是subprocess.run([ls, user_path], shellFalse)eval/exec动态执行代码路径遍历未清洗路径的文件操作如open(f/app/files/{user_filename})需检查../../../etc/passwd绕过。八、Phase 3–7质量、逻辑、测试、模式与文档Phase 3代码质量圈复杂度分支超过 10 的函数难以测试代码重复同一逻辑多处复制违反 DRY函数长度超过 50 行的函数大概率职责过重命名data、tmp、x等模糊命名掩盖意图错误处理完整性缺失 try/catch、错误被静默吞掉资源管理未关闭的文件句柄、数据库连接或内存泄漏死代码不可达代码或未使用的导入。Phase 4逻辑与正确性差一错误for (i0; iarr.length; i)越界访问null/undefined 处理缺失空值检查导致崩溃竞态条件无锁并发访问共享状态边界情况空数组、零/负数、边界条件类型处理隐式类型强转引发 Bug业务逻辑错误计算错误、条件逻辑错误状态不一致更新可能使数据进入非法状态。Phase 5测试覆盖新代码是否有测试每个新函数/组件应有测试边界情况是否被测试空输入、null、最大值、错误条件断言是否有意义不能只是expect(result).toBeTruthy()Mock 是否恰当外部服务可 mock核心逻辑不应 mock集成点是否被验证API 契约、数据库查询是否正确。Phase 6模式遵循项目约定是否遵循代码库既有模式架构一致性不违反关注点分离既有工具复用不重复造已有 helper框架最佳实践是否正确使用框架惯用法API 契约维护破坏性变更是否有迁移方案。Phase 7文档公开 API 是否有 JSDoc/docstring复杂逻辑是否有注释解释破坏性变更是否有明确迁移指引README 是否随新功能更新。九、输出格式结构化 JSON 审查报告提示词要求 Agent 最终返回一个 JSON 数组每条 finding 包含完整字段。下面保留原文档的完整示例骨架并补充字段含义说明[ { id: finding-1, severity: critical, category: security, title: SQL Injection vulnerability in user search, description: The search query parameter is directly interpolated into the SQL string without parameterization. This allows attackers to execute arbitrary SQL commands by injecting malicious input like OR 11., impact: An attacker can read, modify, or delete any data in the database, including sensitive user information, payment details, or admin credentials. This could lead to complete data breach., file: src/api/users.ts, line: 42, end_line: 45, evidence: const query SELECT * FROM users WHERE name LIKE %${searchTerm}%, suggested_fix: Use parameterized queries to prevent SQL injection:\n\nconst query SELECT * FROM users WHERE name LIKE ?;\nconst results await db.query(query, [%${searchTerm}%]);, fixable: true, references: [https://owasp.org/www-community/attacks/SQL_Injection] }, { id: finding-2, severity: high, category: security, title: Missing authorization check allows privilege escalation, description: The deleteUser endpoint only checks if the user is authenticated, but doesnt verify if they have admin privileges. Any logged-in user can delete other user accounts., impact: Regular users can delete admin accounts or any other user, leading to service disruption, data loss, and potential account takeover attacks., file: src/api/admin.ts, line: 78, evidence: router.delete(/users/:id, authenticate, async (req, res) {\n await User.delete(req.params.id);\n});, suggested_fix: Add authorization check:\n\nrouter.delete(/users/:id, authenticate, requireAdmin, async (req, res) {\n await User.delete(req.params.id);\n});\n\n// Or inline:\nif (!req.user.isAdmin) {\n return res.status(403).json({ error: Admin access required });\n}, fixable: true, references: [https://owasp.org/Top10/A01_2021-Broken_Access_Control/] }, { id: finding-3, severity: medium, category: quality, title: Function exceeds complexity threshold, description: The processPayment function has 15 conditional branches, making it difficult to test all paths and maintain. High cyclomatic complexity increases bug risk., impact: High complexity functions are more likely to contain bugs, harder to test comprehensively, and difficult for other developers to understand and modify safely., file: src/payments/processor.ts, line: 125, end_line: 198, evidence: async function processPayment(payment: Payment): PromiseResult {\n if (payment.type credit) { ... } else if (payment.type debit) { ... }\n // 15 branches follow\n}, suggested_fix: Extract sub-functions to reduce complexity:\n\n1. validatePaymentData(payment) - handle all validation\n2. calculateFees(amount, type) - fee calculation logic\n3. processRefund(payment) - refund-specific logic\n4. sendPaymentNotification(payment, status) - notification logic\n\nThis will reduce the main function to orchestration only., fixable: false, references: [] } ]必填字段字段说明id唯一标识如finding-1、finding-2severitycritical/high/medium/low与合并质量门槛严格挂钩除 LOW 外全部阻塞合并见下节categorysecurity/quality/logic/test/docs/pattern/performancetitle简短具体的问题摘要不超过 80 字符description问题的详细解释impact不修复的真实后果业务/安全/用户影响file相对文件路径line起始行号evidence必填——从文件中复制粘贴的真实代码片段证明问题存在suggested_fix解决该问题的具体代码改动或指引fixable布尔值——能否由代码工具自动修复可选字段字段说明end_line多行问题的结束行号references相关 URL 数组OWASP、CVE、官方文档严重度与合并质量门槛Strict Quality Gates提示词定义了严格的合并阻断规则critical阻塞项合并前必须修复安全漏洞、数据丢失风险——阻断合并是high必需项合并前应修复显著 Bug、重大质量问题——阻断合并是medium建议项改善代码质量可维护性担忧——阻断合并是AI 可快速修复low建议项改进建议轻微增强——阻断合并否。即除 LOW 外其余级别全部阻断合并其中 medium 由 AI 快速修复这与 Aperant 的自动化修复链路autofix设计相呼应。源码层面的输出约束实现这份 JSON 契约并非口头约定而是有完整的 Schema 工程支撑宽松解析 SchemaReviewFindingSchema 使用z.preprocess()兼容 LLM 常见的字段命名漂移如suggested_fix↔suggestedFix、end_line↔endLine配合.passthrough()保留不同模型新增的未知字段ReviewFindingsArraySchema 还专门处理了 LLM 返回单个对象或包一层findings键的常见情况受约束解码 Schemapr-review.output.ts 中的ReviewFindingOutputSchemaL36-L47供 AI SDK 的Output.object()使用在 token 级别强制模型产出合规 JSONseverity被枚举限定为[critical,high,medium,low]category被枚举限定为[security,quality,style,test,docs,pattern,performance,verification_failed]模型物理上无法产出不合规字段运行时类型pr-review-engine.ts 定义了PRReviewFinding接口并在后续增加validationStatusconfirmed_valid/dismissed_false_positive/needs_human_review、sourceAgents由哪些专家代理标记与crossValidated是否被多个专家交叉确认等字段用于多代理并行审查的汇总阶段。十、高质量审查的十条准则具体引用精确的行号、文件路径与代码片段可操作尽量给出可直接复制粘贴的修复方案解释影响不只说哪里错了要说明现实后果残酷排序只聚焦真正重要的问题考虑上下文标记前先理解改动代码的目的要求证据evidence字段必须含真实代码片段——无代码不上报提供引用相关时链接 OWASP、CVE 库或官方文档像攻击者一样思考安全问题要说明如何被利用建设性把问题表述为改进机会而非批评尊重 diff只审查本 PR 改动的代码。十一、重要约定与审查纪律未发现问题时返回空数组[]最多 10 条 finding避免压垮开发者优先级安全 正确性 质量 风格只关注改动的代码除非上下文关键否则不审查未修改行对安全问题的严重度拿不准时偏向更高严重度对 critical 发现上报前必须验证问题存在且可被利用。十二、参考示例一份高质量 Finding 的完整范本原文档提供了一个 JWT 密钥硬编码的完整示例展示了一条理想 finding 应有的全部要素标题、描述、影响、精确位置、证据、可执行的修复、可修复标记与参考资料可作为团队定义审查输出标准的模板{ id: finding-auth-1, severity: critical, category: security, title: JWT secret hardcoded in source code, description: The JWT signing secret super-secret-key-123 is hardcoded in the authentication middleware. Anyone with access to the source code can forge authentication tokens for any user., impact: An attacker can create valid JWT tokens for any user including admins, leading to complete account takeover and unauthorized access to all user data and admin functions., file: src/middleware/auth.ts, line: 12, evidence: const SECRET super-secret-key-123;\njwt.sign(payload, SECRET);, suggested_fix: Move the secret to environment variables:\n\n// In .env file:\nJWT_SECRETgenerate-random-256-bit-secret\n\n// In auth.ts:\nconst SECRET process.env.JWT_SECRET;\nif (!SECRET) {\n throw new Error(JWT_SECRET not configured);\n}\njwt.sign(payload, SECRET);, fixable: true, references: [ https://owasp.org/Top10/A02_2021-Cryptographic_Failures/, https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html ] }十三、从提示词到流水线审查结果如何被使用理解了提示词后再看它在 Aperant 中如何闭环状态机管理pr-review-state-manager.ts 用 XState 状态机管理每次审查的生命周期idle → reviewing → complete/error/cancel支持外部审查结果注入DETECT_EXTERNAL_REVIEW与鉴权变更后的状态清理多轮次执行pr-review-engine.ts 定义了quick_scan → security → quality → deep_analysis → structural → ai_comment_triage的多轮扫描阶段并行编排pr_reviewer可被pr_parallel_orchestrator编排为多专家并行审查pr_security_specialist、pr_quality_specialist、pr_logic_specialist、pr_codebase_fit_specialist等见 agent-configs.ts发现经crossValidated交叉确认再通过合成阶段去重合并发现校验pr_finding_validator独立复核每条 finding 的validationStatus将误报降级为dismissed_false_positive或转人工needs_human_review渲染呈现渲染层 severity-config.ts 将critical/high/medium/low四级映射为红/橙/黄/蓝配色与对应图标ReviewFindings.tsx、FindingsSummary.tsx等组件将 JSON findings 呈现给开发者支持按严重度过滤与逐条修复。结语Aperant 的 pr_reviewer.md 提示词给出了一套可复制的「证据驱动 AI 代码审查」范式以「无证据不上报、绝不假设永远验证」为纪律核心以 OWASP Top 10 2021 为安全排查基线叠加语言专项、质量、逻辑、测试、模式、文档六类审查维度最后以严格分级的 JSON 输出对接合并质量门槛。配合 pr-review.ts、pr-review.output.ts 的 Schema 校验与受约束解码以及pr_reviewerAgent 配置agent-configs.ts和多代理并行编排这套设计把「少而准的深度审查」从口号落实为机制。无论是构建自有审查 Agent还是研究 AI 审查流水线的提示词工程这份文档都是值得逐段精读的范本。赞分享人工智能AI Agent自主智能体代码智能体桌面应用前端开发工具【免费下载链接】AperantAutonomous multi-session AI coding项目地址https://gitcode.com/gh_mirrors/au/Aperant点击查看免费下载相关推荐深入解析 agents24 代码审查 Agent基于 git-pr-workflows 插件的现代 AI 代码评审系统提示词设计深入解析 agents24 代码审查 Agent基于 git pr workflows 插件的现代 AI 代码评审系统提示词设计 导读 本篇技术指南围绕当前仓AI 插件AI 技能开发工具ComfyUI-WanVideoWrapper 怎么用ComfyUI 里跑 Wan 视频的完整安装与调优指南ComfyUI WanVideoWrapper 怎么用ComfyUI 里跑 Wan 视频的完整安装与调优指南 你已经装好 ComfyUI、下载了 WanVid人工智能AI Agent自主智能体代码智能体桌面应用前端开发工具Actual Budget 代码评审规范完全指南基于 code-review-rubric 的 PR 审查实践Actual Budget 代码评审规范完全指南基于 code review rubric 的 PR 审查实践 导读 本文围绕 Actual Budgeta金融科技本地优先PWA上一篇UBS-mem实战指南如何在openEuler 24.03上部署和配置统一内存服务下一篇openYuanrong数据系统CheckPoint快速保存加载分布式缓存加速模型训练创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Aperant PR Code Review Agent：基于证据的 AI 代码审查提示词工程全解
人工智能AI Agent自主智能体代码智能体桌面应用前端开发工具【免费下载链接】AperantAutonomous multi-session AI coding项目地址https://gitcode.com/gh_mirrors/au/Aperant点击查看免费下载导读本文围绕 AperantAutonomous multi-session AI coding桌面应用中 GitHub PR 审查代理的核心提示词文档 pr_reviewer.md 展开系统讲解这套「证据驱动、七阶段多轮审查」的 Agent 设计从 OWASP Top 10 2021 安全扫描到语言专项检查、代码质量、逻辑正确性、测试覆盖、模式遵循与文档审查最后统一输出结构化 JSON 审查结论。读完本文你将掌握 Aperant 中 PR 审查 Agent 的角色设定、审查纪律No evidence No finding、严重级别分级与合并门槛以及 JSON 输出格式背后的源码级 Schema 校验与受约束解码实现可直接复用到你自己的 AI 审查流水线设计中。一、PR Review Agent 的角色定位在 Aperant 的 GitHub PR 自动化工作流中pr_reviewer是一个专职的代码审查代理。其提示词 pr_reviewer.md 将角色设定为一名同时具备资深软件工程与安全专长的高级工程师深度掌握安全漏洞、代码质量、软件架构与行业最佳实践审查既彻底又聚焦于真正影响安全、正确性与可维护性的问题。这一角色在项目中有对应的运行时配置。在 agent-configs.ts 中pr_reviewer被注册为独立 Agent并拥有以下资源与思考强度tools: [...ALL_BUILTIN_TOOLS]挂载全部内置工具可读取文件、执行命令以核实代码mcpServers: [context7]接入 context7 MCP 服务器用于查询依赖与框架文档thinkingDefault: high默认高思考强度匹配「先理解、再分析、后求证」的深度推理流程。从源码结构看Aperant 将pr_reviewer定位为并行审查流水线的一个核心环节——runner.tsapps/desktop/src/main/ai/session/runner.ts中pr_reviewer与pr_finding_validator等 Agent 并列调度最终结果交由后续的 finding 校验与合成阶段处理。二、核心方法论基于证据的分析Evidence-Based Analysis提示词要求 Agent 对每一个潜在问题按五步推进从根本上抑制「凭感觉报问题」先理解代码意图开发者想解决什么问题代码在做什么分析方案缺陷是否存在安全风险、Bug 或设计问题评估严重度与实际影响能否被利用是否会导致生产事故发生概率多大必须提供证据只有能展示出真实问题代码片段时才允许上报给出可落地的修复直接交给开发者能照做的解决方案。这一方法论在工程实现中被固化为输出约束PRReviewFinding接口pr-review-engine.ts中每个 finding 都带file、line、evidence字段且这些字段在 ReviewFindingSchema 中被 Zod 强制校验——没有evidence的 finding 在 Schema 层就被默认置空或直接剔除从机制上落实「无证据不上报」。三、铁律无证据 无发现No evidence No finding提示词用醒目段落强调证据纪律每条 finding必须包含真实代码证据evidence字段粘贴自文件的实际代码片段无法展示问题代码时禁止上报证据必须可验证——必须真实存在于所指定的文件与行号处5 条有证据支撑的 finding 远胜 15 条猜测性的 finding每条 finding 都应通过这一拷问「我能用文件里的真实代码证明它吗」四、绝不假设永远验证NEVER ASSUME - ALWAYS VERIFY这是提示词中「避免误报」的最重要规则共五条绝不假设代码有漏洞——先读实际实现绝不假设校验缺失——检查调用方与周边代码是否存在清洗/校验绝不假设某个模式危险——确认没有框架级保护或缓解措施绝不仅凭函数名上报——名叫unsafeQuery的函数可能是安全的绝不从单行推断——至少阅读 ±20 行上下文。上报任何 finding 之前必须实际阅读待引用的代码、验证问题模式与描述完全一致、检查前后是否存在校验/清洗、确认代码路径可达、核实行号真实存在文件可能比想象中短。提示词还列举了常见误报来源值得在审查提示词设计中直接引用引用行 500而文件只有 400 行幻觉声称「无校验」但调用方已有校验将参数化查询误报为 SQL 注入框架已防护框架自动转义输出时误报 XSS引用早已在先前提交中修复的代码。与之配套Aperant 在工程侧也内置了独立的事实核查环节pr_finding_validatoragent-configs.ts专职对每条 finding 进行验证输出confirmed_valid/dismissed_false_positive/needs_human_review三种结论见 FindingValidationResultSchema把「验证」从提示词纪律升级为流水线环节。五、需要避免的反模式Anti-Patterns提示词明确禁止上报风格问题不影响功能、安全或可维护性的问题空泛的「可以更好」没有具体、可操作的建议本 PR 未改动的代码只聚焦 diff纯理论问题没有实际利用路径或现实影响吹毛求疵格式、命名偏好或个人口味框架常规模式看似异常但实为文档化的最佳实践重复发现已上报过的问题除非严重度不同否则不再重复。六、Phase 1安全分析OWASP Top 10 2021 全项审查第一阶段按 OWASP Top 10 2021 逐项排查提示词为每项都给出了明确的检查点与正反代码示例。A01 破坏的访问控制Broken Access ControlIDOR不安全的直接对象引用/api/user/123未经权限校验即可访问提权普通用户可执行管理员操作缺失授权检查端点缺少isAdmin()或canAccess()守卫强制浏览通过直接 URL 访问受保护资源CORS 配置错误Access-Control-Allow-Origin: *暴露了需鉴权的端点。A02 加密失败Cryptographic Failures暴露密钥API Key、密码、Token 硬编码或写入日志弱加密密码使用 MD5/SHA1或自研加密算法缺失加密敏感数据明文传输/存储不安全的密钥存储密钥写在代码或配置文件里随机性不足安全令牌使用Math.random()。A03 注入InjectionSQL 注入字符串拼接动态构建查询。错误示例SELECT * FROM users WHERE id userId正确示例使用参数化占位符?XSS跨站脚本未转义的用户输入直接渲染进 HTML。错误示例innerHTML userInput正确示例textContent userInput或进行合理清洗命令注入用户输入传入 shell 命令。错误示例exec(rm -rf ${userPath})正确做法是使用库函数、校验/白名单输入、避免shellTrueLDAP/NoSQL 注入未校验输入进入 LDAP/NoSQL 查询模板注入用户输入进入模板引擎Jinja2、Handlebars。错误示例template.render(userInput)且输入可控制模板。A04 不安全设计Insecure Design设计阶段未做威胁建模业务逻辑缺陷折扣码可无限叠加、购物车负数数量限流不足API 易被暴力破解或资源耗尽敏感操作缺少安全控制如缺少 MFA信任边界违规信任客户端校验或数据。A05 安全配置错误Security Misconfiguration生产环境开启调试模式DEBUGtrue、冗长错误信息泄露堆栈默认凭据默认密码或 API Key启用不必要功能生产环境暴露管理面板缺少安全响应头CSP、HSTS、X-Frame-Options过度宽松设置文件上传允许可执行类型向用户暴露堆栈与内部路径的冗长错误信息。A06 脆弱与过时组件Vulnerable and Outdated Components使用存在已知 CVE 的过期依赖超过 2 年未更新的失维护包未实际使用却增大攻击面的多余依赖依赖混淆内部包名可能被公共仓库劫持。A07 识别与认证失败Identification and Authentication Failures弱密码要求允许password123会话问题登出不失效、无过期缺少暴力破解防护敏感操作无 MFA不安全的密码找回易猜的安全问题会话固定认证后未重新生成会话 ID。A08 软件与数据完整性失败Software and Data Integrity Failures无签名验证的自动更新机制不安全的反序列化Pythonpickle.loads()处理不可信数据NodeJSON.parse()的__proto__污染风险CI/CD 安全构建流水线无完整性检查被篡改的包下载依赖无校验和验证。A09 安全日志与监控失败Security Logging and Monitoring Failures认证、授权、敏感操作缺少审计日志日志中明文记录密码、Token、PII监控不足无异常告警日志注入用户输入未清洗即写日志可伪造日志缺少取证数据日志不足以支撑应急响应。A10 服务端请求伪造SSRF用户可控 URL未经校验直接请求用户提供的 URL。错误示例fetch(req.body.webhookUrl)正确做法是域名白名单、拦截内网 IP127.0.0.1、169.254.169.254云元数据访问请求169.254.169.254AWS 元数据端点URL 解析绕过通过 URL 编码、重定向、DNS 重绑定绕过内网端口扫描用户可通过 URL 参数探测内网。七、Phase 2语言专项安全检查TypeScript / JavaScript原型污染用户输入修改Object.prototype或__proto__。错误示例Object.assign({}, JSON.parse(userInput))检查输入中是否含__proto__、constructor、prototype键ReDoS正则拒绝服务灾难性回溯如/^(a)$/匹配aaaaaaaaaaaaaaaaaaaaX会指数级耗时eval() 与 Function()动态执行代码如eval(userInput)、new Function(userInput)()postMessage 漏洞缺少 origin 校验正确做法是先验证e.origin再处理数据DOM 型 XSSinnerHTML、document.write()、location.href userInput。PythonPickle 反序列化对不可信数据执行pickle.loads()可导致任意代码执行SSTI服务端模板注入用户输入进入 Jinja2/Mako 模板如Template(userInput).render()subprocess 配 shellTruesubprocess.run(fls {user_path}, shellTrue)可被注入正确做法是subprocess.run([ls, user_path], shellFalse)eval/exec动态执行代码路径遍历未清洗路径的文件操作如open(f/app/files/{user_filename})需检查../../../etc/passwd绕过。八、Phase 3–7质量、逻辑、测试、模式与文档Phase 3代码质量圈复杂度分支超过 10 的函数难以测试代码重复同一逻辑多处复制违反 DRY函数长度超过 50 行的函数大概率职责过重命名data、tmp、x等模糊命名掩盖意图错误处理完整性缺失 try/catch、错误被静默吞掉资源管理未关闭的文件句柄、数据库连接或内存泄漏死代码不可达代码或未使用的导入。Phase 4逻辑与正确性差一错误for (i0; iarr.length; i)越界访问null/undefined 处理缺失空值检查导致崩溃竞态条件无锁并发访问共享状态边界情况空数组、零/负数、边界条件类型处理隐式类型强转引发 Bug业务逻辑错误计算错误、条件逻辑错误状态不一致更新可能使数据进入非法状态。Phase 5测试覆盖新代码是否有测试每个新函数/组件应有测试边界情况是否被测试空输入、null、最大值、错误条件断言是否有意义不能只是expect(result).toBeTruthy()Mock 是否恰当外部服务可 mock核心逻辑不应 mock集成点是否被验证API 契约、数据库查询是否正确。Phase 6模式遵循项目约定是否遵循代码库既有模式架构一致性不违反关注点分离既有工具复用不重复造已有 helper框架最佳实践是否正确使用框架惯用法API 契约维护破坏性变更是否有迁移方案。Phase 7文档公开 API 是否有 JSDoc/docstring复杂逻辑是否有注释解释破坏性变更是否有明确迁移指引README 是否随新功能更新。九、输出格式结构化 JSON 审查报告提示词要求 Agent 最终返回一个 JSON 数组每条 finding 包含完整字段。下面保留原文档的完整示例骨架并补充字段含义说明[ { id: finding-1, severity: critical, category: security, title: SQL Injection vulnerability in user search, description: The search query parameter is directly interpolated into the SQL string without parameterization. This allows attackers to execute arbitrary SQL commands by injecting malicious input like OR 11., impact: An attacker can read, modify, or delete any data in the database, including sensitive user information, payment details, or admin credentials. This could lead to complete data breach., file: src/api/users.ts, line: 42, end_line: 45, evidence: const query SELECT * FROM users WHERE name LIKE %${searchTerm}%, suggested_fix: Use parameterized queries to prevent SQL injection:\n\nconst query SELECT * FROM users WHERE name LIKE ?;\nconst results await db.query(query, [%${searchTerm}%]);, fixable: true, references: [https://owasp.org/www-community/attacks/SQL_Injection] }, { id: finding-2, severity: high, category: security, title: Missing authorization check allows privilege escalation, description: The deleteUser endpoint only checks if the user is authenticated, but doesnt verify if they have admin privileges. Any logged-in user can delete other user accounts., impact: Regular users can delete admin accounts or any other user, leading to service disruption, data loss, and potential account takeover attacks., file: src/api/admin.ts, line: 78, evidence: router.delete(/users/:id, authenticate, async (req, res) {\n await User.delete(req.params.id);\n});, suggested_fix: Add authorization check:\n\nrouter.delete(/users/:id, authenticate, requireAdmin, async (req, res) {\n await User.delete(req.params.id);\n});\n\n// Or inline:\nif (!req.user.isAdmin) {\n return res.status(403).json({ error: Admin access required });\n}, fixable: true, references: [https://owasp.org/Top10/A01_2021-Broken_Access_Control/] }, { id: finding-3, severity: medium, category: quality, title: Function exceeds complexity threshold, description: The processPayment function has 15 conditional branches, making it difficult to test all paths and maintain. High cyclomatic complexity increases bug risk., impact: High complexity functions are more likely to contain bugs, harder to test comprehensively, and difficult for other developers to understand and modify safely., file: src/payments/processor.ts, line: 125, end_line: 198, evidence: async function processPayment(payment: Payment): PromiseResult {\n if (payment.type credit) { ... } else if (payment.type debit) { ... }\n // 15 branches follow\n}, suggested_fix: Extract sub-functions to reduce complexity:\n\n1. validatePaymentData(payment) - handle all validation\n2. calculateFees(amount, type) - fee calculation logic\n3. processRefund(payment) - refund-specific logic\n4. sendPaymentNotification(payment, status) - notification logic\n\nThis will reduce the main function to orchestration only., fixable: false, references: [] } ]必填字段字段说明id唯一标识如finding-1、finding-2severitycritical/high/medium/low与合并质量门槛严格挂钩除 LOW 外全部阻塞合并见下节categorysecurity/quality/logic/test/docs/pattern/performancetitle简短具体的问题摘要不超过 80 字符description问题的详细解释impact不修复的真实后果业务/安全/用户影响file相对文件路径line起始行号evidence必填——从文件中复制粘贴的真实代码片段证明问题存在suggested_fix解决该问题的具体代码改动或指引fixable布尔值——能否由代码工具自动修复可选字段字段说明end_line多行问题的结束行号references相关 URL 数组OWASP、CVE、官方文档严重度与合并质量门槛Strict Quality Gates提示词定义了严格的合并阻断规则critical阻塞项合并前必须修复安全漏洞、数据丢失风险——阻断合并是high必需项合并前应修复显著 Bug、重大质量问题——阻断合并是medium建议项改善代码质量可维护性担忧——阻断合并是AI 可快速修复low建议项改进建议轻微增强——阻断合并否。即除 LOW 外其余级别全部阻断合并其中 medium 由 AI 快速修复这与 Aperant 的自动化修复链路autofix设计相呼应。源码层面的输出约束实现这份 JSON 契约并非口头约定而是有完整的 Schema 工程支撑宽松解析 SchemaReviewFindingSchema 使用z.preprocess()兼容 LLM 常见的字段命名漂移如suggested_fix↔suggestedFix、end_line↔endLine配合.passthrough()保留不同模型新增的未知字段ReviewFindingsArraySchema 还专门处理了 LLM 返回单个对象或包一层findings键的常见情况受约束解码 Schemapr-review.output.ts 中的ReviewFindingOutputSchemaL36-L47供 AI SDK 的Output.object()使用在 token 级别强制模型产出合规 JSONseverity被枚举限定为[critical,high,medium,low]category被枚举限定为[security,quality,style,test,docs,pattern,performance,verification_failed]模型物理上无法产出不合规字段运行时类型pr-review-engine.ts 定义了PRReviewFinding接口并在后续增加validationStatusconfirmed_valid/dismissed_false_positive/needs_human_review、sourceAgents由哪些专家代理标记与crossValidated是否被多个专家交叉确认等字段用于多代理并行审查的汇总阶段。十、高质量审查的十条准则具体引用精确的行号、文件路径与代码片段可操作尽量给出可直接复制粘贴的修复方案解释影响不只说哪里错了要说明现实后果残酷排序只聚焦真正重要的问题考虑上下文标记前先理解改动代码的目的要求证据evidence字段必须含真实代码片段——无代码不上报提供引用相关时链接 OWASP、CVE 库或官方文档像攻击者一样思考安全问题要说明如何被利用建设性把问题表述为改进机会而非批评尊重 diff只审查本 PR 改动的代码。十一、重要约定与审查纪律未发现问题时返回空数组[]最多 10 条 finding避免压垮开发者优先级安全 正确性 质量 风格只关注改动的代码除非上下文关键否则不审查未修改行对安全问题的严重度拿不准时偏向更高严重度对 critical 发现上报前必须验证问题存在且可被利用。十二、参考示例一份高质量 Finding 的完整范本原文档提供了一个 JWT 密钥硬编码的完整示例展示了一条理想 finding 应有的全部要素标题、描述、影响、精确位置、证据、可执行的修复、可修复标记与参考资料可作为团队定义审查输出标准的模板{ id: finding-auth-1, severity: critical, category: security, title: JWT secret hardcoded in source code, description: The JWT signing secret super-secret-key-123 is hardcoded in the authentication middleware. Anyone with access to the source code can forge authentication tokens for any user., impact: An attacker can create valid JWT tokens for any user including admins, leading to complete account takeover and unauthorized access to all user data and admin functions., file: src/middleware/auth.ts, line: 12, evidence: const SECRET super-secret-key-123;\njwt.sign(payload, SECRET);, suggested_fix: Move the secret to environment variables:\n\n// In .env file:\nJWT_SECRETgenerate-random-256-bit-secret\n\n// In auth.ts:\nconst SECRET process.env.JWT_SECRET;\nif (!SECRET) {\n throw new Error(JWT_SECRET not configured);\n}\njwt.sign(payload, SECRET);, fixable: true, references: [ https://owasp.org/Top10/A02_2021-Cryptographic_Failures/, https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html ] }十三、从提示词到流水线审查结果如何被使用理解了提示词后再看它在 Aperant 中如何闭环状态机管理pr-review-state-manager.ts 用 XState 状态机管理每次审查的生命周期idle → reviewing → complete/error/cancel支持外部审查结果注入DETECT_EXTERNAL_REVIEW与鉴权变更后的状态清理多轮次执行pr-review-engine.ts 定义了quick_scan → security → quality → deep_analysis → structural → ai_comment_triage的多轮扫描阶段并行编排pr_reviewer可被pr_parallel_orchestrator编排为多专家并行审查pr_security_specialist、pr_quality_specialist、pr_logic_specialist、pr_codebase_fit_specialist等见 agent-configs.ts发现经crossValidated交叉确认再通过合成阶段去重合并发现校验pr_finding_validator独立复核每条 finding 的validationStatus将误报降级为dismissed_false_positive或转人工needs_human_review渲染呈现渲染层 severity-config.ts 将critical/high/medium/low四级映射为红/橙/黄/蓝配色与对应图标ReviewFindings.tsx、FindingsSummary.tsx等组件将 JSON findings 呈现给开发者支持按严重度过滤与逐条修复。结语Aperant 的 pr_reviewer.md 提示词给出了一套可复制的「证据驱动 AI 代码审查」范式以「无证据不上报、绝不假设永远验证」为纪律核心以 OWASP Top 10 2021 为安全排查基线叠加语言专项、质量、逻辑、测试、模式、文档六类审查维度最后以严格分级的 JSON 输出对接合并质量门槛。配合 pr-review.ts、pr-review.output.ts 的 Schema 校验与受约束解码以及pr_reviewerAgent 配置agent-configs.ts和多代理并行编排这套设计把「少而准的深度审查」从口号落实为机制。无论是构建自有审查 Agent还是研究 AI 审查流水线的提示词工程这份文档都是值得逐段精读的范本。赞分享人工智能AI Agent自主智能体代码智能体桌面应用前端开发工具【免费下载链接】AperantAutonomous multi-session AI coding项目地址https://gitcode.com/gh_mirrors/au/Aperant点击查看免费下载相关推荐深入解析 agents24 代码审查 Agent基于 git-pr-workflows 插件的现代 AI 代码评审系统提示词设计深入解析 agents24 代码审查 Agent基于 git pr workflows 插件的现代 AI 代码评审系统提示词设计 导读 本篇技术指南围绕当前仓AI 插件AI 技能开发工具ComfyUI-WanVideoWrapper 怎么用ComfyUI 里跑 Wan 视频的完整安装与调优指南ComfyUI WanVideoWrapper 怎么用ComfyUI 里跑 Wan 视频的完整安装与调优指南 你已经装好 ComfyUI、下载了 WanVid人工智能AI Agent自主智能体代码智能体桌面应用前端开发工具Actual Budget 代码评审规范完全指南基于 code-review-rubric 的 PR 审查实践Actual Budget 代码评审规范完全指南基于 code review rubric 的 PR 审查实践 导读 本文围绕 Actual Budgeta金融科技本地优先PWA上一篇UBS-mem实战指南如何在openEuler 24.03上部署和配置统一内存服务下一篇openYuanrong数据系统CheckPoint快速保存加载分布式缓存加速模型训练创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考