本文只讲思考和方法，不涉及任何公司细节。所有结论都来自一个真实系统的反复碾压：几百次全量测试、以十亿计的 token。

一、陌生系统的恐惧

每个工程师都接过这种活：一个（或几十个）陌生系统摆在你面前，文档过时、口径不一、当初写代码的人早就走了。老板说"你先熟悉一下"，于是你开始了一场地道战——翻代码、猜意图、找人问、被误导、再翻代码。

三周后你说"我大概熟了"。其实你只是把几个核心模块看熟了，全貌永远在雾里。

我一直在想：“看懂一个系统"这件事，能不能像 CI 一样，变成一条流水线？ 输入是一个仓库，输出是一份可审计、可复核、结构稳定的系统画像。

这篇文章就是我的答案：一个系统级扫描 Skill。但我不想讲它"长什么样”，我想讲造它的过程中，我撞碎的三堵墙——这三堵墙，才是所有 AI 工程化都会撞上的真问题。

二、第一堵墙：一次对话装不下一个系统

最天真的做法是：把代码塞给大模型，让它"分析一下这个系统"。

试过就知道，这在玩具项目上都勉强，在真实系统上直接报废——上下文窗口装不下，硬装进去的结果就是浅：每个模块都被"概括"成一句正确的废话。

解法是把扫描拆成分层流水线：系统级 → 项目级 → 模块级 → 代码级，每层只回答自己这层的问题。这套分层在我的 Skill 里被压缩成了一句话，也是整个系统的总纲：

系统级定世界观，项目级定工程画像；模块专题横向看能力，代码链路纵向追执行。

系统级和项目级是竖向的分层（先世界观，后画像）；模块和链路是横向与纵向的两种切入——横着看一个能力面，纵着追一条执行线。四层关系、两种视角，一句话装完。

这里的关键设计是子 Agent 隔离：每个子任务在独立的上下文里跑，主 Agent 只拿结论和指针，不被细节淹没。

这和我处理报错信息的习惯一模一样：整个堆栈不用进主线程，关键行 + 位置指针就够了。主 Agent 需要回溯证据时，顺着指针回去找。

人脑的注意力很贵，模型的上下文也很贵。隔离不是技巧，是纪律。

三、第二堵墙：提示词的约束力会衰减

流水线跑起来之后，很快撞见第二堵墙：跑到后面几个项目，输出开始缺斤少两。

提示词里明明写了"必须包含 XX 章节"，第一轮跑得好好的，第五个项目开始，章节丢了、格式漂了、口径变了。光看结构就能发现问题。

原因很本质：提示词是概率约束，代码是确定约束。 长链路任务里，“请务必输出完整格式"这种话的约束力逐轮衰减——模型每次都"尽量遵守”，但"尽量"乘以几十个项目，就是稳定的漏检率。

解法只有一个：凡是能用代码检查的，绝不用提示词约束。

所以我的 Skill 里有一整套 contracts——每种文档的输出结构都定义成 JSON schema：章节顺序、元数据枚举（证据状态只能是"已确认/待确认/证据不足"）、证据数量下限、敏感信息检查。模型每产出一版，校验器硬校一遍，缺章、跳序、证据不足，当场打回重写。

我把这个过程叫给 AI 立法。提示词是"建议"，脚本才是"门禁"。

立法就要有法条。我的 Skill 里最硬的几条法条长这样，直接引原文：

  • 不要把"源码中存在"理解成"生产环境启用"。
  • 高风险断言必须降级：没有运行态材料或人工确认时，“生产启用"“完整链路"“已完成"一律不许写成强事实，只能写"源码视角已完成，运行态待确认”。
  • 每个结论都必须给出证据；无法证明的内容标记为"待确认”。
  • 下层分析必须继承上层结论；发现冲突，标记"冲突待复核”，不许静默改写上层世界观。
  • 层级放行必须执行校验脚本，不要只靠模型阅读状态表自行判断。

注意最后一条——连"能不能进入下一步"都不让模型自己说了算。模型可以建议，脚本才算数。

四、第三堵墙：一个模型不值得信任

第三堵墙最反直觉：生成内容的人，不能兼任验收的人。

同一个模型生成又自检，错误是相关的——它理解错的地方，自检时大概率还是用同样的方式理解错。所以我给流水线配了完整的分工：

  • 强模型当"编译器"：我先跟它聊透我的想法，让它产出提示词 + 验收标准——贵的 token 只烧一次，烧在把意图变成规格的环节；
  • 便宜模型批量执行：拿着规格去跑几十个项目的扫描，量大不心疼；
  • 异构模型验收：拿着验收标准判卷——换一家模型，盲区不重叠；
  • 我抽检：每周随机抽几份"验收通过"的报告人工复核，给整条流水线校准误差率。

生成、执行、验收、抽检，每一层都在防上一层的错。这就是工程里的信任原则在 AI 时代的原样复刻：不因为某个组件"看起来很聪明"就免除它的检查。

还有一个我坚持至今的习惯：每个阶段结束后，新起一个对话，让模型以评判者的身份找当前方案的毛病。 原对话里的模型是"共犯"——它记得自己推荐过什么，会不自觉地辩护。新对话没有历史，没有立场，只有"这个东西现在长什么样"。

五、并行边界：依赖关系说了算

流水线跑通后我嫌它慢，想过全量并行。最后得出的结论是：

项目级可以并行（彼此独立），系统级必须串行（要等所有项目结果才能收尾）。

后来我才反应过来，这就是 MapReduce——Map 阶段随便切，Reduce 阶段必须等齐。依赖图里没有箭头的地方，才是可以并行的地方。并行度从来不在"你想不想"，在数据依赖允许不允许。

工程上所有看起来很新的问题，翻到最后都是老问题换了件衣服。

六、几十亿 token 买来的认知

这套东西不是设计出来的，是打出来的。几百次全量测试、以十亿计的 token 消耗——每一个校验字段背后，都对应着某一次真实的"缺斤少两"。

如果有人问这套 Skill 的核心竞争力是什么，我的答案不是提示词写得好，是：它被几百次失败反复毒打过，而且每次失败都被固化成了门禁。

这大概就是 AI 工程化和"玩 AI"的分界线：玩 AI 的人在比谁的提示词妙，做 AI 工程的人在给 AI 建证据、门禁和审计。前者产出演示，后者产出系统。

七、写在最后

回到最初的问题：“看懂一个系统"能从手艺变成流水线吗？

我的答案是能，但代价是把所有"信任 AI"的念头全部掐死：不信它的自觉，只信可校验的产出；不信单次的结果，只信多层的互验；不信它的记忆，只信写在仓库里的契约。

听起来很无情，但这恰恰是让 AI 真正可靠的方式——就像工程化从来不信任人的记性一样。

扫描如是，排查如是，以后所有 AI 参与的关键路径，都如是。

相关阅读：《生产排查，不该是"老师傅"的手艺》——同一套思想在生产事故场景的应用。