2026/8/5

47 天、525 次提交之后：一个高强度 Vibe Coding 项目复盘

AI 可以把每条路都铺得很快，但人必须决定哪一条才是路。

AIVibe Coding软件工程仿真

背景和初始状态

这篇文章复盘的是一个复杂系统建模与仿真评估软件（细节隐去）的最小可用版本的 vibe coding 开发过程。这个系统包含传统增删改查：用户、项目、业务数据录入，也包含了仿真计算和分析：数据传给仿真模块、运行仿真实验、输出结果、完成数据统计和分析。

从 6 月 12 日第一个基线算起，截至 2026 年 7 月 底，仓库累计了 525 次提交、136 次合并提交，分布在 40 个活跃提交日中。列这些这些数字不是为了炫耀高产，实际上，它们反映的是需求的不可避免的反复澄清和微调、系统的混乱程度随着AI一次次的交付不成比例的快速增长、和人工治理的几次关键取舍。

开始正文之前，还应该需要简要介绍项目团队背景。过去几年，我的主要工作是复杂系统仿真建模相关的数据模型、业务理解、仿真算法的设计实现，除了用专用建模软件，也用古法编程（python为主）手搓过一些基于离散事件的仿真评估算法。

之前的项目交付方式，基本上是我带仿真工程师小组，完成仿真算法模块开发；然后软件开发团队配合完成软件基础框架、定制UI的开发；最后，两组人一起完成软件对仿真算法模块的集成和接口调用：传入用户建模数据、完成计算、再回传结果。

从去年开始，我用「初代 vibe coding」的方式—— vscode copilot 里的 tab补全、agent 调试等方式，对我们这个仿真计算库也做过两轮重构，算是积累了一点 vibe coding 的心得，但是止步于这个模块和模块相关接口开发，没做过全栈，对现代前端技术栈仅有耳闻，对前后端架构的理解停留在10多年前浅学 Django、flask 时做过的玩具项目。

今年上半年，我们在其他项目里，为了快速对齐用户的业务理解，也让 AI 快速做过一些页面原型。因为是原型，数据本来都是静态模拟的，不过后来，甲方希望从页面原型上也能看到“真实的”仿真计算结果，所以也尝试过从页面原型对接到仿真计算后台，回传数据回到页面做动态展示（感谢甲方虐我千百遍）。5月开始，codex + chatgpt 5.5 逐渐成为我的 vibe coding 主力，在其他项目中逐渐替代了copilot, opencode 等一众 llm + coding agent 组合。

第一周：搞他一票

整个过程的开端有点草率、颇具「vibe」色彩。这个软件已经经历了一年多的开发周期，形成了一个基于之前的老框架实现的版本，已经走完了多个评审节点、临近验收——但是因为各种历史原因，用户体验不佳，功能也有欠缺，甲方因为业务繁忙，一直顾不上对这个项目做细致的反馈，直到deadline临近，这才重视起来。

6月初，预感上一个版本的前端会被客户喷惨，我就提前做了一个尝试，用合同要求和需求文档作为输入，用一个相近项目的页面原型作为参考（事后分析这是错误的），让AI做了一版前端原型。

效果还不错，大的功能入口和模块，一次就和需求对齐了。最末一级的业务建模、参数配置、仿真分析等具体功能页面细节比较多，经过了两天粗调，感觉也差不多实现了七八成（这里有大坑）。

6月中，项目经理去甲方开会，果然被甲方一通喷，带回来的意见是：尽快整改，下个月中完成新版本的功能和案例演示，确保月底完成验收。

我掏出了刚出炉的页面原型给她看：“老框架修改周期太长了，按甲方的时间要求恐怕来不及，要不，用这版原型改改？主要就差三点：一是页面功能和需求对齐，二是接上后台实现数据持久化，三是集成仿真。三的部分我们之前跑通过，风险不大；一和二，在需求固定的前提下，有gpt5.5的加持，好像也没什么难度，你觉得怎么样？”

