2年经验后端开发-业务场景题总卡在权衡取舍，急需实战决策框架指导

场景：有一个tob的教育系统（单体单实例）需要开发一个ai判题接口（ai判题就是提交落库+调用ai返回），这个接口是开发成同步还是异步，已知系统并发不超过1000。求一些有工作经验的大佬解答一下，是同步还是异步，还是说都可以! 技术栈补充：java,Springboot3,开启虚拟线程,jdk21

想问一下python项目学哪一个写到简历比较好

目标想找agent开发。已经有个一个纯java后端项目，和一个deepresearch的python项目，想再学习一个python项目写到简历上，这几个python项目各倾向哪方面呢，更推荐学哪个呢？感谢解答

Agent 开发项目选择

鱼皮你好，想向你请教两个关于求职的问题。 先简单介绍一下我的情况： 我目前大三，普通民办二本，数据科学与大数据技术专业，计划在 **2027 年暑期找一份 AI Agent 开发方向的实习**。如果学习进度比较快，也想在今年寒假前尝试投递，不过主要目标还是明年暑期。 之前一直按照 Java 后端开发的路线学习，接触过 Spring Boot、MySQL、Redis、Docker 等技术，也学习过编程导航的一些项目，包括用户管理、伙伴匹配、云图库和 AI 超级智能体。 不过，自从接触 Codex 这类 AI 编程 Agent 后，对工具的依赖越来越多，自己的独立编码和调试能力有比较大的退化，这也是接下来想重点补齐的部分。 最近确定想转向 Agent 开发方向，所以打算重新调整学习路线，尤其是项目经历，希望能更贴近实际的岗位招聘需求。 目前主要有两个问题想请教一下： **1. 关于项目选择** 如果目标是 Agent 开发实习岗位，你更推荐学习编程导航中的哪些项目？ 我希望重点做 2 个有一定深度、能够写进简历的项目，而不是单纯追求项目数量。 另外，因为转向 Agent 开发，我也打算将主要开发语言从 Java 转向 Python。编程导航中的项目大多使用 Java，如果我用 Python 重新实现，是否同样适合作为求职项目？或者说，你更建议继续使用 Java？ **2. 关于实习经历** 今年暑假有过一段实习经历，不过不是在公司的 IT 部门，而是在一家留学教育公司的用户运营部门。 主要负责通过 AI 提升视频内容团队的工作效率，最终独立完成并交付了一个公司内部使用的 AI 工作台。 这个工作台整合了素材参考、脚本创作、视频转写、发布包装和运营复盘等功能，支持结合企业知识库和提示词节点辅助内容生产，生成结果可以人工审核、编辑和保存。 技术上主要使用了 React + TypeScript + Node.js，涉及大模型 API 调用、RAG（SQLite + FTS5 + Embedding）、视频转写、飞书集成等，最后部署到了 Linux 服务器上。 不过需要说明的是，**整个项目基本是通过 Vibe Coding 完成的**。虽然需求梳理、功能设计、开发推进和最终交付都是我独立负责，但具体代码实现主要依赖 AI，自己的独立编码能力相对薄弱。 所以想请教一下： 这类偏 AI 应用落地、但主要通过 Vibe Coding 完成的实习经历，对于 Agent 开发岗位是否有价值？ 如果有价值，应该如何在简历和面试中更好地呈现或者说包装这段经历？以及我接下来需要重点补齐哪些能力，才能真正支撑这段项目经历？ 感谢鱼皮抽时间阅读，期待你的建议！

完成AI 万能视频下载总结器项目！---总耗时30h,第一次用ai完成项目，使用Qoder+Qwen3.8-Max实现。已部署上线（没有完全上线好，买错服务器了🤣，不能备案，所以支付功能用不了，等有钱再买个新的服务器）也上传了github，话说这个千问只能看到Credits 消耗都不知道到底用了多少token

