AI开发范式科普
我不用 IDE 写代码,而是用 Markdown 写文档。我要做一个“个人中心”,我就先写docs/modules/个人中心/架构设计.md。我在文档里用自然语言描述:“头像要圆形的,数据从接口拿(参考刚才 AI 提取的 API 映射表),如果没头像就显示默认图。
我是如何一行代码不写,用 AI 开发出专有钉应用的:揭秘“长短期双记忆”开发法
前言:在这个 AI 爆发的时代,编程的门槛正在被无限降低。作为一个拥有丰富经验的开发者,我并没有被 AI 取代,而是选择进化。在本项目中,我挑战了全过程不亲手写一行代码,而是将自己升级为“系统架构师”与“AI 指挥官”。通过构建一套独特的**“长短期双记忆”**系统,并利用 Antigravity 的自动化能力,我将开发节奏提升到了前所未有的速度。本文将为你揭秘这种“降维打击”式的开发范式。
🧠 核心理念:AI 的“外挂大脑”
很多人用 AI 写代码,只是把它当作一个“搜索工具”或“代码补全器”。但我把 AI 当作一个拥有无限算力但需要精准指令的超级工程师。
为了驾驭这个超级工程师,我必须具备深厚的架构功底,并设计了一套**“长短期双记忆” (Long-Short Term Dual Memory)** 架构。
1. 长期记忆 (Long-Term Memory) —— 项目的“灵魂”
这是存储在硬盘上的文档库(docs/ 目录)。它不是废纸堆,而是项目的数字孪生。它包含了:
- 全局记忆:
UI设计规范.md(界面的法律)、专有钉API映射表.md(能力的边界)。 - 模块记忆:
docs/modules/下的独立文件夹。比如“消息系统”模块,就有专门的架构设计.md,详细规定了 WebSocket 怎么连、消息怎么存。
这就好比给 AI 准备了一座图书馆,它随时可以查阅项目的“宪法”和“法律”。
2. 短期记忆 (Short-Term Memory) —— AI 的“工作台”
这是我与 AI 对话的上下文窗口。每次开始任务时,我不会直接说“帮我写个聊天功能”,而是先做**“记忆加载”**:
“请阅读
docs/modules/消息系统/架构设计.md和docs/design/UI设计规范.md,基于这两份记忆,帮我实现聊天页面的前端代码。”
通过这种方式,我把“长期记忆”临时加载到了 AI 的“短期记忆”中,确保它生成的每一行代码都严格符合我的设计规范。
🧩 模块化记忆:像搭积木一样开发
为了防止 AI “幻觉”或逻辑混乱,我采用了模块化记忆 (Modular Memory) 策略。
我将整个复杂的专有钉应用拆解为独立的模块:
- 📂
docs/modules/登录认证 - 📂
docs/modules/消息系统 - 📂
docs/modules/通讯录 - …
每个模块都是一个独立的“记忆胶囊”。当我开发“通讯录”时,我只让 AI 读取“通讯录”的记忆胶囊。
这样做的好处是:
- 专注:AI 不会被无关信息干扰,注意力高度集中。
- 隔离:即使“消息模块”改乱了,也不会影响“登录模块”的稳定性。
- 复用:通用的记忆(如 UI 规范)可以被所有模块反复加载。
🛠️ 实战工作流:我的“极速”开发五部曲
在这个模式下,我的角色从“码农”变成了“产品经理”兼“架构师”。我的日常工作流是这样的:
第一步:自动化知识摄入 (Automated Knowledge Ingestion)
这是我与传统开发最大的不同点。面对晦涩难懂、成百上千页的专有钉官方文档,我不再人工阅读。
- 操作:我使用 Antigravity 的浏览器代理 (Browser Agent) 功能,直接把官方文档链接扔给它。
- 指令:“请阅读这个网页,分析其中的‘用户获取接口’和‘部门列表接口’,并按照我们的 Markdown 格式提取到
专有钉API映射表.md中。” - 结果:AI 自动帮我“吃透”了文档,并转化为了项目可用的长期记忆。这不仅极快,而且避免了人为遗漏。
第二步:定义记忆 (Define Memory)
我不用 IDE 写代码,而是用 Markdown 写文档。
- 我要做一个“个人中心”,我就先写
docs/modules/个人中心/架构设计.md。 - 我在文档里用自然语言描述:“头像要圆形的,数据从
/api/user/info接口拿(参考刚才 AI 提取的 API 映射表),如果没头像就显示默认图。”
第三步:注入记忆 (Inject Context)
打开 AI 对话框,输入指令:
“你现在的任务是开发个人中心。请先阅读
docs/design/UI设计规范.md了解设计风格,然后严格按照docs/modules/个人中心/架构设计.md的逻辑,生成mine.vue的代码。”
第四步:AI 执行 (AI Execution)
AI 会瞬间吐出几百行完美的代码。它知道主色调该用什么(来自 UI 规范),知道接口该怎么调(来自架构设计)。
作为资深开发者,我不再陷入语法细节,而是专注于 Code Review,确保 AI 生成的代码符合架构规范和最佳实践。
第五步:记忆修正 (Memory Refinement)
如果运行报错了,或者效果不对(比如头像不是圆的),我绝不直接改代码。
我会回去修改文档:
修改
架构设计.md:补充一条规则——“头像组件必须使用border-radius: 50%”。
然后告诉 AI:“记忆已更新,请重新生成代码。”
代码是架构的具象化表达;通过修正文档(记忆),我从源头控制代码质量,确保系统逻辑的严密性。
� 为什么说懂代码依然至关重要?
虽然我强调“不亲手写代码”,但这并不意味着编程知识无用。相反,越是使用 AI,越需要深厚的技术积淀。
- 安全与性能的守门人:AI 可能会生成功能跑通但存在 SQL 注入风险或内存泄漏的代码。只有懂代码,才能在 Code Review 阶段一眼看出隐患。
- 复杂逻辑的拆解者:AI 擅长处理单一任务。如果我不懂如何将一个庞大的即时通讯系统拆解为 WebSocket 连接、心跳保活、消息存储等子模块,AI 就会产出一团乱麻。
- 极端情况的预判者:AI 往往只考虑“Happy Path”(正常流程)。作为架构师,我必须在文档中显式要求它处理网络断连、Token 过期等边缘情况。
AI 是最好的“副驾驶”,但方向盘必须掌握在懂地图的“老司机”手里。
📊 实战案例:从文档到落地的全过程
以本项目最复杂的两个模块为例:
案例一:从零构建“消息系统”
- 知识摄入:我让 Antigravity 抓取 WebSocket 协议文档,生成了基础连接代码模版。
- 架构定义:我在
docs/modules/消息系统/架构设计.md中定义了“消息模型”:- “消息必须包含
msgId(UUID),senderId,content,timestamp。” - “本地存储使用 IndexedDB,表名为
chat_history。”
- “消息必须包含
- AI 生成:AI 读取上述定义,一次性生成了包含断线重连机制的
WebSocketService.js。 - 人工验收:我检查代码,发现心跳间隔设置过短(1秒),将其修正为文档中的标准值(30秒)。
结果:一个通常需要高级前端开发一周才能写完的稳定 IM 模块,我仅用 2 小时就完成了从设计到验收的全过程。
案例二:破解复杂的“免登”流程
专有钉的免登(Login)流程涉及前后端紧密配合,文档通常是分散的。我是这样操作的:
- 前端探路:首先指挥 AI 阅读前端 API 文档,锁定
dd.getAuthCode接口。我要求 AI:“只关注如何获取授权码,忽略其他无关信息。” - 后端接力:拿到前端逻辑后,我立刻让 AI 阅读后端 API 文档,寻找“如何用 AuthCode 换取用户信息”的接口。
- 全栈串联:最后,我在
docs/modules/登录认证/架构设计.md中定义了完整的时序:“前端获取 AuthCode -> 发送给 Java 后端 -> 后端调用专有钉接口换取 UserDetail -> 后端生成本地 Token 返回给前端。”
通过这种**“分段摄入,统一编排”**的方式,AI 完美理解了跨端协作的逻辑,一次性写通了整个登录链路。
🧬 进阶思考:将范式抽象为 “Agent Skill”
我后知后觉地发现,这套“长短期双记忆”开发法,本质上可以被抽象为一种通用的 Agent Skill(智能体技能)。
如果我们把 AI 看作一个操作系统,那么这个 Skill 就是一个预装的“驱动程序”。我们可以将其标准化为一套 System Prompt(系统提示词):
- Skill 定义:赋予 AI “架构师助理”的角色设定。
- Memory 挂载:强制 AI 在执行任务前,必须先索引
docs/目录下的“长期记忆”。 - Action 约束:规定 AI 的输出必须经过“文档校验”这一步骤。
这意味着,未来我们不需要每次都重复“请阅读文档”的指令,而是直接加载这个 “Project Architect Skill”,AI 就会自动进入“双记忆模式”。这不仅是开发范式的转变,更是人机协作模式的进化。
�🚀 成果与展望
通过这种**“文档即源码,代码即产物”**的模式,我一个人构建了包含即时通讯、组织架构、工作台等复杂功能的专有钉应用。
- 效率:开发速度提升了 10 倍以上。
- 质量:因为有统一的“UI 记忆”和“API 记忆”,整个应用风格高度统一,Bug 极少。
- 可维护性:哪怕过了一年,我只要看一眼文档,就能立刻把记忆“加载”回来,继续迭代。
这就是 AI 时代的开发新范式:编程语言是基础,架构思维是核心。通过 AI,我们从繁琐的编码中解放出来,真正回归到软件工程的本质——设计与创造。
更多推荐

所有评论(0)