LLM 写代码越来越快，可"写出来"不等于"写得对"。UnvibeCode 是一款证据驱动的代码审查工具，它的 Business Risk Findings 能把藏在复杂代码里的业务漏洞揪出来——每条风险发现都附带触发条件、业务后果和可追踪的源码证据（具体文件、符号、行号），帮新手和普通用户看懂"代码到底哪里会出问题"。

业务漏洞为什么难发现？

传统代码审查多盯着语法错误、空指针、性能慢点。但真正让产品"出问题"的，往往是业务层面的裂缝：

• 支付回调被重复应用，同一笔订单记两次账；
• 网关明确拒绝了交易，代码却把它当"支付成功"；
• 超时逻辑只报错、不释放执行槽，系统越跑越卡。

这些漏洞没有报错，甚至所有接口都返回 200。它们藏在跨文件、跨函数的执行路径里，靠读单个文件很难发现。UnvibeCode 的思路是：先重建"代码到底在做什么业务"，再把每条风险钉到具体的代码行上。

UnvibeCode 的三步走：建图 → 重建工作流 → 对照代码查风险

UnvibeCode 的工作分三步（见 docs/HOW_IT_WORKS.md）：

1. 本地建图：扫描受支持的源码文件，映射文件、符号、import、调用关系，把代码切成有序片段，构建"连接代码图"。
2. 重建业务工作流：把入口点、决策、状态变化、外部副作用和结果串起来，得到 Business Workflow Map，每个工作流都说明它做什么、为谁服务、为什么重要。
3. 对照代码查风险：风险审查聚焦"会伤到客户、权限、数据完整性或运营"的失效，把触发条件、代码行为、业务后果连成一条证据链。

建图和上下文准备在本地完成；只有深度分析所需的结构化代码上下文会送到托管服务（详见下文"隐私"）。

一条 Business Risk Finding 由六段证据组成

每条发现不是一句"这里可能有问题"，而是一条可追踪的证据链，字段顺序固定，方便快速判断：

随后是What to change（修复方向）、Acceptance check（Given/When/Then 形式的验收标准），最后附上Supporting code evidence表格——具体到文件 / 符号 / 行号 / 该处证明什么。

这套结构在 docs/OUTPUTS.md 有完整说明，对应输出文件为03_business_risk_findings.html。

真实案例：支付回调漏洞是如何被揪出来的

以 UnvibeCode 公开的 django-payments 样例为例，Business Risk Findings 找到了2 个支付完整性缺陷（见 docs/gitdocs/django-payments/2026-10-18/）：

• CyberSource 拒绝结果被当成成功支付（CRITICAL）：网关返回"拒绝"或"验证失败"的 reason code 后，provider 仍把支付记录置为 CONFIRMED / PREAUTH 并走成功路径——被拒交易进入了成功支付流程。
• Sagepay 回调更新"传入的等待支付对象"（HIGH）：回调只校验 waiting 状态和返回状态，没有把回调绑定到特定支付记录，理论上可能把状态写到错误的支付上。

报告还配了一张业务路径图，把"网关 → 回调 → 支付记录 → 买家进入成功路径 → 错误交易被当作已支付"这条链路画出来。smolagents 样例则揪出一条：超时只报错、不释放执行槽，超时片段会继续占用本地 runner 直到跑完。

读懂 STRONG EVIDENCE：证据等级与"值得再看一眼"

UnvibeCode 用标签管理可信度：

• STRONG EVIDENCE / SUPPORTED EVIDENCE：发现本身有源码证据支撑，标签标注证据强度。
• STRUCTURAL REVIEW（值得再看一眼的结构性热点）：标记"复杂度集中 / 连接紧密"的代码区域，它们是审查优先级，不是已确认缺陷——报告里会明确区分两者。

💡 关键认知："没有风险发现" ≠ "代码没有缺陷"。一个完成审查但无确认发现的结果，只表示在已分析范围内没有坐实的业务缺陷，不证明整库安全。

隐私与安全：它不会把你的密钥交给 AI

UnvibeCode 在把代码送去做 AI 分析前，会识别可辨认的凭证（API key、密码、access token、私钥）并替换为占位符。不过文档也提醒：深度编码或自定义格式的秘密文件可能逃过这道防线（见 docs/DATA_PROCESSING.md）。

什么时候它不"越界"？边界说明

UnvibeCode不替代：单元/集成/端到端/负载/渗透测试、熟悉系统的工程师人工审查、安全/隐私/法务评估、生产监控。它定位是帮你理解和调查代码，而非自动改代码或替你测试生产。报告里也会提醒：每条场景应在你自己的应用与运行环境里验证后再当"确认缺陷"处理。

此外，超过约2M token的超大仓库只做 Connected Code Map 和完整上下文，不启动工作流与风险审查（见 docs/LIMITATIONS.md）——看结论前，先确认报告里标注的"实际完成的范围"。

如何开始：一条命令跑出风险报告

需要 Python 3.11+：

python3 -m pip install --upgrade unvibecode python3 -m unvibecode review --repository "/path/to/repository"

结果保存在./shipready_results/analysis_<时间戳>/customer_results/，打开00_unvibecode_results.html即可从 Business Workflows 一路读到 Risk Findings。四份配套文件要一起保留（完整入口 + 三份编号报告 + 上下文 ZIP），详见 docs/QUICKSTART.md。

把报告读成"行动清单"的 4 步建议

1. 先看 Business Workflows：确认这个业务流程在你的系统里真实存在。
2. 再看 Risk Findings：读触发条件、业务后果、验收检查。
3. 在 Connected Code 里圈文件：下载 Optimal 上下文，交给 AI 助手深入调查。
4. 按 Acceptance check 写测试：把 Given/When/Then 变成回归用例。

UnvibeCode 不是安全扫描器，也不做渗透测试。它的价值在于把"可能影响业务的代码缺陷"连同可追踪的证据链摆到你面前，让每个发现都能被独立调查和验证——这正是 Business Risk Findings 证据驱动审查的初衷。