Appearance
2026 周报：从工程基础到 Agent 项目实践
第 30 周｜差异化镜头规划落地，套图开始承担不同营销用途
本周主线
延续第 29 周观察到的成片问题，这一周把差异化镜头规划真正落地——把每张图当成不同营销角色来出，让套图承担起不同营销用途。同步在真实容器链路里跑通完整链路，并修了一个空队列阻塞问题。
本周推进
- 真实容器联调：用 Docker Compose 拉起 PostgreSQL、Redis、API 和 Worker，health 和 ready 探针通过，任务能从 API 入库、由 Redis Worker 消费。
- 修一个空队列阻塞问题：发现 Redis 空队列阻塞读取和客户端超时冲突，Worker 因为读超时直接退出；补上断线重连后，Worker 在空队列和连接波动下能继续工作。
- 真出 4 张图：用方舟 Seedream 一次生成 4 张商品推广图——小红书主视觉、淘宝卖点、小红书场景和淘宝活动图，27 秒进入 completed，整条 API → 队列 → Worker → 模型 → 回写链路验通。
- 从 Prompt 出图到工作流编排：把生成从"Prompt 直接出图"转向工作流编排——引入商品理解、营销策划作为分析节点，再按主视觉、卖点特写、使用场景、活动营销图等不同镜头角色分配给成片，按平台规划比例和画面留白。用服装、戒指、箱包等多组商品测试，对比调整前后的套图差异，确认每张图开始承担起不同营销用途。
- 业务边界：这一轮没接 GVA；picture-agent 专用 GVA、七牛上传和 App 完整链路还要单独验收。
本周总结
这周让 Picture Agent 从"能跑"走到"每张图有差异"。把每张图当成不同镜头岗位来跑，让套图真正承担起不同营销用途，从"一次出多张"变成"一次出有差异的多张"。后续重点是稳定出片和按平台适配。身体上的变化也开始有量化结果。
当前状态和后面安排
Picture Agent 已完成 PostgreSQL、Redis、API、Worker 和真实方舟模型的本地联调，差异化镜头规划也已落地并通过对比验证。当前还不能宣称生产上线：picture-agent 专用 GVA、七牛上传、App 完整链路和 Worker 崩溃恢复演练都还要单独验证。身体继续按节奏训练，为 11 月的重要活动准备。
第 29 周｜Picture Agent 从功能验证走向可交接的任务系统
本周主线
继续做一喵修图的 Picture Agent。这周把重心从接新模型转向把任务系统做得更可靠——让任务能被领取、不重复处理、Worker 崩溃后能恢复，并且让下一位维护者能继续接手。同时跑通后用不同商品看早期成片，发现几张图差异不大，更像裁剪换比例，没有真正承担起不同营销用途，这是下一阶段要解决的方向。
本周推进
- 任务存储：抽象成 Repository，能在 SQLite 和 PostgreSQL 之间切换。
- 任务执行：Worker 用
claim + lease领取任务，处理期间续租，过期任务可以恢复。 - 重复保护：通过数据库原子条件防止重复消费和多实例并发，旧 Worker 也不能覆盖新结果。
- 本地验收：用 Mock 跑通 health、ready、自动生成、查询、确认和幂等请求；测试从 9 项扩展到 16 项。
- 交接文档：整理配置、验证结果和下一阶段安排。
- 成片观察：跑通后用不同商品测试，看到成片在光影、构图细节上有一定变化，但整体差异还没有落到不同营销用途上，更像裁剪和轻微换背景。
本周总结
这一周最大的变化有两件事：任务系统开始处理可靠性（任务如何领取、如何避免重复处理、Worker 崩溃后如何恢复），以及看到成片在"营销用途"维度上还不到位。这两个方向会在下一阶段同时往前推。
当前状态和后面安排
代码已经达到可交接阶段，但还没推到远程仓库，也不是生产验收完成。上线前还需要接入真实 PostgreSQL、Redis、GVA 和七牛链路，并做一次 Worker 崩溃恢复演练，同时解决套图差异化问题。
第 28 周｜启动 picture-agent 并跑通 Seedream 5.0 真实生图
本周主线
9 月 9 日开始独立开发一喵修图相关的 picture-agent，9 月 11 日跑通豆包 Seedream 5.0 单张真实生图和本地 9 项测试；9 月 12 日继续准备真实商品图验收，完整 4—6 张链路仍待验证。同期继续少量投递和健身。
本周推进
- 启动 picture-agent：搭起 FastAPI 服务骨架，跑通自动生成和确认方案后再生成两种协议；先支持小红书、抖音、淘宝、微信四个平台和 4—6 张套图规划。
- 形成代码级生图链路：完成商品图上传、七牛转存、豆包 Seedream 5.0 适配和结果回写的接口与测试，本地 9 项测试通过，官方模型单张真实生图成功；尚未用真实商品文件完整跑通 4—6 张套图及正式 App 链路，下一步是后台任务、数据持久化和失败重试。
本周总结
这一周完成了 picture-agent 的接口和模型调用验证；下一步把“已有项目讲清楚”作为重心，把简历、面试表达和项目源码一起往前推。
当前状态和后面安排
接下来补 picture-agent 的真实商品图端到端验收、后台任务、数据持久化和失败重试；同时按请求入口、上下文构造、模型调用、流式返回、状态与记忆的顺序继续复盘 Lunetale，再用 VibeLab 把异步任务、数据库、缓存、对象存储、Sandbox 和错误处理重新吃一遍。
第 27 周｜完成求职试水，转向项目内化与沉淀期
本周主线
新学期开始，把新版简历拿出去试投了一轮，也拿到了大厂实习内推。这周没有继续给项目堆新功能，而是从集中交付转向项目内化、后端基本功和求职表达。
本周推进
- 完成简历试水：获得部分招聘方索要简历、继续沟通和实习内推入口，但目前没有形成合适的面试邀请。当前的客观限制更多是年级和到岗时间，Lunetale 和 VibeLab 的项目方向已经得到一定反馈。
- 收拢技术主线：Lunetale 继续承载对话 Agent、Prompt、流式返回、gRPC 和长期记忆；VibeLab 承载异步任务、PostgreSQL、Redis、对象存储、安全检测和 Sandbox。下一阶段不轻易新增第三个同类项目。
- 重新安排三个月节奏：9 月到 10 月优先吃透两个项目并补后端基础，保留少量高匹配投递；10 月底到 11 月再根据寒假实习开放情况提高投递强度。
本周总结
这轮试水至少证明了，现在的简历已经能够得到一些大厂和招聘方的反馈。后面的问题也变得更具体了：能不能把真实调用链、数据结构、故障排查和设计取舍讲清楚，能不能在不依赖 AI 直接给答案的情况下读懂、修改和验证代码。比继续扩大项目范围更重要的，还是把已经做过的事情真正变成自己的工程能力。
当前状态和后面安排
接下来按真实项目链路一点一点补基础，每周至少留下一项具体产出：一张调用链图、一篇源码笔记、一个可复现实验，或者一次项目口述。同时正常上课、健身和休息，不再每天都把强度拉满。
第 26 周｜VibeLab Agent 微服务安全检测与打包接口接入远程 Sandbox
本周主线
VibeLab 是"一句话生成可发布作品（游戏、网站、工具）"的 AI 平台，本周在 Agent 微服务侧接入安全检测与软件打包两条 HTTP 接口，并使用本地 fixture 驱动真实远程 Sandbox 跑通安全检测业务主链路。
本周推进
链路是 GVA 调 Agent HTTP 接口 → Agent 调 Sandbox → 回给 GVA。Agent 只负责契约、编排和结果汇总；用户代码只在 Sandbox 里跑，主进程不允许直接执行 npm install 或 build。
两条接口（安全检测和软件打包）的契约、状态机和错误规范已准备好，curl 联调示例写入 README，GVA 端实际调用待后续发起。
真正卡住的是远程 Sandbox 的接入。本地开发环境通过组网访问远程 CubeSandbox，排查顺序是确认网络状态、补齐访问权限、确认远程服务正常运行。创建和销毁 Sandbox 都成功后，上传文件仍然报错；最后定位到原调用方式依赖本地无法访问的内部地址，改用更适合当前网络环境的调用方式后，上传和执行恢复正常。
之后用本地临时压缩包替代对象存储下载，跑了一遍真实业务代码（解压、源码检查、依赖检查、Sandbox 构建、运行检查、产物检查）；修复了本地配置未更新和 Sandbox 执行命令未进入源码目录两个问题，整条流程最终完整通过，远程环境日志能看到创建和销毁记录。
本周总结
这周把"调用远程沙箱"从抽象变成了具体。Sandbox 是部署在服务器上的基础设施，本地只写调用适配层；难点是把已有工具按顺序组装起来。先接口契约、再 mock、再真实 Sandbox、最后真实业务代码——这条工程顺序本周完整走了一遍。
当前状态和后面安排
真实 Sandbox 已接入。下一步接入真实对象存储下载，把 Sandbox 完整日志整理进 API 返回；同时软件打包接口推进真实 build 链路。
九月，正式开启新阶段。
第 25 周｜从 Lunetale 收尾转向 Coding Agent 新项目
本周主线
教培和 Lunetale 第二版在本周收尾，工作主线开始转向 VibeHub/VibeLab 第三版。新项目要支持用户上传小游戏、小工具或前端项目，先做安全检查，再构建成可以预览或发布的产物。
本周推进
- Lunetale 收尾：确认第二版暂时停止扩展；排查出一次请求包含两次模型调用，Token 统计和响应延迟需要分开处理，项目后续作为复盘和面试素材。
- 第三版预热：读了作品分发平台和安全检查/沙箱设计，初步理清上传、扫描、构建、运行、发布的链路。
- 职责边界：GVA 负责 HTTP、权限、对象存储和任务记录；Agent 负责 gRPC 契约、任务编排、扫描和打包结果；Sandbox Worker 负责隔离执行用户代码。
- 协作方式：先对齐 proto、状态和错误码，由 Agent 提供 mock，GVA 并行接入；之后再实现真实扫描和 Docker 沙箱。第一期只做 Static HTML/简单 Frontend ZIP。
本周总结
这周的主要突破，是从“把 Agent 调用链跑通”转向理解一条完整的 Coding Agent 工程链路：代码不仅要生成，还要经过检查、构建、运行和验证。Lunetale 第二版暂时收住后，我也更明确了下一阶段的重点：把真实项目问题沉淀成自己的工程经验，同时逐步补齐 Docker、gRPC 和沙箱执行基础。
当前状态和后面安排
第三版还处于理解和接口准备阶段，生产级沙箱尚未完成。接下来先恢复作息，阅读 OpenGame 源码，和 GVA 确认 gRPC 契约，再搭出 Agent 与 Sandbox Worker 的最小框架。
- 读懂项目入口、文件修改和运行方式。
- 确认安全检测、打包接口的字段、状态和错误码。
- 提供 mock，随后完成本地 Docker 沙箱闭环。
- 整理 Lunetale 的真实问题，准备后续简历和投递素材。
第 24 周｜Agent 交付前收尾，个人规划进入下一阶段
本周主线
这周继续收 Lunetale 的预览对话和长期记忆。主链路已经跑通，重点转向身份边界、多角色选人、上下文大小、流式协议和记忆写入这些真实问题。
本周推进
- 对话链路：重新区分剧本、场景、角色和玩家身份，修正流式字段不同步的问题。
- 多角色对话：从候选角色依次回复改为按场景动态选人，减少重复回复和无关调用。
- 上下文与记忆：去掉完整剧本注入，限制运行时字段和记忆写入长度，解决上下文过大与提交失败。
- 阶段收尾：项目暂无新的明确需求，开始把注意力转回 Python、算法、后端基础和项目复盘。
本周总结
这周把预览对话从“链路接通”推进到了“能实际运行”：明确了角色和玩家边界，减少了无关角色调用，也处理了上下文过大和记忆写入失败的问题。更重要的是，我开始把问题放回完整链路里看，而不是只盯着某一个接口或模型调用。
当前状态和后面安排
预览对话主链路已经从“接通”进入“可实际运行”，但选角、流式状态和长期记忆还需要真实环境继续验证。接下来不主动扩大项目范围，先恢复节奏，再整理可用于面试的真实问题。
- 有新的联调或线上问题时再跟进。
- 碎片时间保持算法题，整块时间回看项目源码。
- 按 Python、后端链路、项目复盘、简历与投递的顺序推进。
第 23 周｜接入 MemU，重新验证长期记忆
本周主线
围绕 Lunetale 的长期记忆接入 MemU，并重新检查记忆从写入、检索到回答使用的完整链路。
关键进展
- 跑通 MemU 的记忆写入、检索、更新和删除链路，并修正模型接口配置问题。
- 对比 Mem0 和 MemU 的真实对话效果，确认当前测试还不能只靠关键词命中判断质量。
- 重新划分业务层、记忆层和数据库的职责，明确“记什么”不应该交给向量数据库决定。
本周总结
长期记忆的重点不是接入某个框架，而是判断什么值得保存、状态如何更新、检索结果是否被正确使用，以及历史变化能否被保留。
第 22 周｜长期记忆从摘要走向结构化
本周主线
针对长期记忆混淆、写入阻塞和状态难以更新的问题，把摘要式记忆改成结构化、可更新、可批量处理的记忆卡片。
关键进展
- 将记忆写入从主对话中拆出，改为批量、异步和增量处理，减少重复调用和响应等待。
- 区分玩家表达、故事事实和角色状态，避免不同类型的信息互相污染。
- 开始把具体项目经验抽象成 Agent 产品的通用拆解方式：任务链、状态、工具边界和评估标准。
本周总结
这周最大的收获是明确了：Agent 的稳定性不只取决于模型，也取决于状态、记忆、工具、工作流和异常边界是否被工程化管理。
第 21 周｜Agent 微服务进入真实业务联调
本周主线
Agent 微服务从“能够调用”进入“能够落地”。这一周重点对齐模型输出、业务字段、流式展示和内容创作工作流。
关键进展
- 跑通前端、主业务后端和 Agent 微服务之间的基本链路。
- 发现并处理结构化输出、字段映射和前端分类型展示之间的不一致。
- 开始设计内容创作 Agent 的工作流，明确节点输入输出、状态传递和异常处理。
本周总结
Agent 开发并不是脱离后端的一套独立技术。接口、数据结构、服务通信和异常处理，决定了模型能力能不能真正变成可用功能。
第 20 周｜推进前端、主后端与 Agent 微服务联调
本周主线
进入内容生成 Agent 的真实联调阶段，开始把前端、主业务后端和 Agent 微服务组合成一条真正可用的业务链路。Agent 负责模型和智能体生成，主业务后端负责业务接口与数据承接，前端负责创建、预览和结果展示。
关键进展
- 明确 Agent、主业务后端和前端在内容生成与预览流程中的职责。
- 发现并处理 gRPC 服务未完整挂载的问题，逐项对齐服务注册、接口、环境、鉴权和返回结构。
- 联调中发现需求字段、服务状态和前端展示没有完全同步，开始从整条调用链排查，而不是只修改某个局部接口。
- 将一条预览链路从 100 秒以上优化到约 10 秒，完成第二版阶段性收尾；前端还需要继续验证真实展示效果。
本周总结
这一周真正接触到微服务联调的复杂度：服务能启动，只能说明局部没有报错，不代表注册、鉴权、字段、状态和展示已经形成闭环。性能优化也不是单纯改一个函数，而是先沿着完整调用链定位耗时，再确认改动没有破坏业务结果。第二版到这里完成阶段性收尾，后续更重要的是把这次联调经历整理成自己能讲清楚的项目案例。
第 19 周｜期末结束，启动 Agent 微服务与后端工程主线
本周主线
期末结束后，开始把学习重新放回真实项目。新的工作主线是内容生成 Agent 微服务，同时补齐 Python、HTTP、gRPC 和服务部署等后端基础，并把前几个月的 Agent 学习整理成可以复盘和表达的项目经验。
关键进展
- 明确后续主线由 Agent 微服务、后端基础、源码阅读和项目表达组成。
- 建立源码阅读方向，优先理解长期记忆、多 Agent 协作、工作流和后端服务结构，而不是继续无边界扩展技术名词。
- 开始把前几个月的 Agent 实践重新整理成可复盘、可表达的项目经验，准备后续简历和投递。
本周总结
这一周的重点不是同时学习更多框架，而是确定一个长期节奏：用真实项目带动基础补齐，把做过的事情沉淀成自己能够解释、复现和继续改进的能力。
第 18 周｜期末收束，准备切回项目主线
本周主线
期末复习进入收尾，项目暂时降速。这个阶段没有强行维持技术进度，而是先把考试、睡眠和精力状态收住，为暑假的 Agent 项目周期做准备。
关键进展
- 完成期末阶段的主要复习任务，保留了对项目主线的最低连续性。
- 重新梳理学习、项目和生活的优先级，减少不可控消耗，让下一阶段有可以持续投入的节奏。
本周总结
阶段性降速不是放弃，而是为了让下一轮投入有稳定的精力和节奏。现在比继续堆任务更重要的，是把能长期执行的工作方式重新搭起来。
第 17 周｜期末复习与知识体系整理
本周主线
集中复习操作系统、计组和概统，同时整理博客、后端知识和项目索引。技术项目推进不多，但在把零散笔记和学习材料重新归档。
关键进展
- 完成 chat 包学习笔记和后端知识目录整理。
- 把复杂复习任务拆成可执行的小块，形成更稳定的学习方法，也减少在多个任务之间来回切换的消耗。
本周总结
真正的学习不是一次性记住所有内容，而是能耐心拆解、查资料、验证并形成自己的理解。这个方法同样适用于后面读项目源码和排查线上问题。
第 16 周｜面试反馈与 Agent 微服务业务逻辑
本周主线
面试结束后回到项目，补齐 Agent 微服务的后端业务逻辑，同时把面试暴露出的不足转成具体学习清单，而不是停留在“准备得不够好”的笼统判断上。
关键进展
- 推进 RAG 和对话上下文组织相关的服务逻辑。
- 整理项目索引和接口阅读路径，并开始进入期末复习，让项目、课程和求职准备放回同一张计划表。
本周总结
面试结果是能力边界的真实反馈。下一步需要回到代码和基础，把“不够强”拆成具体的接口、数据库、工程表达和手写能力问题。
第 15 周｜通过 Prompt 结构调整优化缓存复用
本周主线
围绕 Agent 微服务的 Prompt 结构和缓存复用做一次局部性能优化，同时准备项目路演材料。这个阶段既要继续做工程改动，也要把做过的事情转成别人能听懂的项目表达。
关键进展
- 将稳定的角色设定、行为规则与动态场景、状态、对话分开排列。
- 通过对比测试确认稳定前缀更利于缓存复用，并明确这只是局部策略优化，需要结合真实请求继续观察效果。
本周总结
Prompt 不只是内容写法，也会影响系统的性能和成本。一次局部优化不能被夸大成系统级突破，但它让我开始从请求结构和运行成本的角度理解 Agent 微服务。
第 14 周｜三天完成 MergeGuard-AI 交付
本周主线
在明确期限内完成 AI PR Review 项目的 MVP，并尝试将它从评论生成器推进成风险分析和决策工作台。三天的限制迫使我快速收敛需求、拆模块并做出能演示的结果。
关键进展
- 三天完成项目框架、RAG、影响图谱可视化和演示交付。
- 将系统拆成规则、上下文、多个分析角色和统一决策四层，让确定性规则和模型分析各自承担合适的职责。
本周总结
短周期交付让我第一次完整经历了需求收敛、模块拆分、亮点设计、演示和交付。项目虽然粗糙，但让我认识到工程能力不只是把代码写出来，还包括在有限时间里做出取舍并交付结果。
第 13 周｜从技术学习转向真实业务场景
本周主线
从单纯学习 Agent 技术转向寻找真实业务场景，先后探索 Lingra 和 MergeGuard-AI。
关键进展
- 认识到 Agent 必须嵌入具体流程，不能脱离场景堆能力。
- 确定 AI PR Review 作为更聚焦的项目方向，并明确规则与 LLM 的分工。
本周总结
业务架构需要主动收敛，先解决一个具体问题，再扩展功能，比一开始设计大系统更重要。
第 12 周｜完成 RepoMind 复盘，形成项目表达
本周主线
完成 RepoMind/RopeMind 的阶段复盘，把能运行的项目整理成可以解释、评估和迭代的 Agentic RAG 工作台案例。
关键进展
- 梳理项目流程、接口、路由、引用、追踪和评估方式。
- 开始把 Agent 从“能跑”理解为“能观察、能评估、能持续改进”。
本周总结
项目表达的重点不是罗列组件，而是说明它解决了什么问题、如何判断结果好不好。
第 11 周｜收尾 RepoMind，理解 Multi-Agent 与 Harness
本周主线
完成 RepoMind 的收尾模块，并重新思考多智能体和任务编排的工程边界。
关键进展
- 补齐 metadata 和 rewrite 等项目环节。
- 明确多 Agent 不是越多越好，任务拆分、失败重试和结果合并才是核心。
本周总结
复杂 Agent 系统的基础仍然是工程组织能力，而不是堆更多角色和框架。
第 10 周｜重构 RepoMind，跑通 Agentic RAG 思路
本周主线
对照 LangGraph 官方示例重构 RepoMind，理解检索、评估、改写和回答之间的工作流。
关键进展
- 梳理并重构项目核心文件和基础链路。
- 理解 Agent 根据检索结果决定回答、重试或改写问题的过程。
本周总结
官方文档和源码比零散的概念介绍更能建立判断，项目结构也需要在实践中不断修正。
第 9 周｜启动 RepoMind，打通第一个 Agent 项目链路
本周主线
确定 RepoMind 的用户和问题，开始做一个帮助理解 GitHub 项目的工具。
关键进展
- 从用户、流程和模块三个角度拆解项目，而不是直接堆功能。
- 打通项目分析、阅读路线和代码问答的基础设想。
本周总结
从想法到项目的第一步，是先把用户和流程想清楚，再决定技术怎么落地。
第 8 周｜明确 Agent 最小项目目标
本周主线
重新安排期末与技术学习节奏，把“学习 Agent”改成一个可执行的最小项目目标。
关键进展
- 为课程复习和 Agent 项目设置明确的时间边界。
- 确定阶段目标是能理解概念、完成基础设计、做出最小项目并复盘。
本周总结
目标必须能落到具体产出，否则学习很容易停留在名词和收藏资料上。
第 7 周｜继续 LangChain，完成计算机网络基础整理
本周主线
继续学习 LangChain，同时完成计算机网络基础笔记，维持 Agent 和后端基础的双线输入。
关键进展
- 完成一轮网络基础整理。
- 重新安排期末和 Agent 主线，避免多项任务同时失控。
本周总结
技术学习需要连续性；当阶段任务过多时，先保住主线，再恢复速度。
第 6 周｜在课程与比赛中维持技术输入
本周主线
课程和比赛任务较多，技术主线暂时降速，保持算法题和 Agent 基础输入。
关键进展
- 维持基础算法练习和必要的课程任务。
- 认识到阶段性降速需要明确边界，不能让主线彻底消失。
本周总结
不是每周都要高速推进，重要的是在现实任务中保留回到主线的能力。
第 5 周｜补 Python 后端、测试和数据库基础
本周主线
开始补 Python 后端基础，建立从请求、校验、异常、测试到数据库的完整认识。
关键进展
- 学习 Python Web、pytest、请求校验和数据库基础。
- 明确先吃稳一个完整项目链路，再继续扩展新想法。
本周总结
Agent 应用最终仍然要落在后端工程上，基础不稳时，继续堆功能只会让问题更复杂。
第 4 周｜做出 Blog-Agent 雏形，正式切入 Agent 开发
本周主线
基于个人博客做出自动整理文章的 Blog-Agent 雏形，开始把 LLM 能力放进真实工作流。
关键进展
- 规划 Prompt、Markdown、预览、状态和异常处理等基本能力。
- 开始建立 Agent 应用、后端和工程化之间的学习地图。
本周总结
做出一个小而完整的工具，比继续收集概念更能暴露真正需要补的能力。
第 3 周｜完成博客部署，建立第一个工程闭环
本周主线
把个人博客从本地开发部署到服务器，第一次完整经历构建、传输、运行和问题排查。
关键进展
- 处理服务器网络、Docker、SSH、路径和构建产物问题。
- 理解前端、后端、数据库和服务器在一个 Web 系统中的分工。
本周总结
真实部署中的路径、环境和脚本问题，让“能写代码”第一次和“能让系统运行起来”连接起来。
第 2 周｜补 Shell、Docker、Git，进入工程实践
本周主线
开始补 Shell、Docker 和 Git，并把这些工具用于服务器和博客部署。
关键进展
- 从命令记忆转向理解镜像、容器、版本和服务器状态。
- 建立看文档、查资料、验证命令的工程习惯。
本周总结
不会并不可怕，真正重要的是不盲目复制命令，愿意把系统状态和每一步原因弄清楚。
第 1 周｜恢复专业课学习，搭起学习与工程环境
本周主线
恢复专业课学习，整理计算机基础、虚拟机环境和 Obsidian 知识体系。
关键进展
- 复习计算机网络和组成原理，解决虚拟机桥接网络配置。
- 开始用 Obsidian 记录学习路线、项目过程和阶段复盘。
本周总结
这一周重新搭起了学习和工程实践的起点，也确认了身体状态、记录方式和基础环境都是长期成长的一部分。
阶段总复盘｜2026-03-01 至今
回头看，这几个月是在一点一点把线串起来。
3 月的时候，我还在补 Shell、Git、Docker、服务器部署，很多东西都不懂。那时最大的收获是第一次从实际部署里理解“一个 Web 系统是怎么跑起来的”。
4 月开始补 Python 后端、pytest、异常处理、LangChain，也慢慢确定 Agent 是主线。那时更多是在打底：后端基础、工程习惯、学习系统。
5 月开始用 RepoMind / RopeMind 做项目，理解 RAG、LangGraph、Agentic RAG，也开始知道项目要先想用户、流程、模块和系统结构，不能只堆功能。
6 月做 MergeGuard-AI，第一次进入有选题、有期限、有交付压力的项目。虽然粗糙，但它让我体验到开发的快感，也让我知道工程能力不仅是写代码，还包括需求收敛、架构拆分、演示表达和结果交付。
7 月进入真实项目节奏，开始处理 Agent 微服务、gRPC、主业务后端、前端展示、预览链路优化、版本收尾。到 7 月 27 日，链路已经从“接通”进入“内容创作 Agent、多模态生成、流式返回、数据库补齐”的攻坚阶段。这个阶段对我的倒逼很明显：不能只会 vibe coding，必须读源码、补后端、懂通信、懂数据库、懂业务链路，也要能把复杂需求拆成稳定的节点和服务层实现。
8 月在教培、Lunetale 收尾和 VibeLab 切换之间推进真实项目，接触了长期记忆、配置排障、流式协议、异步处理、远程 Sandbox 和安全检测。这个阶段让我看到，工程能力不只是把功能写出来，还包括确认边界、定位故障、验证环境和承认哪些部分尚未完成。
9 月开始从集中交付转向项目内化和生活节奏调整：Picture Agent 从接口、对象存储和 Seedream 的验证，推进到 Repository、Worker 租约、幂等和并发保护，达到可交接但尚未生产验收的阶段；求职试投获得了招聘方索要简历和内推等反馈，但尚未形成合适面试；同时保持训练、阅读和生活连接。下一阶段重点是把已有项目真正讲清楚，并在稳定节奏中补齐后端基础。
现在比较明确的路线是：
- 主线：AI 应用工程化 / Agent 开发；
- 底座：传统后端、数据库、网络、gRPC、服务部署；
- 方法：真实项目驱动 + 系统补课 + 源码阅读 + 复盘沉淀；
- 目标：从“能写功能”，走向“能理解业务、设计系统、推进交付、判断方案”。
这几个月最大的变化是：我从“努力把事情做出来”，走向“理解事情为什么这样做、哪些是自己的贡献、哪些边界还没有验证”，也开始学习不靠持续加码来证明自己。