让我们从一个 Cisco 安全负责人 Anthony Grieco 讲过的精妙比喻开始（来源：Cisco 博客 《8 Years of Security Research in 8 Weeks》）：
"如果一个普通人，平时只骑过自行车，现在突然得到一辆 F1 赛车的钥匙—— 他或许能勉强沿着赛道挪动，但他绝不可能赢得比赛。"
这句话，精准地戳破了当下"AI 安全"领域最大的幻觉： 很多人以为，只要拿到最强的 AI 模型（那辆 F1 赛车），安全问题就解决了。 但现实是——光有引擎，赢不了比赛。
如果 AI 模型已经这么强大，为什么过去几十年，网络安全防御依然慢得令人绝望？
要理解 Foundry 为什么重要，我们不能从"AI 很厉害"出发，而要回到最根本的问题： 一次软件安全评估，到底要解决哪几个最基础的矛盾？ 把它拆到不能再拆，只剩下三个本质矛盾：
一个产品动辄上亿行代码。过去，安全团队被迫做选择题： 基于"风险画像"挑几个模块来查，明知道没扫的地方藏着 Bug， 却只能祈祷黑客也没发现。这就像房间太黑，你只有一支手电筒， 只能照亮一角。
传统静态分析工具臭名昭著—— 每 10,000 条警告里，可能只有 1 条是真问题。 安全专家被淹没在告警的海洋里，陷入无止境的"三连击"： 看告警、排查、发现是误报……再看下一条。
人工红队（模拟攻击）和专家审计， 受限于人脑的速度。再聪明的专家，一天也只能读那么多代码。 于是速度成了天花板， 整个行业被这个天花板压了几十年。
答案是：只解决了第三个（速度），而且如果用错方法，反而会让前两个变得更糟。 因为一个未经约束的强大 AI，会以惊人的速度生产出更多看似可信、实则编造的漏洞报告。 这就是行业里那句著名的批评："AI 会把你淹死在噪音里。"
💡 关键洞察： 模型是加速器（accelerant），而真正的引擎（engine）， 是那套约束、引导、验证 AI 的"方法论框架"。 这句话，正是 Cisco 博客的原文："The model is the accelerant; the harness is the engine." （模型是燃料，编排框架才是引擎。）
我们在第一章得出了结论：真正的引擎是"方法论框架"。 那么 Cisco 把这套引擎开源了出来，取名 Foundry Security Spec。 在认识它之前，我们先用苏格拉底的方式，逼自己想清楚一个最容易被忽略的问题——
Cisco 既然已经做出了能扫描 18 亿行代码的内部系统，为什么开源时给的是一份"规范文档"，
而不是直接把那套能跑的"代码工具"送给你？
这是理解 Foundry 的第一道、也是最关键的一道坎。
Foundry 仓库里没有一行可运行的代码（来源：README.md ——
"There is no code in this repository, and that is intentional."）。
这是故意的。原因藏在第一性原理里：
Cisco 内部那套能跑的系统，被深度"焊死"在 Cisco 自己的基础设施上——
它用的是 Cisco 的云、Cisco 的工单系统、Cisco 的 LLM 网关、Cisco 的部署平台、Cisco 的漏洞分级标准。
如果把这套代码原封不动开源给你，
你拿到的将是"一套只能在 Cisco 那一个环境里跑起来的东西"
（来源：README.md §"Why we're releasing a spec instead of a tool"）。
真正能跨越组织、可被任何人复用的，从来不是代码本身，而是设计： 你需要哪些 AI 角色、每个角色必须保证什么、漏洞从发现到上报如何流动、 什么叫"评估完成"、质量关卡设在哪里、以及—— 哪些捷径会在半年后反咬你一口。这套设计，是与基础设施无关的， 这才是这个仓库真正交付的东西。
Foundry Security Spec 是一份"由 AI 智能体组成的自动化安全评估系统"的开源参考规范（Specification / Seed 种子）。 它不提供运行代码，而是提供：系统应由哪些角色组成、每个角色的行为契约、漏洞的完整生命周期、 以及 11 条不可违背的设计铁律。你拿它当蓝图，在你自己的技术栈上建造属于你的系统。
它就像一套世界级建筑事务所沉淀下来的"抗震大楼设计规范"。 规范不会送你砖头水泥（代码），但它告诉你：承重墙必须设在哪、 地基要打多深、哪种偷工减料会在地震时塌楼（踩过的坑）。 你用本地的建材，盖出适合你城市的楼——但楼是不会塌的。
回到本质。Foundry 解决的核心问题，用它自己的话说就是
（来源：spec.md §1.1）：
"把一台前沿大模型，变成一个能产出有边界、可验证、有优先级的漏洞清单，
并且能告诉你什么时候算干完了的安全评估系统。"
| 本质矛盾（第一章） | 裸用 AI 的下场 | Foundry 的破解之道 |
|---|---|---|
| ① 范围：看不全 | 仍需人工挑模块 | 从"手电筒"换成"泛光灯"：可评估整个代码库，不再被迫做选择题（来源：博客原文 flashlight → floodlight） |
| ② 噪音：误报多 | 噪音被放大数倍 | 在 18 亿行代码上做到误报率 < 3%，靠的是"证据闸门 + 人机混合验证"（来源：博客 + spec.md §7.3） |
| ③ 速度：人脑慢 | 极快，但产出不可信 | 速度照单全收，且通过角色分工与多重关卡让快的同时还准（来源：spec.md §4） |
市面上"AI 找漏洞"的概念满天飞，但 Foundry 有三个独一无二的基因， 让它从"演示玩具"升级为"生产级蓝图"：
Cisco 用六个不同的前沿 AI 模型验证了这套规范（来源：博客 +
README.md "tested across six frontier models"）。
这意味着它不绑死在任何一家 AI 厂商身上。模型会过时、会被超越，
但方法论是稳定的。这就像一份优秀的菜谱，
换了哪个品牌的灶台都能做出好菜。
Foundry 附带一部 宪法constitution.md：包含 11 条"不可违背原则"，每条都对应一个 Cisco 内部曾经踩过、修复过的生产故障。
（constitution.md），里面有 11 条不可违背的原则。
关键在于——每一条都不是凭空设计的偏好，而是 Cisco
亲手上线、亲眼看着它崩溃、再亲手修复后写下的"伤疤"
（来源：constitution.md §Purpose："each one encodes a failure the seed authors shipped, diagnosed, and fixed"）。
违背任何一条，就等于重现那次故障。
它构建于社区驱动的 GitHub Spec Kit一套"规范驱动开发（Spec-Driven Development）"的开源工作流。先写规范，再由 AI 辅助把规范转化为设计、任务和代码。 之上。 这意味着任何团队都能用熟悉、可信的开源协作方式去扩展和改造它 （来源：博客 "built on the community-driven GitHub Spec Kit"）。 你不是被锁进 Cisco 的黑箱，而是拿到一张可自由修改的开放蓝图。
🧭 一句话理清：
你带来两样东西——一台前沿大模型 和 一个要评估的目标软件；
Foundry 给你架构、不变量（invariants）和护栏（guardrails）；
然后你在自己的技术栈上，建造属于你自己的实现。
（来源：README.md "You bring a frontier LLM and a target… Foundry gives you the architecture, the invariants, and the guardrails."）
我们已经知道 Foundry 是什么。但作为企业的安全负责人、架构师或技术决策者， 你真正关心的是一个更尖锐的问题：它凭什么值得我投入团队、改造流程？ 在回答之前，先用苏格拉底的方式，戳破一个几乎所有人都会掉进去的陷阱——
当一个 AI 安全系统宣称"我们今年发现的漏洞数量增长了 10 倍"——
这究竟是一个好消息，还是一个危险信号？
让我们回到本质。安全团队的终极目标是什么？不是"发现更多漏洞"， 而是"让真正危险的问题被修复"。这两者之间，隔着一道致命的鸿沟—— 人的注意力是有限的。
Cisco 在博客里给出了一句堪称"清醒剂"的判断（来源：博客 §"What this means for industry collaboration"）：
"不要把数量（Volume）误认为价值（Value）。
随着 AI 普及，被发现的漏洞数量一定会暴涨。但如果这是你唯一在数的指标， 你或许该问问自己：你真的抓住这个时代的价值了吗？"
这就是 Foundry 价值观的基石：真正的 AI 驱动安全，衡量的是"规模化的可执行精度（actionable precision at scale）"， 而不是漏洞的数量。如果你的团队收到的是一万条未经验证的告警， 那不是能力，那是灾难——你只是把"人工找不过来"的问题， 换成了"人工看不过来"的问题。
可执行的精度（Actionable Precision）：每一条交付给工程师的发现， 都已经过AI 与人类专家的混合验证，附带完整证据、复现步骤和优先级， 工程师拿到即可直接动手修复，无需二次甄别真伪。
劣质 AI 给你的是一摞看不懂的原始化验单（一万条告警）， 你得自己当医生逐条判断。Foundry 给你的是一份医生签字的体检报告： "你有 3 个真问题，按这个顺序处理，这是依据。"——后者才叫价值。
过去安全团队最大的隐痛，是"已知的未知"—— 明知道没扫的代码里藏着 Bug，却没有资源去查。Foundry 把 "扫描整个产品代码库"从"奢望"变成了"日常"。 18 亿行代码、25 种以上编程语言、8 周完成（人工需 8 年）—— 这组数字背后，是企业第一次能够诚实地对管理层说： "我们看遍了，没有漏掉的角落。"
如果说前面是"做得更全更准"，那么 Foundry 设计里最深的价值，
在于一个能自我增强、永不停转的机制——它的官方名字叫
"检测到预防的飞轮（Detection-to-Prevention Flywheel）"
（来源：README.md §Companion + docs/architecture/rule-gap-flywheel.md）。
它的逻辑链条精妙到令人拍案，我们一步步拆开：
系统用一套"检测规则"逐个函数地扫遍代码，找出已知套路的漏洞。稳定、可重复。
同时，另一批 AI 智能体自由探索，去找那些没有任何规则描述过的、针对这个产品独特设计的新型漏洞。Cisco 发现：最高危的漏洞，往往来自这种探索，而非现成规则。
当探索发现了一个真漏洞，而现有规则没有一条能抓到它时，系统会自动记录下这个"缺口"（来源：spec.md FR-042）。
专家（或自动化的 Self-Improver 角色）把这次的一次性发现，提炼成一条通用规则，加入规则语料库。
从此，在这个产品以及所有未来的产品上，这一整类漏洞都会在第一遍扫描时就被系统性捕获。探索智能体被解放出来，去更远的地方狩猎新东西。
这就是飞轮：没有终点，每一次评估都在让规则语料库变大； 语料库越大，下一次扫描第一遍就能抓到越多——飞轮越转越快。
飞轮还有一个更惊人的"第二级效果"。这套规则语料库（Cisco 用的格式叫 CodeGuard一种开源的检测规则格式，由 Cisco 原创并捐赠给 CoSAI（安全 AI 联盟），现作为 OASIS 开放项目维护。一份规则可同时用于"评估时检测"和"编码时预防"。）是可移植的。
同一条规则，在"评估已完成的代码"时是检测器； 把它加载进开发者的 AI 编程助手（IDE 插件），在"代码正在被写出来"时就变成了预防器。 于是：
🔁 复利公式：
你上一次评估教会语料库"识别"的那一类 Bug，
现在会在每一个开发者的编辑器里、在敲下那行有问题代码的瞬间，
被"预防"掉——比下一次评估还要早。
每转一圈飞轮，都同时提升了"这里的检测能力"和"处处的预防能力"。
（来源：README.md "Every turn of the loop improves detection here and prevention everywhere."）
这就是 Foundry 与所有"一次性扫描工具"的根本区别： 探索的成果是一次性的（一个发现就是一个发现）， 但只要把它的教训沉淀成规则，检测投入就会变成跨越所有未来评估的复利。
| 维度 | 传统静态分析 / 裸用 AI | Foundry 驱动的安全评估 |
|---|---|---|
| 核心指标 | 漏洞数量 | 可执行精度 |
| 信噪比 | 1 个有效 / 10,000 条告警 | 误报率 < 3%（经混合验证） |
| 覆盖范围 | 被迫挑选模块（手电筒） | 整个代码库（泛光灯） |
| 价值积累 | 每次从零开始 | 飞轮复利，越用越聪明 |
| 检测与预防 | 割裂的两件事 | 同一套规则，检测即预防 |
| 交付物 | 一堵告警之墙 | 已验证、带证据、可直接修 |
我们知道了 Foundry 是什么、为什么有价值。现在到了最硬核的部分—— 掀开引擎盖。在拆零件之前，先用第一性原理问一个最根本的问题：
如果只让一个万能 AI 智能体去"读代码、找漏洞、判真假、写报告"全包了，
会出什么问题？为什么 Cisco 偏偏要把它拆成 8 个角色？
答案藏在一句极其深刻的设计哲学里（来源：spec.md §4.2 Rationale）：
"每个角色都有一个独特的失败模式，而下一个角色的存在，正是为了捕获这个失败。"
Cisco 反复发现一个规律：只要把任意两个角色合并，合并后角色的质量标准，就会向两者中较弱的那个滑落。 让我们顺着这条"失败链"往下推，你会发现 8 个角色是被"逼"出来的，而非凭空设计：
智能体是一个由大模型驱动、按固定职责在循环中工作、通过共享"基质（Substrate）"与同伴协调的工作单元。 角色是一种命名的专长（检测器、分诊员……）；一个角色可以有许多并发实例。
你不会让一个医生同时做挂号、拍片、读片、手术、写病历——那样每个环节都是业余水平。 Foundry 就像一家医院：导诊、影像科、放射科医生、外科医生、质控、出报告各司其职， 一道工序的疏漏，被下一道专业工序兜住。
这 8 个角色（来源：spec.md §4.2）可以归入三大分层：
知识层 负责"看懂目标"，
流水线层 负责"找—判—证—报"，
监督层 则统管全局与"何时算完"。
| 角色 | 一句话职责 | 它捕获的"失败" | 类比 |
|---|---|---|---|
| ① 编排器 Orchestrator |
操作员唯一的接口：验证配置、生成与维护整个团队、监控状态、管预算；同时答疑、派活、接受指挥 | —（总指挥） | 医院院长 + 前台 |
| ② 索引器 Indexer |
建立代码的结构知识：符号、调用图、谁调用谁 | 没它，下游问"谁调了这个函数"无人能答 | 图书馆目录系统 |
| ③ 制图师 Cartographer |
绘制安全地图：架构、攻击面、信任边界、数据流、威胁模型 | 没它，分诊只能逐个瞎猜边界 | 城市安防地图 |
| ④ 检测器 Detector |
广度优先：规则扫荡 + 自由探索，把一切可疑都丢进库 | —（故意高产、低精度） | 地毯式初筛护士 |
| ⑤ 分诊员 Triager |
噪音过滤器：逐一调查候选，凭证据判定真伪 | 捕获检测器的"噪音" | 主治医师读片 |
| ⑥ 验证器 Validator |
证明过滤器：在真实靶场上独立复现，证明"真能被利用" | 捕获分诊"听起来对、实则虚构" | 手术确诊 |
| ⑦ 覆盖向导 Coverage-Guide |
把目标拆成清单，追踪进度，宣布"覆盖完成" | 捕获"找到一堆但不知是否全" | 质控主管 |
| ⑧ 报告员 Reporter |
产出人类可读的报告：严重度、分类、复现步骤、汇总 | 捕获"一堆无法行动的结论" | 出具诊断报告 |
📌 流水线的精髓： 检测器故意高产低精度（广撒网，宁可多不可漏）； 分诊员把噪音滤掉；验证器把"嘴上说的"变成"手上证的"； 报告员只把已确认的写成报告。 关键铁律：检测器绝不直接给人看任何东西， 所有候选先躺在内部库里，只有通过分诊的才会浮出水面（这正是宪法第 II 条）。
角色解决了"谁来干活"，但还有一个更深的问题：如何保证这些 AI 智能体不会"自信地胡说八道"？ 这就要请出 Foundry 的灵魂——那部 宪法（Constitution）。
大模型最擅长的，就是生成"流畅、自信、看似合理却完全错误"的内容。
那么——你凭什么相信它报上来的漏洞是真的？
这是整个系统最重要的质量控制，也是"误报率 <3%"背后的核心机密。
Cisco 的原话振聋发聩（来源：constitution.md §I）：
"前沿模型会以一种让未经审查的输出毫无价值的比率， 生产出流畅、自信、看似合理的漏洞声明——而它们是错的。
我们没有靠'要求模型更小心'来解决这个问题。
我们的解法是：要求它的声明必须可被核查，然后真的去核查。"
具体怎么核查？分诊员若想把一个发现判定为 真阳性（true-positive），
它的调查报告必须为以下三件事各引用至少一处具体代码位置
（来源：spec.md §7.3 / FR-087）：
必须指出一个攻击者能控制的入口，并证明从这里能抵达那个危险的"汇聚点"。
不是空中楼阁，是真能走到。
必须指出不可信数据未经充分校验、就跨进可信处理区的那个临界点。
这正是制图师的"安全地图"派上用场之处。
必须指出在汇聚点产生的具体安全后果。
到底能造成什么实质危害？
而最致命的一招在 FR-088： 每一处被引用的代码位置，都会被"机械地"验证它是否真实存在于代码里。 只要有一处引用解析不到真实代码（比如模型编造了一个不存在的函数名）， 该判定立刻被降级为"待复核（needs-review）"—— 无论它的论述听起来多么天衣无缝。
证据闸门：一个发现被标记为"真阳性"前必须满足的结构化要求—— 为可达性、信任边界、影响各提供可机械验证的代码引用。 模型无权给自己颁发"真阳性"勋章；是闸门在颁发。
就像法庭定罪不能靠检察官"我觉得他有罪"，必须出示三样能被核实的物证： 作案路径、越界时刻、造成的伤害。任何一件物证经查是伪造的（地址不存在）， 案子当场降级。幻觉的函数名，就是伪造的物证。
🎯 秘密揭晓： "误报率 <3%" 不是因为模型更聪明，而是因为这道闸门把"无法被核实的声明"挡在了门外。 一个幻觉出来的函数名，过不了机械核查；一个缺少"三条腿"的发现，至多是"线索"，绝不会被当成"真漏洞"递到工程师面前。 Cisco 说：这一道闸门，把真阳性精度从"不可用"提升到了"审阅者愿意信任这个标签"。
宪法共 11 条，每条都对应一次真实的生产事故。我们用一张表，
让你一眼读懂它们各自"踩过的坑"（来源：constitution.md §Core Principles）：
| # | 铁律 | 它防的"坑"（血泪教训） |
|---|---|---|
| I | 证据高于断言 | 模型自信地胡编，未经核查的输出毫无价值 → 要求可核查并真的核查 |
| II | 只浮现"幸存者" | 曾为每条检测建一个工单 → 单个目标产出上万工单，工具"正确却无用" |
| III | 靠心跳判活，绝不靠时钟 | 固定超时无法区分"卡死"和"在等限流" → 90%+ 误杀健康智能体，吞吐趋近于零 |
| IV | 任务认领原子且会随主而亡 | 无原子认领 → 多智能体重复劳动、互相覆盖；无"随主而亡" → 崩溃后任务永久卡死 |
| V | 供应商才是限速裁判 | 每个内部限速值几天就过时 → 要么浪费已付产能，要么形同虚设、掩盖真信号 |
| VI | 先覆盖，再看产出率 | 只看产出率会在"头六小时没找到东西"时误停 → 而那往往是开始，不是结束 |
| VII | "已利用"=已实证 | 每一次对"已利用"标签的稀释，都在一个汇报周期内摧毁审阅者的信任 |
| VIII | 指纹在编辑下保持稳定 | 指纹含行号 → 代码一改，每次重跑都把同一发现当新的重报，操作员永远在重复分诊 |
| IX | 靠基础设施隔离，绝不靠提示词 | 智能体会读到含恶意指令的内容 → 只靠提示词约束的边界，迟早被越过 |
| X | 操作员的权威高于一切智能体 | 智能体会互相"劝退" → 一个说"这块查完了"，全队跟着信，最终用自己的共识当证据 |
| XI | 原子化持久化 | "先删旧再写新"中途崩溃 → 读者啥都读不到且无报错，曾反复丢失数小时的索引构建 |
请特别注意宪法 §Amendment 的态度（来源：constitution.md）：
"'它不方便'和'我们的基础设施做起来很难'，都不构成修改这些原则的理由。
每一条原则实现起来都不方便；但每一条缺席的代价，都比它存在的代价更昂贵。"
除了 8 个核心角色，Foundry 还描述了 5 个可选扩展角色
（来源：spec.md §6）。官方强烈建议：第一次构建时，全部说"不"——
先让 8 个核心角色稳定产出可信的发现，再来考虑这些"进阶装备"：
对特定函数/端点做模糊测试（Fuzzing）与属性测试，在检测器给出广度之处，补上深度。
拿到一个确认漏洞，在代码库其余部分搜寻同类模式，揪出系统性同款问题。
把多个确认漏洞组装成"权限提升图"，显示攻击者如何从入口一步步链到目标。
为确认漏洞生成并验证候选补丁，但永远是"供人类审阅的提案"，绝不自动合并。
阅读团队自己的日志、指标、规则缺口，向操作员提议配置、提示词与新规则——它就是飞轮第④步的自动化引擎。
我们已经看清了引擎的全部零件。最后一个问题，也是最实际的问题： 作为企业，我拿到这份开源蓝图后，第一步该做什么？ 在给出步骤之前，先用第一性原理破除一个最常见的落地误区——
既然这是一份"通用蓝图"，我能不能直接照着它一字不改地开始编码？
如果不能，那些"留白"的地方，又该由谁、在什么时候填上？
答案是不能直接编码。因为这份种子规范（spec.md）在每一个
"取决于你的组织、基础设施或威胁模型"的决策点上，都故意留了白，
用一个醒目的标记标注：[NEEDS CLARIFICATION: ...]
（需要澄清）。整份规范里，这样的"待你填空"约有三十多处。
这不是规范"没写完"，而是它把"该由你决定的事"诚实地交还给你。 落地的本质，就是把这些留白，逐一替换成你自己的答案， 最终得到一份属于你、为你的技术栈量身定制的规范。
落地的核心动作。借助 Spec Kit 的 /speckit.clarify 命令，
AI 会逐一找出规范里的 [NEEDS CLARIFICATION] 标记，
把它们变成一个个问题向你提问；你回答后，规范被就地改写，
留白被你的决定替换。
蓝图是一套顶级西装的版型，但它故意留白了"袖长、肩宽、面料"。 澄清，就是裁缝拿着皮尺逐项量你的身材： "用 GitHub 还是 GitLab？用哪个大模型？有没有测试靶场？" 量完，才能裁出只合你身的那一套。
Cisco 给出了清晰的落地路径（来源：README.md §Getting started），
我们把它梳理成七个步骤。注意：第 0 步看似简单，却是官方最强调的一步。
官方原话："如果某条原则看起来不适合你的情况，答案往往是'我们还没踩到那个坑'，
而不是'那个坑在我这儿不会发生'。"（来源：README.md Step 0）
先理解 11 条铁律为何不可违背，再动手。
在你的项目里安装 Spec Kit；把 constitution.md 拷入
.specify/memory/，注册为后续每一步都要校验的"最高权威"；
再把 spec.md 拷入 specs/001-foundry/。
运行 /speckit.clarify，AI 会逐一向你提问约三十多个留白。
它们分为四组：身份与范围、集成选择、策略选择、扩展范围。
"我还不知道"对集成/策略是可接受的，但对身份与范围不可接受。
/speckit.specify 把澄清后的种子硬化成完整规范，状态从 SEED 变 DRAFT。
注意：硬化常会引出新的留白（例如你说"用 GitHub 企业版"，下一轮就会追问"API 端点是什么"）。
所以要重复"澄清↔硬化"，通常 2-3 轮，直到不再有留白、且通读全文都是"你自己做的决定"。
依次运行 /speckit.plan（技术设计）、/speckit.tasks（依赖有序的任务清单）、
/speckit.implement（逐项编码）。每个里程碑后跑 /speckit.analyze，
自动校验规范、计划、任务、代码与宪法是否漂移。
这些问题分为四组（来源：README.md Step 4 + docs/adoption/clarification-playbook.md），
建议按顺序作答——身份范围先定，它决定后面一切：
| 分组 | 典型问题 | 作答要点 |
|---|---|---|
| A · 身份与范围 最先答 |
系统叫什么名？是否"有源码+有授权"？8 个核心角色要合并/拆分/省略吗？ | 必须给出具体答案，不能"以后再说"。它塑造后面的一切。 |
| B · 集成选择 | 用哪个代码托管/工单？哪个 LLM？哪个数据库？跑在哪里？用什么隔离运行时？ | 种子描述的是每个集成的"接口契约"。"我们用 GitLab、一台 VM、Docker、SQLite"就是完整答案。 |
| C · 策略选择 | 严重度方案？弱点分类法（CWE？）？是否浮现"待复核"？标签如何命名？ | 尽量沿用你组织已有的惯例。 |
| D · 扩展范围 | 5 个可选扩展角色，各要不要？ | 官方建议：首次构建，五个全说"不"。先让核心跑稳。 |
最后，Cisco 在博客里给所有想部署前沿大模型的企业团队，留下了三条凝练的建议 （来源：博客 §"What this means for industry collaboration"）：
不要从零开始。采用像 Foundry Security Spec 这样 身经百战的架构。它构建于 GitHub Spec Kit 之上， 任何团队都能用可信、熟悉的开源协作模式去扩展和适配。
把过往漏洞、领域特定的测试靶场喂给 AI 当向导。 你把知识"种"进框架里，模型才会强大得多。 这正是 Cisco 把"多年领域知识"嵌入编排框架的做法。
用 AI 驱动的自动化，在类生产环境中验证发现， 确保只有被实证过的漏洞才被升级递交给开发者。 这正是"验证器"角色与宪法第 VII 条的精神。
🧭 一句忠告： 不要被"留白多、要迭代"吓退。官方说得很清楚—— 第一次澄清最难，大部分决策都在那一轮敲定；硬化引出新问题是正常的，不是缺陷； 两三轮收敛是常态。 但凡你认真走完，得到的将不是"别人的系统"， 而是三年后你的组织依然在运行的那个系统。
让我们回到第一章那辆 F1 赛车。
故事开始时，前沿大模型把一辆 F1 赛车的钥匙交到了整个行业手里。 但我们很快明白——光有引擎，菜鸟开不快，甚至会因为速度太快而把噪音放大成灾难。
而现在，走完这趟旅程，你已经握有了赢得比赛真正需要的三样东西：
前沿大模型——那台提供澎湃动力的加速器。模型会更迭，但它只是燃料。
Foundry Security Spec——8 个角色、11 条铁律、证据闸门构成的那条专业赛道。这才是真正的引擎。
你和你的团队——通过澄清量身定制、通过嵌入专业知识注入灵魂的驾驭者。
18 亿行代码、8 周、误报率低于 3%——这组数字不再是遥不可及的神话， 而是一个可被任何企业复制的方法论。因为正如 Cisco 所言：
"网络安全既是一项团队运动，也是一段长期旅程。
我们在这里，是为了让天平向所有防御者倾斜。我们同舟共济，永不止步。"
而衡量你是否抓住了这个时代价值的标尺，永远不是漏洞的数量， 而是规模化的可执行精度。 你的团队，不必再淹没在告警的噪音里。
尊重每一位读者，意味着建立共同的认知。以下是本文涉及的全部关键术语，
均提炼自 Foundry 官方文档（spec.md §2 / GLOSSARY.md / constitution.md）。
| 术语 | 英文 | 通俗解释 |
|---|---|---|
| 种子规范 | Seed / Spec | 一份"参考蓝图"而非可运行代码，需经澄清后变成你自己的规范。 |
| 宪法 | Constitution | 11 条不可违背的设计铁律，每条都对应一次真实的生产故障。优先级高于规范本身。 |
| 目标 | Target | 被评估的软件：它的源码，以及（可选）一个运行中的部署实例。 |
| 测试靶场 | Testbed | 目标的一个运行实例，智能体可对它进行探测与利用。可能不存在。 |
| 操作员 | Operator | 配置、启动、引导、停止整个评估的那个人。其指令权威高于一切智能体。 |
| 智能体 | Agent | 由大模型驱动、按角色在循环中工作的工作单元。 |
| 角色 | Role | 智能体的命名专长（检测器、分诊员……）。一个角色可有多个并发实例。 |
| 编排器 | Orchestrator | 操作员唯一的接口：管生灭、管预算、答疑、派活。两个互不阻塞的"门面"。 |
| 索引器 | Indexer | 构建代码的结构知识：符号、调用图、交叉引用。下游一切角色都要查询它。 |
| 制图师 | Cartographer | 绘制安全地图：架构、攻击面、信任边界、数据流、威胁模型。 |
| 检测器 | Detector | 广度优先地产出"候选发现"：规则扫荡 + 自由探索。故意高产、低精度。 |
| 分诊员 | Triager | 噪音过滤器：调查每个候选，凭证据闸门给出判定。 |
| 验证器 | Validator | 证明过滤器：在靶场上独立、洁净室式地复现影响，才能盖"已利用"章。 |
| 覆盖向导 | Coverage-Guide | 把目标拆成清单、追踪进度、宣布"覆盖完成"。"做完没"信号的一半。 |
| 报告员 | Reporter | 产出人类可读的报告与汇总：严重度、分类、复现步骤。 |
| 共享基质 | Substrate | 所有角色都依赖的非智能体机器：工作队列、发现库、沙箱、预算、仪表盘。 |
| 发现 | Finding | 任意生命周期阶段的"被声明的漏洞"，从候选到确认上报。 |
| 候选 | Candidate | 已被检测、但尚未调查的发现。 |
| 判定 | Verdict | 分诊员的分类：真阳性、假阳性、待复核、不适用、代码质量问题。 |
| 证据闸门 | Evidence Gate | 一个发现被判"真阳性"前必须满足的结构化要求：为可达性、信任边界、影响各提供可机械验证的代码引用。 |
| 已利用 | Exploited | 一个真阳性发现的标志：其核心影响已在靶场上被独立洁净室复现。只有验证器能设置，绝不靠推断。 |
| 指纹 | Fingerprint | 发现的稳定标识（路径+符号+漏洞类）。不含行号，以便代码改动后仍能去重。 |
| 检测规则 | Detection Rule | 针对某一漏洞类、可复用、有版本的检查项。规则语料库独立于智能体代码。 |
| 规则缺口 | Rule-Gap | 探索确认了一个真漏洞、却没有任何现成规则能抓到它——这就是"飞轮"成长的燃料。 |
| 覆盖 | Coverage | 评估目标被"可信地尝试过"的程度。"看了但没找到"也算覆盖。 |
| 产出率 | Yield | 按严重度加权的确认发现数 ÷ 单位花费，在一个滑动窗口内度量。 |
| 沙箱 | Sandbox | 围住智能体团队的隔离边界，由基础设施而非提示词强制执行网络与文件边界。 |
| CodeGuard | — | Cisco 原创、捐给 CoSAI 的开源检测规则格式。一份规则可同时用于"评估时检测"与"编码时预防"。 |
| Spec Kit | — | GitHub 的"规范驱动开发"开源工作流。提供 clarify / specify / plan / tasks / implement 等命令。 |
| 飞轮 | Flywheel | "检测→记录缺口→提炼规则→预防"的自增强循环。每转一圈，检测与预防能力同时提升。 |
| 可执行精度 | Actionable Precision | 每条交付的发现都经混合验证、附带证据，工程师拿到即可直接修复。Foundry 衡量价值的真正标尺。 |