夜雨聆风
一句话总结
AI Engineer 在 Vibe Engineering 工作坊中，从零开始操作 Effect 框架，演示如何借助 AI辅助开发和克隆代码库来极速搭建应用，并实现功能模块化与企业级安全。
关键信息
👤 WHO:
AI Engineer 频道主讲者，一位资深程序员（12岁开始编程），分享其对行业AI工具的最新探索成果
🎯 WHAT:
实际演示了Vibe Engineering实操，包括：如何用 LLM 克隆仓库赋予智能体权限，用 mod规范驱动开发编排 HTTP API，规避常见编码陷阱，让现代 AI 产物流畅运行
⏰ WHEN:
曾在六个月前更新模型知识，本次分享实为一场聚焦当下真实环境的空仓库动手实战，在半小时至一个半小时内完成全流程检验
🌐 WHERE:
场景涵盖前后端开发和CLI集成（如Effect / SQLite / Discord 和 Slack频道），是企业级自动化开发与技术演进的关键路径
❓ WHY:
因为知识有压缩时效（比如OpenAI模型和Anthropic Opus等开源模型在效果上落后前沿三至六个月），而大规模企业常见的“时间方差”耗时/中断完全靠LLM驱动的原子工作流才能彻底解决
🔧 HOW:
通过克隆关键仓库生成最佳实践补丁（以 Effect 的 effect.solutions 站为速查入口），采用先Disc规范后编写的底线，监控配置一致性（Bun与VestV2运行时）并定制可独立生存的自动测试框架，最后加装事务回滚防阻塞
💡 SO WHAT:
运用此模式，普通人/小团队等于获得AI全压测系统：每将 AI 流程接入集群即可消除中断排队，相当于有了自带 AI 聊天室底层的，不会因单线程闪退、支持自动进程迁出的「极稳开关」
核心要点
从零开始实际演示
•工作坊强调 真实氛围工程，从零开始未经准备，希望自由互动
•现场参与者对生成式 AI工具已有相当程度的认识，有人已在生产环境运行 V4
•解说人提到通过克隆代码仓库赋予 智能体仓库访问权限，简化开发流程
•夏末开始借助 TypeScript 与 Rust 在 库层面 几乎不再手写代码
•相比人类大脑连续学习，LLMs网络训练后会停滞前进步伐，无法每天吸收新知识
模型记忆与知识更新
•模型通过有限大小的上下文窗口处理信息，100万token的超大窗口可能导致混淆
•知识是压缩后且有时效，如六个月前，需要依赖强化学习获取新知识
•通过将代码库克隆到目录中，伪装成自身代码，能提升模型对特定效果的理解
•避免将代码放在node_modules或.gitignore中，因为模型优化后会忽略这些内容
•使用Vest和TypeScript检查脚本，搭配GPT4（如“刀房里小孩”）应对随机限制
Vibe Engineering实战演示
•目前开源模型相比前沿模型仍落后三到六个月，但已比创业开发用的早期模型更智能
•开发者倾向开源系统，避免如Anthropic对客户端随意限制模型的作法
•用GPT-5.4初始化Git仓库、生成目录文件，执行基础冒烟测试验证
•为项目添加effect v4（Beta，兼容调试反馈）；尝试设置TSGo为TypeScript编译器并通过包安装别名
•因Bun预设的冲突风险，主动禁用Bun来解决警告；提示通过加载窗口后手动重启VS Code并使用预览编译器继续
Effect项目配置详解
-
•将AI项目的所有诊断严重性设为错误级别，让LLM不能接受任何看起来像错误的代码
•参考effect.solutions站点（Kit Langton创建），作为AI项目中使用Effect的快速入门指南
•创建.repos文件夹并以无历史记录方式添加Effect作为git子模块，确保审计通过
•使用mmd列出可用命令（如运行类型检查），并指定访问repos效果库以提取最佳实践
•linter**是背压回路中不可或缺的部分，有助于引导模型朝正确方向发展
Effect HTTP API探索记
•模型易卡在监听模式命令上，需在agent MD 中明确禁止
•OpenAI模型 比 Anthropic Opus** 更简洁，后者可能生成200行代理代码
•规范驱动开发：先讨论生成Markdown规范**，再实现以避免上下文膨胀
•用简单 bash脚本 循环执行小任务，比复杂架构效果更好
•Effect 中推荐使用共享HTTP API默认产生OpenAPI文档**，无需完整客户端
AI代码库重构与API实现
•LLM工作需要先探索和克隆主要库（如TanStack、Zvel）并生成最佳实践文件，效率才能大幅提升
•配置测试环境时，需确认Bun和Vest*的运行时一致性，避免配置与实际环境差异导致问题
•构建HTTP API需按模式制定计划，利用现有效果仓库探索如何用Effect和SQLite实现
•从棕地项目（已有5-10年）起步时，通过让模型生成模式实现多步自动化，降低重构需求
•思考构建命令行工具预取模式，允许用户按需选择（如用Diesel替代全部 Effect），避免过度库采用
模型适配与模式设计
•智能体虽好但MMD标准不通用，Claude和GPT**提示方式不同，需针对性调整
•大写使用影响模型表现：对GPT吼叫会降低性能，对代码中大写则增强关注
•理想方案是命令行界面按模型自动优化上下文，避免维护多方模式
•Opus模型喜欢走捷径，通过自定义lint规则禁止SQL类型转换、强制品牌类型**提升安全性
•观察模型输出后编写关联规则，逐步完善可直接通用的模式库
代码优化与模型选择
•强制使用构造函数会损失效率，而非推荐做法
•新策略是在模式中直接编写规则，阻挡入门接口的错误对象
•Opus 与 OpenAI** 模型在不同场景下表现各异
•用语义代码搜索避免重复实现已有功能
•案例显示两者各有优势：T170 处理问题慢如蜗牛，Opus 却能一次搞定
测试自动化与模式提炼
•循环测试极为有用，能清理混乱代码，自动化流程因人的懒惰至关重要
•代码中的异常如重复层应与模型讨论原因，而非盲目接受
•SQLite场景无需复杂层，但PostgreSQL大型项目需用事务回滚**避免性能问题
•参照效果库提炼通用模式，创建patterns/testing.md最佳实践文件
•通过Open Code创建斜杠命令或使用Code技能标签，助力后续步骤自动化
模式的局限与进化
•技能在特定场景下很理想，但添加过多会污染上下文**，不如斜杠命令通用。
•团队使用不同代理工具如Cursor、Open Code时，相对规则（例如测试useEffect）可作为基准。
•像酒吧禁止滑板一样的规则源于过往错误，写linter插件检查引用有效性是具体应用。
•代码质量依赖人类判断，Anthropic指出无法简单定义好代码，基准是能通过类型检查的LLM更优。
•定义效果模式时，用EVO结合强化学习评估生成代码与最佳实践代码匹配分数。
从零搭建安全系统
•中文翻译段落机械感强，需要重排语序整合破碎逻辑。
•AI集成拉高时间方差，LLM响应需搭配工作流保障原子性**。
•Effect集群能让服务器崩溃后自动迁移流程**，确保操作彻底执行。
•注册逻辑先写数据库再发邮件，若不配对事务极易失败，用户收不到邮件却被告知重试体系糟糕。
•Temporal这类工具高速增长（尤其近十二个月），辅以D、S集成来打造稳健生产环境**。
提到的工具/产品
•Effect — TypeScript 函数式效果框架，支持模块复用+集群移植，提供 effect.solutions 化模板
•Anthropic Opus v4/Opus — 强大但复杂的大语言模型二代 API ，写篇模式往往过于啰嗦
•OpenAI GPT-5.4 // GPT — 表现干脆，给出简短而平实的 command-line/项目骨架用模型
•SQLite + VestV2 (Vest?) — 单元/归复测试基础库，配合事务写小型模式最佳伴侣
•TanStack — 样板式前后端项目标准状态容器，在大仓库应用中降本极明显
•Cursor + Open Code — 侧面代理协助工具之一，组内规则需要定期收缩防止干扰主题上下文
•Vibe-ing based effect.solutions 案例站 — Kit Langton组网列好的的快速实项目入手指南
•Zvel (假定为最简化接口管理) — 降低 llm对大量冗余描述敏感性抽象仓
金句
> ”顺便说一句，使用 V4在生产环境下跑之前其实违背了推荐做法，很不好，但这件事本身效果却激发了稳定的可能性。“ —— AI Engineer
> ”我直接这么叫这次共享就好：“克隆完那个代码仓库，收工走人”，因为满店其实没剩多少自己的原生代码，就这样搞定了自己的应用。”
—— AI Engineer
🎧 扫码收听音频版
扫描下方二维码，收听完整音频 & 查看原文
觉得有用？点个 在看 和 关注 支持一下