AI提示词分享

很多人以为，一份好的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

使用：基于这份提示词，在docs/.ai生成AI开发文档

六、与vibe coding关系

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