大家好，我是隔壁老胡，MortiseAI 创始人，驾驭 AI Coding 是我的专长，让每个人都能玩转 AI Coding 是我的初心~
MortiseAI 希望在 AI 时代，每个人依然能捕获并放大自己的独特价值 - 不只是更快写代码，而是把你的经验与判断沉淀为可复用的 Know-How，让你在能力趋同的未来，依然拥有不可替代的竞争力。
前沿
今天各种 AI IDE 已经能够帮助我们写代码了，但是 AI 真能已经能够帮助我们达成用工具解决问题的目标了吗？
大家刚开始用 AI 写代码的时候，应该都会遇到这种情况
- 明明已经给了明确的指示，但是它就是不按照指示去做
- 或者不停在修改，就是总是无法彻底解决错误，自己又无能为力
- 又或者越改越来越乱，需要修改错误结果把正确修改错了
最近有一个社区传播比较广泛的图，估计也是大家经常能遇到的窘境，揭露了当下 AI 编程不一定好用，经常出现纰漏
我们认为问题的根源不在于 AI 不够强，也不只是人与工具协同没做好。更关键的是：从第一行代码起就跑偏了——软件的设计与代码结构，本质上既不“AI 友好”，也不“人友好”。
就像我们手里明明是一台 F1 级赛车引擎，却硬要装进一辆老头乐里去跑比赛；最后跑不起来，不是引擎不行，而是底盘、结构与规则从一开始就错了。
如果我们能轻松搭起一套既 AI 友好、也人友好的软件地基，会是什么体验？
你会发现：从第一行代码起就不再跑偏，AI 不用猜、人不用扛；改动可控、结构清晰、迭代越做越稳，交付像装配线一样顺滑。
思考
当你把 AI 友好的顶层设计做对、把工程地基打稳，其实就已经完成了一个专业级项目 80% 的工作。
剩下的 20%，不再是“救火式补洞”，而更像是按图装配——清晰、可预测、好推进。
那什么才叫 AI 友好的项目？
重要的事情说三遍：规则，规则，规则
更通俗点：让项目拥有一套可泛化的规则，让 AI 和人都“有章可循”。从架构角度看，就是在做一个选择：深设计 vs 浅设计。
- 深设计：只暴露少量、必要的入口（接口清晰、边界明确），复杂性被收纳在结构里。
- 浅设计：暴露大量不必要的细节（到处都能改、到处都能插），复杂性摊在地面上。
打个比方：
深设计像一团乱麻被装进了一个箱子里，外面只留一个线头。你只要拉对这个线头，就能把线团顺着规则拉回到“完整、有序”的状态。
浅设计则是把乱麻直接摊在地上，你得在噪音和干扰里自己找线头 — 越改越乱，AI 也越写越偏。
所以，AI 友好不是“让 AI 更聪明”，而是让系统本身更有规则、结构更清晰易懂。
为此，我设计了一整套 SOP，把“专业软件工程” 变成一条可复制、可落地的标准化流程：
- 如何保证 AI 不乱写？ — 任务拆解式智能编程，把复杂需求拆成可验证的小任务，让生成过程高质量、可控。
- 如何让结果可控、可复盘？ — Spec 文档即代码，先把规则写清，再让代码按规则生长，实现可治理、可追溯。
- 如何支撑长期演进？ — 组件化工程架构，用清晰边界和可组合组件承载变化，让系统灵活、可维护、可演进。
- 如何形成长期壁垒？ — 领域 Know-How 资产化，把经验沉淀成可复用的规则与方案库，让能力可复用、可增长。
如何保证 AI 不是乱写
任务拆解式智能编程，把复杂需求拆成可验证的小任务，让生成过程高质量、可控。
在我们的 AI 编程实践中，我们发现，把需求一次性交给大模型，往往会带来一连串系统性问题：
- 上下文管理失控：信息太多，模型抓不住重点，容易“跑偏”。
- 过程无反馈：中间不可见、不可控，最后才发现方向错了。
- 局部无法调优：想“只改这里”，却牵一发而动全身。
- 迭代像重开一局：每次升级都像从 0 再生成一次。
- 高度依赖模型能力：多文件或者大段生成成本高。
因此我们换了一个视角：用“上帝视角”的 Workflow 来组织工程。
它让你先看清全局、再控制细节：一方面能整体把控工程全貌，另一方面可以对局部进行精准调优，不再把项目交给模型“盲写”。
具体做法是：先拆解，再生成。
面对复杂业务需求，我们不做“一锅端”的整体上下文管理，而是先把需求拆成可验证的小单元——小组件 / 小任务。在这一步，其实就已经完成了组件化拆分：边界清晰、入口明确、规则可复用，后续生成与迭代才能真正可控。
这样一来，我们就把“一个复杂大问题”，拆成了一组任务单一、边界清晰的子问题，带来三个直接收益：
- 边界隔离：组件之间相对独立，一个组件的改动被限制在自身范围内，不会牵连全局。
- 迭代更轻：升级不再是“重做整套”，而是围绕某个组件的小步优化，需求更小、试错更快。
- 模型门槛更低：组件级任务远比项目级简单，对模型能力要求大幅下降，Qwen、DeepSeek 这类开源模型也能稳定胜任，成本可控、没有 token 焦虑。
如何让结果可控、可复盘
Spec 文档即代码（可治理、可追溯）
为每一次开发建立长期稳定的起点，让需求可治理、可追溯。
程序员里有个段子：代码写到最后，防御性编程防住了所有人 — 也把自己防御住了。
在传统软件开发最大的敌人，其实不是“功能做不完”，而是精力和时间被不断消耗：
当代码之外没有足够的额外记录（规则、意图与决策），时间一久，无论是最初写代码的人，还是后来接手的人，都会在“为什么这么写、当时想解决什么、改了会影响哪”里反复踩坑，付出成倍的沟通与理解成本。
但在传统软件开发中，文档也有它的老问题：发布即过时， 如果想让系统真的能长期维护，就必须解决关键一环：让文档跟着代码走。
没人天生喜欢写文档，尤其是专业文档。所以我们的解法不是“逼大家写”，而是把文档变成自动生成、自动演进的流程产物 — 你不需要从零搭建，只需要在必要时做微调。
换句话说：只修不建
- 将需求自动化拆解、工程级 Spec 文档，0 门槛启动
- 统一 Spec 规范，覆盖所有组件与模块，无需重复学习
- 支持代码逆向生成 Spec，文档随代码演进，永不过期
- Spec 即 Code，他人可直接理解并复现系统
如何支撑长期演进
组件化工程架构（灵活、可维护、可演进）
灵活、可维护、可演进的独立组件
一个 AI 友好的代码项目，不只需要一份清晰的“行动指南”，更需要一套能支撑软件全生命周期的顶层架构。而这一点，恰恰是当下最容易被忽略的。
我们在 Vibe Coding 黑客松里反复看到：决定胜负的关键，从来不是点子有多炫、模型有多强、工具有多新。真正拉开差距的是顶层设计。很多高分项目并不是换了更强的模型，而是 Vibe Coder 用自己熟悉的模型与工具，先打磨出一套独有且可复用的架构方案，然后再把创意稳稳落地。
这给了我们一个非常明确的启发：在 AI Coding 的长期演进里，除了“模型”和“工具”，还必须补上第三块核心拼图，AI 友好的基础架构体系。它决定了项目能否从“能跑的 Demo”，走向“可控、可迭代、可交付的专业工程”。
所以，我们基于对 AI 能力边界的长期实践与验证，构建了一套“应用胶水层”框架 MortiseSpecCodeEngine（MSC Engine）。它的目标很简单：把复杂度收纳进规则里，让 AI 和人都能按同一套结构稳定协作、持续演进。
MortiseSpecCodeEngine : github.com/MortiseAI/m…
MSC Engine 由 4 个部分组成：
- View 视图组件：专注于 GUI 的拆解与重构：把界面拆成多个独立视图单元，支持灵活组合、独立开发与复用。
- Logic 逻辑组件：负责数据处理与业务逻辑封装：遵循 RPD（业务需求驱动），将数据库操作、网络请求、第三方 SDK 集成等能力沉淀为可复用的逻辑单元，与 View 解耦，支持独立迭代与测试。
- Workflow 流程组件：负责“编排与联动”：监听 View / Logic 发出的事件，并将其转换与路由为对应组件的触发与响应事件，让交互流程可视化、可控、可调优。
- DSL 配置组件：Mortise DSL（领域专用语言）用于将 View/Logic 与 Workflow 灵活组装以适配不同业务场景。每个 DSL 实例唯一对应一个业务模块（Module），一一映射，实现模块级的高灵活、可配置与可演进。
这是一套“胶水层”架构：通过通用结构的组件化组装与统一的事件机制，实现组件之间高效、可控的交互与通信，从而让 AI 智能体能够在清晰边界与规则约束下，自动编排并完成复杂软件项目的代码编写与交付。
看看起来很专业？确实很专业。
但你不需要学会具体代码怎么写 — 你只要掌握关键的编程思维与工程概念，就能驾驭 AI 做真正的严肃开发。
更进一步，我们基于这套“胶水层”设计了一组易用的 Spec 指令：即使不了解代码细节，你依然可以像“指挥家”一样，对项目进行测试、定位、修改与迭代 — 做到只修不建、改动可控。
如何形成长期壁垒
领域 Know How 资产化（可复用、可增长）
构建私有可复制、可规模化的解决方案平台。
今天我们在享受 AI 编程带来“更快实现”的同时，更重要的一件事是：用 AI 重建自己的独特优势。因为在 AI 加持下，所有能力会被快速拉平；真正决定长期价值的，是你是否拥有可复用、可交付、可持续演进的 Know-How。
所以我们更希望帮助用户把 Know-How 变成“工程资产”，沉淀成一套可增长的能力体系：
- 无限画布 · 节点化 Workflow：把文档、RAG、Agent、SLM、源码等多形态能力，统一抽象为可组合、可复用的节点。
- 基于节点的增量演进：新需求不再从 0 开始，更多是在既有节点能力上叠加与演进。
- 经验即工程资产：把个人与团队经验，转化为可迁移、可复用、可规模复制的工程能力资产。
AI 时代技术领域 Know How 与传统方式最大的不同是，可以直接面对结果进行交付，例如传统的技术文档，直接转换为结果，是消耗大量的人的精力的去理解内容，然后转化为实际场景的需求，所以在整个链路上面，内容提供者反而收益极低，像某知名 CSDN 博主 3W+粉丝，400 篇文章，收益 0.4 RMB，平均一篇文章的收益 0.01 RMB，而对标海外外包 Upwork/Fiverr 海量 BugFix 0.51 小时的价格 510$，所以未来 Know How 基于 AI 直接交付结果
市场也是很广阔的，我们以 NPM 4400亿/月调用为基准，将全球软件 Library 封装为一键可用的 AI Solution Packs，覆盖多端平台；按 $1 单价、20%商用率保守测算， 市场规模 4W 亿，增长空间广阔。
结语
很多 AI Coding 的“真问题”，就像冰山在水下——它不会直接暴露，而是伪装成另外一种表象。
我们常把失败归咎于“工具和人协同不够”或“描述不够精确”。于是看起来像是：AI 已经很强了，但你没说清楚，它只能靠猜，所以才写偏、写乱、改不动。
这恰恰是当下 Vibe Coding 的典型陷阱：当下的 AI IDE 确实提供了不少约束手段，比如 Cursor Rules、CLAUDE.md、AGENTS.md、Agent Skills……这些配置能有效解决代码层面的基础规范问题，用来“管住 AI 别乱来”。但它们更多是在约束生成行为，而不是在解决“从需求出发，打好顶层设计基础，稳定产出” - 两者之间仍然隔着很长的距离。
于是，最近开始兴起一种新范式：规范驱动开发（Spec-Driven Development, SDD） 。它试图颠覆 Vibe Coding 的“代码先行”，把 Spec 放到流程中心：先产出结构化规范，再由 AI Agent 按规范去生成、验证、迭代代码。
这确实是 AI 友好化编程的一个重要端倪。但它也只是“看见了方向”，还没触及根因，如果底层工程结构、边界与规则体系本身不成立，那么即使有 Spec，仍然容易变成：规范写得很美，落到代码依旧失真，迭代依旧不可控，规模化依旧困难。
立即体验 MortiseAI
MortiseAI Alpha 版本公测中，免费免激活，仅支持 Mac 和 React 编程语言。
MortiseAI 官网下载页面：
实践教程：
Mortise Spec Code Engine（TypeScript/React）GitHub 地址：