又一个新项目完结，全栈 AI 修图 Agent！

大家好，我是程序员鱼皮。 又经过了一段时间的爆肝，我在编程导航的保姆级新项目教程 [《AI 修图智能体》](https://www.codefather.cn/course/2099386518517915649)，完结啦！ 这是一套以 **AI Agent 驱动的图片编辑** 为核心的全栈项目教程，基于 Python 3.13 + FastAPI + LangChain + LangGraph + React 19 + Konva。你只需要输入一句话，AI 就能自动规划修图步骤、调用 21 种编辑工具帮你完成专业级修图，从文生图到抠图调色、区域编辑、图层拆分，全部自动搞定。  每一期文字教程都详细讲解了设计决策和实现细节，让你不只会做，还知道为什么这么做。  这还不够，每个项目我都写了详细的简历写法和面试题解，做完项目直接写到简历上、突击面试，一条龙服务！  真心换真心，我做项目教程的付出也得到了大家的认可，也帮很多同学拿到了大厂 offer~  接下来鱼皮给大家快速介绍这个项目，希望让更多需要它的同学看到，把它变成自己的项目。 秋招正处于黄金时段，简历上写满前沿技术，不仅求职有底气，做项目的能力也会大幅提升！ ## 项目介绍 项目有 8 大核心能力。 1）AI 文生图，输入提示词就能出图 在创作页输入一段提示词，AI 自动生成四张候选图，以四宫格的形式展示给你挑选。整个生成过程通过 SSE 实时推送进度，不用傻等，随时知道跑到哪一步了。选中满意的图片后，直接进入编辑器开始修图。  2）专业级画布编辑器 基于 react-konva 搭建了一个真正能用的图片编辑器，支持画布缩放平移、图层文档管理、撤销重做，还有前后对比滑杆，一拖就能看到修图前后的效果。这不是玩具级 demo，而是对标专业修图软件的交互体验。  3）自然语言驱动修图 这是整个项目最酷的能力。你在对话框里输入一句话，比如“把背景换成海滩”、“提高亮度和饱和度”，AI Agent 会自动分析你的需求，规划出修图步骤，然后一步步调用工具帮你执行。不需要你去找按钮、调参数，说一句话就搞定。  4）21 种编辑工具，覆盖主流修图场景 项目内置了丰富的编辑工具：rembg 一键抠图、11 参调色（亮度/对比度/饱和度/色温等）、裁剪/翻转/缩放/旋转/移动等画布变换、AI 换背景、AI 扩图、超分辨率放大。手动点击工具栏可以用，Agent 也能自动调用，UI 和 Agent 共享同一套工具注册表。  5）智能区域选择 集成了 SAM（Segment Anything Model）点选能力，鼠标点一下就能精准选中画面中的任意物体。还支持笔刷涂抹模式，自由绘制选区。首次点击计算 embedding，后续点击只跑 decoder，响应速度是毫秒级的。  6）局部精细编辑 有了选区之后，可以做局部消除和局部替换。局部消除会用 AI inpainting 把选区内的东西抹掉，自动填补背景；局部替换可以用一句提示词描述你想换成什么，只改选区内容，其他地方纹丝不动。  7）图层拆分和独立操作 一键把图片按语义拆成主体层和背景层，还可以选择拆出 OCR 文字层。拆完之后每个图层可以独立缩放、调色、移动，互不影响。还支持点选画面中的任意物体，把它提升为独立图层，背景自动修复。图层数据用 JSONB 持久化，切换图片再切回来，图层结构不会丢。  8）多步计划和人机协作 当修图需求比较复杂时，AI 会输出一份包含多个步骤的结构化 JSON 计划，每一步标注了依赖关系。服务端会做工具存在性校验、参数合法性检查、依赖补全和环检测，然后按拓扑排序确定执行顺序。用户可以在计划卡片上确认执行、单步重试或取消后续，真正做到人机协作，AI 干活你把关。  当你学会这个项目后，你不仅能开发 AI 修图应用，更能把这套 Agent + 工具注册 + 异步执行的架构套用到任何需要 AI 驱动的业务场景中，比如 AI 设计工具、AI 视频编辑、AI 数据处理等等。 学前沿技术、涨开发经验，全栈 AI Agent 实战开发，绝对让你收获满满！ 而且为了让更多同学参与学习，我直接把所有代码 **完整开源** ！能力强的同学可以自学，点个 star 就算对鱼皮的支持啦~ > 开源仓库：[https://github.com/yuyuanweb/ai-retouch-agent](https://github.com/yuyuanweb/ai-retouch-agent) >  ## 项目收获 本项目选题新颖，紧跟 AI Agent 和 AIGC 趋势，以 **专业级 AI 修图工具** 为目标。区别于增删改查的烂大街项目，你将从零搭建一个集画布编辑器、AI Agent、异步任务、图层系统于一体的全栈应用，技术深度和广度都远超普通项目。 项目内容丰富扎实，前后端 + AI Agent 全链路覆盖，帮你成为 AI 时代企业的香饽饽，给你的简历和求职大幅增加竞争力！ Python 全栈 + LangChain / LangGraph Agent + 专业画布编辑器 + 异步任务 + 图层系统，技术丰富，玩透 AI Agent 全栈项目开发~  鱼皮给大家讲的是 **通用的 AI Agent 开发方法和真实工具产品从 0 到部署的全流程**，从这个项目中你可以学到： + 如何基于 FastAPI + SQLAlchemy 搭建 Python 全栈项目，实现 JWT Cookie 认证？ + 如何设计 Provider 抽象层，一行配置切换 Mock 和真实 AI 模型？ + 如何用 ARQ 异步队列 + Redis Pub/Sub + SSE 实现实时进度推送？ + 如何用 react-konva 搭建专业级图片编辑器，支持图层文档和视口变换？ + 如何用 LangChain 接入规划模型，再用 LangGraph 构建 AI Agent，让大模型规划修图步骤？ + 如何设计统一的工具注册表，一处定义同时服务 UI 和 Agent？ + 如何用 SAM 模型实现智能点选，一键选中任意物体？ + 如何做图层拆分，把一张图拆成主体、背景和文字三个独立图层？ + 如何实现多步计划的服务端校验、拓扑排序和人机协作？ + 如何用 Docker 多阶段构建和 compose profile 实现一条命令部署？ 此外，还能学会很多架构设计、方案取舍、问题排查的方法，提升独立解决复杂问题的能力。鱼皮还给大家提供了大量的项目扩展点，有能力的同学可以进一步拉开和别人的区分度，无限进步！ 满满的项目正反馈：  除视频教程外，鱼皮编程导航的项目还提供： | 教程资料 | 求职助力 | | --- | --- | | 详细的文字教程 / 直播笔记 | ⭐️ 现成的简历写法，直接写满简历 | | 完整的项目源码 | ⭐️ 项目相关面试题解和真实面经 | | 1 对 1 答疑解惑 + 专属交流群 | ⭐️ 项目扩展思路，拉开区分度 | | 前端 + Java 后端万用项目模板 | ⭐️ 从学项目到拿 Offer 一条龙 |  ## 更多介绍 该项目功能完整，涵盖文生图、画布编辑器、AI Agent 对话、编辑工具、区域选择、局部编辑、图层系统、多步计划、营销图、批量处理 10 大模块，覆盖了一个真实 AI 修图产品的核心业务场景。  本项目采用前后端分离 + 异步 Worker 架构。前端是 React 19 + Konva 的单页应用，后端是 Python FastAPI 服务，通过 REST API 和 SSE 通信。 后端内部按照路由层、业务服务层、数据访问层分层，AI 生图、抠图、扩图等耗时任务通过 ARQ 异步队列提交到独立 Worker 执行，结果通过 Redis Pub/Sub + SSE 实时推送给前端。LangChain 负责接入规划模型和绑定工具签名，LangGraph 负责 Agent 的计划编排，ToolRegistry 统一管理所有编辑工具的元信息和执行逻辑。数据分别落在 PostgreSQL（业务数据）、Redis（缓存和消息）和 MinIO（图片资源）中。  项目的核心业务流程非常清晰，能够帮你理清 AI Agent 项目开发的思路，比如一次 AI 修图请求的完整链路：用户输入自然语言指令 → Agent 规划修图步骤 → 服务端校验和拓扑排序 → 用户确认计划 → 按依赖自动执行工具 → 结果推送前端 → 画布实时更新。  不得不说，做项目真的给了很多同学坚持学习的目标、也有了更多拿 Offer 的机会，大家的动力也更足了！冲冲冲！ 

🎙️面试官说的每一句话，我都想留下来：于是我用 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 - 长时间录音 一个开源小工具最有价值的地方，就是：**一个人的需求，最后可能刚好解决了一群人的问题。**

AI 答题应用平台项目后端拼接 userPrompt 问题

### Bug 描述 前端提交的答题答案只有选项字母（A/B/C/D），后端组装给 AI 的 prompt 也只传了题干和用户选的字母，没带选项具体文字，但 AI 输出的分析却和实际选项内容对应上了。请问这是 AI 靠常识脑补的，还是我哪里漏传了选项信息？ ### 用户答案截图 详细完整的报错信息和错误日志，请勿使用模糊不清、缺斤少两的截图  

🚀 项目完结，AI 闯关学习小程序项目（Python AI 全栈） 基于 GitHub Copilot + Claude Code 开发，实战 Taro 小程序框架、Python FastAPI 后端、AI 应用开发、Tavily 联网搜索 Agent、Chroma 向量库 RAG 知识库、AI 生图 + 对象存储。 并用 OpenSpec + MCP + Agent Skills 驾驭 AI，最终用容器部署后端并上线发布小程序 👉 项目教程：https://codefather.cn/course/2037104890135748610

开源我的 Vibe Coding 工作流，已有人靠它把项目做完了

## 前言 > 如果这篇文章对你有帮助，欢迎先去给仓库点个 Star：[**project-vibe-spec**](https://github.com/dnwwdwd/project-vibe-spec)，这对我是很大的鼓励，也让更多人能找到这个工具。 大家好，我是汉堡。 上一篇文章《如何从0到1 Vibe Coding 一个项目，并长期维护》里，我分享了自己踩坑之后沉淀出来的一套 Harness 体系——用文档治理、AGENTS.md、范围冻结和分阶段推进来驯服 Vibe Coding 的混乱。 文章发出去之后，有鱼友来问我：**多个 AI Agent 接力做项目，怎么让它们互相"知道"彼此做了什么？** 答案就在那篇文章里。**多 Agent 之间通信和协作，唯一的方式只有文档。** 在项目根目录维护好 Agent 的"说明书"——Codex/OpenCode 对应 `AGENTS.md`，Claude Code 对应 `CLAUDE.md`——Agent 启动时自动注入，啥也不用说就知道项目的一切。 有人照着做了，昨天来告诉我：**"牛逼，用了文章里的内容之后，AI 的产出就稳多了，现在已经把项目做完了，感谢大佬。"** 这让我很开心。所以今天这篇文章，我想介绍一个更进一步的东西——我把那套方法论直接做成了一个可以复用的 **Agent Skill**。 --- ## 为什么要做成 Skill？ 上篇文章写的是**思路和方法**，但每次新建项目，你还是得自己手写 AGENTS.md、搭 docs/ 目录结构、想文档命名规范…… 重复劳动，而且容易遗漏。 所以我把这套体系沉淀成了一个开箱即用的 GitHub 仓库： > **👉 [https://github.com/dnwwdwd/project-vibe-spec](https://github.com/dnwwdwd/project-vibe-spec)** 如果这个 Skill 对你有帮助，欢迎点个 Star，这对我是很大的鼓励。 --- ## 这个 Skill 解决什么问题？ 回顾一下 Vibe Coding 的几个典型困境： - **上下文膨胀**：代码越多，AI 越难理解全貌 - **耦合蔓延**：改一处牵一发而动全身 - **意图退化**：没有文档，几轮对话后你自己都忘了当初为什么这么设计 - **多 Agent 失忆**：换一个 Agent 工具，之前的上下文全部归零 这些问题都可以追溯到同一个原因——缺乏工程化的文档治理。 `project-vibe-spec` 提供了一套完整的项目规范模板，让你在开始写第一行代码之前，就把"地基"打好。 --- ## Skill 里有什么？ ### 1. AGENTS.md 模板 这是整个体系的核心。AGENTS.md 干的事情只有一件：**让 AI 知道你的编码哲学和项目规范，不用每次都重复交代。** 对于 Codex/OpenCode，启动时会自动将项目级别和全局的 AGENTS.md 注入当前对话上下文。你啥也不用说，Agent 就知道： - 项目的技术栈和架构 - 代码风格和命名规范 - 禁止的行为（比如不要擅自改架构、不要顺手加功能） - 文档优先级和冲突解决规则 - 完成标准（DoD） ### 2. 文档治理体系 一套完整的文档分类规范： | 文档类型 | 命名格式 | 用途 | | --- | --- | --- | | **REQ** 需求文档 | `REQ-YYYYMMDD-XX-*.md` | 新功能或大范围改造前必写 | | **PROG** 进度日志 | `PROG-YYYYMMDD.md` | 每天一日志，记录完成了什么 | | **BUG** 缺陷记录 | `BUG-YYYYMMDD-XX-*.md` | 发现 bug 立即记录 | | **BIZ** 业务决策 | `BIZ-YYYYMMDD-XX-*.md` | 业务流程或实现策略的确认 | | **DEV** 技术方案 | `DEV-YYYYMMDD-XX-*.md` | 复杂模块拆解、阶段实施方案 | 这套体系的价值： - **上下文外挂**：AI 每次对话前先读相关文档，不会丢失上下文 - **可追溯**：三个月后回来，还能知道当初为什么这么设计 - **可交接**：换一个 AI 模型或工具，读一遍文档就能接手 ### 3. 分阶段推进模板（Phase 0 → Phase N） 大项目一口气让 AI 实现 = 灾难。必须拆阶段，每个阶段有明确的 DoD（Definition of Done）： | 阶段 | 内容 | DoD | | --- | --- | --- | | **Phase 0** | 文档体系初始化 | AGENTS.md、README.md、docs/ 结构就绪 | | **Phase 1** | 后端骨架 | 服务可启动、配置可读、数据库可初始化 | | **Phase 2\~3** | 核心链路 | 端到端链路跑通 | | **Phase 4** | 业务 API | 接口字段对齐、错误响应统一 | | **Phase 5** | 前端工程化 | 拆页拆组件、接入真实 API | | **Phase 6\~7** | 收尾上线 | 链路闭环、打包部署 | 每个 Phase 结束必须达到 DoD 才能进入下一阶段。这个纪律不能破。 ### 4. 范围冻结清单 v1 要做什么、不做什么，在一开始就写死。一旦范围冻结，后续开发中 AI 想"顺手"加功能时，你就可以说：**"不在 v1 范围，先记 REQ，下个版本再说。"** --- ## 怎么用？ 直接 clone 或 fork 这个仓库，把模板文件复制到你的项目根目录，按照说明填写你的项目信息即可。 ```bash git clone https://github.com/dnwwdwd/project-vibe-spec ``` 然后把 `AGENTS.md`、`docs/` 目录结构复制到你的项目里，根据你的项目实际情况填写内容。 --- ## 真实反馈 这套方法论有人真的用了。 有读者看了上篇文章之后，把这套文档治理的思路用到了自己的项目上。几天后来反馈：**AI 的产出稳定了很多，项目已经做完了。** 我写这篇文章、做这个 Skill，就是想把这套工程化方法变成别人可以直接用的东西，不用每个人再从头踩一遍。 --- ## 最后 Vibe Coding 的问题不在 AI 的能力，在我们给 AI 的上下文质量。 一个没有文档、没有规范、没有阶段划分的项目，再强的模型也推不动。换上完整的 Harness 体系——文档治理、阶段划分、范围冻结——用中等模型也能稳定推进。 `project-vibe-spec` 就是帮你把这个"地基"快速搭起来的工具。 仓库地址：<https://github.com/dnwwdwd/project-vibe-spec> 如果觉得有用，可以点个 Star，或者在评论区聊聊你的使用体验。 --- ## 相关文章 - [如何从0到1 Vibe Coding 一个项目，并长期维护](https://blog.hejiajun.com) --- *我的博客：[https://blog.hejiajun.com](https://blog.hejiajun.com)*

耄耋专属AI Loop全自动编码器技术笔记

> 写给想了解「多AI Agent 在大LOOP时代怎么真上线」的同学 ## 一句话 **Loop Engineering 时代，别只在聊天里写代码——用多 AI Agent，跑一条自己干活的交付 Loop。** 先给这套 Loop 代码编排器定一条简单主线： **需求 Issue → 多角色 AI 协作 → 脚本验证与独立审阅 → 合并 → 固定脚本部署 → 看板盯进度。** 人定目标和验收；AI 负责中间大部分实现与自检；模型不直接登录生产。 --- ## 为什么不只「开个 Cursor 窗口」 聊天式助手擅长帮你改文件，但上线仍要人拉分支、补测、发版、盯结果。Loop 把这些环节收成固定流水线： | | 聊天式 AI 编程 | Loop | |---|---|---| | 起点 | 粘贴上下文 | Issue / 看板目标 | | 过程 | 人来回追问 | 多角色自动推进 | | 质量 | 靠自觉 | 脚本验证 + 独立审阅 | | 上线 | 手工发版 | 确定性发布脚本 | | 可见性 | 对话记录 | 看板阶段与应用入口 | 一句话：**助手帮你写；Loop 帮你把需求送到可点开的版本。** --- ## 技术骨架：三层分工 ```text 触发层 Forgejo Issue（ai-ready） / 看板「新建项目」 编排层 Worker + loopctl + Hermes 五角色 Profile 落地层 verify.sh → PR 合并 → SSH/Compose 发布 → sslip 域名跳转 ``` - **触发层**：习惯还是 Git Issue；新产品也可在看板填「仓库名 + 目标」一键建仓。 - **编排层**：分析 → 架构 → 编码 → 测试 → 审阅；审阅打回最多返工 3 轮；单阶段约 30 分钟超时。 - **落地层**：过门后由脚本部署，看板只监控和跳转，不托管业务前端。 密钥只在服务器 `secrets/`，不进仓库。 --- ## 多 Agent：故意「拆开」，不让一个模型既当运动员又当裁判 | 角色 | 做什么 | 典型产出 | |---|---|---| | 分析 | 收成可验收目标 | `spec.md` | | 架构 | 拆任务、定边界 | `plan.md` | | 编码 | 改业务代码与测试 | 仓库 diff | | 测试 | 独立补测、跑验证 | 测试报告 | | 审阅 | 只评不改，给通过/打回 | `review.json` | 执行侧用 Hermes 多 Profile，工具集刻意收窄（文件 / 终端 / 必要时代码执行），并设轮次上限，避免一轮对话无限烧 Token。 模型也可分层：编码侧重代码模型，测试用更快模型，审阅用更稳的模型——**质量门与写代码的人不是同一个「脑」**。 ## 配置落在哪 ### 编排层（仓库） `config/loop.json` 只规定： - 五角色各自用哪个 Profile 名 - 工具集（分析 / 架构 / 审阅：`file,terminal`；编码 / 测试再加 `code_execution`） - 单阶段轮次上限、YOLO、返工次数、超时 其中 `hermes.models` 可以按角色覆盖模型名；**留空则用 Profile 默认值**。 ### 执行层（服务器 Hermes） 真正的模型 ID、`base_url`、API Key 写在各 Profile 的 `config.yaml`（例如 `/root/.hermes/profiles/loop-coder/config.yaml`）。 线上现行大致是： | 角色 | 模型 | |---|---| | 分析 / 架构 / 编码 | `ark-code-latest`（火山方舟选GLM5.2） | | 测试 | `deepseek-v4-flash` | | 审阅 | `deepseek-v4-pro` |  ### 小技巧 如果想真正的分饰多角，完全可以多买几个便宜的Agent Plan分别挂不同对应角色能力的**LLM**，但这里由于成本控制的原因，最少两个**LLM**对应不同能力就可以完成基本工作了。 ### 人格层（SOUL） 仓库 `roles/*.md` 同步进各 Profile 的 `SOUL.md`，约束「只做什么、不做什么」： - **模型**负责能力 - **SOUL**负责边界 ### 调用链 ```text Issue Worker → loopctl → 对应 Profile 的 Hermes（--oneshot，瘦工具集）→ 该 Profile 配置的模型 ``` --- ## 有边界的自治（比「全自动」更重要） **会自动做：** 读仓、改码、跑校验、开/合 PR、按脚本部署。 **不会自动做：** 没目标乱开需求、跳过质量门上生产、把密钥写进 Git。 **人能介入：** 看板看卡点、一键重跑；紧急可停 Worker。 发布永远走 `release.sh` / SSH 一类确定性路径，而不是让 Agent 临时拼命令登生产。 --- ## 看板：把黑盒变成进度条 看板回答三件事： 1. 现在跑到哪（分析 / 架构 / 编码 / 测试 / 审阅 / 发布） 2. 有没有被打回、卡在哪 3. 应用在哪打开（当前交付 + 历史项目各自地址） 多项目时：**一仓一应用、独立端口、独立 `*.sslip.io` 域名**。改哪个程序，Issue 就开在哪个仓库。   --- ## 一次真实路径长什么样 1. 看板新建，或在目标仓开 Issue 并打 `ai-ready` 2. Worker 领取 → 工作区拉出 `ai/issue-N` 分支 3. 五角色流水线跑完，产物落在 `.loop/current/` 4. 质量门通过 → PR 合并 5. `deploy_once` 部署 Staging/Production，写好跳转域名 6. 打开 `{项目名}.xxx.sslip.io` 验收 试点里我们用这条链路交付过多智能体对话应用、内容创作平台等——从「一句话目标」到「浏览器能点开」，中间大部分由流水线完成。  --- ## 适合什么，不适合什么 **适合：** 中小功能、脚手架增量、内部试点、需求边界写得清的迭代。 **暂不适合：** 无人值守改核心账务、无评审的大重构、强合规唯一发布通道。 产出质量仍然取决于：需求是否写清、模板是否匹配、模型额度与提示词。 ## 目前Loop编排器自动完成的项目展示    --- ## 结语 Loop 的技术选择可以概括成三句： 1. **角色分离**，降低「自写自审」幻觉； 2. **脚本守门**，模型负责想和改，脚本负责过不过、能不能上； 3. **看板可见**，自动跑也不变成黑盒。 它不是取代工程师，而是把重复的「领任务 → 改代码 → 验证 → 发版」收成一条可观测流水线，让人把时间花在目标与验收上。