Day 15： ✅ 今日完成： 1.完成一个VibeCoding项目搭建、优化和社媒发布 具体项目介绍： 来试试DeepTalk吧。 随时陪你深夜畅谈，陪你舒缓内心焦虑，陪你渡过奥德赛时期的好搭子。 遇到选择纠结了，让巴菲特帮你用长期主义理一理思路； 工作上想不通了，让马斯克帮你用第一性原理拆一拆问题； 情绪低落了，让蔡康永温柔地陪你把心里的结慢慢解开； 对未来迷茫了，让刘擎从哲学的角度帮你看看人生的可能性。 七位大佬，随时在线，不评判、不说教，就是陪你聊。 开源在Github了，去试试吧。 Github地址：https://github.com/danjiujiaohun/DeepTalk 各位鱼友也可以下载尝试，也可以帮忙点点Star

如何从0到1 Vibe Coding 一个项目，并长期维护

我是汉堡。上篇文章《我的第一个 Vibe Coding 项目正式上线，Notus——原生 AI 笔记应用，且完全开源》结尾我说过，要写一篇关于如何持续 Vibe Coding 可长期维护项目的文章。这篇就是。 以下内容来自我自己的血泪教训和成功经验，希望能帮到正在 Vibe Coding 或准备入坑的人。 --- ## 一、我的 AI 博客项目是怎么死的 去年夏天，我买了 Trae 的会员版，打算自己开发一个 AI 博客功能，包含博客摘要、知识库、SEO 这些。刚开发的时候兴奋得很，看着功能一个一个被实现，越做越有干劲，周末好几次熬到凌晨三四点，差点熬穿了。甚至还幻想靠这个赚钱。 但很可惜，这个项目**夭折了**。 那会儿刚接触 Vibe Coding，对工程管理和 harness 相关的知识**极度欠缺**。每次都是想一个功能就让 AI 实现一个，AI 的上下文约等于没有。导致： - 改完 A，B 出问题 - 改完 B，C 又出问题了 - 改完 C，A 又挂了 无限循环，最后心态崩了，维护不过来就放弃了。 --- ## 二、Vibe Coding 的本质困境 Vibe Coding 有一个很形象的比喻——**抽卡游戏**。 刚开始开发的时候，看着自己的想法一个个被实现，就像抽卡前期中奖概率高得很，爽感拉满。但越到后面越难"中奖"： 1. **上下文膨胀**：代码量越大，AI 越难理解全貌，每次改动都是盲人摸象 2. **耦合蔓延**：组件之间相互依赖，改一处牵一发而动全身 3. **意图退化**：没有文档记录，几轮对话之后你自己都忘了当初为什么这么设计 4. **红利消失**：前期快速出功能的爽感过去后，维护成本指数级上升 以上所有问题指向同一个根源：**缺乏工程化管理。** 这个问题可以解决。下面就是我沉淀下来的方案。 --- ## 三、工欲善其事，必先利其器 工程化管理之前，先聊工具和模型的选择。 Vibe Coding 的效果，首先取决于你用的 Coding Agent 和 AI 模型。我个人推荐这几个 Agent 工具： - **Codex**（我的主力）/ **OpenCode**：启动时自动注入项目级别和全局的 AGENTS.md，Agent 啥也不用说就知道项目的一切 - **Cursor**：适合轻量级改动和代码补全 - **Claude Code**：Agent 能力强，适合复杂任务 模型方面，推荐 **GPT 5.6 Terra High、GLM 5.2、Claude 5** 等一线模型。 使用策略上，**用最强的模型做规划和设计，用中高模型做编码。** 比如用 Claude Opus 或 GPT 5.6 Sol High 来写项目的需求文档、总技术文档和各功能模块的实现文档——这些"地基"级别的产出，必须交给最强的脑子。具体的编码实现，交给中高模型来执行。 工具和模型选好了，下面聊工程化管理。 --- ## 四、规划永远比写代码重要一万倍 相信绝大多数人在没 AI 写代码时都喜欢先写后端，再写前端，包括我自己也是如此。但规划和写代码，到底哪个放在前面？ 盖房子最重要的是地基，地基打好了房子才能稳。求职市场里，架构师的工资永远比程序员高。规划和设计的份量，不用多说了。 **在让 AI 写一行代码之前，先用最强模型把需求文档、技术方案和各功能模块的实现文档写清楚。** 这些文档就是你的"地基"。 不一定每处都需要规划得那么细致。文档写得过于事无巨细，反而会让中等模型在执行时缺少自主性和发散性思维，变成了纯粹的"翻译机"。把握好粒度，关键路径细化，边缘逻辑给 AI 留发挥空间。 --- ## 五、合理的数据库表设计 在没有 AI 写代码的时代，数据库设计是顶要紧的步骤。你对业务的理解会直接体现在数据库设计上，而数据库设计的好坏会影响项目业务的复杂程度，进一步影响代码的可读性和可维护性。 用 AI 出方案时，**一定要 review 表的设计**。**能用一个表解决的，就不要用多个表。** 如果 AI 给出的方案不合理，果断和它沟通，选择较优的方案。 同时还要考虑系统后续的拓展功能，防止数据表频繁增删字段，甚至被迫重构表设计。同理，整体方案设计也要把后续拓展的可能性考虑进去——这和规划优先的思路是一脉相承的。 --- ## 六、写代码的先后顺序 在没有 AI 的时候，我习惯先写后端，再写前端，相信大多数人也是这样。但用 AI 写代码，**先写前端，再写后端。** 具体做法： 1. **把项目的完整需求文档发给 AI**，沟通需要多少个页面，每个页面有哪些详细功能。把沟通出的内容补充到需求文档中。 2. **出原型图。** 将需求文档发给 GPT 或 Claude 产出原型图。我个人强烈推荐 Claude Design——审美确实好，原型图不会偏离需求文档要求；而且产出的是 React 代码，可以直接用 Claude 或 GLM 5.2 搭建前端工程跑起来看到页面。如果用 GPT，则用 GPT Image 2 生成设计图，再通过 Codex 像素级还原，但需要注意设计图可能会偏离需求文档的功能。 3. **模拟数据，验证动态页面。** 根据数据库表 DDL 在前端模拟一些数据，测试页面是否全是动态渲染的。 到了这一步，你对 Vibe Coding 上瘾了。 先写后端的时候，大片代码不停输出却看不到任何视觉成果，难免有些失落和不安，总感觉 AI 没有遵循文档的要求。**先写前端让你在最短时间内看到产品长什么样。** 那种即时的成就感和掌控感，完全不一样。反正我自己是这么觉得的，哈哈哈哈。 --- ## 七、好的上下文与文档管理 经过 AI 博客项目的失败，我在开发 Notus 和后续项目的过程中，逐渐沉淀了一套 **Harness 体系**——给 AI 配一个"项目管理大脑"。 ### 7.1 AGENTS.md 模型都是有上下文限制的，虽然现在普遍一百万的上下文窗口，但放到一个庞大的项目中，根本不够看，特别是 GPT 这种 300k+ 的上下文更是难受。一般我自己一个对话最多实现 3\~4 个需求，防止 Agent 频繁压缩上下文导致准确度丢失。 控制对话长度之外，**让 AI 在每次对话开始时就能理解项目的一切**，这才是关键。 `AGENTS.md` 就是干这个的。每次开始一个新项目或维护旧项目时，我都会手写一个 AGENTS.md。对于 Codex/OpenCode 来讲，启动时会自动将项目级别和全局的 AGENTS.md 注入当前对话上下文——你啥也不用说，Agent 就知道关于项目的一切。 下面是一个脱敏后的 AGENTS.md 示例，思路供参考： ```plaintext [AGENTS.md](http://AGENTS.md) 本文件只规定 AI 编码 Agent 在项目仓库中的行为。产品需求、技术方案、数据库表和实施细节由项目文档维护，本文件不重复抄写。 **1. 基本行为** - 始终使用中文回复；代码、标识符、API、数据库字段和提交信息使用英文。 - 先查项目文档、现有代码和测试，再决定如何实现。文档已有答案时，不重复询问用户。 - 只修改当前任务涉及的内容，不顺手做无关重构，不为尚未发生的需求提前建设复杂抽象。 - 不能在当前任务中完成的部分要明确说明，不承诺后台交付。 **2. 权威文档** - 优先读取 `docs/` 中的 Markdown 版本：PRD（做什么）、技术设计文档（怎么设计）、实施文档（怎么推进）、进度文档（现在做到哪里）。 - 冲突优先级：AGENTS.md → 用户本次明确要求 → PRD → 技术设计 → 实施文档 → 进度文档 → 现有代码。 - 发现代码与文档不一致时，不得静默猜测，按高优先级文档确认目标，说明差异并同步修正。 **3. 开始任务前必须自主查询** - 查看进度文档，确认当前阶段、下一任务、前置依赖和阻塞。 - 在 PRD 中搜索相关页面、功能名和验收标准。 - 在技术设计中搜索相关模块、表、API、外部依赖和约束。 - 检查受影响代码、迁移和测试，沿用仓库已有模式。 **4. Vibe Coding 工作流** - 每个任务按最小纵向切片完成：文档定位 → 数据模型/迁移 → 后端服务 → API → UI → 测试 → 文档与进度。 - 数据库变化先写迁移和约束，再改 ORM、服务和 API。 - 需要改变产品范围、架构、表结构或实施顺序时，先更新对应文档，再编码。 - 一次优先交付一个可验证闭环，不并行铺开大量半成品。 **5. 代码结构与依赖方向** - domain/ 不导入具体框架或 SDK。 - API 不直接写 SQL，也不直接调用第三方数据源。 - 配置统一加载，不在业务代码中散读环境变量。 **6. 完成标准** - 相关测试通过；数据库迁移可从空库执行也能从上一版本升级。 - 外部 Provider 的失败、超时、空数据和过期状态已处理。 - 完成后必须更新进度文档的状态、证据、遗留问题和下一任务。 - "代码能运行"不等于完成；测试、文档和进度没有同步时，任务仍未完成。 **7. Git 与文档同步** - 未经用户明确授权，不推送远程、不发布版本。 - 提交只包含当前任务相关修改，不混入无关格式化或重构。 - 不提交 .env*、密钥、数据库、备份、日志、依赖目录和构建产物。 - AGENTS.md 只维护 Agent 行为和代码边界，不复制项目文档的细节。 ``` AGENTS.md 干的事情就一件：**让 AI 知道你的编码哲学和项目规范，不用每次都重复交代。** ### 7.2 文档治理 文档治理是 harness 体系的核心模块。**在让 AI 写代码之前，先让它把需求写清楚。** 我采用的文档分类体系： | 文档类型 | 命名格式 | 用途 | | --- | --- | --- | | **REQ** 需求文档 | `REQ-YYYYMMDD-XX-*.md` | 新功能或大范围改造前必写，明确范围、验收标准 | | **PROG** 进度日志 | `PROG-YYYYMMDD.md` | 每天一日志，记录完成了什么、遇到了什么问题 | | **BUG** 缺陷记录 | `BUG-YYYYMMDD-XX-*.md` | 发现 bug 立即记录，关联来源 REQ | | **BIZ** 业务决策 | `BIZ-YYYYMMDD-XX-*.md` | 业务流程或实现策略的确认和调整 | | **DEV** 技术方案 | `DEV-YYYYMMDD-XX-*.md` | 复杂模块拆解、阶段实施方案 | 关联规则： - **PROG 必须引用相关 REQ/BUG**，保证进度可追溯 - **BUG 必须引用来源 REQ**，知道这个 bug 是从哪个需求引入的 - **BIZ 必须引用对应 REQ**，业务决策不能悬空 这套体系的作用： 1. **上下文外挂**：AI 每次对话前先读相关文档，就不会丢失上下文 2. **可追溯**：三个月后回来，你还能知道当初为什么这么设计 3. **可交接**：换一个 AI 模型或工具，读一遍文档就能接手 ### 7.3 控制 Vibe Coding 的边界 Vibe Coding 的一个诱惑也是陷阱："顺手加一个功能"。 你以为只是"顺手"，但 AI 的上下文是有限的。每多一个功能点，就会引入新的耦合、新的边界情况、新的 bug 风险。 **范围冻结**就是在一开始把 v1 要做什么、不做什么写死。比如 RepoRadar 项目： **纳入 v1 的**：GitHub Search 抓取、规则过滤、去重入库、Agent 分析、仓库列表、配置中心、飞书推送... **明确不进 v1 的**：增速监控、批量提交、导出 CSV/Markdown、语义去重、多数据源接入... 一旦范围冻结，后续开发中 AI 想"顺手"加功能时，你就可以说：**"不在 v1 范围，先记 REQ，下个版本再说。"** ### 7.4 分阶段推进：Phase 0 → Phase N 大项目一口气让 AI 实现 = 灾难。必须拆阶段，每个阶段有明确的 **DoD（Definition of Done）**。 一套典型的阶段划分： | 阶段 | 内容 | DoD | | --- | --- | --- | | **Phase 0** | 文档体系初始化 | AGENTS.md、README.md、docs/ 结构就绪 | | **Phase 1** | 后端骨架 | 服务可启动、配置可读、数据库可初始化 | | **Phase 2** | 核心链路 1 | 端到端链路跑通 | | **Phase 3** | 核心链路 2 | 同上 | | **Phase 4** | 业务 API | 接口字段对齐、错误响应统一 | | **Phase 5** | 前端工程化 | 拆页拆组件、接入真实 API | | **Phase 6** | 通知与配置 | 链路闭环、热重载 | | **Phase 7** | 打包上线 | Dockerfile、持久化、基础回归 | 每个 Phase 结束必须达到 DoD 才能进入下一阶段。**这个纪律不能破。** --- ## 八、实战项目 Notus 下面是我怎么用这套体系把 Notus 从 0 到 1 做出来的。 ### 8.1 项目背景 Notus 是一个本地 AI 原生笔记应用，核心功能是文档编辑、知识库和 AI 创作。对标的其实是 notebookLM 和 YouMind，但完全开源、免费、数据本地存储。开发周期大约 20 天（非全职）。 ### 8.2 怎么用 Harness 体系 **文档先行。** 在写第一行代码之前，我先写了 PRD（产品需求文档），明确了 v1 范围、核心功能、技术选型。 **AGENTS.md 就位。** 项目初始化时就写好 `AGENTS.md`，让 AI 每次对话都先理解项目结构和规范。内容包括项目采用 Tauri + React 架构、前端组件目录结构、代码风格要求，以及禁止的行为（比如不要擅自改架构）。 **分模块推进。** 不是一口气让 AI 写整个应用，而是按模块来：先搭编辑器核心（Markdown 解析与渲染），再建知识库（文档索引 + 语义检索），最后做 Agent 创作（多文件改写 + 风格学习）。 ### 8.3 上下文管理 这是 Notus 开发中踩得最深的一个坑。 当项目代码量上去之后，AI 的上下文窗口根本塞不下全部文件。我的做法是： - **按需加载**：只把当前任务相关的文件喂给 AI，其余文件通过文档索引让 AI 知道"存在但不加载" - **摘要压缩**：对历史对话进行摘要压缩，保留关键决策和上下文 - **意图识别**：先让 AI 判断用户是想改写文章还是单纯闲聊，匹配不同策略 这些经验后来也直接体现在了 Notus 的 Agent 工程模块里。 --- ## 九、实战项目 RepoRadar ### 9.1 项目背景 RepoRadar 的起源其实很接地气——我在懒猫搬砖做副业，为了方便，写了个应用去爬 GitHub 开源仓库，自动判断能不能搬，然后推送到飞书群里。 但这次不一样。这次我一开始就用上了完整的 harness 体系。 ### 9.2 Harness 落地实践 **文档体系先行（Phase 0）**：在写任何代码之前，先把 PRD、AGENTS.md、docs/ 目录结构全部建好。PRD 作为总纲永久保留。 **范围冻结**：v1 只做 GitHub Search 抓取、规则过滤、Agent 分析、飞书推送。增速监控、批量提交、语义去重等全部推到后续版本。 **分阶段 7 步走**：从文档体系初始化 → 后端骨架 → 采集链路 → 分析链路 → 业务 API → 前端 → 打包上线，每一步都有明确的 DoD。 **接口契约先行**：在写代码之前先定义 API 契约（GET /api/repos、POST /api/submit 等），前后端以契约为准各自开发互不阻塞。 ### 9.3 和之前失败的 AI 博客项目对比 | 维度 | AI 博客（失败） | RepoRadar（成功） | | --- | --- | --- | | 文档 | ❌ 无，想到哪做到哪 | ✅ PRD + AGENTS.md + docs/ | | 范围 | ❌ 不断加功能 | ✅ v1 范围冻结 | | 阶段 | ❌ 无规划，一把梭 | ✅ Phase 0-7 分步走 | | 上下文 | ❌ 约等于没有 | ✅ 按需加载 + 摘要压缩 | | 结果 | 心态崩了 | 在掌控之中 | --- ## 十、心态 最后聊聊心态。 Vibe Coding 做久了，最大的坑不是 AI 不够强——是你自己的欲望。看到一个好玩的功能就想加，看到别人开源了什么就想自己也搞一个。但代码是一行一行堆出来的，每多一个功能，维护成本就往上翻。能复用的就别自己造，能用现成库的就别手写。我踩过太多这种坑：花三天写了个工具函数，后来发现 github上早就有成熟方案，比自己写的还好。 项目做着做着没动力了，我经历过好几次。归结下来就两个原因。 一个是**无力维护**。代码越堆越多，改一个地方炸三个地方，每次打开项目都有心理负担。这种情况只能靠前面说的工程化管理兜底——文档、范围冻结、分阶段推进。别等烂摊子收拾不了了才想起来，那时候已经晚了。 另一个是**不赚钱**。花了几百个小时做的项目，上线后用户没几个，更别提收入了。大部分 side project 都这样，没办法。我的态度是：练手的项目，学到东西就算回本；真想赚钱，立项前就想清楚谁来买单、凭什么买单。别一边写代码一边幻想"做完了就有人用了"——大多数时候不会。 --- ## 个人博客 我的博客：<https://blog.hejiajun.com> --- *下一篇预告：Notus 的 Agent 工程细节——上下文压缩、意图识别和工具调用的具体实现。*

