KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
04 · 两个场景共同的五道护栏 — keel 龙骨
这一章回答：无论你在哪种场景，每天实际操作的那套动作是什么。
这一章回答：无论你在哪种场景，每天实际操作的那套动作是什么。
前面两章按场景分，这一章是五个常驻护栏，对应 vibe coding 最容易失守的五处：依赖、范围、一致性、验证、安全。
护栏一：依赖管理
- 一个一个加：每加一个依赖立刻安装并跑通，不要攒一批一起装。
- 版本写死：lock 文件必须提交；
latest、^这类浮动范围只在明确评估过风险后用。 - 先验证存在性：AI 给的包名，先确认它存在、有维护、版本可用（尤其警惕刚发布或已废弃的库）。
- 升级是独立任务：绝不允许"顺手升级依赖"。
护栏二：变更范围控制
在任务开始时就把边界写进提示词：
本次改动范围：只允许修改 A、B 两个文件。
禁止：重命名、重新格式化无关代码、调整目录结构、升级依赖、修改配置文件默认值。
如果确实需要超出范围，先停下来说明理由，等我确认。
这句话能省掉 review 里一半的无谓改动。review 时只看 diff，不听解释。
护栏三：代码一致性
| 风险 | 反制 |
|---|---|
| 风格漂移 | 指定样板文件 + 强制 lint / formatter |
| 命名混乱 | 让它先列出命名清单（模块、函数、事件、字段），你确认后再写代码 |
| 注释语言、日志格式不统一 | 在 AGENTS.md 里写死示例 |
| 会话久了开始跑偏 | 定期让它重述当前约定；约定变化立刻回写 AGENTS.md |
| 新旧实现并存 | 改完让它 grep 一遍旧实现的地方，确认没有留下双重逻辑 |
护栏四：验证
自下而上的四层，缺哪层补哪层：
- 能构建 / 能启动：最便宜的一道闸门，挡住语法与依赖错误。
- 项目自带校验：内容校验、发布卫生检查、路由生成脚本等。AI 不知道它们存在——你要把"跑一遍校验"写进验收。
- 主链路手工验证：一条你能亲眼看到结果的路径（页面能开、接口有返回、命令行有输出）。
- 自动化测试：关键逻辑单测 + 一个覆盖主流程的冒烟用例。
关键原则：让 AI 把验证输出贴给你，而不是让它说"已完成"。 它说完成和你看到绿色输出，是两件事。
由此推出一条组织级做法：CI 是规格的执行守卫。 定义了"什么是对的"（Spec、约定、lint 规则）之后，必须有一条自动化管线持续执行它。没有门禁的规格只是一纸空文——这也是为什么"本地一切正常但线上出错"这类问题会反复发生：缺的不是更聪明的模型，是一道跑在真实环境里的闸门。
在 review 环节，推荐三层过滤：
| 层 | 负责 | 产出 |
|---|---|---|
| AI 自检 | 格式、明显缺陷、与 Spec 的一致性 | 先看它自己的检查清单 |
| AI review | 过滤大量低价值问题（命名、重复、遗漏边界） | 机器稳定处理的部分 |
| 人工 review | 业务语义、架构判断、安全深度审计 | 人不可替代的部分 |
这样安排的效果是：AI 处理量，人处理判断。 review 时间下降，但质量反而更高。
护栏五：安全校验
- 密钥：只从环境变量/密钥服务读取，绝不写进代码、配置或日志。
.gitignore在项目初始化时就建好。 - 输入校验：所有外部输入都要有类型与边界校验，尤其会被拼进 shell、SQL、文件路径或模板的地方。
- 输出转义：渲染到页面或写入 Markdown/HTML 的内容做转义。
- 权限：新接口默认鉴权，需要公开要显式说明。
- 依赖安全：装完顺手跑一次漏洞检查；来历不明的包不要用。
- AI 自带的信息泄露：它可能把日志片段、配置内容、示例 token 直接写进代码或文档。产出前自己先扫一遍有没有敏感串。
为什么这一栏不能省：LLM 生成带漏洞代码的比例，在不同基准下测得 9.8% 到 42.1%；到 2026 年初，生产仓库中由 AI 引入且尚未修复的问题已累积到六位数。 这些数字在不同口径下差异很大，但它们共同指向一件事：AI 生成代码的安全性不能靠假设，只能靠检查。
一道通吃的验收清单
交付前逐条打勾：
- 改动文件清单是否在约定范围内？
- 依赖有没有新增或升级？有就说明原因。
- lint / 构建过了吗？
- 项目自带的校验脚本过了吗？
- 主链路手工跑通了吗？
- 失败路径有没有处理（超时、空值、权限、依赖不可用）？
- 日志和错误信息里有没有敏感数据？
- 如果要回滚，回滚点在哪？
动手：可观察结果
把这五道护栏落到你的项目里，产出：
| 产出 | 判断标准 |
|---|---|
| 一条"验收命令" | 一条命令同时覆盖 lint + 构建 + 项目自带校验 + 冒烟 |
| CI 配置 | 每次 PR 自动执行上面那条命令，失败不可合并 |
AGENTS.md 更新 |
五道护栏写进去，成为常驻上下文 |
| 一次失败演练 | 故意提交一个违反 lint 的改动，确认 CI 拦住了 |
完成标志：你可以在不看 AI 输出的情况下，靠一条命令判断这次改动能不能合。
故障注入
| 注入方式 | 观察 |
|---|---|
| 删掉 lock 文件重新安装依赖 | 看多少次会因为上游版本变化而失败 |
| 让 AI 修 bug 时不给范围句 | 数 diff 里有多少无关文件 |
| 在 CI 里关掉 lint 步骤 | 一周后统计代码风格漂移的规模 |
| 故意让某个外部依赖超时 | 看有没有优雅降级，还是直接 500 |
| 把密钥硬编码进配置文件提交一次 | 验证 .gitignore 与扫描是否真的拦得住（在练习仓库做，别在生产仓库） |
自测题
- 为什么"CI 是规格的执行守卫"？没有 CI 的 SDD 缺了什么？
- 三层 review 中，为什么人工层应该聚焦在业务语义、架构判断和安全，而不是格式？
- 你的项目里，那条"验收命令"是什么？如果现在说不出来，这周先把什麼补上？
- 变更范围限制句里，为什么"禁止重命名和重新格式化"要单独写出来？
- 举一个 AI 可能引入的敏感信息泄露场景，以及你会用哪道工序拦住它。