被喷了我索性扔出价值过万的AI编程prompt

刚醒，就看到朋友给发来的消息说我被人喷了。

在一篇公众号文章里，针对我 昨天的文章 中的招聘信息指出： 我不把人当人了。

而这篇文章题为《 Vibe Coding的第一批受害者出现了！ 》，也是差点 让我以为自己也是个 Vibe Coding 的一大受害者了。

事实上，从我看来则是：觉得这样要求过高，是不把人当人，这确实会是大部分人的感受，确实只属于少数人的特质。我承认我确实要求不低： 只招优秀的人

所以，有必要在这里贴上完整的招聘要求：

我 明 确提到了不要纯 vibe coder ，并需要 对 AI 产出的质量完全把控 。

作为一名 通过了微信公众号软件工程师认证 的 非商单为生的公众号自媒体作者 （最近确实太忙拒了大把商单损失好几个亿 ），我想索性就把本来想在面试中问的问题稍微花十分钟来简单讲几个点。

第一， 要能完整准确地表达需求——如果你连想做什么都讲不清楚，就别指望 AI 能做好了。

我会把需求放在一个 markdown 的文件里，@ 这个文件之后让 Claude Code 完成。

这里有两个细节： 第一是这个文件怎么来； 其次是 为什么要放成一个文件而不是文字直接贴过去。

文件其实就是需求文档 + 技术架构和相关细节的文档。

这听起来很简单，但实际上，对我来说，是最重要的一部分。

这对比往常做传统的需求实现中，事实上， 编程环节通常不会（不应该）占掉大头的时间。

在真正动手之前，我的建议是要 多想 ，把需求吃透，把不明确、矛盾的地方找出来并确认（ 不要完全相信产品经理，他们只是普通人，甚至通常还没你优秀，逻辑不如你严谨 ），然后去思考架构、技术方案、模块应该怎么去做，甚至需要进行技术评审的环节。

最后才是编码、测试、上线。

做一个新的项目或者一个大的模块，我可能会需要花数小时，甚至两三天，去做很多技术方案的调研，去用 AI 搜索、收集和评估许多方案，最终选出合理的方案，再写到需求文档里。

这个文档中，需求只是一部分，对应产品经理的工作。

另一部分更为重要的是， 技术的细节 。

以后端为例，最为重要的是 表接口、字段、索引 ，其次是 核心的业务细节 和 数据处理流程 ，尤其是 CRUD 之外的你不告诉 AI 它就不太能做好的细节，然后是要用到的所有 中间件 ，其次是 代码组织 、 模块化结构 。

如果对标阿里，在我看来，这 至少是 P7，最好是 P8 才能做得很好的工作。

它对应的是一个 架构师和技术专家 、 技术经理 、 最差也得是一个技术组长 通常需要做的事情。

我绝不相信这是一句“给我做个五子棋游戏”，甚至是一句“给我做个淘宝”的 vibe coder 能做好的工作。

那么， 有了文档之后，为什么要放到文件里呢？

因为通常我的文档会很长，我印象里最长的，我应该有写到过 1000 多快 2000 行。

而 Claude Code 在工作的过程中，通常会多次超出上下文，会自动触发上下文压缩。

如果是纯文本贴过去，可能就被压缩飞了，一些重要的信息就丢了。 越到后面，就越离谱了。

而如果是个文件，就没这回事了。

第二、 完善文档

这也是我最近自用的一个诀窍，也在此大方分享。

我更早之前是写好这个千行级别的文档后，就直接给 AI 了，但事实上因为文档过长，难免其中会有一些矛盾或明显的错误。

这就是人和 AI 相比的劣势了，需要用到 AI 的地方了。

当然，我自己肯定可以校正好，但我可能需要花很长的时间。

所以在真正干活之前，先 @ 这个文件,然后下发指令：

全 面 阅读和理解 @xx.md 中的 需 求，指出其中明显的错误、遗漏、矛盾、不完善的地方

然后 AI 就会指出一大堆问题。

我会手动修改，重复这个过程，直到没有问题。

或者只有点无关紧要，AI 吹毛求疵指出的小问题。

然后再让他开干。

第三、 过程中全面监督

作为架构师，自然是要过程中全面监工（如果项目重要），并在发现方向有所不对时，及时制止，要么输入指导意见，要么全面撤消，更新文档后，再从头再来。

而结果上， 自然也是要 review 每一个文件，和几乎每一行代码。