把需求交给 AI，几分钟后代码就出来了。可真正让人头疼的，往往不是“它能不能写”，而是：它改对地方了吗？有没有重复造轮子？这次修改会不会悄悄改变模块之间的边界？
项目越大，这些问题越难靠一次代码生成解决。AI 看见的是当前能读取到的文件和上下文；而团队维护的，却是一套不断演进的结构、约定和历史决策。代码能运行，不等于它符合项目原来的设计。
先看影响，再让它动手
我在做 Jin 时，想尝试把流程反过来：不要一上来就生成代码，而是先把需求整理成一份可以审阅的变更提案。
Jin 会扫描项目，建立模块和文件层级的架构图；收到需求后，再说明哪些架构节点可能受影响、这些节点在项目里承担什么职责，以及建议的架构变化。用户审阅并批准之前，实施不会开始。
这样做不是要让架构图替人做决定，而是把原本藏在上下文里的影响摊开来。提案不对，可以先补充需求；影响范围不合理，也可以在代码生成前停下来。
生成之后，还要对账
代码完成并不代表流程结束。Jin 会重新扫描项目，检查实现是否与架构变更相符，并报告偏差。它也会在动笔前检索已有实现，尽量复用项目中已经存在的做法。
这仍然不能代替代码审查和测试。架构检查回答的是“实现是否和批准的结构变更一致”，不是“程序一定没有 bug”。但至少，需求、架构提案和实现之间多了一条能检查的线索。
适合什么样的项目？
如果你只是写一个一次性脚本，完整的架构审阅可能显得多余。如果项目有稳定的模块边界、多人协作，或者 AI 经常改到意料之外的地方，那么在写代码前看一眼影响范围，可能值得多花这一步。
Jin 是一个面向架构的桌面 Coding Agent。它支持 OpenAI 兼容接口和 Ollama；项目架构历史保存在 .jin/wal.jsonl，可以和代码一起通过 Git 审阅、合并。
它不是“让 AI 永远写对代码”的承诺，而是尝试让 AI 改动更可见、让人能在实施前介入。
项目主页与安装包：github.com/ZYF93/Jin
