先说结论
Codex、OpenCode、Claude Code 我越用越觉得它们有个共同的盲区：它们都是"先写代码"的。 你把需求丢进去，模型开始疯狂调工具读文件、写代码、跑测试，最后甩给你一堆 diff。然后你要做一件非常累的事——看懂它到底干了什么、有没有跑偏、能不能合并。
代码写得越多，review 的成本越高。而"让 AI 写代码容易，让 AI 写的代码可信"难。
我做的这个工具 Jin 反过来了：先让 AI 产出"架构变更提案"，人审完这个提案、批准之后，它才允许动一行代码。 而且它实现代码时只把"跟这次改动有关的符号级代码块"喂给模型，不喂整仓、不让模型自己瞎搜。
下面对比一下几家，再讲 Jin 为什么是"先审架构"。
一、对比 Codex / OpenCode / Claude Code
先把它们的定位摆清楚，不吹不黑。
| 核心思路 | 强项 | 我踩到的坑 | |
|---|---|---|---|
| Codex（OpenAI） | 沙箱里本地执行 + 审批策略 | 安全模型做得好（seatbelt/landlock 沙箱、网络策略）、apply_patch 稳定、有 web_search | 默认信任度高、你还是要读 diff；长任务里上下文会漂，得手动 steer；"它为什么这么改"经常说不清 |
| OpenCode | 多 provider + 工具集 + 会话管理 | provider 广、工具全（glob/grep/todo/webfetch/诊断回灌）、会话可 share/undo、LSP 诊断给到 agent | 工具一多，模型容易"乱用工具"；改完你还是逐行 review；没有"先对齐意图再动手"的闸门 |
| Claude Code | 强模型 + 强工具 + 权限 | 长上下文、agentic 能力最强、hooks/子代理 | 一样是"先写代码"；审批是工具级（ask/allow），不是意图级；代码量一大照样读不过来 |
三家都很好，但它们解决的问题是让 AI 能干活、干得快、干得安全。它们都没解决我真正头疼的那个问题：
"我不信任 AI 一次性写对一大坨代码，我也不想在最后才发现问题。"
Codex 的沙箱解决的是"别把机器搞坏"；OpenCode 的工具集解决的是"干得全"；Claude Code 的模型解决的是"干得准"。但三者都是事后验收——代码写完了你才看到 diff。
二、Jin 的核心差异：把"验收"前移到"提案"阶段
Jin 的流程是：
扫描代码库 → 建立架构台账（L0/L1/facet）
↓
你提需求 → 模型产出"架构变更提案"（改哪些模块、加哪些符号、影响面）
↓
【人审这个提案】← 这里是关键闸门
↓
批准后才让 Eko 实现引擎写代码
↓
实现只用"符号级相关代码 + 既有诊断"做上下文，写完后自动跑 test/typecheck/lint，
失败就回灌给模型自修一轮
↓
版本化（WAL 可回放），每轮实现前打 git checkpoint，一键撤销
一句话："先对齐要改成什么样子，再对齐怎么改。"
1）不用怕看不懂
传统工具给你的是"代码 diff"，你得懂每行。Jin 给你的是架构提案：这次改哪些 L1 模块、增删哪些符号、影响哪些依赖。这是你本来就该关心的层级——你是架构师/负责人，不是来逐行读实现的。看懂"我要动这几个模块、加这个接口"比看懂 800 行 diff 快得多，也稳得多。
2）不漂移
漂移（drift）是长任务 AI 编程的头号杀手：模型写着写着就忘了需求、加了无关文件、改错地方。Jin 靠两个东西压漂移：
- 架构台账是"唯一事实源"。实现阶段的每个编辑都要落在提案批准的"文件白名单"里，越界直接拒绝。模型想在批准范围外加个"顺手"的 helper 文件？工具层直接拦。
- 上下文被收窄。实现时不是把整个仓库塞进去（那是漂移的另一大来源），而是用 LSP 符号索引只注入"这次要动的符号 ±40 行"，外加目标文件里既有的 LSP 报错/警告。模型看到的就是精确相关的那几块，不会"看着别的模块顺手改坏了"。
3）不用逐行 review 代码
因为你 review 的对象是提案，不是 diff。批了提案 = 你已经判断过"这个改动方向和范围是对的"。剩下实现阶段的正确性，交给自动的 test/typecheck/lint + 失败自修循环兜底。你看的是"检查是否全绿 + 架构是否长成了提案要的样子"（一致性校验），而不是逐行读实现。
三、它到底比"裸用 Codex/OpenCode"多做了什么
我列几个具体的工程点（都是我自己实现过的）：
- 架构一致性校验：实现完会重新扫描，检查"批准的 L0/L1/facet 是否真的落到位"，不只是"测试过了就行"。
- WAL 版本回放：每次实现是一个版本，可回放、可 diff 两个版本、可撤销到某个 checkpoint。
- 多 provider 一视同仁：OpenAI Chat/Responses、Anthropic Messages、Google Gemini、Ollama 都能接，模型预设表带上下文窗口和价格。
- MCP 工具是 agent 的一等公民：
mcp__server__tool直接进工具表，不用 UI 手动点。 - AGENTS.md 双层：项目级 + 全局，规划/实现提示词自动注入。
- LLM 诊断日志：JSONL 落盘 + 控制台，空流/工具不支持等错误能查到根因。
四、它适合谁，不适合谁
适合：
- 中大型项目、多模块、有明确架构边界（微服务、多 L1 域）
- 你是负责人/架构师，关心"改对地方"胜过"写得快"
- 需要可审计（谁在什么时候动了什么架构、为什么）
不太适合：
- 一次性脚本、demo、快速原型（架构台账的开销不划算，直接用 Claude Code 更快）
- 你完全不想做"提案审批"这一步——那这个工具的核心价值就没了
五、最后
AI 编程工具走到 2026 年，"能不能干"已经不是瓶颈，"敢不敢让 AI 在真实生产代码里自主改"才是。而"敢"的前提不是模型更强，是你把验收前移到了意图层——先审架构，再放行代码。
这是我做 Jin 唯一但最重要的设计选择。剩下的都是工程细节。
Jin 是一个面向架构的桌面 Coding Agent，支持 macOS/Linux/Windows。开源github.com/ZYF93/Jin，欢迎拍砖。