这个时候，其实是华山一条路的感觉。虽然这个体量的全栈项目从来没做过，但是也不是全无基础，按之前的经验判断（和本人一贯的蜜汁自信），整体应该是可行的——确实是可行的，但是困难也是始料未及的。

端午假期，我没有放假，手上有三个 vibe coding 项目，也不差这一个，开干吧。

开始阶段总是很顺利：先把建模页面与需求严格对齐，这件事在有文档的前提下，AI 评审一轮能把大部分问题筛出来。有些具体交互，比如怎么排布一棵结构树，选择叶子节点时与表格数据筛选怎么联动等，通过简单对话也能沟通到位。

“把装备结构树放在左侧，右侧显示参数表。”

“把任务拆成三级结构。”

总之原型阶段是 vibe coding 最开心的阶段，开着codex内嵌浏览器，一边标注，一边在对话中持续修改，有一种“看你改得快还是我标得快”的氛围，也算是一种（略显廉价的）心流状态。

随后几天，从之前模块迁移过来的可视化仿真、大样本分析页面也有了原型。

但是“看起来改对了”，是一个危险错觉——之前给自己挖的坑，现在顺利掉进去了。

第二周：自己挖坑自己填

在我们这个软件中，每个建模页面，都对应业务输入数据的一部分，最后组成一个大JSON对象，传给仿真。

然而，我最开始用了另一个相近软件的原型作为“基线”，原型页面上有很多模拟数据（mock），例如产品硬件树建模页面，原型页面肯定不是空白的，而是会有一个“A产品、B1子系统、C1模块”这样的简单的示例数据。

当我修改页面时，例如我说“增加一个产品名输入框”，并不等于 AI 就会在JSON对象中创建一个 product_name 字段——很有可能，他会自作主张地复用一个已有字段，这个字段也许是之前原型中已弃用的字段比如 product_id，也有可能，他根本就没给这个前端控件分配字段。

所以，改完一轮页面，又按照产品路线图，“顺利完成”数据持久化、仿真模块集成后，问题出现了：改好数据，运行仿真，结果不变。回到建模页面检查数据，刚刚改完、提示“保存成功”的数据不见了，页面上显示的还是之前的默认数据。

再追问 AI ，他说，为了保持数据和原型页面一致、又能被仿真接口兼容，自己还搞了一套转换、拼接数据的规则。

还有一个不成功的实验，是希望在项目早期， 前端 JSON 结构和仿真逻辑都不稳定的时候，建立一个带有反思功能的“reflexive agent”， 由这个agent 自行建立对项目的理解，从而实现自主化的 agent loop。这个思路本身是值得尝试的，但是瓶颈出现在上下文的匮乏，也就是没有外界信息驱动这套反思模型持续转动。

解决思路：投入人工，建立 JSON Schema, 同时在项目数据管理模块中做了一个项目数据可视化小功能，可以对照页面上的录入数据和后台保存数据，按对象和字段一个个比对。比对之后，心又凉了半截：大量字段都是错配的。AI 误我～

这时，已经骑虎难下了，硬着头皮改吧。我很自然地进入了5小时作息周期，每天总睡眠时间在3-5小时之间摇摆，心情在「天真了吧，看你怎么收场」和「管他呢，搞完一票收工」之间横跳。

我犯了一个本不该犯的低级失误：用一个与项目不一致的原型污染了上下文。如果坚持 spec driven，从零开始写需求、产生页面原型，可以避免至少四天的工作量。

第三周：更大的麻烦

数据结构治理好了，用于测试的案例数据也准备好了，应该开始检验仿真逻辑、出分析结果了。

这次，惹麻烦的是两个 AI 行为。

第一个是 /goal 模式。

“实现 N3 阶段目标，仿真模型消费 project json ，输出 x1、x2、x3 指标”

这样的 goal 确实可以让 agent 一直跑到完成交付，只是，每跑一次 /goal，agent 可能都会选不同的路径，即使这些目标是相互依赖的，应该有大部分路径是共用的。

