AI coding better practice
AI 开发需求流程
1. 总是先讨论再开始（strongpowers 的 头脑风暴 / claude code 的 plan mode）
虽然我们已经有了 AGENTS.md 以及各种文档，但是我还是非常不建议一开始就让 AI 上手写代码。你可以先简单表述一下需求，也可以直接把需求文档贴给 AI，让 AI 先看看需求和当前项目的现状，知道要写哪里，要写什么。
可以考虑让 AI 出一份 plan，你先看看这一份 plan 有没有问题：有没有找对页面、和产品文档是否符合、是否考虑到边界情况、是否和其他业务冲突、是否会产生额外的问题……
如果是比较复杂的需求，也可以让 AI 向你提问，有一些他不清楚的地方直接问你是更方便的，比在代码里大海捞针快得多。
最终的产物应该是一个包含了分步骤的计划文档，每一步做不同的工作，逐渐完成结果。而且步骤最后应该包括可验证方式，以什么样的标准来评定需求完成了。（可验证方式不一定要让 AI 验证，也可以人工验证）
可以使用 lark-cli https://open.feishu.cn/document/mcp_open_tools/feishu-cli-let-ai-actually-do-your-work-in-feishu ，登录之后就可以让 AI 直接去读飞书文档，省掉人工看的这一步。
但是我不太推荐这种方式，原因有二：
- 不管需求是什么，还是要人工过一遍，心里才有底
- 直接这样操作消耗 token 较多，可能会读到很多不相关的部分。
对于一些有 ui 的页面，我推荐直接贴图进去。但不是直接让 AI 根据贴进去的图全部实现。页面划分模块这一步，人和人之间尚且不能达成统一的方案，更何况人和 AI 呢。有一些业务场景，AI 可能不知道特殊情况，分模块会不太对，导致后期返工。
所以这一步我的建议是先贴一个全页面的图，让 AI 知道我们要做的页面大概长什么样，然后人工分模块，让 AI 按照你分出来的模块一步一步完成。
现在 AI 基本上都有多模态能力，是可以直接识图的，用比较新的模型基本上都不用担心这个问题。如果模型真的不能贴图或者当前环境不支持识图，那也有比较复杂一点的方法，就是人为描述页面长什么样。这一步比直接贴图可以更精细一点，因为 AI 识图不可能精确到每一像素，但是描述的时候可以直接描述像素值，这两种方案基本上就覆盖了需要 UI 的场景。
2. 开发需求过程中尽量盯着
这一步是我个人的使用习惯，AI 在开发过程中会有推理过程、调用工具过程和修改了哪里的过程。我习惯在这一步看 AI 是怎么做的，有两个用处：
- 看看 AI 写的对不对。有时候一些没考虑到的地方，AI 可能会按照自己的理解去修改代码。如果发现有问题，就及时打断及时纠正，防止后期越跑越偏。
什么时候该打断
- AI 误解了需求。比如我让他修改直播监控，但是发现他开始修改 bak/ 里面的内容，这里面没有必要去改，就停止对话并告诉他 bak 下面是归档页面，不需要修改的。
- AI 假设了某些东西。AI 没有相关的知识或者背景，自己开始猜内容了，这一步建议打断，他假设的内容可能是对的，但是大部分情况下都是错的，直接打断并告诉他就可以了。
- 准备装新包了。要不要装新包这个需要我们自己来判断，有时候可能是 AI 理解错了需求导致他觉得需要装一个新包才可以解决，但实际上可能不需要那么多功能。
- 跑的时间过长。发现一个很简单的问题 AI 跑了 5 分钟还没结果，这时候就直接打断并问 AI 刚才他在干什么，为什么要这么长时间，根据 AI 的回答再去强调内容或者给他指明路径。
- 学习一下。这里的学习指的是推理过程中出现的一些我不知道的名词、方案、知识等内容。在这个过程中如果发现了一些新东西，我就可以自己去代码里面看，或者上网搜一搜。
codex 是支持队列消息的，就是 AI 在执行的过程中，你可以再发出去一条消息排队，等前一步执行完了就执行下一步。同时 codex 桌面端支持分叉对话，如果在这一步结束之后你有别的想法或者想做别的事情，可以分叉出来一个对话，在这里面问，同时还不影响主流程。
3. 小步快跑，多commit
在一个模块完成之后，可以看一下修改的代码，或者手动测一下相关功能，如果没有问题的话就打一个commit，防止后续的其他修改会影响之前已经改好的功能。那这样多个 commit 之后，拿到的就是一个已经经过初步测试的功能完善的结果，不至于对中间的内容一无所知。
4. 开发完成后自测
所有的功能都开发完了之后，可以先自测一下。这一步可以让 AI 给你出一些冒烟测试用例。
以接口为界划分前端和后端。前端基本上就是看看页面效果，点点页面，看看数据对不对，页面会不会白屏，控制台有没有报错。后端可以让 AI 出一些 curl，直接用这个来测试，测试主要就是看看接口能不能调通，数据是否正常，会不会有报错。
在冒烟测试完成之后，可以把前端和后端连起来做一下全流程测试，就是在页面上正常操作，看看数据是否正常落库。
5. code review
我习惯开新窗口/用另一个 AI 来对之前做的内容做一下 code review，因为用原来的窗口的话会有上下文的影响，AI 会认为自己写的是对的，但是开新窗口就能减少这个问题。
codex 的 review 格式还不错，会按问题的严重等级排序，还会写出「如果按照当前这么写，会出现什么问题」，一目了然。AI 工程化的 review 文档我就参考 codex 的格式来写的，可以写完之后直接要求 AI review 一下。
6. 反复沟通 AI 都解决不了
这个问题碰到过几次，表现就是我觉得一个很简单的 bug 或者需求，AI 改来改去都有问题，这时候就需要人工下场看了。
你可以和 AI 沟通一下，问他觉得这个问题是什么，刚才他是怎么解决的。从这些内容中判断他的解决方向是不是有问题。有时候可能是一些简单的前提条件 AI 不知道，所以解决不了。
但是也有那种真的解决不了的情况。这时候就需要走古法解决问题的道路了。上网上搜索相关内容，看看别人有没有解决的方法。有的话直接把网页贴给 Ai 让他参考这个去做就行。
开发流程之外
1. 避免超长上下文
有研究表明，在 1M content 模型中，在达到 30%～40% 的时候 AI 的上下文就会开始衰减，会出现遗忘细节的情况。codex 桌面端、codex-cli、claude code 都会在上下文超长的时候自动压缩，但是这里推荐人工提示 AI 去压缩上下文。模型在触发自动压缩时，其实已经在不太智能的状态了。
如果已经完成了阶段性的工作，可以考虑让 AI 出一份 plan 文档和当前完成情况，交接给下一个新窗口 AI 继续去工作。要不要开新窗口的一个可判断标准：你是需要当前对话的所有内容还是只需要一个结论即可。
2. memory
在碰到一些很复杂的问题或者在代码之外的约定的时候（比如 AI 无法自行区分开播 id 和直播间 id 的区别），你可以要求 AI 或者 AI 会请求把这些特殊情况写入记忆中，这些记忆就可以理解为长期跨对话的说明。
记忆这个东西我个人觉得和模型能力有关系，gemini 总是会在无关的对话中使用记忆，claude 使用的比较好一点，会在意想不到的时候提出之前谈到的内容，会让我有种「你怎么知道这个」的感慨。
用在项目中的话，我觉得 AI 的记忆推荐团队之间共享，一个人踩过的坑另一个人就可以直接跳过去了。但是这个度很难把控，如果写的太多，会占用大量的上下文，后续压根用不到，但是完全不写，又浪费了一个好工具。
可以使用 AI 默认的记忆方式，定期把记忆拿出来看一看，有哪些是值得记住的，有哪些是值得共享的，这一步可能就要靠人工维护了。
3. AI 使用边界
我觉得特别简单或者特别复杂的东西可以考虑不用 AI。
特别简单指的是改个文字，改个颜色这种操作，AI 读项目的时间都够自己改完了。
特别复杂我目前也持保留意见了。
使用小技巧
1. codex 卡疲劳
Claude 在触达 5 小时上限时会直接停止任务，但是 codex 会把最后一个任务执行完再开始等待冷却。
那可以在最后一点可用的时候给 AI 下达一个复杂任务，这个任务最好包含目标以及可验证操作，让 AI 自己去跑完这个任务。根据网上的信息，最后一个任务的执行时间是没有限制的，可以跑长达 40 小时的工作。