开发了一个 Agent Skill：把 Vibe Coding 从「想到哪写到哪」，变成可恢复、可验证、可持续迭代的工作流

> 欢迎 Star、体验与贡献： 👉开源地址：https://github.com/sz-xiaohuolong/vibe-workflow ## 背景 先说结论：AI 已经很会写代码了，但「会写」不等于「会把项目做完」 这两年，我越来越频繁地使用 Codex、Claude Code 这类 Coding Agent 做真实项目。 刚开始的时候，体验确实很爽： > 「帮我做一个录音软件。」 几分钟后，目录有了，页面有了，代码也有了。 但项目一旦从 Demo 进入真实开发，问题很快就会出现。 比如： - 需求还没有想清楚，Agent 已经开始搭架构、写代码； - 开发到一半随口说一句「顺便加个功能」，整个版本范围开始漂移； - 新开一个会话，Agent 不知道昨天做到哪里，只能重新猜； - 修一个 Bug 连续 Patch 多次，修 A 坏 B，代码越来越乱； - 代码写完了，但测试没跑、Build 没过，Agent 仍然告诉你「Done」； - v0.1、v0.2、v0.3 的文档混在一起，旧需求重新污染当前上下文； - 你只是让它改一个小功能，它却顺手碰了 Schema、权限甚至外部服务。 这些问题的共同点不是： > **AI 不会写代码。** 而是： > **AI 缺少一套能够约束「什么时候做什么、什么时候必须停、什么才算完成」的软件工程工作流。** 于是我做了 **Vibe Workflow**。 ## 1. Vibe Workflow 是什么？ Vibe Workflow 是一个 **Agent Lifecycle Orchestrator Skill**。 它的职责不是重新发明一套 TDD、Debugging 或 Code Review 教程，而是站在这些专业能力之上，负责整个项目的生命周期编排。 我给它定了一个很简单的边界： > **Grill Me 负责确认做什么；Vibe Workflow 负责可靠地把它做出来。** 换句话说： ```text 模糊想法 ↓ Grill Me / Requirement Clarification ↓ 冻结需求 ↓ Vibe Workflow ↓ SPEC ↓ Technical Design ↓ Implementation Plan ↓ Build ↓ Verify ↓ Review ↓ Ship ↓ Maintain ↺ ``` Vibe Workflow 可以作为统一入口。 如果它发现当前需求还没有冻结，就会停止工程活动，并把需求澄清路由给 `grill-me` 或等价能力；需求满足工程入口条件后，再继续后面的 SPEC、设计和实现。 这也是我最希望它解决的问题： > **让用户不需要自己记「现在该调用哪个 Skill」，而是让 Workflow 根据项目状态完成编排。** *** ## 2. 为什么我不想再用「一个超级 Prompt」管理项目？ 很多 Vibe Coding 工作流最后都会变成一段越来越长的提示词： ```text 先读需求 → 再设计 → 再编码 → 记得测试 → 不要乱改 → 遇到 Bug 要分析 → 记得更新文档 → 记得 Git Commit → ... ``` 问题在于，Prompt 越长，并不代表工程越可靠。 真正稳定的软件项目，需要的是： - 状态； - 事实源； - 决策关卡； - 可恢复的进度； - 清晰的版本边界； - 可验证的完成证据； - 按需加载的上下文； - 专业 Skill 之间的编排。 所以 Vibe Workflow 的核心思路不是： > **给 Agent 更多指令。** 而是： > **给 Agent 一个可以运行的软件工程 Harness。** *** ## 3. 整体架构：三层，而不是一个 Skill 包打天下 我把整个体系分成三层。 ```mermaid flowchart TD A["用户想法 / 新版本需求"] --> B["Requirement Layer"] B --> C["Grill Me / Requirement Clarification"] C --> D["Frozen Requirement Baseline"] D --> E["Orchestration Layer"] E --> F["Vibe Workflow"] F --> G["Capability Layer"] G --> H["Brainstorming"] G --> I["Writing Plans"] G --> J["TDD"] G --> K["Systematic Debugging"] G --> L["Code Review"] G --> M["Verification"] ``` #### 第一层：Requirement 负责把模糊想法问清楚，并冻结当前 Release 的产品范围。 #### 第二层：Vibe Workflow 负责判断： 1. 当前处于什么状态？ 2. 下一步应该做什么？ 3. 哪些动作允许 Agent 自主完成？ 4. 哪些事情必须等待人类确认？ 5. 应该调用哪个专业 Skill？ 6. 结果应该写回哪个项目事实源？ #### 第三层：专业能力 例如 Superpowers 中的： - `brainstorming` - `writing-plans` - `test-driven-development` - `systematic-debugging` - `requesting-code-review` - `verification-before-completion` Vibe Workflow 不复制它们。 它只负责： > **When to invoke what, and where the result becomes durable project state.** ## 4. 第一条铁律：工程开始之前，需求必须冻结 这是整个 Skill 最核心的设计。 新项目或新 Release 想进入 SPEC、技术设计或 Build，至少要满足： ```text Requirement Status == FROZEN Open Questions == None Current Release ID exists Acceptance Goals are testable ``` 如果没有满足，就不能因为用户说了一句： > 「直接做吧。」 Agent 就开始脑补需求。 在 Vibe Workflow 里： > **授权实现，不等于授权定义产品范围。** 我把这条原则总结成了一句话： > **What to build is frozen. How to build it is delegated.** 「做什么」必须由人确认。 但「怎么实现」尽量交给 Agent 自己解决。 例如这些通常不需要反复问用户： - 内部函数叫什么； - helper 怎么拆； - 私有接口怎么组织； - 测试文件放在哪里； - 沿用现有项目规范时，目录怎么安排。 而这些必须经过 Human Decision Gate： - 产品范围变化； - Requirement Change； - Public API Breaking Change； - Database Schema / Migration； - 权限与安全模型； - 破坏性操作； - 新的外部付费服务； - Push、PR、Publish、Deploy、Release。 这解决了两个极端： > 既不让 Agent 擅自替你做产品经理，也不让它为了一个变量名来问你三遍。 ## 5. 一个项目不是一次 Prompt，而是多个 Release 真实项目一定会迭代。 比如： ```text Project ├── v0.1 ├── v0.2 ├── v0.3 └── v1.0 ``` 所以 Vibe Workflow 把 **Release** 作为主要生命周期单位。 每个版本都走一次完整但可裁剪的工程流程： ```mermaid flowchart LR A["REQUIREMENTS_FROZEN"] --> B["SPECIFIED"] B --> C["DESIGNED"] C --> D["PLANNED"] D --> E["BUILDING"] E --> F["VERIFYING"] F --> G["REVIEWING"] G --> H["READY_TO_SHIP"] H --> I["RELEASED"] ``` 这意味着： - v0.1 有自己的冻结需求和 SPEC； - v0.2 有自己的冻结需求和 SPEC； - v0.3 也一样。 不会把所有版本一直追加在同一份 PRD 后面。 ## 6. 为什么我用 SPEC，而不是继续堆一套大而全 PRD？ 我希望 Agent 看到的是明确、可实现、可验证的产品行为。 所以在这个体系里： #### `PROJECT_BRIEF` 负责回答： > **这个 Release 到底要做什么？** 包括： - Problem - Target User - Core Scenario - In Scope - Out of Scope - Constraints - Acceptance Goals - Requirement Status #### `SPEC` 负责回答： > **被冻结的需求，具体应该表现成什么行为？** 例如： ```text REQ-003 Start Recording AC-007 点击开始录音后进入 recording 状态。 AC-008 录制失败时必须显示明确错误，不能静默失败。 ``` 因此，`SPEC` 不是另一份重复 PRD。 它更像： > **冻结需求面向工程实现和测试的 Effective Spec。** ## 7. 历史版本和当前事实必须分开 这是我在长期使用 Coding Agent 后越来越重视的一点。 - 如果把所有东西都当成「Living Document」，历史会被不断改写。 - 如果把所有东西都按版本复制，Agent 又会被历史上下文淹没。 所以 Vibe Workflow 将文档分成两类。 ### Released Artifacts：保存当时发生了什么 例如： ```text docs/vibe/releases/v0.2/ ├── PROJECT_BRIEF.md ├── CHANGE.md ├── SPEC.md ├── IMPLEMENTATION_PLAN.md └── VERIFICATION.md ``` Release 完成后，历史 Artifact 原则上封存。 ### Living Documents：描述项目现在是什么样 例如： ```text docs/vibe/ ├── PROJECT.md ├── TECH_DESIGN.md └── PROGRESS.md ``` 重大架构变化则通过： ```text docs/vibe/decisions/ ``` 持续记录。 这个模型可以概括成： > **Released artifacts preserve history. Living documents describe current truth.** ## 8. `PROGRESS.md`：让 Agent 真正支持「明天继续」 很多人说 Agent 有记忆。 但对软件工程来说，我更相信： > **Repository is memory. Chat is conversation.** 聊天是瞬时的。 仓库才是持久状态。 所以 `PROGRESS.md` 在 Vibe Workflow 里非常重要。 它负责记录： ```text Current Release Current Requirement Baseline Current Workflow State Current Slice Current Task Last Stable Commit Completed Tasks Verification Evidence Known Bugs Blockers Open Decisions Next Task ``` 这样今天关闭 Codex，明天重新打开，只需要： ```text $vibe-workflow 继续当前软件项目，并从仓库事实恢复正确状态。 ``` Agent 会根据 Git、代码、测试和项目文档恢复当前状态，而不是靠聊天记忆猜。 ## 9. Context Governor：不是上下文越多越好 这是我认为 Vibe Coding 很容易被忽略的一点。 很多时候，我们会下意识地认为： > 「多给 Agent 一些上下文，总不会错。」 但长期项目里，大量历史信息本身就是噪声。 所以 Vibe Workflow 默认遵循： > **Minimal Sufficient Context** 例如当前任务只是「实现删除录音」，它应该优先读取： ```text AGENTS.md PROGRESS.md 当前 Release 的 Effective SPEC 对应 REQ / AC TECH_DESIGN 的相关部分 当前 Task 相关代码 相关测试 ``` 而不是默认读取： ```text 全部历史 Release 全部 Bug 全部 Decision 整个 Git History 整个仓库 ``` 目标不是让 Agent「知道所有事情」。 而是让它： > **知道完成当前任务所必需的事情。** ## 10. Tiny / Bounded / Architectural：复杂任务严谨，简单任务不官僚 工程流程一旦做重，很容易走向另一个极端： > 改一个按钮文案，也要写 5 份设计文档。 所以 Vibe Workflow 会同时判断： ```text Task Type + Task Complexity ``` 任务类型包括： ```text NEW_PROJECT FEATURE BUG REFACTOR SPIKE REQUIREMENT_CHANGE ``` 复杂度包括： ```text Tiny Bounded Architectural ``` 例如： | 请求 | 分类 | 处理方式 | | ------------------- | ----------------------- | ------------------------------ | | 「把 Start 改成 Record」 | FEATURE + Tiny | 精确修改、验证，不生成完整设计文档 | | 「增加删除录音」 | FEATURE + Bounded | Acceptance + Task Plan + Tests | | 「增加多设备云同步」 | FEATURE + Architectural | 需求冻结 + 设计决策 + 完整计划 | 我很喜欢这句话： > **Complex tasks are rigorous. Simple tasks are not bureaucratic.** *** ## 11. Decision Gate：风险不是看改了多少行代码 一个改动只有 1 行，也可能非常危险。 例如： ```text isAdmin = true ``` 所以风险不能简单通过「代码量」判断。 Vibe Workflow 会优先检查： - Product - Schema - Security - Destructive Operation - External Service - Shipping 等 Decision Gate。 特别是 Schema 这类改变，不能出现： ```text Agent： “为了实现功能，我顺手给 users 表加了两个字段。” ``` 而应该先： ```text Investigate ↓ Proposal ↓ Options / Trade-offs ↓ Recommendation ↓ Explicit Human Approval ↓ Migration ↓ Verification ``` **调查完成，不等于获得执行授权。** *** ## 12. Circuit Breaker：AI 最危险的不是第一次写错，而是连续自信地写错 这一点我特别想做进 Skill。 典型 Vibe Coding Bug 修复流程： ```text 改一个参数 ↓ 没好 ↓ 再改一个参数 ↓ 又坏一个地方 ↓ 再 Patch ↓ 代码越来越乱 ``` Vibe Workflow 加入了 Circuit Breaker。 当出现： - 同类失败连续 3 次； - 修 A 坏 B/C； - 底层架构假设失效； - 修改范围持续扩大； 就必须： ```text STOP PATCHING ↓ Preserve Last Known Good State ↓ Record Debug Snapshot ↓ Operational Status = REPLAN_REQUIRED ↓ Systematic Debugging / Redesign / Replan ``` 它会区分： > **Retry** 和： > **Replan** 不是所有失败都值得「再试一下」。 *** ## 13. Verification 和 Shipping 必须「两权分立」 这是另一个我非常坚持的设计。 ```text Verification Status = 客观证据说明了什么 Shipping Authorization = 人类是否允许执行发布动作 ``` 比如： > 「测试来不及跑了，先发，我承担风险。」 这是一个合法的业务决定。 但它不能把： ```text UNVERIFIED ``` 改写成： ```text VERIFIED ``` 在 Vibe Workflow 中： > **人可以接受风险，但不能修改事实。** 没有 fresh verification evidence，就不能声称： ```text DONE FIXED VERIFIED READY_TO_SHIP ``` 同时，Push、PR、Publish、Deploy、Release 仍然需要明确的人类授权。 *** ## 14. Build 也不是「读完 SPEC，然后一次性写完整项目」 我更希望开发循环是这样的： ```mermaid flowchart TD A["Select Next Task"] --> B["Assemble Task Context"] B --> C["Inspect Existing Code / Tests"] C --> D["RED：先看到正确失败"] D --> E["Minimal Implementation"] E --> F["GREEN"] F --> G["Refactor"] G --> H["Task Verification"] H --> I["Inspect Diff / Review"] I --> J["Commit"] J --> K["Update PROGRESS"] K --> L["Next Task"] ``` 每个版本内部还可以继续拆： ```text Project ↓ Release ↓ Phase（可选） ↓ Vertical Slice ↓ Task ``` 尽量按照可运行、可测试、可提交的 **Vertical Slice** 推进，而不是先把所有数据库写完、再把所有后端写完、最后一起调试。 *** ## 15. Bug 不应该重新走完整产品流程 如果只是普通 Bug： ```text Bug Report ↓ Reproduce ↓ Evidence ↓ Root Cause ↓ Regression Test ↓ Fix ↓ Verify ``` 但如果调查后发现： > 不是实现错了，而是 SPEC 本身定义错了。 那么： ```text BUG ↓ REQUIREMENT_CHANGE ``` 必须重新经过 Requirement Change Gate。 这可以避免 Agent 为了「修 Bug」偷偷改产品定义。 *** ## 16. 它不是 Superpowers 的替代品，而是编排层 Vibe Workflow 当前已经为专业 Skill 预留了明确的路由。 例如： | 场景 | 推荐能力 | | ------------------------ | ---------------------------------------------- | | Requirement 不完整 | \`grill-me\` 或等价 Requirement Clarification | | Architectural Design | \`superpowers:brainstorming\` | | 多步骤 Implementation Plan | \`superpowers:writing-plans\` | | Feature / Bug / Refactor | \`superpowers:test-driven-development\` | | Bug / Test Failure | \`superpowers:systematic-debugging\` | | 重要 Task / Feature | \`superpowers:requesting-code-review\` | | 完成声明之前 | \`superpowers:verification-before-completion\` | 这也是整个 Skill 的定位： > **Vibe Workflow 负责生命周期；专业 Skill 负责专业动作。** *** ## 17. Before vs After：几个最典型的使用场景 | 场景 | 普通 Coding Agent | Vibe Workflow | | ------------- | --------------- | ---------------------------------------- | | 模糊需求让它「直接做」 | 开始脑补产品和架构 | Requirement Gate 未通过，先澄清并冻结 | | 开发中说「顺便加云同步」 | 直接开始加功能 | 识别 Requirement Change，等待明确决策 | | 改一个按钮文案 | 可能过度规划 | Tiny Task，最小修改 + 验证 | | 想改数据库 Schema | 顺手写 migration | Schema Gate：调查 → 提案 → 人类批准 → 执行 | | Bug 连续修 3 次失败 | 继续 Patch | Circuit Breaker → \`REPLAN\_REQUIRED\` | | 新开会话继续项目 | 依赖旧聊天上下文 | 从 Repository + Git + PROGRESS 恢复 | | 代码写完但没测试 | 「Done」 | 保持 \`UNVERIFIED\` | | 老板说「先发布」 | 可能把发布当验证完成 | Shipping Authorization 与 Verification 分离 | ## 18. 这个 Skill 自己也做了测试 我不希望它只是： > 「一篇看起来很完整的软件工程 Prompt。」 所以仓库里专门保留了 Skill 行为测试： ```text tests/ ├── scenarios.md ├── rubric.md ├── validate_skill.sh └── results/ ``` 当前 V0.1 README 中记录了： - 4 类 control / candidate wording micro-tests； - 20 个批准场景； - 5 个独立审查回归场景。 测试重点不是某个函数返回值，而是 Agent 在压力下是否真的遵守工作流。 例如： - 用户催促时会不会绕过 Requirement Gate？ - Tiny Task 会不会被过度文档化？ - Schema Change 会不会偷跑？ - 连续失败后是否会触发熔断？ - 没有 Fresh Evidence 时会不会假装完成？ - 当前版本是否只读取当前 Effective SPEC，而不是把所有历史版本塞进 Context？ *** ## 19. 如何安装？ 当前仓库已经可以作为 Codex Agent Skill 直接安装。 ### 方式一：在 Codex 中安装 把下面这句话发送给 Codex： ```text 请使用 $skill-installer 从 https://github.com/sz-xiaohuolong/vibe-workflow/tree/main/skills/vibe-workflow 安装这个 Skill ``` ### 方式二：使用 Codex 内置安装脚本 ```bash python3 "${CODEX_HOME:-$HOME/.codex}/skills/.system/skill-installer/scripts/install-skill-from-github.py" \ --repo sz-xiaohuolong/vibe-workflow \ --path skills/vibe-workflow ``` 安装后，从下一轮会话开始使用： ```text $vibe-workflow 继续当前软件项目，并从仓库事实恢复正确状态。 ``` 对于一个需求还没有冻结的新项目，也可以直接从 `$vibe-workflow` 进入；它会根据 Requirement Gate 判断是否需要先调用 `grill-me` 或等价的需求澄清能力。 ## 20. 如何使用？ 安装完成、从下一轮会话开始后，Vibe Workflow 主要有三类用法。 1）**新项目从零开始。** 对一个需求还没有冻结的新项目，直接对 Codex 说： ```text $vibe-workflow 我想做一个录音软件 ``` 它会先检查 Requirement Gate：需求未冻结就暂停工程活动，先路由到 `grill-me` 或等价的需求澄清能力；需求冻结后再自动进入 SPEC、设计、Build、Verify、Review、Ship 的后续流程。 2）**继续昨天的项目。** 每天开始工作时说： ```text $vibe-workflow 继续当前软件项目，并从仓库事实恢复正确状态。 ``` Agent 会根据 Git、代码、测试和 `PROGRESS.md` 恢复当前状态，而不是靠聊天记忆猜。 3）**日常迭代与 Bug 修复。** 新增功能就把需求说清楚，交给 Workflow 走一次 Release 流程；修 Bug 就直接描述现象，它会走「Reproduce → Root Cause → Regression Test → Fix → Verify」；想改 Schema 或发布，它会先触发对应的 Decision Gate，等你明确授权后再执行。 使用上记住三句话即可： > **你确认做什么，实现交给 Agent；发布与破坏性操作必须你点头；没有验证证据，Agent 不能说 Done。** ## 21. 哪些人可能适合用它？ 如果你只是让 AI： > 「帮我写一个正则表达式。」 那你大概率不需要它。 但如果你在做下面这些事情，它可能会比较有价值： #### 个人开发者 使用 Codex / Coding Agent 从 0 到 1 做真实项目，希望几周、几个月后仍然能继续维护。 #### Vibe Coding 重度用户 已经发现「生成代码很快，但控制代码熵和需求漂移越来越难」。 #### Agent 工程实践者 希望把 Requirement、Design、Plan、Build、Verification、Release 变成 Agent 可执行的生命周期。 #### 多 Agent / 多 Skill 使用者 已经安装多个专业 Skill，但缺少一个统一的 Lifecycle Orchestrator 来判断什么时候应该调用谁。 #### 长期维护项目 需要跨会话、跨 Release、跨 Bug 修复持续迭代，而不是只做一次性 Demo。 ## 22. 我对 Vibe Coding 的一个判断 我现在越来越觉得： > **Coding Agent 的能力越强，Workflow 反而越重要。** 模型弱的时候，人需要告诉它每一步怎么写。 模型越来越强之后，真正重要的问题开始变成： - 它有没有跑偏？ - 它有没有偷偷扩大范围？ - 它读取的是不是正确上下文？ - 它现在到底在 v0.2 还是 v0.3？ - 它为什么说完成？ - 这次修改有没有证据？ - 哪些事情应该自己决定？ - 哪些事情必须停下来问人？ - 新会话能不能无损继续昨天的工作？ 换句话说： > **AI 编码的瓶颈，正在从「Code Generation」逐渐转向「Engineering Control」。** Vibe Workflow 就是我对这个问题的一次尝试。 它不是为了让 Agent 一次生成更多代码。 而是为了让一个项目经历： ```text 10 个 Task → 50 个 Task → 3 个 Release → 多次 Bug 修复 → 多次新会话 ``` 之后，依然保持： > **可理解、可恢复、可验证、可迭代。** *** ## 23. 写在最后 这个项目目前还是 V0.1。 我更希望它未来变成一个真正经过真实项目不断压测和修正的工作流，而不是继续往 `SKILL.md` 里堆规则。 我给它保留了几条一直不会变的原则： > **Repository is memory. Chat is conversation.** > **What to build is frozen. How to build it is delegated.** > **Minimal sufficient context.** > **Complex tasks are rigorous. Simple tasks are not bureaucratic.** > **Evidence before completion.** 如果你也在使用 Codex、研究 Agent Skill、Vibe Coding、Harness Engineering，欢迎拿真实项目来试一试。 如果它对你有帮助，也欢迎给项目一个 ⭐ Star。 GitHub： [**https://github.com/sz-xiaohuolong/vibe-workflow**](https://github.com/sz-xiaohuolong/vibe-workflow "https://github.com/sz-xiaohuolong/vibe-workflow") 也欢迎通过 Issue 提出： - 你遇到的 Vibe Coding 失控场景； - 当前 Workflow 没覆盖到的边界； - 哪些 Gate 太重； - 哪些规则还不够严格； - 哪些真实场景应该加入下一轮行为测试。 > **之后我也会用这个 Skill 做出更多的产品与大家分享心路历程。** ### 参考与致谢 这个 Skill 的设计过程中参考了多种公开的软件工程、Agent Skill 和 Vibe Coding 实践，包括： - 鱼皮哥的Vibe Coding知识库：[AI 编程零基础入门教程 Vibe Coding ](https://ai.codefather.cn/library/2010994846520700929 "https://ai.codefather.cn/library/2010994846520700929") - 吃遍全国汉堡的文章：[如何从0到1 Vibe Coding 一个项目，并长期维护](https://www.codefather.cn/post/2077996578576056322) - Superpowers：用于 Brainstorming、Planning、TDD、Systematic Debugging、Verification 等专业能力的组合思路 - project-vibe-spec：[https://github.com/dnwwdwd/project-vibe-spec](https://github.com/dnwwdwd/project-vibe-spec "https://github.com/dnwwdwd/project-vibe-spec")

