AISE 模式下的“零代码”POC 初体验本文记录了产品经理兼前端开发利用 AISE 与 OpenSpec 模式，通过指

🛠️ 开发日记：AISE 模式下的“零代码”POC 初体验

日期： 2026-03-28
项目： 多模态 AI 对话系统 POC
角色： 产品经理 (Logic Design) & 前端开发 (Implementation)

📖 术语解释

AISE (AI-Augmented Software Engineering)：即“AI 增强软件工程”。它不再是简单的“让 AI 写行代码”，而是将 AI 嵌入到整个软件生命周期。开发者从“手工业者”转变为“指挥官”，通过表达**意图（Intent）而非手动编写实现（Implementation）**来驱动生产。
OpenSpec：一种 AISE 的落地协议。它强调**“设计先行”**，核心逻辑是：先通过 Plan 生成一份系统设计规范（Spec），再通过 Build 根据这份规范生成代码。它确保了 AI 的输出不是“随机盲盒”，而是受控的、高标准的工业产物。

📝 核心心路历程：不写代码的“爽感”

昨晚我（基于opencode）试用的模式，本质上是 OpenSpec 的敏捷工作流。虽然初期没有显式生成文档，但 AI 在后台已经根据我的指令构建了一套虚拟规范。

1. 【Plan】阶段：逻辑即架构

我给出的第一个指令非常“产品思维”，直接跳过了琐碎的 API 查阅：

我： “请基于 Vue 3 + Element Plus + Vite 设计一个单页面的‘急诊腹痛 AI 助手’。定义好 system_instruction，重点在于急诊的鉴别诊断逻辑。请给出核心组件的 Props 和 Data 设计。”

感悟： 这一步就是 OpenSpec 的灵魂。AI 并没有直接吐代码，而是先帮我理清了急诊的诊断路径。

最终设计方案摘要

技术选型

框架: Vue 3 (Composition API) + Element Plus + Vite
模型: Gemini 2.0 Flash（快速）或 1.5 Pro（复杂推理）
API: 前端直连（适合POC验证）
风格: 现代简约风格

核心文件结构

src/
├── config/
│   └── systemInstruction.js    # 鉴别诊断逻辑
├── composables/
│   └── useGemini.js            # API 封装
├── components/
│   ├── ChatContainer.vue       # 主聊天容器
│   ├── MessageBubble.vue        # 消息气泡
│   ├── ImageUploader.vue        # 图片上传
│   └── ModelSelector.vue       # 模型切换
└── App.vue

System Instruction 要点

腹痛部位九分法 → 常见病因映射
红旗征识别（休克、腹膜炎、异位妊娠等）
SAMPLE问诊逻辑引导
输出：初步评估 + 检查建议 + 红旗提示 + 处置建议

过程需求澄清：

2. 【Build】阶段：暴力实施与零代码修复

架构定好后，直接进入执行态：

我： “准备好了，可以开始实施。这是后端给的海外服务器接口信息：[API_HOST_INFO]。”

感悟： 随后测试发现的问题，我没手写一句代码，全是靠指令驱动修复。这让我有更多时间去思考**“业务闭环”和“外部 API 细节”**。

最终功能界面：

3. 进阶：补齐“灵魂文档” (逆向工程)

体验过程中我意识到，虽然代码跑通了，但没有物理存在的 Spec 文档，后续维护会变难。于是我尝试了逆向补票：

操作： 使用 @opencode /plan 模式，让 AI 分析现有代码，反向提取并生成了 specs/ 目录。

根据我昨晚跑通的代码逻辑，帮我生成 specs/system_design.md 和 specs/business_logic.md 的初稿。重点体现 Vue 3 + Element Plus 的架构，以及针对急诊腹痛的多模态对话逻辑。

产出： 包含 system_design.md（系统设计）和 business_logic.md（医疗逻辑）。这正式确立了项目的“宪法”。

4. 意外的小插曲：模型与网络

本来想直连 Gemini 1.5 Pro，因本地 Clash 系统代理没弄好导致 API 不通。最后用了 OpenCode Zen 免费的 Big Pickle 模型。 反馈： 还不错！在 POC 阶段，免费模型对前端逻辑和 OpenSpec 指令的执行非常精准。

🚀 5. 尝试开启“正向循环”迭代

现在我已经拥有了完整的 specs/ 文档和规范，接下来的开发将彻底进入 “规范驱动” 模式：

先改 Spec (Plan)：所有新功能（如“3D 胃部模型联动”或“结构化病历导出”）先在 Markdown 文档里更新逻辑。

我要加一个“多节点别名切换”功能。
业务目标：解决不同急诊场景下手动换 Key 的麻烦，同时保护 Key 的安全性。 IT 建议：别名做成常量配置，具体映射在后端记录即可，前端不暴露真实Key。
请根据这个诉求，更新相关的spec。

后改代码 (Build)：让 AI 读取最新的 Spec，自动更新 Vue 组件。

总结感悟： AISE 模式下，代码只是逻辑的副产品，清晰的 Spec 才是真正的核心资产。 这种从“打字员”回归“设计师”的感觉，确实是降维打击。