Jiey 的设计思想 可以用一句话概括：声明意图，整体生成。你不再逐行去写「怎么实现」，而是把「要做什么」说清楚，剩下的样板与四端一致性交给确定的引擎。本文讲的是这套思路背后的取舍，而不是工具的具体用法。
逐行生成的天花板
让 AI 一行行写代码，问题不在「写得快不快」，而在三件事：
- 没有全局视角。 AI 写 Controller 时不一定记得三天前定义的状态机；前端表单和后端字段经常对不上。
- 结果不可复现。 同一个需求，换个 prompt、换个时间，产出可能完全不同——你在赌运气。
- 样板占了大头。 一个业务系统里 80% 是 CRUD、校验、归属判断、状态流转这类「写法固定」的代码。让最贵的脑力去手搓最机械的部分，是错配。
Jiey 的回答是：把可机械化的部分彻底机械化，把人的判断留给真正需要判断的地方。
四个核心取舍
1. 意图优先，而不是手写样板
你描述的是「系统要做什么」——有哪些实体、能发生哪些动作、给用户看哪些页面，而不是「这个 Controller 怎么写」。接口、请求体、状态流转、归属校验这些，是意图的自然推论，应该由引擎直出。你永远不必手写 Controller。
2. 一次声明，四端一致
后端、管理后台、移动端、官网，背后是同一份模型。改一处，四端同步重出。一致性不是靠人来回对齐对出来的，而是「生成方式」本身保证的——这叫 consistency by construction。手工项目里最容易出错、最耗人的「前后端对齐」，在这里根本不存在。
3. AI 负责理解，引擎负责产出
这是 Jiey 最关键的分工：AI 把你的话翻译成结构化意图，真正出代码的是确定的引擎。 所以产出是可预测、可复现的——不依赖某次 prompt 的灵光一现。AI 擅长「读懂你」，引擎擅长「不出错地产出」，各司其职。
4. 让一个人拥有一支团队的交付力
所有取舍最终服务于一个目标：把「实现广度」（写代码）压缩到接近零，让个人或小团队也能交付过去需要一整支团队才能做的系统。剩下真正吃功夫的「业务深度」——行业潜规则、现场调研、客户验收——才是人该花时间的地方。
它不解决什么（边界要诚实）
设计思想再好，也有边界：
- 业务深度仍然靠人。 引擎覆盖通用结构，但某个行业的特殊流程、某个客户的特殊规则，需要交付方现场打磨。
- 生产上线是另一回事。 SSL、备份、监控、合规，这些不在「生成代码」的范围里。
- 审美上限靠设计师。 生成的 UI 是「能用 + 好看」，要「惊艳」还得设计师介入。
Jiey 压缩的是「实现广度」，不是「业务深度」——把这条线讲清楚，才不会被夸大宣传带偏。
常见问题
这套思路有底层方法论支撑吗？
有。Jiey 内部用一套声明式建模方法（实体 / 动作 / 页面三类意图），保证从需求到四端代码的推导是确定的。但对使用者来说，你只需要会「把需求说清楚」，方法论由工具内化，不需要你去学规则细节。
跟传统 DDD（领域驱动设计）什么关系？
精神一致——都强调先把领域模型想清楚。区别在于：传统 DDD 是给人看的设计方法，落地仍靠人手写；Jiey 把这套建模变成可执行的声明，由引擎直接产出可运行代码。
为什么不直接让大模型端到端生成整个项目？
因为「可预测」比「偶尔惊艳」更重要。纯大模型端到端的产出方差太大、难复现、难维护。Jiey 把不确定的「理解」交给 AI，把确定的「产出」交给引擎，用工程手段把方差压下来。
我需要懂架构才能用吗？
不需要会写，但会读会让你用得更好。描述需求、做决策不需要架构知识；但要把生成的系统部署上线、跟客户系统对接，仍需要基础工程能力兜底。
提到的概念
- 声明式建模 — 用意图（实体 / 动作 / 页面）描述系统，而非手写实现
- consistency by construction — 一致性由生成方式保证，而非人工对齐
- DDD（领域驱动设计）— Jiey 建模思路的精神来源
评论 0