1.重构背景
因为在之前工作实际遇到的很多问题复盘/思考/源码学习都记录在了前公司的内部wiki，裸辞前忘记copy出来了，所以当时颇有兴致就码了个Blog。但是初版功能比较简单仅仅一个首页包含了文章列表/文章编辑。后来不太好用就用Notion替代了。现在是事业编面试完，时间比较充足，准备逐一把这些老家伙都借助AI重构一遍。
2.准备工作
首先这不是我的首个vibecoing项目
（第一个是健身网站bodycrave，纯纯氛围编程！踩了很多坑，后续我也会梳理展示在项目展示中）
所以我的准备工作还是比较充分的。
使用的codex gpt5.5 （CC是因为上年8月锁国区那波给账号ban了懒得整了，gpt性价比之王可以的）
1.Agent.md规范
1️⃣ 约定工作模式：按照 需求意图 → 结构搭建 → 代码实现 → 效果验证 执行；
2️⃣ 设计规范：去除千篇一律的AI味儿/在已有迭代项目内严格沿用现有设计体系与代码写法/避免烂大街样式/合适/界面贴近可商业化正式产品
3️⃣ 执行原则：开放式需求主动补齐产品方案，保持推进节奏/优先交付最小完整可用版本，保证创意完整落地/前端开发优先本地预览运行无误后再交付/一次交付尽量做到高完成度，减少反复返工
4️⃣ 输出倾向：优先提供可运行代码、交互式原型、Figma 结构化文件、设计素材，而不只是文字方案/文字说明精简/兼顾开发速度与代码质量
2.引用合适的skills/MCP server
SKILLS
- 1️⃣ impeccable ➡️ https://github.com/pbakaus/impeccable
- 2️⃣ skills ➡️ https://github.com/anthropics/skills
- 3️⃣ superpowers ➡️ https://github.com/obra/superpowers
- 4️⃣ skills ➡️ https://github.com/mattpocock/skills
2️⃣4️⃣是两个skills属于是集合 分别是正前后端的工程化/规范化的技能工具。
MCP
- 1️⃣ codegraph
codegraph很好用，github上55k是有道理的，能够形成一套本地的知识图谱，让codex能够依据索引能够更快的定位文件和整个调用链路，缩减无效的文件扫描。在优化阶段引入后，很明显的感觉效率提升。
3.需求文档
重新梳理了本次新Blog的基础功能，详尽的给出了 文章模块/项目模块 的接口列表，库表字段设计。
3.重构过程
准备结束一开始并不是让codex开始按需求干活，从前端➡️后端先沟通明确本次的开发边界。
1️⃣前端原型UI
单单只是靠提示词，很难能够明确的得到自己想要的效果，甚至与已有的界面修改也可能会不如人意。
所以先借助 /Figma 等前端skills，同时我给了一个设计网站：designprompts.dev，按照我选中的风格，给我按照提示词和参考页面制作了一套功能全面可点击界面原型。开发过程明确按照这套原型UI进行前端代码实现和迭代。
2️⃣技术栈确定
双端技术栈按我给出提示词最终敲定：
前端：Vue3/Nuxt3/Ts/Pinia/Tailwind CSS/Markdowm 渲染
后端：Spring Boot/Mybatis-Plus/sa-token/Knife4j
约束环境完全以我本机当前版本为准 Java8 / Mysql9.6.0
3️⃣后端任务拆解
后端因为有superpowers + skills 完全是可以闭环的工作流式开发。
- 1.用 /grill-with-docs和/grill-me 先把我本次重构的目标边界敲定。
- 2.用 /to-prd 和 /to-issues 把我的需求文档进行拆解，输出Doc《Blog Implementation Plan》 开发计划书。
4️⃣开发过程
整个开发过程都是靠superpowers约束：确保项目开发先匹配正确流程，再执行，减少研发误判与返工。
但是在codex中单个对话框上下文内存是有限的，项目周期长的话必须要通过 HANDOFF文件 来让新窗口快速上手。所以我在计划中更具拆解后的任务做了两件事：
-
1️⃣ 让AI严格按照真实的项目小组开发任务，按照推进顺序给我列出了阶段开发任务，并且设置了每个阶段的验收目标。同时形成流程每个阶段完组成后确认后写入。
-
2️⃣ 让AI创建 HANDOFF文件 将Blog项目的细节压缩后写入。确保能快速恢复项目记忆。
之后严格维护这两个文件内容直到项目重构结束。
5️⃣好的&坏的
好结果🍊
1.前端开发过程因为有界面原型UI的存在，开发过程十分顺利。符合预期。
2.后端的开发因为有细分拆解了任务，每个任务独立且目标明确，边界清晰，所以整个重构过程几乎没有堵点。有superpowers的明确反馈和验证机制约束，实现代码质量也很高。
问题🍆
1.实际的开发过程中任然还是会出现没有限制住的情况，比如gpt5.5在设计的时候后端 ORM层 想用jdbc，我给否了换成 Mybatis-Plus 方便我改动，但是实际AI还是使用了 JdbcTemplate。
2.在Agent.md中没有说明自己的开发习惯，比如：没有约定前后端交互标识/常用注解使用/没有注释 ，导致偏离习惯读起来很是别扭。
4.收获&思考
因为有前车之鉴这次避免了很多坑。我觉得得到一些后续可以精进和借鉴的方法：
- 1️⃣ Plan & handoff ：我觉的这个是能够提升对整个项目有明确认知，清楚阶段进度保证能够有序进行，对于大项目一定要维护好 handoff，每个窗口的发生的问题都不会一样，所以要让后续的新窗口能快速上手这个可以做好。但是更好处理这种关于 memory 的问题，应该是还有更好的方案的。持续关注！😊
- 2️⃣ skills ：关于这两个skills集合其实有很多技能工具，但是我使用还是较低的，脱离doc文档使用能力会打折，和以前记住一个函数一样，本质还是需要多练。因为我认为这些使用集合是详细的工作流，Agent智能体可能会快速的发展迭代，但是科学的工作方法、工作思想还是会持续长久的影响。
- 3️⃣ MCP ：MCP服务因为我只使用了 codegraph，理解不太深，在未来这个持续发展的大池子里肯定会有更多更好的MCP服务来适配所做的项目，持续关注。
- 4️⃣ codex使用 ： 在 codex 的使用还是使用的太单一了，每个窗口的 worktrees 其实等于是可以做到类似于git的分支的，只是我这次的重构在后程才反应过来，我的独立任务完全是可以在多分支和依赖关键handoff的文件加持下大大的推进开发进度的。
- 5️⃣ 个性化 ： 这里说是个性化，在之前了解过有很多比如 soul.md，Agent.md，但我认为本质是个人出发针对项目配置处最优的方案，避免了AI不能有针对性的执行。也正如我在发现问题中，等于是我们需要手动拉齐和AI认知，让他知道我要怎么做，这个以后我也要在开发实例清楚我想怎么开发，不要局限于功能开发。
- 5️⃣ 最后 ： 要更好的用好当前的AI，还是不能停下脚步，提升认知，个人的更高的价值就是在AI的边界内设计好规则，把握好方向，做好判断。