问题所在
你加入了新团队。你收购了一家公司。某个关键依赖已无人维护，总得有人去评估它。代码库庞大，时间紧迫。
老办法：打开文件、到处 grep，花几周时间在脑中建立全局图景。单智能体的办法：把文件粘贴给 Claude 提问，一次一个对话，每次会话结束后上下文就丢失了。
两种方式都无法扩展。一个 50 万行的代码库有数百个模块。一个智能体在质量下降之前，上下文里大概只能容纳 20 个文件。你需要几十次依次进行的会话——之后还得自己汇总所有发现。
“我聪明、能干，也有丰富的编程经验，但也只能勉强保持足够的专注，去认真审查单个 Claude 智能体的输出。”—— petesergeant, HN
如果连一个智能体的输出都难以消化，想象一下要在一个从未见过的代码库上，汇总 40 次独立会话的发现。
Chief 如何帮助你
对整个代码库并行阅读
Chief 将你的审计目标分解为并行的阅读任务——每个模块、服务或层级分配一个智能体。智能体同时分散到代码库各处，每个都有限定的范围，上下文始终清晰——同时运行的数量以你的智能体订阅允许的上限为准。这与支撑 Chief 重构工作流的并行执行能力相同，只是用于纯分析。
你设定审计目标，智能体负责阅读
告诉 Chief 你需要了解什么：“梳理所有数据库访问模式，并标记 N+1 查询。”“找出每个身份验证边界，并记录信任模型。”“识别所有外部 API 依赖及其故障模式。”Chief 提出审计计划，由智能体执行。开启 Auto mode 后，各条审计线会在任务上限和你所用服务商的每周用量上限内无人值守地运行。你全程不打开任何一个源文件。
摘要汇总所有发现
每个智能体都会按照你的审计标准报告结构化的发现，Chief 会对照里程碑的验收标准审查每项结果。Chief 的摘要会汇总所有模块的发现——不是原始的智能体对话记录，而是可以直接据此行动的条理化结果。需要你来决定的发现会进入你的待办列表（抢先体验）。
不同审计维度使用不同智能体
用 Claude Code 做架构分析，用 Codex 做机械式的模式检测，用 Qwen Code 评估测试覆盖率。借助 Chief 的 BYOA 模式，你可以为每个审计里程碑选择智能体——安全审查、依赖梳理、死代码检测、API 接口清点——全部并行运行。
跨审计会话的持久上下文
Chief 在每次智能体会话之间维护项目级上下文，并将发现延续下去，让后续任务建立在先前任务的发现之上。当一个智能体发现 auth 模块委托给了一个共享的中间件层时，负责审计该中间件的智能体一开始就掌握这一信息。没有冷启动，也不必重复探索。
为什么代码库审计适合并行智能体
1. 阅读天然高度可并行
审计代码库是纯粹的只读工作。每个模块都可以独立分析。没有合并冲突，没有依赖顺序——只有数百个文件需要同时由智能的“眼睛”来审视。这正是适合 Chief 并行分发的工作负载。
2. 单智能体的上下文崩塌会毁掉审计质量
一个智能体阅读 500 个文件，得出的是浅显、笼统的观察。十个智能体各读 50 个文件，得出的是深入、具体的发现。Chief 让每个智能体都处于最佳状态——范围受限、上下文清晰——同时统筹整个代码库的全局视图。
3. 汇总才是难点，而 Chief 负责处理
价值不在于任何单个智能体的发现，而在于综合所有发现后的整体视图。Chief 对照标准审查每条审计线，并将所有智能体的发现汇总成一份条理清晰的审计报告。你审阅的是汇总结果，而不是原始输出。
4. 审计会重复进行——而 Chief 记得
季度安全审查。收购前尽职调查。合规检查。重大升级前的依赖审计。Chief 的持久项目上下文意味着每次审计都建立在上一次的基础上。第二次审计会更快，因为 Chief 已经了解代码库的结构。
示例：收购前技术尽职调查，对象是一个 40 万行的代码库
1. 设定审计目标。 CTO 打开 Chief，设定一个项目级目标：“对目标公司的后端代码库完成技术尽职调查。评估架构质量、安全态势、扩展瓶颈和技术债务。”
2. Chief 提出审计计划。 Chief 分析仓库结构，提出 5 条并行审计线：
- 审计线 1：架构梳理——服务边界、数据流、依赖图（6 个服务，共 6 个智能体）
- 审计线 2：安全审计——身份验证边界、输入校验、密钥管理、OWASP 攻击面（3 个智能体）
- 审计线 3：数据层分析——schema 设计、查询模式、迁移历史、N+1 检测（2 个智能体）
- 审计线 4：基础设施与部署——CI/CD、容器配置、扩展特性（1 个智能体）
- 审计线 5：代码质量信号——测试覆盖率、死代码、依赖新旧程度、错误处理模式（3 个智能体）
3. 智能体分头行动。 CTO 批准计划，并开启 Auto mode，设置任务上限和服务商用量的每周上限。Chief 并行分发阅读任务，每个任务都限定了范围，同时运行的数量以 CTO 的智能体订阅允许的上限为准。智能体阅读、分析，并按照结构化标准报告发现。不修改任何代码——这是纯粹的分析。
4. 在任何地方监控。 CTO 在董事会会议期间用手机查看进度。审计线 1 已完成 80%。审计线 2 标记了三个严重问题——两个服务中存在硬编码的密钥，以及一个管理端点缺少身份验证检查。这个身份验证问题只有 CTO 本人才能拍板，因此进入了其待办列表（抢先体验）。审计线 3 识别出 14 个 N+1 查询模式。
5. 汇总报告。 Chief 将五条审计线的发现汇总成一份结构化的尽职调查报告：3 个严重安全问题、14 个性能瓶颈、数据层存在中等程度的技术债务、整体架构扎实。CTO 一个源文件都没打开过，就获得了一份全面的技术评估。
6. 结果。 一个通常需要工程团队花 2-3 周的尽职调查流程，大约一天就完成了。每个智能体都在限定的范围内保持了清晰的上下文。每项发现都可以追溯到具体的模块和文件。CTO 基于数据而非直觉，给出了收购建议。
套餐说明。 这种规模的审计远超 Free 套餐每天 30 个任务的额度，因此属于 Pro 的使用场景。使用 Free 套餐时，可以先从一两条审计线开始。
何时使用 Chief
- 你需要理解一个从未见过的代码库——新工作、收购、接手的项目，或开源依赖评估。
- 代码库对单个智能体来说太大——数十个模块中的数百个文件，超出任何单个上下文窗口的容量。
- 你需要结构化的发现，而不是原始对话记录——安全态势、架构质量、技术债务评估或合规验证。
- 审计时间紧迫——尽职调查截止日期、事件响应或迁移前风险评估。
- 并行智能体同时阅读代码库的不同部分——十个智能体各自分析限定的范围，得出的发现比一个智能体浏览全部内容更深入、更具体。
常见问题
这与传统代码审查工具有什么不同？
传统代码审查工具——GitHub PR 审查、Reviewboard、Gerrit——评估的是代码的变更。Chief 的代码库审计评估的是代码本身。你不是在审查 diff，而是分派智能体去阅读和分析整个现有代码库。这就像审查一个 pull request 与审计一家公司整个技术栈之间的区别。
Chief 能否在不修改任何文件的情况下审计代码库？
可以。代码库审计是纯粹的只读操作。智能体分析、报告发现并呈现结果——不修改任何文件，不创建任何分支。Chief 负责协调阅读并汇总发现。
Chief 如何避免智能体得出浅显、笼统的观察？
通过限定每个智能体的范围。Chief 不会让一个智能体试图理解 500 个文件，而是分派 10 个智能体，每个分析 50 个文件。范围受限意味着上下文清晰，进而带来具体、可操作的发现。随后由汇总层把各个智能体的洞察串联起来。
Chief 可以编排哪些类型的审计？
任何针对现有代码库的结构化分析：安全审查、架构梳理、依赖审计、技术债务评估、合规验证、迁移前风险分析、测试覆盖率评估、API 接口清点、死代码检测，以及性能瓶颈识别。
哪些智能体最适合代码库审计？
不同智能体擅长不同的审计维度。Claude Code 的强项是架构推理和安全分析。Codex 能很好地处理机械式的模式检测。借助 Chief 的 BYOA 模式，你可以为每条审计线选择智能体——全部通过一个控制台统一协调。
Chief 会记住以往审计的发现吗？
会。Chief 维护持久的项目级上下文。当你进行季度安全审计时，Chief 已经从上一次审计中了解了代码库结构。重复审计会更快，并且可以聚焦于自上次评估以来发生的变化。
我可以同时审计多个代码库吗？
可以。每个仓库都是一个独立的 Chief 项目，你的所有项目都集中在一处，因此可以同时对多个仓库进行审计。这适用于涉及多个仓库的收购尽职调查，或跨项目的安全排查。Free 套餐支持 5 个项目；Pro 取消此限制。
使用 Chief 做代码库审计是免费的吗？
是的。Free 套餐包含 5 个项目和每天 30 个任务，使用你自己的智能体，无需信用卡。Pro 取消这些限制，并提供抢先体验功能。一次拆分为大量阅读任务的大型审计，通常每天需要超过 30 个任务，因此属于 Pro 的使用场景。