🎙️面试官说的每一句话，我都想留下来：于是我用 Vibe Coding 做了一个免费的 macOS 面试录音工具

## 背景 找过工作的人应该都懂： > **面试复盘有多重要，复盘就有多难。** 一场技术面四五十分钟下来，面试官可能连续问你： - Java / JVM - MySQL / Redis - 项目设计 - Agent / RAG - 场景题 - 算法题 面试结束以后，你脑子里往往只剩下几个模糊片段： > “刚刚那个问题，我是不是答错了？” > “面试官追问了什么来着？” > “我项目那里是不是讲得特别乱？” 更尴尬的是： **你明明知道这场面试里暴露了很多问题，却已经记不清到底暴露了什么。** 于是我想做一件非常简单的事：把面试完整录下来。 然后： ```text 线上面试 ↓ 完整录音 ↓ Whisper / AI 转录 ↓ 生成面试逐字稿 ↓ ChatGPT ↓ 逐题复盘 ``` 让 AI 帮我重新整理： - 面试官到底问了什么？ - 我的原回答是什么？ - 哪些地方答错了？ - 哪些地方虽然没错，但表达很差？ - 一个更好的面试回答应该是什么？ - 这场面试暴露了哪些知识薄弱点？ - 下一场面试前应该重点补什么？ 想法非常简单。 结果真正到了 Mac 上，我发现： > **“把面试官声音 + 自己声音一起录下来”居然没想象中那么省事。** ## 我只是想录个面试，为什么突然开始学虚拟声卡了？ 我的需求真的非常朴素： ```text 面试官的声音 + 我自己的回答 ↓ 一个音频文件 ``` 甚至： > **我连屏幕都不需要录。** 结果调研了一圈以后，发现现有方案大概是这样。 ### 方案一：系统自带录音备忘录 简单是简单。 但很多情况下你最终得到的是： ```text ✅ 自己的麦克风 ❌ 系统内部声音 ``` 也就是说： **你说的话录下来了，面试官的问题没了。** 那还复盘什么…… --- ### 方案二：OBS OBS 当然非常强。 但第一次打开： ```text 场景 来源 音频混音器 音轨 编码器 输出 容器 ``` 我当时只有一个想法： > **我真的只是想录个音。** 😂 --- ### 方案三：BlackHole / 虚拟声卡 这条路线也完全能解决问题。 但很快就变成： ```text 安装 BlackHole ↓ Audio MIDI Setup ↓ Multi-Output Device ↓ Aggregate Device ↓ 检查 Clock Source ↓ 检查 Drift Correction ``` 我： > “等一下，我不是来准备面试的吗？” --- ### 后来我发现了 LoopRec 在调研过程中，我看到了一款让我非常喜欢的软件： **LoopRec。** 它真正让我喜欢的不是功能特别多，而是： > **功能特别少。** 打开以后基本就是： ```text 系统声音 ON 麦克风 ON 系统声音音量 90% 麦克风音量 100% 开始录音 ``` - 没有场景。 - 没有复杂混音台。 - 没有一堆专业录音参数。 这才是我理解中的：“面试录音工具”。 但它的免费版本存在**单次录制时长限制**。问题是技术面试这种东西，很难控制时长：  ```text 30 min 45 min 60 min 90 min 120 min ``` 都有可能。 总不能面试进行到一半说： > “面试官您好，我这个录音软件免费额度快到了，要不今天先到这里？” 😂 然后那个非常典型的程序员念头就出现了：要不我自己写一个？ 于是 InterviewRec 出现了。 ## InterviewRec 一句话介绍： > **一个免费、开源、原生、轻量的 macOS 面试 / 会议录音工具。** 它的工作流程只有： ```text Mac 系统声音 ─┐ ├──→ InterviewRec ──→ M4A 麦克风声音 ───┘ ``` 系统声音就是： > 面试官 / 会议对方的声音。 麦克风就是： > 你自己的回答。 录完以后得到： ```text InterviewRec-2026-08-28-xxxxxx.m4a ``` 然后你想： - 直接回放； - 拖进 Whisper； - 用本地模型转录； - 丢给 ChatGPT； 都可以。 --- ### 它目前能做什么？ V0.1 的功能我刻意控制得非常克制： ```text ✅ 录制 Mac 系统声音 ✅ 录制麦克风 ✅ 系统声音 + 麦克风同时录制 ✅ 输出单个 M4A ✅ 不需要 BlackHole ✅ 不需要配置虚拟声卡 ✅ 系统声音 / 麦克风独立开关 ✅ 两路独立录音音量 ✅ 双路实时音量电平 ✅ 选择麦克风设备 ✅ AirPods / USB 麦克风等输入设备 ✅ 自定义保存目录 ✅ 录完直接播放 ✅ Finder 中定位录音文件 ✅ 设置自动保存 ✅ 完全本地运行 ✅ 免费 ✅ MIT 开源 ``` 项目当前代码就是围绕“系统声音 + 麦克风 → 单个 M4A”这一目标设计的，没有加入 AI、云端或账号系统。 --- ### 不需要虚拟声卡 这是我自己最在意的一点。 InterviewRec 直接使用 macOS 的： **ScreenCaptureKit** 来获取系统声音和麦克风。 当前实现中： ```text ScreenCaptureKit │ ┌─────────────┴─────────────┐ ↓ ↓ System Audio Microphone │ │ └─────────────┬─────────────┘ ↓ PCM Normalize ↓ 48 kHz Float32 ↓ ┌───────────┴──────────┐ ↓ ↓ System Gain Mic Gain │ │ └───────────┬──────────┘ ↓ Mixer ↓ Limiter ↓ AAC ↓ M4A ``` 系统声音和麦克风通过同一个 ScreenCaptureKit Session 获取，最终进入统一的音频处理链路。 所以使用的时候不用： ```text BlackHole Soundflower Loopback VB-Cable ``` 也不会为了录音去修改你的系统默认输出设备。 代码中也使用了 `excludesCurrentProcessAudio`，避免把 InterviewRec 自己产生的声音再次抓进录音链路。 对普通用户来说，最终感知应该只有： ```text 安装 ↓ 授权 ↓ 选择麦克风 ↓ 开始录音 ``` --- ### 真正的原生 macOS App 我没有使用： ```text Electron WebView Tauri Flutter ``` 整个项目技术栈非常简单： ```text Swift 6 + SwiftUI + ScreenCaptureKit + AVFoundation ``` 目前平台范围也砍得很直接： ```text macOS 15 Sequoia+ Apple Silicon Only ``` 支持： ```text M1 M2 M3 M4 M5 ``` 不考虑 Intel。 不考虑 Rosetta。 因为这是一个我自己真正要用的小工具： > **与其为了兼容所有机器把第一版做复杂，不如先把自己的核心场景做好。** UI也十分简洁：  ## Vibe Coding 这个项目还有一个很有意思的地方：它基本是靠 Vibe Coding 做出来的 InterviewRec 本身其实也是我的一次实验： > **现在的大模型，到底能不能从 0 做出一个真正能使用的 macOS 原生工具？** 但我没有采用： ```text “帮我写一个录音软件” ``` 然后坐等 AI 吐完整项目的方式。而是真正按照软件开发流程来做的。 ### 第一步：先做需求，而不是先写代码 我先把 V0.1 需求收缩成一句话： > **系统声音 + 麦克风 → 单个 M4A。** 然后把边界冻结： ```text macOS 15+ Apple Silicon 只录音 不录屏 不联网 不做 AI 不做后端 ``` 这一步看起来没有写一行代码。 但后来回头看： > **它可能是整个项目最重要的一步。** 因为 Vibe Coding 特别容易出现： > “既然 AI 写代码不要钱，那不如全加上。” 结果 Scope 直接爆炸。 --- ### 第二步：先写 Design，再让 Agent 开始干活 项目现在不是只有源码。 还专门保留了： ```text docs/ ├── DESIGN.md ├── PLAN.md └── TESTING.md ``` `DESIGN.md` 回答： > **这个软件怎么实现？** `PLAN.md` 回答： > **Agent 应该按照什么顺序实现？** `TESTING.md` 回答： > **你怎么证明这个东西真的能用？** 这和： ```text Prompt ↓ 疯狂生成代码 ↓ 能编译 ↓ 宣布完成 ``` 完全是两回事。 --- ### 第三步：把系统拆成 Agent 能理解的小模块 现在项目里的音频核心大概是： ```text AudioFrame PCMBufferReader PCMConverter GainProcessor AudioMixer AudioLimiter AudioLevelMeter RecordingWriter ScreenCaptureAudioService RecordingEngine ``` 而不是： ```text RecordingManager.swift 3000 行 ``` 😂 例如： `GainProcessor` 就只负责： > 数字增益。 `AudioMixer` 就只负责： > 合并音频。 `AudioLevelMeter` 就只负责： > 音量计算。 `RecordingWriter` 就只负责： > PCM → AAC/M4A。 我现在越来越觉得： > **好的架构不仅方便人维护，也非常方便 Coding Agent 工作。** 你告诉 Codex： > “修 AudioMixer。” 它只需要理解一个明确的小模块。 而不是每次把整个项目重新读一遍。 --- ### 第四步：不要相信 AI 说“已经完成” 这可能是这次 Vibe Coding 给我最大的体会。 Coding Agent 特别喜欢说： > “Implementation complete.” 但软件工程真正重要的是：测试。 所以我给核心音频 Pipeline 做了自动化测试。 目前覆盖了： ```text GainProcessor AudioMixer AudioLimiter AudioLevelMeter PCMConverter RecordingWriter RecordingState Settings FileNaming ``` 比如 Mixer 测试会真正验证： ```text System Audio + Microphone ↓ 混音结果 ``` 还做了： ```text Synthetic System Tone + Synthetic Mic Tone ↓ Mixer ↓ AAC / M4A ↓ 重新读取生成文件 ↓ 检查两种声音是否都还存在 ``` 以及不同麦克风输入格式的转换测试。 --- ### MVP思维 这个项目目前仍然是： > **V0.1。** 我现在尤其关注： ```text 30～120 分钟真实长录 不同采样率设备的长期同步 Writer Backpressure 异常中断 麦克风热插拔 Crash Recovery 分段保存 ``` 这些属于下一阶段要继续重点验证和改进的内容。 当前仓库里也明确把： > 完整崩溃恢复 / segment recording 留到了 V0.2。 我觉得开源项目没必要一上来就吹： > “完美、稳定、工业级。” 反而应该告诉大家： > **哪里已经做了，哪里还在继续验证。** Issue 和 PR 本来就是开源的一部分。 --- ### 隐私方面 InterviewRec 当前： ```text 不联网 不上传 无账号 无服务器 无埋点 无广告 ``` 所有录音文件只保存在： > **你自己选择的本地目录。** 默认： ```text ~/Music/InterviewRec/ ``` 毕竟： > **技术面试录音本身就是非常敏感的数据。** 如果一个纯录音工具还要求我： ```text 登录 上传 同步 注册账号 ``` 那反而不是我想要的东西。 --- ### 对 Vibe Coding 的理解 以前大家讲 Vibe Coding： > “一句话生成一个网站。” 但真正把 InterviewRec 做下来以后，我越来越觉得，一个更靠谱的流程应该是： ```text Idea ↓ Requirements ↓ Design ↓ Implementation Plan ↓ Coding ↓ Tests ↓ Manual Verification ↓ 迭代 ``` AI 并不是： > **让软件工程消失。** 而是：让软件工程的每一步都变快。 需求可以和 AI 一起讨论。 架构可以让 AI Review。 实施计划可以让 Agent 拆。 代码可以交给 Codex。 测试可以交给 Agent 补。 Bug 可以让 Agent Debug。 文档可以自动维护。 但最终： > **方向、取舍和验收，还是得由人负责。** 至少这是我做 InterviewRec 最大的感受。 --- ## 我自己最终准备怎么使用它？ 其实 InterviewRec 只是整个工作流的第一步。 真正让我觉得它有价值的是： ```text 腾讯会议 / Zoom / 飞书 ↓ InterviewRec ↓ interview.m4a ↓ Whisper ↓ interview.md ↓ ChatGPT ``` 然后把逐字稿交给 AI： ```text 请根据这份技术面试逐字稿： 1. 按时间顺序整理面试官所有问题 2. 还原我的回答 3. 对每个回答进行评价 4. 找出错误、遗漏和表达问题 5. 给出更好的面试标准答案 6. 总结这场面试暴露出的知识薄弱点 7. 给出下一轮复习优先级 ``` ## 最后，代码开源 项目地址：⭐ InterviewRec **GitHub：**[https://github.com/sz-xiaohuolong/InterviewRec](https://github.com/sz-xiaohuolong/InterviewRec) 目前： ```text 📌 macOS 15 Sequoia+ 📌 Apple Silicon 📌 Swift 6 + SwiftUI 📌 ScreenCaptureKit 📌 AVFoundation 📌 MIT License 📌 免费 📌 完全开源 📌 完全本地 📌 无会员 📌 无服务器 📌 无广告 ``` 如果你也是： - 准备秋招 / 春招； - 找实习； - 准备跳槽； - 经常参加线上技术面； - 需要录线上会议； - 想用 AI 复盘自己的表达； 欢迎拿去用。 --- 如果这个小工具刚好解决了你的问题 欢迎： > **点一个 Star ⭐** 也欢迎： ```text Issue PR Bug Report Feature Suggestion ``` 尤其欢迎帮我测试： - AirPods - USB 麦克风 - 腾讯会议 - Zoom - 飞书 - Teams - 不同型号 Apple Silicon Mac - 长时间录音 一个开源小工具最有价值的地方，就是：**一个人的需求，最后可能刚好解决了一群人的问题。**

DeepSeek Harness 桌面端

这两天一直在将 DeepSeek Harness web 端通过 vibe coding 改造成桌面端，Token消耗起飞，但是最终还是弄出来了，也是完全开源：https://github.com/Meditationacm/dsh-desktop.git 细节部分肯定是没打磨好的，继续完善  

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 都这样，没办法。我的态度是：练手的项目，学到东西就算回本；真想赚钱，立项前就想清楚谁来买单、凭什么买单。别一边写代码一边幻想"做完了就有人用了"——大多数时候不会。 ## 我开发的 vibe coding skill 我将上述我的 vibe coding 的工作流和方法开源了一个项目的 vibe 规范 skill（ https://github.com/dnwwdwd/project-vibe-spec ），这样大家就可以直接使用了，无需手动维护文档。希望大家多给我的 skill 点点 star：https://github.com/dnwwdwd/project-vibe-spec --- ## 个人博客 我的博客：<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 编程模式~