写给自己的微信排版工具，8套主题随你挑

最近开始了发展自己的微信公众号【可乐不是Code】，想要分享自己在工作中的踩坑、vibe coding 工具，还有各种实战经验，目前还没有什么粉丝。今天想分享一个在发布推文过程中出现的灵感，然后借助AI做出的微信推文排版工具。 写公众号推文，最头疼的不是内容，是排版。 Markdown 写好了，粘贴到微信编辑器——格式全乱。代码块丢了高亮，标题没有样式，调样式调了1小时。 WX Formatter，三步搞定： 1. 左边写 Markdown 2. 右边实时预览，8种主题一键切换 3. 点一下「复制到剪贴板」，粘贴到微信编辑器，完事 🟢 8套主题：科技蓝、文艺绿、极简灰、暖橙、深夜黑、掘金、星露谷、可乐气泡 🟢 代码语法高亮，技术博主刚需 🟢 自定义主题：导入导出JSON，想怎么改怎么改 🟢 375px手机宽度预览，所见即所得 思路参考了 mdnice，做了本地化，加了几套自己喜欢的主题。如果你也想本地运行、自定义风格，欢迎自取。 vibe coding 第四弹 🎉      

迟来的《万能视频总结器》项目开发路程

## 项目地址 https://github.com/userwanyong/uvd ## 项目背景 **我为什么做这个项目？** 在当前内容爆炸的时代，用户在B站、YouTube、TikTok、抖音等平台上获取信息的需求越来越高，但同时也存在以下痛点： 1. 平台限制下载 - 不提供下载按钮 - 限制清晰度 / 会员限制 2. 下载体验差 - 需要安装工具 - 手机端操作困难 3. 信息获取效率低 - 长视频理解成本高 - 缺乏结构化总结 **我的预期目标** 编写一个跨平台、简单易用、可视化、AI智能总结的视频下载平台。预计实现：多平台视频下载兼容、自动识别并解析视频链接、AI视频总结等特性 ## 开发环境 1. glm-5-turbo+cc 2. context7：搜索最新文档，防止AI使用过时的语法 3. chrome-devtools：进行浏览器端到端自动化测试 4. zread：搜索并读取开源仓库 5. web-reader：读取网页内容 6. web-search-prime+firecrawl-mcp：用来进行网络搜索 7. zai-mcp-server：用于分析chrome-devtools测试截图 8. frontend-design+ui-ux-pro-max：优化前端UI，至于用哪个，让AI自行选择即可 ## 方案设计 因为目标明确，相关竞品大多都是付费版本or功能不完备，因此可以跳过竞品分析，让AI直接进行方案设计，这一步可以使用5.1进行充分设计，开发阶段切换为turbo进行快速开发 ``` 你是一位全栈开发程序员，请你根据我的需求，设计方案、然后找我人工确认、分步骤开发、完成自主测试。 ## 我的需求 在当前内容爆炸的时代，用户在B站、YouTube、TikTok、抖音等平台上获取信息的需求越来越高。 我希望编写一个跨平台、简单易用、可视化、AI智能总结的视频下载平台。 预计实现：多平台视频下载兼容、自动识别并解析视频链接、AI视频总结等特性。 ## 人工思考方案 1）对于前端界面，需要简洁大气，然使用者眼前一亮，清晰易懂各个功能（按钮）是干什么的 2）对于后端设计，可以使用py实现，可以暂时不加数据库，实现核心mvp功能 3）对于视频的下载方式，去GitHub查找相关的项目，进行二次开发，eg. yt-dlp（https://github.com/yt-dlp/yt-dlp） ## 注意事项 1）前端页面必须具备明显差异化，避免模板化设计。整体风格需突出“高级感 + 科技感 + AI感”，通过深色+渐变、高对比卡片。 2）必须在我已有方案基础上进行分析与优化，先输出完整方案，并等待我确认后再开始开发，禁止跳过确认直接编码 3）你必须完全理解开源项目，使用尽量简单的方式实现（比如直接在开源项目代码基础上去修改，或者直接封装，尽量减少代码改动） 4）如果有任何不确定的地方需向我询问，不要自作主张 ``` AI给出了设计文档，这里我也没过多的干预，直接让他根据设计文档进行开发（cc自动退出plan模式） ## 编码实现 turbo的速度还是可以的，快速完成了demo的开发，这里直接看一下UI效果和功能完成度 **1）UI效果**   **2）MVP功能可用性** 可以正常启动 1. 解析视频（特点：输入地址后自动解析，不需要手动点按钮） - b站：解析成功✅️ - YouTube：解析成功✅️ - TikTok：解析失败❌️ - 小红书：解析成功✅️ - 抖音：解析失败❌️ 2. 下载视频 - b站：成功下载并正常查看✅️ - YouTube：成功下载并正常查看✅️ - TikTok：解析失败，未达到资格线❌️ - 小红书：成功下载并正常查看✅️ - 抖音：解析失败，未达到资格线❌️ **3）实际用到的Skill** frontend-design **4）存在问题** 1. 视频封面缩略图未显示 2. TikTok和抖音解析失败 ## bug修复 ``` 1. 视频的信息正常解析，但是视频封面并没有展示出来 2. TikTok和抖音解析失败，请你查找原因并修复 ``` 原因：b站视频缩略图有Referer防盗链、抖音需要用户的Cookie  视频封面缩略图未显示问题，修复成功✅️  但是只有缩略图问题修复成功，抖音和TikTok依然解析失败，把报错信息贴给AI ``` 1. 抖音解析依然失败: ERROR: Unsupported URL: https://www.douyin.com/jingxuan?modal_id=xxx（https://www.douyin.com/jingxuan?modal_id=xxx、https://www.douyin.com/video/xxx） 2. TikTok依然解析失败: sequence item 0: expected str instance, NoneType found（https://www.tiktok.com/@axxx037/video/xxx?is_from_webapp=1&sender_device=pc） ```  当前TikTok解析下载功能已经正常✅️，但缩略图未显示❌️；对于抖音，不能让用户自己提供cookie，不然网站设计初衷的便捷性就没了，继续修复 ``` 1. TikTok的缩略图也没有展示 2. 对于抖音，不能让用户自己提供 Cookie，你可以再通过网络搜索或开源项目找到方案 ```  TikTok缩略图修复成功✅，但貌似是用的Playwright解决视频解析问题，这样内存占用高，解析速度慢，应该寻找更优质的方案 ``` 1. 你是不是用了Playwright 浏览器，但我不认可这种方法，你需要寻找其他方法，可以去github开源社区去查找解决方案 2. 请你仔细分析并提出自己的方案，然后我人工确认，我批准后再进行开发 ``` ️调用mcp进行查找  最终方案如下，我有预感，这次能成！  然后让AI根据新方案进行更改优化  经过漫长的等待~  已经执行完编码工作并完成自动化测试  自动化测试？我不信，我自己来测测  你别说，这次还真成了，可以正常解析与下载！✅️要是让我古法编程，找开源项目、设计方案、执行编码、测试bug，给我一下午也不够啊，就是缩略图还有点毛病，继续继续，写提示词（温馨提示：你的上下文可能已经快爆了，及时总结或者开新窗口） ``` 1. 现在对于抖音视频的解析已经完美实现，但还有一点不足，就是缩略图未显示，你需要修复一下 2. 上一版方案的Playwright 浏览器你是不是给我下载到本地了，检查一下删除没有 ``` 完成两个任务，心想，这么简单的需求肯定能过，毕竟前两个相同需求都是一遍过的  满怀信心进行测试，我靠，翻车了，还是没显示  那就继续吧…… 不过话说，首次开发的时候他自动调用了chrome-devtools这个MCP工具进行自主截图测试，这几次怎么没自动测试一下，那我就来指定一下吧，先/compact总结一下下，腾出点上下文  ``` 1. 现在抖音视频的缩略图依然没有修复好，请你继续进行修复 2. 修复完成后你需要自主截图测试，确保缩略图真正能显示出来 ``` AI给我的回答是：截图并修复了；经过我手动测试后，success！完美！   至此，核心功能已经全部通过 - b站：解析并下载✅️️ - YouTube：解析并下载✅️ - TikTok：解析并下载✅️ - 小红书：解析并下载✅️ - 抖音：解析并下载✅ ## 开发视频总结功能 ``` 你是一位专业的全栈开发工程师，正在开发《视频下载总结器项目》，请你根据需求，进行方案的设计、人工确认、分步骤开发、自主测试验证、最后找我验收。 ## 当前完成度 目前已经完成了核心的视频下载功能，现在要做更多的功能扩展，你必须根据我已有的文档和代码进行完整地分析，确保理解了项目当前的细节，才能进行后续的工作。 ## 现阶段需求 调用AI进行视频内容的总结（可根据弹幕等途径总结），以便于让使用者在不观看长篇视频的情况下大致了解视频的内容，节约时间 ## 当前任务 你需要帮我进行竞品调研、方案设计、开发实现 ## 注意事项 1）如果你有任何不明确的内容，一定要找我人工确认，才能进行下一步的动作 ``` 调研完成，开始进行方案设计  这里是AI询问我们的四个选项  最终得到了一份实现计划：  现在所有步骤都已经明确了，开始开发。注意要跟AI显式说一声使用context7获取最新文档，防止AI使用过时的代码亦或者AI没有自动调用这个工具 ``` 1）你必须通过 Context7 和联网搜索确保你获取到了最新的技术文档，不要使用过时的代码 2）注意不要影响到已有的功能，只新增代码，而不修改代码（开闭原则） 开始开发！ ```  自主测试，api+浏览器   接下来配置.env文件进行AI总结测试  选择智谱的免费模型，重新启动。但还是执行AI总结时报错了  此时上下文已经用的差不多了，直接新开一个会话 ``` 你是一位专业的全栈开发者，正在开发《视频下载总结器项目》，现在你正在开发AI总结功能 ## 现阶段需求 调用AI进行视频内容的总结（可根据弹幕等途径总结），以便于让使用者在不观看长篇视频的情况下大致了解视频的内容，节约时间 ## 当前任务 你已经完成了功能的开发，但当我填入apikey后进行验证时，提示 INFO: 127.0.0.1:54283 - "POST /api/ai/summarize HTTP/1.1" 404 Not Found 你需要修复这个问题，并自主测试 ## 我提供给你的资料 1）@项目代码 2）@视频总结功能设计文档 ## 注意事项 1）如果你有任何不明确的内容，一定要找我人工确认，才能进行下一步的动作 ```  让我手动验收一下  功能是OK的，但是位置放到了页面底部，属实有点奇特，把问题和预期结果抛给AI继续进行修复 ``` 1. 现在功能正常运行了，但是为什么没有上传/解析视频时，AI总结按钮就不展示？ 2. AI总结这个按钮现在是在页面底部，这很不符合用户习惯，你应该放到页面中部或更好的位置，重点是让用户知道有这个功能！ ``` 修复完毕，我觉得效果还可以吧  但是，我又发现一个问题，这思维导图属实有点抽象了  ``` 1）现在AI总结功能已经可用，但是有一点不足，就是思维导图部分有点抽象，你应该使用更简洁明了的方式向用户展示 ``` 修复后的效果如下，可读性提高了，但还是有点AI味，我直接采用最简单粗暴的方式，找了张图让AI按着图中的风格进行更改：  ``` 1）现在思维导图太生硬了，请你参考我提供给你的图片，以后思维导图都按图片中的风格进行生成 2）拓展：给用户增加一个下载选项，可以将思维导图下载到本地 ```  成了！现在这一版就好看多了，但是下载下来有点问题（字体是黑的） ``` 现在可以正常下载，但下载之后为什么字体是黑的，如图 ```  根本原因及修复措施如下：  成功修复，svg和png的字体均正常显示  ## 优化页面布局 ``` 你是一位专业的全栈开发工程师，追求极致完美，正在开发《视频下载总结器项目》，现在请你根据需求，设计方案、人工确认、分步骤开发、自主测试验证、最后找我验收。 ## 项目进度 目前我已经完成了核心的视频下载和AI总结功能，要做更多的功能扩展，你必须根据我已有的文档和代码进行完整地分析，确保理解了项目当前的细节，才能进行后续的工作。 ## 需求 目前的排版是，视频信息，AI总结两个模块竖直排列的，你应该将他们改为水平排列，比如左边是视频解析部分，右边是AI总结部分（可以参考我给你的图片） ## 往期素材 @项目文档 @当前项目源码 ## 当前任务 你需要进行方案设计、开发实现 ## 注意事项 1）如果你有任何不明确的内容，一定要找我人工确认，才能进行下一步的动作 ```  完美收工！

