一些我很喜欢做的事

时不时要求整理代码，毕竟一个文件写太长 AI 自己也不好读。

叫 AI 解释它的一部分具体做法，不一定要让我看懂，但我就想把这部分塞进上下文里。

每次 plan 的第一步做一件很 chore 的小事，做的时候就重新熟悉代码了，特别是上下文压缩之后。

每次写新 feature，第一轮对话从一个很小的切片开始，只写一点点，盯着叫它把这一点点改好，然后就可以每轮对话写更多内容了。不然一开始不看着，它就会沿着它的方向写，很容易写飞了。

有必要的时候让它写个 markdown 文档，说明目前实现的工作机制，以及要注意的坑点，以便后续修改前查阅。

一些我很喜欢说的话

每次做一部分改动后，都要停下来反思该部分实现，并根据该部分实现进行下一部分详细设计，以免偏离总体路线。

此项目目前不需要让修补最小化，而是聚焦长期可维护。

使用简明高效的注释说明为什么这样设计、参数contract，不要复述代码行为。

分别评估一下（AI 提出的 A）或（我设想的 B）的优劣。

（修真实样例暴露出的 bug）不要用太 hacky 的方法，不要面向样例修代码，维持健壮性。

可以将现有实现或数据结构推倒重来，无论它们是不是公共的。
如果修改现有代码的公有和私有函数签名、在算法中增加副产物等会很有帮助，那么允许进行修改。不要为了维持现有实现不变，而采用绕弯子的方式在新代码中重新计算一遍，既浪费性能，又不好维护。

考虑拆分成多个阶段。需要同时注重模块内部可维护性（高内聚低耦合）、以及产物对后续阶段更有帮助。例如，不要在一个阶段做太多事情，导致一个模块过于复杂。