做一个项目 用vibe coding,随着功能模块的增加 对于项目把控越来越难 有时候任务跑偏到不知道 先前的先计划再执行到增加功能这一步貌似失效了 有没有什么解决办法

回复 群友 2236： 有办法。你缺的可能不是“更详细的计划”，而是执行过程中能发现偏差、及时停下来的机制。先计划再执行只有起点，没有自动纠偏能力。 比如给已有项目“增加收藏功能”。 你以为只需要收藏、取消收藏、查看收藏列表。Agent 却发现用户模块“不够优雅”，顺手重构登录，再修改数据库结构。每一步看起来都有理由，但整个任务已经跑偏。 我建议把流程改成：查现状 → 定边界 → 小步修改 → 验收，而不是写完一个大计划就让它一直跑。 一、增加功能前，先让它调查，不准直接改 让 Agent 回答： 现有功能入口在哪？ 哪些模块和数据会受影响？ 有没有能复用的实现？ 哪些判断还没有证据，需要确认？ 要求它附上对应代码位置。这样你审查的是它对真实项目的理解，而不是一份听起来合理的方案。 如果这里就理解错了，后面的计划写得再漂亮也没用。 二、把“计划”换成有边界的任务单 还是收藏功能，可以这样写： 目标：登录用户可以收藏、取消收藏，并查看自己的收藏。 不做：收藏分类、分享、推荐，不重构登录系统。 约束：沿用现有鉴权；不能改变已有接口的返回格式。 验收：重复收藏不会产生重复数据；不同用户不能读取彼此收藏；原有登录流程仍然通过测试。 暂停条件：需要改鉴权、删除旧逻辑、引入新依赖时，先说明原因，等我确认。 这里最关键的是“不做什么”和“什么时候停”。只写目标，Agent 很容易把自己认为必要的事情不断加进去。 三、一次只交付一个你能检查的小闭环 不要一次让它“完成整个收藏系统”。 可以先做收藏和取消收藏的接口及测试，验收通过再接界面，最后检查完整用户流程。每一步都应能独立检查，最好能独立回退。 每轮结束要求它交代： 实际改了什么？ 有没有超出任务边界？ 哪些测试实际运行了，结果是什么？ 还有什么没验证？ “已经实现”和“已经验证”必须分开。Agent 说完成了，不等于功能真的可用。 四、把项目状态放进仓库，不只留在聊天里 不用一开始搞很重的文档体系，先维护三份短记录： 项目地图：模块职责、入口、依赖关系。 关键约定：接口格式、权限边界、不能随便改变的设计及原因。 当前任务：验收条件、已完成项、已知问题和下一步。 新会话先读这些记录，再检查相关代码。记录与代码冲突时要查证，不能把旧文档当真理。 这能减少“上一轮你们已经决定过，这一轮它又重新设计”的情况。 五、验收不仅看新功能，也看旧功能有没有被弄坏 模块越多，越不能靠“点一下新按钮能用”来判断完成。 至少把项目最重要的几条流程变成可重复运行的检查，例如登录、创建数据、读取数据、权限隔离。每次新增功能后重新检查。 也别只让 Agent 根据自己写的代码生成测试：你先规定预期行为，再让它实现测试，否则代码和测试可能一起理解错需求。 你可以直接给 Coding Agent 这段要求： “先不要修改代码。阅读现有实现，说明本次需求涉及的模块、可复用逻辑、影响范围和不确定点，并提供代码依据。然后提出一个最小改动方案，写清本次不做什么、验收条件和需要暂停确认的情况。经我确认后分步实现，每步报告实际改动和验证结果，不顺手重构无关模块。” Anthropic 关于长时间运行 Agent 的工程文章，也采用了类似思路：明确功能清单、增量完成、保留进度记录，并通过测试验证，而不是靠一轮长对话持续推进。 https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents 核心不是让你盯住每行代码，而是保证：每次改动小到你能理解，边界清楚到能识别越界，结果具体到能验证。