我在这里得到一个关键教训：

对 AI 来说，“再做一条可运行路径”通常比“删除三条旧路径并证明没有回归”容易得多。人的职责，是不断指出什么不应该存在。

第二个是 AI 的过度谨慎。在仿真链路没有彻底跑通的时候，AI 做了包括实验台账、方案冻结、哈希、可复现、可审计…一整套过早出现的防御性功能，这严重拖累了开发、测试、评审效率，每一轮迭代变得奇慢无比，从几十分钟上升到若干小时。

到这个阶段，我们有两个团队成员协作，issue和pr提交数量到了高峰，项目一度同时存在几条看似合理的路径：早期数据映射原型、独立 contract provider、旧运行账本、轻量仿真会话，以及不同位置上的数据转换逻辑。

每条路径单独看都能解释，组合起来却开始语义漂移。同一个项目数据，从不同入口运行，可能得到结构不同的仿真输入；前端能保存的字段，模型不一定认识；旧案例中的名称和临时 ID，也可能被新代码误当成稳定引用。

在项目上下文有模糊、有歧义的时候，一个问题很容易被 AI “局部修好”，但也可能带来更多问题。本周进度目标没有实现，反而，项目出现了“改了一处崩了另一处”这种典型的、濒临失控的屎山特征。

这时候，人必须重新建立掌控，项目经理与商务对接，让甲方原计划月中的验收延后到了月底，争取了一个调整心情的时间。

花了一个周末调整心情，下定决心开始铲屎吧。

这时候，项目有十几万行代码，还算一个中小型项目，功能模块和需求仍然是对齐的，实现技术也没有超出我原有的规划，只是被大量的历史负债压着，就像是一台接了大量的飞线的电脑。如果把那些杂七杂八的旁路、兜底都移除，还是能看到我们该有的一条“产品核心链路”，这就好像把一大坨飞线扒拉开，就能看到主板、CPU、显卡、电源和原有的走线、当然还有一些原本该接线但目前空着的插槽。

对于我们的项目，这条主线大概是这样：

Project JSON
  -> projectJson_exporter
  -> simulation_adapter
  -> sim_model_v1
  -> simulation_engine

我觉得有些奇怪的一点是，人是很容易理解这种“主线”思维。不管是之前在其他行业、其他项目的工作经历，还是这次的 vibe coding，不管我把这种思维叫寻找金线、坚守基线、还是回归主线，本质上差不多就是在思考“你从哪里出发、要去哪、此刻在哪、要做什么才能到达目的地”。但是对于此时此刻的一线 LLM （GPT 5.6, gemini 3.6, GLM 5.2, qwen 3.7 等）来说，这个问题还挺难。对他们来说，每条路都是一样的。

这给了我一个启发。我感觉，LLM 会更多地合理化历史行为，而非建立一个简洁、优雅的“低熵模型”，这可能就是因为，我们给 LLM 的训练语境是“项目上下文”，这与人所处的真实语境是不同的——我们的思考是在项目层级外、项目同层、也在技术细节里同时进行的，LLM 的语境限制了 LLM 的反思能力，这可能就是他们“缺乏品味”的原因。

我们按这条链路重新跑通了功能，也建立了唯一的责任边界：

原来的冗余路径、过期文档、过时字段、防御性功能，都被一个一个清理干净。

心得体会：所谓的“品味”，往往是由一系列负面约束构成的，这往往比正向的目标定义或路线描述更关键。例如：

这些话，AI往往在推理阶段也会自己叨咕一遍，但是，会说不等于会做。嘴上一套背地里一套的行径相信做过 vibe coding 的人都领教过。

另一个心得体会：目前的技术条件下， vibe coding 能否成功，大概率取决于，是否有人能给他/她的项目的核心链路、核心技术兜底的“品味”。

第四周：磕磕绊绊的加速

