在指导团队向 ai native 转型的过程中，我发现一个现象：虽然我强调多次，在让 ai 小弟干活之前务必严格把关它的计划和思路，但队员们似乎不得要领，即便是经验老道者也一样，达不到我心中的标准。
而网络上关于 vibe coding 的各类经验分享和教程大多集中在流程、MCP 工具和具体 ai agent 的新特性上，对于软件开发过程中的软性知识所言甚少。加之夸张的表现手法和过度的 hype，给人认为只要用上了新特性，给小弟配上了新工具，一切就能迎刃而解。
此类现象在软件开发的历史上一再重演，以至于我都觉得没有必要一一列举。
但是，作为一个负责任且还指望跟队员们一起探索 vibe coding 众多可能性的大哥，我觉得有必要写点东西。于是乎，在发布完我的 vscode-docpilot 插件新版之后，有了这篇文章。
三种类型的 vibe coder
在我看来，vibe coder 大致可分为三种类型，而它们又恰恰对应三种管理类型：
- 甩手掌柜型，将需求甩给 ai 小弟之后，给小弟充分的自由度，自己只负责验收结果。
- 事必躬亲型，事无巨细、亲力亲为，ai 小弟在他们面前就是打打下手，相当于搜索引擎的升级版。
- 张弛有度型，在原则性和关键点上严格把控，其他的交给 ai 小弟，自己只负责把控大局。
这三种没有对错，只有适合与否。因为最终面对用户的还是你，只要你能在小弟犯错时 hold 得住并最终交付满意的结果，你就赢了。
就目前而言，我属于第三种：既不对 ai 完全放心，但也没有那么勤快和那么多时间，能事无巨细地参与每个环节。并且，我秉承的想法是：既然花了钱，就要用扎实。故而，取了折衷的方式，美其名曰：“张弛有度”。
但是，不论你属于哪一类，假如忽视知识体系的建设，即便你有一个看似不错的开局，但最终一定会陷入困境。
坚实的知识体系是驾驭 ai 小弟的基础
这一点不难理解：缺乏问题域的知识，你将
- 无法判断 ai 小弟的计划和思路是否正确。
- 无法下达有效的指令。
- 在小弟犯错时无法及时纠正。
总之一个词：被动。
不要迷信 “CC 帮助不会写代码的我发布了第一个 app。”这样的传说。以我有限的想象力，它们成立的前提是：
- 成熟的模板类 app，比如：landing page、电商、俄罗斯方块这类小游戏等等。
- 开发者虽然不会写代码，但至少对于要解决的问题域有足够的了解，起码能把问题描述清楚，并能判断结果是否符合预期。
- 开发者会写 web，但不会写 app，诸如此类。
- 应用本身足够简单。
我在之前的文章中曾说过要将 ai 视作“人”，你能相信白痴领导可以驾驭聪明的小弟吗？
在重构遗留代码时，知识体系的重要更显凸出。比如，若是缺乏对前端最佳实践的基本了解和相应框架知识储备的不足，你很可能就无条件接受 ai 给出的华而不实的方案。于是乎，无休止的对话就开始了……
假如你能诚实面对自己的不足，又想借力 ai 来提升效率，改进代码质量，那么请至少在让它干活前，先花点时间借助 ai 来补足一下自己的短板：
- 借助 ai 快速总结相应领域的知识要点、最佳实践和最新动态。
- 借助 ai 评估现有代码的质量，明确要求它基于最佳实践来给出意见。
之后，再自行判断。同时，也请注意 ai 的问题：
- 它有 cutoff date。
- 它有点教条主义，如果不加约束，它会给出大而不当的建议。典型：
- 过度设计
- 照搬 design pattern
- 无脑照搬领域内最佳实践，但忽视了具体背景
比如，在今天的 refactoring plan 中，GC 针对现有的代码库给出建议：使用 Zustand 来替代现有的状态管理方案。但真实情况是：
- 这个项目里并没有用到 react。
- 相关代码是为 vscode 的 webview 服务，而非一般的 web app。
- 现有实现其实已经有了很好的状态管理实现。
疑惑之下，我让 CC 复核了一下 GC 的建议，同时给出我个人意见：没有必要。片刻之后，CC 给出了以下回复：
Analysis: Is Zustand Worth It?
Verdict: NO - The refactor doesn’t provide significant benefits given your current implementation because:
Your Current StateManager is Already Excellent
马基雅维利在《君主论》里表达的核心观点之一：大臣给意见，君主拿主意（原文记不得了，自己问 GPT 吧，😄）。因此，不要无条件接受 ai 的建议；否则，虽不至于落个三家分晋的下场，但你肯定会得到一坨巨大的代码屎山。
典型的知识体系至少包括：
- 业务或领域知识
- 一般性架构和设计原则
- 相关技术栈的最佳实践
- 典型的场景的 UX 模式
但，也不要被它们吓到。在 ai 时代，不妨借助 ai 快速建立高层知识地图（还记得我之前的文章中利用 deep report 的法子么？），然后在实践中再逐步填充细节。
理性面对各类生态工具和项目模板
这类工具重点在于执行侧，其本身并没有解决项目本身的复杂度。
它们的作用更像是放大器，而不是救命药：在好团队或大牛手里，放大他们的优势；在差团队或菜鸟手里，放大他们的劣势。
因此，在你抱怨 ai 小弟写出屎山代码时，不妨提出一个灵魂拷问：怎么会有这么多人为这种写屎山的 ai 小弟付费？
在我看来，使用它们的正确姿势是：
- 先审视团队自身面临的问题。
- 再看看是否能通过引入这些工具来解决。
- 请记住，引入工具会带来额外的负担。如果没有足够的收益，还是不要引入为妙。
一旦觉得适合，那么：
- 使用前，先看它们的代码。
- 使用时，基于自身的特点进行剪裁。
除了一些统计 token 或成本的工具，这类工具最终都是 prompt + 工作流 + mcp tools。比起传统的框架类代码，要容易懂得多。
其中，建议重点看看 prompt，其他两类在时间紧时忽略也罢。因为 prompt 是决定 ai 产出的关键。通过学习他人的 prompt，有助于你提升与 ai 沟通的能力，从而得到更高的杠杆率。
同时，不要迷信 subagent。还记得之前有两篇观点矛盾的文章吗？
我在无废话 Agent：理论篇中已有说明，这里就不再赘述。有兴趣的同学可以去付费阅读或自行搜索网上的讨论。
建立有助于 ai 小弟工作的环境
管理上不是经常说要当好“服务型领导”吗？面对 ai 小弟，我们也要当好“服务型大哥”，搭建一个让它能发挥最大效能的工作环境。
这样，不仅省钱，还能得到更好的结果。
为了让团队内能协调一致地使用 ai 小弟，我们建立了一套规范。并且，因为并没有内部强制要求使用某一个 ai 工具，因此整个做法都是厂家中立的。
建立 llms-txt 目录用于存放供 ai 使用的文档或代码
如果依赖的框架或工具提供了 llms.txt ，那么就直接使用；否则，使用我们自制的工具将其版本库打包成单个 markdown 文件，放在该目录下。
这里不需要对所有依赖都采用这样的方式，因为 ai 可能已经具备了常用框架的能力，如 React、Vue、Next.js 等。这里所指的依赖是指代码中起主要作用且 ai 大概率不了解的依赖。如：langchain、better-auth 等。
有人可能会说：不是已经有 deepwiki 和 context7 这类为 ai 直接提供 mcp 知识库的网站了么，何必还要这么麻烦？
很简单：
- 在之前的文章里就说过，mcp 对于 ai 写代码作用不明显，同时还容易破坏上下文，降低效率。
- 下载到本地可以避免网络依赖，同时 ai 也可以直接读取，更快。
- 这些文档都是基于官方文档而准备的原始资料，没有经过加工，更可靠。
- 因为垃圾上下文会导致 ai 产生垃圾代码。
建立 llms-skills 目录用于存放 ai 可参考的技能
在前一篇文章中，我曾提到给 ai 提供重构原则之后，它给出了更好的 refactoring plan。在此之后，我将此经验在内部进行了推广，同时形成这条规范。
这就好比给员工准备的培训资料一样，你也可以为 ai 小弟准备一份类似的资料。在此目录下，你还可以放置内部的最佳实践、代码规范等。
同时，像重构这类技能，无需给出冗长的细节，比如扔一本 MF 的《重构》，只需给出原则即可。这一工作可直接交给 gpt 来完成。
类似的原则可以包括：
- clean code
- oo design principles
- ……
记住，ai 的能力很强但健忘，你需要准备这些，在给它下指令时让它参考。
建立 prompt 模板
好的 prompt 是让 ai 发挥最大效能的关键，为了让整个团队都能更好地使用 ai，推广好的 prompt 模板是必要的。
这里，我觉得可以借鉴 CC slash command 的例子：
---
allowed-tools: ...
description: ...
---
## Context
...
## Your task
...
## Output <-- 这是我加的，😄
...如此一来，统一团队内部的 prompt 书写方式。并且，你还可以建立一个目录存放常用的 prompt。
针对不同的 ai 创建 instruction
GitHub Copilot、CC、GC 都有类似的文件用于指定 ai 的基本行为和工作方式，除非你统一团队工具，否则没有办法用一个目录来解决。可是，由于 ai 发展迅猛，统一和限制工具的做法并不可取。
因此，为了尽可能复用，我们可以：
- 在 README 中放置项目背景和技术栈。
- 将公共指令放入单独的文件，在各自的 instruction 文件中去引用。
这样，在最大限度上复用的同时，也能适配了各个厂家。
建立测试安全网，不断重构
在开发 vscode-docpilot 插件的过程中，我发现一个有趣的现象：ai 会模仿你的代码风格。
在一开始单一大 js 文件时，CC 会直接将代码一股脑地写在这个文件里。后来，经过若干次重构，代码变得结构化了，CC 也有样学样，在新功能时自动将相关功能放入相关的目录。
好的代码结构除了让 ai 可以模仿之外，还能让它更好地理解代码的意图和功能。由此，在开发新特性时会更高效，一次通过率也会更高。
因此，重构是必要的。测试则充当了重构的安全网，让你可以放心大胆地重构。
最后，简单说说我对工作流的看法：大多数时候，粗放型的工作流就足够了。越精巧的工作流，越容易出问题。原因很简单：
- ai 的能力会不断增强，你定义的工作流会很快过时。
- 过于精细的工作流会限制 ai 的发挥，反而降低效率。
- 将心思花在工作流上是忽略了你开发的本质：解决问题。
记住高大爷的说的话：过早优化是万恶之源。
结语
看到这里，有心人应该发现 vibe coding 本质上是一项技术管理技能，这对于普通开发者来说是一个不小的挑战。要用好它，不妨问自己：我怎么才能带好这个 ai 小弟？
本文包含付费内容，需要会员权限才能查看完整内容。