CLI 是什么？为什么大厂突然集体卷命令行？

大家好，我是程序员鱼皮。 最近不知道大家有没有注意到，互联网大厂的风向又变了。 Google 率先开源了 Workspace CLI，紧接着短短一周之内，飞书、钉钉、企业微信不约而同地在 GitHub 上开源了自己的 CLI 工具。  一时间，CLI 这个计算机世界里最古老的交互方式，突然又火了。 奇了怪了，CLI 不就是黑不拉几的命令行窗口吗？都什么年代了，各大厂不去卷更漂亮的界面，反而集体开起了倒车？  这篇文章，我会依次分享： - 什么是 CLI？ - 怎么用 CLI？ - 为什么大厂都在卷 CLI？ - 有哪些 CLI 开源项目？ - 怎么自己做个 CLI？ 一次性把 CLI 给你讲明白，建议收藏~ ## 什么是 CLI？ CLI 全称 Command Line Interface，翻译过来就是命令行界面。 说白了，就是你在一个小黑框里敲文字命令来操作电脑。  和它对应的，是我们每天都在用的 GUI（Graphical User Interface），也就是图形界面。你平时在手机上看到的那些图标、在电脑上看到的那些窗口和按钮，这些都是 GUI。 举个例子，假设你想把电脑桌面上的一张图片移动到另一个文件夹。用 GUI 的话，你会打开文件管理器，找到图片，用鼠标拖过去放进目标文件夹。 使用 CLI 的话，你打开终端，敲一行命令就搞定了： ```bash mv ~/yupidog.png ~/Downloads ```  再比如切视频、批量改文件名、查服务器日志，这些用 GUI 要点好多步的操作，CLI 往往一行命令就搞定了。 显然，CLI 的特点就是 **简洁直接**，一条命令干一件事，干净利落。 但是，如果想用好 CLI，要求你记住大量命令和参数，这对普通用户来说门槛太高了。 想象一下我那只会用电脑玩斗地主和捕鱼的爸妈，让他们打开终端敲命令？玩呢？  其实 CLI 是计算机最原始的交互方式。在很久以前，电脑压根儿就没有图形界面，所有操作全靠命令行完成。后来 GUI 出现了，普通用户才终于告别了小黑框。从那以后，GUI 一路高歌猛进，成了绝对的主流。厂商们想方设法把界面做得更好看、更好用，按钮越做越大，交互越做越顺滑，一切都是为了让人类用起来更舒服。 但 CLI 从来没有消失，很多程序员朋友们都在用命令行管理服务器、部署项目。而且有些学编程的朋友写的第一行代码 Hello World，可能就是在命令行里跑起来的。 长期以来，CLI 一直是程序员的专属技能，甚至熟不熟悉命令行是区分老手和新手的标志之一。 不过现在 AI 时代来了，技术越来越大众化，CLI 正在重新站到聚光灯下。 ## 上手试试 CLI 使用 CLI 最简单的方式，就是打开你电脑自带的终端。 Mac 用户在应用程序里找到 “终端”，Windows 用户搜索 “PowerShell” 或者 “命令提示符”，打开之后你会看到一个等待输入的光标。 试着敲一行： ```bash date ``` 电脑会直接返回当前的日期和时间。 这就是最简单的 CLI 交互了，你输入一条命令，电脑返回一个结果，没有花里胡哨的界面。  但这只是最基础的用法，现代 CLI 能做的事情远远不止这些。 比如最近飞书刚开源的 [Lark CLI](https://www.feishu.cn/feishu-cli)，这个工具可以让你在终端里直接操作飞书的消息、日历、文档等功能。  首先输入一行命令安装： ```bash npm install -g @larksuite/cli ```  装好之后，先配置一下应用信息： ```bash lark-cli config init --new ```  打开链接配置飞书 CLI 应用：  创建应用成功后，需要登录授权，按需选择你允许通过 CLI 操作的业务： ```bash lark-cli auth login ```  跟着 CLI 的引导一步步操作就好：  授权过程中，记得要在飞书管理后台审核应用：  审核应用通过后，可以再重新执行登录命令，直到你看到「授权成功」：  之后，你就可以用命令行来操作飞书了。 比如查看今天的日程安排： ```bash lark-cli calendar +agenda ```  查看我的待办任务： ```bash lark-cli task +get-my-tasks ```  甚至直接创建一篇文档： ```bash lark-cli docs +create --title "周报" --markdown "# 本周进展" ```  以前这些操作你要打开飞书 App，点好几下才能完成，现在一行命令就搞定了。 CLI 有这么多命令和参数，使用过程中，如果忘了某个命令怎么用，怎么办呢？ 只需要记住一个万能口诀：**不会就加 `--help`**。 比如： ```bash lark-cli --help lark-cli calendar --help ``` 相当于随时翻说明书，CLI 会把所有可用的命令和参数列出来给你看。  对了，如果你觉得传统的终端使用起来不方便，可以试试 [Warp](https://www.warp.dev/) 这种现代终端工具，内置了 AI 辅助和命令自动补全，对新手友好很多。  ## 为什么大厂都在卷 CLI？ 前面我们体验了用 CLI 操作飞书，对程序员来说，用习惯了确实还挺方便的。 但你有没有想过一个问题，大厂们费这么大劲把产品做成 CLI，难道只是为了让我们少点几下鼠标吗？为什么大厂都在卷 CLI？ 答案就 2 个字：**AI**。 大厂们不是在给人类做 CLI，而是在给 AI 做 CLI。 AI 大模型从诞生那天起就在学习海量的代码、命令行操作、终端输出。可以说 **CLI 就是 AI 的母语**，让它读一行命令、执行一个操作，跟喝水一样自然。 反过来，你让 AI 去操作一个图形界面那可就难了。 还是拿飞书举例。假设你想让 AI 帮你搜一下最近同事提到过的 “周报” 相关消息。 假设使用飞书的网页版，AI 需要先打开浏览器，等页面加载完，找到搜索框，输入 “周报”，等结果出来，再一条条翻看消息内容。中间要处理一堆网页元素，导致上下文信息又长又杂，有很多和内容无关的干扰信息。而且万一网页改版了，AI 之前学到的操作方式可能就全废了。 但是飞书提供了 CLI 后，AI 只需要执行一行命令，就能完成任务： ```bash lark-cli im +messages-search --query "周报" ```  有人做过测试，让 AI 通过浏览器完成真实任务，成功率只有 35.8%；换成 CLI 来完成同样的任务，成功率接近 100%！ 所以你会看到一个很有意思的现象。以前大厂做产品，想方设法把 UI 做得好看好用，给人类使用。现在是返璞归真，**面向 AI 做产品，给 AI 使用，越简单直接越好**。谁先把自己的产品 CLI 化，谁就能先被 AI Agent 接入，谁就能在 AI 时代继续保持竞争力。 国外科技博主 Shawn Yeager 甚至写了一篇文章叫《CLI is the new API》，引起了很大反响。意思是以前产品之间的互通靠 API，现在 AI 时代产品和 AI 之间的互通靠 CLI。 说到 API，你可能会有个疑问：API 接口不也是给程序调用的吗？为什么还需要 CLI 呢？  答案很简单，API 虽然也是程序接口，但调用它需要编写代码。而 CLI 就是一行命令的事，AI 大模型在训练过程中学习了大量命令行语料，理解和生成命令对它来说驾轻就熟，再加上 AI 编程工具可以很方便地执行终端命令，所以 CLI 对 AI 来说几乎是零门槛。 而且 CLI 自带 `--help` 说明书，AI 用到哪个命令就查一下用法，不需要你提前把整本 API 文档都塞给它，能节省 Token 消耗。 你可能又问了：之前很火的 MCP 不也是连接 AI 和工具的协议吗？为什么还需要 CLI？ MCP 协议要求把所有工具的名称和参数格式全部注入到 AI 的上下文里，工具一多 Token 消耗就很夸张。ScaleKit 做过一组基准测试，同样的任务，MCP 的 Token 消耗可能是 CLI 的几十倍！  而且 MCP 的运行过程对人类来说就像个黑盒，出了问题很难排查；CLI 就不一样了，如果出错了，就直接把命令复制到终端里跑一遍，报错信息一目了然。 知名 AI 搜索引擎 Perplexity 的 CTO 公开宣布放弃 MCP 转向 CLI，可见这个趋势已经很明显了。 当然这不是说 MCP 就过时了，在需要统一权限管控的企业场景下，MCP 的标准化鉴权规范依然很有价值。而且 Cursor 最近就上线了按需加载 MCP 的功能，不再一股脑把所有工具定义塞进上下文，而是等 AI 需要用到某个工具时再加载。 ## CLI 开源项目 既然 CLI 这么火，GItHub 上必然少不了和 CLI 相关的开源项目。 目前飞书、钉钉、企业微信、Google 等大厂的 CLI 基本都覆盖了消息、日历、文档、通讯录等核心业务，而且都内置了 AI Agent Skills，可以直接被 Claude Code、Cursor 等 AI 工具调用。  除了大厂官方出品，社区里也涌现了很多有意思的项目。 比如 [OpenCLI](https://github.com/jackwener/opencli) 能把 **任意网站、Electron 应用、甚至本地工具** 统统变成命令行接口。 > 开源指路：https://github.com/jackwener/opencli  如果你想让 AI 帮你查 B 站热门、知乎热榜，装上 OpenCLI 后输入一行命令就搞定了。它内置了几十个适配器，覆盖了 B 站、知乎、Twitter、Reddit 等一大堆平台，就像给 AI 装了一个万能遥控器。  还有 [CLI-Anything](https://github.com/HKUDS/CLI-Anything)，它能自动分析一个开源软件的源码，找出每个功能背后的 API 逻辑，然后自动生成对应的 CLI 命令。 > 开源指路：https://github.com/HKUDS/CLI-Anything  ## 怎么自己做一个 CLI？ 如果你有自己的产品或工具，其实可以做个 CLI，让用户通过 AI 更方便地使用。 开发 CLI 的技术方案有很多。之前我在 [编程导航](https://codefather.cn) 带大家做代码生成器项目的时候，就用过 Java 的 Picocli 框架来开发命令行交互。我还做过极客范浏览器主页的 Web 端 CLI，直接在网页里自主实现了命令行界面。对这些方案感兴趣的同学可以去看我之前的教程。  但下面我要重点介绍一个最近发现的宝藏技术，叫 **Ink**。 这还得感谢前段时间 Claude Code 的源码意外泄露，我扒了一下发现，它是通过一个叫 Ink 的库来开发的。 简单来说，我们平时用 React 写网页，React 会把组件渲染成浏览器里的页面。而 React Ink 做的事情是把同样的 React 组件渲染成终端界面。这个库在 GitHub 上已经有几万 Star，Gatsby CLI、Prisma CLI 等知名项目都在用，非常成熟。 > 开源指路：https://github.com/vadimdemedes/ink 举个例子，比如编写下面这段代码，就能渲染出一个简易的终端，会显示一个每秒自动加 1 的计数器。  了解了 React Ink 之后，我们用它来做一个 CLI 试试。 以我的 [编程导航](https://codefather.cn) 为例，这是一个程序员学习交流社区。做成 CLI 工具之后，用户就可以直接在终端里搜索编程教程、查看热门内容，也方便 AI Agent 调用。  我先为这个 CLI 开发 2 个核心功能：**搜索编程导航的内容** 和 **查看热榜**。 整个开发过程其实就跟写网页差不多，简单的 CLI 工具直接让 AI 一把梭就行。 这里我就用 AI 来开发这个 CLI，先编写给 AI 的提示词： ```markdown 帮我用 React Ink 开发一个名为 codefather-cli 的命令行工具，实现以下功能： 1）codefather search <关键词> 获取编程导航搜索结果 https://www.codefather.cn/search/all?searchText=<关键词> 在终端中展示搜索结果列表，包括标题、作者、点赞数 2）codefather hot 获取编程导航热榜 https://www.codefather.cn/hot/all_hot 在终端中展示热榜 TOP20，包括排名、标题、作者、热度 要求：支持 --help 查看帮助信息 ``` 把这段提示词丢给 Claude Code 或者 Cursor 等 AI 编程工具，AI 就能帮你生成完整的项目代码。  最终运行效果大概长这样，还不错吧~  可以试试让 AI 使用这个工具，AI 通过 `--help` 就能快速了解这个工具怎么用，准确地给出了回答，嘎嘎快！  这就是 CLI 的魅力，对人类来说是一个好用的效率工具，对 AI 来说更是一个天然的操作接口。 ## 最后哔哔 CLI 的回归不是技术的倒退，恰恰说明产品设计的思路在进化。 以前做个产品，只需要考虑人类用户怎么用，现在还得想想 AI 怎么用。 未来的产品可能会有两套前端，一套给人类看的 GUI，一套给 AI 用的 CLI，殊途同归。 建议正在使用 AI 工具的朋友们，多关注一下 CLI 的生态。不管是用 CLI 工具提升自己的效率，还是给自己的产品做一个 CLI 让 AI 能调用，都很有价值。 我是鱼皮，持续分享 AI 编程干货，这篇文章也会收录到我免费开源的 [《AI 编程零基础入门教程》](https://ai.codefather.cn/vibe)，GitHub Star 数已经破万，从零开始带你学会用 AI 开发上线自己的产品。 > 开源仓库：https://github.com/liyupi/ai-guide  学会的话欢迎点赞收藏关注哦，也欢迎评论区聊聊：你用过哪些 CLI？对 CLI 有什么看法？