项目经理又去找甲方汇报进度了。这次反馈问题挺多，但是大多是页面细节修改，大方向没什么问题，又松了一口气。

本周好消息，gpt5.6发布了。

本周坏消息，token烧得超快。

卸载了若干 skill，不断提醒对齐项目上下文，但 sol 的token快速消耗和冗长的执行时间也没有明显好转。

降级也不行，sol medium 或 terra 感觉还不如之前的 5.5 high，该出错还是出错，只有继续用 sol high / xhigh。

后来知道了，这是 bug频出的一段时间，靠着官方隔三差五的重置，总算撑了过来。

这个时候，大量的issue集中在页面细节修改上。每天的日常变成了白天提issue，晚上让 AI 清空，第二天周而复始。

这正好是测试 gpt5.6 复杂任务编排能力的机会。于是，修 issue 从原来的单线程（最多2个并行工作树），变成了“批处理式并行”，又变成了“实时检测新issue、灵活调整任务编排”的动态并行模式。AI 彻底化身超级牛马，白天要跟着我们确认缺陷、写issue，晚上连续工作10多个小时，第二天报告成果。

1785989489282

左：人工单线程，中：大拆大合，右：agent自编排

效果相当满意。当 AI 掌握了完整项目上下文、issue又都明确范围、明确目标时，信赖他们的自主化全局编排是最优选择。

当然，也有在人类眼皮底下把 issue 提错的时候，代价就是1天错误画2天来修。

第五周：继续治理

这个阶段的PR明显从 feat 转向了 fix、harden、normalize、preserve 和 retire。

测试重点转向了从输入到输出的全链路结果。事实证明只要测，就会发现问题（反之只要不测就永远发现不了问题）。一次测试，把老项目的硬件树迁移到新项目后，前端测试 635 项通过，Python contract 242 项通过，SQLite 的 PRAGMA quick_check 也是 ok，但仿真实验编译不过——有一处数据引用从老协议迁移到新协议后出现不匹配，阻断了正式链路。

AI 非常容易把一次通过的局部功能测试，顺滑地总结成“问题已解决”。人必须压住宣布完工的冲动，耐心跑通全链路验证。

全链路验证过程中发现，AI 在一次次改写数据再对接仿真算法的过程中，算法实现也从最初用 skill 约定的核心逻辑漂移了不少。

最后的一个大工程，是测试案例的建模数据上升到几千条后，暴露出仿真算法效率不达标。这个工作用“计划/执行”模式，识别了效率瓶颈，顺便优化了算法模块结构，比较顺利地完成了。

第六周：收尾、复盘

去甲方出差，演示功能，用这个最小可用版本完成评审。

回顾整个过程，真正可复用的不是几句提示词，而是一套持续维护的项目环境：

如果重来一遍，有些事仍然无法避免，也有些事有优化的余地。

第一，把完成状态做成显式状态机。草稿、结构完整、可编译、已运行、结果有效，必须从产品界面到 API 都能区分，也就是尽量让人和 AI 能同步看到问题。

第二，更早固化唯一权威链路，避免设计上的摇摆。

第三，真实案例测试尽量提前（这和第二点一样，如果项目有探索性质，实际很难实现）。

第四，为“删除”设里程碑。每增加一条新链路，都要回答哪条旧链路会退出；否则 AI 会非常高效地替你维护所有历史偶然性。

去年，我对于 vibe coding 剥夺了我写代码的乐趣愤愤不平。现在，经过了这次强度更大、程度更深的人机协作，我又找到了另一种更“复合”的乐趣。这种乐趣既包括从 AI 难以替代人类的部分找到的存在主义价值，也体现在高速迭代的节奏中，从定义概念、切分任务、到证据拉扯、切换基线等工作的实时化。某种程度上，这更像是一个持续了40天的 RTS 游戏，而不是回合制游戏——不止要求思考强度，还要求手速。

最后，致谢一起战斗、帮我挡枪、又一个人承担文档工作的项目经理S老师。