vibe coding 请教篇

看起来中规中矩的吧。西东是做后端的。不过西东是直接写了个持续集成，直接把上级下发业务的信息接上 OpenCode，并和 AI 在 OpenViking 记忆系统交代好各种流程，然后全部交给只有开容器权限的 OpenCode 了。OpenCode 会在全新容器里开一个 YOLO 的 OpenCode，那个 OpenCode 才是做工作的智能体。

所以西东平时什么都不用干，只需要坐在工位吃小布丁。

对了，西东采用的模型是经过 LLM as a Verifier（四并发，一验证）增强过的 MiniMax M3。

基本上就想想自己的痛点是什么 很多用户有没有类似的痛点 然后什么技术栈是对开发者和用户都比较友好的 你希望功能要通过什么方式实现 然后就可以做准备了

gpt好像无了吧

你这样仅靠提示词, 丢的东西太多了, 分两个内容介绍下我的方式

1. vibe 思路:

• 手动管理上下文


• 不要频繁创建会话


• 仅告知 LLM 需求和工作内的内容


• 不要 指导 / 规定 / 约束 一些有的没的

2. vibe 流程:

• 先让 LLM 熟悉当前要改动的模块, 内容一定要全, 不能有遗漏


• 告知 LLM 需求 / 工作流程 / 测试验收标准


• 让 LLM 制定工作计划, 输出至 PLAN.md


• 审阅并修改工作计划


• 手动压缩上下文


• 让 LLM 开始工作


• 手动校验结果, 不审阅代码


• 用另一个不同的LLM review 代码


• 提交

另外回答下你的问题:

• 看不到的模型需要手动配置一下, 但 GPT 马上要禁止 cursor 使用了


• 尽量用 cursor cli, 不要再用那个传统界面了

1. 选择一个流行的前后端分离框架，越傻瓜越好


2. 既然有原型了，让AI根据原型生成表结构，建库


3. 用框架的代码生成功能生成接口和页面


4. 根据需求和设计查漏补缺，就像刷腻子，不要想着一次追求完美，多刷几次，直到能交付

你这个自动化程度太低了。用一个厉害的模型帮你拆解任务，然后新开会话让厉害模型自己编排子代理去实现

建议你试试 Trellis 框架，现在的agent都支持

大佬请教一下，为什么用Cli不用界面呀？Cli是有什么优势么？

可能我没说清楚, 我说的是传统的那种 VsCode 界面, 左边文件树, 中间文件内容, 右边对话窗

这种无用信息量太多了, vibe coding 最重要的就是你和 LLM 的上下文

所以要用 CLI, cursor 我记得是叫 Agent 模式?我忘了, 很久不用了

• 先让 LLM 熟悉当前要改动的模块, 内容一定要全, 不能有遗漏

• 先让 LLM 熟悉当前要改动的模块, 内容一定要全, 不能有遗漏

这一条请教下，怎么才能判断LLM熟悉了全部内容啊？有个判断标准或者规则么？

怎么才算是提供了完整的内容呢？

口说可能有点晦涩, 我直接给个我常用的提示词例子:

请你按顺序阅读如下项目内容, 详细了解架构和实现:



1. README.md: 本项目概述

2. docs/requirements.md: 需求说明文档

3. app/service/: 服务类目录

4. xxxx: xxxx



有任何不清楚的内容, 可自行拓展阅读, 并逐个向我提问

一般一线模型阅读完之后, 会给你输出一个总结, 看一眼就知道他了解的如何了, 有问题再纠正

不过我很少遇到需要纠正的情况, 纠正过后我一般都会手动重建下上下文, 因为 纠正 这个动作本身就是会造成注意力缺失和重心误导的

一般一线模型阅读完之后, 会给你输出一个总结

谢谢大佬的解答

大佬，手动管理上下文具体是什么操作呢？可以详细说一下么，谢谢

我一般是三种:

• 执行 /compact 压缩上下文


• 退回上一次对话, 调整上一次的提示词


• 将当前会话结论输出至一个文件(我习惯叫HANDOFF.md), 清空会话, 让 LLM 读这个文件并调整提示词