别再说 AI 编程就是 Vibe Coding 了！6 种主流模式一次讲清

大家好，我是程序员鱼皮。 最近有个朋友跟我说，他去面试的时候，面试官问他：“你对 AI 编程了解多少？” 他张口就来一句 “不就是 Vibe Coding 吗？跟 AI 对话而已，有啥难的？” 然后面试官没绷住笑，反问了一句：“就这？你确定么？” 他愣住了：“阿巴巴巴。。” 如果是 2025 年，这个答案可能还能唬住很多面试官，因为那会儿大家一提 AI 编程，脑子里就只有 Vibe Coding。跟 AI 随便聊几句，代码就出来了，能跑就行。 但 2026 年了，AI 编程的玩法早就不只这一种了！ **AI 编程 != Vibe Coding** Vibe Coding 只是 AI 编程众多模式中的一种，而且是最随性的那种。如今 AI 编程的模式已经非常多了，从跟着感觉走到按流程来，从一个人问 AI 到一整套方法论驱动，不同场景有不同的最佳实践。 今天就给大家一次性讲清楚，目前主流的 6 种 AI 编程模式到底是什么？有什么区别？各自适合什么场景？ 搞懂这些，下次面试再被问到 AI 编程，你就能从容地掏出一整套体系了。 > 本文内容节选自鱼皮免费开源的 [《AI 编程零基础入门教程》](https://ai.codefather.cn/vibe) 中的「Vibe Coding 概念大全」篇，想系统学习 AI 编程的朋友可以直接去看完整教程。 ## 一、Vibe Coding 氛围编程 Vibe Coding 是由计算机科学家 Andrej Karpathy 在 2025 年 2 月提出的概念。它描述了一种全新的编程方式：通过自然语言和 AI 对话，让 AI 帮你写代码，你只需要描述需求、测试结果、指导方向。 你不需要精通编程语法，只需要能清楚表达你的想法，AI 负责把你的想法变成可运行的代码。 所以说，Vibe Coding 的重点不是写代码，而是明确需求并清晰表达。你描述得越清楚，AI 给你的结果就越靠谱。 这就像点外卖一样，你告诉外卖平台你想吃什么，餐厅帮你做好送到手上。你不需要会做饭，但要知道自己想吃什么。 适合场景：做小工具、快速验证想法、个人项目原型、非程序员想快速做出产品。  ## 二、Agentic Engineering 智能体工程 Agentic Engineering 智能体工程是 2026 年 2 月由 Andrej Karpathy（也就是提出 Vibe Coding 的那位大佬）提出的新概念，可以理解为 Vibe Coding 的规范版。 Vibe Coding 就是跟着感觉写代码：你给 AI 一句话，AI 吐出代码，能跑就行，跑不了就把报错粘回去让 AI 再改。做个小工具贼拉快，但项目一大就容易翻车。 而 Agentic Engineering 的思路是：你先想清楚要干嘛、写好方案、拆好任务，再把活交给 AI 去执行，它干完了你还得验收，质量不行再打回去重做。 打个比方，Vibe Coding 的时候你是个 DJ，放什么歌全凭感觉；Agentic Engineering 里你是包工头，流程、质量、验收都得你说了算。**一个跟着感觉走，一个按流程来。** 当然，不是说 Vibe Coding 已经过时了。Vibe Coding 负责让你看到可能性，Agentic Engineering 负责把可能性变成真正能用的东西。二者适用于不同的场景，做小工具时可以用 Vibe Coding，做企业级项目就需要 Agentic Engineering 的思维。  适合场景：中大型项目、团队协作、需要长期维护的正式产品。 ## 三、Harness Engineering 驾驭工程 Harness Engineering 驾驭工程是 2026 年兴起的 AI 工程新范式，核心理念是 **人类掌舵 + 智能体执行**。 它不是去优化 AI 模型本身，而是围绕 AI 智能体搭建一整套约束机制、反馈循环和工作流管理系统，让原本不可预测的 AI 在高可靠性环境下跑得稳、跑得快。 Harness 这个词本意是 “马具”，就像缰绳和马鞍用来引导强大但难以预测的马匹一样，Harness Engineering 就是围绕 AI 编程智能体搭建的整套 “运行环境”，确保 AI 能按照你的预期工作。 Harness Engineering 包含三大核心支柱： 1. 上下文工程：确保 AI 在正确的时间获得正确的信息，包括代码库文档、架构规范、AGENTS.md 文件、测试结果等 2. 架构约束：通过代码规范检查器、自动化测试等机制，强制规定 AI 必须遵守的规则，明确的边界能让 AI 更快地收敛到正确的解决方案 3. 熵管理：定期清理 AI 生成代码中积累的问题，比如过时文档、命名偏差、死代码等  为什么这个概念越来越重要呢？ 因为在 AI 编程时代，**模型本身已经是通用商品，真正的竞争力在于你围绕模型搭建的工程体系**。同一个大模型，在不同的 Harness 环境下，代码质量可能天差地别。程序员的角色正在从 “自己写代码” 转变为 “设计让 AI 可靠写代码的系统”。 适合场景：企业级 AI 开发、对代码质量和稳定性要求高的项目、需要多人协作的长期项目。 ## 四、Ralph Wiggum Loop Ralph Wiggum Loop 是 2026 年比较流行的一种 AI 编程模式，名字来源于《辛普森一家》中那个执着不放弃的角色 Ralph Wiggum。  这个模式目前已有多个开源实现，比如 [wiggumdev/ralph](https://github.com/wiggumdev/ralph)。它的核心思路很简单：**把 AI 放在循环中反复执行，直到需求文档中的所有检查项全部完成。** 工作流程大概是这样的： 1. 先写一份 PRD（产品需求文档），把要做的功能拆解成一个个清晰的检查项 2. 让 AI 智能体开始执行，每次从检查清单中取出未完成的任务 3. AI 完成一个任务后，通过 Git 提交代码并记录进度 4. 以全新的上下文开始新一轮迭代，继续处理剩余任务 5. 不断循环，直到所有检查项完成 这种模式的巧妙之处在于，每轮循环都以干净的上下文开始（通过 Git 和文件来持久化进度），避免了长对话中 AI 容易断片儿的问题。而且可以无人值守地运行，你写好 PRD 就可以去睡觉了，第二天起来检查成果就行。 不过要注意设置好循环次数限制和 Token 预算，防止 AI 陷入无限循环疯狂烧钱。 适合场景：功能明确且可拆解的项目、想让 AI 无人值守地干活、任务量大但单个任务相对独立。 ## 五、BMAD 敏捷 AI 开发方法 BMAD-METHOD（Breakthrough Method of Agile AI-Driven Development，突破性敏捷 AI 驱动开发方法）是一套系统化的 AI 智能体开发框架，目标是将原本混乱的 AI 编程过程变得结构化、可复用。 BMAD 使用 **角色化智能体** 的方式组织开发流程，每个智能体扮演特定角色： - Analyst Agent 分析师：创建项目简报，包含市场分析和用户画像 - PM Agent 产品经理：将简报转化为详细的产品需求文档（PRD） - Architect Agent 架构师：设计技术实现方案和系统架构 BMAD 中的智能体分为两种类型： - Simple Agents 简单智能体：单文件、自包含，适合代码审查、文档生成等聚焦任务 - Expert Agents 专家智能体：具有跨会话持久记忆，配有专属文件夹存放资源，适合复杂的多步骤工作流 每个智能体都有标准化的组成部分，包括人设（角色、身份、沟通风格、原则）、能力列表、交互菜单，以及可选的关键行动。  BMAD 在 GitHub 上获得了几万+ Star，说明这种结构化的 AI 开发方法正在被越来越多的开发者认可。  适合场景：从零开始的完整项目、需要走完分析-设计-开发全流程的产品、团队想要标准化 AI 开发流程。 ## 六、SDD 规范驱动开发 SDD（Spec-Driven Development 规范驱动开发）是 AI 时代的一种新型开发方法论，强调在编码之前先创建明确的、AI 能直接理解和执行的规范文档。 传统开发流程是：想到什么写什么，边写边改，最后再补文档。这样容易导致需求不清晰、代码和文档对不上。 而 SDD 的思路正好相反：**先把需求写成规范文档，并且把规范文档当作代码的唯一真相来源**。 你可以把规范文档理解为 “项目宪法”，它包含了详细的需求描述、系统设计和接口定义。AI 必须严格遵守这些条文来生成代码，确保产出完全符合预期。  为什么 SDD 越来越受重视？ 因为 AI 生成代码的质量直接取决于上下文的清晰度，而不仅仅是依靠提示词技巧。一个清晰的规范文档能比任何 Prompt 黑魔法更有效地减少错误。 SDD 的典型工作流程如下： 1. Constitution 制定准则：定义项目的基本原则、代码规范、性能标准 2. Specify 编写规范：描述要做什么功能、为什么做、用户需求是什么 3. Clarify 澄清疑问：让 AI 提出结构化问题，明确边界情况和错误处理 4. Plan 制定方案：确定技术栈、系统架构、数据模型、API 接口 5. Tasks 拆解任务：把计划拆解成可执行的任务列表，标注依赖关系和优先级 6. Implement 执行实现：AI 按照任务列表生成代码，人类验证 其实这和程序员在企业中开发项目的标准流程非常相似，只不过执行者从人变成了 AI。  2025 年 9 月，GitHub 发布了开源的 [Spec Kit](https://github.com/github/spec-kit) 工具包，帮助开发者在 AI 编程中实践 SDD 方法论。它支持 Claude Code、GitHub Copilot 等主流编程工具，通过一套斜杠命令引导你完成上述流程。即使你不是软件开发专家，也能在 AI 的引导下轻松地走完规范的项目开发流程。  适合场景：需求复杂且明确的项目、对代码质量要求高的场景、团队多人协作开发。 ## 对比一下 学完这些模式后，再来给大家用一张表格来汇总： | 模式 | 一句话总结 | 上手门槛 | 适合项目规模 | |------|-----------|---------|-------------| | Vibe Coding | 跟着感觉走，能跑就行 | 最低 | 小项目/原型 | | Agentic Engineering | 包工头模式，先规划再执行 | 中等 | 中大型项目 | | Harness Engineering | 给 AI 套上缰绳，搭建可靠的运行环境 | 较高 | 企业级项目 | | Ralph Wiggum Loop | 写好清单让 AI 循环干，干完为止 | 中等 | 功能明确的中型项目 | | BMAD | 角色扮演式开发，分析师+产品+架构全上 | 中等 | 从零开始的完整产品 | | SDD | 先写规范文档，再让 AI 照着做 | 中等 | 需求明确、质量要求高的项目 | 注意，这些模式之间并不是互相排斥的，实际开发中完全可以混着用。比如用 SDD 先把规范写好，再用 BMAD 的角色化智能体去执行，底层用 Harness Engineering 的思路来约束 AI 的行为。灵活组合，效果更佳。 ## 最后 回到开头那个面试场景，如果你只知道 Vibe Coding，说明你还停留在 AI 编程的入门阶段。但如果你能把这 6 种模式的适用场景和优劣讲清楚，面试官大概率会对你刮目相看。 话说 AI 编程这个领域变化太快了，现在的最佳实践，过几个月可能就会有更好的替代方案。保持学习、多动手尝试，比记住任何一个概念都重要。 如果你是刚开始学习 AI 编程，肯定是从 Vibe Coding 学起，如果你想系统学习 AI 编程的完整知识体系、快速做出企业级项目和商业产品，可以看我免费开源的 [《AI 编程零基础入门教程》](https://ai.codefather.cn/vibe)，GitHub Star 数破万，涵盖从零基础入门到项目实战再到产品变现的全流程。 > 开源仓库：https://github.com/liyupi/ai-guide  我是鱼皮，持续分享 AI 编程干货，学会的话欢迎点赞收藏关注哦，也欢迎评论区聊聊你现在用过哪些 AI 编程模式~