Scryer 完全指南：用模型驱动开发让 AI 编码代理不再盲目
AI 编码代理（Claude Code、Codex 等）写代码的速度远远快于你 review 的速度。结果是：代码在 shipped，但你对自己代码库的理解在 drift。你原本的架构意图和最终交付的代码之间出现了偏差，而且这种偏差随着每次 agent 提交而扩大。
Scryer 用 模型驱动开发（Model-Driven Development） 的方式解决了这个根本矛盾。它不是在代码之上再加一层抽象，而是在代码旁边维护一个 责任模型（Responsibility Model）——描述系统的每个部分负责什么，以及这些责任映射到哪些源代码行。
核心理念：模型在前，代码在后
Scryer 的核心哲学可以概括为：The model leads; the code follows.
与传统架构文档不同，Scryer 的模型不是 UML 图，也不是代码的框线图再绘制。它基于 C4 模型（Person → System → Container → Component → Operation → Process → Model）的层级结构，每个节点承载：
- Responsibilities（责任）：该组件应当做什么，使用语言无关的自然语言描述
- Directives（指令）：可选的具体实现指导，如”使用 JWT 进行认证”
- Source Mapping（源码映射）：每条责任对应到具体文件和行号范围
代码始终是”怎么做”的真实来源（source of truth for how），而模型是”为什么做”的真实来源（source of truth for what）。
安装与快速开始
Scryer 提供了各平台的预编译二进制文件。下载最新 release 后直接运行：
tar -xzf scryer-*.tar.gz ./scryer
首次启动时，关联你的项目目录并启用 AI 工具集成：
scryer-mcp init
这条命令会自动检测你的环境中的 Claude Code 和 Codex，写入 MCP 配置文件并设置 auto-approve 权限。
典型工作流
Scryer 定义了一套完整的工作流程，从建模到实现再到验证：
第 1 步：引导 Agent 扫描代码库
启动 Scryer 后，直接对你的编码代理说：
“Use scryer to model this project’s architecture.”
Agent 会读取 .scryer/model.scry 文件，扫描你的代码库，将识别出的组件、容器和符号填充到模型中。你会看到节点实时出现在 Scryer 的 UI 树中。
第 2 步：Review 并优化模型
模型生成后，在 Scryer 的 Wiki-style node pages 中逐页审查每个节点：
- 调整节点名称和分组
- 修改或补充 responsibilities
- 添加 implementation directives
- 检查 source mapping 的准确性
Scryer 的 UI 支持就地编辑（inline editing），每个修改立即反映在 planned draft 中。
第 3 步：在模型中规划变更
要做一个变更，先在模型中规划。例如添加一个新的认证中间件：
- 在模型树中创建新节点（
Middleware > AuthMiddleware） - 添加 responsibility：”处理所有 /api/* 路由的 JWT 验证”
- 添加 directive：”使用 jsonwebtoken crate，RSA256 算法”
- 定义与现有模块的关系
这些 pending 的变更进入 planned.scry 文件，与 model.scry（committed model）的 diff 就是 plan——待实现的模型→代码工作队列。
第 4 步：让 Agent 实现 Plan
告诉你的 Agent：
“Implement the plan in scryer.”
Agent 通过 MCP 读取 plan，逐个实现节点，每完成一件就调用 MCP 工具更新模型，将 planned 节点折叠到 committed model 中。Scryer 的 MCP server 提供了丰富的读写工具：
读取工具：get_model（获取完整模型）、get_changes（获取与上次读取的差异）、validate_model（验证 C4 规则一致性）
写入工具：add_nodes/update_nodes/delete_nodes（增删改节点）、add_edges/update_edges/delete_edges（管理关系）、set_groups（分组管理）、update_source_map（链接源码映射）
实现工具：get_task（获取按依赖排序的下一个实现任务）、set_implementing（暂停/恢复漂移检测）
第 5 步：持续漂移检测
Scryer 有一个 always-on 的确定性观测层（no LLM），持续监控源码变化与模型的匹配情况。你可以随时检查模型健康状况——get_health 会报告计划进度、drift 汇总、源码锚点覆盖率，以及代码与模型的分歧点：
- Plan and drift rollup
- Source-anchor coverage（源码锚点覆盖率）
- Import-graph audit（检查声明的链接与实际 imports 是否一致）
支持的解析语言包括 Rust、TypeScript/JavaScript、Python、Go、Java、Ruby、C/C++、C# 和 PHP。这意味着 drift 检测覆盖了绝大多数现代技术栈。
关键特性详解
MCP Server — 与所有 Agent 框架兼容
Scryer 内置了 MCP 服务器。任何支持 Model Context Protocol 的编码代理都可以连接到它读取和修改模型。Claude Code 和 Codex 开箱即用；支持 ACP（Agent Client Protocol）的代理还可以被 Scryer 直接启动用于自动化构建和 drift sync。
实时组件预览
对于 React/TSX 视觉组件，Scryer 通过 per-project Vite dev server 实现确定性渲染——无 agent 介入，无 per-component build。你可以直接在 Scryer UI 中预览组件的外观，prompt 变体并比较渲染结果。
从零构建模型
对于已有项目，你不需要手动创建模型。告诉 Agent “Use scryer to model this project’s architecture”，它就会自动扫描代码库并生成 C4 层级的初始模型，你后续只需要 review 和微调。
适用场景
Scryer 在以下场景中特别有价值：
- 大型重构项目：需要在多个模块间协调变更，模型清楚地显示每个变更的影响范围
- Agent 驱动的持续开发：团队依赖 AI 编码代理进行日常开发，需要保持架构一致性
- 跨语言项目：模型的责任描述是语言无关的，可以跨越重写（如从 Python 迁移到 Rust）
- 新人 onboarding：模型提供了比文档更精确的项目架构入口
小结
Scryer 解决的不只是”Agent 写错代码”的问题——它解决的是 “你不知道 Agent 写的代码对不对” 的根本问题。通过维护一个代码旁边的责任模型，Scryer 让模型始终走在代码前面，让架构意图不再是口头约定或过时的设计文档，而是 Agent 每天读取和遵循的活文档。
如果你是 Claude Code 或 Codex 的重度用户，值得花一小时体验 Scryer 的模型驱动工作流——它可能改变你对 AI 代码生成的信任方式。