发生了什么

和破聊了一些AI开发上的经验，现在AI开发的上下文窗口虽然很长，但是越往后聊是越容易出幻觉的。对于一个常规修改的实践，我通常是这样的工作流：

• 尽可能保持工作区干净
• 从一个最简单的需求描述开始，我的原则是描述一些必要的背景信息、描述现状、然后再提出需求并告知AI期望的结果，然后再与AI进行需求细节的对齐 （这边建议使用Grilling的Skill）
• AI一次性将功能改好
• 如果AI改的不好，那么就通过git放弃变更，重新再开一个会话，调整提示词，重新输出
• 审查并提交代码

这里不建议让AI在改错的情况下，在错误的基础上继续修改。举一个网上流传的经典例子，你想让AI制作一个正宗苏式东坡肉，他一顿操作，告诉你正宗苏式东坡肉做好了。但他采用了一个不正宗的做法，在东坡肉里加入了陈醋。于是你告诉他不要加入陈醋，又一顿操作后告诉你，正宗苏式东坡肉（无陈醋版）做好了。

从结果的角度看显然是没问题的，但是这种对于无陈醋版的备注和修改会留在代码库里。而代码库是Agent的上下文，大语言的模型的本质只是根据前文内容不断预测下一个词语。这样的情况下，就有可能在代码库不断扩张的同时，把这种不好的模式继续繁殖下去。所以更好的做法是丢掉这部分的代码，调整提示词，更加严格的定义AI应该做什么，不应该做什么，让他再做一遍。

如果作为一个长程的大型任务，那么则需要从架构整体分阶段规划并执行任务，从最小能跑通的原型，到完整的功能，要求每一阶段都要人为验收再进入下一阶段，需要在合适的时机对上下文进行压缩。这可能就是一个另外的更大话题，之后再聊这部分吧hhhh

一些分享

这简直是神奇的黑暗魔法哈哈哈哈，要做到这件事情，其实在思路上很简单，也就是将所有的逻辑和数据部分都与引擎隔离，任何的AI行为，数值计算，地图数据等都脱离引擎，而在引擎层仅作为渲染、处理玩家输入、音频等内容。通过这样的方式，将游戏的运行时数据和状态完全隔离开，让其可以接入到任何引擎中。

事实上杀戮尖塔团队应该也有类似的开发经验，从一些mod工具的日志显示中就能看出一些端倪。在Unity调整收费政策时他们才敢大胆的切换引擎。我想RimWorld团队从开发最开始就做了这样的实践。当然思路简单也不代表实践起来很容易，这十分考验工程师的抽象思维和架构能力。

预期

探索一下自己博客的宣传对外渠道，想让更多更广的人参与讨论