vibe coding怎么下手？把握一个核心原则——和人在真实世界的工作场景一样，人之前怎么做就让模型怎么做。举个例子，比如你新接手一个project，如何熟悉？step01：问项目组大佬重点是什么 ，step02：看Wiki文档， step03：看代码

      目前还在一个发展的阶段，或者说“头脑风暴的阶段”，只能写一些零零散散的东西，以及这些碎片碰撞出的新东西。就像写下面这些内容的时候，我想起一个大标题都无从下手，只能写一个个零散的小idea。

        后面期待有伟大的组织出来搞一个统一的框架！

1、如何少烧一点token。

        避免模糊的提问，能多详细就多详细，预防大于治疗的思想嘛，提前跟他都说好，比后面出错返工花费的资源少得多。

        命令行对话窗口肯定是不方便写的。我们在项目下自己新建一个我的需求.md文件，写进去，然后用在命令行对话窗@引用这个文件。

        vieb coding --> spec coding

2、把我的项目改坏了怎么办？

        CC也提供了撤回命令，但我们不用那个，我们用git进行版本管理。vibe coding时代，对git的使用门槛变高了。

3、永久了变笨了

        所有AI都有这个问题，本质上是因为上下文窗口有限。

        /compact命令主动去手动压缩上下文，最佳实践超过了60%就压。

        动辄100B200B其实真正有效的只有60-80%。就像我们脑子塞了太多东西一样，大模型太多东西，进行上下文管理。/context命令，/compact命令手动压缩(就算不手动压缩，CC也会在快满了的时候自动帮你压缩，因为不可能让你聊着聊着就聊爆了，是可以一直聊下去的)

        就算我一直有主动压缩上下文的意识，或者说上下文根本没到需要压缩的程度，也会出现问题。看下面这个场景

4、丢失上下文问题

场景：比如“我让大模型帮我写了一个番茄钟项目，给了他一个需求说明书，包括两个功能点，一个是番茄钟倒计时，一个是自定义专注时间，这两个功能都实现了。但是运行过程中，有bug，我让他调bug的时候，虽然bug修好了，他突然把第二个功能点给我扔掉了”。

        有这么几种方法：1）git进行版本管理，把他丢掉的回滚回来。2）新开一个窗口，防止注意力太深入去修bug了 3）

        但我觉得都是治标不治本，因为根本原因在于，大模型的注意力机制让他无法具有人一样的全局视野，让他修bug他就只盯着修bug（大模型的注意力机制导致的），完全忘了最根本的目的是完成一个满足需求的项目。改进的底层逻辑很简单，就是“人怎么样，就让大模型怎么样”，如何实现呢？在提示词里让他每做一次修改之前都把需求文档再读一遍，就像人时时刻刻记得需求文档要干嘛一样。直接写到Claude code的规则文件claude.md里“先去阅读@项目需求”

5、依然不具有全局视角

        大模型在看了系统代码以及SQL表结构以后，建议我在status字段上加索引。但是他不知道1）这个表实际在生产上的数据不到200万行，其实不用加索引。但是大模型是无法得知生产数据情况的。2）这个字段每隔3分钟由自动任务去更新，频繁更新的字段也不应该加索引。但是自动任务的执行策略我忘记给他了，他也就不知道这个字段每隔3分钟可能会更新。

        还有一点。我之前会给出这样的命令“给我优先级最高的三个优化”，但是我发现由于大模型不具有全局视角，而你并不知道他丢失了哪部分视角，所以他给出的不一定是优先级最高的，所以还是要人来定夺。所以后来我不再提出“给出你认为最值得/优先级最高的三个”这种命令了，我让他给出全部的，由我来判断哪些优先级最高。

6、不要一次问多个不相关的问题。

        还是那句话——“什么都想要的人什么都得不到”，本来的意图是为了节省token，不想分成4次去提问，都放到一次请求中。但一次问大模型4个不相干的问题，让大模型的注意力分散。

7、一个新任务新开一个session，上下文怎么办？或者直接我换了个模型，上下文怎么办？

        我一开始会想，第二个session如何继承第一个session的上下文呢？不继承的话那我不白聊第一个session了吗？后来想明白了，下一个session根本没必要继承上一个session的上下文。

        就像真实开发中，A和B俩人分别开发俩需求，A根本没必要知道B在做什么，A只需要把整个项目搞明白就行了。同样，在vibe coding时，开了一个session完成第一个需求，如果继续做跟第一个需求相关的，那你就直接在第一个session去做啊，没必要重开一个。重开一个那就是我要做第二个需求了，那我完全不需要第一个session的上下文，只需要把claude.md、Wiki文档、代码库加载进上下文就好了。而且相反，如果你给下一个任务塞了上一个任务的上下文反而会让他脑子乱乱的。

8、如何决定什么时候该开一个新session呢？

1）一个会话只处理一个任务，新任务开新会话

2）同一个任务，超过两次纠正还不对，就开新会话；

8、真的需要人操心这么多吗

        目前来看，需要程序员去区分的概念和工具太多了，我觉得这是CC应该去做的，以后都会由CC去做，只不过现在焦虑驱动着大家去不断进行各种尝试

        以后的发展应该是，人要操心的越来越少，只做目标规划、分工和决策这些“领导做的事情”。而不是操心上下文这些小细节！！！

9、会出现和人一样“看串行了”这样的错误

        这是我用Claude code+deepseek-v4-pro进行vibe coding时。一开始回答中出现了错误（和人一样“看串行了”的那种错误），并误导了我，后来我又给他指正。

        后面我又在想，如果不给他指正呢，这个错误就要一直存在吗？那就想想当我自己开发的时候，看串行了导致代码写错了，什么时候会发现呢？测试的时候吧。

10、规则文件里写什么？

规则文件指的是claude.md这种，每个Agent约定的规则文件不同。按照重要程度排序如下：

• 【重要】项目的代码库有几个，分别是谁谁谁
• 【重要】项目的wiki文档在哪
• 不要动哪些文件
• 技术栈是什么
• 启动命令
• 目录结构
• 错误码格式
• 业务概念的解释，比如告诉Agent“发他行”和“发二代”是一个意思
• 之前Agent犯的错
• 。。。

11、切换模型干活

坏了，老板的味儿出来了

12、最佳实践

源自：javaguide

13、对项目的掌控感变低（多人反馈）

        之前这些事都是自己去做，甲方/业务是否满意，这样做哪里有隐藏风险，风险能不能兜住，心里会有个大概，其他系统来问我们系统的边界，或者是否支持某个功能，都能很自信的给出答案。但是AI实现的功能变多以后，记不住了，这些问题在抛给开发者的时候，答不上来了，心理上对项目的掌控感变低。

14、注意力正在被冲击（多人反馈）

        就像你的领导给你分完任务以后，躲在办公室玩手机一样。给出AI指令等待反馈的过程中，用户倾向于刷手机等待，注意力屡次被分散，甚至手机的时候忘记了自己刚刚发出的指令是什么。无法进入心流状态了，人的注意力正在被冲击

15、Agent设计原则？

估计跟设计模式、微服务设计模式大差不差。

无论是23个设计模式还是微服务设计模式，都有一个很重要的原则是，单一职责原则。所以对于这个问题“以后工程师的工作中，用的是一个claude code这样的通用Agent，他可以独自完成需求分析、开发、测试这一套流程，还是三个专用Agent，一个负责产品经理的身份进行需求分析，一个负责开发，一个负责测试”，就有了答案，当然是符合单一职责原则，用三个专门的Agent去做事啦。