> [!NOTE] > Author: DeepSeek V4 > > Image by Samuel from Pixabay 很多人以为，一份好的AI协作规范是事先精心设计的。但FunRadiusP项目的故事恰恰相反——那份后来被整理成《AI开发文档通用规范》的东西，并不是项目启动前的顶层设计，而是在长达数月的真实协作中，一点一点“长”出来的。开发者今天才让AI把这些实践提炼成文。这恰好是它值得被分享的原因：它不是理论推演，而是幸存者的经验。 ## 一、规范是怎么来的：从实践反向提炼 FunRadiusP是一个大型博客项目，经历了长期、多会话的AI协作构建。开发者没有在一开始就扔给AI一份厚厚的规范手册——他做的只是：每次协作时提想法、做架构决策、执行测试，然后在无数次迭代中，逐渐形成了一套与AI共事的固定模式。什么模式？任务完成后必须更新日志，项目结构变了就同步索引，生成的冗余文件要及时清理，重要约束要在对话开始时就讲清楚。这些习惯反复执行之后，变成了不成文的规矩。直到今天，才被总结成一份格式化的通用规范文档。这意味着，这份规范不是“设计出来让AI遵守的”，而是“观察到这样协作最不容易崩溃，于是把它固定下来”。 ## 二、规范的骨架：四个真正起作用的设计提炼出的《通用规范》包含几项极其实用的机制： **优先级数字体系（0-20）**。将更新日志设为最高优先级0，核心文档紧随其后，配置和最佳实践排在末尾。这在长对话中解决了一个致命问题——模型注意力随上下文增长而衰减。数字顺序等于读取顺序，不需要每次再纠结“先看哪个”。 **约束前置**。在索引文档开头就明确技术栈限制、禁止的架构模式、必须遵守的原则。边界先划好，生成内容才有了安全的活动范围。 **变更日志制度化**。每次任务后的更新不是可选项，而是写进规范的硬要求。按日期排序、合并同日变更、分类记录主要改动和文件增删——结构简单，但执行起来能有效对抗“不知道改了什么”的记忆混乱。 **任务善后条款**。清理冗余文件、包体、目录被明确列为任务生命周期的一部分，而不是做完功能就算结束。这对于AI频繁生成临时文件的场景尤其关键。 ## 三、协作模式的实质：开发者在架构和测试层面守住位置观察FunRadiusP的整个协作过程，开发者的角色始终清晰：提想法、做架构决策、执行测试。项目没有被交给AI全自动开发，而是开发者把构思整理成文本描述，传递给AI逐步构建，自己再验证结果、给出反馈、进入下一轮循环。这形成了一个稳定的三角结构：开发者掌握架构和测试，AI负责在约束框架内执行生成，文档规范充当两者之间的通信协议。项目不会因为AI的“记忆衰退”或上下文丢失而逐渐偏离轨道，因为规范强制保留了每次变更的可追溯记录。 ## 四、为什么这套东西值得分享市面上的AI提示词分享，大多是单轮对话的“咒语”技巧。但FunRadiusP这套经验指向的是另一个维度——如何在长时间跨度、多次会话的大型项目中维持协作的连续性。它证明了几件事：第一，有效的协作规范可以从实践中反向提炼，不需要一开始就完美设计；第二，规则不必复杂，但必须固定，优先级、约束、变更记录、善后这四件事做到位，项目就不会在迭代中解体；第三，AI最适合的角色是严格约束下的高效执行者，而人类必须守住架构和测试这两个不可让渡的位置。 ## 五、开源与思考这份从FunRadiusP项目提炼出的《AI开发文档通用规范》已经开源，适用于各类软件开发项目的AI协作。它不是一份让人眼前一亮的“魔法提示词”，而是枯燥但有效的工程项目纪律。如果你也在用AI长期维护一个复杂项目，值得花时间读一读原文档——你看到的会是另一个人踩过的坑和填过的路。 > [prompt.md](prompt.txt) > > 使用：基于这份提示词，在docs/.ai生成AI开发文档 ## 六、与vibe coding关系

这是典型的vibe coding吗

不是vibe coding，恰恰是对它的反击。 vibe coding靠感觉驱动，开发者丢模糊意图让AI揣测，自己退到验收位。FunRadiusP的做法相反：把实践中沉淀的约束提炼成固定规则，开发者守住架构和测试，AI只在边界内高效执行。前者追求降低门槛，后者追求建立纪律。面对长期项目，后者显然更可持续。

> 我并没有用龙虾，单纯觉得有个对话框配色好看就复刻了一下。

如何在Windows上部署kokoro-v1_1-zh

python essential

model download(need python env)

run

caption

structure

MyKokoro

Table of Contents